I don't think that GIMPskel project has been updated in a long time. I
found that it still requires libcups* for some reasonso I manually copy
those files from /usr/lib into the $TOP/lib folder. Wrong or right,
GIMPskel serves its purpose, at least for me.
That DYLD thing is probably easy eno
On Nov 18, 2014, at 10:46 PM, Jeff Singleton wrote:
> On 11/18/14 7:17 PM, Ryan Schmidt wrote:
>> find ~ -name GIMP.app 2>/dev/null
>
> The only other GIMP.app is in the GIMPskel folder in my Downloads folder
> where I build the application bundle.
>
> jsingleton@minimac ~ $ find ~ -nam
Well, just to tell that computing is impressive…
What clever you are guys!
--
Eneko Gotzon Ares
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
On Nov 19, 2014, at 9:14 PM, Merton Campbell Crockett
wrote:
> It would seem to me that if there were a general problem with changes to the
> database software, I should have seen delays when the 15 outdated software
> packages were processed before processing the boost package.
Even an expon
On Thu, Nov 20, 2014 at 2:44 AM, Michael wrote:
> I can't get it to actually load a kernel driver to get the user fuse stuff
> going, and mount_ntfs never gets called.
>
Are you on Yosemite? Apple no longer allows unsigned kernel drivers unless
you tweak a magic boot setting, so ports like osxfu
So I just submitted ticket https://trac.macports.org/ticket/45947 for ntfs-3g,
but it is "nomaintainers".
I can't get it to actually load a kernel driver to get the user fuse stuff
going, and mount_ntfs never gets called.
The port notes make reference to stuff needed to make fuse4x work, but it
https://trac.macports.org/ticket/45645
It's already documented in the ticket tracker.
On Nov 19, 2014, at 9:14 PM, Merton Campbell Crockett wrote:
> Jeremy:
>
> Your assertion that the problem is related to a new version of the database
> software included in the Yosemite software distribution
Jeremy:
Your assertion that the problem is related to a new version of the database
software included in the Yosemite software distribution bothers me.
It would seem to me that if there were a general problem with changes to the
database software, I should have seen delays when the 15 outdated
Yosemite introduced a new version of the database software that MacPorts uses,
making MacPorts horrifically slow presently.
Please let the process complete next time.
A (not yet released) version of MacPorts will address the database changes from
Yosemite.
On Nov 19, 2014, at 17:37, Merton Cam
I was performing an update of outdated software and ran into this problem when
updating Wireshark.
---> Computing dependencies for boost
---> Fetching archive for boost
---> Attempting to fetch
boost-1.56.0_2+no_single+no_static+python27.darwin_14.x86_64.tbz2 from
http://packages.macports.or
Have you tried setting the date on the system back and trying?
On Nov 18, 2014, at 8:43 PM, James Linder wrote:
> On 19 Nov 2014, at 4:00 am, macports-users-requ...@lists.macosforge.org wrote:
>
> I don't recall clearly but I think I wanted to run Snow Leopard in a
> VM. Either 64- or 32-bit
On Wed, Nov 19, 2014 at 10:45 AM, René J.V. wrote:
> > That though does not make what I said incorrect. clang 3.4 fully
> > supports c++11. A statement of fact.
>
> Please don't take my statement about C++11 support out of context.
> Relevant earlier thread: "clang++-mp-3.4 doesn't find initializ
On 19/11/14 10:45, René J.V. Bertin wrote:
On Wednesday November 19 2014 10:20:23 Chris Jones wrote:
That though does not make what I said incorrect. clang 3.4 fully
supports c++11. A statement of fact.
Please don't take my statement about C++11 support out of context.
Relevant earlier thread
On Wednesday November 19 2014 10:20:23 Chris Jones wrote:
> That though does not make what I said incorrect. clang 3.4 fully
> supports c++11. A statement of fact.
Please don't take my statement about C++11 support out of context.
Relevant earlier thread: "clang++-mp-3.4 doesn't find initializer
The issue you describe is an issue with the *deployment* of clang in
MacPorts/OSX. Something else.
... or an issue with the package itself that prevents it being
compiled with clang (I have come across plenty of issues myself of code
that compiles with gcc but fails with clang, because of b
On 18/11/14 23:05, René J.V. Bertin wrote:
On Tuesday November 18 2014 22:59:51 Chris Jones wrote:
Clang 3.4 fully supports c++11 ( if i recall correctly it is complete as of
3.3). So whatever problems you where having it wasn't because clang does not
fully support c++11...
Sorry, but yes.
16 matches
Mail list logo