Why did these not detect the build tag and version correctly?
If you provide documentation to get people over the hump of learning a new tool, others will likely follow suit.
Certainly interesting that someone is actively censoring and/or removing posts containing information on reverse engineering the build process.
Seems to have triggered some antispam thresholds for being a new user who suddently posts alot of links.
Same thing happend to me when I was new on this forum.
Edit: I made an attempt to tell the forum engine that the messages are not spam - please let me know if I missed something.
python3-vici is documented here - Upstream packages — VyOS 1.5.x (circinus) documentation
python3-inotify is in Debian unstable but I don’t see any dependencies that would not make it work in stable
GitHub - mcbridematt/vyos-arm64-builder: Bootstrap VyOS for ARM64 may be useful (s/arm64/amd64 in build.sh and it mostly builds for amd64 too)
Hi from the VyOS people! 
We recognize that there can be challenges with builds - perhaps some packages were never built outside of our Jenkins and might contain hardcoded elements (excluding Jenkinsfiles and build configs, of course). If you encounter any issues, please feel free to fix them, as this would indicate something that needs attention.
However, I was disheartened by the term “sneaky” being used. As the current maintainer of the vyos-cloud-init repository and its primary contributor, I’m surprised by the reported build problems. This package requires no dependencies from VyOS itself. Apart from our additional modules, which are merely extra files in the deb package, it differs from Canonical’s upstream version by only four lines - three of which add the VyOS module to tests, and one removes an unnecessary dependency. These changes might even be dropped in the next update. Building the original Cloud-init from upstream should present similar issues if any. So, labeling this as “sneaky” seems quite misplaced.
The same applies to other builds reported as problematic. As a developer, I regularly build various packages for local testing, including many from the list of non-buildable ones, and have not faced significant issues.
Let’s strive to maintain a healthy and positive environment here. Please avoid toxicity and rudeness. We are not adversaries. Our differences in opinion only help our community grow.
Have a question? Ask.
Have a suggestion? Suggest.
Have a problem? Describe it.
Have time to code? Help improve VyOS.
Thank you for your understanding and cooperation.
One of the big issues I see here is that you, as a developer, have not faced significant issues. Most VyOS users are not developers, however. We’re network administrators and engineers being forced into the role of developers if we wish to maintain the networks we carefully built using open-source software in the last couple of years.
Building the *.iso was already a painstakingly difficult process for a lot of us (even though, in the eyes of some of your co-developers it was “too easy”). Now it became next to impossible. Most users simply gave up, a few die-hards took on the job to create workarounds to actually make this project usable again and the most positive thing I can say about it is that they’re not exactly being helped.
1 Like
The answer is actually right in the error message.
09:17:35 Please get the latest upstream tags.
09:17:35 As an example, this can be done with the following:
09:17:35 $ git remote add upstream https://git.launchpad.net/cloud-init
09:17:35 $ git fetch upstream --tags
You can just copy-paste suggested commands or use another repository URL as a reference. This happens, because git clone does not fetch git tags by default.
So am I! 
I am an educated network engineer, not a software developer.
It is not an easy process for me as well to dig every time in the code, builds, and automation. However, I must do this painstakingly difficult process, as you say, because there are no other community contributors who do this instead of me, and someone must maintain the code and packages to keep it working. Because the community needs this.
I can help with hosting this, just give me some time, as I will be away for the next week (RIPE 88).
However, I think there should be a way for anyone to rebuild all of that repo locally from sources, without trusting any external binaries other than official Debian. Someone sufficiently paranoid might not trust us (after all, we could be secretly working for North Korea or worse) and it should be easy to reproduce all steps (even if it takes an hour or two on a modern CPU) and inspect all sources themselves. Create the container locally with podman-docker to not depend on Docker Hub, etc. And of course need to replace the trademarked logo/artwork etc.
Hi @dd010101 !
Do you have an approximate requirements of what will be needed for that hosting?
How much space built deb repository will require?
And what about jenkins you mentioning: do you have CPU/RAM/Disk requirements?
Thanks for your work!
I’m able to provide hosting for both Jenkins and the packages. Feel free to DM me.
I am willing to help with hosting as well. I have means to host from 2 locations connected with 1Gb symmetric connections in the central US.
i can help with Jenkins hosting for US as well. I have done a bit with Jenkins for infrastructure tasks but not great on the software build side. I see you said 8GB memory, how much disk you think is needed? I can manage the infrastructure if you can manage Jenkins/build.
Excellent point. I will go after it following your doc and provide feedback.
Contribute the project and create the 3 PR is the easier way to get FREE LTS releases, isn’t it?
https://vyos.net/get/contributor-subscriptions/
It’s you way
I want LTS I will spend 3 months to build packages, but I won’t contribute the project because I don’t have time
For the record, I want a custom stable build and spent less than a week rejiggering my scripts to build all the branches from source. It’s a solved problem.
Since it’s solved the problem, I will now close this topic
and you guys can continue your discussion in your forum.
1 Like