> > All those are warnings, not "garbage" or debug output. File bugs about > > those, > > there should be zero warnings in normal usage. > > Shouldn't they trigger abrt then? more importantly, is it possible to capture > that in the QA process during distribution composition? I believe a lot of > those warnings aren't environment dependent, but rather would appear in a > generic installation, so it would be appropriate to detect them early and > take some corrective action---either block them or at least log bugs. > I think it should be a given that we do not install applications that won't > even properly start up. In the past I have reported/fixed several bugs in > less-important packages where the application would not even start or crash > on some basic functionality; I was never sure whether autoqa could detect > such errors. OTOH, I haven't seen such basic failures in few recent Fedora > releases. All those warnings and errors in my log are from applications that do not crash and work completely fine. Which means that at least those 'critical' messages seem "slightly" exaggerated. So, I'll try to file errors. But I'm half expecting library devs to tell me "the application is doing something incorrectly". And when I say "but it seems to work just fine, so why should I see lots of warnings and errors in my logs" they say "so that the developer notices that and fixes the broken application". And we'll be exactly where we were. That's why I'd like to have a runtime variable which would control all these "warnings and stuff", and by default it would show only the most critical issues, like crashes or deteriorated functionality. If the developer or a power user wanted to see that, it would be very easy to switch it on. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
