Hi, Quoting Martin Dosch (2024-11-27 19:23:57) > I am also suffering from this bug.
this is not a bug. What you are reporting is the result of a bug being fixed. > Downgrading sbuild to 0.87.0 from testing fixes it. It doesn't fix it. It hides a problem. What downgrading hides is, that running the clean target is done without checking whether the packages necessary to run the clean target are installed. That's a bug. > ``` > gbp buildpackage -v --source-on > ly > > gbp:info: Performing the build > dpkg-buildpackage: info: source package golang-github-protonmail-gopenpgp-v3 > dpkg-buildpackage: info: source version 3.1.0-2 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Martin Dosch <[email protected]> > dpkg-checkbuilddeps: error: Unmet build dependencies: > golang-github-pkg-errors-dev golang-github-protonmail-go-crypto-dev (>= > 1.1.0~) golang-github-protonmail-go-mime-dev > golang-github-stretchr-testify-dev > dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting > dpkg-buildpackage: warning: (Use -d flag to override.) > E: Failed to clean source directory > /home/martin/build/deb/golang-packaging/golang-github-protonmail-gopenpgp-v3 > (/home/martin/build/deb/golang-packaging/golang-github-protonmail-gopenpgp-v3_3.1.0-2.dsc) > gbp:error: 'sbuild -v --source-only' failed: it exited with 1 > ``` > > So to workaround this bug I have to either disable clean up or not use > build-depends, do I understand this correct? You are using gbp buildpackage around sbuild. Unless you configured it otherwise, gbp buildpackage will not let you proceed if your git clone is not clean. So before running gbp buildpackage you have to clean up the unpacked source, for example by running "git clean -fdx". It is thus indeed quite pointless to give the task of cleaning the unpacked source to sbuild. If you run sbuild via gbp, you should probably configure gbp such that it always passes --no-clean to sbuild. > Maybe add `$clean_source=0;` by default to not break build systems with > the update? If the default for $clean_source is changed, then that will break things for those people who relied on sbuild performing the clean step. Changing the default is an option, but it is one that has to be done very carefully. Whether or not the default for cleaning the source should be changed can be discussed here: https://salsa.debian.org/debian/sbuild/-/merge_requests/71 I have yet to hear an argument that convinces me. Not cleaning the source by default is *not* the fix to your problem though. The situation you had before was the problem. You just didn't see it because you probably had debhelper and some other packages installed. For example, you are currently working on src:golang-github-protonmail-gopenpgp-v3. If I just run "debian/rules clean" on my system I get this: dh clean --builddirectory=_build --buildsystem=golang dh: error: unable to load addon golang: Can't locate Debian/Debhelper/Sequence/golang.pm in @INC (you may need to install the Debian::Debhelper::Sequence::golang module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/aarch64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at (eval 13) line 1. BEGIN failed--compilation aborted at (eval 13) line 1. This happened because I did not have the dependencies required to run the clean target of this package installed. Sbuild not complaining about this before this error happens is a bug. So now, to fix the bug, sbuild checks that the packages required to run the clean target are installed before running it. Thanks! cheers, josch
signature.asc
Description: signature
