Re: GitHub desired workflow...

ny reasons, the > Xcode-provided git should have autostash since Xcode 5.1 or so. > > - Josh > > On 2016-11-2 03:40 , Eric A. Borisch wrote: > >> As should the fact that, for this to work, you need to be using a >> new-enough git (like from ports) and not the system-prov

Re: GitHub desired workflow...

As should the fact that, for this to work, you need to be using a new-enough git (like from ports) and not the system-provided one. On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning wrote: > On 01 Nov 2016, at 01:10 , Brandon Allbery wrote: > > > You can even configure so that becomes the default fo

Re: GitHub desired workflow...

I hoped someone would point me to a command like this. Thanks! - Eric On Monday, October 31, 2016, Joshua Root wrote: > > I'm using 'git pull --rebase --autostash' which does the stash-before and > pop-after automatically. > > - Josh > ___ macports-d

GitHub desired workflow...

Thanks for all the hard work with this transition! I'm sure once we're all "over the hump" we'll look back and wonder why we waited so long. Just so I'm clear on this, is the desired approach for each committer to: == setup == 1) clone macports/macports-ports to the local filesystem == every chan

Re: [152440] trunk/dports/net

Fixed in r152601. I flubbed the commit message, though. Only human. - Eric On Monday, September 12, 2016, Ryan Schmidt wrote: > > > On Sep 8, 2016, at 11:28 PM, ebori...@macports.org wrote: > > > > Revision > > 152440 > > Author > > ebori...@macports.org > > Date > > 2016-09-08 21:28:04 -07

Re: [152440] trunk/dports/net

On Friday, September 9, 2016, Ryan Schmidt wrote: > > > On Sep 8, 2016, at 11:28 PM, ebori...@macports.org wrote: > > > > Revision > > 152440 > > Author > > ebori...@macports.org > > Date > > 2016-09-08 21:28:04 -0700 (Thu, 08 Sep 2016) > > Log Message > > > > zabbix3: New port. > > > > Added P

Soliciting feedback for python port changes (libedit v. readline)

Python (in the terminal) continues to have issues with libedit when exiting the interpreter, leaving the terminal mis-configured. Please weigh in if you are concerned about how this is handled -- potentially by switching all python variants to default to readline, which is what has already been do

Re: port:libclang

On Wed, Mar 9, 2016 at 6:13 AM, René J.V. wrote: > That parser only uses libclang (and thus libLLVM), and the install > footprint of required LLVM/Clang stuff can apparently be reduced to about > 50Mb (on Linux or MS Windows) which is a far cry from the almost 3.5 Gb a > full, uncompressed LLVM+C

Re: about keeping a checksums table in a separate file

On Wednesday, February 3, 2016, Eric A. Borisch wrote: > On Monday, February 1, 2016, Daniel J. Luke > wrote: > >> On Feb 1, 2016, at 3:09 PM, René J.V. Bertin wrote: >> > As an example of a potentially non-trivial file for automatic checksum >> updating >&g

Re: about keeping a checksums table in a separate file

On Monday, February 1, 2016, Daniel J. Luke wrote: > On Feb 1, 2016, at 3:09 PM, René J.V. Bertin > wrote: > > As an example of a potentially non-trivial file for automatic checksum > updating > > I don't think this would be as hard to implement as you seem to think it > would be. > > As a first

Re: HFS+ compression options (WAS: VLC cannot play MKV files?)

On Fri, Jan 29, 2016 at 9:45 AM, René J.V. wrote: > On Friday January 29 2016 09:23:15 Eric A. Borisch wrote: > >>Perhaps an opportunistic execution of afsctool on just-extracted (not >>yet moved into place) files in portimage.tcl (similar to the >>opportunistic use of

HFS+ compression options (WAS: VLC cannot play MKV files?)

On Wed, Jan 27, 2016 at 1:16 PM, Clemens Lang wrote: > On Wed, Jan 27, 2016 at 03:00:52PM +0100, Rainer Müller wrote: >> > I think the system bsdtar doesn't support this on all OS X versions >> > that do support hfs compression. >> >> Right, on my OS X 10.10.5 Yosemite it does not seem to be suppo

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

On Tue, Jan 5, 2016 at 1:03 PM, Clemens Lang wrote: > Hi, > > On Tue, Jan 05, 2016 at 12:44:49PM -0600, Ryan Schmidt wrote: >> >> I'm not comfortable with installing unchecked files on user systems. >> The whole point of the checksum system is to verify that the files >> that are installed on user

Re: [144027] trunk/dports/lang/py-htmldocs/Portfile

There's a later commit that added dist_subdir for those versions that have been stealth-updated... On Sat, Jan 2, 2016 at 11:05 AM, Ryan Schmidt wrote: > >> On Dec 30, 2015, at 12:10 AM, ebori...@macports.org wrote: >> >> Revision >> 144027 >> Author >> ebori...@macports.org >> Date >> 2015-12-29

Re: [143618] trunk/dports/lang/py-htmldocs/Portfile

On Tuesday, December 15, 2015, Ryan Schmidt wrote: > > > On Dec 15, 2015, at 5:40 PM, ebori...@macports.org wrote: > > > > Revision > > 143618 > > Author > > ebori...@macports.org > > Date > > 2015-12-15 15:40:40 -0800 (Tue, 15 Dec 2015) > > Log Message > > > > py-htmldocs: Remove 25, add 35. U

Re: Why py-spyder{,-devel} depends on py-htmldocs.

Petr, 1) it is a trivial install -- just download and extract -- so hopefully it's not a big issue. We can always move it into a variant. 2) Spyder has a menu link to go to python documentation, which I patch to go to the installed documentation. (hence the dependency.) - Eric On Tue, Dec 15, 2

Re: llvm-3.7 release and OpenMP

onth, you mentioned rewriting the llvm Portfile to use the cmake build > system. I think now might be an opportune time to do that in llvm-3.8. Have > you looked into that yet? > > --Jeremy > >> On Sep 3, 2015, at 10:10, Eric A. Borisch wrote: >> >> I'll defer

Re: OpenCoarrays Portfile ticket response?

Done. On Wednesday, September 30, 2015, Damian Rouson < dam...@sourceryinstitute.org> wrote: > > > On Sep 30, 2015, at 5:50 PM, Brandon Allbery > wrote: > > On Wed, Sep 30, 2015 at 8:43 PM, Damian Rouson < > dam...@sourceryinstitute.org > > wrote: > >> Wow. I assume that means we’ll be in the n

Re: OpenCoarrays Portfile ticket response?

I've committed up a working (I believe) version. On Friday, September 25, 2015, Damian Rouson wrote: > * PING *** > > > > On Sep 21, 2015, at 11:31 PM, Mojca Miklavec > wrote: > > > > On Tue, Sep 22, 2015 at 7:27 AM, Damian Rouson wrote: > >> Alessandro Fanfarillo submitted a Portfile f

Re: Python + libedit woes

On Wednesday, September 16, 2015, Joshua Root wrote: > On 2015-9-16 15:00 , Eric A. Borisch wrote: > >> On Tuesday, September 15, 2015, Joshua Root > wrote: > >>> > >>> On 2015-9-16 11:42 , Eric A. Borisch wrote: > >>>> Any thoughts

Re: Python + libedit woes

> On Tuesday, September 15, 2015, Joshua Root wrote: >> >> On 2015-9-16 11:42 , Eric A. Borisch wrote: >> > Any thoughts on this? Are most users not impacted, or have most not >> > tried? >> > >> > https://trac.macports.org/ticket/48807 >

Re: Python + libedit woes

On Tuesday, September 15, 2015, Joshua Root wrote: > On 2015-9-16 11:42 , Eric A. Borisch wrote: > > Any thoughts on this? Are most users not impacted, or have most not > tried? > > > > https://trac.macports.org/ticket/48807 > > <https://trac.macports.org/tic

Python + libedit woes

Any thoughts on this? Are most users not impacted, or have most not tried? https://trac.macports.org/ticket/48807 I'm clearly not the only one. :) - Eric ___ macports-dev mailing list macports-dev@l

Re: llvm-3.7 release and OpenMP

I've created a ticket with some additional info. https://trac.macports.org/ticket/48759 Note that the subversion sync seems to not be running, but at least trac is up! On Thu, Sep 3, 2015 at 1:12 PM, Jeremy Huddleston Sequoia wrote: > >> On Sep 3, 2015, at 10:51, Sean Farley wrote: >> >> >> Je

Re: llvm-3.7 release and OpenMP

e -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the > fat binary of libomp, > you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386". > Jack > ps Note that the perl-based Makefile build is no longer functional in > 3.7.0 and is in t

llvm-3.7 release and OpenMP

Would have done a ticket, but with trac down Attached is a patch to update to the released llvm/clang-3.7 (this comments out the svn fetch code, removes the default +assertions, and adds checksums) As OpenMP is one of the much discussed items that llvm-3.7 brings to the table, I've added a +o

trac is down

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

python + libedit issues

I've recently noticed (not sure when it changed) that when I enter and then exit() the python (using python27 in particular) interpreter built against libedit, the tty flags (as reported by stty -a) aren't getting reset when exiting python -- most noticeably the echo flag is getting turned off. Yes

Re: [138813] trunk/dports/lang

On Mon, Jul 20, 2015 at 11:51 PM, Ryan Schmidt wrote: > On Jul 20, 2015, at 6:20 PM, ebori...@macports.org wrote: > > > > Revision > > 138813 > > Author > > ebori...@macports.org > > Date > > 2015-07-20 16:20:10 -0700 (Mon, 20 Jul 2015) > > Log Message > > > > libomp: New port; LLVM project's Ope

Re: [138675] trunk/dports/gnome/gdmap/Portfile

On Thu, Jul 16, 2015 at 1:44 PM, David Evans wrote: > It may work but your port continues to require the perl version and > intltools perl module dependencies to be explicitly specified and > you don't get the benefits of any improvements in the current version of > intltool. The reason intltoo

Re: [138675] trunk/dports/gnome/gdmap/Portfile

On Wed, Jul 15, 2015 at 8:54 PM, Ryan Schmidt wrote: > > > On Jul 15, 2015, at 4:53 PM, ebori...@macports.org wrote: > > +configure.env-appendINTLTOOL_PERL=${prefix}/bin/perl5.22 > > I guess this port uses intltool? So it should really have a build > dependency on intltool, not p5.22-xml-pars

Re: macports with closed stdout

On Tue, May 5, 2015 at 1:23 PM, René J.V. wrote: > On Tuesday May 05 2015 19:58:44 Clemens Lang wrote: > >That sounds like a perfect use case for screen or tmux. > > I might check out tmux, but screen gets in my way by trying to be too > clever. The easiest would be to redirect all output (">&")

Re: Using xz by default for compression

FYI, lbzip2 is what you probably want, as it *can* decompress a 'stock' archive faster. From the man page: "The lbzip2 utility employs multiple threads and an input-bound splitter even when decompressing .bz2 files created by standard bzip2." That said, I'm in favor of having a list of valid suff

Re: [130886] trunk/dports/graphics

On Sat, Jan 3, 2015 at 10:47 PM, Ryan Schmidt wrote: > > > On Jan 3, 2015, at 12:44 PM, ebori...@macports.org wrote: > > > > Revision > > 130886 > > Author > > ebori...@macports.org > > Date > > 2015-01-03 10:44:45 -0800 (Sat, 03 Jan 2015) > > Log Message > > > > libpgf: New port for Digikam supp

Re: Adding MPI back to Boost

On Sunday, December 14, 2014, Ryan Schmidt wrote: > > On Dec 14, 2014, at 12:21 PM, Sean Farley wrote: > > > > Ryan Schmidt writes: > > > >> So, this would add clang33, clang34, clang35 variants, for example? But > these would be different from the clang 3.x provided by Xcode in some way? > The M

Re: [120646] trunk/dports/python/py-spyder-devel

On Wed, Jun 4, 2014 at 9:30 PM, Ryan Schmidt wrote: > > On Jun 4, 2014, at 11:40 AM, ebori...@macports.org wrote: > > +variant noAntiAlias description {Use non-anti-aliased fonts in > editor.} { > > +patchfiles-append no_AA.diff > > +} > > Note that variant names are treated cas

Re: Any thoughts on changing configure...

On Thursday, April 24, 2014, Jeremy Lavergne wrote: > I remember “-dc” being used for mp_tarball_extract_cmd in place of “-d < “ > for compat: > https://trac.macports.org/changeset/118736/trunk/base/aclocal.m4 > > That should not be forgotten in that ticket’s patch. > > On Apr 24, 2014, at 13:11,

Re: Any thoughts on changing configure...

On Wed, Apr 23, 2014 at 6:23 PM, Eric A. Borisch wrote: > See this ticket : https://trac.macports.org/ticket/43204#comment:12 > > Specifically, this would change the tool settings from environment > variables (TOOL=/usr/bin/tool ./configure) to arguments (./configure > --with-too

Any thoughts on changing configure...

See this ticket : https://trac.macports.org/ticket/43204#comment:12 Specifically, this would change the tool settings from environment variables (TOOL=/usr/bin/tool ./configure) to arguments (./configure --with-tool=/usr/bin/tool) This also fixes an issue where bzip2 (and lbzip2) use BZIP2 as an

Buildbots rejecting certificate of svn.macports.org

Perhaps I missed it being mentioned on the list, but the Lion, Mountain Lion, and Mavericks build bots are rejecting server certificates and failing. You can see them all start to fail in this view: https://build.macports.org/waterfall?last_time=1397200915 First failing one: (Picked Mavericks) ht

Re: Move part of macports infrastructure to GitHub

A related item that bubbled on the mailing list for a while would be to get the http://trac.edgewall.org/wiki/CommitTicketUpdater configured for MP. This would let us refer to and take actions on ("ref #1234" or "closes #5432") tickets in commit messages, which ties a nice bow around commits tied t

Re: MacPorts automake and python

On Thursday, March 20, 2014, David Evans wrote: > On 3/20/14 3:01 PM, Adam Mercer wrote: > > On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch > > > > wrote: > > > >> What was broken that needed fixing (by the original change)? Is there a > >> par

MacPorts automake and python

On Thursday, March 20, 2014, Sean Farley > wrote: > > Adam Mercer writes: > > > On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley wrote: > > > >> Before: my project installed into /path/foo/a > >> After: my project installed into /path/foo/b > > > > Got you, if I configured using: ./configure --pref

Re: MacPorts automake and python

Brining back to dev list; seems like the right place. On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley wrote: > > Adam Mercer writes: > > > On Thu, Mar 20, 2014 at 2:55 PM, Sean Farley wrote: > > > >> I tend to agree with you but need help seeing how this worked > >> before. What path did automake

Buildbot fails to upload packages...

Just making sure this hasn't dropped off the radar. Just picking the latest build: https://build.macports.org/builders/buildports-lion-x86_64/builds/18908/steps/deploy%20archives/logs/stdio - Eric ___ macports-dev mailing list macports-dev@lists.macosf

Re: [116291] trunk/dports/_resources/port1.0/group/debug-1.0.tcl

On Fri, Jan 24, 2014 at 10:51 AM, Sean Farley wrote: > > eg...@gwmail.gwu.edu writes: > >> Just so it can remove it with the `+debug` variant that it adds, it looks >> like... > > Eric is correct. In hindsight, I am now doubting adding > -mtune=native. Maybe just the -O3 -Ofast etc.? > >> On Thu,

Re: What should be done about tickets that seem to be forgotten?

On Mon, Dec 23, 2013 at 11:38 AM, Eric Gallager wrote: > Is there a trac plugin or setting that we could use to have our trac > automatically close tickets like that, too? Sure is: http://trac.edgewall.org/wiki/CommitTicketUpdater. - Eric ___ macport

Re: What should be done about tickets that seem to be forgotten?

I failed to manually close the ticket. (I'm used to a Trac that scans commit messages for closes #) Sorry for the confusion. The port is there now -- give it a shot. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge

Re: Archive vs. local build selection (10.8.5, XCode 5.0.2)

On Tue, Dec 17, 2013 at 4:49 PM, Ryan Schmidt wrote: > > On Dec 17, 2013, at 08:28, Eric A. Borisch wrote: > > > This ticket https://trac.macports.org/ticket/41836 describes an issue > where (apparently, I don't have a matching system to test) 10.8.5 and XCode > 5.0.2

Archive vs. local build selection (10.8.5, XCode 5.0.2)

This ticket https://trac.macports.org/ticket/41836 describes an issue where (apparently, I don't have a matching system to test) 10.8.5 and XCode 5.0.2 are installed. The user installed (I'm guessing from buildbot archive) mpich-default, which wraps /usr/bin/llvm-gcc-4.2. In the setup mentioned, t

Re: [114668] trunk/dports/security/KeePassX/Portfile

On Fri, Dec 13, 2013 at 12:33 PM, Ryan Schmidt wrote: > > On Dec 13, 2013, at 11:25, ebori...@macports.org wrote: > > > +platform darwin { > > +if {${os.major} < 13} { > > +# Build fails with clang: unsupported > -stack-protector-buffer-size=4 > > +# (even though clang -help li

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

On Wed, Sep 18, 2013 at 10:14 PM, Ryan Schmidt wrote: > > On Sep 18, 2013, at 21:45, Eric A. Borisch wrote: > > >> > -depends_lib port:ocaml port:ocaml-findlib > path:bin/mpicc:mpich > >> > +depends_lib port:ocaml port:ocaml-findlib > path:bi

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

On Wednesday, September 18, 2013, Ryan Schmidt wrote: > On Sep 17, 2013, at 22:06, ebori...@macports.org wrote: > > > Revision: 111271 > > https://trac.macports.org/changeset/111271 > > Author: ebori...@macports.org > > Date: 2013-09-17 20:06:42 -0700 (Tue, 17 Sep 2013) > > Log Me

Of variants and revbumping.

I'm preparing to commit the changes to mpich that have been discussed on the mailing list [1] and a ticket [2]. I will revbump port that depend on mpich by default so new distributable archives can be built. But for other modified ports, I have a quick question of preferences: should I revbump po

Re: Of variants and revbumping.

Schmidt wrote: > >> > >>> On Sep 16, 2013, at 12:54, Eric A. Borisch wrote: > >>> > >>>> I'm preparing to commit the changes to mpich that have been discussed > on the mailing list [1] and a ticket [2]. > >>>> > >>>&g

Possible mpich changes / resolution [Was re: Fortran recipe]

> I think it comes down to "I'm installing X (from MP) so I need this > thing I've never met called MPICH that is required" or "I'm installing > MPICH so I can write an MPI program, and I want to use *cc because of > Z." Perhaps the best way to serve both ends is to create sub-ports as > I mentione

Re: Fortran recipe

On Wed, Aug 28, 2013 at 9:14 PM, Jeremy Huddleston Sequoia wrote: > > On Aug 28, 2013, at 18:06, Eric A. Borisch wrote: >> Because when _I_ install mpich +gcc47 and then call mpicc/mpicxx, I want to >> get gcc47 (c/c++) behind it. Perhaps I'm doing a hybrid model with O

Re: Fortran recipe

[Re-sent to list from correct address] On Wed, Aug 28, 2013 at 4:50 PM, Jeremy Huddleston Sequoia wrote: > > On Aug 28, 2013, at 12:00, Eric A. Borisch wrote: > >> Sorry for the blank email. Gmail interface whoops. >> >> So I come back from vacation and find the

Re: Fortran recipe

On Wed, Aug 28, 2013 at 4:54 PM, Jeremy Huddleston Sequoia wrote: > > On Aug 28, 2013, at 12:30, Michael Dickens wrote: > >> Your "recipe" was pretty concise (unlike >> others which declare each variant explicitly and separately), and it >> does what -you- as the port maintainer want it to do. >

Re: Fortran recipe

Sorry for the blank email. Gmail interface whoops. So I come back from vacation and find the mpich port (I'm maintainer; with openmaintainer) has been completely [1] revamped. The variants no longer do what I intended them to do. MPICH provides a set of compiler wrappers (mpicc, mpicxx, etc.) tha

Re: Fortran recipe

uot;."] ""] >>>>>> variant gcc${ver_no_dot} conflicts gcc${over_no_dot} {} >>>>>> } >>>>>> >>>>>> variant g95 conflicts gcc${ver_no_dot} {} >>>>>> >>

Re: Request for comments: mpi and using multiple compilers

On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley wrote: > > ebori...@macports.org writes: >> I personally swap back and forth between variants of mpich >> when I'm testing my own MPI code (why, oh why, doesn't clang have >> OpenMP support yet?) > > Because there is almost no benefit for parallel applic

Re: Request for comments: mpi and using multiple compilers

iants of mpich when I'm testing my own MPI code (why, oh why, doesn't clang have OpenMP support yet?) Hopefully rev-upgrade will catch that something has (potentially) gone south, but it won't likely be able to rebuild things back to their initial state without some hand-holdi

Re: Request for comments: mpi and using multiple compilers

he fortran compiler specified separately with a gfortNN variant, so one could build +clangXX+gfortNN. This opens up an entire new realm of possible breakage, however. - Eric -- Eric A. Borisch ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

RE Request for comments: mpi and using multiple compilers

; chugging along! > Does mpich +gccXX not get you to working fortran and MPI? I'll try to read through some of this thread later, but just looking for clarification on that point. - Eric -- Eric A. Borisch ___ macports-dev mailing list macpor

Re: port list confusion

Oh, and 'port outdated' is nice, too. I haven't used 'port list ' in years. - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port list confusion

Just to add my 2c; I find 'port echo active', 'port echo inactive', and 'port echo outdated' to be my most used (not to mention much faster than than similar list commands.) - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://

Re: Accept to GSoC 2013

On Tue, Apr 9, 2013 at 3:58 AM, Rainer Müller wrote: > On 2013-04-08 21:16, Jeremy Lavergne wrote: > > MacPorts has been accepted to GSoC 2013. > > > > Kudos to Clemens (cal), Rainer (raimue) and Lawrence (larryv) for their > continued assistance and leadership this year. > > > > We're looking fo

Re: hpc gfortran

On Mon, Mar 25, 2013 at 12:16 PM, Sean Farley wrote: > > Eric A. Borisch writes: > > > On Sunday, March 24, 2013, Joshua Root wrote: > > > >> On 2013-3-25 03:45 , Sean Farley wrote: > >> > I know I've brought this up before but I'd like t

Re: [104383] trunk/dports/python/py-numpy/Portfile

On Mon, Mar 25, 2013 at 8:38 AM, Joshua Root wrote: > On 2013-3-26 00:27 , Joshua Root wrote: > > On 2013-3-26 00:22 , Eric A. Borisch wrote: > >> I've pondered ones like this one before. Shouldn't the binary packages > >> be updated (and would they wi

Re: [104383] trunk/dports/python/py-numpy/Portfile

On Mon, Mar 25, 2013 at 7:03 AM, Joshua Root wrote: > > Revision: 104383 > > https://trac.macports.org/changeset/104383 > > Author: stromnov at macports.org > > Date: 2013-03-24 04:29:11 -0700 (Sun, 24 Mar 2013) > > Log Message: > > --- > > py-numpy: set default gcc47 vari

Re: hpc gfortran

ting gfortran (and gcj) out in > subports of the various gccXY and dragonegg ports. It's just that so > far, nobody did the work. > > - Josh > I'm all for it. It's likely less of an issue for many now that the buildbots pull so much of the install/upgrade times down

Re: [MacPorts] #36459: doxygen @1.8.1: graphiz dependency problem?

On Mon, Feb 18, 2013 at 6:39 PM, Ryan Schmidt wrote: > > On Feb 18, 2013, at 18:32, Lawrence Velázquez wrote: > > > On Feb 18, 2013, at 7:19 PM, Ryan Schmidt > wrote: > > > >> On Feb 18, 2013, at 14:26, Lawrence Velázquez > wrote: > >> > >>> Why does doxygen have a dependency on graphviz, anywa

Re: [103053] trunk/dports/net/zabbix2/Portfile

On Mon, Feb 18, 2013 at 8:55 PM, Eric A. Borisch wrote: > > > On Monday, February 18, 2013, Ryan Schmidt wrote: > >> >> On Feb 18, 2013, at 12:00, ebori...@macports.org wrote: >> >> > Revision: 103206 >> > https://trac.macports.org/chang

Re: [103204] trunk/dports

On Mon, Feb 18, 2013 at 6:45 PM, Ryan Schmidt wrote: > > On Feb 18, 2013, at 10:09, ebori...@macports.org wrote: > > > +variant mpich2 requires mpich description {Variant renamed as +mpich} {} > > You should use "Legacy compatibility variant" as the description in these > cases. > > Done. r103217.

Re: [103053] trunk/dports/net/zabbix2/Portfile

t; port:sqlite3 \ > > sqlite3=${prefix}} > > Again I must ask: why is a database server now required on the same > machine? Why is it not sufficient for the database server to be on another > machine I suppose one could. I'll switch it back (for MySQL as well) - or you can, it's nomaintainer. -- Eric A. Borisch ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Ports depending on mpich2: move to mpich

On Jan 26, 2013, at 8:15 AM, Ryan Schmidt > wrote: > We could rename the manpages ourselves. #11576 -- Eric A. Borisch ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Ports depending on mpich2: move to mpich

On Friday, January 25, 2013, Sean Farley wrote: > On Fri, Jan 25, 2013 at 3:29 PM, Eric A. Borisch > > > wrote: > > The MPICH project has named version 3 of the software as MPICH v3.0 > (rather > > than continuing on MPICH2 to become MPICH3.) The mpich[-devel] port ha

Ports depending on mpich2: move to mpich

s.org/ticket/37785 with the diff attached. I plan to apply the patch next week unless there are concerns raised. Thanks, Eric -- Eric A. Borisch ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/mac

hdf5-18 upgrade pending

For the record on the list, I've made this ticket to stage an hdf5-18 upgrade and associated rev-bumps. https://trac.macports.org/ticket/37686 Please review if interested. Thanks, Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org h

Re: gfortran standalone port

On Thu, Jan 17, 2013 at 5:25 PM, Sean Farley wrote: > On Thu, Jan 17, 2013 at 4:54 PM, Jeremy Huddleston Sequoia > wrote: > > On Jan 17, 2013, at 14:44, Joshua Root wrote: > >> On 2013-1-18 08:09 , Jeremy Huddleston Sequoia wrote: > >>> It would be nice if 'port lint' would report about missing

Re: [101627] trunk/dports/python/py-spyder-devel/Portfile

On Wednesday, January 16, 2013, Ryan Schmidt wrote: > > On Jan 16, 2013, at 00:21, Eric A. Borisch wrote: > > Ok. I kind like the date formatted ones (has more information encoded in > it than '1') and they seem to meet the "only requirements" from the guide.

Portfile Workflow Advice

ou can always kick of a manual refresh if you are looking for more recent changes. Works wonderfully for finding what ports (beyond what is installed and reported by rdependentof) depend upon the one I'm currently breaking. - Eric [1] http://code.google.com/p/codesearch/sourc

Man page re-compression in parallel?

Any thoughts on performing the man page (re)compression in parallel (multiple jobs)? It seems like reasonably low-hanging fruit, and on a port with lots of man pages, it can take a while. Not gobs of time, mind you, but enough to make me ask the question. Thanks, Eric -- Eric A. Borisch

Re: [101627] trunk/dports/python/py-spyder-devel/Portfile

ports.org/chunked/reference.html#reference.keywords > Ok. I kind like the date formatted ones (has more information encoded in it than '1') and they seem to meet the "only requirements" from the guide. But if minimal bumps are desired, so be it. Thanks, Eric -- Eric A. Borisch ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [100629] trunk/dports/science/mpich/Portfile

On Mon, Dec 17, 2012 at 11:43 PM, Ryan Schmidt wrote: > > On Dec 17, 2012, at 22:16, ebori...@macports.org wrote: > > > Revision: 100629 > > https://trac.macports.org/changeset/100629 > > Author: ebori...@macports.org > > Date: 2012-12-17 20:16:28 -0800 (Mon, 17 Dec 2012) > > Log Me

Re: mpich3 -> mpich rename opinions?

mpich2 to be 'replaced_by' mpich once there are no dependencies left. -- Eric On Fri, Nov 16, 2012 at 5:20 PM, Sean Farley wrote: > On Fri, Nov 16, 2012 at 4:56 PM, Ryan Schmidt > wrote: > > > > On Nov 16, 2012, at 14:58, Eric A. Borisch wrote: > > > >

Re: [99761] trunk/dports/devel -- and broken SL buildbot?

Yep, missed those in converting it from the other version (Sean Farley's). Those could be added to lint checks, no? I'll get to it tonight. Or anyone else can if they are ambitious. In other news, is the buildbot broken? https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/124

mpich3 -> mpich rename opinions?

I failed to update the topic on my previous message. Here it is again for the record and clarity. On Fri, Nov 16, 2012 at 1:14 PM, Eric A. Borisch wrote: > I'm considering updating the 'mpich' portfile to version 3.0rc1; this is > currently available as 'mpich3.

Re: Java Open Source software in MacPorts?

I'm considering updating the 'mpich' portfile to version 3.0rc1; this is currently available as 'mpich3.' Background: The upstream project has changed naming conventions; they previously had mpich (now at 1.2.7p1) and mpich2 (at 1.5). With the implementation of the MPI-3 standard (mpich2 was MPI-2

Re: [99497] trunk/dports/net

On Wed, Nov 7, 2012 at 3:04 PM, Ryan Schmidt wrote: > Looks like a file needs to be added because the buildbot fails with: > > Error: org.macports.destroot for port zabbix2 returned: xinstall: Cannot > stat: /Volumes/work/mports/dports/net/zabbix2/files/zabbix_server.init, No > such file or direct

Re: [97883] trunk/dports/sysutils/OpenIPMI/Portfile

On Thu, Sep 20, 2012 at 11:56 PM, Ryan Schmidt wrote: > > On Sep 18, 2012, at 15:43, ebori...@macports.org wrote: > >> Revision: 97883 >> http://trac.macports.org//changeset/97883 >> Author: ebori...@macports.org >> Date: 2012-09-18 13:43:40 -0700 (Tue, 18 Sep 2012) >> Log Message:

Re: hdf5-18 openmpi conflicting with gcc46

On Thu, Sep 6, 2012 at 11:10 PM, Lawrence Velázquez wrote: > On Sep 6, 2012, at 11:26 p.m., Srinath Vadlamani wrote: > >> This was not the case a few months ago, but now it is. >> >> Why? > > The openmpi variant now forces the use of the compiler that was used to build > openmpi. It conflicts wit

Re: science ports upgrade to gcc47

On Mon, Aug 6, 2012 at 11:44 AM, Sean Farley wrote: >> arpack >> cfitsio >> dotwrp >> fftw-3 >> fftw-3-long >> fftw-3-single >> qrupdate >> wgrib2 > > These are all bogus because they only have a +gcc4X for the fortran > compiler. The C/C++ code is still compiled with clang (or whichever is > the

Usage reporting status?

What ever became of doing some basic port usage statictics (based on downloads / attempts from pakages.macports.org, perhaps)? I recall there was some activity (last summer?) to put together some reporting... Thanks, Eric ___ macports-dev mailing list

Re: New PPL breaks gcc4*. (Also: trac e-mail notifications missing/delayed?)

On Mon, Jul 2, 2012 at 12:02 PM, Eric A. Borisch wrote: > I don't seem to be getting (CC:) e-mails from trac, either, FWIW. > Perhaps they're just delayed. Scratch that; one just showed up. The gcc issue remains. ___ macports-dev maili

New PPL breaks gcc4*. (Also: trac e-mail notifications missing/delayed?)

Just wanted to raise the visibility on this one. https://trac.macports.org/ticket/35057 Most (all?) gcc4* ports expect PPL version 0.(>=11); The new PPL is version 1.0 (gcc4* builds break) with a new dylib (rev-upgrade hits, forces a re-build doomed to fail). I don't seem to be getting (CC:) e-ma

Re: [93767] trunk/dports/python/py-spyder

(which would enable the separate preference directories.) Spyder is a development environment, so I don't think having multiple versions is too far-fetched. And the step of having to rename the directory for a new version just might remind the user to double-check that settings are corre

Re: [93767] trunk/dports/python/py-spyder

) previously, both would run only one (26 or 27, depending on which made the preference files) python in the interactive interpreters... This seems worse than having two preference directories. -Eric -- Eric A. Borisch ___ macports-dev mailing list m

Re: py-h5py port issues with HDF5 version

the portfile, which will fix these issues, as the binary package will get recompiled against the new hdf5-18. I try to keep on top if it (the hdf5-18 portfile change happened 48 hours ago or so) but I am still recovering from jet lag... - Eric -- Eric A. Borisch

  1   2   >