On Jun 10, 2010, at 5:28 PM, Jack Howarth wrote:
> On Thu, Jun 10, 2010 at 11:50:46AM -0700, Toby Peterson wrote:
>> On Jun 10, 2010, at 11:26 AM, Jack Howarth wrote:
>>
>>> On Thu, Jun 10, 2010 at 06:23:08PM +0200, Vincent Lefevre wrote:
On 2010-06-10 11:50:49 -0400, Jack Howarth wrote:
>>>
On Thu, Jun 10, 2010 at 11:50:46AM -0700, Toby Peterson wrote:
> On Jun 10, 2010, at 11:26 AM, Jack Howarth wrote:
>
> > On Thu, Jun 10, 2010 at 06:23:08PM +0200, Vincent Lefevre wrote:
> >> On 2010-06-10 11:50:49 -0400, Jack Howarth wrote:
> >>> Exactly the point. MacPorts sorely needs the same s
On 2010-06-10 11:50:46 -0700, Toby Peterson wrote:
> On Jun 10, 2010, at 11:26 AM, Jack Howarth wrote:
> > Yes, but that is tangential to the fact that any soversion bump for
> > a support library in MacPorts currently forces a mass migration to
> > the new version since there is no support for co-
On Jun 10, 2010, at 11:26 AM, Jack Howarth wrote:
> On Thu, Jun 10, 2010 at 06:23:08PM +0200, Vincent Lefevre wrote:
>> On 2010-06-10 11:50:49 -0400, Jack Howarth wrote:
>>> Exactly the point. MacPorts sorely needs the same sort of split-off
>>> feature as fink where a libmpfr2-shlibs/libmpfr3-shl
On Thu, Jun 10, 2010 at 06:23:08PM +0200, Vincent Lefevre wrote:
> On 2010-06-10 11:50:49 -0400, Jack Howarth wrote:
> > Exactly the point. MacPorts sorely needs the same sort of split-off
> > feature as fink where a libmpfr2-shlibs/libmpfr3-shlibs split-off
> > package could contain the required r
On Jun 10, 2010, at 2:10 PM, Daniel J. Luke wrote:
> On Jun 10, 2010, at 11:52 AM, Joshua Root wrote:
>>> Error: port uninstall failed: Image error: libtool @2.2.8_0+darwin not
>>> installed as an image.
>>
>> Try the tip of the 1.9 branch.
>
> Works great. Thanks!
As an aside, it would be pret
On Jun 10, 2010, at 11:52 AM, Joshua Root wrote:
>> Error: port uninstall failed: Image error: libtool @2.2.8_0+darwin not
>> installed as an image.
>
> Try the tip of the 1.9 branch.
Works great. Thanks!
--
Daniel J. Luke
+===
On Jun 10, 2010, at 07:04, Ryan Schmidt wrote:
>
> On Jun 10, 2010, at 07:38, David Nicholls wrote:
>
>> Computing dependencies for gnudatalanguage
>> ---> Fetching gnudatalanguage
>> ---> Verifying checksum(s) for gnudatalanguage
>> ---> Extracting gnudatalanguage
>> ---> Configuring gnuda
On 2010-06-10 11:50:49 -0400, Jack Howarth wrote:
> Exactly the point. MacPorts sorely needs the same sort of split-off
> feature as fink where a libmpfr2-shlibs/libmpfr3-shlibs split-off
> package could contain the required runtime shared libraries which
> can co-exist but the main libmpfr2/libmpf
On 2010-6-11 00:59 , Daniel J. Luke wrote:
> % sudo port -dv uninstall libtool
> DEBUG: no portfile in registry for libtool @2.2.8_0+darwin
> DEBUG: no portfile in registry for libtool @2.2.8_0+darwin
> ---> Deactivating libtool @2.2.8_0+darwin
> DEBUG: Image error: libtool @2.2.8_0+darwin not ins
On Thu, Jun 10, 2010 at 04:43:27PM +0200, Vincent Lefevre wrote:
> On 2010-06-10 10:09:18 -0400, Jeremy Lavergne wrote:
> > We can easily make an mpfr3 port, which would result in the same
> > functionality.
> >
> > Naively, since the libraries have different versions in their names they
> > oug
On Thu, Jun 10, 2010 at 10:59:46AM -0400, Daniel J. Luke wrote:
>
> (doing an upgrade gives the same error after generating the new version's
> archive).
>
> Looks like portuninstall.tcl (line 149) just needs to check for image vs
> direct and do uninstall vs deactivate.
>
unfortunately I don
% sudo port -dv uninstall libtool
DEBUG: no portfile in registry for libtool @2.2.8_0+darwin
DEBUG: no portfile in registry for libtool @2.2.8_0+darwin
---> Deactivating libtool @2.2.8_0+darwin
DEBUG: Image error: libtool @2.2.8_0+darwin not installed as an image.
while executing
"portimage::d
On 2010-06-10 10:09:18 -0400, Jeremy Lavergne wrote:
> We can easily make an mpfr3 port, which would result in the same
> functionality.
>
> Naively, since the libraries have different versions in their names they
> ought not conflict.
> mpfr.0.dylib
> mpfr.1.dylib
But files like mpfr.h would c
We can easily make an mpfr3 port, which would result in the same functionality.
Naively, since the libraries have different versions in their names they ought
not conflict.
mpfr.0.dylib
mpfr.1.dylib
On Jun 10, 2010, at 10:03 AM, Jack Howarth wrote:
> This is one of the major defects in the curr
On Jun 10, 2010, at 09:03, Jack Howarth wrote:
> On Thu, Jun 10, 2010 at 03:48:19PM +0200, Vincent Lefevre wrote:
>> FYI, GNU MPFR 3.0.0 has just been released, but it is normal that
>> I haven't updated the port yet: this new version is *not* binary
>> compitible with the previous ones, and ther
On Thu, Jun 10, 2010 at 08:19, wrote:
Jeremy
> Revision 68694 Author sha...@macports.org Date 2010-06-10 06:19:13 -0700
> (Thu, 10 Jun 2010)
>
> Log Message
>
> py26-pyxmpp: update to version 1.1.1
>
> Modified Paths
>
> trunk/dports/python/py26-pyxmpp/Portfile
I was holding off on bumping to
On Thu, Jun 10, 2010 at 03:48:19PM +0200, Vincent Lefevre wrote:
> FYI, GNU MPFR 3.0.0 has just been released, but it is normal that
> I haven't updated the port yet: this new version is *not* binary
> compitible with the previous ones, and there are some dependencies
> that must be resolved first.
FYI, GNU MPFR 3.0.0 has just been released, but it is normal that
I haven't updated the port yet: this new version is *not* binary
compitible with the previous ones, and there are some dependencies
that must be resolved first. For instance, the current Math::MPFR
Perl module is not compatible with
On Jun 10, 2010, at 02:46, Rainer Müller wrote:
> On 2010-06-10 08:58 , Ryan Schmidt wrote:
>> It appears that "port sync" will create the index locally, even for ports
>> trees using svn, but if you've been using "svn up" directly (as I was) then
>> you'll have to keep the index updated another
On 2010-06-10 08:58 , Ryan Schmidt wrote:
> It appears that "port sync" will create the index locally, even for ports
> trees using svn, but if you've been using "svn up" directly (as I was) then
> you'll have to keep the index updated another way.
"svn up && portindex" should be sufficient, too
21 matches
Mail list logo
