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.
Attachment:
smime.p7s
Description: Kryptografický podpis S/MIME