Archlinux repository server & package build system, written in V.
 
 
 
 
 
 
Go to file
Jef Roosens b91d7b3159
ci/woodpecker/push/lint Pipeline was successful Details
ci/woodpecker/push/docs Pipeline was successful Details
ci/woodpecker/push/arch Pipeline was successful Details
ci/woodpecker/push/build Pipeline was successful Details
ci/woodpecker/push/docker Pipeline failed Details
ci/woodpecker/push/deploy unknown status Details
ci/woodpecker/push/test Pipeline failed Details
Merge pull request 'Apply new vfmt defaults' (#180) from Chewing_Bever/vieter:new-vfmt-defaults into dev
Reviewed-on: vieter/vieter#180
2022-05-14 20:09:03 +02:00
.woodpecker feat(ci): split Arch releases into vieter & vieter-git 2022-05-11 08:05:24 +02:00
docs fix: don't pass --nodeps to initial build step (#173) 2022-05-10 13:36:07 +02:00
src refactor: apply new vfmt defaults 2022-05-14 20:06:08 +02:00
.dockerignore Switched to patch-based builder, based on weekly 2022-01-27 19:18:11 +01:00
.editorconfig Just some changes to poke CI 2022-03-27 23:33:33 +02:00
.gitignore docs: migrated over Hugo documentation 2022-05-01 12:14:13 +02:00
.gitmodules docs: migrated over Hugo documentation 2022-05-01 12:14:13 +02:00
CHANGELOG.md feat(ci): split Arch releases into vieter & vieter-git 2022-05-11 08:05:24 +02:00
Dockerfile feat: simplified config down to pkg_dir & data_dir 2022-05-03 19:50:14 +02:00
LICENSE Added AGPLv3 license [CI SKIP] 2022-01-27 22:34:12 +01:00
Makefile docs: migrated over Hugo documentation 2022-05-01 12:14:13 +02:00
PKGBUILD feat(ci): split Arch releases into vieter & vieter-git 2022-05-11 08:05:24 +02:00
PKGBUILD.dev feat(ci): split Arch releases into vieter & vieter-git 2022-05-11 08:05:24 +02:00
README.md chore: update README 2022-05-11 08:05:24 +02:00
renovate.json Add renovate.json 2022-04-11 10:01:38 +00:00
test.py Solved the "removing old packages" problem (I think) 2022-04-09 21:08:54 +02:00
vieter.toml feat: simplified config down to pkg_dir & data_dir 2022-05-03 19:50:14 +02:00

README.md

Vieter

Documentation

I host documentation for Vieter over at https://rustybever.be/docs/vieter/. API documentation for the current codebase can be found at https://rustybever.be/api-docs/vieter/.

Overview

Vieter is a restart of the Pieter project. The goal is to create a simple, lightweight self-hostable Arch repository server, paired with a system that periodically builds & publishes select Arch packages. This would allow me to build AUR packages (or PKGBUILDs I created myself) "in the cloud" & make sure I never have to compile anything on my own systems, making my updates a lot quicker.

Why V?

I chose V as I've been very intrigued by this language for a while now. I wanted a fast language that I could code while relaxing, without having to exert too much mental effort & V seemed like the right choice for that.

Compiler

Vieter compiles with the standard Vlang compiler. However, I do maintain a mirror. This is to ensure my CI does not break without reason, as I control when & how frequently the mirror is updated to reflect the official repository.

Features

  • Arch repository server
    • Support for multiple repositories & multiple architectures
    • Endpoints for publishing new packages
    • API for managing repositories to build
  • Build system
    • Periodic rebuilding of packages
    • Prevent unnecessary rebuilds

Building

In order to build Vieter, you'll need a couple of libraries:

  • An installation of V
  • gc
  • libarchive
  • openssl

NOTE: if you encounter any issues compiling Vieter using the absolute latest version of V, it might be because my mirror is missing a specific commit that causes issues. For this reason, the make v command exists which will clone my compiler in the v directory & build it. Afterwards, you can use this compiler with make by prepending all make commands with V_PATH=v/v. If you do encounter this issue, please let me know so I can update my mirror & the codebase to fix it!

Contributing

If you wish to contribute to the project, please take note of the following:

  • Rebase instead of merging whenever possible, e.g. when updating your branch with the dev branch.
  • Please follow the Conventional Commits style for your commit messages.