The Inkscape 0.42 release is complete, and packages are now available: https://sourceforge.net/project/showfiles.php?group_id=93438 Lots of new features and fixes since 0.41. :-) Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: Upgrade portage to supply inkscape 0.42 If there are any problems with this release, please report them here and/or at the Inkscape bug tracker. FYI, we are shooting for getting 0.43 out within a month or two.
Created attachment 64402 [details] inkscape-0.42.ebuild Ebuild attached. Tested on amd64 with no problems.
Tested on x86 (P4 Xeon's) and works great!
Some additional optional requirements to get the python scripting to work too - found this in the Gentoo forum posted by Matteo Azzali: <<<<<<<<<<<<<<<<<<<<< Quoted from Forum >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just to warn in advance. Compile (emerge) inkscape 0.42 will not require them, but they'll be required to run inkscape scripts (very good new feature) so there'll be need for libxml-xql-perl (requiring perl) and python-xml (requiring python). http://packages.debian.org/unstable/source/libxml-xql-perl http://pyxml.sourceforge.net/ Since these packages aren't in portage at the moment, I just wanted to warn (if someone post a link to a "howto create ebuilds" tutorial I can also try to write down....) bit more docs: http://www.inkscape.org/cgi-bin/wiki.pl?GettingExtensionsWorking http://www.inkscape.org/cgi-bin/wiki.pl?GettingEffectsWorking P.S.:Since scripting will need big dependancies and is not compile-needed, maybe a specific use flag will be useful too. <<<<<<<<<<<<<<<<<<<<< End Quote >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thought some of you might find that interesting - looking forward to testing the ebuild.
I added an ebuild for XML-XQL as per the comment above, pyxml is already in portage. I modified to ebuild to reflect this.
Created attachment 64408 [details] inkscape-0.42.ebuild
Would it be possible to break-up the operation of the plugin USE flag into, perhaps, plugin and scripting? This would allow installation of the scripting dependencies separately from the other plugin elements. I personally would make use of the Perl and Python scripting features but have no need for Dia, skencil etc. Regards, Neil Darlow
*** Bug 100505 has been marked as a duplicate of this bug. ***
Good idea to break up the USE flag, we expect to see growth in the use of scripting over the next few releases, and the Gentoo package needs a smarter way of handling this, so that if someone doesn't need every extension available, they don't have to install a huge amount of secondary packages. Bryce
Please re-attach the ebuild as text/plain.
(In reply to comment #9) > Please re-attach the ebuild as text/plain. My bad. Sorry for the spam :/
Created attachment 64521 [details] inkscape-0.42.ebuild inkscape 0.42 ebuild. New USE flag 'scripting', with conditions on 'perl' and 'python' scripting? ( python? ( dev-python/pyxml ) perl? ( dev-perl/XML-XQL ) )
Are the changes you made to separate the plugins from the scripting actually going to change the way that Inkscape is built? For example, lets say that I already have pyxml installed, but don't want scripting support to be available in Inkscape. Will setting USE="-scripting" actually *force* Inkscape to be built without scripting even if pyxml is available? You may also want to consider reassigning the bug to zypher@gentoo.org since he is the specific maintainer for this package (as per package metadata).
I should explain something regarding "effects" and "scripting", as I just realized it could lead to some confusion from a packaging standpoint. From a packaging perspective, effects (also sometimes called extensions) and scripting are two completely different, unrelated things. Effects are (generally) external programs that are exec'd by Inkscape and could be written in any language, including Python, Perl, Java, C/C++, etc. etc. They are handed some portion of the SVG document (usually the current selection), allowed to make whatever alternations they desire, and then return the changed SVG to Inkscape. Effects are a relatively new feature but already a number of extensions have been contributed and are available in the program. Separate from this, Inkscape also has scripting support. This literally means that a Python interpreter and a Perl interpreter can be compiled into the application. This allows you to type in scripts into a dialog in Inkscape and have them be interpreted and (in theory) operate on the document directly. However, this is still a very early-in-development feature and is not very widely used except for development/experimentation purposes. Anyway, I just wanted to clarify this in case people noticed the --with-perl and --with-python options in the configure script; those flags are for the script interpreters, not for the Effects mechanism. Also, in this thread where people (including myself) have spoken about 'scripting', we really were (mostly) talking about the 'Effects' feature. Also, I think it may be worth naming the USE flag 'effects' rather than 'scripting', to avoid future confusion. Possibly the scripting features can be turned on/off via the normal gentoo 'perl' and 'python' USE flags?
how about this solution: * 'perl' and 'python' use flag enabling python and perl support at compile time * 'effects' use flag, who implies a dependency on pyxml (if python use flag is enabled) and/or on XML-XQL (if perl flag is enabled) This means simply renaming the 'scripting' flag in my ebuild.
works great on my pentium 4 system :)
That sounds good, however it's not necessary to make the effects conditional on the perl or python scripting, since those things are completely orthogonal. I.e., the effects will work regardless of whether you specify --with-perl or --with-python for compile. Thus I think you can simplify to this: * 'perl' and 'python' use flag enabling internal python and perl support at compile time * 'effects' use flag, who implies a dependency on pyxml and on XML-XQL
Works fine on my ancient Athlon machine (CFLAGS="-march=athlon -O2 -pipe").
Created attachment 64646 [details] inkscape-0.42.ebuild changes to reflect comment 16
Btw, why don't you use the ebuild function 'use_enable' for the 'mmx' flag, or 'use_with' for the 'bonobo', 'inkjar', 'gnome', ... flags like you did for the 'spell' flag? This would allow to keep the ebuild unmodified even if the inkscape people change the default autoconf setting for one of these options.
Commited to portage ebuild from Comment #18. Thanks for help.
As 0.42 has several major bugs (such as line width not working), this bug #100386 should be reopened (or marked upstream?), the ebuild should rather not got into portage until 0.42.1 is out. An announcement for this has already been made on www.inkscape.org
btw, the whole src_unpack() section of the ebuild is now useless and should be removed from the final ebuild
Created attachment 64969 [details] Cleaner inkscape-0.42.ebuild Here is a cleaner ebuild. It uses use_with and use_enable, removes the src_unpack function, and also moved the G2CONF line into the src_compile function so it isn't processed every time the ebuild is.
Created attachment 64970 [details] Fixed clean inkscape-0.42.ebuild Whoops, use the gnome2.eclass config function.
(In reply to comment #23) > Created an attachment (id=64969) [edit] > Cleaner inkscape-0.42.ebuild > > Here is a cleaner ebuild. It uses use_with and use_enable, removes the > src_unpack function, and also moved the G2CONF line into the src_compile > function so it isn't processed every time the ebuild is. Very nice. You beat me to it. But I was just going to wait for 0.42.1.
