Hi Adam, On Tue, Oct 16, 2018 at 05:05:50PM +0200, Adam Borowski wrote: > Have you started to actually mess with preliminary builds of it? Ie, would > me pushing such a change immediately help you? Or would it be just as good > if I committed it to git for now?
When I added hurd-i386 to CI, also added hurd-amd64 back in Heidelberg. That CI job now fails a little earlier. It hasn't made progress in a while though. So just commit. I guess I'll have a few more reports once CI catches up with other archs. I expect that this takes about a week. > For some strange reason, Hurd buries its marking deep inside a > complex-format section of the ELF object instead of using the readily > available field in the header meant for this very purpose. Heck, Hurd even > has a value officially assigned (0x04). Not doing this makes recognizing it > a lot more complex. > > But, if false positives are ok for you as long as there are no false > negatives, doing it fully doesn't seem urgent. Yeah, I want zero false negatives and few false positives. The purpose of this check is to abort early when something is obviously wrong. It must not fail when things are good, but occasionally failing late only wastes some CPU time. One easy thing you could do is reject a $os value of 3 for hurd. Helmut
