On 15/07/15 15:11, Pietro Battiston wrote: > Il giorno dom, 12/07/2015 alle 20.38 +0200, Tomasz Buchert ha scritto: > > On 11/07/15 00:37, Pietro Battiston wrote: > > > Hi Tomasz, > > > > > > thank you very much for your careful review. > > > > > > Il giorno mar, 30/06/2015 alle 13.58 +0200, Tomasz Buchert ha > > > scritto: > > > > On 30/06/15 12:35, Pietro Battiston wrote: > > > > > > > > > > [...] > > > > > > > > There is also the "issue" of polluting $PATH with so many > > > > binaries, > > > > but I don't think it's a formal requirement. I think it would be > > > > better > > > > to have "gbutils plot ..." interface. > > > > > > > > > > This I think is unavoidable. Typically, running analyzes with such > > > utilities involves calling several of them in a same bash > > > command... > > > the fact that each can be called with a short and intuitive > > > sequence of > > > digits is crucial. Something like "gb rand" rather than "gbrand" > > > _could_ in principle work, but I don't think I would prefer it, > > > both > > > for ease of use and because installing a two-chars executable would > > > actually, to my eyes, create more pollution (increase the > > > probability > > > of clashes). > > > > Actually I proposed "gbutils" (not "gb"), but, as I said, there is > > probably no formal requirement in this respect. > > > Hi Pietro, > Just to clarify: I had understood your suggestion, and my answer to it > is "I don't think it is practical for users". Think of it as replacing > cat, echo, grep and others with "unixutils cat", "unixutils echo", > "unixutils grep"... the similarity breaks when we look at the userbase, > but for those who do use gbutils... I think you get my point. Frankly, I don't get your point. These are basic Unix programs, used all the time in scripts, command line, etc. And there is also tradition. The <program> <command> interface is not a bad idea: git uses it and I don't think that people find git "impractical". But I don't really care, as long as the people at the NEW queue have nothing against it and the multitude of commands does not collide with anything else in the whole archive (have you checked?). > > > > > > > > That said, the fixed package is still at > > > http://mentors.debian.net/debian/pool/main/g/gbutils/gbutils_5.6.6 > > > -1.dsc > > > > > > I also uploaded the packaging repo to Alioth, something previously > > > I > > > had forgot to do: > > > git://anonscm.debian.org/collab-maint/gbutils.git > > > > You probably forgot to push upstream and pristine-tar branches. > > Och, and moreover, Vcs-Browser is wrong. You can use: > > https://anonscm.debian.org/cgit/collab-maint/gbutils.git > > > > Fixed, thanks. I don't know what had made me so sure that the link was > right and I had to just wait the 6 hours time to see it work. > I now also pushed the upstream and pristine-tar branches, as well as > the tags. Great. > > Related to your other email, I updated build-depends and depends so > that now all utilities/functionalities are compiled and installed, and > introduced a patch fixing a few typos in the previously not installed > utilities. > > Updated package: > http://mentors.debian.net/debian/pool/main/g/gbutils/gbutils_5.6.6-1.dsc > > Thanks again! You're welcome. Do you want me to sponsor it? (in any case, don't forget to verify that there are no collisions, apt-file search is your friend) > > Pietro > Cheers, Tomasz
Attachment:
signature.asc
Description: Digital signature