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 `-
Attachment:
signature.asc
Description: PGP signature