GNOME Bugzilla – Bug 691807
Tracker should build against libgee 0.8
Last modified: 2013-03-11 13:01:30 UTC
As I understood, libgee 0.8 is the targeted default for GNOME 3.8. As a consequence, tracker should also follow this and support libee 0.8.
Created attachment 233543 [details] [review] This seems to be all that's needed... works fine in my tests...
Comment on attachment 233543 [details] [review] This seems to be all that's needed... works fine in my tests... Thanks for the patch! :)
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
I am reopening this. I tried building Tracker master in Jhbuild and it fails unless I revert this patch. GNOME 3.8 is targeting libgee 0.6 (or libgee-1.0 .pc file), which is what we had before. So I am inclined to revert this. Before I do, do you have any comment Dominique?
(In reply to comment #4) > I am reopening this. I tried building Tracker master in Jhbuild and it fails > unless I revert this patch. GNOME 3.8 is targeting libgee 0.6 (or libgee-1.0 > .pc file), which is what we had before. So I am inclined to revert this. Before > I do, do you have any comment Dominique? Are you sure about that? My current builds of gnome 3.7.91 are all based on gee-0.8. The main packages are: - gnome-contacts - rygel - empathy - folks
Oh.. I think the issue is simply that jhbuild was never informed about this change: https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.8.modules#n959 gee is not even listed as a dependency for tracker; this is likely the root cause of the error.
oh.. I think I managed to see what else you stated: - Taking the 0.15.3 tarball, it does not build with gee 0.8, due to errors in tracker-resudump.c? It looks though as if the tarball is just not created on a correct system. For example: tracker-0.15.2/utils/tracker-resdump/: total 80 -rw-r--r-- 1 dle1gis users 996 Feb 6 10:29 Makefile.am -rw-r--r-- 1 dle1gis users 31313 Feb 15 12:28 Makefile.in -rw-r--r-- 1 dle1gis users 36507 Feb 15 12:38 tracker-resdump.c -rw-r--r-- 1 dle1gis users 3114 Aug 3 2011 tracker-resdump.vala -rw-r--r-- 1 dle1gis users 6 Feb 15 12:38 tracker_resdump_vala.stamp tracker-0.15.3/utils/tracker-resdump/: total 84 -rw-r--r-- 1 dle1gis users 996 Mar 8 22:09 Makefile.am -rw-r--r-- 1 dle1gis users 31313 Mar 8 22:33 Makefile.in -rw-r--r-- 1 dle1gis users 40205 Jul 8 2012 tracker-resdump.c -rw-r--r-- 1 dle1gis users 3114 Jul 8 2012 tracker-resdump.vala -rw-r--r-- 1 dle1gis users 6 Jul 8 2012 tracker_resdump_vala.stamp => so, 0.15.2 had a MORE RECENT version of tracker-resdump.c than 0.15.3 (even though the vala time stamp would be more recent). The .vala files, for what it's worth, are identical. The generated .c code indeed does differ And the code causing errors differs as follows: -#line 31 "/home/martyn/Source/tracker/utils/tracker-resdump/tracker-resdump.vala" - _tmp0_ = gee_array_list_new (G_TYPE_STRING, (GBoxedCopyFunc) g_strdup, g_free, NULL, NULL, NULL); -#line 31 "/home/martyn/Source/tracker/utils/tracker-resdump/tracker-resdump.vala" +#line 31 "/home/martyn/Source/checkout/gnome/tracker/utils/tracker-resdump/tracker-resdump.vala" + _tmp0_ = gee_array_list_new (G_TYPE_STRING, (GBoxedCopyFunc) g_strdup, g_free, NULL); +#line 31 "/home/martyn/Source/checkout/gnome/tracker/utils/tracker-resdump/tracker-resdump.vala" => (- being from 0.15.2 and + being 0.15.3) If I git clone it and do the whole bootstrapping on my own, the build works just fine. So I'd argue that there are some 'broken' auto-generated files shipped in the tarball of 0.15.3.
(In reply to comment #5) > (In reply to comment #4) > > I am reopening this. I tried building Tracker master in Jhbuild and it fails > > unless I revert this patch. GNOME 3.8 is targeting libgee 0.6 (or libgee-1.0 > > .pc file), which is what we had before. So I am inclined to revert this. Before > > I do, do you have any comment Dominique? > > Are you sure about that? > My current builds of gnome 3.7.91 are all based on gee-0.8. The main packages > are: > - gnome-contacts > - rygel > - empathy > - folks That's exactly my set up here now. Previously I had libgee2 (on Ubuntu 12.10) installed which is version 0.6.4-2. The versioning here is highly confusing. The Jhbuild was linking to the system version. I've removed libgee2 and it now links and build perfectly with the Jhbuild version gee-0.8 (with pkgconfig). This is what I have from within jhbuild: $ pkg-config --modversion gee-0.8 0.9.92 (In reply to comment #6) > Oh.. I think the issue is simply that jhbuild was never informed about this > change: > > https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-deps-3.8.modules#n959 > > gee is not even listed as a dependency for tracker; this is likely the root > cause of the error. Gee is actually not a hard dependency, it's required for parts of Tracker, but those are mostly utilities, nothing major. It just so happens to be a problem if we link to the wrong version of Gee on the system. (In reply to comment #7) > oh.. I think I managed to see what else you stated: > - Taking the 0.15.3 tarball, it does not build with gee 0.8, due to errors in > tracker-resudump.c? > > It looks though as if the tarball is just not created on a correct system. > > For example: > tracker-0.15.2/utils/tracker-resdump/: > total 80 > -rw-r--r-- 1 dle1gis users 996 Feb 6 10:29 Makefile.am > -rw-r--r-- 1 dle1gis users 31313 Feb 15 12:28 Makefile.in > -rw-r--r-- 1 dle1gis users 36507 Feb 15 12:38 tracker-resdump.c > -rw-r--r-- 1 dle1gis users 3114 Aug 3 2011 tracker-resdump.vala > -rw-r--r-- 1 dle1gis users 6 Feb 15 12:38 tracker_resdump_vala.stamp > > tracker-0.15.3/utils/tracker-resdump/: > total 84 > -rw-r--r-- 1 dle1gis users 996 Mar 8 22:09 Makefile.am > -rw-r--r-- 1 dle1gis users 31313 Mar 8 22:33 Makefile.in > -rw-r--r-- 1 dle1gis users 40205 Jul 8 2012 tracker-resdump.c > -rw-r--r-- 1 dle1gis users 3114 Jul 8 2012 tracker-resdump.vala > -rw-r--r-- 1 dle1gis users 6 Jul 8 2012 tracker_resdump_vala.stamp > > => so, 0.15.2 had a MORE RECENT version of tracker-resdump.c than 0.15.3 (even > though the vala time stamp would be more recent). > > The .vala files, for what it's worth, are identical. > The generated .c code indeed does differ > > And the code causing errors differs as follows: > > -#line 31 > "/home/martyn/Source/tracker/utils/tracker-resdump/tracker-resdump.vala" > - _tmp0_ = gee_array_list_new (G_TYPE_STRING, (GBoxedCopyFunc) g_strdup, > g_free, NULL, NULL, NULL); > -#line 31 > "/home/martyn/Source/tracker/utils/tracker-resdump/tracker-resdump.vala" > +#line 31 > "/home/martyn/Source/checkout/gnome/tracker/utils/tracker-resdump/tracker-resdump.vala" > + _tmp0_ = gee_array_list_new (G_TYPE_STRING, (GBoxedCopyFunc) g_strdup, > g_free, NULL); > +#line 31 > "/home/martyn/Source/checkout/gnome/tracker/utils/tracker-resdump/tracker-resdump.vala" > > > => (- being from 0.15.2 and + being 0.15.3) > > If I git clone it and do the whole bootstrapping on my own, the build works > just fine. Yea, I am now linking to the Gee in Jhbuild and it works fine. > So I'd argue that there are some 'broken' auto-generated files shipped in the > tarball of 0.15.3. Exactly. I did revert the patch that fixes this bug to see if it solved my problem and I think subsequently, I used make dist/make distcheck with that generated source (from Vala). So this is entirely my fault. Thanks for noticing and helping with this, leaving this bug as closed. I mainly opened it due to the version confusion I think. Thanks again.
Out of curiosity: will you roll a 0.15.3.1 tarball with the auto-generated files fixed?
(In reply to comment #9) > Out of curiosity: will you roll a 0.15.3.1 tarball with the auto-generated > files fixed? Now in the process of fixing it. I am going to see if I can push the same version again so the tarball on the website is updated, but I have a feeling I will have to go with a 0.15.3.1 (or 0.15.4).
Well, I tried and failed: https://bugzilla.gnome.org/show_bug.cgi?id=695625 I think I will have to roll a new release. I don't really want to update the configure file and NEWS file just because the tarball itself is wrong when nothing else changes in git, :/ will give the guys some time to respond before doing a new release.