Bug#835141: RFS: telegram-purple/1.3.0-1 [ITP] -- Purple plugin to support Telegram

[Ben Wiederhake <BenWiederhake.GitHub@gmx.de>]

Package: sponsorship-requests
Version: sponsorship-requests
Severity: wishlist

Dear mentors,

in this mail:
(1) Asking potential sponsor about state
(2) normal RFS stuff
(3) things where I need help


(1) @Josue Ortega:  Are you still interested in sponsoring this package?  If
not, no problem, just please say so :)


(2) normal RFS stuff:
I am looking for a sponsor for my package "telegram-purple":

 * Package name    : telegram-purple
   Version         : 1.3.0-1
   Upstream Author : Matthias Jentsch <mtthsjntsch@gmail.com>
 * 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:

    https://mentors.debian.net/package/telegram-purple

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

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

Or if you prefer to view the tree:

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

The package is (of course) mostly lintian clean and passes several other tests.
- Lintian "spelling-error-in-binary":  it's in a debug message of tgl.
- Lintian "hardening-no-bindnow":  see below

There is no pidgin-packaging team, otherwise I would have contacted
them nearly a year ago.

Please read README.source for some packaging choices.

Changes since the last upload (February 2016):
- new upstream version (finally! :D)
- bump standards from 3.9.6.0 to 3.9.8.0 (no-op)
- simplify orig-tar generation (upstream support)
- check for any changed copyrights (removal of "rawtar" process)
- reduce and fix d/docs
- update README.source ('make dist' and typos)
- update dev chat link in d/upstream/metadata


(3) Things where I need help:

The suggested fix for "hardening-no-bindnow" (namely, `hardening=+all`,
which inserts a `-fPIE`) breaks the build, as we need to build an
intermediate shared library, tgl, which can't work with PIE.  The
failing call to gcc looks like this:
    gcc -shared -o libs/libtgl.so objs/${lot-of-objects}.o -fPIE -pie \
      -Wl,-z,relro -Wl,-z,now -L/usr/lib/${and/so/on} -rdynamic -ggdb -lz
-lgcrypt
    /${path/to}/Scrt1.o: In function `_start':
    (.text+0x20): undefined reference to `main'
Since technically that file doesn't need to be built, the final
shared library (would) also fails:
gcc -shared -o bin/telegram-purple.so objs/${lots}.o tgl/libs/libtgl.a \
  -fPIE -pie -Wl,-z,relro -Wl,-z,now -L${paths} -l${things} -rdynamic -ggdb
Being a shared library, there naturally is no `main`, and a shared library
shouldn't be compiled with -fPIE.  Thus, I ignore this warning.

QA on mentors claims that the watchfile isn't valid:
    A watch file is present but doesn't work
    - Scanning for watchfiles in .
    - Found watchfile in ./debian
    - Scan finished
I can't reproduce this on my local 'testing' installation, nor
'unstable' chroot, as `./debian/rules get-orig-source` works as
expected, and I don't know QA's exact invocation of uscan, or the
error they see.

Regards,
Ben Wiederhake