I'm on #Fedora#Silverblue 40, and I'm now seeing a lot of "No video with supported format and MIME type found" errors.
I don't have mozilla-openh264 installed, so I guess that might make sense? Let's fix that...
# rpm-ostree install mozilla-openh264<br></br>...<br></br>error: Could not depsolve transaction; 1 problem detected:<br></br> Problem: package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System conflicts with openh264 provided by openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264<br></br> - package openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 obsoletes noopenh264 < 1:0 provided by noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from @System<br></br> - package mozilla-openh264-2.4.0-2.fc40.x86_64 from fedora-cisco-openh264 requires openh264(x86-64) = 2.4.0-2.fc40, but none of the providers can be installed<br></br> - conflicting requests<br></br># rpm -qa | grep noopenh264<br></br>noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64<br></br># rpm-ostree install --uninstall noopenh264 mozilla-openh264<br></br>error: Package/capability 'noopenh264' is not currently requested<br></br>
There's clearly something I don't understand here. I don't know how noopenh264 is installed but not requested and still causes a conflict. I must be alone in having this problem based on lack of bugs that I can find in RH's bugzilla.
I don't think I saw this problem on Silverblue 39, but I was using that for only a few days before rebasing on 40, and was previously on my "classic" Fedora 39 installation where it definitely wasn't showing up with the rpmfusion packages installed.
@mcdanlj we're aware of this, but it's awkward - https://pagure.io/workstation-ostree-config/pull-request/508 . this kind of awkwardness is a lot of the reason the atomic desktops still aren't more prominently pushed yet, we know there are still some awkward edges to sand off.
@adamw Thank you! I'm grateful for the immutable/atomic work, and I've been through some sanding off rough edges before... It's worth a few of those for the benefits. ☺
@notting@adamw I understand why flatpak means "start your config over from scratch or move files around" but it's still a pain. I'd really like it if flatpak had a declarative way to offer to auto-migrate existing configuration. That might make me take it more seriously.
@mcdanlj@notting@adamw It would definitely be nice if Firefox as a flatpak could import from traditionally packaged Firefox
...but if you want what you have in RPM Firefox in Flatpak Firefox for yourself, you can move or copy your ~/.mozilla/firefox/ to ~/.var/app/org.mozilla.firefox/.mozilla/firefox/
(I'm not saying this is a proper solution, just that this is a workaround for anyone familiar with command lines.)
@garrett@notting@adamw Right, I can figure this out on a case by case basis. But it's not something that's reasonable to ask of all users generally. If part of the flatpak spec was where the configuration lives outside flatpak, then flatpak itself could offer to move (or copy) configuration when installing a flatpak for which existing "legacy" configuration existed.
It's somewhat analogous from an end user experience point of view to how browsers offer to import your data from other browsers. But done instead across locations for the same app, and configured declaratively so that it's implemented once in flatpak itself. The app itself literally can't do that because the whole point of the restriction is the additional sandboxing, as I understand it...
@mcdanlj@garrett@notting that's an interesting idea, not sure I've heard it floated before...not sure who to pass it on to, maybe mcatanzaro or @siosm ?
@adamw@mcdanlj@garrett@notting The Firefox Flatpak could do that, but not automatically. It could show the path that the user would have to pick manually in the file picker to import an existing profile from the host.
@siosm@adamw@garrett@notting my expectation wouldn't be moving just one profile. It would be the entire configuration. That by it declaring a set of one or more more (source, destination) pairs of paths, when installing any flatpak, you would be given the option of moving the config, and possibly on uninstall the option of moving the config back. This would be for any package that declared these pairs, and not specific to Firefox.
@mcdanlj@adamw@garrett@notting That could indeed work and that should live in Flatpak code directly. But that creates all sorts of new questions: What happens if I want both the system one and the Flatpak one to work and have independent settings? I use the host Firefox for some things and the Flatpak for others as both have limitations. So it would need work. Best path forward would be to open an issue on the Flatpak git repo on GitHub.
it would by default be user-controlled and prompted
if the target did not exist, the default would be to copy from the source to the target
if the target already existed and was newer than the source, the default choice would be not to copy the files, and a choice might not be presented
if the target already existed and was older than the source, the default could be to copy over it, with explicit permission from the user
This would reasonably handle both a migration from native to flatpak and simultaneous usage, and not require users to search for information on configuration files to have a seamless move.
@siosm@mcdanlj@adamw@garrett@notting dunno, doesn't seem like a problem worth solving. we're gaining support for flatpaks in the default install. You still might have to change from a fedora to a flathub install but all the configs will be at the right place.
@siosm@swick@adamw@garrett@notting It's definitely not only Firefox. I first ran into this with FreeCAD, as it happened. But it could easily have been anything. Almost everything stores configuration. Why would this be specific to Firefox?
@mcdanlj@swick@adamw@garrett@notting Yes, it can be useful for any app but the most common case is Firefox as it's currently installed in the base image in Fedora Atomic Desktops. Other apps are expected to be installed as Flatpaks directly.
In all cases, this is better tracked in an issue on GitHub. This will get lost if this remains a thread on Mastodon.
@siosm@swick@adamw@garrett@notting I'm not ignoring this, by the way — my idea is to use this thread of conversation to think through and do a better job of writing up a more coherent feature suggestion.
@mcdanlj@siosm@adamw@garrett@notting when do you sync? Only on the first time the flatpak app is run? Installed? What if the config doesn't make sense for the flatpak version? This seems like a shit ton of complexity and edge cases for little gain.
@swick@siosm@adamw@garrett@notting I would suggest this only when a flatpak app is installed or uninstalled, thus the "source" and "target" language I used. (You might reasonably also suggest a separate capability for users to choose to initiate this at any time if they so desire, but that's not part of what I have been suggesting.)
If the config doesn't make sense to copy for some particular app, then it would be a bug to declare such an equivalence using this suggested feature. But this is not a normal case.
It is not complexly specified, so complexity would be an unnecessary aspect of implementation.
Calling this "little gain" and crudely dismissing it is discouragingly dismissive, and devalues the work that users have done in developing their preferred configuration. ☹️
If it were declared, then at the very least, users could get information in a consistent way about how to preserve their configuration, and not have to hope that they found the right stack overflow answer when they do a web search. The question of whether to automate copying could reasonably be a separate conversation from making a consistent record of equivalent paths for configuration. But the possibility of such a feature could add rationale for implementing the record in the first place.
@mcdanlj@siosm@adamw@garrett@notting it is completely possible that a config that works when the app runs on the host doesn't work when the app runs in flatpak. The same app could have configs that work in both cases. What to you do now? I'm not dismissing the idea for no reason but because I cannot see how this would work well.
FreeCAD has plenty of paths in configuration. Some of them might not work and still need fixing. It would still be better than starting over entirely from scratch, speaking as a user.
Please feel free to describe specific examples where you feel that this would be damaging so we can have a conversation about specifics rather than sweeping generalities.
@adamw@mcdanlj@garrett@notting@siosm It seems like it should be possible to rsync the ~/.mozilla profile data over to the ~/.var/app/org.mozilla.Firefox profile location, assuming the flatpak Firefox version is >= the rpm version.
Add comment