Patch 2296 WIP adjustments to allow building with ghc-9.6

Title WIP adjustments to allow building with ghc-9.6
Superseder Nosy List bfrk
Related Issues
Status obsoleted Assigned To

Created on 2023-05-30.18:19:19 by bfrk, last changed 2024-05-11.08:14:29 by ganesh.

File name Status Uploaded Type Edit Remove
patch-preview.txt bfrk, 2023-05-30.18:19:17 text/x-darcs-patch
wip-adjustments-to-allow-building-with-ghc_9_6.dpatch bfrk, 2023-05-30.18:19:17 application/x-darcs-patch
See mailing list archives for discussion on individual patches.
msg23295 (view) Author: bfrk Date: 2023-05-30.18:19:17
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)
msg23742 (view) Author: ganesh Date: 2024-02-18.20:23:06
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                 
darcs seems to assume that the return of getFileSystemEncoding is always 

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. (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 
msg23744 (view) Author: ganesh Date: 2024-02-19.09:00:23
It looks like the problem is actually triggered by directory, 
specifically this commit: 

I haven't dug any further yet.
msg23745 (view) Author: ganesh Date: 2024-02-19.09:41:30
It is actually a different error after that commit compared to directory 

| parse error in file _darcs/rebase
| not enough input
msg23746 (view) Author: ganesh Date: 2024-02-19.09:55:14
154a29c9fd2dddaa830faee66d84df528a92199c is the commit that flips to the 
error about recoverEncode
msg23750 (view) Author: ganesh Date: 2024-02-19.18:23:08
Moving the discussion about the problem to issue2716
msg23798 (view) Author: bfrk Date: 2024-05-10.12:08:53
I've lost track of where we are wrt ghc >= 9.6. Is this patch still relevant or can it be obsoleted?
msg23807 (view) Author: ganesh Date: 2024-05-11.08:14:29
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
Date User Action Args
2023-05-30 18:19:19bfrkcreate
2023-06-24 14:58:56ganeshsetstatus: needs-screening -> followup-in-progress
2024-02-18 20:23:06ganeshsetmessages: + msg23742
2024-02-19 09:00:24ganeshsetmessages: + msg23744
2024-02-19 09:41:30ganeshsetmessages: + msg23745
2024-02-19 09:55:14ganeshsetmessages: + msg23746
2024-02-19 18:23:08ganeshsetmessages: + msg23750
2024-05-10 12:08:54bfrksetmessages: + msg23798
2024-05-11 08:14:29ganeshsetstatus: followup-in-progress -> obsoleted
messages: + msg23807