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

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.

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: