Please describe the problem.
The change of resolver to LTS 19 (lts-19.16) still causes stack builds to fail on Windows
with a plan construction problem. Pinning Win32 as Win32-2.11.1.0
in extra-deps as
suggested by stack is not enough to resolve the issue -- one has to go further and
pin Win32 as Win32-2.9.0.0
and do similarly with a few other GHC boot packages
including Cabal
. This setup then builds and tests just fine. I'm aware this needs to
be probably addressed in the cabal file instead but as a user the patch below is my
local fix for the issue.
What steps will reproduce the problem?
stack setup && stack build
. Observe the following output:
Warning: C:\Projektit\git-annex.branchable.com\git-annex--BUILD-220730-b5dc04099\stack.yaml: Unrecognized field in ProjectAndConfigMonoid: explicit-setup-deps
Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for git-annex-10.20220724(+assistant
+benchmark
-dbus
-debuglocks
+gitlfs
-magicmime
+pairing
+production
+torrentparser
+webapp):
Win32-2.12.0.1 from stack configuration does not match (>=2.6.1.0 && <2.12.0.0) (latest
matching version is 2.11.1.0)
needed since git-annex is a build target.
Some different approaches to resolving this:
* Set 'allow-newer: true'
in C:\hs-stack\config.yaml to ignore all version constraints and build anyway.
* Recommended action: try adding the following to your extra-deps
in C:\Projektit\git-annex.branchable.com\git-annex--BUILD-220730-b5dc04099\stack.yaml:
- Win32-2.11.1.0@sha256:f503acb4ea2e7da6433549d5ff7d0851da54f226df032b40ae51559c7914d62f,4387
Plan construction failed.
# End of transcript or log.
What version of git-annex are you using? On what operating system?
git-annex version: 10.20220725-gb5dc04099
build flags: Assistant Webapp Pairing TorrentParser Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: mingw32 x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
A successful build that passes the testsuite is achieved with the patch to stack.yaml
below.
Windows 10 version 21H2 (build 19044.1826), 64 bit.
Please provide any additional information below.
Apply the following patch to build on Windows:
diff --git a/stack.yaml b/stack.yaml
index 8ca5d7383..94b724fe2 100644
--- a/stack.yaml
+++ b/stack.yaml
@@ -22,5 +22,10 @@ extra-deps:
- network-multicast-0.3.2
- sandi-0.5
- torrent-10000.1.1
+- Win32-2.9.0.0
+- Cabal-3.6.3.0
+- directory-1.3.7.1
+- process-1.6.14.0
+- time-1.11.1.2
explicit-setup-deps:
git-annex: true
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer.
stack.yaml
on hackage still seems to say lts-18.@Ilya: Yes, the change took place in commit b5dc04099efd8b1bd2dbfa09a288518eabf8ceec which was some 24 hours after release 10.20220724.
Hey, thanks and sorry for inflicting that stack change on you a second time. I hypothesized that the toolchain installation, that failed before, might have been a transient problem, and it seems it was, but now these other problems surface..
Surprisingly, putting Win32 in the stack file does not break stack build on linux. But I don't like putting it in there regardless, and needing to downgrade the other dependencies for it is also suboptimal.
I'll revert the stack.yaml change again, and it seems we'll need to wait for ?em>entities to be fixed before updating it.
@joey: No problem. Most of my git-annex use is rather vanilla (apart from annexing huge files) so I don't usually need the very latest in git-annex so I can always fall back to an earlier release/build. It's just that I like to keep track of git-annex's development and make sure it works on Windows most of the time which means I feel a need to build fresh versions and then kind of dogfood them as soon as possible. As a non-developer being able to report build errors and other bugs is my way of taking part in this project and hopefully in the process help make things smoother for the Windows user constituent that I represent.
PS. Ikiwiki broke that link you made to my related todo. What's with that? The backlink appears in the todo, however.