On Tue, 2022-05-31 at 09:52 -0400, Scott Talbert wrote: > > Quoting Scott Talbert (2022-05-31 15:04:51) > > > In thinking about the packages that are FTBFS when using > > > LC_ALL=C, this is > > > cause by somewhat of a regression in haskell-devscripts, since > > > the old > > > install recipe used to set LC_ALL=C.UTF-8[1] before running the > > > command > > > where most of these packages are failing (due to the copyright > > > symbol). > > > > > > I'm thinking that rather than update all of these individual > > > packages (and > > > who knows how many more) to set LC_ALL=C.UTF-8, we should restore > > > this > > > setting in haskell-devscripts, and perhaps even set LC_ALL=C.UTF- > > > 8 > > > globally in hlibrary.mk? > > > > > > What do you all think? > > > > I think it should be set as minimally as possible - and clearly > > documented. > > > > E.g. only within the rules known to specifically need it, not > > loaded > > into the global make environment across all make targets. > > That was my initial thinking, too. However, the buildd's set > LC_ALL=C.UTF-8, so wouldn't we want packages built outside the > buildd's to > be built consistently? I think it might make sense to be as minimal as possible. I think the reproducibility tests alternative locales (e.g., fr_CH.UTF-8). If we force this for everything it would make it impossible to run buildtime tests in different locales. If it is fixed minimally, the haskell-filestore package will need it setting in debian/rules as the tests explicitly test non-ascii filepaths. For reference, there are 164 packages that FTBFS that are maintained by the haskell team. -- Robert
Attachment:
signature.asc
Description: This is a digitally signed message part