Hi,

This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).

This is probably a clear violation of Debian Policy section 4.9 (clean target),
but this is filed as severity:minor for now, because a discussion on
debian-devel showed that we might want to revisit the requirement of a working
'clean' target.

More information about this class of issues, included common problems and
solutions, is available at
https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild

Relevant part of the build log:
The full build log is available from:
http://qa-logs.debian.net/2023/08/13/libgdiplus_6.1+dfsg-1_unstable.log

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Hi,

I reproduced this on current libgdiplus 6.1+dfsg-1.2 with the real sequence
dpkg-buildpackage -b followed by dpkg-buildpackage -S, and prepared a tested
fix in debian/rules. Attached is the scoped debian/rules fix I prepared
against libgdiplus 6.1+dfsg-1.2.

For this bug specifically, the fix changes the clean logic to use
dh_auto_clean, guarded on config.status, instead of the older manual clean
sequence that left the tree in a state where a subsequent source build failed.
With that change in place, dpkg-buildpackage -S succeeds after a successful
binary build on the same tree.

Validation on the patched tree: dpkg-buildpackage -b succeeds;
dpkg-buildpackage -S succeeds afterwards on the same tree; a clean
unstable-amd64-sbuild succeeds; piuparts passes when run for amd64.

The separate vendored Googletest compatibility failure is tracked in #1135544
and is not part of this patch.

Since libgdiplus is currently orphaned (#1079870), I am sending this as an
adoption/QA-style handoff rather than assuming an active maintainer workflow.

Regards,
James