What is the recommended formula setup for contributing to qusal & qubesos?

[kennethrrosen]

Commitment

I confirm that I have read the following resources:

• How to troubleshoot Qusal
• How to ask questions The Smart Way
• Writing the perfect question
• Question checklist
• Could you please make my preference the default?

Question

In reference to the thread below; a user would like to contribute regularly (or once) to qusal or the QubesOS project. What are the recommended steps and formulas and dom0/U changes one should take assuming the user starts with the dev formula?

You don't need the sys-git to use dev. You need the sys-pgp though to verify commit and tag signatures though, because I enforce it with merge.verifySignatures (git configuration), although you verification of pgp keys is done locally, when you need to sign, you will need the sys-pgp setup. You will also need qusal.ConnectTCP, see sys-net/README.md to install the sys-net.install-proxy on the desired netvm, as dev does not have a netvm. If there are more questions, please open a new question issue for others to see it in the issue section instead of the PR section.

Originally posted by @ben-grande in https://github.com/ben-grande/qusal/issues/75#issuecomment-2186827657

.

[ben-grande]

You will need:

• dev - for development, I recommend installing user's preferred editor, as only Vim is installed.
• sys-pgp: for signing commits.
• sys-ssh-agent for split-ssh setup. Read security limitations, it is not "perfect".
• qubes-builder for building Qubes components and Qusal in the future (not ready yet, in development).
• sys-net.install-proxy: can be on any netvm, to provide the dev qube with a proxy to access remote SSH servers, including git repositories for example.

Optional but recommended:

• sys-cacher: recommended to speed up package installation.
• mgmt because the management_dispvm needs to be Fedora to work on minimal fedora qubes and this formula guarantees this instead of letting the user at mercy, I instruct the installation of a desired state.

I recommend first trying this setup, it is transparent to the user (if the installation works), there will be (hopefully) no problems. So it is very easy to manage without having to learn many things. After you have used this setup, use your experience to build your custom dev setup. There is no one formula fits all, I don't try to do that, I try to bring the basics that is useful.

Related thread on how to test and run code:

• https://github.com/ben-grande/qusal/issues/68

[kennethrrosen]

Mgmt are already Fedora, so that seems okay. My hangup at present is the sys-net proxy. When installed in the template of my current sys-net, and with the RPC and policies in place, nothing will connect. Moving current sys-net to sys-net-old then running the formulas is no good, either, as the PCI devices through which connectivity is served exists on sys-net-old but are needed by the new sys-net to download packages. That is where I'm stuck now.

[ben-grande]

The qube sys-net don't need to be created, only target the template of the netvm you want to use as the proxy with sys-net.install-proxy:

Assuming the template of sys-net is fedora-40:

sudo qubesctl --skip-dom0 --targets=fedora-40 state.apply sys-net.install-proxy

When installed in the template of my current sys-net, and with the RPC and policies in place, nothing will connect.

Please see https://github.com/ben-grande/qusal/issues/61 for debugging.

Moving current sys-net to sys-net-old then running the formulas is no good, either, as the PCI devices through which connectivity is served exists on sys-net-old but are needed by the new sys-net to download packages. That is where I'm stuck now.

Can you share all the commands and outputs?

Intended workflow:

1. Open Qube Manager, rename sys-net to sys-net-old.
2. Start sys-net-old and check if DNS is working
3. Proceed with qubesctl commands

PCI devices can be attached to multiple qubes, such as sys-net and sys-net-old. What can't happen is both qubes powering on when they have the same PCI devices attached. Another problem you may be facing may be due to no-strict-reset. Does your network PCI card requires this qvm-pci option? You can check if it is set with qvm-pci list.

[kennethrrosen]

Restarting mirage cleared the issue with the sys-net not connecting with the proxy installed in its template.

[ben-grande]

Restarting mirage cleared the issue with the sys-net not connecting with the proxy installed in its template.

What is your mirage version? Was it deployed by Qusal?

In dom0:

cat /var/lib/qubes/vm-kernels/mirage-firewall/version.txt

Latest version is v0.9.1.

Beginning in v0.9.0, it is possible to recover from a netvm change. Maybe shutdown of upstream netvm and wait till restart, it cannot recover from this state yet. Maybe report an issue upstream if using the version equal or above v0.9.0.