search for: n371

...acket expression as an escape for an otherwise literal regex is in gnulib's tree-wide syntax-checking. And of course, you don't want to hit a false-positive of the regex itself being an otherwise forbidden string. For example: https://git.savannah.gnu.org/cgit/gnulib.git/tree/top/maint.mk#n371 And since libvirt used to use gnulib's maint.mk regex-based syntax checking, before weaning itself off gnulib, this may be why libvirt-ci (the source of lcitool) still utilizes @FOO@ regex with [@] escaping. Or, it could be because gitlab and/or Cirrus do their own @FOO@ expansions at job kic...

On 3/1/23 17:54, Eric Blake wrote: > I took the easy route of crippling what I couldn't get working, on the > grounds that partial coverage is better than none now that we have > Cirrus CI checking commits on additional platforms. > > This series got me to a green checkmark: > https://gitlab.com/ebblake/nbdkit/-/pipelines/793156983 > > but depends on an as-yet