Re: [111797] trunk/dports/math/gnudatalanguage/Portfile
On Oct 2, 2013, at 07:46, take...@macports.org wrote:
Revision: 111797
https://trac.macports.org/changeset/111797
Author: take...@macports.org
Date: 2013-10-02 05:46:48 -0700 (Wed, 02 Oct 2013)
Log Message:
---
gnudatalanguage: updated for 0.9.4. fixed a bug that gcc44 didn't conflict
with gcc48. added gcc49
Modified Paths:
--
trunk/dports/math/gnudatalanguage/Portfile
+variant gcc49 conflicts gcc44 gcc45 gcc46 gcc47 gcc48 description {enabling
of the support for OpenMP with gcc48} {
+configure.compiler macports-gcc-4.9
+}
This variant's description is wrong (gcc48 - gcc49)
Also, should gcc49 be included in this if statement?
if {[variant_isset gcc44] || [variant_isset gcc45] || [variant_isset gcc46] ||
[variant_isset gcc47] || [variant_isset gcc48]} {
configure.args-delete -DOPENMP=OFF
configure.args-append -DOPENMP=ON
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: introducing Trac_Assigner: a script to automatically assign tickets to their port maintainer
Hi Bill, are you talking about convenience or about dog fight ? Has there already been issues with GPL components in macports.org ? I can help by gathering the sources of the components PortsAutoComplete is based on. Eric Le Tue, 01 Oct 2013 13:35:22 -0700, William Siegrist wsiegr...@apple.com a écrit : On Oct 1, 2013, at 1:25 PM, Joshua Root j...@macports.org wrote: On 2013-10-2 06:02 , Eric Le Lay wrote: I'm welcoming your comments on the approach or the code. Nice work; thanks! I wonder if the license will be a problem. Apple apparently has a policy against shipping GPLv3 code in their products, but I don't know if the same applies for something hosted on macosforge. Please re-license it. GPL licenses require a lot of extra paperwork for me, and it may not get approved in the end. -Bill ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: introducing Trac_Assigner: a script to automatically assign tickets to their port maintainer
Components it is based on? Is it not your original work? Or are you referring to dependencies? Your code should be covered by some other license if you want it to get installed on the server. -Bill On Oct 2, 2013, at 8:42 AM, Eric Le Lay ele...@macports.org wrote: Hi Bill, are you talking about convenience or about dog fight ? Has there already been issues with GPL components in macports.org ? I can help by gathering the sources of the components PortsAutoComplete is based on. Eric Le Tue, 01 Oct 2013 13:35:22 -0700, William Siegrist wsiegr...@apple.com a écrit : On Oct 1, 2013, at 1:25 PM, Joshua Root j...@macports.org wrote: On 2013-10-2 06:02 , Eric Le Lay wrote: I'm welcoming your comments on the approach or the code. Nice work; thanks! I wonder if the license will be a problem. Apple apparently has a policy against shipping GPLv3 code in their products, but I don't know if the same applies for something hosted on macosforge. Please re-license it. GPL licenses require a lot of extra paperwork for me, and it may not get approved in the end. -Bill ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
subports * prepend?
Hi all, two questions: (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. (2) Am I correct that there are no *-prepend equivalents to *-append? 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. Thanks for any comment! ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
two submissions
Hi all, could someone have a quick look at Tickets #40533 and #40534: https://trac.macports.org/ticket/40533 https://trac.macports.org/ticket/40534 These are quite simple, so should be no big deal. I replaced `file link` commands with Macport's extension `ln -s`. I understood it is preferable to use these extensions. Thanks! ~petr smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [111821] trunk/dports/sysutils/sudo/Portfile
On Oct 2, 2013, at 14:51, rai...@macports.org wrote:
Revision: 111821
https://trac.macports.org/changeset/111821
Author: rai...@macports.org
Date: 2013-10-02 12:51:50 -0700 (Wed, 02 Oct 2013)
Log Message:
---
sysutils/sudo:
Fix copying of configuration in post-activate
Modified Paths:
--
trunk/dports/sysutils/sudo/Portfile
Modified: trunk/dports/sysutils/sudo/Portfile
===
--- trunk/dports/sysutils/sudo/Portfile 2013-10-02 19:31:35 UTC (rev
111820)
+++ trunk/dports/sysutils/sudo/Portfile 2013-10-02 19:51:50 UTC (rev
111821)
@@ -6,6 +6,7 @@
namesudo
epoch 1
version 1.8.8
+revision1
categories sysutils security
license ISC
maintainers nomaintainer
@@ -56,7 +57,7 @@
post-activate {
if {![file exists ${prefix}/etc/sudoers]} {
-copy ${destroot}${prefix}/etc/sudoers.dist ${prefix}/etc/sudoers
+copy ${prefix}/etc/sudoers.dist ${prefix}/etc/sudoers
}
}
Oops, thank you, I wasn't paying attention.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: subports * prepend?
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
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: [MacPorts] #40654: Upgrade of iterm2
I submitted two tickets 40653 and 40654 with patches, that are nomaintainer. I would be willing to take them over, but I wasn't sure how I was supposed to do that. Just declare myself the maintainer? I also contributed a perl 5.18 Portfile, which seems to have a maintainer + openmaintainer. I'd wasn't sure how that worked either. Can someone tell me how this works or where I need to RTFM? Thanks, Mark —Mark ___ Mark E. Anderson e...@emer.net On Wed, Oct 2, 2013 at 7:23 PM, MacPorts nore...@macports.org wrote: #40654: Upgrade of iterm2 + Reporter: emer@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: MacPorts Future Component: ports |Version: 2.2.99 Keywords: | Port: iterm2 + Upgrade of iterm2 to latest version. -- Ticket URL: https://trac.macports.org/ticket/40654 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: [MacPorts] #40654: Upgrade of iterm2
At 7:30 PM -0400 10/2/13, Mark Anderson wrote: I submitted two tickets 40653 and 40654 with patches, that are nomaintainer. I would be willing to take them over, but I wasn't sure how I was supposed to do that. Just declare myself the maintainer? I also contributed a perl 5.18 Portfile, which seems to have a maintainer + openmaintainer. I'd wasn't sure how that worked either. Can someone tell me how this works or where I need to RTFM? I don't have commit privs but I maintain a couple ports. Info at: http://guide.macports.org/#project.contributing Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #40654: Upgrade of iterm2
Ok, so I just needed to RTFM, I had a feeling. Thanks! Mark —Mark ___ Mark E. Anderson e...@emer.net On Wed, Oct 2, 2013 at 7:38 PM, Craig Treleaven ctrelea...@cogeco.cawrote: At 7:30 PM -0400 10/2/13, Mark Anderson wrote: I submitted two tickets 40653 and 40654 with patches, that are nomaintainer. I would be willing to take them over, but I wasn't sure how I was supposed to do that. Just declare myself the maintainer? I also contributed a perl 5.18 Portfile, which seems to have a maintainer + openmaintainer. I'd wasn't sure how that worked either. Can someone tell me how this works or where I need to RTFM? I don't have commit privs but I maintain a couple ports. Info at: http://guide.macports.org/#**project.contributinghttp://guide.macports.org/#project.contributing Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: handle_option-prepend
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
Re: default configure.cppflags
On Oct 2, 2013, at 19:02, Ryan Schmidt wrote:
https://trac.macports.org/ticket/40655
Do we want this in base? There are probably other situations where it's
useful too.
One place this would come in handy is for CPPFLAGS in situations when MacPorts'
default `-I${prefix}/include` is problematic for some build systems. Ideally
the build systems should be fixed of course, but when that's difficult, some
ports (like abiword) may write `configure.cppflags -I. -I${prefix}/include`;
with this patch to base, it could be more simply written
`configure.cppflags-prepend -I.`.
But another way to handle that issue is to replace `-I${prefix}/include` with
`-isystem${prefix}/include`, and several ports (like freetype, ghostscript
and pianobar) do that. Which brings up the question of whether we should change
MacPorts' default configure.cppflags to that. Would there be any harm?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: default configure.cppflags
On Oct 2, 2013, at 8:14 PM, Ryan Schmidt ryandes...@macports.org wrote:
One place this would come in handy is for CPPFLAGS in situations when
MacPorts' default `-I${prefix}/include` is problematic for some build
systems. Ideally the build systems should be fixed of course, but when that's
difficult, some ports (like abiword) may write `configure.cppflags -I.
-I${prefix}/include`; with this patch to base, it could be more simply
written `configure.cppflags-prepend -I.`.
+1 to this being possibly useful
But another way to handle that issue is to replace `-I${prefix}/include`
with `-isystem${prefix}/include`, and several ports (like freetype,
ghostscript and pianobar) do that. Which brings up the question of whether we
should change MacPorts' default configure.cppflags to that. Would there be
any harm?
where is -isystem documented? If it does what it looks like it does, it could
possibly cause issues depending on what is in ${prefix}/include (ie, if there's
some header that would override a system header).
Actually, even -I${prefix}/include is too big of a stick since builds pick up
installed ports even if they shouldn't (which is why, way back in the mists of
time, we didn't set that by default). Hopefully some version of
sandboxing/trace mode will eventually fix this (so that only files belonging to
ports that are listed as dependencies appear as if they exist to software
that's being built).
--
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
Re: default configure.cppflags
On Oct 2, 2013, at 19:29, Daniel J. Luke wrote:
But another way to handle that issue is to replace `-I${prefix}/include`
with `-isystem${prefix}/include`, and several ports (like freetype,
ghostscript and pianobar) do that. Which brings up the question of whether
we should change MacPorts' default configure.cppflags to that. Would there
be any harm?
where is -isystem documented?
I found it in the gcc documentation in the same place where -I is documented:
http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
If it does what it looks like it does, it could possibly cause issues
depending on what is in ${prefix}/include (ie, if there's some header that
would override a system header).
What it does is append the given directory after all -I directories. Also, if
an -isystem directory is also specified with -I, the -I for that directory is
ignored. So in this way I think it's exactly what we want. From what I've read,
-isystem should be used for system and third party library headers, and -I
should be used for paths within your project's own source code. I've made the
change locally and I'll try it out for awhile and see what happens. The patch
is on this ticket:
https://trac.macports.org/ticket/40656
Actually, even -I${prefix}/include is too big of a stick since builds pick up
installed ports even if they shouldn't (which is why, way back in the mists
of time, we didn't set that by default). Hopefully some version of
sandboxing/trace mode will eventually fix this (so that only files belonging
to ports that are listed as dependencies appear as if they exist to software
that's being built).
You mean opportunistic linking? We also put -L${prefix}/lib in LDFLAGS and set
CPATH and LIBRARY_PATH; they all contribute to opportunistic linking. Changing
-I to -isystem isn't meant to address this problem.
___
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
