Your message dated Tue, 10 Nov 2015 16:10:16 +0100
with message-id <[email protected]>
and subject line Re: Bug#804625: allow to keep source.changes on binary builds
has caused the Debian Bug report #804625,
regarding allow to keep source.changes on binary builds
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
804625: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804625
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: git-buildpackage
Version: 0.6.22
Severity: wishlist
Hi,
feel free to close this bug if I'm doing something conceptually wrong here...
I stumbled across the following blog post a few days ago where a pbuilder
hook is created to generate a _source.changes file for source-only uploads
http://www.corsac.net/?rub=blog&post=1579
This does work with plain pdebuild, but not with git-buildpackage
--git-pbuilder because the latter always removes the _source.changes file
after an successful binary build. Actually, it does create a source changes
file early in the process (before pbuilder), so the hook isn't even
necessary.
As far as I understood creating the source.changes during a binary build
would be preferred to using the -S flag, because it would ensure that
the binary package can actually build before upload.
If all that is true please add an option to either keep the source.changes
file generated by git-buildpackage or at least keep it if it has been
generated with the build hook described above.
Thanks,
Bernhard
--- End Message ---
--- Begin Message ---
Hi,
>> Of course I don't see a good way to distinguish betweeen the original
>> one and the recreated one at the moment (except for using another name
>> or carrying checksums somewhere). Probably not worth the hassle, feel
>> free to close if you agree.
>
> ...if you pick another file name it won't be removed.
I agree that this is most likely the best way forward. Closing the bug.
Bernhard
--- End Message ---
