Hi, Quoting Sebastian Ramacher (2024-12-28 19:27:45) > > That being said, unless we decide that sbuild should *remove* any existing > > unpacked source package, your setup sounds incompatible with having a > > static build path as it is used on the buildds. How would you prefer to see > > this resolved? Should sbuild bail out early with a better error message? > My sbuild is not configured to run with sbuild_mode = "buildd" though.
normal sbuild tries to do something similar to what happens on the buildds. In my experience, many users of sbuild value that when they run sbuild on their packages locally and it succeeds, then it will also succeeds on the buildds. > To be honest, I'd like the build path change reverted for user mode. I'm not married to the build path. We can revert it. But I don't think it's up to me. This change was motivated by the reproducible builds team. Their motivation is to have artifacts built locally be reproducible when comparing them to those created by the buildds. The buildds switched to a reproducible build path, so the sbuild default switched as well. If you want this changed, I'd say that you don't have to convince me but the reproducible builds team. > And if that does not happen, I would at least expect an error message in that > case as it is consistent with the dpkg-soure -x behaviour. The message could > indicate that set buildpath to "" to have randomized build paths back. Yes, that is a good idea, thanks! I will prepare a commit that does exactly that. While we are on the topic, did you find the NEWS entry displayed when you upgraded your sbuild version comprehensible or would you add more corner cases like this one to it? Thanks! cheers, josch
signature.asc
Description: signature
