Jack,
I think you broke ghostscript-nox in one of your recent changes:
Failed: Cannot read PatchFile
/sw/fink/dists/stable/main/finkinfo/text/ghostscript-nox.patch
Byw,
Max
signature.asc
Description: Message signed with OpenPGP using GPGMail
Fink wizards,
I am doing a clean fink install on a Mac OS X 10.9.5 system. It works fine up
until GhostScript is attempted. The log is below and seems to imply that
there is an inconsistent dependency?
I tried the suggested fixes, but no joy.
It looks like my attempt to install octave
On 9/26/14, 4:55 AM, Scott Hannahs wrote:
Fink wizards,
I am doing a clean fink install on a Mac OS X 10.9.5 system. It works fine
up until GhostScript is attempted. The log is below and seems to imply that
there is an inconsistent dependency?
I tried the suggested fixes, but no joy.
It's actually a ghostscript-8.61-4 oddity, but was probably there
before: Updating fails for me with the message
Preparing to replace ghostscript 8.61-3 (using
.../ghostscript_8.61-4_darwin-i386.deb) ...
Unpacking replacement ghostscript ...
/sw/bin/dpkg: error processing
On Mar 22, 2008, at 3:25 AM, Martin Costabel wrote:
It's actually a ghostscript-8.61-4 oddity, but was probably there
before: Updating fails for me with the message
Preparing to replace ghostscript 8.61-3 (using .../
ghostscript_8.61-4_darwin-i386.deb) ...
Unpacking replacement
On Mar 21, 2008, at 5:31 PM, Jack Howarth wrote:
Does anyone know why when installing ghostscript 8.61-3 in fink
10.5 unstable,
the following dpkg warnings appear?
Preparing to replace ghostscript 8.61-3 (using .../
ghostscript_8.61-4_darwin-i386.deb) ...
Unpacking replacement
On Mar 21, 2008, at 3:17 PM, Alexander Hansen wrote:
On Mar 21, 2008, at 5:31 PM, Jack Howarth wrote:
Does anyone know why when installing ghostscript 8.61-3 in fink
10.5 unstable,
the following dpkg warnings appear?
Preparing to replace ghostscript 8.61-3 (using .../
On Mar 21, 2008, at 6:25 PM, Jens Noeckel wrote:
On Mar 21, 2008, at 3:17 PM, Alexander Hansen wrote:
On Mar 21, 2008, at 5:31 PM, Jack Howarth wrote:
Does anyone know why when installing ghostscript 8.61-3 in fink
10.5 unstable,
the following dpkg warnings appear?
Preparing to replace
On 9/5/06, Peter Dyballa [EMAIL PROTECTED] wrote:
Am 05.09.2006 um 04:41 schrieb Alexander Hansen:
You never specified explicity what happened so i don't really have
enough information to tell you more about what you could have done.
If it failed because of a build conflict being swapped
Am 05.09.2006 um 04:41 schrieb Alexander Hansen:
You never specified explicity what happened so i don't really have
enough information to tell you more about what you could have done.
If it failed because of a build conflict being swapped back in
prematurely, then this generally goes away with
Am 05.09.2006 um 15:22 schrieb Alexander Hansen:
But what happened just before this?
Before these steps of selfupdate/update-all, *days* before, libjasper
was installed.
fink usually tries to remove a package that is buildconflicted.
What you're showing looks like what I said before:
On 9/5/06, Peter Dyballa [EMAIL PROTECTED] wrote:
Am 05.09.2006 um 15:22 schrieb Alexander Hansen:
But what happened just before this?
Before these steps of selfupdate/update-all, *days* before, libjasper
was installed.
fink usually tries to remove a package that is buildconflicted.
Jens Noeckel wrote:
[]
So I think the best fix is to submit a new ghostscript.info file
which has the configure flag --without-jasper and then no longer
needs a BuildConflict entry.
I committed this to CVS. I also put you as new maintainer, as you said
you would accept(*). The revision
Hi,
disabling jasper doesn't seem the right way to solve a buildconflict...
The -I/sw/include flags remain before the -I. flags, and since god
knows
what could be in /sw/include (eg, from a user's local pkgs), the
problem remains.
The first attempt, using the standard tools, worked
On Sep 4, 2006, at 3:28 AM, Jean-François Mertens wrote:
Hi,
disabling jasper doesn't seem the right way to solve a
buildconflict...
The -I/sw/include flags remain before the -I. flags, and since god
knows
what could be in /sw/include (eg, from a user's local pkgs), the
problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 4, 2006, at 4:30 PM, Jens Noeckel wrote:
Logic then dictates that I should go even further and remove the
BuildDepends on libjpeg and libpng3, as well as the runtime
dependencies on the corresponding shlibs.
Of course, the whole point of
On Sep 4, 2006, at 1:40 PM, Chris Zubrzycki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 4, 2006, at 4:30 PM, Jens Noeckel wrote:
Logic then dictates that I should go even further and remove the
BuildDepends on libjpeg and libpng3, as well as the runtime
dependencies on
On 04 Sep 2006, at 23:36, Jens Noeckel wrote:
On Sep 4, 2006, at 1:40 PM, Chris Zubrzycki wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 4, 2006, at 4:30 PM, Jens Noeckel wrote:
Logic then dictates that I should go even further and remove the
BuildDepends on libjpeg and
Am 04.09.2006 um 01:34 schrieb Alexander Hansen:
When trying an update-all after a selfupdate, this failed because
libjasper1 had to be removed – and it is too hard to ask my
permission? Even the package gets re-installed afterwards?
The engine isn't perfect--it will try to put the
On 9/4/06, Peter Dyballa [EMAIL PROTECTED] wrote:
Am 04.09.2006 um 01:34 schrieb Alexander Hansen:
When trying an update-all after a selfupdate, this failed because
libjasper1 had to be removed – and it is too hard to ask my
permission? Even the package gets re-installed afterwards?
Hello!
When trying an update-all after a selfupdate, this failed because
libjasper1 had to be removed – and it is too hard to ask my
permission? Even the package gets re-installed afterwards?
When then doing the re-build and re-install by hand, the complete /sw/
share/ghostscript/8.51
Am 03.09.2006 um 16:04 schrieb Peter Dyballa:
When then doing the re-build and re-install by hand, the complete /
sw/share/ghostscript/8.51 branch was removed.
This is not the proper method!
Sorry! This is my fault: I had my own examples directory still in the
old 'transitional' tree.
On 9/3/06, Peter Dyballa [EMAIL PROTECTED] wrote:
Hello!
When trying an update-all after a selfupdate, this failed because
libjasper1 had to be removed – and it is too hard to ask my
permission? Even the package gets re-installed afterwards?
It's a BuildConflict. Fink tries to remove the
On Sep 3, 2006, at 4:34 PM, Alexander Hansen wrote:
On 9/3/06, Peter Dyballa [EMAIL PROTECTED] wrote:
Hello!
When trying an update-all after a selfupdate, this failed because
libjasper1 had to be removed – and it is too hard to ask my
permission? Even the package gets re-installed
On Thu, 16 Sep 2004, Martin Costabel wrote:
Could you send the output starting from the last complete linker command
line? The symbol _XpmReadFileToPixmap is defined in
/usr/X11R6/lib/libXpm.dylib, so we would need to see whether this
library is linked in.
The same problem I previously
Shrisha Rao wrote:
[]
This:
checking for whether -lXpm needs to be explicitly given... unknown
[]
and this:
gcc -L/sw/lib -L/usr/X11R6/lib -o xdvi xdvi.o events.o dvi-init.o
dvi-draw.o special.o font-open.o filefind.o pk.o vf.o util.o popups.o psheader.o
psgs.o -lXaw -lXmu -lXt -lSM -lICE
On Sat, 18 Sep 2004, Martin Costabel wrote:
The errors you are getting seem to indicate that in your case
libXaw.dylib is missing, libXaw.a is present, but both libXpm.a and
libXpm.dylib are missing or are otherwise broken.
You will probably have to reinstall X11SDK.pkg from the XCode tools
Shrisha Rao wrote:
[]
ld: warning multiple definitions of symbol _hash_create
/usr/lib/libdl.dylib(strhash.So) definition of _hash_create
../kpathsea/SHARED/libkpathsea.dylib(hash.o) definition of _hash_create
ld: Undefined symbols:
_XpmReadFileToPixmap
make[2]: *** [oxdvi.bin] Error 1
make[1]:
Greetz.
Pls. excuse if this is an already-known issue. On the website it is
mentioned that XCode 1.5 seems to cause problems with some packages. I
have noticed what seem to be such problems, with GS and teTeX. Here is
the tail of the teTeX log:
ld: warning multiple definitions of symbol
[...]
On a somewhat different but related note, why are several of the
GhostScript
.info files duplicated in both the stable and unstable trees?
That's perfectly normal. Any file that is in the stable tree came at
some point from the unstable tree. They get only removed if a newer
version
tetex-nox depends on tetex-shlibs and tetex-dev, and the latter two require
the X11-enabled versions of ghostscript in order to *build*, but not in
order to run.
To build tetex-nox without installing those versions, you'll need to do
binary installs of the little -shlibs and -dev parts, via:
31 matches
Mail list logo
