Hi,
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
Hi,
Could I ask a committer to take a look at
https://trac.macports.org/ticket/41108
I know it hasn't been submitted for that long…. But it fixes build problems the
current port has with OSX 10.9, so it would be good to get it committed asap.
Thanks in advance.
cheers Chris
smime.p7s
On Fri, Nov 01, 2013 at 04:27:40PM +0100, Clemens Lang wrote:
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
Anyone with several OS versions available, please double check my apple files
in perl_select.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On Nov 1, 2013, at 10:27, Clemens Lang wrote:
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?
I’m not sure if there’s any licensing difference. Historically, we’ve said
I think we use `installs_libs no` for those licensing checks.
On Nov 1, 2013, at 14:09, Ryan Schmidt ryandes...@macports.org wrote:
I’m not sure if there’s any licensing difference. Historically, we’ve said
that if a dependency is needed at build time and at runtime, then it should
be
Hi all,
Is it possible to have local PortGroup files to use with a local Portfile
repository? If so, where should they be put? Or otherwise, how should one
try out a new PortGroup?
Thanks,
David
___
macports-dev mailing list
On Nov 1, 2013, at 14:29, David Strubbe dstru...@gmail.com 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?
It’s a hidden directory at:
dports/_resources/
We use “installs_libs no” to indicate that a port that other ports depend on
does not install any libraries.
That’s no help when the port does install libraries, like ImageMagick does.
On Nov 1, 2013, at 13:11, Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
I think we use `installs_libs
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
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
On Nov 1, 2013, at 2:09 PM, Ryan Schmidt ryandes...@macports.org wrote:
I’m not sure if there’s any licensing difference. Historically, we’ve said
that if a dependency is needed at build time and at runtime, then it should
be listed in only depends_lib, even if it is not a library. However I
On Nov 1, 2013, at 14:44, Daniel J. Luke wrote:
On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote:
I’m not sure if there’s any licensing difference. Historically, we’ve said
that if a dependency is needed at build time and at runtime, then it should
be listed in only depends_lib, even if it is
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 14:44, Daniel J. Luke wrote:
On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote:
The solution would be for ports that use the ImageMagick libraries to
depend on it via depends_lib and for those only needing
On Nov 1, 2013, at 14:55, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 14:44, Daniel J. Luke wrote:
On Nov 1, 2013, at 2:09 PM, Ryan Schmidt wrote:
The solution would be for ports that use the ImageMagick
On Fri, Nov 01, 2013 at 03:21:36PM -0400, Eric Gallager wrote:
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...
I believe portfiles will use portgroups from their own repository, so
portgroups
On Nov 1, 2013, at 3:58 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 14:55, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 14:44, Daniel J. Luke wrote:
On Nov 1, 2013, at 2:09 PM, Ryan
On Nov 1, 2013, at 15:02, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 1, 2013, at 3:58 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 14:55, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1,
On Nov 1, 2013, at 15:02, Dan Ports dpo...@macports.org wrote:
On Fri, Nov 01, 2013 at 03:21:36PM -0400, Eric Gallager wrote:
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...
I believe
On Nov 1, 2013, at 4:04 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 15:02, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 1, 2013, at 3:58 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 14:55, Daniel J. Luke dl...@geeklair.net wrote:
On Nov 1, 2013,
Someone, do a test!
On Nov 1, 2013, at 16:05, Ryan Schmidt ryandes...@macports.org wrote:
That was what I assumed would happen, but is not what I observed when I last
tried it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On Nov 1, 2013, at 14:10, s...@macports.org wrote:
Revision
112798
Author
s...@macports.org
Date
2013-11-01 12:10:31 -0700 (Fri, 01 Nov 2013)
Log Message
upx:
* perl5 build dependency, use perl5.12
* see #29763 beginning of perl_select work
Modified Paths
•
On Nov 1, 2013, at 15:09, Daniel J. Luke wrote:
which again, you're assuming that no port has a runtime dependency on a
library that doesn't link with that library (which a reasonable person might
express as a depends_run dependency). This is #2 from above.
The only way you can assume
On Nov 1, 2013, at 4:15 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 15:09, Daniel J. Luke wrote:
which again, you're assuming that no port has a runtime dependency on a
library that doesn't link with that library (which a reasonable person might
express as a
Knew I shouldn’t have bothered trying to make perl. Reverting r112798 in
r112809.
snark/
Oh well, maybe the ticket can just sit for another two years.
Or can we just remove perl, wholesale?
/snark
On Nov 1, 2013, at 16:10, Ryan Schmidt ryandes...@macports.org wrote:
These dependencies are
Well, this is the reason I haven’t touched it. It was convenient to have a port
providing “perl”, “pod2man”, etc. The “port select” mechanism is what we
decided we wanted to use, but that it was for a user’s convenience, and that
ports cannot rely on a user having chosen any particular version.
Or we could stop with the silliness and just have the perl5 port install the
current (stable) perl5 (which is 5.18.1 right now). We could simplify the p5-*
ports to just work with the current perl5, and IFF there is an actual need for
an older perl, we can have a separate port for it...
On Nov
I clearly misunderstood your last comment on the ticket:
Some time has passed, and subports now solve this part of the problem. Are
there any remaining reasons why we should not remove the perl5 port and add
the perl_select port as suggested? We would of course need to find all ports
On Nov 1, 2013, at 15:40, Jeremy Lavergne wrote:
I clearly misunderstood your last comment on the ticket:
Some time has passed, and subports now solve this part of the problem. Are
there any remaining reasons why we should not remove the perl5 port and add
the perl_select port as
On Nov 1, 2013, at 15:38, Daniel J. Luke wrote:
Or we could stop with the silliness and just have the perl5 port install the
current (stable) perl5 (which is 5.18.1 right now). We could simplify the
p5-* ports to just work with the current perl5, and IFF there is an actual
need for an
Yes. But perl5 provided the files. A port could depend on bin:perl:perl5 and
be assured that, if for some reason /usr/bin/perl did not exist, then the
perl5 port would be installed and it would then provide /opt/local/bin/perl.
The difference with “port select” is that there is no port that
On Nov 1, 2013, at 15:47, Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
Yes. But perl5 provided the files. A port could depend on bin:perl:perl5 and
be assured that, if for some reason /usr/bin/perl did not exist, then the
perl5 port would be installed and it would then provide
On Nov 1, 2013, at 15:30, Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
Knew I shouldn’t have bothered trying to make perl. Reverting r112798 in
r112809.
This takes care of r112798 but you also had r112801-r112808…
___
macports-dev mailing
If we remove the perl5 port and switch to users using “port select” to create
the /opt/local/bin/perl symlink, then we cannot from any other port rely on
/opt/local/bin/perl existing, just like we cannot from any other port rely on
anything else that “port select” creates for any other
Yes, I see what I did to (my) pioneers there. I’m going to leave it without the
epoch change.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
On Nov 1, 2013, at 15:59, Jeremy Lavergne jer...@lavergne.gotdns.org wrote:
If we remove the perl5 port and switch to users using “port select” to
create the /opt/local/bin/perl symlink, then we cannot from any other port
rely on /opt/local/bin/perl existing, just like we cannot from any
On Nov 1, 2013, at 4:45 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 15:38, Daniel J. Luke wrote:
Or we could stop with the silliness and just have the perl5 port install the
current (stable) perl5 (which is 5.18.1 right now). We could simplify the
p5-* ports to just
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
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
On Nov 1, 2013, at 16:41, Eric Gallager eg...@gwmail.gwu.edu wrote:
On Fri, Nov 1, 2013 at 5:15 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 1, 2013, at 15:41, michae...@macports.org wrote:
+# In 10.8+, the LANG environment variable needs to be set to
+# C
Hi,
p.s.
Could a commuter also take a look at.
https://trac.macports.org/ticket/40949
its needed to fix the pythia variant of ROOT.
cheers Chris
On 1 Nov 2013, at 5:12pm, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
Hi,
Could I ask a committer to take a look at
On 2013-11-2 02:27 , Clemens Lang wrote:
Hi,
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
2013/10/17 Davide Liessi davide.lie...@gmail.com:
Can anybody please review my Portfile?
https://trac.macports.org/ticket/40139
I updated the Portfile again.
Can someone please review it?
(I'm sorry for the multiplication of the files and of the Portfile
versions; comment:8 contains a list of
On Nov 1, 2013, at 17:25, Joshua Root wrote:
On 2013-11-2 02:27 , Clemens Lang wrote:
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
On 2013-11-2 10:12 , Ryan Schmidt wrote:
On Nov 1, 2013, at 17:25, Joshua Root wrote:
On 2013-11-2 02:27 , Clemens Lang wrote:
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
https://trac.macports.org/ticket/40852#comment:101
Does anyone know why the binary library isn't part of the rsync tarball?
It's coming in through SVN just fine ... Do I need to have a separate
download for it, not just a patchfile? - MLD
On Fri, Nov 1, 2013, at 10:56 PM, MacPorts wrote:
On Nov 1, 2013, at 22:00, Michael Dickens michae...@macports.org wrote:
https://trac.macports.org/ticket/40852#comment:101
Does anyone know why the binary library isn't part of the rsync tarball?
It's coming in through SVN just fine ... Do I need to have a separate
download for it, not
Probably because rsync's -C option gets used at one point. But a half
meg file in the ports tree isn't a great idea to begin with. Is it
really impossible to build from source *and* unavailable for download
anywhere?
On 2013-11-2 14:00 , Michael Dickens wrote:
On 11/01/2013 08:39 PM, Joshua Root wrote:
Probably because rsync's -C option gets used at one point. But a half
meg file in the ports tree isn't a great idea to begin with. Is it
really impossible to build from source *and* unavailable for download
anywhere?
I agree. Where is the source?
On 2013-11-2 14:41 , Blair Zajac wrote:
On 11/01/2013 08:39 PM, Joshua Root wrote:
Probably because rsync's -C option gets used at one point. But a half
meg file in the ports tree isn't a great idea to begin with. Is it
really impossible to build from source *and* unavailable for download
I have a ticket https://trac.macports.org/ticket/41004 with an issue
between Boost and Apple's new libc++; or, something like that. A simple
program which shows this issue is:
{{{
#include boost/lexical_cast.hpp
template class T struct to_hex{
T value;
operator T() const {return value;}
51 matches
Mail list logo
