Re: New build failure emails are difficult to act on

[Jeremy Huddleston Sequoia]

> On Nov 2, 2016, at 06:52, Lawrence Velázquez <lar...@macports.org> wrote:
> 
> Can you open a ticket for this and assign it to me? You can just
> copypaste your original email as the description or something.

Thanks:  https://trac.macports.org/ticket/52810#ticket

> 
> vq
> 
>> On Nov 2, 2016, at 3:56 AM, Jeremy Huddleston Sequoia 
>> <jerem...@macports.org> wrote:
>> 
>> 
>>> On Nov 2, 2016, at 00:20, Mojca Miklavec <mo...@macports.org> wrote:
>>> 
>>> On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote:
>>>> I've been having a bit of difficulty dealing with the new buildbot emails. 
>>>>  I would really like links to the individual failing jobs.  Instead, we're 
>>>> given links to each job and a list of failed ports, but there is no 
>>>> indication as to which port corresponds to which job.  One must look 
>>>> thorough each link to find the relevant one.
>>>> 
>>>> Could we get those links added to the 'Broken ports' section?
>>> 
>>> Sure. We gladly accept patches :) :) :)
>>> 
>>> OK, joke aside. I wrote the part of the code that generates the
>>> emails, but I did not manage to figure out how to map the build
>>> number/url to a port. Buildbot nine is apparently more clever about
>>> that and there it should apparently be more straightforward to do it,
>>> but many are reluctant to switch just yet.
>>> 
>>> There are several ways to fix this:
>>> 
>>> - hack into Python code (most elegant, but I did not have any success
>>> with that yet)
>>> 
>>> - I once tried to fetch the contents of json files for individual
>>> builds and parse it, but that crashed/froze the buildbot (it might be
>>> that I wrote buggy code, but that approach is super ugly anyway)
>>> 
>>> - probably the easiest workaround would be to print the URL or the
>>> build number to
>>> https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764/steps/summary/logs/stdio
>>> which would make it easier to map the URLs to ports.
>>> 
>>> Somewhat related tickets:
>>> https://trac.macports.org/ticket/52766
>>> https://trac.macports.org/ticket/51995
>> 
>> FYI, My current hack method is to open the 'Full logs:' link, check out the 
>> summary, and then figure out from that list which of the job's to check (if 
>> the third job failed, pick the link with the third number in the series).
>> 
>> --Jeremy
>> 
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 



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

New build failure emails are difficult to act on

[Jeremy Huddleston Sequoia]

I've been having a bit of difficulty dealing with the new buildbot emails.  I 
would really like links to the individual failing jobs.  Instead, we're given 
links to each job and a list of failed ports, but there is no indication as to 
which port corresponds to which job.  One must look thorough each link to find 
the relevant one.

Could we get those links added to the 'Broken ports' section?

Eg:

> Begin forwarded message:
> 
> From: build...@macports.org
> Subject: Build Failure: lldb-devel
> Date: November 1, 2016 at 19:19:05 PDT
> To: jerem...@macports.org, lar...@macports.org
> Reply-To: nore...@macports.org
> 
> Status:   Failure
> Build slave:  ports-10.8_x86_64_legacy
> Full logs:
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764
> Build reason: The SingleBranchScheduler scheduler named 'ports' triggered 
> this build
> Port list:llvm-devel libcxx llvm-3.9 llvm-3.8
> Subport list:
>   - clang-3.8
>   - clang-3.9
>   - clang-devel
>   - libcxx
>   - lldb-devel
>   - llvm-3.8
>   - llvm-3.9
>   - llvm-devel
> Variants: None
> Revision: b41cdadc7fcefb70f64303bbba494373654cc3dd
> Build time:   1:33:43
> Committer:Jeremy Huddleston Sequoia <jerem...@macports.org>
> 
> Log from failed builds:
>   Building 'lldb-devel' ... [ERROR]
>   > maintainers: jerem...@macports.org,lar...@macports.org.
> 
> Broken ports:
>   - lldb-devel
> 
> Responsible maintainers:
>   - jerem...@macports.org
>   - lar...@macports.org
> 
> Links to individual build jobs:
> - ports-10.8_x86_64_legacy-builder #9429
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9429
> - ports-10.8_x86_64_legacy-builder #9430
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9430
> - ports-10.8_x86_64_legacy-builder #9431
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9431
> - ports-10.8_x86_64_legacy-builder #9432
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9432
> - ports-10.8_x86_64_legacy-builder #9433
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9433
> - ports-10.8_x86_64_legacy-builder #9434
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9434
> - ports-10.8_x86_64_legacy-builder #9435
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9435
> - ports-10.8_x86_64_legacy-builder #9436
>  
> https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/9436
> 
> -- 
> Best regards,
> MacPorts Buildbot
> https://build.macports.org/
> 

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

Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)

[Jeremy Huddleston Sequoia]

> On Nov 1, 2016, at 17:47, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote:
>> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70
> 
>> [...]
> 
>> commit 864eb7639d6774a7853767be6b15384c790bfe70
>> Author: Jeremy Huddleston Sequoia <jerem...@macports.org>
>> AuthorDate: Tue Nov 1 16:52:53 2016 -0700
>> 
>>libcxx: Bump to 3.9.0 (#52666)
>> 
>>Signed-off-by: Jeremy Huddleston Sequoia <jerem...@macports.org>
> 
> Please do not use the # syntax anymore in commit messages. This is now
> reserved for references to pull requests on GitHub. Instead, paste the
> full URL to the Trac ticket into the commit message:
> 
> Closes https://trac.macports.org/ticket/52666
> 
> When you add keywords such as "closes", "fixes", "fix" in front of the
> ticket URL, the ticket will also automatically be closed with a
> reference to the commit.

Cool, thanks.  I missed that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac & Subversion available again

[Jeremy Huddleston Sequoia]

> On Oct 21, 2016, at 18:16, Clemens Lang  wrote:
> 
> Hello MacPorts users and developers,
> 
> On Fri, Oct 21, 2016 at 08:12:59PM +0200, Clemens Lang wrote:
>> Due to the current SVN and Trac downtime, we are also discussing to
>> make the move of Trac sooner if that helps us restore service earlier.
>> We will keep you informed on this.
> 
> Due to the current unplanned downtime, we brought the migration of our
> Trac installation forward and finished it today. Pending DNS
> propagation, you should be able to reach Trac at trac.macports.org
> again. Note that you will need a GitHub account to log into Trac now.
> 
> Please make sure that you have added the email address you used in Trac
> to your GitHub account. A cronjob will automatically associate your
> tickets and other contributions with the GitHub login a few minutes
> after your login.

How often does this job run?  It's been about a day now, and I still cannot 
edit tickets (beyond making comments).  My @macports.org email address was on 
my github account months ago, so that's not the issue.

--Jeremy

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

Re: llvm / clang and thread_local storage problems

[Jeremy Huddleston Sequoia]

That's not really a reduced test case.  It would be helpful if we could get a 
reduced test case of the problem that doesn't involve having to debug the 
entire guile application.  An ideal test case would be a small C or C++ file 
without external dependencies that showcased the issue.

--Jeremy

> On Oct 20, 2016, at 10:20 AM, Jack Howarth <howarth.at.macpo...@gmail.com> 
> wrote:
> 
> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
> <jerem...@apple.com> wrote:
>> 
>>> On Oct 9, 2016, at 09:47, Jack Howarth <howarth.at.macpo...@gmail.com> 
>>> wrote:
>>> 
>>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>> <jerem...@apple.com> wrote:
>>>> thread_local support was added in OS X 10.9 (along with 
>>>> __cxa_thread_atexit being added to Libc as part of that support).  As long 
>>>> as your minimum deployment target is 10.9, you should be fine.  The issue 
>>>> is that you're on 10.6, so you don't have __cxa_thread_atexit.
>>>> 
>>>> There is active conversation right now about adding a fallback 
>>>> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
>>>> https://reviews.llvm.org/D21803 as that might be quite useful for your 
>>>> needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
>>>> get it in.
>>> 
>>> On the topic of thread local support, the failures in the guile 2.0.x
>>> test suite should be looked at...
>>> 
>>> https://trac.macports.org/ticket/52556
>>> 
>>> to determine if Apple's thread-local-storage implementation is buggy
>>> as upstream guile claims.
>> 
>> Radar?
> 
> Jeremy,
>  I finally puzzled out how to run the offending test case in
> guile by itself. This can be done using the current MacPorts guile
> 2.0.13 using...
> 
> 
> 1) Installl MacPorts and then execute "sudo port -d install guile" in
> a Terminal window to install the dependencies required for guile as
> well as guile
> 2) In a terminal window, execute 'sudo port -d build guile' to rebuild
> guile retaining the build directory.
> 3) change directory into the MacPorts build directory for guile
> 2.0.13. In my case this was with
> 
> cd 
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
> 
> 5) change to sudo because MacPorts work directories are owned by root
> 
> sudo csh
> 
> 4) set the required environmental variables for the guile-test test
> harness script...
> 
> setenv GUILE_LOAD_PATH
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
> setenv TEST_SUITE_DIR
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite/tests
> 
> 5) finally run the failing test case under the installed MacPort's guile...
> 
> /opt/local/bin/guile  -e main -s guile-test srfi-18.test
> 
> Running srfi-18.test
> FAIL: srfi-18.test: thread-terminate!: termination destroys non-started thread
> FAIL: srfi-18.test: thread-terminate!: termination destroys started thread
> 
> Totals for this test run:
> passes: 59
> failures:   2
> unexpected passes:  0
> expected failures:  0
> unresolved test cases:  0
> untested test cases:0
> unsupported test cases: 0
> errors: 0
> 
> I've added those details to radar://28688091 "guile 2.0.12 exposes
> potential thread-local-storage bug on Mac OS X".
> Jack
> ps The problem was that the comments in the guile-test test harness,
> for running the tests individually, mentioned the need to set
> TEST_SUITE_DIR but failed to discuss the need to set GUILE_LOAD_PATH
> as well.
> 
> 
>> 
> ___
> 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

Re: llvm / clang and thread_local storage problems

[Jeremy Huddleston Sequoia]

> On Oct 9, 2016, at 09:47, Jack Howarth <howarth.at.macpo...@gmail.com> wrote:
> 
> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
> <jerem...@apple.com> wrote:
>> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
>> being added to Libc as part of that support).  As long as your minimum 
>> deployment target is 10.9, you should be fine.  The issue is that you're on 
>> 10.6, so you don't have __cxa_thread_atexit.
>> 
>> There is active conversation right now about adding a fallback 
>> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
>> https://reviews.llvm.org/D21803 as that might be quite useful for your 
>> needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
>> get it in.
> 
> On the topic of thread local support, the failures in the guile 2.0.x
> test suite should be looked at...
> 
> https://trac.macports.org/ticket/52556
> 
> to determine if Apple's thread-local-storage implementation is buggy
> as upstream guile claims.

Radar?



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

Re: Of C++ (and other) runtimes

[Jeremy Huddleston Sequoia]

> On Oct 7, 2016, at 08:59, René J.V. Bertin  wrote:
> 
> On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote:
> 
> [was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of 
> using libstdc++]
> 
>> it might be useful to refine this mechanism to allow something like
>> "configure.compiler.cxx macports-gcc-XYZ", which would add a direct
>> library dependency on libgcc (among other things).
> 
> Yep, that sounds like a good idea, but can that not be handled by the 
> existing configure.cxx syntax?
> 
> BTW: how risky is it to replace libc++ on newer OS X versions which do in 
> fact provide them?

My advice is to not mess with the base OS.  There is a very good reason why I 
force the user to use a variant and don't even give instructions on how to use 
darwinup to install the libcxxabi and libcxx tarballs.

That being said, it's technically possible and they should be binary compatible.

I was actually using the newer libcxxabi and libcxx ports on Lion and Mountain 
Lion for a while.  The only issue I saw was that a system process (helpd or 
something like that) was crashing (I think on ML).  I didn't dig into the 
issue, but it's possible it was just a bug in the daemon that was revealed by 
the newer C++ runtime.  It's also quite possible there was a serious regression 
in the C++ runtime.  I never got around to looking into it more closely.

> And since we're talking about runtimes: is it even possible to upgrade the 
> ObjectiveC runtime, as far as that is of any interest when you don't upgrade 
> the rest of the SDK using it?

It's all code and objc4 is OSS.  Go nuts 
(http://opensource.apple.com/source/objc4/objc4-680/).  Make backups.  YMMV.

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



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

Re: llvm / clang and thread_local storage problems

[Jeremy Huddleston Sequoia]

thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
being added to Libc as part of that support).  As long as your minimum 
deployment target is 10.9, you should be fine.  The issue is that you're on 
10.6, so you don't have __cxa_thread_atexit.

There is active conversation right now about adding a fallback implementation 
of __cxa_thread_atexit directly into libcxxabi.  See 
https://reviews.llvm.org/D21803 as that might be quite useful for your needs.  
If so, provide a patch to libcxxabi that incorporates it, and I'll get it in.

Thanks,
Jeremy


> On Oct 8, 2016, at 23:06, Ken Cunningham  
> wrote:
> 
> 
> On 2016-10-08, at 10:03 PM, Stephen J. Butler wrote:
> 
>> FYI, it's in the Xcode 8 release notes:
>> 
>> https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html
>> 
>> I did a quick test file and it seems to compile with Apple clang. No clue on 
>> compatibility issues though.
>> 
> 
> Thanks!
> 
> 
>> Thanks for finding and sharing that information. It sounds like you could 
>> get TLS by using MacPorts clang instead of Xcode clang, but that it will be 
>> incompatible with whatever TLS implementation Apple eventually creates.
> 
> 
> I had hoped it would be in the macports-clang-3.7 build I'm using, but it 
> seems to error out.
> 
> However, I noticed this bit in the the libcxxabi port 
> 
> libcxxabi-3.7.0.src/include/cxxabi.h
> 
> 
> #ifdef __linux__
> // Linux TLS support. Not yet an official part of the Itanium ABI.
> // 
> https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables
> extern int __cxa_thread_atexit(void (*)(void *), void *, void *) throw();
> #endif
> 
> and - if I open up that guard, it actually builds cleanly on MacOSX.
> 
> I wonder if TLS support was just disabled on all but Linux...perhaps I'll try 
> installing this new version I just built and see what happens. --- after I 
> back everything up :>
> 
> Ken
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 22, 2016, at 12:32, Adam Dershowitz <de...@alum.mit.edu> wrote:
> 
> 
> 
>> On Sep 22, 2016, at 3:24 PM, Jeremy Huddleston Sequoia 
>> <jerem...@macports.org> wrote:
>> 
>> 
>>> On Sep 22, 2016, at 10:37, Adam Dershowitz <de...@alum.mit.edu> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 22, 2016, at 1:07 PM, Jeremy Huddleston Sequoia 
>>>> <jerem...@macports.org> wrote:
>>>> 
>>>>> 
>>>>> On Sep 22, 2016, at 07:19, Adam Dershowitz <de...@alum.mit.edu> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 22, 2016, at 4:49 AM, Jeremy Huddleston Sequoia 
>>>>>> <jerem...@macports.org> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Sep 21, 2016, at 12:45, Adam Dershowitz <de...@alum.mit.edu> wrote:
>>>>>>> 
>>>>>>> It does:
>>>>>>> 
>>>>>>> $ xcode-select -p
>>>>>>> /Applications/Xcode.app/Contents/Developer
>>>>>>> 
>>>>>>> 
>>>>>>> For me some updates in Macports, including some builds, seem to work 
>>>>>>> OK, and others, such as cmake, are giving an error:
>>>>>>> https://trac.macports.org/ticket/52258
>>>>>>> 
>>>>>>> I’m not sure if I then need to completely switch to Xcode 7?  Or if I 
>>>>>>> can just install the command line tools for 10.11 Xcode 7.3.1?  If I do 
>>>>>>> that, where do they install, so that I can point xcode-select to the 
>>>>>>> proper path?
>>>>>> 
>>>>>> If you don't have the CLTools installed, you wouldn't be able to install 
>>>>>> most of MacPorts.  I'm pretty sure you likely have them installed.
>>>>>> 
>>>>>> Dropping back down to Xcode 7 would mean that Xcode.app would contain 
>>>>>> the 10.11 SDK and would workaround your issue, but the issue is that the 
>>>>>> port isn't honoring your SDK (and maybe deployment target) selections 
>>>>>> (which default to / and host os version respectively).
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> Something is still not clear to me.  I had Xcode 7 installed.  I was 
>>>>> under the impression that it included the SDK internally, so I don’t 
>>>>> think that I had separately installed the CLTools (although I’m not 
>>>>> positive).  
>>>> 
>>>> Do you have /usr/include on your system?  If you do, you installed the 
>>>> CLTools.
>>> 
>>> Yes, I do.  Although I can’t confirm when I might have installed it (is 
>>> there an easy way to tell if the headers were from some older version i.e. 
>>> 10.7,10.8 etc?).
>> 
>> $ pkgutil --file-info /usr/include/AvailabilityInternal.h
>> 
>> or just:
>> 
>> $ grep 'define __MAC_OS_X_VERSION_MAX_ALLOWED' 
>> /usr/include/AvailabilityInternal.h
>> 
>> The OS upgrade should remove that path, so you likely installed it at some 
>> point since upgrading your OS.
> 
> I do have the 10.11 tools installed (although they are slightly different 
> from each other and from my current OS:
> 
> $ pkgutil --file-info /usr/include/AvailabilityInternal.h
> volume: /
> path: /usr/include/AvailabilityInternal.h
> 
> pkgid: com.apple.pkg.DevSDK
> pkg-version: 10.11.3.0.1.1456982112
> install-time: 1457024872
> uid: 0
> gid: 0
> mode: 644
> 
> pkgid: com.apple.pkg.DevSDK_OSX1011
> pkg-version: 7.3.1.0.1.1461711523
> install-time: 1462497081
> uid: 0
> gid: 0
> mode: 644
> $ grep 'define __MAC_OS_X_VERSION_MAX_ALLOWED' 
> /usr/include/AvailabilityInternal.h
>#define __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_11_4
> 
> But, likely close enough.  


Yep, there were no SDK changes in 10.11.5 and 10.11.6, so there was no need to 
release SDK updates for those OS versions.

What you have there is exactly as expected.

>>>>> And, I have used macports for many years without a problem (over many 
>>>>> versions of Xcode).  When Xcode 8 was released I installed it, but didn’t 
>>>>> install CLTools either.
>>>>> What still isn’t clear to me is if cmake and openmodelica (which does 
>>>>> have the same problem as cmake, but it also depends on cmake so I tried 
>>>>> to bu

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 22, 2016, at 10:37, Adam Dershowitz <de...@alum.mit.edu> wrote:
> 
> 
> 
>> On Sep 22, 2016, at 1:07 PM, Jeremy Huddleston Sequoia 
>> <jerem...@macports.org> wrote:
>> 
>>> 
>>> On Sep 22, 2016, at 07:19, Adam Dershowitz <de...@alum.mit.edu> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 22, 2016, at 4:49 AM, Jeremy Huddleston Sequoia 
>>>> <jerem...@macports.org> wrote:
>>>> 
>>>> 
>>>>> On Sep 21, 2016, at 12:45, Adam Dershowitz <de...@alum.mit.edu> wrote:
>>>>> 
>>>>> It does:
>>>>> 
>>>>> $ xcode-select -p
>>>>> /Applications/Xcode.app/Contents/Developer
>>>>> 
>>>>> 
>>>>> For me some updates in Macports, including some builds, seem to work OK, 
>>>>> and others, such as cmake, are giving an error:
>>>>> https://trac.macports.org/ticket/52258
>>>>> 
>>>>> I’m not sure if I then need to completely switch to Xcode 7?  Or if I can 
>>>>> just install the command line tools for 10.11 Xcode 7.3.1?  If I do that, 
>>>>> where do they install, so that I can point xcode-select to the proper 
>>>>> path?
>>>> 
>>>> If you don't have the CLTools installed, you wouldn't be able to install 
>>>> most of MacPorts.  I'm pretty sure you likely have them installed.
>>>> 
>>>> Dropping back down to Xcode 7 would mean that Xcode.app would contain the 
>>>> 10.11 SDK and would workaround your issue, but the issue is that the port 
>>>> isn't honoring your SDK (and maybe deployment target) selections (which 
>>>> default to / and host os version respectively).
>>>> 
>>>> 
>>> 
>>> 
>>> Something is still not clear to me.  I had Xcode 7 installed.  I was under 
>>> the impression that it included the SDK internally, so I don’t think that I 
>>> had separately installed the CLTools (although I’m not positive).  
>> 
>> Do you have /usr/include on your system?  If you do, you installed the 
>> CLTools.
> 
> Yes, I do.  Although I can’t confirm when I might have installed it (is there 
> an easy way to tell if the headers were from some older version i.e. 
> 10.7,10.8 etc?).

$ pkgutil --file-info /usr/include/AvailabilityInternal.h

or just:

$ grep 'define __MAC_OS_X_VERSION_MAX_ALLOWED' 
/usr/include/AvailabilityInternal.h

The OS upgrade should remove that path, so you likely installed it at some 
point since upgrading your OS.

>>> And, I have used macports for many years without a problem (over many 
>>> versions of Xcode).  When Xcode 8 was released I installed it, but didn’t 
>>> install CLTools either.
>>> What still isn’t clear to me is if cmake and openmodelica (which does have 
>>> the same problem as cmake, but it also depends on cmake so I tried to build 
>>> that with the working cmake) should work with my current configuration?  Do 
>>> they each have a bug?  Should just installing 10.11 CLTools allow them to 
>>> build?
>> 
>> It's possibly a bug in cmake and openmodelica ports (they're using the SDK 
>> inside of Xcode.app even though MacPorts is configured to use /).
>> 
>> It's definitely a bug in cmake and openmodelica upstream.  They're failing 
>> to build properly for the older deployment targets when using newer SDKs.
> 
> In that case, it sounds likely that installing the newer CLTools won’t help, 
> since I already have /usr/include.  So, at this point my options are to wait 
> for bug fixes, or to downgrade.

Yes.

>>> Perhaps the answer, that I was missing, is that to use Xcode 8, on 10.11, 
>>> the user must explicitly install CLTools, but that would not be the case to 
>>> run Xcode 7 on 10.11 or Xcode 8 on 10.12?
>> 
>> Depends on your perspective.  We'd like to be in the world where you don't 
>> need to install the system headers, but 90% of OSS software fails when the 
>> SDK is newer than the base system because most OSS assumes that the SDK 
>> matches the minimum deployment target.
> 
> 
> Thanks.  



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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 21, 2016, at 13:44, Jack Howarth  wrote:
> 
> On Wed, Sep 21, 2016 at 4:19 PM, Rainer Müller  wrote:
>> On 2016-09-21 21:15, Adam Dershowitz wrote:
>>> That comment does not make it at all clear what those of us who updated to 
>>> Xcode 8 (but not beta!) but are still on OS X 10.11 are supposed to do.
>>> I have posted a ticket about building cmake that seems to be because it is 
>>> trying to use 10.12 SDK, but it is not clear how to work around that.
>> 
>> That would be normal. The latest SDK can be used on previous systems.
>> For example, on OS X 10.10 Yosemite, Xcode 7.2 also only ships the 10.11
>> SDK.
>> 
> 
> Though apparently not for the SDK installed in / by the Command Line
> Tools!  

The SDK installed at / needs to match the base system.  If you installed 10.12 
headers to /, projects would fail to link due to header / library mismatch.

> Otherwise, Apple wouldn't have declared that there will be no
> 10.11 Command Line Tools in the Xcode 8 releases and would have
> provided  a 10.11 Command Line Tools for Xcode 8.1 which installed the
> 10.12 SDK in /.

Apple never declared that.

The only thing stated is that there would be no release for Xcode 8 (ie, 8.0).

The issue that prompted us to not ship the tools was discovered very late in 
the 8.0 cycle and will take time to address.  We are aware of the problem and 
are working on a solution.

In the mean time, you should just use the 7.3 CLTools (for the SDK at /) and 
Xcode 8.0 for the toolchain.

--Jeremy

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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 21, 2016, at 13:02, Jack Howarth  wrote:
> 
> On Wed, Sep 21, 2016 at 3:46 PM, Marko Käning  wrote:
>> Hi,
>> 
>> there is no CLT for Xcode 8?
>> 
>> How come Xcode 8.0 tells me in "Preferences/Locations" that it uses CLT 
>> "Xcode 8.0 (8A218a)”!
>> 
> 
> Launching the Xcode 8 application should resolve the license issue.
> 
>> I recently ran into this issue
>> ---
>> :info:configure
>> :info:configureXcode not set up properly. You may need to confirm the 
>> license
>> :info:configureagreement by running /usr/bin/xcodebuild without 
>> arguments.
>> :info:configure
>> ---
>> with Xcode 8 on El-Capitan myself when trying to install port:qt5(-kde).
>> 
>> 
>> 
>> Qt’s configure script errors out because of a non-found xcrun:
> 
> The xcrun copy in Xcode.app has been deprecated out in favor of the
> system copy in /usr/bin.

Slight correction there... it was deprecated around Xcode 5.
It was removed in Xcode 8.

> Upstream qt development fixed this issue by changing the failing test
> for xcrun to one for xcodebuild.
> 
> https://trac.macports.org/ticket/52200
> 
>> ---
>> $ which xcrun
>> /usr/bin/xcrun
>> $ /usr/bin/xcrun -find xcrun
>> xcrun: error: unable to find utility "xcrun", not a developer tool or in PATH
>> ---
>> 
>> René thus suggested the attached patch for qt5(-kde) as a workaround .
>> 
>> Greets,
>> Marko
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>> 



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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 21, 2016, at 12:46, Marko Käning  wrote:
> 
> Hi,
> 
> there is no CLT for Xcode 8?
> 
> How come Xcode 8.0 tells me in "Preferences/Locations" that it uses CLT 
> "Xcode 8.0 (8A218a)”!

That refers to what is selected via xcode-select.  That means that xcrun and 
the stubs like /usr/bin/clang result in usage of the toolchains within that 
Xcode.app version.  The CLTools toolchain is in 
/Library/Developer/CommandLineTools.  If you have Xcode.app installed, you 
likely don't even care about /Library/Developer/CommandLineTools and the only 
reason you need the CLTools package is for the headers for the base system 
(/usr/include, et al.)


> 
> I recently ran into this issue 
> ---
> :info:configure
> :info:configureXcode not set up properly. You may need to confirm the 
> license
> :info:configureagreement by running /usr/bin/xcodebuild without arguments.
> :info:configure
> ---
> with Xcode 8 on El-Capitan myself when trying to install port:qt5(-kde).
> 
> 
> 
> Qt’s configure script errors out because of a non-found xcrun:
> ---
> $ which xcrun
> /usr/bin/xcrun
> $ /usr/bin/xcrun -find xcrun
> xcrun: error: unable to find utility "xcrun", not a developer tool or in PATH
> ---
> 
> René thus suggested the attached patch for qt5(-kde) as a workaround.
> 
> Greets,
> Marko
> 
> 
> 
> 
> 



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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 21, 2016, at 12:45, Adam Dershowitz  wrote:
> 
> It does:
> 
> $ xcode-select -p
> /Applications/Xcode.app/Contents/Developer
> 
> 
> For me some updates in Macports, including some builds, seem to work OK, and 
> others, such as cmake, are giving an error:
> https://trac.macports.org/ticket/52258
> 
> I’m not sure if I then need to completely switch to Xcode 7?  Or if I can 
> just install the command line tools for 10.11 Xcode 7.3.1?  If I do that, 
> where do they install, so that I can point xcode-select to the proper path?

If you don't have the CLTools installed, you wouldn't be able to install most 
of MacPorts.  I'm pretty sure you likely have them installed.

Dropping back down to Xcode 7 would mean that Xcode.app would contain the 10.11 
SDK and would workaround your issue, but the issue is that the port isn't 
honoring your SDK (and maybe deployment target) selections (which default to / 
and host os version respectively).



> 
> --Adam
> 
> 
> 
>> On Sep 21, 2016, at 3:40 PM, Jack Howarth  
>> wrote:
>> 
>> On Wed, Sep 21, 2016 at 3:15 PM, Adam Dershowitz  wrote:
>>> That comment does not make it at all clear what those of us who updated to 
>>> Xcode 8 (but not beta!) but are still on OS X 10.11 are supposed to do.
>>> I have posted a ticket about building cmake that seems to be because it is 
>>> trying to use 10.12 SDK, but it is not clear how to work around that.
>>> Perhaps the answer is to downgrade to Xcode 7, and stay away from 8?  (It 
>>> is a big download!)
>>> Or, it might be that just the 10.11 command line tools is enough?
>>> 
>> 
>> If you install Xcode 8 on 10.11, you need to make sure that
>> 'xcode-select -p' reports /Applications/Xcode.app/Contents/Developer
>> so that you are actually using the Xcode 8 compilers. The Command Line
>> Tools installed by Software Update or 'xcode-select --install' on
>> 10.11 will be those from Xcode 7.3.1 and will provide the 10.11 SDK
>> installed in /.
>> 
>>> --Adam
>>> 
>>> 
>>> 
 On Sep 21, 2016, at 2:44 PM, Lawrence Velázquez  
 wrote:
 
 Jack Howarth has noted on IRC that that Apple will not be releasing
 a Command Line Tools package for Xcode 8 on El Capitan [*].
 
  There is no Command Line Tools (OS X 10.11) for Xcode
  8 package. Xcode 8 contains SDKs that are incompatible
  with earlier toolchains. Developers who want to make use
  of the Xcode 8 SDKs from the command line must choose
  the SDK with xcode-select. Developers on OS X El Capitan
  who have installed versions of the Command Line Tools
  (OS X 10.11) for Xcode 8 Beta should install Command
  Line Tools (OS X 10.11) for Xcode 7.3.1. (28234439)
 
 Do we need to adjust our installation instructions to account for this?
 The consequences of mixing the Xcode 7 CLT with Xcode 8 are not clear to
 me; maybe it's not a problem at all.
 
 [*]: 
 http://adcdownload.apple.com/Developer_Tools/Xcode_8.1_beta/Release_Notes_for_Xcode_8.1_beta.pdf
 
 vq
 ___
 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
> 



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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 21, 2016, at 12:15, Adam Dershowitz  wrote:
> 
> That comment does not make it at all clear what those of us who updated to 
> Xcode 8 (but not beta!) but are still on OS X 10.11 are supposed to do. 

If you don't need the CLTools, do nothing.
If you need the CLTools, install the latest version (or likely just stick with 
the version that you have if you already have them).

> I have posted a ticket about building cmake that seems to be because it is 
> trying to use 10.12 SDK, but it is not clear how to work around that.

If a port is using an SDK and you haven't configure it to do so, that's a port 
bug.

> Perhaps the answer is to downgrade to Xcode 7, and stay away from 8?  (It is 
> a big download!)

Why?  Fix the bug in the port.

> Or, it might be that just the 10.11 command line tools is enough?

The 10.11 CLTools installs the 10.11 headers to /.  Your issue with cmake is 
likely that the port is (incorrectly) trying to use the 10.12 SDK and expecting 
it to match the base system somehow... ?

> 
> --Adam
> 
> 
> 
>> On Sep 21, 2016, at 2:44 PM, Lawrence Velázquez  wrote:
>> 
>> Jack Howarth has noted on IRC that that Apple will not be releasing
>> a Command Line Tools package for Xcode 8 on El Capitan [*].
>> 
>>  There is no Command Line Tools (OS X 10.11) for Xcode
>>  8 package. Xcode 8 contains SDKs that are incompatible
>>  with earlier toolchains. Developers who want to make use
>>  of the Xcode 8 SDKs from the command line must choose
>>  the SDK with xcode-select. Developers on OS X El Capitan
>>  who have installed versions of the Command Line Tools
>>  (OS X 10.11) for Xcode 8 Beta should install Command
>>  Line Tools (OS X 10.11) for Xcode 7.3.1. (28234439)
>> 
>> Do we need to adjust our installation instructions to account for this?
>> The consequences of mixing the Xcode 7 CLT with Xcode 8 are not clear to
>> me; maybe it's not a problem at all.
>> 
>> [*]: 
>> http://adcdownload.apple.com/Developer_Tools/Xcode_8.1_beta/Release_Notes_for_Xcode_8.1_beta.pdf
>> 
>> vq
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 



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

Re: No Xcode 8 CLT for El Capitan

[Jeremy Huddleston Sequoia]

> On Sep 21, 2016, at 11:44, Lawrence Velázquez  wrote:
> 
> Jack Howarth has noted on IRC that that Apple will not be releasing
> a Command Line Tools package for Xcode 8 on El Capitan [*].
> 
>   There is no Command Line Tools (OS X 10.11) for Xcode
>   8 package. Xcode 8 contains SDKs that are incompatible
>   with earlier toolchains. Developers who want to make use
>   of the Xcode 8 SDKs from the command line must choose
>   the SDK with xcode-select. Developers on OS X El Capitan
>   who have installed versions of the Command Line Tools
>   (OS X 10.11) for Xcode 8 Beta should install Command
>   Line Tools (OS X 10.11) for Xcode 7.3.1. (28234439)
> 
> Do we need to adjust our installation instructions to account for this?
> The consequences of mixing the Xcode 7 CLT with Xcode 8 are not clear to
> me; maybe it's not a problem at all.

No need to change any instructions for MacPorts.

Install the Xcode 7 CLT
Install Xcode 8.0
Everything will work the way you want.

The only reason that we have our users install the CLT package is for the SDK 
that is installed at /.  There is no difference between that content in the 
Xcode 7 CLT and what would have been the Xcode 8 CLT.

The only difference is that the Xcode 8 CLT would contain the Xcode 8 toolchain 
at /Library/Developer/CommandLineTools.  Unfortunately, this toolchain 
(specifically swift) is not compatible with the OS X 10.11 SDK, so we did not 
ship it and are working on a solution to the problem.

--Jeremy



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

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 19, 2016, at 04:18, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
> 
>>> TMPDIR points into /var/folders.
>> 
>> Yes, and it looks like those do get cleared out on boot.
>> 
>> Note, however, that this particular case relates to the cache dir, not tmp 
>> (C, not T).
> 
> Oh, right, but there are icon caches in both C and T dirs:
> 
> {{{
> %> sudo sh -c "du -hcs /var/folders/*/*/*/com.apple.IconServices"
> 81M/var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices
> 264K
> /var/folders/11/_bf842l54ngf42g66hkzslmwgp/T/com.apple.IconServices
> 82M/var/folders/99/yvy25dd94jn_ykbfkf1q4mzwgw/C/com.apple.IconServices
> 88M/var/folders/gf/wmgp2zv506dcsg7_cjxx69m4gr/C/com.apple.IconServices
> 234M
> /var/folders/j1/1439ppj08xj8h6006s6drbq0gs/C/com.apple.IconServices
> 11M/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/com.apple.IconServices
> 80M/var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/C/com.apple.IconServices
> 264K
> /var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/T/com.apple.IconServices
> 12K/var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.IconServices
>  0B/var/folders/zz/zyxvpxvq6csfxvn_n0/T/com.apple.IconServices
> 12K/var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/C/com.apple.IconServices
>  0B/var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/T/com.apple.IconServices
> 577Mtotal
> }}}
> 
> Those are compressed sizes; uncompressed they take about 5.5Gb .
> 
> 
>>> How large is your own icon cache directory? And asking here is me 
>>> investigating. I wouldn't really know where else to ask, Apple's 
>>> support/discussions forum? Doesn't seem like the most appropriate place to 
>>> discuss this kind of thing :)
>> 
>> 6 MB for me.  1MB each for two others.
> 
> Right, looks like something isn't right - or something was changed 
> significantly since 10.9. 

I suspect a change is at least part of it.  On 10.9, I see 
com.apple.IconServices that contain ISCacheTOC and *.iscachebmp files.  On 
10.10, I see com.apple.iconservices (notice the case difference) that contains 
a single store.index file, and there is a global 
/Library/Caches/com.apple.iconservices.store (which is 28 MB on my system).

> I do have a 277Mb large /opt/local/share/icons, but those shouldn't be picked 
> up by Apple's IconServices (only a few icon theme directories have ever been 
> opened in the Finder, and only by me, not any of the other users with big 
> icon caches.
> 
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 19, 2016, at 03:31, René J.V. Bertin  wrote:
> 
> On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote:
> 
>> /var/tmp definitely isn't cleared though.
> 
> TMPDIR points into /var/folders.

Yes, and it looks like those do get cleared out on boot.

Note, however, that this particular case relates to the cache dir, not tmp (C, 
not T).

> Here's an example entry from macports's icon cache:
> 
> %> sudo afsctool -vvv 
> /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1C57091BDD19F39A692B6.iscachebmp
>  
> /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1C57091BDD19F39A692B6.iscachebmp:
> File is HFS+ compressed.
> File content type: dyn.age80w65dqfv0u3pcrz2a
> File size (uncompressed data fork; reported size by Mac OS 10.6+ Finder): 
> 4194304 bytes / 4.2 MB (megabytes) / 4 MiB (mebibytes)
> File size (compressed data fork - decmpfs xattr; reported size by Mac OS 
> 10.0-10.5 Finder): 112916 bytes / 115 KB (kilobytes) / 112 KiB (kibibytes)
> File size (compressed data fork): 112932 bytes / 115 KB (kilobytes) / 112 KiB 
> (kibibytes)
> Compression savings: 97.3%
> Number of extended attributes: 0
> Total size of extended attribute data: 0 bytes
> Approximate overhead of extended attributes: 536 bytes
> Approximate total file size (compressed data fork + EA + EA overhead + file 
> overhead): 115488 bytes / 115 KB (kilobytes) / 113 KiB (kibibytes)
> 
> There are a number of files of the same size, plus many smaller. I have no 
> idea how I can map this to an actual icon though.
> 
> 
>>> Even if keeping track of who's entitled to access which bits of cached icon 
>>> info the cache agent could prune the cache, removing everything that hasn't 
>>> been accessed for more than a reasonably long time.
>> 
>> Again, I think you are seeing something anomalous.  You should investigate 
>> before jumping to conclusions.
> 
> How large is your own icon cache directory? And asking here is me 
> investigating. I wouldn't really know where else to ask, Apple's 
> support/discussions forum? Doesn't seem like the most appropriate place to 
> discuss this kind of thing :)

6 MB for me.  1MB each for two others.

# du -scm /private/var/folders/*/*/*/com.apple.iconservices
6   
/private/var/folders/c1/7p4m5bx904392j49x1w2vyxhgn/C/com.apple.iconservices
1   
/private/var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.iconservices
1   
/private/var/folders/zz/zyxvpxvq6csfxvn_n0z07r/C/com.apple.iconservices
6   total




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

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 19, 2016, at 00:34, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote:
> 
>>>> Yes, of course it's possible.  Don't.  There's nothing special about the 
>>>> UID in this case that has anything to do with what you're seeing.
>>> 
>>> So what does make the difference?
>> 
>> What is "the difference" that you want?  All users have a user session, and 
>> if logged in to the gui, they also have an aqua (gui) session.  All users.
> 
> As I said, there's an order of magnitude difference in the size of the icon 
> cache for users like root, and that of users like macports or ldap.

Well, that has nothing to do with the username or uid.  It has to do with what 
the user is doing.

> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is 
> emptied at boot.

No.  /tmp is emptied at boot, not /var/tmp and not /var/folders.

> My machine has been up for 35 days, and in that time I certainly didn't log 
> any of the "incriminated" users into an aqua session.

Well, if you're able to update to 10.10+, launchd2 is much much nicer at 
helping triage such things...

> I did things as the macports user that could explain why an IconServiceAgent 
> was started for it, but that's it. FWIW, I removed the entries for a few 
> other users before reporting here, including avahi - those haven't come back 
> yet.
> 
> A difference I could think of is a setting that tells the system not to let a 
> particular user log in to a gui session.
>  Which is why I thought of a UID<500; those at least don't show up in the 
> login manager. But maybe they can still be logged in if the login manager is 
> in traditional text (= no icon) mode?

There are ACL settings somewhere to control that.  It's not based on uid.  I 
don't recall what it is off the top of my head.

>>> Possibly a tool, but what could have that effect? AFAIK the icon cache is 
>>> chiefly used by the Finder, so anything that leverages the Finder might 
>>> cause an icon cache to be populated.
>> 
>> It's marked as RunAtLoad on my system (Sierra).  That would explain why it's 
>> running, even if nothing needs it...
> 
> But RunAtLoad for whom

For all users.

> , and when?  Boot time? Or login, and if so, what kind of login?

The user (background) session is created whenever the user does pretty much 
anything (ssh, cron, sudo -u, screen sharing, etc.).
The gui (aqua) session is created wheneger the user logs in to the gui (screen 
sharing, console, etc).

> How many copies do you have running now?

Of what?

User domains?  11:
$ launchctl print system | grep com.apple.xpc.launchd.domain.user
com.apple.xpc.launchd.domain.user.235
com.apple.xpc.launchd.domain.user.502
com.apple.xpc.launchd.domain.user.200
com.apple.xpc.launchd.domain.user.260
com.apple.xpc.launchd.domain.user.55
com.apple.xpc.launchd.domain.user.92
com.apple.xpc.launchd.domain.user.501
com.apple.xpc.launchd.domain.user.212
com.apple.xpc.launchd.domain.user.89
com.apple.xpc.launchd.domain.user.202
com.apple.xpc.launchd.domain.user.0

iconservicesagent processes? 2, one in the system domain and one in my user's 
aqua session:
$ ps aux | grep iconservicesagent
jeremy677   0.0  0.1  2918544  19908   ??  SMon09AM   0:08.85 
/System/Library/CoreServices/iconservicesagent
root   92   0.0  0.0  2516172492   ??  Ss   Mon09AM   0:00.47 
/System/Library/CoreServices/iconservicesagent

> What surprises me is that every user would have to need a personal icon cache 
> for every icon in the system.
> I know user A could have an app installed with a doc type having a particular 
> icon that no other user on the system is likely to encounter, but would it 
> hurt if they did get to see the icon if they stumbled across such a document? 
> IOW, would it be bad if all file-to-icon associations were cached in a 
> central location, 1 copy for everyone?

Yes.  That's a clear privacy violation.  User A could use that to determine 
what applications User B has installed.  If there happened to be some kind of 
image rendering exploit, User A could install an app private to them to cause 
User B to render compromised icons.  Etc, etc, etc.

> Not only does that cache get big, it also consists of plenty of small files, 
> which makes its actual footprint on disk even larger (due to blocksize; I 
> think that hasn't changed with SSDs?).

Have you looked at the cache to see exactly what the icons are that are taking 
up so much room?  I suspect that might give you a clue as to how they're 
gettin

Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 18, 2016, at 04:25, René J.V. Bertin  wrote:
> 
> Hi,
> 
> This isn't actually about codesigning but something that may have come up 
> because of my testing in that domain.
> 
> I got a low disk space warning (for an unrelated reason) and hunting down the 
> space eater I noticed this:
> 
> {{{
> %> id macports
> uid=502(macports) gid=503(macports) 
> groups=503(macports),12(everyone),61(localaccounts),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),100(_lpoperator)
> %> ps -u 502
>  UID   PID TTY   TIME CMD
>  502  1476 ?? 0:26.85 /sbin/launchd
>  502  1479 ?? 0:19.00 /usr/sbin/distnoted agent
>  502  3843 ?? 0:00.14 /usr/libexec/xpcd
>  502  3844 ?? 0:13.81 com.apple.IconServicesAgent
>  502 94723 ?? 0:00.06 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/md
>  502 95293 ?? 0:00.19 /usr/sbin/cfprefsd agent
> }}}
> 
> I'm not sure if it's normal that macports has a launchd running

That all looks as expected for someone on OS X 10.9.  launchd2 in 10.10+ did 
away with per-user launchd.  All domains are managed by the same process.

> or to what extent that has to do with my recent tests of using that user's 
> keychain for codesigning. I started the Keychain Utility as user macports, 
> maybe that's what launched launchd c.s.
> Anyway, I don't see any valid reason why the macports user would have a 
> fullblown icon cache. In my case each cache directory eats up about 900Mb. 
> Some may find that insignificant; I still consider it a waste of space.

That's pretty large.  I'm a bit surprised by that.

My macports user's disk usage is about 90 MB, mostly for its pch cache.

> I also notice that users like root and _securityagent have *much* smaller 
> icon cache directories. Does anyone know if there's a setting or other means 
> to limit the information being cached by users that should never run 
> full-blown sessions? Could it be related to the UID being larger or smaller 
> than some symbolic value (often 500 on Unix)?
> 
> Evidently the macports user isn't the only one that's concerned: any user 
> added by MacPorts is (polkituser, polkitd, avahi, ldap, ...)
> 
> Is it possible to create users with UID<500 despite those numbers being 
> "reserved by Apple"?

Yes, of course it's possible.  Don't.  There's nothing special about the UID in 
this case that has anything to do with what you're seeing.


> 
> Thanks,
> René
> 
> PS: this is what afsctool reports about my icon caches
> {{{
> %>  sudo afsctool -cfvv -8 -J4 /var/folders/*/*/C/com.apple.IconServices

What is -J4?  I don't see that option mentioned, and afsctool seems to bawk at 
it.

> Adding 
> /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/8d/5ghf31k1063f1wcln60nd91hgv/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/99/yvy25dd94jn_ykbfkf1q4mzwgw/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/gf/wmgp2zv506dcsg7_cjxx69m4gr/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/j1/1439ppj08xj8h6006s6drbq0gs/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.IconServices to 
> queue
> Adding 
> /var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/C/com.apple.IconServices to 
> queue
> Starting 4 worker threads to process queue with 8617 items
> 11% [33.45%] .. 21% [33.95%] .. 32% [33.63%] .. 42% [31.99%] .. 52% [30.15%] 
> .. 63% [29.08%] .. 73% [27.90%] .. 84% [27.30%] .. 94% [27.62%]
> Processed 8617 entries
> Total number of files: 14016
> Total number of file hard links: 0
> Total number of folders: 0
> Total number of folder hard links: 0
> Total number of items (number of files + number of folders): 14016
> Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 6306042064 
> bytes / 6.32 GB (gigabytes) / 5.88 GiB (gibibytes)
> Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5 
> Finder): 665214917 bytes / 678.6 MB (megabytes) / 647.2 MiB (mebibytes)
> Folder size (compressed): 676008333 bytes / 689.4 MB (megabytes) / 657.5 MiB 
> (mebibytes)
> Compression savings: 89.3%
> Approximate total folder size (files + file overhead + folder overhead): 
> 698299808 bytes / 698.3 MB (megabytes) / 666 MiB (mebibytes)
> }}}
> 
> IOW, they compress about 10x. A real shame HFS doesn't have transparent, 
> online compression!!



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

Re: Fakeroot destrooting [Was: Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 13, 2016, at 2:06 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Tuesday September 13 2016 01:39:41 Jeremy Huddleston Sequoia wrote:
> 
>> That's just the nature of things.
> 
> Yeah, life sucks and all that ...
> 
>> Do you have 3rd party menu extras?  IIRC, you're on 10.9, and 3rd party menu 
>> extras run in SystemUIServer.  I frequently got SystemUIServer crashes 
>> thanks to iStat Menus.
> 
> Indeed, I have a few. In fact, even Qt's "systray" icon thingy may rely on 
> menu extras, I never checked that.
> 
> So, what crashes now due to iStat Menus? :)

The newer versions are much more stable.  I haven't seen the frequent crashes 
that I used to, but if they were to crash, they would just tear down their own 
separate process instead of all of SystemUIServer. =)

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

Re: Fakeroot destrooting [Was: Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 13, 2016, at 00:14, René J.V. Bertin  wrote:
> 
> On Monday September 12 2016 21:51:55 Jeremy Sequoia wrote:
> 
> I can confirm that there *is* feedback on radars, though I do have to admit 
> that in my case it is usually one of 3 forms:
> - works as intended
> - please check if the issue still exists in the latest release (typically 
> months later)
> - please install the latest OS X version and tell us if the bug still persists

Yes, ADC often sends template responses for bugs that are reported against old 
OS versions or when fixed (or we believe are fixed) in various releases.

> Esp. the latter response doesn't really help. I know that clinging to an old 
> OS X release isn't the ideal solution either, but I think that a different 
> approach would be more constructive as long as a version is still supported 
> and receives updates of whatever kind. 

Sometimes bugs are fixed in newer versions of the OS and not backported to 
older OS versions because they don't meet the criteria for an SU.  Many bugs 
got fixed in Sierra that won't get fixed in an El Cap software update.  That's 
just the nature of things.


On the flip side, a significant percentage the radars that I receive have 
insufficient information for action, and I send them back with detailed 
instructions on providing me with a sysdiagnose, sample projects, etc, etc.  I 
usually do so within days of receiving the radar, and they sometimes sit for 
months without action on the part of the originator.


> There are software providers out there who tend to give the impression they 
> don't always take into consideration the fact that we (as in those who file 
> bug reports) don't work for them, and Apple aren't completely foreign to that.
> 
> Anyway, a bit off-topic :)
> 
> R.
> 
> PS: no, I cannot think of any open radars I filed about issues that keep 
> nagging me. I may have filed one about a frequent SystemUIServer crash when 
> getting back to my session from the login screen, but I actually haven't seen 
> that crash for a bit now.

Do you have 3rd party menu extras?  IIRC, you're on 10.9, and 3rd party menu 
extras run in SystemUIServer.  I frequently got SystemUIServer crashes thanks 
to iStat Menus.

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



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

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 09:44, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Saturday September 10 2016 08:45:38 Jeremy Huddleston Sequoia wrote:
> 
>> Yes, for most cases we would probably not need root access at activation 
>> time, but for those cases you just listed, we would.  We could do a pass 
>> over the bom to determine if root access is needed or not.  The UI for 
>> handling such a case is non-trivial.  Do we prompt once for the entire run 
>> of the process or escalate permissions for each port we encounter and then 
>> drop them again?  If 8 ports are being installed and 4 require root, that's 
>> not a good user experience to prompt for password 4 times.
> 
> I think it'd be up to the port to indicate if it requires root privileges 
> during the destroot. This is (implicitly) what happens with ports that create 
> a new user or group; there's a phase that requires root (configure, I think).

> How's that handled at the UI level? I'm guessing that the phase will simply 
> fail for the port(s) that don't have the appropriate privileges.


My point is not about the failure case but the working case.  

Ideally, the user would be able to do 'port -v -s install '.

The secure thing to do is not escalate until we need to, prompt, do our thing, 
then throw away the privs when done.  The problem with that is that we'd ask 
for credentials 2-3 times during the install and only when we need them.

The less secure thing to do is just ask for credentials up front if anything 
will need root access and then just promote/demote as needed.

The latter is a better user experience, and perhaps this can be the default but 
configurable for those that want more security.

>>> I understand that the certificate catching is coupled to the file's inode 
>>> (whatever that is under HFS+), and the new copy indeed had a new inode. And 
>>> yet another inode after signing it.
>> 
>> If you can reproduce this, please let me know and file a radar with details 
>> and let me know the number, so I can followup internally on it.  I haven't 
>> seen such cases.  The only issue I'm aware of is with overwriting an 
>> existing file (eg: using cp instead of mv).
> 
> To make this reproducible I'd probably be looking at the following sequence?
> 1) copy a binary from some original and ad-hoc sign it
> 2) delete it
> 3) copy the original once more and sign it with another certificate
> 
> Correct me if I'm wrong, but I think that's what a `port -n upgrade --force` 
> boils down to if signing is done in the post-activate, no?
> Is there any reason to expect that the certificate used in 3) must be a new 
> one not yet used to sign other executables?
> 
>> iOS was never branded as UNIX.  It is UNIX-like, but it was never UNIX.
> 
> AFAIK it is or used to be based on OS X, evidently without the userland but 
> with a comparable kernel. Was that just a shortcut way of thinking of things?

iOS has the same core os macOS.  Much of everything below the UI layer is 
shared between the two platforms, but there are subtle differences, similar to  
how tvOS and watchOS are forked from iOS.

Even though iOS shares much of the same codebase as macOS, it is not UNIX.  
Apple has never certified iOS as UNIX.


>> I've got an internal 1TB SSD and it is more than enough for most of my 
>> needs.  I mainly use USB for thumbsticks and my camera.  In such cases, the 
>> throughput is bottlenecked on the attached device, not the bus.
>> 
>> That being said, my server machine is a 2012 MacMini, and I've got a 
>> DroboMini and a LaCie RAID attached to it via thunderbolt, and the 
>> throughput and latency are more than adequate for my demanding needs.
> 
> Thunderbolt external disks and 1TB SSDs are simply out of my budget.
> 
>> For folks like you and me, it might be a minor concern being limited to 1TB, 
>> but we can certainly use an external SSD or an SDXC to increase storage as 
>> needed in the future.
> 
> I see it as more than a minor concern. Not because I expect I'll ever need 
> more than 1TB internal space, but I would certainly not feel comfortable when 
> I know I cannot replace something that can fail that easily and unpredictable 
> as an SSD (or HDD for that matter). I don't recall but it's quite likely too 
> that I replaced the HDD in my current MBP with a Hitachi as soon as I 
> received the machine.

FWIW, HDDs are much more flakey than SSDs.  I've had to replace countless HDDs 
in my life, but I've yet to see one of my SSDs reach the end of their lives.

> My only experience to date with SSDs was as an external. Connected over FW800 
> (the fastest bus I had at the time) showed 0 gain over a good HDD ... and the 
> whole thing died catast

Re: Fakeroot destrooting [Was: Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 09:38, Clemens Lang <c...@macports.org> wrote:
> 
> Hi,
> 
> On Sat, Sep 10, 2016 at 09:14:16AM -0700, Jeremy Huddleston Sequoia wrote:
>> No, the DYLD_INSERT_LIBRARIES approach is the right one here.
>> Interested users would need to disable SIP.
> 
> "Interested users" would be everybody who uses MacPorts. I'd vote
> against telling all our users to disable SIP. It's a useful
> security/safety feature and it even helps us because users can no longer
> mess up their /usr/bin.

No.  "Interested users" would be everybody who wants to use this fakeroot 
implementation instead of sudo.  Users would need to make the tradeoff decision 
for themselves as to whether they want SIP+sudo or !SIP+fakeroot.

> I don't see why the kernel, dyld, or whoever strips the flags could not
> just behave like running a copy of the binary at hand when it sees a
> DYLD variable, i.e. do the workaround we're doing manually at the
> moment.

Because that'e exactly what the system binary bit is intended to prevent.  The 
system binary bit on the executables is in place to ensure that binary is not 
interposed by third party code that can potentially degrade the integrity of 
the running system.

>> It would be nice if a mechanism were in place to determine trust of
>> certain libraries in DYLD_INSERT_LIBRARIES.
> 
> So you're suggesting DYLD_INSERT_LIBRARIES on SIP-protected binaries
> should only work if the inserted library is signed? How would that
> improve anything? Are you suggesting every open source project out there
> that uses library preloading now pays for a certificate and regularly
> builds and releases binaries for macOS? Frankly, I don't see that
> happening.

IMO, there should be a way to establish a trust model such that certain 
binaries could be inserted (maybe with a particular entitlement on the dylib).  
That isn't possible right now.  Please file radars to vote for this getting 
addressed in a future release.

OSS projects are free to do what they want for the benefit of their customers.  
They can sign their code with an ADC-provided cert, a cert from another CA, or 
not at all and just instruct users on how to sign the binary themselves.

>> Please file radars and point me to them, so I can make sure they get
>> routed to the right place (likely as dupes, but dupes are very useful
>> "votes" for bugs).
> 
> Those tickets have been filed when SIP was introduced and
> DYLD_INSERT_LIBRARIES stopped working.
> Evidently, it wasn't important
> enough to get fixed, so you'll forgive me if I have better things to do
> with my time.

All the radars that I am aware of are mainly focused around 
"DYLD_INSERT_LIBRARIES doesn't get passed through system binaries" not 
"DYLD_INSERT_LIBRARIES doesn't get honored by system binaries".  The latter is 
what this is about.




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

Re: Fakeroot destrooting [Was: Re: lldb ...]

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 05:22, Clemens Lang <c...@macports.org> wrote:
> 
> Hi,
> 
> On Fri, Sep 09, 2016 at 01:59:50PM -0700, Jeremy Huddleston Sequoia wrote:
>>> As an aside, I'd be in favour of setting up MacPorts such that
>>> ${prefix} is owned by a ${macports_operator} who's got admin rights
>>> (= myself) and reserve use of actual root privilege to those few
>>> ports that require setting up SETUID/GETUID executables or that need
>>> to create users or groups.
>> 
>> YES!  We should not be needing to do such things as root.  That is
>> 100% true, and I am in full support of moving away from that and only
>> using root for activate.  We should be able to use fakeroot
>> (https://wiki.debian.org/FakeRoot) for destdir.
> 
> Except that fakeroot uses library preloading, a technique that's more or
> less dead on modern OS X thanks to Apple's changes related to SIP:
> DYLD_INSERT_LIBRARIES is stripped for all binaries with the SIP bit set.
> Combine that with every binary in /usr/bin and /bin having the bit, and
> you'll end up the variable being removed on the first invocation of a
> shell (which is basically everywhere in the build systems of our ports).
> 
> It can still be done with utter hacks (copying the binary into a file
> without the SIP bit and executing it from there, which we do for trace
> mode), but I have neither seen any other library preloading utility that
> used to work on OS X implement these changes nor convinced any of their
> developers to do so.
> 
> Other approaches that would allow simulating permissions, such as Linux'
> user namespaces don't exist on OS X at all. I think it's pretty obvious
> that implementing new code that relies on library preloading is riding a
> dead horse on macOS.

No, the DYLD_INSERT_LIBRARIES approach is the right one here.  Interested users 
would need to disable SIP.  It would be nice if a mechanism were in place to 
determine trust of certain libraries in DYLD_INSERT_LIBRARIES.  Please file 
radars and point me to them, so I can make sure they get routed to the right 
place (likely as dupes, but dupes are very useful "votes" for bugs).

Thanks,
Jeremy



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

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 05:09, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-09-09 22:59, Jeremy Huddleston Sequoia wrote:
>> 
>>> On Sep 9, 2016, at 04:38, René J.V. Bertin <rjvber...@gmail.com> wrote:
>>> 
>>> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
>>> 
>>> 
>>>>> different than your case either.  Either way, the debugger and all
>>>>> its dependencies need to be signed by a valid certificate.
>>>> 
>>>> That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
>>>> it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
>>>> get it working.
>> 
>> It requires the ggdb executable and all libraries it links against to be 
>> signed.  The port is written such that it only links against Apple-provided 
>> executables, so that solves that dependency.
> 
> No?
> 
> $ otool -L /opt/local/bin/ggdb
> /opt/local/bin/ggdb:
>   /opt/local/lib/libintl.8.dylib (compatibility version 10.0.0, current 
> version 10.5.0)
>   /opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current 
> version 6.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)
>   /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current 
> version 8.1.0)
>   /opt/local/lib/libexpat.1.dylib (compatibility version 8.0.0, current 
> version 8.2.0)
> 
> 
> On OS X 10.10 Yosemite, signing only the ggdb binary was certainly
> enough. I cannot reproduce this on macOS 10.12 Sierra, so
> the requirements might have changed.

10.10 predates SIP and related hardening around ptrace().  That version is so 
far in my rearview that I forget the details there, sorry.  I'll have to dig 
into it, but it certainly seems wrong to me that a process could become 
privileged if it linked against unsigned libraries.

> Also on Sierra it looks like I can no longer give codesign a
> certificate, which is not known and trusted to the system.
> 
> Both of these facts would destroy my idea of signing with a self-signed
> certificate, but requiring the user to add trust on the certificate.
> 
> Rainer
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 10, 2016, at 02:15, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Friday September 09 2016 13:59:50 Jeremy Huddleston Sequoia wrote:
> 
>>> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
>>> owned by a ${macports_operator} who's got admin rights (= myself) and 
>>> reserve use of actual root privilege to those few ports that require 
>>> setting up SETUID/GETUID executables or that need to create users or groups.
>> 
>> YES!  We should not be needing to do such things as root.  That is 100% 
>> true, and I am in full support of moving away from that and only using root 
>> for activate.  We should be able to use fakeroot 
>> (https://wiki.debian.org/FakeRoot) for destdir.
> 
> Why would we even require root for activation, except for the few exceptions 
> that install items outside of ${prefix} or that install SETUID/GUID to 
> another user/group? 

Exactly, so we'll need root access at activation time for such things.

Yes, for most cases we would probably not need root access at activation time, 
but for those cases you just listed, we would.  We could do a pass over the bom 
to determine if root access is needed or not.  The UI for handling such a case 
is non-trivial.  Do we prompt once for the entire run of the process or 
escalate permissions for each port we encounter and then drop them again?  If 8 
ports are being installed and 4 require root, that's not a good user experience 
to prompt for password 4 times.

> It's already an implicit requirement that the MacPorts operator (the user who 
> installs it and ports) be an admin user, and once ${prefix} is created 
> there's no need for it and anything below it to require root access.
> 
> I've run MacPorts for years like that, and only moved away from it very 
> recently because I made an error (forgot a ${destroot}) that caused pollution 
> of my ${prefix}. Of course the protection I gained with that move is very 
> relative, and depends on the destroot step NOT being run as root.
> 
> Would fakeroot work on OS X, including on versions that predate SIP/rootless?

There's absolutely nothing preventing something like that from working 
technically.  All it's doing is interposing FS syscalls like stat(), chown(), 
chmod(), and storing that information as a shadow.  The limitation that I see 
is with executables that are restricted from using DYLD_INSERT_LIBRARIES for 
the interposition (ie: the same problem we have with darwintrace).  We would 
need to use our own versions of cp, mv, chmod, chown, stat, install, etc 
command line utilities instead of the system binaries.

> Funny btw, I trust Debian to have written a safe fakeroot implementation, but 
> if you read the wiki you get the impression it's a dangerous little hacking 
> tool, which could be misused easily e.g. to make any executable setuid root...

Such executables still need to be installed through real root access in order 
to become "really" setuid root.

>> It's quite a bit more complicated than that.  First off, these settings are 
>> on by default but can be configured through SIP flags, boot args, etc.  
>> There >are also many types of restrictions that have different effects.
> 
> Hah, TMI :)
> 
>> Because of the CS_HARD restriction, all libraries that are linked against 
>> require a valid code signature.
> 
> Out of curiosity, if an IDE were to use a proper lldb debugger implementation 
> that uses liblldb rather than an existing external driver (lldb-mi, python, 
> ...), will all of the IDE have to be signed or is that still a requirement 
> only for the debugserver utility?

The process doing the debugging (the one that is calling ptrace(2)) is the one 
that has these restrictions, ie: debugserver.

>> This is because you likely already launched the executable, so the old 
>> signature for that particular inode was already cached.  If you copied 
>> debugserver somewhere else and then copied it back, it would have addressed 
>> the problem for you.
> 
> Presumable, but that's the point, it didn't. I tried that manually, but 
> shouldn't reinstalling via MacPorts have taken care of that too? Because that 
> does
> - delete the previous copy
> - install a new, unsigned copy
> - sign the new copy
> 
> I understand that the certificate catching is coupled to the file's inode 
> (whatever that is under HFS+), and the new copy indeed had a new inode. And 
> yet another inode after signing it.

If you can reproduce this, please let me know and file a radar with details and 
let me know the number, so I can followup internally on it.  I haven't seen 
such cases.  The only issue I'm aware of is with overwriting an existing file 
(eg: using cp instead of mv).

>>> I'm con

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 9, 2016, at 04:38, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Friday September 09 2016 12:10:05 Rainer Müller wrote:
> 
> 
>>> different than your case either.  Either way, the debugger and all
>>> its dependencies need to be signed by a valid certificate.
>> 
>> That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
>> it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
>> get it working.

It requires the ggdb executable and all libraries it links against to be 
signed.  The port is written such that it only links against Apple-provided 
executables, so that solves that dependency.

> And lldb requires only the debugserver executable to be signed.

Again, because debugserver uses entitlements, all its dependencies need to be 
signed as well.

$ otool -L  /opt/local/libexec/llvm-devel/bin/debugserver
/opt/local/libexec/llvm-devel/bin/debugserver:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
307.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1238.0.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1348.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 1349.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 
228.0.0)

As you can see, all of its dependencies are system libraries, so they're all 
valid.

>> Did this change with El Capitan or Sierra?
> 
> I'm guessing that would somehow be evident from the lldb-3.9 CMake files and 
> build instructions...
>> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
>> `codesign --keychain`. This keychain does not have to be listed in
>> `security list-keychains`.
> 
> Does `man codesign` still mention the search list  requirement in the 
> documentation for --keychain?

Yes, that is still a requirement.

> 
> On Friday September 09 2016 02:26:19 Jeremy Huddleston Sequoia wrote:
> 
>>>> I'd hate that because I've set things up with macports_user=myself and
>>>> everything under workpath owned by myself, to avoid constant need for
>>>> UID changing. I kind of doubt I'm the only one maintaining lots of
>>>> ports who does that.> > 
>>> I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as
>>> root in order to setup desired permissions in the destroot?  That's a
>>> good place to handle the resigning.
> 
> I do a lot of development on projects for which I also maintain ports; in 
> fact, development that's tightly coupled to the fact the code is available 
> via a port. Doing all that work "as myself" only to transfer it to the port 
> afterwards is a hassle and waste of time as far as I'm concerned. It's not so 
> much that I want to avoid having to put sudo in front of each and every port 
> command (I'd write a `sport` wrapper/alias). I don't want to grow the habit 
> of putting sudo in front of everything I'm doing around those ports' build 
> directories and that I'd also be doing in development that's got nothing to 
> do with MacPorts. I also want to be able to open a port's source tree in an 
> IDE, run incremental builds in subdirs for ${build.dir}, etc. So I've set my 
> macportsuser to my own username, and most of the time I run everything up to 
> and including `port destroot` as myself (and set up symlinks to `port work` 
> for easy access). Typically, for -devel ports that use fetch.git I also 
> replace ${worksrcdir} with a symlink to the working copy under my own home 
> directory (that way I also won't lose local changes if I ever forget to use 
> -o or -k).
> Many of the contributions I've made to KDE over the past few years were 
> developed with this approach. I've used the standard approach (macportsuser = 
> macports) on a VM Bradley gave me access to, and it's definitely a lot less 
> productive.
> Evidently this is not the kind of advanced use we need to consider for 
> regular users, but port developers/maintainers are users too, and I think we 
> *could* consider their needs too.
> 
> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is 
> owned by a ${macports_operator} who's got admin rights (= myself) and reserve 
> use of actual root privilege to those few ports that require setting up 
> SETUID/GETUID executables or that need to create users or groups.

YES!  We should not be needing to do such things as root.  That is 100% true, 
and I am

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 9, 2016, at 01:17, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote:
> 
>> That's not really necessary.  All that is relevant is that the macports user 
>> has read access to the file.
> 
> If memory serves me well I had to set read access on ~macports, 
> ~macports/Library and ~macports/LibraryKeychains too in order to be able to 
> read the test keychain in there as myself.

> The fact that codesign only accepts keychain file arguments that are also in 
> the user's keychain search list may have something to do with that. Anyway, 
> yes, a user specification may not be really necessary, but giving 
> ${macports_user} read access to your own keychain directory (for instance) 
> doesn't sound like such a good idea.

You would have needed to set executable access on those directories, not read 
access.  And yes, the file would need to be in the user's keychain search list.

Also, yes, giving ${macports_user} read access to your user's login keychain is 
not a good idea.  It should be locked down to just the users that need it and 
still guarded by a passphrase.

>>> Technically it doesn't really matter if it's implemented in "base" or in a 
>>> PortGroup, right?
>> 
>> In order for *every* port to benefit, it needs to be in base.
> I don't see this argument. Are you considering codesigning each and every 
> binary automatically, without any need for requesting that from the Portfile? 
> What's the point in that?

Yes.  The fact that we aren't doing that for the binary packages that we ship 
is quite embarrassing.  We should solve this problem more generally such that 
we can ship properly signed binaries for every port.  Users installing the 
binary packages that we ship right now are running unsigned code, and that is 
quite frightening.  There's nothing guaranteeing that the package hasn't been 
MITMd.  There's no way for us to revoke a certificate if it turns out that our 
build servers had been compromised, etc.

> OTOH, if portfile devs have to indicate which binary is to be signed they can 
> just as well add a PortGroup to be able to access that functionality. 

Yeah, it would be much better if we just signed every Mach-O in the destroot of 
every port.

>> If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign 
>> everything" case.
> 
> Ah, the problem with inline replying :) I don't think anyone of us has even 
> thought of a "let's sign everything case". There's clearly never been a need 
> for that, and even if at some point it's going to be a necessity there will 
> 1) be enough time to have integrated the then mature feature into "base" and 
> 2) it will become a forced necessicity. 
> 
> As a side-thought: it shouldn't be particularly difficult to implement a 
> "base" feature which defines a set of PortGroups to be included by default by 
> every port, if such a thing doesn't already exist. I know there's been talk 
> about making at least parts of "base" updateable as a port; this could be an 
> easy alternative.

Yeah, I could see this being a PortGroup that is opt-in now and then becomes 
always-on or opt-out in a future version of base.

>> post_destroot{} would resign it as specified in the macports.conf
> 
> I'd hate that because I've set things up with macports_user=myself and 
> everything under workpath owned by myself, to avoid constant need for UID 
> changing. I kind of doubt I'm the only one maintaining lots of ports who does 
> that.

I don't understand.  Can you elaborate?  Doesn't post_destroot{} run as root in 
order to setup desired permissions in the destroot?  That's a good place to 
handle the resigning.

>>> There are 2 details to work out:
>>> - HOME is set to ${prefix}/var/macports/home (~macports)
>> 
>> HOME is irrelevant.
> 
> No, it isn't. It's what the Security framework uses to find keychains. Try it 
> out for yourself and then correct me if I'm wrong ;)
> I was very surprised to discover that, but then I realised that this is why 
> `sudo codesign ...` still uses the calling user's keychains.  Of course I 
> don't know if there have been changes in this aspect in 10.10 or later, but 
> it's true for 10.9 .

That's because you're using sudo, which doesn't change the bootstrap session.  
You likely want to do something like:

sudo launchctl asuser `id -u joebob` sudo -u joebob codesign ...

which requires launchd2 (OS X 10.10+)

>> No, the user doing the signing in post_destroot{} would be root.
> 
> Codesign will still need to find the keychain, be able to read it, and the 
> file will need to be in the searchlist of the user in who's homedir the file 
> lives.

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 8, 2016, at 15:13, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Thursday September 08 2016 13:09:33 Jeremy Huddleston Sequoia wrote:
>>> codesign.files   ${prefix}/bin/binary1 developer \
>>>${prefix}/bin/binary2 firewall
>>> codesign.identifier  org.macports.${name}
>> 
>> 
>> I don't like this approach.
>> 
>> We should solve this type of problem at the base layer.  Everything should 
>> be codesigned as configured in macports.conf (using a specified identity in 
>> a specified keychain, or defaulting to adhoc).
> 
> I think you'll also need to specify the user who owns the keychain, let's 
> call him/her the macports_operator.

That's not really necessary.  All that is relevant is that the macports user 
has read access to the file.

> Technically it doesn't really matter if it's implemented in "base" or in a 
> PortGroup, right?

In order for *every* port to benefit, it needs to be in base.

> I like the idea of a PortGroup because it allows to deploy the new feature 
> without waiting for a new base release, and also makes pushing updates so 
> much easier.

If it's in a PortGroup, it is opt-in and doesn't solve the "let's sign 
everything" case.

> Similarly, it shouldn't really make a difference whether the information is 
> read from macports.conf or somewhere else - but I suppose a PortGroup can 
> read from that file too.
> 
>> The port itself should build() using adhoc signing, and base's post-build 
>> should resign everything (preserving all attributes) using the settings 
>> specified in macports.conf.
> 
> build{} and post-build{} are executed as ${macports_user}, right? That should 
> be compatible with my observation that codesign will change ownership of the 
> target file (unless it's executed as root).

Ah, right, sorry.  Mixing up build system paradigms.

build{} would sign it adhoc.
post_destroot{} would resign it as specified in the macports.conf

> There are 2 details to work out:
> - HOME is set to ${prefix}/var/macports/home (~macports)

HOME is irrelevant.

> , not to ~${macports_user} i.e. not the home directory of the user specified 
> via the macports_user variable. It will need to point to the home directory 
> of the user who owns the keychain (${macports_operator})

No, it doesn't.

> - evidently ${macports_user} will need to be able to read the required 
> keychain, possibly every directory in the path to that keychain.

No, the user doing the signing in post_destroot{} would be root.

> The first detail is trivial, the 2nd a bit less. I get around it because the 
> post-activate{} step executes as root, so read access is automatic. The only 
> easy way to solve it for the macports_user is to let the keychain be owned by 
> that user.

If you want the macports user to do the signing, that's fine too.  It doesn't 
need to own the keychain, just have read access to it.  It could be group read 
access or other read access.

> I've tried to set things up that way by preparing a keychain with a signing 
> certificate and its 2 keys. Once that's done you can automate the process of 
> installing that keychain in ~macports/Library/Keychains and adding it to the 
> search list via the security command. However, codesign refused to find that 
> identity, when called by macports user. There's a transcript of my attempts 
> in an earlier of my messages in this thread.
> The base layer could of course do a dedicated post-build that is executed as 
> root. I presume...

Yes.

>> This approach allows us to specify an identity on the builders that is an 
>> apple developer signing identity such that all binaries coming out of 
>> MacPorts have a chain of trust back to Apple.
> 
> Is that something we want

I'd say most definitely.

> (except for things like kexts in ports like the one I once proposed for ZFS) 
> and is that something that Apple would accept

I don't see why not.  I have such a key for XQuartz.

> ... without requiring a vote in when updates can be published, what can be 
> accepted etc?
> I also don't really see why it would be bad to allow ports to let users sign 
> or resign binaries with an identity of their own.

That should be controlled at the base layer.  We shouldn't have a mixmatch of 
signing identities for different files as that will break library validation 
for any ports that might need LV.

> If you allow that for building from source, why not allow it for prebuilt 
> packages too? Can you give an example what's so incredibly dangerous about 
> resigning code that was signed on the buildbots?

You could certainly resign it after first validating the original signature.

Signing unsigned code without first validating it is a clear security 

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 5, 2016, at 03:49, Rainer Müller  wrote:
> 
> On 2016-09-05 00:57, René J.V. Bertin wrote:
>> In a first draft the command accepted a list of binaries to sign, and read 
>> the identify from a configuration file. I suppose that corresponds to what 
>> you mean with a declarative syntax?
>> I then went to a simpler, single-binary interface because I realised that it 
>> would sometimes be necessary to specify a different identity. It shouldn't 
>> be hard to change that into
>> 
>> ```
>> codesign identity binary1 [binary2 [...]]
>> ```
> 
> In a Portfile you would not be interested in the name of the identity,
> the but trust policy it grants (firewall bypass, task_for_pid, etc.).
> 
> Otherwise you would expect users to set up different identities and
> assign the correct trust policy, which is just not feasible.
> 
> I am thinking of a list of files and policies such as:
> 
> codesign.files   ${prefix}/bin/binary1 developer \
> ${prefix}/bin/binary2 firewall
> codesign.identifier  org.macports.${name}


I don't like this approach.

We should solve this type of problem at the base layer.  Everything should be 
codesigned as configured in macports.conf (using a specified identity in a 
specified keychain, or defaulting to adhoc).

The port itself should build() using adhoc signing, and base's post-build 
should resign everything (preserving all attributes) using the settings 
specified in macports.conf.

This approach allows us to specify an identity on the builders that is an apple 
developer signing identity such that all binaries coming out of MacPorts have a 
chain of trust back to Apple.



> Of course this identifier would usually just be the default value, so it
> does not need to be specified explicitly.
> 
 Alternatively, MacPorts could create the certificate and then export it in 
 such a way that users only have to import it. There might be other 
 benefits to that (signing kexts provided by ports ...).
>>> 
>>> I don't think I understand your idea... Why would we need to export it
>>> for users to import it again? The generated identity is meant only to be
>>> used by MacPorts and nothing else.
>> 
>> I don't know how easy it is to automate the certificate creation, if at all 
>> possible. Creating one that users only have to import removes a step or two 
>> that could go wrong (if it cannot be automated), importing may be easier to 
>> automate, and there may be an advantage if everyone signs using the same 
>> certificate.
> 
> If users need a identity, they can generate one with Keychain Access.
> The identity generated by MacPorts is only meant to be used by MacPorts.
> 
>>> This approach cannot be used to sign kext, as that requires a
>>> certificate signed by Apple.
>> 
>> I was thinking about a hypothetical possibility to redistribute such a 
>> signed certificate. I know, probably extremely unlikely, but one can dream :)
> 
> No way to do that. As we are code-signing on the local machine, we would
> need to distribute the private key. Everyone would be allowed to sign
> their kext with this, which defeats the whole purpose of signed kexts.
> 
>>> This is not fully automatic and requires user interaction. This makes it
>>> fragile as it requires users to follow manual steps very closely to
>>> generate a certificate and set the required trust. That needs to be
>>> automated.
>> 
>> I wouldn't be completely surprised if it turns out to be impossible to 
>> automated the whole process; Apple could well have seen to that as a 
>> protection against unexpected certificates popping up, with unlimited trust 
>> etc. It's been a while since I used the API, and I only used the parts 
>> related to traditional credentials, and keychain creation/management.
> 
> My intention here is to describe a way how the code-signing can be
> automated. We do not gain much by providing a solution that still
> requires manual interaction by the user. Generating a certificate and
> signing the binary should be completely transparent to the user.

That obfuscation is very bad for security purposes.  We should not hide this 
detail from users.  It needs to be very explicit.

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

Re: lldb ...

[Jeremy Huddleston Sequoia]

> On Sep 2, 2016, at 05:19, Rainer Müller  wrote:
> 
> On 2016-08-31 23:25, Lawrence Velázquez wrote:
>>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin  wrote:
>>> 
>>> I noticed that Apple don't ship an lldb-mi executable (at least they don't 
>>> for OS X 10.9). 
>> 
>> Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does not. 
>> Someone else is welcome to bisect on that.
>> 
>>> Has anyone looked at building an lldb port before?
>> 
>>> The real problem is going to be with the code-signing. This is done 
>>> automagically by lldb's Xcode projects so it's not entirely clear which 
>>> files have to be signed ... nor if an "ad-hoc" signing identify ("-") will 
>>> lead to a usable debugger.
>> 
>> You opened a ticket about this a while ago. One of Eric's comments hints at 
>> what a pain it might be to get it working with code signing.
>> 
>> https://trac.macports.org/ticket/45251
> 
> That would equivalent to what gdb recommends for codesigning.
> 
> https://sourceware.org/gdb/wiki/BuildingOnDarwin#Giving_gdb_permission_to_control_other_processes
> 
> 
> In my opinion, the actual implementation of codesigning should be in base:
> 
> 1) Create a self-signed certificate/identity for code-signing
> 2) Import certificate/identity into keychain
> 3) Add it to trust store (`security add-trusted-cert ...`)
> 4) In activate phase, if requested in Portfile, codesign the binary

No, that is incredibly dangerous.  code should not be signed during activate, 
it should be signed at build time.  The packages that a user downloads from 
MacPorts should not be altered at activation time.  Ideally, the packages they 
download should be codesigned by a MacPorts developer codesigning certificate.


> Unsolved problems:
> For step 1), how to to automate certificate creation.

Don't.  This should be a manual process.  The user should create a keychain and 
specify the path to the keychain in macports.conf.  If that's not set, we 
should just adhoc sign.

> We cannot click
> that in Keychain Assistent. That means finding a way to do it
> programmatically with other tools. As far as I see, this is just a
> standard x509 certificate which could be done with openssl, but which
> extensions need to be enabled?
> 
> For step 4), how to give user 'macports' access to the System.keychain
> without entering a password?

Don't use System.keychain.  A separate keychain should be used just for the 
codesigning.  It should be password protected, and the user should be prompted 
for the password to unlock the keychain as part of 'port build'.

> As an alternative, how to import the
> identity (both private/public key) into a different keychain with
> unlocked access?

It should be unlocked by the user providing the password to unlock the keychain.

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



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

Re: [150874] trunk/dports/lang/python32

[Jeremy Huddleston Sequoia]

FWIW, I prefer 'git format-patch' output for patches.  If I actually had to 
rename patches per file, maintaining llvm would be a nightmare. =/


> On Aug 4, 2016, at 05:35, Clemens Lang  wrote:
> 
> FWIW, I agree with Lawrence here. I think we should improve our patch
> naming, especially since it doesn't really matter *where* a patch comes
> from, either. Why do we really need to know whether a patch-*.diff file
> comes from MacPorts when compared to a different patch? We should be
> judging patches by their content, not their origin.
> 
> What I've seen in other systems and would also recommend as a guideline
> for patches in MacPorts:
> - Write a commit message into the patch file. Patch headers can include
>   arbitrary text, so type a message explaining what the patch does and
>   why it is needed. Add references to any upstream tickets (I've
>   started doing this for my ports according to OpenEmbedded's
>   Upstream-Status tag [1]).
> - Use the summary line of the commit message as patch name, like git
>   format-patch does it.
> 
> I have in the past also ignored our patch naming guidelines when I
> thought it made sense; for example, I generally backport patches from
> upstream git repositories using .patch, because that's what
> GitHub generates.
> 
> [1] 
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations
> 
> -- 
> Clemens
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: [149320] trunk/dports/lang/qore-mysql-module

[Jeremy Huddleston Sequoia]

Failed to parse file lang/qore-mysql-module/Portfile: Variant name mariadb-10.0 
contains invalid characters

> On Jun 10, 2016, at 23:15, davidnich...@macports.org wrote:
> 
> Revision
> 149320
> Author
> davidnich...@macports.org
> Date
> 2016-06-10 23:15:48 -0700 (Fri, 10 Jun 2016)
> Log Message
> 
> qore-mysql-module: updated to v2.0.2 and added support for newer mysql and 
> mariadb ports
> Modified Paths
> 
>   • trunk/dports/lang/qore-mysql-module/Portfile
> Removed Paths
> 
>   • trunk/dports/lang/qore-mysql-module/files/
> Diff
> 
> Modified: trunk/dports/lang/qore-mysql-module/Portfile (149319 => 149320)
> 
> --- trunk/dports/lang/qore-mysql-module/Portfile  2016-06-11 06:01:57 UTC 
> (rev 149319)
> +++ trunk/dports/lang/qore-mysql-module/Portfile  2016-06-11 06:15:48 UTC 
> (rev 149320)
> 
> @@ -4,8 +4,7 @@
> 
>  PortSystem  1.0
> 
>  
> 
>  nameqore-mysql-module
> 
> -version 2.0.1
> -revision1
> 
> +version 2.0.2
> 
>  categories  lang
> 
>  license LGPL-2.1
> 
>  maintainers davidnichols
> 
> @@ -14,32 +13,39 @@
> 
>  use_bzip2   yes
> 
>  homepagehttp://qore.org
>  platforms   darwin
> 
> -master_sitessourceforge:qore
> 
> +master_sites
> https://github.com/qorelanguage/module-mysql/releases/download/v${version}
>  
> 
> -checksums   md5 28e9a89f7e543f46ddb6bb3dcc838c2c \
> -sha1 4c219ce39d2fc0c025e1dc46fe7a6a8bff5f0020 \
> -rmd160 172c9f9ebee4b638e470e096e1537d6decff3af3
> 
> +checksums   md5 29800c39a41c90824ef530c551ae4a7e \
> +sha1 5abf5c0ddea7719bee45dae0cbea76d8afe13dbe \
> +rmd160 c3459e518186bfc4176cbb8b06adf5d68bcd4943
> 
>  
> 
> -patchfiles  patch-configure
> 
> +variant mariadb conflicts mariadb-10.0 mariadb-10.1 mysql51 mysql55 mysql56 
> mysql57 percona description {use mariadb} {}
> +variant mariadb-10.0 conflicts mariadb mariadb-10.1 mysql51 mysql55 mysql56 
> mysql57 percona description {use mariadb-10.0} {}
> +variant mariadb-10.1 conflicts mariadb mariadb-10.0 mysql51 mysql55 mysql56 
> mysql57 percona description {use mariadb-10.1} {}
> +variant mysql51 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql55 mysql56 
> mysql57 percona description {use mysql 5.1} {}
> +variant mysql55 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql56 
> mysql57 percona description {use mysql 5.5} {}
> +variant mysql56 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql55 
> mysql57 percona description {use mysql 5.6} {}
> +variant mysql57 conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql55 
> mysql56 percona description {use mysql 5.7} {}
> +variant percona conflicts mariadb mariadb-10.0 mariadb-10.1 mysql51 mysql55 
> mysql56 mysql57 description {use percona} {}
> 
>  
> 
> -variant mariadb conflicts mysql51 mysql55 mysql56 percona description {use 
> mariadb} {}
> -variant mysql51 conflicts mariadb mysql55 mysql56 percona description {use 
> mysql 5.1} {}
> -variant mysql55 conflicts mariadb mysql51 mysql56 percona description {use 
> mysql 5.5} {}
> -variant mysql56 conflicts mariadb mysql51 mysql55 percona description {use 
> mysql 5.6} {}
> -variant percona conflicts mariadb mysql51 mysql55 mysql56 description {use 
> percona} {}
> -
> -if {![variant_isset mariadb] && ![variant_isset mysql51] && ![variant_isset 
> mysql55] && ![variant_isset mysql56] && ![variant_isset percona]} {
> 
> +if {![variant_isset mariadb] && ![variant_isset mariadb-10.0] && 
> ![variant_isset mariadb-10.1] && ![variant_isset mysql51] && ![variant_isset 
> mysql55] && ![variant_isset mysql56] && ![variant_isset mysql57] && 
> ![variant_isset percona]} {
> 
>  default_variants +mariadb
> 
>  }
> 
>  
> 
>  if {[variant_isset mariadb]} {
> 
>  set mysql_port "mariadb"
> 
> +} elseif {[variant_isset mariadb-10.0]} {
> +set mysql_port "mariadb-10.0"
> +} elseif {[variant_isset mariadb-10.1]} {
> +set mysql_port "mariadb-10.1"
> 
>  } elseif {[variant_isset mysql51]} {
> 
>  set mysql_port "mysql51"
> 
>  } elseif {[variant_isset mysql55]} {
> 
>  set mysql_port "mysql55"
> 
>  } elseif {[variant_isset mysql56]} {
> 
>  set mysql_port "mysql56"
> 
> +} elseif {[variant_isset mysql57]} {
> +set mysql_port "mysql57"
> 
>  } elseif {[variant_isset percona]} {
> 
>  set mysql_port "percona"
> 
>  }
> 
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes



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

Re: [149312] trunk/dports/python/py-ngl/Portfile

[Jeremy Huddleston Sequoia]

Adding port python/py-ngl
Failed to parse file python/py-ngl/Portfile with subport 'py26-ngl': can't read 
"PYTHONPATH": no such variable
Failed to parse file python/py-ngl/Portfile with subport 'py27-ngl': can't read 
"PYTHONPATH": no such variable


> On Jun 10, 2016, at 13:51, dstru...@macports.org wrote:
> 
> Revision
> 149312
> Author
> dstru...@macports.org
> Date
> 2016-06-10 13:51:48 -0700 (Fri, 10 Jun 2016)
> Log Message
> 
> py-ngl: Add test phase.
> Modified Paths
> 
>   • trunk/dports/python/py-ngl/Portfile
> Diff
> 
> Modified: trunk/dports/python/py-ngl/Portfile (149311 => 149312)
> 
> --- trunk/dports/python/py-ngl/Portfile   2016-06-10 20:50:42 UTC (rev 
> 149311)
> +++ trunk/dports/python/py-ngl/Portfile   2016-06-10 20:51:48 UTC (rev 
> 149312)
> 
> @@ -66,6 +66,13 @@
> 
>  }
> 
>  
> 
>  livecheck.type   none
> 
> +
> +test.run yes
> +# FIXME: how to set macosx, 10.10, and x86_64 in general?
> +test.env-append
> PYTHONPATH=${worksrcpath}/build/lib.macosx-10.10-x86_64-${python.version}/PyNGL:${PYTHONPATH}
> +test {
> +system "${python.bin} 
> ${worksrcpath}/build/scripts-${python.version}/pynglex -w x11 ngl01p"
> +}
> 
>  } else {
> 
>  livecheck.type   regex
> 
>  livecheck.urlhttp://www.pyngl.ucar.edu/Download/
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes



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

Re: [MacPorts] #51287: Inkscape crashes on startup if enchant is installed with +applespell

[Jeremy Huddleston Sequoia]

> On May 12, 2016, at 12:57, David Evans  wrote:
> 
> On 5/12/16 2:53 AM, MacPorts wrote:
>> #51287: Inkscape crashes on startup if enchant is installed with +applespell
>> ---+--
>>  Reporter:  jo.vanoost@…  |  Owner:  devans@…
>>  Type:  defect| Status:  closed
>>  Priority:  Normal|  Milestone:
>> Component:  ports |Version:
>> Resolution:  fixed |   Keywords:
>>  Port:  inkscape enchant  |
>> ---+--
>> 
>> Comment (by raimue@…):
>> 
>> Replying to [comment:9 devans@…]:
>>> I've updated the dependencies in inkscape in r148331, requiring enchant
>> +aspell -applespell.  This fixes the spell checking issue reported here
>> although enchant has to be manually installed with these variants for the
>> build to succeed.  Will do the same for inkscape-devel shortly.
>> 
>> This forces everyone with inkscape installed to manually switch the
>> enchant variants before their upgrade can continue, as the default
>> installation is still enchant +applespell. I got multiple reports
>> (personally and on IRC) from people that were unsure what to do. The error
>> message is a bit confusing and does not tell users how they are supposed
>> to proceed:
>> 
>> {{{
>> --->  Fetching archive for inkscape
>> Error: Failed to archivefetch inkscape: enchant must be installed with
>> +aspell and without +applespell.
>> }}}
>> 
>> To document it somewhere, the command to switch variants before attempting
>> an upgrade of inkscape would be:
>> {{{
>> $ sudo port upgrade --enforce-variants enchant +aspell -applespell
>> }}}
>> 
> 
> Thanks for mentioning this.  I also had misgivings about the error message 
> which emanates from the activate variants
> port group.  I've also seen a number of questions from people who were unsure 
> what to do and not just for inkscape.
> I don't have the time right now to do anything about this but perhaps someone 
> else can look at the port group and see if
> this message can be made clearer (e.g. directly indicate the appropriate 
> command to execute in all cases).
> 
> I still think it would be better to reinstate +aspell as the default variant 
> as it previously was and leave +applespell
> as an option for those who favor it.  This would avoid breaking the default 
> build on a popular application.

If +applespell is really broken in enchant on Mountain Lion, then this change 
should be made on the enchant Portfile and just on Mountain Lion.

--Jeremy



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

Re: *-devel ports for llvm and gcc

[Jeremy Huddleston Sequoia]

> On May 5, 2016, at 11:22, Ryan Schmidt  wrote:
> 
> 
> On May 4, 2016, at 10:35 AM, Bradley Giesbrecht  wrote:
>> 
>> On May 4, 2016, at 7:47 AM, Ryan Schmidt  wrote:
>>> 
>>> On May 4, 2016, at 9:38 AM, Rainer Müller  wrote:
>>> 
 Users should easily see which port provides a stable version and which
 tracks a pre-release.
>>> 
>>> Maybe there's another way we can indicate whether a port is stable or not.
>> 
>> categories lang unstable
> 
> That sounds reasonable. I think I like that.

Sure.  I'll do that for the next llvm version.



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

Re: [148371] trunk/dports/audio/taglib/Portfile

[Jeremy Huddleston Sequoia]

This change broke every port that depends on taglib because the project no 
longer installs /opt/local/lib/libtag.1.dylib.

Please make sure you test changes rather than trusting upstream and doing 
version bumps blind.

Thanks,
Jeremy

> On May 5, 2016, at 12:46, m...@macports.org wrote:
> 
> Revision
> 148371
> Author
> m...@macports.org
> Date
> 2016-05-05 12:46:15 -0700 (Thu, 05 May 2016)
> Log Message
> 
> taglib: bump to 1.11.
> Modified Paths
> 
>   • trunk/dports/audio/taglib/Portfile
> Diff
> 
> Modified: trunk/dports/audio/taglib/Portfile (148370 => 148371)
> 
> --- trunk/dports/audio/taglib/Portfile2016-05-05 19:34:18 UTC (rev 
> 148370)
> +++ trunk/dports/audio/taglib/Portfile2016-05-05 19:46:15 UTC (rev 
> 148371)
> 
> @@ -5,7 +5,7 @@
> 
> PortGroup  cmake  1.0
> 
> 
> 
> name taglib
> 
> -version  1.10
> 
> +version  1.11
> 
> categories   audio
> 
> license  {LGPL-2 MPL-1.1}
> 
> maintainers  nomaintainer
> 
> @@ -18,8 +18,8 @@
> 
> homepage http://taglib.github.io/
> platformsdarwin
> 
> master_sites http://taglib.github.io/releases/
> -checksumsrmd160  a02682defc8f6a611e28e5e8db6dd72310a18230 \
> - sha256  
> 24c32d50042cb0ddf162eb263f8ac75c5a158e12bf32ed534c1d5c71ee369baa
> 
> +checksumsrmd160  1f900807c5f0998fbc7f7c4005d00fc42e0bce83 \
> + sha256  
> ed4cabb3d970ff9a30b2620071c2b054c4347f44fc63546dbe06f97980ece288
> 
> 
> 
> depends_lib-append  port:zlib
> 
> 
> 
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes



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

Issues with variants in current base trunk

[Jeremy Huddleston Sequoia]

I'm on current trunk (r146932), and I'm running into an issue with variants 
during an upgrade.

$ port list outdated
Warning: The 'list' action only shows the currently available version of each 
port. To see installed versions, use the 'installed' action.
wine-devel @1.9.6  x11/wine-devel

$ sudo port -v -s upgrade wine-devel
Error: libepoxy: Variant python27 conflicts with python34
Error: Unable to open port: Error evaluating variants
Error: Follow http://guide.macports.org/#project.tickets to report a bug.

$ port installed libepoxy
The following ports are currently installed:
 libepoxy @1.3.1_1+python34+universal (active)

$ grep python27 /opt/local/etc/macports/variants.conf
+python27

Firstly, I'm not sure how the libepoxy port was installed with the +python34 
variant in the first place since variants.conf had +python27 since before I 
installed the first port:

$ ls -l /opt/local/var/macports/software/libepoxy
total 508
-rw-r--r-- 1 root admin 516493 Mar 19 17:58 
libepoxy-1.3.1_1+python34+universal.darwin_13.i386-x86_64.tbz2

$ ls -l /opt/local/etc/macports/variants.conf
-rw-r--r-- 1 root admin 1203 Mar 18 23:54 /opt/local/etc/macports/variants.conf

And given the current state, an upgrade action should honor the installed 
variants.  Instead, it seems to be unioning them with variants.conf.

I suspect that maybe there is an inverted logic somewhere that caused my 
variants.conf to be honored during the upgrade but not the initial install but 
haven't dug deeper into it yet.

--Jeremy



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

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Jeremy Huddleston Sequoia]

> On Mar 11, 2016, at 02:14, Mojca Miklavec  wrote:
> 
> Hi,
> 
> A few more questions:
> 
> (1) If I want to target 10.5 from 10.6 I probably need libmacho and
> libunwind as well? What about these lines from libcxxabi? Are they
> most likely needed or not?
> 
>pre-build {
>system "nm -g ${prefix}/lib/libmacho.a 2> /dev/null | grep
> ' \[DST\] ' | awk '{print \$3}' >
> ${worksrcpath}/unexported_symbols_macho"
>system "nm -g ${prefix}/lib/libunwind.a 2> /dev/null |
> grep ' \[DST\] ' | awk '{print \$3}' | grep -v '^__Unwind' >
> ${worksrcpath}/unexported_symbols_unwind"
>system "cat ${worksrcpath}/unexported_symbols_macho
> ${worksrcpath}/unexported_symbols_unwind >
> ${worksrcpath}/unexported_symbols"
>}

That just ensures that the build libc++abi.dylib doesn't re-export libunwind 
and libmacho.  Yes, you want to include those lines.

> 
>build.env-append \
>EXTRA_LDFLAGS="${prefix}/lib/libmacho.a
> ${prefix}/lib/libunwind.a -unexported_symbols_list
> ${worksrcpath}/unexported_symbols"
> 
> 
> (2) Installing libunwind +universal (with clang 3.4) fails with
> "clang: error: unknown argument: '-fno-integrated-as'". If I remove
> that flag from the Portfile it fails with
> 
> ld: absolute addressing (perhaps -mdynamic-no-pic) used in
> _unwind_phase2 from ./UnwindLevel1.o not allowed in slidable image.
> Use '-read_only_relocs suppress' to enable text relocs
> 
> and if I try to compile it with clang 3.7 it start installing gdbm
> (most likely it tries to build clang 3.7 + universal) and fails.
> 
> If I don't need libunwind on 10.6 (for 10.5), then I'll skip it. If I
> do, I need to find a workaround.
> 
> Thank you,
>Mojca



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

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Jeremy Huddleston Sequoia]

> On Mar 11, 2016, at 01:50, Mojca Miklavec <mo...@macports.org> wrote:
> 
> On 11 March 2016 at 09:35, Jeremy Huddleston Sequoia wrote:
>>> On Mar 10, 2016, at 17:20, Mojca Miklavec wrote:
>>> On 10 March 2016 at 21:26, Ryan Schmidt wrote:
>>>>> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> While following
>>>>> https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
>>>>> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
>>>>> might have an even better support for PPC than 3.6).
>>>>> 
>>>>> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
>>>>> so I wasn't able to install libcxx. I get:
>>>>> 
>>>>>> clang++-mp-3.7 a.cc -arch ppc
>>>>> ld: unknown/unsupported architecture name for: -arch ppc
>>>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>>>> invocation)
>> 
>> The linker you have installed doesn't support ppc.  You need to install ld64 
>> with the +ld64_127 variant to get the last version of the linker that 
>> supported ppc.
> 
> Oh, thank you. That explains a lot.
> 
> I now did
>   sudo port -v -s install ld64 +ld64_127 +universal
> and clang 3.7 indeed no longer complains about unsupported architecture.
> 
> It is still complaining about:
> 
> ld: warning: ignoring file
> /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a,
> missing required architecture ppc in file

I suspect that is because you had the wrong linker active when you built 
clang-3.7.  The architectures in that library are determined at build time 
based on the capabilities of the linker.  Sorry, but it looks like you may need 
to force rebuild clang-3.7.

> but it generates the binary as expected.
> 
> Now I'm stuck at
> 
> ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
> Needed to perform lazy binding to function _abort for architecture ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)

dyld_stub_binder only exists for i386 and x86_64 on OSX.  It was added to 
libSystem in SnowLeopard.

Try forcing a 10.5 deployment target by adding -mmacosx-version-min=10.5 to 
work around that, and file a bug report about this at http://www.llvm.org/bugs 
(and let me know the number).


> from compiling libcxxabi:
> 
> /opt/local/bin/clang-mp-3.7 -I/opt/mp/10.5/include abort_message.o
> cxa_aux_runtime.o cxa_default_handlers.o cxa_demangle.o
> cxa_exception.o cxa_exception_storage.o cxa_guard.o cxa_handlers.o
> cxa_new_delete.o cxa_personality.o cxa_thread_atexit.o
> cxa_unexpected.o cxa_vector.o cxa_virtual.o exception.o
> private_typeinfo.o stdexcept.o typeinfo.o -arch ppc -arch i386 -arch
> x86_64 -o libc++abi.dylib -dynamiclib -nodefaultlibs -current_version
> 3.7.0 -compatibility_version 1 -install_name /usr/lib/libc++abi.dylib
> -lSystem -std=c++11 -stdlib=libc++ -fstrict-aliasing
> -Wstrict-aliasing=2 -Wsign-conversion -Wshadow -Wconversion
> -Wunused-variable -Wmissing-field-initializers -Wchar-subscripts
> -Wmismatched-tags -Wmissing-braces -Wshorten-64-to-32 -Wsign-compare
> -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter
> -Wnewline-eof
> ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).
> Needed to perform lazy binding to function _abort for architecture ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> It must have something to do with the fact that I use
>   export MACOSX_DEPLOYMENT_TARGET="10.5"
> but I didn't yet try to figure out how to modify Portfiles to actually
> link against 10.5 SDK.

Odd.  I'd expect MACOSX_DEPLOYMENT_TARGET="10.5" to not use dyld_stub_binder at 
all.

> 
> Before I spend half a day debugging: what's the easiest way to add
>   -isysroot /Developer/SDKs/MacOSX10.5.sdk
> to the relevant ports and which ports are most likely relevant for
> this error? Just libcxxabi?
> 
> I will also try to change "if {${os.major} < 10} { ... }" in libcxxabi
> to "< 11" just in case.
> 
>>>>> At the same time clang++-mp-3.4 works fine even though both clang 3.4
>>>>> and 3.7 are x86_64 only.
>> 
>> That's because it's actually just acting a s front-end to gcc for -arch ppc.
> 
> Thank you.
> 
>>>>> I'm now trying to rebuild everything as +universal (with ppc included
>>>>> in the list of universal architectures) and hope that it 

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Jeremy Huddleston Sequoia]

> On Mar 10, 2016, at 17:20, Mojca Miklavec  wrote:
> 
> On 10 March 2016 at 21:26, Ryan Schmidt wrote:
>>> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec wrote:
>>> 
>>> Hi,
>>> 
>>> While following
>>>   https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
>>> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
>>> might have an even better support for PPC than 3.6).
>>> 
>>> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
>>> so I wasn't able to install libcxx. I get:
>>> 
 clang++-mp-3.7 a.cc -arch ppc
>>> ld: unknown/unsupported architecture name for: -arch ppc
>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)

The linker you have installed doesn't support ppc.  You need to install ld64 
with the +ld64_127 variant to get the last version of the linker that supported 
ppc.

>>> At the same time clang++-mp-3.4 works fine even though both clang 3.4
>>> and 3.7 are x86_64 only.

That's because it's actually just acting a s front-end to gcc for -arch ppc.

>>> I'm now trying to rebuild everything as +universal (with ppc included
>>> in the list of universal architectures) and hope that it will work
>>> afterwards.

Nope.  That has nothing to do with it.  That just means what architectures the 
clang executable will run on, not which architectures and platforms it will 
target.

>>> But I would be grateful for ideas about why clang 3.4
>>> would be able to create ppc binaries and clang 3.7 not.

3.4 doesn't.
3.7 does, but you didn't have the correct linker.

>>> Thank you,
>>>  Mojca
>>> 
>>> PS: I'm not actually using the PPC, I'm doing this all for fun and as
>>> a challenge. But I don't have any VM with 10.5, so I wanted to do the
>>> cross-compiling step on VM with 10.6.
>> 
>> Maybe:
>> 
>> https://trac.macports.org/changeset/129356
> 
> Weird. This changes predates the initial version of
>https://trac.macports.org/wiki/LibcxxOnOlderSystems
> that suggests cross-compiling libcxxabi with ppc support.
> 
> Judging from
>http://www.csl.cornell.edu/~fang/sw/llvm/
> I would imagine that there must be a way to compile libc++ (even on
> 10.4 and even if from another repository). The problem is a bit of a
> chicken-and-egg, requiring a working clang-3.6 (3.7?) compiler to
> build libc++; but 3.7 would refuse to do the linking step. Maybe I'll
> need to do that in multiple stages as described on that website.
> 
> I'm waiting for the universal build of clang 3.4 to finish first. I
> don't know if that will make any difference, but let's see.
> 
> Mojca

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

Re: LeopardSDKFixes on PPC

[Jeremy Huddleston Sequoia]

To be clear, you replaced libgcc_s.10.5.dylib on your Leopard box with one 
copied from Snow Leopard or later, right?  Did you also fix the one in the 
Leopard SDK?

> On Mar 9, 2016, at 7:42 AM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> I wanted to try the following out on a PPC:
>https://trac.macports.org/wiki/LeopardSDKFixes
> 
> I did both steps, but "__uint128_t" still doesn't work. Is that
> expected given that it's just an old PPC box? (I'm aware that PPC is
> not too well supported in clang, but that doesn't mean I shouldn't
> experiment a bit :)
> 
> Thank you,
>Mojca

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

Re: Using cxx11 PortGroup on < 10.9

[Jeremy Huddleston Sequoia]

> On Jan 25, 2016, at 08:04, Michael Dickens  wrote:
> 
> We've had this discuss before, how to do C++11 for libstdc++ and libc++.
> 
> The cxx11 PortGroup implements C++11 compliance for libc++ only. It
> errors out when using libstdc++.
> 
> What Mojca is asking is whether we can add an implementation for when
> using libstdc++

"libstdc++" means /usr/lib/libstdc++.6.dylib, and it doesn't support C++11, so 
it is not possible to use the system libstdc++ for C++11 code.  I don't think 
we want to start supporting people using ${prefix}/lib/libstdc++.6.dylib from 
libgcc as that is quite untested and aiming for a world of hurt.

> , and I am on board with agreeing on how to do this
> change. It won't be perfect, since using libstdc++ has issues & will
> require selecting a default compiler for building that is C++11
> compliant; and, MacPorts provides no good way to add whitelist options
> beyond variants in this case. Variants are what we used to do for
> selecting a compiler suite, e.g., for various math ports.
> 
> I see no need to have port-by-port intervention; either one is using
> libc++ or libstdc++, depending on host OS and user-select options. If
> using the former, then just do what the cxx11 PortGroup does right now.
> 
> If using the latter, then do something like the following -- which I
> admit is not perfect, but it should work for most ports:
> {{{
> # *clang* when using libstdc++ do not seem to support C++11;
> # C++11 support seems to need GCC 4.7+ when using libstdc++;
> # could use C++0x support on GCC4.[56], but just ignore it since
> # there are newer compilers already in place as defaults.
> 
> # Blacklist GCC compilers not supporting C++11 and all CLANG.
> # This is probably not necessary, but it's good practice.
> 
> compiler.blacklist-append *clang* {*gcc-3*} {*gcc-4.[0-6]}
> 
> # and whitelist those we do want to use. wish there were a better way.
> # these will be used in the order provided.
> 
> compiler.whitelist macports-gcc-5 macports-gcc-4.9

This is surely not what you want.  This will cause the build to use 
${prefix}/lib/libstdc++.6.dylib.  I could see this being useful for 10.5 and 
earlier or ppc builds (because libc++ doesn't work on those platforms), but we 
don't really support those platforms any more anyways.  You might as well use 
the more-tested path of using libc++ and a macports-clang compiler in these 
cases.

To be clear, setting configure.cxx_stdlib to "libstdc++" means 
/usr/lib/libstdc++.6.dylib, it does not mean use any libstdc++ available.  The 
macports-gcc compilers don't quite work well for this scenario.  If you really 
want to support this, we'll need some new option for this (maybe 
macports-libstdc++), and dependency tracking will become quite difficult.

> }}}



> 
> My US$0.02. - MLD
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: Using cxx11 PortGroup on < 10.9

[Jeremy Huddleston Sequoia]

> On Jan 25, 2016, at 09:29, Mojca Miklavec <mo...@macports.org> wrote:
> 
> On 25 January 2016 at 18:11, Jeremy Huddleston Sequoia wrote:
>>> On Jan 25, 2016, at 08:04, Michael Dickens wrote:
>>> 
>>> We've had this discuss before, how to do C++11 for libstdc++ and libc++.
>>> 
>>> The cxx11 PortGroup implements C++11 compliance for libc++ only. It
>>> errors out when using libstdc++.
>>> 
>>> What Mojca is asking is whether we can add an implementation for when
>>> using libstdc++
>> 
>> "libstdc++" means /usr/lib/libstdc++.6.dylib, and it doesn't support C++11, 
>> so it is not possible to use the system libstdc++ for C++11 code.  I don't 
>> think we want to start supporting people using 
>> ${prefix}/lib/libstdc++.6.dylib from libgcc as that is quite untested and 
>> aiming for a world of hurt.
> 
> Just to clarify. I don't want to "support" anyone building C++11 code
> against /usr/lib/libstdc++.6.dylib.
> 
> I would like to support building C++11 code against libc++ for users
> who have not modified their stdlib setting yet (that includes the
> buildbots) and for a small subset of ports where doing that doesn't
> actually lead to crashes and problems. Examples include clang-3.7,
> root6 etc.

What about something like cxx11.no_abi_boundary which would do what we do in 
clang:

configure.cxx_stdlib libc++
depends_lib-append port:libcxx

instead of the error message?

Both cases would benefit from the group's blacklist while allowing for both use 
cases.

> But I agree that one can in principle do that without the portgroup.
> 
> (Even more than that I would really like to see the buildbots with
> libc++ as their default stdlib being set up.)
> 
> Then again ... the longer we postpone this action, the less people
> will feel that it would have to be done at all and the smaller the
> chances will be that we would be able to fix remaining problems.
> 
> Mojca
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: Using cxx11 PortGroup on < 10.9

[Jeremy Huddleston Sequoia]

> On Jan 23, 2016, at 14:08, Mojca Miklavec  wrote:
> 
> Hi,
> 
> Would it be possible to implement a way to use the cxx11 PortGroup
> without having to use libc++ as default stdlib? Maybe with an
> additional configuration like:
>PortGroup cxx11 1.0
>cxx.require_global_libc++ no
> (but with a better keyword of course).
> 
> What I have in mind are ports that require C++11, but don't have any
> C++ dependencies and thus don't suffer from stdlib incompatibility.
> 
> Examples of such ports would be root6, newer versions of clang etc.

Yes, there are clients which use just the C++ STL and don't export any C++ 
APIs.  However, clang is not one of them.  It has C++ dependecies (llvm) and 
exports C++ APIs (libclang).  Since it can't be built on older systems anyways, 
we just force libc++.

> It
> would be handy to have a shortcut, but cxx11 PortGroup alone is a tiny
> bit too restrictive.

What benefit does "cxx.require_global_libc++ no" have over the current approach 
of just doing:

configure.cxx_stdlib libc++
depends_lib-append port:libcxx

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



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

Re: cmake port not installed by cmake portgroup on builders when building clang-3.8

[Jeremy Huddleston Sequoia]

> On Nov 30, 2015, at 15:02, Mojca Miklavec <mo...@macports.org> wrote:
> 
> On 30 November 2015 at 20:58, Jeremy Huddleston Sequoia
> <jerem...@macports.org> wrote:
>> I hit a build failure on the buildbots 
>> (https://build.macports.org/builders/buildports-mavericks-x86_64/builds/14982)
>>  because the cmake port was not installed as a build dependency:
>> 
>>sh: /opt/local/bin/cmake: No such file or directory
>> 
>> The cmake portgroup sets:
>> 
>># can use cmake or cmake-devel; default to cmake if not installed
>>depends_build-append path:bin/cmake:cmake
>> 
>> Yet the cmake port was not installed when building clang-3.8.  It was 
>> installed when building llvm-3.8.
>> 
>> Does anyone see what the problem is?
> 
> I would suspect
>depends_build   port:cctools
> lacking an "-append".

Good eye.  Thanks!  Staring at the same Portfile for days makes you blind to 
some things! =)

--Jeremy



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

cmake port not installed by cmake portgroup on builders when building clang-3.8

[Jeremy Huddleston Sequoia]

I hit a build failure on the buildbots 
(https://build.macports.org/builders/buildports-mavericks-x86_64/builds/14982) 
because the cmake port was not installed as a build dependency:

sh: /opt/local/bin/cmake: No such file or directory

The cmake portgroup sets:

# can use cmake or cmake-devel; default to cmake if not installed
depends_build-append path:bin/cmake:cmake

Yet the cmake port was not installed when building clang-3.8.  It was installed 
when building llvm-3.8.

Does anyone see what the problem is?

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

Re: Owner of MacPorts account on GitHub

[Jeremy Huddleston Sequoia]

> On Nov 10, 2015, at 15:58, Lawrence Velázquez  wrote:
> 
> On Nov 9, 2015, at 4:45 PM, Rainer Müller  wrote:
> 
>> On 2015-11-09 21:01, Mojca Miklavec wrote:
>>> Does anyone know who owns
>>>   https://github.com/MacPorts
>>> ?
>> 
>> I would be interested to know that as well. I actually found a way to
>> send them a message last week. Now we can just wait for them to get back
>> to us.
> 
> Surprise! It's me.
> 
> I've been waiting 2 years 6 months 18 days for this. Thought it might never 
> happen.
> 
> vq

It would be great if you could convert it to an organization rather than a user 
and add others to the org.

--Jeremy




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

Re: [141139] trunk/base/src/port1.0/portchecksum.tcl

[Jeremy Huddleston Sequoia]

Well since nobody else spoke, this is what I went with in r142074.

Thanks,
Jeremy

> On Oct 12, 2015, at 07:00, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> I can’t speak for anyone else, but that works for me :)
> 
>> On Oct 11, 2015, at 8:08 PM, Jeremy Huddleston Sequoia 
>> <jerem...@macports.org> wrote:
>> 
>> Ok, so if the set includes the union of "good" and "specified", we're all 
>> happy?
>> 
>>> On Oct 11, 2015, at 13:25, Daniel J. Luke <dl...@geeklair.net> wrote:
>>> 
>>> +1
>>> 
>>> If we really want to encourage people to stop using the weak hashes, we 
>>> could print a warning if any of them are in the output.
>>> 
>>>> On Oct 11, 2015, at 4:12 PM, Joshua Root <j...@macports.org> wrote:
>>>> How about this:
>>>> 
>>>> * If the checksums specified in the Portfile include sha256, just print
>>>> out the actual values for those checksum types.
>>>> 
>>>> * If not, add sha256 to the list when printing out the actual values.
>>>> 
>>>> After all there's no harm in using weak hashes in addition to good ones.
>>>> 
>>>> - Josh
>>>> 
>>>> On 2015-10-12 07:02 , Joshua Root wrote:
>>>>> Yes, and I seem to remember having this conversation once before... :)
>>>>> 
>>>>> On 2015-10-12 05:06 , Daniel J. Luke wrote:
>>>>>> it’s really useful for the case when upstream publishes a checksum 
>>>>>> (that’s not one of our default ‘good’ ones) when the output includes the 
>>>>>> checksums that are in the portfile.
>>>>>> 
>>>>>>> On Oct 11, 2015, at 1:34 PM, jerem...@macports.org wrote:
>>>>>>> Use $default_checksum_types for handy copy/paste output on checksum 
>>>>>>> failure
>>>>>>> 
>>>>>>> This should help adoption of better, more robust hashing algorithms.
> 
> — 
> 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-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

Re: xorg-libXt

[Jeremy Huddleston Sequoia]

sudo port -v -s upgrade -n --force xorg-libXt +flat_namespace

+flat_namespace can't break anything.  Installing libXt with +flat_namespace 
will give you the exact same thing you already had.
-flat_namespace *can* break things (like openmotif), which is why openmotif 
requires the +flat_namespace variant.

I added the +flat_namespace variant in order to give users on such legacy 
software an option until (if ever) those libraries are fixed.

When trac comes back, see https://trac.macports.org/ticket/45712

--Jeremy

> On Oct 22, 2015, at 05:40, Adam Dershowitz  wrote:
> 
> I normally would have done some searching on for tickets and such, but at the 
> moment some of the Macports servers are having issues, so I figured I would 
> just ask you about it directly.  I hope that you don’t mind.
> I just saw that open motif and xorg-libXt both are outdated and I tried to 
> upgrade them.  Macports upgraded xorg-libXt just fine, but then when it tried 
> to upgrade open motif it complained that:
> Error: org.macports.archivefetch for port openmotif returned: xorg-libXt must 
> be installed with +flat_namespace.
> Please see the log file for port openmotif for details:
> 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_openmotif/openmotif/main.log
> Error: Unable to upgrade port: 1
> 
> I never directly installed either of these.  They were each dependents on 
> other ports, so were installed with variants as those ports set them up.  So, 
> I wanted to check how best to go about getting this upgrade to work, and to 
> make sure that installing with +flat_namespace is not going to start breaking 
> other ports such as ImageMagick and ghostscript since each of those uses 
> these ports?
> 
> Thanks,
> 
> --Adam
> 
> 
> 



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

Re: [MacPorts] #49227: gcc5 @5.2.0: fix gcj

[Jeremy Huddleston Sequoia]

> On Oct 19, 2015, at 13:37, Jack Howarth  wrote:
> 
> On Mon, Oct 19, 2015 at 3:41 PM, MacPorts  wrote:
>> #49227: gcc5 @5.2.0: fix gcj
>> +--
>>  Reporter:  howarth.at.macports@…  |  Owner:  mww@…
>>  Type:  defect | Status:  new
>>  Priority:  Normal |  Milestone:
>> Component:  ports  |Version:  2.3.4
>> Resolution: |   Keywords:  haspatch
>>  Port:  gcc5   |
>> +--
>> 
>> Comment (by jeremyhu@…):
>> 
>> Replying to [comment:11 graziosi.angelo@…]:
>>> Replying to [comment:10 jeremyhu@…]:
 graziosi.angelo, you don't understand potential fallout to compiler
>> changes.
 
 At worst, the compiler produces bad code and anything that it compiled
>> needs to be recompiled.  We don't have a mechanism for triggering that, so
>> we need to be extra careful taking toolchain changes.
>>> 
>>> Exactly what happens at (almost) every new compiler release. Recently,
>> MSYS2/MINGW64, for having adopted GCC-5.2, had to recompile *all* its
>> packages, and a few didn't rebuilt any more and are out of distribution..
>> On OSX and friends, things are no better..
>> 
>> No, that's certainly not true.  Some people may *choose* to recompile with
>> newer compilers because they want to.  That doesn't mean that the older
>> compiled code was wrong.
>> 
>> We are careful here because we don't want to release compilers that
>> produce incorrect binaries.
>> 
> 
> You do realize that the boehm-gc code is entirely limited to gcj
> and its associated libraries.

Yes.

> It is built as a convenience library
> linked into those and isn't distributed independently as a library in
> FSF gcc.  

Yes.

> Also, we don't even really have a functional gcj currently
> on darwin14 and early because gcj isn't being properly built and
> doesn't create the ecj1 required for java source files.

Yes.

> Your current
> gcj only works for precompiled classes which is pretty much useless.

Yes.

> It is rather unfortunate that FSF gcc never added java file
> compilation tests to their libjava testsuite to capture that but
> libjava development is pretty moribund.
> Also this change is pretty much pre-authorized in the comment of
> 
>  * ALIGNMENT is the largest N, such that
>  * all pointer are guaranteed to be aligned on N byte boundaries.
>  * defining it to be 1 will always work, but perform poorly.
> 
> in boehm-gc/include/private/gcconfig.h. You could set the alignment to
> 1 if you wanted to be extra careful, but the fact that an alignment of
> 2 produces a boehm-gc and gcj which produce no regression in their
> testuites on both darwin13 and darwin15 is a pretty damn good
> confirmation that the change is safe.

I'd feel better just skipping the compilation of gcj and not shipping a broken 
compiler which upstream has stopped caring about to our users.

> 
>> --
>> Ticket URL: 
>> MacPorts 
>> Ports system for OS X



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

Re: [MacPorts] #49273: clang-mp-3.7 and MACOSX_DEPLOYMENT_TARGET=10.3 do not mix

[Jeremy Huddleston Sequoia]

> On Oct 14, 2015, at 09:32, Jarkko Hietaniemi  wrote:
> 
>> 
>>  ld64 is the linker.  You can use variants to choose what the default
>>  linker is.  +ld64_latest should be preferred in most cases, but there is
>>  lag after Apple releases Xcode versions before we can update ld64-latest
>>  to the newest version, so ld64-xcode may be newer during that period.
> 
> FWIW, I now tested the "sudo port install ld64 +ld64_xcode" recipe, and 
> verified that it works fine.  I may add this to the Darwin notes of
> Perl, since I'd never heard of this, and I do build Perl on Darwin quite 
> often.
> 
>>  If you really want to support all systems, setting it 10.4 should suffice.
>> 
>>  If you want to cover the 99.9% case, setting it to 10.6 should suffice.
>> 
>>  10.8 and 10.9 as minimum requirements are starting to be come more popular
>>  as well, but the reasons for that probably don't impact perl too much.
>>  You may, however, want to consider 10.7 because I brought in a good
>>  portion of SUSv4 updates, some Libc API extensions from FreeBSD, NetBSD
>>  RBTrees, and other various Libc niceties.
> 
> Then there is the option of not specifying the target at all?  Or is that a 
> bad idea?  (It means using the oslevel of the build system as the target, 
> right?)
> 
> What exactly happens if something compiled with, say, 10.8 target, is run in, 
> say, 10.7?  Will it run slow?  Or run wrong?  Or just not run?

If you build with a deployment target that is newer than the OS you run the 
built executable on, it won't run.




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

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 14, 2015, at 09:21, Landon J Fuller <land...@macports.org> wrote:
> 
> 
> On Oct 13, 2015, at 9:16 PM, Jeremy Huddleston Sequoia 
> <jerem...@macports.org> wrote:
>>> If anything, I think MacPorts ought to be shielding users from Apple’s use 
>>> of tooling updates to bitrot working software that happens to not be 
>>> aligned with their release-to-release platform priorities.
>> 
>> The best way to "shield users" is to fix or remove broken and unmaintained 
>> ports.
> 
> Unlike post-iOS7 Apple, I don’t think platform vendors serve their users by 
> capriciously breaking working software.

I take great personal offense to that statement.  Apple engineers (myself 
included) take great strides to make sure that existing software continues to 
work.  Binary compatibility is a top concern at Apple, and if you find any case 
where existing software breaks after an OS update, make sure you report it.

> If the apple-gcc42 port — or any other — works, then I see no reason to 
> forbid developers from using it.

The port works in that the resulting software does what it was designed to do.  
The problem is that it was designed almost a decade ago.  It is an antiquated 
toolchain that is riddled with bugs, won't ever be fixed, and doesn't support 
modern language revisions.

> If, in the future, it ceases to work, I see no reason to forbid interested 
> parties from fixing it.

There have been no such interested parties; I was the one that resurrected it 
and improved it to allow it to be a usable fallback compiler while ports got 
fixed to support clang or clang got fixed to deal with broken corner cases 
exposed by ports.  That usefulness is now dried up.  If someone does become 
interested, I would be happy to let them take over, but it would probably be 
more worthwhile to update the gcc6 port with support for the apple gcc driver 
driver instead of meddling with a nearly decade old compiler.

--Jeremy




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

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 14, 2015, at 10:07, Landon J Fuller <land...@macports.org> wrote:
> 
> 
> On Oct 14, 2015, at 10:35 AM, Jeremy Huddleston Sequoia 
> <jerem...@macports.org> wrote:
> 
>> 
>>> On Oct 14, 2015, at 09:21, Landon J Fuller <land...@macports.org> wrote:
>>> 
>>> 
>>> On Oct 13, 2015, at 9:16 PM, Jeremy Huddleston Sequoia 
>>> <jerem...@macports.org> wrote:
>>>>> If anything, I think MacPorts ought to be shielding users from Apple’s 
>>>>> use of tooling updates to bitrot working software that happens to not be 
>>>>> aligned with their release-to-release platform priorities.
>>>> 
>>>> The best way to "shield users" is to fix or remove broken and unmaintained 
>>>> ports.
>>> 
>>> Unlike post-iOS7 Apple, I don’t think platform vendors serve their users by 
>>> capriciously breaking working software.
>> 
>> I take great personal offense to that statement.  Apple engineers (myself 
>> included) take great strides to make sure that existing software continues 
>> to work.  Binary compatibility is a top concern at Apple, and if you find 
>> any case where existing software breaks after an OS update, make sure you 
>> report it.
> 
> It’s not just binary compatibility (although that in of itself is a serious 
> problem), it’s also source compatibility. Apple’s constant breaking changes,

Can you enumerate these constant breaking changes please?

> keyed to Xcode/SDK versions used — coupled with rapid deprecation and removal 
> of previous SDKs/toolchains

Can you give a specific example of what you believe was done rapidly?  OpenSSL 
was deprecated for about 5 years before its headers were removed from the SDK.  
That seems like more than enough time for projects to adapt.  Additionally, the 
library still ships, maintaining binary compatibility.

> , along with mandatory toolchain updates required to support later releases — 
> means that existing, working, tagged code, written against purely 
> stable/public APIs, bitrots in place at a frenetic pace.

This is true for pretty much any platform.  I challenge you to build gtk1 on a 
modern Linux distro or qt2 on FreeBSD 10.

> Depending on the scale/scope of breaking changes, the cost to keep software 
> (written to defined APIs!) building and working across iOS (and increasingly 
> OS X) releases can be unexpectedly large, creating a risk to 
> maintaining/supporting software on the platform that is quickly outpacing 
> what we can reasonably justify as a business.

We take great pains to ensure that shipped apps continue to work on new OS 
versions by maintaining binary compatibility.

Yes, requirements change (for example, requiring a root view controller in iOS 
7), and developers need to adapt to newer requirements, but a TON of effort is 
made to ensure backwards compatibility.

> With open-source projects like PLCrashReporter, I don’t believe there's been 
> an iOS release since iOS 6 that did not contain serious kernel/dyld 
> regressions caught by our test suite.

You will have absolutely no sympathy from me if you try to use software that 
takes over the exception handler port.  If you do that, you're asking for 
trouble. I've yet to see an implementation that does this right other than 
service that Apple already provides to developers to do this for them.

> In addition, each Xcode/SDK release has broken the build, requiring that we 
> take otherwise functioning tagged code and issue an additional release just 
> for compatibility with the latest Xcode. The amount of churn created by 
> Apple’s breakneck development pace — coupled with a willingness to break 
> developers — has reached a point where I’m ready to give up trying to ship 
> stable releases at all, as there’s little point in providing a “stable” 
> release that will — at absolute best — break again in the next 6-12 months.

>>> If the apple-gcc42 port — or any other — works, then I see no reason to 
>>> forbid developers from using it.
>> 
>> The port works in that the resulting software does what it was designed to 
>> do.  The problem is that it was designed almost a decade ago.  It is an 
>> antiquated toolchain that is riddled with bugs, won't ever be fixed, and 
>> doesn't support modern language revisions.
> 
> If it solves someone’s problem — such as building an older port or software — 
> it still holds value. I don’t think anyone should be obligated to maintain 
> it, but neither do I think that we need to adopt Apple’s approach of forced 
> deprecation of things we no longer like.

It doesn't have anything to do with liking it or not.  It's riddled with bugs, 
and I see no value in fixing it.

> 
> -landonf



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

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 14, 2015, at 12:30, Landon J Fuller <land...@macports.org> wrote:
> 
> 
> On Oct 14, 2015, at 12:59 PM, Jeremy Huddleston Sequoia 
> <jerem...@macports.org> wrote:
> 
>> 
>>> On Oct 14, 2015, at 10:07, Landon J Fuller <land...@macports.org> wrote:
>>> 
>>> 
>>> On Oct 14, 2015, at 10:35 AM, Jeremy Huddleston Sequoia 
>>> <jerem...@macports.org> wrote:
>>> 
>>>> 
>>>>> On Oct 14, 2015, at 09:21, Landon J Fuller <land...@macports.org> wrote:
>>>>> 
>>>>> 
>>>>> On Oct 13, 2015, at 9:16 PM, Jeremy Huddleston Sequoia 
>>>>> <jerem...@macports.org> wrote:
>>>>>>> If anything, I think MacPorts ought to be shielding users from Apple’s 
>>>>>>> use of tooling updates to bitrot working software that happens to not 
>>>>>>> be aligned with their release-to-release platform priorities.
>>>>>> 
>>>>>> The best way to "shield users" is to fix or remove broken and 
>>>>>> unmaintained ports.
>>>>> 
>>>>> Unlike post-iOS7 Apple, I don’t think platform vendors serve their users 
>>>>> by capriciously breaking working software.
>>>> 
>>>> I take great personal offense to that statement.  Apple engineers (myself 
>>>> included) take great strides to make sure that existing software continues 
>>>> to work.  Binary compatibility is a top concern at Apple, and if you find 
>>>> any case where existing software breaks after an OS update, make sure you 
>>>> report it.
>>> 
>>> It’s not just binary compatibility (although that in of itself is a serious 
>>> problem), it’s also source compatibility. Apple’s constant breaking changes,
>> 
>> Can you enumerate these constant breaking changes please?
> 
> Off the top of my head? iOS 7 regression broke RTF viewing in UIWebView at 
> the last possible minute before GM. That was a fun scramble.

Sounds like a legitimate bug rather than an intentional change.  Bugs happen.  
Report them, and they'll get fixed.  Yes, it sucks when things ship to 
customers with bugs, but that happens, and it's not a problem unique to Apple.  
I test you to find a single piece of software that ever shipped completely bug 
free.

> There’s plenty more that you can easily find — if you care — in 
> Radar/OpenRadar, or almost any complex open source project’s bug tracker.

If you can show me specific examples, and if any of them really as overly quick 
deprecation or removal, I will certainly fight on your behalf to correct such 
missteps.  However, I am not aware of anything like that.  Please be specific.  
Point me to radars that you've filed, etc, and I'll look them up and help you 
out.

>> Can you give a specific example of what you believe was done rapidly?  
>> OpenSSL was deprecated for about 5 years before its headers were removed 
>> from the SDK.  That seems like more than enough time for projects to adapt.  
>> Additionally, the library still ships, maintaining binary compatibility.
> [snip]
>> We take great pains to ensure that shipped apps continue to work on new OS 
>> versions by maintaining binary compatibility.
>> 
>> Yes, requirements change (for example, requiring a root view controller in 
>> iOS 7), and developers need to adapt to newer requirements, but a TON of 
>> effort is made to ensure backwards compatibility.
> 
> 
> Sure. Xcode only ships with the current SDK, and that occurs at least once a 
> year. This prevents projects from declaring a specific SDK version that they 
> build against, because that will inescapably break tagged releases within the 
> year.

Re "that will inescapably break tagged releases within the year" I don't think 
it's quite as bad as you exclaim.  There are plenty of complex projects that 
build just as fine now as they did a few years ago with an older SDK.  I can 
still build all of Xorg from over 5 years ago with the current SDK.  There are 
plenty of extra warnings due to clang diagnostic improvements, but it builds.   
Furthermore, again I stress that this problem is not unique to Apple.  
Developers targeting Windows, Linux, FreeBSD, Solaris, etc all have the same 
problem of SDKs getting updated.  Developers can just as easily state that a 
given tag is intended to be built against a specific OS X SDK on OS X, a 
specific glibc version on Linux, specific FreeBSD versions, etc.

Why are you seeing this as an Apple problem?

> However, the new SDKs will themselves often break source compatibility

Sometimes, yes.  However, that is usually done after mu

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 13, 2015, at 09:55, Landon Fuller <land...@macports.org> wrote:
> 
> 
> On Oct 12, 2015, at 14:14, Jeremy Huddleston Sequoia <jerem...@macports.org> 
> wrote:
> 
>> Yes, and I was quite happy that the compilers failed to work in Yosemite, 
>> allowing me to mark them as unavailable.  Unfortunately, some life was 
>> breathed into them again, preventing them from slipping off to their well 
>> deserved graev.
> 
> If someone wants to do the maintenance work, I don’t see why we ought to 
> artificially constrain their ability to do so. If nobody does the work, then 
> the packages clearly aren’t a priority, and can be retired.

Yes, but we still want apple-gcc42 for older OS versions.

> 
>> libstdc++ does not exist on new platforms (eg: tvOS and watchOS).  Projects 
>> should not be using libstdc++ any more and should have migrated by now 
>> (unless, of course, they need to support Snow Leopard users still).
> 
> Apple has also dropped a number of POSIX-defined APIs on tvOS and watchOS, as 
> well as a number of Darwin/Mach APIs; Apple’s modern platform priorities 
> aren’t really a measure of what is ideal for — or required by — software 
> users or developers on OS X.
> 
>> I wouldn't be surprised if the headers disappeared from a future SDK or had 
>> markup preventing them from being used with a deployment target of 10.7 or 
>> higher.
> 
> 
> If anything, I think MacPorts ought to be shielding users from Apple’s use of 
> tooling updates to bitrot working software that happens to not be aligned 
> with their release-to-release platform priorities.

The best way to "shield users" is to fix or remove broken and unmaintained 
ports.

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

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

As mentioned earlier, I updated base and the ports to defer dropping support 
for these legacy compilers.

I also did an audit of the ports that are blacklisting clang and fixed a few 
along the way to remove the blacklisting.  It's not surprising that most of the 
remainder are dead ports, over half of which don't even build on current OS 
versions despite the blacklisting of clang.  Here's my summary:

# Projects bugs: Misc
./devel/inform/Portfile:compiler.blacklist  *clang*
./lang/gprolog/Portfile:compiler.blacklist-append  *clang* *llvm-gcc-4.2

# Project bugs: clang strictness is helping to find real project errors and 
it's likely newer gcc fail as well
./sysutils/apt/Portfile:compiler.blacklist  *clang*

# Projects bugs: Misc C++
./news/nget/Portfile:compiler.blacklist  *clang*
./science/coinor-liblemon/Portfile:compiler.blacklist  *clang*
./science/solid/Portfile:compiler.blacklist  *clang*
./textproc/irstlm/Portfile:compiler.blacklist  *clang*
./textproc/stardict/Portfile:compiler.blacklist *clang*

# Project bugs: Bad gnulib-tool hacks
./lang/g-wrap/Portfile:compiler.blacklist-append   *clang*

# Project bugs: ccdep.pl
./graphics/sam2p/Portfile:compiler.blacklist-append  *clang*

# Project bugs: gcc extension that clang does not implement: -fnested-functions
./games/frozenbubble2/Portfile:compiler.blacklist  *clang*

# Project bugs: gcc extension that clang does not implement: __builtin_apply, 
etc.
./science/swarm/Portfile:compiler.blacklist  *clang*

# Not sure if these are project issues or an llvm bug
./lang/pfe/Portfile:compiler.blacklist  *clang* *llvm-gcc-4.2

# Only done a non-default variant
./science/nds2-client/Portfile:compiler.blacklist-append   *clang*

# Don't seem to build despite (and sometimes because of) the blacklisting
./aqua/SIDPLAY/Portfile:compiler.blacklist  *clang*
./aqua/TeXShop/Portfile:compiler.blacklist  *clang*
./cross/arm-elf-gcc3/Portfile:compiler.blacklist  *clang* *llvm-gcc-4.2
./cross/i386-mingw32-gcc/Portfile:compiler.blacklist *llvm-gcc-4.2 *clang*
./cross/m68k-elf-gcc/Portfile:compiler.blacklist  *clang* *llvm-gcc-4.2
./cross/msp430-gcc-devel/Portfile:compiler.blacklist *clang*
./cross/msp430-gdb/Portfile:compiler.blacklist *clang*
./cross/msp430-gdb-devel/Portfile:compiler.blacklist *clang*
./editors/texstudio/Portfile:compiler.blacklist  *clang*
./finance/taxbird/Portfile:compiler.blacklist  *clang*
./gis/grass/Portfile:# compiler.blacklist  *clang*
./lang/hugs98/Portfile:compiler.blacklist  *clang*
./net/sobby/Portfile:compiler.blacklist  *clang*
./science/alps/Portfile:compiler.blacklist  *clang*

# Listed as not supported on recent OS versions anyways.  Does anyone care?  If 
not, we should just remove these ports.
./graphics/agave/Portfile:compiler.blacklist *clang*
./graphics/exact-image/Portfile:compiler.blacklist-append  *clang*
./math/classias/Portfile:compiler.blacklist  *clang*
./net/mediatomb/Portfile:compiler.blacklist  *clang*
./science/bali-phy/Portfile:compiler.blacklist *clang*
./science/eo/Portfile:compiler.blacklist  *clang*
./textproc/mgizapp/Portfile:compiler.blacklist  *clang*
./textproc/pialign/Portfile:compiler.blacklist  *clang*
./textproc/sword/Portfile:compiler.blacklist-append *clang*

# The gcc-4.2 ports don't help because they're blacklisted as well (most are 
libstdc++ C++11 hacks that should be done differently)
./python/py-healpy/Portfile:compiler.blacklist *gcc-4.2 *clang*
./science/gnuradio/Portfile:compiler.blacklist-append *clang* {*gcc-3*} 
{*gcc-4.[0-6]}
./science/gr-foo/Portfile:compiler.blacklist-append *clang* {*gcc-3*} 
{*gcc-4.[0-6]}
./science/gr-ieee802-11/Portfile:compiler.blacklist-append *clang* 
{*gcc-3*} {*gcc-4.[0-6]}
./science/gr-ieee802-15-4/Portfile:compiler.blacklist-append *clang* 
{*gcc-3*} {*gcc-4.[0-6]}
./science/seqan-apps/Portfile:compiler.blacklist  *gcc-4.2 *clang* 
macports-gcc-4.9
./science/volk/Portfile:compiler.blacklist-append *clang* *gcc-3.* 
{*gcc-4.[0-6]}

# There ports are for legacy versions.  Current versions aren't blacklisted.
./databases/mysql5/Portfile:compiler.blacklist-append *clang*
./databases/mysql51/Portfile:compiler.blacklist-append *clang*
./lang/ruby186/Portfile:compiler.blacklist *clang* *llvm-gcc-4.2

# Blacklisting done conditionally such that it doesn't matter here
./databases/rethinkdb/Portfile:compiler.blacklist-append   *clang*


> On Oct 12, 2015, at 13:14, Jeremy Huddleston Sequoia <jerem...@macports.org> 
> wrote:
> 
> 
>> On Oct 12, 2015, at 11:28, Joshua Root <j...@macports.org> wrote:
>> 
>> On Mon, Oct 12, 2015 at 1:49 PM, Jeremy Huddleston Sequoia
>> <jerem...@macports.org> wrote:
>>> 
>>>> On Oct 11, 2015, at 23:15, Ryan Schmidt <ryandes...@macports.org> wrote:
>>>> 
>>>> On Oct 11, 2015, at 11:14 AM, jerem...@macports.org wrote:
>>>> 
>>>

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

Hey Eric,

Last month, you mentioned rewriting the llvm Portfile to use the cmake build 
system.  I think now might be an opportune time to do that in llvm-3.8.  Have 
you looked into that yet?

--Jeremy

> On Sep 3, 2015, at 10:10, Eric A. Borisch <ebori...@macports.org> wrote:
> 
> I'll defer on rewriting the portfile for cmake.
> 
> I guess I like having libomp separate for now as it's much quicker to
> update (build) it stand-alone while it's still getting frequent
> updates. Note that (apparently) llvm is also packaging the OpenMP
> runtime separately for now -- see the pre-built binaries section of
> http://llvm.org/releases/download.html
> 
> I like your patch to teach clang where to look -- I'll add that when I
> have a chance.
> 
> 
> On Thu, Sep 3, 2015 at 11:21 AM, Jack Howarth
> <howarth.at.macpo...@gmail.com> wrote:
>>   You really will want to rewrite the llvm37 Portfile to use a cmake
>> build. The openmp 3.7 can be built in-tree using cmake (with the
>> sources placed at projects/openmp. Also the default for -fopenmp is
>> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
>> with...
>> 
>> --- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
>> +++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
>> @@ -182,7 +182,7 @@
>> set(DEFAULT_SYSROOT "" CACHE PATH
>>   "Default  to all compiler invocations for --sysroot=." )
>> 
>> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
>> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>>   "Default OpenMP runtime used by -fopenmp.")
>> 
>> set(CLANG_VENDOR "" CACHE STRING
>> 
>> In fink, we set the explicit location of the buried libomp.dylib with...
>> 
>> --- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
>> 09:10:45.0 -0400
>> +++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
>> @@ -6368,12 +6368,18 @@
>>options::OPT_fno_openmp, false)) {
>> switch (getOpenMPRuntime(getToolChain(), Args)) {
>> case OMPRT_OMP:
>> +  // Help clang find libomp.dylib
>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>   CmdArgs.push_back("-lomp");
>>   break;
>> case OMPRT_GOMP:
>> +  // Help clang find libgomp.dylib
>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>   CmdArgs.push_back("-lgomp");
>>   break;
>> case OMPRT_IOMP5:
>> +  // Help clang find libiomp5.dylib
>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>   CmdArgs.push_back("-liomp5");
>>   break;
>> case OMPRT_Unknown:
>> @@ -8079,9 +8085,13 @@
>> // Also link the particular OpenMP runtimes.
>> switch (getOpenMPRuntime(ToolChain, Args)) {
>> case OMPRT_OMP:
>> + // Help clang find libomp.dylib
>> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>   CmdArgs.push_back("-lomp");
>>   break;
>> case OMPRT_GOMP:
>> +  // Help clang find libgomp.dylib
>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>   CmdArgs.push_back("-lgomp");
>> 
>>   // FIXME: Exclude this for platforms with libgomp that don't 
>> require
>> @@ -8089,6 +8099,8 @@
>>   CmdArgs.push_back("-lrt");
>>   break;
>> case OMPRT_IOMP5:
>> + // Help clang find libiomp5.dylib
>> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>   CmdArgs.push_back("-liomp5");
>>   break;
>> case OMPRT_Unknown:
>> 
>> to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
>> fat binary of libomp,
>> you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386".
>>   Jack
>> ps Note that the perl-based Makefile build is no longer functional in
>> 3.7.0 and is in the process of being completely removed for the 3.8.0
>> release.
>> 
>> On Wed, Sep 2, 2015 at 9:59 PM, Jeremy Huddleston Sequoia
>> <jerem...@macports.org> wrote:
>>> Looks good to me.  Could you go ahead and push this to svn and also do 
>>> similar changes to the llvm-3.8 port for your openmp variant?
>>> 
>>> Thanks,
>>> Jeremy
>>> 
>>>> On Sep 2,

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 11, 2015, at 23:15, Ryan Schmidt  wrote:
> 
> On Oct 11, 2015, at 11:14 AM, jerem...@macports.org wrote:
> 
>> Revision
>> 141132
>> Author
>> jerem...@macports.org
>> Date
>> 2015-10-11 09:14:38 -0700 (Sun, 11 Oct 2015)
>> Log Message
>> 
>> apple-gcc42: Drop support on ElCap
> 
> 
> On Oct 11, 2015, at 11:15 AM, jerem...@macports.org wrote:
> 
>> Revision
>> 141133
>> Author
>> jerem...@macports.org
>> Date
>> 2015-10-11 09:15:20 -0700 (Sun, 11 Oct 2015)
>> Log Message
>> 
>> llvm-gcc42: Drop support on ElCap
> 
> 
> On Oct 11, 2015, at 12:09 PM, jerem...@macports.org wrote:
> 
>> Revision
>> 141134
>> Author
>> jerem...@macports.org
>> Date
>> 2015-10-11 10:09:05 -0700 (Sun, 11 Oct 2015)
>> Log Message
>> 
>> Refactor and update portconfigure::get_compiler_fallback
>> 
>> Separate out list generation into stages for easier updates in the future.
>> Use newer clang versions when using libc++ as our default C++ runtime.
>> Don't add legacy gcc fallbacks on El Capitan.
> 
> 
> Any particular reason you removed apple-gcc42 and llvm-gcc42 on El Capitan? 
> We only just released MacPorts 2.3.4 which finally returned apple-gcc42 and 
> llvm-gcc42 to the list of available compilers for Xcode 6 and later 
> (r140687). Reverting r141132, apple-gcc42 builds fine for me on 10.11, and 
> reverting r141133, llvm-gcc42 builds fine for me with apple-gcc42 on 10.11. 
> Are there situations where these compilers don't work correctly because of a 
> change in El Capitan?

They don't support C11
They don't support C++11
They don't support libc++
They've been deprecated for almost 5 years now.
I don't want to give the impression that we actually support this legacy 
toolchain on modern systems; it's only purpose was to help build ports that 
weren't building with clang.
If you don't want to drop support for them now, what do you consider a good 
time?  I'd prefer to not keep around legacy compilers if they're not actually 
needed.  So I guess I'll flip the question to you and ask if there's any 
compelling reason why one would still need them on El Cap.  Xcode 7's clang 
(and indeed macports-clang-3.7) is a much more mature, robust, and reliable 
compiler on El Cap than gcc-4.2.

--Jeremy



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

Re: [141132] trunk/dports/lang/apple-gcc42/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 12, 2015, at 11:28, Joshua Root <j...@macports.org> wrote:
> 
> On Mon, Oct 12, 2015 at 1:49 PM, Jeremy Huddleston Sequoia
> <jerem...@macports.org> wrote:
>> 
>>> On Oct 11, 2015, at 23:15, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> 
>>> On Oct 11, 2015, at 11:14 AM, jerem...@macports.org wrote:
>>> 
>>>> Revision
>>>> 141132
>>>> Author
>>>> jerem...@macports.org
>>>> Date
>>>> 2015-10-11 09:14:38 -0700 (Sun, 11 Oct 2015)
>>>> Log Message
>>>> 
>>>> apple-gcc42: Drop support on ElCap
>>> 
>>> 
>>> On Oct 11, 2015, at 11:15 AM, jerem...@macports.org wrote:
>>> 
>>>> Revision
>>>> 141133
>>>> Author
>>>> jerem...@macports.org
>>>> Date
>>>> 2015-10-11 09:15:20 -0700 (Sun, 11 Oct 2015)
>>>> Log Message
>>>> 
>>>> llvm-gcc42: Drop support on ElCap
>>> 
>>> 
>>> On Oct 11, 2015, at 12:09 PM, jerem...@macports.org wrote:
>>> 
>>>> Revision
>>>> 141134
>>>> Author
>>>> jerem...@macports.org
>>>> Date
>>>> 2015-10-11 10:09:05 -0700 (Sun, 11 Oct 2015)
>>>> Log Message
>>>> 
>>>> Refactor and update portconfigure::get_compiler_fallback
>>>> 
>>>> Separate out list generation into stages for easier updates in the future.
>>>> Use newer clang versions when using libc++ as our default C++ runtime.
>>>> Don't add legacy gcc fallbacks on El Capitan.
>>> 
>>> 
>>> Any particular reason you removed apple-gcc42 and llvm-gcc42 on El Capitan? 
>>> We only just released MacPorts 2.3.4 which finally returned apple-gcc42 and 
>>> llvm-gcc42 to the list of available compilers for Xcode 6 and later 
>>> (r140687). Reverting r141132, apple-gcc42 builds fine for me on 10.11, and 
>>> reverting r141133, llvm-gcc42 builds fine for me with apple-gcc42 on 10.11. 
>>> Are there situations where these compilers don't work correctly because of 
>>> a change in El Capitan?
>> 
>> They don't support C11
>> They don't support C++11
>> They don't support libc++
> 
> None of that has changed since Yosemite.

Yes, and I was quite happy that the compilers failed to work in Yosemite, 
allowing me to mark them as unavailable.  Unfortunately, some life was breathed 
into them again, preventing them from slipping off to their well deserved graev.

>> They've been deprecated for almost 5 years now.
>> I don't want to give the impression that we actually support this legacy 
>> toolchain on modern systems; it's only purpose was to help build ports that 
>> weren't building with clang.
>> If you don't want to drop support for them now, what do you consider a good 
>> time?  I'd prefer to not keep around legacy compilers if they're not 
>> actually needed.  So I guess I'll flip the question to you and ask if 
>> there's any compelling reason why one would still need them on El Cap.  
>> Xcode 7's clang (and indeed macports-clang-3.7) is a much more mature, 
>> robust, and reliable compiler on El Cap than gcc-4.2.
> 
> Nobody's suggesting putting them anywhere but last in the fallback list.
> There are still ports that won't build without them. Refusing to build
> them at all when they do work isn't helpful.

Last I checked, the ports that are still blacklisting clang outright also fail 
to build in general.  I went through all the remaining ports that listed 
*clang* or clang in compiler.blacklist and updated most of them to build with 
clang.  libpar2  was the only one that built that I didn't fix.  The rest 
didn't even build with apple-gcc-4.2.

Are there any ports other than libpar2 that you are aware of that have issues 
when built with clang?

I'll do another audit today and send out a summary.

I'll update base to allow the fallback for now while we discuss.

> Add notes if you want to
> make it crystal clear that nobody should be using these on recent
> systems if they can help it.
> 
> If they break again in future, I doubt anyone will bother fixing them,
> and that's fine.
> 
> - Josh


> On Oct 12, 2015, at 11:40, Jack Howarth <howarth.at.macpo...@gmail.com> wrote:
> 
> In the fink project, the llvm-gcc42 package is kept only to provide a
> compiler which fully supports traditional mode cpp for use with the
> legacy xmkf package.

That's a bit overkill.  fink should look into using tradcpp instead.

> The fink llvm-gcc42 packaging also builds against
> clang with the appropriate patchin

Re: [141211] trunk/dports/finance/libgeier/Portfile

[Jeremy Huddleston Sequoia]

> On Oct 12, 2015, at 18:42, Ryan Schmidt  wrote:
> 
> 
>> On Oct 12, 2015, at 7:12 PM, jerem...@macports.org wrote:
>> 
>> Revision
>> 141211
>> Author
>> jerem...@macports.org
>> Date
>> 2015-10-12 17:12:02 -0700 (Mon, 12 Oct 2015)
>> Log Message
>> 
>> libgeier: Fix build failure and alow universal by using openssl instead of 
>> nss
>> Modified Paths
>> 
>>  • trunk/dports/finance/libgeier/Portfile
> 
>> Diff
>> Modified: trunk/dports/finance/libgeier/Portfile (141210 => 141211)
>> --- trunk/dports/finance/libgeier/Portfile   2015-10-12 23:53:51 UTC (rev 
>> 141210)
>> +++ trunk/dports/finance/libgeier/Portfile   2015-10-13 00:12:02 UTC (rev 
>> 141211)
>> @@ -21,25 +21,14 @@
>> depends_lib-append  port:libxml2 \
>> port:libxslt \
>> port:xmlsec \
>> -port:nss \
>> -port:nspr \
>> +path:lib/libssl.dylib:openssl \
>> port:argp-standalone
>> 
>> -# nss is not universal
>> -universal_variant   no
> 
> libgeiger still can't build universal because of dependency xmlsec which 
> still depends on nss.
> 
> The above changes change the installed files, so the revision needs to be 
> increased.

Revbumps are only required if the port actually built previously.  It was 
failing to build before the change.  Was someone actually able to build it 
before I made the change?



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

Re: [141139] trunk/base/src/port1.0/portchecksum.tcl

[Jeremy Huddleston Sequoia]

Ok, so if the set includes the union of "good" and "specified", we're all happy?

> On Oct 11, 2015, at 13:25, Daniel J. Luke  wrote:
> 
> +1
> 
> If we really want to encourage people to stop using the weak hashes, we could 
> print a warning if any of them are in the output.
> 
>> On Oct 11, 2015, at 4:12 PM, Joshua Root  wrote:
>> How about this:
>> 
>> * If the checksums specified in the Portfile include sha256, just print
>> out the actual values for those checksum types.
>> 
>> * If not, add sha256 to the list when printing out the actual values.
>> 
>> After all there's no harm in using weak hashes in addition to good ones.
>> 
>> - Josh
>> 
>> On 2015-10-12 07:02 , Joshua Root wrote:
>>> Yes, and I seem to remember having this conversation once before... :)
>>> 
>>> On 2015-10-12 05:06 , Daniel J. Luke wrote:
 it’s really useful for the case when upstream publishes a checksum (that’s 
 not one of our default ‘good’ ones) when the output includes the checksums 
 that are in the portfile.
 
> On Oct 11, 2015, at 1:34 PM, jerem...@macports.org wrote:
> Use $default_checksum_types for handy copy/paste output on checksum 
> failure
> 
> This should help adoption of better, more robust hashing algorithms.
> 
> — 
> Daniel J. Luke
>
> ++ 
> | * dl...@geeklair.net * |
>   
> | *-- http://www.geeklair.net -* |
>   
> ++ 
> |   Opinions expressed are mine and do not necessarily   |
>   
> |  reflect the opinions of my employer.  |
>   
> ++
> 
> 
> 
> 



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

Re: [140857] trunk/dports/gnome/libgdata

[Jeremy Huddleston Sequoia]

This resulted in the dylib id changing.  You need to revbump dependents:

Could not open /opt/local/lib/libgdata.19.dylib: Error opening or reading file 
(referenced from /opt/local/lib/grilo-0.2/libgrlyoutube.so)

I did grilo-plugins for you.

--Jeremy

> On Oct 4, 2015, at 12:14, dev...@macports.org wrote:
> 
> Revision
> 140857
> Author
> dev...@macports.org
> Date
> 2015-10-04 12:14:07 -0700 (Sun, 04 Oct 2015)
> Log Message
> 
> libgdata: update to version 3.17.3, use gnome unstable livecheck.
> Modified Paths
> 
>   • trunk/dports/gnome/libgdata/Portfile
> Added Paths
> 
>   • 
> trunk/dports/gnome/libgdata/files/patch-m4-ax_compiler_flags_ldflags.m4.diff
> Removed Paths
> 
>   • trunk/dports/gnome/libgdata/files/patch-gdata-gdata.symbols.diff
> Property Changed
> 
>   • trunk/dports/gnome/libgdata/
> Diff
> 
> Property changes: trunk/dports/gnome/libgdata
> 
> Modified: svn:mergeinfo
> /users/devans/GNOME-3/stable/dports/gnome/libgdata:108269-136044
> /users/devans/GNOME-3/unstable/dports/gnome/libgdata:116416-118154,125521-125568
> /users/rmstonecipher/gnome/libgdata:102363-103172
> + 
> /branches/mld-qt-481/dports/gnome/libgdata:92720,92813,92891,92963,93522,93556,93699,93743,93771-93773,93806,93817-93818,93856
> /users/devans/GNOME-3/stable/dports/gnome/libgdata:108269-140741
> /users/devans/GNOME-3/unstable/dports/gnome/libgdata:116416-118154,125521-125568,136638-140633
> /users/rmstonecipher/gnome/libgdata:102363-103172
> Modified: trunk/dports/gnome/libgdata/Portfile (140856 => 140857)
> 
> --- trunk/dports/gnome/libgdata/Portfile  2015-10-04 19:14:04 UTC (rev 
> 140856)
> +++ trunk/dports/gnome/libgdata/Portfile  2015-10-04 19:14:07 UTC (rev 
> 140857)
> 
> @@ -5,8 +5,7 @@
> 
>  PortGroup   gobject_introspection 1.0
> 
>  
> 
>  namelibgdata
> 
> -version 0.16.1
> -revision1
> 
> +version 0.17.3
> 
>  set branch  [join [lrange [split ${version} .] 0 1] .]
> 
>  description libgdata is a GLib-based library for accessing online 
> service APIs using the \
> 
>  GData protocol --- most notably, Google's services.
> 
> @@ -23,8 +22,8 @@
> 
>  
> 
>  use_xz  yes
> 
>  
> 
> -checksums   rmd160  955b13e6b8b3ecc508fa9891ea35f014e9255c75 \
> -sha256  
> 8740e071ecb2ae0d2a4b9f180d2ae5fdf9dc4c41e7ff9dc7e057f62442800827
> 
> +checksums   rmd160  6dbb946ed0f7867049ee0fb2254f966abcea5223 \
> +sha256  
> ff280b031c50a99ed735c3fa18fbea9ae3e4cc5e3d7dd58ebae09994b01b513b
> 
>  
> 
>  depends_build   port:pkgconfig \
> 
>  port:intltool \
> 
> @@ -45,7 +44,7 @@
> 
>  
> 
>  gobject_introspection yes
> 
>  
> 
> -patchfiles  patch-gdata-gdata.symbols.diff
> 
> +patchfiles  patch-m4-ax_compiler_flags_ldflags.m4.diff
> 
>  
> 
>  # reconfigure using upstream autogen.sh for intltool 0.51 compatibility
> 
>  
> 
> @@ -63,4 +62,4 @@
> 
>  test.runyes
> 
>  test.target check
> 
>  
> 
> -livecheck.type  gnome
> 
> +livecheck.type  gnome-with-unstable
> 
> Deleted: trunk/dports/gnome/libgdata/files/patch-gdata-gdata.symbols.diff 
> (140856 => 140857)
> 
> --- trunk/dports/gnome/libgdata/files/patch-gdata-gdata.symbols.diff  
> 2015-10-04 19:14:04 UTC (rev 140856)
> +++ trunk/dports/gnome/libgdata/files/patch-gdata-gdata.symbols.diff  
> 2015-10-04 19:14:07 UTC (rev 140857)
> 
> @@ -1,11 +0,0 @@
> 
>  gdata/gdata.symbols.orig 2014-09-17 16:22:31.0 -0700
> -+++ gdata/gdata.symbols  2014-09-19 00:22:07.0 -0700
> -@@ -1089,8 +1089,6 @@
> - gdata_freebase_topic_result_get_type
> - gdata_freebase_topic_result_new
> - gdata_freebase_topic_result_dup_object
> --gdata_freebase_result_error_get_type
> --gdata_freebase_result_error_quark
> - gdata_freebase_result_get_type
> - gdata_freebase_result_new
> - gdata_freebase_result_dup_variant
> 
> Copied: 
> trunk/dports/gnome/libgdata/files/patch-m4-ax_compiler_flags_ldflags.m4.diff 
> (from rev 140741, 
> users/devans/GNOME-3/stable/dports/gnome/libgdata/files/patch-m4-ax_compiler_flags_ldflags.m4.diff)
>  (0 => 140857)
> 
> --- 
> trunk/dports/gnome/libgdata/files/patch-m4-ax_compiler_flags_ldflags.m4.diff  
> (rev 0)
> +++ 
> trunk/dports/gnome/libgdata/files/patch-m4-ax_compiler_flags_ldflags.m4.diff  
> 2015-10-04 19:14:07 UTC (rev 140857)
> 
> @@ -0,0 +1,10 @@
> 
> +--- m4/ax_compiler_flags_ldflags.m4.orig 2015-07-11 11:33:59.0 
> -0700
>  m4/ax_compiler_flags_ldflags.m4  2015-07-11 11:34:44.0 -0700
> +@@ -49,7 +49,6 @@
> + 
> + # Base flags
> + AX_APPEND_COMPILE_FLAGS([ dnl
> +--Wl,--no-as-needed dnl
> + $3 dnl
> + ],ax_warn_ldflags_variable,[$ax_compiler_flags_test])
> + 
> 
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> 

Re: Any more changes to merge for 2.3.4?

[Jeremy Huddleston Sequoia]

That is not going to happen any time soon unless you are willing to write up a 
port to provide the as-wrapper as an alternative to cctools.  I don't want the 
MacPorts clang falling back on the Xcode toolchains when -no-integrated-as is 
used.

C.f. the entire thread about reproducible builds...

> On Sep 30, 2015, at 07:05, Jack Howarth  wrote:
> 
> Joshua,
>   One issue which doesn't seem to be addressed yet in the svn
> package set is to make sure that no package forces a dependency on
> cctools when Xcode 7 in installed. IHMO, this is undesirable behavior
> because it regresses the enhanced modern opcode support in the new
> clang-based assembler (which is not to be confused with llvm-as).
> Packages like atlas which currently don't tolerate the new AVX support
> can be downgraded by to SSE3 with a change like...
> 
> http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.9-libcxx/stable/main/finkinfo/sci/atlas-xcode7.patch?revision=1.1=markup
> 
>   Jack
> 
> On Wed, Sep 30, 2015 at 9:09 AM, Joshua Root  wrote:
>> Is there anything else we should get in before tagging 2.3.4?
>> 
>> - Josh
>> ___
>> 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



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

Re: about alternative ports and the build bots

[Jeremy Huddleston Sequoia]

The issue exists in more general form for cases like ffmpeg and ffmpeg-devel 
when the dylib id changes (eg: when bumping it due to binary incompatibility).  
If the user goes and installs ffmpeg-devel, then anything that depends on 
ffmpeg needs to be built from source because the buildbot produces content 
linked against ffmpeg.

I don't think there's really any way around this with MacPorts currently.

> On Sep 28, 2015, at 06:59, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I'd like to bring up something related to alternative ports and the build 
> bots. It concerns my qt5-kde port (submitted on trac), but the principle is 
> more generic.
> 
> In short, consider 2 ports that are supposed to be alternatives like port:foo 
> and port:foo-devel, but that are different enough in where they install 
> libraries that their binary forms are not drop-in replacements, and that 
> cannot of course be installed concurrently. To keep this generic, let's 
> assume there's a port:foo-mac which adheres to a Mac-inspired install layout 
> and port:foo-xdg which adheres to a layout that's compatible with the ones 
> used on Linux and other Unixes. Let's also assume that there as always been a 
> foo PortGroup that takes care of defining variables for the various install 
> locations, and that sets up a path: style dependency on port:foo (or one of 
> its alternatives). This PortGroup has been split into foo-mac, foo-kde 
> PortGroups and a general foo PortGroup that can include the appropriate foo 
> "sub PortGroup" as a function of what the user has installed or a preference 
> declared by a dependent port.
> 
> So when building a port that depends on foo:
> - if foo-xdg is installed and foo.prefer_mac isn't defined, use the foo-xdg 
> PortGroup
> - else if foo-mac is installed and foo.prefer_xdg isn't defined, use the 
> foo-mac PortGroup
> - else if foo.prefer_xdg is defined, use the foo-xdg PortGroup
> - else use the foo-mac PortGroup
> 
> From this it should follow that any port that does not declare a preference 
> will use the foo-mac PortGroup (pulling it in if necessary) unless the user 
> already installed port:foo-xdg .
> 
> If no binary builds existed, this should more or less cover all possible 
> cases. It would be nice to have the option to "prefer the one but can make do 
> with the other too" vs. "require the one over the other" (aborting when the 
> requirement is not met), but if that's even possible it can be a next 
> evolution.
> 
> Binary builds exist however, so something should be done to prevent pulling 
> in a binary build for (against) foo-mac when foo-kde is installed, and 
> vice-versa. I think I have a solution for that, which should work if my 
> assumption is correct that binary packages are built each starting with a 
> virgin MacPorts install, i.e. pulling in only the required dependencies.
> It works like this: the foo-xdg defines a `fooxdg` variant (if it doesn't 
> exist already), and makes it default. That way, any port that "inherits" 
> port:foo-xdg without requesting it specifically will get a (default) variant 
> that exists only on the user's end and not on the build bots, and therefore, 
> `port install somePortDependsOnFoo` will be a request for 
> somePortDependsOnFoo+fooxdg, leading to an install-from-source. On the other 
> hand, a port that prefers/requests foo-xdg will have the +fooxdg variant set 
> as a default also on the buildbots, and thus be available as a binary build 
> against port:foo-xdg .
> 
> The default_variant could be set only when the variant is defined in the 
> PortGroup or when foo.prefer_xdg is set, but I do not currently see why that 
> would be necessary or preferable.
> However, I'm not sure how best to ensure that someone with port:foo-mac 
> installed will not end up installing a binary package that is built against 
> port:foo-xdg , and I think that isn't already ensured. Maybe those ports 
> should simply do a pre-fetch check if foo-xdg is indeed the one installed 
> (via a proc to be provided by the foo-xdg PortGroup)?
> 
> 
> I think this is completely orthogonal to questions about reproducible builds, 
> before anyone mentions that principle :) and I can only hope that this is not 
> "MacPorts doesn't support this". (The real-world implementation of 
> port:foo-xdb, port:qt5-kde, is quite likely to be a requirement for KF5 ports 
> currently in preparation.)
> 
> Thoughts and feedback welcome!
> 
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: libexec vs lib

[Jeremy Huddleston Sequoia]

> On Sep 19, 2015, at 09:16, Andrew L. Moore  wrote:
> 
> Guys,
> Macports appears to install qt5-mac, llvm-3.5 and llvm-3.7 wholesale under 
> libexec.  This is not a traditional destination. Is there a reason for 
> choosing libexec over lib?

lib isn't the right place either.  It's not all library content.  It's actually 
a nested prefix.  libexec was chosen as the base for this separate prefix to be 
most analogous with /usr/libexec/gcc/...

If we want to come up with a standard location for subprefixes (eg: 
${prefix}/opt), I'd be happy to switch to that.

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

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 09:21, Jack Howarth <howarth.at.macpo...@gmail.com> wrote:
> 
>   You really will want to rewrite the llvm37 Portfile to use a cmake
> build.

Not unless we can depend on cmake existing out-of-tree.  If we need to depend 
on port:cmake, that introduces cycles.

--Jeremy

> The openmp 3.7 can be built in-tree using cmake (with the
> sources placed at projects/openmp. Also the default for -fopenmp is
> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
> with...
> 
> --- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
> +++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
> @@ -182,7 +182,7 @@
> set(DEFAULT_SYSROOT "" CACHE PATH
>   "Default  to all compiler invocations for --sysroot=." )
> 
> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>   "Default OpenMP runtime used by -fopenmp.")
> 
> set(CLANG_VENDOR "" CACHE STRING
> 
> In fink, we set the explicit location of the buried libomp.dylib with...
> 
> --- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
> 09:10:45.0 -0400
> +++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
> @@ -6368,12 +6368,18 @@
>options::OPT_fno_openmp, false)) {
> switch (getOpenMPRuntime(getToolChain(), Args)) {
> case OMPRT_OMP:
> +  // Help clang find libomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lomp");
>   break;
> case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lgomp");
>   break;
> case OMPRT_IOMP5:
> +  // Help clang find libiomp5.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-liomp5");
>   break;
> case OMPRT_Unknown:
> @@ -8079,9 +8085,13 @@
> // Also link the particular OpenMP runtimes.
> switch (getOpenMPRuntime(ToolChain, Args)) {
> case OMPRT_OMP:
> + // Help clang find libomp.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lomp");
>   break;
> case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-lgomp");
> 
>   // FIXME: Exclude this for platforms with libgomp that don't require
> @@ -8089,6 +8099,8 @@
>   CmdArgs.push_back("-lrt");
>   break;
> case OMPRT_IOMP5:
> + // Help clang find libiomp5.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>   CmdArgs.push_back("-liomp5");
>   break;
> case OMPRT_Unknown:
> 
> to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
> fat binary of libomp,
> you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386".
>   Jack
> ps Note that the perl-based Makefile build is no longer functional in
> 3.7.0 and is in the process of being completely removed for the 3.8.0
> release.
> 
> On Wed, Sep 2, 2015 at 9:59 PM, Jeremy Huddleston Sequoia
> <jerem...@macports.org> wrote:
>> Looks good to me.  Could you go ahead and push this to svn and also do 
>> similar changes to the llvm-3.8 port for your openmp variant?
>> 
>> Thanks,
>> Jeremy
>> 
>>> On Sep 2, 2015, at 15:34, Eric A. Borisch <ebori...@macports.org> wrote:
>>> 
>>> Would have done a ticket, but with trac down
>>> 
>>> Attached is a patch to update to the released llvm/clang-3.7 (this comments 
>>> out the svn fetch code, removes the default +assertions, and adds checksums)
>>> 
>>> As OpenMP is one of the much discussed items that llvm-3.7 brings to the 
>>> table, I've added a +openmp variant to clang-3.7. This variants pulls in 
>>> port:libomp and sets up clang such that "-fopenmp" will use it by default. 
>>> This makes it much more likely for tools like autoconf to detect OpenMP 
>>> support. (Without the variant, openmp support is still there, but it 
>>> requires -fopenmp=libomp, which isn't in the set of standard "can we do 
>>> OpenMP" flags.) If people are supportive of it, I would suggest making it a 
>>> default variant.
>>&

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 10:32, Sean Farley <s...@macports.org> wrote:
> 
> 
> Jeremy Huddleston Sequoia <jerem...@macports.org> writes:
> 
>>> On Sep 3, 2015, at 09:21, Jack Howarth <howarth.at.macpo...@gmail.com> 
>>> wrote:
>>> 
>>>  You really will want to rewrite the llvm37 Portfile to use a cmake
>>> build.
>> 
>> Not unless we can depend on cmake existing out-of-tree.  If we need to 
>> depend on port:cmake, that introduces cycles.
> 
> 
> How? I only see these as dependencies for cmake:
> 
> $ port rdeps cmake
> The following ports are dependencies of cmake @3.3.1_0:
>  curl
>pkgconfig
>  libiconv
>gperf
>zlib
>  xz
>gettext
>  expat
>  ncurses
>openssl
>curl-ca-bundle
>  perl5
>perl5.16
>  gdbm
>  bzip2
>  libarchive
>libxml2
>lzo2
> 
> I see that libomp depends on cmake but cmake doesn't depend on libomp
> nor llvm so how is it a cycle?

You're not looking at build dependencies.

On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ 
clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its 
C++11 requirement.

--Jeremy



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

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 10:51, Sean Farley <s...@macports.org> wrote:
> 
> 
> Jeremy Huddleston Sequoia <jerem...@macports.org> writes:
> 
>>> On Sep 3, 2015, at 10:32, Sean Farley <s...@macports.org> wrote:
>>> 
>>> 
>>> Jeremy Huddleston Sequoia <jerem...@macports.org> writes:
>>> 
>>>>> On Sep 3, 2015, at 09:21, Jack Howarth <howarth.at.macpo...@gmail.com> 
>>>>> wrote:
>>>>> 
>>>>> You really will want to rewrite the llvm37 Portfile to use a cmake
>>>>> build.
>>>> 
>>>> Not unless we can depend on cmake existing out-of-tree.  If we need to 
>>>> depend on port:cmake, that introduces cycles.
>>> 
>>> 
>>> How? I only see these as dependencies for cmake:
>>> 
>>> $ port rdeps cmake
>>> The following ports are dependencies of cmake @3.3.1_0:
>>> curl
>>>   pkgconfig
>>> libiconv
>>>   gperf
>>>   zlib
>>> xz
>>>   gettext
>>> expat
>>> ncurses
>>>   openssl
>>>   curl-ca-bundle
>>> perl5
>>>   perl5.16
>>> gdbm
>>> bzip2
>>> libarchive
>>>   libxml2
>>>   lzo2
>>> 
>>> I see that libomp depends on cmake but cmake doesn't depend on libomp
>>> nor llvm so how is it a cycle?
>> 
>> You're not looking at build dependencies.
>> 
>> On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ 
>> clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its 
>> C++11 requirement.
> 
> Ah, I see more dependencies now. The only C++11 requirements I see
> though are with the 'gui' variant. So, wouldn't we be able to depend on
> 'cmake -gui' or am I missing something else?

We don't have support for expressing that well in base, so I'm just very 
conservative about bringing in any dependencies into the toolchain.  I'm happy 
to add non-default variants to llvm and clang, but adding a new dependency 
(especially one that can bring in both perl and python) is a bit scary. =/

Note that building a newer toolchain on Tiger is a bit of a challenge, and we 
ended up using a +bootstrap variant in the apple-gcc42 port to help out with 
that, but I'd prefer not to have to resort to such tactics for more recent OS 
versions.  Specifically, I'd prefer to not have to tell people to install cmake 
-gui, then clang-3.7, then cmake with their desired variants.

I guess it would be ok to have such users use clang-3.4 to build cmake to build 
clang-3.8, but that's also sub-optimal.  I'm certainly not against it, though, 
since it is only an issue for older OS versions.

If you (or someone else) wants to take a shot at this, please do so.  I think 
at minimum, we'd need to:
a) Update the llvm-3.8 port with a dependency on port:cmake and relevant 
other changes
b-1) Update the cmake port to check if clang-3.8 is installed and blacklist 
it if it isn't
b-2) Come up with a better way (in base) of ensuring that a compiler is not 
used to satisfy its own dependencies if it is not already installed

--Jeremy



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

Re: llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

Looks good to me.  Could you go ahead and push this to svn and also do similar 
changes to the llvm-3.8 port for your openmp variant?

Thanks,
Jeremy

> On Sep 2, 2015, at 15:34, Eric A. Borisch  wrote:
> 
> Would have done a ticket, but with trac down
> 
> Attached is a patch to update to the released llvm/clang-3.7 (this comments 
> out the svn fetch code, removes the default +assertions, and adds checksums)
> 
> As OpenMP is one of the much discussed items that llvm-3.7 brings to the 
> table, I've added a +openmp variant to clang-3.7. This variants pulls in 
> port:libomp and sets up clang such that "-fopenmp" will use it by default. 
> This makes it much more likely for tools like autoconf to detect OpenMP 
> support. (Without the variant, openmp support is still there, but it requires 
> -fopenmp=libomp, which isn't in the set of standard "can we do OpenMP" 
> flags.) If people are supportive of it, I would suggest making it a default 
> variant.
> 
> Note that -I/opt/local/include and -L/opt/local/lib (assuming standard 
> MacPorts install location) are required with -fopenmp for things to work and 
> not complain about missing omp.h or -lomp.
> 
> If there is someone more familiar with clang/llvm building (of the tools 
> themselves), it might be interesting to consider baking in those -I/-L flags 
> (or move the libomp include/lib install directories so they only have omp.h 
> and the libomp*.dylib files and using those) so -fopenmp would "just work." 
> (Without the extra -I and -L)... Let me know if there is interest and I can 
> rework the libomp port to support this.
> 
> Thanks,
>   - Eric
> 

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

Re: Ncurses 6

[Jeremy Huddleston Sequoia]

mysql ports are missing the dependency and revbump.  I don't want to add it 
myseslf since the dep may be variant-dependent.

$ port contents mysql55 | egrep '(bin|dylib)' | while read f ; do otool -L $f | 
grep -q ncurses  echo $f; done
/opt/local/lib/mysql55/bin/mysql
/opt/local/lib/mysql55/bin/mysql_embedded


 On Aug 17, 2015, at 18:07, Joshua Root j...@macports.org wrote:
 
 I'm just about to update ncurses to 6.0. The ABI has changed, so I'm rev
 bumping all declared dependents. There are no incompatible API changes,
 so most ports should just work. But keep an eye out for ports that link
 with ncurses without declaring a dependency, or do anything along the
 lines of assuming that ncurses will always be version 5.x when checking
 for it.
 
 - Josh
 ___
 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

libressl in MacPorts

[Jeremy Huddleston Sequoia]

Hey guys,

I just wanted to drop a line letting you know that I added libressl yesterday.  
All ports have been updated to accept libressl as a dependency instead of 
openssl where applicable.  As libressl aims to be API compatible with OpenSSL, 
many ports just work or have already been updated by upstream to address 
libressl changes.  This, however, does not mean that they will all work.  If 
you come across any build failures in your ports, I suggest you take a look at 
upstream, FreeBSD, or OpenBSD to see if a patch already exists.  If not, 
FreeBSD has a pretty nice wiki tracking the common issues and their appropriate 
resolutions:

https://wiki.freebsd.org/LibreSSL

--Jeremy



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

Re: libressl maintainer

[Jeremy Huddleston Sequoia]

Oops.  Thanks for catching that.

 On Aug 7, 2015, at 16:00, Mihai Moldovan io...@macports.org wrote:
 
 Hi Jeremy
 
 If you do not plan to maintain libressl, please set it to nomaintainer,
 otherwise add yourself to the maintainer list and openmaintainer.
 
 Openmaintainer should never be the only maintainer - that's what nomaintainer 
 is
 for.
 
 
 
 Mihai
 

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

Re: [MacPorts] #48173: Lion buildbot builder: No space left on device

[Jeremy Huddleston Sequoia]

Yeah, we still have a bunch of users staying on Snow Leopard because of various 
reasons.  Lion was the last OS that supported EFI32, so there are some users 
who can't upgrade past Lion.

That being said, you can probably netboot to a newer OS image and use Disk 
Utility there to resize it.  Another way of doing that if the netboot approach 
fails is to shutdown the VM and add its disk to another VM (selecting shared 
when adding it).  Then resize it in the other VM and remove it (selecting 
don't delete when removing).


 On Jul 17, 2015, at 13:56, Keith Dart keith_d...@apple.com wrote:
 
 I did look at it and there seems to be 20GB free. That still might not be 
 enough for some builds, I guess. I did enlarge the virtual disk by another 20 
 GB. But so far I’m been unable to resize the file system in the guest. I 
 tried the disk utility and it seems to see the extra size and let me expand 
 it by dragging a pull handle. Then I apply it, and the log entries claim it 
 was successful. However, it is not actually resized.  
 
 So I guess another option is to boot into another image, such as net booting. 
 Then try to resize the offline partition.  But there seems to be no way to do 
 that with these VMs. So right now I’m stuck at this point. Any suggestions?
 
 BTW, I’m curious, does anybody still use these older OS X?  
 
 
 On Jul 14, 2015, at 21:37, MacPorts nore...@macports.org wrote:
 
 #48173: Lion buildbot builder: No space left on device
 -+-
 Reporter:  ryandesign@…|  Owner:  admin@…
 Type:  defect  | Status:  new
 Priority:  Normal  |  Milestone:
 Component:  server/hosting  |Version:
 Resolution:  |   Keywords:
 Port:  |
 -+-
 Changes (by ryandesign@…):
 
 * cc: jeremyhu@… (added)
 
 
 Comment:
 
 This problem did not appear again for a few weeks and I thought maybe it
 was mysteriously resolved (as the disk space shortage on the packages
 server was mysteriously resolved in #48174), but Jeremy H reported that
 the issue [https://lists.macosforge.org/pipermail/macports-
 dev/2015-July/031072.html resurfaced Sunday] when building a large port
 (clang-3.7). Keith, can you please respond to this ticket in some way?
 Thanks.
 
 -- 
 Ticket URL: https://trac.macports.org/ticket/48173#comment:1
 MacPorts https://www.macports.org/
 Ports system for OS X
 



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

Lion buildbot is out of space

[Jeremy Huddleston Sequoia]

error: error opening 
'/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/tools/extra/clang-tidy/readability/Release+Debug+Asserts/ContainerSizeEmptyCheck.d.tmp':
 Error opening output file 
'/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/tools/extra/clang-tidy/readability/Release+Debug+Asserts/ContainerSizeEmptyCheck.d.tmp':
 No space left on device
fatal error: error in backend: IO failure on output stream.
error: error opening 
'/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/tools/extra/clang-tidy/readability/Release+Debug+Asserts/ReadabilityTidyModule.d.tmp':
 Error opening output file 
'/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/tools/extra/clang-tidy/readability/Release+Debug+Asserts/ReadabilityTidyModule.d.tmp':
 No space left on device
fatal error: error in backend: IO failure on output stream.
rm: 
/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/tools/extra/clang-tidy/readability/Release+Debug+Asserts/ReadabilityTidyModule.d.tmp:
 rm: No such file or directory
/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/clang-3.7/work/build/tools/clang/tools/extra/clang-tidy/readability/Release+Debug+Asserts/ContainerSizeEmptyCheck.d.tmp:
 No such file or directory



 On Jul 12, 2015, at 23:03, nore...@macports.org wrote:
 
 The Buildbot has detected a failed build on builder buildports-lion-x86_64 
 while building MacPorts.
 Full details are available at:
 http://build.macports.org/builders/buildports-lion-x86_64/builds/29860
 
 Buildbot URL: http://build.macports.org/
 
 Buildslave for this Build: apple-lion-x86_64-ports
 
 Build Reason: scheduler
 Build Source Stamp: [branch trunk] 138590
 Blamelist: jerem...@macports.org
 
 BUILD FAILED: failed status
 
 sincerely,
 -The Buildbot
 
 
 

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

Re: [135541] trunk/dports/audio/pulseaudio

[Jeremy Huddleston Sequoia]

Yeha, I agree there's not much reason to use pulseaudio because CoreAudio 
basically covers all you would need.  I just noticed the broken linkage and 
mentioned it.  If VLC dropped the pulseaudio dependeny, then perhaps VLC-devel 
should be updated as well.

 On Apr 27, 2015, at 00:21, René JV Bertin rjvber...@gmail.com wrote:
 
 Is there any reason to build the PA bits of VLC, given that VLC has native 
 audio support? I removed the dependency from my own VLC port version, and 
 everything works just fine.
 
 I asked elsewhere about pulseaudio on OS X, IIRC even on a PA bug tracker or 
 forum, and was told there's very little reason to use it on OS X. Which makes 
 sense, IMHO. 
 
 R
 
 On 26 Apr 2015, at 22:34, Jeremy Sequoia jerem...@apple.com wrote:
 
 I noticed this issue because of broken linkage in VLC-devel.
 
 Sent from my iPhone...
 
 On Apr 26, 2015, at 13:15, David Evans dev...@macports.org wrote:
 
 On 4/26/15 11:39 AM, Jeremy Huddleston Sequoia wrote:
 The new portaudio breaks dependents.
 
 pulseaudio now installs ${prefix}/lib/pulseaudio/libpulsecommon-6.0.dylib 
 instead of ${prefix}/lib/pulseaudio/libpulsecommon-5.0.dylib
 
 Are those two files really ABI incompatible, or is this yet another case 
 of upstream developers failing to version their binaries correctly?
 
 Either way, please revbump all dependents.
 
 Thanks,
 Jeremy
 As far as I can see, it's not required.  I tested against all dependents 
 and they are all linking with
 
 /opt/local/lib/libpulse.0.dylib
 
 not
 
 /opt/local/lib/libpulsecore-6.0.dylib
 
 Dave
 
 
 
 
 ___
 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
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: Port variant libcaca -x11 still pulls in xorg deps...

[Jeremy Huddleston Sequoia]

 On Apr 21, 2015, at 23:53, Marko Käning mk-macpo...@techno.ms wrote:
 
 Hi Jeremy,
 
 thanks for your helpful response.
 
 
 On 22 Apr 2015, at 00:20 , Jeremy Huddleston Sequoia jerem...@macports.org 
 wrote:
 imlib2's configure script looks like it has a way to disable X11 support, 
 but the resulting dylib is still linked against X11 libs.  Here's a patch to 
 get you started:
 
 imlib2.x11_variant.patch
 
 Based on that I have filed a ticket for further review [1]. It builds fine 
 here.

Yes, but unfortunately, it still links against libX11 and libXext despite not 
needing them.  I suspect this is an opportunistic linkage because the libraries 
aren't actually used by anything:

~/src/macports/dports/graphics/imlib2 $ otool -L 
work/destroot/opt/local/lib/libImlib2.dylib 
work/destroot/opt/local/lib/libImlib2.dylib:
/opt/local/lib/libImlib2.1.dylib (compatibility version 6.0.0, current 
version 6.6.0)
/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current 
version 11.0.0)
/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current 
version 10.0.0)
/opt/local/lib/libfreetype.6.dylib (compatibility version 18.0.0, 
current version 18.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)

~/src/macports/dports/graphics/imlib2 $ nm -m 
work/destroot/opt/local/lib/libImlib2.dylib | grep Xext

~/src/macports/dports/graphics/imlib2 $ nm -m 
work/destroot/opt/local/lib/libImlib2.dylib | grep X11


 freeglut (and libGLU) are GLX ports.  freeglut cannot build a GLUT.framework 
 based on OpenGL.framework.  If you need to use GLUT/CGL, don't use the 
 freeglut port.
 
 Well, I am not sure what to do about this in libcaca, as all I did was moving 
 things
 from the port into the default x11 variant, so changing nothing effectively 
 for x11.
 
 As I am not an X11 Xpert, I am unsure about whether a non-X11 port 
 would/could build
 with or w/o GLUT/CGL.

Well presumably it wants to render something to the window server.  If that 
window server is X11, then it needs to use GLX and would use mesa and freeglut 
for GLUT.  If that window server is OS X's WindowServer, then it needs to use 
OpenGL.framework and GLUT.framework.

 Wondering whether there is any connection between the above and 
 gstreamer1-gst-plugins-good
 failing on me [2]...

Unrelated.

 
 Greets,
 Marko
 
 
 
 [1] https://trac.macports.org/ticket/47532
 [2] https://trac.macports.org/ticket/47525



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

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On Apr 22, 2015, at 10:30, Lawrence Velázquez lar...@macports.org wrote:
 
 On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com 
 wrote:
 
 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 
 Yes, that would be adding a new dependency on libgcc and FSF GCC for all 
 C++ ports. But so does using libc++ on 10.6. Implicitly at least. 
 Fortunately that doesn't add dependencies on 10.7 and higher.
 
 For specific ports, yes. In general, muniversal might take of that. But it 
 doesn't make a lot of sense to change our ports base to muniversal, if we 
 can salvage the current state by using clang. Which implies libc++. Gotcha.
 
 What does muniversal have to do with anything?
 
 I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing 
 as a hacky substitute for a proper GCC driver-driver.

Ah, clever.  I see what you mean, but yeah, that would require more extensive 
use of muniversal which is more of a hack in my mind than a proper solution. =/

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



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

Re: GCC driver-driver [was: Re: standard way to require c++11?]

[Jeremy Huddleston Sequoia]

 On Apr 22, 2015, at 11:23, Mihai Moldovan io...@macports.org wrote:
 
 On 22.04.2015 07:39 PM, Jeremy Huddleston Sequoia wrote: 
 On Apr 22, 2015, at 10:30, Lawrence Velázquez lar...@macports.org wrote:
 
 On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com 
 wrote:
 
 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 [...]
 For specific ports, yes. In general, muniversal might take of that. But 
 it doesn't make a lot of sense to change our ports base to muniversal, if 
 we can salvage the current state by using clang. Which implies libc++. 
 Gotcha.
 
 What does muniversal have to do with anything?
 
 I think Mihai is thinking about using the portgroup's automatic lipo(1)-ing 
 as a hacky substitute for a proper GCC driver-driver.
 
 Yep, thanks Larry.
 
 
 Ah, clever.  I see what you mean, but yeah, that would require more 
 extensive use of muniversal which is more of a hack in my mind than a proper 
 solution. =/
 
 You're right. The proper solution would be to add the old driver-driver back 
 to FSF GCC and get it upstreamed, instead of relying even more on muniversal.
 
 Personally, I do not wish to do so, for multiple reasons.
 
 First, a compiler is a somewhat delicate matter and I do not think I've got 
 experience to get it right. I don't want to completely break (or break in 
 subtle ways) FSF GCC on OS X.
 
 Next, there's this copyright-license issue. While only taking driver-driver 
 from GCC 4.2 and backporting it to at least the newest GCC 5 version might 
 technically not be too difficult (although it probably requires 
 re-implementation in C++?), Apple would still be the original copyright 
 holder on that code and as such can decide under what license to release it. 
 Given they don't want to do that on a GPL-3 basis, only a complete rewrite 
 (for whatever that means *exactly*) would give a contributor the right to 
 claim copyright and determine the license.

That's not how it works.

1) It wouldn't be backporting because it's not going backwards ;)

2) Copyright and license are different issues.  It doesn't matter that Apple 
holds the copyright.

3) The driver-driver is GPLv2+ (look at driverdriver.c in the apple-gcc42 
port), so it's perfectly usable with gcc5.

 Even in a complete rewrite case, I'd be concerned with legal problems 
 because the general concept of a GCC driver-driver was their idea. Given that 
 we'd want the new driver-driver to behave like the 4.2 one, there 
 inadvertently will be similarities.

You cannot copyright ideas.  That is what patents are for.

 On the other hand, maybe Apple doesn't care and would indeed be happy to see 
 GCC a little bit better supported on their platform. This is pure speculation.

I don't really care about gcc, and I doubt many other at Apple do either.  
We've moved on to clang years ago and don't give gcc much thought.

 Does anyone here have:
  - a clear understanding of the legal matter?

I am not a lawyer, so I cannot give advise, but I am confident enough in my own 
understanding to act.

  - experience with writing robust code and maybe even a little bit of 
 knowledge of GCC's internals (likely helpful)?

yes

  - enough time to backport/implement this?

No, but it should be fairly straight forward, especially if you only care about 
supporting i386/x86_64 since that only requires the single intel CTARGET gcc.  
If you want to support ppc, that will be more problematic because you'll need 
to build a ppc gcc and an intel gcc.  Look at how hacky the build_gcc script is 
in the apple-gcc42 port.

  - confidence a backport will be accepted by the GCC project?

It isn't something FSF is interested in.  They haven't cared for the past 10 
years, so I doubt they'd start caring now.  It also doesn't really fit the gcc 
model.

 It's not required to meet all points. Even one would be good enough. This can 
 be a team effort if needed. The GCC Strike Force![0]
 
 On OS X, having driver-driver again with -arch support would certainly be a 
 very welcome improvement to FSF GCC.[1]
 
 
 
 Mihai
 
 [0] joke on https://wiki.debian.org/XStrikeForce (which itself it not a joke 
 but a great thing for Debian.)
 [1] This would only be useful for MacPorts on recent OS X releases if 
 -stdlib=libc++ would make GCC not link to its own libstdc++ at all. I don't 
 know if that's the case.
 
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote:
 
 I don't know any port that fails to build with libstdc++ but is
 happy with libc++ offhand.
 llvm-3.7 and webkit-gtk are two such ports that I can point to off
 the top of my head.
 
 By libstdc++ I am of course referring to the *system* libstdc++. I
 apologize if that was not clear.
 
 I was talking about explicitly needing libc++, not C++11 support. I assume 
 webkit-gtk and llvm-3.7 only need libc++ by extension because they are using 
 C++11 features. Naturally, system libstdc++ won't cut it for these, but 
 there's no immediate reason why they wouldn't in theory compile with a more 
 recent libstdc++.

Yes, but that's not a supported configuration, and I don't plan on putting any 
effort into trying to support that.

Note that pretty much *ALL* of MacPorts C++ ports need to be compiled using the 
same C++ runtime.


 Yes, but then you'd need to use the FSF GCC compilers from MacPorts
 to build all of your C++ ports in order for them to interoperate, and
 those ports would all have a new dependency on the libgcc port.
 
 Furthermore, nobody has bothered to update the gcc ports to use the
 Apple gcc driver driver, so the use of multiple -arch options pretty
 much blocks +universal which is a big issue for ports like wine that
 have heavy dependencies and are i386.
 
 Yes, that would be adding a new dependency on libgcc and FSF GCC for all C++ 
 ports. But so does using libc++ on 10.6.

But the libc++ runtime that we install on 10.6 is signifigantly different in 
installation method than the libstdc++ runtime that is installed by libgcc.  It 
is designed to be compatible with future OS versions.  The port just installs a 
root, and activation installs the root.

 Implicitly at least. Fortunately that doesn't add dependencies on 10.7 and 
 higher.
 
 For specific ports, yes. In general, muniversal might take of that. But it 
 doesn't make a lot of sense to change our ports base to muniversal, if we can 
 salvage the current state by using clang. Which implies libc++. Gotcha.

What does muniversal have to do with anything?


 On 15.04.2015 10:45 AM, Mojca Miklavec wrote:
 On Wed, Apr 15, 2015 at 9:42 AM, Mihai Moldovan wrote:
 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Because the above is completely entirely true.  You can have
 multiple versions of C++ runtimes in the same process (even
 libc++ and libstdc++).  The issue arrises when you try to pass
 objects between them.  For example, assume libA links libstdc++
 and libB links another copy of libstdc++ as well as libA.  If
 libA exports C++ API that libB consumes, then it will be
 interacting with them through the wrong runtime.
 
 Re-iterating: is this not the case for multiple copies of libc++?
 
 I don't know enough to answer, but at the moment we don't have
 multiple copies of libc++ anywhere. (Yet. I'm not sure what C++1z
 will bring.)
 
 On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 It is certainly be the case for multiple copies of the libc++
 runtime.  But we're not dealing with multiple copies of libc++.
 However, you are considering multiple copies of libstdc++.
 
 How would you end up with two different versions of libc++?
 
 Yes, I was explicitly thinking of C++1z support, which would (as far as I can 
 tell) potentially lead to multiple copies of libc++.

Why would that potentially lead to multiple copies of libc++?

 Ok, so that's a problem. Not an immediate one, but maybe coming up some time 
 later. I realize this is slightly off-topic for *this thread*, but I'd like 
 to understand when and why this is a problem in general (multiple copies of 
 some C++ runtime.)
 I haven't yet understood it completely. Maybe I'm too stupid to do so in 
 general, but I'm still very fuzzy on that aspect.

Each runtime manages its internal data structures independently of the other.  
If you allocate an object in one runtime and release it in another, you may 
mess up accounting or worse because the second runtime does not own the memory 
of the object you are trying to free.

 On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 Do you have evidence of any such issues? If so, that is a bug that
 should be filed. If you notice, our headers are heavily annotated
 with '#ifdef __BLOCKS__' around such cases.
 
 No. No hard evidence as such. I can only remember seeing this happen before 
 with... the wine ports IIRC? That's why we blacklisted FSF GCC on the wine* 
 ports quite a while ago.

If so, it's a bug and deserves a radar.


 On 15.04.2015 12:55 PM, Jeremy Huddleston Sequoia wrote:
 What the system libraries link against is irrelevant.  It is the
 interfaces provided by the system libraries that matters.
 
 So... uhm, to know if things could potentially go awry, I'd need to check the 
 API if functions take C++ objects directly and guess what these functions 
 might do with the objects?

You could just dump global symbols and see if any of them

Re: Port variant libcaca -x11 still pulls in xorg deps...

[Jeremy Huddleston Sequoia]

imlib2's configure script looks like it has a way to disable X11 support, but 
the resulting dylib is still linked against X11 libs.  Here's a patch to get 
you started:



imlib2.x11_variant.patch
Description: Binary data


freeglut (and libGLU) are GLX ports.  freeglut cannot build a GLUT.framework 
based on OpenGL.framework.  If you need to use GLUT/CGL, don't use the freeglut 
port.

 On Apr 21, 2015, at 01:01, Marko Käning mk-macpo...@techno.ms wrote:
 
 Hi Jeremy,
 
 this pulls in xorg:
 ---
 $ sudo port install libcaca -x11
 ---  Computing dependencies for libcaca
 ---  Dependencies to be installed: freeglut libGLU mesa xorg-dri2proto 
 xorg-glproto xorg-libXdamage xorg-damageproto xorg-libXxf86vm 
 xorg-xf86vidmodeproto imlib2 libid3tag
 ---
 
 because of imlib2 and free glut - due to missing x11 variants:
 ---
 $ port variants imlib2 freeglut
 imlib2 has the variants:
   universal: Build for multiple architectures
 freeglut has the variants:
   debug: Enable debug binaries
   universal: Build for multiple architectures
 ---
 
 Any ideas how to fix this?
 
 Greets,
 Marko
 
 
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 Yes, I actually have libc++ on all of my SL+ machines except a couple
 VMs I keep around for testing the default configuration.  IMO, it
 seems far easier to live on libc++ on SL than libstdc++ because so 
 many ports these days require it.
 
 What are they actually requiring? libc++ or C++11?

They are requiring C++11 which by extension means libc++ in our current 
situation.

 I don't know any port
 that fails to build with libstdc++ but is happy with libc++ offhand.

llvm-3.7 and webkit-gtk are two such ports that I can point to off the top of 
my head.

By libstdc++ I am of course referring to the *system* libstdc++.  I apologize 
if that was not clear.

 If someone on = 10.8 set libc++ globally... tough luck. He'll get 
 an error when trying to install the port.
 
 Which is stupid. Users would set libc++ globally precisely for the 
 reason you are trying to address: to avoid issues with the lack of 
 C++11 support in libstdc++. And then you are ruling out exactly the 
 users who care about C++11 most.
 
 It's not stupid if you consider my point that libstdc++ is well able to
 compile C++11 code if using the FSF GCC in MacPorts.

Yes, but then you'd need to use the FSF GCC compilers from MacPorts to build 
all of your C++ ports in order for them to interoperate, and those ports would 
all have a new dependency on the libgcc port.

Furthermore, nobody has bothered to update the gcc ports to use the Apple gcc 
driver driver, so the use of multiple -arch options pretty much blocks 
+universal which is a big issue for ports like wine that have heavy 
dependencies and are i386.

 That will leave the
 problem if choking on Apple's headers that make use of their Blocks
 extension, though.

Do you have evidence of any such issues?  If so, that is a bug that should be 
filed.  If you notice, our headers are heavily annotated with '#ifdef 
__BLOCKS__' around such cases.

 (Which is practically all Cocoa/Carbon stuff, I
 guess?) For that reason (and +universal), clang + libc++ are indeed
 the superior choice. I agree. There are problems with that approach as
 well, though. More to that later in this message...
 
 
 But given that, in the case of hardcoding configure.cxx_stdlib to 
 another C++ runtime than the autodetected/default value, the 
 selected C++ runtime not matching the system C++ runtime and this 
 potentially leading to a variety of subtle to not so subtle bugs, 
 erroring out looked like the best thing to do.
 
 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 What do you mean by the system runtime?  There is no system 
 runtime.  There are two runtimes available on the system, an ancient
 libstdc++ kept around for binary compatibility, and a more modern
 libc++.
 
 With system runtime, I mean the runtime that gets linked by Apple's
 libraries.

What the system libraries link against is irrelevant.  It is the interfaces 
provided by the system libraries that matters.

 For instance:
 
 /usr/lib/libobjc.dylib:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
 version 228.0.0)
/usr/lib/libauto.dylib (compatibility version 1.0.0, current
 version 1.0.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current
 version 48.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
 version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1197.1.1)
 
 Anything that links against -lobjc will also pull-in the system
 runtime libc++.

libobjc is a *client* of libc++.  It does not expose any C++ interfaces to its 
clients.  As I mentioned in my earlier response, it is perfectly valid to have 
any number of various C++ runtimes in the same process so long as they are 
isolated from eachother.

 This is a problem, because we cannot provide an libobjc
 alternative in MacPorts, so you may end up with two different versions
 of libc++ instead. Is that any better?

How would you end up with two different versions of libc++?

 On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
 To be fair, I did most of the work in MacPorts only after extensive 
 testing of the configuration and transition by Apple in Mountain Lion
 (or maybe it was Mavericks).  On newer OSX versions, we have an added
 benefit of having libstdc++ on top of libc++abi.  We don't have that
 benefit on SL, but other than that, installing the libcxx port on SL
 gets you a pretty modern and well tested C++ runtime that is forwards
 compatible with the system libc++ on Lion and later.
 
 What does mean forward compatible here? Does it mean that programs
 linked against libc++ will continue to work if you upgrade libc++ (which
 is AFAIK also the case with libstdc++), or does it mean that you can mix
 multiple libc++ versions in the same process? If I read port info
 libcxx correctly, the latter case doesn't work even with libc++.

It means that if you use 'clang++-mp-3.4 --stdlib

Re: standard way to require c++11?

[Jeremy Huddleston Sequoia]

 On Apr 14, 2015, at 00:11, Mojca Miklavec mo...@macports.org wrote:
 
 On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
 On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
 On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote:
 Could something like that be added to the compiler_blacklist
 PortGroup? I believe that pure C++11 projects need consistent handling
 and it would be very handy to allow a keyword like compiler.c++11 or
 compiler.something c++11 to replace all of the logic above inside
 a port.
 
 Yes, I should make that a PortGroup, iff it turns out to be good enough
 to be one.
 
 In my opinion this could/should be part of compiler_blacklist. No real
 need for a separate PortGroup.
 
 I don't fully understand that part. What if someone sets libc++
 globally? And: won't that pull in libstdc++ from gcc?
 
 = 10.9: libstdc++? error
 = 10.9: libc++? continue
 
 = 10.8: libstdc++? continue
 = 10.8: libc++? error
 
 This by itself is not pulling in anything yet. What I wanted to express
 is that I assume using libstdc++ on = 10.9 an error and using libc++ on
 = 10.8 an error.
 
 While I do understand 10.9: libstdc++? error, I disagree with =
 10.8: libc++? error for at least two reasons:
 - A bunch of my ports explicitly switch to libc++ (just because they need 
 C++11)
 - Users can set to use libc++ globally
 
 If someone on = 10.8 set libc++ globally... tough luck. He'll get an
 error when trying to install the port.
 
 Which is stupid. Users would set libc++ globally precisely for the
 reason you are trying to address: to avoid issues with the lack of
 C++11 support in libstdc++. And then you are ruling out exactly the
 users who care about C++11 most.

Yes, I actually have libc++ on all of my SL+ machines except a couple VMs I 
keep around for testing the default configuration.  IMO, it seems far easier to 
live on libc++ on SL than libstdc++ because so many ports these days require it.

 But given that, in the case of
 hardcoding configure.cxx_stdlib to another C++ runtime than the
 autodetected/default value, the selected C++ runtime not matching the
 system C++ runtime and this potentially leading to a variety of subtle
 to not so subtle bugs, erroring out looked like the best thing to do.

What do you mean by the system runtime?  There is no system runtime.  There 
are two runtimes available on the system, an ancient libstdc++ kept around for 
binary compatibility, and a more modern libc++.

 Jeremy did extensive testing of that configuration and I'm running a
 copy of MacPorts with those changes as well. I hardly experienced any
 problems (other than initial build failures that had to be polished
 out every now and then). I believe that this should become the default
 setting in not too distant future if we want to keep MacPorts working
 on older systems.

To be fair, I did most of the work in MacPorts only after extensive testing of 
the configuration and transition by Apple in Mountain Lion (or maybe it was 
Mavericks).  On newer OSX versions, we have an added benefit of having 
libstdc++ on top of libc++abi.  We don't have that benefit on SL, but other 
than that, installing the libcxx port on SL gets you a pretty modern and well 
tested C++ runtime that is forwards compatible with the system libc++ on Lion 
and later.

 No, libstdc++ is explicitly designed to allow multiple, incompatible
 libstdc++ version being in use at the same time.

I think you misunderstand.  This is not entirely true.

 Why do people report problems then?

Because the above is completely entirely true.  You can have multiple versions 
of C++ runtimes in the same process (even libc++ and libstdc++).  The issue 
arrises when you try to pass objects between them.  For example, assume libA 
links libstdc++ and libB links another copy of libstdc++ as well as libA.  If 
libA exports C++ API that libB consumes, then it will be interacting with them 
through the wrong runtime.

 In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
 -stdlib=libstdc++ chokes on #include type_traits.

Yeah.  That's because C++11 isn't supported by libstdc++ on SL.

 I would suspect some misconfiguration. I successfully compiled many
 C++11 projects with mp-clang-3.4 (and libc++ of course).
 
 On OS X lower than 10.9? I can take out my VM for a test spin tonight
 and see if I can reproduce the issue (as a minimal testcase without
 MacPorts.)

See http://trac.macports.org/wiki/LibcxxOnOlderSystems

 Maybe I didn't express it properly (or maybe I didn't read your
 statement carefully enough in the first place). Yes, you can compile
 #include type_traits on  10.9 with clang++-mp-3.4, but not with
 the system libstdc++ and I'm not sure how you would compile against
 libstdc++ as shipped by libgcc/gcc-4.9. But the idea is that you *can*
 compile that if you use libc++. My main point was that there should be
 no need to blacklist clang.
 
 cat test.cpp
 #include type_traits
 
 int main()
 {
 return 0;
 }
 
 clang++-mp-3.5 test.cpp -o test
 

Re: [134510] dports/x11/freeglut

[Jeremy Huddleston Sequoia]

Damnit, thanks.  I just checked that the dylib id didn't change and didn't 
notice they messed up the versioning.

This doesn't require a bump of dependents.  It just requires fixing the 
versioning in freeglut.  I'll set the current version to 13.0.0 and the 
compatibility version to 1.0.0.

--Jeremy

 On Mar 29, 2015, at 16:02, Jack Howarth howarth.at.macpo...@gmail.com wrote:
 
 Jeremy,
   The situation with freeglut 3.0.0 is described in
 http://sourceforge.net/p/freeglut/bugs/51/ and
 http://sourceforge.net/p/freeglut/bugs/213/. Back in 2004, I filed the
 first bug about the compatibility version being set too high on darwin
 and it was ignored. This issue came back to bit us when upstream
 switched the build to use cmake as that doesn't allow the
 compatibility version to be manually set. Thus the freeglut 3.0.0
 release ends up lowering the compatibility version to a number
 sensible in the cmake build mechanism.
   In fink, we took the approach of creating a new freeglut2
 package and stored the shared library in a buried directory. This
 allows legacy binaries (built against the old freeglut compatibility
 version) to retain access to the library from the freeglut-shlibs
 split-off package and binaries built against the new freeglut2 package
 to use the buried shared library from a freeglut2-shlibs split-off
 package. The development headers and library symlinks are stored in
 freeglut and freeglut2 packages which conflicts/replaces each other.
   I'm not sure how you will want to handle this in MacPorts due
 to the limitations of the packaging mechanism, You may need to simply
 rebuild everything against the new freeglut with the 'regressed'
 compatibility version.
Jack
 ps The upstream developer decided to take the hit on darwin with this
 breakage with the view that going forward the version/compatibility
 numbering is now coherent.
 
 On Sun, Mar 29, 2015 at 5:01 PM, petr 9...@ingv.it wrote:
 
 
 r134510 | jerem...@macports.org | 2015-03-27 22:12:03 +0100 (Fri, 27 Mar 
 2015) | 2 lines
 
 freeglut: Bump to 3.0.0
 
 
 
 Jeremy,
 this version bump requires also a revision bump of the lib dependencies.
 Cheers,
 ~petr
 
 This is what I observed after upgrade:
 
 ---  Cleaning freeglut
 ---  Removing work directory for freeglut
 ---  Updating database of binaries
 ---  Scanning binaries for linking errors
 Incompatible library version: /opt/local/bin/xterra requires version 13.0.0 
 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaclock requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacademo requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacafire requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaplay requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaserver requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaview requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/img2txt requires version 13.0.0 
 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/lib/libcaca++.0.dylib requires 
 version 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 
 3.0.0
 Incompatible library version: /opt/local/lib/libcaca.0.dylib requires 
 version 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 
 3.0.0
 ---  Found 10 broken file(s), matching files to ports
 ---  Found 2 broken port(s), determining rebuild order
 ---  Rebuilding in order
 terra @0.7
 libcaca @0.99.beta19 +x11
 
 
 
 
 ___
 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

Re: [134510] dports/x11/freeglut

[Jeremy Huddleston Sequoia]

Actually, I think I'll just do similarly and revbump all dependents.  
Unfortunately, that means anyone using the library for their own projects will 
need to recompile, but that's probably better than the maintenance headache of 
being different than upstream going forward.  Hopefully they can manage to 
version themselves correctly now that they're on cmake.

--Jeremy

 On Mar 29, 2015, at 23:12, Jeremy Huddleston Sequoia jerem...@macports.org 
 wrote:
 
 Damnit, thanks.  I just checked that the dylib id didn't change and didn't 
 notice they messed up the versioning.
 
 This doesn't require a bump of dependents.  It just requires fixing the 
 versioning in freeglut.  I'll set the current version to 13.0.0 and the 
 compatibility version to 1.0.0.
 
 --Jeremy
 
 On Mar 29, 2015, at 16:02, Jack Howarth howarth.at.macpo...@gmail.com 
 wrote:
 
 Jeremy,
  The situation with freeglut 3.0.0 is described in
 http://sourceforge.net/p/freeglut/bugs/51/ and
 http://sourceforge.net/p/freeglut/bugs/213/. Back in 2004, I filed the
 first bug about the compatibility version being set too high on darwin
 and it was ignored. This issue came back to bit us when upstream
 switched the build to use cmake as that doesn't allow the
 compatibility version to be manually set. Thus the freeglut 3.0.0
 release ends up lowering the compatibility version to a number
 sensible in the cmake build mechanism.
  In fink, we took the approach of creating a new freeglut2
 package and stored the shared library in a buried directory. This
 allows legacy binaries (built against the old freeglut compatibility
 version) to retain access to the library from the freeglut-shlibs
 split-off package and binaries built against the new freeglut2 package
 to use the buried shared library from a freeglut2-shlibs split-off
 package. The development headers and library symlinks are stored in
 freeglut and freeglut2 packages which conflicts/replaces each other.
  I'm not sure how you will want to handle this in MacPorts due
 to the limitations of the packaging mechanism, You may need to simply
 rebuild everything against the new freeglut with the 'regressed'
 compatibility version.
   Jack
 ps The upstream developer decided to take the hit on darwin with this
 breakage with the view that going forward the version/compatibility
 numbering is now coherent.
 
 On Sun, Mar 29, 2015 at 5:01 PM, petr 9...@ingv.it wrote:
 
 
 r134510 | jerem...@macports.org | 2015-03-27 22:12:03 +0100 (Fri, 27 Mar 
 2015) | 2 lines
 
 freeglut: Bump to 3.0.0
 
 
 
 Jeremy,
 this version bump requires also a revision bump of the lib dependencies.
 Cheers,
 ~petr
 
 This is what I observed after upgrade:
 
 ---  Cleaning freeglut
 ---  Removing work directory for freeglut
 ---  Updating database of binaries
 ---  Scanning binaries for linking errors
 Incompatible library version: /opt/local/bin/xterra requires version 13.0.0 
 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaclock requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacademo requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacafire requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaplay requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaserver requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/cacaview requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/bin/img2txt requires version 
 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides version 3.0.0
 Incompatible library version: /opt/local/lib/libcaca++.0.dylib requires 
 version 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides 
 version 3.0.0
 Incompatible library version: /opt/local/lib/libcaca.0.dylib requires 
 version 13.0.0 or later, but /opt/local/lib/libglut.3.dylib provides 
 version 3.0.0
 ---  Found 10 broken file(s), matching files to ports
 ---  Found 2 broken port(s), determining rebuild order
 ---  Rebuilding in order
terra @0.7
libcaca @0.99.beta19 +x11
 
 
 
 
 ___
 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

Re: [133903] trunk/dports/gis/proj/Portfile

[Jeremy Huddleston Sequoia]

You need to revbump everything that links against libproj when its dylib id 
changes, such as in this version bump.

Is the dylib id change *actually* necessary, or did upstream developers 
erroneously change the dylib id?

 On Mar 15, 2015, at 10:00, vi...@macports.org wrote:
 
 Revision
 133903
 Author
 vi...@macports.org
 Date
 2015-03-15 10:00:28 -0700 (Sun, 15 Mar 2015)
 Log Message
 
 proj: update to 4.9.1
 Modified Paths
 
   • trunk/dports/gis/proj/Portfile
 Diff
 
 Modified: trunk/dports/gis/proj/Portfile (133902 = 133903)
 
 --- trunk/dports/gis/proj/Portfile2015-03-15 15:27:08 UTC (rev 133902)
 +++ trunk/dports/gis/proj/Portfile2015-03-15 17:00:28 UTC (rev 133903)
 
 @@ -4,8 +4,7 @@
 
  PortSystem  1.0
 
  
 
  nameproj
 
 -version 4.8.0
 -revision1
 
 +version 4.9.1
 
  set datumgrid_version 1.5
 
  categories  gis
 
  platforms   darwin
 
 @@ -20,8 +19,9 @@
 
  master_siteshttp://download.osgeo.org/proj/
  distfiles-append${name}-datumgrid-${datumgrid_version}.zip
 
  checksums   ${name}-${version}.tar.gz \
 
 -rmd160  a2a20159b333aeef9f6322ccc97a0a14cc38fe89 \
 -sha256  
 2db2dbf0fece8d9880679154e0d6d1ce7c694dd8e08b4d091028093d87a9d1b5 \
 
 +checksums   proj-4.9.1.tar.gz \
 +rmd160  d13b21e7ab9c027d875a72baa5d5a491e464873a \
 +sha256  
 fca0388f3f8bc5a1a803d2f6ff30017532367992b30cf144f2d39be88f36c319 \
 
  proj-datumgrid-${datumgrid_version}.zip \
 
  rmd160  f5deacd0242557c92c35d43941cd52a7e4096467 \
 
  sha256  
 723c4017d95d7a8abdf3bda4e18d3c15d79b00f9326d453da5fdf13f96c287db
 
 ___
 macports-changes mailing list
 macports-chan...@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-changes



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

Re: [133903] trunk/dports/gis/proj/Portfile

[Jeremy Huddleston Sequoia]

You need to revbump *all* ports that get broken by this dylib id change, not 
just the ones that impact your install and are not openmaintainer.  I just did 
three that were impacting my install.  You need to find the remaining 
dependents and revbump them.

--Jeremy

 On Mar 16, 2015, at 10:20, petr 9...@ingv.it wrote:
 
 
 In r133984 I revision bumped some of the ports which needed a rebuild on my 
 installation.
 
 M   databases/spatialite-tools/Portfile
 M   databases/spatialite/Portfile
 M   python/py-spatialite/Portfile
 M   gis/grass/Portfile
 M   databases/postgis2/Portfile
 M   gis/gdal/Portfile
 M   graphics/libgeotiff/Portfile
 
 I omitted ncarg and qgis, which are not openmaintainer.
 
 ~petr
 
 
 
 On 16 Mar 2015, at 17:49, Jeremy Huddleston Sequoia jerem...@apple.com 
 wrote:
 
 You need to revbump everything that links against libproj when its dylib id 
 changes, such as in this version bump.
 
 Is the dylib id change *actually* necessary, or did upstream developers 
 erroneously change the dylib id?
 
 On Mar 15, 2015, at 10:00, vi...@macports.org wrote:
 
 Revision
 133903
 Author
 vi...@macports.org
 Date
 2015-03-15 10:00:28 -0700 (Sun, 15 Mar 2015)
 Log Message
 
 proj: update to 4.9.1
 Modified Paths
 
 • trunk/dports/gis/proj/Portfile
 Diff
 
 Modified: trunk/dports/gis/proj/Portfile (133902 = 133903)
 
 --- trunk/dports/gis/proj/Portfile  2015-03-15 15:27:08 UTC (rev 133902)
 +++ trunk/dports/gis/proj/Portfile  2015-03-15 17:00:28 UTC (rev 133903)
 
 @@ -4,8 +4,7 @@
 
 PortSystem  1.0
 
 
 
 nameproj
 
 -version 4.8.0
 -revision1
 
 +version 4.9.1
 
 set datumgrid_version 1.5
 
 categories  gis
 
 platforms   darwin
 
 @@ -20,8 +19,9 @@
 
 master_siteshttp://download.osgeo.org/proj/
 distfiles-append${name}-datumgrid-${datumgrid_version}.zip
 
 checksums   ${name}-${version}.tar.gz \
 
 -rmd160  a2a20159b333aeef9f6322ccc97a0a14cc38fe89 \
 -sha256  
 2db2dbf0fece8d9880679154e0d6d1ce7c694dd8e08b4d091028093d87a9d1b5 \
 
 +checksums   proj-4.9.1.tar.gz \
 +rmd160  d13b21e7ab9c027d875a72baa5d5a491e464873a \
 +sha256  
 fca0388f3f8bc5a1a803d2f6ff30017532367992b30cf144f2d39be88f36c319 \
 
proj-datumgrid-${datumgrid_version}.zip \
 
rmd160  f5deacd0242557c92c35d43941cd52a7e4096467 \
 
sha256  
 723c4017d95d7a8abdf3bda4e18d3c15d79b00f9326d453da5fdf13f96c287db
 
 ___
 macports-changes mailing list
 macports-chan...@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-changes
 
 ___
 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



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

Re: Xvfb MIA

[Jeremy Huddleston Sequoia]

 On Feb 12, 2015, at 08:58, Jack Howarth howarth.at.macpo...@gmail.com wrote:
 
 Jeremy,
So I take it that it is impossible to use MacPort's Xvfb

There is no port for Xvfb.  That's the only issue. If you want it, I suggest 
you make a subport of xorg-server to provide it.

 without
 abandoning the use of the Xquartz server in /opt/local/X11?

I'm not sure where you got that idea, but certainly that is not the case.

Also, it's not in /opt/local/X11.

 That is
 rather unfortunate as my experience in packaging over 500 cran modules
 for fink was that at least 26 needed to have R CMD INSTALL passed
 through xvfb-run as those trigger accesses to the X server.
 Jack
 
 On Wed, Feb 11, 2015 at 10:49 PM, Jeremy Huddleston Sequoia
 jerem...@macports.org wrote:
 Xvfb is part of xorg-server.  MacPorts only installs the XQuartz DDX from 
 the xorg-server and xorg-server-devel ports.
 
 On Feb 11, 2015, at 18:48, Jack Howarth howarth.at.macpo...@gmail.com 
 wrote:
 
 Jeremy,
  Where is the Xvfb binary hidden in MacPorts? It is part of
 Xquartz so I assume we must have it hidden in one of the xorg
 packages. I ask because I need to leverage Xvfb and the xvfb-run
 script borrowed from fink in order to update the rNMR package to 1.1.8
 (which attempts to access the X11 server during the R CMD INSTALL
 step). In fink, we saw the same issue but solved it by passing the R
 command in question to the modified Debian xvfb-run script. Assuming
 that MacPorts has Xvfb buried in some package, I can package up the
 xvfb-run script for general use.
   Jack
 xvfb-run
 



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

Re: Xvfb MIA

[Jeremy Huddleston Sequoia]

Try this:
--disable-xquartz --disable-glx --disable-dri --disable-launchd --enable-kdrive 
--disable-xsdl --enable-xnest --enable-xvfb

 On Feb 12, 2015, at 12:13, Jack Howarth howarth.at.macpo...@gmail.com wrote:
 
 Jeremy,
 Exactly what needs to be passed to configure in the xorg-server
 Portfile to trigger Xvfb to build? I see...
 
  --enable-xvfb   Build Xvfb server (default: yes)
 
 in the output of './configure --help' in the build directory but the
 config.log left behind only shows...
 
 configure:28382: checking whether to build Xvfb DDX
 configure:28384: result: no
 
  Jack
 
 On Thu, Feb 12, 2015 at 1:13 PM, Jeremy Huddleston Sequoia
 jerem...@macports.org wrote:
 
 On Feb 12, 2015, at 08:58, Jack Howarth howarth.at.macpo...@gmail.com 
 wrote:
 
 Jeremy,
   So I take it that it is impossible to use MacPort's Xvfb
 
 There is no port for Xvfb.  That's the only issue. If you want it, I suggest 
 you make a subport of xorg-server to provide it.
 
 without
 abandoning the use of the Xquartz server in /opt/local/X11?
 
 I'm not sure where you got that idea, but certainly that is not the case.
 
 Also, it's not in /opt/local/X11.
 
 That is
 rather unfortunate as my experience in packaging over 500 cran modules
 for fink was that at least 26 needed to have R CMD INSTALL passed
 through xvfb-run as those trigger accesses to the X server.
Jack
 
 On Wed, Feb 11, 2015 at 10:49 PM, Jeremy Huddleston Sequoia
 jerem...@macports.org wrote:
 Xvfb is part of xorg-server.  MacPorts only installs the XQuartz DDX from 
 the xorg-server and xorg-server-devel ports.
 
 On Feb 11, 2015, at 18:48, Jack Howarth howarth.at.macpo...@gmail.com 
 wrote:
 
 Jeremy,
 Where is the Xvfb binary hidden in MacPorts? It is part of
 Xquartz so I assume we must have it hidden in one of the xorg
 packages. I ask because I need to leverage Xvfb and the xvfb-run
 script borrowed from fink in order to update the rNMR package to 1.1.8
 (which attempts to access the X11 server during the R CMD INSTALL
 step). In fink, we saw the same issue but solved it by passing the R
 command in question to the modified Debian xvfb-run script. Assuming
 that MacPorts has Xvfb buried in some package, I can package up the
 xvfb-run script for general use.
  Jack
 xvfb-run
 
 



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

libGLU and mesa

[Jeremy Huddleston Sequoia]

Hello everyone,

mesa received quite a version bump last night.  As part of that, libGLU was 
pushed out to a separate port (much like glut was a few years ago) to match 
upstream's packaging changes.

I've updated the few ports that I'm aware of that use libGLU and will be trying 
to build other ports that depend on mesa to determine if they need libGLU or 
not.  If you run into any build failures in ports because GL/glu.h can't be 
found or because libGLU can't be found, please add a new dependency on 
port:libGLU.

Thanks,
Jeremy



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

Re: libGLU and mesa

[Jeremy Huddleston Sequoia]

Yeah, it looks like fox has some code in configure to try to deal with the 
absence of libGLU, but it doesn't work.

 On Feb 11, 2015, at 12:10, Marko Käning mk-macpo...@techno.ms wrote:
 
 
 On 11 Feb 2015, at 21:09 , Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
 
 Can you send the commands macports built? It might be the new include/lib
 is not in the build commands.
 
 Here is one:
 
 :info:build libtool: compile:  /usr/bin/clang++ -DPACKAGE_NAME=\fox\ 
 -DPACKAGE_TARNAME=\fox\ -DPACKAGE_VERSION=\1.6.46\ 
 -DPACKAGE_STRING=\fox 1.6.46\ 
 -DPACKAGE_BUGREPORT=\jer...@fox-toolkit.com\ -DPACKAGE_URL=\\ 
 -DPACKAGE=\fox\ -DVERSION=\1.6.46\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1 -D_GNU_SOURCE=1 
 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1 -DHAVE_DLFCN_H=1 
 -DLT_OBJDIR=\.libs/\ -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 
 -DHAVE_DIRENT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 
 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBDL=1 
 -DHAVE_VSSCANF=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 
 -DHAVE_PNG_H=1 -DHAVE_TIFF_H=1 -DHAVE_ZLIB_H=1 -DHAVE_BZLIB_H=1 
 -DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_X11_EXTENSIONS_SHAPE_H=1 -DHAVE_X11_XC
 URSOR_XCURSOR_H=1 -DHAVE_X11_EXTENSIONS_XRENDER_H=1 
 -DHAVE_X11_EXTENSIONS_XRANDR_H=1 -DHAVE_X11_EXTENSIONS_XFIXES_H=1 
 -DHAVE_X11_EXTENSIONS_XINPUT_H=1 -I. -I../include -I../include 
 -I/opt/local/include -I/opt/local/include/freetype2 -Wall -Wformat 
 -Woverloaded-virtual -Wshadow -DHAVE_JPEG_H=1 -DHAVE_PNG_H=1 -DHAVE_TIFF_H=1 
 -DHAVE_ZLIB_H=1 -DHAVE_BZ2LIB_H=1 -DHAVE_XFT_H=1 -I/usr/include/freetype2 
 -DHAVE_XSHM_H=1 -DHAVE_XSHAPE_H=1 -DHAVE_XCURSOR_H=1 -DHAVE_XRENDER_H=1 
 -DHAVE_XRANDR_H=1 -DHAVE_XFIXES_H=1 -DHAVE_XINPUT_H=1 -DNO_XIM -DHAVE_GL_H=1 
 -MT FXGroupBox.lo -MD -MP -MF .deps/FXGroupBox.Tpo -c FXGroupBox.cpp -o 
 FXGroupBox.o /dev/null 21
 
 ___
 macports-dev mailing list
 macports-dev@lists.macosforge.org
 https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: Xvfb MIA

[Jeremy Huddleston Sequoia]

Xvfb is part of xorg-server.  MacPorts only installs the XQuartz DDX from the 
xorg-server and xorg-server-devel ports.

 On Feb 11, 2015, at 18:48, Jack Howarth howarth.at.macpo...@gmail.com wrote:
 
 Jeremy,
   Where is the Xvfb binary hidden in MacPorts? It is part of
 Xquartz so I assume we must have it hidden in one of the xorg
 packages. I ask because I need to leverage Xvfb and the xvfb-run
 script borrowed from fink in order to update the rNMR package to 1.1.8
 (which attempts to access the X11 server during the R CMD INSTALL
 step). In fink, we saw the same issue but solved it by passing the R
 command in question to the modified Debian xvfb-run script. Assuming
 that MacPorts has Xvfb buried in some package, I can package up the
 xvfb-run script for general use.
Jack
 xvfb-run

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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

 On Feb 7, 2015, at 02:01, René J.V. Bertin rjvber...@gmail.com wrote:
 
 Hello,
 
 I think I found the error leading to OpenGL initialisation failure in VLC 
 2.2.0 rc2 built through MacPorts. Or rather: it must be a lack of 
 initialisation because I'd hope a failure during that step would be signalled 
 and handled appropriately ...
 
 The configure procedure finds both the GLX libGL.dylib library and the OpenGL 
 framework, and links both. Somehow that doesn't lead to linker warnings, 
 which is why I didn't notice it before. More details at 
 https://trac.videolan.org/vlc/ticket/13838 .

Good luck with that.  My experience with that track is that they will just 
close your ticket and tell you to piss off.

 I'd appreciate feedback from someone more familiar with autoconf/automake to 
 trace and correct this issue.
 Jeremy: you seem to be the last person to have updated port:VLC-devel; did 
 that build to a functional player for you?

Yeah, the last time I touched it, it built fine and gave me a functional 
VLC.app.

As upstream developers' manners leave much to be desired, I opted to stop 
maintaining the port and haven't really messed with it for quite some time.

 It does not for me, and I'd like to be able to exclude the possibility that 
 my local build environment is somehow the reason for this GL/GLX confusion.

Can you point me to a build log?  I'll take a look later.  Too tired now...

 
 Kind regards,
 René
 

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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

 On Feb 7, 2015, at 04:23, Jean-Baptiste Kempf j...@videolan.org wrote:
 
 And Jeremy reopend tickets when clearly asked to not reopen without more
 info?

Yes, I reopened tickets for *real problems* that were closed by rude upstream 
developers who did not wish to fix bugs in their software, and I was 
continually threatened and insulted by said developers for simply reporting 
said problems.

 Problems should be correctly fixed, not hacked. We're the ones, in the
 end, that have to maintain it, not you.
 
 All other platform maintainers understand that, except Macports.

That's laughable.  I challenge you to enumerate the number of times I've 
suggested hacking around a problem as the final solution or accepting a quick 
fix to a problem which decreases maintainability.  I always push for properly 
engineered solutions and good architecture.

 No, I don't think that's true. At MacPorts we have to find and walk a fine 
 line, but our needs are comparable to Fink's, HomeBrew's and a few lesser 
 known others, and together we do represent a large enough movement that our 
 needs cannot just be waved off because we don't do everything the exact Mac 
 way, or (in this case), because we happen to have X11 stuff available.
 
 It's funny how VLC on Brew works fine and is used, notably by tomahawk
 (pure Qt application) and we never ever had a problem with them.

VLC also works great on MacPorts, with the exception of the new issue René is 
discussing now.

 We have numerous patches from all BSD, most Linux distributions, Windows
 and so on, and all of them get merged, with the very notable exception
 of MacPorts.

What are these notable exceptions?  We only have 5 (minor) patches that haven't 
been integrated:

== PR-34741-no__clang_version__.patch
Fixes improper handling of older versions of clang in modules/gui/macosx/about.m

== buildfix-package.mak.patch and configure.ac-no-arch.patch
Minor build system tweaks

== no-sparkle.patch
Obvious

== static_assert.patch
Obvious

None of these are hacks or decrease maintainability for you.

 Of course I can also find a more hackish fix, like the fix I used to build 
 against Qt4 instead of Qt5, but giving us the impression that we're on our 
 own if we don't follow your build recipe exactly (because we can't) will 
 only discourage us from sharing proper patches.
 
 You can't use bootstrap, and configure?

We do use bootstrap and configure.



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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

 On Feb 7, 2015, at 05:51, René J.V. Bertin rjvber...@gmail.com wrote:
 
 But I am! Please have a look at the logs I attached to the trac ticket...
 
 Jeremy wasn't, and that's the topic of this mail, about supposedly us
 insulting him, because we closed his bugreport that he kept reopening,
 while the whole time, he was hacking your buildsystem.
 
 In defense of Jeremy, I think he was. I took over the Portfile that had his 
 signature, so I'm presuming that's what he used too.
 And it does a bootstrap before invoking configure.

I don't know where things stand today, but a couple years ago when I tried to 
help out, nobody was maintaining the VLC port in MacPorts, and it had aged 
quite a bit.  The VLC build system was an utter hack, and the Portfile that was 
managing it was equally repugnant.  I spent quite a bit of time getting us up 
to a modern version of VLC and also created the VLC-devel port to track 
upstream development versions in hopes of finding issues *before* they released 
them.

I got things into a decent state for us and reported bugs upstream to help them 
improve things for other distributions.  After multiple disagreements, I 
decided to just give up trying to help upstream.




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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

 On Feb 7, 2015, at 05:57, Jean-Baptiste Kempf j...@videolan.org wrote:
 
 In defense of Jeremy, I think he was. I took over the Portfile that had his 
 signature, so I'm presuming that's what he used too.
 And it does a bootstrap before invoking configure.
 
 He claimed that sedding our buildsystem was correct.

Can you point out where you're referring to?

 Not to mention heavily patching VLC, with no good reason, as we can see
 with the NSEnviron ticket.

How is that heavily patching VLC?  Also, as you can see by my comment in that 
ticket, the change I am suggesting makes your app conform to environ(3).  Right 
now, you're relying on undocumented behavior which could change.

 Again in his defense, I hold him in high esteem as a developer, who knows OS 
 X way more intimately than most (he's the main XQuartz developer).
 
 So what? He could be the kernel core developer or Linux Torvalds, that 
 wouldn't
 change a thing. He behaved wrongly, and then complained we were
 insulting him, and lied about his patches not being taken in accounts.

Really?  Where have I lied?

 I've seen the patches, I've even extended one (to get rid of the last 
 references to Growl). We may not agree on how good the reasons are for those 
 patches (= the ones I know of), but from what I can see they have nothing to 
 do with the issue at hand.
 
 One of them is amazing, by patching a clear and on-purpose limitation of
 linking to libavcodec 56...

Where are you referring to?



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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

 On Feb 7, 2015, at 13:44, Jean-Baptiste Kempf j...@videolan.org wrote:
 
 On 07 Feb, Jeremy Huddleston Sequoia wrote :
 I got things into a decent state for us and reported bugs upstream to help 
 them improve things for other distributions.  After multiple disagreements, 
 I decided to just give up trying to help upstream.
 
 Which disagreements?

Mainly, the hostility exuded by VLC developers.  As reference, you can see:

1) https://trac.videolan.org/vlc/ticket/9475
2) https://trac.videolan.org/vlc/ticket/10832
3) This thread.

 Of all your 9 bugs reported, all of them were fixed, in time.
 One, more info was requested and is still open, because of that.
 
 One of the bug was heated, and in the end, the issue where the port was
 a wrong sed in your buildsystem.

That sed usage had been there for years (well before I tried to start cleaning 
up the port).  It was using sed as part of generating some paths to run your 
'genmf' script in.  Presumably, this was all added by someone before you guys 
added the bootstrap script.  I appreciate your (eventual) help in figuring that 
out, but the hostility was simply uncalled for.

 Yet, you reopened it 3 times, even after you were asked to not do that.

Yes, that is quite rude.  You should not be hostile and threatening to your 
users nor distros for reporting problems or reopening them if they are still 
unresolved.  This behavior is one of the reasons I decided to stop maintaining 
the VLC ports.

I will not be responding further.

--Jeremy



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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

 One of them is amazing, by patching a clear and on-purpose limitation of
 linking to libavcodec 56...
 
 I don't see a patch that does anything like that among the ones included.
 What limitation?
 
 https://trac.macports.org/browser/trunk/dports/multimedia/VLC/files/patch-ffmpeg-2.4.diff

Well I have no knowledge of that particular change because I didn't make it.  
Can you explain what compatibility problems VLC has with newer versions of 
ffmpeg, so I can pass along the information?





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

Re: OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X

[Jeremy Huddleston Sequoia]

Yeah, I shoulndn't've gotten suckered back into that.

 On Feb 7, 2015, at 12:47, René J.V. Bertin rjvber...@gmail.com wrote:
 
 On Saturday February 07 2015, Jeremy Huddleston Sequoia wrote regarding Re: 
 OpenGL/GLX dual link error in VLC 2.2.0 git/master via MacPorts on OS X
 
 Just let it fly, Jeremy. I have the impression that we're dealing with a 
 12yo, or someone with that emotional mindset (the kind of person who spends 
 way too much time on his angry teenager desktop look and gets annoyed when 
 something distract him from that). And sadly also someone who confirms a 
 number of stereotypes about the French ... (though he also reminded me of 
 people from certain calvinist Dutch sects I've known).
 I won't repeat what he called you in a personal email to me when I kept 
 trying to put your earlier remarks in context.
 
 See https://trac.videolan.org/vlc/ticket/13836 .
 
 Cheers,
 R.



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