Re: Delete wrong ImageMagick/GraphicsMagick-1.3.14-1-src.tar.bz2 ?
On Jul 15 21:02, Reini Urban wrote: There is a GraphicsMagick-1.3.14-1-src.tar.bz2 in release/ImageMagick which can IMHO be deleted. I just had a look and it seems to be deleted already. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Delete wrong ImageMagick/GraphicsMagick-1.3.14-1-src.tar.bz2 ?
There is a GraphicsMagick-1.3.14-1-src.tar.bz2 in release/ImageMagick which can IMHO be deleted. Can I? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
SECURITY: ImageMagick, GraphicsMagick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yaakov S (Cygwin Ports) wrote: ImageMagick contains several format string vulnerabilities, which may allow an attacker to execute arbitrary code. Solution: update to 6.2.5.5 or 6.2.6 (our current is 6.0.4-1 !!!) More information: http://www.gentoo.org/security/en/glsa/glsa-200602-06.xml http://www.gentoo.org/security/en/glsa/glsa-200503-11.xml First, ping. Second, I just knew this was going to happen... GraphicsMagick is also similarly affected. Solution: upgrade to 1.1.7. More information: http://security.gentoo.org/glsa/glsa-200602-13.xml Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEBNh+piWmPGlmQSMRAvwiAKDfqWRK3i9ca7VPCe8Sd6J0Iw/z/gCg6UGQ msCPNAz11VIWlD0WFabS+CA= =WtIw -END PGP SIGNATURE-
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.
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.
Re: ImageMagick/Graphicsmagick
(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
[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
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/Graphicsmagick
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
