[3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Bas Wijnen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Tue, Mar 28, 2017 at 07:51:59PM +0200, Gregor Riepl wrote:
> This is a 'P' level warning, so I don't think an explicit override is
> required: https://lintian.debian.org/tags/no-upstream-changelog.html

Ah right.  In that case it's fine to just ignore the message.

> > Did you change any of the filenames?  If not, did you check with piuparts that
> > everything is cleaned up after install and remove?
> 
> No, that isn't necessary when naming the binary package libarcus3.
> 
> Lintian will pick up that the SONAME is libArcus.so.3, verify that the symlink
> is correct and that the package name contains the API version.

So now you have libArcus.so -> libArcus.so.3 -> libArcus.so.1.0.0?  That's
weird, but on my system I see libwt does the same thing, so I suppose it's not
a problem...

> Not ideal, because it will cause maintenance overhead when upstream increments
> the SOVERSION, but it won't require any source changes.

You have maintenance when that happens anyway.

> >>> I'm not sure about "no-symbols-control-file"; it doesn't appear on my local
> >>> system when I build it, and the build output suggests that the symbols file is
> >>> generated, but I don't see it.  Does anyone else on this list know about it?
> >>> Otherwise, ask on the mentors list, or #debian-mentors on irc.
> > 
> >> This is classified as 'I', and seems overly picky to me.
> >> But I don't fully understand the implications either, so it may need to be
> >> discussed with an expert.
> > 
> > Yes, it's fine to ignore it for now I suppose.  I would be interested to know
> > what's happening though.
> 
> I suppose this file will help with dependency autocalculation on shared libs.

Yes, symbols files track version information about individual symbols in a
library, which allows programs to depend on the lowest version that supports
all the features, thus avoiding dependencies on new libraries, which makes it
more likely that packages from sid work on stable unchanged (we don't support
that, but that doesn't mean we have to break it), and it avoids problems with
large transitions.

> Since we're closely tying a certain libArcus to a certain Cura version, I
> believe it only has limited usefulness in our case.

Yes, I agree.  My interest wasn't based on it being useful, but in the fact
that I don't understand the error, or the messages I see when building the
package (it says it's building the symbols file, but it doesn't seem to exist
after the build).

> I created such a manpage. It's unlikely that it will have to be changed often
> (except for the version, of course), so it won't be hard to maintain anyway.

Yes, that's the plan.  I would personally leave out the version as well,
because I'm very likely to forget to update it when a new version is released.

> I already started working on a suitable package and will take the RFP shortly.

Great!

> Can you advise on how to generate and maintain the source tarball?
> Upstream (http://www.opensans.org) only distributes the file open-sans.zip,
> without any versioning. The fonts do contain a version in their metadata,
> however: It's "1.10"

Assuming they change that version whenever they do a new release, you can use
it.  For generating the tarball, just unzip it, then tar it and name it
properly (opensans_0.10.orig.tar.gz).

> I haven't found a way to convince uscan to accept the file, so writing a
> working watch file and autogenerating fonts-open-sans-1.10_orig.tar.gz is a
> bit out of my league. Can you help?

I don't think uscan can handle that.  It can transform filenames, but it will
not download the file, so it cannot examine the metadata inside it.  So that
means you can't use a watch file in this case.

Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJY2qoUAAoJEJzRfVgHwHE6hFcP/2El/VQRkBPrtfy3xGxGQ3dU
3X9ITUqaJwJQRyNxV+ovMF3siOS0lmqY8A3ILmkm62g5XselFf9o/kuhFWFRQ9vh
a8dPs3QyphSvn5qZKQUJ3dVPiJWZpOd0BgCt1PmOUyNp+/EKu5xFywZvvAdbS32E
mTGbFGLSz9QwhYXM7o4mLpCOnmvjRhS00fazn7eTZzBMLveHL5su225AVkREr2IT
eXOHYo3pTf6P3Ce8O48D8OL4GCsC00WjlSKtWP0NETnWTyf/ymd96Rl9gftWIolQ
ERniVYPRHjrdEPCtQl8ZLRE6eRyLAs2ag2L+ZBCSZI/hobLbWvArJ/xbCN7BbSZs
KHIl/QO/jwm1ZW0JhvSgHYDCKtLeZcnTctCPn8wn/72j/Mvy9h01oKFKs4SK9aBk
2QzUMW/JnswKwyybTBqeDCbHydlRW/pL5oeqinCAMPFQD7GJkr1kdmDLpGvjh6Te
2UOzy5l6J2hQYkwSSanVmKaLx2B5vtR6N6xhoeToojqyax9MayXSwb7bZHVSXeMD
6UqrsSMYjgO0DVCDaTj6nfVskzN5i34mkjqIjl3ZuOwk7aJoaMm1w/3+Z84GA45O
e374N6FKhTrHyyxCXltLjA8OK2eYYM/fzpqp19pf3TEjIceI/bXjkivOBG3Hfoz0
6b+ZRwbOjGM4Yn2dTG3G
=O3te
-----END PGP SIGNATURE-----