[Devs] Time Estimates for officially-accepted, user-contributed QubesOS packages

User Support General
1

Can someone with experience developing packages in Qubes help me estimate the time required to develop a new package for Qubes?

I have good news: NovaCustom (the Qubes-certified laptop manufacturer) has offered to provide funding to BusKill (the FOSS laptop kill cord project) to develop a package to make it easier to install BusKill on QubesOS.

First, Wessel (the founder of NovaCustom) has asked me to provide an estimate (in dollars/hours) for how much time we expect it to take to make a BusKill package for QubesOS. I’ve never built a package for QubesOS, so I began doing some research – but I couldn’t find much useful documentation on how to actually make a software package for QubesOS, nor how much time I should expect it to take.

Because I haven’t built a QubesOS package before, I was thinking of offering this funding to the QubesOS community. Is there anyone here who would like to be paid to develop a BusKill package for QubesOS? If so, what is your estimate for the number of hours that this would require?

The end-deliverable would be that any QubesOS user would just have to type one command in dom0 to install BusKill, eg:

qubes-dom0-update qubes-buskill

I think the actual work would be fairly minimal. All of the software is already written. All that’s needed is to package it into something that will:

  1. Put an 11-line file on sys-usb:/etc/udev/rules.d/buskill.rules
  2. Put a symlink on sys-usb
  3. Run a command on sys-usb
  4. Update sys-usb:/rw/config/rc.local
  5. Put 5 files on dom0 (longest is 275 lines)

The manual process (including all of the files and commands needed to run to complete the installation) is described here:

At first I thought this would be done with salt, but I couldn’t find a clear guide describing how to write and test a basic “hello world” package for QubesOS, and then how that translates into something like qubes-dom0-update qubes-buskill (without requiring the user to have to download our salt files from a third party site, which would defeat the purpose)

I read the documentation on contrib packages, but that left more questions than answers. The majority of the example repos of existing contrib packages have no README.md file. Of the majority that do, their install instructions are something like clone this repo, then copy files which kinda defeats the purpose. I found only one with a reasonable install instructions that would meet our needs, but I couldn’t find one that simply did put file A in dom0:/path/to/x and put file B in sys-usb:/path/to/y.

What I really need is a guide describing how to fork & edit the qubes-skeleton repo into a qubes-hello-world repo, and then how to test an execution of the new qubes-hello-world package (showing me very clearly what commands I need to execute in dom0 to run the install of the contrib package qubes-hello-world).

Anyway, most importantly, can someone with experience making official contrib packages for QubesOS tell me how many hours they would expect it to take to make this BusKill package for QubesOS?

5 Likes
2

Hey! Thanks for the work on BusKill!

I think this should probably be posted to qubes-devel to get more developers/contributor’s eyes on it.

1 Like
3

Is qubes-devel the google group? Or matrix? Or is that a separate forum here on Discourse?

1 Like
4

Yes, the mailing list / google group

2 Likes
5

done. I’ll post a link to it when it clears the mod queue.

1 Like
6

@fepitre can you add a readme to the skeleton package with info what goes into what file? And may an example what needs to be done to install new file?

2 Likes
7

FWIW, I still haven’t seen anything in the mod queue. Has it been sent yet?

1 Like
8

FWIW, I still haven’t seen anything in the mod queue. Has it been sent yet?

yeah, but I sent it with mutt from my personal domain. Is there a chance that google rejected it prior to entering your mod queue? I’m always getting banned from Google et al. due to false-positives…

Edit: I’m 80% sure I sent it correctly, as I used the same method that I used in the past to post to the qubes user mail group – way back before these Discourse forums existed.

1 Like
9

@fepitre can you add a readme to the skeleton package with info what goes into what file? And may an example what needs to be done to install new file?

@fepitre I’d greatly appreciate if that README included the actual commands that we would need to run for us to actually run a local test install of the modified skeleton repo – before we submit it (blindly) to the Qubes team for review.

1 Like
10

GitHub - QubesOS-contrib/qubes-skeleton: Skeleton package serving as an example of Qubes component. · GitHub take a look at the README now :slight_smile:

2 Likes
11

@fepitre great comprehensive work, thanks!

Dumb question: is there any way to run qubes-inside-of-qubes so that I can test installs of packages in some isolated/disposable environment, without risking my main real dom0 with tests of builds?

Or is the recommended approach that Qubes devs have a whole separate laptop for doing Qubes testing?

1 Like
12

@fepitre So rpm_spec/skeleton-dom0.spec.in is what will run on dom0

And rpm_spec/skeleton-vm.spec.in is what will run on the AppVM named “vm” – is that correct?

So to run something on the TemplateVM named debian-13-xfce, we’d need to create a file named rpm_spec/skeleton-debian-13-xfce.spec.in

And to run something on the DispVM TemplateVM named debian-13-xfce-dvm, we’d need to create a file named rpm_spec/skeleton-debian-13-xfce.spec.in

And to run on sys-usb VM, we’d create a file named rpm_spec/skeleton-sys-usb.spec.in

Is that correct?

If that’s not correct, then where do we define the actual name of the destination Qube that we want to update?

Edit: Oh, no, I think the place where the actual VM is defined by name is in the .qubesbuilder file, which is documented in another repo. Specifically, this examples section was very elucidating

Here is an example for qubes-python-qasync:

host:
  rpm:
    build:
    - python-qasync.spec
vm:
  rpm:
    build:
    - python-qasync.spec
vm-buster:
  deb:
    build:
    - debian
vm-bullseye:
  deb:
    build:
    - debian
source:
  files:
  - url: https://files.pythonhosted.org/packages/source/q/qasync/qasync-0.9.4.tar.gz
    sha256: qasync-0.9.4.tar.gz.sha256

It defines builds for the host and vm package sets for all supported RPM distributions, like Fedora, CentOS Stream, and soon openSUSE with the rpm level key. This key instructs RPM plugins to take as input provided spec files in the build key. For Debian-related distributions, only the buster and bullseye distributions have builds defined with the level key deb. Similar to RPM, it instructs Debian plugins to take as input directories provided in the build key.

I think the docs could be improved if a better .qubesbuilder example were used – including one where vm-debian-12-xfce were used, and indicating that vm just matches to all VMs.

1 Like
13

So, from my last comment, it looks like we’re not matching based on the actual name of the VM. I’m not sure if that’s impossible or if that’s just not recommended.

From: qubes-builderv2/README.md at 39f27fef1449d4e6d4190d2f6377e43fd9485509 · QubesOS/qubes-builderv2 · GitHub

Here is a non-exhaustive list of distribution-specific keys:


    host-fc41 --- Fedora 41 for the host package set content only
    vm-bullseye --- Bullseye for the vm package set only

Can you please link to where we can get an exhaustive list of distribution-specific keys (PACKAGE_SET-DISTRIBUTION_NAME) and any other possible way that we can match to destination VMs?

Of course I don’t expect the documentation itself to provide an exhaustive list, but I do expect the docs to tell us how we can figure out all possible keys ourselves (eg by querying the repo mirrors or by executing some command on dom0 or something)

1 Like
14

Not really unfortunately. I mean, it’s possible to get something running with a bunch of hacks (like switching all VMs to PV virt mode), but it isn’t very reliable.

But, at least VM stuff you can test in any VM, for example create fresh standalone and remove it afterwards. Or even use a disposable.

That’s what we do in practice…

No, it’s a package for any VM with RPM packages - so, Fedora mostly. And for debian there is debian directory that vm → deb key in .qubesbuilder points at.

No, it’s building packages that user can install wherever they want - it’s up to the user to decide where they want it. The .qubesbuilder defines also what kind of packages are built.

List of distributions is configured in the config in the distributions, see for example: qubes-builderv2/example-configs/qubes-os-r4.3.yml at main · QubesOS/qubes-builderv2 · GitHub

But generally, it’s better to use generic host and vm keys (not vm-bookworm etc), so it builds for all of them.

2 Likes
15

@fepitre Can you please add a LICENSE file to the repo?

*add LICENSE by maltfield · Pull Request #4 · QubesOS-contrib/qubes-skeleton · GitHub

Currently it’s unclear if the contents of this repo is copyleft at all.

1 Like
16

Sorry, I have no idea. I only have visibility into the mod queue.

1 Like