PyQt5 officially only supports Python 3.
However, it works with Python 2, at least with calibre.
Don't merge with python3 version, since it build with different
dependencies. And there's some conflicts when generate binary.
* keep python-PyQt5 as 5.13.2 since it's last version supports Python 2
While we're at it:
* ship dist-info for python-PyQt5 for setuptools constrain check.
musl-legacy-compat was removed from base-chroot-musl in
75eca1b03e, meaning that all templates
that depend on it had to add it as makedepends for native musl builds.
Therefore, for consistency, cross-vpkg-dummy shouldn't pull it either.
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-ru package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-pl package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-en package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-el package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-de package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-cs package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
aspell dictionnaries aren't architecture dependent: the dictionnary
format depends on size_t, therefor it needs to be made architecture
specific. This is why the dictionaries are stored in /usr/lib and not
in /usr/share.
This fixes the aspell-fr package on amd64 and probably most 64bits
architectures.
More information about this:
http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html
