On Fri, Jun 10, 2011 at 2:44 AM, Ryan Schmidt wrote:
> The epoch is the most significant number for MacPorts when determining if a
> port is outdated. When MacPorts says that "miniupnpc 1.5_0" is installed, it
> really means "2_1.5_0" because the epoch is 2. In r79340 you changed it to
> "0_1.5
> We do already have some variables in macports.conf that can easily cause
> breakage and we don't support changing, namely binpath and extra_env.
> Maybe if we grouped all the setting in that category (optflags is the
> other one that comes to mind) in a section at the end of the
> That's a good point, we do that now, so this might not be a problem. We
> didn't used to do that, and got several bug reports from, for example, people
> ending up building ppc i386 universal binaries on Snow Leopard.
Might be handy to have a `portconf -n` or similar functionality as well.
On Jun 9, 2011, at 22:05, Jeremy Lavergne wrote:
>> We'll probably still get people who migrate their old macports.conf to a new
>> machine, and cause new problems due to using an older compiler. Hopefully
>> most users will notice.
>
> Isn't this why we comment out the configuration if using
On Jun 9, 2011, at 22:01, Ryan Schmidt wrote:
> We'll probably still get people who migrate their old macports.conf to a new
> machine, and cause new problems due to using an older compiler. Hopefully
> most users will notice.
Maybe it would be good to print a message, at least at the debug le
On Jun 9, 2011, at 21:49, Joshua Root wrote:
> On 2011-6-10 12:46 , Ryan Schmidt wrote:
>>
>> I don't know why we have extra_env. But I know two reasons to have binpath:
>> 1) it lets us check that ports are using the right compiler [1]; 2) it lets
>> users use MacTeX instead of MacPorts' TeX L
On 2011-6-10 12:46 , Ryan Schmidt wrote:
>
> On Jun 9, 2011, at 21:31, Joshua Root wrote:
>
>> On 2011-6-10 12:25 , Ryan Schmidt wrote:
>>>
We do already have some variables in macports.conf that can easily cause
breakage and we don't support changing, namely binpath and extra_env.
On Jun 9, 2011, at 21:31, Joshua Root wrote:
> On 2011-6-10 12:25 , Ryan Schmidt wrote:
>>
>>> We do already have some variables in macports.conf that can easily cause
>>> breakage and we don't support changing, namely binpath and extra_env.
>>> Maybe if we grouped all the setting in that catego
On Jun 9, 2011, at 21:44, Jeremy Lavergne wrote:
>> I suggest that if no phases were skipped, the current behavior is fine, but
>> if phases were skipped, MacPorts should not print the link to the bug
>> reporting instructions, but should instead tell the user to clean and try
>> again. Any obj
> I suggest that if no phases were skipped, the current behavior is fine, but
> if phases were skipped, MacPorts should not print the link to the bug
> reporting instructions, but should instead tell the user to clean and try
> again. Any objections?
Do you plan to keep the message indicating w
I'm tired of bug reports with main.logs attached that aren't complete (i.e.
that contain lines saying "Skipping completed").
When a port error occurs, MacPorts 1.9.2 prints the location of the log file,
and a link to bug reporting instructions, which people don't read.
I thought I remembered th
On Jun 9, 2011, at 21:23, Joshua Root wrote:
> On 2011-6-10 10:48 , Ryan Schmidt wrote:
>>
>> On Jun 9, 2011, at 16:07, Jeremy Huddleston wrote:
>>
>>> I assumed that this was already possible and was amazed that it wasn't...
>>> with this patch, one can set "compiler" in $prefix/etc/macports.
On 2011-6-10 10:48 , Ryan Schmidt wrote:
>
> On Jun 9, 2011, at 16:07, Jeremy Huddleston wrote:
>
>> I assumed that this was already possible and was amazed that it wasn't...
>> with this patch, one can set "compiler" in $prefix/etc/macports.conf to
>> choose a default compiler.
>>
>> Thoughts?
On Jun 9, 2011, at 16:07, Jeremy Huddleston wrote:
> I assumed that this was already possible and was amazed that it wasn't...
> with this patch, one can set "compiler" in $prefix/etc/macports.conf to
> choose a default compiler.
>
> Thoughts?
We do not want the user to be able to specify tha
On Jun 9, 2011, at 16:41, and.dam...@macports.org wrote:
> Revision: 79340
> http://trac.macports.org/changeset/79340
> Author: and.dam...@macports.org
> Date: 2011-06-09 14:41:23 -0700 (Thu, 09 Jun 2011)
> Log Message:
> ---
> port miniupnpc, set up right compilr, fixed a
On Thu, Jun 9, 2011 at 17:07, Jeremy Huddleston wrote:
> I assumed that this was already possible and was amazed that it wasn't...
> with this patch, one can set "compiler" in $prefix/etc/macports.conf to
> choose a default compiler.
>
> Thoughts?
What's the use case for wanting to select a com
I assumed that this was already possible and was amazed that it wasn't... with
this patch, one can set "compiler" in $prefix/etc/macports.conf to choose a
default compiler.
Thoughts?
Index: src/port1.0/portconfigure.tcl
===
--- sr
Hi,
is there anybody out there who successfully installed XCode4 in parallel to an
already existing XCode3? Any hints on what one would have to consider if one
were to try XCode4?
Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosfor
On Jun 9, 2011, at 13:04, Larry Gilbert wrote:
> bitcoind is not the usual ends-with-d daemon. It can act both as a
> daemon and a client, and I think it's intended to be run as a normal
> user and not root.
Thanks, in that case, let's leave it as is.
__
bitcoind is not the usual ends-with-d daemon. It can act both as a
daemon and a client, and I think it's intended to be run as a normal
user and not root.
-L2G
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/ma
On Jun 9, 2011, at 12:18, Andrea D'Amore wrote:
> On Thu, Jun 9, 2011 at 6:37 PM, Ryan Schmidt wrote:
>
>> Shouldn't server processes go in sbin not bin?
>
> AFAIR /sbin is for system's binaries, like administration tools and in
> general root-only programs.
Right... I guess I assumed that, be
On Thu, Jun 9, 2011 at 6:37 PM, Ryan Schmidt wrote:
> Shouldn't server processes go in sbin not bin?
AFAIR /sbin is for system's binaries, like administration tools and in
general root-only programs.
Do we have an existing policy about that?
--
Andrea
On Jun 9, 2011, at 11:31, and.dam...@macports.org wrote:
> Revision: 79320
> http://trac.macports.org/changeset/79320
> Author: and.dam...@macports.org
> Date: 2011-06-09 09:31:51 -0700 (Thu, 09 Jun 2011)
> Log Message:
> ---
> port bitcoin, added command line server, fixed
Am 07.06.2011 um 11:41 schrieb Ryan Schmidt:
> On Jun 7, 2011, at 01:16, Titus von Boxberg wrote:
>
>> The same problem is given here:
>> http://stackoverflow.com/questions/4697859/mac-os-x-and-static-boost-libs-stdstring-fail
>>
>> But I currently do not understand the problem.
>> And the "sol
24 matches
Mail list logo