Not digging into discussion politics, but I will skip the test upstream until the root cause is clear. IMHO the test indeed succeeds for what it tests, the tcpflood abort is a non-intended but useful side-failure not tests. More details in PR.
https://github.com/rsyslog/rsyslog/pull/6280 Rainer El sáb, 1 nov 2025 a las 12:35, Santiago Vila (<[email protected]>) escribió: > > On Sat, Nov 01, 2025 at 10:48:25AM +0100, Michael Biebl wrote: > > > I treat failures that do happen on non-official buildds as non-RC > > Why? > > > > I understand that debugging the failing test might take time and > > > effort, but if you are not willing to debug it, which is ok, then > > > please at least disable or skip it, which should not be difficult. > > > > If you looked at the referenced other bug report you would have noticed that > > the issue has been debugged and sent upstream. > > So I find your statement rather insulting and condescending when it's > > apparently you who didn't spend the time to read #1100103 > > Sorry for the misunderstanding. By "debugging" I really meant > "actually findind a fix" (which did not happen in #1100103). > > We don't know when (if at all) upstream will offer a fix. Some people > who try to build the package with enough disk space and enough memory > (i.e. not doing anything "wrong") can't build the package reliably. > This is why I suggest to disable the test in the meantime. > > Thanks.
