Re: How to keep uncommitted work in a git clone

On 04/11/16 05:39, David Bariod wrote: Hello, Personnally, I would just commit such change. It is cheap, can be reworked later and be ketp safe in a private remote repository in case of disaster. With git there are no reason to not commit event not ready yet change set. I would not do this,

Re: How to keep uncommitted work in a git clone

On 04/11/16 04:18, Sterling Smith wrote: On Nov 3, 2016, at 7:54PM, Arno Hautala wrote: On Thu, Nov 3, 2016 at 9:56 PM, Ryan Schmidt wrote: Well, I tried that. I git stashed, then made changes to curl and committed them, and later when I

Re: git fetch fails because of gnutls_handshake

On 29 Oct 2016, at 4:27 pm, Lawrence Velázquez wrote: >> On Oct 29, 2016, at 11:17 AM, René J.V. Bertin wrote: >> >> Does trac no longer auto-subscribe new participants? > > Our Trac has never automatically subscribed anyone except ticket >

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

On 23 Oct 2016, at 3:14 am, Lawrence Velázquez wrote: >> On Oct 22, 2016, at 8:08 PM, Marko Käning wrote: >> >> in the light of the upcoming commit of the new 'qt5-kde' port I want >> to ask (again) whether it would be acceptable, that we - for

Re: Issues with oudated ports / GitHub

ts.org> wrote: >>> >>> >>>>> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez <lar...@macports.org> >>>>> wrote: >>>>> >>>>> On Oct 7, 2016, at 2:09 PM, Chris Jones <jon...@hep.phy.cam.ac.uk>

Re: Issues with oudated ports / GitHub

> On 7 Oct 2016, at 6:08 pm, Daniel J. Luke wrote: > > On Oct 7, 2016, at 11:59 AM, Marcel Bischoff wrote: It pains me to say that Homebrew is running circles around MacPorts in the department of current available packages. >>> >>>

Re: Working with Git

On 07/10/16 17:39, Craig Treleaven wrote: On Oct 7, 2016, at 12:16 PM, Sterling Smith <smit...@fusion.gat.com> wrote: On Oct 7, 2016, at 7:20AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: My point still stands though, you have to actively try the things you need to do,

Re: Working with Git

Hi, There will always be problems with the transition to GitHub that can be discussed on the mailing list to find a common solution. Then it can be documented to point people to that if they have the same problem. Yes. But I want to at least know how to perform the tasks that I currently

Re: Working with Git

On 06/10/16 12:15, Ryan Schmidt wrote: On Oct 6, 2016, at 06:09, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: On 06/10/16 11:43, Mojca Miklavec wrote: On 6 October 2016 at 09:39, Chris Jones wrote: How do I take the user's pull request, make additional changes, and commit them

Re: Working with Git

On 06/10/16 11:43, Mojca Miklavec wrote: On 6 October 2016 at 09:39, Chris Jones wrote: How do I take the user's pull request, make additional changes, and commit them to our master? Anyone can commit to the branch created by the user for the pull request. So you can just checkout

Re: Working with Git

On 06/10/16 10:19, Ryan Schmidt wrote: On Oct 6, 2016, at 4:02 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: On 06/10/16 10:00, Ryan Schmidt wrote: On Oct 6, 2016, at 3:59 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: Hi, The instructions at https://trac.macpo

Re: Working with Git

On 06/10/16 10:00, Ryan Schmidt wrote: On Oct 6, 2016, at 3:59 AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: Hi, The instructions at https://trac.macports.org/wiki/WorkingWithGit seem a little out of date w.r.t. forking. It says "To do that, go to ​https://github.com/mac

Re: Working with Git

ives a 404 error... Chris On 06/10/16 09:44, Ryan Schmidt wrote: On Oct 6, 2016, at 03:32, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: On 06/10/16 09:22, Ryan Schmidt wrote: On Oct 6, 2016, at 02:33, Sterling Smith <smit...@fusion.gat.com> wrote: Ryan, On Oct 5, 2016, a

Re: Working with Git

On 06/10/16 09:22, Ryan Schmidt wrote: On Oct 6, 2016, at 02:33, Sterling Smith wrote: Ryan, On Oct 5, 2016, at 7:53PM, Ryan Schmidt wrote: Suppose a user submits an update to a port. With Subversion, the user would submit a patch in a

Re: Working with Git

> How do I take the user's pull request, make additional changes, and commit them to our master? Anyone can commit to the branch created by the user for the pull request. So you can just checkout that branch yourself, make changes, commit and push them back to the branch, and thus the merge

Re: Patch naming policy (was: Re: [153574] trunk/dports/sysutils/skey)

> On 5 Oct 2016, at 2:56 pm, Rainer Müller wrote: > > On 2016-10-05 01:45, Ryan Schmidt wrote: >>> Patches should follow the patch-*.diff naming scheme, so this >>> should be named patch-skeyprune-man8.diff or similar. >>> >>>

Re: order of operations in port upgrade

Hi, The current order makes more sense to me. Only clean once the activation is successful. I also fail to see how your proposal helps with your fragmentation ? Chris On 05/10/16 10:09, René J.V. Bertin wrote: Hi, Quick question: a normal (non-forced) upgrade currently does 1) install

Re: Dual g++ ABI in libraries --- how to handle it?

> On 4 Oct 2016, at 3:35 am, Alexander Gaenko wrote: > > Hi, > > The build of our C++ library > (https://www.macports.org/ports.php?by=name=alpscore) fails > with g++-mp-6 --- apparently due to the fact that Boost libraries used > by our code were compiled with the "old"

Re: weird (buggy?) build dependency on a clang port

Because macports-clang-3.7 occurs first in the fallback list. Print out ${compiler.fallback} if you don't believe me. :) Installed compiler ports are not considered "more available" than uninstalled ones. Which of course is a good thing. A port installation should be fully reproducible. For

Re: How to discontinue ports completely (py26 deprecation) ...

On 11/08/16 20:40, Fred Wright wrote: On Wed, 10 Aug 2016, Lawrence Velázquez wrote: On Aug 10, 2016, at 5:21 PM, Fred Wright wrote: I don't consider Python 2.6 to be "cruft". Developers need many versions of Python installed for testing, and that includes any

Re: port:libclang (and libLLVM)

> On 9 Mar 2016, at 5:08 pm, René J.V. Bertin wrote: > >> On Wednesday March 09 2016 08:41:56 Eric A. Borisch wrote: >> >> FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50 >> options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather >>

Re: port:libclang

Hi, As far as I am aware ROOT6 does not offer any build option to use an external clang installation. It always builds its own internal version, and I would not be in favour of MacPorts changing this until such a time as upstream offers it as an officially supported option. Not that I am

Re: where Xcode 3.1 / command line tools ...

On 24/02/16 15:13, Brandon Allbery wrote: On Wed, Feb 24, 2016 at 10:12 AM, Chris Jones <jon...@hep.phy.cam.ac.uk <mailto:jon...@hep.phy.cam.ac.uk>> wrote: Been ages since I ran 10.6, so I might have forgotten where things are in that OS, but have you checked the O

Re: where Xcode 3.1 / command line tools ...

Been ages since I ran 10.6, so I might have forgotten where things are in that OS, but have you checked the OSX App Store for Xcode ? On 24/02/16 15:08, petr wrote: Hi I am trying to install Macports on an old OS X 10.6 system, but have difficulties to get/find Xcode 3.1 and the command

Re: VLC cannot play MKV files?

Hi, On 26/01/16 09:47, Vincent Habchi wrote: I was under the impression that Apple already compressed the files and programs installed with the operating system, using HFS compression, ever since taking up less disk space was listed as a feature of Snow Leopard. Yeah, I thought so too, but

OSX 10.11 buildbot status ?

Hi, Just curious, but whats the status of getting a buildbot for 10.11 set up ? Would be good to start proving binary tarballs for this platform. Cheers chris ___ macports-dev mailing list macports-dev@lists.macosforge.org

Re: Plan B?

On 12/10/15 16:25, Mojca Miklavec wrote: On Mon, Oct 12, 2015 at 4:59 PM, Mark Anderson wrote: I dunno, but it seems like we're easily the most active project on here. Followed by XQuartz maybe. Webkit seems to be hosted on Mac OS Forge as well and it seems relatively active:

ROOT6 Update commit

Hi, Could I ask someone to take a look at https://trac.macports.org/ticket/48376 to review for committing ? many thanks Chris ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: avoid usage of Macport installed software

On 7 May 2015, at 5:48 pm, petr 9...@ingv.it wrote: Hi all, I am working on some new port. It works already quite fine, but I observe that when using it without Tracemode, it would pick up various already installed programs. Most of these are also provided by Xcode, but notably

Re: Port xapian-bindings' dependency on MacPorts' (outdated) ruby port

On 16/04/15 09:40, René J.V. Bertin wrote: On Thursday April 16 2015 08:54:30 Chris Jones wrote: If the port needs ruby it should depend on a macports ruby version and not rely on the system one, regardless of what version the system one is. This is normal macports behavior, to provide

Re: Port xapian-bindings' dependency on MacPorts' (outdated) ruby port

On 16/04/15 08:18, Marko Käning wrote: Hi, I am trying to make use of xapian-bindings, which has a dependency on MacPorts' ruby, which currently results in version 1.8.7 --- $ ruby --version ruby 1.8.7 (2013-06-27 patchlevel 374) [i686-darwin13] --- Now I ask myself, whether this port

Re: expecting a user to use `port select` from a Portfile (re: Qt 5 support on OS X 10.6)

On 27/03/15 11:05, René J.V. Bertin wrote: Hello, I've managed to get Qt 5.3 to build on OS X 10.6 and adapt my qt5-mac-devel Portfile for that. No small feat, as this is not officially supported by Digia. Main issue here: the system compilers on 10.6 (*gcc-4.2, and clang from Xcode 3.2 as

Re: standard way to require c++11?

On 19/03/15 18:44, Michael Dickens wrote: On Thu, Mar 19, 2015, at 02:06 PM, Lawrence Velázquez wrote: On Mar 19, 2015, at 1:56 PM, Michael Dickens michae...@macports.org wrote: Exactly. If we key off of {${configure.cxx_stdlib} eq libstdc++}, then I think this can be made to work; er, mostly.

Re: standard way to require c++11?

On 19/03/15 17:54, René J.V. Bertin wrote: On Thursday March 19 2015 17:01:02 Chris Jones wrote: Using gcc is a bad idea, this can lead to C++ runtime issues. On newer OS X versions where libc++ is the default (or only) C++ runtime. No, its problematic on all OSX releases. Which means

Re: standard way to require c++11?

Hi, The bottom line is there is no clean way of supporting C++11 on 10.8 or older. Its can only be done on a best try basis. Using gcc is a bad idea, this can lead to C++ runtime issues. In the root6 port we use # Force a compatible compiler compiler.blacklist-append *gcc* {clang 500}

Re: port upgrade outdated order

On 04/03/15 15:57, Mihai Moldovan wrote: On Wednesday March 04 2015 08:58:17 Chris Jones wrote: ports themselves cannot opt in or out, and nor should they be able to. Its up to the user running the port command to decide. That's too dogmatic. I have presented a case where the options

Re: port upgrade outdated order

Hi, On 04/03/15 17:29, René J.V. Bertin wrote: On Wednesday March 04 2015 17:34:32 Mihai Moldovan wrote: Aren't you relying on the assumption that all ports register all the files they install? They really should. If they don't, that's arguably a bug. Exceptions may apply. Let me

Re: port upgrade outdated order

OK, I'll rephrase then. It seems OK for a port to opt into tracemode, if needed to fix bugs like this, but if the user has tracemode globally disabled ports should not be allowed to opt out. ^ enabled . ___ macports-dev mailing list

Re: port upgrade outdated order

On 04/03/15 17:24, René J.V. Bertin wrote: On Wednesday March 04 2015 16:52:50 Chris Jones wrote: If upstream cannot/wont fix, then if we want to keep the port in MacPorts, it should be worked around. trace mode (or anything that does the same thing, hides the installed version) strikes me

Re: port upgrade outdated order

On 04/03/15 16:10, René J.V. Bertin wrote: On Wednesday March 04 2015 09:26:10 Brandon Allbery wrote: Port bugs are never OK. A diagnostic/debugging mode that is forced on in some port as a hackaround for port bugs instead of fixing the port is *also* never OK. When a port fails to build

Re: port upgrade outdated order

On 04/03/15 16:43, René J.V. Bertin wrote: On Wednesday March 04 2015 16:22:16 Chris Jones wrote: When a port fails to build because the project/package/whatever it provides doesn't support building with a previous version present, is that a port bug? As far as I am concerned its a bug

Re: port upgrade outdated order

note that trace mode fixes this ;-) How so? By masking files that aren't part of the operating system, Xcode, or port dependencies. Hmmm, can't say the term trace evokes that for me :) I think I understood that ports can opt out from this mode, no? Can they also activate it? ports

Re: port upgrade outdated order

On 04/03/15 10:37, René J.V. Bertin wrote: On Wednesday March 04 2015 08:58:17 Chris Jones wrote: I think I understood that ports can opt out from this mode, no? Can they also activate it? ports themselves cannot opt in or out, and nor should they be able to. Its up to the user running

Re: port upgrade outdated order

On 04/03/15 11:29, René J.V. Bertin wrote: On Wednesday March 04 2015 10:51:06 Chris Jones wrote: Personally, I think what it does is *always* correct. Aren't you relying on the assumption that all ports register all the files they install? yes. If they don't that should be regarded

Re: ~/.macports

On 12/02/15 12:13, René J.V. Bertin wrote: On Thursday February 12 2015 12:33:53 Clemens Lang wrote: You should be aware of the security implications of this change. For example, sudo port edit vim gets you arbitrary code execution and arbitrary file access as root. Exactly one of the

Re: ~/.macports

On 10/02/15 17:32, René J.V. Bertin wrote: On Tuesday February 10 2015 17:10:37 Chris Jones wrote: 1) at least is solvable as you can configure your sudoers list to allow your main user to run your port command (and that command only) through sudoers without requiring a password. I know

Re: ~/.macports

On 10/02/15 15:06, René J.V. Bertin wrote: On Tuesday February 10 2015 14:42:49 Jeremy Lavergne wrote: Not sure you can make extended ACLs propagate the right way. The old school option is creating a common group for both users and have appropriate umasks. Yep. That's subject to the same

Re: MacPorts forum(s)?

Hi, I for one so no particular reason why anyone would need a list of all list members, whatever password protection or mangling you put into place. If you want to send someone a mail and not sure if they are are member, just cc them as well and let the system sort the rest out. I would be

Re: using ninja instead of make

Hi, On 1 Jan 2015, at 10:16 pm, René J.V. Bertin rjvber...@gmail.com wrote: On Thursday January 01 2015 22:38:32 Clemens Lang wrote: Hi The only configuration system (of relevant size and adoption) that falls into this category is CMake. We could use ninja instead of make for all

Re: Making QtCurve build on Snow Leopard

On 30/11/14 19:05, Marko Käning wrote: Hi, in order to make port QtCurve install on Snow Leopard it is necessary to let the port choose a macports-gcc compiler, preferrably the one perhaps already installed on the system. If you have to use a MacPorts compiler, you would be better off using a

Re: Port deactivate boost hangs forever

Hangs forever here. I interrupted it, tried to deactivate and de-install manually, to no avail. What am I supposed to do at this point? wait longer. It will take a while but will eventually finish... ___ macports-dev mailing list

Re: Port deactivate boost hangs forever

On 10/11/14 09:42, Vincent Habchi wrote: Hi Chris, wait longer. It will take a while but will eventually finish… Yep, it did. Thanks. But that’s really unexpected, especially since I run a MBA with those super-fast PCI-e SSD. I think we ought even to warn the user about this (but I don’t

Re: How to reliably find the C++11 array header?

On 31/10/14 09:45, Thibaut Paumard wrote: Hi, Building of Gyoto failed on Montain Lion: https://build.macports.org/builders/buildports-mtln-x86_64/builds/18764 The error message is: /bin/sh ../libtool --tag=CXX --mode=compile /usr/bin/clang++ -DHAVE_CONFIG_H -I. -I.. -I../include

Re: Clang: Mavericks v. the rest (was Re: buildbot failure in MacPorts on buildports-mavericks-x86_64)

Hi, The warning is correct. If s_decoded.name is a boolean then s_decoded.name = 12 is always true. OSX10.9 has a newer clang, which issues a warning in this case (-Wtautological-constant-out-of-range-compare), older OSes have older clang versions that do not. Finally -Werror turns it into

Commit for ROOT6 update

Hi, Could I ask a committer, or anyone who is interested, to take a look at https://trac.macports.org/ticket/45265 which is an update to the ROOT6 port. There is one issue, which is upstream and moved to a new internal LLVM version, which I believe prevents building on OSX 10.6. I think this

Re: Checking for C++ runtime link mis-matches ?

Hi, On 24 Jun 2014, at 01:01 am, Ryan Schmidt ryandes...@macports.org wrote: On Jun 23, 2014, at 12:50 PM, Christopher Jones jon...@hep.phy.cam.ac.uk wrote: Does MacPorts now check for linking c++ runtime mis-matches, i.e. when one library using one runtime, libc++ say, links against

Re: Buildbot failure for new ROOT ports

On 9 May 2014, at 03:02 pm, Mojca Miklavec mo...@macports.org wrote: On Fri, May 9, 2014 at 2:29 PM, Jeremy Lavergne wrote: Could someone explain the reason for the failure in https://build.macports.org/builders/buildports-mavericks-x86_64/builds/3369 error: forward declaration of

Re: non standard install location and binary packages

Hi, On 10 May 2014, at 08:59 am, Eric Le Lay ele...@macports.org wrote: Hello list, I'm running macports 2.3.0 beta2 on 10.6.8 and can't configure macports to use binary archives. I've set buildfromsource=never in macports.conf and used the -b flag with no success: they are simply

Re: wildcarding port select files to install ?

No takers ;) I would like to finalise a new port select port, and thus if there is no way to do this, would like to know so I can just bite the bullet and list all the files by hand. cheers Chris On 08/04/14 16:54, Chris Jones wrote: Hi, Is it possible to wildcard the files

Re: Building clang/cling 3.5 for ROOT on Lion

On 08/04/14 01:48, Ryan Schmidt wrote: On Apr 7, 2014, at 18:09, Christopher Jones wrote: p.s. whats the most recent MacPorts clang compiler you can install on OSX10.7 ? clang 3.4 and earlier should build fine on 10.7. Indeed. They aren't quite the same thing though in the end, as on OSX

Re: Building clang/cling 3.5 for ROOT on Lion

Indeed. They aren't quite the same thing though in the end, as on OSX 10.8 and newer it supports c++11, whereas on 10.7 it doesn't, because of the underlying system support. So the same clang34 compiler now builds root6 fine on OSX10.9, but fails on 10.7. My recollection of all the previous

Re: Building clang/cling 3.5 for ROOT on Lion

Hi, On 08/04/14 10:14, Mojca Miklavec wrote: On Tue, Apr 8, 2014 at 10:12 AM, Chris Jones wrote: Indeed. They aren't quite the same thing though in the end, as on OSX 10.8 and newer it supports c++11, whereas on 10.7 it doesn't, because of the underlying system support. So the same clang34

Re: Building clang/cling 3.5 for ROOT on Lion

You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc++, and likewise for every library that uses it via a C++ API. Yes, but that doesn't help

Re: Building clang/cling 3.5 for ROOT on Lion

On 08/04/14 11:26, Joshua Root wrote: On 2014-4-8 20:02 , Chris Jones wrote: You can actually use libc++ all the way back to 10.6 (with the libcxx port). The trick is that if you build root against libc++, then every library it uses via a C++ API must also be built against libc

Re: Building clang/cling 3.5 for ROOT on Lion

I didn't say that libc++ doesn't work – I didn't try that at all (I'm not even sure I know how to do it; maybe I could create a new macports installation with instructions posted by Jeremy a while ago). I just said that using clang-3.4 doesn't help as that doesn't support all c++11 features

Re: Building clang/cling 3.5 for ROOT on Lion

PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full c++11 support. However, upstream claim to be targeting 10.8 and 10.9, so I would hope

Re: Building clang/cling 3.5 for ROOT on Lion

On 08/04/14 13:35, Ryan Schmidt wrote: On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9. As a general point, I agree, only OSX10.9 has full

Re: Building clang/cling 3.5 for ROOT on Lion

On 08/04/14 13:41, Joshua Root wrote: On 2014-4-8 22:35 , Ryan Schmidt wrote: On Apr 8, 2014, at 07:34, Chris Jones wrote: PS: It's not an issue of me personally upgrading the OS. I'll do that sooner or later. But it would be slightly suboptimal if the port only worked on 10.9

Re: Building clang/cling 3.5 for ROOT on Lion

On 08/04/14 13:52, Mojca Miklavec wrote: On Tue, Apr 8, 2014 at 2:46 PM, Chris Jones wrote: Thats OK for a standalone build, but the whole point of having root in macports is to pick up various dependencies from Macports. This trick would then only work if the user built all

Re: Building clang/cling 3.5 for ROOT on Lion

I'll see if I can manage to build the whole ROOT 6 with -stdlib=libc++ (without referencing any other piece from MacPorts). But that probably means that I shouldn't use OpenGL from the system, right? Don't forget, you will also need to rebuild each and every port that root uses, that uses a

Re: Building clang/cling 3.5 for ROOT on Lion

SO unless MacPorts is planning on switch its 10.8 builds to by default use libc++, this doesn't help much with getting the port working on 10.8 At this time, we believe it is best to leave 10.8 and earlier on libstdc++, and use libc++ on 10.9 and later. There is a FAQ entry… Yes of

wildcarding port select files to install ?

Hi, Is it possible to wildcard the files in a XYZ_select port, so that all the files that match the wildcard are installed when a version is selected ? In particular with https://trac.macports.org/browser/users/mojca/ports/sysutils/root_select we would like some way to just have root_select

Root port update

Hi, Could i ask a commitor to take a look at https://trac.macports.org/ticket/42867 It updates root to a new version, that fixes compilation with the latest Xcode 5.1 on OSX 10.9, so it would be useful to get it out quickly. Cheers Chris ___

Re: buildbot and binary archives ...

Hi, The first thing you should check is if the license in the Port file allows for the binaries to be distributed ? Chris On 20/02/14 14:54, Peter Danecek wrote: Hi all, from a user report I realised that there is probably no binary archive available for Maverick of one port I am

Re: C++11 on Mountain Lion and lower?

Hi, - The only C++ runtime that Apple provides on all systems since 10.5(?) is the one delivered with gcc 4.2.1. I really doubt that Apple will change that to a recent libc++ You are wrong on this point. Apple have been abandoning gcc in favour of clang/LLVM over the last few OSX

Re: C++11 on Mountain Lion and lower?

On 04/12/13 11:48, Titus von Boxberg wrote: Am 04.12.2013 11:00, schrieb Chris Jones: Hi, On OSX Macports explicitly links using the libc++ runtime, where as on older releases it This is exactly why c++11 code is fine on OSX10.9, as the default compiler libc++ used there supports

Re: C++11 on Mountain Lion and lower?

Hi, On 04/12/13 12:01, Ryan Schmidt wrote: On Dec 4, 2013, at 05:29, Clemens Lang wrote: Obviously C++11 support is a problem we're going to face sooner or later. It is a problem now and I don't think just avoiding C++11 on older systems is going to cut it. I’m not entirely opposed to that

Re: C++11 on Mountain Lion and lower?

Hi, you dropped the last text block from my mail where I said that I think that macports shouldn't care much about users using macports libraries for their own software. I very much disagree here. MacPorts is *not* just about providing a bunch of applications for users to run, but also about

Re: C++11 on Mountain Lion and lower?

Hi, On 4 Dec 2013, at 09:14 pm, Ned Deily n...@acm.org wrote: In article 529f1c08.4000...@hep.phy.cam.ac.uk, Chris Jones jon...@hep.phy.cam.ac.uk wrote: 10.6 is perhaps slightly different in that it is the last release to support PowerPC applications. Maybe some users have a need

Re: C++11 on Mountain Lion and lower?

Hi, On 5 Dec 2013, at 12:22 am, Clemens Lang c...@macports.org wrote: On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote: Of the system libraries in /usr/lib/system, only a single one exports C++ symbols (and that seems to be related to kernel extension stuff). I haven't checked

Re: C++11 on Mountain Lion and lower?

Hi, I am not an expert, but based on the discussion in https://trac.macports.org/ticket/39975 my understanding is there is no easy way to enable c++11 on systems older than 10.9 using the current MacPorts release. You need to use the libc++ runtime by default everywhere, not, libstdc++, and

ROOT update to work around FreeType issue

Hi, Could someone with commit access take a look at. https://trac.macports.org/ticket/41572 ? It adds a work around for an issue ROOT has with the recent FreeType 2.5.1 update. Not yet really clear where the issue lies, but my bet is with ROOT itself, so this work around (which is to revert

Re: Detect OS upgrades and refer users to Migration

On 17 Nov 2013, at 06:06 pm, Landon Fuller land...@macports.org wrote: On Nov 4, 2013, at 20:06 , Ryan Schmidt ryandes...@macports.org wrote: ... we’d really prefer them to uninstall and reinstall all ports. Users *really* (and rightfully) hate this, especially when there aren't

Re: Detect OS upgrades and refer users to Migration

On 17 Nov 2013, at 07:22 pm, Landon Fuller land...@macports.org wrote: On Nov 17, 2013, at 14:02 , Chris Jones jon...@hep.phy.cam.ac.uk wrote: Yes, there are. For instance the change in the default c++ runtime from libstdc++ to libc++ with OSX 10.9. These two runtimes cannot reliably

Re: port update (ROOT - Support for OSX10.9)

Hi, Sorry to pester, but i would be grateful if a commiter could take a look at the two tickets below. Cheers chris On 1 Nov 2013, at 09:59 pm, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, p.s. Could a commuter also take a look at. https://trac.macports.org/ticket/40949 its

port update (ROOT - Support for OSX10.9)

Hi, Could I ask a committer to take a look at https://trac.macports.org/ticket/41108 I know it hasn't been submitted for that long…. But it fixes build problems the current port has with OSX 10.9, so it would be good to get it committed asap. Thanks in advance. cheers Chris smime.p7s

Re: port update (ROOT - Support for OSX10.9)

Hi, p.s. Could a commuter also take a look at. https://trac.macports.org/ticket/40949 its needed to fix the pythia variant of ROOT. cheers Chris On 1 Nov 2013, at 5:12pm, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, Could I ask a committer to take a look at https

Re: Recommended permissions and ownership of Subversion checkout of dports

I am aware (and so should you be), that these files are editable by my user account and contain code that will be run with super user privileges – so if you're concerned about possible privilege escalations, you should create the checkout as root (which also implies you need root privileges to

Re: CMake warning wrt frameworks during configure phase on Snow Leopard

Hi, The suggested fix in http://bugs.python.org/issue14018 is to manually fix the symlinks in /Developer/SDKs/MacOSX10.6.sdk … ! Hmmm… I don't know what and how to fix this. Any guide that is telling you to manually start fiddling with sym links in system areas, is a guide you should

Re: Fortran recipe

Huddleston Sequoia jerem...@macports.org wrote: On Aug 25, 2013, at 13:53, Chris Jones jon...@hep.phy.cam.ac.uk wrote: Hi, On 25 Aug 2013, at 7:22pm, Christoph Deil deil.christ...@gmail.com wrote: On Aug 25, 2013, at 10:44 AM, Mojca Miklavec mo...@macports.org wrote: On Sun, Aug 25

Re: Fortran recipe

Hi, For the science/root port, the reason the port provides variants to use various gcc (and clang) compilers is not really because of fortran. ROOT provides an interactive build environment, and that environment is based on the compiler used to build ROOT. As such the user might have a reason

Re: Fortran recipe

Hi, On 25 Aug 2013, at 6:44pm, Mojca Miklavec mo...@macports.org wrote: On Sun, Aug 25, 2013 at 5:16 PM, Jeremy Huddleston Sequoia wrote: Seeing as how many developers don't understand the problems surrounding mixing multiple versions of the C++ runtime in a single process, I doubt that

Re: Fortran recipe

Hi, On 25 Aug 2013, at 07:29 PM, Ryan Schmidt ryandes...@macports.org wrote: On Aug 25, 2013, at 12:56, Chris Jones wrote: Its not clear to me if we also need to remove the variants that build with Macports clang. As I understand things these aren't affected by the c++ runtime issues

Re: Fortran recipe

Hi, On 25 Aug 2013, at 07:50 PM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: On Aug 25, 2013, at 11:29, Ryan Schmidt ryandes...@macports.org wrote: On Aug 25, 2013, at 12:56, Chris Jones wrote: Its not clear to me if we also need to remove the variants that build

Re: Fortran recipe

On 25 Aug 2013, at 8:04pm, Jeremy Huddleston Sequoia jerem...@macports.org wrote: On Aug 25, 2013, at 11:54, Chris Jones jon...@hep.phy.cam.ac.uk wrote: I suggest that your +cocoa variants use compiler.whitelist macports-clang-3.2 macports-clang-3.1 to force one of those compilers

Re: Fortran recipe

On 25 Aug 2013, at 8:14pm, Ryan Schmidt ryandes...@macports.org wrote: On Aug 25, 2013, at 13:51, Chris Jones wrote: On 25 Aug 2013, at 07:29 PM, Ryan Schmidt wrote: On Aug 25, 2013, at 12:56, Chris Jones wrote: Its not clear to me if we also need to remove the variants that build

Re: Fortran recipe

On 25 Aug 2013, at 8:17pm, Ryan Schmidt ryandes...@macports.org wrote: On Aug 25, 2013, at 14:15, Chris Jones wrote: So now I have PortGroup compiler_blacklist_versions 1.0 # Force a compatible clang compiler compiler.blacklist-append {clang 425} compiler.fallback-append

Re: Fortran recipe

Hi, On 25 Aug 2013, at 8:09pm, Mojca Miklavec mo...@macports.org wrote: On Sun, Aug 25, 2013 at 8:54 PM, Chris Jones wrote: On 25 Aug 2013, at 07:50 PM, Jeremy Huddleston Sequoia wrote: I suggest that your +cocoa variants use compiler.whitelist macports-clang-3.2 macports-clang-3.1

Re: Fortran recipe

Thanks, it wasn't clear to me something as simply as that was going to work ! On 25 Aug 2013, at 8:24pm, Lawrence Velázquez lar...@macports.org wrote: On Aug 25, 2013, at 3:17 PM, Ryan Schmidt ryandes...@macports.org wrote: On Aug 25, 2013, at 14:15, Chris Jones wrote: So now I have

Re: Fortran recipe

Hi, There is. http://trac.macports.org/changeset/104174 Is this in the latest release, or only available in the trunk for the moment ? vq smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list

  1   2   >