Bug#947368: binNMU: build dependents of doxygen-latex

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

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: 947...@bugs.debian.org

On August 23th, ghostscript 9.28 went into unstable that caused issues with math
formulas in HTML documentation generated by Doxygen. Latest version 1.8.16-2 of
the doxygen package has fixed Bug#947121. Please schedule rebuilding every
package dependent on doxygen-latex at build time and that was uploaded from
August to today.

nmu caffe_1.0.0+git20180821.99bd997-4 . all . -m 'Rebuild against fixed 
doxygen-latex'
nmu coinor-csdp_6.2.0-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu coinor-dylp_1.10.4-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu fflas-ffpack_2.4.3-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu fltk1.3_1.3.4-10 . all . -m 'Rebuild against fixed doxygen-latex'
nmu freefem++_3.61.1+dfsg1-5 . all . -m 'Rebuild against fixed doxygen-latex'
nmu gdcm_3.0.4-2 . all . -m 'Rebuild against fixed doxygen-latex'
nmu givaro_4.1.1-2 . all . -m 'Rebuild against fixed doxygen-latex'
nmu gtg-trace_0.2-2+dfsg-6 . all . -m 'Rebuild against fixed doxygen-latex'
nmu gyoto_1.4.3-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu hwloc_2.1.0+dfsg-2 . all . -m 'Rebuild against fixed doxygen-latex'
nmu libdc1394-22_2.2.5-2.1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu libdc1394_2.2.6-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu libemf_1.0.11-3 . all . -m 'Rebuild against fixed doxygen-latex'
nmu librsb_1.2.0.8+dfsg.1-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu libvdpau_1.3-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu linbox_1.6.3-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu mlpack_3.2.2-2 . all . -m 'Rebuild against fixed doxygen-latex'
nmu mpich_3.3.2-2 . all . -m 'Rebuild against fixed doxygen-latex'
nmu mrpt_1:1.5.8-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu openvdb_5.2.0-7 . all . -m 'Rebuild against fixed doxygen-latex'
nmu range-v3_0.10.0-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu speech-tools_1:2.5.0-7 . all . -m 'Rebuild against fixed doxygen-latex'
nmu starpu_1.3.3+dfsg-2 . all . -m 'Rebuild against fixed doxygen-latex'
nmu uhd_3.14.1.1-1 . all . -m 'Rebuild against fixed doxygen-latex'
nmu vtk6_6.3.0+dfsg2-5 . all . -m 'Rebuild against fixed doxygen-latex'
nmu vtk7_7.1.1+dfsg2-1 . all . -m 'Rebuild against fixed doxygen-latex'

Bug#947121: reproducible

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

On Sun, 22 Dec 2019 12:11:31 +0100 Paolo Greppi  wrote:
> BTW, don't you think that such an error should be fatal for the build ?

It's really strange. If it'd been more annoying, we wouldn't have missed the
error.

However, a few broken doc packages have gotten into the main archive which have
no rendered formulas on their HTML pages. I think all packages that at least
Build-Depends on doxygen-latex and have uploaded since August 23th, when
ghostscript 9.28 was introduced, should be rebuilt against updated doxygen.

Bug#943499: telegram-desktop: Disable building in big endian archs

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

tags 943499 patch
stop

25.10.2019 17:12, Lisandro Damián Nicanor Pérez Meyer пишет:
> A removal for those archs has been asked in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943467 but
> ideally the package should list the architectures it builds instead of being 
> Arch: any. This will not
> waste buildds' time and also provide a clearer insight to people looking for 
> this app in their archs.

I agree with you, but dpkg does not seem to provide an easy way to
express such assertion that the package works only on little-endian
architectures.

I tried to just list[1] all possible CPUs in the Architecture field, but
I do not understand its syntax. It looks like line breaks or comments
are not allowed.

 [1]: 
https://salsa.debian.org/debian/telegram-desktop/commit/c22fa4f7cfb3105f3c9889d5342ff7aeeef68157

Below is a copy of the commit.

commit c22fa4f7cfb3105f3c9889d5342ff7aeeef68157
Author: Nicholas Guriev 
Date:   Tue Oct 22 09:10:07 2019 +0300

Restrict supported architectures

diff --git a/debian/control b/debian/control
index 4fd34d9..ba7a6ec 100644
--- a/debian/control
+++ b/debian/control
@@ -35,7 +35,9 @@ Vcs-Git: https://salsa.debian.org/debian/telegram-desktop.git
 Vcs-Browser: https://salsa.debian.org/debian/telegram-desktop
 
 Package: telegram-desktop
-Architecture: any
+# Only little endian is supported. Cmd:
+# awk '/^\s*[^#]/ && $5 == "little" {print $1}' ../dpkg-1.19.7/data/cputable
+Architecture: i386 ia64 alpha amd64 arm arm64 mipsel mipsr6el mips64el 
mips64r6el nios2 powerpcel ppc64el riscv64 sh3 sh4 tilegx
 Depends: qt5-image-formats-plugins (>=5.5), ${misc:Depends}, ${shlibs:Depends}
 Recommends: fonts-open-sans
 Built-Using: ${cpplibs:Built-Using}

Bug#940938: telegram-desktop: Could not start Telegram Desktop!

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

Severity: minor
Tags: moreinfo

Hi!

22.09.2019 12:41, Utkarsh Gupta пишет:
> [2019.09.22 15:07:08] FATAL: Could not move logging to 
> '/home/utkarsh2102/.local/share/TelegramDesktop/log.txt'!

Please check that Telegram can write to this file, especially that it
isn't immutable. See lsattr(1), flag 'i'.

Telegram Desktop needs its working directory to be fully accessible
under your EUID. I'd recommend you to remove the ~/.local/share/TelegramDesktop
directory (this will drop your current Telegram session) and then start
telegram-desktop as unprivileged user, without sudo.

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#934440: [telegram-desktop] New version available (1.8.1)

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

merge 934440 932457
stop

The new update for v1.8.1 has been ready[1] yesterday. It requires
rlottie[2] as dependency which is still in the NEW queue. As soon as the
library goes into the archive, we'll upload telegram-desktop right away.

 [1]: https://salsa.debian.org/debian/telegram-desktop/tree/mymedia/next
 [2]: https://salsa.debian.org/debian/rlottie

Bug#931832: If you need sponsoring please talk to me

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

26.07.2019 13:26, Andreas Tille пишет:
> I do not know who else is working on the repository but I consider it
> overly complex to have several branches and the one with debian in the
> name not containing any debian/ folder.  I wished people would maintain
> some kind of default repository layout to let others immediately know
> what might be happening.

Even if one person is working on the package, it makes sense to use
isolated feature branches. In this case code review is possible, and Git
history is more transparent.

The rlottie package isn't released yet, and so the debian/master branch
is empty. Once the package gets uploaded, its relevant code will be
merged into the main branch.

> I confirm that I also get 
> 
> gbp:error: Error creating rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz: 
> Pristine-tar couldn't checkout 
> "rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz": xdelta: expected from file 
> (/tmp/pristine-tar.UVXpmzNnnT/recreatetarball) of length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.UVXpmzNnnT/recreatetarball) of 
> length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.vZRVhMOe2a/recreatetarball) of 
> length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.LB2mLbYQva/recreatetarball) of 
> length 12779520 bytes
> xdelta: expected from file (/tmp/pristine-tar.LB2mLbYQva/recreatetarball) of 
> length 12779520 bytes
> pristine-tar: Failed to reproduce original tarball. Please file a bug report.

I've already reported this Bug#933031.

> Upstream is meanwhile at 0~git20190725.d07040d .

I see. I had been starting to work on the package last Friday before the
upstream library got this update. Give me some time to stabilize code
base. Please be patient.

Bug#931832: If you need sponsoring please talk to me

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

25.07.2019 23:20, Andreas Tille пишет:
> Unfortunately I can not find a debian/ dir in the debian/master branch.
> Please explain your Git layout and how I can build it using gbp if you
> want to be sponsored.

My current work is in personal branch mymedia/master. See discussion under MR!1

https://salsa.debian.org/debian/rlottie/merge_requests/1

In fact, two difficulties remain.

1. A confirmation of fix of corrupted orig tarball is required.
2. I have to do something about the Lintian 
debian-watch-file-should-mangle-version
   warning. Either I ignore it as false-positive, or I really must add
   the dversionmangle option if it affects something. I'm not 100% sure.

Bug#933031: pristine-tar: unable to unpack some deltas of version 2

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

Package: pristine-tar
Version: 1.46
Severity: important

pristine-tar of version 1.46 available in Debian Unstable can't unpack
deltas of versions 2 generated by pristine-tar 1.33 from Ubuntu Xenial.

I've committed a tarball for the rlottie package into my Git repository
using pristine-tar 1.33. Then I try to regenerate the tarball inside
Debian chroot and get the next error.

$ pristine-tar --debug --verbose checkout 
../rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz
pristine-tar: git archive --format=tar 9fed0d3da5cfa7eabd4fa8c2590dd86e5b1442e1 
| (cd '/tmp/pristine-tar.2a5pcCDc3n' && tar x)
pristine-tar: tar xf /tmp/pristine-tar.cBbx8nKDp6/tmpin -C 
/tmp/pristine-tar.Dvxlxlx8Qn
pristine-tar: set subdir to rlottie
pristine-tar: subdir is rlottie
pristine-tar: mkdir /tmp/pristine-tar.o0lKEjWozz/workdir
pristine-tar: mv /tmp/pristine-tar.2a5pcCDc3n 
/tmp/pristine-tar.o0lKEjWozz/workdir/rlottie
pristine-tar: rlottie/example/resource/360\302\272_degree.json is listed in the 
manifest but may not be present in the source directory
pristine-tar: creating missing rlottie/example/resource/360\302\272_degree.json
pristine-tar: doing full tree sweep to catch missing files
pristine-tar: tar cf /tmp/pristine-tar.o0lKEjWozz/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.o0lKEjWozz/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.o0lKEjWozz/manifest
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.o0lKEjWozz/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.o0lKEjWozz/recreatetarball) of 
length 12779520 bytes
pristine-tar: tar cf /tmp/pristine-tar.o0lKEjWozz/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.o0lKEjWozz/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.o0lKEjWozz/manifest
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.o0lKEjWozz/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.o0lKEjWozz/recreatetarball) of 
length 12779520 bytes
pristine-tar: set subdir to rlottie
pristine-tar: subdir is rlottie
pristine-tar: mkdir /tmp/pristine-tar.4XNCSF8pDG/workdir
pristine-tar: mv /tmp/pristine-tar.o0lKEjWozz/workdir/rlottie 
/tmp/pristine-tar.4XNCSF8pDG/workdir/rlottie
pristine-tar: tar cf /tmp/pristine-tar.4XNCSF8pDG/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.4XNCSF8pDG/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.4XNCSF8pDG/manifest -H gnu
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.4XNCSF8pDG/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.4XNCSF8pDG/recreatetarball) of 
length 12779520 bytes
pristine-tar: set subdir to rlottie
pristine-tar: subdir is rlottie
pristine-tar: mkdir /tmp/pristine-tar.SY9ZY0yfKg/workdir
pristine-tar: mv /tmp/pristine-tar.4XNCSF8pDG/workdir/rlottie 
/tmp/pristine-tar.SY9ZY0yfKg/workdir/rlottie
pristine-tar: tar cf /tmp/pristine-tar.SY9ZY0yfKg/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.SY9ZY0yfKg/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.SY9ZY0yfKg/manifest -H posix
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball) of 
length 12779520 bytes
pristine-tar: tar cf /tmp/pristine-tar.SY9ZY0yfKg/recreatetarball --owner 0 
--group 0 --numeric-owner -C /tmp/pristine-tar.SY9ZY0yfKg/workdir 
--no-recursion --mode 0644 --verbatim-files-from --files-from 
/tmp/pristine-tar.SY9ZY0yfKg/manifest
pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball 
/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
xdelta: expected from file (/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball) of 
length 12779520 bytes
pristine-tar: Failed to reproduce original tarball. Please file a bug report.
pristine-tar: failed to generate tarball

You'll find problematic delta in the repository of the rlottie package
under the mymedia/weird-delta tag. Steps to reproduce:

git clone https://salsa.debian.org/debian/rlottie.git
git branch pristine-tar mymedia/weird-delta
pristine-tar checkout ../rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz

Here is version numbers of dependencies of both programs.

Name Version  Architecture Description

Bug#931750: telegram-desktop: Packace uninstallable due to alleged lack of dependency

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

It happens because you've installed some packages from the experimental
repository where Telegram Desktop was built against Qt 5.11.3. Now you
have to downgrade version of libqt5core5a. Install it from stable repo,
for example.

Also I would recommend you to decrease priority of the experimental
repository.

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#927711: CVE-2019-10044

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

Hi,

09.05.2019 23:42, Moritz Mühlenhoff пишет:
> What's the status? Has upstream been contacted for an isolated fix, are
> you planning to address this for buster?


As John Preston said, there was no a special fix of the issue in 1.5.12.
It is mistake that this version is considered to contain the fix.
And as far as I can see, Telegram Desktop has no a fix of this CVE yet.

At least some code[1] in HistoryWebPage checks for hidden URLs. But it
does not always work properly. For example, it shows a confirmation
for https://www.аррӏе.com/ (https://www.xn--80ak6aa92e.com/) but not
for http://blаzeinfosec.com (http://xn--blzeinfosec-zij.com).

 [1]: 
https://sources.debian.org/src/telegram-desktop/1.5.11-1/Telegram/SourceFiles/history/media/history_media_web_page.cpp/#L133

Bug#926218: range-v3: FTBFS with gcc 8.3

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

Alexis Murzeau, thank you very much for the investigation. Then we can
ignore that warning in a good conscience. To avoid "unrecognized command
line option" errors, I've rewritten the ranges_append_flag macro used by CMake.

Bug#926218: range-v3: FTBFS with gcc 8.3

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

Control: forwarded -1 https://github.com/ericniebler/range-v3/issues/856

Hi!

Thank you for the report! Which hardware architecture do you use to
build the package?

There is something similar in upstream bug tracker.

Bug#920851: gyp: OS variable on non-Linux systems

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

Package: gyp
Version: 0.1+20180428git4d467626-2
Severity: minor

I have a simple test consisting of two files (see attachments). As you
can see, it sets the GYP_OS_VAL macro equal to the value of the OS
predefined variable, and the main.cpp file prints this value to stdout.
In that way I examined the initial value of the OS variable set by gyp.
But I am puzzled by the results on kFreeBSD, the Debian port, and on
GNU/Hurd. The variable contains a string "linux". Which I think is not
quite correct as these systems have no connection with the Linux kernel
and sometimes require special handling.

Below I am showing what I have gotten on kFreeBSD.

$ uname -a
GNU/kFreeBSD nola 9.0-2-686 #0 Sun May 17 22:06:56 UTC 2015 i386 i386 
Intel(R) Core(TM) i3-6006U CPU @ 2.00GHz GNU/kFreeBSD
$ gyp --no-parallel --depth .
$ make
CC(target) out/Default/obj.target/ttt/main.o
LINK(target) out/Default/ttt
$ out/Default/ttt
GYP_OS_VAL=linux

And here is what happened on GNU/Hurd.

$ uname -a
GNU debian 0.9 GNU-Mach 1.8+git20190109-486/Hurd-0.9 i686-AT386 GNU
$ gyp --no-parallel --depth .
$ make
CC(target) out/Default/obj.target/ttt/main.o
LINK(target) out/Default/ttt
$ out/Default/ttt
GYP_OS_VAL=linux

Please provide a built-in mechanism to distinguish Linux as target
system from kFreeBSD or GNU/Hurd.
#include 
int main()
{
  printf("GYP_OS_VAL=%s\n", GYP_OS_VAL);
  return 0;
}
{
  'targets': [
{
  'target_name': 'ttt',
  'type': 'executable',
  'defines': [
'GYP_OS_VAL="<(OS)"',
  ],
  'sources': [
'main.c',
  ],
},
  ],
}

Bug#884539: fbxkb: does not explain how to add new keyboards

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

Control: tags -1 moreinfo

Left click on flag switches to the next keyboard layout. To configure
available layouts, use setxkbmap tool. For example the following command
will allow you to switch between US and French layouts by Caps Lock key.

setxkbmap us,fr -option grp:caps_toggle

fbxkb is a pretty simple program. Its primary purpose is to display
current keyboard layout, nothing more.

So what is your question?

Bug#918667: Fwd: Bug#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?

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

09.01.2019 14:40, bret curtis пишет:
> what happens if you use -lsndio when you compile? This is just out of 
> curiosity.

$ cc openal-example.o -o openal-example -lopenal -lalut -lsndio
/usr/bin/ld: cannot find -lsndio
collect2: error: ld returned 1 exit status

The libsndio-dev package is not installed into a system as it is not
listed as a dependency of libopenal-dev.

Bug#918667: Fwd: Bug#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?

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

I'm sending the message again, it seems the previous one hasn't reached 
bugs.d.o.


 Forwarded Message 
Subject: Re: Bug#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?
Date: Wed, 9 Jan 2019 22:37:35 +0300
From: Коля Гурьев 
To: bret curtis 

09.01.2019 14:40, bret curtis пишет:
> what happens if you use -lsndio when you compile? This is just out of 
> curiosity.

$ cc openal-example.o -o openal-example -lopenal -lalut -lsndio
/usr/bin/ld: cannot find -lsndio
collect2: error: ld returned 1 exit status

The libsndio-dev package is not installed into a system as it is not
listed as a dependency of libopenal-dev.

Bug#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?

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

I'm sending the message again, it seems the previous one hasn't reached 
bugs.d.o.


 Forwarded Message 
Subject: Re: Bug#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?
Date: Wed, 9 Jan 2019 22:37:35 +0300
From: Коля Гурьев 
To: bret curtis 

09.01.2019 14:40, bret curtis пишет:
> what happens if you use -lsndio when you compile? This is just out of 
> curiosity.

$ cc openal-example.o -o openal-example -lopenal -lalut -lsndio
/usr/bin/ld: cannot find -lsndio
collect2: error: ld returned 1 exit status

The libsndio-dev package is not installed into a system as it is not
listed as a dependency of libopenal-dev.

Bug#918667: libopenal-dev on kFreeBSD: missing dependency libsndio?

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

Package: libopenal-dev
Version: 1:1.19.1-1
Control: affects -1 telegram-desktop

I try to build a simple example[1] found on the world wide web. It
requires libalut or libaudio. And it uses no any header or function of
libsndio, but I get the following error.

cc openal-example.o -o openal-example -lopenal -lalut
/usr/bin/ld: warning: libsndio.so, needed by 
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so, not 
found (try using -rpath or -rpath-link)
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_getpar'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_write'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_setpar'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_close'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_read'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_initpar'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_stop'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_open'
/usr/lib/gcc/i686-kfreebsd-gnu/6/../../../i386-kfreebsd-gnu/libopenal.so: 
undefined reference to `sio_start'
collect2: error: ld returned 1 exit status

The issue affects also telegram-desktop on kfreebsd-amd64[2].

 [1]: https://github.com/ffainelli/openal-example
 [2]: 
https://buildd.debian.org/status/fetch.php?pkg=telegram-desktop=kfreebsd-amd64=1.5.4-1=1546785287=0

Bug#917315: libtgvoip: FTBFS on several arches (i386, mips, ppc64el, s390x) after recent upload

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

There are at least three different issues. The first thing you mentioned
relates to SSE2 extension on i386 and already has a fix[1] in Git. The
second one because of the lack of release architectures in files
webrtc_dsp/rtc_base/system/arch.h and webrtc_dsp/typedefs.h. Actually,
those lists need to be extended. The third issue is caused by system
headers on GNU/Hurd and kFreeBSD.

 [1]: 
https://salsa.debian.org/debian/libtgvoip/commit/5bb9a8bdf260b528f589bd83400ade1476c94702

Bug#915975: please package and release new version of telegram desktop version 1.4.8

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

Control: retitle -1 please package and release new version of telegram desktop 
version 1.5.2
Control: tag -1 pending

John Preston has released a new version of Telegram Desktop last week.
Now a merge request[1] with update is under review. And I hope it will
be uploaded soon.

 [1]: https://salsa.debian.org/debian/telegram-desktop/merge_requests/5

Bug#915975: please package and release new version of telegram desktop version 1.4.8

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

Hi,

09.12.2018 01:20, shirish शिरीष пишет:
> Please package and release new version fo telegram-desktop v 1.4.8 .

This is pre-release version of Telegram Desktop and won't be packaged, sorry.

> Also your watchfile needs to be tweaked it seems, see
> https://github.com/telegramdesktop/tdesktop/releases while at t.d.o.
> it says that the latest is 1.4.3 which is obviously wrong.

No, it's correct. 1.4.3 is the latest version available on
desktop.telegram.org. But in changelog[1] only 1.4.0 is mentioned.

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

Bug#365427: Autotests for apt-build utility

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

I intend to do some refactoring of apt-build, but first I'd like to
write autopkgtests for the package. I have two versions of a simple test
case for install command, and I still can't decide what language use for
tests. In attachment you'll find two identical scripts in Bash and Perl.
Comments are welcome!

It'd be good to write full tests before new year and buster freeze.

To be clear: I'm not going to adopt the package yet, because I'm unsure
that I have enough time for this work.



install.pl
Description: Perl program


install.sh
Description: application/shellscript

Bug#907595: debhelper: Support of terse flag in DEB_BUILD_OPTIONS

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

tag 907595 patch
tag 907738 patch
stop

01.09.2018 10:18, Niels Thykier пишет:
> clone 907595 -1
> retitle -1 debhelper: Make DH_QUIET apply to cmake build system
> 
...
> 
> This looks like two small bite-sized independent changes that could be
> easy takings for prospective new contributors to debhelper.  I have
> tagged and cloned the bug accordingly.

My changes turned quite interlinked, so my merge request[1] attempts to
close two these bugs. And I think it's impractical to have two different
bug number for such changes.

 [1]: https://salsa.debian.org/debian/debhelper/merge_requests/9

Bug#907595: debhelper: Support of terse flag in DEB_BUILD_OPTIONS

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

Package: debhelper
Version: 11.3.5
Severity: wishlist

The cmake build system always passes the -DCMAKE_VERBOSE_MAKEFILE=ON
option even if the DEB_BUILD_OPTIONS contains the terse tag. The tag
means that build process should produce less output than usual[1].

Also somehow the DH_QUIET environment variable does not affect verbosity
of Makefile.

 [1]: Debian Policy Manual, P. 4.9.1

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#905822: telegram-desktop: Problems with sound and sending audio

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

Hi,

10.08.2018 10:49, Diego Herchhoren пишет:
> I just installed telegram-desktop on my Strecht System.

>From which source did you install the program? From Telegram Desktop
site[1] or from backports Debian repository?

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

Bug#904133: t-d ftbfs with memory exhaustion on many targets

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

Hi,

20.07.2018 14:38, Matthias Klose пишет:
> the package ftbfs at least on armel, and mips* in Debian

It failed to build due to a missing linker option, -latomic. The fix is
already available[1], but an issue is that the option may add an
unneeded dependency.

> Did you make any measurements how much better the code is with -flto?  I'm
> unsure if it's worth the trouble for a desktop application.

Deactivation of LTO leads to more memory consumption during compilation.
At least at my laptop building process without -flto requires 5.81 GB of
virtual memory, takes two and a half hours and produces a binary of
29.7 MB size. In current state, building of the package requires 4.97 GB
of virtual memory, takes about one hour and produces a binary of 23.2 MB
size. To be honest, I have the laptop with 4 GB of RAM, so such a long
time in the first case is understandable. Obviously, without LTO,
results are less good, but we can try to disable link-time optimizations
as an experiment.

 [1]: 
https://salsa.debian.org/debian/telegram-desktop/commit/d922c6628f2ee56bf3e896db64f20c41352d8246

Bug#898414: Please switch to using Ayatana AppIndicator for system tray icon

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

Hi,

Thank you for the patch of Telegram Desktop for Ayatana Indicators.

It makes sense to leave loading of the old Ubuntu AppIndicator for
backward compatibility. And in such form, the patch is likely to be
applied upstream. They still support Ubuntu 12.04.

I think we could try to load libayatana-appindicator, and then, in case
of error, try libappindicator.

--- a/Telegram/SourceFiles/platform/linux/linux_libs.cpp
+++ b/Telegram/SourceFiles/platform/linux/linux_libs.cpp
@@ -234,14 +234,14 @@ void start() {
 	bool gtkLoaded = false;
 	bool indicatorLoaded = false;
 	QLibrary lib_gtk, lib_indicator;
-	if (loadLibrary(lib_indicator, "appindicator3", 1)) {
+	if (loadLibrary(lib_indicator, "ayatana-appindicator3", 1) || loadLibrary(lib_indicator, "appindicator3", 1)) {
 		if (loadLibrary(lib_gtk, "gtk-3", 0)) {
 			gtkLoaded = setupGtkBase(lib_gtk);
 			indicatorLoaded = setupAppIndicator(lib_indicator);
 		}
 	}
 	if (!gtkLoaded || !indicatorLoaded) {
-		if (loadLibrary(lib_indicator, "appindicator", 1)) {
+		if (loadLibrary(lib_indicator, "ayatana-appindicator", 1) || loadLibrary(lib_indicator, "appindicator", 1)) {
 			if (loadLibrary(lib_gtk, "gtk-x11-2.0", 0)) {
 gtkLoaded = indicatorLoaded = false;
 gtkLoaded = setupGtkBase(lib_gtk);

Bug#898813: telegram-desktop: URI passed to the client via command line is ignored

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

Hello,

16.05.2018 08:05, Alexander Kernozhitsky пишет:
> According to `man telegram-desktop` output:
> 
> telegram-desktop [-startintray] [-many] [-debug] [-- URI]
> 
> we can pass an URI to open a specified chat or a channel inside the 
> application.
> But it seems that the passed URI is ignored. I looked into the code and
> noticed that it is parsed by the command line options parser, but is
> used nowhere else in the code.

Here it means a user can pass a URI within tg scheme. For example:

$ telegram-desktop -- tg://resolve?domain=mymedia

This is exactly the same links used on t.me site for instant open
Telegram client.

Bug#893554: range-v3 FTBFS

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

Hi,

19.03.2018 23:54, Adrian Bunk пишет:
> Some recent change in unstable makes range-v3 FTBFS:
> 
> https://tests.reproducible-builds.org/debian/history/range-v3.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/range-v3.html

I can't reproduce these errors with gcc 7.3.0-15 or above. That version
has fixed a bug[1] related to similar errors.

Could you please rebuild the range-v3 package by yourself and tell about
compilation results against the latest gcc-7 package?

 [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85118

Bug#892548: dhelp: /usr/sbin/dhelp_parse broken with ruby 2.5

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

tags 892548 - unreproducible
reassign 892548 libruby2.5
forcemerge 892099 892548
stop

It appears the bug with very similar issue was fixed in the libruby2.5
package so I merge these bugs. If your error still exists, let us know.

Bug#892548: dhelp: /usr/sbin/dhelp_parse broken with ruby 2.5

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

Control: tag -1 unreproducible

Unfortunately, I can't reproduce this error. However, I've faced the
other error related to dhelp's cron script. It fails to build a document
index, and so search doesn't work. But at least the dhelp_parse utility
can rebuild its documentation directory, and a home page is still
available. It seems some of the next warnings aren't linked to dhelp.

But these issues are already reported, see Bug#803342 and Bug#889651.

(dhelp)root@barberry:/# sh -x /etc/cron.weekly/dhelp
+ [ -d /var/lib/dhelp ]
+ [ -x /usr/sbin/dhelp_parse ]
+ [ -x /usr/bin/index++ ]
+ rm --force /var/lib/dhelp/documents.index
+ /usr/sbin/dhelp_parse -r
/usr/lib/ruby/vendor_ruby/debian.rb:223: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:224: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:227: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:230: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:233: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:236: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:348: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:557: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:577: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:578: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:743: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:753: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:763: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:772: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:799: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:1004: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
+ /usr/sbin/dhelp_parse -i
/usr/lib/ruby/vendor_ruby/debian.rb:223: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:224: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:227: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:230: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:233: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:236: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:348: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:557: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:577: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:578: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:743: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:753: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:763: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:772: warning: parentheses after
method name is interpreted as an argument list, not a decomposed argument
/usr/lib/ruby/vendor_ruby/debian.rb:799: warning: 

Bug#893540: telegram-desktop: Fails to build with Qt 5.10

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

Hi,

To build the package in chroot, mount /dev/shm directory using the next
command:

sudo mount --bind /dev/shm /path/to/chroot/dev/shm

I hope this will fix the configuring error.

Bug#887010: telegram-desktop segfaults on debian buster (amd64) using Gnome3

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

Control: severity -1 important

Please send Telegram logs from the ~/.local/share/TelegramDesktop/log.txt
file to debug this crash.

31.01.2018 12:34, Robin Mueller-Bady пишет:
> Setting XDG_CURRENT_DESKTOP to NONE works fine all the time. If it is not 
> set, Telegram
> won't start at all due to a SIGSEV. In both ways completely deterministic :-)

If so and the program works (in any way), the bug should have important
or normal severity because a workaround is found.

Bug#887010: telegram-desktop segfaults on debian buster (amd64) using Gnome3

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

Hi,

12.01.2018 16:31, Robin пишет:
> Versions of packages telegram-desktop depends on:
...
> pn  libtgvoip1.0 

It seems you have no installed package with libtgvoip. This may have led
to such crash.

> Setting the environment variabel 'XDG_CURRENT_DESKTOP' to 'NONE' solves the
> issue temporarily.

Does I understand correctly, Telegram works fine *some time* and then
crashes? This may be related to an incoming call that cannot be handle
properly without libtgvoip, and it's unlikely affected by the
XDG_CURRENT_DESKTOP environment variable.

Bug#888679: telegram-desktop: unused build-dependency on dee?

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

Control: forwarded -1 https://github.com/telegramdesktop/tdesktop/pull/4368

Telegram Desktop really works as usual even without libdee. Thank you
for calling attention to it. The fix will be uploaded shortly as all
other comments will be corrected.

Bug#885459: telegram-desktop: FTCBFS on all architectures

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

Hello,

27.12.2017 15:16, Boyuan Yang пишет:
> Package telegram-desktop FTCBFS on all architecture according to buildd
> logs[1].
> 
> There are all kinds of reasons about build failures across different
> architectures, including cc1plus internal compiler error, timeout, vmem
> exhaustion, etc.
> 
> Please investigate into this issue. I'm not sure what we can do, perhaps
> the best plan is to force non-parallel compilation (instead of make -j4
> or whatsoever on buildds).

I already found a fix[1] for memory exhaustion by GCC. If we look at a
file where the RPL_CONSUMER_TYPE_ERASED_ALWAYS macro is used[2], we
discover that the replacement of the auto keyword with more specific
type solves the problem.

But unfortunately there is another issue with linking on all
architectures except for amd64 and i386. Once a solution is found, I'll
prepare a new version of the package.

That's example of the error:

obj.target/liblinux_glibc_wraps.a(linux_glibc_wraps_64.o): In
function `__wrap_clock_gettime':

./obj-powerpc64le-linux-gnu/./Telegram/SourceFiles/platform/linux/linux_glibc_wraps_64.c:27:
undefined reference to `clock_gettime@GLIBC_2.2.5'
/usr/bin/ld: Telegram: No symbol version section for versioned
symbol `clock_gettime@GLIBC_2.2.5'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status

I don't think that non-parallel build let us avoid the errors.

 [1]:
https://anonscm.debian.org/git/collab-maint/telegram-desktop.git/commit/?id=4dc4aadc8497a996f91d75fa7d8b64884cf8b54c
 [2]:
https://anonscm.debian.org/git/collab-maint/telegram-desktop.git/tree/Telegram/SourceFiles/rpl/consumer.h?id=4dc4aadc8497a996f91d75fa7d8b64884cf8b54c#n629

Bug#883634: telegram-desktop: Segmentation fault

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

Hello!

06.12.2017 03:21, Jiaxun Yang пишет:
> There is a segmentation fault happened during the start of telegram-desktop:
> 
> QApplication: invalid style override passed, ignoring it.
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: cannot register
> existing type 'GdkDisplayManager'
> 
> (telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
> 'result != 0' failed
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
> failed
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: invalid (NULL) pointer
> instance
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: invalid (NULL) pointer
> instance
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> 
> (telegram-desktop:1827): GLib-GObject-WARNING **: cannot register
> existing type 'GdkDisplay'
> 
> (telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
> 'result != 0' failed
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_type_register_static: assertion 'parent_type > 0' failed
> 
> (telegram-desktop:1827): GLib-CRITICAL **: g_once_init_leave: assertion
> 'result != 0' failed
> 
> (telegram-desktop:1827): GLib-GObject-CRITICAL **:
> g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
> failed

This is very similar to Bug#859172.

> Versions of packages telegram-desktop recommends:
> ii  libappindicator1  0.4.92-5

Try to install the libappindicator3-1 package instead (or in addition
to) already installed libappindicator1.

Bug#883235: ITP: range-v3 -- range library for C++11/14/17

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

Package: wnpp
Severity: wishlist
Owner: !

* Package name: range-v3
  Version : 0.3.0
  Upstream Author : Eric Niebler 
* URL : https://github.com/ericniebler/range-v3
* License : Boost
  Programming Lang: C++
  Description : range library for C++11/14/17

This is a dependency for a forthcoming version of the telegram-desktop
package.

Bug#877747: xdg-utils: Suggests: gvfs-bin, which contains only deprecated tools

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

Yeah, it should be really fixed in a new upstream version. Xdg-utils
already supports that GNOME tool. I hope this feature will be in a next
upload. See others commits and a merge in my Git branch.

09.10.2017 06:02, Paul Wise пишет:
> This patch definitely is not enough to fix this issue, need this too:
> 
> https://anonscm.debian.org/git/collab-maint/xdg-utils.git/commit/?h=mymedia/temporary=0d6eebb27c562e8644ccf616ebdbddf82d0d2dd8

Bug#877747: xdg-utils: Suggests: gvfs-bin, which contains only deprecated tools

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

Control: tag -1 pending

https://anonscm.debian.org/git/collab-maint/xdg-utils.git/commit/?id=c593722ef4d6cd24a9d4d427b4db02990c40517c

Bug#865210: xdg-utils: New upstream version

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

forwarded 865210 https://bugs.freedesktop.org/show_bug.cgi?id=101640
stop

Hi,

In the latest upstream version, autotests are faulty. Therefore, I
believe we have to refrain from updating the package right now.

I provided a patch[1] to fix some kind of errors, but I'd like to wait
for review from upstream authors.

I've put the link to an upstream bug in the tests into forwarded field
to track changes there.

 [1]: https://bugs.freedesktop.org/attachment.cgi?id=134577

Bug#876401: ITA: xdg-utils -- desktop integration utilities from freedesktop.org

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

Hi,

28.09.2017 14:58, Emilio Pozuelo Monfort пишет:
> I have approved your request to join pkg-freedesktop.
Thank you!

So I'll do as suggested by Laurent Bigonville. I'll put an email address
of the team in the Maintainer field and my name in the Uploaders list.
And then I'll be continuing my work on the package this weekend.

Bug#774590: ITA: xdg-utils -- desktop integration utilities from freedesktop.org

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

retitle 876401 ITA: xdg-utils -- desktop integration utilities from
freedesktop.org
owner 876401 !
stop

I'd like to work on this package and adopt it. First of all, it makes
sense to deal with an unreleased version from Git. Afterwards, I'll
merge a new upstream version, v1.1.2 and I'll look into a list of bugs
of the package (I didn't examine all bugs yet).

I already have some skills in packaging, but I'll be grateful for any
help; any suggestions are welcome.

Bug#873702: lintian: False positive: desktop-entry-lacks-keywords-entry

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

Hi, thank you for the fix!


diff --git a/checks/menu-format.pm b/checks/menu-format.pm
index 3de4490..be1a1c4 100644
--- a/checks/menu-format.pm
+++ b/checks/menu-format.pm
@@ -641,7 +641,7 @@ sub verify_desktop_file {
 if (!defined $vals{Icon}) {
 tag 'desktop-entry-lacks-icon-entry', $file;
 }
-if (!defined $vals{Keywords}) {
+if (!defined $vals{Keywords} && $vals{'Type'} ne 'Link') {
 tag 'desktop-entry-lacks-keywords-entry', $file;
 }
 }


But if I understand the specification properly, the Keywords field is 
forbidden not only for links (type 2 in the specification) but also for 
directories (type 3). In general, this field is allowed for applications 
(type 1). I therefore think the correct condition would be like the next.


if (!defined $vals{Keywords} && $vals{'Type'} eq 'Application') {
...
}

(I'm not familiar with Perl, and I don't know how it should look).

Bug#873701: lintian: False positive: apache2-unparsable-dependency

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

Package: lintian
Version: 2.5.52
Severity: normal
X-Debbugs-CC: debian-apa...@lists.debian.org

Dear Lintian maintainers,

It seems Lintian offers to make modifications that break work of the
a2enconf script. At least if I add `mod_` in the next line, a2enconf
fails due to a disabled module.

# Depends: php7.0

I faced this when I checked an Apache configuration[1] in my new package.
Lintian says:

W: phpliteadmin: apache2-unparsable-dependency 
etc/apache2/conf-available/phpliteadmin.conf php7.0

N:
N:The package is declaring a module dependency within an Apache
N:configuration file which does not meet the requirements. 
Dependencies
N:must be declared without paths, leading "mod_" prefix and 
without file

N:extension.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: apache2, Type: binary
N:

 [1]: 
https://anonscm.debian.org/git/collab-maint/phpliteadmin.git/tree/debian/phpliteadmin.conf?id=65a5c8cc4294ef0247e7327ceca745c4b38d69d5

Bug#873702: lintian: False positive: desktop-entry-lacks-keywords-entry

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

Package: lintian
Version: 2.5.52
Severity: normal

Dear Lintian maintainers,

The tool suggest to add a Keywords field to .desktop file which has
Type=Link, but this is not allowed by the current specification[1].

I faced it on my .desktop file[2] with an URL link. Lintian says:

I: phpliteadmin: desktop-entry-lacks-keywords-entry 
usr/share/applications/phpliteadmin.desktop

N:
N:This .desktop file does either not contain a "Keywords" entry 
or it does

N:not contain any keywords not already present in the "Name" or
N:"GenericName" entries.
N:
N:.desktop files are organized in key/value pairs (similar to 
.ini files).
N:"Keywords" is the name of the entry/key in the .desktop file 
containing

N:keywords relevant for this .desktop file.
N:
N:The desktop-file-validate tool in the desktop-file-utils 
package is

N:useful for checking the syntax of desktop entries.
N:
N:Refer to
N: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html,

N:https://bugs.debian.org/693918, and
N: 
https://wiki.gnome.org/Initiatives/GnomeGoals/DesktopFileKeywords for

N:details.
N:
N:Severity: wishlist, Certainty: certain
N:
N:Check: menu-format, Type: binary
N:

 [1]: 
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html#recognized-keys
 [2]: 
https://anonscm.debian.org/git/collab-maint/phpliteadmin.git/tree/debian/phpliteadmin.desktop?id=65a5c8cc4294ef0247e7327ceca745c4b38d69d5

Bug#873593: ITP: phpliteadmin -- web-based SQLite database admin tool

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

Package: wnpp
Severity: wishlist
Owner: Nicholas Guriev 

* Package name: phpliteadmin
  Version : 1.9.7.1
  Upstream Author : phpLiteAdmin project
* URL : https://www.phpliteadmin.org/
* License : GPL-3.0+
  Programming Lang: PHP
  Description : web-based admin tool for SQLite databases

Hello, everyone!

I'd like to package phpLiteAdmin in Debian to simplify its use. I've
started to work on packaging. I hope it will be useful as a Debian
package.

Bug#872714: telegram-desktop: Not Available

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

I don't know exactly why this error occurs. Look at Bug#872500.

20.08.2017 15:31, Mr.Mei пишет:

Package qtbase-abi-5-7-1 is not available, but is referred to by another 
package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'qtbase-abi-5-7-1' has no installation candidate

Bug#863116: libtgvoip: FTBFS on non-Linux: #error "Unsupported operating system"

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

Hello!

How does sound subsystem work in Debian on FreeBSD? It does like on
Linux? If I just add a macros for FreeBSD and Hurd, will it work? I
cannot test this right now...

22.05.2017 04:23, Aaron M. Ucko пишет:

Source: libtgvoip
Version: 0.4.1~git20170517.2ed5a50-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of libtgvoip for kfreebsd-* have been failing:

   /«PKGBUILDDIR»/audio/AudioInput.cpp:27:2: error: #error "Unsupported operating 
system"

Builds for hurd-i386 fail earlier, due to gyp bug #799356, but it
looks like they would otherwise hit the same error.  Ideally, the
build system would actually check for the availability of libasound
and libpulse.  For the time being, though, it should suffice to treat
kFreeBSD (__FreeBSD_kernel__ && __GLIBC__) and the Hurd (__gnu_hurd__)
the same as (non-Android) Linux.

Could you please take a look?

Thanks!

Bug#860510: telegram-desktop: FTBFS on mips(el): out of memory for qrc_telegram_emoji.o

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

This object file contains data from Telegram/Resources/art/emoji.webp. I
believe the better solution would be to place all resources outside a
executable binary.

I don't know how to split qrc_telegram_emoji.cpp (it's auto-generated
file) into several pieces at this moment.

18.04.2017 05:16, Aaron M. Ucko пишет:

Source: telegram-desktop
Version: 1.0.29-1
Severity: important
Justification: fails to build from source

Builds of telegram-desktop for mips and mipsel failed because the
compiler couldn't allocate enough memory to build
qrc_telegram_emoji.o:

cc1plus: out of memory allocating 245670072 bytes after a total of 46022656 
bytes (mips)

cc1plus: out of memory allocating 67108744 bytes after a total of 71057408 
bytes (mipsel)

Could you please take a look?  Would it be possible to split
qrc_telegram_emoji into more manageable compilation units?

Thanks!

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#862582: ITP: libtgvoip - VoIP library for Telegram clients

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

Package: wnpp
Severity: wishlist

Hello everybody!

I intend to make a package for this VoIP library that is used by the
new version of Telegram Desktop.

The source is available on GitHub: https://github.com/grishka/libtgvoip
This library is software in public domain, and it's distributed under
the Unlicense conditions: https://unlicense.org

Bug#861861: telegram-desktop: use locale setting

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

Control: severity -1 wishlist
Control: forwarded -1 
https://github.com/telegramdesktop/tdesktop/issues/3387

Control: tag -1 +upstream

Hello!

I think this is an upstream issue so I've forwarded this bug to them.

Bug#861251: telegram-desktop: please unset QT_QPA_PLATFORMTHEME

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

26.04.2017 17:45, Graham Inggs пишет:

Adding the following line below the 'setenv("QT_STYLE_OVERRIDE"' line
worked for me:
+unsetenv("QT_QPA_PLATFORMTHEME");


Okay, I'll add your workaround to the patch. But it seems to be worked
only in a few cases. I'm not sure, but I think there are some other
conditions affect this behavior of Telegram. Because I was able to
reproduce it on my laptop, and your solution works there. But on my
desktop computer I even cannot launch Telegram when libqt5libqgtk2
package is installed. (When appmenu-qt5 package is installed, Telegram
doesn't start but your hack works).


For which Ubuntu desktop environment did you need to setenv
QT_STYLE_OVERRIDE?  It does not seem to be set in Unity or MATE, so
removing that line from the patch had no effect for me.


I don't remember exactly. I was trying to run it on Ubuntu Devel at
January, and Telegram crashed at that time. So I'll leave the line with
QT_STYLE_OVERRIDE just in case.

I think all these problems ensue from the fact that system Qt is built
with GTK support, in contrast to Qt in Telegram upstream. Put simply, I
found -no-gtkstyle among Qt flags in .travis/build.sh file. And it'd be
great to provide the same behavior of Qt in runtime.

Bug#861410: dhelp: apache2-maintscript-helper invoked from a modified environment

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

Control: tag -1 +pending

The fix of this error is already available in git[1]. It will be in the 
next version.


But right now, you can add return statement in the begin of 
try_chconf_apache2 function in /usr/share/dhelp/maint-scripts/httpd.sh 
file on line 139. And you have to manually enable dhelp.conf Apache 
configuration file.


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

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#791770: dhelp: Depends on obsolete ruby-bdb

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

Control: owner -1 !

Please don't remove this package. I already work on patch to fix this 
bug. I think I can perform migration from a module for Berkley DB to DBM 
class from the Ruby standard library. I'm attaching my current draft. 
Now I going to write migration scripts and test them.


By the way, can I check a previously installed version of the package in 
postinst script?
=== modified file 'debian/changelog'
--- debian/changelog	2014-12-12 22:02:20 +
+++ debian/changelog	2017-04-24 20:23:36 +
@@ -1,3 +1,10 @@
+dhelp (0.6.21+nmu6ubuntu1) UNRELEASED; urgency=medium
+
+  * Migrate to a module from the standard library
+- Remove ruby-bdb dependency
+
+ -- Nicholas Guriev   Mon, 24 Apr 2017 23:21:54 +0300
+
 dhelp (0.6.21+nmu6) unstable; urgency=medium
 
   * Non-maintainer upload.

=== modified file 'debian/control'
--- debian/control	2014-05-18 13:18:39 +
+++ debian/control	2017-04-24 20:20:58 +
@@ -11,7 +11,7 @@
 Package: dhelp
 Depends: perl-modules, libtemplate-perl, libhtml-parser-perl,
  liburi-perl, liblocale-gettext-perl, libdata-page-perl,
- ruby | ruby-interpreter, ruby-bdb, ruby-debian, ruby-gettext,
+ ruby | ruby-interpreter, ruby-debian, ruby-gettext,
  doc-base, swish++, pstotext, poppler-utils, ucf (>= 0.8),
  ${misc:Depends}
 Recommends: www-browser | html2text

=== modified file 'devtools/list-dirs.rb'
--- devtools/list-dirs.rb	2012-06-12 21:50:00 +
+++ devtools/list-dirs.rb	2017-04-24 19:50:51 +
@@ -2,7 +2,7 @@
 
 path = ARGV.shift || Dhelp::DOC_DIR_DATABASE
 puts "Opening #{path}"
-ddd = Dhelp::DocDirDatabase.open(BDB::RDONLY, path)
+ddd = Dhelp::DocDirDatabase.open(DBM::READER, path)
 ddd.each do |dir, doc_id, title|
   puts "#{dir} -> #{doc_id} (#{title})"
 end

=== modified file 'lib/dhelp.rb'
--- lib/dhelp.rb	2014-05-18 13:18:39 +
+++ lib/dhelp.rb	2017-04-24 19:57:08 +
@@ -18,7 +18,7 @@
 Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 =end
 
-require 'bdb'
+require 'dbm'
 require 'pathname'
 require 'fileutils'
 
@@ -239,23 +239,18 @@
 
   # Database for doc-base directories. It contains base directories associated
   # with the corresponding doc-base doc id and the document title.
-  class DocDirDatabase < BDB::Hash
-def self.open(flags   = BDB::RDONLY,
+  class DocDirDatabase < DBM
+def self.open(flags   = DBM::READER,
   name= DOC_DIR_DATABASE,
   options = {},
   mode= 0644)
-  default_options = {"ffactor"   => 8,
- "nelem" => 1,
- "cachesize" => 5000,
- "hash"  => nil,
- "lorder"=> 0}
-  super(name, nil, flags, mode, default_options.merge(options))
+  super(name, mode, flags)
 end
 
 # Traverse entire BD, passing directory, doc_id and title of each item to
 # the block
 def each
-  super do |k,v|
+  each_pair do |k,v|
 value = DocDirDatabaseValue.new(v)
 yield DocDirDatabaseKey.new(k).dir, value.doc_id, value.title
   end
@@ -266,19 +261,19 @@
 def add(dir, doc_id, title)
   key = DocDirDatabaseKey.new(:dir => dir)
   value = DocDirDatabaseValue.new(:doc_id => doc_id, :title => title)
-  put(key.to_raw_data, value.to_raw_data)
+  self[key.to_raw_data] = value.to_raw_data
 end
 
 def include?(dir)
   key = DocDirDatabaseKey.new(:dir => dir)
-  return super(key.to_raw_data)
+  return has_key?(key.to_raw_data)
 end
 
 # Returns an array with two elements, doc_id and title, for the registered
 # doc-base document in the given directory
 def info_for_path(dir)
   key = DocDirDatabaseKey.new(:dir => dir)
-  raw_value = get(key.to_raw_data)
+  raw_value = self[key.to_raw_data]
   if raw_value.nil?
 raise KeyNotFoundError, "Can't find information for path #{dir}"
   end
@@ -448,10 +443,11 @@
 # Registers a list of doc-base documents as part of Dhelp
 def _register_docs(doc_list, user_opts={})
   register_opts = {:regenerate_index => false}.merge(user_opts)
-  open_flag = register_opts[:regenerate_index] ? (BDB::CREATE|
-  BDB::TRUNCATE) :
- BDB::CREATE
-  doc_dir_db = DocDirDatabase.open(open_flag, @doc_dir_database)
+  if register_opts[:regenerate_index]
+doc_dir_db = DocDirDatabase.open(DBM::NEWDB, @doc_dir_database)
+  else
+doc_dir_db = DocDirDatabase.open(DBM::WRCREAT, @doc_dir_database)
+  end
   index_paths = []
   doc_list.each do |doc|
 doc.formats.each do |format|

=== modified file 'test/tc_dhelpdocumentpool.rb'
--- test/tc_dhelpdocumentpool.rb	2014-05-18 13:18:39 +
+++ test/tc_dhelpdocumentpool.rb	2017-04-24 20:19:29 +
@@ -1,6 +1,7 @@
 require 'test/unit'
 require 'dhelp'
 require 'fileutils'
+require 'set'

Bug#859687: freeglut: Package freeglut 3.0

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

Hello!


thanks for a bug report. The new version of package was prepared
about a year ago. But during the test of all reverse dependencies
there were some problems (crashes).


Where can I find the new package version? What dependencies crashed? I 
tried to run a couple of random programs which depend on freeglut. 
And... they work with 3.0.0 version.

Bug#859687: freeglut: Package freeglut 3.0

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

I'd like to make the package with new upstream version. I already 
started work on my patch. But right now I have some troubles: all tests 
fail :(


The error is the same for each test:

 adt-run [04:03:07]: test build2: [---
 bash: /dev/fd/62: No such file or directory
 adt-run [04:03:08]: test build2: ---]
 adt-run [04:03:08]: test build2:  - - - - - - - - - - results - - 
- - - - - - - -

 build2   FAIL non-zero exit status 1
 adt-run [04:03:08]: test build3: preparing testbed
 ...

I run adt-run using plain chroot under root. Any ideas?

So far, I did the following modifications. Note I'm beginner and not a 
Debian Developer so this patch may contain some mistakes. But I hope 
they are very few.
>From 40c52d9c421602a032af31a27c8d30ef501ccebb Mon Sep 17 00:00:00 2001
From: Nicholas Guriev 
Date: Fri, 14 Apr 2017 03:40:26 +0300
Subject: [PATCH] New upstream version

---
 debian/changelog   |  9 +
 debian/compat  |  2 +-
 debian/control | 14 +++---
 debian/freeglut3-dev.install   |  1 +
 debian/freeglut3.install   |  2 +-
 debian/patches/03_fix_hurd.diff| 13 -
 debian/patches/06_fix_FTBFS_kFreeBSD.patch | 10 +-
 debian/patches/07_HOME-fixed-buffer.patch  | 10 +-
 debian/patches/series  |  1 -
 debian/rules   |  6 +-
 10 files changed, 26 insertions(+), 42 deletions(-)
 delete mode 100644 debian/patches/03_fix_hurd.diff

diff --git a/debian/changelog b/debian/changelog
index 9225f32..ba5b5ed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+freeglut (3.0.0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload
+  * New upstream release (closes: 859687)
+- Refresh patches, remove 03_fix_hurd.diff
+  * Bump debhelper version
+
+ -- Nicholas Guriev   Fri, 14 Apr 2017 03:05:41 +0300
+
 freeglut (2.8.1-3) unstable; urgency=medium
 
   * [1ee10b3] Update gitignore.
diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index 8bee492..d673bc0 100644
--- a/debian/control
+++ b/debian/control
@@ -3,20 +3,14 @@ Maintainer: Anton Gladky 
 Section: graphics
 Testsuite: autopkgtest
 Priority: optional
-Build-Depends: autoconf,
-   automake,
-   autotools-dev,
-   debhelper (>= 9),
-   dh-autoreconf,
+Build-Depends: cmake (>=2.8.8),
+   debhelper (>= 10),
libgl1-mesa-dev | libgl-dev,
libglu1-mesa-dev | libglu-dev,
-   libtool,
libusbhid-dev [kfreebsd-any],
libx11-dev,
-   libxext-dev,
libxi-dev,
-   libxt-dev,
-   libxxf86vm-dev [amd64 i386]
+   libxrandr-dev
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/freeglut.git
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/freeglut.git
@@ -46,8 +40,6 @@ Section: libdevel
 Depends: freeglut3 (= ${binary:Version}),
  libgl1-mesa-dev | libgl-dev,
  libglu1-mesa-dev | libglu-dev,
- libxext-dev,
- libxt-dev,
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: OpenGL Utility Toolkit development files
diff --git a/debian/freeglut3-dev.install b/debian/freeglut3-dev.install
index 78c73b8..a295728 100644
--- a/debian/freeglut3-dev.install
+++ b/debian/freeglut3-dev.install
@@ -4,3 +4,4 @@ usr/include/GL/freeglut_std.h
 usr/include/GL/glut.h
 usr/lib/*/libglut.a
 usr/lib/*/libglut.so
+usr/lib/*/pkgconfig/freeglut.pc
diff --git a/debian/freeglut3.install b/debian/freeglut3.install
index af9ec47..c165e3f 100644
--- a/debian/freeglut3.install
+++ b/debian/freeglut3.install
@@ -1,2 +1,2 @@
 usr/lib/*/libglut.so.3
-usr/lib/*/libglut.so.3.9.0
+usr/lib/*/libglut.so.3.10.0
diff --git a/debian/patches/03_fix_hurd.diff b/debian/patches/03_fix_hurd.diff
deleted file mode 100644
index 06a1dd3..000
--- a/debian/patches/03_fix_hurd.diff
+++ /dev/null
@@ -1,13 +0,0 @@
-Description: fix compilation on hurd
-
 a/src/freeglut_joystick.c
-+++ b/src/freeglut_joystick.c
-@@ -1095,6 +1095,8 @@
- joy->num_axes = joy->num_buttons = 0;
- joy->name[ 0 ] = '\0';
- 
-+i = 0;
-+
- #if TARGET_HOST_MACINTOSH
- /* XXX FIXME: get joystick name in Mac */
- 
diff --git a/debian/patches/06_fix_FTBFS_kFreeBSD.patch b/debian/patches/06_fix_FTBFS_kFreeBSD.patch
index 9fe5d2b..35e1a11 100644
--- a/debian/patches/06_fix_FTBFS_kFreeBSD.patch
+++ b/debian/patches/06_fix_FTBFS_kFreeBSD.patch
@@ -3,9 +3,9 @@ Author: Anton Gladky
 Applied-Upstream: https://svn.redports.org/gahr/graphics/freeglut/freeglut-2.8.0.diff
 Last-Update: 

Bug#859172: telegram-desktop: Segmentfault due to lack of libappindicator3-1 library dep

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

Alright then, could you send a back-trace or a core-dump again? I hope 
something changed in the new version of the package. In fact, there was 
some modification in a code where Telegram crashes.

Bug#859172: telegram-desktop: Segmentfault due to lack of libappindicator3-1 library dep

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

Boyuan, does it still occur in the latest version of the package, v1.0.29-1?

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#859057: telegram-desktop: FTBFS everywhere but x86

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

I think the best way is listing of the largest possible number of 
architectures, at least, all supported in Debian.


I have no idea how macros with CPU names are used. But macros with 
bitness, ARCH_CPU_32_BITS and ARCH_CPU_64_BITS, are used for 
optimizations in Telegram/SourceFiles/ui/animation.h file. I took info 
about bitness from Debian site or Wikipedia, I hope it doesn't contain a 
mistake.


I prepared this patch with such list. What do you make of it? Maybe 
there is a better solution?
Description: Add multi-architecture support
Author: Nicholas Guriev 
Bug: https://github.com/telegramdesktop/tdesktop/issues/3167
Bug-Debian: https://bugs.debian.org/859057
Forwarded: no
Last-Update: 2017-04-08

Index: tdesktop/Telegram/SourceFiles/config.h
===
--- tdesktop.orig/Telegram/SourceFiles/config.h
+++ tdesktop/Telegram/SourceFiles/config.h
@@ -266,7 +266,7 @@ static const char *ApiHash = "344583e457
 #endif
 
 #if Q_BYTE_ORDER == Q_BIG_ENDIAN
-#error "Only little endian is supported!"
+#warning "Be aware, only little endian is supported!"
 #endif // Q_BYTE_ORDER == Q_BIG_ENDIAN
 
 #ifndef BETA_VERSION_MACRO
Index: tdesktop/Telegram/SourceFiles/core/build_config.h
===
--- tdesktop.orig/Telegram/SourceFiles/core/build_config.h
+++ tdesktop/Telegram/SourceFiles/core/build_config.h
@@ -60,6 +60,42 @@ Copyright (c) 2014-2017 John Preston, ht
 #define ARCH_CPU_X86_FAMILY 1
 #define ARCH_CPU_X86 1
 #define ARCH_CPU_32_BITS 1
+#elif defined(_M_ALPHA) || defined(__alpha__)
+#define ARCH_CPU_ALPHA 1
+#define ARCH_CPU_64_BITS 1
+#elif defined(_M_ARM) || defined(__arm__)
+#define ARCH_CPU_ARM 1
+#define ARCH_CPU_32_BITS 1
+#elif defined(_M_ARM64) || defined(__aarch64__)
+#define ARCH_CPU_ARM 1
+#define ARCH_CPU_64_BITS 1
+#elif defined(__mips__)
+#define ARCH_CPU_MIPS 1
+#define ARCH_CPU_32_BITS 1
+#elif defined(__mips64__)
+#define ARCH_CPU_MIPS 1
+#define ARCH_CPU_64_BITS 1
+#elif defined(_M_PPC) || defined(__powerpc__)
+#define ARCH_CPU_POWERPC 1
+#define ARCH_CPU_32_BITS 1
+#elif defined(__powerpc64__)
+#define ARCH_CPU_POWERPC 1
+#define ARCH_CPU_64_BITS 1
+#elif defined(__sparc__)
+#define ARCH_CPU_SPARC 1
+#define ARCH_CPU_64_BITS 1
+#elif defined(__sh__)
+#define ARCH_CPU_SUPERH 1
+#define ARCH_CPU_32_BITS 1
+#elif defined(__s390__)
+#define ARCH_CPU_ZARCH 1
+#define ARCH_CPU_32_BITS 1
+#elif defined(__s390x__) || defined(__zarch__)
+#define ARCH_CPU_ZARCH 1
+#define ARCH_CPU_64_BITS 1
+#elif defined(__m68k__)
+#define ARCH_CPU_MOTOROLA_68K
+#define ARCH_CPU_32_BITS 1
 #else
 #error Please add support for your architecture in core/build_config.h
 #endif

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#859172: telegram-desktop: Segmentfault due to lack of libappindicator3-1 library dep

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

Thank you very much for the stack-trace and debug logs. I have come to 
understand that the crash doesn't relate to libappindicator. Telegram 
crashes when it's initializing GTK on 
Telegram/SourceFiles/platform/linux/linux_libs.cpp:109. I saw it was 
already fixed in new version [1].


Could you run their binary of v1.0.14 version [2] to confirm my guess? 
(You were already trying with v1.0.27, weren't you.) Also it'd be great 
if you try to remove libappindicator1 package, and then run 
telegram-desktop, or if you install libappindicator3-1 package and run 
Telegram. (I'm only interesting whether the program crashes again or 
not, I daresay yes, and this behavior doesn't depend on libappindicator.)


Besides you can try a workaround with GDK_BACKEND environment variable. 
Try to set it to "x11".


[1]: https://github.com/telegramdesktop/tdesktop/commit/8884cb1
[2]: https://updates.tdesktop.com/tlinux/tsetup.1.0.14.tar.xz

Bug#859172: telegram-desktop: Segmentfault due to lack of libappindicator3-1 library dep

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

Oh sorry, I'm very beginner. But I discovered nice instructions related 
to gdb: how to generate a back-trace [1], [2].


Please send your back-trace. Also try to start Telegram in debug mode 
(type `telegram-desktop -debug` in terminal) and get me logs (they can 
be found in ~/.local/share/TelegramDesktop/log*.txt and 
~/.local/share/TelegramDesktop/DebugLogs/log*.txt files).


Or you can send me a core-dump (you'll find it in 
~/.local/share/TelegramDesktop/core, but before this, increase the core 
files limit by typing `ulimit -c unlimited`), but be carefully, it may 
contain private information if you logged in. But the last point at your 
discretion.


01.04.2017 16:33, Boyuan Yang пишет:

Running telegram-desktop 1.0.27 (tdesktop binary release) won't crash. The
only output is:

(Telegram:7331): GLib-GObject-WARNING **: /build/glib2.0-B1uXKV/
glib2.0-2.50.3/./gobject/gsignal.c:2523: signal 'child-added' is invalid for
instance '0x6a15db0' of type 'GtkMenu'


Very interesting. Then I'm not sure that it relates to libappindicator.

[1]: https://wiki.ubuntu.com/Backtrace#Generation
[2]: 
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details#gdb-not-yet-running

Bug#859172: telegram-desktop: Segmentfault due to lack of libappindicator3-1 library dep

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

Control: tags -1 + unreproducible

What I've done:

1. Loaded under XUbuntu 16.10 LiveUSB
2. Added Debian unstable repo
3. Installed telegram-desktop
4. Removed libappindicator1 and libappindicator3-1

The first one didn't even installed, the second one was removed and all 
its dependencies.


5. Telegram Desktop is started well. But the icon on system panel isn't 
displayed [1]. In other respects, it works perfectly.


Probably, it makes sense to add libappindicator in recommends.

Could you test it with upstream binary? Could you install 
telegram-desktop-dbgsym package and run it under gdb?


[1]: https://i.imgur.com/Qa8FEzq.png

Bug#859057: telegram-desktop: FTBFS everywhere but x86

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

31.03.2017 23:01, Graham Inggs пишет:

FWIW, I've just tried building telegram-desktop with your patch on the
Ubuntu PPA builders and it was successful on arm64, armhf and ppc64el.


Very good! Does the program really work? You can run it or send a message?

31.03.2017 15:51, Boyuan Yang пишет:

It seems that upstream code would give up when compiling if the host is not
x86 or x86_64. However, such information and defined macros were not used
anywhere in the source code. Thus I think we could simply patch away the
blocking #error macro.


One of these macros is used in Telegram/SourceFiles/ui/animation.h:169

#ifdef ARCH_CPU_32_BITS
#define SHIFTED_USE_32BIT
#endif // ARCH_CPU_32_BITS

#ifdef SHIFTED_USE_32BIT
...

Also have a look at Telegram/SourceFiles/config.h:276

#if Q_BYTE_ORDER == Q_BIG_ENDIAN
#error "Only little endian is supported!"
#endif // Q_BYTE_ORDER == Q_BIG_ENDIAN

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#859027: telegram-desktop: Incomplete debian/copyright?

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

Control: tag -1 + fixed

29.03.2017 20:18, Chris Lamb пишет:

I just ACCEPTed telegram-desktop from NEW but noticed it was missing
attribution in debian/copyright for at least:

  Telegram/Patches/qtbase_5_6_2.diff
  debian/patches/Avoid-depending-on-static-libraries.patch

etc.

(This is *not* exhaustive so please check over the entire package
carefully and address these on your next upload.)


I've add mentions about the first patch into debian/copyright. The 
second patch no longer includes foreign code, I moved all borrowings 
from Qt source into special file debian/qt_functions.cpp. I hope there 
are no other missing attributions.


29.03.2017 23:08, Mattia Rizzolo пишет:
> Actually, Nicholas, what's the state of your endeavour to improve the
> upstream situation, and reduce the patching done on the Debian site?

They merged my last pull request [1], so I deleted 
d/p/Fix-desktop-integration-issues.patch.


[1]: https://github.com/telegramdesktop/tdesktop/pull/3109

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#859221: ITP: microsoft-gsl

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

Package: wnpp
Severity: wishlist

Hello everybody!

I intend to make a package for Microsoft Guidelines Support Library
(GSL). It's a build dependency of new version of telegram-desktop v1.0.27.

The package is ready, I need to get a wnpp bug number. I hope you'll be 
able to download the package [1] after a few minutes.


The source is available on GitHub: https://github.com/Microsoft/GSL
The software is distributed under the license MIT (Expat).

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

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