@qrilka_twitter I see. Let me check it first. Thanks.
Sure, it's just a card, if you'd like to dive into that task feel free to open a proper issue. We've touch this topic when talking with @snoyberg just this week. I guess he will share his ideas on it. As far as I remember the main point was that we now store some "last used" timestamp for snapshots. So "g" could mean something like "any snapshots not used for N months"
I see. OK. Let me try to get some concepts. Just wiped my folder, cannot say which parts take the most space. Also, still on this topic, is it simpler to provide user some kind of manual management? Like listing all ghc versions, and remove all building cache related to one version, some kind.
The last couple of days (at least yesterday and today) I've seen this behaviour a lot:
Preparing to download ghc-8.6.5 ...
ghc-8.6.5: download has begun
ghc-8.6.5: 17.49 MiB / 175.83 MiB ( 9.95%) downloaded...
ghc-8.6.5: 47.24 MiB / 175.83 MiB ( 26.87%) downloaded...
ghc-8.6.5: 76.67 MiB / 175.83 MiB ( 43.61%) downloaded...
ghc-8.6.5: 107.02 MiB / 175.83 MiB ( 60.86%) downloaded...
ghc-8.6.5: 136.92 MiB / 175.83 MiB ( 77.87%) downloaded...
ghc-8.6.5: 167.14 MiB / 175.83 MiB ( 95.06%) downloaded...
ghc-8.6.5: 175.83 MiB / 175.83 MiB (100.00%) downloaded...
Downloaded ghc-8.6.5.
Unpacking GHC into /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5.temp/ ...
Received ExitFailure (-15) when running
Raw command: /bin/tar Jxf /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5.tar.xz
Run from: /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5.temp/
Error: Error encountered while unpacking GHC with
tar Jxf /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5.tar.xz
run in /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5.temp/
The following directories may now contain files, but won't be used by stack:
- /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5.temp/
- /home/vsts_azpcontainer/.stack/programs/x86_64-linux/ghc-8.6.5/
For more information consider rerunning with --verbose flagBut I don't see it all the time. Am I alone?
I've seen it both on VMs (on CI services, Travis and Azure), when in Docker containers (on CircleCI), and when building a Docker image (on Travis and locally).
@qrilka_twitter I don't really have reproduction steps, but the code is available at: https://github.com/magthe/ci-test-hs/ (the branch Add Azure Pipelines)
Examples of CI builds at:
- VM, pre-built binary: https://dev.azure.com/magthe/CI%20Test/_build/results?buildId=20 (I think one can reach that with a github account)
- Building docker image (Build and deploy stage, if you look at earlier stages VM with pre-built binary worked): https://travis-ci.com/magthe/ci-test-hs/jobs/208730847
- Successful build of docker image: https://cloud.drone.io/magthe/ci-test-hs/25/1/4 (again, I think a github account is sufficient)
Building image locally (docker build -t foo:0 .) first failed, then I followed the suggestion and added --verbose, then it succeeded. Howerver, the CI builds keep failing sporadically.
I think it might have to do with buffering of output, but I'm not sure
@snoyberg An odd thing with the display of this package.
https://www.stackage.org/lts-13.26/package/unordered-containers-0.2.10.0
Shows the "latest on hackage" as 0.2.9.0
https://www.stackage.org/lts-13.26/package/unordered-containers-0.2.10.0
Shows the "latest on hackage" as 0.2.9.0
@DanBurton I think I've fixed it with this commit, it still needs to deploy fpco/stackage-server@07f3ef2
I had fun explaining that one to a non-technical family member
If anyone is running into the "mirrors.json is expired" issue, please see this issue for explanation and workaround:
Also, please feel free to weigh in with a vote on that issue.
As you can tell, I'm in favor of disabling the export checks
It is pretty obvious you are in favour of that yes :grin:
I think that, no matter what the security concerns are and how valid they are, it's a bad situation to be in, relying on upstream to keep that JSON file up-to-date when they apparently have let it expire a few times by now.
I think that, no matter what the security concerns are and how valid they are, it's a bad situation to be in, relying on upstream to keep that JSON file up-to-date when they apparently have let it expire a few times by now.
I am trying to formulate a container based workflow to build a haskell project. The idea is to share a container with all project deps (ghc, stack, libs) with other developers, so that when they build the project, only the project's files need to be built and not the deps. This workflow was possible in the 1.9.x stack version, but it is breaking in the 2.x version (all files in the project are built every time stack build is launched within the build container). Is there a workaround to let stack pick up pre-compiled dependencies from the container and still have the project build incrementally?
Maybe I've been using a hacky approach - the package cache in my build image is in /root/.stack (when I build the image with either stack version). The (multi-package) project directory is mounted into the container at /project - when I run stack 1.9 in this directory, stack keeps its work in /project/.stack-work and is able to build incrementally (i.e. when i change some source files in the project and rebuild, only the changed files and packages that depend on it are re-built). In 2.x perhaps because the sqlite db is in /root/.stack, every build rebuilds all the packages in /project.
Is there a better way @DanBurton ?
Ay. Richard Eisenberg wanted to see if there were any stack-specific issues to be discussed with regards to the "provenance qualified package imports" proposal: ghc-proposals/ghc-proposals#115
My sense is that this is all generally build-tool agnostic stuff that's prior to that phase, but it is indeed good to double check
Compiler thinks a type is different depending on where it is referenced
Are there any workarounds in the meantime? Maybe even some tips as to how someone could submit a patch to fix it?