Bug#809623: RFS: telegram-purple/1.2.3-1
Telegram-purple is a generic purple-plugin,
[...] including "pidgin" into the name would be highly misleading.
Other libpurple backends are named pidgin-* (like pidgin-openfetion,
pidgin-skype and pidgin-librvp) and I don't see any libpurple backends
with other names. Perhaps these packages should be renamed though.
Consistency for the sake of consistency is not always a good thing. And
since this "consistency" can be confusing, I'm going to wilfully break it.
Furthermore, renaming the plugin to "pidgin-telegram" has several
disadvantages: All error messages would need to be adapted, paths would
need updating, including the translation strings, and users are probably
expecting the name to be "telegram-purple" (at least initially).
Where should I write this down? d/control maybe? Or as a "wontfix"-bug
against the package (as soon as it exists in the BTS)?
As a comment in debian/control or README.Debian. I wouldn't bother
filing a wontfix bug yourself.
Will do so in the next upload.
It reports a lot of things, mostly false positives or related to the
underlying libtgl. However, at least codespell (the very first to be run,
and I was sure I already did that) yields a few things.
I'd be interested to know if those are false positives in the tools it
runs or caused by it.
Again, I haven't really had the time to go through it, but here's an
overview:
- 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.
- 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)
- 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(?!).
- 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)
- 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.
- "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.)
- 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 problem of bashisms relates to the program checkbashism, like
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
Sorry for the wall of text, but you *did* ask for it :P
I wonder if libtgl should be packaged separately so that all the
Telegram clients could use it?
We previously thought about this, and came to the result: No.
So far, ABI-compatibility was broken between every other commit to
libtgl, and it is under development. The last "stable" release is quite
a long time ago and heavily outdated. No other program (*including*
tg-cli) can be expected to use the same version of libtgl alongside
telegram-purple.
Packaging tl-parser or the intermediate "generate" program is also a bad
idea: One *could* do that, but it's only useful for libtgl. So there is
a significant lack of users.
Note that tl-parser is relatively stable, especially the output format.
So if anyone disagrees with me in the amount of users, I'm happy to
package tl-parser for you.
BTW, Telegram has a pretty terrible reputation amongst cryptographers,
personally I would switch to OTR or Signal/TextSecure if you can.
I know, and I agree. I support Telegram for other reasons.
But this isn't about which one is better. Telegram *does* have non-zero
Debian users that are using pidgin. Note there are enough people already
using the Fedora package, the Adium bundle (distributed by Matthias on
github), clone the repo directly, or use the Ubuntu PPA, to rectify
inclusion in Debian.
Regards,
Ben Wiederhake
Btw: I'm naturally subscribed to the bug. And because you address your
mails to me, too, I receive them twice :P
Reply to: