Re: extract multiple files with formats

On Aug 26, 2014, at 1:48 PM, Jeremy Lavergne wrote: > vim might be a good example on this. > >distfiles-appendvim-7.4.16-fc19-breakindent.patch:breakindent This only works for vim because extract.only is explicitly restricted to the tarball. Base downloads the patches and subsequently

Re: extract multiple files with formats

On Aug 26, 2014, at 1:27 PM, Bradley Giesbrecht wrote: > Is something like this possible: > > distfiles file1.gz file2.zip To my knowledge, no. Fetching will work fine, but the extract phase assumes that all elements of extract.only (defaulting to all distfiles) are the same kind of archive a

Re: [MacPorts] #38556: cpphs @1.3: update to 1.16, use haskell-1.0 portgroup, rename to hs-cpphs

On Aug 8, 2014, at 3:32 PM, MacPorts wrote: > #38556: cpphs @1.3: update to 1.16, use haskell-1.0 portgroup, rename to > hs-cpphs > ---+ > Reporter: larryv@… | Owner: macports-tickets@… > Type: update| Status: new > Pri

Re: GSoC Project: Final Report

On Aug 24, 2014, at 3:51 PM, Shashwat Pandey wrote: > I had to refactor the --follow-dependencies code to allow for the list of > dependencies to be visible before actual uninstall. From the log, it seems > like there is an issue with the else block (lines 66-98, portuninstall.tcl) > in the g

Re: GSoC Project: Final Report

On Aug 18, 2014, at 6:01 PM, Shashwat Pandey wrote: > I have worked on 'Interactive Port Command' project this summer and have > completed many use cases. > > You can find more details about the project here. > To check out the code, visit the repository here. > > Interactivity is the default

Re: Non versioned ports

On Aug 23, 2014, at 7:25 AM, Vincent wrote: > However, I’ll have a look a ‘mercurial’ (unless someone out there is a guru > of this yet-another-DRC and can advise me directly) to figure out if there is > a way to specify a date as a revision. In which case, yes, that would make > sense. http:

Re: Failing livecheck for kdenlive

On Aug 21, 2014, at 7:25 PM, Marko Käning wrote: > On 22 Aug 2014, at 01:18 , Joshua Root wrote: >>> On Aug 21, 2014, at 5:50 PM, Marko Käning wrote: DEBUG: The regex is "kdenlive-(\d+(\.\d+)+)" >> More that if your livecheck isn't finding the current version, you need >> to fix your livec

Re: Failing livecheck for kdenlive

On Aug 21, 2014, at 5:50 PM, Marko Käning wrote: > any idea why kdenlive’s livecheck fails claiming that 0.9.2 is *newer* than > 0.9.8? > > --- > DEBUG: Executing org.macports.main (kdenlive) > DEBUG: livecheck phase started at Thu Aug 21 23:48:00 CEST 2014 > DEBUG: Executing org.macports.livec

Re: [124054] trunk/base/src/macports1.0/reclaim.tcl

On Aug 17, 2014, at 3:55 PM, ksamm...@macports.org wrote: > Revision > 124054 > Author > ksamm...@macports.org > Date > 2014-08-17 12:55:50 -0700 (Sun, 17 Aug 2014) > Log Message > > Added a block to stop it from deleting your home directory +1 vq _

Re: [123768] trunk/base/src/macports1.0/macports.tcl

On Aug 14, 2014, at 12:50 PM, Eric Cronin wrote: > My original patch to add this that's in trac somewhere (#27485 it looks like) > did this, but others thought stash/stash pop was bad so I removed it and just > got in the habit of committing everything locally instead I don't really have a pro

Re: [123768] trunk/base/src/macports1.0/macports.tcl

On Aug 14, 2014, at 4:04 AM, Joshua Root wrote: > On 2014-8-14 17:58 , Lawrence Velázquez wrote: >> On Aug 14, 2014, at 2:40 AM, Joshua Root wrote: >> >>> Do we really need to call 'sh -c' here? >> >> I assumed that directory changes persist af

Re: [123768] trunk/base/src/macports1.0/macports.tcl

On Aug 14, 2014, at 2:40 AM, Joshua Root wrote: > Do we really need to call 'sh -c' here? I assumed that directory changes persist after the call to "system" — hence the pushd/popd in the previous version. We could probably get by with "cd $portdir && … && cd \$OLDPWD", though. We could also

Re: Usage of the term MacPorts (was: Topological sorting of perl modules)

On Aug 13, 2014, at 6:45 AM, Joshua Root wrote: > If we were talking about portmgr then I would agree. But I don't think > MacPorts is a collective noun, it's a proper noun denoting a single > project. That the name has a plural form probably confuses the issue > further. I don't know, I think o

Re: Usage of the term MacPorts (was: Topological sorting of perl modules)

On Aug 13, 2014, at 6:45 AM, Joshua Root wrote: > If we were talking about portmgr then I would agree. But I don't think > MacPorts is a collective noun, it's a proper noun denoting a single > project. That the name has a plural form probably confuses the issue > further. I don't know, I think o

Re: Usage of the term MacPorts (was: Topological sorting of perl modules)

On Aug 13, 2014, at 8:56 AM, Arno Hautala wrote: > I think the more important question is what the "venery" term is for > portfiles. > > "A MacPorts of Portfiles" doesn't sound that great. > A TCL of Portfiles? a Subversion of Portfiles vq ___ macpo

Re: [123558] trunk/dports/lang/rust/Portfile

On Aug 10, 2014, at 11:38 PM, Joshua Root wrote: > Chances are this will come back to bite you at some point, e.g. when > clang adds a new warning. There's really no reason to inflict build > failures due to warnings-turned-errors on our users. That's true; I guess I was overly focused on trimmi

Re: [123423] trunk/dports/perl/p5-email-mime-contenttype/Portfile

On Aug 9, 2014, at 4:41 PM, David Evans wrote: > On 8/9/14 12:46 PM, Frank Schima wrote: > >> I think the code looks better indented. But I will stay with the consensus >> on this (of course). >> > > +1 for Frank's position here. I've been adding the 4 spaces when > updating perl ports as wel

Re: [123423] trunk/dports/perl/p5-email-mime-contenttype/Portfile

On Aug 9, 2014, at 11:47 AM, Frank Schima wrote: > Just curious about why you are removing the indenting spacing in these perl > ports? I would say it is more common to indent in blocks. I’m open to a > discussion about what is preferred. I know when I edit p5 and other ports, I > add 4 spaces

Re: Please commit ticket #44474

On Aug 5, 2014, at 10:30 AM, Davide Liessi wrote: > Dear MacPorts developers, > can you please commit https://trac.macports.org/ticket/44474? Done, thanks! http://trac.macports.org/changeset/123117 vq ___ macports-dev mailing list macports-dev@lists

Re: [122496] branches/gsoc14-pip2port

On Jul 23, 2014, at 6:12 AM, gau...@macports.org wrote: > Revision > 122496 > Author > gau...@macports.org > Date > 2014-07-23 03:12:35 -0700 (Wed, 23 Jul 2014) > Log Message > > Used openssl for checksum generation > --- branches/gsoc14-pip2port/pypi2port.py 2014-07-23 10:11:24 UTC (rev > 1

Re: Maintainers census

On Jul 22, 2014, at 2:11 PM, Arno Hautala wrote: > "BCC" because you know someone is going to start a "Reply All; Please > take me off this mailing list" fire. Plus, you're conducting a census, > not a discussion. +1 vq ___ macports-dev mailing list m

Re: MacPorts Developer Meeting?

On Apr 4, 2014, at 3:22 PM, Mojca Miklavec wrote: > If you are interested in coming, maybe you can also add the continent > of your choice to the reply ;) Can't say for sure what I'll be up to in 2015, but I'd be interested. I'm currently in New York. vq (Sorry to dredge this up after so many

Re: Root port update

On Mar 16, 2014, at 12:53 PM, Chris Jones wrote: > Could i ask a commitor to take a look at > > https://trac.macports.org/ticket/42867 > > It updates root to a new version, that fixes compilation with the latest > Xcode 5.1 on OSX 10.9, so it would be useful to get it out quickly. https://tra

Re: [117621] trunk/base

+1 vq On Mar 8, 2014, at 9:55 AM, Gustaf Neumann wrote: > Also, big, big thanks from my side! -gustaf neumann > > Am 08.03.14 08:53, schrieb Ryan Schmidt: >> On Mar 5, 2014, at 16:19, c...@macports.org wrote: >> >>> ... >>> macports: use a local copy of Tcl 8.5, mostly fix out-of-source build

Re: flags for base's configure script: should there be more or fewer? (was "Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl")

On Mar 7, 2014, at 5:06 PM, Eric Gallager wrote: > libtasn1 is not actually something that gnutls maintains themselves, they > only vendor it in as a convenience. Bringing it back to MacPorts, the copy of > Tcl that is vendored in is more like libtasn1 in gnutls, in that MacPorts > only vendor

Re: commit rights ...

On Feb 21, 2014, at 11:53 AM, Peter Danecek wrote: > But maybe having more committers might reduce backlog, just a thought … Membership requests are evaluated by the project managers only (Josh, Rainer, and Ryan). vq ___ macports-dev mailing list mac

Re: Call for Testers: MacPorts Statistics

On Feb 8, 2014, at 4:55 PM, Eric Gallager wrote: > Really? That sounds dangerous, but if you say it works fine, I guess I can > give it a try... That's more or less what selfupdate already does. If you also want to switch to using a checkout of the ports tree, you'll have to edit your sources

Re: [116839] trunk/dports/devel/re2/Portfile

On Feb 8, 2014, at 4:42 PM, Sean Farley wrote: > I don't think so because it was uninstallable on machines believe > Mavericks due to libc++ issues. Ah, you're right then; I didn't actually look at the ticket until just now. Sorry for the noise. vq _

Re: [116839] trunk/dports/devel/re2/Portfile

Doesn't this require an epoch bump also? vq Sent from my iPhone > On Feb 8, 2014, at 8:37 AM, h...@macports.org wrote: > > Revision > 116839 > Author > h...@macports.org > Date > 2014-02-08 05:37:06 -0800 (Sat, 08 Feb 2014) > Log Message > > re2: downgrade to 20130622 for Lion and Mountain Lion

Re: deployment target and sdk version (was Re: [115735] trunk/dports/devel/class-dump/Portfile)

On Jan 25, 2014, at 6:28 AM, Joshua Root wrote: > I still think that quoting with braces in expressions when double quotes > would do is harder to read, BTW. The more I see it, the more I agree. https://trac.macports.org/changeset/116453 vq ___ macpo

Re: [116449] trunk/base/src/port1.0

On Jan 25, 2014, at 11:57 AM, c...@macports.org wrote: > Revision > 116449 > Author > c...@macports.org > Date > 2014-01-25 08:57:17 -0800 (Sat, 25 Jan 2014) > Log Message > > port1.0: Tcl cleanup, from a patch by Gustaf Neumann > - removed numeric comparisons where not necessary > - braced exp

Re: [115735] trunk/dports/devel/class-dump/Portfile

On Jan 10, 2014, at 2:41 PM, Jeremy Huddleston Sequoia wrote: > On Jan 10, 2014, at 08:50, Joshua Root wrote: > >>> Revision: 115735 >>> https://trac.macports.org/changeset/115735 >>> Author: larryv at macports.org >>> Date: 2014-01-09 21:25:03 -0800 (Thu, 09 Jan 2014) >>> Log Me

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

(a) There's already a configure.mtune option. You should use that ("configure.mtune native") instead of appending to all the flags options. (b) Don't you have to disable binary archives if you set "-mtune=native"? vq Sent from my iPhone > On Jan 23, 2014, at 3:07 PM, s...@macports.org wrote: >

Re: Deactivating the installed version before trying to install the update

On Jan 20, 2014, at 8:44 AM, Adam Mercer wrote: > On Sun, Jan 19, 2014 at 11:37 PM, Ryan Schmidt > wrote: > >> Better yet, see if changing -I to -isystem fixes this; see #40656. If so, >> commit a local version of this fix to your port until MacPorts 2.3 is >> released. > > No, that doesn't

Re: Compilers and MPI Port Groups

On Jan 19, 2014, at 6:41 PM, Sean Farley wrote: > Any objections before I push? Not sure they're "objections" so much as "nitpicks". > set compilers.list {cc cxx cpp objc fc f77 f90} There's a "configure.objcxx" option now. > # dragonegg versions will always match the corresponding clang vers

Re: [MacPorts] Mirrors modified

On Jan 18, 2014, at 7:41 AM, MacPorts wrote: > Page "Mirrors" was changed by jakwi...@gmail.com > Diff URL: > Revision 54 > Comment: adds one Profiles mirror from China USTC > Changes: > ---8<--8<--8<--8<--8<-

Re: [115574] trunk/dports/graphics/makeicns/Portfile

> On Jan 5, 2014, at 5:29 PM, Ryan Schmidt wrote: > > Right, it’ll become simplified, but not totally eliminated. :/ > > Adding -stdlib=… would be wrong for non-clang? > > It would be nice if base could put the right argument into the flags > automatically. I don’t think we can realistically e

Re: [115561] trunk/dports/audio/mpd/Portfile

On Jan 5, 2014, at 3:13 AM, Ryan Schmidt wrote: > Default variants must include “+” or “-“ as desired, e.g.: > > default_variants +mad > > if you want to enable the variant by default or: > > default_variants -mad > > if you want to disable it by default. https://trac.macports.org/changeset/

Re: [115352] trunk/dports/devel/gettext/Portfile

Looks like the patch went MIA. vq On Dec 31, 2013, at 3:33 PM, jerem...@macports.org wrote: > Revision > 115352 > Author > jerem...@macports.org > Date > 2013-12-31 12:33:36 -0800 (Tue, 31 Dec 2013) > Log Message > > gettext: autoreconf to pick up correct C++ runtime > Modified Paths > > trunk

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

On Dec 31, 2013, at 6:33 AM, mk-macpo...@techno.ms wrote: > Perhaps I wasn’t patient enough and should have rebooted to make MacOSX’s > launchpad realise the vanishing of the two files? ;) Heh. I can't speak for you, obviously, but when I deactivated GitX just now on Mavericks, the icon disappe

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

On Dec 30, 2013, at 7:11 PM, Craig Treleaven wrote: > Myth installs double-clickable Applescript helpers that you can drag to the > Dock--which auto-magically creates a link. What I've experienced is that when > Myth is uninstalled, the link on the Dock remains. Perhaps LaunchPad is > doing t

Re: [115275] users/landonf/openjdk7/dports/java/openjdk7/Portfile

This prevents use of our llvm-gcc42 port ("macports-llvm-gcc-4.2"). Is this intentional? vq On Dec 30, 2013, at 10:20 AM, land...@macports.org wrote: > Revision > 115275 > Author > land...@macports.org > Date > 2013-12-30 07:20:02 -0800 (Mon, 30 Dec 2013) > Log Message > > Explicitly whitelis

Re: Launchpad-links to non-existing executables stay behind after deinstalling mythtv-core.27

On Dec 30, 2013, at 9:57 AM, Craig Treleaven wrote: > Yes, that would be expected behaviour. MacPorts has no way of knowing that > the link was created so it ends up pointing to a now-deleted file after an > uninstall. Where do the links come from? Are they created by MythTV at runtime? If M

Re: [114733] users/landonf/openjdk7/dports/java/openjdk6/Portfile

On Dec 27, 2013, at 8:56 AM, Landon Fuller wrote: > On Dec 22, 2013, at 3:11 , Ryan Schmidt wrote: > >> This will unnecessarily make users of Xcode < 5 install the llvm-gcc42 port, >> when they have a perfectly good version of llvm-gcc42 provided by Xcode. >> Rather than this, you should use

Looks like Trac is down again. (eom)

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

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

On Dec 10, 2013, at 5:17 AM, Akim Demaille wrote: > For instance https://trac.macports.org/ticket/34225 The best thing to do is to email macports-dev, as you did. The ticket might just have been overlooked, or maybe no one's found the time to get to that particular ticket. Feel free to email

Re: [114303] trunk/dports

On Dec 4, 2013, at 2:18 PM, michae...@macports.org wrote: > Revision: 114303 > https://trac.macports.org/changeset/114303 > Author: michae...@macports.org > Date: 2013-12-04 11:18:35 -0800 (Wed, 04 Dec 2013) > Log Message: > --- > various dports: allow use of either py*-pyqt

Re: [114094] trunk/dports/python

On Dec 4, 2013, at 1:30 AM, Ryan Schmidt wrote: > On Nov 29, 2013, at 05:40, Peter Danecek wrote: > >> No testing is not done during build or installation. So these dependencies >> are strictly not necessary. However, when you would like to test the package >> (after installation) you would n

Re: zsh +mp_completion (auto-completion for port(1))

On Nov 27, 2013, at 2:48 AM, Jean-Philippe Ouellet wrote: > Changeset 101584 removed the mp_completion variant of zsh, supposedly > because it "has zero versioning relationship to anything else that is > installed". > > What does that mean? It still works, it was useful, and it wasn't > replaced

Re: [113549] trunk/www/install.php

On Nov 20, 2013, at 9:13 AM, Joshua Root wrote: > On 2013-11-20 12:37 , Ryan Schmidt wrote: >> >> On Nov 19, 2013, at 19:33, Jeremy Lavergne wrote: >> >>> Really? Twice on the license? >> >> Yes, as we already documented previously, right? This is not new for >> Mavericks. > > I'm pretty sur

Re: 10.9 and compiler

On Nov 17, 2013, at 4:42 PM, Blair Zajac wrote: > On Nov 17, 2013, at 1:35 PM, Christopher Jones > wrote: > >> On 17 Nov 2013, at 9:07pm, Blair Zajac wrote: >> >>> Can we not use blacklists on 10.9? Do we need to always use clang? Or is >>> that only for C++ code that we have to use clang

Re: Mavericks java recipe?

On Nov 15, 2013, at 3:04 PM, "Daniel J. Luke" wrote: > Before I do more work on #41378, I figured that I'd ask and see if anyone has > worked up a nice recipe for detecting a java install on Mavericks yet? > > I'd like the subversion-javahlbindings port to be able to warn people and > exit ear

Re: documentation and licensing ...

On Nov 14, 2013, at 2:53 PM, Peter Danecek wrote: > in an attempt to comply with licensing (which the original package might fail > to do), I add some doc files. I have put them into ${portpath}/files and than > copy them directly into destroot. Where are you getting these files coming from?

Re: [113226] trunk/dports/python/py-graph-tool/Portfile

On Nov 12, 2013, at 4:43 PM, mm...@macports.org wrote: > Revision: 113226 > https://trac.macports.org/changeset/113226 > Author: mm...@macports.org > Date: 2013-11-12 13:43:58 -0800 (Tue, 12 Nov 2013) > Log Message: > --- > py-graph-tool: apparently is not part of libstdc++

Re: [113224] trunk/dports/lang/python27

On Nov 12, 2013, at 3:57 PM, j...@macports.org wrote: > Revision: 113224 > https://trac.macports.org/changeset/113224 > Author: j...@macports.org > Date: 2013-11-12 12:57:39 -0800 (Tue, 12 Nov 2013) > Log Message: > --- > python27: version bump to 2.7.6 > > Modified Paths:

Re: [113152] trunk/dports

On Nov 10, 2013, at 8:55 PM, Jeremy Huddleston Sequoia wrote: > On Nov 10, 2013, at 17:18, Lawrence Velázquez wrote: > >> Don't these all have to switch to "autoreconf.args-append" to avoid wiping >> out the default value? > > The default value of

Re: [113152] trunk/dports

On Nov 10, 2013, at 8:04 PM, jerem...@macports.org wrote: > Revision: 113152 > https://trac.macports.org/changeset/113152 > Author: jerem...@macports.org > Date: 2013-11-10 17:04:28 -0800 (Sun, 10 Nov 2013) > Log Message: > --- > multiple: Replace -fvi with -fi in autoreconf

Re: Questions on dependencies

On Nov 10, 2013, at 7:23 AM, Michael Dickens wrote: > How does one indicate a runtime dependency that is checked for at > configure time and not used for building or linking? As previously stated, one could use either depends_lib or depends_build + depends_run, because depends_lib does not curr

Re: Questions on dependencies

On Nov 9, 2013, at 1:35 PM, Craig Treleaven wrote: > So, in a way, we all use depends_lib for certain things as a short-hand for > listing stuff as both depends_build and depends_run, no? That's the general usage, yes. > In a perfect world, maybe we should have a "depends_mod" for indicating a

Re: 'port upgrade foobar' upgrades everything

On Nov 7, 2013, at 11:25 PM, Blair Zajac wrote: > I recall that 'port upgrade foobar' would only upgrade foobar It should actually upgrade foobar and foobar's outdated dependencies, unless you pass "-n". > but it seems that recently it'll upgrade everything. This is happening on my > PPC Pow

Re: @macports.org handle

On Nov 7, 2013, at 12:46 PM, David Strubbe wrote: > 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.

Re: Questions on dependencies

On Oct 31, 2013, at 2:54 PM, Peter Danecek wrote: > (2) python package dependencies > > Intuitively, I would say that most python package dependencies were lib > dependencies. But they actually may install without, right? So is it okay to > declare them lib dependencies or might it be better t

Re: Recommended permissions and ownership of Subversion checkout of dports

On Oct 17, 2013, at 9:53 PM, Ryan Schmidt wrote: > Surely the macports user needs write permission to change things when running > "sudo port sync"? Is there a particular reason you need to run "sudo port sync"? I just run "port sync" on my system, and everything works fine. (I own my Subversi

Re: where to put examples?

On Oct 17, 2013, at 11:18 AM, Peter Danecek wrote: > So now my questions: > - Are there any guidelines on where to place documentations and examples? > - Which would be the correct pattern? > - Does the cited PortGroup Sugar make sense at all? > - Wouldn't it make sense to providing variables des

Re: Merging Gstreamer Update?

On Oct 16, 2013, at 5:00 AM, Dominik Röttsches wrote: > Also, could I get trac bug-editing rights for the account associated with > this email address? Only MacPorts committers can edit Trac tickets. vq ___ macports-dev mailing list macports-dev@list

Re: xinstall vs file copy/mkdir

On Oct 7, 2013, at 11:31 AM, Ryan Schmidt wrote: > On Oct 7, 2013, at 07:16, Davide Liessi wrote: > >> Is there a preferred choice between xinstall and file Tcl extensions? >> Which one should I use? > > For creating directories, they're pretty equivalent. If you need to specify > ownership (

Re: Compile/Link 101

On Oct 4, 2013, at 9:39 PM, Craig Treleaven wrote: > I actually don't know how the test _can succeed_ with XCode 5? There is no > '-L' flag to indicate that the library is under /opt/local/lib. MacPorts sets the LIBRARY_PATH environment variable in the configure phase, which sufficiently rece

Re: variant handling ...

On Oct 3, 2013, at 2:52 PM, Peter Danecek wrote: > On Oct 3, 2013, at 20:40 , Joshua Root wrote: > >> On 2013-10-4 04:07 , Peter Danecek wrote: >>> >>> Hi all, >>> >>> one more question (at least) related to subports. >>> >>> In my Portfile w/ subports I use variants, which allow to switch

Re: Portfile with multiple distfiles of differing extract.suffix

On Sep 30, 2013, at 12:47 PM, Ryan Schmidt wrote: > On Sep 30, 2013, at 11:18, Bradley Giesbrecht wrote: > >> Is there an example Portfile with multiple distfiles of differing >> extract.suffix? > > I can't think of an example at the moment, but you could grep Portfiles for > those with a po

Re: /opt/local on non-boot partition

On Sep 28, 2013, at 6:55 PM, Eric Gallager wrote: > Beware, though, that if you make /opt/local a symlink, you'll run into > https://trac.macports.org/ticket/39850 Only if MacPorts thinks that it's installed to /opt/local. If you build MacPorts from source with --prefix, as Ryan suggested, it s

Re: Temporary fixing a file in /opt/local/share… generated by another port

On Sep 26, 2013, at 11:47 AM, Vincent Habchi wrote: > The newest version of QGis does not compile because of bug in SIP 4.15.x. > Specifically, the file qsyntaxhighlighter.sip located in > ${prefix}/share/pyXX-sip/PyQt4/QtGui is buggy, and causes an error. I own a > fixed copy which allow a co

Re: Supported configurations once Mavericks is released

On Sep 25, 2013, at 4:37 PM, Jeremy Lavergne wrote: > I also like the concept but the distinction of "tier 1: 64-bit unless only > 32-bit" seems a little odd at first glance. I know the exceptional reasons > are valid, conveying them to users on the other hand... > > Do you think there is a cl

Re: [111054] trunk/base/src/port1.0/portconfigure.tcl

On Sep 22, 2013, at 2:46 PM, Rainer Müller wrote: > On 2013-09-14 03:12, lar...@macports.org wrote: >> --- trunk/base/src/port1.0/portconfigure.tcl 2013-09-14 00:55:38 UTC (rev >> 111053) >> +++ trunk/base/src/port1.0/portconfigure.tcl 2013-09-14 01:12:32 UTC (rev >> 111054) >> @@ -51,11 +51,11

Re: introducing Trac_Assigner: a script to automatically assign tickets to their port maintainer

On Sep 24, 2013, at 4:50 PM, Mojca Miklavec wrote: > How would you deal with tickets like this one? > https://trac.macports.org/ticket/39383 If a ticket has multiple ports, just Cc all the relevant maintainers, with no owner. Just like on that ticket. Is there a problem with that? > And what

Re: Fortran recipe

On Sep 23, 2013, at 5:55 PM, David Strubbe wrote: > Right, that is what I was thinking should be done. Except that that is almost certainly incorrect. Most ports that have compiler variants can be installed without any of them selected. So they should only depend on libgcc if a variant *is* se

Re: Fortran recipe

On Sep 23, 2013, at 5:28 PM, David Strubbe wrote: > 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 If that line is not conditionalized

Re: Tcl question ...

On Sep 19, 2013, at 9:37 AM, Peter Danecek wrote: > I see there is the `ln` alias. So I tried to replace the following line >file link ${worksrcpath}/TestBitVector/BitVector.py ../BitVector.py > > with >ln ../BitVector.py ${worksrcpath}/TestBitVector/BitVector.py > > The first work

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

On Sep 18, 2013, at 10:45 PM, "Eric A. Borisch" wrote: > On Wednesday, September 18, 2013, Ryan Schmidt wrote: > >> This is concerning, because it means the port builds differently depending >> on what ports the user already has installed. This won't work right if the >> user gets a pre-compiled

Re: Checksums for patch files?

On Sep 18, 2013, at 2:57 PM, mk-macpo...@techno.ms wrote: > I wonder where to find the documentation of the suffix function used by > py-oursql. Looks like it is appending the extract.suffix, but it is not > obvious that it belongs to extract... http://trac.macports.org/browser/tags/release_2_

Re: Checksums for patch files?

On Sep 18, 2013, at 3:40 AM, Joshua Root wrote: > On 2013-9-18 17:28 , mk-macpo...@techno.ms wrote: >> Hi devs, >> >> could it be advisable to have checksums also for every patch file associated >> with a certain port? >> (But this is probably not needed when the patch file is being pulled via

Re: [111159] trunk/dports/multimedia/gpac/Portfile

On Sep 16, 2013, at 10:08 AM, Frank Schima wrote: > On Sep 15, 2013, at 8:55 PM, ryandes...@macports.org wrote: > >> -# Fix configure execute bit >> post-extract { >> -xinstall -m 550 ${worksrcpath}/configure ${worksrcpath} >> +file attributes ${worksrcpath}/configure -permissions a+x >

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

On Sep 15, 2013, at 9:09 AM, ecro...@macports.org wrote: > Revision: 08 > https://trac.macports.org/changeset/08 > Author: ecro...@macports.org > Date: 2013-09-15 06:09:53 -0700 (Sun, 15 Sep 2013) > Log Message: > --- > autoconf: changing compression requires changin

Re: [111056] trunk/dports/devel/gettext

On Sep 14, 2013, at 9:51 PM, Joshua Root wrote: >> Revision: 111056 >> https://trac.macports.org/changeset/111056 >> Author: larryv at macports.org >> Date: 2013-09-13 18:42:54 -0700 (Fri, 13 Sep 2013) >> Log Message: >> --- >> gettext: Run autoreconf to get libtool that pa

Re: [110825] trunk/dports/python/py-graph-tool/Portfile

On Sep 6, 2013, at 11:12 PM, mm...@macports.org wrote: > Revision: 110825 > https://trac.macports.org/changeset/110825 > Author: mm...@macports.org > Date: 2013-09-06 20:12:08 -0700 (Fri, 06 Sep 2013) > Log Message: > --- > py-graph-tool: blacklist *gcc* <= 4.3 > > Modified

Re: [110690] trunk/dports/devel/boost/Portfile

On Sep 3, 2013, at 7:17 PM, jerem...@macports.org wrote: > Revision: 110690 > https://trac.macports.org/changeset/110690 > Author: jerem...@macports.org > Date: 2013-09-03 16:17:41 -0700 (Tue, 03 Sep 2013) > Log Message: > --- > boost: Fix cxx_stdlib usage > > Modified Path

Re: [110419] trunk/base/src/port1.0/portconfigure.tcl

On Sep 1, 2013, at 12:47 AM, Lawrence Velázquez wrote: > On Aug 31, 2013, at 12:02 PM, Jeremy Huddleston Sequoia > wrote: > >> I reverted this as it prevents the Portfile from overriding (eg: r110452 and >> r110480) and other ports (eg: cctools, ld64, boost) >&g

Re: [110419] trunk/base/src/port1.0/portconfigure.tcl

On Aug 31, 2013, at 12:02 PM, Jeremy Huddleston Sequoia wrote: > I reverted this as it prevents the Portfile from overriding (eg: r110452 and > r110480) and other ports (eg: cctools, ld64, boost) > > If you would like to revise it to support Portfiles setting > 'configure.cxx_runtime', that w

Re: [110369] trunk/base/src

On Aug 30, 2013, at 2:41 PM, jerem...@macports.org wrote: > Revision: 110369 > https://trac.macports.org/changeset/110369 > Author: jerem...@macports.org > Date: 2013-08-30 11:41:03 -0700 (Fri, 30 Aug 2013) > Log Message: > --- > Add support for setting cxx_stdlib in macport

Subport blocks for $name (Was: [MacPorts] #40263: goffice: update to 0.10.6)

On Aug 28, 2013, at 6:38 PM, MacPorts wrote: > #40263: goffice: update to 0.10.6 > -+ > Reporter: c.herbig@… | Owner: macports-tickets@… > Type: update | Status: closed > Priority: Normal | Milestone: > Compo

Re: A question about "massive" changes in the repository

On Aug 27, 2013, at 6:10 AM, Ryan Schmidt wrote: > I would say please do whatever is easiest for you, since you've already spent > a lot of time on this and I don't want you to be delayed in publishing your > work by a cumbersome process. And don't worry about any ports being momentarily broke

Re: A question about "massive" changes in the repository

On Aug 24, 2013, at 7:29 AM, Mojca Miklavec wrote: > - Should this be addressed in a single commit or should ports be > changed one-by-one? (If one-by-one, some ports will be non-functional > for the time of updating.) It's fine to do a single huge commit if all the changes are to fix exactly th

Switching libstdc++ from libsupc++ to libc++abi (Was: [109683] trunk/dports/multimedia/mkvtoolnix/Portfile)

On Aug 20, 2013, at 1:43 AM, Jeremy Huddleston Sequoia wrote: > The issue for is that mkvtoolnix is using libstdc++.dylib provided by libgcc > and other ports that it links against (boost and icu) are using libstdc++ > provided by OS X. Objects cannot be passed between the two runtimes. I >

Re: Fortran recipe

On Aug 25, 2013, at 3:27 PM, Chris Jones wrote: > Hi, > >> There is. >> >> http://trac.macports.org/changeset/104174 > > Is this in the latest release, or only available in the trunk for the moment ? It was released in 2.2.0. https://trac.macports.org/browser/tags/release_2_2_0/base/ChangeLo

Re: Fortran recipe

On Aug 25, 2013, at 3:23 PM, Chris Jones wrote: > On 25 Aug 2013, at 8:17pm, Ryan Schmidt wrote: > >> On Aug 25, 2013, at 14:15, Chris Jones wrote: >> >>> So now I have >>> PortGroup compiler_blacklist_versions 1.0 # Force a compatible clang compiler compiler.blacklist-appen

Re: Fortran recipe

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

Re: new ports dibbler and uftp - commit needed

On Aug 23, 2013, at 11:16 AM, Francois Claire wrote: > Can someone please check tickets #39602 and #40218 and commit the files ? I am working on #40218. Got a little sidetracked. vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https

Re: [109683] trunk/dports/multimedia/mkvtoolnix/Portfile

On Aug 23, 2013, at 5:47 AM, Ryan Schmidt wrote: > Unfortunately, it seems clang does not support all the C++11 features > mkvtoolnix uses; as I'm sure you saw, when using clang, the configure script > says: > > > checking for support for C++11 feature "initializer lists"... no > checking for

Re: Building openmpi with gcc + dragonegg

On Aug 20, 2013, at 2:18 AM, Jeremy Huddleston Sequoia wrote: > > On Aug 19, 2013, at 20:53, Lawrence Velázquez wrote: > >> On Aug 19, 2013, at 3:35 PM, Jeremy Huddleston Sequoia >> wrote: >> >>> I don't think base currently supports choosi

Re: [109882] users/mojca/wxports/x11/xchm/Portfile

On Aug 21, 2013, at 8:20 AM, Mojca Miklavec wrote: > On Wed, Aug 21, 2013 at 9:36 AM, Jeremy Huddleston Sequoia wrote: >> On Aug 20, 2013, at 23:43, mo...@macports.org wrote: >> >>> +# TODO: ImageMagick doesn't need to be universal >>> +# it's only needed to convert the image to png >>>

Re: Building openmpi with gcc + dragonegg

On Aug 19, 2013, at 3:35 PM, Jeremy Huddleston Sequoia wrote: > I don't think base currently supports choosing which version of gcc is used > when selecting the dragonegg compilers. Support for that will need to be > added to trunk/base, and you'll need to wait until that is in a release (+2

<    1   2   3   4   5   6   7   8   9   >