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

[Gregor Riepl]

>>> Then there's "no-upstream-changelog", which is tricky: it seems there really
>>> isn't a changelog file provided by upstream for libarcus and uranium.  It's
>>> probably a good idea to ask them about this.
> 
>> What's supposed to be in there?
>> Can it be free-form?
> 
> Yes.  But you can't make it up; upstream needs to write it.  And I wouldn't
> want them to waste their time on reverse engineering their changelog.  So I
> think this is something that may deserve a lintian override.

Ok. I will add the changelog file to Cura.

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

>>> "package-name-doesnt-match-sonames" on libarcus means that package should be
>>> called "libarcus2" (the capital can be ignored, but the 2 is important to make
>>> sure versioning works well).  Don't change the name of the -dev package, just
>>> the library's package itself.
> 
>> Since there is no conclusive response from upstream, I fixed this by naming
>> the package libarcus3. The other packages have been kept as-is.
> 
> 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.

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

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

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

>> Added some marketing blurb from the Cura homepage.
>> As I'm not a Cura author, I can only make something up, but I can't really
>> speak on their behalf. May need a review.
> 
> That's fine, as a packager you are an expert user and that should be good
> enough for writing this.  I'll check them when you upload the new packages.

Thanks!

>> Why does it need a manpage?
> 
> Every program in Debian that the user can run directly must have one.  Programs
> that can be launched from a menu system can still also be lauched from the
> commandline.  I use that all the time: I know the names of the programs I want
> to run, but don't know where to find them in the menu structure.  So I open a
> terminal and type the name.
> 
> If a program has its documentation in some other form (a website, or as part of
> the program), the manpage can just point to that.  Having a manpage is useful
> anyway, because it makes the program show up when searching the man page
> directory (man -k keyword).  In this case, it should probably contain the long
> description of the package, a statement that it doesn't accept any commandline
> arguments, and a pointer to the web site.

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

>>> font-in-non-font-package is also something that needs to be fixed.  There
>>> should be no fonts in any of your packages.  It would be best if cura would
>>> just look for fonts in /usr/share/fonts/; if that's too hard, add symlinks from
>>> where it expects them to the fonts in there.  You also need a dependency on the
>>> package containing the fonts, of course.
> 
>> This one is a bit hard.
>> The only Debian package containing Open Sans that I could find is
>> texlive-fonts-extra, and that one is huge and doesn't even include them in
>> TrueType format.
> 
> Hmm, it looks like this font is indeed not packaged:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701478

Yes, I noticed that RFP too.

>> Would you rather suggest I create a fonts-opensans package from upstream
>> (Google in this case) first?
>> Or would one specific to Cura be ok?
> 
> Creating a new package for it would be the way to go.  The alternative would be
> to use a different font, but that would mean patching Cura, and I agree with
> you that that wouldn't be nice.

I don't think replacing the font is a good idea.
Open Sans is released under APL-2.0, so should be fine in Debian.

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

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"

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?

Thanks,
Gregor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/3dprinter-general/attachments/20170328/3b373370/attachment.sig>