On Sat, December 5, 2015 4:08 pm, openbsd-m...@clark-communications.com wrote: > Yes, if I end up writing a scraper, I will very likely obtain the html > pages > from the www directory of my local CVS mirror, rather than making http > requests > of the OpenBSD website. > > Another nice piece of data to have about a patch level would be the > revision > number in CVS for that patch. > At present, the only place I see that information is inside the patch.sig > file, e.g. > > > http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/004_smtpd.patch.sig >
I meant, I parse the files in patches/*/common, not the html in cvs. I found it easier. I get a nice little report of the errata number, name and synopsis. It's mostly wasted as I see the cvs checkin first and am already rebuilding. :) > My approach is to build an entire new release for the current patch level. > I understand this is way overkill, but given that is is a (mostly) > automated > process, I prefer this > approach to manually applying and rebuildingâ*¦. This is also what I do. I rebuild the whole release and then apply the kernel or base tarball to update the systems. This way I have an up-to-date release available for new system deployments as well. I don't have the luxury of redundency or down time to fully redeploy a system to update it. I do maintain configuration changes in siteXX.tgz files in case I do have to redeploy. Unfortunatly, they are mostly untested which is bad, but it should get me 95% of the way. A dev/staging environment is in the works. > I can imagine that at some point I can have my build system send me a > notification that a new patch is available, and a bit later, > that a new release has been built and is available for installation, > if/when I > so choose. > My build machine monitors cvs for -stable updates in the code, as well as changes to the patches/$version/ folder. I see the cvs changes, and if errata newer than the build machine's patchlevel have been created. I mirror the patches directory so all the systems compare their patchlevel to my internal mirror. Currently, I manually kick off a new release build and then initiate an update from each system. The patchlevel handles errata, but I can't yet be sure a system has the latest stable changes. The theory is that it's the errata that's important, so I haven't solved that problem yet. As it stands I have way better insite into the changes going onto my OBSD machines as compared to the linux ones with rolling updates of hundreds of packages.