|
Nice one!
thanks for that.
Am 02.02.2017 um 22:33 schrieb Peter Vágner:
Hello,
Sorry that I am talking a lot about qt-at-spi recently however I
have looked at it a bit more closely during past few days.
What I have found out that the stable version qt-at-spi 0.3.1 we
were using all the time is several years old.
qt-at-spi is not in the rapid development since that time but
there are about 40 additional commits in its git repository that
might be usefull up to now.
So it's why I have also came up with qt-at-spi-git and
lib32-qt-at-spi-git packages in the AUR today.
This is not the end of this story though. The matter is a bit more
complicated.
Originally qt-at-spi maintainers were using qmake to manage its
build process. This is also the case with the qt-at-spi 0.3.1
stable release we have been using all the time.
As the development progressed, qt-at-spi lived as a QT5 built-in
feature and some of its changes were also cherry picked into the
original QT4 compatible repository. In order to more tightly
integrate into the QT / KDE ecosystem, the build environment has
been switched from qmake to cmake. Ability to translate the
library into various languages has also been added although no
translations are in the qt-at-spi repository and this feature
appears to be unused as far as I can see.
This resulted in qt-at-spi being hard dependency on kdelibs
package.
We do have 32 and 64 bit kdelibs packages in Arch linux however we
don't have multilib lib32-kdelibs package. The package has been
available a while ago and it has been dropped because nothing else
depended on it for quite a while.
So I have done a horible hack.
I have built qt-at-spi-git package using cmake the way its
creators intended with translations support and kdelibs dependency
in place.
However when building lib32-qt-at-spi-git package I avoided
pulling ton of multilib dependencies related to lib32-kdelibs. I
have forcefully reverted some commits from the qt-at-spi source
tree disabling translation support, removing cmake build system
support and restored qmake build system support. This is hacky
configuration I have used for building lib32-qt-at-spi-git.
Whether it's useful is still to be seen. However I think we should
try to make some good use of it if it's available.
So if you like to try out slightly more up to date qt-at-spi
builds you do have a chance.
https://aur.archlinux.org/packages/qt-at-spi-git
https://aur.archlinux.org/packages/lib32-qt-at-spi-git
Greetings
Peter
On 02.02.2017 at 04:19 B. Henry wrote:
yes, the 32bit alsa pkg is useful, I got
it as a dep for something a long time ago, and think
more than one app I uses requires it.
I asume you have more than one server uncommented in your pacman
mirrorlist file, but if not do
so.
I do not know what exactly is going on, but the correct version
now is 29, not 28 i.e.
lib32-util-linux 2.29.1-1
the build date for the version I list is the 20th of Jan,
although I just installed it
yesterday, so somehow you are showing an old version...I'd
replace my whole pkg database with
pacman -Syyu
in case yours is somehow corrupted or similar. This could happen
if you got some packages from
one server, and other from another perhaps, aand or your
database update was from one server
but you were downloading the packages from another and the first
was not up to date.
_______________________________________________
orca-list mailing list
orca-list gnome org
https://mail.gnome.org/mailman/listinfo/orca-list
Orca wiki: https://wiki.gnome.org/Projects/Orca
Orca documentation: https://help.gnome.org/users/orca/stable/
GNOME Universal Access guide: https://help.gnome.org/users/gnome-help/stable/a11y.html
Log bugs and feature requests at http://bugzilla.gnome.org
|
