Bug#809623: Fwd: Re: Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

(For completeness: this is the mail to which Gianfranco Costamagna 
responded. This mail contains no new information.)



 Weitergeleitete Nachricht 
Betreff: Re: Bug#809623: RFS: telegram-purple/1.2.3-1
Datum: Wed, 13 Jan 2016 21:40:27 +0100
Von: BenWiederhake.GitHub <benwiederhake.git...@gmx.de>
An: Gianfranco Costamagna <costamagnagianfra...@yahoo.it>

Hello,


My script would probably do the following thing:
- delete the file fetched by uscan, since it's utterly incomplete
- use the upstream version to clone (as in git-clone) the repository
- ./configure && make dist || (echo "Too old upstream version; doesn't
support orig tarballs yet."; exit 1)
- delete all temporary files
Ugh.


seems an overkill :)


Seems like it, true, but sadly is necessary. The package is in version
control, and unless we provide pre-bundled origtars somewhere (which
won't happen), this has to build the origtar by invoking "make dist" in
the source tree.


And all that so that someone can say "dh get-orig-source".
So, who does this? (And can I assume git to be installed? I don't like
having such a big b-d ...)


git is needed for everybody who wants to work on Debian, not needed
to be a b-d :)


Now this is getting absurd: the whole point of dh get-orig-source is to
support people for who "git pull" is too complicated. But suddenly I can
assume that git is installed, although git is not pulled by build-essential?

$ sudo pbuilder --login
(SNIP)
# apt-get install build-essential
[SNIP]
# git --version
-bash: git: command not found


In short, the reason is: tgl ("the" submodule) is way too unstable and
volatile to ever be packaged separately.


this makes sense even if it should be avoided, but it is up to your sponsor
that part :)


Well, either that, or roughly 8 packages that are absolutely and utterly
useless building libtgl. (I'm not overestimating! 3 packages for
tl-parser and tgl each, plus 2 packages for "generate")

I agree with you that this should be avoided at *most* costs, but not at
*all* costs.

Regards,
Ben

Bug#809623: RFS: telegram-purple/1.2.3-1

[BenWiederhake.GitHub]

Hello,


They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.


no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded 
tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source


Oh, wow. This will take a bit time until I grasp everything well enough 
to publish something with this :P


Most prominently, I don't like the "everythingisoneline" approach of the 
watchfile. I guess someone has already suggested changing it to the 
"usual" YAML-based approach?



this is my virtualbox watch file

version=3

opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*//
 \
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2
 \
debian /bin/sh debian/get-orig-source.sh


I... I believe I understand this. However, testing this will be a pain, 
and automatic testing probably impossible.


Is there some kind of established "best practice" for testing these? Or 
is the best practice just to "run by hand until it works, then wait 
until it breaks for DEHS"?



I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they
will be dropped in the next version, in favor of relatively clean
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that
into Build-Depends.)


sure, even better, maybe if you integrate with watch file.


I can do that, sure. Can you tell me who profits from this, though? It's 
a bit demoralizing to have to write and test things like these if noone 
will ever profit from this.


I understand that d/watch is needed by DEHS to monitor how outdated the 
Debian repository is, in some sense. So I wrote a d/watch for that, and 
made sure it works and will continue to work.


I also understand that some maintainers prefer working with uscan to 
fetch and integrate the newest upstream version. But that doesn't apply 
here, as the preferred mode of updating is doing a "git pull".


My script would probably do the following thing:
- delete the file fetched by uscan, since it's utterly incomplete
- use the upstream version to clone (as in git-clone) the repository
- ./configure && make dist || (echo "Too old upstream version; doesn't 
support orig tarballs yet."; exit 1)

- delete all temporary files
Ugh.

And all that so that someone can say "dh get-orig-source".
So, who does this? (And can I assume git to be installed? I don't like 
having such a big b-d ...)



BTW submodules should in my opinion be considered as different sources, and 
packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to 
track and fix
(specially for security issues)


Already extensively documented in d/README.source

In short, the reason is: tgl ("the" submodule) is way too unstable and 
volatile to ever be packaged separately.


There is only one other program that might enter the Debian repository 
(tg-cli, I don't see any RFP or ITP for it) will never be used together 
with telegram-purple, and will most definitely never use a compatible 
version of tgl.



Currently, we assume that the builder eventually invokes ./configure
with whatever arguments he pleases and the usual semantics. This
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the
new configure-script will be put into git. At no point, there's a need
for the "user" (here: builder) to call auto{,re}conf.



Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?


exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you,  but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated,


None of our scripts assume any architecture or have a list of all of 
them. What part of which script would become "outdated"? What would change?



BTW the version should always be a -1 revision, until the -1 reaches debian 
(specifically new queue)


Hmm, but this makes it easier for me to track which versions there were.

But okay, I'll push the next version as 1.2.4-1 if you wish.


you don't have to bump the debian revision, this will make harder for a sponsor 
to track it, and
useless for Debian users (they won't find the intermediate releases)


Huh? I'm confused. I make sure that all versions have a different 
number, and go increasing as per dpkg --compare-versions. Why is it 
*harder* to track progress?


I mean, sure, I can change my behavior regarding that, I just think it's 
a good idea if I also know the reason for it :P


Regards,
Ben

Bug#809623: RFS: telegram-purple/1.2.3-1

[Gianfranco Costamagna]

Hi again,



>Oh, wow. This will take a bit time until I grasp everything well enough 
>to publish something with this :P
>
>Most prominently, I don't like the "everythingisoneline" approach of the 
>watchfile. I guess someone has already suggested changing it to the 
>"usual" YAML-based approach?


you should just call uscan [--debug] and have your new tarball ready to go

>I... I believe I understand this. However, testing this will be a pain, 
>and automatic testing probably impossible.
>
>Is there some kind of established "best practice" for testing these? Or 
>is the best practice just to "run by hand until it works, then wait 
>until it breaks for DEHS"?


I don't follow, uscan just calls the script you are calling manually, and in
addition it calls it with the parameters (version and so on).

you just need to look at vbox get-orig-source script, it should be easy to 
understand

>I can do that, sure. Can you tell me who profits from this, though? It's 
>a bit demoralizing to have to write and test things like these if noone 
>will ever profit from this.


other people will be able to look at the sources, integrate a new release
without having to know how exactly all of this works
>I understand that d/watch is needed by DEHS to monitor how outdated the 
>Debian repository is, in some sense. So I wrote a d/watch for that, and 
>made sure it works and will continue to work.


sure, but adding a script called, it doesn't break that part

>I also understand that some maintainers prefer working with uscan to 
>fetch and integrate the newest upstream version. But that doesn't apply 
>here, as the preferred mode of updating is doing a "git pull".


this might make sense then :)

>My script would probably do the following thing:
>- delete the file fetched by uscan, since it's utterly incomplete
>- use the upstream version to clone (as in git-clone) the repository
>- ./configure && make dist || (echo "Too old upstream version; doesn't 
>support orig tarballs yet."; exit 1)
>- delete all temporary files
>Ugh.


seems an overkill :)

>And all that so that someone can say "dh get-orig-source".
>So, who does this? (And can I assume git to be installed? I don't like 
>having such a big b-d ...)


git is needed for everybody who wants to work on Debian, not needed
to be a b-d :)

>Already extensively documented in d/README.source


ack
>In short, the reason is: tgl ("the" submodule) is way too unstable and 
>volatile to ever be packaged separately.


this makes sense even if it should be avoided, but it is up to your sponsor
that part :)

>There is only one other program that might enter the Debian repository 
>>(tg-cli, I don't see any RFP or ITP for it) will never be used together 
>with telegram-purple, and will most definitely never use a compatible 
>version of tgl.


ok

>None of our scripts assume any architecture or have a list of all of 
>them. What part of which script would become "outdated"? What would change?


I don't remember, config.sub and config.guess were outdated in many packages 
because
of missing autotools-dev and autoreconf.

I don't think this harms somewhere, so why not run it automatically?

(I'm a cmake guy, I can't provide a better rationale, I run it because it 
works(TM))
>Hmm, but this makes it easier for me to track which versions there were.
>
>But okay, I'll push the next version as 1.2.4-1 if you wish.


no problem, you can bump the revision, just when the package will be ready 
somebody will
have to merge everything in a single -1 revision and upload on unstable

>Huh? I'm confused. I make sure that all versions have a different 
>number, and go increasing as per dpkg --compare-versions. Why is it 
>*harder* to track progress?
>
>I mean, sure, I can change my behavior regarding that, I just think it's 
>a good idea if I also know the reason for it :P


nah it is fine, just I like to press "CTRL+R" telegram-purple, find the dget 
line
and press enter :)

too lazy to go on mentors, search the last revision, copy-paste the link and 
then dget
(for this git is better for sure)

cheers,

Gianfranco

Bug#809623: RFS: telegram-purple/1.2.3-1

[Gianfranco Costamagna]

Hi,

>
>Seems like it, true, but sadly is necessary. The package is in version 
>control, and unless we provide pre-bundled origtars somewhere (which 
>won't happen), this has to build the origtar by invoking "make dist" in 
>the source tree.


why you cant provide pre-bundled origtars? I know some project that does 
exactly the same.

they have submodules and when they tag a new release, they also upload the 
version together
with the "minimal" one

e.g.
https://github.com/vslavik/poedit/releases

>Now this is getting absurd: the whole point of dh get-orig-source is to 
>>support people for who "git pull" is too complicated. But suddenly I can 
>assume that git is installed, although git is not pulled by build-essential?


I'm not talking about buildd machines. uscan usually is called by *developers*
who want to try to build the package.

e.g. a normal user does apt-get source telegram-purple (because it is outdated
and he want the new and shiny version)

he do the apt-get source, he do the uscan --debug, and at the end he can build
everything (maybe an uupdate).
(let us assume the new release doesn't need packaging changes of course)

>Well, either that, or roughly 8 packages that are absolutely and utterly 
>useless building libtgl. (I'm not overestimating! 3 packages for 
>tl-parser and tgl each, plus 2 packages for "generate")
>
>I agree with you that this should be avoided at *most* costs, but not at 
>*all* costs.


I fully agree there, if it can be avoided fine, but if not... we should deal
with a common sense and a trade-off.

Now I come with a question.
You want to maintain the package only in Debian? or in all linux distro around 
the globe?

you are doing the repack work as Debian work, this means that other linux 
derivatives
won't ever gain from the work, and they will need to do it again.

Pushing the tarball (complete and reduced) upstream, will save a lot of work 
for everybody



and simplify a lot the Debian packaging
(just a simple watch file, with no repack at all).

Do you agree on this point?
(I'm not saying my POV is the correct one, but sometimes Upstream and Debian 
have to fight a little
bit and find a common way :) )

cheers!

Gianfranco

Bug#809623: RFS: telegram-purple/1.2.3-1

[BenWiederhake.GitHub]

Control: tags -1 - moreinfo

Hello,

thanks for taking a look at this package :D


I'm not sure if anybody picked up the work for this bug, but lets do
another review:

- -please drop commented default stuff from rules file
- -please merge changelog in one single entry
  (also "mentors" is not a target series)


These (and only these; see below) are already fixed in 1.2.4-2, which 
was uploaded 8 days ago [1]


I guess I did something wrong if you haven't seen that, even though I 
thought it should be done this way. Can you tell me what I should do 
differently next time?



- -please drop rawtar and genorigtar.sh, they seem useless with the
current watch file.


They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.

As already documented in d/README.source, the orig-tarball can't be 
gathered from the obvious sources:

- Github (definitely)
- pristine-tar (definitely)
- git-buildpackage (afaik)
They all fail for the same reason: missing support for submodules within 
submodules. (Or gbp simply requires more setup than I thought.)


I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they 
will be dropped in the next version, in favor of relatively clean 
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that 
into Build-Depends.)



- -please use autoreconf and b-d on dh-autoreconf if possible


I'm not entirely sure what you mean by this.

Currently, we assume that the builder eventually invokes ./configure 
with whatever arguments he pleases and the usual semantics. This 
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the 
new configure-script will be put into git. At no point, there's a need 
for the "user" (here: builder) to call auto{,re}conf.


Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?

On a side note: 1.2.4 isn't going to make it anyway. Apparently, it's 
horribly unstable on Windows.


Regards,
Ben Wiederhake
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809623#79

Bug#809623: RFS: telegram-purple/1.2.3-1

[Gianfranco Costamagna]

Hi,



>These (and only these; see below) are already fixed in 1.2.4-2, which 
>was uploaded 8 days ago [1]


dget -u 
http://mentors.debian.net/debian/pool/main/t/telegram-purple/telegram-purple_1.2.4-2.dsc

this is the file I downloaded now and it looks better.

Maybe when you have too many versions, you can consider deleting the package 
from mentors and uploading it
again, just to avoid sponsors to download an older version


>I guess I did something wrong if you haven't seen that, even though I >thought 
>it should be done this way. Can you tell me what I should do 

>differently next time?

maybe delete and reupload :)
but honestly it was my fault, I didn't look at the whole RFS bug thread.

>They generate the orig tarball.
>The watchfile is to check for the newest version.
>These are unrelated things.


no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded 
tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source

this is my virtualbox watch file

version=3

opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*//
 \
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2
 \
debian /bin/sh debian/get-orig-source.sh
>As already documented in d/README.source, the orig-tarball can't be 
>gathered from the obvious sources:
>- Github (definitely)
>- pristine-tar (definitely)
>- git-buildpackage (afaik)
>They all fail for the same reason: missing support for submodules within 
>submodules. (Or gbp simply requires more setup than I thought.)


ok this seems legit then :)

>I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they 
>will be dropped in the next version, in favor of relatively clean 
>chaining of git-archive and tar --concatenate.
>(Obviously not part of the build process, so no need to put any of that 
>into Build-Depends.)


sure, even better, maybe if you integrate with watch file.

BTW submodules should in my opinion be considered as different sources, and 
packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to 
track and fix
(specially for security issues)

>I'm not entirely sure what you mean by this.
>
>Currently, we assume that the builder eventually invokes ./configure 
>with whatever arguments he pleases and the usual semantics. This 
>approach does not need anything explicit in d/rules.
>autoreconf is only called when we change configure.ac, in which case the 
>new configure-script will be put into git. At no point, there's a need 
>for the "user" (here: builder) to call auto{,re}conf.

>Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?


exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you, but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated, and just 
rebuilding the package
with an updated toolchain will make them build on new architectures.

so, b-d on dh-autoreconf and call --with autoreconf from the default dh call

>On a side note: 1.2.4 isn't going to make it anyway. Apparently, it's 
>horribly unstable on Windows.


who cares? :)

I mean, if the bugs are windows-only related this shouldn't be a stopper for 
Debian

BTW the version should always be a -1 revision, until the -1 reaches debian 
(specifically new queue)

you don't have to bump the debian revision, this will make harder for a sponsor 
to track it, and
useless for Debian users (they won't find the intermediate releases)

cheers,

G.

Bug#809623: RFS: telegram-purple/1.2.3-1

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tags -1 moreinfo

Hi,

I'm not sure if anybody picked up the work for this bug, but lets do
another review:

- -please drop commented default stuff from rules file
- -please use autoreconf and b-d on dh-autoreconf if possible
- -please merge changelog in one single entry
 (also "mentors" is not a target series)
- -please drop rawtar and genorigtar.sh, they seem useless with the
current watch file.

note: I didn't test the program, there is something to fix
before :)

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWll34AAoJEPNPCXROn13ZIwYQAJSU1K6/dQ9rwgRIdWbUtwKn
hsJwLIwDO+dMMpMt8X925SveoyQxsivMyASZ6lDr2C6GySEdgsTBl4gnqebSeYrh
BkjD37jEcAMeGWxVLsGWnEeTdU1viMHziPSNcebZE7OdP6dLesSW4B/iBCqQ2WCd
ZXhYHZ8Yo2hF9/5u3X1Prfnjnuyo4rCZnTxQLeES1whgEqK+Vo0lX89k91JYWPiJ
XHAHOSuP4yrpdYPFSVbB+HrjbHZWqFeBdfCrxOqTtWqH+XMJ4zjW4TCdIaVieUib
8HrZH4yVJx/1gY5RUUxEeamA72lxByvnJeGPhpaW6XAtX8TSn425BAVaEeb0suq3
gzVmNtps5wphXexJpqXMJJkxA13YSCHCq+5YC1sS68EFrOb4mUsfL7njrQB46HGU
ZHccEcewD/6e1Yv+lSTOdej3wMfcfyflDBGCLg+x5s+wHSeSXwL/y5VxNlSqBIW/
va9ZW6SoN702oTnY/khyL1yY6USqfbW2HZUbLTbHmfzSBEK2FdoAzOGDhXrGeXmX
Sgnne6Gluv0Y+9Tyf85JbiU9pyGZft8w7HnlJkFi3DsW1oQ5UmFm11TP3nsFIvPR
LrIDAzU/lc7YzWEOfrvZQTCI3jturV19fAOxJ8/4Be0KBSppuZt7msvK4VyUep8H
bKy4Ye3PgqIdIXNoahXW
=AOmJ
-END PGP SIGNATURE-

Bug#809623: RFS: telegram-purple/1.2.3-1

[Paul Wise]

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

Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

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


Sounds good!


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


How about an option that changes the following:
- Current: thousands of warning for French, because the French dict is 
missing.
- Suggested: single warning, saying "French dictionary not found 
(expected at /usr/share/some/where)"


But I guess this should be reported against POFileSpell, not c-a-t-t, right?


- "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 $


*head-desk*

It looks like I wrote the documentation while tired.

$ grep tlgpub README.md
We no longer ship `tg-server.pub` (old format), but instead
   `tg-server.tlgpub` (new format). [snip]

Obviously, the spelling "tlg" is wrong, and should be "tgl". All files 
are named correctly. This will be fixed in the next upstream release.



After reading the source code I see that it is some sort of public key.


It is, basing on Telegram's public key. (Has to be requested by mail. 
Don't ask me why they had that idiotic idea.)
The tglpub file-format is easy enough to be written with nothing but a 
hexeditor; is clearly explained (just three big endian integers); comes 
along with a program that demonstrates how to generate the tglpub given 
the original pubfile.


In case you wonder why we don't just read the original pubkey: 
proprietary file format, and wanted to avoid using a function that 
smells like OpenSSL.



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


Because it's the first and only thing at which I looked when opening the 
page for the first few times. Now I finally actually read it (oh god, 
sorry dear author of the page). I included it into 1.2.4-2. (See 
separate mail.)



- 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


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.


Sure, no pressure, just wanted to mention it, in case a 
Make-compatibility-guru reads along :P



Sorry for the wall of text, but you *did* ask for it :P


One goal of c-a-t-t is to expose more people to the tools, eventually
leading to better tools :)


I wasn't even remotely aware of the sheer flood of such tools, each of 
them doing different things, and then there's sanity check so basic that 
you didn't even need a "tool" for that and just used grep/find/etc. 
Thank you for the program, the work, the feedback :D


Regards,
Ben Wiederhake

Bug#809623: RFS: telegram-purple/1.2.3-1

[Paul Wise]

On Wed, Jan 6, 2016 at 1:25 AM, Ben Wiederhake wrote:

> How about an option that changes the following:
> - Current: thousands of warning for French, because the French dict is
> missing.
> - Suggested: single warning, saying "French dictionary not found (expected
> at /usr/share/some/where)"
>
> But I guess this should be reported against POFileSpell, not c-a-t-t, right?

Sounds perfect. Indeed it should be reported against POFileSpell. If
you do that, please mark it as affecting c-a-t-t and add c-a-t-t
usertags though, using the documentation listed in the c-a-t-t README
file.

> It is, basing on Telegram's public key. (Has to be requested by mail. Don't
> ask me why they had that idiotic idea.)
> The tglpub file-format is easy enough to be written with nothing but a
> hexeditor; is clearly explained (just three big endian integers); comes
> along with a program that demonstrates how to generate the tglpub given the
> original pubfile.
>
> In case you wonder why we don't just read the original pubkey: proprietary
> file format, and wanted to avoid using a function that smells like OpenSSL.

Personally I would have just made a text based format with a comment
header containing a URL to the format description, followed by 3 lines
containing the integers :)

> Because it's the first and only thing at which I looked when opening the
> page for the first few times. Now I finally actually read it (oh god, sorry
> dear author of the page). I included it into 1.2.4-2. (See separate mail.)

FYI, there is some talk of merging it into the AppStream standard as
Charles Plessy doesn't have time to fix the gatherer.

> I wasn't even remotely aware of the sheer flood of such tools, each of them
> doing different things, and then there's sanity check so basic that you
> didn't even need a "tool" for that and just used grep/find/etc. Thank you
> for the program, the work, the feedback :D

I'm glad to see people using it :)

Please note that there were 3 implementations of this idea:

My ugly unmaintainable list of shell commands on a wiki page:

https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

My initial attempt at writing something maintainable:

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things-old.git

Jakub Wilk's much cleaner and better initial implementation of the same:

https://bitbucket.org/jwilk/maquack

He didn't want to work on it any more and his version was much better
so I dumped mine, renamed his to check-all-the-things and continued
from there. Thanks to Jakub Wilk for doing the initial work and
injecting some sanity into this project :)

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git

Jakub writes a lot of things, If anyone wants to package his stuff,
there are still some things not yet in Debian:

https://jwilk.net/software/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#809623: RFS: telegram-purple/1.2.3-1

[BenWiederhake.GitHub]

* d/README.source
- In upstream README.md you tell Debian Maintainers to use the
genorigtar.sh. Looking at Policy §4.14, I think README.source should
also instruct to do that.

* Paul Wise already wondered if libtgl should be separately packaged.
The related Debian Policy bit is §4.13 [3]


[Follow-up Mail]


 * Please install the appdata file. You can do this with dh_install(1)
by creating a file called debian/install with this line in it:
telegram-purple.metainfo.xml usr/share/appdata
or by making the upstream build system install the file.


Here's my initial attempt at writing a README.source that covers all 
topics (displaying the content does not require you to clone or do 
anything, works even without JavaScript) :


https://github.com/BenWiederhake/telegram-purple/tree/debian-develop/debian#readme

Is this an acceptable way to write up all rationales?

The other fixes are "in the pipeline" (mostly already done in git), but 
the next upload to mentors may take another day or three.


I'll post some of the things discovered by check-all-the-things (e.g. a 
new error from cppcheck, spelling mistakes in debug messages, etc.) as 
pull requests to the respective repositories. However, none of them need 
immediate attention or can be considered a bug. (The cppcheck-thing 
looks pretty concerning, but I understand enough of the code to verify 
that the uninitialized values are never read, so it's good enough, 
considering the PR I'll make against tgl.)


Regards,
Ben

Bug#809623: RFS: telegram-purple/1.2.3-1

[Jakub Wilk]

* Ben Wiederhake , 2016-01-02, 23:13:

The Russian PO file reads:

Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 
&& n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && 
n%10<=9) || (n%100>=11 && n%100<=14)? 2 : 3);

[...]
Even though I don't speak Russian, I can tell that this Plural-Forms 
can't possibly be correct. Here 4 plural forms are declared, but the 
expression never evaluates to 3.


Since it's just modular arithmetic, one can just parse the formula to 
fill out a 10x10 table as a "proof". I did that, and came to the same 
result as you do, without even looking at your program. (Originally I 
assumed a precedence error / parsing issue / whatever, so I didn't 
want to start reading C code ... sorry.)


For the record, here's my interpretation, with parenthesis added:

((n%10==1 && n%100!=11)
? 0
: ((n%10>=2 && n%10<=4 && (n%100<12 || n%100>14))
   ? 1
   : ((n%10==0 || (n%10>=5 && n%10<=9) || (n%100>=11 && n%100<=14))
  ? 2
  : 3)))

This rule can be written in regex as follows (note that there is an 
implicit "and not any of the above", although it doesn't make a 
difference):

- "[023456789]1" => "Transifex one"
- "[023456789][234]" => "Transifex few"
- "1.|.[056789]" => "Transifex many"
- else => "Transifex other"


Hmm, these "one"-"few"-"many"-"other" reminded me about CLDR. An indeed, 
if you look at CLDR's plurals table[0], there's a 4th form applicable to 
floating-point numbers. My hypothesis is that this Plural-Forms is a 
result of a botched automatic conversion from CLDR data. 


[0] 
http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html#ru

Now, it would be cool if i18nspector explained better what is wrong 
here. [snip]  I hope to implement this in the future.


Sounds awesome! However, I was still able to understand that 
*something* about the expression was fishy, but didn't understand that 
i18nspector is able to detect issues like this.


i18nspector has a small database of "correct" Plural-Forms for the most 
"popular" languages (including Russian). So all it knew was that your 
Plural-Forms was different than the rest of the world uses.


(It does have other Plural-Forms correctness checks that don't require 
any linguistic data, but they didn't trigger in this case.)



(Doesn't that essentially require a SAT-solver?)


Theoretically, yes, checking that a plural expression never evaluates to 
a certain value is NP-hard.


But in practice almost all real-world Plural-Forms are structured 
similarly to what we saw in this thread, making them easy to analyse. So 
I intend to implement something like this:


1) Try to prove that f(i + 100) == f(i) for all i > 100.

2) If we're able to prove it, then we know that the image of f is equal 
to {f(0), f(1), ..., f(199), f(200)}.


3) Otherwise, assume that the Plural-Forms is okay. (Alternatively: 
assume that Plural-Forms so unusual that it's almost certainly broken.)


--
Jakub Wilk

Bug#809623: RFS: telegram-purple/1.2.3-1

[Eduardo M KALINOWSKI]

On 02-01-2016 19:08, Jakub Wilk wrote:
>
>> and how Russion plurals work(?!).
>
> The Russian PO file reads:
>
> Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2
> && n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 &&
> n%10<=9) || (n%100>=11 && n%100<=14)? 2 : 3);
>
> Even though I don't speak Russian, I can tell that this Plural-Forms
> can't possibly be correct. Here 4 plural forms are declared, but the
> expression never evaluates to 3.
>

These links show expected plural forms:

http://localization-guide.readthedocs.org/en/latest/l10n/pluralforms.html
https://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms

They seem to agree on the expression for Russian.


-- 
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Bug#809623: RFS: telegram-purple/1.2.3-1

[Paul Wise]

On Sun, Jan 3, 2016 at 12:29 AM, Ben Wiederhake wrote:

> Telegram-purple is a generic purple-plugin, and also works well with Adium,
> Finch, and well enough with certain libppurple-using frontends such as
> telepathy-haze and Spectrum.
> So 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.

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

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

I wonder if libtgl should be packaged separately so that all the
Telegram clients could use it?

BTW, Telegram has a pretty terrible reputation amongst cryptographers,
personally I would switch to OTR or Signal/TextSecure if you can.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#809623: RFS: telegram-purple/1.2.3-1

[Juhani Numminen]

On Sat, 02 Jan 2016 01:49:10 +0100 Ben Wiederhake
 wrote:

> I am looking for a sponsor for my package "telegram-purple"

I am not a DD or DM, so I can't offer sponsoring, but here are some
things for you to look at.
I'm hoping to help you improve the package and to learn myself as well.

 * d/changelog
   - Usually only the versions that made into Debian are listed here,
so I'd collapse the entries to just one entry containing "Initial
release" only.

 * d/control
   - The Vcs-* fields point to debian packaging. You should specify
the branch in Vcs-Git as described in Debian Policy §5.6.26 [1] and
add Vcs-Browser field, too.

* d/rules
  - Most of those comment lines seem to be from a package template and
could be removed. I'd keep just L29 which actually explains why
something is done (and of course L1 which is the special shebang
line).

* d/README.source
   - In upstream README.md you tell Debian Maintainers to use the
genorigtar.sh. Looking at Policy §4.14, I think README.source should
also instruct to do that.

* Paul Wise already wondered if libtgl should be separately packaged.
The related Debian Policy bit is §4.13 [3]

[1] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields
[2] https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
[3] https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

Regards,
Juhani Numminen

Bug#809623: RFS: telegram-purple/1.2.3-1

[BenWiederhake.GitHub]

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

Bug#809623: RFS: telegram-purple/1.2.3-1

[BenWiederhake.GitHub]

Hello,
>>   * Package name: telegram-purple


This should probably be named pidgin-telegram in line with the other
pidgin/libpurple plugins we have in the archive already.


Oh, I forgot to include the rationale for sticking with the name.

Telegram-purple is a generic purple-plugin, and also works well with 
Adium, Finch, and well enough with certain libppurple-using frontends 
such as telepathy-haze and Spectrum.

So including "pidgin" into the name would be highly misleading.

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)?



The package is (of course) lintian clean and passes several other tests.

In case you want to check more things, you can run
check-all-the-things from Debian experimental.


Oh! I never checked experimental, that's why I didn't find it XD

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'm going to work through the 8K likes it spits out over the next days.

Regards,
Ben Wiederhake

Bug#809623: RFS: telegram-purple/1.2.3-1

[Jakub Wilk]

Hi, I happen to be i18nspector upstream.

* BenWiederhake.GitHub , 2016-01-02, 20:31:
- i18nspector and Transifex (the service we use for our translation) 
heavily disagree about how a po-file should look like,


Care to elaborate on how they "heavily disagree"?


and how Russion plurals work(?!).


The Russian PO file reads:

Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<12 || n%100>14) ? 
1 : n%10==0 || (n%10>=5 && n%10<=9) || (n%100>=11 && n%100<=14)? 2 : 3);

Even though I don't speak Russian, I can tell that this Plural-Forms 
can't possibly be correct. Here 4 plural forms are declared, but the 
expression never evaluates to 3.


I'm too lazy to make a mathematical proof that this the case, so instead 
I wrote a small program that demonstrates it. Please see the attachment. 
Let me know if the program ever stops. :-P


Now, it would be cool if i18nspector explained better what is wrong 
here. That is, instead of


E: ru_RU.po: incorrect-plural-forms 'nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) 
|| (n%100>=11 && n%100<=14)? 2 : 3);' => 'nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;' or 'nplurals=4; 
plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;'

which is likely to make your eyes bleed, said something like this:

E: ru_RU.po: codomain-error-in-plural-forms f(x) != 3

I hope to implement this in the future.


- include-what-you-use Is completely useless: It doesn't recognize ,


This is bug #722132, which is super-annoying (and I would consider it RC 
if I were the maintainer), but IME you can often just ignore iwyu's 
moaning about missing standard headers.



- 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 {} \;"


Using --check-compatibility is probably a bad idea. It will complain 
about things that almost everyone wants, like the header entry or plural 
forms.


--
Jakub Wilk
#include 

unsigned long f(unsigned long n)
{
	return n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || (n%100>=11 && n%100<=14)? 2 : 3;
}

int main(int argc, char **argv)
{
	unsigned long i;
	for (i = 0; ; i++) {
		printf("f(%lu) = %lu\n", i, f(i));
		if (f(i) == 3)
			break;
	}
}

Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

Hi, I happen to be i18nspector upstream.


Wow! What a quick response, thank you :)


- i18nspector and Transifex (the service we use for our translation)
heavily disagree about how a po-file should look like,


Care to elaborate on how they "heavily disagree"?


I "only" refer to the pluralization form.


and how Russion plurals work(?!).


The Russian PO file reads:

Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 &&
n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9)
|| (n%100>=11 && n%100<=14)? 2 : 3);


This is copied verbatim from the Transifex service. I'm not competent 
enough in Russian to dare touching it. This discussion seems to lead to 
a bug in Transifex itself. I'll contact Transifex about this, linking to 
this discussion.



Even though I don't speak Russian, I can tell that this Plural-Forms
can't possibly be correct. Here 4 plural forms are declared, but the
expression never evaluates to 3.


Since it's just modular arithmetic, one can just parse the formula to 
fill out a 10x10 table as a "proof". I did that, and came to the same 
result as you do, without even looking at your program. (Originally I 
assumed a precedence error / parsing issue / whatever, so I didn't want 
to start reading C code ... sorry.)


For the record, here's my interpretation, with parenthesis added:

((n%10==1 && n%100!=11)
 ? 0
 : ((n%10>=2 && n%10<=4 && (n%100<12 || n%100>14))
? 1
: ((n%10==0 || (n%10>=5 && n%10<=9) || (n%100>=11 && n%100<=14))
   ? 2
   : 3)))

This rule can be written in regex as follows (note that there is an 
implicit "and not any of the above", although it doesn't make a difference):

- "[023456789]1" => "Transifex one"
- "[023456789][234]" => "Transifex few"
- "1.|.[056789]" => "Transifex many"
- else => "Transifex other"

In this form, it's rather easy to verify that "Transifex other" never 
happens. The names of the forms are based on what Transifex calls them.



I'm too lazy to make a mathematical proof that this the case, so instead
I wrote a small program that demonstrates it. Please see the attachment.
Let me know if the program ever stops. :-P


I'm going to recommend http://haroldbot.cloudapp.net/ for this, even 
though it fails with "Something went wrong" for all queries related to 
this. I have no idea why.



Now, it would be cool if i18nspector explained better what is wrong
here. [snip]  I hope to implement this in the future.


Sounds awesome! However, I was still able to understand that *something* 
about the expression was fishy, but didn't understand that i18nspector 
is able to detect issues like this. (Doesn't that essentially require a 
SAT-solver?)


([snip] other issues that need no response from my side.)

Regards,
Ben Wiederhake
PS: Juhani Numminen, I haven't ignored your mail, but my response to 
your mail is going to take longer. Sorry, and thanks for your detailed 
feedback!

Bug#809623: RFS: telegram-purple/1.2.3-1

[Juhani Numminen]

2016-01-02 20:40 GMT+02:00 Juhani Numminen :
> I am not a DD or DM, so I can't offer sponsoring, but here are some
> things for you to look at. [...]

I'll add to that:

 * Please install the appdata file. You can do this with dh_install(1)
by creating a file called debian/install with this line in it:
telegram-purple.metainfo.xml usr/share/appdata
or by making the upstream build system install the file.

Regards,
Juhani

Bug#809623: RFS: telegram-purple/1.2.3-1

[Paul Wise]

On Sat, Jan 2, 2016 at 8:49 AM, Ben Wiederhake wrote:

>  * Package name: telegram-purple

This should probably be named pidgin-telegram in line with the other
pidgin/libpurple plugins we have in the archive already.

> The package is (of course) lintian clean and passes several other tests.

In case you want to check more things, you can run
check-all-the-things from Debian experimental.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#809623: RFS: telegram-purple/1.2.3-1

[Ben Wiederhake]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "telegram-purple"

 * Package name: telegram-purple
   Version : 1.2.3-1
   Upstream Author : Matthias Jentsch 
 * URL : https://github.com/majn/telegram-purple
 * License : GPL2+
   Programming Lang: C
   Section : net

It builds those binary packages:

  telegram-purple - Purple plugin to support Telegram

To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/telegram-purple

Alternatively, one can download the package with dget using this command:

  dget -x http://mentors.debian.net/debian/pool/main/t/telegram-purple
/telegram-purple_1.2.3-1.dsc

I've been following the debian-mentors list for quite a while, so it's likely
that I made different mistakes :P
The package is (of course) lintian clean and passes several other tests.
There is no pidgin-packaging team, otherwise I would have contacted them months
ago.

Regards,
Ben Wiederhake