After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725001 - Shows Pitivi as installed when it's not
Shows Pitivi as installed when it's not
Status: RESOLVED FIXED
Product: gnome-software
Classification: Applications
Component: General
3.11.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Software maintainer(s)
GNOME Software maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-02-23 14:11 UTC by Stephen
Modified: 2015-05-27 09:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Stephen 2014-02-23 14:11:41 UTC 
Using Software 3.11.90 on a fresh install of Fedora 20 + Gnome 3.12 Copr (http://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/) Pitivi shows as being installed at version 0.15.2 when it isn't installed at all. yum/dnf info pitivi shows 0.92 and 0.15.2 available.

After installing pitivi 0.92 via dnf, Software still shows 0.15.2 as installed.

On a different machine with Gnome/Software 3.10 without Pitivi installed, Software correctly shows it as not installed with 0.92 available.
Comment 1 Richard Hughes 2014-02-25 10:12:41 UTC 
Do you perhaps have pitivi installed locally or using jhbuild?
Comment 2 Stephen 2014-02-25 11:43:50 UTC 
No. Installed F20 fresh from an ISO on a USB, everything since installed using yum, added the Gnome 3.12 repo via Copr, Pitivi not previously installed at all.
Comment 3 Richard Hughes 2014-04-07 16:04:50 UTC 
So it could be that the state of pitivi is being cached by gnome-software. I'll ask the dnf guys about this now.
Comment 5 Rafal Luzynski 2015-05-27 08:57:09 UTC 
I mark this bug as fixed after an IRC conversation with Richard. It's still true that there is no direct synchronization between PackageKit and dnf database so we still need a dnf-packagekit plugin as a general solution. But there is a workaround in packagekitd which reaches the RPM database and provides a reliable information for GNOME Software whether a package is installed or not. GNOME Software now (usually) requires packagekitd to be running so this particular issue will not occur again.