Discussion:
[Inkscape-devel] Debian 8 compatibility falling apart after one month of Debian 9
Josh Andler
2017-07-22 16:15:54 UTC
Permalink
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 <
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bryce Harrington
2017-07-22 18:15:04 UTC
Permalink
Post by Josh Andler
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
Post by Josh Andler
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel <
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Alex Valavanis
2017-07-22 19:02:51 UTC
Permalink
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
Post by Josh Andler
Post by Josh Andler
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
Post by Josh Andler
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
Post by Josh Andler
about C++ features getting introduced into the codebase years after
they're
Post by Josh Andler
available in compilers... given previous practices and reasoning, this
wouldn't pass the enterprise litmus test as they wouldn't update to a
newer
Post by Josh Andler
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
Post by Josh Andler
On Sat, Jul 22, 2017 at 1:49 AM, Michael Soegtrop via Inkscape-devel <
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
Post by Josh Andler
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------
------------------
Post by Josh Andler
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
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Eduard Braun
2017-07-22 19:09:41 UTC
Permalink
Post by Bryce Harrington
Post by Josh Andler
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/5198e38c82379f7b87f5cd964d565821a5786a49/CMakeScripts/DefineDependsandFlags.cmake#L250

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.
Post by Bryce Harrington
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
Martin Owens
2017-07-22 20:48:51 UTC
Permalink
Post by Bryce Harrington
+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
Mattia Rizzolo
2017-07-23 21:51:19 UTC
Permalink
For Debian there are online lists with all packages and versions, e.g.
https://packages.debian.org/stable/allpackages?format=txt.gz
For Ubuntu the lists are e.g.
https://packages.ubuntu.com/de/xenial/allpackages?format=txt.gz
http://packages.linuxmint.com/list.php?release=Sonya
Should be easy to convert with XSLT.
It should take only a few lines of Python to fetch and check these.
All of those are Debian derivates, and they share the same packaging and
repository format.
So it's (imho) way easier to instead get the Sources file (like
https://deb.debian.org/debian/dists/stretch/main/source/Sources.xz for
debian, very similar URI for the others) and use any rfc 822 parser to
read it; there are also debian-specific things like a python-debian
python module and a grep-dctrl thing for bash (both usuable outside of a
debian environment, here "debian-specific" means they are done to parse
debian (and derivative) stuff).
--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Martin Owens
2017-07-23 22:17:57 UTC
Permalink
Thanks Michael,
https://packages.debian.org/stable/allpackages?format=txt.gz
https://packages.debian.org/oldstable/allpackages?format=txt.gz
https://packages.debian.org/testing/allpackages?format=txt.gz
https://packages.debian.org/jessie/allpackages?format=txt.gz
(goto https://packages.debian.org/stable/, select a version at the
top
and click at the end on "(compact compressed textlist)")
Looks like you've got a sizable amount of data here.
I guess there are similar lists for the other major distros.
It should take only a few lines of Python to fetch and check these.
What are the relevant distros?
Ubuntu (this covers A LOT of distros)
Mint
Fedora
Debian
openSUSE
Arch / Manjaro (although arch is fairly bleeding edge)

That most of the targets. We'd first have to get a sensible read on
supported versions vs bleeding edge and their relevant dates.

Only then could we calculate the packages we need.

Best Regards, Martin Owens
Eduard Braun
2017-07-23 22:21:57 UTC
Permalink
I have some experience with creating build systems which use specific
package versions based on Cygwin. Since there is a working MSys build,
it shouldn't be difficult to build with specific package versions - one
just has to create a local cygwin or MSys package repository, which
keeps these specific versions and tell the Cygwin/MSys installer to use
that one. The Cygwin installer creates a suitable repository as a cache
automatically. Not sure how this works with MSys, but I guess it has
similar features. The main issue here might be to get the versions
mentioned in the Wiki. One might have to build them from scratch.
If someone has a years old cache folder of Cygwin or MSys with all the
old package versions, please put is somewhere.
It would make sense to run two builds, one with the latest packages and
one with an archived set of packages.
Best regards,
Michael
(just for clarification: we're using MSYS2, not MSYS! Also we're
creating native builds based on mingw-w64, not Cygwin builds)

While I agree on the idea of having CI with packages using the minimal
version numbers it does not make that much sense to uses MSYS2 as a base
as it's designed to be rolling release and constantly develops. Creating
our own package repository sounds like a lot of unncessary work,
especially as I doubt a "years old cache" of MSYS2 would be able to
build Inkscape at this stage (as a matter of fact I added some packages
myself and fixed some bugs in others along the way).
I assume it'd be much easier to decide on some old but widespread Linux
distro an base CI on that.

Regards,
Eduard
Tobias Ellinghaus
2017-07-24 09:01:06 UTC
Permalink
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via
Dear Eduard, dear Inkscape Team
Post by Eduard Braun
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.
I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).
While I tend to believe that users of ages old stale^Wstable distributions
shouldn't expect bleeding edge development versions of programs to work on
their systems I'd still like to help with at least the glib/gtk part:

Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.

The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)

[...]
Best regards,
Michael
Tobias


[0] https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#GDK-VERSION-MAX-ALLOWED:CAPS
Alex Valavanis
2017-07-24 10:59:02 UTC
Permalink
I've re-added the listing for Debian oldstable to our "Tracking
Dependencies" page...
http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Distros
Post by Tobias Ellinghaus
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via
Dear Eduard, dear Inkscape Team
Post by Eduard Braun
If this version matches the actual requirement unexpected build
failures
Post by Eduard Braun
like Michael was experiencing should be impossible as cmake would
already warn at the configure stage.
I would think that CMake allows newer versions than the specified one,
unless explicitly told otherwise. The issue here is that some GTK 3.16
are actually used although only GTK 3.8 features should be used (as far
as I understood).
While I tend to believe that users of ages old stale^Wstable distributions
shouldn't expect bleeding edge development versions of programs to work on
Read [0] and [1], then add the defines to CMakeLists.txt to have them set for
all files. Also make sure that the compiler warns about deprecated functions.
That will bring you half way there. Once the code base compiles without
compiler warnings you can enable -Werror for development builds (i.e., when
there is a .git folder) and you will be sure to stay compatible with those
libraries.
The rest can be done with CI, or just crowd source it and wait for people
complaining when builds fail. :-)
[...]
Best regards,
Michael
Tobias
[0] https://developer.gnome.org/glib/stable/glib-Version-
Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
[1] https://developer.gnome.org/gdk3/stable/gdk3-General.html#
GDK-VERSION-MAX-ALLOWED:CAPS
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Alex Valavanis
2017-07-24 11:05:23 UTC
Permalink
Just another +1 for handling this all through CI. It will place an
impossible burden on developers if we need to manually rebuild everything
on a list of "supported" build systems before committing to trunk.

The PPA builds are currently out of date because we don't yet have an
"official" mirror of the git repo on Launchpad. It's not too tricky to set
up though, and we can switch to using git-builder when it's available.


AV
Post by Alex Valavanis
I've re-added the listing for Debian oldstable to our "Tracking
Dependencies" page... http://wiki.inkscape.org/wiki/index.php/Tracking_
Dependencies#Distros
Post by Tobias Ellinghaus
Am Sonntag, 23. Juli 2017, 23:22:46 CEST schrieb Michael Soegtrop via
Dear Ed