[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> - 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.



Reply to: