Mentor's note; hopefully fewer questions means we're getting closer to proposal writing ;)

cormander howdy kragniz cormander: hi there! kragniz how goes with you? cormander good kragniz cormander: cool! kragniz I've been thinking a little about the tooling to create the patch packages cormander great kragniz so assuming we're doing the one rpm per patch route, we need to create an rpm for each supported kernel, right? cormander that will get very messy cormander I would put all versions that applies to in it [ERROR] The command “path/to/kpatch/repo/<kernel” is not known to the server. cormander like so; /path/to/kpatch/repo/<kernel version>/patch-name/module.ko cormander or maybe the reverse; /path/patch-name/<kernel-version>/module.ko --- up to you kragniz olay, so contain builds of the patch against all supported kernels cormander right cormander in the %post script of the rpm, the userspace script you write will determine if an update to the package actually changed the checksum of the module for the current running version cormander and only remove / reinsert it if so cormander when you generate the rpm, what your patching is in newer kernels, so you won't have to "add" more versions later cormander unless you have a future patch touch the same thing that a previous patch does - cormander and you'll have a list of newer modules that are smaller, and and bunch of updated files for older kernel versions kragniz that sounds good kragniz is there a drawback to reloading current patches anyway? cormander you run the risk of hitting a function that's on the kernel stack kragniz other than the risk of breaking something cormander and failing to re-insert it cormander so, best to only remove/re-insert stuff when you have to kragniz okay, that sounds reasonable kragniz so the input for this build system would be a source patch, and it would build kpatch modules for all kernels it applies cleanly against, or would we provide some version limitation? kragniz ie, something.patch is for kernels 3.14 - 3.16 only cormander version limitation. more specifically, release limitation cormander we're only doing EL7 kernels kragniz okay, cool kragniz I need to run for about half an hour, sorry! cormander no problem, just say my name when you're back kragniz will do cormander also - just because a patch cleanly applies doesn't mean it's correct. It can even be dangerous. Patch selection is a painfully manual process. Hard to automate cormander also, patches often don't cleanly go into kernels that need it cormander you can assume that patch selection is out of scope. The real meal of the deal here is the build and release automation |<-- imcleod_ has left freenode (Ping timeout: 244 seconds) cormander kragniz: going to sign off shortly, unless you're still around