Is this different from what the makeicns port does?
> On May 27, 2016, at 7:30 AM, mcalh...@macports.org wrote:
>
> Revision
> 149057
> Author
> mcalh...@macports.org
> Date
> 2016-05-27 05:30:37 -0700 (Fri, 27 May 2016)
> Log Message
>
> octave family: generate icons with XCode prior to 4.5 (#5
On Sep 5, 2016, at 19:10, Fred Wright wrote:
>
>
>> On Sat, 3 Sep 2016, Ryan Schmidt wrote:
>>
>> But only do this if this software requires it. Otherwise, let MacPorts use
>> its default value of -Os.
>
> Seriously? In this day and age?
>
> AIUI, Apple used to use -Os for their own builds
On Thu, 1 Sep 2016, [ISO-8859-1] René J.V. Bertin wrote:
> On Wednesday August 31 2016 17:29:54 Lawrence Velázquez wrote:
>
> >The gdb port instructs the user to modify a system LaunchDaemon to
> >effectively circumvent taskgated. I frankly think that's an awful idea,
> >and future ports should n
On 2016-9-6 10:10 , Fred Wright wrote:
On Sat, 3 Sep 2016, Ryan Schmidt wrote:
But only do this if this software requires it. Otherwise, let MacPorts use its
default value of -Os.
Seriously? In this day and age?
AIUI, Apple used to use -Os for their own builds in the PPC era, since it
was
On Mon, Sep 5, 2016 at 9:26 PM, Fred Wright wrote:
> Interesting, given that the Linux kernel *requires* optimization to build
> correctly, due to some issue with macros vs. inline functions. Of course
> that's gcc, not clang, and it doesn't necessarily rule out -Os.
>
Yes. And I was talking ab
On Mon, 5 Sep 2016, Brandon Allbery wrote:
> On Mon, Sep 5, 2016 at 8:10 PM, Fred Wright wrote:
>
> > But when they switched to Intel, they also switched
> > to -O2. This allowed them to inflate the performance benefit of the
> > architecture switch. :-)
> >
>
> ...as long as -O2 worked. Experie
I was thinking (and have been) building the emulator with -O3 as I understand
from what I can gather from that -O3 prioritizes code speed over code size, and
the emulator is both small already and speed-hungry….but I see there is also
-Ofast in clang-3.8 (which is what my MacPro is building it w
On Mon, Sep 5, 2016 at 8:10 PM, Fred Wright wrote:
> But when they switched to Intel, they also switched
> to -O2. This allowed them to inflate the performance benefit of the
> architecture switch. :-)
>
...as long as -O2 worked. Experience from FreeBSD and from early MacPorts
experiments with
On Sat, 3 Sep 2016, Ryan Schmidt wrote:
> But only do this if this software requires it. Otherwise, let MacPorts use
> its default value of -Os.
Seriously? In this day and age?
AIUI, Apple used to use -Os for their own builds in the PPC era, since it
was needed to keep the bloat down to a dul
> On Sep 5, 2016, at 4:09 PM, Bradley Giesbrecht wrote:
>
>> On Sep 5, 2016, at 8:03 AM, Lawrence Velázquez wrote:
>>
>>> On Sep 5, 2016, at 8:42 AM, Craig Treleaven wrote:
>>>
>>> Not to belabour the issue, but should it not be the impact to port users
>>> that determines whether a change
Ryan Schmidt writes:
>> On Aug 31, 2016, at 3:59 PM, s...@macports.org wrote:
>>
>> Revision
>> 152202
>> Author
>> s...@macports.org
>> Date
>> 2016-08-31 13:59:44 -0700 (Wed, 31 Aug 2016)
>> Log Message
>>
>> folly: add new port
>> Added Paths
>>
>> • trunk/dports/devel/folly/
>>
>
>>
> On Sep 5, 2016, at 8:03 AM, Lawrence Velázquez wrote:
>
>> On Sep 5, 2016, at 8:42 AM, Craig Treleaven wrote:
>>
>> Not to belabour the issue, but should it not be the impact to port users
>> that determines whether a change is “minor” or not?
>
> I believe the "minorness" of the change is
On Monday September 05 2016 16:23:23 Rainer Müller wrote:
> I see no problem in generating certificates automatically. We also add
> users to the system or create launchd configurations without forcing the
> user to do it manually.
Yeah, exactly, I'm not really comfortable with adding users to th
> On Sep 5, 2016, at 8:42 AM, Craig Treleaven wrote:
>
> Not to belabour the issue, but should it not be the impact to port users that
> determines whether a change is “minor” or not?
I believe the "minorness" of the change is wholly up to the maintainer.
> The number of lines, by itself, does
On 2016-09-05 12:56, René J.V. Bertin wrote:
> On Monday September 05 2016 12:21:08 Rainer Müller wrote:
>
> Do the steps in that TN include the trust setting and the magic command in
> lldb's code-signing document?
I was talking about generating self-signed identities/certificates and
that is c
On 2016-09-05 13:29, René J.V. Bertin wrote:
> Reminds me: I'm not really comfortable with the idea that PortFiles
> would be able to create and store certificates. I'd rather see a form
> where they can check for the availability of the identity, and then
> inform the user exactly what command to
> On Sep 4, 2016, at 8:54 PM, Lawrence Velázquez wrote:
>
>> On Sep 4, 2016, at 8:32 PM, MacPorts wrote:
>>
>> #52144: mariadb: support for mpkg / mdmg
>> -+---
>> Reporter: ctreleaven@…| Owner: pixilla@…
>> Type: enhancement |
On Monday September 05 2016 12:49:22 Rainer Müller wrote:
> In a Portfile you would not be interested in the name of the identity,
> the but trust policy it grants (firewall bypass, task_for_pid, etc.).
That depends, I'd say. Is it even possible to uncouple identifier and trust
policy to the ext
On Monday September 05 2016 12:21:08 Rainer Müller wrote:
Do the steps in that TN include the trust setting and the magic command in
lldb's code-signing document?
> However, another thing I did not think of before, what should be used as
> expiry date on the certificate? According to the TN, OS
On 2016-09-05 00:57, René J.V. Bertin wrote:
> In a first draft the command accepted a list of binaries to sign, and read
> the identify from a configuration file. I suppose that corresponds to what
> you mean with a declarative syntax?
> I then went to a simpler, single-binary interface because
On 2016-09-02 14:19, Rainer Müller wrote:
> For step 4), how to give user 'macports' access to the System.keychain
> without entering a password? As an alternative, how to import the
> identity (both private/public key) into a different keychain with
> unlocked access?
I found the missing informat
21 matches
Mail list logo