Brief Description
Attempted install of Chrome due to Chromium crashing. GDebi will install from Software but not launch
Versions of Hardware/Software
Librem 13 v2, PureOS 8, updated as of today
Reproduction Steps
Attempted multiple times. Restarted software.. Restarted Librem.
Expected Behavior (Expected Result)
Launch of Gdebi
Current Behavior (Broken Result)
Gdebi would not launch
Hi @james.rufer
I can't seem to reproduce this. gdebi installs fine for me, and launches fine both from the Applications menu and from the command line. Can you clarify exactly how you are trying to run it? Note that gdebi-gtk is the command, not gdebi.
Software reports that gdebi is installed but will not launch. It is not in the menu nor does it launch from terminal. Uninstall and reinstall from software produces the same result.
Can you clarify what you mean by "Software reports that" and exactly what happens when you attempt to run it from the terminal? (ideally eg. pastebin the output, screenshots, etc.)
Software has "launch" and "remove" listed as options so it reports that it is installed.
Terminal:
ames@Librem13v2-Enterprise:~$ gdebi-gtk
Could not find the database of available applications, run update-command-not-found as root to fix this
gdebi-gtk: command not found
james@Librem13v2-Enterprise:~$ su
Password:
root@Librem13v2-Enterprise:/home/james# gdebi-gtk
Could not find the database of available applications, run update-command-not-found as root to fix this
gdebi-gtk: command not found
root@Librem13v2-Enterprise:/home/james# update-command-not-found
root@Librem13v2-Enterprise:/home/james#
Software has "launch" and "remove" listed as options so it reports that it is installed.
Interesting. Looks like Software is lying to us! Can you provide the output of:
$ dpkg -l gdebi root@Librem13v2-Enterprise:/home/james# $ dpkg -l gdebi
Could not find the database of available applications, run update-command-not-found as root to fix this
$: command not found
@james.rufer The "$" is not part of the command but rather the prompt. Please re-run without the "$" prefix.
I have been able to reproduce this issue.
Installing gdebi from Software manager install package gdebi-kde :
Gdebi Directory on PureOs repo
Desinstall gdebi from Software Manager
Then install the TRUE gdebi package from command line (root) :
apt install gdebi
You can now launch gdebi from Menu or from command line :
gdebi-gtk
Issue to be solved : Install gdebi from Software Manager should install "gdebi" package instead of gdebi-kde
Installing gdebi from Software manager install package gdebi-kde :
Gdebi Directory on PureOs repo
You are manually downloading the deb here?
No I wanted to precise the fact that if you are trying to install gdebi from Software Manager - which was james.rufer operation if I understood well - will lead of the installation of the "gdebi-kde" package from pureos repo.
Then I wanted to point this gdebi directory in pureos repo to show the several gdebi packages to james.rufer in case he was not familiar whith apt-cache operations.
The operations I am suggesting him to try to solve the issue are :
Then I made a suggestion for pureos team to solve this issue in a broader way :
@mak Can you help me out here? I spent some time poking appstream but as the "expert" (!) I think you might be able to help me out. I'm trying to work out why gdebi-kde takes precedence over the other when generating the metadata file that eventually ends up in /var/cache/.../C.gvz. The difference in the .desktop files is "only" https://gist.github.com/lamby/29ec4e27ac28e34efe6489de0b1e4f8a/raw but not sure about the "which one to pick" rule. Any tips/pointers? Thanks
@chris.lamb Hmm... There is no "precendence" system, both apps should show up in the software center with a .desktop file like this (although we potentially should do something about OnlyShowIn apps that only list one DE).
On PureOS, we don't export the AppStream generator hints anywhere unfortunatey, a fact that I should change. Debian, however, does export hints, and there you can see https://appstream.debian.org/sid/main/issues/gdebi.html - the icon "gnome-mime-application-x-deb" isn't found. This is maybe related to that icon being a mimetype icon (it's technically legal by the XDG icon spec to load mime icons for apps, and the AppStream generator honors that, but from an UI standpoint I think it's a terrible idea to make an app assume the icon of a filetype - maybe our generator should actually stop that practice).
The gdebi-kde package references a different icon, which is found by the generator, so it shows up. This could be related to the icons being symlinks, but I actually need to look into that.
In general, something really weird is going on here, since on Debian, the gdebi-kde package has an error hint on its application, claiming that no icon was found, and yet, an icon and extracted data show up - this is a state that actually can't happen, especially not for a package that did not receive any upload since 2016.
So, it's not just you who is puzzled, I will look into this a bit deeper later when I am done with most of the infrastructure work.
The other - unrelated - issue is that gdebi-kde and gdebi-gtk both claim to be "GDebi", so when this is fixed, we will just have two gdebis in the software center, which is also not cool. I might implement a generic solution which will just exclude an app if it only has a .dektop file (and no metainfo file) and only lists one DE in its OnlyShowIn field (with the effect of GDebi not showing up at all, until its maintainers add a metainfo file, determine some "default" GDebi, or give both GUIs slightly different names and drop the OnlyShowIn directive).
On a related note: I actually don't think anyone should be using gdebi in 2018 ;-) GNOME Software can install .deb packages, and gdebi has its own, not very well maintained resolver for package dependencies, while everyone else is using APTs new native support for local package installations. So, gdebi would need some serious work to be updated (doesn't mean that it doesn't work at time, but with every year of super-low maintenance, the break risk doubles).
Great. I've filed a bug against Gdebi in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887056
I actually don't think anyone should be using gdebi in 2018 […]
Well, I agree! ::p
So it is! Can't believe I didn't catch that. Been away a few days sick and catching up. Here's what's produced without it:
root@Librem13v2-Enterprise:/home/james# dpkg -l gdebi
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend | |
| / Err?=(none)/Reinst-required (Status,Err: uppercase=bad) | |
| / Name Version Architecture Description | |
+++-==============================================-============================-============================-==================================================================================================
un gdebi <none> <none> (no description available)
Yes Alex, this install worked and yes, you also identified the problem coming from Software over command line install.
On a related not: I actually don't think anyone should be using gdebi in 2018 ;-) GNOME Software can install .deb packages,
This is a good point....
Perhaps we should make this the default option in PureOS for third party .deb installs as opposed to sending average end users down the terminal, synaptic, archive manager, gdebi paths etc. etc., as options.
@james.rufer Thanks for your response - as you can see from the recent history this specific issue is being resolved.
Perhaps we should make this the default option in PureOS for third party .deb installs as opposed to sending average end users down the terminal, synaptic, archive manager, gdebi paths etc. etc., as options.
It surely is right now? Or: can you explain why/where you think/see otherwise? :)
It's not for third party .debs. There are three noticeable things:
Oh? GNOME Software should register for the deb package mimetype... So, I wonder what went wrong there...
This is a pretty long standing issue for me under PureOS, getting third party .deb files to install consistently. I'm wondering if we even need to have Archive Manager as a preinstalled application and shouldn't just remove it, leaving Software as the only option for installing third party .debs.
You surely want a way to open compressed zip/tar.gz/tar.xz etc. archives in the default install.
Ideally, Software would automagically open and install third party .debs and no one would have to even worry about gdebi or Archive Manager wanting to install the app.
.tar.bz2 files are not installable packages, they are just compressed archives like .zip/.tar.gz/.tar.xz files. They are to be uncompressed with an Archive Manager, and can't be installed with a tool like GNOME Software.
Renamed back and filed the 'default' issue as https://tracker.pureos.net/T364. These are two seperate issues AIUI.