Obviously not for screened. Oh, and I forgot to mention that the error only
happens on Linux.

1 patch for repository http://darcs.net/screened:

patch 101d824f8aa74f1e3535ea3b8cfb17a063a08686
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon May 29 11:57:59 CEST 2023
  * WIP adjustments to allow building with ghc-9.6

  This patch currently breaks tests/switch-encoding.sh, regardless of which
  ghc/base version is used. The error happens when we try to send a bundle
  with UTF8 encoded meta data and content with the environment set to
  LC_ALL=C. The message is:

    darcs: recoverEncode: invalid argument (invalid character)

Attachments

• patch-preview.txt
• wip-adjustments-to-allow-building-with-ghc_9_6.dpatch

Just capturing some notes from Vekhir on IRC:

I've been investigating https://bugs.darcs.net/patch2296 and think
it is related to https://gitlab.haskell.org/ghc/ghc/-/issues/20344.

When darcs sets the LocaleEncoding in                 
https://hub.darcs.net/darcs/darcs-
screened/browse/src/Darcs/UI/External.hs#532,
darcs seems to assume that the return of getFileSystemEncoding is always 
Unicode-compatible.

However, as above linked issue in GHC explains, getFileSystemEncoding can 
also be ASCII. I have verified that GHC 9.0.2, 9.2.8, 9.4.8, and 9.6.3 all 
return ASCII when LC_ALL=C is set.

I don't know why switch-encoding works in earlier versions of GHC (<9.6). 
Perhaps some change in unix 2.8 causes the difference in behaviour.
2.7.2.2 (included in the earlier GHC versions) was first shipped with
GHC 8.2, so there's about 5 years worth of changes. I'm bound to versions 
shipped with GHC, so can't investigate which commit if any causes the 
issue.

It looks like the problem is actually triggered by directory, 
specifically this commit: 
https://github.com/haskell/directory/commit/78b3e596502e180f228299f10726
e13837d0a352

I haven't dug any further yet.

It is actually a different error after that commit compared to directory 
1.3.8:

| parse error in file _darcs/rebase
| not enough input

154a29c9fd2dddaa830faee66d84df528a92199c is the commit that flips to the 
error about recoverEncode

Moving the discussion about the problem to issue2716

I've lost track of where we are wrt ghc >= 9.6. Is this patch still relevant or can it be obsoleted?

This one is obsolete - darcs does support ghc-9.6 (and 9.8) now.

The test failure was resolved by https://bugs.darcs.net/patch2368