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