Package: tup
Version: 0.8-1+b1
Severity: normal

I'm not sure whether this problem is in tup itself or in libfuse3.

When I run tup on the minimal example whose files are attached below,
tup runs pdftex (correctly). However, pdftex fails:

$ tup init
.tup repository initialized: .tup/db
$ tup
[ tup ] [0.028s] Scanning filesystem...
[ tup ] [0.058s] Reading in new environment variables...
[ tup ] [0.085s] Parsing Tupfiles...
1) [0.002s] .
0) [0.001s] auto
[ ] 100%
[ tup ] [0.098s] No files to delete.
[ tup ] [0.098s] Generating .gitignore files...
[ tup ] [0.141s] Executing Commands...
* 0) pdftex test.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2025/dev/Debian) (preloaded format=pdftex)
restricted \write18 enabled.
entering extended mode
(./test.tex)
*
! Emergency stop.
<*>

! ==> Fatal error occurred, no output PDF file produced!
Transcript written on test.log.
*** tup messages ***
*** Command ID=30 failed with return value 1
[ ] 100%
*** tup: 1 job failed.

I modified the tupfile to run pdftex under strace. It showed that
pdftex read in the test.tex source file twice, the first time correctly. However, on the second read-in, the file had zero size (which produced
the error in pdftex). See the attached strace-extract.log


ODI1NzIxIGFjY2VzcygiLi90ZXN0LnRleCIsIFJfT0spICAgICAgID0gMAo4MjU3MjEgbmV3ZnN0 YXRhdChBVF9GRENXRDwvaG9tZS9zYW5qb3kvVHVwdGV4dGVzdD4sICIuL3Rlc3QudGV4Iiwge3N0 X2Rldj1tYWtlZGV2KDAsIDB4NTMpLCBzdF9pbm89MTQsIHN0X21vZGU9U19JRlJFR3wwNjQ0LCBz dF9ubGluaz0xLCBzdF91aWQ9MTAwMCwgc3RfZ2lkPTEwMDAsIHN0X2Jsa3NpemU9NDA5Niwgc3Rf YmxvY2tzPTgsIHN0X3NpemU9NDksIHN0X2F0aW1lPTE3NTI1OTEzNTYgLyogMjAyNS0wNy0xNVQx Njo1NTo1Ni4xOTA1NzE1NDIrMDIwMCAqLywgc3RfYXRpbWVfbnNlYz0xOTA1NzE1NDIsIHN0X210 aW1lPTE3NTI1OTEzNDcgLyogMjAyNS0wNy0xNVQxNjo1NTo0Ny4yNjY1NjUyMDkrMDIwMCAqLywg c3RfbXRpbWVfbnNlYz0yNjY1NjUyMDksIHN0X2N0aW1lPTE3NTI1OTEzNDcgLyogMjAyNS0wNy0x NVQxNjo1NTo0Ny4yNjY1NjUyMDkrMDIwMCAqLywgc3RfY3RpbWVfbnNlYz0yNjY1NjUyMDl9LCAw KSA9IDAKODI1NzIxIG9wZW5hdChBVF9GRENXRDwvaG9tZS9zYW5qb3kvVHVwdGV4dGVzdD4sICIu L3Rlc3QudGV4IiwgT19SRE9OTFkpID0gMzwvaG9tZS9zYW5qb3kvVHVwdGV4dGVzdC90ZXN0LnRl eD4KODI1NzIxIGZzdGF0KDM8L2hvbWUvc2Fuam95L1R1cHRleHRlc3QvdGVzdC50ZXg+LCB7c3Rf ZGV2PW1ha2VkZXYoMCwgMHg1MyksIHN0X2lubz0xNCwgc3RfbW9kZT1TX0lGUkVHfDA2NDQsIHN0 X25saW5rPTEsIHN0X3VpZD0xMDAwLCBzdF9naWQ9MTAwMCwgc3RfYmxrc2l6ZT00MDk2LCBzdF9i bG9ja3M9OCwgc3Rfc2l6ZT00OSwgc3RfYXRpbWU9MTc1MjU5MTM1NiAvKiAyMDI1LTA3LTE1VDE2 OjU1OjU2LjE5MDU3MTU0MiswMjAwICovLCBzdF9hdGltZV9uc2VjPTE5MDU3MTU0Miwgc3RfbXRp bWU9MTc1MjU5MTM0NyAvKiAyMDI1LTA3LTE1VDE2OjU1OjQ3LjI2NjU2NTIwOSswMjAwICovLCBz dF9tdGltZV9uc2VjPTI2NjU2NTIwOSwgc3RfY3RpbWU9MTc1MjU5MTM0NyAvKiAyMDI1LTA3LTE1 VDE2OjU1OjQ3LjI2NjU2NTIwOSswMjAwICovLCBzdF9jdGltZV9uc2VjPTI2NjU2NTIwOX0pID0g MAo4MjU3MjEgcmVhZCgzPC9ob21lL3NhbmpveS9UdXB0ZXh0ZXN0L3Rlc3QudGV4PiwgIlxcZGVm XFx4e1xcdGltZXN9XG5cXG1lc3NhZ2V7SEVMTE8gVEhFUkV9XG4kMlxceDIkXG5cXGVuZFxuIiwg NDA5NikgPSA0OQo4MjU3MjEgY2xvc2UoMzwvaG9tZS9zYW5qb3kvVHVwdGV4dGVzdC90ZXN0LnRl eD4pID0gMAoKCjgyNTcyMSBhY2Nlc3MoIi4vdGVzdC50ZXgiLCBSX09LKSAgICAgICA9IDAKODI1 NzIxIG5ld2ZzdGF0YXQoQVRfRkRDV0Q8L2hvbWUvc2Fuam95L1R1cHRleHRlc3Q+LCAiLi90ZXN0 LnRleCIsIHtzdF9kZXY9bWFrZWRldigwLCAweDUzKSwgc3RfaW5vPTE0LCBzdF9tb2RlPVNfSUZS RUd8MDAwLCBzdF9ubGluaz0wLCBzdF91aWQ9NjU1MzQsIHN0X2dpZD02NTUzNCwgc3RfYmxrc2l6 ZT00MDk2LCBzdF9ibG9ja3M9MCwgc3Rfc2l6ZT0wLCBzdF9hdGltZT0wLCBzdF9hdGltZV9uc2Vj PTAsIHN0X210aW1lPTAsIHN0X210aW1lX25zZWM9MCwgc3RfY3RpbWU9MCwgc3RfY3RpbWVfbnNl Yz0wfSwgMCkgPSAwCjgyNTcyMSBvcGVuYXQoQVRfRkRDV0Q8L2hvbWUvc2Fuam95L1R1cHRleHRl c3Q+LCAidGVzdC50ZXgiLCBPX1JET05MWSkgPSAzPC9ob21lL3NhbmpveS9UdXB0ZXh0ZXN0L3Rl c3QudGV4Pgo4MjU3MjEgZnN0YXQoMzwvaG9tZS9zYW5qb3kvVHVwdGV4dGVzdC90ZXN0LnRleD4s IHtzdF9kZXY9bWFrZWRldigwLCAweDUzKSwgc3RfaW5vPTE0LCBzdF9tb2RlPVNfSUZSRUd8MDAw LCBzdF9ubGluaz0wLCBzdF91aWQ9NjU1MzQsIHN0X2dpZD02NTUzNCwgc3RfYmxrc2l6ZT00MDk2 LCBzdF9ibG9ja3M9MCwgc3Rfc2l6ZT0wLCBzdF9hdGltZT0wLCBzdF9hdGltZV9uc2VjPTAsIHN0 X210aW1lPTAsIHN0X210aW1lX25zZWM9MCwgc3RfY3RpbWU9MCwgc3RfY3RpbWVfbnNlYz0wfSkg PSAwCjgyNTcyMSByZWFkKDM8L2hvbWUvc2Fuam95L1R1cHRleHRlc3QvdGVzdC50ZXg+LCAiIiwg NDA5NikgPSAwCjgyNTcyMSBjbG9zZSgzPC9ob21lL3NhbmpveS9UdXB0ZXh0ZXN0L3Rlc3QudGV4 PikgPSAwCg==
So, I think that the problem is related to fuse mounting. This problem
happens with the tup 0.8-1+b1 package but not with the tup 0.8-1
package. The only difference between them (my arch is amd64) is, from
the changelog:

* Rebuild against libfuse3-4

Thus, it may be related to linking (and using?) the newer libfuse3
library (3.17.2 instead of 3.14.0):

$ dpkg -l libfuse3\*
ii libfuse3-3:amd64 3.14.0-4 amd64 Filesystem in Userspace (library) (3.x version)
ii libfuse3-4:amd64 3.17.2-3 amd64 Filesystem in Userspace (library) (3.x version)

The minimal example for running tup as above has two files: Tupfile and test.tex (and needs pdftex to be installed). Here they are:


OiB0ZXN0LnRleCB8PiBwZGZ0ZXggJWYgfD4gJUIucGRmICVCLmxvZwo=
\message{HELLO THERE}
$2\times2$
$2\times2$
$2\times2$
$2\times2$
$2\times2$
$2\times2$
$2\times2$
$2\times2$
\end

-- System Information:
Debian Release: sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.32-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tup depends on:
ii fuse3 3.17.2-3
ii libc6 2.41-10
ii libfuse3-4 3.17.2-3
ii libpcre2-8-0 10.45-1
ii libsqlite3-0 3.46.1-6
ii procps 2:4.0.4-8

tup recommends no packages.

tup suggests no packages.

-- no debconf information

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)