> On Mar 23, 2017, at 8:56 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> > wrote: > > On donderdag 23 maart 2017 15:52:52 CET John Ralls wrote: >>> On Mar 23, 2017, at 3:49 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> >>> wrote:> >>> On woensdag 22 maart 2017 22:05:25 CET Geert Janssens wrote: >>>> commit 9f3ad5510427eb69c857814de15e1c1be0727d2d >>>> Author: Jesse Olmer <je...@wickedgoodtimes.com> >>>> Date: Sat Feb 13 21:59:05 2016 -0800 >>>> >>>> Bug 739571 - Matching imported transactions doesn't indicate >>>> previously >>>> >>>> matched entries >>>> >>>> Track pending matches from the current import and display this >>>> >>>> information in the match picker. >>> >>> This commit (which I pushed myself) breaks travis because its unit test >>> uses g_assert_true and friends. >>> >>> A quick lookup shows the maint branch of gnucash is still running travis >>> tests on Ubuntu 12.04 (Precise), which ships with glib-2.0 2.32 while >>> g_assert_true was introduced in glib-2.0 2.38. >>> >>> I'm in two minds about how to proceed. >>> - I could revert the patch and rework it for master only. This will delay >>> its formal release with a few months. >>> - I could backport my patches that set the minimum required glib-2.0 >>> version to 2.40 and adjust the travis environment to trusty (14.04) like >>> master. >>> >>> The fundamental question here is do we still want to support Ubuntu 12.04 >>> ? It will be EOL by the end of next month so I don't know whether it's >>> still worth spending effort for ? >>> >>> What you others think ? >> >> I suggest the 3rd alternative: Use HAVE_GLIB_2_38 to disable the offending >> tests on systems that don't support it. Supporting older distros doesn't >> mean supporting them as development platforms where all tests must work and >> pass. >> > That's a good option. we already use the same macro for other exceptions. > Will > implement it that way. > >> For longer term, maint's configure.ac says that it requires 2.28. Has anyone >> actually tried to build with 2.28 recently? We could set up Travis with >> various versions of glib to ensure that we don't accidentally break our >> minimum requirement claims. > > I believe the 2.28 baseline stems from RHEL/Cents 6. It's the most recent > version there. I have no idea whether current stable builds on that platform > and I'm not sure it ever did. The epel repos only contain gnucash 2.4 so it > may well be we have dropped support already in the 2.6 development cycle (I > don't remember unfortunately). > > RHEL/Centos 7 ship glib2 2.46. > > openSuse's oldest still maintained release appears to be Leap 42.1 according > to Frank's link. This distro ships glib2 2.44. > > Travis/Ubuntu Trusty (14.04LTS) ship glib2 2.40 > Travis/Ubuntu Precise (12.04LTS) ship glib2 2.32 > > I mentioned two other distros in my commit message: > Debian stable ships glib2 2.46 in backports > Mingw in our Windows environment has glib2 2.42 > > So the only two really old ones are RHEL/Centos 6 and Ubuntu Precise (12.04). > > Again I don't know if we ever supported the former with gnucash 2.6. The > older > will go EOL next month. > > If I find some time I'll see if I can build gnucash 2.6 on Centos 6. I > believe > I still have a vm somewhere with that distro. > > Can you set up travis with custom glib2 versions ? That looks tricky. > >> >> This is also a good time to review our minimum requirements for master, as >> we've about 4 months until the first beta release and we're switching to >> WebKit2 so that 2.8 can be in Fedora and that drags in Gtk3. We've also >> implemented a lot of code that requires at least gcc-4.8 and is happier >> with gcc-5.0. We need to figure out what versions of the major distros >> support that, derive from that the minimum version of glib and gtk and >> clean up the code accordingly, fixing any deprecations as we go. > > Well for glib2 I just did the exercise. All of the above mentioned distros > except for RHEL/Centos 6 and Ubuntu Precise are supported if we set the > baseline to 2.40. That makes Ubuntu Trusty (and by extension travis as > configured for master) the oldest supported release. > > I am only checking distros that are slow in updating here by the way. I > assume > distros like Fedora, arch and gentoo to be more recent than those (which has > always been the case so far). > > As for gcc, again RHEL/Centos 6 and Ubuntu Precise are definitely falling on > the wayside.The former ships with 4.4.7, the latter with 4.6.3. I'll just > stop mentioning these two distros from now on. > > RHEL/Centos 7: 4.8.5 (gcc 6 available via software collections) > Mingw: 4.8 (and there are test builds of more recent versions, but not > verified with gnucash yet) > Debian stable 4.9.2 > Ubuntu trusty 4.8.4 > openSuse Leap 4.8 (default), 5.3.1 (available in the repos) > > Gtk3 support. I think at least 3.10 should be the baseline because that > version introduces css styling as a replacement for GtkStyle. Maintaining > both > variants is not desirable. Luckily all platforms we care about for gnucash > 2.8 > match this baseline: > RHEL/Centos 7: 3.14.13 > Mingw: ?? (Mingw64 has 3.22 - which is recommended by gtk itself as platform > for windows) > Debian stable 3.14.5 > Ubuntu trusty 3.10.8 > openSuse Leap 3.16.7 > > Webkit2gtk > RHEL/Centos 7: 2.4.9 > Mingw: ?? (Mingw64 has 2.4.9) > Debian stable 2.4.9 > Ubuntu trusty 2.4.10 > openSuse Leap 2.10.7 > > boost > RHEL/Centos 7: 1.53 > Mingw: 1.55 (self built; Mingw64 has 1.63) > Debian stable 1.55 > Ubuntu trusty 1.54 (1.55 available) > openSuse Leap 1.58 > > Is there anything else we changed requirements for ?
Thanks for working through all of that. Yes, ICU, though we don't require a recent version and its API is very stable. There's also Googletest but that's so easy to install from Github that I think we shouldn't worry about it. There's also gettext (see bug 759844 <https://bugzilla.gnome.org/show_bug.cgi?id=759844>), but that's more an issue for what we use to build release tarballs than anything that users or distro packagers need to be concerned about. Since MinGW64 supports directly a lot of dependencies that we've been building from source--with significant difficulty in some cases--maybe we should put some effort into redoing the Windows build system to use that instead of vanilla MinGW sooner rather than later. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
