Closed baryluk closed 3 years ago
According to the logs dpkg-deb -x is failing to run
INFO:AptPackageDeploy:Deploying libstdc++6_10.2.1-6_amd64.deb to /home/user/vps1/home/baryluk/Projekty/multimonitor/AppDir/opt/libc tar: ./usr/share/doc/libstdc++6: Cannot utime: No such file or directory tar: Exiting with failure status due to previous errors dpkg-deb: error: tar subprocess returned error exit status 2
could you try to run it manually like this dpkg-deb -x < path to libstdc++6_10.2.1-6_amd64.deb> <path to AppDir/opt/libc>
I would like to discard that it's a dpkg-deb issue
@azubieta yes, dpkg-deb -x
fails with the same error.
strace shows this near the end:
...
[pid 2387865] mkdirat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu", 0700) = -1 EEXIST (File exists)
[pid 2387865] newfstatat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 2387865] openat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28-gdb.py", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0644) = -1 EEXIST (File exists)
[pid 2387865] unlinkat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28-gdb.py", 0) = 0
[pid 2387865] openat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28-gdb.py", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0644) = 3
[pid 2387865] write(3, "# -*- python -*-\n# Copyright (C)"..., 2387) = 2387
[pid 2387865] utimensat(3, NULL, [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] close(3) = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share/gdb/auto-load/usr/lib", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share/gdb/auto-load/usr", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share/gdb/auto-load", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share/gdb", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], 0) = 0
[pid 2387865] symlinkat("libstdc++.so.6.0.28", AT_FDCWD, "./usr/lib/x86_64-linux-gnu/libstdc++.so.6") = -1 EEXIST (File exists)
[pid 2387865] unlinkat(AT_FDCWD, "./usr/lib/x86_64-linux-gnu/libstdc++.so.6", 0) = 0
[pid 2387865] symlinkat("libstdc++.so.6.0.28", AT_FDCWD, "./usr/lib/x86_64-linux-gnu/libstdc++.so.6") = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/lib/x86_64-linux-gnu/libstdc++.so.6", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], AT_SYMLINK_NOFOLLOW) = 0
[pid 2387865] openat(AT_FDCWD, "./usr/lib/x86_64-linux-gnu/libstdc++.so.6", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3
[pid 2387865] newfstatat(3, "", {st_mode=S_IFLNK|0777, st_size=19, ...}, AT_EMPTY_PATH) = 0
[pid 2387865] close(3) = 0
[pid 2387865] symlinkat("gcc-10-base", AT_FDCWD, "./usr/share/doc/libstdc++6") = -1 EEXIST (File exists)
[pid 2387865] unlinkat(AT_FDCWD, "./usr/share/doc/libstdc++6", 0) = 0
[pid 2387865] symlinkat("gcc-10-base", AT_FDCWD, "./usr/share/doc/libstdc++6") = 0
[pid 2387865] utimensat(AT_FDCWD, "./usr/share/doc/libstdc++6", [UTIME_OMIT, {tv_sec=1610278539, tv_nsec=0} /* 2021-01-10T11:35:39+0000 */], AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
...
It seems that we have to fill a bug on the dpkg bug tracker then. If you found any workaround please leave it here for future users.
It looks like the bug is actually in the tar
. tar -x -p -f data.tar.xz
(after extracting manually data.tar.xz using ar x libc6*.deb
), shows same issue.
tar
correctly passes AT_SYMLINK_NOFOLLOW
. And the file it is trying to update utime
exists:
lrwxrwxrwx 1 user user 32 May 7 17:00 ./lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.31.so
Maybe it is a bug in the FUSE. Anyway, closing, as this is not appimage-builder
issue.
It is sshfs bug. https://github.com/libfuse/sshfs/issues/250
Sorry for the noise here. I just never experienced this issue despite me using sshfs
daily for last few years, until I tried appimage-builder.
Moving, the entire directory
~/tmp
(on tmpfs), makes it not fail and successfully build the AppImage