Anyone know if the #haskell #haskellstack #docker images (e.g.: https://hub.docker.com/layers/fpco/stack-build/lts-22/images/sha256-09dcc6cf3739dbb5f73bbb84dc15ee815f463409653c5159673afc7d3b4134b7?context=explore) are still maintained, and what might be the best way to report a bug?  

The LTS_SLUG _seems_ wrong, and when I attempt a `stack build` in that image, I run out of space compiling GHC. (e.g.: https://gitlab.com/bss03/restman/-/jobs/6622698704 

I _expect_ the docker image would contain a GHC that stack would find and use; I am using the matching resolver for the tag (e.g.: 22.17). 

Docker

Beans beans - Lemmy

They make you fart The more you fart the better you feel So eat your beans with every meal

Had a great weekend making updates to my #OpenSource #hsinstall project. And then getting it reinstated in #Stackage, #AppImage binary released via #Github, and the #AUR package updated for #ArchLinux. Nice feeling of accomplishment I haven't been having so much at work.
https://github.com/dino-/hsinstall #Haskell #HaskellStack
GitHub - dino-/hsinstall: Pack a haskell project into a deployable directory structure

Pack a haskell project into a deployable directory structure - GitHub - dino-/hsinstall: Pack a haskell project into a deployable directory structure

GitHub
WTF, #haskellStack? Out of the box you create a project .cabal from Odin-knows-where and just litter it with non-existing libraries and modules, that will cause execution and builds to fail? Out of the box? Why? So now I have to figure out a project config that your imagination figmanted, and remove things my project doesn't have but you put there any way, which then just gets overridden by you next time I build the project? Lovely. Not. Please tell me I'm the only one suffering this shit.