Bug#809623: RFS: telegram-purple/1.2.3-1
On Sun, Jan 3, 2016 at 3:31 AM, Ben Wiederhake wrote:
> - flawfinder yields too many results to be practical (~ 2460 lines). This is
> mostly due to libtgl being written in a style that uses static arrays for
> everything, including parsing and output.
I've been thinking of making the default for c-a-t-t to limit output
of checks by default, probably to around 10 lines.
> - The output of "POFileSpell" seems to depend on the local dictionaries. It
> seems to flag every word in every language I don't speak. (~ 1640 lines)
This is correct, you obviously need to install the relevant
dictionaries for it to be useful.
> - i18nspector and Transifex (the service we use for our translation) heavily
> disagree about how a po-file should look like, and how Russion plurals
> work(?!).
Jakub discussed this.
> - include-what-you-use Is completely useless: It doesn't recognize
> <stddef.h>, although it is installed and appears in the reference:
> http://en.cppreference.com/w/c/header
> It also recommends to do a lot of silly things, such as including struct
> declarations in .c files. (~ 2820 lines)
Jakub explained this.
> - The following check complains loudly about plurals:
> "find -type f \( -iname '*.po' -o -iname '*.pot' \) -exec msgfmt --check
> --check-compatibility --check-accelerators --output-file=/dev/null {} \;"
> I'm not sure what to do with that information. We want correct plural
> support, so this won't change.
Jakub explained this. I plan to have some sort of verbosity level
thing in c-a-t-t, less verbosity would turn off --check-compatibility
for this check I guess.
> - "suspicious-source" works like a charm. It runs in a fraction of a second,
> and outputs only a single line: "./tg-server.tglpub"
> That's absolutely correct! I like that program. (I'm not complaining, I'm
> admiring the program. The file ./tg-server.tglpub is clearly documented in
> the README.md, including a link to a side-project with the sole purpose of
> reproducibly generating this single file for public sources.)
Hmm, are you sure?
pabs@chianamo ~/telegram-purple-1.2.3 $ grep tglpub README.md
pabs@chianamo ~/telegram-purple-1.2.3 $
After reading the source code I see that it is some sort of public key.
> - The "Please add some upstream metadata" warning triggers. Since this is
> not a scientific project, and there won't be any doi-references, I'm going
> to ignore the warning. However, I'm going to use this to ask: Why is that a
> warning? Why not include it in the build scripts of the deb-science
> packaging team instead?
The upstream metadata stuff has nothing to do with science apart from
being initiated by the science team. Just include the parts that apply
to this package. I don't understand why so many people have this
misconception.
> - The problem of bashisms relates to the program checkbashism, like
Not sure I understood this.
> incompatibilities between make-implementations to checkgmakeism, a program
> I'd like to see being written. I made up the name. I have no idea how to do
> that. So far, we did it by trial and error, and change something whenever a
> user complains. AFAIK, by now we only support gmake, due to the use of
> "ifdef", which should be ".ifdef" in bsd-make:
> https://github.com/majn/telegram-purple/issues/137#issuecomment-167970054
That would be a good check to have but for now I don't know of any
implementation or anyone interested in working on such a thing.
> Sorry for the wall of text, but you *did* ask for it :P
I did :)
One goal of c-a-t-t is to expose more people to the tools, eventually
leading to better tools :)
> Btw: I'm naturally subscribed to the bug. And because you address your mails
> to me, too, I receive them twice :P
Apologies, the default in the Debian BTS is to not subscribe
submitters and I can't assume that you are on debian-mentors, so I
CCed you.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: