Re: [Inkscape-devel] Debian 8 compatibility falling apart after one month of Debian 9
Ok, I am giving up now. The next issue is the change of "create_popup_menu" in "filter-effects-dialog.cpp". There is no easy way to patch this for GTK 3.14, because there Gtk::Menu::Menu(const Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates that 3.8 is what should be required for GTK+... This is the official place this is tracked, so if someone introduced features that are incompatible it's their problem to fix. This is no different than us being conservative about C++ features getting introduced into the codebase years after they're available in compilers... given previous practices and reasoning, this wouldn't pass the enterprise litmus test as they wouldn't update to a newer distro version a month after release. There are cases where we did decide to push past that standard, but they've been very few and far between.
Cheers, Josh
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel < inkscape-devel@lists.sourceforge.net> wrote:
Ok, I am giving up now. The next issue is the change of "create_popup_menu" in "filter-effects-dialog.cpp". There is no easy way to patch this for GTK 3.14, because there Gtk::Menu::Menu(const Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Jul 22, 2017 at 09:15:54AM -0700, Josh Andler wrote:
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates that 3.8 is what should be required for GTK+... This is the official place this is tracked, so if someone introduced features that are incompatible it's their problem to fix. This is no different than us being conservative about C++ features getting introduced into the codebase years after they're available in compilers... given previous practices and reasoning, this wouldn't pass the enterprise litmus test as they wouldn't update to a newer distro version a month after release. There are cases where we did decide to push past that standard, but they've been very few and far between.
+1 agreed on all points.
Would people like to establish a process for periodically considering proposals for incrementing dependency versions? I'm thinking like a monthly project meeting to discuss development status and direction.
Bryce
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel < inkscape-devel@lists.sourceforge.net> wrote:
Ok, I am giving up now. The next issue is the change of "create_popup_menu" in "filter-effects-dialog.cpp". There is no easy way to patch this for GTK 3.14, because there Gtk::Menu::Menu(const Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Guys,
This is a result of my overzealous deprecation fixes... sorry about that; I'll go back and try to insert backward-compatibility patches.
I agree that we should try to support older LTS releases, but there can be fairly major headaches in simultaneously supporting bleeding-edge distros (Arch etc) and Debian oldstable. For example, until last month, we needed to cope with 4 years of API change history (Wheezy released in May 2013).
I think it would be useful to agree a general policy for this kind of thing... i.e., how long after a new LTS Ubuntu/Debian release will we aim to allow build compatibility? The "safest" option is to guarantee that all Debian/Ubuntu releases are supported until their EOL. However, that means essentially rejecting all use of new library features for ~5 years, which I can imagine will limit innovation and put off some developers from contributing.
AV
On 22 July 2017 at 19:15, Bryce Harrington <bryce@...961...> wrote:
On Sat, Jul 22, 2017 at 09:15:54AM -0700, Josh Andler wrote:
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates that 3.8 is what should be required for GTK+... This is the official
place
this is tracked, so if someone introduced features that are incompatible it's their problem to fix. This is no different than us being
conservative
about C++ features getting introduced into the codebase years after
they're
available in compilers... given previous practices and reasoning, this wouldn't pass the enterprise litmus test as they wouldn't update to a
newer
distro version a month after release. There are cases where we did decide to push past that standard, but they've been very few and far between.
+1 agreed on all points.
Would people like to establish a process for periodically considering proposals for incrementing dependency versions? I'm thinking like a monthly project meeting to discuss development status and direction.
Bryce
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel < inkscape-devel@lists.sourceforge.net> wrote:
Ok, I am giving up now. The next issue is the change of "create_popup_menu" in "filter-effects-dialog.cpp". There is no easy
way
to patch this for GTK 3.14, because there Gtk::Menu::Menu(const Gtk::Menu&) is private. Since there are no GTK backports in Debian 8, I have to update to Debian 9 to build inkscape. Not nice :-(
Best regards,
Michael
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 22.07.2017 um 20:15 schrieb Bryce Harrington:
On Sat, Jul 22, 2017 at 09:15:54AM -0700, Josh Andler wrote:
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies indicates that 3.8 is what should be required for GTK+... This is the official place this is tracked, so if someone introduced features that are incompatible it's their problem to fix.
This is also the version indicated in the cmake scripts (which should probably be kept in sync with the wiki page), see https://gitlab.com/inkscape/inkscape/blob/5198e38c82379f7b87f5cd964d565821a5...
If this version matches the actual requirement unexpected build failures like Michael was experiencing should be impossible as cmake would already warn at the configure stage.
Would people like to establish a process for periodically considering proposals for incrementing dependency versions? I'm thinking like a monthly project meeting to discuss development status and direction.
I guess it would be more efficient to
* decide which distributions we want to support as this will ultimately limit the dependency versions we *can* support (I doubt that would need to be re-evaluated monthly). * implement proper checks (likely CI builds) that ensure we do not accidentally introduce dependencies not. The ppa builds run on older Ubuntu distributions were always helpful in that regard, so I hope we can get them (or something comparable using GitLab CI) back up eventually.
Regards, Eduard
On Sat, 2017-07-22 at 11:15 -0700, Bryce Harrington wrote:
+1 agreed on all points.
Would people like to establish a process for periodically considering proposals for incrementing dependency versions? I'm thinking like a monthly project meeting to discuss development status and direction.
I would. I had to use some C++11 which is newer than what we have the wiki. I haven't done as much C++ as I would have liked because of the restrictions on C++11 and with that being now available, it's made the process of development easier for me.
Hopefully we can set some reasonable limits and keep the page up to date. But to make this job easier, we should try and see if we can set up some automatic support scripts that pull in a summary of the different distros and their versions of key dependencies.
Does anyone know anything like this?
Best Regards, Martin Owens
participants (6)
-
Alex Valavanis -
Bryce Harrington -
Eduard Braun -
Josh Andler -
Martin Owens -
Michael Soegtrop