Re: RFS: peless -- GTK Text browser
no, the cleanup refers to the debian package. I've already done it for
the most (but not uploaded to my web space).
But if you have newer version let me know, I'll work on your new release.
I've solved the boost_regex problem with a quick check with dpkg -S and
subsequent reg-exp to look which flag is the correct one and the package
is compiling well under SID and ETCH (backport possible)
Paul Elliott ha scritto:
> 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 at:
> Gentlemen, do any of these questions/issues, require that I do anything to
> the upstream source? Is there anything I need to do?
>> Some comments/questions:
>> * Why aren't the .dsc and .changes files gpg-signed?
>> * Upstream URL is missing from debian/copyright
>> * There are some commented lines in debian/rules that will never be
>> used. Why not get rid of these?
>> * Similarly, debian/watch may be cleaned up somewhat.
>> * Long description misses a space between "them." and "It". The second
>> sentence seems redundant to me
>> * A .desktop file would be nice
> I think there is one. look in /usr/local/share/applications after a "make install".
>> * The URL in debian/watch
>> (ftp://ftp.berliOS.de/pub/peless/ubuntu.704/peless-(.*)\.tar\.gz) looks
>> strange. Is there a "distribution-neutral" source?
> The spec files for other distros are in the tarball but these
> are not installed by "make install". So these files would not
> be seen by a binary user. A developer would know that these are not
> relevant if not working with that distro.
>> * Do you find the program useful and why?
> I use it, but I am biased. I like to jump between files. I like to have
> my lister be an X program so I can let it be hidden by other windows
> when I am not using, then bring it to the top, when I want to use it
>> dam JabberID: email@example.com
> By the way, is it too late for changes to the upstream source?
> I have found a superior way to build peless.
> This was prompted by Giorgio Pioda's query about boost versions
> and handling the boost libraries. The version you have is my
> ad-hoc way of dealing with this problem. At the time peless
> was originally developed, this was the only possible solution.
> Giorgio Pioda's, question however, has caused me to do some research
> on the net and I found out that Thomas Porschberg
> <firstname.lastname@example.org> has found a superior solution in the form of
> some m4 macros. http://www.randspringer.de/boost/
> This method will probably become the standard way of dealing
> with boost in a auto* tools context.
> It has the advantage that it automaticly figures out what
> version of boost is there. In most cases no parameters
> are needed on the ./configure line.
> These changes affect only the way peless is built, it involves
> no changes to the ultimate source i.e. the .cc and .h files!
> I have done some proof of concept testing of Thomas Porschberg's
> method with peless and it appears to work.
> If these changes are inconvient I will put them on hold
> until the next changes in the source become necessary.
> 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.
> In the USA, you can travel thousands of miles, before you can find a
> place where a language other than English is commonly used. That is
> why we are all so bad at languages. The exception is Spanish in the
> South and Southwest, but I came to Texas to late to in life learn
> Spanish or TexMex.
> Thank you for helping put peless into debian.