When generating Entropy metadata out of Portage xpak information,
strip /* from SLOT (a.k.a. the sub-slots part).
At the same time, rework get_installed_package_metadata() to return
stripped SLOT information to upper layers.
Sub-slots have little meaning for Entropy packages, since rebuilds are
not its business and soname bumps are already properly detected at
dependencies calculation time. However, implementing this feature in
future might have sense, for some currently unknown reasons.
Since Entropy Client migration to file iterator-based content metadata,
such information became unavailable to Entropy SPM's add_installed_package().
In the Portage SPM plugin implementation, such method was responsible of
reconstructing the XPAK CONTENTS file if missing. Injected packages are actually
missing that file (because it does not get created through "emerge -B").
The net result is that Portage vdb metadata for Entropy injected packages was
incomplete.
This commit introduces the ability for Entropy Client to fall back to
package URLs if the repository database URL is not responding as expected
(tested at the application level).
This improves fault-tolerance greatly.
This follows the previously introduced expand_plain_package_mirror()
method. Now both methods can expand repository and package mirror URLs
read from Entropy repository configuration files adding product, arch
and branch information.
If ETP_DEBUG_WATCHDOG env variable is set, entropy.const will create
a timer thread that prints to stderr the full application thread dump.
This is quite useful in case of hard to reproduce deadlocks at the library
level.
Mixing multiprocessing with multithreading is bad and we all know that.
However, in this specific case there was nothing wrong in running tiny
functions in another process.
It seems that entropy.dump.dumpobj() is efficient enough nowadays to
have it running in the same process anyway.
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.
