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
template struct to_hex{
T value;
operator T() const {return value;}
friend std::istream& operator
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 downloa
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? Whe
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:
> < https://trac.macports.org/ticket/
On Nov 1, 2013, at 22:00, Michael Dickens 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 just a patchfile?
< 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 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
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:c
> 2013/10/17 Davide Liessi :
> 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 the files needed for
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 d
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 wrote:
> Hi,
>
> Could I ask a committer to take a look at
>
> https://trac.macports.org/ticket/41108
>
>
On Nov 1, 2013, at 16:41, Eric Gallager wrote:
> On Fri, Nov 1, 2013 at 5:15 PM, Ryan Schmidt 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" otherwise /usr/bin/sed fails with
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 wrote:
>
> On Nov 1, 2013, at 15:41, michae...@macports.org wrote:
>
> > +# In 10.8+, the LANG env
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
On Nov 1, 2013, at 15:59, Jeremy Lavergne 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 other
>> port rely on
On Nov 1, 2013, at 4:45 PM, Ryan Schmidt 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 work with the curre
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
> 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 p
On Nov 1, 2013, at 15:30, Jeremy Lavergne 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 list
macports-dev@lists.ma
On Nov 1, 2013, at 15:47, Jeremy Lavergne 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 /opt/local/bin/perl.
>> The
> 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 t
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
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
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
> de
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
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.
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 wrote:
> These dependencies are not correct: the perl5.12
On Nov 1, 2013, at 4:15 PM, Ryan Schmidt 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 depends_run dependency). T
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 assu
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
>
>
Someone, do a test!
On Nov 1, 2013, at 16:05, Ryan Schmidt 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
https://lists.macosforge.org/
On Nov 1, 2013, at 4:04 PM, Ryan Schmidt wrote:
> On Nov 1, 2013, at 15:02, Daniel J. Luke wrote:
>> On Nov 1, 2013, at 3:58 PM, Ryan Schmidt wrote:
>>> On Nov 1, 2013, at 14:55, Daniel J. Luke wrote:
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt wrote:
> On Nov 1, 2013, at 14:44, Daniel J
On Nov 1, 2013, at 15:02, Dan Ports 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 portfiles will
On Nov 1, 2013, at 15:02, Daniel J. Luke wrote:
> On Nov 1, 2013, at 3:58 PM, Ryan Schmidt wrote:
>> On Nov 1, 2013, at 14:55, Daniel J. Luke wrote:
>>> On Nov 1, 2013, at 3:50 PM, Ryan Schmidt 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 3:58 PM, Ryan Schmidt wrote:
> On Nov 1, 2013, at 14:55, Daniel J. Luke wrote:
>> On Nov 1, 2013, at 3:50 PM, Ryan Schmidt 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
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 14:55, Daniel J. Luke wrote:
> On Nov 1, 2013, at 3:50 PM, Ryan Schmidt 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 v
On Nov 1, 2013, at 3:50 PM, Ryan Schmidt 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 its programs t
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
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 not a library. However I think
> we should ch
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 wrote:
>
> On Nov 1, 2013, at 13:29, David Strubbe wrote:
>
> > Is it possible to have local PortGrou
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 fil
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 wrote:
> I think we use `installs_libs no` for those licensing che
On Nov 1, 2013, at 14: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?
It’s a hidden directory at:
dports/_resources/
__
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
macports-dev@lists.macosforg
I think we use `installs_libs no` for those licensing checks.
On Nov 1, 2013, at 14:09, 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
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 sa
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 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 wh
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
Descrip
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
51 matches
Mail list logo
