Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

I just wanted to try out the new git setup to make sure things were working for me, and this was a simple little thing to do. On Mon, Oct 31, 2016 at 7:10 PM, Brandon Allbery wrote: > > On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez > wrote: > >>

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

heads/master by this push: new > 8ed388e berkeleygw: Remove svn $Id$ line.8ed388e is described below > commit 8ed388e541ce01d92d698791fefd72a4bd2448c9Author: David Strubbe > <dstru...@mit.edu> > AuthorDate: Mon Oct 31 18:48:04 2016 -0700 > berkeleygw: Remove svn $I

Re: nested port upgrading and variants

11:12:10 David Strubbe wrote: > > Hi David, > > > >used for a dependency. That's all it does. The only way I know of that you > >could make opencv get installed with +qt5 in this context is to do "port > >install kf5-digikam-devel +qt5" (whether that

Re: nested port upgrading and variants

Hi René, The purpose of the active_variants portgroup is to provide error messages like the one you mentioned, after checking whether a certain variant was used for a dependency. That's all it does. The only way I know of that you could make opencv get installed with +qt5 in this context is to do

Re: [154019] trunk/dports/science/LORENE

Also the last line is misspelled, I think you mean "place where you have write access". On Wed, Oct 19, 2016 at 7:35 PM, Ryan Schmidt wrote: > > > On Oct 18, 2016, at 7:01 AM, thib...@macports.org wrote: > > > > Revision > > 154019 > > Author > > thib...@macports.org >

Re: [153943] trunk/dports/science

> > > Le 17 oct. 2016 à 20:12, David Strubbe <dstru...@macports.org> a écrit : > > It appears libX11, in the LIB_PGPLOT variable, is used in principle to > compile some codes that are not in fact compiled in this package. It looks > like X11 is only in fact used via pgplot.

Re: [153943] trunk/dports/science

16, 2016, at 11:57 PM, David Strubbe <dstru...@macports.org> > wrote: > > > > Additionally, the dependency port:xorg-libX11 does not seem necessary: I > don't see any evidence in the build log that it is used, and the build > succeeds without it being active. > > Are

Re: port:lapack useful?

Hi Takeshi, Thanks for the response. On Mon, Oct 17, 2016 at 7:55 AM, Takeshi Enomoto wrote: > > * LAPACK from netlib is active. > I do not doubt that the netlib LAPACK is active -- this is of course the reference implementation that the vendors use in optimization. >

Re: [153943] trunk/dports/science

Additionally, the dependency port:xorg-libX11 does not seem necessary: I don't see any evidence in the build log that it is used, and the build succeeds without it being active. On Sun, Oct 16, 2016 at 5:23 PM, David Strubbe <dstru...@macports.org> wrote: > Hi, > > Let me add

port:lapack useful?

Hello Takeshi, I just noticed that you created a port lapack (including BLAS) in r146856. Is this really useful? We already have the ATLAS port which provides BLAS and LAPACK; the OpenBLAS port which provides exactly the same implementation of LAPACK from netlib as your port lapack; and the

Fwd: [MacPorts] #51724: compilers-1.0: default to gcc6

Hi all, Ryan has proposed moving to gcc6 as the standard default version of the GCC compiler, which would be done in the compilers portgroup. It sounds like a good idea to me. Does anyone see a problem with that with their ports that use the compilers portgroup? (If so, the default can always be

Re: [149308] trunk/dports/science/paraview/Portfile

Hi Ryan, The +testing variant of revision 2 is equivalent to no variant at revision 1. So, yes it does have an effect, of removing quite a lot of installed files that are unnecessary except for when testing. David On Sat, Jun 11, 2016 at 3:21 AM, Ryan Schmidt wrote: >

Re: Snow Leopard compilers

Thanks for the info, Mojca. I understand the situation now, though I would certainly be in favor of handling this more clearly in base as you outlined. That worked. (inevitably, it turns out clang-3.4 which was taken instead has its own different problem on that code...) David On Thu, Jun 9,

Snow Leopard compilers

Hi all, I am a bit confused about what is going on with selection of compiler on Snow Leopard for the apbs port. It is taking clang for C but llvm-g++-4.2 for C++, and the latter does not work for this port. If clang++ were used I think it would work. Why is that not being selected? Why is an

Re: Broken libgcc update

This is reported in this ticket: https://trac.macports.org/ticket/51245 On Thu, May 5, 2016 at 12:40 PM, Marius Schamschula wrote: > Hi all, > > Yesterday, r148332 updated libgcc and several versions of gcc. The build > bots failed to build these ports, and now my own

Re: variants

On Mon, Apr 11, 2016 at 4:42 PM, Daniel J. Luke wrote: > > The ideal port has no variants (or at least has only default variants) - > it builds with all reasonable options and people don't have to think about > it. > I agree, but the question is what to do when the port does

Re: variants

ior is correct. >> >> When a port is installed as a dependency of some other port, it should be >> installed the same way as if it were installed manually first. >> >> ie. A requires B: >> >> port install A >> and >> >> port install B &

Re: variants

Well, that is not the current behavior if a variant is specified manually. What happens is: port install A +var does port install B +var && port install A +var. Why do you think it would be inappropriate to do that for default variants? On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke

Re: variants

I'd like to second that. I think many issues of variant dependencies are helped by passing down both manually specified and default variants. David On Mon, Apr 4, 2016 at 10:44 AM, Takeshi Enomoto wrote: > Dear Ryan and Mojca, > > OK. So I see that this is not the problem

Re: CFITSIO's Fortran interface

Hi Sébastien and Ryan, The solution discussed here will solve the problem but is unnecessarily restrictive by using only +gcc5. What you should do is this line instead: compilers.enforce_some_fortran cfitsio Then any of the Fortran variants gcc5, g95, gcc49 etc. will be accepted. This is part

https fetch on buildbots?

Hi all, After making a commit to the port miriad, I find that the fetch fails on the buildbots like this ( https://build.macports.org/builders/buildports-mtln-x86_64/builds/27365/steps/compile/logs/stdio). Is there any inherent problem with fetching from an https site? Or, any suggestion on how

Re: [144607] trunk/dports/science/octopus/Portfile

Ok, thanks for the explanation. And the fix to my logic in the Portfile. David On Thu, Jan 14, 2016 at 8:14 AM, Ryan Schmidt <ryandes...@macports.org> wrote: > > On Jan 13, 2016, at 11:53 AM, David Strubbe wrote: > > > Oh ok. I have seen some ports have a revision incre

Re: [144607] trunk/dports/science/octopus/Portfile

Oh ok. I have seen some ports have a revision increased recently because of a change of default variants, so I was following that, but I guess they shouldn't have been. David On Wed, Jan 13, 2016 at 12:47 PM, Ryan Schmidt wrote: > > On Jan 13, 2016, at 11:45 AM, Ryan

Re: [144336] trunk/dports/science/silo/Portfile

Are you sure that is what this line meant? It is hard to believe that ccache could be related to this error message of illegal syntax in a Makefile. And, I just commented out the ccache line and the port seems to work fine without that line, or with configure.ccache yes. David On Sat, Jan 9,

build.args

Hi all, Is there a way to get the value of build.args in a Portfile? I would like to do something like pre-test { test.args-append ${build.args} } but there is no such variable. David ___ macports-dev mailing list

Re: [144426] trunk/doc-new/guide/xml/portfile-tcl.xml

Oops and thanks for the further clarifications. I have just updated it. David On Fri, Jan 8, 2016 at 5:02 PM, Joshua Root wrote: > > Revision: 144426 > > https://trac.macports.org/changeset/144426 > > Author: dstrubbe at macports.org > > Date: 2016-01-08

blitz-devel: Mercurial clone failed

Hi all, I just made an update (unrelated to fetching) to blitz-devel, a nomaintainer port, and got this error below from each buildbot, even though it worked fine on my machine. Anyone know what this is about? Thanks, David DEBUG: Executing org.macports.fetch (blitz-devel) DEBUG: Executing:

pymol-devel obsolete?

Hi all, I propose to make the port pymol-devel obsolete. There is a pymol port, which is a newer version of the same software. It is not clear what, if any, purpose pymol-devel serves, though years ago it was a newer version than the pymol port (no clear reason was stated at the time for why this

"port install" for subport

Hi all, If you are in the directory of a Portfile, you can use "port install" or "port install current" to install the port described by the Portfile. But what if the Portfile contains a subport? Is there a way to install the subport in this way? It would be helpful for testing purposes. Thanks,

Re: Warnings when parsing hdfeos5 Portfile

I added the warning. The use of mpi_active_variant_name in this Portfile apparently fails, so yes it should be changed in the Portfile to not trigger the warning. We had discussed this on the list about a month ago, regarding also the cdo and ncarg ports. David On Sun, Dec 20, 2015 at 11:03 AM,

Re: [141620] trunk/dports/math/netgen/Portfile

Ok, I changed it only because it was not working for me (at least at the time). David On Sat, Dec 12, 2015 at 5:24 AM, Ryan Schmidt wrote: > > > On Dec 12, 2015, at 4:18 AM, dstru...@macports.org wrote: > > > > Revision > > 141620 > > Author > > dstru...@macports.org >

Re: removing subport

from this port, because the conflict with the non-double port was not handled properly and so the double port failed to install. And I didn't see any tickets about it. David On Fri, Dec 11, 2015 at 7:29 PM, Ryan Schmidt <ryandes...@macports.org> wrote: > > On Dec 10, 2015, at 5:

removing subport

Hi all, I want to make the "gromacs-double" subport instead just a variant "gromacs +double" as I don't see any particular reason why both would need to be co-installed, and it seems clearer this way. How should one proceed for removing a subport, compared to the procedure for removing a port?

Re: Qt5 port unparsable: can't read "qt_archdata_dir": no such variable

Do 'svn revert' on it. On Mon, Nov 23, 2015 at 11:29 AM, Vincent Habchi wrote: > Ryan, > > > qt_archdata_dir should be set in the qt5 1.0 portgroup. Do you perhaps > have local modifications to this portgroup that are conflicting with the > official version? > > Bullseye!

Re: Owner of MacPorts account on GitHub

Yes, this is a pet peeve of mine. Try figuring out whether a ticket has been filed against the port "R" or not... It would be helpful to give the option in this context not to use regexes, so to check whether the port field is exactly "R" (or if separated into comma-delimited fields, one is

Re: Nonexistent mpi.default variable lets port upgrade fail

Discussed and resolved here: https://trac.macports.org/ticket/49669 David On Thu, Nov 12, 2015 at 3:33 AM, David Evans wrote: > On 11/11/15 11:36 PM, Marko Käning wrote: > > Ooops, what does this error suddenly happen? > > > > --- > > ---> Updating MacPorts base sources

platform

Hi all, Can someone explain what the meaning of the possible values of the 'platforms' variable are in a Portfile? Most ports seem to list 'darwin' but I have seen some that say 'macosx' or even 'puredarwin'. I understand the meaning of clearly different operating system designations such as

Re: Including port groups multiple times (was: Re: passing variants to dependencies; pre-activate check)

Hi Rainer, Do you have a suggestion of how to accomplish that? That could potentially be a simpler approach than adding include guards. If we do go with include guards, anyone want to comment on my particular implementation? Index: dports/_resources/port1.0/group/active_variants-1.1.tcl

Re: passing variants to dependencies; pre-activate check

ies. This comes from port1.0/portutil.tcl and should @@ -278,3 +284,5 @@ pre-activate { _check_require_active_variants activate } + +} On Tue, Oct 13, 2015 at 10:35 PM, Joshua Root <j...@macports.org> wrote: > On 2015-10-14 13:04 , David Strubbe wrote: > > > - W

Re: passing variants to dependencies; pre-activate check

Hi Josh, Thanks for the response. On Tue, Oct 13, 2015 at 8:26 PM, Joshua Root <j...@macports.org> wrote: > On 2015-10-14 04:53 , David Strubbe wrote: > > Can anyone help me with these questions? > > > > In short, I am wondering: > > - Why does 'port install xcr

Re: passing variants to dependencies; pre-activate check

quartz > :debug:activate required: x11, forbidden: > :debug:activate rejected, because required variant x11 is missing > :msg:activate Warning: tk must be installed with +x11. > :debug:activate Executing org.macports.activate (xcrysden) > :msg:activate ---> Activating xcrysden @1.5.

Re: passing variants to dependencies; pre-activate check

Executing org.macports.activate (xcrysden) :msg:activate ---> Activating xcrysden @1.5.60_1+gcc5 On Sat, Oct 10, 2015 at 11:33 PM, David Strubbe <dstru...@macports.org> wrote: > > > On Sat, Oct 10, 2015 at 10:34 PM, Joshua Root <j...@macports.org> wrote: > >> On 2015-

Re: passing variants to dependencies; pre-activate check

before activate. When I deactivate and re-activate, I don't see the message. My conclusion was that pre-activate was not being run in the latter case -- is there some other reason it wouldn't be written? David On Sat, Oct 10, 2015 at 7:06 PM, Joshua Root <j...@macports.org> wrote: > On

passing variants to dependencies; pre-activate check

port. Is there a way to get some code to run when activating a deactivated port? Thanks, David On Sun, Nov 16, 2014 at 6:40 PM, Lawrence Velázquez <lar...@macports.org> wrote: > On Nov 16, 2014, at 5:32 PM, David Strubbe <dstru...@macports.org> wrote: > > > All right, b

Re: passing variants to dependencies; pre-activate check

On Sat, Oct 10, 2015 at 10:34 PM, Joshua Root <j...@macports.org> wrote: > On 2015-10-11 11:34 , David Strubbe wrote: > > Thanks for checking. I realize now I can find these two different > > behaviors, depending on whether the other dependency BWidget is > > installed

Re: [140793] trunk/dports/math/svdlibc/Portfile

Ok, thanks. David On Sat, Oct 3, 2015 at 7:35 AM, Ryan Schmidt wrote: > > > On Oct 2, 2015, at 2:43 PM, dstru...@macports.org wrote: > > > > Revision > > 140793 > > Author > > dstru...@macports.org > > Date > > 2015-10-02 12:43:15 -0700 (Fri, 02 Oct 2015) > > Log

Re: migration instructions

On Mon, Sep 14, 2015 at 8:04 PM, Joshua Root wrote: > > > 2. The list of ports generated in myports.txt and requested.txt will > > include ports that are deactivated, including one line for each version > > of a port, whether active or not. One line total regardless of number

migration instructions

Hello all, I have just updated to Yosemite and used the migration instructions at http://trac.macports.org/wiki/Migration I want to point out two issues: 1. Running "sudo port clean all" takes a huge amount of time. Apparently many hours for me; I didn't have the patience to let it finish.

Re: Easy access to external repositories.

Hi Artur, Since you are discussing the question of ensuring the reliability of results, let me point out that you can add a testphase in the Portfile, to run a testsuite with the command port test. I am developing and maintaining several software package for condensed-matter physics and have

Re: Easy access to external repositories.

A general question: what is the purpose of adding a repo for the ESO software, as opposed to just committing the individual Portfiles that exist in that repo to the standard MacPorts repo? David On Mon, Jun 1, 2015 at 11:44 AM, René J.V. rjvber...@gmail.com wrote: On Monday June 01 2015

Re: Easy access to external repositories.

In our case: we have a community of astronomers that have requested a distribution mechanism for ESO software via MacPorts, which they are familiar with. However, our software is only relevant to astronomers (a few hundred users), rather than the much larger community that the default

Re: Easy access to external repositories.

Provided the licenses for your software and its dependencies would make the binaries redistributable, the binaries will be built automatically for the default variants by the buildslaves (using various recent versions of OSX) after a commit of a Portfile to the MacPorts repository, and then those

Re: Easy access to external repositories.

[dstru...@gmail.com] on behalf of David Strubbe [dstru...@macports.org] *Sent:* 01 June 2015 21:06 *To:* Artur Szostak *Cc:* MacPorts Development *Subject:* Re: Easy access to external repositories. Provided the licenses for your software and its dependencies would make the binaries

Re: GSoC Project: Revitalizing Pallet

Why is it called Pallet? David On Wed, May 6, 2015 at 8:59 PM, Mark Anderson e...@emer.net wrote: I love it. I agree with Ryan, I think a portfile Editor/IDE should be a separate MacPorts.framework project from Pallet. —Mark ___ Mark E. Anderson e...@emer.net On Wed,

Re: Buildbot cruft: /opt/local/bin/mvn31

How about using ls -lt in an appropriate step of the Portfile to get this info? David On Tue, Mar 17, 2015 at 2:35 PM, Marko Käning mk-macpo...@techno.ms wrote: Hi Blair, On 17 Mar 2015, at 19:25 , Blair Zajac bl...@orcaware.com wrote: Error: org.macports.destroot for port maven31

Re: Current best practice to select GCC compiler in Portfile

Hi Rainer, Sean did indeed add the default_variants to the compilers portgroup in the last month or two. Perhaps you were trying before then. David On Thu, Feb 26, 2015 at 9:30 AM, Rainer Müller rai...@macports.org wrote: On 2015-02-26 14:22, Artur Szostak wrote: Let me rephrase: Assuming I

Re: [128393] trunk/dports/science/berkeleygw/Portfile

Thanks, fixed in r128435. On Thu, Nov 20, 2014 at 8:18 PM, Ryan Schmidt ryandes...@macports.org wrote: On Nov 20, 2014, at 12:23 PM, dstru...@macports.org wrote: Revision 128393 Author dstru...@macports.org Date 2014-11-20 10:23:26 -0800 (Thu, 20 Nov 2014) Log Message

passing default variants to dependencies?

Hi all, Is there a way to make default variants be passed to dependencies when installing them? My octopus port depends on fftw-3 and needs it to be built with a Fortran variant. octopus has +gcc48 as default variant, and building fftw-3 +gcc48 will work. But on the buildbots it just builds

Re: passing default variants to dependencies?

...@macports.org wrote: Asking to ensure that your dependencies have certain variants applied is depending on variants. Restricting it to variants that the dependent port has itself doesn't change the fundamental issues. - Josh On 2014-11-17 09:05 , David Strubbe wrote: Thanks

Re: [127404] trunk/dports/science/sparskit/Portfile

Hi Ryan, The point is that there is no check unfortunately on whether the tests passed. You have to read through the results to see whether they are ok. So the test phase would fail only if execution of one of the steps failed, unlike the typical situation where 'make check' would give an error

Re: [127404] trunk/dports/science/sparskit/Portfile

Schmidt ryandes...@macports.org wrote: On Nov 2, 2014, at 12:51 PM, David Strubbe wrote: The point is that there is no check unfortunately on whether the tests passed. You have to read through the results to see whether they are ok. So the test phase would fail only if execution of one

Re: Getting the entire configure.cflags variable

You could alternately try to patch the code to pay attention to CFLAGS. I'm not sure how complicated that would be in the build system. David On Thu, Oct 2, 2014 at 6:13 PM, Ryan Schmidt ryandes...@macports.org wrote: On Oct 2, 2014, at 4:29 PM, Lawrence Velázquez wrote: On Oct 2, 2014,

Re: [125581] trunk/dports/science/abinit/Portfile

That worked, thanks for the tip! David On Sun, Sep 21, 2014 at 10:28 PM, Ryan Schmidt ryandes...@macports.org wrote: On Sep 22, 2014, at 12:21 AM, dstru...@macports.org wrote: Revision 125581 Author dstru...@macports.org Date 2014-09-21 22:21:07 -0700 (Sun, 21 Sep 2014) Log

Re: echo script output to the display

One approach you could use for the test output is to redirect it into a file, and then put a ui message to look at that file for the results. David On Sat, Sep 20, 2014 at 2:11 PM, Mark Brethen mark.bret...@gmail.com wrote: On Sep 20, 2014, at 10:30 AM, Clemens Lang c...@macports.org wrote:

access files on buildbot?

Hi all, Is there a way to access a file such as a config.log from a failed port build on a buildslave? After my recent changes r125398 and r125404 to the abinit port, the build failed on Mountain Lion, in the configure stage, as follows: checking for mpicc-mpich-mp...

Re: Ticket #44479

Maybe you are just looking at the list of open tickets that are submissions, i.e. only the ones that haven't made it in. A large number certainly have been accepted over the years. David On Mon, Aug 4, 2014 at 2:22 PM, Nathan Wehr gtolem...@gmail.com wrote: I’m fairly new to MacPorts, and I

Re: Binary distributability of codeblocks: GPL OpenSSL conflict

Is there a simple way to determine the sequence of dependencies, like ffmpeg-gnutls-nettle-openssl ? David On Thu, Jul 10, 2014 at 6:51 PM, David Evans dev...@macports.org wrote: On 7/10/14 3:18 PM, Mojca Miklavec wrote: Actually, something similar is true for ffmpeg as well: ffmpeg is

empty error message on activation of texlive-common

Hello all, I just got this output on upgrading ports, with an error message for activating texlive-common which is empty. Anyone know what is going on? David ... --- Fetching archive for texlive-common --- Attempting to fetch texlive-common-2014_0.darwin_12.noarch.tbz2 from

Re: empty error message on activation of texlive-common

/_opt_local_var_macports_registry_portfiles_texlive-common-2013_0_262d7eea3bb2898396497218a856f330b058d55c58552609aa010ea520eabefa-5752/texlive-common On Mon, Jul 7, 2014 at 1:58 PM, Joshua Root j...@macports.org wrote: On 2014-7-8 03:18 , David Strubbe wrote: Hello all, I just got this output on upgrading ports

Re: [121204] trunk/dports

Hi Ryan, I agree that it should not be a problem, but it actually crashed both 'port search' and 'svn diff' commands for me which seemed like a pretty significant problem. Also that character renders in various different ways (for cat, emacs, etc.), mostly erroneous, so it fails in the goal of

Re: [121204] trunk/dports

How does one make XQuartz's xterm support UTF-8? David On Sun, Jun 22, 2014 at 11:26 PM, Mihai Moldovan io...@ionic.de wrote: * On 23.06.2014 02:12 am, Michael Dickens wrote: That said, it's quite possible that I've messed up my xterm settings somehow, which is causing the locking (me,

Re: [120684] trunk/dports/devel/srecord/Portfile

Hi Ryan, Why is using a patchfile instead of reinplace preferable? David On Sun, Jun 8, 2014 at 3:33 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 5, 2014, at 12:30 PM, m...@macports.org wrote: Revision 120684 Author m...@macports.org Date 2014-06-05 10:30:25 -0700

Re: Identifying possible situations for interactivity

Here's another possible scenario: installing a port that requires a dependency to have a certain variant, but this variant is not set. It could offer to reinstall the dependency with that variant. David On Mon, May 12, 2014 at 10:04 AM, Shashwat Pandey devshashwatpan...@gmail.com wrote: Hi

Re: Compiler variants in portfile

You can use clang -E to preprocess Fortran in a way compatible with gcc's cpp (at least on the several codes I have tested it with). David On Thu, Apr 17, 2014 at 1:16 PM, Sean Farley s...@macports.org wrote: Sébastien Maret sebastien.ma...@icloud.com writes: Le 17 avr. 2014 à 18:13, Sean

Re: curious dependency issues

: On Apr 7, 2014, at 17:14, David Strubbe wrote: Ok, I think I see what is going on here: apparently port installed depends:XXX returns all ports depending on port XXX -- OR a port that contains the string XXX. It's a regular expression search. So if you want the ports that depend on gcr, you

curious dependency issues

Hi all, I found two strange things in using 'port installed depends:'. The 'gcr' port appears to depend on itself, and gconf and gtk3 appear to depend on each other. Does this make sense? Is it a bug in base or the Portfiles? David $ port installed depends:gcr The following ports are currently

Re: curious dependency issues

supplanted by depof:. David On Mon, Apr 7, 2014 at 2:03 PM, Bradley Giesbrecht pixi...@macports.orgwrote: On Apr 7, 2014, at 9:12 AM, David Strubbe dstru...@gmail.com wrote: Hi all, I found two strange things in using 'port installed depends:'. The 'gcr' port appears to depend on itself

Re: New MacPorts web site

Looks great. I suggest that in the info on the right-hand side for a given port, you mention also the possibility of running port test when available. David On Mon, Apr 7, 2014 at 4:13 PM, mk-macpo...@techno.ms wrote: Hi Ryan, I do like your work very much! This looks really cool!!! A few

Re: curious dependency issues

PM, Eric Gallager eg...@gwmail.gwu.edu wrote: I was under the impression that the depends: pseudo-portname and the depof: portname were two separate things... On Mon, Apr 7, 2014 at 2:19 PM, David Strubbe dstru...@gmail.com wrote: Hm, I guess I got depends: from suggestions in messages

Re: curious dependency issues

xorg-libxcb, xorg-libXcomposite, and xorg-libXcursor. David On Mon, Apr 7, 2014 at 6:01 PM, David Strubbe dstru...@gmail.com wrote: Indeed, evidently depends: does some strange things which depof: does not. Though man port does not define depends:, it is recommended here: https

xcrysden and mesa702

Hi Jeremy and others, Do you have any suggestions regarding my submitted ports xcrysden ( https://trac.macports.org/ticket/41320) and mesa702 ( https://trac.macports.org/ticket/41319)? I understand it is undesirable to introduce an old version of mesa, but I am not sure how to investigate the

Re: removing -arch from LDFLAGS

I'm saying that if the user sets build_arch to i386 in macports.conf, adding '-arch i386' to LDFLAGS is one of the ways that we tell the build system to build for i386 and not for (say) x86_64 which is the default on recent systems. So if you don't do that, you may need to do something else.

Re: removing -arch from LDFLAGS

PortGroup for more information. I hope this helps. - MLD On Tue, Nov 12, 2013, at 10:40 AM, David Strubbe wrote: gfortran just doesn't accept the -arch argument, so I am not sure if there is a way to take the arch into account. Can anyone else comment on how, if at all, building with gfortran

Re: local PortGroup repo?

removed regardless of whether executing the portfile succeeds. - Josh On 2013-11-12 17:16 , David Strubbe wrote: I see. As it stands, I am not sure how to actually uninstall the ports I installed with the test portgroup -- they are still there after the failed uninstall. Any tip? David

removing -arch from LDFLAGS

Hi all, Is there a way to remove the -arch option from LDFLAGS, as for gfortran? Using configure.compiler macports-gcc-XX removes it, but that is not compatible with the Fortran recipe which only sets configure.f90 etc. On my machine, the default value is LDFLAGS='-L/opt/local/lib

Re: local PortGroup repo?

I tried it out, and it works partially. The PortGroup file I made in _resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but not when uninstalling. For example: $ sudo port uninstall libxc @2.0.2_0+gcc47 Warning: PortGroup fortran 1.0 could not be located. fortran-1.0.tcl does

Re: local PortGroup repo?

I see. As it stands, I am not sure how to actually uninstall the ports I installed with the test portgroup -- they are still there after the failed uninstall. Any tip? David On Tue, Nov 12, 2013 at 12:44 AM, Sean Farley s...@macports.org wrote: dstru...@mit.edu writes: I tried it out, and

Re: removing -arch from LDFLAGS

...@macports.org wrote: On 2013-11-12 16:32 , David Strubbe wrote: Hi all, Is there a way to remove the -arch option from LDFLAGS, as for gfortran? Using configure.compiler macports-gcc-XX removes it, but that is not compatible with the Fortran recipe which only sets configure.f90 etc. On my

Re: redefined data types in different packages - request for help

Looks like this is C++. There might be something you can do with namespaces. David On Sat, Nov 9, 2013 at 9:15 AM, Mojca Miklavec mo...@macports.org wrote: On Sat, Nov 9, 2013 at 3:08 PM, Mojca Miklavec mo...@macports.org wrote: Hi, one of the problems I'm experiencing when compiling

Re: @macports.org handle

The guide says: 7.3. Port Update Policies Port maintainers normally are given commit privileges to the Subversion repository so they can make updates to their own ports. I suggest that be clarified if more conditions apply. David On Thu, Nov 7, 2013 at 12:41 PM, Rainer Müller

local PortGroup repo?

Hi all, Is it possible to have local PortGroup files to use with a local Portfile repository? If so, where should they be put? Or otherwise, how should one try out a new PortGroup? Thanks, David ___ macports-dev mailing list

Re: open tickets

Hi committers, I'd like to ask again for someone to take a look at these two tickets, for a maintainer patch and taking over an abandoned port. Thanks, David On Sun, Oct 6, 2013 at 11:15 PM, David Strubbe dstru...@gmail.com wrote: Hi committers, Can you please take a look at two open

Re: open tickets

wrote: Handled. Have you applied for commit access? On Oct 24, 2013, at 5:20 PM, David Strubbe wrote: Hi committers, I'd like to ask again for someone to take a look at these two tickets, for a maintainer patch and taking over an abandoned port. Thanks, David On Sun, Oct 6

open tickets

Hi committers, Can you please take a look at two open tickets I submitted? The first is an enhancement to my sparskit port; the second is about port abandonment of libxc. I submitted it 5 days ago, so the 72 hour timeout period has elapsed. Thanks, David [1]

default_variant and conflicts: suggestion for base

Hi all, As we see at https://trac.macports.org/wiki/PortfileRecipes, the recommended code for a default variant with one of several mutually exclusive variants is: if {![variant_isset q8] ![variant_isset q32]} { default_variants +q16 } In this case, as in the older Fortran recipe also on

suggestion for Fortran recipe

Hi Jeremy and others, I think a few lines can be simplified in the new Fortran recipe. For default variants, it seems to me that it makes no difference whether it is set when the variant was explicitly selected. i.e this code from the Portfile recipe if {![variant_isset q8] ![variant_isset

ticket guidelines

According to the guide at http://guide.macports.org/#project.tickets, ticket summaries should have the form: Summary: [port] [version] [concise description] Example: rrdtool @1.2.23 +python Configure error - build failure However it appears in practice that this is the appropriate form for a

Re: [MacPorts] #40309: submission: berkeleygw

Thanks! David On Mon, Sep 23, 2013 at 4:50 PM, MacPorts nore...@macports.org wrote: #40309: submission: berkeleygw -+ Reporter: dstrubbe@… | Owner: macports-tickets@… Type: submission | Status: closed

Fortran recipe

Hi all, In the Fortran recipe at https://trac.macports.org/wiki/PortfileRecipes#fortran, can't this common line be refactored out of the variants? depends_lib-append path:lib/libgcc/libgcc_s.1.dylib:libgcc David ___ macports-dev mailing list

Re: Fortran recipe

Right, that is what I was thinking should be done. Currently it appears in two places inside variant_isset blocks. On Mon, Sep 23, 2013 at 5:51 PM, Lawrence Velázquez lar...@macports.orgwrote: On Sep 23, 2013, at 5:28 PM, David Strubbe dstru...@gmail.com wrote: In the Fortran recipe

  1   2   >