Re: 2.3.2
On 10/16/14, Ryan Schmidt ryandes...@macports.org wrote: On Oct 16, 2014, at 12:50 PM, Joshua Root wrote: So Yosemite is out today. Might as well tag a new release before I build the pkg. Is there anything critical that needs to go onto the branch first? Could we update the checks in configure.ac that test for outdated OS X and Xcode versions? For example, we should inform users of 10.9.4 and earlier that they should update. Update from 10.9.4 to 10.9.5, or to 10.10? The former seems safe enough, as the configure script has traditionally warned about updates between minor versions, but the latter would be a shift in policy (at least as far as the configure script goes), and would most likely be controversial, at least judging by the Why I Run Old System Software thread on macports-users (for which I am still working on my own reply). ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.2
On 10/17/14, Ryan Schmidt ryandes...@macports.org wrote: On Oct 17, 2014, at 1:29 PM, Eric Gallager wrote: On 10/16/14, Ryan Schmidt wrote: For example, we should inform users of 10.9.4 and earlier that they should update. Update from 10.9.4 to 10.9.5, or to 10.10? To 10.9.5. OK, phew, that should be fine then... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: RFC: Python maintenance policy
Maybe not new py24-foo or new py25-foo ports, but what about +python24 or +python25 variants for ordinary ports that have python bindings? For example, this isn't the port itself, but from reading the upstream gdb mailing lists, it looks like gdb upstream actually extended their support for python backwards to python24 with their most recent release this summer (7.8), whereas before they had only supported back to python26... On 9/23/14, Andrea D'Amore and.dam...@macports.org wrote: On Tue, Sep 23, 2014 at 4:46 AM, Lawrence Velázquez lar...@macports.org wrote: == POLICY == […] The policy is informally half in place, noone is actually creating new py24-foo or py25-bar (or at least I hope soo), that said I'm glad to see old py* ports being phased out. This could be handled by the python** portgroups that are already in place after defining stable-version (or latest-stable) variable in the main portgroup. -- Andrea ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On 9/20/14, Ryan Schmidt ryandes...@macports.org wrote: On Sep 20, 2014, at 6:18 PM, Lawrence Velázquez wrote: On Sep 20, 2014, at 2:11 PM, Mark Brethen wrote: On Sep 20, 2014, at 10:30 AM, Clemens Lang wrote: You're thinking it should run automatically instead of user setting? Setting test.run and test.cmd doesn't make MacPorts run the tests automatically. You still have to run `sudo port test` explicitly to run tests. Does that change where the output is sent? No. I'm not aware of a proper method to do this, either. You might be able to fiddle with MacPorts' internal verbosity setting, but that would be a hack. Is the test phase for debugging? Yes, it's for MacPorts developers. It's not supposed to be used by end-users. I wouldn't necessarily say that. The test phase tests the software. Users may well want to test that the software they're going to use passes its test suite. I opened a ticket that is kind of related to that (users wanting to know if their software passes its test suite): https://trac.macports.org/ticket/42731 About variants for tests: I usually find myself making a variant for a port's test phase when the test phase needs a dependency that is not needed for any of the other phases (which is https://trac.macports.org/ticket/38208 btw), or if the configure script needs special flags passed to it to be able to run the `test` target properly (which, on another tangent, is actually normally called `check` according to the GNU Coding standards: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets . I keep finding myself having to override the default `test.cmd` in my Portfiles to set it to `check` because of this. Also note that this target is listed under Standard Targets for Users, so I think that would be another point of evidence for `port test` being a command for end users to use). About the actual topic of this thread, which is displaying the output of the `system` command in Portfiles: I kinda wish that this output was displayed as well... normally as a half-measure I find myself duplicating all of my calls to `system` in Portfiles: first as a call to `ui_debug`, to show what the call to `system` is actually going to do, and then the actual call to `system` itself. While it might not be quite the same as having the actual output, it can at least function as a crude sort of printf debugging... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: echo script output to the display
On 9/25/14, Lawrence Velázquez lar...@macports.org wrote: On Sep 25, 2014, at 2:22 PM, Eric Gallager eg...@gwmail.gwu.edu wrote: Pretty sure `ui_debug` only prints when the user uses the `-d` flag (for debug), as opposed to, say, `ui_info`, which always prints. I know `system` swallows output, but I thought the original point was about sending that output to stdout, and not just to the log or wherever. vq Right, I realize that distinction now; seeing that you had made a separate reply to Ryan helped clarify that for me... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Configuration and environment check command (was: Re: [124047] trunk/base)
Does it have to parallel selfupdate? diagnose works perfectly well by itself without the self in front of it... On 8/26/14, Craig Treleaven ctrelea...@macports.org wrote: On Aug 25, 2014, at 6:35 AM, Rainer Müller rai...@macports.org wrote: However, I am not too happy with naming the command 'port doctor'. Many other commands used with port(1) are verbs, but using this as a verb carries the wrong message. I know where the naming comes from, but there is no need to match any other terminology and we should rather define our own coherent names. My proposal would be to rename this to 'port selfcheck' instead. I second the proposal. Selfcheck is a bit awkward, but it does parallel selfupdate nicely. Anything would be better than doctor, which is transparently derivative. 'port selfexam' ? 'port sefldiagnose' ? Just kidding, but they play on the medical theme... Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
open-cobol update and destroot sandbox violations (was Re: Package open-cobol not working for me)
After seeing https://trac.macports.org/ticket/44485 filed against open-cobol about this same issue, I decided to check up on the upstream bug I had filed that was blocking my update to version 2.0, and found that it had some new responses: https://sourceforge.net/p/open-cobol/bugs/73/ Could someone who is more well-versed in the history of MacPorts help me to better explain to upstream why we install to a destroot and prevent writes outside of it? On Wed, Jun 4, 2014 at 3:26 PM, Michael Peternell michael.petern...@gmx.at wrote: Maybe important: clang is used on OSX, because it has no gcc installed anymore. But clang is the new gcc. To clarify: --- on the command line --- $ gcc clang: error: no input files --- end of command line --- (my system: OSX 10.8.5) Regards, Michael Am 04.06.2014 um 18:38 schrieb Eric Gallager eg...@gwmail.gwu.edu: Maybe I'll install clang 3.4 and 3.5 once I have some spare cycles; my computer just finished rebuilding llvm 3.3 and gcc 4.7 and 4.8 due to the recent updates, and those all took a long time on their own... Anyways, doing the latter of the things you suggested, I seem to have managed to remove the flag from cobc-config, so I will attach a patch once I am done... On Wed, Jun 4, 2014 at 2:44 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 3, 2014, at 8:24 PM, Eric Gallager wrote: open-cobol is actually a source-to-source compiler (or transpiler) that compiles to C code, and then uses the host C compiler to compile the generated C code, which means that something that looks like an open-cobol error might actually be an error with your host compiler. By the error message, it looks like OP is using the clang that comes with Mavericks/Xcode 5, which has gotten overly strict about what it accepts recently, and which I do not use anyways (because I am still on Snow Leopard), so I will not be able to reproduce your error (my /opt/local/bin/cobc successfully compiles the example source file into a runnable executable on my machine). You might be able to reproduce the problem on Snow Leopard if you rebuild open-cobol with configure.compiler=macports-clang-3.5 (or -3.4). Even without doing so, you can confirm that the file /opt/local/bin/cob-config installed by open-cobol contain the -R argument, which as I understand it is never used on OS X. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: perl5.20
Do you also have the years when Apple made each of these versions its system perl as well? On Wed, Jul 23, 2014 at 7:59 PM, Mark Anderson e...@emer.net wrote: Yeah, I'm with Daniel here. I think we should only support the latest version of Perl. From perl.org: *We recommend that you always run the latest stable version, currently 5.20.0* The whole reason we are in this mess is that long gap you see between 5.8 and 5.10 when we all thought Perl 6 was just around the corner (and always will be). Now that we have a yearly release cadence we should just stick to the latest. 5.205.20.02014-05-27 5.185.18.02013-05-18 5.165.16.02012-05-20 5.145.14.0 2011-05-14 5.125.12.02010-04-12 5.105.10.02007-12-18 5.85.8.02002-07-18 —Mark ___ Mark E. Anderson e...@emer.net On Wed, Jul 23, 2014 at 6:48 PM, Daniel J. Luke dl...@geeklair.net wrote: On Jul 23, 2014, at 6:26 PM, Frank Schima m...@macports.org wrote: As long as everything works in 5.20. So far I’m hitting a few bumps with p5.20-digest-sha1 [1] and p5.18-pdl not compiling. I can’t even try p5.20-pdl until p5.20-digest-sha1 is fixed. note that they both build find on a 'vanilla' install of perl5.20... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Boost.Python and g++
On Wed, Jun 4, 2014 at 4:18 PM, René J.V. Bertin rjvber...@gmail.com wrote: On Jun 04, 2014, at 20:21, Eric Gallager wrote: Wow, that looks a lot simpler than I thought that it would be... I was expecting something like this would have to be fixed upstream by gcc, because that is how they handle the GNU vs. NeXT Objective C runtime issues, but if all it takes in this case is this script, it seems like just using this script would be easier... the main thing I worry about would be how the version numbers are hardcoded, but that seems like it should be easy enough to fix. Does gcc still support spec files (cf. gcc -dumpspecs)? Yes. If so, one could probably patch in the information via that mechanism, and not add a series of library specifications regardless of whether you're linking or not ... In any case I'd invoke the system clang compiler. ...this is just to get the version number, right? If we include this script in a port (such as the one ryandesign is working on in https://trac.macports.org/ticket/44413 for example), we could avoid having to actually invoke the compiler by just using the `configure.compiler` setting, and then `reinplace`-ing that into the script. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: new ports and maintainer
A compromise here could be, instead of getting rid of openmaintainer entirely, or keeping it opt-in like it currently is, we could make it opt-out instead. There are two ways we could do this: 1. When committing new ports submitted by users without commit access, make it a policy to automatically add openmaintainer for them unless they specifically request otherwise, or: 2. Get rid of the openmaintainer pseudo-maintainername entirely, and replace it with a new pseudo-maintainername that would be equivalent to what is currently signified by leaving out the openmaintainer pseudo-maintainername. I am not sure what we would call this replacement though... On Thu, Jul 24, 2014 at 3:13 PM, Daniel J. Luke dl...@geeklair.net wrote: On Jul 24, 2014, at 2:37 PM, Sean Farley s...@macports.org wrote: Why not drop 'openmaintainer' and amend the community policy to have every port be what we now call 'openmaintainer'? Furthermore, we could set up a way for the listed port authors to be emailed when a port with their name on it has changed. I, for one, appreciate the ability to specify which ports I don't care if people apply patches to vs. ports where I'm very careful about updating/keeping things from breaking. Ultimately, I'm not willing to provide active support for something that lots of other people are going to (potentially) be updating (and, in general, I prefer to get prior notice of a possible change before it hits the repo). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: What would YOU like to see 'port doctor' do?
On Tue, Jul 22, 2014 at 2:28 AM, Joshua Root j...@macports.org wrote: On 2014-7-22 10:08 , Adam Dershowitz wrote: A few ideas: Checking for files that should not be in macports directory, that end up being there. They could be left either by an old install, or by a different installer that inappropriately put them in the directory (there was some recent discussion of an installer for an application that was built using macports then shipped with an installer so the installer would just put stuff there). Perhaps this could be done by looking at all the files in /opt/local and comparing with all the port contents? Any extras are an error. Unfortunately this is not quite that easy, as there will be various config files, data files, cache files and so on that are not registered to a port. Besides those, there are also the files installed by base itself: https://trac.macports.org/ticket/37853 and also the symlinks created by `port select`: https://trac.macports.org/ticket/43996 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: perl5.20
On Tue, Jul 22, 2014 at 1:37 PM, Daniel J. Luke dl...@geeklair.net wrote: On Jul 22, 2014, at 11:51 AM, Mojca Miklavec mo...@macports.org wrote: - I'm unable to test 1000 ports. we should probably enhance `port test` to be more useful. With the perl modules (at least), they usually have test suites that we should be able to run to verify we're not breaking things - so changes to MacPorts perl could get some tests 'for free' One enhancement for `port test` that I would like to see would be an option to run the test phase automatically instead of having to explicitly call it with `port test`: https://trac.macports.org/ticket/42731 Also test phase dependencies would be useful, especially if we are talking about CPAN ports, because I know when using CPAN manually it would often print a message about some dependencies only being needed for testing: https://trac.macports.org/ticket/38208 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: [MacPorts] #43502: gcc49 @4.9-20140406: move to stable release version
Forwarding this to macports-dev, as I said I would in the ticket (in response to a user request asking that this be brought to the attention of a mailing list): -- Forwarded message -- From: MacPorts noreply@... Date: Thu, Jul 17, 2014 at 12:40 PM Subject: Re: [MacPorts] #43502: gcc49 @4.9-20140406: move to stable release version To: egall@..., mww@... Cc: macports-tickets@..., rouson@..., sebastien.maret@..., kurtjaeke@..., szhorvat@..., mopihopi@..., sean@..., mojca@..., luis.kornblueh@..., damian@..., jse.mnl@..., Peter.Danecek@... #43502: gcc49 @4.9-20140406: move to stable release version --+--- Reporter: egall@… | Owner: mww@… Type: update | Status: new Priority: Normal | Milestone: Component: ports|Version: Resolution: | Keywords: Port: gcc49| --+--- Comment (by egall@…): Replying to [comment:19 damian@…]: Has this port been abandoned? Can anyone suggest another avenue that might yield a more detailed response from a macports developer or maintainer? Is there a mailing list we should contact? I'll forward this to the macports-dev mailing list. I suppose you could also try asking some of the gcc upstream mailing lists... -- Ticket URL: https://trac.macports.org/ticket/43502#comment:20 MacPorts http://www.macports.org/ Ports system for OS X ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
Looks like jmr took care of updating the port for me, thanks jmr! On Fri, Jul 11, 2014 at 7:38 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 11, 2014, at 7:19 AM, Eric Gallager eg...@gwmail.gwu.edu wrote: Right, this just reminded me, I need to update the port-depgraph port to work with MacPorts 2.3+... is there already a newer subversion revision that I could point it at, or would I have to update the actual port-depgraph script myself, too? It doesn't look like the script has been modified since 2011. However, 2.3 compatibility should be easy; see other scripts for the minor changes that need to be made. I have some other changes to depgraph that I need to commit too... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Binary distributability of codeblocks: GPL OpenSSL conflict
Right, this just reminded me, I need to update the port-depgraph port to work with MacPorts 2.3+... is there already a newer subversion revision that I could point it at, or would I have to update the actual port-depgraph script myself, too? On Fri, Jul 11, 2014 at 6:48 AM, Ryan Schmidt ryandes...@macports.org wrote: Or if you prefer a more visual representation, install the port-depgraph port. $ port info port-depgraph port-depgraph @0.1.0 (sysutils, macports) Description: Run a recursive dependency listing against a given port, outputing a Graphviz graph description. Homepage: http://svn.macports.org/repository/macports/contrib/port-depgraph Fetch Dependencies: subversion Library Dependencies: graphviz Platforms:darwin License: BSD Maintainers: eg...@gwmail.gwu.edu, openmaintai...@macports.org On Jul 10, 2014, at 8:20 PM, Joshua Root j...@macports.org wrote: port rdeps On 2014-7-11 10:15 , David Strubbe wrote: 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 mailto: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 not distributable because its license gpl conflicts with license OpenSSL of dependency openssl ffmpeg-gnutls-nettle-openssl ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [121692] trunk/dports/sysutils
On Mon, Jul 7, 2014 at 4:12 PM, Aljaž Srebrnič g...@macports.org wrote: Should we start thinking about a golang PortGroup? Yeah, the amount of golang-using software has been slowly increasing lately, but not much of it has made it to MacPorts yet. Having a golang PortGroup would definitely make it easier to create the ports needed to bring some of these things to MacPorts. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Missing (build) dependencies as found through trace mode.
The way I would handle each of those categories would be: - mandatory: simple enough, just use a `port:`-style depspec - recommended: use a `bin:`-style depspec, so the system versions can still satisfy it. Note that the autogen port does not fit in with the rest of the autotools suite, despite its name (this confusion is further compounded by the fact that many software packages call their local autoreconf-equivalent scripts autogen.sh, which is a practice that autotools upstream frowns upon: see http://www.gnu.org/software/automake/manual/html_node/Future-of-aclocal.html#Future-of-aclocal for more on why these scripts are confusing and bad), so I would not include autogen in this category. - optional: make a separate variant for them, depending on what the configure script does with them once it finds them, and use a `port:`-style depspec in the variant. In the apache2 example, only the first one of lynx/links/elinks is actually used, so only a dependency on lynx would be necessary. - very optional: make a separate variant for them, and use a `bin:`-style depspec in the variant. Since the addition of dependencies of this type do not technically change how the software actually gets built (which is what variants are supposed to be used for), be sure to add a note or something mentioning that the variant only exists to placate trace mode's pedantry (and anyone's own personal OCD). Although some people might object to such a variant even with such a note, so you might want to be careful with these ones. - ???: The cctools-headers one reminds me, it would be nice to have a `header:`-style depspec, to match the `bin:`-style and `lib:`-style ones On 6/27/14, Mihai Moldovan io...@ionic.de wrote: This said, I have a rather huge list of ports to upgrade, so I'll keep track of all of them and make a list of categorized missing dependencies. Currently I have the categories: mandatory: build failures recommended: better to have them around, stuff like autogen, automake, autoconf etc. optional: dependencies to make configure happy, like elinks, links, lynx in the apache2 example very optional: being searched for, but system tools can do the job just as well. No build or configure failures due to these, otherwise auto-move to mandatory. Stuff like gawk, gsed, grep, gzip etc. ???: dependencies I have no idea how to handle. Stuff like cctools, cctools-headers, bison etc. Mihai ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Missing (build) dependencies as found through trace mode.
On 6/29/14, Mihai Moldovan io...@ionic.de wrote:
* On 30.06.2014 04:06 am, Eric Gallager wrote:
Note that the autogen port does not fit in with
the rest of the autotools suite, despite its name
gnutls has been searching for ${prefix}/bin/autogen. Not sure what it meant
to find, exactly. I assumed the autogen port, but this may be wrong.
It doesn't seem to be any part of GNU autotools.
Oh yeah, gnutls is actually the autogen port; I believe we had a
ticket about that: https://trac.macports.org/ticket/42728
- optional: make a separate variant for them, depending on what the
configure script does with them once it finds them, and use a
`port:`-style depspec in the variant. In the apache2 example, only the
first one of lynx/links/elinks is actually used, so only a dependency
on lynx would be necessary.
Also in this case, I tend to put MacPorts-only software in this category.
A lot of those unmet dependencies seem to be stemming from configure trying
find
software to enable additional features. Then again, who would really enable a
gtkdoc variant for gnutls? Wouldn't it be better to just turn this stuff
off via a --disable- or --without- configure switch?
This isn't gtk-doc specifically, but I do have a more general `+docs`
variant in my local gnutls2 Portfile... it also adds a dependency on
`bin:xsltproc:libxslt` and on texinfo, and uses the configure switches
as well:
https://github.com/cooljeanius/LocalPorts/blob/master/devel/gnutls2/Portfile#L182
Even better, cmake's list: (optional) port:bzr port:dpkg port:root5
port:mercurial port:qt4-mac port:openssh port:subversion
file:include/cairo/cairo.h:cairo port:fontconfig port:freetype
port:gdk-pixbuf2
file:include/glib-2.0/glib-object.h:glib port:gtk2
file:include/pango-1.0/pango/pango.h:pango port:gettext port:python26
where are you getting this from?
- very optional: make a separate variant for them, and use a
`bin:`-style depspec in the variant. Since the addition of
dependencies of this type do not technically change how the software
actually gets built (which is what variants are supposed to be used
for), be sure to add a note or something mentioning that the variant
only exists to placate trace mode's pedantry (and anyone's own
personal OCD). Although some people might object to such a variant
even with such a note, so you might want to be careful with these
ones.
Almost every software has a rather long list of this dependency type.
Maybe just ignoring that and letting trace mode bark is good enough here?
As already pointed out by you, there's no functional difference when building
the
software, whether with or without those dependencies.
Creating a variant for everything sounds like a maintaining nightmare
(and it doesn't help us anyway.)
Just to clarify, I didn't mean one variant per dependency, but rather
one mega trace mode compliance variant that has all of them. I
sometimes stick these in a variant where I make other
maintainer-specific changes, such as forcing autoreconfing, or
enabling additional warnings, and stuff like that.
- ???: The cctools-headers one reminds me, it would be nice to have
a `header:`-style depspec, to match the `bin:`-style and `lib:`-style
ones
Yeah, but that's not trivial. See, for instance, gl.h, provided by mesa
and...
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/
Wouldn't that second one actually be OpenGL/gl.h as opposed to the
GL/gl.h that mesa installs, due to how framework headers are
written?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [120643] trunk/dports/lang/eero-devel
On 6/6/14, Brandon Allbery allber...@gmail.com wrote:
On Fri, Jun 6, 2014 at 1:58 PM, Vincent vi...@macports.org wrote:
With the quotes. Pedantically ${1+$@} is most correct, but (a) I
suspect the case that protects against would fail anyway, and (b) on OS X
/bin/sh is bash which handles $@ as if it were ${1+$@}. (I do wonder
how long before Apple abandons bash though)
I must admit I fail to see what ${1+“$@”} exactly refers to…
In classic Bourne shell, $@ produces a single empty quoted string if
there are no shell parameters. ${1+$@} means expand $@ if and only if
$1 is set, even if it is set to an empty string. The Korn shell
(specifically ksh93, IIRC) introduced the interpretation of $@ that bash
uses.
As the Korn shell is open source now, it would not surprise me if that
replaced bash at some point, should Apple decide it needs a newer shell
than a GPL2-ed bash. zsh also has a permissive license (although some
contributed scripts are GPL; I haven't checked the version) and might also
be an alternative.
Wasn't zsh actually already the default shell in OS X previously back
in the early days of OS X, before Apple switched to bash? Or am I
mis-remembering and getting it mixed up with tcsh?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE3
Of those ports you mention, I currently only have kchmviewer installed on my current machine, which I installed while testing different chm-viewing applications. I generally use the Chmox port for those purposes now though. I would still urge caution when removing/obsoleting the rest though, just in case. While kde3 may be old and in some cases broken, one advantage that it does have is a smaller installation footprint and does not take as long to compile. I have been leaving qt3 installed on my current machine for this reason for a while, so that its conflict with qt4-mac will prevent my machine from wasting time compiling qt4-mac, at least until I have more compile time available... On 6/4/14, Nicolas Pavillon ni...@macports.org wrote: Hello, This topic has been discussed some time ago on this mailing list without a real conclusion, but I am again considering the status of KDE3 on Macports. Considering that Qt5 is out and KDEF5 is soon to be released, it makes KDE3 more and more obsolete. Furthermore, it seems to not build presently on the later platforms (ticket #41136). I would therefore start considering making the whole KDE3 suite gradually obsolete unless there is some opposition after my mail. Considering the existing ports, it seems to me that there are first some dependents ports which could be dealt with (see list below), and then the KDE3 suite itself which could be made obsolete in a second stage. I tried to make below a list of the existing ports depending on kde3 that I hope to be exhaustive, along with my opinion about their status. Of course, any opinion is welcome about them. My idea would be that in case all the ports below can be handled, I would seriously consider to then make the whole kde3 suite obsolete too. Ports that can be replaced: - kmymoney: can be replaced with kmymoney4 - filelight: can be replaced with kde4-filelight - kcachegrind: can be replaced with kcachegrind4 - konversation11: can be replaced with konversation Ports without replacement: - kchmviewer: still depends on qt3, possesses a variant for kde which is said to be untested. The variant could be dropped in my opinion. - klibido: appears to be not developed anymore since 2006. After 8 years, the ports could be made obsolete. - ndmanager: there was a notice announcing the passage to qt4 in mid-2013, but no new development. Could be made obsolete. - qalculate-kde: there is a new version for kde4, but I could not get it to build. Even qalculate-gtk does not build presently on my platform. If the build is not fixed, it could be made obsolete anyway. - koffice: This is a big piece of kde3, along with a whole bunch of language ports. There is a koffice2-devel port, but it has not been maintained at all (nomaintainer). It still depends on the old kde4 1.0 portgroup, and fails at the configure stage. As it is a non-working *-devel port, I would tend to make it obsolete. There is also a new submission request for calligra (ticket #37579), which has not been submitted yet. I tested a little bit with the latest versions, and I can get something partly working, so that a port commit could be considered with what I have. For what I understand from a simplistic web search, calligra seems more promising than koffice2 as a stable release software. Koffice may then be set a replaced by calligra. From the list above, there could be some clean up which could be beneficial, along with some ports which are clearly obsolete. Then, in the case all of the above can be dealt with, it seems to me that kde3 could be set as obsolete and replaced by kde4. However, this simplistic way of expressing it does not consider the mess of ports in both architectures, so that a way of making the transition should be thought of. Cheers, Nicolas ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: KDE3
On 6/5/14, Mojca Miklavec mojca.miklavec.li...@gmail.com wrote: On Thu, Jun 5, 2014 at 2:34 PM, Eric Gallager wrote: Of those ports you mention, I currently only have kchmviewer installed on my current machine, which I installed while testing different chm-viewing applications. I generally use the Chmox port for those purposes now though. There's also xCHM (also packaged in MacPorts; before you ask – no, it doesn't need X11 [any longer]). Mojca I did try that as well, but it crashes on startup for me (which I guess I should file a ticket about)... I also tried chmsee, but that depends on firefox-x11, which no longer exists (which I also need to file a ticket about)... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [120476] trunk/dports/cross/avrdude/Portfile
I thought that that ticket was for doxygen though... so are you saying
that avrdude depends on the same parts of texlive that doxygen does?
On 6/5/14, Aljaž 'g5pw' Srebrnič g...@macports.org wrote:
You’re correct, see #43894[1] to track the bug resolution.
[1]: https://trac.macports.org/ticket/43894
On 04 giugno 2014 at 20:34:33, Eric Gallager (eg...@gwmail.gwu.edu) wrote:
Also, while we are commenting on this revision, is the entirety of
texlive
really needed for the docs variant? If the description says that it
requires LaTeX, that seems to me like it would just indicate a dependency
on texlive-latex or maybe texlive-latex-extra, but not necessarily the
whole texlive distribution... but idk, I could be wrong, just
wondering...
On Thu, May 29, 2014 at 5:01 PM, Ryan Schmidt
wrote:
On May 29, 2014, at 10:22 AM, g...@macports.org wrote:
Revision
120476
Author
g...@macports.org
Date
2014-05-29 08:22:23 -0700 (Thu, 29 May 2014)
Log Message
cross/avrdude:
docs require latex to be present, so adding texlive ad a build
dependency,
and making the variant optional
Modified Paths
• trunk/dports/cross/avrdude/Portfile
Diff
Modified: trunk/dports/cross/avrdude/Portfile (120475 = 120476)
--- trunk/dports/cross/avrdude/Portfile 2014-05-29 15:13:37 UTC
(rev 120475)
+++ trunk/dports/cross/avrdude/Portfile 2014-05-29 15:22:23 UTC
(rev 120476)
@@ -5,6 +5,7 @@
name avrdude
version 6.1
+revision 1
categories cross devel
maintainers bdmicro.com:bsd
description an Atmel AVR MCU programmer
@@ -29,10 +30,8 @@
configure.args --mandir=${prefix}/share/man \
--disable-parport
-variant docs description {Build documentation} {
- depends_build-append port:texinfo
+variant docs description {Build documentation (requires LaTeX)} {
+ depends_build-append port:texlive
configure.args-append --enable-doc
}
-
-default_variants +docs
There is no reason to revbump when removing default variants, because
MacPorts will not remove variants from an installed port unless the
user
explicitly tells it to do so (e.g. by using sudo port upgrade
--enforce-variants avrdude -docs)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
--
Aljaž 'g5pw' Srebrnič
Sent with Airmail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Access to machines with old OS versions/architectures, like 10.4, 10.5, ... ppc
As far as access to old hardware goes, I have an old PowerPC iMac G3 running 10.3.9 sitting in my basement gathering dust (which is too old to even build base, so I am not sure why I even mentioned it...), and an old white plastic MacBook running 10.5/i386, which I do not think I have installed MacPorts on (yet), but I probably could do so easily... I am pretty sure that it does have Fink and TigerBrew on it though. I suppose I could set it up as a server, but seeing as it is a laptop, it would feel kind of weird to leave it just sitting there running all the time... The laptop I currently use (a 13 mid-2009 MacBook Pro running 10.6/x86_64) could also be considered old, but there is no way that I am letting other people ssh into my machine while I am also using it myself. I suppose I can see what I can do about the other, older one though... On 6/5/14, Mojca Miklavec mo...@macports.org wrote: Hi, I was wondering if there was any chance/interest to set up a bunch of computers with different architectures and OS versions installed (but mainly setups like 10.4/PPC, 10.4/i386, 10.5/PPC, 10.6/x86_64) so that a few trusted developers could have ssh access to those machines in order to be able to test and fix issues on those machines every now and then. I know that these OSes are no longer officially supported and I'm aware that a lot of software will simply stop working on the old boxes at some point (Fink uses branches: if new software version doesn't support the old OS, it stays at the old version; of course there are drawbacks to that approach as well), but I imagine that there are: - people or companies willing to donate old functional hardware - probably some individuals willing to plug them in somewhere - developers willing to play and nail some of the problems/bugs down (A similar, but different feature would be a slightly more capable machine running the latest OS for developers with older hardware and software.) Is there anyone else who would find such a setup useful? Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: certsync: Please test patches on systems 10.9
On 6/5/14, Clemens Lang c...@macports.org wrote: Hi, Thanks for the feedback everyone. More details inline below: Like we do with the Portfiles in trunk, could you split the patch between the whitespace changes and the functionality changes? I could, but it would mean extra work for me because our version control system does not support generating (or committing) partial patches. So I'm just not going to bother. Right now with the two of them together, it is kind of harder to know which sections of the patch to focus on when reading it... Looking at the patch, it's not very hard to ignore the whitespace-only hunks, especially since they're mostly separated from the changes in the code. Reading the diff isn't very helpful anyway, though, because I completely swapped one function with a different one, making the diff pretty meaningless. Fails to build on Snow Leopard: built-in:0: warning: Mac OS X version 10.5 or later is needed for use of the new objc abi I'm not sure what that means. new means 64-bit in that case. You get that warning when you compile for a 64-bit architecture with '-mmacosx-version-min=' set to '10.4' or lower. certsync.m:226: warning: implicit declaration of function ‘SecTrustGetTrustResult’ Undefined symbols: _SecTrustGetTrustResult, referenced from: _certificatesForTrustDomain in ccQPWJhT.o ld: symbol(s) not found collect2: ld returned 1 exit status I've removed the call to SecTrustGetTrustResult. Its result was unused anyway. Leopard: certsync.m:162: warning: implicit declaration of function ‘SecPolicyCreateBasicX509’ I've provided an alternative implementation of the same behavior for systems without SecPolicyCreateBasicX509. The source of SecurityTool [1] was very helpful for this. and Tiger: certsync.m:28:25: error: Availability.h: No such file or directory That would require a configure script to fix, but … certsync.m:294: warning: implicit declaration of function 'SecTrustSettingsCopyTrustSettings' certsync.m: In function 'exportCertificates': certsync.m:402: warning: implicit declaration of function 'SecCopyErrorMessageString' … since I think those have been present before my changes, I'm not sure I'm going to bother. It looks like it's just a matter of wrapping the call to SecTrustSettingsCopyTrustSettings in an if that checks for the function's availability and just consider the certificate trusted if there aren't any. The calls to SecCopyErrorMessageString could probably be replaced by a dummy message on systems that don't have the function. Please test again (and feel free to patch for Tiger, especially if you can test on this system, because I'm fishing in muddy waters there, given I can't verify only the *trusted* roots are exported). [1] http://opensource.apple.com/source/SecurityTool/SecurityTool-40596/verify_cert.c -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Boost.Python and g++
Wow, that looks a lot simpler than I thought that it would be... I was expecting something like this would have to be fixed upstream by gcc, because that is how they handle the GNU vs. NeXT Objective C runtime issues, but if all it takes in this case is this script, it seems like just using this script would be easier... the main thing I worry about would be how the version numbers are hardcoded, but that seems like it should be easy enough to fix. (cc-ing macports-dev because this seems like more of a development issue) On Mon, Jun 2, 2014 at 7:29 AM, Akim Demaille akim.demai...@gmail.com wrote: Hi all, A long long time ago I had started discussing (well, complaining might be more appropriate :-) about the fact that I could no longer use g++ to compile my project, because Boost.Python was compiled with clang++'s libc++. Well, since then I managed to wrap a dirty script, g++-libc++, which does the trick for me: it compiles with g++, but using libc++. It might be useful for some users. Actually, maybe it should be shipped with MacPorts' g++ (some distros provide similar scripts to GNU/Linux to use clang++ on top of libstdc++). Cheers. ___ macports-users mailing list macports-us...@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: certsync: Please test patches on systems 10.9
Like we do with the Portfiles in trunk, could you split the patch between the whitespace changes and the functionality changes? Right now with the two of them together, it is kind of harder to know which sections of the patch to focus on when reading it... On Mon, Jun 2, 2014 at 6:41 PM, Clemens Lang c...@macports.org wrote: Hi, […] test the attached patch […] Attached, sorry. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [120476] trunk/dports/cross/avrdude/Portfile
Also, while we are commenting on this revision, is the entirety of texlive
really needed for the docs variant? If the description says that it
requires LaTeX, that seems to me like it would just indicate a dependency
on texlive-latex or maybe texlive-latex-extra, but not necessarily the
whole texlive distribution... but idk, I could be wrong, just wondering...
On Thu, May 29, 2014 at 5:01 PM, Ryan Schmidt ryandes...@macports.org
wrote:
On May 29, 2014, at 10:22 AM, g...@macports.org wrote:
Revision
120476
Author
g...@macports.org
Date
2014-05-29 08:22:23 -0700 (Thu, 29 May 2014)
Log Message
cross/avrdude:
docs require latex to be present, so adding texlive ad a build
dependency,
and making the variant optional
Modified Paths
• trunk/dports/cross/avrdude/Portfile
Diff
Modified: trunk/dports/cross/avrdude/Portfile (120475 = 120476)
--- trunk/dports/cross/avrdude/Portfile 2014-05-29 15:13:37 UTC
(rev 120475)
+++ trunk/dports/cross/avrdude/Portfile 2014-05-29 15:22:23 UTC
(rev 120476)
@@ -5,6 +5,7 @@
name avrdude
version 6.1
+revision 1
categoriescross devel
maintainers bdmicro.com:bsd
description an Atmel AVR MCU programmer
@@ -29,10 +30,8 @@
configure.args--mandir=${prefix}/share/man \
--disable-parport
-variant docs description {Build documentation} {
-depends_build-append port:texinfo
+variant docs description {Build documentation (requires LaTeX)} {
+depends_build-append port:texlive
configure.args-append --enable-doc
}
-
-default_variants +docs
There is no reason to revbump when removing default variants, because
MacPorts will not remove variants from an installed port unless the user
explicitly tells it to do so (e.g. by using sudo port upgrade
--enforce-variants avrdude -docs)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Permissions change with MacPorts 2.3?
According to Fink's documentation, adding a .build extension to the
folder name has the same effect as adding a .noindex extension to it,
which is what they do with their build folder:
http://www.finkproject.org/doc/users-guide/uguide.en.html#conf.optional
So that could be another option...
On Tue, Jun 3, 2014 at 9:16 PM, Craig Treleaven ctrelea...@cogeco.ca
wrote:
At 11:02 PM +0200 6/3/14, Clemens Lang wrote:
Hi,
I sometimes use EasyFind to search in portfiles. I noticed today
that the macports folder under ${prefix}/var is no longer visible. I
would guess this happened after I upgraded to MacPorts 2.3 but I
can't be certain. Using the command line, I see the following:
[Š]
Was it an intended change to hide this directory? Or a glitch on my
system?
That was intentional. In specific, it's this Changelog entry:
Disable Spotlight indexing on build directories, distfiles,
registry, log files, archives, base source and the default ports
tree. (cal in r113649)
You can avoid this by manually reverting the change and touching a file
named .nohide in the directory. See
http://trac.macports.org/changeset/113649
Thanks. I noticed that in the change log but didn't see how it was
implemented.
Based on some searching (ie no hands-on experience!), it seems that it
might be simpler to create a .metadata_never_index file [1] inside that
folder to encourage Spotlight to leave it alone. Alternatively, we could
add .noindex to the folder name to achieve the same effect.
Wouldn't one of these be a better solution?
Craig
[1] http://apple.stackexchange.com/questions/92784/
preventing-spotlight-from-indexing-files-folders
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ticket port command?!
On Tue, May 20, 2014 at 5:21 PM, Bradley Giesbrecht pixi...@macports.org wrote: There is the macportsscripts port, I don't know much about it The macportsscripts port used to be phw's, and installed a single script, port-fetchall.sh, that dealt with the issue described in https://trac.macports.org/ticket/2421. I took it over after forking it and adding a bunch of new scripts to it: https://trac.macports.org/ticket/37836 Since then I have updated the port 3 more times: https://trac.macports.org/ticket/38432 https://trac.macports.org/ticket/39117 https://trac.macports.org/ticket/41788 Most of the scripts in it are just ones that I have found on Trac or elsewhere around the internet, but I have modified them and stuff. If you find other scripts elsewhere that you would like added to the repo, just send me a pull request or let me know some other way or something. In users/pixilla/scripts I have prefixed my commands/scripts with mp- which I like because I can type mp- and hit tab a couple times to see what commands I have available to me. I try to mimic what the command does in the name like mp-svn-up-dports. Where the name ends with port, like mp-svn-log-port we run svn log on whatever port makes of our input. example: mp-svn-log-port maintainer:g5pw Regards, Bradley Giesbrecht (pixilla) On May 20, 2014, at 4:29 AM, Aljaž 'g5pw' Srebrnič g...@macports.org wrote: Thanks for the links, Bradley. I was thinking that it would probably be nice to have a common set of utilities like there to ease portfile development. What do you guys think? On 19 maggio 2014 at 19:28:27, Bradley Giesbrecht (pixi...@macports.org) wrote: On May 13, 2014, at 12:53 AM, Aljaž Srebrnič wrote: This may be the script Ryan uses: http://trac.macports.org/browser/users/ryandesign/scripts/portissues I use this script: http://trac.macports.org/browser/users/pixilla/scripts/mp-trac-tickets-port mp-trac-tickets-port name:^dovecot2 Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: ticket port command?!
Just realized that I forgot to make sure that this made it back to the lists, so re-cc-ing macports-dev... On Mon, May 12, 2014 at 3:23 AM, mk-macpo...@techno.ms wrote: Hi Eric, On 12 May 2014, at 01:40 , Eric Gallager eg...@gwmail.gwu.edu wrote: Yes, it would be... I came across a script that did the querying and viewing parts before, so I added it to my macportsscripts repo: https://github.com/cooljeanius/macportsscripts/blob/master/macportstrac.sh thanks for the link. (the macportsscripts port should install it) Oh, I didn’t know it even exists as a port. :) But yeah, that script is really rudimentary and stuff, and it would be much better to have the sort of functionality you were describing in base instead of in some random script. As Brad wrote, this is all about viewing, but as I suggested the pre-filling of a new ticket form as well as uploading of the often asked for main.log would be a valuable addition to it, which is why it should be part of port’s TCL code base, I believe. But I’ll install your port as well as Brad’s scripts this evening. Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: trac down?
So it is. Thanks for getting it up again! On Tue, May 20, 2014 at 9:34 AM, Shreeraj Karulkar skarul...@apple.comwrote: All Trac is up again. Shree On May 20, 2014, at 3:24 AM, Ryan Schmidt ryandes...@macports.org wrote: On May 20, 2014, at 05:19, Peter Danecek peter.dane...@bo.ingv.it wrote: I have problems to contact trac and http://www.downforeveryoneorjustme.com/trac.macports.org indicates that this is not only a local problem. Can someone look into this? I've forwarded your message to admin at macosforge dot org; they're the ones who can address infrastructure issues. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] InstallingMacPorts modified
I was under the impression that the recommendation to install X11 was just a recommendation, and not actually a requirement... The section does not actually say that installing X11 is a requirement to use MacPorts, it just says that it is highly recommended for many MacPorts apps. Although I suppose that could be clarified some... On Fri, May 16, 2014 at 10:28 PM, Ryan Schmidt ryandes...@macports.orgwrote: On May 11, 2014, at 20:47, MacPorts nore...@macports.org wrote: Page InstallingMacPorts was changed by eg...@gwmail.gwu.edu Diff URL: https://trac.macports.org/wiki/InstallingMacPorts?action=diffversion=73 Revision 73 Comment: the Install XWindows (X11) section is kind of out-of-date; add some updated information to it We should really just remove it. Installing X11 is not required to use MacPorts, and hasn't been for many years. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] InstallingMacPorts modified
Oops, did not see this before updating in https://trac.macports.org/wiki/InstallingMacPorts?action=diffversion=74 ... anyways, the directions on how to install it with MacPorts are under there, too, but that is just one way to do it. While it might be better to install it with MacPorts, the user should at least know how it has traditionally been done and why we now recommend installing it with MacPorts so that they can have all the information to properly evaluate whether they want to do things the old way or the new way. On Mon, May 19, 2014 at 6:02 PM, Ryan Schmidt ryandes...@macports.orgwrote: On May 19, 2014, at 17:00, Eric Gallager wrote: On Fri, May 16, 2014 at 10:28 PM, Ryan Schmidt wrote: On May 11, 2014, at 20:47, MacPorts wrote: Page InstallingMacPorts was changed by eg...@gwmail.gwu.edu Diff URL: https://trac.macports.org/wiki/InstallingMacPorts?action=diffversion=73 Revision 73 Comment: the Install XWindows (X11) section is kind of out-of-date; add some updated information to it We should really just remove it. Installing X11 is not required to use MacPorts, and hasn't been for many years. I was under the impression that the recommendation to install X11 was just a recommendation, and not actually a requirement... The section does not actually say that installing X11 is a requirement to use MacPorts, it just says that it is highly recommended for many MacPorts apps. Although I suppose that could be clarified some... I don't even recommend it. If you need the X11 app, install it using MacPorts (sudo port install xorg-server). ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Welcome Our GSoC 2014 Students
I would have applied if I were still a student this year, but I graduated last May, so I would have felt a little dishonest applying for something that is supposed to be for students when I am no longer one... On Thu, Apr 24, 2014 at 1:57 PM, Clemens Lang c...@macports.org wrote: Hi Mojca Congratulations to everyone. In case it's not a secret, I would be interested to know how many students applied. It isn't. We had six applications this year. IIRC that's in the ballpark of what we always had, but a little more would have been nice, I guess. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Orfeotoolbox 4
There is a `notes` keyword that can be used in Portfiles to display stuff under `port notes` and at the end of the process of installing a port On Thu, Apr 24, 2014 at 5:02 AM, Vincent Habchi vi...@macports.org wrote: Hi there, would it be possible to add to the Orfeotoolbox Portfile a few lines to display, at the end of the install phase, a message explaining how to configure QGis 2.2 to use the library? Thanks, Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: doxygen issue ...
Instead of modifying the Makefile, how about trying to modify the Doxyfile instead? That was what eventually worked for me when I was running into some issues with doxygen when adding a `+docs` variant to the port for dpkg... On Tue, Apr 22, 2014 at 2:16 PM, Peter Danecek peter.dane...@bo.ingv.itwrote: Hi all, I am running into some quite stupid build problem with a not yet official globus port, `globus_ftp_control`. This software also builds documentations via doxygen and the problem is related to doxygen/pdflatex, but I have no idea how to fix this. During the process doxygen creates some Makefile with a loop to run `pdflatex` several times until no rebuild is needed. The logic is probably that it would run few times, and if there is some problem and the process does not converge, this is caught at count=5. Now looking into the details I realise that on my system the document/pdflatex, there are really 5 iterations need to build the document, so I hit the limit and the process is interrupted. A easy fix would e to raise the no. of iterations, or to modify the Makefile in some other way. But as all this doc directories are created during the build by doxygen I have no idea how to influence the process. Any ideas what could be done to solve this issue? Thanks! ~petr ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: doxygen issue ...
The patch with the `+docs` variant has not yet been committed to trunk: https://trac.macports.org/ticket/39018 Actually looking at the last patch I attached to that ticket, it appears that it does not yet have the part where I fixed the Doxyfile... However, that ticket already has enough patches attached to it, so instead of attaching more, I will just wait until that part is committed and then open a new ticket for my further fixes to the `+docs` variant. In the meantime you can see my patch for the Doxyfile here: https://github.com/cooljeanius/LocalPorts/blob/master/sysutils/dpkg/files/patch-doc_Doxyfile.in.diff (note: a lot of the changes in that diff were just made by running `doxygen -u`; only a few of them were actually manual...) On Thu, Apr 24, 2014 at 10:47 AM, Peter Danecek peter.dane...@bo.ingv.itwrote: [Resend including the list, updated] On 24 Apr 2014, at 15:53, Eric Gallager eg...@gwmail.gwu.edu wrote: Instead of modifying the Makefile, how about trying to modify the Doxyfile instead? That was what eventually worked for me when I was running into some issues with doxygen when adding a `+docs` variant to the port for dpkg... For sure in practice it is not possible to act on the Makefile which is dynamically created in the build step. But I have no idea how this would be influences in doxygen and where to start looking. Now, I will have closer look into the `Doxyfile` and the cited port to get a better idea. Update: I actually looked at the port `pdkg`, but found no trace of some patch to Doxyfile or a `+docs` variant. Are you referring really to this port? I also looked at the `Doxyfile` and found no parameter which would influence the rebuild look. Thanks! ~petr On Tue, Apr 22, 2014 at 2:16 PM, Peter Danecek peter.dane...@bo.ingv.it wrote: Hi all, I am running into some quite stupid build problem with a not yet official globus port, `globus_ftp_control`. This software also builds documentations via doxygen and the problem is related to doxygen/pdflatex, but I have no idea how to fix this. During the process doxygen creates some Makefile with a loop to run `pdflatex` several times until no rebuild is needed. The logic is probably that it would run few times, and if there is some problem and the process does not converge, this is caught at count=5. Now looking into the details I realise that on my system the document/pdflatex, there are really 5 iterations need to build the document, so I hit the limit and the process is interrupted. A easy fix would e to raise the no. of iterations, or to modify the Makefile in some other way. But as all this doc directories are created during the build by doxygen I have no idea how to influence the process. Any ideas what could be done to solve this issue? Thanks! ~petr ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Is there a way to figure out which deps would have to be build from sources
On Sat, Apr 12, 2014 at 4:55 PM, mk-macpo...@techno.ms wrote:
Hi devs,
I just wonder whether someone out there
has already written some script
which can determine for any given port A
whether non-binary ports B1-Bn are to be build
during port A's installation.
Greets,
Marko
P.S.: I do know that there is mp-distributable.sh in order to determine
whether a port is binary-distributable.
Well, if there is already mp-distributable.sh, then it probably should not
be too hard to loop over a port's rdeps and run that script for each of
them... maybe something like this?
#!/bin/sh
for depport in `port -q rdeps $1`; do
sh /path/to/mp-distributable.sh ${depport}
done
(note: not actually tested yet)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Where do I find a good example of a tests variant (which is really installing the tests on the system)?
On Fri, Apr 11, 2014 at 6:52 PM, mk-macpo...@techno.ms wrote: On 21 Mar 2014, at 00:14 , Ryan Schmidt ryandes...@macports.org wrote: I'm not aware of any ports that do that, or any tests that are designed to work that way. Only recently I came across the test phase which can be defined in a portfile. I've introduced properly running tests for kmymoney4-devel with r118839. The user can build and run the tests by using this sequence: -- $ sudo port test kmymoney4-devel +tests -- Yeah, I have noticed that my Portfiles with test phases usually end up with the test phase hidden in a variant like that as well, although in my case it is usually because there is no way to specify dependencies needed just for the test phase: https://trac.macports.org/ticket/38208 (which is why I just stick them in a variant instead) Afterwards the user could proceed with -- $ sudo port install kmymoney4-devel +tests -- without the tests actually being installed in the system, which the tests variant might imply. The issue for tests not actually being part of the normal install process is https://trac.macports.org/ticket/42731 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: automatic port select after installing the first port in the group
Sounds kind of like the sensible alternatives approach that many dpkg-based package managers take: https://packages.debian.org/unstable/sensible-utils On Mon, Apr 7, 2014 at 8:02 AM, Mojca Miklavec mo...@macports.org wrote: Hi, for Python ports it makes sense not to install python to $prefix/bin because that would shadow the python which comes with the system. What about if we currently ship a certain port that installs the binary to $prefix/bin and would like to allow parallel installation of a newer (experimental) version. In order to prevent conflicts the binaries should no longer end up in $prefix/bin. But would it be possible/allowed to automatically run port select port_group_name port_version after the first of two ports gets installed? That way the users would still get the expected binary in $prefix/bin when they first install the port. Those who want to play with both versions would still be free to do so by running port select manually at any time. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: location of man pages for multiple versions of the same program
On Mon, Apr 7, 2014 at 10:44 AM, Brandon Allbery allber...@gmail.comwrote: On Mon, Apr 7, 2014 at 10:40 AM, Mojca Miklavec mo...@macports.orgwrote: It probably wouldn't be such a bad idea to create a script $prefix/bin/portname-initversion.sh which would prepend $prefix/libexec/port/something to PATH. Or maybe simply create a script like $prefix/libexec/port/something/usethisone.sh to do the same. And then man pages would automatically work ... I've wanted this for a while. That, or adding support for something along the lines of modules.sourceforge.net. (Unlike port select, this might be automatable.) There is a ticket open requesting a port for that btw: https://trac.macports.org/ticket/38598 I had been working on a Portfile for it a while ago, but gave up for some reason... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: curious dependency issues
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 on this list. Using port installed depof:gcr gcr is not listed, so that is more reasonable. depof:gtk3 does not list gconf, and depof:gconf does list gtk3. So it seems that depends: is buggy. Maybe it should be removed if it has been 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, and gconf and gtk3 appear to depend on each other. Does this make sense? Is it a bug in base or the Portfiles? I don't know if depends: is a bug but it is not documented in man port whereas depof: is: port installed depof:gcr Regards, Bradley Giesbrecht (pixilla) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Developer Meeting?
On Fri, Apr 4, 2014 at 4:47 PM, Daniel J. Luke dl...@geeklair.net wrote: On Apr 4, 2014, at 3:22 PM, Mojca Miklavec mo...@macports.org wrote: Having the meeting at two locations (one in Europe and one somewhere in USA) at the same time and organizing a short videoconference each day. But that only makes sense if there's sufficient interest and someone should organize the local event there. Let's first figure out if we have sufficient interest to organize the event at all. a /long/ time ago, I suggested a MacPorts meetup after a Macworld, and it ended up being only two people (drernie and me). I would hope that there would be more interest in something now. I was trying to figure out if there was any information about username-continent written somewhere, but couldn't find anything. (Maybe that or the default timezone like UTC+1/UTC-7/... could be useful optional information for http://trac.macports.org/wiki/MacPortsDevelopers for those who don't mind sharing that information.) I think fkr collected some info for the xglobe port - but I don't think it's been updated in forever (it's nomaintainer now...) I found it and attached it. You are right that it seems not to have been updated in forever, as it still uses @opendarwin.org email addresses instead of @macports.org ones. # This file is part of the XGLobe distribution and is taken from xearth # # Format: # latitude longitude Name [color=colorname] # positive latitude - north of equator # negative latitude - south of equator # positive longitude - east of 0ｰ meridian # negative longitude - west of 0ｰ meridian # # to be included in this file, send mail to: f...@opendarwin.org # # to just display these markers on the map: # xglobe -nomarkers -markerfile $PREFIX/share/xglobe/xglobe-markers.opendarwin 38.24 -121.26 drer...@opendarwin.org 37.19 -122.03 esei...@apple.com 37.87 -122.27 ri...@opendarwin.org 37.21 -122.05 s...@opendarwin.org 55.4012.35 ol...@opendarwin.org 51.24 0.21 chris.r...@isode.com 33.50 -118,21 tor...@mrcla.com 37.09 -122.08 j...@opendarwin.org 48.2802 7.4858 pk...@opendarwin.org 46.2248 7.3485 m...@opendarwin.org 49.5210.52 p...@opendarwin.org 38.49 -77.05 w...@opendarwin.org 50.0414.24 land...@opendarwin.org 40.36 -74.03 gwri...@opendarwin.org 33.47 -84.21 fea...@opendarwin.org 37.53 -122.16 ke...@opendarwin.org 45.520155 -122.688643 m...@opendarwin.org 45.53375-122.69855jbe...@opendarwin.org 33.27 -88.49 leim...@mac.com -27.50 152.96 ilis...@opendarwin.org -37.796355 144.981220 ye...@opendarwin.org 37.33 -122.03 wa...@opendarwin.org 34.49 134.34 po...@opendarwin.org 35.98 -78.94 d...@opendarwin.org 37.38 -122.26 fen...@opendarwin.org 48.560510 2.301050 m...@opendarwin.org 35.00 135.45 morim...@opendarwin.org 38.9 -104.75 b...@opendarwin.org 37.37 -122.03 t...@opendarwin.org 35.7194 139.6951 pgu...@opendarwin.org 42.6978230 -84.5150650 dl...@opendarwin.org 56.1610.21 dan...@opendarwin.org 10.496 -66.8982 j...@opendarwin.org 25.110433, 121.528026 dig...@opendarwin.org 48.43 -68.37y...@opendarwin.org 34.331318 135.350835 takan...@opendarwin.org 60.13 24.55 j...@opendarwin.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118533] trunk/dports/net/pidgin/Portfile
I thought we were doing variants now, when the dependency is for more than just the perl executable, at least: https://trac.macports.org/ticket/43193 On 4/4/14, Ryan Schmidt ryandes...@macports.org wrote: On Apr 4, 2014, at 00:03, dev...@macports.org wrote: Revision 118533 Author dev...@macports.org Date 2014-04-03 22:03:33 -0700 (Thu, 03 Apr 2014) Log Message pidgin: depend on perl5, increment revision to rebuild archived binary with latest default version (#42213), maintainer timeout. Modified Paths * trunk/dports/net/pidgin/Portfile Diff Modified: trunk/dports/net/pidgin/Portfile (118532 = 118533) @@ -38,7 +38,8 @@ port:libidn \ port:libxml2 \ port:nspr \ -port:nss +port:nss \ +port:perl5 You should use a specific version of perl instead, like perl5.16. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Developer Meeting?
I would be interested in going, although Europe is kind of far away from North America... What continent are most people from macports-dev located on? (Also, apparently 100 EUR is about $140 USD, and 30 EUR/day is about $40 USD/day... I had no idea that the two currencies had diverged that much recently...) On 4/4/14, Mojca Miklavec mo...@macports.org wrote: Hi, I'm curious how many people would be willing and able to join if we organized a 3-5 day long developer meeting somewhere in the heart of Europe (somewhere close to public transportation, but outside of city centers, somewhere in nature). Let's assume that we could reach a price of 100 EUR (let's say 30 EUR/day) with all costs included (that is: lodging, food, conference room rental, so you would only need to cover travel expenses in addition to that). This means: - finding a time slot when most people would be able to attend - making a reservation at some inexpensive holiday site - make sure they have good internet connection and a room with enough tables and chairs - collect reservations, prepare a (flexible) program - bring yourself and your mac to the site (- and maybe finding a sponsor to give us access to a high speed multi core mac during those few days to be able to compile things faster ;) The meeting would cover: - getting to know each other - some talks about amazing things you did, would like to do or would like to see done - brainstorming, round table with discussion about new ideas and future - hacking sessions, ticket closing marathon - enough free time to enjoy nature: walks or maybe some field trips around If we could get some 10-20 people to attend (and at least someone from portmgr), it could be an amazing experience. Any interest? (I'm thinking about 2015.) Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Developer Meeting?
Oops, I did not see this message before sending my previous one, which said pretty much the same thing... US/ET here as well, and both Washington/DC/US and Boston/MA/US would be easier for me, as I already have experience with both cities... although it would be cool to go to Europe sometime if I could manage it... On 4/4/14, Michael Dickens michae...@macports.org wrote: Ditto what Mark wrote. For me, this would generally be easier during the summer break (maybe even bring the whole family, depending on where it is). That said, I'm wondering where most MacPorts devs reside -- seems like there are at least a few out in US/CA. I'm in US/ET. There are certainly some in Europe ... Wondering if Washington/DC/US or Boston/MA/US might be more centrally located. I like the idea of a MP gathering. We do this for my other projects, along with presentations by GSoC students on their work and a day hackfest, so why not with MP too? - MLD On Fri, Apr 4, 2014, at 01:15 PM, Mark Anderson wrote: If I can get myself to Europe. Depends on where and when. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Noticing Perl stuff along the wire again
How about making a separate perl5-rewrite branch in subversion, working on the draft in that branch, and then merging that once it is ready? That would still technically meet jmr's ideally in a single commit criterion, as the only commit to trunk would be the merge from the other branch. On Fri, Apr 4, 2014 at 7:11 PM, Mark Anderson e...@emer.net wrote: I'm with you 100% there. Whatever we do it should be properly planned. Let me dig though and put together a draft. Mark --Mark ___ Mark E. Anderson e...@emer.net On Fri, Apr 4, 2014 at 7:08 PM, Joshua Root j...@macports.org wrote: On 2014-4-5 07:24 , Daniel J. Luke wrote: On Apr 4, 2014, at 1:20 PM, Mark Anderson e...@emer.net wrote: I know we've argued about this time and time again, but Perl issues are coming back up it seems. I've started work - admittedly not getting very far on the cpan-mp idea. I'm still trying to figure out /base to be honest and brush off my Perl-XS skills. do you have anything where someone can look at it? I'd be interested in helping make things better... I feel like we have had this argument again and again, and I'm loathe to start this argument again, but at what point are we going to pull the trigger on keeping one perl, deciding to drop old Perls, that kind of thing. I can put together a proposal and drop it on the wiki - if that will make things easier to decide/pick apart. A wiki page might be a good idea - it seems like there are a few people who are strongly opposed to that general plan (keeping just one good perl), and that there's been enough inertia to keep things from changing. I don't really care what we do with perl as long as it works. I've done way more work on the perl ports than I ever wanted to, simply because they were broken and stopping other stuff from working. There were some changes to perl begun in late 2008 that apparently weren't completely planned out and never really got finished. A lot of the subsequent work was attempting to fix that mess. So let's not have a repeat of that. Whatever we do, let's figure out where we're going before we start making changes, think through the impact on users and how to minimise it, and make the changes all at once when they're ready (ideally in a single commit). - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On 4/3/14, Clemens Lang c...@macports.org wrote: However, I've noticed during my last use of port_cutleaves from contrib [1] that I see failures to open Portfiles from registry a lot more often than I used to. I tried investigating a little, but haven't been able to pinpoint a reason for that. It might just be my installation (because I had to manually intervene with the database upgrade), but I guess making sure and giving it another look wouldn't hurt. Can anybody reproduce this? It might not be a critical problem though, because it'd only break pre-/post-deactivate hooks, and we don't have a lot of those anyway. I count 13 Portfiles with pre-deactivate hooks and 33 Portfiles with post-deactivate hooks. Of course that is not counting the PortGroups that use them: all 3 Haskell PortGroups use pre-deactivate hooks, and there are a few hundred Portfiles using the main Haskell PortGroup. Also, the Octave, TeXLive, and x11font PortGroups each use post-deactivate hooks, and there are a few hundred more Portfiles using at least one of those PortGroups, between the three of them... idk if a few hundred is enough to be considered a lot, considering that we have over 18000 ports overall currently, but I think it is still enough to consider giving it a look... [1] http://trac.macports.org/browser/contrib/port_cutleaves/ -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compiler variants in portfile
You might want to cc sean on this, as he was the one who wrote the compilers-1.0.tcl PortGroup... On 3/27/14, Sébastien Maret sebastien.ma...@icloud.com wrote: Hi all, I'm writing a portfile for a software written in C/C++ and Fortran77/90: http://trac.macports.org/ticket/42886 Following a comment macsforever2000, I've modified my original port to provide several fortran compiler variants. However, my port requires that CC, CXX, CPP, and FC/F77 are all from a gcc variant. For example, it's not possible to compile it using CC=clang and FC=gfortran-mp-4.8. How can I modify it so that all compilers come from the same compiler suite? Thanks in advance for your advices. Sébastien ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that's something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas - feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the haspatch keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread...) MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don't remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Besides all the things mentioned in this thread so far, I would like to note that there are some options to have it both ways and have a bigger presence on GitHub, even if we still keep our Trac infrastructure as well. For one, there is the mirrors account that has a bunch of read-only mirrors set up for other popular open-source projects that are hosted elsewhere: https://github.com/mirrors We could try to get that account to put up a mirror of the MacPorts read-only git mirror as well, or just put up a read-only mirror similarly ourselves. Second, GitHub has a Trac service hook that can be enabled under a repo's settings under Webhooks Services, although the notes there say that that hook is deprecated in favor of the trac-github plugin: https://github.com/aaugustin/trac-github We could try using that plugin to be able to still do everything in Trac and yet also have a presence on GitHub at the same time. Third, even if we do not want to move the MacPorts infrastructure itself to GitHub, we could at least make a MacPorts Organization on GitHub that MacPorts developers could be added to if they wanted: https://github.com/organizations/new Having a GitHub organization could at least show the GitHub community that we do at least have a human presence there, even if we do not necessarily also have a code presence there as well. Anyways, I bring up these ways to have it both ways because while I do use GitHub a lot, it is becoming harder and harder to do so, as they dropped support for the Snow Leopard version of the GitHub desktop a while ago, and more recently they made some change to the website that broke it in the Snow Leopard version of Safari, so now whenever I am using Safari, I have to remember to open all links to GitHub in Firefox or Chrome instead, which is annoying. While I can still use it, it is part of a trend of dropping compatibility that has me worried that if we move entirely to GitHub, users on older OSes might eventually get left behind, without Trac still being there as a backup. Hence why I prefer having both instead of just one. On 3/16/14, Joshua Root j...@macports.org wrote: On 2014-3-17 05:42 , Sean Farley wrote: If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I would certainly agree with that. However I would also agree with what Landon said here: https://lists.macosforge.org/pipermail/macports-dev/2013-September/024252.html Rainer also did a great job of explaining why moving to github is a bad idea earlier in the thread. Much the same applies to bitbucket. I should note that I've used both git and hg for real work, and a modern DVCS certainly has its advantages. But that said, I really haven't felt like I was being restricted by svn while working on MacPorts. In fact, sometimes being able to check out a single file or directory deep in the tree comes in handy. If the majority of contributors really find that they are being held back by svn, I guess I would support moving our repos to hg. We could at least add an official hg mirror. But the OP said that the thread was about github and the convenience of pull requests, not git as such. If the problem is that people find it's too much trouble to svn diff and attach the output to a ticket, maybe client side automation is the solution. We have a script to apply a patch straight from a Trac URL, so why not one to create a ticket and attach a patch. It would be more complicated certainly, but if saving that handful of clicks gets more people involved, I guess it's worth it. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Scheduled downtime on Mar 11, 15-19 UTC
Also trac appears to be failing to display recent commits again... On Wed, Mar 12, 2014 at 12:34 PM, Peter Danecek peter.dane...@bo.ingv.itwrote: This one still persists ... ~petr On 12 Mar 2014, at 16:57, Peter Danecek peter.dane...@bo.ingv.it wrote: Hi all, I just realised that there seem to be some issues with the website as well. - https://www.macports.org/ports.php (Available Ports) does not give results; - The homepage does not reply (.../index.php); ~petr ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
flags for base's configure script: should there be more or fewer? (was Fwd: [MacPorts] #42756: macports doesn't compile with bundled tcl)
Bringing this discussion to macports-dev as suggested. Anyways, r117621https://trac.macports.org/changeset/117621 removed a bunch of flags from the configure script in base, many of which I found useful. Personally, I generally prefer giving users more configure options rather than fewer, as I respect users' freedom to build their software the way that they want to, and would prefer that exercising that freedom remains as easy as possible (here, in the form of providing configure flags, but the concept can also be extended to things like adding more variants to Portfiles). Anyways, that is my personal preference at least, which way are other people on this list leaning? larryv at least has already come out as deletionist, but what about the rest of you? -- Forwarded message -- From: MacPorts nore...@macports.org Date: Fri, Mar 7, 2014 at 2:50 PM Subject: Re: [MacPorts] #42756: macports doesn't compile with bundled tcl To: xeron.os...@gmail.com, macports-tick...@lists.macosforge.org Cc: rai...@macports.org, eg...@gwmail.gwu.edu #42756: macports doesn't compile with bundled tcl + Reporter: xeron.oskom@... | Owner: macports-tickets@... Type: defect | Status: new Priority: Normal | Milestone: Component: base |Version: 2.2.99 Resolution: | Keywords: Port: | + Comment (by larryv@...): Replying to [comment:8 egall@...]: Replying to [comment:6 cal@...]: That increases the possibility for misconfigurations (such as choosing Tcl 8.6), If a user is building from source themselves, they should be aware of that. Also I fail to see why choosing Tcl 8.6 is considered a misconfiguration. It's a misconfiguration because we don't support it. I just checked out trunk and the sqlite3 one still exists, too. Also while the `--with-included-tclthread` flag may be gone now, I would argue that should be brought back as well This isn't the place for this conversation (take it to macports-dev if you wish), but I strongly oppose adding more configuration flags than the ones we already have. I wouldn't be opposed to removing even more of them. -- Ticket URL: https://trac.macports.org/ticket/42756#comment:10 MacPorts http://www.macports.org/ Ports system for OS X ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
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 Fri, Mar 7, 2014 at 4:09 PM, Joshua Root j...@macports.org wrote: On 2014-3-8 07:13 , Eric Gallager wrote: Bringing this discussion to macports-dev as suggested. Anyways, r117621 https://trac.macports.org/changeset/117621 removed a bunch of flags from the configure script in base, many of which I found useful. Personally, I generally prefer giving users more configure options rather than fewer, as I respect users' freedom to build their software the way that they want to, and would prefer that exercising that freedom remains as easy as possible (here, in the form of providing configure flags, but the concept can also be extended to things like adding more variants to Portfiles). Anyways, that is my personal preference at least, which way are other people on this list leaning? Batteries included is generally preferable to more variants. I would tend to agree that the problem in the ticket is user error, but OTOH it's easy to have CFLAGS lying around in your environment and forget to unset them. Maybe we should at least delete flags containing $PREFIX from CFLAGS and LDFLAGS like we do PATH. Looks like the flags removed by r117621 were: --with-tcl --with-tclinclude --with-tclpackage --with-tcl-sqlite3= --with-included-tclthread As Tcl is now part of base, my view would be that providing flags to use a different one would make about as much sense as providing --with-pextlib= or --with-cregistry=. Many other software packages include other software packages as part of their base, and the general trend is to only use the included one as a fallback in case one is not already installed. For example I was working with the sources of gnutls earlier today and they only fall back to using their included libtasn1 when the configure script fails to find one installed, and using the included one produces a warning. This is because 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 vendors it in as a convenience and does not actually maintain it itself, which is why the tarball remains untarred until it is needed. Meanwhile the pextlib and cregistry libraries are not found anywhere else externally, because they are only used in MacPorts internally so far. It makes no sense to include flags for them because there is nowhere else that they could point, whereas on the other hand with Tcl, there are many other places that the flag for them could point. So I would argue that because of this, it actually makes *much* more sense to include a --with-tcl= flag than either a --with-pextlib= flag or a --with-cregistry= flag. larryv at least has already come out as deletionist, but what about the rest of you? Name calling really doesn't help your case. - Josh The label deletionist isn't name-calling, it's an accurate term for a philosophical position that people can have towards content in community-based software projects: https://en.wikipedia.org/wiki/Deletionism_and_inclusionism_in_Wikipedia Many people apply the label to themselves voluntarily. Sorry for any offense caused by my using it, I just assumed that people were familiar with the term... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Disk Space - Snow Leopard MacPorts buildbot
Could the buildbot running out of disk space account for the corrupted clang-3.3 binary archive that I reported in #42668https://trac.macports.org/ticket/42668? Maybe it ran out of disk space when creating the archive, and the resulting error led to the archive being truncated due to never having been finished? On Sun, Mar 2, 2014 at 2:02 PM, Jeremy Huddleston Sequoia jerem...@apple.com wrote: It looks like we're low on disk space on the SL buildbot: https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/25067/steps/compile/logs/stdio DEBUG: Attempting ln -sf /opt/local/var/macports/build/_opt_mports_dports_devel_cppunit/cppunit/work /opt/mports/dports/devel/cppunit/work DEBUG: changing euid/egid - current euid: 0 - current egid: 0 DEBUG: egid changed to: 20 DEBUG: euid changed to: 506 Error: Failed to install cppunit DEBUG: couldn't open /opt/local/var/macports/build/_opt_mports_dports_devel_cppunit/cppunit/work/.macports.cppunit.state: no space left on device while executing --Jeremy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: commit rights ...
That can get bypassed for GSOC students though, right? At least that was how I remember mariusc got his commit rights, and he was the most recent committer added that I can think of... Anyways, with all these GSOC students that look like they are applying this year, perhaps when they get their commit rights, that could be used as an opportunity for the project managers to add some other people who have been waiting in line outside of the whole GSOC process as well? On Fri, Feb 21, 2014 at 10:05 PM, Lawrence Velázquez lar...@macports.org wrote: On Feb 21, 2014, at 11:53 AM, Peter Danecek peter.dane...@bo.ingv.it 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 macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: commit rights ...
I agree that normatively, now would be better than later, I was just speculating descriptively about what it might take to get some new approvals... On Fri, Feb 28, 2014 at 3:42 PM, Clemens Lang c...@macports.org wrote: Hi, That can get bypassed for GSOC students though, right? At least that was how I remember mariusc got his commit rights, and he was the most recent committer added that I can think of... The actual confirmation email still came from one of portmgr@, I think it was Rainer. So, no, this doesn't get bypassed for GSoC students either, but they're not subject to the process as the rest of us (or rather, you) are. Anyways, with all these GSOC students that look like they are applying this year, perhaps when they get their commit rights, that could be used as an opportunity for the project managers to add some other people who have been waiting in line outside of the whole GSOC process as well? IMO, now is as good a time as any. Why delay it if it's finished earlier? Of course portmgr@ are all volunteers, too. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: commit rights ...
+2 for Clemens being part of portmgr. Objectively, he would be a good choice due to his activity level and amount of contributions to the project. Biasedly, I would want him to be part of it because he was the one who encouraged me to apply for commit rights in the first place... On 2/28/14, Bradley Giesbrecht pixi...@macports.org wrote: +1 Good choice. Regards, Bradley Giesbrecht (pixilla) On Feb 28, 2014, at 12:56 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: portmgr@ could grow to include another volunteer though :-P Maybe it should include someone as influential as Clemens. On Feb 28, 2014, at 15:42, Clemens Lang c...@macports.org wrote: IMO, now is as good a time as any. Why delay it if it's finished earlier? Of course portmgr@ are all volunteers, too. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Trac down?
Trac looks down to me from here, too: http://downforeveryoneorjustme.com/trac.macports.org agrees as well... On Wed, Feb 12, 2014 at 7:22 AM, Peter Danecek peter.dane...@bo.ingv.itwrote: Update: I just got the confirmation mail back for the ticket I was submitting. So something still works, but is terribly slow. ~petr Hi all, Trac seems to have done down recently. I was compiling a ticket, which I could not submit. Now trac.macports.org does not reply (confirmed by downforeveryoneorjustme). Could some have a look at it? Thanks! ~petr ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Restarting Perl Arguments. :-P
Do you have a link to your fork on Github? I would like to star it. On Sun, Feb 9, 2014 at 2:52 PM, Mark Anderson e...@emer.net wrote: So I've started messing around with getting a Proof of Concept CPAN-MP link working, so we don't need to have to have 8 billion perl ports. This was an idea on a thread long ago. I'll be keeping a github branch in my fork as soon as I get something that resembles something that isn't how in the hell does this work jibberish. Anyone who's interested, give me a holler, and I'll keep you in the loop. --Mark ___ Mark E. Anderson e...@emer.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Call for Testers: MacPorts Statistics
Is there an easy way to convert a non-trunk installation of MacPorts into a trunk installation of it? The relevant guide sectionhttp://guide.macports.org/#installing.macports.subversion says: If you installed MacPorts using the package installer, skip this section. I don't exactly have room for multiple installations of MacPorts on my current drive... I also found two different HowTo guides on the Wiki, but I am not sure which one would be better to follow: https://trac.macports.org/wiki/howto/SyncingWithSVN and https://trac.macports.org/wiki/howto/RunningTrunk On Sat, Feb 8, 2014 at 2:46 PM, Joshua Root j...@macports.org wrote: On 2014-2-9 03:39 , Clemens Lang wrote: Note that the port uses `startupitem.autostart` in a way that only works with the most recent trunk [2]. If your MacPorts installation isn't compatible, the auto-loading will fail and you'll have to run `port load mpstats` manually. Trunk is actually a hard requirement since it also needs the curl post command. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Call for Testers: MacPorts Statistics
Really? That sounds dangerous, but if you say it works fine, I guess I can give it a try... On Sat, Feb 8, 2014 at 4:49 PM, Clemens Lang c...@macports.org wrote: Just install right over it, that works fine. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
How to get around MacPorts assuming that Exit code: 1 is a failure?
I am working on a Portfile from which I want to call the `unifdef` command. The manpage for `unifdef` says: Exit status is 0 if output is exact copy of input, 1 if not, 2 if trouble. The whole reason I am running `unifdef` is to change the output, so I *want* it to return 1. However, when I put this in my Portfile, it interprets this as a failure. Is there any way that I can get around this? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: How to get around MacPorts assuming that Exit code: 1 is a failure?
I had to escape the brackets, but after that, it worked. Thanks! On Sat, Feb 8, 2014 at 9:23 PM, Joshua Root j...@macports.org wrote: On 2014-2-9 12:22 , Eric Gallager wrote: I am working on a Portfile from which I want to call the `unifdef` command. The manpage for `unifdef` says: Exit status is 0 if output is exact copy of input, 1 if not, 2 if trouble. The whole reason I am running `unifdef` is to change the output, so I /want/ it to return 1. However, when I put this in my Portfile, it interprets this as a failure. Is there any way that I can get around this? unifdef || [ $? -ne 2 ] ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Bison 3
You might want to add yourself on CC on http://trac.macports.org/ticket/39910 as I added some patches that allow all 3 versions of bison to be installed in parallel to that ticket On Mon, Feb 3, 2014 at 11:37 AM, Akim Demaille akim.demai...@gmail.comwrote: Le 26 janv. 2014 à 16:24, Akim Demaille akim.demai...@gmail.com a écrit : What is holding the inclusion of Bison 3 in the ports? http://trac.macports.org/ticket/41600 was opened two months ago. Helloo! Anybody out there? How can I help? ___ macports-users mailing list macports-us...@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [116291] trunk/dports/_resources/port1.0/group/debug-1.0.tcl
Just so it can remove it with the `+debug` variant that it adds, it looks like... On Thu, Jan 23, 2014 at 10:32 PM, Joshua Root j...@macports.org wrote: On 2014-1-24 09:50 , Sean Farley wrote: lar...@macports.org writes: (a) There's already a configure.mtune option. You should use that (configure.mtune native) instead of appending to all the flags options. Oh, awesome, thanks for the tip. (b) Don't you have to disable binary archives if you set -mtune=native? Probably so. Luckily, there are no ports using this port group so this kind of feedback is appreciated. (c) Why is a portgroup called debug adding -mtune=native anyway? - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [116220] trunk/dports/python
The one thing I'd caution against is removing any py24* ports that have no newer versions. I cannot think of any off the top of my head, but I guess that would just be something to check for while removing the py24* ports, i.e., making sure that they have a version available for a newer python before removing it. On Wed, Jan 22, 2014 at 12:25 PM, Frank Schima macsforever2...@macports.org wrote: I agree. I think all py24-* ports should be removed now. Removing py24-* ports will change the default python to 2.7 for people who (mistakenly) install py-foo. I would not object to everything less than py27-* leaving too but maybe later. Cheers! Frank On Jan 22, 2014, at 9:11 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Those packages were blocking the removal of python24 subports that I maintain (e.g py-elementtree). 100% agree with removing at least the python24 modules like Sean said. Also, people are quite capable of pulling python24’s modules out of our repository after removal if they need them. While Sean has a use for python24 itself, it has security problems and is not supported. I feel it also should get removed and used in a local repository if possible, but I’m perfectly content with doing just modules for now. Realistically, most modules below python27 should get axed. On Jan 22, 2014, at 10:53, Sean Farley s...@macports.org wrote: j...@macports.org writes: Instead of deleting a few random py24 subports, why don't you ask the python24 maintainer and the -users list if anyone still needs python 2.4? (They said yes last time we asked.) And if they don't, make a ticket for deleting python24 and either deleting or updating to a newer python for all its dependents. I would like to not get rid of python24 anytime soon because it allows me to test compatibility. I am not opposed, however, to removing all the py24-* ports (maybe all but virtualenv and friends?). ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compilers and MPI Port Groups
Go for it! I want to see how it turns out. On Sun, Jan 19, 2014 at 6:41 PM, Sean Farley s...@macports.org wrote: s...@macports.org writes: s...@macports.org writes: s...@macports.org writes: Hello all and Happy Boxing Day! I have done a complete rewrite of the compilers and mpi port groups based on suggestions from previous emails. I will try to keep this email short and provide links for those that want to know more. Highlights: - specify which compilers to set via compilers.choose, e.g. 'compilers.choose f77 f90 fc' - functions for testing if fortran has been selected for optional interfaces - portfile author can specify if fortran (or mpi) is required - unified and have made non-conflicting openmpi and mpich ports; also added an openmpi-devel port [1] - can now select either mpi port as the default mpi installation Example of a portfile using the new compilers portgroup: https://smf.io/macports/changeset/compilers Example of a portfile that uses the mpi portgroup: https://smf.io/macports/files/mpi/dports/science/hdf5-18/Portfile The changes I made to the sparskit and hdf5-18 portfiles are just examples I did for illustrative purposes. I won't push them unless the portfile author wants it. The mpich and openmpi portfiles need these changes so that the mpi portgroup will work. Anyway, I'd like to push this soon so that I can continue other work (and close a lot of tickets), so it'd be great if others could take a look at the proposed changes. [1] https://smf.io/macports/changeset/81bb51 or look at the changelog https://smf.io/macports/changelog to see all the diffs Just an update to say that I've gone ahead and finished updating all the ports that use mpi to use this new port group. The only work that needs to be done is to get some review of this patch series and after that, permission to push. I've cc'd the people who are the maintainers of the ports I changed, listed below. It'd be great to have you guys look at the changes. dstrubbe: sparskit, hpl, octopus eborisch: mpich mww: openmpi raimue: valgrind, valgrind-devel takeshi: berkeley_upc, omnixmp, gnudatalanguage, netcdf, netcdf-cxx, netcdf-cxx4, netcdf-fortran mmoll: optpp, hdf5-18, arpack hum: plda howarth: apbs-mpi mattoates: raxml mk: scotch michaelld: SuiteSparse Check out http://smf.io/macports for the updated changes. Having other people look at this would be great and hopefully would catch some of the errors I missed. The common ones I noticed were missing revbumps (though, I think I got all of those now). Documentation is very much read the comments and the code itself or look at an example so, apologies about that. Also, sometimes I couldn't think of a good name for a proc, so if anyone has a better name, please speak up. Some changes since last email are: - ensure the same mpi is used via mpi.enforce_variant - ensure the same c compiler is used (even when using mpi) via compilers.enforce_c - similar for fortran, compilers.enforce_fortran - test for avx compatible compiler via avx_variant_isset Still yet to be done is to replace all custom recipes done for the compiler variants. By my count, there are no more than 72 of those ports. This is lower priority since they'll still work as is. If nobody has any objections to this, I was hoping to push this in a few days. Any objections before I push? I guess at this point the errors that are left are of the type that one finds after trying to get the buildbot to compile a port. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Any objections to removal of the carbon variant in py-wxpython-2.8?
It just feels more Mac-native. Also it has a shorter dependency chain in that it does not drag in gtk, nor does it require that gtk be installed with the `+x11` variant. On Thu, Jan 16, 2014 at 9:14 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Jan 15, 2014, at 19:57, Eric Gallager wrote: On Wed, Jan 15, 2014 at 6:13 PM, Ryan Schmidt wrote: On Jan 15, 2014, at 10:27, Eric Gallager wrote: I am still on 10.6 and still use the `+carbon` variant for py-wxpython-2.8… Yes but would it be a problem for you to use the +gtk variant instead? If so please explain. No, just that I prefer it and currently use it... I could probably do without it though. Why do you prefer it? In what way is the carbon variant different from the gtk variant? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Any objections to removal of the carbon variant in py-wxpython-2.8?
I am still on 10.6 and still use the `+carbon` variant for
py-wxpython-2.8...
On Wed, Jan 15, 2014 at 11:11 AM, Mojca Miklavec mo...@macports.org wrote:
Hi,
The port py-wxpython-2.8 currently supports two conflicting variants:
+carbon (32-bit Carbon-based wxWidgets)
+gtk (GTK-based wxWidgets)
On 10.6 the variant +carbon is the default one, while on 10.7 and
later only +gtk can be used anyway.
I would like to remove the variant +carbon because it complicates
matters more than necessary and removing it only affects outdated
software on outdated OS in the way that users would be forced to use
X11 instead of 32-bit Carbon, but the ports would still work.
The kind of complications I'm talking about is that a port like
py-robotframework-ride would need to explicitly support three
different variants (wxwidgets30, wxwidgets28, wxgtk28), set
supported_archs i386 ppc with wxwidgets28, refuse to compile with
Xcode 4.4 and later, make sure that the right variant is active
(require_active_variants port:py${python.version}-wxpython-2.8 carbon gtk)
and be executed with 'arch -i386 binary_name'. Without all that the
building on the buildbot fails.
List of ports that depend on wxPython 2.8:
- gis/grass (broken at the moment anyway)
- python/py-robotframework-ride
- python/py26-pyphant (kind-of-broken, compatibility with 3.0 almost
finished)
- python/py-pyface (also supports Qt which is superior)
- editors/spe (somewhat outdated)
- python/py-dsv (somewhat outdated)
If anyone has a strong argument against the removal of Carbon support
in wxPython 2.8, please speak now.
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Fwd: Any objections to removal of the carbon variant in py-wxpython-2.8?
On Wed, Jan 15, 2014 at 6:13 PM, Ryan Schmidt ryandes...@macports.org
wrote:
On Jan 15, 2014, at 10:27, Eric Gallager wrote:
I am still on 10.6 and still use the `+carbon` variant for
py-wxpython-2.8…
Yes but would it be a problem for you to use the +gtk variant instead? If
so please explain.
Oops, forgot to make sure that my previous response to this made it back to
the lists:
-- Forwarded message --
From: Eric Gallager eg...@gwmail.gwu.edu
Date: Wed, Jan 15, 2014 at 11:51 AM
Subject: Re: Any objections to removal of the carbon variant in
py-wxpython-2.8?
To: Jeremy Lavergne jer...@lavergne.gotdns.org
Cc: Mojca Miklavec mo...@macports.org
No, just that I prefer it and currently use it... I could probably do
without it though.
On Wed, Jan 15, 2014 at 11:31 AM, Jeremy Lavergne
jer...@lavergne.gotdns.org wrote:
Eric: do you mean you need +carbon?
Mojca: Is it possible to simply restrict all these things to a 10.6-only
block in the Portfile?
On Jan 15, 2014, at 11:27, Eric Gallager eg...@gwmail.gwu.edu wrote:
The kind of complications I'm talking about is that a port like
py-robotframework-ride would need to explicitly support three
different variants (wxwidgets30, wxwidgets28, wxgtk28), set
supported_archs i386 ppc with wxwidgets28, refuse to compile with
Xcode 4.4 and later, make sure that the right variant is active
(require_active_variants port:py${python.version}-wxpython-2.8 carbon
gtk)
and be executed with 'arch -i386 binary_name'. Without all that the
building on the buildbot fails.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [115354] trunk/dports/devel/gettext
Is the giant patch still necessary after the update to gettext in r115755https://trac.macports.org/changeset/115755 ? On Tue, Dec 31, 2013 at 5:22 PM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: On Dec 31, 2013, at 14:01, David Evans dev...@macports.org wrote: On 12/31/13 1:22 PM, jerem...@macports.org wrote: Revision 115354 Author jerem...@macports.org Date 2013-12-31 13:22:54 -0800 (Tue, 31 Dec 2013) Log Message gettext: Actually add the patch... Added Paths • trunk/dports/devel/gettext/files/ • trunk/dports/devel/gettext/files/autoreconf.patch Diff Jeremy -- Suggest you revert this change to gettext as the build fails due to lack of autoheader provided by autoconf. Seems your patch is making it reconfigure on its own. See comments in Portfile about the resulting circular dependency. Yeah, this patch is the alternative to having the circular dependency. Since we can't run autoreconf, I figured generating a patch would be fine... Looking into it... --Jeremy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [115354] trunk/dports/devel/gettext
oops sorry I missed that one... thanks for pointing it out to me. On Fri, Jan 10, 2014 at 5:46 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Jan 10, 2014, at 16:22, Eric Gallager wrote: Is the giant patch still necessary after the update to gettext in r115755? The giant patch was already removed in r115361. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Obsolete Ports for firefox-x11 and thunderbird-x11
I had been working on getting their ports updated at one point, but it's a lot of work and I don't think I ever finished the job... On Thu, Jan 9, 2014 at 7:33 AM, Johannes Kastl m...@ojkastl.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I just stumbled upon the ports for firefox and thunderbird, and thought this would be an easy way to ensure I always have a recent version on each machine, where port upgrade outdated is run periodically. But they are, how to put this delicately, stinking old? Or am I missing something here? $ port info thunderbird-x11 firefox-x11 thunderbird-x11 @2.0.0.22 (mail, x11) Variants: debug, universal Description: Thunderbird makes emailing safer, faster and easier than ever before with the industry's best implementations of features such as intelligent spam filters, a built-in spell checker, extension support, and much more. Homepage: http://www.mozilla.com/thunderbird/ Build Dependencies: pkgconfig Library Dependencies: libidl, glib2, zip, gtk2, gnome-vfs, gnome-icon-theme, cairo, nspr Platforms:darwin License: MPL Maintainers: nomaintai...@macports.org -- firefox-x11 @7.0.1_3 (www, x11) Variants: debug, gnome, official_branding Description: Firefox empowers you to browse faster, more safely and more efficiently than with any other browser. Homepage: http://www.mozilla.com/firefox/ Build Dependencies: findutils, pkgconfig, autoconf213, yasm, apple-gcc42 Library Dependencies: heimdal, gconf, esound, libcanberra, findutils, gtk2, mesa, xorg-libXt Platforms: darwin License: unknown Maintainers: nomaintai...@macports.org Shouldn't we delete them, so no user will actually use these old farts? TB 2.0 is from 2007, FF 7 is from 2001. If these are the actual versions, I do not want to know how many critical bugs have been fixed since... Of course it would be nice if someone would step up and maintain them. I'm lacking both time and experience. Regards, Johannes - -- What is comedy? Comedy is the art of making people laugh without making them puke. (Steve Martin) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlLOlwQACgkQzi3gQ/xETbJ68wCZAeZtX7RmFWNHkgUKBfRvKsEw nvkAoJc8S2peE5VarQoFJtRZuiZns218 =xnHr -END PGP SIGNATURE- ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Looking for a few good maintainers
I'd be willing to help, but unfortunately I think that the a few spare cycles requirement is going to disqualify me, as my main hard drive recently died and I'm still in the process of transferring to a new one... On Mon, Jan 6, 2014 at 5:47 PM, David Evans dev...@macports.org wrote: The current gnome-utils and gnome-games ports are unmaintained and outdated. In current GNOME3 distributions, they have been replaced by individual packages, none of which have been ported to MacPorts as yet. If anyone has a few spare cycles to port and maintain any of these ports, please take a look at the referenced tickets for details. Thanks for your help. [1] https://trac.macports.org/ticket/42035 (gnome-utils) [2] https://trac.macports.org/ticket/42037 (gnome-games) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ 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?
Is there a trac plugin or setting that we could use to have our trac automatically close tickets like that, too? On Sun, Dec 22, 2013 at 12:13 PM, Eric A. Borisch ebori...@macports.orgwrote: I failed to manually close the ticket. (I'm used to a Trac that scans commit messages for closes #x) 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.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Any wxMSW users out there?
I think I tried installing it once but was never able to do so successfully: Local-Admins-MacBook-Pro:~ root# port installed wxmsw None of the specified ports are installed. I forget what the exact build failure was... Anyway I would like to keep it around and get it to work because there was some project that uses wxWidgets successfully on Windows that I was trying to port to OS X, so it might be helpful to use in the porting process... On Thu, Dec 12, 2013 at 9:23 AM, Mojca Miklavec mo...@macports.org wrote: Hi, a while back I did a clean-up of wxWidgets ports, including wxGTK, but I didn't touch wxMSW. The question is: does anyone really need wxMSW or may we delete it? The port is outdated (the version 2.8.4 is from May 2007, it hasn't even been upgraded to version 2.8.5 from September 2007) and fails already during configure (it is possible that the problem is at least somewhat related to MinGW, but I don't really know). And yet there is no single bug report requesting an upgrade or a fix to allow building the port. My assumption is that nobody has been using this port for a long time. I would suggest to delete it unless there are any objections or needs to keep it around. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ 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?
Emailing the mailing lists like this sometimes works. I just added myself on cc. On Tue, Dec 10, 2013 at 5:17 AM, Akim Demaille akim.demai...@gmail.comwrote: For instance https://trac.macports.org/ticket/34225 Cheers! ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: C++11 on Mountain Lion and lower?
What about using the libcxx and libcxxabi ports for libc++? Is there any way to make that work? On Tue, Dec 3, 2013 at 1:38 PM, Clemens Lang c...@macports.org wrote: On Tue, Dec 03, 2013 at 05:00:25PM +, Christopher Jones wrote: Is this really a good idea though. My recollection is, whilst not as bad as mixing libc++ and libstdc++ runtimes, mixing the two different libstd++ runtimes can still lead to problems…. ? Under the constraints we have I think its the best solution possible. Alternatives would be - Mark the port as broken on systems darwin13 :( - Build a private copy of all dependencies of rethinkdb against macports libstdc++. Since that includes boost and a couple of other rather large ports, I don't think this is a feasible solution either. - Get Apple to ship a version of libstdc++ that supports C++11 on outdated OS releases - Get Apple to make libc++ the default stdlib on all releases that have libc++ None of those sound very appealing to me. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Suggestion for a progress counter for port install/upgrade
This is http://trac.macports.org/ticket/5001 On Fri, Nov 15, 2013 at 8:49 PM, mk-macpo...@techno.ms wrote: Hi MacPorts core devs, just now I once again missed a feature I wish was there in MP. If I install a lot of ports (when I am setting up a machine from scratch, like now) or upgrade an installation which hadn’t been upgraded for a longer time I am overwhelmed by the amount of lines flooding my console… I would be happy a few additional lines informing me about the progress e.g. like this — — Installing 193 ports — (1/193) === Port skrooge === --- Fetching skrooge --- Verifying checksum(s) for skrooge --- Extracting skrooge --- Configuring skrooge --- Building Scrooge --- Staging skrooge into destroot --- Deactivating skrooge-devel @0.8.0-1215845_0 --- Cleaning skrooge-devel --- Computing dependencies for skrooge --- Installing skrooge @0.8.0.6_0 --- Activating skrooge @0.8.0.6_0 --- Cleaning scrooge — (2/193) === Port blablah === --- Fetching blablah . . . — where of course to be installed dependencies would also count. Objections? Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
Hoping this gets fixed sometime soon, because for some reason it's been screwing with my `camlimages` build... On Tue, Nov 12, 2013 at 7:20 AM, Titus von Boxberg ti...@v9g.de wrote: Am 11.11.2013 20:08, schrieb Mojca Miklavec: On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote: Without having a system here to test my suggestions, you might be able to - configure tiff to not define this type name (or define it correctly in the sense of portability and compatibility, at least). I cannot configure it to not define the type name uint64. This type name is used all over the place. The solution might be to define it to uint64_t instead of unsigned long. Yes, that seems reasonable as long as uint64_t is guaranteed to be defined before the typedef of uint64 happens. Maybe you could patch tiffconfig.h.in or something else in tiff's configuration phase. Regards Titus ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: GNOME 3
Yeah, I agree, it's nice to have the GNOME 3 versions of GNOME software available via MacPorts... I just wish we could have kept the GNOME 2 versions of some of them around at the same time... On Wed, Nov 13, 2013 at 6:46 AM, Ryan Schmidt ryandes...@macports.orgwrote: Dave, thanks for all your work getting GNOME 3 into MacPorts! ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Unable to log in to Trac
I wasn't even trying to log in, I was just refreshing the page, and got a
similar error:
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 441,
in send_error
data, 'text/html')
File /usr/lib/python2.6/site-packages/trac/web/chrome.py, line
828, in render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216,
in __getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 309,
in _get_session
return Session(self.env, req)
File /usr/lib/python2.6/site-packages/trac/web/session.py, line
201, in __init__
if req.authname == 'anonymous':
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216,
in __getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 168,
in authenticate
authname = authenticator.authenticate(req)
File
/usr/lib/python2.6/site-packages/IgneousAuthenticationModule-2.0-py2.6.egg/igneousauth/auth.py,
line 34, in authenticate
s = Session.objects.get(pk=fid)
File /usr/lib/python2.6/site-packages/django/db/models/manager.py,
line 132, in get
return self.get_query_set().get(*args, **kwargs)
File /usr/lib/python2.6/site-packages/django/db/models/query.py,
line 344, in get
num = len(clone)
File /usr/lib/python2.6/site-packages/django/db/models/query.py,
line 82, in __len__
self._result_cache = list(self.iterator())
File /usr/lib/python2.6/site-packages/django/db/models/query.py,
line 273, in iterator
for row in compiler.results_iter():
File /usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py,
line 680, in results_iter
for rows in self.execute_sql(MULTI):
File /usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py,
line 734, in execute_sql
cursor = self.connection.cursor()
File /usr/lib/python2.6/site-packages/django/db/backends/__init__.py,
line 252, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
File
/usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py,
line 140, in _cursor
self.connection = Database.connect(**conn_params)
OperationalError: could not connect to server: Connection timed out
Is the server running on host data.macosforge.org and accepting
TCP/IP connections on port ?
On Mon, Nov 11, 2013 at 2:22 PM, Leo Singer aron...@macports.org wrote:
Hi,
I am unable to log in to Trac right now. Upon logging in, I get the
following Python traceback:
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 441, in
send_error
data, 'text/html')
File /usr/lib/python2.6/site-packages/trac/web/chrome.py, line 828, in
render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216, in
__getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 309, in
_get_session
return Session(self.env, req)
File /usr/lib/python2.6/site-packages/trac/web/session.py, line 201,
in __init__
if req.authname == 'anonymous':
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216, in
__getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 168, in
authenticate
authname = authenticator.authenticate(req)
File
/usr/lib/python2.6/site-packages/IgneousAuthenticationModule-2.0-py2.6.egg/igneousauth/auth.py,
line 34, in authenticate
s = Session.objects.get(pk=fid)
File /usr/lib/python2.6/site-packages/django/db/models/manager.py,
line 132, in get
return self.get_query_set().get(*args, **kwargs)
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line
344, in get
num = len(clone)
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line
82, in __len__
self._result_cache = list(self.iterator())
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line
273, in iterator
for row in compiler.results_iter():
File
/usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py, line
680, in results_iter
for rows in self.execute_sql(MULTI):
File
/usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py, line
734, in execute_sql
cursor = self.connection.cursor()
File /usr/lib/python2.6/site-packages/django/db/backends/__init__.py,
line 252, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
File
/usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py,
line 144, in _cursor
cursor = self.connection.cursor()
InterfaceError: connection already closed
Thanks,
Leo Singer
Graduate Student @ LIGO-Caltech
Leo Singer
Graduate Student @ LIGO-Caltech
(w)626-395-8510
Re: Questions on dependencies
Speaking of my script, I've made a bunch of changes to it recently, so I'll
probably need to create a new tag sometime so I can update the
`macportsscripts` port that points to it... The version from 0.1.4 still
reports library links that are there due to libtool overlinking, and I've
been working on finding ways to ignore those links, mainly by checking for
symbol usage with `nm`...
On Fri, Nov 8, 2013 at 10:34 PM, Craig Treleaven ctrelea...@cogeco.cawrote:
At 4:27 PM +0100 11/1/13, Clemens Lang wrote:
On Fri, Nov 01, 2013 at 10:27:04AM +1100, Joshua Root wrote:
If they are needed at build time and runtime, use depends_lib. If they
are only needed at runtime, use depends_run.
is there any difference between listing a package in both depends_build
and depends_run compared to just listing it in depends_lib, e.g. in how
licensing stuff propagates?
Since MacPorts ensures depends_run dependencies are installed before
attempting to build a package, we usually do not notice a depends_run
dependency that should rather be depends_build.
I'm currently trying to improve trace mode to a point where every
package I have installed builds fine using trace mode and I've come
across the gcc ports, which set
depends_run port:ld64 port:cctools
but fail to configure when trace mode (correctly) hides files installed
by these ports. I wonder whether the correct fix would be to convert
those into depends_lib, or just add them as depends_build, too.
I was playing with egall's port-depcheck.sh script:
https://github.com/cooljeanius/macportsscripts/
blob/v0.1.4/port-depcheck.sh
It identified several interesting things in my MythTV ports that I hadn't
known before--including a couple more opportunistic links (Myth is so
promiscuous!).
A couple of questions for the more-experienced here.
Myth includes Perl and Python bindings that need a number of dependencies
to work (eg port:${pymodver}-mysql, port:${perlmodver}-dbd-mysql, etc). I
have these listed as depends_lib but no Myth binaries link directly to
them. Is it advantageous to list them instead as depends_run?
egall's script says that Myth does not link directly to
qt4-mac-${mysqlver}-plugin but does link directly to qt4-mac. Again, are
there advantages to showing qt4-mac as a depends_lib but the plugin as a
depends_run?
I'm not a professional developer; just trying to understand a little more.
Thanks,
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: @macports.org handle
Apply for commit access: http://guide.macports.org/#project.membership Warning: it can take a while to get approved though... On Thu, Nov 7, 2013 at 11:40 AM, Robert Oschwald robertoschw...@googlemail.com wrote: I’m co-maintainer of sysutils/bacula and want to take over maintenance of www/mod_jk, too. For this, I want to use the @macports.org handle. How do I get one? Best, Robert ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: local PortGroup repo?
Really? That's strange, I could've sworn I was able to use the qmake portgroup in my local PortFile repository successfully when I was testing it... On Fri, Nov 1, 2013 at 2:36 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Nov 1, 2013, at 13:29, David Strubbe wrote: 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? In my previous testing, I found that unfortunately no, portgroup files in secondary port repositories are not used. The only place portgroup files are found is in the main port repository. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112810] trunk/dports/math/octave-devel
Yes there is, it just gets put in `/opt/local/libexec/gnubin`, which is not added to PATH by default. This is the same as most other GNU ports. On Fri, Nov 1, 2013 at 5:15 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Nov 1, 2013, at 15:41, michae...@macports.org wrote: +# In 10.8+, the LANG environment variable needs to be set to +# C otherwise /usr/bin/sed fails with an error, if you +# installed gsed with default name this should have no effect. There is no way to install gsed with default name in MacPorts. Years ago there was a variant to do so, but it was removed because using it caused problems for programs that assume “sed” is BSD sed on OS X. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts Trac is not displaying new changesets again
Me three. I had to check the macports-changes mailing list to be able to see the most recent changes: https://lists.macosforge.org/pipermail/macports-changes/2013-October/date.html On Wed, Oct 30, 2013 at 6:06 PM, Aljaž 'g5pw' Srebrnič g...@macports.orgwrote: Yup, i noticed that, too. On 30 ottobre 2013 at 23:01:20, Joshua Root (j...@macports.org//j...@macports.org) wrote: E.g. https://trac.macports.org/changeset/112746 - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev -- Aljaž 'g5pw' Srebrnič ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: open tickets
Yeah it can take a while to hear anything back... I sent in an application back in May and I haven't really heard anything back, either... On Thu, Oct 24, 2013 at 5:52 PM, David Strubbe dstru...@gmail.com wrote: Thanks! Yes, I sent an email to macports-...@lists.macosforge.org about a month ago regarding commit access, as specified by the guide, and a reminder a couple of weeks ago, but I didn't hear anything back. David On Thu, Oct 24, 2013 at 5:41 PM, Jeremy Lavergne jer...@lavergne.gotdns.org 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, 2013 at 11:15 PM, David Strubbe dstru...@gmail.com wrote: 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] https://trac.macports.org/ticket/40638 [2] https://trac.macports.org/ticket/40646 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Mavericks
In the blog post you link to, it mentions a tool called cpp11-migratehttp://clang.llvm.org/extra/cpp11-migrate.html, which has since been renamed to clang-modernizehttp://clang.llvm.org/extra/clang-modernize.html. Could we have this be a sub-port of at least one of the Macports clang ports, so as to make it easier for developers to make this transition? Heck, if we install the clang-modernize tool, we could even run it ourselves in the portfiles that need it while we wait for the developers to do it themselves... On Tue, Oct 22, 2013 at 5:57 PM, Jeremy Huddleston Sequoia jerem...@macports.org wrote: Apple released Mavericks today, and MacPorts works great on the new OS (assuming you use trunk/base). However, there is one big change that I want to point out to other MacPorts developers: the C++ runtime. The default C++ runtime is now libc++. libstdc++ is still available for binary compatibility, but newly built applications and frameworks should use libc++. This means that clang++ should be used for all C++ code since g++ does not support libc++. If a port uses C++ and fails to build with clang, it will not be supported on Mavericks (unless it does not export nor utilize C++ APIs to/from other ports). At this point, most C++ ports just work with libc++, so most users will be able to install their ports on Mavericks. One of the main reasons ports fail to build with libc++ is the tr1 namespace. If you see build errors about missing tr1 headers, please see this website for information: http://cplusplusmusings.wordpress.com/2013/06/03/whats-up-with-tr1-and-c11-and-libc/ Here is the list of ports which are currently listed as not working on Mavericks (mainly due to C++ issues). If you need any of these ports, please work with maintainers and developers to address the issues. aqua/qt4-mac archivers/libpar2 devel/openfst devel/quickfix gnome/mlview graphics/agave graphics/dcmtk graphics/enblend graphics/exact-image graphics/inkscape graphics/lib2geom graphics/podofo kde/krusader lang/chapel math/classias math/eigen math/gnudatalanguage math/octave multimedia/lmms multimedia/mp4v2 net/mediatomb net/obby science/arb science/bali-phy science/ds9 science/eo science/htcondor science/magicspp science/solid science/swarm textproc/cuneiform textproc/mgizapp textproc/opensp textproc/pialign textproc/sword Thanks, Jeremy ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112272] trunk/dports/audio/ices0/Portfile
Couldn't a bin-style dependency be used here (i.e. bin:iconv:libiconv) so
that /usr/bin/iconv can fulfill it as well?
On Wed, Oct 16, 2013 at 5:00 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Oct 16, 2013, at 04:33, j...@macports.org wrote:
Revision: 112272
https://trac.macports.org/changeset/112272
Author: j...@macports.org
Date: 2013-10-16 02:33:32 -0700 (Wed, 16 Oct 2013)
Log Message:
---
ices0: convert ices.1.in to UTF-8 so sed doesn't fail on 10.8
Modified Paths:
--
trunk/dports/audio/ices0/Portfile
Modified: trunk/dports/audio/ices0/Portfile
===
--- trunk/dports/audio/ices0/Portfile 2013-10-16 09:22:47 UTC (rev
112271)
+++ trunk/dports/audio/ices0/Portfile 2013-10-16 09:33:32 UTC (rev
112272)
@@ -30,6 +30,10 @@
patchfiles patch-src-in_mp4.c.diff \
patch-r13773.diff
+post-patch {
+system -W ${worksrcpath}/doc iconv -f ISO-8859-1 -t UTF-8
ices.1.in ices.1.in.new mv ices.1.in.new ices.1.in
+}
+
You should probably add a build dependency on libiconv then. It's already
there indirectly because it's a library dependency of pkgconfig but you
should explicitly list any dependencies you directly use.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Trac down?
http://downforeveryoneorjustme.com/trac.macports.org/timeline says that it's not just me... Anyone got any idea why? I had a ticket I wanted to file... I guess it can wait though... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Trac down?
Yup, can confirm that it is now working again. Thanks! Out of curiosity, what had gone wrong in the first place? On Mon, Oct 14, 2013 at 5:48 PM, William Siegrist wsiegr...@apple.comwrote: Should be fixed now. -Bill On Oct 14, 2013, at 1:35 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Times out for me too. I've forwarded it to the generic admin account and Mr. Siegrist's. On Oct 14, 2013, at 4:29 PM, Eric Gallager wrote: http://downforeveryoneorjustme.com/trac.macports.org/timeline says that it's not just me... Anyone got any idea why? I had a ticket I wanted to file... I guess it can wait though... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112137] trunk/dports/gis/gdal/Portfile
They've worked perfectly fine as non-conflicting up until this point...
On Sun, Oct 13, 2013 at 6:43 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Oct 12, 2013, at 14:09, strom...@macports.org wrote:
Revision: 112137
https://trac.macports.org/changeset/112137
Author: strom...@macports.org
Date: 2013-10-12 12:09:49 -0700 (Sat, 12 Oct 2013)
Log Message:
---
gdal: add postgresql93 variant
Modified Paths:
--
trunk/dports/gis/gdal/Portfile
Modified: trunk/dports/gis/gdal/Portfile
===
--- trunk/dports/gis/gdal/Portfile2013-10-12 16:08:01 UTC (rev
112136)
+++ trunk/dports/gis/gdal/Portfile2013-10-12 19:09:49 UTC (rev
112137)
@@ -275,6 +275,12 @@
configure.args-append
--with-pg=${prefix}/lib/postgresql92/bin/pg_config
}
+variant postgresql93 description {Enable PostgreSQL 9.3 support} {
+depends_lib-append port:postgresql93
+configure.args-delete --without-pg
+configure.args-append
--with-pg=${prefix}/lib/postgresql93/bin/pg_config
+}
The postgresql variants presumably need to be marked as conflicting with
one another.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112012] trunk/dports/python/py-gobject3/Portfile
or just do that thing that some python ports do where older python versions have separately-written sub-ports for the last version of that subport that worked with that python version. On Wed, Oct 9, 2013 at 12:32 PM, Clemens Lang c...@macports.org wrote: Hi, On Wed, Oct 09, 2013 at 09:08:59AM -0700, dev...@macports.org wrote: Revision: 112012 https://trac.macports.org/changeset/112012 Author: dev...@macports.org Date: 2013-10-09 09:08:59 -0700 (Wed, 09 Oct 2013) Log Message: --- py-gobject3: update to version 3.10.0. Since this apparently broke py26-gobject3 we should probably remove that from the Portfile. I haven't checked exactly what's wrong with the py26-gobject3 build, though. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40508: unicode_path patch not working on subversion 1.8.3 release
You can use the `-d` flag to your port command to make sure. Although since
it didn't error out on you, I would assume that it worked...
On Mon, Oct 7, 2013 at 12:21 PM, MacPorts nore...@macports.org wrote:
#40508: unicode_path patch not working on subversion 1.8.3 release
+--
Reporter: genuinefafa@… | Owner: dluke@…
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports |Version: 2.2.0
Resolution: | Keywords:
Port: subversion |
+--
Comment (by genuinefafa@…):
If i did everything right... The patch do not work (at least not on my
Mac)
{{{
sh-3.2# cd ~
sh-3.2# wget
http://subversion.tigris.org/nonav/issues/showattachment.cgi/1291/svn_1.8.x_darwin_unicode_precomp.patch
--2013-10-07 13:16:27--
http://subversion.tigris.org/nonav/issues/showattachment.cgi/1291/svn_1.8.x_darwin_unicode_precomp.patch
Resolving subversion.tigris.org...
204.16.104.146
Connecting to subversion.tigris.org|204.16.104.146|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4469 (4.4K) [text/plain]
Saving to: `svn_1.8.x_darwin_unicode_precomp.patch'
100%[===]
4,469 19.5K/s in 0.2s
2013-10-07 13:16:28 (19.5 KB/s) - `svn_1.8.x_darwin_unicode_precomp.patch'
saved [4469/4469]
sh-3.2#
sh-3.2# cd `port dir subversion`
sh-3.2# mv ~/svn_1.8.x_darwin_unicode_precomp.patch files/patch-
osx_unicode_precomp.diff
sh-3.2# port build subversion +unicode_path
--- Computing dependencies for subversion
--- Fetching distfiles for subversion
--- Verifying checksums for subversion
--- Extracting subversion
--- Applying patches to subversion
--- Configuring subversion
--- Building subversion
}}}
Is there a way I can know if the patch was applied?
--
Ticket URL: https://trac.macports.org/ticket/40508#comment:11
MacPorts http://www.macports.org/
Ports system for OS X
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: suggestion for Fortran recipe
I think it was Sean Farley, so I'm explicitly adding him on cc to this
conversation...
On Fri, Oct 4, 2013 at 10:32 AM, Jeremy Huddleston Sequoia
jerem...@macports.org wrote:
Yeah, that sounds reasonable.
As for the PortGroup, IIRC, someone was working on a general compilers
PortGroup which would incorporate this.
On Oct 3, 2013, at 18:47, David Strubbe dstru...@mit.edu wrote:
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 q32]} {
default_variants +q16
}
is functionally equivalent to
if {![variant_isset q8] ![variant_isset q16] ![variant_isset q32]}
{
default_variants +q16
}
since if +q16 is selected it is not important whether we consider that
choice to have been made by default or not.
As a result, in the Fortran recipe,
if {[variant_isset gcc${ver_no_dot}]} {
if {${default_fortran_variant} != +gcc${ver_no_dot}} {
set default_fortran_variant
}
}
is equivalent in functionality to
if {[variant_isset gcc${ver_no_dot}]} {
set default_fortran_variant
}
and the corresponding if-condition can be removed in the g95 statement,
thus removing some lines and simplifying it.
I am also wondering, can't the Fortran recipe be made a PortGroup? It
seems problematic for the maintainability of the portfiles for there to be
such a large block duplicated in many portfiles. If it were a PortGroup,
then issues like the one above could be settled centrally.
Best,
David
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] XcodeVersionInfo deleted version
Yeah, that's Mountain Lion On Fri, Oct 4, 2013 at 2:47 PM, Jeremy Lavergne jer...@lavergne.gotdns.orgwrote: After some version, the OS is now OS X and no longer Mac OS X ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: subports * prepend?
If it's so easy to work around it, then that means it should be pretty easy
to add an alias or something that does the same thing as the workaround in
base, right?
On Wed, Oct 2, 2013 at 5:37 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Oct 2, 2013, at 13:53, Peter Danecek wrote:
(1)
I am working on a port for iRods. This software package would provides a
server and a set of clients. Currently I am interested only in the client
part (for those who might know the product: icommands and fuse) and there
might be no need for the server part after all, but how knows. So I would
like to anticipate this possibility.
As the ports (server + 1* clients) would share substantial parts
Portfile code (it is built from one single package), I guess it is a good
idea to use subports for this. I have little experience with this, but I
think one could come up with something like this:
irods
The main port itself, either meta port or server port w/
dependency on clients?
A port which is not supposed to be used directly, like is the case
for example for the py-* ports?
irods-server
for the server part
irods-clients
all clients (use variants to switch on parts?)
irods-icmds / irods-client-icmds / irods-icommands
irods-fuse / irods-client-fuse
for the various clients separated into different subports
Maybe at some point it might be helpful to separate a lib subport as
well, but this probably depend on the project itself.
So what are the pros/cons in doing the one o the other? Any guidelines
for the port naming?
How to deal with the main port if it is supposed to do nothing? Do I
need to disable all phases or is the intended use different? Should it
provide just a message to the user (any good example for this?). I was
looking a bit around i the repo, but found no example which fits exactly
the above situations.
I'm not familiar with iRODS so it's hard for me to say whether you should
have a single client (sub)port or multiple client (sub)ports.
Can I assume that the FUSE, i-Commands, etc. clients are various ways of
accessing an iRODS server? And that different users -- or even different
programs -- might need to use different clients? If so, variants should not
be used, since a port cannot depend on a variant of another port. So I
would say your choices are between a single client port that installs all
clients always (without any variant choices), or multiple client subports,
each of which installs one client, and all of which can be installed
simultaneously. Your choice of which route to take would be based whether
all clients are in a single distfile, how their build system is set up, and
how long it takes to build. If each client is its own distfile, or the
build system is set up to build only one client at a time, or it takes a
long time to build, those would be good reasons to use a separate subport
for each client.
If you don't need the server now, you don't need to worry about that; you
can add a subport for it later if needed.
(2)
Am I correct that there are no *-prepend equivalents to *-append?
That's right.
Is there a way the have this functionality? I was thinking to do
something like:
long_description-perpend \
This subport provides the i-commands client.
Where the generally description of the system is given in the main port.
long_descriptionThis subport provides the i-commands client.
${long_description}
My subports often have the same description as the main port. This is bad
and due to laziness, and when I've thought of changing this, I've thought I
would append, not prepend. However that may be because as you say we don't
have a -prepend operator and I had not previously considered how easy it is
to work around that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: handle_option-prepend
I have actually wanted something like this in base for a while now, and just forgot to open a ticket about it... On Wed, Oct 2, 2013 at 8:02 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Oct 2, 2013, at 16:49, Eric Gallager wrote: If it's so easy to work around it, then that means it should be pretty easy to add an alias or something that does the same thing as the workaround in base, right? It would be implemented differently in base -- copy the -append implementation and change it slightly -- but yes it would be easy to do. Here it is: https://trac.macports.org/ticket/40655 Do we want this in base? There are probably other situations where it's useful too. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
