Re: New build failure emails are difficult to act on

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 Huddles

New build failure emails are difficult to act on

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

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

> 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://gi

Re: Trac & Subversion available again

> 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

Re: llvm / clang and thread_local storage problems

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

Re: llvm / clang and thread_local storage problems

> 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

Re: Of C++ (and other) runtimes

> 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

Re: llvm / clang and thread_local storage problems

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

Re: No Xcode 8 CLT for El Capitan

> 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

Re: No Xcode 8 CLT for El Capitan

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

Re: No Xcode 8 CLT for El Capitan

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

Re: No Xcode 8 CLT for El Capitan

> 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

Re: No Xcode 8 CLT for El Capitan

> 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

Re: No Xcode 8 CLT for El Capitan

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

Re: No Xcode 8 CLT for El Capitan

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

Re: No Xcode 8 CLT for El Capitan

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

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

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

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

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

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

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

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

> 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

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

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

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

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

Re: lldb ...

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

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

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

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

> 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 ${ma

Re: lldb ...

> 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

Re: lldb ...

> 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 ${macpo

Re: lldb ...

hains`. > > 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 thi

Re: lldb ...

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

Re: lldb ...

> 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

Re: lldb ...

> 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

Re: lldb ...

> 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

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

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,

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

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

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

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,

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

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

Re: *-devel ports for llvm and gcc

> 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

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

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

Issues with variants in current base trunk

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

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

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

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

> 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: >>>>> O

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

> 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

Re: LeopardSDKFixes on PPC

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

Re: Using cxx11 PortGroup on < 10.9

> 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

Re: Using cxx11 PortGroup on < 10.9

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

Re: Using cxx11 PortGroup on < 10.9

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

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

> 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/buil

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

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

Re: Owner of MacPorts account on GitHub

> 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

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

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 Huddl

Re: xorg-libXt

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

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

> 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@… |

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

> 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

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

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

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

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

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

> 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

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

> 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, >&g

Re: [141132] trunk/dports/lang/apple-gcc42/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 <

Re: llvm-3.7 release and OpenMP

k; >> 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: &

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

> 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

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

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

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

> 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

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

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.

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

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,

Re: Any more changes to merge for 2.3.4?

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

Re: about alternative ports and the build bots

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

Re: libexec vs lib

> 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

Re: llvm-3.7 release and OpenMP

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 o

Re: llvm-3.7 release and OpenMP

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

Re: llvm-3.7 release and OpenMP

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

Re: llvm-3.7 release and OpenMP

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

Re: Ncurses 6

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

libressl in MacPorts

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

Re: libressl maintainer

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

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

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.

Lion buildbot is out of space

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

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

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

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

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

Re: standard way to require c++11?

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

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

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

Re: standard way to require c++11?

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

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

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

Re: standard way to require c++11?

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

Re: standard way to require c++11?

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

Re: [134510] dports/x11/freeglut

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.

Re: [134510] dports/x11/freeglut

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

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

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

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

/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

Re: Xvfb MIA

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

Re: Xvfb MIA

: 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

libGLU and mesa

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

Re: libGLU and mesa

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

Re: Xvfb MIA

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

  1   2   3   4   >