Build current (rolling, circinus) apt repo and iso image too

[marekm72]

While it's not something of high priority (rolling iso still available, and possible to rebuild using the still available apt repo), I think it still makes sense as early warning of possible breakage (if changes are first made to current, and then backported to sagitta) giving us more time to fix any issues.

For a start, I've tried to make a few obvious changes to build-iso.sh (using the public apt repo for now) - got as far as starting build inside the container, but then it fails:

Removing old vyos-build directory...
Cloning the VyOS build repository...
Checking out the current branch...
Already on 'current'
Removing branding...
Downloading apt signing key...
Building the ISO...
Show output? Press y...
Current UID/GID: 0/0
I: Checking if packages required for VyOS image build are installed
I: using build flavors directory data/build-flavors
Version contained illegal character(s), allowed: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-+
ISO build failed

Not sure what's with the illegal characters, haven't looked inside the container yet.

[dd010101]

We want to support as few branches as possible - then we need to support and test only those branches, if you add third then your support overhead and testing will grow pretty much by 1/3. In reality the support of current packages would require even higher overhead since that's the branch that changes most often.

There is some overlap indeed and it would give you early warning in some cases. Basically it's not worth it because the overhead is much larger than the benefit. I do follow the development and the current branch has much more changes than sagitta and this delta will only increase over time.

There is also another reason why to delay - there are supposedly upcoming changes like different build system and stream branches that will turn the package build process upside down, thus whatever work we do now we would need to redo once the changes are implemented and there is high chance that the next release would be affected by these changes before release. Thus such work would be just for the gap between now and until they implement the changes, seems like waste of effort.

That's why we want to delay the support for next release until we have indication of release like release candidate or we see talks about the next next release or the upcoming changes are done.

In short - we plan to and want to support package build for circinus eventually but not currently. Generally we want to add support when it's necessary.

I'm not sure what is your motivation but I doubt it's worth it. For example if you want to debrand the circinus then it makes so much more sense to develop new debranding script, that would modify and re-generate/re-sign specific .deb packages from official repository. This would have much less overhead than trying to compile all the packages from scratch just for debranding purpose. I don't see much other motivation why would you want to build the circinus packages now or in the interim before the changes are implemented.

You absolutely can build ISO of circinus if you want to use packages that come from the official repository. You don't even need to use their repository, you can make your own mirror. Our script can't build circinus since it's just not made for it, there are bunch of changes necessary to add circinus support. That's why you would need to build the ISO as per official documentation.

The version error is likely because the build-iso.sh is autogenerating the version and whatever it generates is likely malformed/not valid version for the circinus build command. To add support for circinus ISO isn't too hard I believe if we use official repository so this is something we could implement via our build-iso.sh right now.

[Crushable1278]

It is not currently possible to build a Circinus .iso from the official repo because there is no official Circinus repo, and they still call for Current while building Circinus. In fact, building a Circinus .iso from source and running the smoketests runs into at least 3 different errors due to missing backports (as of 3 days ago). Additionally, there is no Circinus build container yet.

I know it's likely no where near release yet, but this is a bit concerning to me. Current's vyos-1x revision is well above Circinus'. If the VyOS devs follow the same process as they have previously where they create a branch's repo by simply copying/renaming current, there could be a long period of time that the packages aren't right until someone cleans up the repository (which they never seem to do for any branch).

My primary motivation for enabling Circinus builds was to, once their official stream releases are built and released, be able to compare my output with theirs and adjust my build process accordingly, improving the 1:1 nature of my other branches. It really is trivial today to convert Sagitta to Circinus and/or current, but as you said, you increase your maintenance burden.

From a package perspective, the difference between Sagitta to Circinus is:

• nat-rtsp
• waagent
• isc-kea
• removal of some legacy packages

[dd010101]

...there is no official Circinus repo... Additionally, there is no Circinus build container yet.

I'm not sure what do you mean - if the vyos-build has circinus branch then you have repo & container all in one. I even see that the vyos-build dockerhub has the image as well (published hour ago), but even if it didn't - you have the vyos-build and that's all you need anyway.

I know it's likely no where near release yet, but this is a bit concerning to me. Current's vyos-1x revision is well above Circinus'. If the VyOS devs follow the same process as they have previously where they create a branch's repo by simply copying/renaming current

Isn't the whole point of the new stream approach exactly not to do this? I think they now develop everything in current then backport to circinus if it's done. The circinus is nowhere near done - that's why it makes sense that nothing on circinus is done yet and thus everything waits for backporting and this explain the larger delta between current and circinus. If we are closer to RC the delta perhaps will be smaller but there always will be some delta with stream approach, because the chance that current branch has no upcoming features in progress and everything is done isn't very likely.

It really is trivial today to convert Sagitta to Circinus and/or current, but as you said, you increase your maintenance burden.

What is the purpose of getting circinus of today? The point is to get circinus of the future and I do expect there will be quite some way before we get there - and following the way from the start is unnecessary. I don't see any practical purpose of building the circinus of now - this circinus doesn't represent the circinus of future whatsoever.

The support of building developing branch is significant - debugging why it doesn't build anymore this week, finding the cause, the need to explain people to wait for pull-requests to be merged, doing intermediate patches so people can build meanwhile the build is broken and fix in no sight, and of course the testing - why would you want to do this early - if you don't need to? If you don't do this they you provide build that doesn't work so that's pointless too.

I hope the sagitta will feature complete/frozen as equuleus is once the cicinus gets near the release candidate, so there is only one branch under development for us - not multiple at the same time.

[Crushable1278]

Ah, that container tag is definitely new in the last week or so. Nice.

Yes, you can build a repo from source yourself and the container can also be built from source, but there is no official existing apt repo to build Circinus from (disregarding that building a circinus .iso looks for a current dists in the apt repo structure), and I'm not maintaining my own container registry as you are, even if local.

If everything was backported from current to circinus to sagitta, circinus wouldn't be broken. There were several commits a week or so ago that went straight into sagitta, bypassing circinus and fixing sagitta.
I'm not sure what you mean by Circinus not being done. Yes, Current should be expected to have many more revisions of the same code. Following the above methodology, you don't break Circinus as we saw Sagitta broken, but here we are. The version numbering is simply a consequence of the split, and their lack of cleaning house in the apt repo will come back to bite them until it is rectified.
We know this is how they build the apt repos as sagitta has remnants of defunct packages from its time as current as well as dated packages- see VPP, python3-inotify.

I don't care about Circinus - I care that my build output matches the official output as close as possible as it's validation that I/we are doing this correctly. I won't be running Circinus until well passed its EPA as I did with Sagitta.

[dd010101]

...there is no official existing apt rep...

Yes, circinus is using current repository - this tells me that the VyOS team didn't build it yet. That's why I feel it's nowhere near done, when no ISO exists yet and you have years of development ahead.

I don't care about Circinus - I care that my build output matches the official output as close as possible as it's validation that I/we are doing this correctly.

I think the only proper way would be to have subscription and access to official images - otherwise we can only guess what is in those images and if our packages are good match. I guess the old official repository will be migrated to the current-like infrastructure and then we will have no insight into to the binary result. I do believe though that all the differences with the official repository is legacy baggage where the packages were side-loaded before the CI was implemented and this explains most of the differences. I do believe this would be left behind with the migration to the new repository.