Control: affects 1052002 - wasmedge Control: affects 1052002 + src:wasmedge
On Thu, Nov 09, 2023 at 09:52:04AM +0100, Paul Gevers wrote: > > Hi Paul, > > Thank you for your report. This is caused #1052002, which I had marked > > as affects: wasmedge previously. > > Sorry for not checking that, but because you marked it as affecting the > *binary* package wasmedge, it doesn't show up looking for bugs in the source > package wasmedge (that may be a bts bug). Because this is a FTBFS issue, I > recommend you to mark it affects src:wasmedge instead of wasmedge. Alright, fair enough. Hopefully fixed above? > > Also, I'm not sure I understand how clang migrated to testing when it > > introduced an autopkgtest regression in another package. Isn't > > autopkgtest integration in britney supposed to prevent this kind of > > thing from happening? > > britney prevents this kind of things currently only for *direct* reverse > (test) dependencies. In this case we have: > > test/Depends: clang (from src:llvm-defaults) -> (Depends) clang-16 > > As I'm pretty sure you meant not clang, but one of the versioned clang > packages, britney didn't see the breakage. There are multiple ways to > improve this: > * britney should look at all transitive dependencies (we lack the resources > and also not environmentally friendly) > * britney could be taught to translate (automatically or via configuration) > "-defaults" packages to their real packages. This would be good for multiple > ecosystems, patches welcome. > * Individual packages that are sensitive could use the > `hint-testsuite-triggers` trick from the autopkgtest spec [1] and add the > current real packages. That's a PITA to maintain though, and adding versions > that you don't really test is wrong. Hrm, that's useful context and in hindsight makes a lot of sense. Thanks so much for spending the time to explain this to me! In the meantime, I'll mark the embed-cxx test as flaky in the next WasmEdge upload until the clang-16 bug gets fixed. Best, Faidon
