#8

Are you running Silverblue in a VM?

#9

Yes, but that is not what is causing Julian’s error.

#10

You will note I didn’t say it was.

2 Likes
#11

Hello,
For enabling repos for rpm-ostree to layer I would think you need to do it with ostree remote add. To import the keys you would use ostree remote gpg-import. Remember to use rpm-ostree cleanup -m before executing an installation of a layered package.

#12

Wouldn’t this expect an OSTree repo, not an RPM repo?

#13

I guess it would, uh nevermind… although you can install local rpm’s as layered pkgs

1 Like
#14

BTW, in this case, the better solution may be to just use the Flatpak of VS Code or actually OSS Code.

Also note: VS Code is governed by the Microsoft EULA and thus legally said, proprietary. (and has some tracking and this feedback button enabled)
While OSS Code is the name of the actual source code you can find on GitHub and in flathub’s case, they compile it from source.

So here are the links:

Developing applications using Flatpak-packaged editors/IDEs
#15

In general, I agree with you, but I again want to refer to this link (Developing applications using Flatpak-packaged editors/IDEs). There are more examples, why flatpak is not yet an alternative for general purpose IDEs.

#16

Thanks for the pointer and I understand the concern. However, IMHO, this is the wrong way to solve the problem.

What you do: Just going back to the “old” technology, because it does not work.
What should be done: Fix the “new” technology, so it works.

In a more specific way here, e.g., there is actually a way to make it work as flatpak is pretty flexible and with the correct privileges you can make apps break out of the sandbox to run commands on the host. This is usually all, it needs to fix the usual problem.

Unfortunately, it needs a little setup, but it’s possible. Actually, I’ve now explained it in detail in the thread you linked:

1 Like
#17

I will look, into your wrapper script. If it works as expected ( flatpak probably provides even easier solutions in the future) this would eliminate my need for rpm repos.

Thank you!

#18

Okay,

So there is basically no difference between an ‘OSTree repo’ and a standard package repo from everything I have read. and in practice If I enable a repo for my system to layer a package, it must be done with the command I mentioned, as well the gpg key import too. This is the only way I am aware of to enable a repo for Silerblue to use.

#19

It is a good thing to note that Silverblue 30 Beta will likely still have toolbox issues as I have been unable to run mine since I upgraded from F29SB. I cannot access my previously created fedora-toolbox container that I made with F29SB, and I cannot create any containers in F30SB (prebeta) without using sudo. Even though toolbox creates a container as sudo, I cannot use it as my user since my UID is wrong for the container rights, and it messes up the home directory rights etc…

#20

For accessing the F29 one, does --release 29 not work?

#21

I’ve always just dropped them in /etc/yum.repos.d, which works since rpm-ostree uses libdnf anyway.

OSTree repos are pretty different, I’m somewhat surprised adding an ostree remote for this worked…

#22

I actually haven’t tried it since I am pretty much focused on something else at the moment. By --release 29 I assume you are meaning for an option argument for toolbox, I haven’t tried and have deleted the F29 container before I read this comment (face palm). Anyway, I’m not too worried about toolbox most times, just when I need it, I need it. So I spun up a small container for my purposes when I couldn’t use fedora-toolbox, I can do the same for this situation.

1 Like
#23

Sorry, I haven’t actually done it for standard repos. So you are likely correct, and the /etc/yum.repos.d method makes perfect sense for the ostree based system.

#24

For me it works now with latest FSB30. But you must not use sudo.

#25

Yeah, it’s still broken on my SB30 Beta rebase, so something I have layered no doubt.

#26

Visual studio code now fully support snap packages.

Is there any reason to assume that snaps are not functional on fedora silverblue?

#27

Snaps usually don’t play well with SELinux, at minimum.

1 Like