I needed to render a png to SVG and thought I'd use graphicsmagick, which has USE=svg enabled. As it turns out this does nothing since the SVG coder has been disabled by default since ~2009; it's hidden behind a magic #define. Enabling this magic #define results in a built SVG coder that indeed does not work, as advertised. :{ The USE flag should be removed. Reproducible: Always Steps to Reproduce: 1. build graphicsmagick with USE=svg 2. no SVG functionality 3. sadness I'll cook up a PR to remove the svg USE flag.
To avoid any potential confusion: by default the SVG *writer* is not built; however the libxml-based SVG reader _is_. Unfortunately this is also basically useless due to missing features. Since removing the svg flag turned out to be more difficult than expected due to dependent packages and flag propagation in the imagemagick-tools virtual, I would like to suggest that we add at least a conditional warning that SVG support is broken (when enabled). Would that be acceptable?
(In reply to Holger Hoffstätte from comment #1) > Since removing the svg flag turned out to be more difficult than expected > due to dependent packages and flag propagation in the imagemagick-tools > virtual, I would like to suggest that we add at least a conditional warning > that SVG support is broken (when enabled). I'm not sure what's wrong with the svg(-)? suggestion I made before?
(In reply to Sam James from comment #2) > (In reply to Holger Hoffstätte from comment #1) > > Since removing the svg flag turned out to be more difficult than expected > > due to dependent packages and flag propagation in the imagemagick-tools > > virtual, I would like to suggest that we add at least a conditional warning > > that SVG support is broken (when enabled). > > I'm not sure what's wrong with the svg(-)? suggestion I made before? Nothing wrong with it, as far as I can tell it would work but make things more weird/inconsistent overall. I just don't want to remove the flag and create churn (and possible more bugs) because strictly speaking the capability required by the virtual is there.
(In reply to Holger Hoffstätte from comment #3) > (In reply to Sam James from comment #2) > > (In reply to Holger Hoffstätte from comment #1) > > > Since removing the svg flag turned out to be more difficult than expected > > > due to dependent packages and flag propagation in the imagemagick-tools > > > virtual, I would like to suggest that we add at least a conditional warning > > > that SVG support is broken (when enabled). > > > > I'm not sure what's wrong with the svg(-)? suggestion I made before? > > Nothing wrong with it, as far as I can tell it would work but make things > more weird/inconsistent overall. I just don't want to remove the flag and > create churn (and possible more bugs) because strictly speaking the > capability required by the virtual is there. But that's not what would happen -- it's the opposite? Right now, it looks like the functionality is there, but it isn't. By dropping USE=svg properly and adjusting the virtual, anything which demands USE=svg from the virtual will no longer be wrongly satisfied by gm. What am I missing?
(In reply to Sam James from comment #4) > Right now, it looks like the functionality is there, but it isn't. By > dropping USE=svg properly and adjusting the virtual, anything which demands > USE=svg from the virtual will no longer be wrongly satisfied by gm. What am > I missing? You're not missing anything, I'm trying to figure out the best way forward and minimize collateral damage, nothing else. If you agree that removing the flag from GM and relaxing the constraint in the virtual are the right way forward then I can do that (once the jpeg2k stuff is resolved). This has been broken since 2009 so I don't think it's urgent anyway, but all this is just frustrating. I've tried IM and it's vastly slower, and vips is not a useable replacement either.
Please, remove this darn 'USE=svg'. I spent 2 hours figuring out why gm wasn't working :-/
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5ec4bb122b1fde6be6849464cc34178514c90bd commit a5ec4bb122b1fde6be6849464cc34178514c90bd Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2024-05-19 12:24:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-05-19 17:01:35 +0000 media-gfx/graphicsmagick: remove nonfunctional USE=svg The SVG coder was disabled in 2009; see ChangeLog.2009#565 Closes: https://bugs.gentoo.org/921532 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Sam James <sam@gentoo.org> media-gfx/graphicsmagick/graphicsmagick-1.3.43-r1.ebuild | 4 +--- media-gfx/graphicsmagick/graphicsmagick-9999.ebuild | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af40c92d01c669f2574bcfe40e326ba13c5e1454 commit af40c92d01c669f2574bcfe40e326ba13c5e1454 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2024-05-19 12:26:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-05-19 17:01:34 +0000 virtual/imagemagick-tools: relax svg requirement for graphicsmagick Bug: https://bugs.gentoo.org/921532 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Signed-off-by: Sam James <sam@gentoo.org> .../imagemagick-tools/imagemagick-tools-0-r2.ebuild | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
I don't think the "svg(-)" in virtual/imagemagick-tools is what we wanted? That dep is forcing me to downgrade to the stable graphicsmagick and enable USE=svg for it.
Hm, good point. I think the dep expression is right - there's no alternative other than forking with a svg? ( ... ), !svg? ( ... ), I think, but I suspect this is Portage trying to be helpful given it sees an older version of GM with the flag, and that it'll go away when newer GM is stabled?
(+ cleaned up)
I'm not in a position to test right now, but I think the svg(-) dep will actually prevent the use of graphicsmagick to satisfy the virtual when the stable versions with IUSE=svg are removed from the tree. At that point, graphicsmagick[svg(-)] will be unsatisfiable, meaning that only imagemagick can be used. I haven't thought very hard about this, but it seems to me that if you set USE=svg for the virtual, then only imagemagick should satisfy it, because graphicsmagick doesn't do SVG. OTOH if you leave USE=svg unset for the virtual, then either imagemagick or graphicsmagick should be acceptable regardless of whether they have USE=svg set themselves.
I think you're right.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af22ddb2c61f30b103776b09f2ce7e1d5ecadb87 commit af22ddb2c61f30b103776b09f2ce7e1d5ecadb87 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-08 17:13:39 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-08 17:14:59 +0000 virtual/imagemagick-tools: add 1, drop 0-r3 I gave Holger bad advice when we were discussing af40c92d01c669f2574bcfe40e326ba13c5e1454. mjo rightly points out on the bug that svg(-) will make Portage cling to older graphicsmagick which had a (noop) USE=svg. Let's drop it entirely and do the ugly branching in RDEPEND with "svg? ( ... ) !svg? ( ...)". Bug: https://bugs.gentoo.org/921532 Fixes: af40c92d01c669f2574bcfe40e326ba13c5e1454 Signed-off-by: Sam James <sam@gentoo.org> ...ick-tools-0-r3.ebuild => imagemagick-tools-1.ebuild} | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
I see that we have: kde-apps/kwave/kwave-24.05.0.ebuild:66: virtual/imagemagick-tools[png,svg] kde-apps/kwave/kwave-24.02.2.ebuild:66: virtual/imagemagick-tools[png,svg] app-admin/usbview/usbview-3.1.ebuild:22: virtual/imagemagick-tools[png,svg] app-admin/usbview/usbview-3.0.ebuild:23: virtual/imagemagick-tools[png,svg] dev-python/sphinx/sphinx-7.3.7-r2.ebuild:68: virtual/imagemagick-tools[jpeg,png,svg] dev-python/sphinx/sphinx-7.2.6.ebuild:66: virtual/imagemagick-tools[jpeg,png,svg] I wonder if any of those can be loosened...
Thanks, the new version may be ugly but I think it's correct. (In reply to Sam James from comment #14) > dev-python/sphinx/sphinx-7.3.7-r2.ebuild:68: > virtual/imagemagick-tools[jpeg,png,svg] > dev-python/sphinx/sphinx-7.2.6.ebuild:66: > virtual/imagemagick-tools[jpeg,png,svg] > > I wonder if any of those can be loosened... For sphinx at least, that dep is behind USE=test.
