Due: https://git.gnome.org/browse/vala/commit/?id=c755bb4bd3b078363193ea41495e4c9f2782a9d8 Not sure what to do: 1. I would add a blocker for <vala-0.20 to glib-2.36, but it would cause a lot of blockers of packages still depending on older vala versions (most of them due not being updated to vala.eclass) 2. This patch could be backported to other vala slots... but when I did it for 0.18, I found it wanting to run plain "valac" at compile time :S What do you think we should do? I think we need to "push" people a bit to use vala.eclass once and for all Reproducible: Always
Too many packages still not using vala.eclass :'( $ grep -r dev-lang/vala */*/*.ebuild| cut -d / -f 1,3 | cut -d : -f1|sed -e 's/.ebuild//' -| sed -e '/vala-common/d' -| sed -e '/dev-lang/d' - app-backup/deja-dup-22.1 app-backup/deja-dup-24.0 app-editors/latexila-2.4.1 app-i18n/ibus-1.4.1 app-i18n/ibus-1.4.2 app-i18n/libskk-0.0.11 app-i18n/libskk-0.0.12 app-i18n/libskk-0.0.9 dev-libs/folks-0.4.3 dev-libs/folks-0.6.9 dev-libs/granite-0.1.0 dev-libs/libappindicator-12.10.0 dev-libs/libdbusmenu-0.6.2 dev-libs/libindicate-12.10.0 dev-libs/libindicate-12.10.1 dev-util/anjuta-3.4.3 gnome-extra/activity-log-manager-0.9.2 gnome-extra/activity-log-manager-0.9.3 gnome-extra/activity-log-manager-0.9.4 gnome-extra/avant-window-navigator-0.4.0 gnome-extra/gnome-contacts-3.4.1 gnome-extra/gnome-dvb-daemon-0.2.9 gnome-extra/gnome-games-3.4.2 gnome-extra/libgda-4.2.13 gnome-extra/libgda-5.0.3-r1 gnome-extra/synapse-0.2.10 gnome-extra/zeitgeist-datahub-0.7.0 gnome-extra/zeitgeist-datahub-0.8.1 gnome-extra/zeitgeist-datahub-0.8.2 gnome-extra/zeitgeist-datahub-0.9.5 gnome-extra/zeitgeist-datasources-0.8.0.1 gnome-extra/zeitgeist-0.9.5 mail-client/postler-0.1.1 media-gfx/shotwell-0.12.3 media-gfx/simple-scan-3.4.2 media-libs/babl-0.1.10 media-libs/babl-0.1.6 media-libs/babl-0.1.8 media-libs/babl-9999 media-libs/gegl-0.1.8-r1 media-libs/gegl-0.1.8 media-libs/gegl-0.2.0-r1 media-libs/gegl-0.2.0 media-libs/gegl-9999 media-libs/grilo-0.1.18-r1 media-libs/gst-rtsp-server-0.10.8 media-libs/libchamplain-0.12.3 media-libs/memphis-0.2.3 media-plugins/gmpc-mmkeys-11.8.16 media-sound/gmpc-11.8.16 media-sound/rhythmbox-2.97 media-sound/rhythmbox-2.98 media-sound/spek-0.7 media-sound/xnoise-9999 media-video/cheese-3.4.2 media-video/totem-2.32.0-r2 media-video/totem-2.32.0-r2 net-libs/gssdp-0.12.2.1 net-libs/gtk-vnc-0.5.0-r1 net-libs/gtk-vnc-0.5.1 net-libs/gupnp-vala-0.10.4 net-libs/libsocialweb-0.25.20 net-libs/telepathy-glib-0.18.1 net-misc/rygel-0.14.3-r1 net-misc/rygel-0.14.3 net-misc/rygel-0.16.3 net-misc/rygel-0.16.4 net-misc/rygel-0.18.0 net-misc/spice-gtk-0.14-r2 net-misc/spice-gtk-0.14-r2 net-misc/spice-gtk-0.14 net-misc/spice-gtk-0.14 net-misc/spice-gtk-0.15.3 net-misc/spice-gtk-0.15.3 net-misc/spice-gtk-0.16 net-misc/spice-gtk-0.16 net-misc/spice-gtk-0.18 net-misc/spice-gtk-0.18 net-misc/vinagre-3.4.2 sci-geosciences/gpx-viewer-0.3.0 sys-apps/accountsservice-0.6.22 sys-apps/accountsservice-0.6.29-r1 sys-apps/accountsservice-0.6.30 sys-apps/systemd-ui-1 sys-apps/systemd-ui-2 sys-apps/systemd-ui-9999 sys-apps/uevt-2.3-r1 www-client/midori-0.4.6-r1 www-client/midori-0.4.8 www-client/midori-0.4.9 www-client/midori-9999 x11-libs/libdesktop-agnostic-0.3.92 x11-libs/libfm-9999 x11-misc/alltray-0.7.5.1 x11-misc/dockmanager-0.1.0 x11-misc/lightdm-1.0.11 x11-terms/valaterm-0.4.3 x11-terms/valaterm-0.6 xfce-extra/xfce4-vala-4.10.2
Maintainers, please start migrating your vala based packages to vala.eclass to let us handle their versioning better, not needing to keep really old vala versions in the tree for a long time when not really needed Thanks
(In reply to comment #2) > Maintainers, please start migrating your vala based packages to vala.eclass > to let us handle their versioning better, not needing to keep really old > vala versions in the tree for a long time when not really needed Did anyone tell you that this is a horrible eclass already? :P
It's the first time I hear that
Well, systemd-ui converted. (In reply to comment #4) > It's the first time I hear that Well, it's terribly hard to understand at a first glance. It exports src_prepare() by default but expects you to set deps by hand. One contradicts the other, resulting in quite a large potential of packages missing vala deps. Moreover, I'm not comfortable with exporting src_prepare() there at all. I'd really prefer an explicit call for vala setup rather than exporting src_prepare() from an eclass which lexically goes to the end.
(In reply to comment #5) > Well, systemd-ui converted. > > (In reply to comment #4) > > It's the first time I hear that > > Well, it's terribly hard to understand at a first glance. It exports > src_prepare() by default but expects you to set deps by hand What deps?
(In reply to comment #6) > (In reply to comment #5) > > Well, systemd-ui converted. > > > > (In reply to comment #4) > > > It's the first time I hear that > > > > Well, it's terribly hard to understand at a first glance. It exports > > src_prepare() by default but expects you to set deps by hand > > What deps? $(vala_depend)
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Well, systemd-ui converted. > > > > > > (In reply to comment #4) > > > > It's the first time I hear that > > > > > > Well, it's terribly hard to understand at a first glance. It exports > > > src_prepare() by default but expects you to set deps by hand > > > > What deps? > > $(vala_depend) Ah yes that's really ugly!
Every heard of a "tracker bug", where you file separate bugs for separate herds and make them block the tracker? This is so messy.
If I find a way to automatically open that ton of bugs and assign them, fine, until then... :/
(In reply to comment #1) > Too many packages still not using vala.eclass :'( > > $ grep -r dev-lang/vala */*/*.ebuild| cut -d / -f 1,3 | cut -d : -f1|sed -e > 's/.ebuild//' -| sed -e '/vala-common/d' -| sed -e '/dev-lang/d' - If you run "epkginfo -Hm" with that contents, you can get list of maintainers
mail-client/postler media-sound/gmpc media-sound/xnoise media-plugins/gmpc-mmkeys www-client/midori x11-libs/libdesktop-agnostic x11-misc/dockmanager xfce-extra/xfce4-vala converted. Let me know if I missed something.
> net-libs/telepathy-glib-0.18.1 0.18.2 and later are already using vala.eclass
quite a few offending ebuilds have been ported already but filter that list...
*** Bug 463934 has been marked as a duplicate of this bug. ***
*** Bug 464194 has been marked as a duplicate of this bug. ***
*** Bug 464292 has been marked as a duplicate of this bug. ***
*** Bug 464518 has been marked as a duplicate of this bug. ***
*** Bug 464322 has been marked as a duplicate of this bug. ***
*** Bug 464744 has been marked as a duplicate of this bug. ***
Created attachment 344700 [details] list Updated list with packages and its maintainers
Comment on attachment 344700 [details] list > * app-backup/deja-dup [gentoo] > * app-backup/deja-dup [gentoo] > * gnome-extra/activity-log-manager [gentoo] > * gnome-extra/synapse [gentoo] > * gnome-extra/zeitgeist-datahub [gentoo] > * gnome-extra/zeitgeist-datahub [gentoo] > * gnome-extra/zeitgeist-datahub [gentoo] > * gnome-extra/zeitgeist-datahub [gentoo] > * gnome-extra/zeitgeist-datasources [gentoo] > * gnome-extra/zeitgeist [gentoo] > * media-gfx/shotwell [gentoo] > * media-libs/memphis [gentoo] > * sci-geosciences/gpx-viewer [gentoo] Fixed.
*** Bug 467352 has been marked as a duplicate of this bug. ***
I think all were migrated
Created attachment 353844 [details, diff] Patch to support gobject-introspection-1.36 in vala-0.16 Backporting the original patch indeeds results in an invocation of valac by the build system. This is caused by make because the .vala file is newer then the .c file, hence a regeneration would be required. So the correct way to patch this would be to patch the generated .c file instead of the .vala file to prevent generation during build. (Patching the .vala file as well still causes a regeneration, which could probably be fixed by touching all .c files in the vala/ dir.)
Created attachment 353846 [details, diff] Patch to support gobject-introspection-1.36 in vala-0.18 Similar for vala 0.18. Adding these patches to this bug for others who might need this. I needed it for some packages in my elementary overlay (https://github.com/pimvullers/elementary).
*** Bug 465832 has been marked as a duplicate of this bug. ***
Doesn't appear to be fixed. If you have both the dev-lang/vala 0.14 and 0.20 slots installed, you can't emerge gobject-introspection-1.36.
You need to unmerge old slot and, if a package is still pulling old slot, bump that package to a newer version
There may not be a newer package available, and that misses the point of a slotted package. It's slotted so that two or more versions can be installed simultaneously. It must be OK to have them both installed simultaneously, or the author would not have slotted the package. Since vala is slotted, gobject-introspection could behave more nicely if it specified the slot of vala that it needs.
Created attachment 356974 [details, diff] Patch to support gobject-introspection-1.36 in vala-0.14 This patch can be used to add support for gobject-introspection 1.36 to Vala 0.14.
@Russ if you need a patched version of vala you can use the patch I just attached to this bug. Alternatively you can get the patch and patched ebuilds for vala and gobject-introspection from the elementary overlay: https://github.com/pimvullers/elementary or use layman. @Pacho I do understand the ide to use this as an incentive to get packages in tree updated to use the latest vala version, but as Russ mentions, that's not the idea behind slotted packages. Also some packages might require older vala versions (I have on in the overlay which builds fine with newer versions then 0.16, but which causes runtime issues with those, hence I backported the patch for these versions earlier). You might want to consider including the attached patches in portage tree to give people an alternative when their beloved package does not support Vala 0.20 at this point.
vala slots are a bit like gcc slots, they are there but you cannot expect all packages to work with them (ask the gcc team if you don't believe me). I am the one who slotted vala back in the days and I do not see a problem with the current situation. Of course we could remove the blocker, there is no blocker for older gcc, even in cases where an older slot is known to not be able to compile a given packages, would you prefer that ?
This is the way I patched gobject-introspection-1.36 when I bumped into this. I trust you gentoo devs to choose the best for all. --- dev-libs/gobject-introspection/gobject-introspection-1.36.0.ebuild 2013-07-27 13:31:09.000000000 -0400 +++ /usr/local/portage/dev-libs/gobject-introspection/gobject-introspection-1.36.0.ebuild 2013-08-22 19:32:43.160276731 -0400 @@ -24,7 +24,7 @@ >=dev-libs/glib-2.36:2 doctool? ( dev-python/mako ) virtual/libffi:= - !<dev-lang/vala-0.20.0 + !<dev-lang/vala-0.20.0:0.20 " # Wants real bison, not virtual/yacc DEPEND="${RDEPEND} Thanks very much
@Russ, the problem with the fix you propose is that the older vala versions might no longer be able to parse the Gir files generated by the newer gobject-introspection package. So in my opinion the correct way to fix this is the seonc option Pacho mentioned in this bugs first post. But I'll leave the final decision up to the devs as I now have working versions in my overlay.
(In reply to Pim Vullers from comment #35) > @Russ, the problem with the fix you propose is that the older vala versions > might no longer be able to parse the Gir files generated by the newer > gobject-introspection package. > > So in my opinion the correct way to fix this is the seonc option Pacho > mentioned in this bugs first post. But I'll leave the final decision up to > the devs as I now have working versions in my overlay. But there is no package in the tree requiring old vala slot. You simply need to update that packages to their testing versions (if you are mixing stable and testing). Also, upstream is only taking care of latest version and this "breakage" has allowed us to fix all packages in the tree to use vala.eclass and, then, allow us to drop older (and unmaintained) slots in the near future instead of having a mix of multiple versions, some of them really old (like 0.10 slots) In summary -> as all consumers have been migrated to vala.eclass and they are able to use the latest vala version, there is no need of older slots once all is stabilized (that is being already handled in stabilization Gnome 3.8 bug)