kind plea help me to compile dbus-x11 for ARM64
JanuszChmiel opened this issue · 6 comments
The fact is that dbusů-launch work, but without dbus-x11 some apps have issues including Mate. I would had to recode all C sources which wants to communicate with other processes so it would run dbus-launch binary name.
So dbus-launch can be used to start simple processes, but if Mate-session initialize other processes, it is not enough to work by this way.
Dear MR Rausty.
Do you think, that you could give Me a piece of advice how to compile dbus-x11?
The package for non ARM64 Bit architecture is available here:
https://aur.archlinux.org/packages/dbus-x11/
Sure I will install all needed dependencis myself thanks to included WEB table with dependencies list. But I do not know where to get The needed source code?
Link is here:
git+https://anongit.freedesktop.org/git/dbus/dbus#commit=a330c6184fe9c7f67495f8d4563b11d51a6dccc7
So if you would help Me to download The source I will try to compile myself. I have allready successfully compiled Gradio, Orca I install all needed dependencies thanks to Aur repository and its perfect dependencies list table. I Am not lazy, I can really compile.
Thank you very much for yours advice.
I have also found unsoft true. Some times seamonkey and Firefox stop to cooperate with Orca. I can activate it four seven times and suddenly,, Orca stop to cooperate with those processes. So I want to install dbus-x11.
But even there are some light nuances inf functions, Arch Linux still retain my favourite Linux distro. Thank you very much for yours help.
I have allready asked on ARch general mailing list. I really do my best.
Stale issue message
@JanuszChmiel as you know, but many people who use Android still do not, we have made tremendous progress during the summertime with being able to build packages on smartphones. Some of the resources are being manifested in this installation script so quickly that they have not yet even been documented in the help options! Looking at this issue I have found some information I would like to share with you for I attempted to build and have built dbus-x11 many times today.
Start with the command yay dbus-x11
in a regular user account. If you have already built the dbus-x11 package then you will want to try the enhanced user option which has not been documented yet: startarch el user
. The fundamental difference between the types of logins is that the enhanced user account login cannot create hard links that are to soft links.
Change the architecture to any and add sudo before make like this sudo make -C dbus check
in function check() in file PKGBUILD. Do not continue withyay
. Instead use makepkg -irs --noconfirm
.
If using the login we have been using up to now does not succeed because of a permission error after making the two changes mentioned, login like so; startarch el user
.
Switch to the working directory. In this case ~/.cache/yay/dbus-x11
and check the permissions on directory pkg. If they look okay all is well. If they do not adjust them accordingly. Continue the command makepkg -irs --noconfirm
.
If this does not succeed delete the directory ~/.cache/yay/dbus-x11
. Use yay dbus-x11
again. When this process completes modify file PKGBUILD once more and continue with makepkg -irs --noconfirm
. The package has built numerous times, and this is the best result I have gotten so far:
PASS: test-sd-activation 5 /sd-activation/transient-services/later
PASS: test-sd-activation 6 /sd-activation/transient-services/in-advance
============================================================================
Testsuite summary for dbus 1.12.20
============================================================================
# TOTAL: 146
# PASS: 143
# SKIP: 2
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 1
============================================================================
See test/test-suite.log
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=dbus
============================================================================
make[4]: *** [Makefile:1904: test-suite.log] Error 1
make[4]: Leaving directory '/home/user/.cache/yay/dbus-x11/src/dbus/test'
make[3]: *** [Makefile:2012: check-TESTS] Error 2
make[3]: Leaving directory '/home/user/.cache/yay/dbus-x11/src/dbus/test'
make[2]: *** [Makefile:2229: check-am] Error 2
make[2]: Leaving directory '/home/user/.cache/yay/dbus-x11/src/dbus/test'
make[1]: *** [Makefile:1796: check-recursive] Error 1
make[1]: Leaving directory '/home/user/.cache/yay/dbus-x11/src/dbus/test'
make: *** [Makefile:706: check-recursive] Error 1
make: Leaving directory '/home/user/.cache/yay/dbus-x11/src/dbus'
==> ERROR: A failure occurred in check().
Aborting...
It appears to be an upstream error.
It appears to be an upstream error.
It appears to be an upstream error at first sight. After studying the log file this is what I have found:
# Feature: SystemdActivation
# Interface: org.freedesktop.DBus.Monitoring
# Interface: org.freedesktop.DBus.Debug.Stats
# Time since timeout reset 0xf0641c0: 0.170 seconds
ok 28 /properties/get-all
PASS: test-dbus-daemon 28 /properties/get-all
# End of properties tests
# Start of policy tests
# Resetting test timeout (reference: 0xf0641c0; factor: 1)
dbus-daemon[28117]: [session uid=0 pid=28117] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted
# GLib-DEBUG: posix_spawn avoided (fd close requested) (child_setup specified)
../build-aux/tap-driver.sh: line 145: 27653 Aborted
Bail out! Test timed out (SIGALRM received)
ERROR: test-dbus-daemon - Bail out! Test timed out (SIGALRM received)
It seems that this is not an upstream error at all! The components the test wishes to test with are not installed. @JanuszChmiel can you please see if you have better luck testing this than I please.
can safely close this issue
It seems that the bot closed this issue back in springtime.
is perfectly compiled for aarch64 and it is perfectly working
Even the more so I would like you to test if you can please. The motivation for my request is that you have everything already installed in your smartphone that the test should want:
The components the test wishes to test with are not installed.
Also you just mentioned that it is working perfectly. So this means that the compilation should go smoothly.
resources are being manifested in this installation script so quickly that they have not yet even been documented in the help options!
If using the login we have been using up to now does not succeed because of a permission error after making the two changes mentioned, login like so;
startarch el user
.
Many commands including the command gcl
are affected in the different types of PRoot user logins.