From e832676d3818ed23876416c657e12e3fc740e67a Mon Sep 17 00:00:00 2001 From: Dan Date: Fri, 29 Jul 2022 22:02:56 +0000 Subject: [PATCH 1/6] Added a comment --- ...ment_14_2acf9c8a2d261ee69f3649b05581be4d._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment diff --git a/doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment b/doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment new file mode 100644 index 0000000000..8cbea4da96 --- /dev/null +++ b/doc/git-annex-find/comment_14_2acf9c8a2d261ee69f3649b05581be4d._comment @@ -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? +"""]] From 34d7675302ff0a8964765a99351a65e8fd54a44f Mon Sep 17 00:00:00 2001 From: Atemu Date: Sat, 30 Jul 2022 15:30:31 +0000 Subject: [PATCH 2/6] Added a comment --- .../comment_15_7124135eced9d6516141bb9be8bb345e._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/git-annex-find/comment_15_7124135eced9d6516141bb9be8bb345e._comment diff --git a/doc/git-annex-find/comment_15_7124135eced9d6516141bb9be8bb345e._comment b/doc/git-annex-find/comment_15_7124135eced9d6516141bb9be8bb345e._comment new file mode 100644 index 0000000000..e191413b0e --- /dev/null +++ b/doc/git-annex-find/comment_15_7124135eced9d6516141bb9be8bb345e._comment @@ -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. +"""]] From 0b748f8d9b7b87876385cf5063d38a00383537af Mon Sep 17 00:00:00 2001 From: jkniiv Date: Sun, 31 Jul 2022 08:56:00 +0000 Subject: [PATCH 3/6] lts-19.16 causes an issue on Windows --- ...19.16_still_causes_trouble_with_Win32.mdwn | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn new file mode 100644 index 0000000000..0830314264 --- /dev/null +++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32.mdwn @@ -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"]] From 2d982ffccda81bd89978ec3251ae7eadb238bb22 Mon Sep 17 00:00:00 2001 From: Ilya_Shlyakhter Date: Sun, 31 Jul 2022 17:25:27 +0000 Subject: [PATCH 4/6] Added a comment: lts version --- ...comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment new file mode 100644 index 0000000000..31ef6d2c9f --- /dev/null +++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_1_7fc0ffa7787353cf40fff0bc8da43c1d._comment @@ -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. + + +"""]] From 0e14491e00c1aad01e8f9e986509954205bd5235 Mon Sep 17 00:00:00 2001 From: jkniiv Date: Sun, 31 Jul 2022 18:00:59 +0000 Subject: [PATCH 5/6] Added a comment --- .../comment_2_0b96112c5d57886add62d79e7bf6044e._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment diff --git a/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment new file mode 100644 index 0000000000..e62aa2a009 --- /dev/null +++ b/doc/bugs/Resolver_lts-19.16_still_causes_trouble_with_Win32/comment_2_0b96112c5d57886add62d79e7bf6044e._comment @@ -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. :) +"""]] From 53a5d2179734cc515c62597872be132a679a8caa Mon Sep 17 00:00:00 2001 From: jkniiv Date: Sun, 31 Jul 2022 18:41:02 +0000 Subject: [PATCH 6/6] created my user page --- doc/users/jkniiv.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/users/jkniiv.mdwn diff --git a/doc/users/jkniiv.mdwn b/doc/users/jkniiv.mdwn new file mode 100644 index 0000000000..6e401e56ed --- /dev/null +++ b/doc/users/jkniiv.mdwn @@ -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.