Bug#744823: RFS: gnuais/0.3.0-1 [ITP]
2014-09-02 18:09 GMT-03:00 Ruben Undheim <ruben.undheim@gmail.com>:
>>
>>> 3. I've gone through all Copyright-lines in all the files and I hope I
>>> have included all. However, after I put the licenses separately below,
>>> a few lintian information warnings appeared. I'm not sure what is best
>>> to do here.
>>
>> There are errors.
>>
> [...]
>>
>>
>> LGPL-2+ and GPL-2+ are ok. But, in your case, you must put: "Licese:
>> GPL-2 or GPL-2+".
>
> I'll fix these things.
Sorry, but I need you review each file. As an example, Everaldo Canuto
hasn't copyright over src/gui/osm-utils.h, src/gui/osm-gps-map-ais.c
and src/gui/osm-gpsmap-ais.h. There is a other case. I didn't see the
name Matti Aarnio in copyright. Use 'grep -sriA30 copyright *' to
search. Thanks!
>>> 4. NEWS removed. gnuais.conf-example installed by gnuais.examples.
>>> Patch added so that the program knows where to find the example
>>> configuration file since it is used as a template the first
>>> time gnuais runs. (01_conf_location.patch)
>>
>>
>> No, you can't install/change files in /usr/local. Fix it.
>
> What do you mean? It does not install anything in /usr/local..
> When gnuais is started the first time, it copies gnuais.conf-example
> into ~/.config/gnuais/gnuais.conf.
> Since gnuais.conf-example now is installed in
> /usr/share/doc/gnuais/examples instead of
> /usr/share/doc/gnuais/, the program needs to know this, and therefore
> the patch is needed.
> Maybe I have to be more precise in the patch-description.
Sorry. I will try to explain better. I saw in your patch:
- tmp_file =
fopen("/usr/local/share/doc/gnuais/gnuais.conf-example","r");
+ tmp_file =
fopen("/usr/local/share/doc/gnuais/examples/gnuais.conf-example","r");
- ret =
cpfile(conf_home_folder,"/usr/local/share/doc/gnuais/gnuais.conf-example");
+ ret =
cpfile(conf_home_folder,"/usr/local/share/doc/gnuais/examples/gnuais.conf-example");
Now I know your intention. But, from FHS[1]:
"The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being
overwritten when the system software is updated."
Your package can't touch in /usr/local. Then, the original upstream
path must be kept because you can't create a /examples/ directory
inside /usr/local. Therefore, this path will never exist.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
>>> 5. NEWS removed. OpenStreetMap is provided by libosmgpsmap which is in
>>> d/control. I haven't written a README.Debian file since I don't think
>>> there is anything special that applies for Debian users
>>> compared to other users.
>>
>>
>> Are you sure about this? Please, see:
>>
>> $ dpkg -I ../gnuais_0.3.2-1_amd64.deb
>> [...]
>> Depends: libasound2 (>= 1.0.16), libc6 (>= 2.14), libcurl3 (>=
>> 7.16.2), libmysqlclient18 (>= 5.5.24+dfsg-1), libpulse0 (>= 0.99.1)
>
> Not gnuais, but gnuaisgui.
> $ dpkg -I ../gnuaisgui_0.3.2-1_amd64.deb
> [...]
> Depends: gnuais (= 0.3.2-1), libc6 (>= 2.7), libcairo2 (>= 1.2.4),
> libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.37.3), libgtk-3-0
> (>= 3.0.0), libosmgpsmap-1.0-0 (>= 1.0.1)
Sorry, I was mistaken. You are right. Thanks for explanation.
>>> 6. I've added an icon for gnuaisgui. I have not added for gnuais since
>>> it is a command line utility only.
>>
>>
>> So I think that no need a gnuais.menu file... Why put it in menu?
>
> gnuais must run in the background when gnuaisgui is used. It might be
> useful to have it available in the menu.
> The needs="text"-option ensures that it starts in a shell. What is the
> intention with needs="text" afterall if not having
> some console-programs available in the menu? I may of course remove it
> if it's preferable.
Ok. There are cases that you need a "text" in menu. You can keep it .
But I think that it is uncommon. Maybe you can use a script to start
gnuais and gnuaisgui via menu. What you think about it?
>>> 10. I've gotten rid of the hardening-no-fortify-functions with 02_cflags.patch.
>>> The "debian-watch-may-check-gpg-
>>> signature" is still there. I hope
>>> I don't have to fix that one. I may look into that later.
>>
>> No. To solve it you will need a GPG signed file from upstream. We can
>> upload with this Lintian. But I would like to suggest you to ask for
>> upstream to add a GPG signature for next release. To see more details,
>> '$ man uscan' (search for pgpsigurlmangle). To sign the tarball, the
>> upstream can use 'gpg -ab <tarball_name>'.
>
> I will try to fix this, but it will take some time, I suppose.
Yes. As I said, we can upload this inicial version as-is.
> Thanks a lot!
>
> Regards,
> Ruben
You're welcome. I am glad to help.
Cheers,
Eriberto
Reply to: