You are not logged in.

#1 Re: Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-10 22:08:37

I don't have strong opinion about that but...

my idea is to set versions only for dependencies that belong to qt5, kde-framework, plasma, kde-apps groups. These groups have the property that the version number is the same for all member packages, they are updated together from upstream and have strict version requirements ( especially for plasma )... That enables us to update version numbers only for those groups and it should apply for all member packages ( by mangle-pkgbuild at common-functions, for example )

#2 Creating/Maintaining Packages » recurrent problem with plasma dependency loop » 2019-03-10 16:10:14

aliemjay
Replies: 3

Hi all,

The packages kde-cli-tools and plasma-workspace have dependency loop on each other.

The build system tries to build kde-cli-tools first, when  the correct order is to build plasma-workspace first. This repeatedly delayed some plasma packages and caused long-lasting version mismatch. e.g. https://bbs.archlinux32.org/viewtopic.php?id=2671

I wonder why kde-cli-tools is always scheduled first despite build failure?

#3 Re: Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-10 15:51:58

Fixing "dependencies" error is straightforward. Additionally, it would also prevent hard-to-debug mixing of incompatible versions that would otherwise pass the build silently (e.g https://bbs.archlinux32.org/viewtopic.php?id=2628) . as well as saving build slave time smile

sry for the delay.

#5 Re: Creating/Maintaining Packages » "double-conversion 3.1.2" breaks ABI backward compatibility » 2019-03-08 14:25:52

In to my local install only, all the packages listed below have binaries linked to libdouble-conversion.

Most packages don't have explicit dependency, So I don't think rebuilding is a solution unless we rebuild all pactree:

 $ pactree -sru double-conversion 
 $ find /usr/bin/ /usr/lib/ -type f | { while read so; do if ldd "$so" | grep double-conversion > /dev/null; then echo $so; fi; done } | pacman -Qoq - | sort | uniq
appstream-qt
ark
attica
avahi
baloo
baloo-widgets
bluez-qt
breeze
calligra
dolphin
frameworkintegration
gpsd
grantlee
gwenview
k3b
kaccounts-integration
kactivities
kactivities-stats
karchive
kauth
kbookmarks
kcmutils
kcodecs
kcompletion
kconfig
kconfigwidgets
kcontacts
kcoreaddons
kcrash
kdbusaddons
kde-cli-tools
kdeclarative
kdeconnect
kdecoration
kdelibs4support
kdeplasma-addons
kdesu
kdiagram
kdnssd
kdoctools
keditbookmarks
kemoticons
kfilemetadata
kglobalaccel
kguiaddons
kholidays
khotkeys
khtml
ki18n
kiconthemes
kidletime
kio
kio-extras
kirigami2
kitemmodels
kitemviews
kjobwidgets
kjs
kjsembed
kleopatra
kmime
knewstuff
knotifications
knotifyconfig
kompare
konsole
kpackage
kparts
kpeople
kpimtextedit
kpmcore
kpty
kross
krunner
kscreenlocker
kservice
ktexteditor
ktextwidgets
kunitconversion
kwallet
kwayland
kwidgetsaddons
kwin
kwindowsystem
kxmlgui
libaccounts-qt
libdbusmenu-qt5
libkcddb
libkdcraw
libkexiv2
libkipi
libkleo
libkomparediff2
libksane
libkscreen
libksysguard
marble-common
milou
modemmanager-qt
networkmanager-qt
okteta
okular
oxygen
phonon-qt5
plasma-desktop
plasma-framework
plasma-workspace
polkit-qt5
poppler-qt5
powerdevil
prison
purpose
qca
qgpgme
qt5-base
qt5-declarative
qt5-location
qt5-multimedia
qt5-quickcontrols2
qt5-script
qt5-sensors
qt5-serialport
qt5-speech
qt5-svg
qt5-tools
qt5-virtualkeyboard
qt5-wayland
qt5-webchannel
qt5-webengine
qt5-webkit
qt5-x11extras
qt5-xmlpatterns
qtermwidget
qwt
signond
solid
sonnet
subversion
syntax-highlighting
systemsettings
telegram-qt
threadweaver

#6 Re: Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-08 12:31:41

This can be prevented if exact version dependencies were provided in the first place!

I'll suggest a possible solution for that in a new post.

#7 Creating/Maintaining Packages » "double-conversion 3.1.2" breaks ABI backward compatibility » 2019-03-08 11:58:10

aliemjay
Replies: 7

double-conversion from 3.1.2 onward names the library libdouble-conversion.so.3, while in previous versions, the library name is libdouble-conversion.so.3.0.0.
This change is from upstream an is considered a fix to a faulty naming convention.
https://github.com/google/double-conver … ac532fba71

The problem is that all dependent packages needs rebuilding against the new version and many packages in build-list fails because of that, and these packages are many - essentially every qt app and others.
Archlinux updated the PKGBUILDs since 4 days to 3.1.2 but hasn't yet built it, so that new Plasma packages are built against the previous version (3.1.1).

So, should we patch the package and keep old naming?
or otherwise reschedule dependent packages for mass rebuild?

#8 Re: Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-08 11:19:15

Thanks a lot for your time :-)

Just a quick question,
Can the build system handle dependencies with exact version regarding scheduling and build order?
Because I have an idea and want to know how easy it is to implement.

#9 Re: Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-07 15:52:48

very nice :-)

x265 built successfully but there is another issue though,

kfilemetadata now fails to build and the recent log shows that it installs "ki18n-5.54" in the build environment while the latest and the ONLY version available is "ki18n-5.55" and was built 3 weeks ago ( https://www.archlinux32.org/packages/i686/extra/ki18n/ )!
Please note that this version mismatch is the cause of build failure because v5.15 kde apps expect v5.55 plasma framework.

So, Why and how do build servers get outdated packages? Why are exact version dependencies not specified UPSTREAM so we can avoid these bugs and necessary manual intervention?

#10 Re: Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-06 03:24:10

I can confirm that this commit is the sole cause of build failure as I have just reverted it and built successfully.

#11 Building » [SOLVED] x265 build failure holds back Plasma updates » 2019-03-05 19:01:33

aliemjay
Replies: 14

Hi devs,

The latest commit to x265: https://git.archlinux32.org/archlinux32 … 0bb6b262df,
reverted the previous commit that disables assembly code (accidentally?) causing build failure and Plasma is now stuck in build-list for more than a week  because of that.

I hope this get fixed soon,
Thanks!

#12 Re: Pacman / Pacman Upgrades » [solved] LXQt will not start » 2019-01-04 05:45:58

Can you please provide more info:
1. the output you get when launching a qt5 app from terminal.
2. are you on "stable" or "testing"
3. the latest upgrades:

$ grep -e '\[ALPM\] upgrade' /var/log/pacman.log

#13 Re: Pacman / Pacman Upgrades » plasma-desktop is stuck at 5.14.0 for more than 2 months » 2019-01-04 05:09:49

Thanks a lot! your efforts are greatly appreciated.

I have recently tested the newly built packages in "staging" and they fixed some recent problems with my Plasma DE (audio devices not detected; no graphing widgets or sensors;...). I hope that they are pushed to "stable" or "testing" soon.

#14 Pacman / Pacman Upgrades » plasma-desktop is stuck at 5.14.0 for more than 2 months » 2018-12-25 07:45:29

aliemjay
Replies: 2

Hi devs,

I noticed that plasma-desktop lags behind other packages of the KDE suit; other KDE packages have been updated and built for every revision from 5.14.0 to 5.14.4 while plasma-desktop is stuck at 5.14.0 for more than 2 months with no new builds in testing or staging repos.

Is this expected from the build system or is there a problem somewhere??

#15 Pacman / Pacman Upgrades » "Cannot mix incompatible Qt library" for some Qt apps » 2018-11-17 14:01:56

aliemjay
Replies: 1

Hi devs,

The following message appears and causes sddm, kwin and plasmashell to segfault and essentially prevents login to plasma DE:

Cannot mix incompatible Qt library (version 0x50b01) with this library (version 0x50b02)

This error appeared 3 weeks ago in the testing branch on Manjaro32, but now I managed to reproduce it with very minimal fresh installation of archlinux32 (~800MB) in chroot jail with only sddm and kwin packages explicitly installed and is on the stable branch. Other Qt apps works well including the KDE suit.

----UPDATE----
This problem is with both the stable and testing repos. But the fact that I emphasize here is that the problem persists in the testing repos even after the upgrades there and despite the fact that the Qt libraries have identical versions and that all KDE packages are built against Qt 5.11.2. The following applies to testing repos at the time of writing. I am sorry for any confusion.
----

I tried hard to find the faulty package or library here but to no avail. Here is what I have tried so far:

1- All qt5 packages are versioned 5.11.2:

$ pacman -Q | grep qt5
qt5-base 5.11.2-3.0
qt5-declarative 5.11.2-1.0
qt5-graphicaleffects 5.11.2-1.0
qt5-multimedia 5.11.2-1.0
qt5-quickcontrols 5.11.2-1.0
qt5-quickcontrols2 5.11.2-1.0
qt5-script 5.11.2-1.0
qt5-sensors 5.11.2-1.0
qt5-speech 5.11.2-1.0
qt5-svg 5.11.2-1.0
qt5-x11extras 5.11.2-1.0
qt5-xmlpatterns 5.11.2-1.0

2- after setting QT_DEBUG_PLUGINS=1 as environment variable, the processes log the metadata of loaded qt plugins and the weird thing is that ALL loaded plugins have version = 330498 = 0x50b02 = 5.11.2 . Here is a sample:

QFactoryLoader::QFactoryLoader() looking at "/usr/lib/qt/plugins/platforms/libqeglfs.so"
Found metadata in lib /usr/lib/qt/plugins/platforms/libqeglfs.so, metadata=
{
    "IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
    "MetaData": {
        "Keys": [
            "eglfs"
        ]
    },
    "className": "QEglFSIntegrationPlugin",
    "debug": false,
    "version": 330498
}
Got keys from plugin meta data ("eglfs")

3- strace shows that the processes do not access any .so file other than the qt plugins before showing the message.

Board footer

Powered by FluxBB