Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Would this coming weekend be too late? I can provide a build (and associated dependencies) to Jehan then.
Thanks, Partha
On Tue, Oct 14, 2014 at 3:38 PM, Josh Andler <scislac@...400...> wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Partha,
That's definitely not too late. In fact sooner than I hoped for. :) Thanks for being so proactive on that.
Cheers, Josh
On Tue, Oct 14, 2014 at 2:26 PM, Partha Bagchi <partha1b@...400...> wrote:
Would this coming weekend be too late? I can provide a build (and associated dependencies) to Jehan then.
Thanks, Partha
On Tue, Oct 14, 2014 at 3:38 PM, Josh Andler <scislac@...400...> wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Shall we bump the Cairo dependency to 1.14.0 in trunk then?
Obviously, this would write off a lot of current Linux distro releases if we made it a hard dependency... but if we don't then I'm not sure we can really mark the downscaling issue as truly fixed.
AV
On 15 October 2014 04:50, Josh Andler <scislac@...400...> wrote:
Partha,
That's definitely not too late. In fact sooner than I hoped for. :) Thanks for being so proactive on that.
Cheers, Josh
On Tue, Oct 14, 2014 at 2:26 PM, Partha Bagchi <partha1b@...400...> wrote:
Would this coming weekend be too late? I can provide a build (and associated dependencies) to Jehan then.
Thanks, Partha
On Tue, Oct 14, 2014 at 3:38 PM, Josh Andler <scislac@...400...> wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2014-10-15 16:34 GMT+02:00 Alex Valavanis <valavanisalex@...400...>:
Shall we bump the Cairo dependency to 1.14.0 in trunk then?
Yes, absolutely.
Obviously, this would write off a lot of current Linux distro releases if we made it a hard dependency... but if we don't then I'm not sure we can really mark the downscaling issue as truly fixed.
The non-current distros will just have to use 0.48.
Regards, Krzysztof
On Wed, Oct 15, 2014 at 05:09:27PM +0200, Krzysztof Kosiński wrote:
2014-10-15 16:34 GMT+02:00 Alex Valavanis <valavanisalex@...400...>:
Obviously, this would write off a lot of current Linux distro releases if we made it a hard dependency... but if we don't then I'm not sure we can really mark the downscaling issue as truly fixed.
The non-current distros will just have to use 0.48.
Yesterday I spoke with seb128 about including the newer cairo in Ubuntu 14.10 but looks like it missed the cut-off. So it's going to be at least another 6 months before the new cairo is available in a Ubuntu release.
Shall we bump the Cairo dependency to 1.14.0 in trunk then?
Yes, absolutely.
Actually, in thinking about this, I'm not sure upping the version requirement ends up helping users.
First, for Windows and OSX, most users are going to be using a pre-build anyway, and we control the cairo version there, so it's a non-issue.
For distros which *are* already including cairo 1.14, when the user obtains inkscape - whether manually built, from a ppa, or from the distro itself - it'll use the latest cairo already so forcing it in the config doesn't really matter here.
For distros which *aren't* already including cairo 1.14 (which is all of them at the moment), if the user wants to get Inkscape, this will force them to first upgrade cairo. But Cairo is a system-level library so upgrading it to a non-distro provided package introduces a lot of risk. Some users will shy from doing this; others will boldly do it and break their system. (I've seen printing mysteriously break, because I inadvertantly installed a cairo to /usr/local/lib that lacked pdf support, and evince decided to use that instead of system cairo.)
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
Instead I think we should allow inkscape to install and run with either version of cairo, but message it on the download page that the newer version of cairo will fix the downscaling bug.
Bryce
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
Regards, Krzysztof
This debate also raises the spectre of the old "Gtk+ 3" debate again... any system with Cairo 1.14 will also certainly have Gtk+ >= 3.2 available. Last time the issue was raised of switching to Gtk3 by default for inkscape >= 0.92, it was noted that it would write off users of LTS distros like RHEL, CentOS etc. If we set a hard Cairo >= 1.14 dependency, it will effectively do the same thing.
I think we really need a policy statement from the board about support periods... it's a major maintenance headache if we're aiming to support Inkscape on everything from RHEL 5 (stable release from 2007-2017) to distros like Arch Linux that pull in bleeding edge libraries. By the end of an RHEL support cycle, that would mean that we'd be supporting builds using a ten-year range of infrastructure. We already have literally hundreds off conditional build statements, and each of these represents a hazard... so something has to give somewhere!
How about something like this...
0.48.x: Continue to support as an Inkscape LTS release for another couple of years, but cap the API versions we'll support so we don't have to keep releasing a new 0.48.x whenever the private Poppler headers change! Security issues and simple/serious bug fixes only. 0.91: Set Cairo >= 1.14 dependency; release as scheduled... no backports to old distros. 0.92: Enable Gtk+ 3 by default (Gtk+ 2 kept as fallback) 0.93: Remove Gtk+ 2 support and GDL fork; migrate to upstream libcroco
AV
On 16 October 2014 13:48, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
Regards, Krzysztof
2014-10-16 15:55 GMT+02:00 Alex Valavanis <valavanisalex@...400...>:
0.48.x: Continue to support as an Inkscape LTS release for another couple of years, but cap the API versions we'll support so we don't have to keep releasing a new 0.48.x whenever the private Poppler headers change! Security issues and simple/serious bug fixes only.
We could either continue fixing 0.48 to work with new Poppler or use only the poppler-glib based importer. However, the latter converts all text to paths AFAIK.
0.91: Set Cairo >= 1.14 dependency; release as scheduled... no backports to old distros.
+1
0.92: Enable Gtk+ 3 by default (Gtk+ 2 kept as fallback)
I think GTK+3 should be made a hard requirement as soon as we fork the 0.91 branch. The amount of conditional stuff in the UI code is getting really unwieldy.
0.93: Remove Gtk+ 2 support and GDL fork; migrate to upstream libcroco
+1 for the GDL and libcroco stuff.
Regards, Krzysztof
On Thu, Oct 16, 2014 at 7:07 AM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote:
We could either continue fixing 0.48 to work with new Poppler or use only the poppler-glib based importer. However, the latter converts all text to paths AFAIK.
Let distros patch for 0.48... let's not waste any more energy on that branch unless a serious security issue comes up.
I think GTK+3 should be made a hard requirement as soon as we fork the 0.91 branch. The amount of conditional stuff in the UI code is getting really unwieldy.
I really think people need to use gtk3 builds for production work before making suggestions like this. Liam has been very vocal about how broken the canvas stuff is for example, yet he's the only one (at least publicly) trying to figure it out currently.
On top of that, I'm going to reiterate the need for more controls to move to the canvas because things in the Tool Controls Bar do run into the overflow menu at fullscreen on the most common laptop resolution for the Calligraphy Tool & Text Tool. The bonus is that at least with Ubuntu's Ambiance theme, the overflow button doesn't show up, so controls disappear into the ether. The Text & Font dialog also maxes out the dock and is unusable. The rulers are broken. I'm sure there's much more because this is based on less than 10 mins of messing around.
I'm not saying we shouldn't pursue GTK3, I'm saying we need to stick to the old rule of "don't break trunk", and if GTK3 builds aren't in a far better state it's a premature hard requirement. More simply, if GTK3 doesn't end up as the default for 0.92, it's a useless requirement. Note that I'm saying this because the current thought is to have a "short" merge window for 0.92 so we can get back to having more frequent releases again.
Cheers, Josh
On Thu, 2014-10-16 at 14:55 +0100, Alex Valavanis wrote:
it's a major maintenance headache if we're aiming to support Inkscape on everything from RHEL 5
I'm not sure we should aim for certain things as a project that potentially increase the workload on volunteers. Unless paid to support these platforms, we can only really support that which we have the resources to mitigate the effects of and the will to do so.
I'd keep inkscape >=0.91 for latest distros only unless otherwise funded/dedicated employees can do the heavy lifting. For now at least.
The board might not be provisioned with the right power to make this call. I believe that it's concerned with money, trademarks and other organizational items and defers to the developer list for technical votes.
Martin,
On Thu, Oct 16, 2014 at 02:55:42PM +0100, Alex Valavanis wrote:
This debate also raises the spectre of the old "Gtk+ 3" debate again... any system with Cairo 1.14 will also certainly have Gtk+ >= 3.2 available. Last time the issue was raised of switching to Gtk3 by default for inkscape >= 0.92, it was noted that it would write off users of LTS distros like RHEL, CentOS etc. If we set a hard Cairo >= 1.14 dependency, it will effectively do the same thing.
I think we really need a policy statement from the board about support periods...
Martin is correct that the board is not charterd to set technical direction for Inkscape.
I much prefer seeing technical decisions made via rough consensus. When we all are on the same page about something, the project as a whole is able to move forward much more decisively. When things are decided by voting or by a committee, there's always a risk that there's going to be a disgruntled minority.
That said, it's definitely true there are a number of issues - like this one - where we collectively need a single solution, but are currently of diverse opinions. My hope (and plan) is to work through this list one by one and really hash out them out together with some healthy debate, with the goal that we gain a rough consensus on each. You're probably right that documenting them as policy would be beneficial, so we're not just making decisions based on who touched the code last.
Now, obviously there are going to be some items that we're simply never going to all agree on. If we're down to just one or two nay's on an issue, that's probably fine. But the important thing is that dissenters feel their views are being fairly taken into consideration, and are willing to let the motion proceed without blocking it.
it's a major maintenance headache if we're aiming to support Inkscape on everything from RHEL 5 (stable release from 2007-2017) to distros like Arch Linux that pull in bleeding edge libraries. By the end of an RHEL support cycle, that would mean that we'd be supporting builds using a ten-year range of infrastructure. We already have literally hundreds off conditional build statements, and each of these represents a hazard... so something has to give somewhere!
Yes, this is a good point. It sucks being limited by a platform. I feel the same way when I think about having to support Windows and OSX, when I'm trying to get a release out and we're blocked on some Windows bug. More than a few times I've thought it'd make releases go so much smoother if we could just ignore their needs and focus on Linux, and let other people worry about porting issues. Those people should all be using Linux instead, in my opinion. So I can totally see the point of view here with respect to LTS users and their antique Linux systems.
But, as a project we're more successful if we can deliver on a diverse assortment of platforms. By that I mean we get more developers making more contributions, we get more recognition by the public, and we meet the needs of a wider range of the public.
Now, I wouldn't go so far as to say we need to support every possible bit of hardware and every release of every distro out there. We can set some reasonable boundaries. For instance, with LTS releases I think one ought to be sufficient - so we should support Ubuntu 14.04 but not worry as much about 12.04.
Of course, "support" can have a lot of meanings. It can mean that we actively test it and assure that the user will have a good experience. Or it can mean we'll begrudge bug reports, but aren't going out of our way to make smooth sailing for folks. Or it can mean that Inkscape will install and run and be usable but beyond that you're on your own.
Because we're an all-volunteer organization, the level of support we can give to any particular platform is really a function of the level of interest by volunteers. We could state as a project we're committed to giving strong support for Inkscape on ARM, but if no one is actually working on that platform, then de facto we don't actually support it.
So with all that said, I think "Tier C" support we should keep to be as broad as we possibly can, "Tier B" I think is sufficient for our LTS support, and "Tier A" should be limited to what individual developers are actively running and using.
How about something like this...
0.48.x: Continue to support as an Inkscape LTS release for another couple of years, but cap the API versions we'll support so we don't have to keep releasing a new 0.48.x whenever the private Poppler headers change! Security issues and simple/serious bug fixes only. 0.91: Set Cairo >= 1.14 dependency; release as scheduled... no backports to old distros. 0.92: Enable Gtk+ 3 by default (Gtk+ 2 kept as fallback) 0.93: Remove Gtk+ 2 support and GDL fork; migrate to upstream libcroco
I like this list, although I do agree with Josh here. Because of how much time has passed since 0.48 was released, I'd be more comfortable if we bump it down one release, so Cairo >= 1.14 in 0.92, and Gtk+ 3 in 0.93, etc. with the caveat that like Josh mentioned, we move to a much faster turnaround for releases.
I'll arrange a discussion around updating our Roadmap, and include consideration for timing of transitions like these.
Bryce
AV
On 16 October 2014 13:48, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
Regards, Krzysztof
On Thu, Oct 16, 2014 at 5:48 AM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote:
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If you're concerned about Inkscape being released with High severity bugs you should really go take a look at our tracker. 131 marked as High that are New, Confirmed, or Triaged. We've still got time before release! :)
Cheers, Josh
On Thu, Oct 16, 2014 at 02:48:36PM +0200, Krzysztof Kosiński wrote:
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
I'd be fine with that, if you think that would make for a fair compromise.
I understand where you're coming from, that you want to ensure users don't have an embarrassingly poor experience with this new Inkscape release. A lot of work has gone into it and you want to make sure it's seen in its best light. I feel the same way.
I also want to make sure users have a good experience just being able to get the dang thing installed, and I know many will give up at the first sign of trouble. I want as many people as possible to have an Inkscape experience, even if it's got a known issue.
Consider that at least in this case, *no code changes* are needed to continue to work with the old cairo library.
By not setting cairo 1.14.0 as a hard dependency, we're leaving the choice to the affected users. These are Linux users, and I think they won't be at all surprised to hear that upgrading some lower level bit is needed for getting a better experience. We can totally message the need to upgrade Cairo in our announcements and on the downloads page, without making it a hard requirement in code. I think they'll appreciate not being forced to do this immediately, and be able to safely kick the tires on Inkscape first, and have the flexibility of upgrading cairo if they really want it.
Trust me, I definitely have a direct interest in getting as many people upgraded to the latest cairo as possible. But I think we're in a situation where we can get most of the gain but allow users to avoid most of the pain if we leave it to the user.
Bryce
On Thu, Oct 16, 2014 at 8:34 PM, Bryce Harrington <bryce@...961...> wrote:
I'd be fine with that, if you think that would make for a fair compromise.
I would be okay with that as well.
I'll also throw a +1 on the rest of what Bryce said because I feel the same way and have made a similar assessment of the situation.
Cheers, Josh
2014-10-17 5:34 GMT+02:00 Bryce Harrington <bryce@...961...>:
On Thu, Oct 16, 2014 at 02:48:36PM +0200, Krzysztof Kosiński wrote:
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
I'd be fine with that, if you think that would make for a fair compromise.
I understand where you're coming from, that you want to ensure users don't have an embarrassingly poor experience with this new Inkscape release. A lot of work has gone into it and you want to make sure it's seen in its best light. I feel the same way.
I thought about this a little more and I think I was initially far too fundamentalist. I would be OK with simply giving the users some clear indication how to fix the display of raster images (e.g. display a dialog box that directs them to a wiki page with instructions on how to install new Cairo).
Regards, Krzysztof
On Fri, Oct 17, 2014, at 07:42 AM, Krzysztof Kosiński wrote:
I thought about this a little more and I think I was initially far too fundamentalist. I would be OK with simply giving the users some clear indication how to fix the display of raster images (e.g. display a dialog box that directs them to a wiki page with instructions on how to install new Cairo).
That's a very good idea. I simple call to cairo_version() gives us the nice run-time checking we need. We'd just want to be sure to add a user preference for snoozing and suppressing the dialog (e.g. "ok", "remind me later", "don't remind me again").
On Fri, Oct 17, 2014 at 04:42:01PM +0200, Krzysztof Kosiński wrote:
2014-10-17 5:34 GMT+02:00 Bryce Harrington <bryce@...961...>:
On Thu, Oct 16, 2014 at 02:48:36PM +0200, Krzysztof Kosiński wrote:
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
I'd be fine with that, if you think that would make for a fair compromise.
I understand where you're coming from, that you want to ensure users don't have an embarrassingly poor experience with this new Inkscape release. A lot of work has gone into it and you want to make sure it's seen in its best light. I feel the same way.
I thought about this a little more and I think I was initially far too fundamentalist. I would be OK with simply giving the users some clear indication how to fix the display of raster images (e.g. display a dialog box that directs them to a wiki page with instructions on how to install new Cairo).
Great, sounds good. For Ubuntu I'll make sure we have a PPA available. Hopefully something similar can be done for RedHat and other distros.
Bryce
El vie, 17-10-2014 a las 16:42 +0200, Krzysztof Kosiński escribió:
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
I'd be fine with that, if you think that would make for a fair compromise.
I understand where you're coming from, that you want to ensure users don't have an embarrassingly poor experience with this new Inkscape release. A lot of work has gone into it and you want to make sure it's seen in its best light. I feel the same way.
I thought about this a little more and I think I was initially far too fundamentalist. I would be OK with simply giving the users some clear indication how to fix the display of raster images (e.g. display a dialog box that directs them to a wiki page with instructions on how to install new Cairo).
As the user who reported the bug being discussed, I'd like to add that for my workflow (and I'm sure that many people's workflows too) including bitmap images in vector illustrations is a critical feature. Removing the ability to work with bitmaps is a no-go. If I install Inkscape from the repositories and find that I would immediatelly roll back to the previous version. People getting a program from repository expects that the program works. Period. Getting instructions to make the missing feature work (which is a moving target, because different distros and different platforms have different ways to achieve it) is not good for users and it's a burden for whoever has to mantain that wiki page with updated information about how to make the thing work on every platform.
I'm not afraid of compiling stuff myself (actually I have been compiling inkscape and cairo master) but I always relied upon the stable version from the repositories for my production work. The version from the repositories has to just work, and if that means making the newer cairo a hard dependency and staying with the old one until the distro gets the new cairo, that's fine.
That means that no user will find that the last stable version breaks for something that is crucial to their workflow. That's a really nasty surprise when you have a lot of work to do.
The consequences of bumping the cairo version as a hard dependency will be that somebody does a PPA for Ubuntu or people who prefer to compile will have to do some extra work. And for the latter, a wiki page explaining how to do it would be fine (I've done it, it's not difficult and relatively safe if you compile using a custom prefix). People who compile their own stuff are used to reading documentation. People who get the programs from repositories or installers just expect that the program will work.
Gez.
On Sat, Oct 18, 2014 at 6:22 AM, Gez <listas@...3059...> wrote:
As the user who reported the bug being discussed, I'd like to add that for my workflow (and I'm sure that many people's workflows too) including bitmap images in vector illustrations is a critical feature. Removing the ability to work with bitmaps is a no-go. If I install Inkscape from the repositories and find that I would immediatelly roll back to the previous version. People getting a program from repository expects that the program works. Period.
Anyone who would be getting it from a repository (minus the Stable PPA unless we provide cairo there too) WILL HAVE the correct version of cairo. It has been released. When it comes to spring distro releases, it will not be an issue. It will really only potentially be an issue for LTS users who want to compile Inkscape themselves. You keep saying from repos, so I need to emphasize, it won't be an issue for people getting it from vendor repos.
Cheers, Josh
Just a practical question : should people like me who use Trunk PPA on LTS distros simply stop to accept daily PPA builds now and continue to work with today's build ?
ivan
Le 18/10/14 21:15, Josh Andler a écrit :
On Sat, Oct 18, 2014 at 6:22 AM, Gez <listas@...3059...> wrote:
As the user who reported the bug being discussed, I'd like to add that for my workflow (and I'm sure that many people's workflows too) including bitmap images in vector illustrations is a critical feature. Removing the ability to work with bitmaps is a no-go. If I install Inkscape from the repositories and find that I would immediatelly roll back to the previous version. People getting a program from repository expects that the program works. Period.
Anyone who would be getting it from a repository (minus the Stable PPA unless we provide cairo there too) WILL HAVE the correct version of cairo. It has been released. When it comes to spring distro releases, it will not be an issue. It will really only potentially be an issue for LTS users who want to compile Inkscape themselves. You keep saying from repos, so I need to emphasize, it won't be an issue for people getting it from vendor repos.
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Oct 18, 2014 at 3:14 PM, ivan louette <ivan_louette@...48...> wrote:
Just a practical question : should people like me who use Trunk PPA on LTS distros simply stop to accept daily PPA builds now and continue to work with today's build ?
If you already use Trunk, you'd already be exposed to the "problem". If you're using Ubuntu 14.04, it has a cairo snapshot that contains a different scaling patch, but it should be fine.
Cheers, Josh
Thanks a lot !
I use Kubuntu 14.04 and trunk PPA on two different partitions (in fact I have two Kubuntu and one Crunchbang partitions and also a Win8 Virtualbox). Thus if I have any problem with one of my two Kubuntu I will stop to upgrade my PPA on the other one.
In fact I don't use bitmap a lot, but I would test the svg filters on them as soon as possible after Cairo and Inkscape will be upgraded.
ivan
Le 19/10/14 00:41, Josh Andler a écrit :
On Sat, Oct 18, 2014 at 3:14 PM, ivan louette <ivan_louette@...48...> wrote:
Just a practical question : should people like me who use Trunk PPA on LTS distros simply stop to accept daily PPA builds now and continue to work with today's build ?
If you already use Trunk, you'd already be exposed to the "problem". If you're using Ubuntu 14.04, it has a cairo snapshot that contains a different scaling patch, but it should be fine.
Cheers, Josh
How about introducing a configuration flag like:
# opt in to broken build... $ configure --enable-broken-cairo-support
... Old Cairo support enabled Checking for CAIRO... Yes *** WARNING: old Cairo versions (<1.14) have a serious issue with bitmap downscaling that severely affects Inkscape. This option is not suitable for creating distributable packages of Inkscape. See https://launchpad.net/bugs/whatever *** ...
# Default build... $ configure
... Checking for CAIRO... No
This will help to ensure that users opt in to support of old versions, and hopefully packagers will not be tempted to break their users' experience of Inkscape. Those who *really* want to build 0.91 with broken image handling can still do so at their own peril.
AV On 19 Oct 2014 08:32, "ivan louette" <ivan_louette@...48...> wrote:
Thanks a lot !
I use Kubuntu 14.04 and trunk PPA on two different partitions (in fact I have two Kubuntu and one Crunchbang partitions and also a Win8 Virtualbox). Thus if I have any problem with one of my two Kubuntu I will stop to upgrade my PPA on the other one.
In fact I don't use bitmap a lot, but I would test the svg filters on them as soon as possible after Cairo and Inkscape will be upgraded.
ivan
Le 19/10/14 00:41, Josh Andler a écrit :
On Sat, Oct 18, 2014 at 3:14 PM, ivan louette <ivan_louette@...48...>
wrote:
Just a practical question : should people like me who use Trunk PPA on LTS distros simply stop to accept daily PPA builds now and continue to work with today's build ?
If you already use Trunk, you'd already be exposed to the "problem". If you're using Ubuntu 14.04, it has a cairo snapshot that contains a different scaling patch, but it should be fine.
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El sáb, 18-10-2014 a las 12:15 -0700, Josh Andler escribió:
On Sat, Oct 18, 2014 at 6:22 AM, Gez <listas@...3059...> wrote:
As the user who reported the bug being discussed, I'd like to add that for my workflow (and I'm sure that many people's workflows too) including bitmap images in vector illustrations is a critical feature. Removing the ability to work with bitmaps is a no-go. If I install Inkscape from the repositories and find that I would immediatelly roll back to the previous version. People getting a program from repository expects that the program works. Period.
Anyone who would be getting it from a repository (minus the Stable PPA unless we provide cairo there too) WILL HAVE the correct version of cairo. It has been released. When it comes to spring distro releases, it will not be an issue. It will really only potentially be an issue for LTS users who want to compile Inkscape themselves. You keep saying from repos, so I need to emphasize, it won't be an issue for people getting it from vendor repos.
You say it's not an issue because at the time of the release of Inkscape all the distros that could offer inkscape 0.91 will already have the right version of Cairo, right? That's true, and I know this is rather unlikely, but if some distro decides to stick to the previous version of Cairo for whatever reason and a packager builds inkscape for their repos, the issue would affect all of their users.
It's unlikely but not impossible.
LTS users who want to compile themselves, on the other hand, are better equiped to deal with a dependency not met. As I mentioned earlier, you can install the right cairo version in a different prefix and load it when the inkscape binary is executed (that's how I tried it without messing with my system-wide cairo).
My point is that people who chose an LTS distro but want to run a new version of the program that they can only get by compiling the sources, are probably prepared to deal with it, and building the new cairo will be at their reach. Using Inkscape with the old cairo brings back a very nasty bug that breaks lots of people's workflows. Making the new version of a dependency avoids that and only creates an extra problem to people who are likely to be able to deal with it.
G.
On Sat, Oct 18, 2014 at 08:35:29PM -0300, Gez wrote:
El sáb, 18-10-2014 a las 12:15 -0700, Josh Andler escribió:
On Sat, Oct 18, 2014 at 6:22 AM, Gez <listas@...3059...> wrote:
As the user who reported the bug being discussed, I'd like to add that for my workflow (and I'm sure that many people's workflows too) including bitmap images in vector illustrations is a critical feature. Removing the ability to work with bitmaps is a no-go. If I install Inkscape from the repositories and find that I would immediatelly roll back to the previous version. People getting a program from repository expects that the program works. Period.
Anyone who would be getting it from a repository (minus the Stable PPA unless we provide cairo there too) WILL HAVE the correct version of cairo. It has been released. When it comes to spring distro releases, it will not be an issue. It will really only potentially be an issue for LTS users who want to compile Inkscape themselves. You keep saying from repos, so I need to emphasize, it won't be an issue for people getting it from vendor repos.
You say it's not an issue because at the time of the release of Inkscape all the distros that could offer inkscape 0.91 will already have the right version of Cairo, right?
In practice, yes.
That's true, and I know this is rather unlikely, but if some distro decides to stick to the previous version of Cairo for whatever reason and a packager builds inkscape for their repos, the issue would affect all of their users.
It's unlikely but not impossible.
Correct, it's not impossible. It's a legitimate concern.
LTS users who want to compile themselves, on the other hand, are better equiped to deal with a dependency not met. As I mentioned earlier, you can install the right cairo version in a different prefix and load it when the inkscape binary is executed (that's how I tried it without messing with my system-wide cairo).
If it were any of our other dependency libraries I'd tend to agree.
Cairo is used by a lot of different applications, from evince to web browsers to administration tools... In theory, you could leave your old version of libcairo2 in /usr/lib, and install the new 1.14 to /usr/local/lib, and all would be good. That's how it's *supposed* to work. Then you build inkscape against the /usr/local/lib version of the library and get the best of both worlds.
In my experience though (and I reinstall cairo A Lot), odd problems can crop up when you do this. For example, I'd omitted PDF support for my /usr/local/lib/ installed libcairo2, and suddenly evince broke and web browser printing quit working properly.
I fear that making inkscape installation *harder* in order to save inexperienced users from seeing this bug, we may inadvertantly lead them into a situation where they're inadvertently break their system.
My point is that people who chose an LTS distro but want to run a new version of the program that they can only get by compiling the sources, are probably prepared to deal with it, and building the new cairo will be at their reach. Using Inkscape with the old cairo brings back a very nasty bug that breaks lots of people's workflows. Making the new version of a dependency avoids that and only creates an extra problem to people who are likely to be able to deal with it.
Hmm, I see where you're coming from (and thank you for arguing the point) but I come to the opposite conclusion. If, as you say, building a new cairo is within their reach, and they're going to build Inkscape from scratch (rather than use a PPA), then we should be able to safely assume if/when they run into this particular bug they'd know enough to read Known Issues and Release Notes and so forth, and learn that they should upgrade their cairo as well.
My guess is that the lion's share of LTS users are going to just install from a PPA (or equivalent), and that's where we should be focusing our efforts. Such a PPA would include both Inkscape builds and new Cairo 1.14 system packages, and it'd all Just Work.
The audience we're arguing about - LTS users compiling from scratch - are probably going to be quite a small crowd. My guess here is they're not going to be a bunch of neophytes, but rather are going to be technically apt folks (since they're ok compiling from scratch) who just like keeping their system stable (since they run LTS versions). I think it's safe to assume such cautious techies will read NOTICES we post, and I also think they'll appreciate having the flexibility to choose what the priority is for them: System stability trading off rendering quality, vs. good downscaling quality trading off potential system bugs.
Trust me, I've put a good share of effort into making sure this bug is adequately solved. I certainly don't want it to see it continue to afflict people! At the same time, I know how risk-adverse LTS users are and how much risk taking we're asking of them if we demand they upgrade Cairo. My preference is to educate them about the choices and let them decide which path is right for them.
If their usage model involves embedding bitmaps in SVG documents, then it's going to be an easy choice! And we can totally support them. OTOH, if they're an occasional Inkscape user who want's the latest and greatest but isn't willing to take a risk with a system library and doesn't care about downscaling bitmaps, we can totally support them too.
Bryce
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
Good Idea!
OK, I have provided the latest 64-bit windows devlibs including Cairo 1.4.0, gtk+-2.24.25, gtk+3.14.3, glib-2.42.0 etc. etc. to Johan.
I have not had time to build the 32-bit libraries yet.
Thanks, Partha
On Tue, Oct 14, 2014 at 11:50 PM, Josh Andler <scislac@...400...> wrote:
Partha,
That's definitely not too late. In fact sooner than I hoped for. :) Thanks for being so proactive on that.
Cheers, Josh
On Tue, Oct 14, 2014 at 2:26 PM, Partha Bagchi <partha1b@...400...> wrote:
Would this coming weekend be too late? I can provide a build (and associated dependencies) to Jehan then.
Thanks, Partha
On Tue, Oct 14, 2014 at 3:38 PM, Josh Andler <scislac@...400...> wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
As it happens I'm compiling cairo on mingw, and I've found a problem in aclocal.float.m4. These lines...
if strings - conftest | grep seesnoon >/dev/null ; then
...fail because on windows you get conftest.exe instead of conftest. Any suggestions for a workaround? something that keeps the detection functionality working.
Best Regards Joel Holdsworth
On 14/10/14 20:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I think the portable way is to call conftest$ac_exeext to get the correct executable-extenstion for the current platform.
dan
On Thu, 16 Oct 2014 17:14:20 +0100, Joel Holdsworth <joel@...1709...> wrote: As it happens I'm compiling cairo on mingw, and I've found a problem in
aclocal.float.m4. These lines...
if strings - conftest | grep seesnoon >/dev/null ; then
...fail because on windows you get conftest.exe instead of conftest. Any suggestions for a workaround? something that keeps the detection functionality working.
Best Regards Joel Holdsworth
On 14/10/14 20:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for
the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Daniel Macks dmacks@...2516...
Looks like older cairo had a different approach (searching the object file rather than the fully linked executable) up until this change:
http://cgit.freedesktop.org/cairo/commit/build/aclocal.float.m4?id=7cfebce15...
Why are we top-posting?
dan
On Thu, 16 Oct 2014 12:21:27 -0400, Daniel Macks <dmacks@...2516...> wrote: I think the portable way is to call conftest$ac_exeext to get the
correct executable-extenstion for the current platform. dan
On Thu, 16 Oct 2014 17:14:20 +0100, Joel Holdsworth <joel@...1709...> wrote: As it happens I'm compiling cairo on mingw, and I've found a problem in
aclocal.float.m4. These lines... > if strings - conftest | grep seesnoon >/dev/null ; then
...fail because on windows you get conftest.exe instead of
conftest. > Any suggestions for a workaround? something that keeps the detection > functionality working. >
Best Regards Joel Holdsworth
On 14/10/14 20:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91. > > So, any Windows devs want to see about building it and testing
for > the devlibs?
The sooner we can can get on this, the better... > > http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. > > Monitor 10
servers for $9/Month. > > Get alerted through email, SMS, voice calls or mobile push notifications. > > Take corrective actions from your mobile device. > > http://p.sf.net/sfu/Zoho
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers
for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Daniel Macks dmacks@...2516...
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Daniel Macks dmacks@...2516...
Yeah this fixes it: http://paste2.org/8NhGx5F2
Though it still only gives me a static library when I specifically configure with --enable-shared :(
Joel
On 16/10/14 17:21, Daniel Macks wrote:
I think the portable way is to call conftest$ac_exeext to get the correct executable-extenstion for the current platform.
dan
On Thu, 16 Oct 2014 17:14:20 +0100, Joel Holdsworth <joel@...1709...> wrote: As it happens I'm compiling cairo on mingw, and I've found a problem in
aclocal.float.m4. These lines...
if strings - conftest | grep seesnoon >/dev/null ; then
...fail because on windows you get conftest.exe instead of conftest. Any suggestions for a workaround? something that keeps the detection functionality working.
Best Regards Joel Holdsworth
On 14/10/14 20:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for
the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Daniel Macks dmacks@...2516...
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
conftest extesion bug filed upstream at https://bugs.freedesktop.org/show_bug.cgi?id=85120
dan
On Thu, 16 Oct 2014 18:16:08 +0100, Joel Holdsworth <joel@...1709...> wrote: Yeah this fixes it: http://paste2.org/8NhGx5F2
Though it still only gives me a static library when I specifically configure with --enable-shared :(
Joel
On 16/10/14 17:21, Daniel Macks wrote:
I think the portable way is to call conftest$ac_exeext to get the correct executable-extenstion for the current platform.
dan
On Thu, 16 Oct 2014 17:14:20 +0100, Joel Holdsworth <joel@...1709...> wrote: As it happens I'm compiling cairo on mingw, and I've found a problem in
aclocal.float.m4. These lines...
if strings - conftest | grep seesnoon >/dev/null ; then
...fail because on windows you get conftest.exe instead of conftest. Any suggestions for a workaround? something that keeps the detection functionality working.
Best Regards Joel Holdsworth
On 14/10/14 20:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for
the devlibs?
The sooner we can can get on this, the better...
http://cairographics.org/releases/cairo-1.14.0.tar.xz
Cheers, Josh
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Daniel Macks dmacks@...2516...
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- Daniel Macks dmacks@...2516...
On 14-10-2014 21:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The updated cairo binaries that Partha built are now in devlibs64. Please test and see if anything is broken. Partha also updated other dependencies, but I have not committed them for lack of time to do it properly.
thanks, Johan
On 2014-10-21 19:34 (+0100), Johan Engelen wrote:
On 14-10-2014 21:38, Josh Andler wrote:
Hey all,
For those who don't sub to the cairo list, cairo 1.14 has been released which has the downscaling we need available for 0.91.
So, any Windows devs want to see about building it and testing for the devlibs?
The updated cairo binaries that Partha built are now in devlibs64. Please test and see if anything is broken. Partha also updated other dependencies, but I have not committed them for lack of time to do it properly.
I would recommend to patch cairo 1.14.0 if included in Inkscape installers for stable releases:
Users on OS X testing osxmenu packages with cairo 1.14.0 reported random (daily) crashes (critical: no emergency save -> dataloss).
While trying to locally reproduce the crashes, I noticed that with cairo from git master the crashes no longer. AFAICT the related commit in cairo git master which fixes it is:
http://cgit.freedesktop.org/cairo/commit/?id=2de69581c28bf115852037ca41eba13...
Based on the backtraces, a related cairo bug report seems to be
https://bugs.freedesktop.org/show_bug.cgi?id=85372
Steps to trigger such crashes with Inkscape and cairo 1.14.0: 1) launch inkscape trunk with default (new) prefs 2) zoom to 100% 3) draw a star (default settings) 4) keep star selected, switch to Spray tool 5) start spraying (to fill the visible canvas area) 5a) until (random) crash occurs 5b) zooming out (or in) may trigger the crash too
Backtrace of such a crash: https://gist.github.com/su-v/6d19e317a5dc20974194
participants (14)
-
Alex Valavanis -
Bryce Harrington -
Daniel Macks -
Gez -
ivan louette -
Jabier Arraiza -
Joel Holdsworth -
Johan Engelen -
Jon A. Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Partha Bagchi -
su_v