Hi all,
MacPorts has been invited to send a representative to a 3
day meeting in Athens, Greece, on December 1st-3rd 2015, on the topic of
reproducible builds. It's being organised by the Debian folks, and in
their words, "The idea is to get a better understandings of the issues,
share perspective
Dear Ryan,
> Distfiles usually should not be added to the Subversion repository anymore.
> Is there no other location on the Internet from which this file could have
> been downloaded by the port?
I see. I’ll svn delete the file and use another one.
It would be nice if the rules should be clear
> On Sep 20, 2015, at 8:36 AM, Thibaut Paumard wrote:
> Unless the project decides on one
> over the other,
https://guide.macports.org/chunked/porthier.html
"libexec/
System daemons and system utilities (executed by other programs)."
—
Daniel J. Luke
On Sep 20, 2015, at 1:50 PM, Kurt Hindenburg wrote:
> On Sep 4, 2015, at 3:02 PM, Joshua Root wrote:
>
>>> https://trac.macports.org/ticket/28640 - port lint check when should use
>>> -append
>>
>> r-
>>
>> Overriding the deps set by a portgroup is not always incorrect.
>
> Do you mean to say
On Sep 20, 2015, at 1:46 PM, Mojca Miklavec wrote:
> On Fri, Sep 18, 2015 at 12:08 PM, Ryan Schmidt wrote:
>
>> For this particular problem, the correct solution is to fix the lua port by
>> renaming it to lua53 and making it install its headers to a directory that
>> is not ${prefix}/include (
Hello,
> On Sep 4, 2015, at 3:02 PM, Joshua Root wrote:
>
> On 2015-9-4 07:43 , Kurt Hindenburg wrote:
>> Hi,
>> Can I get some feedback on these patches?
>>
>> https://trac.macports.org/ticket/38208 - add depends_test
>
> r+
>
> LGTM. My one concern would be that end users may not want irre
On Fri, Sep 18, 2015 at 12:08 PM, Ryan Schmidt wrote:
> On Sep 17, 2015, at 10:51 AM, Mojca Miklavec wrote:
>> On Thu, Sep 17, 2015 at 4:47 PM, Rainer Müller wrote:
>>> On 2015-09-17 14:49, Mojca Miklavec wrote:
I would like to hide a couple of ports while building one specific
port. I kn
On Sunday September 20 2015 12:35:03 Ryan Schmidt wrote:
>Range filtering is already included in the compiler_blacklist_versions
>portgroup. An example is given in the portgroup:
Yes,
># compiler.blacklist-append {clang >= 421.11.66 < 444}
That only applies to the Xcode clang versions, as far
On Sunday September 20 2015, Brandon Allbery wrote regarding "Re:
compiler.whitelist and compiler installation side-effects"
[this is a resurrected message]
>Because we can't provide any meaningful support if it's using a random
>compiler?
That's what I meant with discourage rather than disallo
Let's keep the discussion on the mailing list.
On Sep 20, 2015, at 12:27 PM, René J.V. Bertin wrote:
> BTW, how difficult would it be to implement a range filter for blacklisting
> older macports-clang versions, or newer versions (3.7 doesn't build on OS X
> 10.6) :
>
> {macports-clang < 3.4}
On Sep 20, 2015, at 8:06 AM, René J. V. Bertin wrote:
> Ryan Schmidt wrote:
>
>> rule, that is the compiler that will be used. If Xcode does not provide
>> clang,
>> or if Xcode clang matches a blacklist rule (for example in your case, if
>> Xcode
>> clang is < build 500), then if macports-cla
> On Sep 20, 2015, at 8:17 AM, take...@macports.org wrote:
>
> Revision
> 140487
> Author
> take...@macports.org
> Date
> 2015-09-20 06:17:47 -0700 (Sun, 20 Sep 2015)
> Log Message
>
> Add distfile for fpc
> Added Paths
>
> • distfiles/fpc/fpc.man-2.6.4.tar.bz2
> Diff
>
> Added: distfile
On Sun, Sep 20, 2015 at 9:47 AM, René J.V. wrote:
> Is there any particular reason to disallow using Intel's compiler, rather
> than discourage it because of lack of testing? (or Xcode, if you take the
> above to the letter ^^)
Because we can't provide any meaningful support if it's using a ran
On Sunday September 20 2015, Brandon Allbery wrote regarding "Re:
compiler.whitelist and compiler installation side-effects"
>The point of the whitelist is to deal with buggy compilers. If 3.7 is
>preferred then it usually means that 3.6 can't build a working version of
>the port; as such, it wou
On Sun, Sep 20, 2015 at 9:06 AM, René J. V. wrote:
> *) a white list is a list of acceptable items which is checked against
> what's
> available
>
The point of the whitelist is to deal with buggy compilers. If 3.7 is
preferred then it usually means that 3.6 can't build a working version of
the p
Ryan Schmidt wrote:
> rule, that is the compiler that will be used. If Xcode does not provide clang,
> or if Xcode clang matches a blacklist rule (for example in your case, if Xcode
> clang is < build 500), then if macports-clang-3.7 exists (which it does),
> macports-clang-3.7 will be used (being
Le 19/09/2015 13:16, Andrew L. Moore a écrit :
> Guys,
> Macports appears to install qt5-mac, llvm-3.5 and llvm-3.7 wholesale under
> libexec. This is not a traditional destination. Is there a reason for
> choosing libexec over lib?
>
Hi,
In the Linux world, libexec is an optional directory i
On Sep 20, 2015, at 6:06 AM, René J.V. Bertin wrote:
> What are the exact effects in terms of compiler installation when I set?
>
>compiler.whitelistclang macports-clang-3.7 macports-clang-3.6
> macports-clang-3.5 macports-clang-3.4
> compiler.blacklist-append macports-llvm-gc
Jeremy Huddleston Sequoia wrote:
>> Macports appears to install qt5-mac, llvm-3.5 and llvm-3.7 wholesale under
^^^^
Actually, that's a recent decision that ignored months of work I did on the Qt5
port; I used ${prefix}/libexec/qt
Hello,
What are the exact effects in terms of compiler installation when I set?
compiler.whitelistclang macports-clang-3.7 macports-clang-3.6
macports-clang-3.5 macports-clang-3.4
compiler.blacklist-append macports-llvm-gcc-4.2 llvm-gcc-4.2
compiler.blacklist-append g
Hi,
I recently added fpc and chose libexec following e.g. llvm-3.5.
I’m ready to switch to the appropriate destination (lib?).
It seems that libexec is for binaries used by binaries and
is not assumed to be in user’s PATH.
I installed a launch script for xhyve.
This is not a daemon script.
Where
21 matches
Mail list logo
