I have this message when updating:
Refreshing PackageKit...
Erro: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.PackageKit': timed out (service_start_timeout=25000ms)
erro: comando não executado corretamente
I had the same issue while updating, but I just got rid of packagekit I don’t need that, didn’t even know why it was installed, as it was an optional dependency for a KDE package.
No one should be using packagekit.
And whomever added it to the KDE ISOs again should be given a demerit. 
( somewhat seriously - I noticed it is included in recent ISO … this should be reviewed )
https://wiki.archlinux.org/title/Pacman/Tips_and_tricks#Graphical
EDIT.
Looks like for some reason packagekit-qt5 was present, but commented back in 2021, but became uncommented with this commit
KDE 21.1 Pahvo changes (87931518) · Commits · Profiles & Settings / iso-profiles · GitLab
And has been present, also changed to qt6, since then. I have no idea why. It never should have been included.
Further note in case someone needs it…
This means that current systems are likely to have the following packages:
packagekit
packagekit-qt6
libpackagekit-glib
These can/should all be purged.
Pacman 7.0 (libalpm.so=15) rebuilds are complete.
everything look to be in order post pacman 7.x, except i get an pacman error;
error: restricting filesystem access failed because the landlock rule for the temporary download directory could not be added!
enabling DisableSandbox
DisableSandbox
in pacman.conf, clears it.
You forgot to check your Pacnews, there are three of them. 
i did merge them, DisableSandboxin was disbaled by default in mine. 
Right. I think I put my head on backwards this morning. 
Where did you get the error and how do you trigger it? I can’t reproduce (and yes, by default it is commented).
omano ~ $ pac nano
:: Synchronizing package databases...
core is up to date
extra is up to date
multilib is up to date
warning: nano-8.2-1 is up to date -- reinstalling
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (1) nano-8.2-1
Total Installed Size: 2.56 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [------------------------------------] 100%
(1/1) checking package integrity [------------------------------------] 100%
(1/1) loading package files [------------------------------------] 100%
(1/1) checking for file conflicts [------------------------------------] 100%
(1/1) checking available disk space [------------------------------------] 100%
:: Processing package changes...
(1/1) reinstalling nano [------------------------------------] 100%
:: Running post-transaction hooks...
(1/5) Arming ConditionNeedsUpdate...
(2/5) Looking for .pacnew files...
(3/5) Looking for Pacnew/Pacsave created.
(4/5) Checking which packages need to be rebuilt
(5/5) Updating the info directory file...
(no comment on the deprecated, readded, re-removed ‘SyncFirst’)
So uh … what about the newly uncommented lines in /etc/makepkg.conf.d/rust.conf ?
We previously had those lines commented out but now they are not and have new content ?
!/hint/bash
#
# /etc/makepkg.conf.d/rust.conf
#
#########################################################################
# RUST LANGUAGE SUPPORT
#########################################################################
# Flags used for the Rust compiler, similar in spirit to CFLAGS. Read
# linkman:rustc[1] for more details on the available flags.
#RUSTFLAGS="-C opt-level=3"
# Additional compiler flags appended to `RUSTFLAGS` for use in debugging.
# Usually this would include: ``-C debuginfo=2''. Read linkman:rustc[1] for
# more details on the available flags.
#DEBUG_RUSTFLAGS="-C debuginfo=2"
#!/hint/bash
# shellcheck disable=2034
#
# /etc/makepkg.conf.d/rust.conf
#
#########################################################################
# RUST LANGUAGE SUPPORT
#########################################################################
# Flags used for the Rust compiler, similar in spirit to CFLAGS. Read
# linkman:rustc[1] for more details on the available flags.
RUSTFLAGS="-Cforce-frame-pointers=yes"
# Additional compiler flags appended to `RUSTFLAGS` for use in debugging.
# Usually this would include: ``-C debuginfo=2''. Read linkman:rustc[1] for
# more details on the available flags.
DEBUG_RUSTFLAGS="-C debuginfo=2"
You must forgive me for wondering if this was intentional or not as well ?
They were in makepkg.conf before if I recall the .pacnew merge I did 5 minutes ago. Now they are in dedicated file (basically moved from makepkg.conf to rust.conf).
Not in mine as far as I know. Certainly not existent in this last merge and simply ‘moved’ to this new file. I have the file, also had the file. But its default lines were different than the current ones, and were commented out, unlike the current ones (being suggested by the pacnew).
I see we had RUSTFLAGS beginning with pacman 5.22, but those lines were scrapped at some point for this other file - maybe thats what you are referring to.
Still the lines in the file were commented and now they are not and have new content.
This is what I have in my TimeShift makepkg.conf file from 19th of July (it was the same in the one I merged today):
........
RUSTFLAGS="-Cforce-frame-pointers=yes"
........
DEBUG_RUSTFLAGS="-C debuginfo=2"
........
I’m pretty confident I didn’t add compilation flags myself for Rust, I’m not a developer, I don’t know why you wouldn’t have them in yours.
//EDIT: have a look in current Stable makepkg config file https://mirror.easyname.at/manjaro/stable/core/x86_64/pacman-6.1.0-7-x86_64.pkg.tar.zst
Since we are talking about it … I am relatively sure I had RUSTFLAGS at some point too.
Because I always go through and set something like march=native on all of them.
But I dont have it in my makepkg.conf, and I havent done any changes or merging or similar recently.
Oh I see your edit now with the Stable pacman. So yeah its there, but thats 6.1 vs 7.0+ … pretty big gap.
I suppose I just cant quite remember when the lines were removed … but it seems rather impossible to have been just now.
Again - I already had/have the /etc/makepkg.conf.d/rust.conf file.
It is not new.
Which is why I was presented with a /etc/makepkg.conf.d/rust.conf.pacnew file.
And that file uncomments previously commented lines, and changes the active content of those lines. The two files are copied above.
It also has a ‘shellcheck disable’ line that … well … I dont know how I feel about leaving it on an end user file … I probably would not if it were my choice. And is another tidbit contributing to my wonder at whether this files state is intentional or not.
7 posts were merged into an existing topic: Why no to packagekit? How insecure is it?
@servimo 'Twas only a temporary breakage. Thou shalt update thine packages and in doing so, shall see that thy issue has been resolved.
Fret not! Yea, verily I say unto you this day: I will remove packagekit-qt6 from the KDE ISO profile forthwith.
As per the infinite wisdom of Allan, the Great and Holy Pacman Himself and his faithful minion Morten, has so declared the RUSTFLAGS were moved from /etc/makepkg.conf to /etc/makepkg.conf.d/rust.conf.
Folks, if you want to discuss PackageKit, please create a new Member Hub topic.
EDIT: @cscs Moved the related discussion to Why no to packagekit? How insecure is it?
The package I linked is the current package in Stable, it is not a big gap, it is the version you had before updating. I don’t know I think I provided enough evidence at this point. It was there in my old TimeShift files, it is there in the package you can download in repositories, it is there in your cached package if you look at it, maybe you need other people to do the investigation too, to come to same result, then you may remember you did something? I too like to understand and don’t just “believe”, but when evidence are there just don’t ignore them 
Yes it is not new, the file existed with the commented line, now it is updated with the lines un-commented and flags modified (basically as said, moved from makepkg.conf to this file).
Then … what are you arguing?
I know how a pacnew works and why its there.
My question was - were the line changes on purpose and what was the intent?
You will notice for example that in Arch they continue to be commented out
Maybe the answer is simple - Manjaro wants them uncommented, but accidentally pushed the commented version last time. Or something.
…you’re looking upstream instead of the rust.conf in the package itself.