[Pkg-electronics-devel] gnucap package.

[Felix Salfelder]

Hi Carsten

On Thu, Mar 08, 2018 at 06:16:47PM +0100, Carsten Schoenert wrote:
> > 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.
> 
> [..]
>
> 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 agree, thanks for the background.

> > 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.

good.

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

noted. thanks for spelling this out

> > 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.

i'm not entirely happy about the -dev package. but it's the closest i
could get so far. might require fine tuning, but depends.

> 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.

there are 4. 3 are closed. in the other, #802307, somebody misread the
manual. (how) can I close it?

There's also
  * Fix FTCBFS: Add gnucap:native to Build-Depends. (Closes: #-1)

is that correct for "nobody cared about writing a bug report"?

> 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.

i have edited the changelog once more. might be worth a try.

thanks again
felix