Firefox 66.0.2 breaks on unresolvable dependencies

I seen the new " Firefox package renamed since 66.0.2" but I can’t write there.

Updating Firefox breaks here with unresolvable dependencies: firefox-i18n

[frank@pc ~]$ LC_ALL=C sudo pacman -Syu
[sudo] password for frank: 
:: Synchronizing package databases...
lib32 is up to date
core is up to date
desktop is up to date
gtk                                                                                                  141.8 KiB  2.77M/s 00:00 
[############################################################################] 100%
:: Starting full system upgrade...
:: Replace firefox-kde with gtk/firefox? [Y/n] 
resolving dependencies...
warning: cannot resolve "firefox-kde=66.0.2", a dependency of "firefox-i18n"
:: The following package cannot be upgraded due to unresolvable dependencies: firefox-i18n

:: Do you want to skip the above package for this upgrade? [y/N] y
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing firefox-kde breaks dependency 'firefox-kde=66.0.1' required by firefox-i18n
:: installing firefox-i18n-de (66.0.2-1) breaks dependency 'firefox-langpack=66.0.1' required by firefox-i18n

dam,

sry, life sucks when I overlooked the lines about firefox-i18n

Thougt that we only have firefox-i18n-* packages.

After the update when for example right clic an image and save as, nothing happens, no dialog to save the image. For this I downgrade to firefox-kde. Thanks

1 Like

To complement JC’s Post, the terminal output while trying a link / image with the “save as” to save:

(firefox:17229): Gtk-WARNING **: 17:49:26.784: 
  Can't open portal file chooser: 
  GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
  The name org.freedesktop.portal.Desktop was not provided by any .service files

Strange, saving pictures works fine for me in FF 66.

The save-as is still broken in firefox-66.0.2-3

-4 uploaded, please try.
I have to make xdg-desktop-portal hard depends

3 Likes

thank you brli
with …-4 “save as” in firefox is working for me.

Solved the issue for me too. Thanks!

Hmm, i’m tried to install flatpak some days ago but it failed, that’s why i have that package. It’s strange, Arch’s firefox package did not depends on it.

Arch’s Firefox doesn’t enable this feature by default, and currently has no strong motivation on it (They put the HowTo in Wiki).

Since we’re KDE-centric distro, I decide to provide this by default in our package, thus the xdg-desktop-portal becomes permanent dependency of our firefox.

2 Likes

does we need xdg-desktop-portal as hard dependency? i think not because it exist a similar package xdg-desktop-portal-kde

one pic is with xdg-desktop-portal-kde and without with xdg-desktop-portal and the other with xdg-desktop-portal and xdg-desktop-portal-kde, do you notice a difference?


a propos firefox do you know about LTO?
Link Time Optimization slim binaries and improve performance.
palemoon is a slim fork from firefox

-rw-r--r-- 1 tom tom 36591088 15.03.2019 15:14 palemoon-28.4.0-1-x86_64.pkg.tar.xz
-rw-r--r-- 1 tom tom 41316836 23.02.2019 10:18 palemoon-bin-28.4.0-1-x86_64.pkg.tar.xz

the lto compiled packages is 12% smaller then without lto

Here in Taiwan, we are bombard with retarded Fake News™ produced by pro-China media and Chinese their own.

With this daily life, I HATE that when people talking about things that are just misleading.

Usually I would use some real strong words, but OKAY, let’s be kind.

  1. the relation between xdg-desktop-portal and xdg-desktop-portal-kde is like what’s between phonon and phonon-backend-gstreamer, check what you’ve installed with pacman -Ql <package name>

  2. the usage of xdg-desktop-protal has NOTHING to do with your GUI, it is all about how firefox handle signals with your OS, try to dowanload ANY pictures from within firefox with your two settings again, better run firefox from konsole, so that you’ll notice the difference.

  1. There is no reason to compare a different browser with firefox
  2. There is no objective measures between a self-built package and a upstream-provided binary.
  3. Well, IN FACT, even the same configuration compiled with the same computer, the package size differs from KB to MB, and you can easily tell the packages are different by comparing the hashsum of binary and lib files in the packages.
  4. If you ever check how the delivered packages are born (what we, as packager provided), you should long noticed that we provide LTO for a long time, when we start to use Clang instead of GCC as compiler.
1 Like

feindsender …like a fly on the wall, it seems a really unfair competition :wink:

ok