Closed gjost closed 6 years ago
This is happening on the detail page for a mezzanine binary, in the code that produces the list of remote locations of the file:
Trusted remotes
hq-shenandoah 89b6858d-247f-4343-b49c-784900dd8c3d
ddr@ddr-editor:/media/qnfs/kinkura/gold/ddr-densho-332 a4d84966-2048-4b01-9327-eb682d00de7c
cloud-backblaze-b2 bd80b391-5f37-4e57-814c-5a614587b2e6
On the affected machine:
densho@ddreditor:~$ sudo git annex version
[sudo] password for densho:
git-annex version: 6.20170101.1
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
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 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
GFroh: looks like editor is looking for the b2 annex extension app b/c the repo on kinkura has a b2 spec remote.
FWIW I cloned that repo on my local. I can see the backblaze remote in the repo's list of remotes but i dont get the error.
GFroh: that’s b/c the special remote is not connected to your repo. looks like joeyh has a way of telling git annex to ignore certain remotes by default; but that functionality is in a slightly newer version than what we’re running (http://git-annex.branchable.com/forum/Is_there_an___39__annex-cost__39___to_NEVER_access_remote__63__/) (‘annex-ignore’) we’re going to see what happens if the b2 extension is available, but without credentials defined so it won’t actually be able to make the network call. if git-annex just reports an error trying to reach that remote, but doesn’t throw a full exception (and properly checks whereis status for the other remotes) then maybe we can just call it good.
Add config file setting to optionally disable the git-annex-whereis call.
We'll work at HQ to redesign the backup infrastructure so that the b2
special remotes are attached to repo clones outside of gold
I added a new config setting that controls whether file-detail runs git-annex-wheres:
[local]
git_annex_whereis=True
Set it to False
and restart to disable whereis.
so on 2.2.7 i got binaries to work but no dice on master. i have git_annex_whereis=False
in both the ddrlocal.cfg and ddrlocal-local.cfg
tried setting it to false even in the ddrlocal.cfg.dpkg-dist to no avail.
Did you restart the app? sudo service supervisor restart
ddr-cmdln
and ddr-local
only look at config files ending in .cfg
- they would ignore ddrlocal.cfg.dpkg-dist
.
I've never even seen a ddrlocal.cfg.dpkg-dist
file. My guess is that it's something the Debian packaging system (dpkg is a component of this) put in while installing, probably if it was trying to install ddrlocal.cfg
but it was already there or something. (For instance, if I'm replacing or editing a system config file I often make a copy of the original called SOMEFILE.conf.orig
)
You might have gotten that if you removed ddrlocal-develop
and installed ddrlocal-master
on a system. apt-get remove
uninstalls the specified app but usually leaves config files in place. IIRC apt-get purge
the configs and any other files associated with a package.
Update/Correction: The packager should ask what you want to do with an existing config file. The default behavior is to leave whatever is already there in place, and to install the package's version as FILE.dpkg-dist
in the same directory. So you probably want to do this:
cd /etc/ddr; sudo mv ddrlocal.cfg.dpkg-dist ddrlocal.cfg`
and then restart.
pkikawa 2018-03-23 16:31: