I see the build depends on Jenkins which looks like something big, complex and I’ve never used it before. I have followed the instructions found here How-To-Install-Jenkins-on-Debian-12.md · GitHub and installation was successful, then I have used its web UI to install the recommended plugins, set admin password etc. but don’t know what to do next, how to start build of the source packages with it. The build scripts are run only after Jenkins does its magic getting specific commits specified in Jenkinsfile from github source repos, but what command do I need to run to start such build of all packages?
I’m impressed as I see you’ve figured out all that magic already 
Still looks very complex for me, at least for now - wish there was a simpler way, without all that heavy Java stuff…
If I can help (like provide free hosting for the packages, a lot of upload bandwidth available as most of my traffic is in the opposite direction) for such an unofficial more open V**S rebuild project, just let me know. Packages with “vyos” in their names may need to be renamed to avoid trademark issues too (unless trademark owners allow otherwise).
They say that bandwidth is not free for them:
Last but not least, hosting and maintaining repositories in a way that keeps them available on the web all the time is not free, and neither is the bandwidth used by image builds.
But they already use Cloudflare (which will cache all files up to 512MB for free), so it’s just an excuse.
1 Like
Come on people, we can’t of course deny there are costs involved. May it be hours of labor or costs of hosting everything from code to the build services.
Can’t say I like current situation, but then again, I’m not running the project and I cannot see the financial status.
2 Likes
The dev.packages.vyos.net doesnt seem to be using cloudflare but AWS for hosting.
Or were you thinking of some other site?
1 Like
You can see the directory listings, but try to click on some .deb or InRelease file and then you get the full-page message “You have been blocked” from Cloudflare. Which is confusing as it suggests the site is under some kind of attack or even the user is an evil hacker, it doesn’t tell the user that access to the file was limited intentionally and why. It was all before the blog post that would explain this.
Let’s be real: it was never about bandwidth costs, it’s about making LTS build inaccessible (or too hard to reach) to non-paying users, and they’ve been really clear about it on their blog post.
The bandwidth issue is just an excuse as they can fully cache the repo using Cloudflare, there are some public mirrors of the repo and there was no call for the community to sponsor mirrors (something that lots of community members including me would gladly do).
The main issue for me was the shoot first and ask later (or tell later in this case) approach. We had no prior notice that the repo would be taken offline, so we were unable to mirror it or build the packages from source beforehand.
1 Like
Any sagitta package on dev.packages.vyos.net will redirect to sagitta-packages.vyos.net, which is behind Cloudflare:
Some docs on how to achieve this from VyOS would be nice since the answer nowadays is “build it yourself”.
The same from any of you who already managed to do this would be nice towards the rest of us
So in short those who managed to do this themselves are the same evil as VyOS who currently dont provide information on how to achieve this?
To me its exactly the same… some got upset on VyOS for not providing these packages for free any longer and those who managed to build these themselves also clearly dont want to provide them for free or information on how to achieve your own repo (as in command by command instructions).
To me thats same s**t different name…
Don’t entertain trolls, please.
Some posts have disappeared from this thread - what happened while I was sleeping?
I don’t think people don’t want to share, more like it simply takes time to reverse-engineer the complex build process with all its dependencies.
I don’t see any trolls here, or have I missed something?
2 Likes
I would like to build 1.4 from the source code.
Question: All the building blocks are included inside
https://github.com/vyos/vyos-build ?
Orlando
Unfortunately it’s not that simple, some dependencies are outside that repo as well, and you may have to learn Jenkins if you haven’t yet. Some posts with useful hints have been removed from this thread and their author banned, so it seems it may not be welcome to discuss here. We are all humans and sometimes over-react, it may be better for the community if some actions could be reversed, not sure if that is possible though.
s/freeloaders/contributors
My specific case is that I’d like to experiment with a bug fix to accel-ppp - see Don't terminate whole PPPoE session in response to client IPV6CP TermReq if IPv6 not required · Issue #57 · accel-ppp/accel-ppp · GitHub - where I’m not sure about correctness of my patch (what exactly needs to be done to properly close just IPV6CP without closing whole PPPoE session, without causing resource leaks) but don’t want any other changes, as the same router also does BGP and OSPF in a proven working setup I don’t dare to break that (last thing I want is angry customers) so rolling is not an option.
When it becomes so complicated to rebuild VyOS it becomes more and more tempting to switch to pure Debian where it’s easy to rebuild and reinstall packages on a running system without rebooting (though there is some disruption to customers when PPPoE sessions are restarted). Or Alpine which is more lightweight and can be made to run from RAM, to avoid filesystem damage if not shut down properly.
As for the trademark issues, it would be good to know what exactly needs to be removed/replaced/renamed - does “vyos” in some filename already cause trademark infringement, and the VyOS™ team actually got a paid license from Brocade/AT&T/Ciena to have right to use their Vyatta™ trademark - or was that even Vyatta(R) registered trademark - as there still exist some legacy files with “vyatta” in their names? Or does it only apply to the logo/artwork and file names in packages can be left unchanged? (Similar situation if a LInux or BSD distro had some files with “unix” in their names - oh wait, there are unix domain sockets so it’s probably OK to keep using AF_UNIX sockets despite the UNIX(R) registered trademark. But IANAL and YMMV.)
No, it doesn’t. AF_UNIX is a perfect example — internal identifiers are not branding and it’s ok if they match some trademarked words.
(Trademarks are also limited to classes, e.g., Microsoft® Windows™ is a trademark in the software class and a shop that sells window frames can use it without any fear of getting sued for it).
was that even Vyatta(R) registered trademark
Vyatta was a registered trademark, but since VyOS was never using that name in its branding, it was never an issue. Ubiquiti also left vyatta-named files in EdgeOS and their lawyers said it was ok.
In short, the question is only about the visible branding. If nothing creates an impression that the image comes from the VyOS team (i.e., user-visible names and artwork are replaced), we have no problem with it.
Why are you trying to replicate their Jenkins build environment? You’re working way, way too hard.
Use their Jenkinsfile as a baseline on how to build the packages, nothing more.
The entire build process for each package can be scripted in shell/bash, and automated that way. You should pull in just about 79 packages during an iso build run.
Currently there is no elegant way to build packages without hacking the Jenkins scripts somehow or rewriting the Jenkinsfiles to bash (making your own build platform) and then deal with the continuous updates.
It’s all there, you just need to plug it in.
Well, is it all there or not?
Different strokes for different folks I guess, but I didn’t have to patch any code for my “pipeline” to work.
Perhaps you could feed back your Jenkins improvements to the greater project to improve its “buildability”. Even simple comments to the code. Your configuration file suggestion sounds great too. I’d revisit the Jenkins idea if it meant I didn’t have to completely learn a new product from scratch.