Closed Ryex closed 2 years ago
Hello @Ryex,
thank you for pointing this out. The problem is that it is not always straightforward to tell where a warning ends, and where an error starts. Therefore, I opted for a strict policy where only "known" warnings were accepted. However, I agree that this can be annoying in some unexpected/new cases. Thus, I changed the system
method. Now, it accepts single-line warnings starting with warning:
(case insensitive). Those do not trigger any system error anymore, but they are forwarded to the logger. This should cover a large range of "warning" cases.
While working on getting together an Appimage for one of my favorite programs I encountered a build failure because warnings were propagated as errors. this system call method should be edited to ignore such warnings
this is already done with
exclude.append('fuse: warning:')
but a more generic check for warnings should be usedthese warnings may need to be propagated out to
stderr
but they should not halt.