On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov wrote:

This is the best thing we can do now. I briefly looked at vte 0.38 and found that it contains *a lot* of API changes. It requires non-trivial patches to port sakura and other applications. Let's leave the task of API porting to the apps developers.

Well, at least in the apps I ported the API changes weren't that difficult to adapt to. But, they weren't dedicated terminal applications. IIRC features were removed where the best we could do would be stubbing them out. On another note, I wouldn't be opposed to using this opportunity to flip our package names around, so we'll have vte2, vte2.90 and vte. Or, if we want to match the library names, vte, vte2_90 and vte-2.91. Or maybe some other combination. In any case, vte3 isn't really the right name.

On Mon, Sep 29, 2014 at 6:39 PM, wrote:

On 2014-09-29 08:35, Jan Alexander Steffens wrote:

...

On Mon, Sep 29, 2014 at 5:45 AM, Anatol Pomozov wrote:

...

This is the best thing we can do now. I briefly looked at vte 0.38 and found that it contains *a lot* of API changes. It requires non-trivial patches to port sakura and other applications. Let's leave the task of API porting to the apps developers.

Well, at least in the apps I ported the API changes weren't that difficult to adapt to. But, they weren't dedicated terminal applications. IIRC features were removed where the best we could do would be stubbing them out.

On another note, I wouldn't be opposed to using this opportunity to flip our package names around, so we'll have vte2, vte2.90 and vte. Or, if we want to match the library names, vte, vte2_90 and vte-2.91. Or maybe some other combination. In any case, vte3 isn't really the right name.

Note that the whole reason for vte-common (the pty helper binary) is not an issue anymore with latest vte3 anymore. Upstream has deprecated it and disabled the build by default, I enabled it for now, but when we disable it again, the binary can move to the vte2 package.

I'm not very happy with having 2 outdated copies of vte in our repos though, it's another old library that will not receive any maintenance at all. I only want to package the older version in our repos if someone can assure me that it will stay active for only 6 months, after that it should disappear from repos and all applications that haven't been ported should die together with it.

The terminal plugin for Cairo Dock is now fully ported with the help of Anatol. I had a look at pantheon-terminal as well, but it's way out of my league. Changes are not straightforward for someone who does not speak Vala or C: some functions are deprecated and/or no longer available, and it's not just VTE :( I opened a bug report on Launchpad and am waiting for some feedback, but keeping the old one around for a little while would be nice.

On 29/09/14 19:39, jan@jgc.homeip.net wrote:

I'm not very happy with having 2 outdated copies of vte in our repos though, it's another old library that will not receive any maintenance at all. I only want to package the older version in our repos if someone can assure me that it will stay active for only 6 months, after that it should disappear from repos and all applications that haven't been ported should die together with it.

So as not to delay the Gnome 3.14 move even longer, I went ahead and added vte290 to [testing] and rebuilt roxterm, sakura and tilda against that in [community-testing]. I also moved etc/profile.d/vte.sh into vte-common 0.38.0-2. I hope you are OK with the above changes; of course, once these three terminal emulators add support for vte-2.91, we can go ahead and drop vte290. When you do move Gnome 3.14 to the stable repos, please also move vte290 to [extra] and the following packages to [community]: cairo-dock cairo-dock-plugins giggle nemiver pantheon-terminal remmina roxterm sakura tilda