#10

I’m trying the cleanup -m - no way I’m uninstalling gnome-tweaks :wink:

#11 
sudo rpm-ostree cleanup -m
sudo rpm-ostree rebase fedora/29/x86_64/silverblue 2>&1 | tee rebase-29-log
1 metadata, 0 content objects fetched; 569 B transferred in 1 seconds
Checking out tree 478cb22... done
Enabled rpm-md repositories: fedora updates
Updating metadata for 'fedora': 100%
rpm-md repo 'fedora'; generated: 2018-09-11 16:03:23
Updating metadata for 'updates': 100%
rpm-md repo 'updates'; generated: 2018-02-20 19:18:14
Importing metadata 100%
Resolving dependencies... Forbidden base package replacements:
  gnome-shell-extension-alternate-tab 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-classic-session 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-common 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-window-list 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-apps-menu 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-places-menu 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
  gnome-shell-extension-launch-new-instance 3.30.0-1.fc29 -> 3.29.91-1.fc29 (fedora)
failed
error: Some base packages would be replaced
#12

I had tried, and it didn’t work…

#13

There’s a GNOME Tweaks Flatpak instead.

#14

I couldn’t find it - I did find Calibre though :wink:

#15

This is https://github.com/projectatomic/rpm-ostree/issues/415
which was one of the (but not the only) major driving issues forming the work on rpm-ostree rojig♲📦.

#16

I’ve run into this again installing some headers required to build some R packages. Since I’m beta-testing here, I tried rebasing to fedora-workstation:fedora/29/x86_64/testing/silverblue and the installs now run. Am I going to run into trouble doing this?

#17

You should be fine. Wait about a week and rebase back to the fedora/29/x86_64/silverblue ref and you should be good.

#18

It’ll probably be more like a month - I’ve got a few projects I need to bang out that don’t involve containers.

#19

I have been running into this issue from time to time as well, this time I am getting

Resolving dependencies... Forbidden base package replacements:
  libgomp 8.2.1-5.fc29 -> 8.2.1-4.fc29 (updates)

Can this be affected by the number/type of layered packages I install. Maybe related to the rpm sources of my layered packages and the silverblue upstream not in sync?

The last time the problem just disappeared (so I am thinking of some sort of “not on sync” issue) but I would love to get some pointers to investigate or better avoid this issue.

This is the list of layered packages I have:

chromium docker gcc git i3 i3lock jq keychain mysql neovim npm pavucontrol postgresql pv python3-neovim redis the_silver_searcher tmux xautolock xclip yubioath-desktop zsh and I also have one local package (rofi-1.5.1-2.x86_64).

#20

I recall using rpm -q --whatrequires package, though it wasn’t always perfect.

#21

Thanks, now I know it is due to the layered gcc which is probably not that uncommon on dev environments I suppose?

#22

did you try to use fedora-toolbox instead of layering packages for dev “stuff”?

#23

Not yet but thank you for the pointer! Our project setups still rely on docker-compose and so docker so it will probably be hard to move these into containers I suppose. I would love to be able to get rid of most of these overlays but one step at a time.

#24

FWIW if you’re doing app development, you can also do stuff inside a Flatpak SDK (you can enter one via flatpak run --filesystem=home org.freedesktop.Sdk or flatpak run --filesystem=home org.gnome.Sdk). If you’re using GNOME Builder it’ll automatically take care of building inside a Flatpak.

2 Likes
#25

I need the GCC for native library bindings (in ruby and in go). As of today the issue no longer exists and I can just run rpm-ostree upgrade without any issues.

Would still like to find out what the root cause of all this is and if issues like this one will occur frequently. Not big of a deal though.

1 Like
#26

How did you determine these were the issues?

I am on a fresh install of Fedora IoT. The first thing I did was “rpm-ostree upgrade” and “systemctl reboot.” Then I tried “rpm-ostree install gcc” and I get the following error…

"

Checking out tree c9b381a… done
Enabled rpm-md repositories: fedora-modular updates updates-modular fedora

<…Shortened, as I’m typing this out…>

Forbidden base package replacements:
libxcrypt 4.4.4-1.fc29 -> 4.4.4-2.fc29 (updates)
Resolving dependencies… done
error: Some base packages would be replaced

"

The output from “rpm-ostree status” is:

ostree://fedora-iot:fedora/stable/x86_64/iot
Version: 29.20190317.0 (2019-03-17T12:02:20Z)
Commit: c9b381…
GPGSignature: Valid signature by C2A3FA9DC…

ostree://fedora-iot:fedora/stable/x86_64/iot
Version: 29.20181206.0 (2018-12-06T16:57:28Z)
Commit: 12c4e6…
GPGSignature: Valid signature by C2A3FA9DC…

I don’t require you to debug this for me. I’d like to do the same debug method you did to get gcc installed on a fresh Fedora IoT install. Before doing “rpm-ostree install” I tried this on the 12c4e6 tree and had even more conflicts than just for libxcrypt. I’ve done “rpm-ostree cleanup -m” as suggested here as well with no effect.

#27

In this case you should probably rpm-ostree install toolbox and then use toolbox for your development environment.

#28

Removed comment. I thoroughly messed up my environment. Please do not follow my lead using “rpm-ostree override”. I didn’t realize the repercussions of my actions until I understood the rpm-ostree deployment strategy.

#29

In general, stuff like gcc goes a bit better running inside toolbox, which sets up a normal Fedora Workstation environment inside a container.