Wayland_protocols_jll install tree hash error

I am trying to install Gtk on linux (RedHatEnterprise 8.8) with Julia 1.10.2 from a clean slate (I purged ~/.julia) and add fails when fetching “Wayland_protocols_jll”
So I tried simply ]add Wayland_protocols_jll and that fails with hash mismatch:

Downloaded artifact: Wayland_protocols
ERROR: Unable to automatically download/install artifact 'Wayland_protocols' from sources listed in '/home/fessler/.julia/packages/Wayland_protocols_jll/bXHUY/Artifacts.toml'.
Sources attempted:
- https://pkg.julialang.org/artifact/97ba5172167298b990339cda263370d192688f61
    Error: Tree Hash Mismatch!
  Expected git-tree-sha1:   97ba5172167298b990339cda263370d192688f61
  Calculated git-tree-sha1: db4da094e21fb0d44033a9f6d789a8315bc31fe2

- https://github.com/JuliaBinaryWrappers/Wayland_protocols_jll.jl/releases/download/Wayland_protocols-v1.31.0+0/Wayland_protocols.v1.31.0.any.tar.gz
    Error: Tree Hash Mismatch!
  Expected git-tree-sha1:   97ba5172167298b990339cda263370d192688f61
  Calculated git-tree-sha1: db4da094e21fb0d44033a9f6d789a8315bc31fe2

I never had such a failure before. How does one diagnose this and where would one even report an issue?

What filesystem do you use? You should be able to see it with the command

df -T
1 Like

Ah, this is is a university login server and I believe it is running AFS.
Here is the output:

devtmpfs                                                             devtmpfs     9064672           0    9064672   0% /dev
tmpfs                                                                tmpfs        9094764          20    9094744   1% /dev/shm
tmpfs                                                                tmpfs        9094764      947276    8147488  11% /run
tmpfs                                                                tmpfs        9094764           0    9094764   0% /sys/fs/cgroup
/dev/mapper/vg1-lv_root                                              ext4        59639716    50498128    6079624  90% /
/dev/sda2                                                            ext4          989032      317412     604036  35% /boot
/dev/mapper/vg1-lv_tmp                                               ext4        30787492       64812   29133432   1% /tmp
/dev/sda1                                                            vfat          511720        5944     505776   2% /boot/efi
AFS                                                                  afs       2147483647           0 2147483647   0% /afs
macc-isi-nfs4.value.storage.umich.edu:/caen-linux-apps/clse2022/caen nfs4      4194304000  3811837952  382466048  91% /usr/caen
macc-isi-nfs4.value.storage.umich.edu:/caen-linux-apps/clse2022/um   nfs4      4194304000  3811837952  382466048  91% /usr/um
macc-isi-nfs4.value.storage.umich.edu:/caen-linux-apps               nfs4      4194304000  3811837952  382466048  91% /opt/caen
tmpfs                                                                tmpfs        1818952           0    1818952   0% /run/user/114315090
//engin-labs.m.storage.umich.edu/engin-labs-linux/seunggu/dotfiles   cifs     57671680000 50663553632 7008126368  88% /home/seunggu
tmpfs                                                                tmpfs        1818952           0    1818952   0% /run/user/9195
//engin-labs.m.storage.umich.edu/engin-labs-linux/fessler/dotfiles   cifs     57671680000 50663553632 7008126368  88% /home/fessler

Thank you so much for replying. I am teaching a large freshman DSP class using Julia and suddenly Gtk has stopped working on macOS (see Gtk not working on MacOS Sonoma 14.4 or 14.4.1 · Issue #698 · JuliaGraphics/Gtk.jl · GitHub) so now I am trying to give them linux and windows options. And of course it is final project time in the semester…

The tree hash check depends on the filesystem, and it hasn’t been tested on uncommon filesystems like AFS, so it’s possible the implementation is incorrect for that system. In this case you can set the environment variable JULIA_PKG_IGNORE_HASHES:

export JULIA_PKG_IGNORE_HASHES="true"

before starting julia to ignore that test.

To anyone else reading this: do not pre-emptively set JULIA_PKG_IGNORE_HASHES unless you’re 100% certain it solves a real issue (and in that case please report it to Pkg.jl), as you’d ignore potential security issues!

2 Likes

It looks like all the files are being set as executable.

julia> using Pkg, Tar, Downloads, Inflate

julia> url = "https://github.com/JuliaBinaryWrappers/Wayland_protocols_jll.jl/releases/download/Wayland_protocols-v1.31.0+0/Wayland_protocols.v1.31.0.any.tar.gz";

julia> write("data.tar", inflate_gzip(Downloads.download(url)))
555008

julia> Tar.tree_hash("data.tar")
"97ba5172167298b990339cda263370d192688f61"

julia> Tar.extract("data.tar", "extracted-tar");

julia> Pkg.GitTools.tree_hash("extracted-tar") |> bytes2hex
"97ba5172167298b990339cda263370d192688f61"

julia> chmod("extracted-tar", 0o777; recursive=true)
"extracted-tar"

julia> Pkg.GitTools.tree_hash("extracted-tar") |> bytes2hex
"db4da094e21fb0d44033a9f6d789a8315bc31fe2"

1 Like

Does

(@v1.10) pkg> test Tar

pass for you?

]add Tar followed by ]test Tar fails with the same hash problem:

ERROR: Unable to automatically download/install artifact 'Tar' from sources listed in '/home/fessler/.julia/packages/Tar_jll/1VjwH/Artifacts.toml'.
Sources attempted:
- https://pkg.julialang.org/artifact/c1b8e405c143b54c372813d3e98b4489e808c122
    Error: Tree Hash Mismatch!
  Expected git-tree-sha1:   c1b8e405c143b54c372813d3e98b4489e808c122
  Calculated git-tree-sha1: 3816d9a52d02d8b609a7a796b1a7ba12d1f7b005

- https://github.com/JuliaBinaryWrappers/Tar_jll.jl/releases/download/Tar-v1.35.0+0/Tar.v1.35.0.x86_64-linux-gnu.tar.gz
    Error: Tree Hash Mismatch!
  Expected git-tree-sha1:   c1b8e405c143b54c372813d3e98b4489e808c122
  Calculated git-tree-sha1: 3816d9a52d02d8b609a7a796b1a7ba12d1f7b005

Next I will try with the recommended ignore hashes. Back soon…

After invoking export JULIA_PKG_IGNORE_HASHES="true" then ]test Tar works fine.

It still reports the tree hash mismatch, but then proceeds (as expected):

Environment variable $JULIA_PKG_IGNORE_HASHES is true: ignoring hash mismatch and moving artifact to the expected location
└ @ Pkg.Artifacts /usr/um/julia-1.10.2/share/julia/stdlib/v1.10/Pkg/src/Artifacts.jl:360

I am happy to help with any tests you suggest to make it work safely on AFS. Thanks so much! BTW, should I report an issue in Pkg.jl?

What do you get if you run the following in the same file system as the artifact directory:

julia> using Pkg, Tar, Downloads, Inflate

julia> url = "https://github.com/JuliaBinaryWrappers/Wayland_protocols_jll.jl/releases/download/Wayland_protocols-v1.31.0+0/Wayland_protocols.v1.31.0.any.tar.gz";

julia> write("data.tar", inflate_gzip(Downloads.download(url)))
555008

julia> Tar.tree_hash("data.tar")
"97ba5172167298b990339cda263370d192688f61"

julia> Tar.extract("data.tar", "extracted-tar");

julia> Pkg.GitTools.tree_hash("extracted-tar") |> bytes2hex
"97ba5172167298b990339cda263370d192688f61"

And do the files in “extracted-tar” have executable permissions?

The first two outputs are the same
555008 and "97ba5172167298b990339cda263370d192688f61"

The final output differs from your example:
"db4da094e21fb0d44033a9f6d789a8315bc31fe2"

Here is part of the of ls -laR. Lots of files with mode 700, so yes, executable, which is odd for xml files and such…

[fessler@caen-vnc-mi06 artifacts]$ ls -laR extracted-tar/
extracted-tar/:
total 0
drwx------. 2 fessler utmp 0 Apr 11 13:40 .
drwx------. 2 fessler utmp 0 Apr 11 13:40 ..
drwx------. 2 fessler utmp 0 Apr 11 13:40 share

extracted-tar/share:
total 0
drwx------. 2 fessler utmp 0 Apr 11 13:40 .
drwx------. 2 fessler utmp 0 Apr 11 13:40 ..
drwx------. 2 fessler utmp 0 Apr 11 13:40 licenses
drwx------. 2 fessler utmp 0 Apr 11 13:40 pkgconfig
drwx------. 2 fessler utmp 0 Apr 11 13:40 wayland-protocols

extracted-tar/share/licenses:
total 0
drwx------. 2 fessler utmp 0 Apr 11 13:40 .
drwx------. 2 fessler utmp 0 Apr 11 13:40 ..
drwx------. 2 fessler utmp 0 Apr 11 13:40 Wayland_protocols

[......]

extracted-tar/share/wayland-protocols/staging:
total 0
drwx------. 2 fessler utmp 0 Apr 11 13:40 .
drwx------. 2 fessler utmp 0 Apr 11 13:40 ..
drwx------. 2 fessler utmp 0 Apr 11 13:40 content-type
drwx------. 2 fessler utmp 0 Apr 11 13:40 drm-lease
drwx------. 2 fessler utmp 0 Apr 11 13:40 ext-idle-notify

[....]

extracted-tar/share/wayland-protocols/unstable/xdg-shell:
total 2048
drwx------. 2 fessler utmp     0 Apr 11 13:40 .
drwx------. 2 fessler utmp     0 Apr 11 13:40 ..
-rwx------. 1 fessler utmp 27375 Apr 11 13:40 xdg-shell-unstable-v5.xml
-rwx------. 1 fessler utmp 45262 Apr 11 13:40 xdg-shell-unstable-v6.xml

extracted-tar/share/wayland-protocols/unstable/xwayland-keyboard-grab:
total 1024
drwx------. 2 fessler utmp    0 Apr 11 13:40 .
drwx------. 2 fessler utmp    0 Apr 11 13:40 ..
-rwx------. 1 fessler utmp 5601 Apr 11 13:40 xwayland-keyboard-grab-unstable-v1.xml

It looks like Tar.jl is not setting permissions correctly. I would file an issue on GitHub - JuliaIO/Tar.jl: TAR files: create, list, extract them in pure Julia

Tar.jl just uses Julia’s chmod function to set permissions. I would start investigating whether chmod works in isolation.

1 Like

According to AFS Permissions (Access Control Lists) - SCS Computing Facilities - Carnegie Mellon University,

AFS ignores standard Unix permissions (the ones you set with the chmod command), with the exception of the file owner mode bits

so I’m not sure whether it’s even possible to do this correctly.

1 Like

I think it should be possible to disable the x owner mode bit with chmod.

I tried chmod from Julia and at the linux command line (both chmod 644 tmp and chmod -x tmp) and I could not remove the x bit any of these ways :frowning:

Your home directory is actually not in AFS anymore (it used it be for decades). It is on a cifs mounted network file server that is extremely not really posix / linux. Everything has fake 600 permissions no matter what (chmod does nothing at all) and it is (among other things) somewhat case insensitive. Agreed that doing it correctly on that volume is likely impossible.

As an aside about AFS: chmod would have worked fine in AFS and permissions for group and other permissions bits can be set in AFS via chmod even if they are ignored for actually determining permissions.

3 Likes