On Thu, Jan 26, 2017 at 09:09:00PM +0300, Коля Гурьев wrote: > > 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.
I really prefer them to be bit-by-bit identical. Please use pristine-tar to accomplish so. Furthermore gbp had a bug recently whereas it wouldn't produce identical tarballs without (#851645). > Done, removed. Thank you! > > * 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 > > + 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. > > 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. Ok: Question 2: Is there any difference between a "Release" build and a "Debug" build? If the only difference is the a different -O coming from the package's build system, then there is always the -O coming from dpkg-buildflags. > > + 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. Please try to get this done soon, as I foresee it won't be long after stretch when 1.0.2 will be gone for good. > > * 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]. aehm, sigh. I guess this is also due to the broken support to dynamic linking… > 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. well, "inextricably", the only debian-specific thing is the DEB_HOST_MULTIARCH variable, but really the gnu triplet is standardized, and pretty much every building tool has a way to get to it. And the QCoreApplication::addLibraryPath should be solved elsewhere: doing that in that level is just hacky. Anyhow, good enough for a Debian upload, but you should really work toward getting this included upstream. > 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. add_precompiled_header is the locally defined function that you're patching (incidentally, that file is not included in d/copyright); what in particular don't you understand of it? In this patch you're workarounding some deficience coming from either that set(_pch_c_flags_file ...) or export_all_flags(..); not sure what, it's is pretty convoluted indeed… Wonder what's the point of such complicated build system. > 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. Yay. Question: why don't you also name the icons telegram-desktop, as you name the binary and the WMClass? > Now I put the new package on mentors.debian.org [3] again. > [3] > https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.2-1.dsc I think you're not using the boundled minizip, but still that should be referenced in the d/copyright. Also, why are you using a more restrictive license for debian/* instead of also picking the OpenSSL exception? Theoritically this could lead to patches that can't be upstreamed, or somthing stupid like this. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
