> On Nov 9, 2015, at 17:31, René J.V. Bertin wrote:
>
> On Monday November 09 2015 16:11:54 Jeremy Huddleston Sequoia wrote:
>
> hi,
>
>>> Now what if you do
>>>
>>> %> ln -s libssl.35.dylib libssl.1.0.0.dylib ?
>>>
>>> (assuming that libressl indeed installs libssl.35.dylib)
>>>
>>> If tha
Pixilla was kind enough to update both the amavisd-new and opendkim ports but I
ran into a problem with unbound, a dependency of opendkim. I went to look at
the opendkim port on trac to see if I could figure it out or open a ticket but
I see "Trac Error" when attempting to view any port.
Here's
On Mon, Nov 9, 2015 at 8:31 PM, René J.V. wrote:
> First quick tests (downloading a couple of release tarballs from github,
> with /opt/local/bin/curl) suggests that it works. Which doesn't really
> surprise me too much: both libraries are written in C. As long as dependent
> software sticks to p
On Monday November 09 2015 16:11:54 Jeremy Huddleston Sequoia wrote:
hi,
> > Now what if you do
> >
> > %> ln -s libssl.35.dylib libssl.1.0.0.dylib ?
> >
> > (assuming that libressl indeed installs libssl.35.dylib)
> >
> > If that works, it can be handled with a very simple post-destroot addit
> On Nov 9, 2015, at 13:40, René J.V. Bertin wrote:
>
> On Monday November 09 2015 15:27:54 Ryan Schmidt wrote:
>
>>> Interesting. I think it was FreeBSD that tried to do that (both API and
>>> ABI) and failed at both, and said rebuild stuff for one or the other.
>>> Apparently they were the
> On Nov 9, 2015, at 13:10, René J.V. Bertin wrote:
>
> On Monday November 09 2015 15:05:26 Ryan Schmidt wrote:
>
>> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a
>> rebuild is needed to make things work, then this
>
> Yes, but at least on Linux libressl installs lib
On 2015-11-09 22:40, René J.V. Bertin wrote:
> Now what if you do
>
> %> ln -s libssl.35.dylib libssl.1.0.0.dylib ?
>
> (assuming that libressl indeed installs libssl.35.dylib)
>
> If that works, it can be handled with a very simple post-destroot addition in
> both ports .
You should not do th
On Monday November 09 2015 15:27:54 Ryan Schmidt wrote:
> > Interesting. I think it was FreeBSD that tried to do that (both API and
> > ABI) and failed at both, and said rebuild stuff for one or the other.
> > Apparently they were the ones who made the mistake, and it actually works
> > if done
On Nov 9, 2015, at 2:34 AM, Artur Szostak wrote:
> Let me ask another question: Is there a seamless way to add building and
> mirroring services from 3rd parties for the pre-built binaries?
No. We want verified binaries built in a clean-room by known servers, not
binaries built in unknown cond
On Nov 9, 2015, at 3:12 PM, Brandon Allbery wrote:
> On Mon, Nov 9, 2015 at 4:05 PM, Ryan Schmidt wrote:
>> In r139229 Jeremy made libressl a drop-in replacement for openssl.
>
> Interesting. I think it was FreeBSD that tried to do that (both API and ABI)
> and failed at both, and said rebuild s
On Mon, Nov 9, 2015 at 4:05 PM, Ryan Schmidt
wrote:
> In r139229 Jeremy made libressl a drop-in replacement for openssl.
Interesting. I think it was FreeBSD that tried to do that (both API and
ABI) and failed at both, and said rebuild stuff for one or the other.
Apparently they were the ones wh
On Monday November 09 2015 15:05:26 Ryan Schmidt wrote:
> In r139229 Jeremy made libressl a drop-in replacement for openssl. If a
> rebuild is needed to make things work, then this
Yes, but at least on Linux libressl installs libraries with different numbers
(libssl.so.35 vs libssl.so.1.0.0). I
On Nov 9, 2015, at 2:43 PM, Brandon Allbery wrote:
> On Mon, Nov 9, 2015 at 3:39 PM, René J.V. wrote:
>> I understand that libressl aims to be API-compatible with openssl so that it
>> can act as a drop-in replacement. How far does that go, far enough that one
>> can symlink the libssl and libcr
On Mon, Nov 9, 2015 at 3:39 PM, René J.V. wrote:
> I understand that libressl aims to be API-compatible with openssl so that
> it can act as a drop-in replacement. How far does that go, far enough that
> one can symlink the libssl and libcrypto runtimes from the one port to the
> shared libraries
Hi,
I understand that libressl aims to be API-compatible with openssl so that it
can act as a drop-in replacement. How far does that go, far enough that one can
symlink the libssl and libcrypto runtimes from the one port to the shared
libraries of the other, without having to rebuild dependents
Hi,
I want to deactivate a port and its dependencies. Something similar to "port
uninstall --follow-dependencies portname". But I do not want to uninstall
anything, I just want to deactivate. How should I construct such a port
command? The closest I can think of is:
sudo port deactivate portna
I've been using this [1] procedure for quite a while.
It could easily be adapted for widespread use by hosting the binaries
and signatures somewhere publicly.
And I'm not sure of the specifics, but I know there are build scripts
in the repo somewhere for building all ports. A previous message [2]
Hi,
Let me ask another question: Is there a seamless way to add building and
mirroring services from 3rd parties for the pre-built binaries?
Kind regards.
Artur
From: macports-users-boun...@lists.macosforge.org
[macports-users-boun...@lists.macosforge.
18 matches
Mail list logo