* Package name    : audio-recorder
  Version         : 1.6
  Upstream Author : Osmo Antero <osmoma@gmail.com>
* URL             : https://launchpad.net/audio-recorder
* License         : GPLv3
  Programming Lang: C
  Description     : record what is played in the loudspeakers

This program allows you to record your favourite music or audio to a file.
It can record audio from your system soundcard, microphones, browsers and
webcams. Put simply; if it plays out of your loudspeakers you can record it.
This program has a timer that can start, stop or pause recording on certain
conditions such as audio level, file size and clock time. This recorder can
automatically record your Skype calls. It supports several audio (output)
formats such as OGG audio, Flac, MP3 and WAV.


There is already an ubuntu package, so migrating to Debian should be easly.
I don't have time right now to package this myself, perhaps in a near future.
I am however open to collab, review, sponsor or whatever.

Hi Arturo,

I'm interested in maintaining this package. If I don't confuse this, I
used this program when I was using Linux Mint and now that I am using
Debian, I would like to see it included.

I have not yet contributed to Debian, so I have no experience in
maintaining packages. I already read the Debian New Maintainers' Guide
and I hope I will learn the details "by doing".

You said, you are open to collab, review, sponsor or whatever. So if you
like, I would look at it and see how far I come and ask whenever I have
questions.
You say migrating to Debian should be easy, so maybe it is just the
right package for me to start. :-)

Regards,
 David

Hi again,

the last release cannot be built on recent Debian versions because of
naming conflicts in the source code with libgtk-3-dev.
This is fixed in the current trunk of audio-recorder and I just wrote an
Email to the upstream author and asked him to release a new version of
audio-recorder, so I can package it. :-)

I also changed the bug title to ITP.

Regards,
  David

Ok David,

Go ahead with the packaging :-)

best regards.

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?

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?

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.

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.

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.

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.

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.


Yours
  David


[1] http://manpages.ubuntu.com/manpages/trusty/man8/intltoolize.8.html
[2] https://launchpad.net/audio-recorder

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.

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.

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.

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.

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.

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.

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

Hi Arturo,

thank you for your email. I wrote an email to the upstream developer,
asking him to change a few things. :-)

It is not included in the binary package, only in the source package.
Still this leads to a lintian error. I also informed upstream about
this, maybe he will just fix it. If not, it is probably OK to copy the
Makefile.in.in of my intltool installation to the po folder.
environment.

I will have a closer look at it.
updated anymore.
So, the source code is here: [1].
The projects' site is not updated: [2]
And the current tarball I had to pick from the ppa: [3]

I asked the upstream maintainer to update the projects' site again, at
least to put the tarball of the current version there.


Yours
  David

[1] https://code.launchpad.net/~audio-recorder/audio-recorder/trunk
[2] https://launchpad.net/audio-recorder
[3] https://launchpad.net/~audio-recorder/+archive/ubuntu/ppa

Hi Arturo,

it took a long time, but finally I got most of the problems with
audio-recorder solved. I'm in contact and also have write access to the
source code now. So if there are further problems, it should no be too
hard to fix them.

The only thing I have no solution for at the moment is the proablem with
the watch file. I think this it not too important, but please let me
know what you think about it.

Here is the link to the new package:

https://mentors.debian.net/package/audio-recorder

Yours
  David

Thanks for your work!!

I reviewed it. Things I see you should address:

* Please, put the debian packaging in a git repo and put the VCS-*
directives in the debian/control file.

* The package does not build from source. This is the log of my try:
http://paste.geeknode.org/?f1401b0a45259399#2QVZg7aa3EZYkkPb4BGkBxpzk0HK7tWa7mihFubRx0Q=

You should try yourself using pbuilder, or other tools that does the
build in a clean environment.

* If I take long to reply you should also contact the debian mentors
mailing lists.
Ask for advice and review there, probably there are people who have
more spare time than me.
You could CC me in the emails you send to debian-mentors.

(please, keep the ITP bug in CC)

Ok, the package looks very good now.

I uploaded it to unstable (it should go to the NEW queue).

Things to address:

* d/patches/0001-Delete-extra-COPYING-file-in-data.patch deletes
upstream COPYRIGHT file.
I guess this is to avoid installing it. Perhaps the makefile part
should be enough for not installing it?
* lack of d/watch file. I remember the upstream code was very hidden,
but still we should have a d/watch file.
* dpkg-shlibdeps reports a lot of possible unneeded dependencies.
Please review them to strip down the list of dependencies.

Hi Arturo,

Yeah! :) Thank you very much! I'm really happy about that.

I changed it now. I already committed it to the git repository. I think
it will be fine if it is in the next version.

Yes that's right. So I added a watch file. I only have to convince the
upstream author to release the current version on the projects page
instead of only doing it in the ppa.
He did this for version 1.9.3 , but forgot it for version 1.9.4 . I will
just him again. Or maybe he will tell me how to do it myself, since I
have write-access at the launchpad project now.

Ok, I will do this. But it will probably take some time, because I first
have to understand this whole dpkg-shlipdeps substitution a little more. ;)

Thank you again!

Yours
  David

Hi Arturo,

there was a new upstream version of audio-recorder today. So i packaged
the new version with my latest changes. Maybe you could upload it as
soon as version 1.9.4 is out of the NEW queue.

https://mentors.debian.net/package/audio-recorder

Btw: The mentors page says that the watch file is not working, but on my
system it actually is working.

Yours
  David

Hello,

great to see audiorecorder close to being included in Debian.  I had
offered help for packaging the software at
https://bugs.launchpad.net/bugs/1391951 but I never got around to doing
an ITP.  Let me know if you are interested in a co-maintainer.  I am DM
and would be able to upload packages without requiring a DD sponsor.

Regards

Rolf

Hi Rolf,

A few words regarding the workflow:
Because Osmo publishes audio-recorder as an Ubuntu package, it already
contains a debian/ directory. So I download the latest tarball, untar
it, delete the debian/ directory and tar it again.

I work with git and gbp, so the all the packaging work is done in a git
repository. That is https://github.com/NoreSoft/audio-recorder at the
moment. I am not a big fan of github, but chose it for simplicity. If
you prefer something more free, let me know. If not, I could just give
you write access to the repo.

The last upload of the package got rejected with the following notice:

So I am not quite sure yet how to handle this. My first idea is to ask
Osmo if he may have this in more detail.

Regards
  David

Hi,

ping me when you need sponsor for this package.
I can later give Rolf DM upload rights if required.

best regards.

Bom dia,

It seems, that launchpad auto translation already did this for the
German translation. So I just fixed some smaller mistakes I saw on the way.


The audio-recorder package was rejected by Debien FTP masters, because
of the "(C) linux community".
Can you say, who in particular contributed to audio-recorder?

Viele Grüße,
  David

Beware that unlike German Urheberrecht Copyright is not automatically
assigned.  So, unless contributions were made with a specific copyright
request they are public domain.  You can command copyright for your own
work.  I assume what you meant to do is acknowledge the contributions.
But again, that does not mean the contributors have copyright and things
become much simpler.  Only you as upstream author have copyright and you
are of course free to mention contributors (who again do not have
copyright unless they requested this).

IANAL, but that that's my understanding.

Oh, Du bist Deutsch?

Re-hi again,

Look guys, I am just a portuguese (hobby) FARMER who drinks almost 1 bottle
vine every evening.
Ok?
So let us keep things simple !
;-)

Boa noite,
  Osmo e Bica (A portuguese dog. She can Python quite well)



On Tue, Feb 14, 2017 at 8:29 PM, Rolf Leggewie < debian-bugs@rolf.leggewie.biz> wrote:

David,

thank you for your mail.

Awesome.  Just add me to the uploaded fields as "Rolf Leggewie
<foss@rolf.leggewie.biz>" please.

That's actually much more complicated than it needs to be.  While it
does make sense to ask upstream to stop shipping a debian directory,
DebSrc3.0 which I believe is by now the default will overwrite any
directory if you want that.  The debian directory is always overridden
(c.f.
https://wiki.debian.org/Projects/DebSrc3.0#Advantages_of_new_formats).
You only need to repack things if upstream tarball contains
undistributable content according to DFSG (not licensed for
redistribution, etc.).

That's what I use for my other packages, too, so I'm very familiar with it.

You could host at alioth but personally I like github.  My account on
github is leggewie.

Upstream uses launchpad.net which recently got git support.  We might
look into moving the debian packaging there.  Do you know if upstream is
proficient in git?

Anything passing through NEW will get the fine comb when it comes to
copyright.  You need to look at every single file before uploading.
That's normal and you should prepare the upload accordingly.

Regards

Rolf

Hi there,

I uploaded a new audio-recorder package to mentors:
https://mentors.debian.net/package/audio-recorder

Mainly it is an update of the debian/copyright file. But while I edited
it, I found a lot of auto-generated files in the source tarball. So I
deleted them via dquilt patch. I hope this is the right way to handle
such files.

Could you please have a look at it, Rolf, and give me some feedback or
upload the package, if it seems fine to you?

Yours
  David

Awesome!  Thanks.

I see you pushed changes to github so I will focus my review on what's
up there, assuming it is identical to what's on mentors.debian.net  I've
not looked at mentors.

60fd5fd4c
It's a trivial fix, but if upstream has that spelling error I think it
would be better to keep it.  Where do you draw the line?  Who knows,
there might be some kind of intended meaning that you and I missed?  In
that part of our work, we are just documenting, not correcting IMO.

08dc66295a
I'm not sure if changing "The entire Linux community" to "Team audio
recorder" is sufficient.  I'm not sure such an entity exists and it's
basically equally opaque.  If it's not specific enough to understand who
to contact in case you'd like to ask for a relicensing of the code then
it's not specific enough for Debian.  Let's say you'd like to develop a
closed-source variety of audio-recorder, who would you need to ask for
permission?  Besides, as I already mentioned previously, my feeling is
that nobody but Osmo Antero has copyright.  There are two conditions
that need to be met for this NOT to be true; 1) significant
contributions from third parties and 2) those parties requested for
copyright when making those contributions.  2) is not documented in the
files and it should be IF there was a third-party copyright.

I understand that Osmo enjoys drinking his vine and keep things simple.
But he is making things unnecessarily complicated here by adding an
opaque group of people to the copyright holders.  I believe that what he
wants to do is acknowledge outside contributions.  That's what the
AUTHORS file is for which is actually present but does not list anybody
besides him.  It's fine for him to make a broad statement there such as
"a multitude of patches were gladly received by a number of people from
the Linux community.  If you'd like to see your name here specifically
contact me at XYZ".  Copyright is about who owns the ultimate rights to
the source.  GPL extends quite a few of those rights to the users (such
as the right to modify, redistribute, etc.)  What Osmo is doing (and I'm
absolutely certain that is unintentional) is to give basically everyone
who can somehow claim to be part of the Linux community to fully OWN the
code and that includes the right to relicense it, for example.  This
would effectively make the source public domain and strip it of the
protections the GPL provides (such as disallowing redistribution as a
closed-source binary program).  I am sure Osmo did not intend to release
as public domain.

This absolutely needs clarification, no way around that.  My suggestion
is to simply drop the erroneous and very dangerous line giving the Linux
community or Team Audiorecorder the copyright.  All users already have
very broad rights protected under the GPL.  Adding that line actually
puts those rights in jeopardy.

dfe98839e3 adds Ian Holmes as copyright holder for src/gst-recorder.c.
If there are any other other copyright holders then that's the way we
should handle copyright attribution for them as well, unless they have
copyright in a broad number of files.

329aa8ce287
"Other" is not a good name for License.  I suggest to follow
https://tracker.debian.org/media/packages/g/granule/copyright-1.4.0-7-4
or https://github.com/giuliopaci/SPro/blob/master/debian/copyright which
I found doing a quick Google search.
https://lists.debian.org/debian-legal/2015/01/msg00054.html says there
is a later version of the file with a better worded license term.  If
that's the case it would be advisable for upstream to exchange the
current for the later version.  If upstream doesn't do this, we can also
do it in Debian only.  If the file is not necessary to build the binary,
we might want to simply drop it via debian/clean.  This question needs
more consideration.

Are they giving any problems during the build?  If no, then I'd say not
to bother with them at all.  If yes and they aren't removed by "dh
clean" already then the file debian/clean is the proper place.  Have a
look at "man dh_clean".  Simply put, you can list file names one per
line in debian/clean to be removed as one of the first steps during the
build. Wildcards are allowed, RegExp might be.  This is better than
using patches because deleting a 1MB file it takes a patch that's
slightly bigger than 1MB.  It's easier to read during code inspection as
well.

Regards

Rolf

Hi Rolf,

a general question: Are you OK with the way I commit every step in git
or would you prefer that I clean up the history a little bit before pushing?

The spelling error was not from upstream, it was mine. ;) And I found a
second one in the same line. I corrected it, now.

The ftp master who rejected the package is fine with this solution. Of
course we can still try to find a better solution.

You might be right on this. For me it was quite clear, that Team
audio-recorder is the launchpad team:
https://launchpad.net/~audio-recorder
Maybe we could add this link instead of the email address to the
copyright file?

I will ask Osmo if he is fine with changing the copyright to him only. I
will keep you and the bug in CC. Just did not want to spam Osmo with the
rest of the email, since most of it is not interesting for him.
that the software could be public domain.

There is other software under permissive licenses in Debian... I think
there are worse things than that.

I adjusted this.

Upstream in this case is me. ;) I have write access to the upstream
repository and I put the po/Makefile.in.in there. The file I added is
from the current Testing version of gettext (0.19.8.1-2). I copied the
license text from there.

We could drop the file, we just would have to run intltoolize before the
build process. I was not quite sure how to do it.

Done.


Yours,
  David

Hi Osmi,

Rolf is probably right, that you are actually the only copyright holder.

What do you think? Would it be OK for you to change the copyright for
the code to your name and mention the whole Linux community and / or
team audio recorder in the AUTHORS file instead?

Yours
  David

for files we delete with debian/clean?

David

Good morning David,

Whatever you think makes most sense.  Your style looks absolutely fine
to me.

No.  The software has whatever license it has.  We are just documenting
what that is.  While doing this due diligence we might actually find out
that the license as stated is not what the author intended (a license
bug if that's how you want to look at it).  Debian is doing this to
guarantee to its users that all software complies with DFSG and thus the
users do not have to do this work.  Again, there really is no way around
this.

I am not sure that debian/copyright is currently complete, yet.
"licensecheck -r" lists quite a few files under LGPL license for example
and "rgrep -i copyright ." gives a lot more names than currently
documented.  There's still work to be done here.

It is already being done in line 18 of the current debian/rules file via
"--with autoreconf".  So, at least for Debian it seems that file (and
possibly others) is not necessary and will be replaced during the build
anyhow.

dh-autoreconf is a superset of autotools-dev and thus I pushed an
untested fix to the rl-wip branch on github.  Feel free to cherry-pick
after verification.

The Depends and Build-Depends lines look surprisingly long.  Why do you
have so many explicit runtime dependencies in Depends?  Isn't this
picked up automatically by ${misc:Depends} and ${shlibs:Depends}?  If
necessary this can be fixed later, but it struck me as odd when I
stumbled upon it now.

Thanks again for your work.

Regards

Rolf

Yes, absolutely.  The only other option is to create a separate
dfsg-free upstream tarball and strip the relevant files from that tarball.

In your case, of course, you might also use your upstream powers and
consider to drop the file upstream depending on whether or not it should
be shipped in upstream releases.

Good morning,
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.

As you said: If the license as stated is not what the author intended,
we can call his attentation to that. But apart from that we are
documenting. And if the license is DFSG-compliant, there is no reason
here, to not include the package into Debian.

You are right. Indeed everything seems to be under LGPLv3. I will ask
Osmo if this was intended. The boilerplates in the source files have to
be correct in either way, since the shorten the LGPL as GPL.
COPYING should also be adjusted.
I can do that, as soon as I recieve an answer from Osmo.

There are source files without copyright notice. Do we have to add that?
For example the header files under src/ .

I think you are wrong here. intltoolize is not run by autoreconf.

Done.

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?

Done.

Probably Osmo wants to keep those files. We can ask him, of course.

Thank you for your help.

Yours
  David

Me again. ;)

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?

David

Hello and good morning!

No, that's just informational.

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.

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

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.

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

Hi there,

No, it doesn't.

Actually because I thought I wouldn't have to include them into
debian/copyright and I wasn't sure about some of the licenses. ;) Of
course that was not the only reason. I thought it would make everything
more clean. So we could just leave them in place?

I cannot remember, why I added --with autoreconf . I did so half a year
ago and I wasn't smart enough to make notes or to use version control
from the beginning.
I _think_ it was because Makefile.in.in was a symlink back then and I
wanted to override it during the build process, because lintian reported
an error about this.

I will try to build the package without --with autoreconf later.


Yours
  David

Hi Rolf,

So, Osmo didn't answer yet.

I thought a little more about that issue.
it is DSFG-free.


But I think, the license _is_ clear (GPL or LGPL may be a little bit
unclear and has to be clarified).
Maybe I am wrong here, but I think the following is true:

Adding an entity to the copyright holders only states that they hold
copyright on their contributions to the file.
For example if I take some file under GPL, modify it and publish it
under the GPL again, it does not give me (nor the original author) the
right to publish the modified work under a license that is not
GPL-compatible.

If "Team audio-recorder" is not a legal entity (what I think it is and
FTP masters seem to agree with me), only their contributions become
public domain. If Osmo chooses to release his version of the file under
GPL and part of it is public domain, the file is finally licensed under GPL.

If Osmo holds the full copyright, because the copyright notice does not
make any sense, it doesn't matter.


So in my opinion the file always has the license Osmo chooses (in this
case probably GPLv3), no matter if "Team audio-recorder" is an
additional copyright holder or not.

By the way, I am not sure if we maybe _have_ to add some copyright
notice for those who actually contributed to audio-recorder.


So I want to propose this:
- I see that the GPL/LGPL issue is fixed.
- We leave the copyright notice to "Team audio-recorder" as it is.
- We could add a note like "as stated in AUTHORS file" and add a list to
that file, who is part of "Team audio-recorder" from launchpad.
- Or add a note "as listed at
https://launchpad.net/~audio-recorder/+members ".
- I remove debian/clean and --with autoreconf .
- While all of this is in progress I have a look at the dependencies.


Then (in my opinion) we should be ready to upload.

Please let me know what you think.

Viele Grüße
  David

Hi again,
mentioned dependencies under "Depends:". I was able to manually remove
them and record audio afterwards.

But: It seems that there are dependencies missing. I installed
audio-recorder in a fresh Testing installation and it did not work. I
got an error like "Unable to init server.". I could fix this by
installing gome-core, but I am not sure, which package is actually needed.

Since audio-recorder is GUI-based it is quite obvious that some kind of
desktop environment should be installed. But how to put this into
debian/control ?

Yours
  David

the packaging is now being developed at
https://github.com/leggewie-DM/audio-recorder

Hi Gents,

I'm, alas, just a user.

If there is a testing build which might work on Buster, I'd be happy to test it and report back.

Thanks!

Mark