Migrate the fosdem/video repo into multiple repos at git.fosdem.org/video

dexterlb commented

2026-08-10 11:38:53 +00:00

Member

Proposed repo layout:

repo fazantix:
- cmd, lib - Go code, copy as-is
- tools - rename contrib dir from fazantix repo
- debian - debian package build scripts
- nix - nix package build scripts
- man - man page
- external - vendored code, currently v4l library
repo audio-mixer
- pcb - move hardware/pcbs/audio_* from video repo
- firmware - move hardware/firmware/audio_board from the video repo
- software/audioctl - move software/audioctl from the video repo
- software/audioctl-ui - move software/audioctl_ui from the video repo
- software/nix - move audioctl nix packages from software/nix-deployment from the video repo
repo network-switch
- pcb - move hardware/pcbs/switch_board from video repo
repo dual-capture
- pcb - move hardware/pcbs/fosdem-dual-capture from video repo
repo videobox
- pcbs/power-board, pcbs/*-hat - move from hardware/kicad_pcbs/* from the video repo
- firmware/box-rp2040 - move from hardware/firmware/box_rp2040 from the video repo
- software/fhwctl - piece together from bits of video_status
- software/video-status - piece together from bits of video_status
- software/flasher - @dexterlb will program from scratch
- software/nix-deployment - move from software/nix-deployment from the video repo
- software/debian-deployment - come up with a script that creates a debian image reproducibly, also move some ansible stuff from the infra repo that works with a standalone box and not all of the fosdem infra
- manual - translate manual stuff to typst and put them here; do not embed pdf files
repo fosdem-infra
- move ansible stuff from the infra repo that depends on the fosdem infra and is unusable for standalone boxes
repo videobox-generated-manual - can also just be some files hosted somewhere and not a repo
- automatically generate from the manual dir in the videobox repo

Please suggest improvements and/or alternatives. One thing that should be considered is whether to split the PCBs into separate repos, although I like them better in the same repos together with related firmware/software.

Proposed repo layout: - repo `fazantix`: - `cmd`, `lib` - Go code, copy as-is - `tools` - rename `contrib` dir from fazantix repo - `debian` - debian package build scripts - `nix` - nix package build scripts - `man` - man page - `external` - vendored code, currently v4l library - repo `audio-mixer` - `pcb` - move `hardware/pcbs/audio_*` from video repo - `firmware` - move `hardware/firmware/audio_board` from the video repo - `software/audioctl` - move `software/audioctl` from the video repo - `software/audioctl-ui` - move `software/audioctl_ui` from the video repo - `software/nix` - move audioctl nix packages from `software/nix-deployment` from the video repo - repo `network-switch` - `pcb` - move `hardware/pcbs/switch_board` from video repo - repo `dual-capture` - `pcb` - move `hardware/pcbs/fosdem-dual-capture` from video repo - repo `videobox` - `pcbs/power-board`, `pcbs/*-hat` - move from `hardware/kicad_pcbs/*` from the video repo - `firmware/box-rp2040` - move from `hardware/firmware/box_rp2040` from the video repo - `software/fhwctl` - piece together from bits of video_status - `software/video-status` - piece together from bits of video_status - `software/flasher` - @dexterlb will program from scratch - `software/nix-deployment` - move from `software/nix-deployment` from the video repo - `software/debian-deployment` - come up with a script that creates a debian image reproducibly, also move some ansible stuff from the infra repo that works with a standalone box and not all of the fosdem infra - `manual` - translate manual stuff to typst and put them here; **do not embed pdf files** - repo `fosdem-infra` - move ansible stuff from the infra repo that depends on the fosdem infra and is unusable for standalone boxes - repo `videobox-generated-manual` - can also just be some files hosted somewhere and not a repo - automatically generate from the `manual` dir in the `videobox` repo Please suggest improvements and/or alternatives. One thing that should be considered is whether to split the PCBs into separate repos, although I like them better in the same repos together with related firmware/software.

albert commented

2026-08-10 17:42:21 +00:00

Member

I’d say we should split Fazantix and its UI as well.

If we want to do a combined build with the web interface inside the executable, we can vendor it in as a build artifact as a pre-step.
This could also be done with audioctl.

The other UI-thing is whether we should do one monolithic app with toggleable features, or make a separate repo for each.

Note: if we use the same framework, we can do small repos and reference them in by git commit/tag in node_modules.
Then the glue apps for FOSDEM (on control.v.f.o) and for other conferences (box-local) will just reference the existing UIs (and skip or move components around, if we want to)

Note2: I’d advise against creating a custom npm package repository: packagecloud do also provide an npm registry, but this has a lot of pitfalls (npm/yarn do not support multiple repos, so we need to upload the dependencies as well)

I’d say we should split Fazantix and its UI as well. If we want to do a combined build with the web interface inside the executable, we can vendor it in as a build artifact as a pre-step. This could also be done with audioctl. The other UI-thing is whether we should do one monolithic app with toggleable features, or make a separate repo for each. Note: if we use the same framework, we can do small repos and reference them in by git commit/tag in node_modules. Then the glue apps for FOSDEM (on control.v.f.o) and for other conferences (box-local) will just reference the existing UIs (and skip or move components around, if we want to) Note2: I’d advise against creating a custom npm package repository: packagecloud do also provide an npm registry, but this has a lot of pitfalls (npm/yarn do *not* support multiple repos, so we need to upload the dependencies as well)

albert commented

2026-08-10 17:43:07 +00:00

Member

videobox-generated-manual I’d say should just be build artifacts :)

If @gerry is so kind to create a repo for the manual I’ll do the git history shenanigans and try experiment with the CI.

`videobox-generated-manual` I’d say should just be build artifacts :) If @gerry is so kind to create a repo for the manual I’ll do the git history shenanigans and try experiment with the CI.

dexterlb commented

2026-08-10 20:06:20 +00:00

Author

Member

I’d say we should split Fazantix and its UI as well.

If we want to do a combined build with the web interface inside the executable, we can vendor it in as a build artifact as a pre-step. This could also be done with audioctl.

I'm not a fan of splitting the UI from the rest of the stuff because of the following reasons:

Non-reason: bundling the UI with the executable - as you said this is easily addressed technically
Actual reason: I want everything concerning a certain component to be in one repo, so that a person who is not familiar with the project who is interested in a component (e.g. the audio mixer) can clone the audio mixer repo and have everything they need to get a fully-working audio mixer with all the necessary hardware/firmware/software/ui
Actual reason: It will finally force us to migrate the UIs from npm to pnpm, which supports subdirectories natively. I am also really against hosting an npm registry: importing by git url should be fine for all use-cases and should let people hack on our stuff a lot more easily.
Actual reason: API changes need to be committed to both the UI dir and the backend dir which is an extreme pita

> I’d say we should split Fazantix and its UI as well. > > If we want to do a combined build with the web interface inside the executable, we can vendor it in as a build artifact as a pre-step. This could also be done with audioctl. I'm not a fan of splitting the UI from the rest of the stuff because of the following reasons: - Non-reason: bundling the UI with the executable - as you said this is easily addressed technically - Actual reason: I want everything concerning a certain component to be in one repo, so that a person who is not familiar with the project who is interested in a component (e.g. the audio mixer) can clone the audio mixer repo and have everything they need to get a fully-working audio mixer with all the necessary hardware/firmware/software/ui - Actual reason: It will finally force us to migrate the UIs from npm to pnpm, which [supports subdirectories natively](https://pnpm.io/package-sources#install-from-a-subdirectory-of-a-git-repository). I am also really against hosting an npm registry: importing by git url should be fine for all use-cases and should let people hack on our stuff a lot more easily. - Actual reason: API changes need to be committed to both the UI dir and the backend dir which is an extreme pita

albert commented

2026-08-11 04:19:41 +00:00

Member

A short note on this: then there should be separate directories with different debian trees inside for each program/app (e.g. golang stuff, js frontend, python helpers), as debhelper is not multi-language friendly and requires us to do a lot of boilerplate to manually replicate its functionality, as I needed to do with fazantix.

Otherwise I‘m OK with the monorepo-per-module concept :)

A short note on this: then there should be separate directories with different `debian` trees inside for each program/app (e.g. golang stuff, js frontend, python helpers), as `debhelper` is not multi-language friendly and requires us to do a lot of boilerplate to manually replicate its functionality, as I needed to do with fazantix. Otherwise I‘m OK with the monorepo-per-module concept :)

Rows
Columns

Migrate the fosdem/video repo into multiple repos at git.fosdem.org/video #1