Certainly that kind of splitting is unfeasible. I understand there are a bunch of fixes, however applications work somehow and I wouldn't like to break them. Also, even if Vala is hosted at GNOME, I remind you there's plenty of projects relying on Vala. Other applications are as important as GNOME applications.
However, in the case of other applications, those may as well keep using Vala 0.24. After all, distributions ship with multiple versions and Vala is parallel-installable exactly for this reason. In reality, my main concern is about the concrete accessors bug. How much stuff does that bug affect? Would it be possible to just drop in a custom.vala for those until the bug gets fixed? On Thu, Aug 21, 2014 at 9:31 PM, Evan Nemerson <[email protected]> wrote: > They're in the staging branch. For Geary, the relevant error is at > > http://paldo.org:8010/builders/vala-staging/builds/44/steps/geary/logs/stdio > > This is due to the binding for Gtk.Window.set_default_icon_list's > argument becoming owned. The change is correct according to the > annotations in GTK+. > > Currently, Vala will free the list after passing it to > set_default_icon_list, which could result in a use-after-free inside of > GTK+, potentially causing Geary to crash. In this case, it looks like > the best thing to do would be simply change line > src/client/components/main-window.vala:62-64 to > > GLib.List<unowned Gdk.Pixbuf> pixbuf_list = new > GLib.List<unowned Gdk.Pixbuf>(); > pixbuf_list.append(IconFactory.instance.application_icon); > set_default_icon_list((owned) pixbuf_list); > > Now that they know about the potential crash, I suppose it's up to Jim > whether or not it's a requirement, but I would think so. > > There should be quite a few other changes like this which would be great > to have this cycle, as well as lots of changes to make currently useless > API (i.e., stuff which generates invalid C) usable which we don't have > to worry about the API for as they obviously weren't in use. > Unfortunately, there are also a lot of things which break API for less > urgent reasons (like fixing memory leaks) mixed in, which could wait for > next cycle. However, Rico has already put a lot of work in to this, I'm > not sure it's fair to ask him to split those out as it would require > quite a bit of additional effort. > > -E > > > On Thu, 2014-08-21 at 12:04 -0700, Jim Nelson wrote: > > It's not a requirement. Rico mentioned that these changes affected > > Geary. Since it sounds like these changes will either in be 0.26 or > > 0.28, I was hoping to see what the problems are now rather than be hit > > with them later. That's all. > > > > -- Jim > > > > On Thu, Aug 21, 2014 at 12:01 PM, Luca Bruno <[email protected]> > > wrote: > > > Why is it a requirement? For which applications? > > > > > > > > > On Thu, Aug 21, 2014 at 8:57 PM, Jim Nelson <[email protected]> wrote: > > >> Is this on a branch somewhere? I'd like to know how this affects > > >> Geary (and Yorba's other projects). > > >> > > >> -- Jim > > >> > > >> On Thu, Aug 21, 2014 at 11:41 AM, Luca Bruno <[email protected]> > > >> wrote: > > >>> Thanks for your hard work. Is this change a requirement for the new > > >>> stable > > >>> release? Blocking some software? Can it be merged instead in vala > > >>> 0.27? > > >>> > > >>> > > >>> On Thu, Aug 21, 2014 at 7:28 PM, Rico Tzschichholz > > >>> <[email protected]> > > >>> wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> I had a small discussion on IRC with Evan about still pushing a > > >>>> greater > > >>>> Gtk+ bindings update for the current cycle. [1] > > >>>> > > >>>> Those updates are fixing a lot problems like unusable symbols and > > >>>> a > > >>>> bunch of memory-leaks. While the GIR transition for building the > > >>>> gtk+-3.0 binding is delayed for quite some time it is pretty > > >>>> necessary > > >>>> to finally get starting to those issues. > > >>>> > > >>>> I really like to push the staging changes to master despite being > > >>>> in the > > >>>> GNOME freeze. There was also no vala release yet which other > > >>>> projects > > >>>> could rely on. Official GNOME applications which are using Vala > > >>>> will be > > >>>> fixed as fast a possible. Currently known are gitg and geary > > >>>> which needs > > >>>> minor patching. > > >>>> > > >>>> Regards, > > >>>> Rico > > >>>> > > >>>> [1] https://git.gnome.org/browse/vala/log/?h=staging > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> -- > > >>> www.debian.org - The Universal Operating System > > >>> _______________________________________________ > > >>> vala-list mailing list > > >>> [email protected] > > >>> https://mail.gnome.org/mailman/listinfo/vala-list > > > > > > > > > > > > -- > > > www.debian.org - The Universal Operating System > > _______________________________________________ > > vala-list mailing list > > [email protected] > > https://mail.gnome.org/mailman/listinfo/vala-list > > > _______________________________________________ > vala-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/vala-list > > -- www.debian.org - The Universal Operating System _______________________________________________ vala-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/vala-list
