Versions under 0.6.8 freeze on "Would you like to register?" screen

[Duncan Colhoun]

If you attempt to close of minimise a Wait or Force close dialog appears

Only started to happen on upgrade to Ubuntu 18.04

[James Lu (jlu5)]

I can confirm this under Ubuntu 18.04 and 0.6.7-1. There seems to be sporadic freezes on startup, and a reproducible one on shutdown (eventually Variety has to be force killed by a watchdog thread)

This seems to have been fixed in 0.6.8 and later by removing all the vrty.org-related code, so I'm suspecting that the issue lies in that (is some thread blocking on failure?). I have *not* been able to isolate the freeze reason though, and the 0.6.8 "fix" removing a large portion of code is probably too invasive to backport to a stable release[1][2].

[1]: https://github.com/varietywalls/variety/commit/914e463b96ddd7d6ae2259ce5d8b6e287d0bb277
[2]: https://github.com/varietywalls/variety/commit/b4f12693bddf5fefc1e41d6e22903c4f5273f348

[James Lu (jlu5)]

In other words, I would really appreciate some help on this issue :(

[Peter Levi (peterlevi)]

Hi James. I think it would be a great loss of time to search for a hard-to-tracedown GTK-related bug in those dialogs that serve a feature that has been long non-working, and are no longer there in the current release. I think the right action here is to backport the removal code - while huge in "footprint", those changes are mostly fairly trivial.

My general stance regarding bugs in older versions is this:
Variety is an entirely non-mission-critical application, that is also heavily dependent on volatile Internet APIs. It's entirely possible that a past "stable" release gets sufficiently outdated to be non-functional, and it's usually less risky to bring it to a more current state than to apply special bugfixes to the old releases (as those can have unpredicted side effects).

[David Daynard (nardholio)]

Why wouldn't you just bump the release version? Especially since the bug is fixed and 18.04 is an LTS

[James Lu (jlu5)]

In a perfect world yes, updates could be delivered in a timely fashion and we wouldn't suffer from any issues. But the SRU process is long[1], and I'm not convinced that trying to push a massive shift from Python 2 -> 3 would be appropriate.

Last time there was the issue of nobody verifying the SRU targeting xenial[2], which would've fixed a bunch of bugs[3][4]! Ironically the SRU page *discourages* uploaders from doing the verification process themselves, but I wonder if that would've been the only option to actually get something done.

I have not had a pleasant experience pushing SRUs, so my interest in working on another one alone is low. And this is exacerbated by how the most of _my_ interest is towards Debian and not Ubuntu directly. (There's only so much time and energy I have, sorry.)

Part of the solution to this bug is actually figuring out what's causing it. Trying to hide it in a new upstream release is very much opaque to the verifiers, and I don't think they'd appreciate that.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates
[2]: https://bugs.launchpad.net/ubuntu/+source/variety/+bug/1628074
[3]: https://launchpad.net/ubuntu/+source/variety/0.6.0-1ubuntu2
[4]: https://launchpad.net/ubuntu/+source/variety/0.6.0-1ubuntu1