Gå till innehåll

Hjälp till att utveckla KDE Linux

KDE Linux-gruppen uppskattar alltid hjälp med att utveckla KDE Linux till framtidens operativsystem.

  • För att tala med KDE Linux-utvecklarna, använd Matrix.
  • För att föreslå ändringar, skicka in en sammanslagningsförfrågning för ett av de relevanta git-arkiven.
  • ** För att rapportera problem i själva KDE Linux operativsystemet** (dvs. design av operativsystemet, integration, systemtjänster etc.) använd invent.kde.org och ignorera den skrämmande röda banderollen längst upp på sidan.
  • För att rapportera problem i KDE Plasma eller andra KDE-program, använd bugs.kde.org.
  • För att få hjälp med någonting relaterat till KDE Linux, använd discuss.kde.org, och märk inlägget med “kde-linux”.

CI-avbilder

Kontrollera byggloggen för ditt flöde. Det bör ange var avbilderna har publicerats.

Det går också att bläddra bland avbilderna härifrån.

Förbättra den lokala bygghastigheten

För att snabba upp lokala byggen, skapa filen mkosi.local.conf i arkivets rot med följande innehåll:

[Content]
Environment=LOCALE_GEN="en_US.UTF-8 UTF-8" # ersätt med dina landsinställningar`
Environment=MIRRORS_COUNTRY=us # ersätt med din landskod`
Environment=PARALLEL_DOWNLOADS=50 # om din Internet-hastighet är snabb

Btrfs-lagringsdrivrutinen för Docker måste användas, annars kommer det inte riktigt att fungera.

Om värddatorns filesystem använder Btrfs (som KDE Linux), lägg till följande i /etc/docker/daemon.json

{
  "storage-driver": "btrfs"
}

Officiell dokumentation av Docker som förklarar det finns här.

Om Btrfs inte används på värddatorn kan ändå en Btrfs-volym skapas som säkerhetskopieras av en fil så här:

systemctl stop docker.socket docker.service || true
fallocate -l 64G /store/docker.btrfs
mkfs.btrfs /store/docker.btrfs
[ -d /var/lib/docker ] || mkdir /var/lib/docker
mount /store/docker.btrfs /var/lib/docker
systemctl restart docker.socket docker.service

Kör sedan:

./build_docker.sh --incremental

Bygga egna systemavbilder

Man kan generera egna KDE Linux-avbilder för att testa paketintegration eller systemmodifieringar lokalt. Byggprocessen använder mkosi omgiven av en Docker- behållare.

För att inkludera egna paket, lägg till önskade paketnamn i relevanta inställningsfiler (t.ex. sektionen [Packages] i mkosi.conf eller de specifika .packages-filerna) innan byggskriptet körs.

Kör bygget med:

./build_docker.sh

När bygget är klart är utdata en .iso-avbild som finns i mkosi.output/.

Snabbtest med Virt-Manager

Det snabbaste sättet att testa ändringarna är att starta .iso-avbilden direkt som en befintlig disk i en virtuell maskin, och kringgå hela installationsprocessen.

  1. Öppna Virtual Machine Manager och starta guiden New Virtual Machine.
  2. Ange Local Install Media och välj den genererade .iso-filen.
  3. Tilldela minst 4 GB RAM och 2 processorkärnor.
  4. Viktigt: I inställningen av den virtuella maskinen, se till att Firmware är inställd till UEFI och Secure Boot är inaktiverat.

För en mer permanent installation eller instruktioner om hur andra virtualiseringsverktyg som VirtualBox eller UTM används, se handledningen Installera i en virtuell maskin.

Testa ändringar med openQA

KDE Linux använder en automatiserad openQA-testsvit för att testa systemavbilder innan de publiceras. Sviten startar avbilder i virtuella maskiner och utför viktiga arbetsflöden, inklusive att installera ett nytt system, uppgradera ett befintligt och testa funktionaliteten hos det installerade systemet. Det hjälper till att upptäcka regressioner som kanske inte är synliga när man testar en lokal version manuellt.

Om en ändring påverkar byggande av avbilder, installation, uppdateringar, systemtjänster eller skrivbordsmiljön, överväg om de automatiserade testerna behöver täcka den. Se openQA för utvecklare för att lära dig hur man skriver tester för det.


Artikel bidragen av , och med licens CC-BY-4.0.