Migration of services - 11. build service

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

the eleventh service on the migration list is the build service.


-- Migration status --

The previous build service used its own instance of Ubuntu Launchpad - you 
know it as QuickBuild. This is operated on the previous primary site, so 
it was necessary to deal with the change.

In parallel, a second set of builders is used to build packages for PSB and 
PTB repositories. These builders are designed from the beginning to be 
completely independent of QuickBuild. This makes it easier to add new 
versions of distributions, other architectures and, above all, allows 
these builders to run sustainably.

After changing the primary archive, official packages are no longer 
published from QuickBuild, but from PSB. This is starting with TDE 
R14.0.7. Therefore, QuickBuild is no longer used to build official 
packages and there is no need to deal with its migration.


From a technical point of view: The reprepro tool is now used to manage all 
APT repositories. Sbuild (with schroot) is used to build binary packages. 
The inoticoming tool is used to automate the import of packages (both 
source and binary) into reprepro.


-- What needs to be done --

QuickBuild provided build tasks management and a web interface for finding 
packages, monitoring build status, and viewing build logs. Such a web 
interface is not available for the currently used reprepro + sbuild.

Because Launchpad is too extensive - it provides many services that we 
don't need and don't want to use, there is no intention to set up a new 
Launchpad instance as a replacement for QuickBuild. Originally I was 
hoping that mini-buildd could be a good replacement because it also uses 
reprepro + sbuild. But after an initial thorough research and testing, I 
found that the mini-buildd is designed with many limitations that make it 
unsuitable for us. It is not possible to remove these limitations, as this 
would require a fundamental change in the concept of mini-buildd 
operation. That's why I stopped further research of mini-buildd.

Since I have not found any other usable existing solution, it seems that we 
will need to design and create our own solution here. Although it is not a 
high priority now, it is an important step, because the current build 
service is completely dependent on me. I already have some ideas, but so 
far there was not enough time for me to start making the first components.


-- More ideas and suggestions?

Because the current state of the build service has been working well for a 
long time - many years for PSB and PTB, starting with R14.0.7 also for 
official packages, I suggest to focus efforts on other migration tasks 
first. And leave the build service improvements for later.

Do you have any other ideas and suggestions?

Cheers
-- 
Slávek

Attachment: signature.asc
Description: This is a digitally signed message part.

____________________________________________________
tde-users mailing list -- users@xxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxx
Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@xxxxxxxxxxxxxxxxxx

[Index of Archives]     [Trinity Devel]     [KDE]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]     [Trinity Desktop Environment]

  Powered by Linux