Re: [Inkscape-user] [Inkscape-devel] Inkscape 0.47pre2
On 31/08/2009, at 6:11 PM, Alexandre Prokoudine wrote:
Is anyone doing a Mac/native GTK+ build for pre2?
Sorry for pushing, but it's a week since pre2 was released and all we have is sources :(
I'm working on a universal package that will run on Leopard and Snow Leopard.
I don't think it is worth creating another gtk-native-mac build, unless anyone wants to start actively working on the things I mentioned about the one I made for pre0 -- the gtk-native-mac version is going to require a fair amount of attention before it can become the main supported one over the x11-based version.
Work on the universal x11-based package for Mac is a little slow... partly because I am quite busy with work, and partly because of the added complication of testing an additional version of the operating system (Snow Leopard 10.6).
Anyway, Mac builds are coming and haven't been forgotten. If anyone else with mac packaging experience wants to contribute to the effort, it would be useful to look at some of the outstanding issues I haven't got to yet, like the dictionary bundling or the DBUS bundling/startup (might be similar to what GIMP has). If so, let me know.
Cheers, Michael
On Tue, 2009-09-01 at 10:15 +1000, Michael Wybrow wrote:
I'm working on a universal package that will run on Leopard and Snow Leopard.
Also... is there anyone out there who can look into doing a build of 0.46 for Snow Leopard?
At the moment it seems to be broken. However, if we can get the older 0.46 working on Snow Leopard, then we can one-up some of the current commercial companies who have declared no ongoing support for older versions of the software.
Of course, I'm not suggesting we take away from getting 0.47 out. It is just that we have a nice window of opportunity to show why Open Source in general can be better than proprietary.
On 1/9/09 02:15, Michael Wybrow wrote:
Anyway, Mac builds are coming and haven't been forgotten. If anyone else with mac packaging experience wants to contribute to the effort, it would be useful to look at some of the outstanding issues I haven't got to yet, like the dictionary bundling or the DBUS bundling/startup (might be similar to what GIMP has). If so, let me know.
1) I have had a look at the spell check dictionary issue, but got stuck when it seemed to fail in an area outside of my abilities (C++ code reading $ASPELL_CONF to get the list of available spell check dictionaries for the 'Spell Check' page in the preferences dialog)
Bug #396322 in Inkscape: “Spell checker crashes the OS X package”: https://bugs.edge.launchpad.net/inkscape/+bug/396322
2) GIMP on OS X: dbus-binaries are included in the application bundle and called by the launcher script before exec'ing gimp-bin
launcher scripts in the app-skeleton: http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/Gimp-app-template/Contents/Resources/bin/gimp?revision=6&view=markup http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/Gimp-app-template/Contents/Resources/bin/gimp-remote?revision=6&view=markup
MacPorts configuration and portfiles+patches for gimponosx: http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/GimpPorts/
Script files for building & bundling http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/scripts/
I do not have a lot of MacPorts experience and haven't built GIMP myself, but it seems important to note that GIMP on OS X (Gimp.app) only builds with a separate MacPorts tree, as the application being relocatable depends not on DYLD_LIBRARY_PATH for the included shared libs but on the MacPorts prefix pointing to a symbolic link in /tmp, which must exist at build and (recreated every time) at run time.
D-Bus would be nice to have but IMHO it is not a blocker for 0.47 as the D-Bus API for Inkscape still lives in a separate branch - or are there plans to include it in 0.47 already?
3) Did you have a look at the proposed fixes for the ImageMagick raster effects? https://bugs.edge.launchpad.net/inkscape/+bug/390024
I cannot offer to contribute more due to lack of mac packaging experience - anything else that could be helpful besides trying to triage new / unconfirmed osx bugs on launchpad?
hth, ~suv
On 01/09/2009, at 10:15 AM, Michael Wybrow wrote:
On 31/08/2009, at 6:11 PM, Alexandre Prokoudine wrote:
Sorry for pushing, but it's a week since pre2 was released and all we have is sources :(
Anyway, Mac builds are coming and haven't been forgotten. If anyone else with mac packaging experience wants to contribute to the effort, it would be useful to look at some of the outstanding issues I haven't got to yet, like the dictionary bundling or the DBUS bundling/startup (might be similar to what GIMP has). If so, let me know.
I've put up a Mac Inkscape-0.47pre2-1.LEOPARD.dmg package. I wasn't able to add it to the existing 0.47pre2 directory on SourceForge (same problem the Windows packager had) because there were no group write permissions on that directory. Hence I renamed that directory to "UnwritableDir" and made a new 0.47pre2 directory and copied all the 0.47pre2 files there. Can someone remove the UnwritableDir directory? Also, can whoever creates such release folders in future please check that they are writable by other inkscape packagers?
I'll test this package on Snow Leopard tonight, but it should hopefully work given I tried some earlier private builds.
For any of the Mac packagers (not important for users themselves), this build includes the ImageMagick components that were previously missing, thanks ~suv. Note: the ImageMagick components will fail if the user has a version installed in the same prefix that the packager used when building the bundle -- this is a good reason to use an obscure long Macports prefix if you're packaging (see next paragraph). This is because you can tell ImageMagick where to look for its components but it still checks it's install directory and uses them anyway if they exist.
Also, it the package no longer uses the DYLD_LIBRARY_PATH environment variable to specify where the libraries can be found. Instead they all have their internal paths rewritten at packaging time to be relative to the path of the executable. To allow enough space in the libraries and executables for this path rewriting, the packager must use a Macports installation that has been installed in a longer than normal PREFIX. I don't know what the minimum size is, but I've put a requirement in the packaging script to check that it is at least 50 characters. Thus it needs to be installed in something like /opt/ local-universal-macports-in-really-long-prefix-for-inkscape-etc-etc... you get the idea. This should solve a lot of problems with our bundled libraries conflicting with system versions.
I haven't yet looked at the aspell issue.
Let me know of any new issues.
Cheers, Michael
:) Thank you for this effort! 0.47pre2-1 works without issues on OS X 10.5.8 with XQuartz 2.4.0 in preliminary tests.
On 8/9/09 06:38, Michael Wybrow wrote:
Also, it the package no longer uses the DYLD_LIBRARY_PATH environment variable to specify where the libraries can be found. Instead they all have their internal paths rewritten at packaging time to be relative to the path of the executable. To allow enough space in the libraries and executables for this path rewriting, the packager must use a Macports installation that has been installed in a longer than normal PREFIX. I don't know what the minimum size is, but I've put a requirement in the packaging script to check that it is at least 50 characters. Thus it needs to be installed in something like /opt/ local-universal-macports-in-really-long-prefix-for-inkscape-etc-etc... you get the idea. This should solve a lot of problems with our bundled libraries conflicting with system versions.
i.e. unless I modify the limit in osx-app.sh locally, I have to rebuild the complete MacPorts tree for Inkscape if I 'svn update' to the current version of the packaging files in trunk?
Let me know of any new issues.
Did you notice that the bundled python site-packages for 2.6 are not universal but i386 arch only whereas the older ones are all universal builds? Could this be a reason why python extensions fail on SL but work for those who copied the 0.46 python folder into 0.47pre1-2 (0.46 has no 2.6 versions - could be that this forces fallback to python 2.5?)
~suv
On 8/9/09 09:24, ~suv wrote:
On 8/9/09 06:38, Michael Wybrow wrote:
Also, it the package no longer uses the DYLD_LIBRARY_PATH environment variable to specify where the libraries can be found. Instead they all have their internal paths rewritten at packaging time to be relative to the path of the executable. To allow enough space in the libraries and executables for this path rewriting, the packager must use a Macports installation that has been installed in a longer than normal PREFIX. I don't know what the minimum size is, but I've put a requirement in the packaging script to check that it is at least 50 characters. Thus it needs to be installed in something like /opt/ local-universal-macports-in-really-long-prefix-for-inkscape-etc-etc... you get the idea. This should solve a lot of problems with our bundled libraries conflicting with system versions.
i.e. unless I modify the limit in osx-app.sh locally, I have to rebuild the complete MacPorts tree for Inkscape if I 'svn update' to the current version of the packaging files in trunk?
sorry, I was answering in a haste and didn't read all changed lines in 'osx_app.sh' to the end - the instructions in the comments are loud and clear ;-)
Could you take a look at my patch in Bug #424394 “Launching and Path problems under Mac”? https://bugs.launchpad.net/inkscape/+bug/424394
I have been using it for several days now with different application paths (several ' ', '&', '|' and '#' combinations). As I wrote in the last comment I had to change the '#' escaping for the other two resource files as well which eliminates the need for 'ESCAPED2TOP'.
~suv
The 2nd prerelease works great so far on the Mac 10.5.7,
Thanks for all your hard work :)
On Tue, Sep 8, 2009 at 10:43 AM, ~suv<suv-sf@...16...> wrote:
On 8/9/09 09:24, ~suv wrote:
On 8/9/09 06:38, Michael Wybrow wrote:
Also, it the package no longer uses the DYLD_LIBRARY_PATH environment variable to specify where the libraries can be found. Instead they all have their internal paths rewritten at packaging time to be relative to the path of the executable. To allow enough space in the libraries and executables for this path rewriting, the packager must use a Macports installation that has been installed in a longer than normal PREFIX. I don't know what the minimum size is, but I've put a requirement in the packaging script to check that it is at least 50 characters. Thus it needs to be installed in something like /opt/ local-universal-macports-in-really-long-prefix-for-inkscape-etc-etc... you get the idea. This should solve a lot of problems with our bundled libraries conflicting with system versions.
i.e. unless I modify the limit in osx-app.sh locally, I have to rebuild the complete MacPorts tree for Inkscape if I 'svn update' to the current version of the packaging files in trunk?
sorry, I was answering in a haste and didn't read all changed lines in 'osx_app.sh' to the end - the instructions in the comments are loud and clear ;-)
Could you take a look at my patch in Bug #424394 “Launching and Path problems under Mac”? https://bugs.launchpad.net/inkscape/+bug/424394
I have been using it for several days now with different application paths (several ' ', '&', '|' and '#' combinations). As I wrote in the last comment I had to change the '#' escaping for the other two resource files as well which eliminates the need for 'ESCAPED2TOP'.
~suv
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 08/09/2009, at 2:38 PM, Michael Wybrow wrote:
I've put up a Mac Inkscape-0.47pre2-1.LEOPARD.dmg package.
I'll test this package on Snow Leopard tonight, but it should hopefully work given I tried some earlier private builds.
This package works on Snow Leopard also. Might be a little slow to start the very first time though.
Cheers, Michael
Hi I must be going senile as I cannot find this on either the inkscape or sourceforge sites.
I searched for Inkscape-0.47pre2-1.LEOPARD.dmg and it returns no results
where do I find this?
TIA
Gaz(UK)
2009/9/8 Michael Wybrow <michael.wybrow@...131...>
On 08/09/2009, at 2:38 PM, Michael Wybrow wrote:
I've put up a Mac Inkscape-0.47pre2-1.LEOPARD.dmg package.
I'll test this package on Snow Leopard tonight, but it should hopefully work given I tried some earlier private builds.
This package works on Snow Leopard also. Might be a little slow to start the very first time though.
Cheers, Michael
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 9/9/09 00:31, Gary Hawkins wrote:
I must be going senile as I cannot find this on either the inkscape or sourceforge sites.
I searched for Inkscape-0.47pre2-1.LEOPARD.dmg and it returns no results
where do I find this?
browse to http://sourceforge.net/projects/inkscape/files/inkscape/0.47pre2/ and download the file http://sourceforge.net/projects/inkscape/files/inkscape/0.47pre2/Inkscape-0.47pre2-1.LEOPARD.dmg/download
hth, ~suv
Thank You, see said I was senile LOL
thanks again
Gaz(UK)
2009/9/9 ~suv <suv-sf@...16...>
On 9/9/09 00:31, Gary Hawkins wrote:
I must be going senile as I cannot find this on either the inkscape or sourceforge sites.
I searched for Inkscape-0.47pre2-1.LEOPARD.dmg and it returns no results
where do I find this?
browse to http://sourceforge.net/projects/inkscape/files/inkscape/0.47pre2/ and download the file < http://sourceforge.net/projects/inkscape/files/inkscape/0.47pre2/Inkscape-0....
hth, ~suv
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
participants (5)
-
Gary Hawkins -
Jon A. Cruz -
Michael Wybrow -
Panos Laganakos -
~suv