[Pkg-electronics-devel] gnucap package.

[Carsten Schoenert]

Hello Felix,

Am 07.03.18 um 17:34 schrieb Felix Salfelder:
...
>> http://dep.debian.net/deps/dep14/
> 
> some of this seems to be about (much) more complex cases. i can dig into
> this more. please point out things i am getting completely wrong.

you are of course free to do what ever you like and prefer, DEP14 is
'just' a proposal but it makes really sense in my eyes to think about a
good branch layout. As long as you just upload to unstable and maybe
sometimes to experimental you will not get any tricky situations so far.
But once you need to prepare a security upload, and this maybe for
different releases, or you want to provide various backport versions you
will shortly see why it's really a good idea to have own branches for
this. Some Maintainers also do the packaging work for Ubuntu and Debian
in the same tree. And that's what DEP14 is about, it's suggesting a
common branch layout for projects.

I guess gnucap isn't a classical candidate for the scenarios I pointed
out. I follow the DEP14 proposal to keep my workflows in the package I
maintain in sync. I just wanted to point to this DEP.

>> I personally would also run wrap-and-sort on the Debian folder to
>> improve the readability of the sequencer files.
> 
> nice! never heard of that. (i do not have a strong opinion on flags,
> hence used the default)

The flags are the salt for w-a-s and '-ast' has the highest gain on
sorting files in the debian folder.

>> Another things I'd like to suggest, please be a bit more verbose on your
>> commit messages. Especially third persons (like me) are depending on a
>> good declarative commit message to get your intention for the commits in
>> a really short amount of time.
> 
> i have rebased everything in the course of moving to salsa. lots of
> changes were related to intermediate releases that have never bee> uploaded. this is mostly gone now.

Thanks, looks much better now.

>> Also ec0b37f3, "bump standards version"
>>
>> Why you have done this, why no further changes are needed. The policy
>> version hasn't just increased about a micro version.
> 
> generally, there are no changes required relative to the previous
> uploads, as the package now looks entirely different. if it fails to
> meet some standard, then not because i have bumped the version.

Yes, my experience over the past years is just simple that I myself need
at some point to look at my own commits and I'm happy for any
information I found years later why I have it done and what
circumstances are responsible for the commits. And this is also true for
the bumps of the Standards-Version. It's just 2-3min I need to write the
commit messages, and even less if I just need to write "No further
changes needed."

> anyway i have put a commit message with hints to the paragraphs in the
> standard that seemed relevant within the bump range.

Thanks.

...
>> The creation of the symbols file isn't that difficult, but as the source
>> is the C++ based symbols will change with every modification of the C++
>> compiler so the symbols files hasn't a big win like for classical C
>> files. But yes, can be added later.
> 
> I assume that this does not require a lintian override.

No, please not. The lintian tag is there for some reason and only in
rare cases a override is reasonable.
If you would override this information probably you and nobody else will
ever see that a symbol file should be created here.
I've done a quick look into a possible symbols files. The maintenance of
such a file would be a big mess over the time due libgnucap0 has only
unversioned symbols (all symbols are *@Base). So strongly suggest to not
add a symbols file now. If libgnucap0 will get symbols with a version
this looks different, but I guess this will never happen. ;)

If you want to add a symbols file you would need to do the following

> $ dpkg-deb -x ../libgnucap0_0.36~20171003-1_amd64.deb /tmp/libgnucap0
> $ dpkg-gensymbols -v0.36~20171003~ -plibgnucap0 -P/tmp/libgnucap0 -Odebian/libgnucap0.symbols
Please note that some symbols may be 32/64bit specific, you would need
to build the package at least for i386 with the generated file to see if
you need to modify the file further. Would look like this for one
different symbol then.

>  (arch-bits=64)_ZN4priv8conv_outIlEEvP7_objectPvjPT_ at Base 0.36~20171003~
>  (arch-bits=32)_ZN4priv8conv_outIxEEvP7_objectPvjPT_ at Base 0.36~20171003~
See also the Wiki page about this whole topic.

https://wiki.debian.org/UsingSymbolsFiles

...
> done, unless i'm missing something.

Great. The packaging looks good so far, I can't say much about the -dev
packages you have created and how useful they are. I have no deeper
knowledge about gnucap, maybe some other member here on the list could
say something helpful criticism on that.

But could you please have a look at the existing bug reports for gnucap
and add valid Closes tags to the changelog so the report are closed with
the version number of the upload once the package will hit the archive?
I guess quite all or most of the reports can be closed by a next upload.

Once this is done we can think about a upload. Would you also keep up
some extra information on some entries in the changelog file? Keep in
mind users (and the FTP masters as well!) will typically only look here
to see what has changed in this version. The package will need to go
through NEW anyway due the new binary packages you've added.

-- 
Regards
Carsten Schoenert