I was not able to trigger the bug after a half dozen logout/login to the same user. However, I do notice that thee are a lot of geoclue processes that are not cleaned up:
fedora33# ps -fe | grep sfalco
sfalco 911 1 0 11:11 ? 00:00:00 /usr/lib/systemd/systemd --user
sfalco 912 911 0 11:11 ? 00:00:00 (sd-pam)
sfalco 1130 1 0 11:11 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 1749 1 0 11:12 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 2357 1 0 11:13 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 2966 1 0 11:13 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 3560 1 0 11:14 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 4187 1 0 11:15 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 4794 1 0 11:16 ? 00:00:00 /usr/libexec/geoclue-2.0/demos/agent
sfalco 5228 911 0 11:17 ? 00:00:00 /usr/bin/dbus-broker-launch --scope user
sfalco 5229 5228 0 11:17 ? 00:00:00 dbus-broker --log 4 --controller 11 --machine-id 453c53fe1e0e40538136bd60780043d7 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000
I was able to build KiCad for aarch64.
Works fine. Thanks for the rapid fix.
I tried merging bcm283x-firmware-20200306-1.163d84c.fc32.aarch64.rpm into several images:
Fedora-Workstation-32-20200225.n.0.aarch64.raw.xz Fedora-Workstation-32-20200307.n.0.aarch64.raw.xz Fedora-Workstation-32-20200308.n.0.aarch64.raw.xz
In all cases, the dracut shell bug is still present.
Works properly. Thanks!
As per https://www.cqrlog.com/comment/7947#comment-7947 it looks like there is a significant bug in cqrlog-2.4.0, and upstream has recommended rebuilding with the tip of the source tree rather than with cqrlog-2.4.0.tar.gz.
As per https://www.cqrlog.com/comment/7947#comment-7947 it looks like there is a significant bug in cqrlog-2.4.0, and upstream has recommended rebuilding with the tip of the source tree rather than with cqrlog-2.4.0.tar.gz.
I tried this build and it fixes #1765939 and #1770478. Thanks!
This update has been unpushed.
I rebuilt kicad with it and it resolved the issue.
Works great. And a very necessary upgrade since so many people have switched to the 2.0 protocol.
This does not need to be pushed to users because there are no functionality changes. However, a spec file change has been committed, to fix future builds.
Kernel 4.18.16-200.fc28.armv7hl fixes a serious Ethernet issue on ARM Wandboards. As such, it is important to make this kernel available as an update to Fedora as quickly as possible.
Restoring the old soname behavior fixes my issue. I am able to install and run the -6 build with no problems. Great job!
Restoring the old soname behavior fixes my issue. I am able to install and run the -6 build with no problems. Great job!
It does not work for me. I ran that exact command. All it did was create:
libbaccats.so -> /etc/alternatives/libbaccats.so
It did not create:
libbaccats-9.0.7.so -> libbaccats.so
I'd like to request that you delete your "libbaccats-9.0.7.so -> libbaccats.so" symlink on your machine. Then run the command and see if "libbaccats-9.0.7.so -> libbaccats.so" is re-created for you.
If alternatives creates "libbaccats-9.0.7.so -> libbaccats.so" for you, then there is something that is keeping it from working properly for me. I'd like to figure out what that is...
I may not be using alternatives correctly. As per the readme, if I do:
alternatives --config libbaccats.so
then I only get:
lrwxrwxrwx 1 root root 31 Jun 11 10:13 libbaccats.so -> /etc/alternatives/libbaccats.so*
What command did you use to create the link:
lrwxrwxrwx. 1 root 13 May 14 09:35 /usr/lib64/libbaccats-9.0.7.so -> libbaccats.so
I see in your 'ls' that your libbaccats-9.0.7.so has a different date from your other files, so I'm wondering how it got created.
One last time trying to post karma. Sorry for the noise...
Confirmed fixed the bug. Thanks!