When you try to install one thing, it tells you in the title text it is already installed:

And in my case, everything is installed.
Show a checkmark or so for "already installed".
AFAIK querying the current installation state of a package is possible without root access, so AFAIK it should work fine.
v13 (upgraded from before)
GNOME 3.28
Fedora 28
This should already be the case:

Can you confirm that the packages listed in Dependencies match those for Fedora?
I'm seeing the same thing on Fedora 28, none of the installed packages (which are installed, and are listed with the correct package names on the wiki / in the tooltips for the download button(s)) are recognized as being installed.


Not sure exactly how PackageKit is accessed, but packagekit.service is running on the system.
$ systemctl status packagekit.service
● packagekit.service - PackageKit Daemon
Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendor p>
Active: active (running) since Fri 2018-10-26 07:32:59 EDT; 20h ago
Main PID: 23948 (packagekitd)
Tasks: 4 (limit: 4915)
Memory: 92.2M
CGroup: /system.slice/packagekit.service
└─23948 /usr/libexec/packagekitd
Oct 26 07:32:59 teevey systemd[1]: Starting PackageKit Daemon...
Oct 26 07:32:59 teevey PackageKit[23948]: daemon start
Oct 26 07:32:59 teevey systemd[1]: Started PackageKit Daemon.
Oct 27 01:07:52 teevey packagekitd[23948]: Skipping refresh of jridky-gimp-next>
Oct 27 01:07:53 teevey PackageKit[23948]: search-file transaction /28822_aecddb>
Oct 27 04:24:29 teevey PackageKit[23948]: search-file transaction /28823_eabcec>
$ sudo dnf list installed folks fuse-sshfs
Installed Packages
folks.x86_64 1:0.11.4-5.fc28 @fedora
fuse-sshfs.x86_64 2.10-1.fc28 @updates
Querying the package status over DBus (manually via d-feet) returns correct state results:

Even more curious, if I click one of the buttons...

When failing to install the already-installed package, pkmon logs the following:
```
05:22:49 PackageKit emit transaction-list-changed
05:22:49 PackageKit current: /28830_abaccdee
05:22:49 PackageKit emit added: /28830_abaccdee
05:22:49 PackageKit added: /28830_abaccdee
Transactions:
1 /28830_abaccdee
Daemon state: 'State:
0 install-packages /28830_abaccdee state[running] exclusive[1] background[0]
'
/28830_abaccdee allow_cancel 1
/28830_abaccdee percentage -1
05:22:49 PackageKit role now install-packages
/28830_abaccdee role install-packages
/28830_abaccdee status setup
/28830_abaccdee status query
/28830_abaccdee percentage 0
/28830_abaccdee status loading-cache
/28830_abaccdee percentage 1
/28830_abaccdee percentage 2
/28830_abaccdee percentage 3
/28830_abaccdee status finished
05:22:52 PackageKit failed to adopt: fuse-sshfs-2.10-1.fc28.x86_64 is already installed
05:22:52 PackageKit emit transaction-list-changed
05:22:52 PackageKit last: /28830_abaccdee
05:22:52 PackageKit emit removed: /28830_abaccdee
05:22:52 PackageKit removed: /28830_abaccdee
````
Since I don't have Fedora installed, would you mind adding a few debug()'s for the variables available and installable to see what they are showing? The section of interest is here:
I've only tested this on Ubuntu and PackageKit uses a strange bitmasking I've not used before, so I might have done something incorrect:
Basically arch is supposed to restrict the search to architectures that match the host machine, to avoid pulling in 32-bit/64-bit/Arm etc packages. The arch;~installed is obviously supposed to trim that further to uninstalled packages for your arch.
Because your screenshot there shows 2x fuse-sshfs I suspect that it is the arch mask that is not working. Maybe there is something to do with multi-lib support that in Fedora that isn't the same in Ubuntu?
Extra Bits
I tried to make the button a multi-function thing so you could recover. The two most likely I think are failed/aborted password auth and "other package manager has lock" situations.
As far as the "Untrusted Source" message, I assumed on Ubuntu it was because those packages were coming from Universe or another section not officially supported by Canonical. If that's not a thing in Fedora though, maybe there is extra work I have to do to tell PackageKit who is calling the operations.
Because your screenshot there shows 2x
fuse-sshfsI suspect that it is the arch mask that is not working. Maybe there is something to do with multi-lib support that in Fedora that isn't the same in Ubuntu?
I don't _think_ it's an arch issue, because fuse-sshfs doesn't have multiple arch versions available. Whereas folks _does_, yet it's only listed once. Possibly the multiple listings are due to multiple versions being available for the current arch, which is a normal thing in Fedora since the updates repo is separate from the repo for the release packages (which is labeled fedora), so any package that's been updated since the distro release will have a version in both repos:
$ sudo dnf list fuse-sshfs
Last metadata expiration check: 2:07:50 ago on Sat 27 Oct 2018 08:29:02 AM EDT.
Installed Packages
fuse-sshfs.x86_64 2.10-1.fc28 @updates
$ sudo dnf list folks
Last metadata expiration check: 2:08:24 ago on Sat 27 Oct 2018 08:29:02 AM EDT.
Available Packages
folks.i686 1:0.11.4-5.fc28 fedora
folks.x86_64 1:0.11.4-5.fc28 fedora
$ sudo dnf list folks --showduplicates
Last metadata expiration check: 2:08:37 ago on Sat 27 Oct 2018 08:29:02 AM EDT.
Available Packages
folks.i686 1:0.11.4-5.fc28 fedora
folks.x86_64 1:0.11.4-5.fc28 fedora
$ sudo dnf list fuse-sshfs --showduplicates
Last metadata expiration check: 2:08:48 ago on Sat 27 Oct 2018 08:29:02 AM EDT.
Installed Packages
fuse-sshfs.x86_64 2.10-1.fc28 @updates
Available Packages
fuse-sshfs.x86_64 2.8-5.fc28 fedora
fuse-sshfs.x86_64 2.10-1.fc28 updates
python2-gobject is also listed twice, but nautilus-extensions only once, which again may be an updates-vs-fedora thing:
$ sudo dnf list python2-gobject nautilus-extensions --showduplicates
Last metadata expiration check: 2:09:29 ago on Sat 27 Oct 2018 08:29:02 AM EDT.
Installed Packages
nautilus-extensions.x86_64 3.28.1-1.fc28 @fedora
python2-gobject.x86_64 3.28.3-1.fc28 @updates
Available Packages
nautilus-extensions.i686 3.28.1-1.fc28 fedora
nautilus-extensions.x86_64 3.28.1-1.fc28 fedora
python2-gobject.i686 3.28.2-1.fc28 fedora
python2-gobject.x86_64 3.28.2-1.fc28 fedora
python2-gobject.i686 3.28.3-1.fc28 updates
python2-gobject.x86_64 3.28.3-1.fc28 updates
...But I'll add some debugging to packagekit.js and see what I can see.
$ sudo dnf list folks
Last metadata expiration check: 2:08:24 ago on Sat 27 Oct 2018 08:29:02 AM EDT.
Available Packages
folks.i686 1:0.11.4-5.fc28 fedora
folks.x86_64 1:0.11.4-5.fc28 fedora
...Oh, right: I forgot that I'd forcibly-uninstalled folks as part of testing this, to see if the Additional Features list would notice. (It didn't.) So, that's why there's no "Installed Version" there. But everything was the same when it _was_ installed, from the GSConnect perspective.
Aha! Progress... after a fashion.
I added debug()s to packagekit.js, and determined that Available and Installable are always equal:
diff --git a/service/ui/packagekit.js b/service/ui/packagekit.js
--- a/service/ui/packagekit.js
+++ b/service/ui/packagekit.js
@@ -351,6 +351,8 @@ var DependencyButton = GObject.registerClass({
available = await this._getAvailable(this.names);
available = available.map(pkg => pkg.get_name());
+ debug("Available: " + available);
+
// None found; show help
if (available.length === 0) {
this._help();
@@ -360,6 +362,8 @@ var DependencyButton = GObject.registerClass({
// Reduce the available packages to those that are uninstalled
installable = await this._getInstallable(available);
+ debug("Installable: " + installable.map(pkg => pkg.get_name()));
+
// All available packages are installed; show done
if (installable.length === 0) {
this._done();
DEBUG: [packagekit.js:_reset:354]: Available: fuse-sshfs,fuse-sshfs
DEBUG: [packagekit.js:_reset:354]: Available: gsound
DEBUG: [packagekit.js:_reset:354]: Available: folks
DEBUG: [packagekit.js:_reset:354]: Available: nautilus-extensions,python2-gobject,python2-gobject
DEBUG: [packagekit.js:_reset:365]: Installable: fuse-sshfs,fuse-sshfs
DEBUG: [packagekit.js:_reset:365]: Installable: gsound
DEBUG: [packagekit.js:_reset:365]: Installable: folks
DEBUG: [packagekit.js:_reset:365]: Installable: python2-gobject,nautilus-extensions,python2-gobject
So then I decided to flip the logic on _getInstallable(), and list the packages that _are_ installed. That works:
diff --git a/service/ui/packagekit.js b/service/ui/packagekit.js
--- a/service/ui/packagekit.js
+++ b/service/ui/packagekit.js
@@ -219,7 +219,7 @@ var DependencyButton = GObject.registerClass({
_getInstallable(names) {
return new Promise((resolve, reject) => {
this.client.resolve_async(
- PackageKit.filter_bitfield_from_string('arch;~installed'),
+ PackageKit.filter_bitfield_from_string('arch;installed'),
names,
null,
() => {},
DEBUG: [packagekit.js:_reset:354]: Available: fuse-sshfs,fuse-sshfs
DEBUG: [packagekit.js:_reset:354]: Available: gsound
DEBUG: [packagekit.js:_reset:354]: Available: folks
DEBUG: [packagekit.js:_reset:354]: Available: nautilus-extensions,python2-gobject,python2-gobject
DEBUG: [packagekit.js:_reset:365]: Installable: fuse-sshfs
DEBUG: [packagekit.js:_reset:365]: Installable: gsound
DEBUG: [packagekit.js:_reset:365]: Installable:
DEBUG: [packagekit.js:_reset:365]: Installable: nautilus-extensions,python2-gobject
Note the disappeared duplicates, and the complete disappearance of folks from Installable (actually "Installed" now), since I don't have any version installed currently.
So, I think _filtering_ installed packages to determine what's not installed doesn't work, at least on Fedora, because an installed package is still also available, and there can be additional non-installed versions available even for an installed package. To determine what's _actually_ installed, that property has to be positively queried, instead of negatively filtered.
Okay, that may work. I think the important thing is to filter out first for distribution, since detecting distributions can get sketchy and I'd rather avoid that.
So, adding newest to the filters fixes the duplicates issue:
diff --git a/service/ui/packagekit.js b/service/ui/packagekit.js
index 8ace8d2..f38ec64 100644
--- a/service/ui/packagekit.js
+++ b/service/ui/packagekit.js
@@ -194,7 +194,7 @@ var DependencyButton = GObject.registerClass({
_getAvailable(names) {
return new Promise((resolve, reject) => {
this.client.resolve_async(
- PackageKit.filter_bitfield_from_string('arch'),
+ PackageKit.filter_bitfield_from_string('arch;newest'),
names,
null,
() => {},
@@ -219,7 +219,7 @@ var DependencyButton = GObject.registerClass({
_getInstallable(names) {
return new Promise((resolve, reject) => {
this.client.resolve_async(
- PackageKit.filter_bitfield_from_string('arch;~installed'),
+ PackageKit.filter_bitfield_from_string('arch;newest;~installed'),
names,
null,
() => {},
@@ -377,4 +377,3 @@ var DependencyButton = GObject.registerClass({
}
}
});
With that set, `available` becomes the list of packages that _can_ be installed to add features:
DEBUG: [packagekit.js:_reset:354]: Available: fuse-sshfs
DEBUG: [packagekit.js:_reset:354]: Available: gsound
DEBUG: [packagekit.js:_reset:354]: Available: folks
DEBUG: [packagekit.js:_reset:354]: Available: nautilus-extensions,python2-gobject,python2-nautilus
As far as "installable", though, the PackageKit docs on Filters (which is on my system in `/usr/share/gtk-doc/html/PackageKit/introduction-ideas-filters.html`, I'm sure it's on the web somewhere too) has this to say about installed versions:
Removing installed versions in search results
When outputting a list of packages, it's important to remove the available package if the same version is installed. This is required, as the user may doSearchName("kernel",filter="none")and only want to return results that can be operated on. For instance, suppose we have installed:kernel-2.6.29.4-167 (installed) kernel-2.6.29.5-191 (installed)And in the remote software sources we have:
kernel-2.6.29.4-167 (fedora) kernel-2.6.29.5-191 (fedora-updates) kernel-2.6.30.1-203 (fedora-updates)If we do
Resolve("kernel",filter="none")we should expect:kernel-2.6.29.4-167 (installed) kernel-2.6.29.5-191 (installed) kernel-2.6.30.1-203 (fedora-updates)If the
kernel-2.6.29.4-167 (fedora)result was returned, this will be in the list of results, and is a valid install target. The user will get very confused why2.6.29.4-167is both installed and not installed.
So, yeah, it sounds like the secret is to query _available_, query _installed_, and then ~intersect them~ subtract installed from available to see if anything remains, which would then be the installable set.
Okay, in that case _getInstallable() should query arch;newest;installed...well, it could be renamed to _getInstalled() or we could do the following all inside _getInstallable():
let installed = await this._getInstalled(available.map(pkg => pkg.get_name()));
installed = installed.map(pkg => pkg.get_name());
let installable = available.filter(pkg => !installed.includes(pkg.get_name()));
Does that seem right to you? The inversions here are bit confusing without being able to test myself :)
As far as the "Untrusted Source" message, I assumed on Ubuntu it was because those packages were coming from Universe or another section not officially supported by Canonical. If that's not a thing in Fedora though, maybe there is extra work I have to do to tell PackageKit who is calling the operations.
Untrusted packages are a thing in Fedora, but all of the packages in question should definitely be part of the "trusted" set, since they're all coming from Fedora's official repos.
The part that really confuses me, though, is that even setting the transaction flags to ONLY_TRUSTED doesn't remove that message. From what I've been able to understand of the API docs so far, it _seems_ as though it should? (It doesn't prevent the transaction from going through, and completing successfully. The auth dialog just still shows that message.)
From: FeRD (Frank Dana) <[email protected]>
Subject: [PATCH] Add ONLY_TRUSTED flag
This does nothing.
---
service/ui/packagekit.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/service/ui/packagekit.js b/service/ui/packagekit.js
index f38ec64..270d926 100644
--- a/service/ui/packagekit.js
+++ b/service/ui/packagekit.js
@@ -244,7 +244,7 @@ var DependencyButton = GObject.registerClass({
_installPackages(package_ids) {
return new Promise((resolve, reject) => {
this.client.install_packages_async(
- PackageKit.TransactionFlagEnum.NONE,
+ PackageKit.TransactionFlagEnum.ONLY_TRUSTED,
package_ids,
null,
() => {},
Okay, in that case
_getInstallable()should queryarch;newest;installed...well, it could be renamed to_getInstalled()or we could do the following all inside_getInstallable():let installed = await this._getInstalled(available.map(pkg => pkg.get_name())); installed = installed.map(pkg => pkg.get_name()); let installable = available.filter(pkg => !installed.includes(pkg.get_name()));Does that seem right to you? The inversions here are bit confusing without being able to test myself :)
It _seems_ right... makes my head spin too, really, but it makes sense to me. And avoids the extra PackageKit query round-trip I was worried might be necessary, to turn a filtered/subtracted set of package names back into package_ids. Guess I'll give it a whirl and see how it works!. :grin:
(TBH, yeah _getInstallable() _could_ be renamed to _getInstalled() with this change. OR, another way to go, _getAvailable() and _getInstwhatever() could be refactored into a _getPackages(names, installed) that takes a boolean argument to switch the filter string. Or even _getPackages(names, filters) with the filter string _as_ an argument. Point is, that filter string is literally the entire difference between the two methods.)
This seems to be the relevant portion of PackageKit emitting this warning:
/* TRANSLATORS: is not GPG signed */
g_string_append (string, g_dgettext (GETTEXT_PACKAGE, N_("The software is not from a trusted source.")));
g_string_append (string, "\n");
/* UpdatePackages */
if (priv->role == PK_ROLE_ENUM_UPDATE_PACKAGES) {
/* TRANSLATORS: user has to trust provider -- I know, this sucks */
text = g_dngettext (GETTEXT_PACKAGE,
N_("Do not update this package unless you are sure it is safe to do so."),
N_("Do not update these packages unless you are sure it is safe to do so."),
g_strv_length (priv->cached_package_ids));
g_string_append (string, text);
}
I also found an old bug that was reassigned to PackageKit from Launchpad:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1638510
Point is, that filter string is literally the entire difference between the two methods.
That's true, let's just go ahead and rename it _query(names, filter) then. Nice and short and there's no point in duplicating code here. It'll be a nice reusable js async function later if needed.
EDIT
BTW, I'm working in shell/gmenu.js right now, so if you're going PR this stuff you might as well strip out all the suggested-action lines.
You seem to have a good grasp here, and you're digging in the code so I sent you push access (as well as @getzze who did most of the hard bluez work). I think simple bugfixes you guys can go ahead and push, otherwise we can just feature-branch and review like normal.
FYI I'm into extension.js, shell/gmenu.js and shell/device.js for what should've been a feature branch at the moment.
You seem to have a good grasp here, and you're digging in the code so I sent you push access (as well as @getzze who did most of the hard bluez work). I think simple bugfixes you guys can go ahead and push, otherwise we can just feature-branch and review like normal.
Cool. I shall endeavor... actually, I won't even be naïve enough to say "I'll try not to break anything".
"I'll do my best to clean up all my own messes," that's a more realistic goal.
FYI I'm into
extension.js,shell/gmenu.jsandshell/device.jsfor what should've been a feature branch at the moment.
LOL, the number of times I've done that...
One nice thing is that git checkout -b <newbranch> basically turns the current branch _into_ a feature branch, with all the history intact. Then, if you haven't pushed, you can git checkout master and git reset --hard <refid> bac to the point where you _should've_ branched off originally. Generally that isn't that big of a deal... _if_ you haven't pushed.
The only thing I'm not sure about is how that would deal with any commits you've merged and pulled _from_ the remote, since that point. I don't know if I've ever tried that. But... git pull_should_ hopefully retrieve them, maybe? ¯\_(ツ)_/¯ Be an interesting experiment...
I had a few hours downtime, but I'm gonna dig into packagekit.js now, I'll take care of the suggested-action removal real quick, then do the _query() refactoring and try to make that new installable logic go...
FYI I'm into
extension.js,shell/gmenu.jsandshell/device.jsfor what should've been a feature branch at the moment.LOL, the number of times I've done that...
One nice thing is that
git checkout -b <newbranch>basically turns the current branch _into_ a feature branch, with all the history intact.
[...stuff...]
¯\_(ツ)_/¯Be an interesting experiment...
Ah, you've already pushed it. #NEEEEEVERMIND ...And as a pair of commits, one tiny one huge, but both dated _five days_ ago! Well, I don't even know what to make of that! :laughing:
Ha, yeah the menu code in GNOME Shell is really convoluted because of all the legacy stuff they have to keep to not break extensions. I basically had to implement nested submenus myself. It took a long time to get it stable, and I think there's one or two quirks left (but non-fatal).
I've got a few more changes to polish up that fix some issues with the battery proxy, but I'm off for some downtime myself :)

Having the same issue on GSConnect 15, GNOME 3.30.2, Manjaro 18.0.0.
__ Built after this commit was merged, per translator instructions.
This means either PackageKit is uninstalled (most likely) or your package manager is not supported. In this case, it's hard to know if these are installed or if/when that changes, so the "Help" ("Abi") link is there pointing to the dependency page.
Unfortunately there's no easy way to install PackageKit without PackageKit :stuck_out_tongue:
It's sort of weird problem, but the best I could think of (so far) is to at least leave the entries there so people know what they might need, and then follow the Help link to figure out whether they already have those packages installed.
Maybe you could at least detect and show a useful error if PackageKit is not installed?
Got it to work, but I agree with @rugk - there should be something useful written when it is not installed, such as
"To detect installed packages, please install PackageKit. Otherwise, you can refer to the wiki and verify the packages manually."
There should be a way to disable the daily notification either way.
There should be a way to disable the daily notification either way.
I agree, but that is/may deserve another issue, does not it?
...What daily notification? AFAICT the previous two comments are the first mention of that in this thread, so I'm not sure what it's referring to.
(But I'll look into detecting a missing PackageKit and failing informatively.)