Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
9a1f14e6f0
10 changed files with 150 additions and 0 deletions
52
doc/bugs/Remote__47__Glacier.hs_build_error_GHC_9.0.1.mdwn
Normal file
52
doc/bugs/Remote__47__Glacier.hs_build_error_GHC_9.0.1.mdwn
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
### Please describe the problem.
|
||||
Build error 1 during build process of git-annex on alpine 5.15 using GHC 9.0.1.
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
Build git-annex on alpine 5.15 using following APKBUILD:
|
||||
https://github.com/ayakael/aports/blob/testing/git-annex/testing/git-annex/APKBUILD
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
git-annex: 20211123
|
||||
os: alpine linux 5.15
|
||||
ghc: 9.0.1
|
||||
cabal: 3.6.2.0
|
||||
|
||||
### Please provide any additional information below.
|
||||
I made an attempt of fixing by reverting the first fix attempt done on line 181 by commit 2739adc. It gave the same error, but it is most likely related. I know very little of haskell, thus could not push the debugging further.
|
||||
|
||||
[[!format sh """
|
||||
# If you can, paste a complete transcript of the problem occurring here.
|
||||
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
|
||||
[411 of 670] Compiling Remote.Glacier ( Remote/Glacier.hs, /var/build/aports/testing/git-annex/src/git-annex-8.20211123/dist-newstyle/build/x86_64-linux/ghc-9.0.1/git-annex-8.20211123/build/git-annex/git-annex-tmp/Remote/Glacier.o, /var/build/aports/testing/git-annex/src/git-annex-8.20211123/dist-newstyle/build/x86_64-linux/ghc-9.0.1/git-annex-8.20211123/build/git-annex/git-annex-tmp/Remote/Glacier.dyn_o )
|
||||
|
||||
Remote/Glacier.hs:179:12: error:
|
||||
• Couldn't match type: Key
|
||||
-> MeterUpdate
|
||||
-> Maybe Utility.Hash.IncrementalVerifier
|
||||
-> (ContentSource -> Annex a0)
|
||||
-> Annex a0
|
||||
with: forall a.
|
||||
Key
|
||||
-> MeterUpdate
|
||||
-> Maybe Utility.Hash.IncrementalVerifier
|
||||
-> (ContentSource -> Annex a)
|
||||
-> Annex a
|
||||
Expected: Remote -> Retriever
|
||||
Actual: Remote
|
||||
-> Key
|
||||
-> MeterUpdate
|
||||
-> Maybe Utility.Hash.IncrementalVerifier
|
||||
-> (ContentSource -> Annex a0)
|
||||
-> Annex a0
|
||||
• In the expression: byteRetriever . retrieve'
|
||||
In an equation for ‘retrieve’: retrieve = byteRetriever . retrieve'
|
||||
|
|
||||
179 | retrieve = byteRetriever . retrieve'
|
||||
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
make: *** [Makefile:58: git-annex] Error 1
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
### 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)
|
||||
Oh absolutely. This version compiles fine under alpine 5.14, which uses GHC 8.8.4. I've been using this software for many years without major issues, and it's a linchpin of my backup infrastructure. Thanks for the all the good work!
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="mih"
|
||||
avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
|
||||
subject="Translates to Windows!"
|
||||
date="2021-11-25T07:34:48Z"
|
||||
content="""
|
||||
Sorry for being silent for so long. I just got a contemporary machine with windows, such that hardware age should no longer be a concern for any performance comparison.
|
||||
|
||||
I did not yet find the time to re-assess this issue in full, but I tried the new filter-process setting with a simple `datalad create` (this only adds a few tiny files, but nevertheless took long, and was the original motivation for this issue). Enabling the new setting reduces the runtime by 25% (from 4.5s to 3.5s on average).
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
[[!comment format=mdwn
|
||||
username="mih"
|
||||
avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
|
||||
subject="More statistics"
|
||||
date="2021-11-25T13:09:11Z"
|
||||
content="""
|
||||
I looked into the global affect of this switch on a large and versatile set of use cases in the form of the DataLad test suite: https://github.com/datalad/datalad/pull/6245
|
||||
|
||||
It is worth keeping in mind that there are only small-size files involved!
|
||||
|
||||
The benefit is somewhere between noticeable and remarkable. An overall runtime reduction of 16% with benefits ranging from 5% to 32% depending on the tested functionality.
|
||||
|
||||
This will need a bit of further investigation to drill down on the reason for this large variability, but given that the sign is always in the right direction this is really great! Thx much!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="mih"
|
||||
avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
|
||||
subject="Even more impact on real systems"
|
||||
date="2021-11-26T14:23:34Z"
|
||||
content="""
|
||||
It seems the impact on real systems is even more sever: https://github.com/datalad/datalad/pull/6245#issuecomment-979992551 -- factor 2-3 faster on that particular machine. Maybe consumer systems do some kind of expensive process startup inspection (antivirus?) that bring a swarm of child processes to a crawl.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="Atemu"
|
||||
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
|
||||
subject="comment 20"
|
||||
date="2021-11-25T19:23:46Z"
|
||||
content="""
|
||||
Also ran across this today. All I did was a simple copy of a few files to a remote using a filter. I can provide the index and lck files if needed.
|
||||
|
||||
git-annex version: 8.20211011
|
||||
"""]]
|
||||
|
|
@ -15,3 +15,5 @@ conda linux nodep (standalone) build 8.20211012-geb95ed486 and then with another
|
|||
|
||||
|
||||
|
||||
[[!meta author=yoh]]
|
||||
[[!tag projects/datalad]]
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="jkniiv"
|
||||
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
|
||||
subject="comment 4"
|
||||
date="2021-11-23T21:46:43Z"
|
||||
content="""
|
||||
Thanks Joey for investigating this issue thoroughly. Also, my thanks to kyle for expanding my initial report
|
||||
with Linux-related details I didn't have time to prepare.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
### Please describe the problem.
|
||||
I've a type=directory remote, with exporttree=yes on a USB disk. when running `git annex --content` git annex list a long list of `export cibox-usb toto ok` lines for file it already exported before. I’ve check some of those file, and their content are correct.
|
||||
|
||||
Those line hide real new export, and I wonder if it doesn’t slow the process.
|
||||
|
||||
There seem to be no way to tell git-annex that those file are already ok, and it should try again to export them.
|
||||
`
|
||||
|
||||
### What steps will reproduce the problem?
|
||||
|
||||
Just running `git annex --content name-of-the-remote`
|
||||
|
||||
|
||||
### What version of git-annex are you using? On what operating system?
|
||||
git annex from Debian :
|
||||
|
||||
git-annex version: 8.20211011
|
||||
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
|
||||
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
|
||||
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: linux x86_64
|
||||
supported repository versions: 8
|
||||
upgrade supported from repository versions: 0 1 2 3 4 5 6 7
|
||||
local repository version:
|
||||
|
||||
### 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)
|
||||
It’s only a bug on what git-annex display. It does the asked work: the file are correctly exported where I look for them.
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 2"
|
||||
date="2021-11-23T23:12:47Z"
|
||||
content="""
|
||||
I see that. But the entire run was not prohibitively long - just 30m 21s... previous succesful though ran total 22m 14s (see eg [here](https://github.com/datalad/git-annex/runs/4271323847?check_suite_focus=true)) so may be test started to stall?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 3"
|
||||
date="2021-11-23T23:22:36Z"
|
||||
content="""
|
||||
oh that [successful log](https://github.com/datalad/git-annex/runs/4271323847?check_suite_focus=true) doesn't even have any line with `migrate`, so some new test stalling on NFS HOME/CWD?
|
||||
"""]]
|
||||
Loading…
Reference in a new issue