Bug#830207: RFP: audio-recorder -- record what is played in the loudspeakers
On 15 August 2016 at 02:23, David Rabel <David.Rabel@noresoft.com> wrote:
> Hi,
>
> on Friday the upstream author released a new version and so I spent a
> good part of the weekend packaging. ;-)
>
> I uploaded the package at mentors.debian.net :
> https://mentors.debian.net/package/audio-recorder
>
> But I've got a lot of questions and I hope you can help me:
>
> 1) lintian reports an error: source-contains-unsafe-symlink, referring
> to the po/Makefile.in.in which is a symlink to
> /usr/share/intltool/Makefile.in.in . It seems to me that this symlink is
> intended. Even more since there is a --copy option for intltoolize to
> copy such files instead of creating a symlink. See [1]. I am not sure
> what is best practice here. I found some patches for other programs
> where they just copy the Makefile.in.in file to satisfy lintian. Should
> I also do this?
>
The Makefile.in.in file seems like a file that should not be included
in a binary package.
That file is usually used (wit just one '.in' in the name) to build
the [upstream] software package. See the newmaint guide [1].
The final debian binary package should only include the audio-recorder
tool, and not any other
stuff used to build the package itself.
> 2) dpkg-shlibdeps gives me several warnings of the form "package could
> avoid a useless dependency if binary was not linked against *library*
> (it uses none of the *library*'s symbols)". For libgthread,
> libpangocairo, libdbusmenu-glib, libatk, libcairo-gobject, libpango,
> libdbus as *library*. I guess these libraries are automatically linked
> because the makefile uses some variables like GLIB_LIBS, GTHREAD_LIBS,
> etc which probably include libraries that or not necessarily needed.
> Aren't those libraries that are always available in a GNOME environment?
> Do I have to do something about this warnings?
>
You could investigate why this is happening.
Please, talk to GNOME people, since I'm not familiar with their environment.
The dpkg-shlibdeps is a warning to take into account, but is not a
blocker for the package to join debian.
> 3) I deleted the upstream debian directory at the beginning. That means
> it is not even included in the orig.tar.gz . I wanted to avoid any
> conflicts. Is that OK?
> I want to ask the upstream maintainer if he could provide a tar.gz
> without the his debian directory in the future. He seems to be a nice
> person, so probably he will do this.
>
You repacked the upstream tarball? That's fine.
What is really great is that upstream doesn't ship the d/ dir. Please,
talk to them.
> 4) I changed the version from 1.8+0 to 1.8-0 after I had problems with
> dh_make. I think the hyphen is more or less reserved. In upstream
> tarball it separates name and version and in the Debian version it it is
> for the revision. I am just not sure if replacing it by a plus sign is
> best practice. What do you think? And should I ask the upstream
> maintainer to change his versioning scheme?
> I also replaced the version in configure.ac, so it is also replaced in
> the binary.
>
Changing the version is probably not a good practice. I would suggest
to talk with
upstream for this change.
Yes, suggesting a versioning scheme is fine.
> 5) I did not know how to make the watch file work. Because at the
> moment, the launchpad site [2] is not updated anymore, so I had to pick
> the tar.gz manually from the ppa. Maybe the easiest is to ask the
> maintainer to update that site at least when he releases a new version.
Where are the upstream source? Is there any SCM (git).
If launchpad is not updated anymore, where is the code living now?
Perhaps you could suggest upstream to migrate to github or something similar.
>
> 6) I wanted to change http to https wherever possible, but I was not
> sure where I have to. Now I only did it in the po file strings. I did
> not change it in source files or automatically generated files.
>
Beware that it doesn't make sense to migrate to https if the final URL
will not work.
i.e: check if the HTTPS url works before changing from http to https.
> 7) When running check-all-the-things there where a lot of warnings more.
> But I think what is left over is not important for this case. Still I
> wanted to mention it.
>
Fine.
Given the amount of changes required to upstream audio-recorder
(tarball, versioning, URL/git, etc) I would suggest to package the
*next* upstream release, which is meant to include all of these
changes.
[1] https://www.debian.org/doc/manuals/maint-guide/first.en.html#portable
--
Arturo Borrero González
Reply to: