gregor herrmann:
> [..]
> 
> So currently I have:
> 
> - reprotest called as 
>   env -u TMPDIR -- reprotest --variations=+all,-build_path,-user_group 
> --verbosity 1 . -- schroot default 2>&1 | [..]
> 

Thanks, this helped me reproduce the bug locally. I was having trouble before, 
because the bug only occurs when fileordering is switched on but user_group is 
not switched on.

The bug is because disorderfs was being run as root inside the schroot, but the 
build was being run as the normal unprivileged user. This was because I was 
dropping privs in the wrong place, I've fixed in commit e367967, see if it 
works for you:

https://anonscm.debian.org/git/reproducible/reprotest.git/commit/?id=e367967

(The bug didn't show up because the user_group variation has some hacks in it, 
to force the fileordering variation to run as the target user.)

> [..]
> 
> What I don't understand: The second build starts with:
> 
> [..]
> INFO:root:starting build with source directory: 
> /tmp/autopkgtest.tgbi5X/build-experiment-1/, artifact pattern: ./../*.deb
> ..
> INFO:root:executing build in /tmp/autopkgtest.tgbi5X/const_build_path/
> tail: Î޷¨´ò¿ª'debian/changelog' ¶ÁȡÊý¾: ȨÏ޲»¹»
> dpkg-buildpackage: error: tail of debian/changelog subprocess returned exit 
> status 1
> INFO:root:build successful, copying artifacts
> /bin/sh: 2: cd: can't cd to /tmp/autopkgtest.tgbi5X/build-experiment-1/
> 
> but there is no /tmp/autopkgtest.tgbi5X/build-experiment-1/ directory
> anywhere:
> 
> [..]

This is explained by the fact that reprotest moves stuff from 
build-experiment-1 to const_build_path, in order to run both builds in the same 
build path. The build failed, so reprotest didn't run the cleanup to move the 
directory back. Then, reprotest thought the build was successful (it says 
"INFO:root:build successful" in your log) so it tried to do more stuff with 
/tmp/autopkgtest.tgbi5X/build-experiment-1/, but it's not there because the 
build actually failed.

The fact that reprotest thought the build was successful, was a bug in 0.7.3 
with --no-clean-on-error that I just noticed, which I accidentally fixed in a 
refactoring just before I fixed this bug. The previous code was doing

if ( run_build ); then ( cleanup ); fi

but of course this doesn't preserve the non-zero exit code from run_build, duh. 
The fix for this is in git / will be in 0.7.4 as well.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Reply via email to