On Wednesday May 04 2016 08:25:09 Ryan Schmidt wrote:
> I looked at the version number of the llvm-3.7 port and noted it was 3.7.1,
> which looks like a stable version number.
> I looked at the version number of the llvm-3.8 port and noted it was
> 3.8-r262722_1, which looks like a development v
> On May 4, 2016, at 7:47 AM, Ryan Schmidt wrote:
>
>
>> On May 4, 2016, at 9:38 AM, Rainer Müller wrote:
>>
>> On 2016-05-04 15:20, Ryan Schmidt wrote:
In my opinion, llvm-3.8 and llvm-3.9 should really have a -devel
prefix as long as they provide pre-releases. The same also applies
> On May 4, 2016, at 9:38 AM, Rainer Müller wrote:
>
> On 2016-05-04 15:20, Ryan Schmidt wrote:
>>> In my opinion, llvm-3.8 and llvm-3.9 should really have a -devel
>>> prefix as long as they provide pre-releases. The same also applies
>>> to gcc6. With the *-devel naming scheme it would be easy
On 2016-05-04 15:20, Ryan Schmidt wrote:
>> In my opinion, llvm-3.8 and llvm-3.9 should really have a -devel
>> prefix as long as they provide pre-releases. The same also applies
>> to gcc6. With the *-devel naming scheme it would be easy to
>> identify the latest stable version.
>
> I disagree. W
On Apr 29, 2016, at 3:20 AM, René J.V. Bertin wrote:
> On Thursday April 28 2016 21:37:53 Ryan Schmidt wrote:
>
>>> I would think that an adaptive mechanism to determine a default variant
>>> isn't incompatible with reproducible builds (or at least an accepted/able
>>> exception) because the s
> On Apr 29, 2016, at 9:19 AM, Rainer Müller wrote:
>
> On 2016-04-29 04:37, Ryan Schmidt wrote:
>> When multiple version variants are available, we usually suggest you
>> default to the latest stable version. Right now that's llvm-3.7.
>
> I was surprised it is not the llvm-3.8 port, as that v
On May 3, 2016, at 7:10 PM, Abdulrahman Alshammari wrote:
> Hey,
> The attached portfile is working now perfectrly after fixing some issue. I am
> not sure if what I did is the right one or there is something better than
> this. When I install civl, it works fine, but when I uninstall it, the f
On May 4, 2016, at 8:58 AM, Ryan Schmidt wrote:
>> Can you just manually put the openssl distfile on the master mirror? Since
>> so many ports depend on it, we're likely to see lots of noise from people
>> with older systems.
>
> Done.
Excellent. Thanks Ryan!
--
Daniel J. Luke
_
> On May 4, 2016, at 7:50 AM, Daniel J. Luke wrote:
>
> On May 4, 2016, at 8:48 AM, Ryan Schmidt wrote:
>>> If we can force a mirror of openssl in the meantime (if it's not there
>>> already), it would be useful to prevent more tickets from being opened for
>>> failed builds.
>>
>> The mirro
On May 4, 2016, at 8:48 AM, Ryan Schmidt wrote:
>> If we can force a mirror of openssl in the meantime (if it's not there
>> already), it would be useful to prevent more tickets from being opened for
>> failed builds.
>
> The mirror-all-ports script runs automatically twice a week. The script t
On May 4, 2016, at 7:47 AM, Daniel J. Luke wrote:
> On May 4, 2016, at 8:46 AM, Ryan Schmidt wrote:
>> On May 4, 2016, at 1:58 AM, Joshua Root wrote:
>>> Probably the best fix on our end would be to reinstate the immediate
>>> mirroring that used to happen from a post-commit hook. And possibly
On May 4, 2016, at 8:46 AM, Ryan Schmidt wrote:
> On May 4, 2016, at 1:58 AM, Joshua Root wrote:
>> Probably the best fix on our end would be to reinstate the immediate
>> mirroring that used to happen from a post-commit hook. And possibly make the
>> build block until the mirroring is done. In
On May 4, 2016, at 1:58 AM, Joshua Root wrote:
> Probably the best fix on our end would be to reinstate the immediate
> mirroring that used to happen from a post-commit hook. And possibly make the
> build block until the mirroring is done. In fact, maybe the mirroring could
> be triggered from
13 matches
Mail list logo
