Not needed with html5-parser 0.4.6
Modify the test to work with all versions of html5-parser
Fixes#990 (Update testsuite for html5-parser 0.4.6 changes)
Since xdg-mime only cares about basename(filename) and that filename is
an existing file (and we don't know where the installed one is), create
an empty file with the right name and then delete that.
Since installing code will also delete a directory tree, it should run
first. This avoids exotic cases where it deletes the binaries it just
installed.
Use case: co-installing python2/python3 using a bindir bundled with the
rest of calibre's code, in order to maintain an alternatives system
pointing symlinks in /usr/bin at the configured binaries.
The uninstaller is only meant to be used on systems where calibre is
being installed live. For staged installs, it can be assumed that the
same mechanism which takes care of installing files from the staging dir
to live systems, is also able to remove calibre when desired. Usually
this will be a linux package manager.
Injecting the location of the mime_resources file from P() in non-frozen
builds will depend on the mime resource from the source tree rather than
the same location during install time... a source tree which may be
deleted after successful installation. On a frozen build, or when using
'develop' instead of 'install', this path will be the same, and things
just work.
The solution is to add *both* paths, and try to uninstall whichever one
exists.
In order for xdg-utils programs to successfully install resources to the
staging root instead of /usr, this variable needs to be set and
additionally some arcane directories must be created that xdg-utils,
astoundingly, does not know how to just gracefully handle.
xdg-mime is simply hopeless as it does not have a --noupdate flag. When
using a staged install, copy it with shutil instead.
This creates an additional variable containing the version number
extracted from a git checkout via `git describe`, and diverts all
human-readable output to use that via get_version.
The Windows-specific hack initially added in commit
8743efbed1e54d8dd4e71ba71ebd5a7806564270 should be able to be removed
now as it is no longer necessary. The python encoding on Windows is sane
in python3.
The sort() call is operating on objects that have no comparison
functions and span multiple types, so they were always compared by their
hash(). This resulted in adding an action, then removing it, causing the
entire "Available Actions" box to be sorted seemingly at random.
This was uncovered during python3 porting, as the objects cannot be
compared at all and therefore return errors.
The default sort order (before anything is done) is to sort based on
pretty names, and therefore use this as the sort key when re-sorting.
Traceback (most recent call last):
File "C:\CBH_Data\calibre.git\calibre_dev\src\calibre\srv\ajax.py", line 141, in book_to_json
File "C:\CBH_Data\calibre.git\calibre_dev\src\calibre\devices\utils.py", line 98, in create_upload_path
File "C:\CBH_Data\calibre.git\calibre_dev\src\calibre\utils\filenames.py", line 40, in ascii_filename
File "C:\CBH_Data\calibre.git\calibre_dev\src\calibre\utils\filenames.py", line 30, in ascii_text
AttributeError: 'int' object has no attribute 'decode'
map() is an iterable, so using it as a shortcut for a proper for loop in
order to apply functions, is no longer valid.
Also move from the long deprecated string.*() functions -- which no
longer exist in python3 -- that are better dealt with through the native
str/unicode type methods.
Seems to be caused by a bug in the lxml version in the builds, which
causes it to output unicode chars as entities, which in turn were
getting stripped by the sanitize_html() function. Fixes#1825905 [amazon scrapper not retrieving accented caracters](https://bugs.launchpad.net/calibre/+bug/1825905)
