Re: fetching a generated patch from github

On Jun 2, 2015, at 1:58 PM, René J.V. Bertin wrote: > Is there a way to get a patchfile from github other than in a pre-patch or > post-fetch step with a statement like > > wget "https://github.com/user/repo/compare/hashA...hashB.patch"; You should be able to do something like this. patch

Re: dylib paths

On Jun 2, 2015, at 1:42 PM, Sterling Smith wrote: > I am trying to create a port for the MDSplus library. I have beat the > library’s make process into submission to make use of DESTDIR and other > standard directories. So now it creates several dylibs and executables in > the proper directo

Re: cloudflare/zlib on OS X

On Jun 2, 2015, at 4:40 AM, René J.V. Bertin wrote: > Do you verify that with every bit of code that is available through MacPorts? We make reasonable attempts to make sure that the legal business is kosher. > I'm sorry, but you're making a way too big fuss out of this. The modified > code is

Re: cloudflare/zlib on OS X

n Monday June 01 2015 18:00:29 Lawrence Velázquez wrote: > >> Where do they explicitly license their contributions under the zlib license? > > They don't explicitly change the licensing of the files they modify. If those > files each carry a zlib license they will still carr

Re: cloudflare/zlib on OS X

On Jun 1, 2015, at 5:11 PM, René J.V. Bertin wrote: > I was (most likely) right: without that 1 file with a GPL license the > CloudFlare patches won't change the zlib license. Where do they explicitly license their contributions under the zlib license? vq __

Re: [136885] trunk/dports/devel/cableswig/Portfile

Well that's embarrassing. Now we're even, after the libjpeg-turbo / muniversal business :P :P vq > On May 29, 2015, at 1:18 AM, ryandes...@macports.org wrote: > > Revision > 136885 Author > ryandes...@macports.org Date

Re: how to: meta-package port

On May 28, 2015, at 11:48 AM, René J.V. Bertin wrote: > What was the magic formula again to use in a meta-package port that only > exists to pull in (depend on) a number of other ports? Just supported_archs > noarch together with an error message in the pre-fetch? Install some dummy files inst

Re: [136794] trunk/dports/_resources/port1.0/group/select-1.0.tcl

This may require some revbumps. I'll work on that tomorrow. vq Sent from my iPhone > On May 27, 2015, at 3:03 AM, lar...@macports.org wrote: > > Revision > 136794 > Author > lar...@macports.org > Date > 2015-05-27 00:03:53 -0700 (Wed, 27 May 2015) > Log Message > > select-1.0: Don't overwrite `

Re: [136684] trunk/dports

On May 24, 2015, at 1:42 PM, Joshua Root wrote: > >> Revision: 136684 >> https://trac.macports.org/changeset/136684 >> Author: jwa at macports.org >> Date: 2015-05-23 22:41:08 -0700 (Sat, 23 May 2015) >> Log Message: >> --- >> python27: version bump of python27 and friends

Re: [136505] trunk/dports/graphics/vips/Portfile

So now a default vips install requires both Python 2.7 and Python 3.4? This is unnecessary and confusing. You should select just one variant as the default, if any. vq > On May 19, 2015, at 7:49 PM, bgilb...@macports.org wrote: > > Revision > 136505

Re: [136318] trunk/dports/devel/autoconf/Portfile

On May 14, 2015, at 3:43 PM, David Evans wrote: > I understand what you're saying, but this seems to me to be in the > category of fixing things that aren't broken. In addition, it > complicates maintenance by opening us up to perl version specific > problems on the various platforms, particular

Re: [136296] trunk/dports/math/liblinear/Portfile

Now users who had +python33 installed will upgrade and suddenly have +python27 instead. This will also happen for libsvm (r136297). I added the legacy variants to provide an upgrade path. They should be left there for a year to provide a reasonable upgrade window; I even noted the end of the wi

Anyone know what version of Perl comes with Tiger? (eom)

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

Re: [136023] trunk/dports/python/py-protobuf/Portfile

Ports should not download anything at build time. Can this be fixed? vq > On May 9, 2015, at 4:21 PM, bl...@macports.org wrote: > > Revision > 136023 Author > bl...@macports.org Date > 2015-05-09 13:21:21 -0700 (Sat, 09 May 2

Re: [136002] trunk/base/doc/porthier.7

On May 9, 2015, at 11:33 AM, Peter Danecek wrote: > I committed, this change, because it will be effective only after release and > it is probably the only reason why ports use that path to install examples in > the first place. I am not aware of any other document mentioning it. > BTW: Does t

Re: [136002] trunk/base/doc/porthier.7

On May 9, 2015, at 11:18 AM, Lawrence Velázquez wrote: > Why? Some ports still install to share/examples. Never mind, just saw #23280. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listi

Re: [136002] trunk/base/doc/porthier.7

Why? Some ports still install to share/examples. vq > On May 9, 2015, at 7:33 AM, p...@macports.org wrote: > > Revision > 136002 Author > p...@macports.org Date > 2015-05-09 04:33:18 -0700 (Sat, 09 May 2015) > Log Message >

Re: avoid usage of Macport installed software

On May 7, 2015, at 12:52 PM, Brandon Allbery wrote: > On Thu, May 7, 2015 at 12:48 PM, petr <9...@ingv.it> wrote: > >> 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

Re: [135847] trunk/dports/science/volk

On May 6, 2015, at 8:49 PM, Michael Dickens wrote: > * MacPorts -does not guarantee- that libstdc++ will work for C++11 > support (when using any GCC or Clang); use of it is purely on a port by > port basis as to whether or not it will work. MacPorts will not formally > support this configuration

Re: [135847] trunk/dports/science/volk

On May 6, 2015, at 2:59 PM, Michael Dickens wrote: > But, I disagree with the comment on the next line: > {{{ > # As we only support libc++, clang is implicitly required. > }}} > Although we do not directly support libstdc++, it does work and is the > default for 10.8 and prior, which MacPorts do

Re: [135847] trunk/dports/science/volk

On May 6, 2015, at 1:09 PM, Michael Dickens wrote: > As for using the compiler_blacklist_versions, there is a line in the > cxx11 variant that reads: > {{{ >compiler.blacklist-append *gcc* {clang < 500} > }}} > > Isn't the 2nd part what this PortGroup is used for? Or, am I mistaken > her

Re: [135847] trunk/dports/science/volk

On May 6, 2015, at 2:31 PM, Lawrence Velázquez wrote: > On May 6, 2015, at 1:09 PM, Michael Dickens wrote: > >> As for using the compiler_blacklist_versions, there is a line in the >> cxx11 variant that reads: >> {{{ >> compiler.blacklist-append *gcc* {cl

Re: [135847] trunk/dports/science/volk

On May 5, 2015, at 2:49 PM, Ryan Schmidt wrote: > It doesn't look like you're using the capabilities of the > compiler_blacklist_versions portgroup here. Doesn't look like it, so the portgroup is unnecessary. > In the context of Tcl I'm unfamiliar with the "[3-6]" notation that you're > using

Re: Proper library version numbering

On May 2, 2015, at 8:09 PM, Joshua Root wrote: > On 2015-5-2 23:30 , Lawrence Velázquez wrote: > >> https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html#//apple_ref/doc/uid/TP40002013-SW2

Re: Proper library version numbering

On May 2, 2015, at 9:05 AM, Ryan Schmidt wrote: > But it's not totally clear to me what proper library versioning entails -- > what specifically I should be telling the developers of those projects to do > instead. There are too many different version numbers. For example: > > > $ port instal

Re: [135656] trunk/dports/_resources/port1.0/group/cxx11-1.0.tcl

On Apr 29, 2015, at 1:16 AM, Mihai Moldovan wrote: > Enclosing *gcc* is really to make sure nothing funny is going on with > globbing. There is no globbing. Tcl doesn't do willy-nilly filename expansion like shells do. vq ___ macports-dev mailing li

Re: Variants +clang3{0,1,2} ...

On Apr 25, 2015, at 5:49 AM, petr <9...@ingv.it> wrote: > To my understanding the +clang3{0,1,2} refer to clang-3.{0,1,2} respectively. Yup. > These clang ports are no obsolete. Yup. > However, there are still quite some ports around with these variants, so I > guess these clang3{0,1,2} varia

Re: [MacPorts] PortfileRecipes modified

On Apr 22, 2015, at 5:01 PM, MacPorts wrote: > Page "PortfileRecipes" was changed by pixi...@macports.org > Diff URL: > > Revision 84 > Changes: > ---8<--8<--8<--8<--8<--8<--8<--8< > I

Re: Ports not listed as outdated

On Apr 22, 2015, at 7:40 AM, Mojca Miklavec wrote: > Maybe I need to explain a bit more. > > I have a sparse SVN checkout configured as: > file:///Users/me/app/macports/trunk/dports [nosync] > > I used [nosync] because I'm often bitten by failures during svn > updates when my local changes

Re: standard way to require c++11?

On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia wrote: > On Apr 20, 2015, at 23:51, Mihai Moldovan 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

Re: port: new action_environment and/or environment mode

On Apr 14, 2015, at 4:59 PM, Lawrence Velázquez wrote: > the "environment" is already something specific to *nix. That is, the term "environment" already has a specific meaning in *nix. vq ___ macports-dev ma

Re: port: new action_environment and/or environment mode

On Apr 14, 2015, at 4:31 PM, Bradley Giesbrecht wrote: > I opened a ticket for this simple base patch: > https://trac.macports.org/ticket/47442 > > My knowledge of tcl and base is limited, I know my code needs cleanup and > tests. Looking for feedback to decide if I should continue. > > The go

Re: [135005] trunk/dports/x11/xinit/Portfile

On Apr 13, 2015, at 10:38 AM, Mihai Moldovan wrote: > The "problem" is that this is not a real "block" but a list element. > While a newline at the beginning is generally ignored by the notes base > code, newlines at the end are not. Not escaping a newline there is thus > leading to output like t

Re: [134918] trunk/dports/multimedia/mpv/Portfile

You should use our "copy" proc here as well, instead of "file copy". vq > On Apr 10, 2015, at 4:10 PM, io...@macports.org wrote: > > Revision > 134918 Author > io...@macports.org Date > 2015-04-10 13:10:54 -0700 (Fri, 10 Apr

Re: "port provides" inside a Portfile?

On Apr 5, 2015, at 9:56 PM, Michael Dickens wrote: > Thus, in the new volk Portfile, I need to set up a pre-extract check to > see if libvolk is already installed, and if so then which port owns it. > If a gnuradio* port owns it, then I have the Portfile error out, telling > the user to force dea

Re: Changing port group default options

On Mar 31, 2015, at 1:05 PM, Mojca Miklavec wrote: > In my opinion increasing the version of the portgroup should be > reserved for (fundamentally) incompatible changes or when the syntax > changes. This is just changing the question to "what's an 'incompatible' change?". Permitting portgroups

Re: Changing port group default options

On Mar 31, 2015, at 11:12 AM, Rainer Müller wrote: > In my opinion, changes to the default behavior of port group options > should be introduced with an increment of the port group version. > > In this case, it would have worked like this: > > 1. Add a new port group cmake-1.1.tcl with > 'def

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

On Mar 27, 2015, at 9:20 AM, Mojca Miklavec wrote: > On Fri, Mar 27, 2015 at 12:33 PM, Chris Jones wrote: >> >> IMHO, if upstream have 'officially' dropped support for OSX10.6, then this >> is not something MacPorts ports should second guess, so my preference would >> be for the 3rd option, just

Re: Transient problems with MacPorts Trac

On Mar 23, 2015, at 8:44 AM, Clemens Lang wrote: > I'm seeing database connection problems with trac on every second or so page > load. Don't know if this is related, but the Trac log has not been updated in 12 hours; the last revision I see is r134330. https://trac.macports.org/log https://t

Re: [134311] trunk/dports/devel/hub/Portfile

On Mar 22, 2015, at 12:23 AM, Mihai Moldovan wrote: > On 22.03.2015 02:25 AM, Ryan Schmidt wrote: > >> The best way to clear the build.target (or any option) is to simply not give >> a value, e.g. by writing just: >> >> build.target > > FWIW, I disagree here. Not giving it a value could, for

Re: [134288] trunk/dports/sysutils/pidof/Portfile

On Mar 21, 2015, at 4:43 PM, Ryan Schmidt wrote: > If you use "use_configure no", you're indicating to MacPorts that this port > uses something that isn't anything like autoconf, so that default universal > variant goes away, and you get to program one yourself. This implies that "use_configur

Re: determining the how and why of a port dependencies

> On Mar 21, 2015, at 6:48 AM, René J.V. Bertin wrote: > > I was very surprised to see unexpected dependencies like port:gtk3 and > port:llvm-35 appear in the (long) list. Is there a way to figure out what > leads to these dependencies? $ port rdeps kde4-baseapps and $ port rdeps --full kde4

Re: [134216] trunk/dports/science/kst/Portfile

You should probably use destroot.dir (or cmake.build_dir, if that's more obvious) in the post-destroot script instead of hard-coding "${workpath}/build". vq > On Mar 20, 2015, at 9:57 AM, ni...@macports.org wrote: > > Revision > 134216 Author > ni...@

bison @3.0.4 and postgresql7

Hi, Can anyone with a PowerPC machine test whether postgresql7 builds successfully with current bison (@3.0.4_0), and send me the log if not? Thanks, vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailma

Re: standard way to require c++11?

On Mar 19, 2015, at 1:56 PM, Michael Dickens wrote: > On Thu, Mar 19, 2015, at 01:54 PM, 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

Re: [134167] trunk/dports/lang/falcon/Portfile

You should probably use build.dir here, instead of hard-coding "${workpath}/build". vq > On Mar 19, 2015, at 12:27 PM, s...@macports.org wrote: > > Revision > 134167 Author > s...@macports.org Date > 2015-03-19 09:27:00 -0700

Trac is back (eom)

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

MacPorts Trac looks down (eom)

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

Re: [GSoC] I'm interested in participating and need some guides

On Mar 18, 2015, at 5:37 PM, Clemens Lang wrote: >> Currently, I am interested in two potential ideas: >> 1. Improve fetching from version control > > I think there's a ticket for the first one somewhere in our bugtracker > with a couple of ideas. I don't have the link handy, but maybe somebody

Re: [134068] trunk/dports/python

I reverted this in r134069 . The gdbm module is part of the Python standard library so we should not retire any of its subports until we actually remove the relevant CPython port. vq > On Mar 17, 2015

Re: Death of Google Code

On Mar 13, 2015, at 2:03 PM, Ryan Schmidt wrote: > On Mar 13, 2015, at 12:46 PM, Mark Anderson wrote: > >> Do we have any idea what we need to do/should do to prepare for the >> eventual shutdown of google code? I know a lot of stuff has been >> abandoning it, but I feel like we've got quite a f

Re: ccache imposes sudo for configure?

On Mar 12, 2015, at 1:40 PM, René J.V. Bertin wrote: > can someone explain to me why it is that setting `configureccache yes` > in macports.conf makes it obligatory to do `port configure` via sudo > (with an error if that is not the case)? The ccache setup assumes that $macportsuser is not the s

Re: [133744] trunk/dports/textproc/libxml2/Portfile

On Mar 10, 2015, at 11:43 AM, Andrea D'Amore wrote: > On 10 March 2015 at 13:50, Ryan Schmidt wrote: >> For future reference, since this does not change the way that the port >> installs by default, the revision should not have been increased. > > I stood by the rule to bump revision if instal

Re: port upgrade outdated order

On Mar 4, 2015, at 1:59 PM, René J.V. Bertin wrote: > @ larry >> Base doesn't have a concept of equivalence. It doesn't know that qt5-mac and >> qt5-mac-devel are interchangeable. We could implement virtual ports or >> something like that, but that's a rather larger project. > > Would be more li

Re: port upgrade outdated order

On Mar 4, 2015, at 11:52 AM, René J.V. Bertin wrote: > On a related note: it'd be nice if MacPorts could be a little bit more > proactive in deactiving conflicting ports. Like when installing a subport > that conflicts with one of its siblings. If both are at the same version I > don't see why

Re: [132916] distfiles

On Mar 3, 2015, at 3:00 AM, Ryan Schmidt wrote: >> On Feb 13, 2015, at 2:53 AM, jerem...@macports.org wrote: >> >> Revision >> 132916 >> Author >> jerem...@macports.org >> Date >> 2015-02-13 00:53:30 -0800 (Fri, 13 Feb 2015) >> Log Message >> >> Move large ld64 patch to distfiles >> Added Paths

Re: port upgrade outdated order

On Mar 3, 2015, at 6:50 PM, René J.V. Bertin wrote: > On Tuesday March 03 2015 17:01:08 Daniel J. Luke wrote: > >>> Is there a way to influence the order in which (sub)ports are upgraded? >> >> upgrade works in dependency order > > And for when the dependencies are identical? As far as I know

Re: [133173] trunk/dports/mail/alpine/Portfile

On Mar 2, 2015, at 2:12 AM, Ryan Schmidt wrote: > without_tcl is a legacy variant so it seems like there shouldn't be any cases > when it is enabled by default. But without_tcl used to be the only default variant. So if I don't continue enabling it by default, the next conditional… if {![

Removing negative variants from alpine (Was: [MacPorts] #38091: alpine @2.00_4: update to 2.11)

On Feb 25, 2015, at 9:49 PM, MacPorts wrote: > #38091: alpine @2.00_4: update to 2.11 > ---+-- > Reporter: larryv@… | Owner: john@… > Type: update| Status: closed > Priority: Normal| Milestone: > Component: ports |Ver

Re: circular dependencies

On Feb 23, 2015, at 10:18 AM, René J.V. Bertin wrote: > Ugh. Just make it optional (as in "can be turned off"), ok? ... I don't see us ever making trace mode mandatory, but we would eventually like to make it the default mode of operation. And if a port fails to build under trace mode, we cons

Re: undo commit ???

On Feb 20, 2015, at 4:34 AM, petr <9...@ingv.it> wrote: > I saw that in r132950 and r132951 you corrected the error I introduced > with r132349. Thanks for this and sorry for the extra effort! No worries. > However, I would like to better understand what went wrong and how am > I supposed to act

Re: circular dependencies

> On Feb 20, 2015, at 1:46 AM, René J.V. Bertin wrote: > > Is there any support in MacPorts for circular dependencies (as far as such a > thing is possible)? No. A port’s dependency graph must be acyclic. > I'm building the freetype +infinality version with harfbuzz support, which > depends o

Re: Wrong information displayed in some trac pages

On Feb 15, 2015, at 6:34 AM, Davide Liessi wrote: > Is there a way to fix that commit? Subversion commits are immutable as far as we're concerned, but I just did a reverse merge to restore the old history to the path in question. Please verify that py-python-poppler-qt4's history is now in the

Re: [MacPorts] #46844: help2man: add support for perl5.{16,18,20}

> On Feb 13, 2015, at 3:47 AM, MacPorts wrote: > > #46844: help2man: add support for perl5.{16,18,20} > ---+--- > Reporter: Mathias.Laurin+macports.org@… | Owner: macports- > Type: enhancement| t

Re: files automatically excluded from the destroot dir and installation

On Feb 11, 2015, at 10:52 AM, René J.V. Bertin wrote: > Does it also remove files that should never make it into an installer tarball? Not that I'm aware of. If for some unfathomable reason a build system installs a .DS_Store, you should report that as a bug. vq ___

Re: memberlist

On Feb 10, 2015, at 6:24 PM, Lawrence Velázquez wrote: > It scans the Cc list for the addresses of list members who don't want dups > and simply doesn't deliver anything to those addresses. Ergh. It also scans the "To" header. vq __

Re: memberlist

On Feb 10, 2015, at 6:02 PM, Ryan Schmidt wrote: > If by "it" you mean Mailman, then as far as I know, it does nothing to > deduplicate your mail. It sends the messages it has been instructed to send. > So if a message is addressed To a mailing list you're subscribed to, and Cc'd > to you, the

Re: MacPorts forum(s)? (was: Re: memberlist)

On Feb 10, 2015, at 5:29 PM, René J.V. Bertin wrote: > I see them as complementary. Some people prefer mailing lists, others like > myself prefer to keep their incoming mail as few as possible. "Complementary" implies that the items in question reinforce each other in a positive manner. Havin

Re: MacPorts forum(s)? (was: Re: memberlist)

On Feb 10, 2015, at 12:43 PM, René J.V. Bertin wrote: > To kick off the discussion: has a MacPorts forum site ever been taken into > consideration Not since I've been paying attention, which has been a few years. > if so, what were the reasons not to provide one (a summary would be fine)? I p

Re: memberlist

On Feb 10, 2015, at 8:01 AM, René J.V. Bertin wrote: > Would it be possible to give members of the list access to the memberlist Technically, yes. Mailman allows the list administrators to change the visibility of the subscribers list.[1] Practically, there's no need to broaden this visibility

Re: [132594] trunk/dports/science/demeter/Portfile

On Feb 5, 2015, at 10:50 PM, Ryan Schmidt wrote: > On Feb 5, 2015, at 11:39 AM, lar...@macports.org wrote: > >> +# latest tagged release is the stable one. (3 Feb 2015) >> subport demeter-devel { >> -github.setupbruceravel demeter 0.9.20pre10 >> +github.setupbruceravel de

Re: openssl nomaintainer :( [was Re: [132564] trunk/dports/devel/openssl/Portfile]

On Feb 5, 2015, at 11:02 AM, Daniel J. Luke wrote: > I've been running this for the past day and haven't noticed any issues (or > had anyone complain about it yet). I've taken over maintainership, added Clemens as co-maintainer, and pushed 1.0.2. http://trac.macports.org/log/trunk/dports/deve

Using Xcode toolchain internals (Was: apple clang vs macports clang performance)

On Jan 28, 2015, at 5:58 PM, René J.V. Bertin wrote: > Really now, even if that's true for the other stuff in there, it > shouldn't be for libclang Says who? Apple can reserve that particular library for internal use if it wants. (This doesn't mean that you *cannot* use it, it means that it's a

Re: how about a port containing the missing bits from Apple's LLVM toolchain?

On Jan 28, 2015, at 2:22 PM, René J.V. Bertin wrote: > On Wednesday January 28 2015 10:56:32 Jeremy Huddleston Sequoia wrote: > >>> Would it at least be possible to expand on that. In other words, why? >> >> There are no shipped libraries for you to link against for the headers >> to be worthwh

Re: how about a port containing the missing bits from Apple's LLVM toolchain?

On Jan 28, 2015, at 1:17 PM, René J.V. Bertin wrote: > The standard variant for llvm, to have binary packages, and apparently a > locally built clang to skip the arm_runtime. As far as I can tell that didn't > include assertions. Pre-release llvm-* ports enable +assertions by default. If you i

Re: Cutting down on python versions

On Jan 23, 2015, at 3:22 PM, Jeremy Lavergne wrote: > Joshua pointed it out in a previous thread: we don't make use of other > package managers (Pip in this instance), so we shouldn't have their > packages in MacPorts unless they have requisites in MacPorts. Ohh, I see. Well that's not the axe

Re: Infinality patches and pango/cairo's +quartz variant

On Jan 23, 2015, at 8:52 PM, René J.V. Bertin wrote: > Cairo and pango have both been changed to force +quartz. Why is that? See #44414. I think the eventual goal is to remove the `quartz` variant and enable that backend on OS X always. This will simplify the ports and, more importantly, depen

Re: Cutting down on python versions

On Jan 23, 2015, at 3:13 PM, Jeremy Lavergne wrote: > Will your update include our stance on including all python packages > versus only c-modules (or otherwise needing MacPorts' involvement)? I'm not sure what you mean. vq ___ macports-dev mailing li

Re: Cutting down on python versions

On Jan 23, 2015, at 2:52 PM, Adam Mercer wrote: > I recall there being an effort to cut down the number of python ports, > what is the status of this Close to completion. I've been meaning to send out a status update but haven't gotten around to it. > and what python versions are we aiming to s

Re: PowerPC ld64 on Snow Leopard (Was: depends_run should ignore +/- universal?!)

On Jan 23, 2015, at 2:16 AM, Jeremy Huddleston Sequoia wrote: > No, that's expected. If ppc is desirer, we should have 127.2. Right. I meant "worse" in the sense of "more confusing", as far as the port itself goes. > I think the best solution would probably be similar to the perl port. We

Re: PowerPC ld64 on Snow Leopard (Was: depends_run should ignore +/- universal?!)

On Jan 23, 2015, at 2:12 AM, Jeremy Huddleston Sequoia wrote: > ld64 and cctools have been that way for years without issue. Only recently > did I remove that in an effort to make the versioning of those ports less > complicated. See: > > https://trac.macports.org/changeset/131487 Huh, int

Re: PowerPC ld64 on Snow Leopard (Was: depends_run should ignore +/- universal?!)

On Jan 23, 2015, at 1:33 AM, Lawrence Velázquez wrote: > My last change dropped ld64 +universal to v127.2 Rather, it changed the version if a PowerPC build were requested in any way. So that's probably even worse. vq ___ macports-dev mail

PowerPC ld64 on Snow Leopard (Was: depends_run should ignore +/- universal?!)

On Jan 22, 2015, at 10:45 PM, Ryan Schmidt wrote: > I don't think we ever intended the version to be changed inside a variant. I > would consider it a maintainer error to do so. I don't think the portindex > accommodates more than one version per port, and the portindex is used to > determine

Re: depends_run should ignore +/- universal?!

On Jan 21, 2015, at 5:10 PM, René J.V. Bertin wrote: > The situation is this: Infinality are patches that improve rendering but > don't change anything else. So a variant is the logical way to go, as it > won't break dependencies. Sure. > Those patches evolve, and thus have a version number,

Re: depends_run should ignore +/- universal?!

On Jan 21, 2015, at 1:13 PM, René J.V. Bertin wrote: > The freetype +infinality variant will have a runtime dependency > freetype-infinality, a (sub)port that serves mostly to introduce the > versioning information for the Infinality patches, but also installs a few > text files. This sounds

Re: Forcing a recompilation of an installed port without uninstalling

On Jan 20, 2015, at 3:18 PM, René J.V. Bertin wrote: > On Tuesday January 20 2015 14:34:30 Lawrence Velázquez wrote: > >> `port upgrade --force` is basically a `port install` that's interrupted >> between the install and activate phases by the deactivation of the old po

Re: Forcing a recompilation of an installed port without uninstalling

On Jan 20, 2015, at 3:15 PM, René J.V. Bertin wrote: > On Tuesday January 20 2015 14:22:23 Lawrence Velázquez wrote: > >> And `port upgrade` preserves the variant selection of the >> currently-installed port, while the other subcommands do not. > > Hmm, how? By looki

Re: Forcing a recompilation of an installed port without uninstalling

On Jan 20, 2015, at 7:08 AM, René J.V. Bertin wrote: > On Tuesday January 20 2015 00:08:42 Ryan Schmidt wrote: > >> "sudo port -n upgrade --force" is the invocation you're looking for. >> "--force" forces the upgrade, even if MacPorts thinks the port is up to date >> while "-n" prevents MacPor

Re: automatic port clean

On Jan 20, 2015, at 7:05 AM, René J.V. Bertin wrote: > What's bad about asking for confirmation when that's an option the user has > to activate in macports.conf? Heck, the request could even be skipped when > doing `port upgrade` so that common workflows continue to flow without > interventio

Re: Forcing a recompilation of an installed port without uninstalling

On Jan 20, 2015, at 7:08 AM, René J.V. Bertin wrote: > Does `upgrade` work like `install` would if you have just done a manual > destroot? `port destroot` does not actually install anything, so no. And `port upgrade` preserves the variant selection of the currently-installed port, while the o

Re: path depends with wildcard?

On Jan 20, 2015, at 12:25 PM, Michael Dickens wrote: > I've been working on getting a "swig-devel" port up and running, and it > works locally for me. But in order to use it (e.g., > "swig-python-devel"), I need to specify dependencies using a wildcard > because we don't know the SWIG version. Fo

Re: about uninstalling bits from a previous version to build a new version

On Jan 19, 2015, at 6:01 AM, René J.V. Bertin wrote: > As I mentioned before, Qt 5.4.0 has an issue building if Qt 5.3.2 is present > in the destination: one of its components includes the target header path in > the compiler header search path list, and then chokes when it includes a > header

Re: qt5- prefix

On Jan 17, 2015, at 4:09 AM, René J.V. Bertin wrote: > On Saturday January 17 2015 00:14:09 Mojca Miklavec wrote: > >> I don't know what exactly QtCurve does, so I find it a bit difficult >> to judge to which category it belongs and whether a prefix is >> justified in that case. > > It's a them

Re: qt5- prefix

On Jan 17, 2015, at 4:09 AM, René J.V. Bertin wrote: > There's a difference between ports for which Qt represents an optional > dependency, and ports that cannot live without it. Let's face it, a Qt app > isn't so very different from a Python or Perl app: it simply extends what the > base tech

Re: qt5- prefix

On Jan 16, 2015, at 5:09 PM, René J.V. Bertin wrote: > On Friday January 16 2015 16:43:45 Lawrence Velázquez wrote: > >> A buildslave will not provide archives that a user could not compile >> themselves. > > So the buildslaves for 10.6 run 10.6 themselves? Yes. >

Re: qt5- prefix

On Jan 16, 2015, at 4:29 PM, René J.V. Bertin wrote: > Bit rot, in source code? Not literal rot, but as the operating system and developer tools move on, it gets more and more difficult to maintain older software that is not under active development. > I frankly don't see any reason to prefer

Re: libc++, C++11, and C++14 on Leopard and Snow Leopard

On Jan 15, 2015, at 1:25 PM, Mojca Miklavec wrote: > PowerPC aside (or included :), it would be really nice to have a few > extra buildbots for 10.6-10.8 (or maybe even 10.5 now that you got it > working) with libc++ being set by default to allow compiling C++11 > code. The archives don't encode

Re: MinGW-w64

On Jan 14, 2015, at 5:36 AM, Mojca Miklavec wrote: > a) install binutils (easy) > b) install headers (easy) > c) build gcc ("make [install] all-gcc" from GCC sources) > d) build crt (requires gcc) > e) build libgcc from gcc sources ("make [install] all-target-libgcc" > from GCC sources) > f) buil

Re: libc++, C++11, and C++14 on Leopard and Snow Leopard

On Jan 14, 2015, at 2:47 PM, Lawrence Velázquez wrote: > you cannot deactivate or install llvm-X.Y. *deactivate or uninstall vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: libc++, C++11, and C++14 on Leopard and Snow Leopard

On Jan 14, 2015, at 2:30 PM, René J.V. Bertin wrote: > Unless I misunderstand you, that doesn't make them dependent on LLVM. They > just cannot run what's not installed :) Are we still talking about MacPorts here? MacPorts enforces runtime dependencies; if you have cctools +llvmXY or ld64 +llv

<    1   2   3   4   5   6   7   8   9   >