date:20031221

As the lead developer of ImageMagick I would like to clear up a few
misconceptions being stated on this list.

  1. Harold L Hunt II says: This package [GraphicsMagick] will replace
 ImageMagick for various reasons. One of those reasons is that the
 GM folks are committed to provide ABI stability and proper version
 numbers, whereas IM is not making such a commitment and has already
 made various arbitrary changes to ABI version numbers.

 This is something Bob Friensenhahn is trying to convince people of
 but it is simply not true.  http://studio.imagemagick.org/ states
 our project goal of: ImageMagick's focus is on performance,
 minimizing bugs, and providing stable APIs and ABIs.  Bob Friensenhahn
 does not speak for ImageMagick.  He tends to diminish ImageMagick in
 various mailing lists I assume in order to promote his ImageMagick
 clone project, GraphicsMagick.

  2. Daniel Reed says: GaphicsMagick is a feature-for-feature
 replacement of ImageMagick.  This is simply not true.  GraphicsMagick
 is missing many features that ImageMagick has and if you run
 a program or script against the two you will in many cases get
 different results.

  3. Daniel Reed says: I considered ImageMagick's to be votes for
 GraphicsMagick.  Why vote at all if you are going to usurp the votes?
 A vote for ImageMagick should remain with ImageMagick.  If you want
 votes for GraphicsMagick have a separate vote.

If you choose to support GraphicsMagick instead of ImageMagick, fine.  However,
base your decision on facts, not misconceptions.

Re: ImageMagick/Graphicsmagick

[EMAIL PROTECTED] wrote:

As the lead developer of ImageMagick I would like to clear up a few
misconceptions being stated on this list.
How many developers have you still got?  There doesn't seem to be much 
evidence of other developers on the project anymore.

  1. Harold L Hunt II says: This package [GraphicsMagick] will replace
 ImageMagick for various reasons. One of those reasons is that the
 GM folks are committed to provide ABI stability and proper version
 numbers, whereas IM is not making such a commitment and has already
 made various arbitrary changes to ABI version numbers.
We had a discussion on the cygwin-apps mailing list; unfortunately, the 
discussion might not have always had ImageMagick in the subject, so you 
might not be able to find all of the messages.  The gist of the 
discussion was that, regardless of stated intentions, the way that 
ImageMagick was handling ABI version numbers was going to cause problems 
on Cygwin.  Someone else can pipe in with the details if you ask again, 
but I was satisified with the results of the discussion.

 This is something Bob Friensenhahn is trying to convince people of
 but it is simply not true.  http://studio.imagemagick.org/ states
 our project goal of: ImageMagick's focus is on performance,
 minimizing bugs, and providing stable APIs and ABIs.  Bob Friensenhahn
 does not speak for ImageMagick.  He tends to diminish ImageMagick in
 various mailing lists I assume in order to promote his ImageMagick
 clone project, GraphicsMagick.
Are we not adults capable of making our own decisions?  Bob had nothing 
to do with this discussion and he has nothing to do with the fact that 
there is a problem with the way that ImageMagick is handling library 
version numbers.

  2. Daniel Reed says: GaphicsMagick is a feature-for-feature
 replacement of ImageMagick.  This is simply not true.  GraphicsMagick
 is missing many features that ImageMagick has and if you run
 a program or script against the two you will in many cases get
 different results.
Hasn't been a problem for us so far.  If you want to prove us wrong, 
you'd better be prepared to submit some step-by-step examples of how to 
generate such cases and describe why the differing results are 
meaningful.  Assuming that you do that, why should we care?  We've only 
had the ImageMagick package for less than a month and, quite frankly, it 
is easier to maintain the GraphicsMagick package because the build files 
don't create empty directories that I have to go back and delete by 
hand, among other things.

  3. Daniel Reed says: I considered ImageMagick's to be votes for
 GraphicsMagick.  Why vote at all if you are going to usurp the votes?
 A vote for ImageMagick should remain with ImageMagick.  If you want
 votes for GraphicsMagick have a separate vote.
Nope.  I packaged ImageMagick, then I found GraphicsMagick and was 
convinced (by the code, not rhetoric) that it is superior for our 
purposes.  I will not continue to package ImageMagick; I will only 
continue to package GraphicsMagick.

Don't come down on Daniel, accusing him of usurping other people.  I 
announced that I was pulling the ImageMagick pacage and would be 
replacing it with a functional equivalent named ImageMagick.  He handled 
the votes according to my announcement.

If you choose to support GraphicsMagick instead of ImageMagick, fine.  However,
base your decision on facts, not misconceptions.
No misconceptions here.  The real problem is that some of this 
discussion took place under subject lines like Re: Pending Package List 
..., I believe.  The history is covered in our mailing list; our search 
engine doesn't find it, but Google might.  Happy reading.

Harold

Re: ImageMagick/Graphicsmagick

 How many developers have you still got?  There doesn't seem to be much 
 evidence of other developers on the project anymore.

Clearly you have made up your mind so it seems a waste of time to answer
questions you don't really care about but here goes.  We have 7 developers
mostly part time.  I am the original author and full-time developer of
ImageMagick and a majority of the GraphicsMagick was written by me.

 We had a discussion on the cygwin-apps mailing list; unfortunately, the 
 discussion might not have always had ImageMagick in the subject, so you 
 might not be able to find all of the messages.  The gist of the 

I found them all.

 discussion was that, regardless of stated intentions, the way that 
 ImageMagick was handling ABI version numbers was going to cause problems 
 on Cygwin.  Someone else can pipe in with the details if you ask again, 
 but I was satisified with the results of the discussion.

GraphicsMagick has the same ABI versioning numbers as ImageMagick.  ImageMagick
starts at 6 rather than 1 since previous versions of ImageMagick was at 5.

 Are we not adults capable of making our own decisions?  Bob had nothing 
 to do with this discussion and he has nothing to do with the fact that 
 there is a problem with the way that ImageMagick is handling library 
 version numbers.

Bob chimed in on your mailing list and I was responding to that message.

 Hasn't been a problem for us so far.  If you want to prove us wrong, 
 you'd better be prepared to submit some step-by-step examples of how to 
 generate such cases and describe why the differing results are 
 meaningful.  Assuming that you do that, why should we care?  We've only 

I could submit step-by-step examples but why waste my time since you do
claim you do not care.

 had the ImageMagick package for less than a month and, quite frankly, it 
 is easier to maintain the GraphicsMagick package because the build files 
 don't create empty directories that I have to go back and delete by 
 hand, among other things.

That's an excellant criteria for choosing a package for the entire CYGWIN
community :-).

 Nope.  I packaged ImageMagick, then I found GraphicsMagick and was 
 convinced (by the code, not rhetoric) that it is superior for our 
 purposes.  I will not continue to package ImageMagick; I will only 
 continue to package GraphicsMagick.

Again, you have not investigating the best solution here.  You have
made up you mind based on just a few criteria and you are shoving it
down everyones throat.  Given your strong statements and clear unwillingness
to discuss which project is best based on merit, don't bother replying.
I will not waste anymore of the CYGWIN community's time on a dead subject.
I will tell the CYGWIN community that ImageMagick Studio intends to 
have full support of ImageMagick 5.5.7 and 5.5.8 Beta for CYGWIN and both
source and binaries will be available on
ftp://ftp.imagemagick.org/pub/ImageMagick.

Diff for generic readme and generic-build script to automatically generate pkg data and file listings

2003-12-21 Thread Alan Miles

All,

Based on the 1.8 version of the generic build script I would like to submit
this patch, which would allow package maintainers
to automatically update the distribution READMEs when they do a build.

1/ The option all does not call list. The fix in the patch does.
2/ The patches to both file let the PKG, VER, and REL variables in the
README be automatically be filled in by the script -
   then maintainers won't have to manually do this.
3/ This patch fulfills the wish to have the file names be automatically be
placed in the README prior to binary/src build
   releases. The 1.8 version heads in that direction, but the functionality
isn't there.
4/ I have defined a NEWVER variable to handle the newer REL part of the
original README
5/ Defined a new export variable: 'ThePackageReadMeFile' which defines the
Package README file name
   (saves defining it twice) - both 'list' and 'install' use it
6/ I haven't renamed the routine list, which it should be since it is a
package readme editor
7/ Note: the e sed command (quoting the man page for sed):

   Extended sed command:

   `e [COMMAND]'
 This command allows one to pipe input from a shell command into
 pattern space.  Without parameters, the `e' command executes the
 command that is found in pattern space and replaces the pattern
 space with the output; a trailing new-line is suppressed.

 If a parameter is specified, instead, the `e' command interprets
 it as a command and sends it to the output stream (like `r' does).
 The command can run across multiple lines, all but the last
 ending with a back-slash.

 In both cases, the results are undefined if the command to be
 executed contains a NUL character.

8/ To prevent using sed's -i option (see the message from Igor
http://cygwin.com/ml/cygwin/2003-11/msg01067.html -
   this should mitigate Igor's concerns). I store the /usr/bin/basename of
the Readme file into a variable which allows the script to
   generate a temporary readme file (/tmp/%PKG%.README)

   Then I do an [effective]:
   mv -f /tmp/%PKG%.README /usr/share/doc/Cygwin/%PKG%.README

   operation. I do NOT write the temp file in the /usr/share/doc/Cygwin/
directory since this will lead to a very subtle problem:
   The files listed would show two entries instead of one for the README,
e.g.,
  /usr/share/doc/Cygwin/%PKG%.README
  /usr/share/doc/Cygwin/%PKG%.README.tmp

which is not what we want.

For further [past] postings see items
http://cygwin.com/ml/cygwin/2003-11/msg01067.html and
http://cygwin.com/ml/cygwin/2003-11/msg00700.html

for details.

_
Alan Miles
ICQ#: 171006836
More ways to contact me: http://wwp.icq.com/171006836
_


packaging_templates.diff
Description: Binary data

Re: ImageMagick/Graphicsmagick

2003-12-21 Thread Igor Pechtchanski

(From the context I'm assuming I'm talking to John Cristy, but it would've
been nice if you'd signed your message).

John,

I hope I'm not starting a flame war here, but I feel I have to respond.
Cygwin is an all-volunteer effort, so anyone offering to maintain a
package does so *at his/her own convenience*.  This means, among other
things, that the package is easy to version, that future releases will not
involve a lot of pain to port to Cygwin, that Cygwin-related patches will
be accepted by the upstream maintainers, that they will not snub certain
Cygwin-specific concerns (e.g., directories named aux, filename case
issues, spaces in filenames, etc), that bugs that manifest only on Cygwin
will not be ignored, and so on.  Whether a package answers all those
criteria is up to the Cygwin maintainer to decide.  AFACS, Harold decided
that GraphicsMagics would be easier *for him* to maintain, and thus that
is what he offered to package.

FWIW, there is no reason why *both* ImageMagick and GraphicsMagick can't
be packaged for Cygwin (barring the obvious file clashes, but those should
be worked out amicably between maintainers), especially if you are willing
to become a Cygwin port maintainer and can demonstrate features that are
present in ImageMagick and lacking in GraphicsMagick (to get votes from
the community).

Also, see some specific replies below.

On Sun, 21 Dec 2003 fedoraatstudiodotimagemagickdotorg wrote:

 [snip]

  Are we not adults capable of making our own decisions?  Bob had nothing
  to do with this discussion and he has nothing to do with the fact that
  there is a problem with the way that ImageMagick is handling library
  version numbers.

 Bob chimed in on your mailing list and I was responding to that message.

No, Bob did not chime in.  He was specifically Cc'd on the list to ask
his opinion on how to best structure the ImageMagick packages given an
obvious (and already discovered by the time he was contacted) problem with
shared library naming.  Why he was contacted instead of you is on Chuck
Wilson's head -- my guess is because his name was sprinkled all over the
ImageMagick ChangeLog/CVS log relating to the build process.  He stated
(and Harold later confirmed, apparently) that GraphicsMagick does not have
this problem.  Also, you didn't seem to be responding to that message.
If you'd like to respond to the original e-mail with the build questions,
here's the reference: http://cygwin.com/ml/cygwin/2003-12/msg00235.html
(use the Raw text option to get a real mbox-formatted message except for
some header address munging).

  Hasn't been a problem for us so far.  If you want to prove us wrong,
  you'd better be prepared to submit some step-by-step examples of how to
  generate such cases and describe why the differing results are
  meaningful.  Assuming that you do that, why should we care?  We've only

 I could submit step-by-step examples but why waste my time since you do
 claim you do not care.

And he's right in not caring.  It's not his responsibility to provide the
best (in whoever's opinion) graphics manipulation package for Cygwin.
All Harold wants to do is build a package that fits his needs and share it
with the Cygwin community (or, perhaps, add a few extras, if they don't
take too much effort and he's feeling charitable).  If you feel that
another package would be of more benefit, feel free to propose to maintain
it by ITPing it on the cygwin-apps list.

  had the ImageMagick package for less than a month and, quite frankly, it
  is easier to maintain the GraphicsMagick package because the build files
  don't create empty directories that I have to go back and delete by
  hand, among other things.

 That's an excellant criteria for choosing a package for the entire CYGWIN
 community :-).

As I said above, Harold is only choosing a package for *himself*.  Nothing
stops you from maintaining a Cygwin port of ImageMagick.

  Nope.  I packaged ImageMagick, then I found GraphicsMagick and was
  convinced (by the code, not rhetoric) that it is superior for our
  purposes.  I will not continue to package ImageMagick; I will only
  continue to package GraphicsMagick.

 Again, you have not investigating the best solution here.  You have
 made up you mind based on just a few criteria and you are shoving it
 down everyones throat.

No, he's volunteering to support the package that he feels would provide
the most return for the least effort.  Anyone not happy with that can
provide their own favorite package.

 Given your strong statements and clear unwillingness to discuss which
 project is best based on merit, don't bother replying.

Apparently, there are different criteria of merit.

 I will not waste anymore of the CYGWIN community's time on a dead
 subject. I will tell the CYGWIN community that ImageMagick Studio
 intends to have full support of ImageMagick 5.5.7 and 5.5.8 Beta for
 CYGWIN and both source and binaries will be available on
 ftp://ftp.imagemagick.org/pub/ImageMagick.

Re: ImageMagick/Graphicsmagick

2003-12-21 Thread Nicholas Wourms

[EMAIL PROTECTED] wrote:

Again, you have not investigating the best solution here.  You have
made up you mind based on just a few criteria and you are shoving it
down everyones throat.  Given your strong statements and clear unwillingness
to discuss which project is best based on merit, don't bother replying.
I will not waste anymore of the CYGWIN community's time on a dead subject.
I will tell the CYGWIN community that ImageMagick Studio intends to 
have full support of ImageMagick 5.5.7 and 5.5.8 Beta for CYGWIN and both
source and binaries will be available on
ftp://ftp.imagemagick.org/pub/ImageMagick.


I'm sorry but I don't like the potential ramifications if this were to 
happen.  Not that I really have any say in the matter, I don't, but I 
feel that others out there share some of the concerns I will mention.

Harold, you've earned every right to make this decision as you see fit, 
and I respect that, but surely some sort of compromise can be reached 
which will satisfy both parties?  The original author seems willing to 
work with your complaints if you are willing to keep an open mind.

However, the original author should realize that Harold has some valid 
points concerning the libtool versioning you used as well as hardcoding 
the version minors into the module directory paths.  In effect, this 
means that we'd have to make a new runtime package each time the 
subminor was bumped PLUS keep the existing packages to maintain backward 
compatibility.

On the other hand, I've not looked at GraphicsMagick, do they use the 
same names for includes, include-dirs, modules, module-dirs,  
libraries?  If not, I can definitely see this as a PITA if you are 
building something which depends on the original names, since you'd have 
to tell it the new names and such.  However, if it does use the same 
names, then inevitably there are going to be many who get confused and 
unintentionally (or perhaps intentionally) install both versions of the 
this software.  When dll hell starts to set in, they probably aren't 
going to e-mail either of you personally, rather they are going to flood 
our already high-volume main list with false bug reports and what not. 
 Plus, what if I or anyone else decide to package something which 
depends on the ImageMagick libraries?  Then we'd have to tell people to 
make sure they uninstall the author's version to be able to use my 
package, even if they preferred the author's version.  You can see where 
I'm going with this and the picture isn't pretty.

Cheers,
Nicholas

Re: ImageMagick/Graphicsmagick

Nicholas,

Nicholas Wourms wrote:

[EMAIL PROTECTED] wrote:

Again, you have not investigating the best solution here.  You have
made up you mind based on just a few criteria and you are shoving it
down everyones throat.  Given your strong statements and clear 
unwillingness
to discuss which project is best based on merit, don't bother replying.
I will not waste anymore of the CYGWIN community's time on a dead 
subject.
I will tell the CYGWIN community that ImageMagick Studio intends to 
have full support of ImageMagick 5.5.7 and 5.5.8 Beta for CYGWIN and both
source and binaries will be available on
ftp://ftp.imagemagick.org/pub/ImageMagick.
Harold, you've earned every right to make this decision as you see fit, 
and I respect that, but surely some sort of compromise can be reached 
which will satisfy both parties?  The original author seems willing to 
work with your complaints if you are willing to keep an open mind.
No, I don't buy that.  Indicating to others that you are willing to work 
with them does not usually start by calling the points that they reached 
misconceptions.  No, John (or whomever fedora is) started with some 
other point in mind and has not so far offered any help to address the 
problems.  His attitude up to this point does not encourage me to bother 
to ask him for help.

However, the original author should realize that Harold has some valid 
points concerning the libtool versioning you used as well as hardcoding 
the version minors into the module directory paths.  In effect, this 
means that we'd have to make a new runtime package each time the 
subminor was bumped PLUS keep the existing packages to maintain backward 
compatibility.
Yes, those are some of the issues of concern.

On the other hand, I've not looked at GraphicsMagick, do they use the 
same names for includes, include-dirs, modules, module-dirs,  
libraries?  If not, I can definitely see this as a PITA if you are 
building something which depends on the original names, since you'd have 
to tell it the new names and such.  However, if it does use the same 
names, then inevitably there are going to be many who get confused and 
unintentionally (or perhaps intentionally) install both versions of the 
this software.  When dll hell starts to set in, they probably aren't 
going to e-mail either of you personally, rather they are going to flood 
our already high-volume main list with false bug reports and what not. 
 Plus, what if I or anyone else decide to package something which 
depends on the ImageMagick libraries?  Then we'd have to tell people to 
make sure they uninstall the author's version to be able to use my 
package, even if they preferred the author's version.  You can see where 
I'm going with this and the picture isn't pretty.
That really is the problem with offering ImageMagick at all: the 
directory structure, library names and version numbers (mind you, we are 
building shared libraries, not static libraries), and hard-coded 
directory paths in the executables are going to cause nightmares 
whenever a new version of ImageMagick is released.  Additionally, the 
version numbering scheme being used by ImageMagick is not going to make 
it easy to handle these problems; we would most likely have to 
re-version each release to get things to work together well.  As a note 
for those that missed the discussion: our aim is, as usual, to be able 
to continue to provide older versions of the shared libraries in 
addition to the newer versions so that applications linked against the 
older versions will continue to work; the problem that ImageMagick has 
here is that the ABI version and the ImageMagick version are 
inter-dependent since some files that the library requires are installed 
in a versioned directory; another problem that John (or whomever) may 
not be thinking about is that DLLs on Cygwin cannot be symlinked to to 
cause applications linked against older, but compatible, library 
versions to continue to work.  Windows does not know what a symlink is, 
so we cannot use that technique to keep older apps working.

We can very easily package one version of ImageMagick, but updates to 
that package are going to be horrible and are going to require a 
packaging structure so arcane that I will be almost unable to hand the 
package off to someone else should I get bored with it.  ImageMagick 
could make a lot of changes to their build system to accomodate us, but 
GraphicsMagick already had these changes when we discovered it.  I see 
no reason to work with the project leader of ImageMagick (who started 
his interaction with my by publicly berating me on a mailing list) to 
make changes to their build system when GraphicsMagick has already got 
those changes.

Harold

[Fwd: Mail delivery failed: returning message to sender]

Looks like our fine friend has decided to stick his head in the sand.

So much for Nicholas's theory that he had expressed a willingness to 
work with us.

Harold

=
 Original Message 
Subject: Mail delivery failed: returning message to sender
Date: Sun, 21 Dec 2003 16:26:04 -0500
From: Mail Delivery System [EMAIL PROTECTED]
To: me@
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
  fedora@
SMTP error from remote mailer after MAIL FROM:me@:
host studio.imagemagick.org [66.192.180.107]:
550 5.7.1 Access denied
=

Re: ImageMagick/Graphicsmagick

[Resending under original subject.]

Looks like our fine friend has decided to stick his head in the sand.

So much for Nicholas's theory that he had expressed a willingness to 
work with us.

Harold

=
 Original Message 
Subject: Mail delivery failed: returning message to sender
Date: Sun, 21 Dec 2003 16:26:04 -0500
From: Mail Delivery System [EMAIL PROTECTED]
To: me@
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
  fedora@
SMTP error from remote mailer after MAIL FROM:me@:
host studio.imagemagick.org [66.192.180.107]:
550 5.7.1 Access denied
=

Re: ImageMagick

John,

[EMAIL PROTECTED] wrote:

Now that I understand the Cygwin community a bit better, I propose a solution
that should satisfy everyone.  I am the original author and current primary
maintainer of ImageMagick.  I will spend some time ensuring ImageMagick
complies with the general Cygwin package requirements and then submit it
as a contributed package as detailed in http://cygwin.com/setup.html.
Any help/suggestions in how to properly package ImageMagick for Cygwin
is welcome.
That is fine with me.  Go to one of our mirror sites:

http://cygwin.com/mirrors.html

Then navigate to the following directory:

release/ImageMagick

Then grab the following file:

ImageMagick-5.5.7-1-src.tar.bz2

There is a script in that file that handles the packaging and building 
of ImageMagick for Cygwin... it should be called ImageMagick-5.5.7-1.sh. 
 The first thing you should do is bump it to ImageMagick-5.5.7-2.sh for 
your local test builds.  You should then run the script with the 
following options (one at a time): prep, conf, build, install, strip, 
pkg, spkg.  If all of those work, then you can look at the 'install' 
step in the build script and notice my little bit of magic to delete 
some empty folders in the install tree and (don't remember if this is 
there or not) to move some folders to other locations.  Ideally we would 
like not to have to do such manual steps in our platform-specific build 
script.

Then you can go back and look at the review of my package from Charles 
Wilson where he lays out the various upgrade scenarios that are going to 
cause us problems and see if you can propose either a platform-specific 
fix or if you can address the issues with generic updates to 
ImageMagick's build and versioning system.

If you address all of the concerns then I will hand over the package to 
you for maintainership, but I reserve the right to refuse to hand it 
over if we feel that any remaining problems are going to cause a large 
amount of mailing list volume whenever the package is updated.  Realize 
that our prime goal here is to minimize mailing list traffic of bug 
reports (especially false bug reports).

Harold

ImageMagick

Now that I understand the Cygwin community a bit better, I propose a solution
that should satisfy everyone.  I am the original author and current primary
maintainer of ImageMagick.  I will spend some time ensuring ImageMagick
complies with the general Cygwin package requirements and then submit it
as a contributed package as detailed in http://cygwin.com/setup.html.
Any help/suggestions in how to properly package ImageMagick for Cygwin
is welcome.

Thanks for your consideration.
John Cristy
http://www.imagemagick.org

Re: ImageMagick/Graphicsmagick

2003-12-21 Thread Charles Wilson

Igor Pechtchanski wrote:

No, Bob did not chime in.  He was specifically Cc'd on the list to ask
his opinion on how to best structure the ImageMagick packages given an
obvious (and already discovered by the time he was contacted) problem with
shared library naming.  Why he was contacted instead of you is on Chuck
Wilson's head -- my guess is because his name was sprinkled all over the
ImageMagick ChangeLog/CVS log relating to the build process. 
Two reasons:
  1) I'm the maintainer of libtool for cygwin.  Bob is one of the 
official upstream maintainers of libtool.  During summer 2002 and up 
thru November 2002, I was working with Bob on fixing some libtool issues 
-- and his test bed for these *libtool* changes was the ImageMagick 
codebase.  In retrospect, it seems that this was BEFORE GraphicMagick 
forked -- so I presume that at THAT time, Bob was a developer in good 
standing with the IM team.  I gather, tho, now that I've scanned the 
relevant mailing lists, that even then there was some discord developing.

  2) Some time later, Bob emailed ME privately asking about the 
procedures for contributing a package to cygwin -- something called 
GraphicsMagick that *I* believed was an addon to ImageMagick.  Bob 
specifically asked about do I need to also contribute prereqs.  The 
answer, of course, was Yes, all official packages may only depend on 
other official packages.  and I never heard anything on the subject again.
  I assumed that IM was a prereq for GM, and that Bob was unwilling to 
provide IM as a package, just to enable him to provide his add-on GM 
package.  I viewed this as a fairly sane decision since IM (and GM, of 
course, now that I've learned that it is a fork of IM) are each a 
gigantic beast of a package...

  So, when a question arose concerning IM, libtool, library versioning 
issues, and packaging it for cygwin -- of course I thought of Bob.  (Why 
would *I* take it upon myself to go ask the upstream IM maintainer 
something?  That would've been stomping all over Harold's turf!  But I 
*could* go ask *my* contact, with whom *I* had worked on IM 
previously...  I had no knowledge of the fork, or the dispute that 
caused it, at the time)

--Chuck

xwinclip and openoffice

2003-12-21 Thread Øyvind Harboe

Just a few more comments to my question:

If I do not start xwinclip, I can copy and paste e.g. formulas in OpenOffice, or 
tables from OpenOffice to an Evolution HTML email.

This is what is going on AFAICT:

xwinclip detects when my Linux box is updating its clipboard and then updates the 
windows clipboard.

At this point xwinclip updates the linux clipboard, since the windows clipboard 
changed. 

However, the linux-windows clipboard format translations are inheritly lossy, and 
hence
I want xwinclip to avoid them if it can.

yvind

Re: Java hello world link error

2003-12-21 Thread Jon A. Lambert

mauro zallocco wrote:
 
 with the following command:
 g++ Test.java
 

gcj --main=Test Test.java

See also: http://gcc.gnu.org/java/

--
J. Lambert


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Java hello world link error

2003-12-21 Thread Tim Prince

At 08:04 PM 12/20/2003, mauro zallocco wrote:

Folks,

I installed gcc-java on Windows XP, and am attempting to compile:

class Test {
  public static void main(String argv[]) {
  System.out.println(Hello World);
  }
}
with the following command:
g++ Test.java
This produces a gazillion link errors, a sample follows:
/cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+0x2d):Test.java
: undefined reference to `__Jv_InitClass'
/cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+0x37):Test.java
: undefined reference to `java::lang::System::out'
/cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+0x5f):Test.java
: undefined reference to `java::lang::Object::Object[in-charge]()'
/cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+0xc8):Test.java
: undefined reference to `__Jv_RegisterClass'

Why not start out by linking it as a java program, with gcj, rather than as 
C++ ?

Tim Prince 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Java hello world link error

2003-12-21 Thread mauro zallocco

Thank you for the suggestion.
Here is what I get.

$ gcj Test.java
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld:
cannot
find -liconv
collect2: ld returned 1 exit status

Mauro

 -Original Message-
 From: Tim Prince [mailto:[EMAIL PROTECTED]
 Sent: Sunday, December 21, 2003 10:39 AM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: Re: Java hello world link error


 At 08:04 PM 12/20/2003, mauro zallocco wrote:

 Folks,
 
 I installed gcc-java on Windows XP, and am attempting to compile:
 
 class Test {
public static void main(String argv[]) {
System.out.println(Hello World);
}
 }
 
 with the following command:
 g++ Test.java
 
 This produces a gazillion link errors, a sample follows:
 /cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+
 0x2d):Test.java
 : undefined reference to `__Jv_InitClass'
 /cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+
 0x37):Test.java
 : undefined reference to `java::lang::System::out'
 /cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+
 0x5f):Test.java
 : undefined reference to `java::lang::Object::Object[in-charge]()'
 /cygdrive/c/DOCUME~1/mzallocc/LOCALS~1/Temp/ccywNFar.o(.text+
 0xc8):Test.java
 : undefined reference to `__Jv_RegisterClass'
 
 

 Why not start out by linking it as a java program, with gcj,
 rather than as
 C++ ?

 Tim Prince



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Java hello world link error

2003-12-21 Thread Jon A. Lambert

mauro zallocco wrote:
 $ gcj Test.java
 /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld:
 cannot
 find -liconv
 collect2: ld returned 1 exit status
 

You probably need to install one or both of these:

$ cygcheck -c | grep iconv
libiconv1.9.1-3OK
libiconv2   1.9.1-3OK


--
J. Lambert


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

ImageMagick/Graphicsmagick

As the lead developer of ImageMagick I would like to clear up a few
misconceptions being stated on this list.

  1. Harold L Hunt II says: This package [GraphicsMagick] will replace
 ImageMagick for various reasons. One of those reasons is that the
 GM folks are committed to provide ABI stability and proper version
 numbers, whereas IM is not making such a commitment and has already
 made various arbitrary changes to ABI version numbers.

 This is something Bob Friensenhahn is trying to convince people of
 but it is simply not true.  http://studio.imagemagick.org/ states
 our project goal of: ImageMagick's focus is on performance,
 minimizing bugs, and providing stable APIs and ABIs.  Bob Friensenhahn
 does not speak for ImageMagick.  He tends to diminish ImageMagick in
 various mailing lists I assume in order to promote his ImageMagick
 clone project, GraphicsMagick.

  2. Daniel Reed says: GaphicsMagick is a feature-for-feature
 replacement of ImageMagick.  This is simply not true.  GraphicsMagick
 is missing many features that ImageMagick has and if you run
 a program or script against the two you will in many cases get
 different results.

  3. Daniel Reed says: I considered ImageMagick's to be votes for
 GraphicsMagick.  Why vote at all if you are going to usurp the votes?
 A vote for ImageMagick should remain with ImageMagick.  If you want
 votes for GraphicsMagick have a separate vote.

If you choose to support GraphicsMagick instead of ImageMagick, fine.  However,
base your decision on facts, not misconceptions.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: docbook-xsl-1.64.1-1

2003-12-21 Thread Marcel Telka

I've updated the docbook-xsl package to version 1.64.1-1.

docbook-xsl package contains XSL stylesheets for the DocBook XML DTD 
created by Norman Walsh and others.

Changes since 1.62.4-1:
- Updated to mainstream 1.64.1
- Added 'extensions' directory

To update your installation, click on the Install Cygwin now link on 
the http://cygwin.com/ web page. This downloads setup.exe to your 
system. Then, run setup and answer all of the questions.

If you have questions or comments, please send them to the Cygwin 
mailing list at: cygwin at cygwin dot com. I would appreciate it if you 
would use this mailing list rather than emailing me directly.

-- 
+---+
| Marcel Telka   e-mail:   [EMAIL PROTECTED]  |
|homepage: http://telka.sk/ |
|jabber:   [EMAIL PROTECTED] |
+---+


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: List responces (Was: Re: Third-party products that include Cygwin)

At 12:31 AM 12/20/2003, Rolf Campbell you wrote:
Larry Hall wrote:
At 05:24 PM 12/13/2003, Hannu E K Nevalainen you wrote:
PLEASE NOTE:
** on a mailing list; please keep replies on that particular list **
I'm a little confused by the intent of your note above.  If this is directed at 
me, I replied to your message the way I always reply, with
reply all.  That goes to the list.  It also goes to you directly, since
you don't set your reply-to header.  If you prefer to get just one copy of any reply 
(i.e. the one that goes to the list), set your reply-to
header to point to the list.  My email client will obey your stated preference 
automatically.  Of course, if you were directing this comment
at someone else, then you can ignore the above.
You have made an assumption that everyone accesses this list the same way you do.  
For those of us that use the nntp gateway, we cannot set our reply-to field to be the 
list.


Good point.  My apologies.  I guess if your method of access doesn't 
support reply-to, you're stuck with the status quo unless you decide 
to use Chris's new reply-to only list.  You (and anyone else that has
this problem) might want to check it out.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cron problem after using hibernate

At 03:25 PM 12/20/2003, David Bath you wrote:
I have been running cron for over a year now without any problems until recently. 
Typically I leave my PC running XP on all day and then hibernate it very late in the 
evening, turning it back on each morning. Cron would run without fail executing as 
expected until sometime after 11/21. Around that time I used setup to update all out 
of date programs, and 2 that updated were cygrunsrv and cron. After that update, cron 
no longer performs anything in my crontab once the PC has been hibernated and then 
turned back on. Rebooting or restrting cron by executing cygrunsrv -E cron then 
cygrunsrv -S cron fixes the problem everytime. The ps output always shows cron even 
when cron doesn't work.

I've tried reverting to older cron and cygrunsrv in all combinations and none of it 
fixed the problem. I've looked over the problem reports and saw nothing there either. 
I've run the most recent cron_check.sh and it reports no problems.

I've attached the cygcheck output, but not my crontab since it works correctly after 
the cron restarts so I doubt it's the problem.


Do you google?

http://www.cygwin.com/ml/cygwin/2003-10/msg00978.html

For future reference, this list prefers that you *attach* the output of 
cygcheck rather than including it in the context of the email message. 
Attaching helps limit 'false positive' hits when searching the archives.
TIA for you help in this matter.


--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cron problem after using hibernate

2003-12-21 Thread Igor Pechtchanski

On Sun, 21 Dec 2003, Larry Hall wrote:

 At 03:25 PM 12/20/2003, David Bath you wrote:
 [snip]
 I've attached the cygcheck output, but not my crontab since it works
 correctly after the cron restarts so I doubt it's the problem.

 Do you google?

 http://www.cygwin.com/ml/cygwin/2003-10/msg00978.html

 For future reference, this list prefers that you *attach* the output of
 cygcheck rather than including it in the context of the email message.
 Attaching helps limit 'false positive' hits when searching the archives.
 TIA for you help in this matter.
 --
 Larry Hall

Larry, the cygcheck output *was* attached -- look at the Raw text.
Guess someone needs to tweak the archive scripts (I'd take a look if I
knew where they were).

Line wrapping would have been nice, though.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster.  -- Patrick Naughton

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cron problem after using hibernate

2003-12-21 Thread David Bath

Larry Hall wrote:
At 03:25 PM 12/20/2003, David Bath you wrote:

I have been running cron for over a year now without any problems until recently. Typically I leave my PC running XP on all day and then hibernate it very late in the evening, turning it back on each morning. Cron would run without fail executing as expected until sometime after 11/21. Around that time I used setup to update all out of date programs, and 2 that updated were cygrunsrv and cron. After that update, cron no longer performs anything in my crontab once the PC has been hibernated and then turned back on. Rebooting or restrting cron by executing cygrunsrv -E cron then cygrunsrv -S cron fixes the problem everytime. The ps output always shows cron even when cron doesn't work.

I've tried reverting to older cron and cygrunsrv in all combinations and none of it fixed the problem. I've looked over the problem reports and saw nothing there either. I've run the most recent cron_check.sh and it reports no problems.

I've attached the cygcheck output, but not my crontab since it works correctly after the cron restarts so I doubt it's the problem.

Do you google?

http://www.cygwin.com/ml/cygwin/2003-10/msg00978.html
Could be my problem, but as I mentioned it had worked flawlessly for at
least a year even with daily hibernation until just very recently, so
I'd be surprised if that is the cause of my problem. But on the other
hand, being an experienced software engineer I know stranger things do
happen, so you never know.

For future reference, this list prefers that you *attach* the output of
cygcheck rather than including it in the context of the email message.
Attaching helps limit 'false positive' hits when searching the archives.
TIA for you help in this matter.
I did attach it as I have been a long time reader of this list and knew
of this recommendation. It does show as an attachment in the digest I
received this morning. TIA yourself Larry.

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

Re: Cron problem after using hibernate

At 03:31 PM 12/21/2003, Igor Pechtchanski you wrote:
On Sun, 21 Dec 2003, Larry Hall wrote:

 At 03:25 PM 12/20/2003, David Bath you wrote:
 [snip]
 I've attached the cygcheck output, but not my crontab since it works
 correctly after the cron restarts so I doubt it's the problem.

 Do you google?

 http://www.cygwin.com/ml/cygwin/2003-10/msg00978.html

 For future reference, this list prefers that you *attach* the output of
 cygcheck rather than including it in the context of the email message.
 Attaching helps limit 'false positive' hits when searching the archives.
 TIA for you help in this matter.
 --
 Larry Hall

Larry, the cygcheck output *was* attached -- look at the Raw text.


OK.


Guess someone needs to tweak the archive scripts 


I guess so...



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cron problem after using hibernate

At 03:46 PM 12/21/2003, David Bath you wrote:
Larry Hall wrote:
At 03:25 PM 12/20/2003, David Bath you wrote:

I have been running cron for over a year now without any problems until recently. 
Typically I leave my PC running XP on all day and then hibernate it very late in 
the evening, turning it back on each morning. Cron would run without fail executing 
as expected until sometime after 11/21. Around that time I used setup to update all 
out of date programs, and 2 that updated were cygrunsrv and cron. After that 
update, cron no longer performs anything in my crontab once the PC has been 
hibernated and then turned back on. Rebooting or restrting cron by executing 
cygrunsrv -E cron then cygrunsrv -S cron fixes the problem everytime. The ps 
output always shows cron even when cron doesn't work.

I've tried reverting to older cron and cygrunsrv in all combinations and none of it 
fixed the problem. I've looked over the problem reports and saw nothing there 
either. I've run the most recent cron_check.sh and it reports no problems.

I've attached the cygcheck output, but not my crontab since it works correctly 
after the cron restarts so I doubt it's the problem.

Do you google?
http://www.cygwin.com/ml/cygwin/2003-10/msg00978.html

Could be my problem, but as I mentioned it had worked flawlessly for at least a year 
even with daily hibernation until just very recently, so I'd be surprised if that is 
the cause of my problem. But on the other hand, being an experienced software 
engineer I know stranger things do happen, so you never know.


Well, that seems to be the latest wisdom on this issue, unless someone 
else pipes up with some more specific debugging that would suggest otherwise.
Of course, that doesn't mean there isn't a solution.  But this post would
suggest that the problem isn't Cygwin-specific.


For future reference, this list prefers that you *attach* the output of cygcheck 
rather than including it in the context of the email message. Attaching helps limit 
'false positive' hits when searching the archives.
TIA for you help in this matter.

I did attach it as I have been a long time reader of this list and knew of this 
recommendation. It does show as an attachment in the digest I received this morning. 
TIA yourself Larry.


You're welcome.  It doesn't show up as an attachment for me (that's fine)
or the email archives (which I checked before commenting).  Guess that's
an issue for the archives, as Igor pointed out.



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

ImageMagick