Bug#851756: RFS: telegram-desktop/1.0.2-1
23.01.2017 18:51, Mattia Rizzolo пишет:
On Wed, Jan 18, 2017 at 10:07:34PM +0300, Коля Гурьев wrote:
[1] https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-1.dsc
It seems this one is using a different .orig.tar.gz than the first one.
Neither of them being the .tar.gz I download from github. bad.
I generated .orig.tar.gz using gbp utility. This archive and the one
from Github seem more or less identical except for name.
* d/compat:
+ please use 10. Read the relevant part of debhelper(7) before.
* d/control:
+ as said below, I'd say this is good to go in main
+ Build-dep on 'gyp:all', why that architecture qualification? I'm
not even sure what that is supposed to mean
...
* d/manpage.1.ex:
+ this is an example empty file, get rid of it (or even better, write
a useful one)
* d/README.Debian:
+ there is a todo there. I'm pretty sure users are not interested in
knowing you need to "Sort out dpkg-shlibdeps warnings". Please move
that list elsewhere (this could either be a d/TODO file, or bugs in
some bug tracker (like the Debian one, once it's accpeted)
...
* d/telegram-desktop.doc-base.EX:
+ this is an example file, get rid of it
Done, removed.
* d/rules:
+ BUILD_MODE doesn't seem to actually change anything except for the
name of a directory. if so I guess you can just get rid of that
+ please drop 'nostrip' handling; if you strip binaries, then dh_strip
won't have anything left to strip, and the genereted -dbgsym package
won't contain anything useful
+ also drop all of those INSTALL_* things. Just call dh_install to
copy the binary in place (no need to create the directory with it)
and then mv(1) to rename it. same for the icon: mkdir + cp is cool
(but feel free to keep using install(1) for this one if you like)
Personally I'd even prefer dh-exec over that, because I like a more
declarative packaging, but you're call.
+ I think you could just add a `--buildsystem cmake` in the dh call,
then the override_dh_auto_build could go, as could the "configure
with cmake" be substituted by a dh_auto_configure call. OTOH this
requires changing other bits of how you're building the package.
+ also the parallel stuff should really be handled by dh itself,
instead of make. besides, just doing the makes very little of the
build parallel.
I rewrote d/rules. But I haven't been able to get rid BUILD_MODE
variable, because I can't arbitrarily manipulate an output directory of
gyp. It's hard coded inside gyp sources [1]. The format is as follows:
$generator_output/$output_dir/$config
where $generator_output is an absolute path of the directory that
specified in the --generator-output parameter (it's equal to a path to a
root of a git repo), $ouput_dir and $config are the same-name parameters.
Thus I give dh the directory with CMakeLists.txt as a source directory.
And then CMake does figure everything out for itself.
But I don't know how to right clean the source. If I don't use the
workaround with `--sourcedirectory=$(CURDIR)`, the cleaning fails when
true source is already clean. It says source directory doesn't exist.
I use dh-exec to install as noted in dh_install(1).
+ you build-dep on libss1.0-dev, doesn't this work with libss1.1? If
it doesn't please open an upstream issue, and be ready to have a
debian bug as soon as it's accepted into the debian archive
Unfortunately TG Desktop doesn't compile with OpenSSL v1.1.0. I was
trying to fix it, but I've failed. This seems to require huge changes.
* d/shlibs.local:
+ why?
The package isn't being built without this. I get the error:
dh_shlibdeps -O--sourcedirectory=out/Release
install -d debian/telegram-desktop/DEBIAN
dpkg-shlibdeps -Tdebian/telegram-desktop.substvars
debian/telegram-desktop/usr/bin/telegram-desktop
dpkg-shlibdeps: error: no dependency information found for
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 (used by
debian/telegram-desktop/usr/bin/telegram-desktop)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/telegram-desktop.substvars
debian/telegram-desktop/usr/bin/telegram-desktop returned exit code 2
debian/rules:29: recipe for target 'binary' failed
And I found the temporary solution on StackOverflow [2].
* d/telegramdesktop.desktop:
+ upstream already ships one, why duplicate?
My mistake, I removed it. Initially I didn't notice that this file
already is in upstream. But I even don't know why it's there. They just
don't use it. Original Telegram Desktop automatically generates .desktop
file at the first start up.
* d/p/Avoid-depending-on-static-libraries.patch:
+ it links unrelated bugs, or why does it anyway?
+ can you work on a patch that does that by means of a compile flag,
and send it upstream?
* d/p/Fix-autorestart-when-new-language-is-selected.patch:
+ this definitely should be upstream already
I changed a bit all patches. I split them into several parts.
The first, d/p/Avoid-depending-on-static-libraries.patch, contains
everything related to address static dependencies. I understand this
patch is useless for upstream because it's inextricably bound with Debian.
The second, d/p/Flags-for-precompiled-header-and-MOC.patch,
solves issues with flags for precompiled header. I don't get how
add_precompiled_header function works, it seems I've used undocumented
features of CMake.
The third, d/p/Fix-desktop-integration-issues.patch, fixes some problems
which began because I renamed the executable binary and don't take their
Updater. I'll most likely prepare a pull request to upstream.
Now I put the new package on mentors.debian.org [3] again.
[1]
https://chromium.googlesource.com/external/gyp/+/a7055b3989c1074adca03b4b4829e7f0e57f6efd/pylib/gyp/generator/cmake.py#1092
[2] https://stackoverflow.com/a/31888928/5000805
[3]
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.2-1.dsc
Reply to: