[Pkg-electronics-devel] Update to package gerbv

[Carsten Schoenert]

Hi Gudjon,

Am 12.01.19 um 21:22 schrieb Gudjon I. Gudjonsson:
...

>> The package is now also still at debhelper 10, there is no need to stay
>> on this old debhelper version.
> Changed to 12

You have forgotten to also increasing the compat level. Fixed by me with
adding an additional commit. Cherry-picking on your side would have made
your life easier. :)

>> The maintainer contact still points to a non existing address.
> Removed

Not pushed?
I adjusted this now to get this completed.

...
>> The current last commit is including a lot of various changes that do
>> not directly depend. This makes it really hard to see what was changed
>> and why.
>> It also has removed files that are present in the orig tarball. Was this
>> intended?
> The files are removed when doing 
> debian/rules clean
> All the files removed are autogenerated during build.

Yes, but this is not the problem.
You modify the original source directly and not by patching the source
done by a patch queue or prior before importing the source. And this is
dpkg-source correctly detecting and prints out a warning.

> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building gerbv using existing ./gerbv_2.6.2.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: warning: ignoring deletion of file missing, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file INSTALL, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file test-driver, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file ltmain.sh, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file depcomp, use --include-removal to override
> dpkg-source: warning: ignoring deletion of file Makefile.in, use --include-removal to override
> ....

It is clear to me what you want to archive but this is not the right
way. And it's useless as you already noticed the clean target is doing
the same or can do the same.
And, by importing the next upstream release these file will probably
get appearing again. :/

So you have two options in general, you clean out these file by doing a
rebuild of the tarball before importing the new source or you do the
removing this while building the package. If ever possible I avoid a
rebuild of a tarball and do this only if required to fulfill the DFSG e.g.
I normally don't care much of these .in files as they are recreated
anyway and get overwritten while building due the nature of the autotools.

The solution could be quite easy here, just revert the commit. But you
also mixed up other things into this one commit!
A good example why it is a really bad idea to do something like this as
happen to you. Commits should be small and atomic so a mistake can be
easily reverted at any time and do not interfere with other unrelated parts.

And to stress more on this, you did this mix up again in "10df9903
Remove Ramakrishnan from the uploaders field (Closing: #859286)"
BTW, the trigger into the BTS is "Closes:" not "Closing:".

Given the summarize for the this commit I wouldn't expect also to see
other unrelated changes in this commit too! Please don't do this. This
commit is including three independent changes.
It takes always a lot of times to follow (or find) such hidden
modifications, and time is something that is a limited resource on my side.

BTW: At least two of these changes in this commit you still could have
simple get cherry-picked from my changes. :)

> Hope you are happy with the changes now.

Well, let's say I'd done this differently. :)

I added the missing change for the Maintainer email address and the
compat level and did a upload now.

And the copyright file should be changed to be machine readable.

-- 
Regards
Carsten Schoenert