Open sten0 opened 4 years ago
A colleague of mine confirmed that the trigger is when tests are executed in a non-UTF-8 environment. It may be reasonable to assume a UTF-8 environment in 2024, and make wgrep throw an error when loading when a non-UTF-8 environment is detected. Alternatively, converting to and from UTF-8 looks like it will be required.
With f0ef9bf,
wgrep-bom-with-multibyte
andwgrep-bom-with-unibyte
still often fail. The test passes on some CI infrastructure but not others, so it looks like a flaky test or a corner-case to me. eg: our CI does various forms of minor fuzzing for basic QA. If it looks more like a problem in our infrastructure (rare, but sometimes happens) please let me know why, and I'll contact the people who are responsible for this. At this time, tests are run with Emacs 26.3, but we'll most likely be switching to 27.1 sometime in the next few months. I've also confirmed test pass on my local system. By the way, I sincerely appreciate that you're providing these tests :-)Were I to hasard a guess as to why the tests are failing on the buildd network, but not the DebCI network, it would be because buildd sets
LANG='C'
andLANGUAGE='en_US:en'
, and maybe wgrep assumes a UTF-8 locale? I'm sorry I can't be of more help at this time. Assuming it's not a subtle dynamic binding issue, I suspect the solution will be something like modifying wgrep-mode to use one of these https://www.gnu.org/software/emacs/manual/html_node/elisp/Converting-Representations.html on non-UTF8 systems.Here's the data:
Full build logs for all tested architectures available here (all failing): https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/emacs-wgrep.html
And the logs from our second CI network (all passing, except wgrep-ag-normal which is skipped due to #73) https://ci.debian.net/packages/e/emacs-wgrep/testing/amd64/ https://ci.debian.net/data/autopkgtest/testing/amd64/e/emacs-wgrep/6761710/log.gz