Cannot open URL's from AppImage #8721
Comments
|
How are you attempting to open the url? Click the link in the preview panel? Double click url in entry view? Ctrl + Shift + U keyboard shortcut? Does this happen for all urls or just ones that are special like cmd:// ? |
droidmonkey
added
distribution: AppImage
more info needed
platform: Linux
and removed
bug
labels
|
it seems to happen on all url
Right click on entry and open url
or
link in the preview panel
or shift control U
Le 31/10/2022 à 13:28, Jonathan White a écrit :
… How are you attempting to open the url? Click the link in the preview
panel? Double click url in entry view? Ctrl + Shift + U keyboard shortcut?
Does this happen for all urls or just ones that are special like cmd:// ?
—
Reply to this email directly, view it on GitHub
<#8721 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBFWRCAG67JF3UA5FPH2VLWF63PVANCNFSM6AAAAAARTAGMYI>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hi, I have the same issue after upgrading from 2.7.1 to 2.7.4 (Linux Mint 20.3).
cmd:// and URL HTTP/HTTPS are concerned. When running AppImage in my terminal I've this error:
Traceback (most recent call last):
File "/usr/bin/gnome-terminal", line 9, in <module>
from gi.repository import GLib, Gio
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in <module>
from . import _gi
ImportError: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
/usr/bin/xdg-open: 869: iceweasel: not found
/usr/bin/xdg-open: 869: seamonkey: not found
/usr/bin/xdg-open: 869: mozilla: not found
/usr/bin/xdg-open: 869: epiphany: not found
/usr/bin/xdg-open: 869: konqueror: not found
/usr/lib/chromium/chromium: symbol lookup error: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
/usr/bin/xdg-open: 869: chromium-browser: not found
/usr/bin/xdg-open: 869: google-chrome: not found
/usr/bin/xdg-open: 869: www-browser: not found
/usr/bin/xdg-open: 869: links2: not found
/usr/bin/xdg-open: 869: elinks: not found
/usr/bin/xdg-open: 869: links: not found
/usr/bin/xdg-open: 869: lynx: not found
/usr/bin/xdg-open: 869: w3m: not found
xdg-open: no method available for opening 'https://github.com'Workaround
cd /tmp
wget https://github.com/keepassxreboot/keepassxc/releases/download/2.7.4/KeePassXC-2.7.4-x86_64.AppImage
chmod u+x KeePassXC-2.7.4-x86_64.AppImage
./KeePassXC-2.7.4-x86_64.AppImage --appimage-extract
then exit KeepassXC.
appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC
/tmp/squashfs-root/org.keepassxc.KeePassXC.desktop: hint: value item "Security" in key "Categories" in group "Desktop Entry" can be extended with another category among the following categories: Settings, or System
Using architecture x86_64
/tmp/squashfs-root should be packaged as KeepassXC-2.7.4-fixed.AppImage
AppStream upstream metadata found in usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml
Trying to validate AppStream information with the appstreamcli tool
In case of issues, please refer to https://github.com/ximion/appstream
org.keepassxc.KeePassXC.appdata.xml
E: ~:~: xml-markup-invalid Could not parse XML data: Entity: line 77: parser error : expected '>'
<release version="2.7.3" date="2022-10-23">
^
Entity: line 1031: parser error : Opening and ending tag mismatch: release line 63 and releases
</releases>
^
Entity: line 1033: parser error : Opening and ending tag mismatch: releases line 63 and component
</component>
^
Entity: line 1034: parser error : EndTag: '</' not found
^
Validation échouée : erreurs : 1
run_external: subprocess exited with status 3Failed to validate AppStream information with appstreamcli
-- </description
++ </description>
++ </release>Fix warnings:
Remove this lines: -- <url type="vcs-browser">https://github.com/keepassxreboot/keepassxc</url>
-- <url type="contribute">https://keepassxc.org/docs#contribute</url>4.1 Create a fixed AppImage ./appimagetool-x86_64.AppImage squashfs-root KeepassXC-2.7.4-fixed.AppImage
|
|
The URL opening issue is some sort of incompatible MIME type handling between Qt and your system. It's reproducible, but I don't think we can fix that. There is a workaround, but not a nice one. See here: #8669 (comment) |
|
Does that meas there is no solution ? |
|
I admit that I have a little difficulty in understanding since version 2.7.1 works correctly. |
|
I think I am affected by the same problem. debian bullseye: KDE neon live cd: endeavour OS live cd: Fedora live cd: garuda live cd: |
|
The problem is this here: #8737 (comment) |
|
But how to explain then the solution proposed by Leepic ? |
By doing this you force the appimage to use your system library. Might as well just use the ppa at that point. |
|
I don't think it's same problem as #8737, more likely a glib incompatible problem. KeePassXC invokes other Applications, but the other Applications have problems with libglib-2.0.so.0 included in the AppImage. Reproduced on Ubuntu 22.10 |
|
Then, is there a solution for this problem ? |
Two ways:
Or, KeePassXC can discard bundle library information when it calls external application, but I wonder if there's simple way to do it. |
|
Hello, |
|
I too am having this issue with Debian 11 KDE. I'm wondering at this point just compile from source and be done with it? I really like the AppImage as it's nice and self-contained. |
|
Use the flatpak.. |
|
Does this mean that the AppImage version will eventually disappear? Thank you in advance for your answers |
|
Hello, |
|
@plegrand1 At this point, this looks like a configuration issue on your system. Does the browser open when you run I'm not sure whether anything can be added to the AppImage to make this work by default, as the specific browser association would be up to each user's system. |
|
I just made a test with xdg-open http://www.google.fr from a shell and it works fine. |
|
The error message you show indicates appimage cannot see your configuration file that defines the default browser. It isn't a keepassxc specific issue. |
AppImage/AppImageKit#124 (comment) might be relevant? |
|
Yup precisely that! |
|
Should the unset command be run once and for all or on each reboot? |
|
Then i made the test From my point of view and my limited knowledge, this is very similar to the original problem. |
|
With 2.7.8 appimage on Debian Bookworm (12), I still get the same error as reported by @clunst here. Undefined symbol is still fixed by removing the mismatched libglib-2.0.so.0 from the appimage and repacking it. This should still be open. Is it tracked elsewhere? |
|
Appimage is a failed standard. Use flatpak |
|
Hello, |
|
It is an answer, maybe not the one you wanted to read. How can we keep fixing problems in appimage that crop up on all these disparate systems? It's a failed solution to the problem of portability, clearly. |
|
FlatPak uses a huge amount of space compared to AppImage and introduces unpleasant issues being more isolated (i.e. cannot access host's fonts, GTK config), which is why I use AppImages when available. It used to work well for KeePassXC too until 1-2 years ago. With that said, if you no longer support AppImages, why release them at all? It creates an expectation that we should report bugs as they are found. That's overhead for you and frustration for us. 😉 Instead, why not work on a static build process (perhaps with musl libc)? I'm not sure if that's easy with C++ but it's quite common with Rust and Go projects for example. Heck I'd contribute to a bounty for that, as it would be cleaner than AppImage (or FlatPak). Edit: It doesn't help that the big green button on https://keepassxc.org/download/#linux links to the AppImage, which tells users that it's the main officially-supported Linux download. |
|
The download page is just that. You don't download flatpaks, snaps, or ppas from a website. You do download appimages. Flatpak shares dependencies so it's only "huge" once. |
|
It would be my only KDE application, with well over 1GB of dependencies so I'm not keen on doing that. 😉 The download page says how to get the software installed locally. It shows all the options, not just the AppImage. Again, why build and distribute an AppImage if it's unsupported? It is frustrating. At least there should be a big bold "provided 'as-is' — please do not report bugs" under the green button so users have the correct expectation going in. It is a reasonable warning to make which I've seen in plenty of open source projects. |
|
I've been using AppImage for years and works fine for what I use it for except I too can't click on URL to send the link to my browser such as Chrome or FireFox. So I've made it as a habit just copy and paste the URL into my browser. It's not a huge deal but it's one of those quirks in the world of Linux. I know the main issue is the Qt library which is broken. Previous version of the Qt library worked without issues till the last update. Another alternative is compile from source which I've done numerous times before. Like I said it's not a deal breaker for me long as other function work such as sending username and password to the browser via the plugin. |
|
Good point @NoahDar I too tend to stick to AppImage despite the bugs because of the overall simplicity of the approach (an executable to drop in Perhaps a short list of known bugs for the AppImage might be more appropriate than a blanket "as-is" disclaimer. That said I'd still be curious to see if a static build (true, not glibc) could be devised to replace the AppImage. I know Qt 5 can play nice with musl libc (there's Alpine builds) so, maybe? |
|
I think this particular bug is actually fixable. A step in the right direction was taken with #10624 by switching to I've pointed earlier at AppImage/AppImageKit#124 (comment) . I don't really know much about AppImages, nor how KeePassXC's AppImage is set up. But my impression is that the change suggested there needs to be done when building the AppImage. This should then allow |
Hello,
since last update (2.7.4), opening url from KeePassXC does not works anymore.
I use Appimage KeePassXC
Debian SID
Firefox 106
KeePassXC-Browser : 1.8.3.1
I made some tests :
Opening URLs does not work with 2.7.3 and 2.7.4 appimage version
It works fine with the 2.7.1 appimage version
Debug Info
KeePassXC - Version 2.7.4
Révision : 63b2394
Distribution : AppImage
Qt 5.15.2
Le mode débogage est désactivé.
Système d’exploitation : Debian GNU/Linux bookworm/sid
Architecture de l’unité centrale : x86_64
Noyau : linux 6.0.0-2-amd64
Extensions activées :
Bibliothèques cryptographiques :
Thanks for your help
The text was updated successfully, but these errors were encountered: