Bug#940666: RFS: phpliteadmin/1.9.8.2-1 -- web-based SQLite database admin tool

[Коля Гурьев]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "phpliteadmin"

 * Package name: phpliteadmin
   Version : 1.9.8.2-1
   Upstream Author : Dane Iracleous , Christopher 
Kramer  and others
 * URL : https://www.phpliteadmin.org/
 * License : GPL-3.0+
 * Vcs : https://salsa.debian.org/mymedia-guest/phpliteadmin
   Section : web

It builds those binary packages:

  phpliteadmin - web-based SQLite database admin tool
  phpliteadmin-themes - web-based SQLite database admin tool - themes

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/phpliteadmin

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/phpliteadmin/phpliteadmin_1.9.8.2-1.dsc

Or you can see a merge request of the new package version:

  
https://salsa.debian.org/mymedia-guest/phpliteadmin/merge_requests/2/diffs#b92c9d7f6a1fe2f439cb4bef6011394658166981

Changes since the last upload:

   * New upstream release.
 - New dependency, PHP module mbstring.
   * Drop Fix-authentication-bypass.patch since hash_equals() is now used
 to compare passwords.
   * Bump Standards-Version to 4.4.0.
 - Specify 'Rules-Requires-Root: binary-targets' in d/control.
   * Bump debhelper compatibility level to 12, no related changes.

Regards,

--
  Nicholas Guriev



signature.asc
Description: OpenPGP digital signature

Bug#931036: RFS: dhelp/0.6.26 QA, RC

[Коля Гурьев]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "dhelp"

 Package name : dhelp
 Version  : 0.6.26
 License  : GPL-2
 Section  : doc

It builds those binary packages:

  dhelp - online help system

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/dhelp

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

  dget -x https://mentors.debian.net/debian/pool/main/d/dhelp/dhelp_0.6.26.dsc

Changes since the last upload:

 * Do not remove entire /usr/share/doc/HTML directory while reindexing
   or deinstalling (closes: #929850).
 * Add the sensible-utils package as runtime dependency.
 * Use Git repository at the salsa.debian.org site.

Regards,
 Nicholas Guriev

Bug#907250: RFS: ms-gsl/1.0.0-2 [RC]

[Коля Гурьев]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ms-gsl"

 Package name: ms-gsl
 Version : 1.0.0-2
 Upstream Author : Microsoft Corporation
 URL : https://github.com/Microsoft/GSL
 License : Expat (MIT)
 Section : libdevel

It builds those binary packages:

  libmsgsl-dev - Microsoft Guidelines Support Library

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/ms-gsl


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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/ms-gsl/ms-gsl_1.0.0-2.dsc

Also there is a merge request on salsa:

  https://salsa.debian.org/debian/ms-gsl/merge_requests/1/diffs

Changes since the last upload:

  * Add Catch-Classic-Workaround.patch (closes: #906385).
- Redefine a macro for compatibility with Catch 1.x.x.


Regards,
 Nicholas Guriev

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Коля Гурьев]

17.05.2017 15:20, Mattia Rizzolo пишет:

Well, I guess at least gbp's upstream/ tags at least, in this
case I'd expect a debian/0.4.1~git20170514.73bf810 at the commit
afa9bd2ea3c81a3f74b740946186a94e2112c957.
I think there should be a flag in some gbp command to do that in some
cases (but I don't have enough experience in using gbp on top of the
upstream git repo)


Okay, I created debian/0.4.1_git20170517.2ed5a50-1 and 
upstream/0.4.1_git20170517.2ed5a50 tags. I hope it's the right thing.


17.05.2017 15:23, Mattia Rizzolo пишет:

Although, I now see upstream did a commit "hopefully" fixing it, so try
that out instead of your "solution"?


Cool! This really fixes the error, at least for me.

Furthermore, I fixed post-receive hook on Alioth. I accidentally set 
post-update hook instead of post-receive.

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Коля Гурьев]

In addition, I added a patch for fix deadlock when an incoming call is 
complete. It works for me, but it may cause some other problems.

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Коля Гурьев]

16.05.2017 13:01, Mattia Rizzolo пишет:

Using git as you know I prefer it :)


Okay


I fixed the HEAD on alioth to point to the debian branch (as otherwise
cloning would checkout master causing
warning: remote HEAD refers to nonexistent ref, unable to checkout.


Thank you


), also could you please push some upstream tags and add an appropriate
d/gbp.conf?


What kind of tags you're interested in? Unfortunately, there are no any 
tags in the upstream repository.


I also renamed debian branch to master, so gbp seems to be working.


Review:
* d/control:
  + Vcs-Git is wrong
  + I appreciate when Vcs-Browser is the same as Vcs-Git, given they can
be now (hint: use /git/ in both)
* d/rules:
  + why are you calling dh_install manually at the end of
dh_auto_install? it's called by dh anyway


I corrected a link to git and rewrote d/rules for a little.


It also fails to build for me on i386 with an error that looks like SSE2
related (but I'll let you look at it).


I added a condition for x86. On other Little-Endian architectures the 
package is built, but I don't know whether it works.


16.05.2017 13:05, Gianfranco Costamagna пишет:

does this mean having to restrict telegram to amd64 and eventually only i386?
this would exclude a lot of architectures


Why? I think no, it've been compiled on Launchpad, but it seems Telegram 
won't be working on Big-Endian machines.

Bug#862691: RFS: telegram-desktop/1.1.0-1 - official telegram messaging application

[Коля Гурьев]

Package: sponsorship-requests
Control: block -1 by 862687
X-Debbugs-CC: mat...@debian.org

Dear mentors,

I am looking for a sponsor for my package "telegram-desktop"

 * Package name: telegram-desktop
   Version : 1.1.0-1
   Upstream Author : John Preston 
 * URL : https://desktop.telegram.org
 * License : GPLv3+ with OpenSSL exception
   Section : net

It builds those binary packages:

  telegram-desktop - official telegram messaging app

To access further information about this package, please visit the 
following URL:


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.1.0-1.dsc


Changes since the last upload:

  * New upstream release
- Telegram Calls in desktop application and other improvements
  * Refresh patches
- Fixed hung on startup in Unity or MATE environment (LP: #1680943)
- Changed optimization level from -Ofast to -O2

The new version of the package depends on libtgvoip, a library for 
calls. I also packaged it, and you will find it mentors.d.n too.


Mattia, I send this email to you because you already uploaded previous 
versions. You don't mind?


By the way, I pushed commits with the new version into git.d.o. The 
package that I uploaded to mentors.d.n, corresponds to 579fd0b commit.


Regards,
  Nicholas Guriev

Bug#862687: RFS: libtgvoip/0.4.1~git20170514.73bf810-1 [ITP] - VoIP library for Telegram clients

[Коля Гурьев]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libtgvoip"

 * Package name: libtgvoip
   Version : 0.4.1~git20170514.73bf810-1
   Upstream Author : Gregory Klyushnikov 
 * URL : https://github.com/grishka/libtgvoip
 * License : Unlicense (in public domain)
   Section : libs

It builds those binary packages:

   libtgvoip-dev - VoIP library for Telegram clients - developer files
   libtgvoip0.4.1 - VoIP library for Telegram clients

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/libtgvoip

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

dget -x 
https://mentors.debian.net/debian/pool/main/libt/libtgvoip/libtgvoip_0.4.1~git20170514.73bf810-1.dsc


This is build dependency for the new version of Telegram Desktop.

Regards,
  Nicholas Guriev

Bug#861352: RFS: dhelp/0.6.23 [QA] -- online help system

[Коля Гурьев]

28.04.2017 08:52, Gianfranco Costamagna пишет:

well, with apache2 installed, the whole package is not working
http://localhost/doc/HTML/index.html

I think you have to configure it, this is why I thought it was a problem
on my apache installation and not on your package.
Removing apache2 makes the documentation stuff show correctly and nicely.


It was the error of dhelp, I was able to reproduce this.

Without Apache it worked because dhelp tries to guess it should
redirect a browser to local filesystem or to localhost server.

I daresay if you install apache2 and enable dhelp.conf file and cgi
module, the package will be working.

But maintainer scripts don't turn cgi module on automatically at the
moment. I'll try to solve this.

Bug#861352: RFS: dhelp/0.6.23 [QA] -- online help system

[Коля Гурьев]

27.04.2017 23:52, Gianfranco Costamagna пишет:

Hi,

apache2-maintscript-helper invoked from a modified environment. Please hint 
required arguments manually
dpkg: error processing package dhelp (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:



not sure, but removing apache2 "fixed" the issue

who cares? the package works :)
(feel free to investigate if you want!)

G.


Thanks that you noticed this bug.

But removing apache2 looks like a dirty hack. This error occurred
because of the bad merge. Take a look at a fix[1], please.

[1] 
https://anonscm.debian.org/cgit/collab-maint/dhelp.git/commit/?id=f33acd31ac972c43c17f298d7671ae80ec9157a2

Bug#861352: RFS: dhelp/0.6.23 [QA] -- online help system

[Коля Гурьев]

Package: sponsorship-requests

Dear mentors,

I found an unfortunate mistake in my previous patch for dhelp[1]. It 
broke search. So I prepared changes to fix it. I also resolve these 
lintian warnings:


  W: dhelp source: package-uses-deprecated-debhelper-compat-version 5
  W: dhelp source: ancient-standards-version 3.9.3 (current is 3.9.8)
  W: dhelp: spelling-error-in-readme-debian the the (duplicate word) the

There is only one lintian warning left:

  W: dhelp: apache2-reverse-dependency-uses-obsolete-directory 
etc/apache2/conf.d/dhelp.conf


It seems the package provides configuration file for Apache 2.4.


So I am looking for a sponsor for the package "dhelp"

 * Package name: dhelp
   Version : 0.6.23
 * License : GPL v2+
   Section : doc

It builds those binary packages:

dhelp - online help system

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/dhelp


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dhelp/dhelp_0.6.23.dsc


Besides, I discovered a git repository for the package and pushed there. 
The archive which was uploaded to mentors, correspond to a commit with 
hash 588535b.



https://anonscm.debian.org/cgit/collab-maint/dhelp.git/commit/?id=588535b3aee782df8ca56bd7cab10fa963baac50

Changes since the last upload:

  * QA upload.

  [ Nicholas Guriev ]
  * Complete the migration process from Berkeley DB to GNU dbm.
- Fix crash on searching.
  * Bump debhelper version.
  * Update standards version.
- Deleted a deprecated d/menu file.
- Wrote a new dhelp.desktop file.
- Added link to a git repository.
  * Now www-browser dependency is suggested, but not recommended, to
avoid autoinstallation redundant programs on servers.
  * Add mandatory dependency on libcgi-pm-perl package (closes: #824219)
  * Basque, Indonesian, Japanese, Swedish translations (found in VCS).

  [ Georgios M. Zarkadas ]
  * Fix unowned files after purge (closes: #679691).


Regards,
  Nicholas Guriev

Bug#861233: RFS: dhelp/0.6.22 [QA] -- online help system

[Коля Гурьев]

Package: sponsorship-requests
Control: block 791770 by -1

Dear mentors,

I am looking for a sponsor for the package "dhelp"

 * Package name: dhelp
   Version : 0.6.22
 * License : GPL v2+
   Section : doc

It builds those binary packages:

dhelp - online help system

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/dhelp


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dhelp/dhelp_0.6.22.dsc


Changes since the last upload:

  * QA upload.
  * Remove ruby-bdb dependency (closes: #791770)
- Migrate to a module from the standard library.
- Update tests.
  * Replace perl-modules dependency with just perl.


Regards,
  Nicholas Guriev

Bug#859235: RFS: telegram-desktop/1.0.27-1 -- official telegram messaging application

[Коля Гурьев]

In the last commit ce2dcd9 I already modified libmicrosoft-gsl-dev build 
dependency to libmsgsl-dev (according to a new name of that package, see 
#859238). Also a repo address was changed to 
https://anonscm.debian.org/git/collab-maint/telegram-desktop.git


01.04.2017 05:37, Boyuan Yang пишет:

Now that the RFS is blocked by other packages, could you please try to add
patch for #859057? The patch is tested by someone on Ubuntu and is working
well (at least on little-endian machines).


I added a patch, but I didn't test it. If it works, I'll send it to the 
upstream.



Plus, could you please add the workaround for #859172? The patch is simple but
could avoid crashing on GTK-based DEs. We need a real solution in the future.

diff --git a/debian/control b/debian/control
index 91fa74cb..ffba1455 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Vcs-Browser: https://github.com/mymedia2/tdesktop

 Package: telegram-desktop
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, qt5-image-formats-plugins
(>=5.5)
+Depends: ${shlibs:Depends}, ${misc:Depends}, qt5-image-formats-plugins
(>=5.5), libappindicator3-1
 Description: official telegram messaging app
  Telegram is a messaging app with a focus on speed and security, it is
  super-fast, simple and free. You can use Telegram on all your devices at the


I doubt that it's related to appindicator. And I still don't know how to 
reproduce that error. But I hope it was fixed in the new version.

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Коля Гурьев]

08.04.2017 18:07, Mattia Rizzolo пишет:

Nice, would you also please push upstream and prisitine-tar branches?
(you may name upstream and debian branches as you see fit, just be sure
HEAD points to the packaging branch and debian/gbp.conf reflects the
reality if it's not the default)


Done.


Look better, debhelper >= 10 is available in xenial, yakkety and zesty.
Besides, in theory you are supposed to test your packages in Debian too
:P

Also, it shouldn't matter much, as you should be building your packages
in the current development version, using a chroot (see tools like
pbuilder or sbuild).


Oh, I was a fool, I didn't note that this version is available in 
xenial-updates repository. I used xenial in chroot jail for ensure that 
all dependencies are specified correctly. But pbuilder or sbuild seem so 
complicated for me.



> It seems the upstream doesn't need this patch because they use a last

version of UnitTeset++ framework where the header has capital letters.


| + In libunittest++ debian package others paths are.

The grammar of this sentence is off :)
I suggest "In the libunittest++ debian package the paths are different".
But is it really just a debian thing? :O  Or upstream changed something?


Sorry, English isn't my native language (you already know it) :-(
As for libunittest++, I think it relates to old version of this package 
in Debian archive, v1.4. A new version v2.0 is available, but it looks 
that everything works okay.

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Коля Гурьев]

04.04.2017 03:22, Mattia Rizzolo пишет:

As others said already, 'microsoft' in the package name is a sad
situation.  Personally, is just a can of worms I do not want to open for
so little, so please rename it to something else (I like 'ms-gsl').


I changed package name to ms-gsl as you want (libmsgsl-dev for .deb 
package). These names sound as good as the previous ones, I think. 
Anyway, I don't know much about these law things.



 Version : 0.1~2017.03.20~git16a6a41-1


I recommend using 0 instead of 0.1 as base version.


Okay, I see this is a good idea. I also updated to a new version as well.


As I said privately, I'd enjoy having a git repository for this :)
Here I feel you could enjoy even more baing the repo out of upstream
git (see an example in the dehydrated package); or you can see my
pencil2d package for an example of a thing building tarball out of
upstream git, ready to be committed; as you prefer.


I temporally uploaded my repo to GitHub [1]. I believe alioth.debian.org 
will be a better location. I've registered there (my username is 
mymedia-guest) just now.


The first commit in that repository corresponds to what I uploaded to 
mentors.debian.net. I made final modifications (for this stage) in the 
last, 8dec145.


I also made get-orig-source target in d/rules. It clones the upstream 
repository and pack it in a tar archive. I made it because I hadn't 
found any tarball on upstream GitHub.



* test building, I noticed it didn't take advantage of my quad-core
  system; why didn't you use compat level 10?


I'm Ubuntu user, but there is only debhelper of version 9 in ubuntu 
repositories. So I added --parallel option into d/rules file as an 
interim solution.



* please send that UnitTest.patch upstream; that's clearly one of those
  cases their stupid system with a case-insensitive file system tricked
  them…
* that empty directory tests/unittest-cpp, why didn't you remove it?


It seems the upstream doesn't need this patch because they use a last 
version of UnitTeset++ framework where the header has capital letters.
Was I supposed to delete that directory? I thought it was in the 
upstream repo and I shouldn't have touch it.


04.04.2017 20:25, PICCORO McKAY Lenz пишет:

this "library" does not provide real funtionallity, its only to code "as
moscosoft like"


You got the wrong idea. This library is an implementation of C++ Core 
Guidelines written by Bjarne Stroustrup and Herb Sutter. It could very 
well be included into a future C++ Standard. You have not to regard this 
as a creature of evil Microsoft. See an old announce [2].


Theoretically, this may not be the only implementation, but I could not 
find another one. If you get a replacement, I'll be very glad. But right 
now your attacks are unconstructive and blatantly false.


[1] https://github.com/mymedia2/ms-gsl
[2] 
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

Bug#859238: RFS: microsoft-gsl/0.1~2017.03.20~git16a6a41-1

[Коля Гурьев]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "microsoft-gsl"

 Package name: microsoft-gsl
 Version : 0.1~2017.03.20~git16a6a41-1
 URL : https://github.com/Microsoft/GSL
 License : MIT (Expat)
 Section : libdevel

It builds those binary packages:

  libmicrosoft-gsl-dev - Microsoft Guidelines Support Library

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/microsoft-gsl

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/microsoft-gsl/microsoft-gsl_0.1~2017.03.20~git16a6a41-1.dsc


More information about hello can be obtained from https://www.example.com.

This package is required for build new version of telegram-desktop

Regards,
 Nicholas Guriev

Bug#859235: RFS: telegram-desktop/1.0.27-1 -- official telegram messaging application

[Коля Гурьев]

Oh sorry, I forgot to say that for build this package you have to 
install libmicrosoft-gsl-dev [1]. This is build dependency.


[1]: 
https://mentors.debian.net/debian/pool/main/m/microsoft-gsl/microsoft-gsl_0.1~2017.03.20~git16a6a41-1.dsc

Bug#859235: RFS: telegram-desktop/1.0.27-1 -- official telegram messaging application

[Коля Гурьев]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I've prepared a package with new version of Telegram Desktop. So I am
looking for a sponsor for my package "telegram-desktop"

 * Package name: telegram-desktop
   Version : 1.0.27-1
   Upstream Author : johnprestonm...@gmail.com
 * URL : https://desktop.telegram.org
 * License : GPLv3+ with OpenSSL exception
   Section : net

It builds those binary packages:

telegram-desktop - official telegram messaging app

To access further information about this package, please visit the 
following URL: https://mentors.debian.net/package/telegram-desktop


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

dget -x 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.27-1.dsc


Changes since the last upload:

  * New upstream release
  * Refresh patchs
  * Add attribution info (closes: #859027)
  * Fix build in i386 (closes: #859058)

I see some errors on mentors site. What do they mean?

Mattia, I send to you this request because you are my sponsor for the 
previous upload.


Regards,
 Nicholas Guriev

Bug#851756: telegram-desktop/1.0.12-1

[Коля Гурьев]

Hi!

26.02.2017 14:35, Mattia Rizzolo пишет:

few minutes/hours after this they released another one too, it seems :P
They took the whole "release early, release often" thing a bit too
seriously, IMHO u.U


Yeah, I updated my repo with the package [1], and now I have nothing to add.

But I have a question related to new alpha versions. The upstream 
removed some third code from their repository, but they added submodule 
GSL [2]. It's not GNU Scientific Library, but Guideline Support Library 
from Microsoft under MIT (Expat) license. This library seems not to be 
in the Debian archive. Should I package it? It's used only at build-time.


Another submodule, Mapbox Variant, seems already to be in the 
libmapbox-variant-dev package.



umh, TBH I wouldn't know.  We usually *love* very verbose builds.
Outputting the whole gcc command is usually a good idea, as there are
tools checking the build logs for the presence of certain build flags
(see blhc and bls).
I *think* you could pass an extra -DCMAKE_VERBOSE_MAKEFILE=OFF to
verride the previous -DCMAKE_VERBOSE_MAKEFILE=ON passed by debhelper,
but if you want it, I'd like if you could put it behind a check for the
presence of a variable or something so you can do it only in your
system, so others keep getting the full log.
Besides, in case of failure the gcc call is priceless!


Okay, then whenever I want to make build less detailed, I'll temporarily 
append this flag to dh_auto_build command in the d/rules file. I didn't 
found another appropriate place for this.



As you perhaps noticed, my knowledge of English is not very well, and I
don't know what the problem with the manpage.


Ack.  Yes, that "allow to" → "allow one to" is a bit tricky.
I sent you a PR for that.


I merged it, thanks!


I can't understand why pristine-tar is necessary if I could download an
original tarball using uscan (or manually).


You probably little.  The gain for me is quite relevant, as for example
right now I'm connected through a 3G modem with limited bandwitdh; using
pristine-tar allowed me to download few KBs and get a several MB tarball
out; probably I could have lived by downloading the tarball anew, but it
is for example priceless while working on libreoffice-dictionaries,
where the tarballs are 70+ MB with very small changes across versions.
It mostly is a tool to help coworkers, but in the past it came handy
also for me, in a moment where I wanted to build several past versions
of a program and instead of downloading hundreds of MBs of tarballs I
could just `pristine-tar checkout` them out.

BTW, the name you used for the tarball you committed is unfortunate, as
a tool named `origtargz` (from devscripts) can detect it.  It would be
nice if you could commit the renamed/symlinked one made by
$srcname_$ver.orig.tar.gz
that you surely have around somehow, given that you need it to actually
build the package.


I got it, thank you! Did I make pristine commit correctly?


Note that this doesn't match *at all* your top commit (that you even
tagged) cfb1daea9b2ff0b4501d2e97ca979d56b5b58364 :P
Anyway, given that now we got a workable git repository, feel free to
stop uploading those, and just hand me a commit id :)


Well, I left a tag debian/1.0.14-1 on e04e46e commit id.

[1] https://github.com/mymedia2/tdesktop/releases/tag/debian/1.0.14-1
[2] https://github.com/Microsoft/GSL

Bug#851756: telegram-desktop/1.0.12-1

[Коля Гурьев]

Control: retitle -1 RFS: telegram-desktop/1.0.13-1 [ITP]

Oh, but they have released a new version today. So current upstream 
version is 1.0.13. I uploaded new package [1] into mentors just in case.
A bug, when a main window was not closed by Alt-F4 and in some other 
cases, has been fixed.


20.02.2017 17:17, Mattia Rizzolo пишет:

DPKG_EXPORT_BUILDFLAGS = 1
is not needed: if you read debhelper(7) you'll see that starting with
compat 9 those are already exported by dh.


It's fine. I removed this line from d/rules.


export DH_VERBOSE  # for easy debugging this script
does this work without the "=1" bits?  (personally I export that in my
environment as I always want local builds to be as verbose as possible,
so I don't see the difference.


Indeed, it works even without this line.

And also, how can I turn verbose CMake output off? I fear to miss an 
important GCC warning. But I don't want to interrupt compilation in this 
case.



It's not a techinical thing, but more political, actually.  I want to
decide the license of what I write.
But what you did before was ok.


Well, I'm completely confused, sorry, then I brought it back.


This still need to take care of:

* spelling-error-in-binary (please upstream the fix)
* spelling-error-in-manpage
* desktop-entry-lacks-keywords-entry (please upstream the fix)


I'll make a pull request to upstream for fix keywords and encoding 
fields in .desktop file. It seems spelling errors in binary are related 
to log strings, those are not showed in user interface.


As you perhaps noticed, my knowledge of English is not very well, and I 
don't know what the problem with the manpage.



Hmm... It seems to be working. But lintian sill warnings about
hardening-no-fortify-functions.


That usually means that something doesn't respect
CFLAGS/CXXFLAGS/CPPFLAGS & friends


Maybe this is a false positive...


git check:
* pristine-tar is not pushed/updated (after some check, if you have
  pristine-tar-commit=True doing a `gbp buildpackage…` it does commit it
  by itself, in some cases.…)
* you have a lot of branch, including a "master" (which is HEAD) and a
  "debian", but it seems latter is abbandoned, and the actual
  debianization is on "master".  can you clean it up a bit?
* you have a weird looking tag tmp-old-debian
* you might want or not to push the upstream branch in your repo, your
  call, but if you don't let me suggest you don't call the debianization
  branch "master" ("debian" is cool, but please change HEAD).
* there is not upstream tag pushed for the last upstreams


I deleted all old branches, renamed current master to debian and pushed 
all new tags (I keep forgetting to run git push --tags ¯\_(ツ)_/¯ ).


I can't understand why pristine-tar is necessary if I could download an 
original tarball using uscan (or manually). Pristine-tar seems to commit 
binary blobs into git repo. Why, in thunder? What the profit if I still 
must download the tarball?


[1] 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.13-1.dsc

Bug#851756: telegram-desktop/1.0.12-1

[Коля Гурьев]

New version has been released yesterday. I built the package [1] and 
fixed some your comments as you wrote.


Sorry for the delay. I had some troubles with hardware of my computer, 
but I hope now they have been solved.


11.02.2017 15:41, Mattia Rizzolo wrote:

I do not assume the sponsoree is subscribed to either the bug or
debian-mentors, so I suggest you always CC him.


No problem, I obtained that message using Web-Browser.

02.02.2017 20:33, Boyuan Yang wrote:

* Please consider explicitly enable (full) hardening flags in d/rules and test
if the build can pass.


Hmm... It seems to be working. But lintian sill warnings about 
hardening-no-fortify-functions.



* Is the hard Depends: to fcitx-frontend-qt5 necessary? Your instruction would
make everyone who installs telegram-desktop to install fcitx, which is an
Input Method Framework. I recommend you downgrade it to Suggests.

* Build-depends fcitx-frontend-qt5 seems very wrong. Could you please explain
why you add this one?


You are perfectly right. I removed fcitx-frontend-qt5 from build 
dependencies. I also removed libva-dev and libvdpau-dev because I 
deleted -l flag which are related to them.


11.02.2017 15:41, Mattia Rizzolo wrote:

dpkg-shlibdeps reports a lot of libraries that are linked but the binary
doesn't use any symbol: can you try to build with -Wl,--as-needed ?


Thank you for the helpful option. But I did not use it because I 
manually got rid of any spare libraries from linker options. And now 
dpkg-shilibdeps does not show any warnings.



In d/copyright, the Apache-2.0 license text should point to the thing in
/usr/share/common-license; it's not enough to point to an external
website, per Debian Policy everything should be available locally.


Fixed


Well, it's bullshit if you ask me; I wouldn't be particularly happy to
put my work in the public domain exactly because I don't want the
"Telegram team needs to use full Telegram Desktop source code with some
different license" as they put it.  But yep, it's right.


Okay, I do not get it. I believe it would be better if the package was 
not a frant. I mean, let the patches have the same license like the 
upstream code. Like any other package in Debian archive.



You patched Telegram/gyp/Telegram.gyp but are you sure you don't have to
also patch Telegram/gyp/telegram_linux.gypi ?  At the very least I
noticed a
-L/build/foobar/out/Release/../../../Libraries/libexif-0.6.20/libexif/.libs
in the final linking that I didn't expect to see, and there is no
libexif-dev in Build-Depends.


Don't worry, this directory (out/Release/../../../Libraries) usually 
does not exist, so I think it not an issue. I guess it does not matter 
because that option is after

-L/usr/lib/x86_64-linux-gnu/qt5/lib
-L/usr/local/lib
and other which start with -L and relate to system folders.

[1] 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.12-1.dsc

Bug#851756: RFS: telegram-desktop/1.0.6-1

[Коля Гурьев]

They really make new versions very often. But I've already built the 
package on v1.0.6 [1].


Also I fixed typo in d/copyright and wrote d/watch. (To be honest, I'd 
just copy-pasted it from uscan(1).)


I can't understand how pristine-tar works. Should I manually download 
new tarball for each new release and commit its delta into the repo?


[1] 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.6-1.dsc

Bug#851756: RFS: telegram-desktop/1.0.5-1

[Коля Гурьев]

Control: retitle -1 RFS: telegram-desktop/1.0.5-1

31.01.2017 12:07, Mattia Rizzolo пишет:

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).


Thanks, I changed d/gbp.conf, and now they seems identical.


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.


gyp defines _DEBUG macro in Debug build. And then TG Desktop stores its 
settings in independent directory, -debug flag is ignored (the program 
always writes logs), and LTO optimization is disabled in compile-time. 
NDEBUG macro is defined in Release build, but it is not used.



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.


When I tried to print Qt library path inside special test program, it 
looked fine. But when I printed it inside main function (at the very 
beginning) of Telegram Desktop, it was empty. I think a global object 
changes this path inside its constructor. I will explore this issue.



Question: why don't you also name the icons telegram-desktop, as you
name the binary and the WMClass?


Their binary creates the icon just named telegram. Also I believe it 
really makes sense, because there is Telegram logo on this icon, not 
only Telegram Desktop.



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.



I examined upstream source and tried to extract all copyrights, so I 
rewrote d/copyright.
According to their contributing policy [1], I put my patches into public 
domain. Is it right?



New stable version was released yesterday. So I have fixed your remarks 
and have built the new package [2]. At the same time, I had added the 
manpage. I had written it in markdown (I like this markup language), and 
had supplemented d/rules to build the manual in nroff format.


Furthermore, I registered new core application for obtaining api_id to 
avoid potential API issues which are described on [3].


[1] 
https://github.com/telegramdesktop/tdesktop/blob/master/.github/CONTRIBUTING.md#sign-your-work
[2] 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.5-1.dsc
[3] 
https://core.telegram.org/api/obtaining_api_id#using-telegram-39s-open-source-code

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-langua

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Коля Гурьев]

19.01.2017 00:23, Gianfranco Costamagna пишет:

I see tag for 1.0.1 pushed on github [1]


This is alpha version. It is not in upstream changelog on [1].

To be noted upstream author does not always publish the tags in time.

P.S.: I don't know how to put this remote changelog into the package.

[1] https://desktop.telegram.org/changelog

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Коля Гурьев]

I already fixed a few things: debian/changelog, the list of build 
dependencies. My fork on Github is specified temporally in 
debian/control. I just don't know a more appropriate value for this 
field at the moment.


I've putted the current changes back to [1].

I would appreciate your advice about my debian/rules. What can I improve it?

[1] 
https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-1.dsc


18.01.2017 19:05, Mattia Rizzolo пишет:

Now, I usually don't sponsor NEW packages for new people without a
record of past contributions to Debian, as I don't trust them to stick
around and actually maintain the package), but I'm inclined to make an
exception to this rule of mine on the basis that I'd love to have this
package for myself (but be aware, I really expct the package to be
maintained…).


I will do my best for that.

By the way, this is my nickname in Telegram: https://t.me/mymedia

18.01.2017 19:22, Andrey Rahmatullin пишет:

Why is it in contrib?


From what I understand, there are packages with dependencies on 
non-free software in contrib section. This program does not work if 
Telegram server is stopped for any reason. But this server is 
proprietary, more accurately, it does not even distribute in public. So 
I thought the package has to be in contrib.  Correct me, please, if I am 
wrong.

Bug#851756: RFS: telegram-desktop/1.0.0-2

[Коля Гурьев]

Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "telegram-desktop"

 * Package name: telegram-desktop
   Version : 1.0.0-2~rc2
   Upstream Author : John Preston 
 * URL : https://desktop.telegram.org/
 * License : GPLv3
   Section : net

  It builds those binary packages:

telegram-desktop - official telegram messaging app

  To access further information about this package, please visit the 
following URL:


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


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

dget -x 
https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc


  More information about hello can be obtained from 
https://www.example.com.


  Changes since the last upload:

  * Fixed restart when choosing language
  * Made x32 build, but only inside chroot jail
  * Updated README for Debian
  * Renamed binary
  * Solve command-in-menu-file-and-desktop-file problem, fix icon links
  * Solve binary-or-shlib-defines-rpath lintian error
  * Initial build (Closes: #767418)

  Regards,
   Nicholas Guriev