Hello and good morning!
On 19.02.2017 19:45, David Rabel wrote:
> dpkg-source emits a warning concerning the fiels that dh-clean deletes,
> e.g.:
>
> dpkg-source: warning: ignoring deletion of file missing, use
> --include-removal to override
>
> Is this a problem?
No, that's just informational.
On 19.02.2017 19:29, David Rabel wrote:
> Good morning,
>
> On 19.02.2017 00:48, Rolf Leggewie wrote:
>>> What you actually say is: IF we leave it as it is, the worst case is
>>> that the software could be public domain.
>> No. The software has whatever license it has.[...]
> I meant leave it as it is "upstream".
> In my opinion the software is DFSG-compliant in any way. If the
> copyright holder is Osmo or Team audio-recorder or the software is
> public domain.
Part of the work as maintainer and especially when doing an ITP is to
verify the code is indeed DFSG-free. Personally, I'd have trouble with
ambiguity in the form of "Well, I can't really be certain if the
software is licensed as GPL, LGPL or public domain but since all those
are DFSG-free it should be OK". One should clarify what the license is
and release the ITP only afterwards.
> There are source files without copyright notice. Do we have to add
> that? For example the header files under src/ .
Publishing something without claiming copyright automatically makes it
public domain. So, unless Person A publishes file X with a copyright
notice and person B republishes it, stripping the copyright notice,
those files do not usually have copyright. It's OK to assume that files
for which we cannot find a copyright claim to be copyright-free (until
we are made aware of the contrary, that is).
> I think you are wrong here. intltoolize is not run by autoreconf.
That's what I read during my research about dh-autoreconf (not
autoreconf). It's entirely possible that I am mistaken. As I said, my
changes were untested. Does the package still compile?
By the way, why do you remove the autogenerated files in the first place
when upstream apparently is keen to ship them and it creates a "problem"
for you in having to recreate them? This is usually only necessary if
those autogenerated files are old and do not support newer platforms.
That's when you need to autoreconf. Otherwise, it's unnecessary but it
does have the benefit of future-proofing the package somewhat.
>> The Depends and Build-Depends lines look surprisingly long.[...]
> I copied both Build-Depends and Depends from the upstream control file.
> I'm not too familiar with ${misc:Depends} and ${shlibs:Depends} . Maybe
> you would like to fix this?
Not sure if this is even wrong. It just struck me as odd.
I have not compiled your package yet. You could strip the additional
packages from Depends, build the package and inspect the resulting deb
file with "dpkg --info $path-to-deb-file" and if the dropped
dependencies are still listed then listing them explicitly in
debian/control wasn't necessary. If they are no longer there, I'd
install the package, run the binary and unless I run into problems I'd
assume the dependencies weren't actually really necessary.
You can read more about ${misc:Depends} and ${shlibs:Depends} in "man 7
debhelper" under the heading "Automatic generation of miscellaneous
dependencies."
Regards
Rolf
