Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
fcb8b19737
6 changed files with 141 additions and 0 deletions
|
|
@ -0,0 +1,92 @@
|
|||
### 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:
|
||||
|
||||
[[!format sh """
|
||||
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?
|
||||
|
||||
[[!format sh """
|
||||
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:
|
||||
|
||||
[[!format diff """
|
||||
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. :)
|
||||
|
||||
[[!meta author=jkniiv]]
|
||||
[[!meta title="windows: Resolver lts-19.16 still causes trouble with Win32 for stack builds"]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Ilya_Shlyakhter"
|
||||
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
|
||||
subject="lts version"
|
||||
date="2022-07-31T17:25:27Z"
|
||||
content="""
|
||||
Did the resolver change to lts-19.16? [`stack.yaml` on hackage](https://hackage.haskell.org/package/git-annex-10.20220724/src/stack.yaml) still seems to say lts-18.
|
||||
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="jkniiv"
|
||||
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
|
||||
subject="comment 2"
|
||||
date="2022-07-31T18:00:59Z"
|
||||
content="""
|
||||
@Ilya: Yes, the change took place in commit [[!commit b5dc04099efd8b1bd2dbfa09a288518eabf8ceec]] which was some 24 hours after
|
||||
release 10.20220724. :)
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="Dan"
|
||||
avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
|
||||
subject="comment 14"
|
||||
date="2022-07-29T22:02:56Z"
|
||||
content="""
|
||||
Ah, I hadn't considered the parallel to the standard `find` command, but now that you mention that I understand where you're coming from and can appreciate why `whereis` is free of this association.
|
||||
Still, I would think that a user who, after looking at the docs for `git annex find`, specified `--all` because they wanted to operate on keys would not be surprised.
|
||||
|
||||
I notice that the man page for `git annex find` already has a \"SEE ALSO\" reference to `git annex whereis`.
|
||||
Could this be expanded so that it more clearly and prominently advises the reader who is looking to query against all known keys to check out the `--all` argument to `git annex whereis` as well as its `--format=` option if \"whereis\" information is not actually of interest?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="Atemu"
|
||||
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
|
||||
subject="comment 15"
|
||||
date="2022-07-30T15:30:31Z"
|
||||
content="""
|
||||
How about a `git annex find --keys` option? That way it's crystal clear you're searching among keys rather than files.
|
||||
"""]]
|
||||
10
doc/users/jkniiv.mdwn
Normal file
10
doc/users/jkniiv.mdwn
Normal file
|
|
@ -0,0 +1,10 @@
|
|||
This is the git-annex wiki page for the user jkniiv aka. Jarkko Kniivilä.
|
||||
|
||||
I'm a gen-X Windows/Linux geek from Hämeenlinna, Finland (the EU), who has been using git-annex on and off
|
||||
for a few years now but only since late 2019 or so in earnest. I finally found a use case with managing the
|
||||
relatively huge files that are the backup images of my laptops. I also tend to add whole external hdds into
|
||||
their respective annexes (with an annex.largefiles setting at 1 megabytes) then cloning those to my laptops
|
||||
secondary drive E: (on an ssd) without getting the annex objects and thus keeping a rudimentary catalog of my
|
||||
offline files always at hand.
|
||||
|
||||
In a past life I used to be a systems specialist (Linux servers and FOSS) for an internet consultancy.
|
||||
Loading…
Reference in a new issue