This commit moves the Entropy Resources Lock from:
> /var/lib/entropy/client/database/<arch>/.using_resources
to a simpler:
> /var/lib/entropy/.using_resources
The main reason for the move is to make such path more consistent across
architectures.
On a fresh install, with no downloaded repositories, users were forced
to restart Rigo in order to have the search function fully functional.
If a local repository is configured but not downloaded (thus, not
available) the same bug happens.
It turned out to be Entropy._enabled_repos, returned by Entropy.repositories()
which didn't get re-initialized after a repository update. This commit adds
a _validate_repositories() call inside _repositories_updated_signal().
Application.get_markup() and Application.get_extended_markup() must
always return bytestring (decoded) data to make Gtk3 libs and code
happy. It happened that _("N/A") was returned without passing through
prepare_markup() or escape_markup(). This commit fixes it.
If app_name is unicode decoded, the following code will fail (in pl_PL):
>>> prepare_markup(_("<b>%s</b>, internal error")) % (_("Application"),)
with a nice UnicodeDecodeError due to implicit bytestring decode.
prepare_markup() output is bytestring, _() output is unicode.
Thanks to Enlik for reporting.
When sabayon-weekly is updated, the web service is hit by a huge amount of
requests. This commits add a bit more entropy on the execution of
_auto_repositories_update() (random between 30mins to 2 hours) and reduces
the timer frequency to 8hrs (from 4).
It has been observed that using os.fdopen() below in multi-threaded
scenarios is causing EBADF (thus OSError). There is probably a racen
condition down in the stack or mkstemp() itself is not guaranteed against
concurrent access. For now, just consume one more file descriptor and
avoid the race completely.
Using subprocess.PIPE and Popen.wait() causes the child process to
block in case of write (stdout) buffer full. Rewrite the whole
function to use simple a simple fd via mkstemp(). This way, even
if the env variable is very long, the process won't hang.
This issue has been observed in dev-texlive/texlive-latexextra-2012's
SRC_URI, which is more than 131k chars long!
Use the gobject-introspection GLib libraries instead of the old
ones if they are available, for the communication with RigoDaemon
in case of unprivileged repository update requests.
Fabio Erculiani
Sławomir Nizio