Re: RFS: peless -- GTK Text browser
Hi Damyan and Paul
Damyan Ivanov ha scritto:
> [Added debiam-mentors and dropped Thomas from CC]
> -=| Paul Elliott, Thu, 24 May 2007 00:29:35 -0500 |=-
>> On Wed, May 23, 2007 at 12:08:16AM +0300, Damyan Ivanov wrote:
>>> -=| Giorgio Pioda, Tue, 22 May 2007 21:51:48 +0200 |=-
>>>> I have packaged a nice GTK text reader that can be very usefull to
>>>> compare files (shown in separated tabs), and search for text in
>>>> files. The package seems to me quite mature and is downloadable
>> Gentlemen, do any of these questions/issues, require that I do
>> anything to the upstream source? Is there anything I need to do?
> I think not. Perhaps the only wish of mine is to publish the source in
> the berlios download area.
>>> * A .desktop file would be nice
>> I think there is one. look in /usr/local/share/applications after a
>> "make install".
> Good. Giorgio, since you don't use "make install", this file does not
> get installed. Is there a reason to prefer debian/install over "make
> install"? Either way, please include the .desktop file in the final .deb
The reason is the 10.1 policy; I tried to set up nostrip versions for
debugging with the original "make install" but it doesn't work properly
so I switched to dh_istall and dh_strip.
>> A developer would know that these are not
>> relevant if not working with that distro.
> Sure. I am confused not by the contents of the file, but by its
> location on the site. ftp/site/debian/source.tar.gz looks like
> something debian-specific, which (I believe) is not the case.
>>> * Do you find the program useful and why?
>> I use it, but I am biased. I like to jump between files. [...]
It is nice to compare files without the fear of accidentally modify them
if this is not necessary; really nice!
> Sure, you're the author :) My question was to Giorgio. It is best
> if the maintainer uses the package so (s)he can triage bug reports,
> provide patches and otherwise be of help. This is not a strict
> requirement, but a recommendation.
>> By the way, is it too late for changes to the upstream source?
>> I have found a superior way to build peless.
>> If these changes are inconvient I will put them on hold
>> until the next changes in the source become necessary.
> Not at all. When you're happy with them, release as usual, incrementing the version string. The maintainer can prepare new packages when it is
> convenient for him.
>> Sometime in the future, I would like to get peless's error
>> messages translated into languages other than English to make
>> peless multi-lingual. The prep is all there, all user visible
>> strings are indicated by the _() macro! I just have to find
>> someone to do the translation.
> When you get non-English-native users, the translations will follow
> naturally :) If you publish the .pot somewhere, I can try the Bulgarian