Summary: Not a bug. Antoine Jacoutot <ajacou...@bsdfrog.org> wrote:
> On Fri, Jun 07, 2019 at 02:49:32AM +0300, cho...@jtan.com wrote: > > Antoine Jacoutot writes: > > > That is because 001 only includes kernel object files which you do not > > > have > > > since you run under a chroot and didn't extract > > > /usr/share/relink/kernel.tgz > > > So syspatch(8) considers you don't have that "set" installed. > > > syspatch-003 on the other end includes a header change and that header > > > *is* > > > installed on your system. So syspatch installs it. But you are missing > > > all the > > > other pieces to actually relink your kernel and that's why it fails. > > > > Thank-you that makes sense. > > > > It did throw me a little though; I would expect a tool such as this to > > report its inaction as well as its action. > > > > I take it that syspatch performs these checks also with the other sets? eg. > > It would skip an X patch if the X sets were not installed? > > Yes that's correct. > > > > You are running syspatch under a totally unsupported setup. > > > > This is a common refrain and I do understand why it's used but it's not a > > concern. I'm not after support, I can put the pieces back together when I > > break them. > > > > But is 'all the sets' the only configuration which OpenBSD's tools consider > > valid in general? 'Supported'? > > Well, it's not really about the sets. > > From the man page: > > CAVEATS > syspatch is designed to work solely on official OpenBSD releases. > > What you are running is not. > An official release comes with a kernel. > One can skip a set but if I think it's fair for the tools to assume one has > at least one kernel and baseXX installed... > > > In any case I still do think there's a bug here but now it's clear that > > it's one of: > > > > * syspatch doesn't report skipping patches (it also skipped a kernel patch > > when it recognised the lack of kernel but attempted to relink it later > > anyway for another patch, which will boil down to the same test). > I explained why. > It sees that there's a candidate for replacement (in this case some headers), > so > it extracts the patch. Since it also contains kernel objects files, it will > run > reorder_kernel, but you didn't extract the release object files in your chroot > (which the installer does)... so boom. > > > * syspatch's manpage doesn't fully describe its behaviour when one or more > > sets are mising. > > We accept patches for man pages :-) > > > Please note that I'm not whinging that OpenBSD doesn't work the way I > > demand and insisting on change. I've noticed there's been a lot of that > > recently. I've found what I deem to be a fault and, if anyone else agrees, > > would like suggestions on how I could fix it (chiefly, which of the above > > is the real bug) and I will follow up with a patch. > > Documentation is clear that syspatch only works on releases. Your chroot is > not > because you didn't extract some sets from the baseXX set (and again, IMHO it's > fine for our tools to assume you have at least that particular set installed). > > -- > Antoine >
