Control: retitle -1 apt: FTBFS on Arch Linux with libapt test failures Control: severity -1 wishlist
Hi Christian Heusel, as said on IRC, we are happy to receive and help with bug reports here in the BTS, but I had to dial back on the severity quite a bit as this is not applying to Debian and hence not release-critical to Debian (apt is not in any danger of being removed from testing or a future release for obvious reasons, but it could still confuse unsuspecting users and automatic processes working with and against bugreports). No worries, severity has hardly any practical meaning for us so your bug report isn't handled and dealt with slower or faster regardless of it being tagged serious or wishlist. But enough of the pretext, lets start with the on topic: Am Sun, Nov 17, 2024 at 08:15:21PM +0100, schrieb Christian Heusel: > * What was the outcome of this action? > Building the package yields test failures for 2.9.11 Did you try with earlier versions or is 2.9.11 the first you try? The tests in question themselves haven't changed in months. The code they test might have, but to figure that out it would be very beneficial to know if that was "always" the case or a recent change. > * What outcome did you expect instead? > The application builds without test failures Can you perhaps provide some instructions so that we with Debian as a starting base could reach a point where we can reproduce this failure which preferably doesn't involve "install Arch on a spare machine" or (at least for me, others might have other opinions) the word "Docker". As in, a Debian chroot can be relatively easy bootstrapped even on foreign Linux distros with (c)debootstrap. I suppose something like this exists for Arch, too? And how can I check out your work so far and build that to see the error(s) myself? > [ FAILED ] URITest.AutoProxyTest (0 ms) That test has 4 checks and they all fail… they don't do much through, they just call a script, so that screams setup problem like that the script isn't executable or you are building on tmpfs with noexec or something like that. > [ RUN ] TreeParserTest.ParseInvalid > /usr/include/c++/14.2.1/string_view:256: constexpr const > std::basic_string_view<_CharT, _Traits>::value_type& > std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with > _CharT = char; _Traits = std::char_traits<char>; const_reference = const > char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' > failed. > Aborted (core dumped) While the libapt code this is crashing in should be rewritten to not crash… (which I did once, but it was kinda ugly, so we discarded it, but now that a bunch of std::string_view recently landed perhaps…) anyway, this is a test that is trying to trigger an exception. Do you perhaps build with exceptions disabled? Or was GoogleTest perhaps built without them? Which type of GoogleTest is that anyhow, the pre-built or the one that is build with apt. Our buildsystem supports both in theory, but GoogleTest upstream tends to advice against building the goods and the tests differently – in Debian that doesn't usually happen, but in a more source-orientated (AUR stuff is built on user-systems, right?) this might be more of a factor, maybe? At least I assume that both "failures" are a red herring and the actual problem causing them is deeper and more related to how Arch is setup. Hence my interest in chroot instructions… if you can't reproduce it there, we have a first good lead. Best regards David Kalnischkies
signature.asc
Description: PGP signature
