Bug#975356: xfce4-panel: cairo_region_destroy crash

2022-11-27 Thread Горбешко Богдан 

On 27.11.2022 11:16, Akbarkhon Variskhanov wrote:

Control: severity -1 normal
Control: tags -1 unreproducible moreinfo

Thanks for reporting. However, we can't do much without a proper
backtrace. Could you try with the latest version and see if you can
get a backtrace? You can follow this guide:
https://wiki.debian.org/HowToGetABacktrace


I couldn't reproduce this too, it barely crashed during these 2 years. 
Running it under gdb all the time just for the case it happens again 
would be too of a burden, sorry.

Bug#1011463: libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

2022-05-23 Thread Горбешко Богдан 
Okay, I sacrificed decibel-audio-player and volti (wasn't using them 
long ago anyway).


But it still breaks ruby-gobject-introspection. Sid has a newer version, 
which depends on some non-existent libgirepository-1.0-1-with-libffi8 
though. So it's probably better to wait until the dependencies settle down.


On 23.05.2022 18:00, Simon McVittie wrote:

On Mon, 23 May 2022 at 16:59:55 +0300, Bohdan Horbeshko wrote:

libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

Yes, that is a true statement. If python-gi still existed in Debian,
then you would not be able to use new versions of libgirepository-1.0-1
together with old versions of python-gi, because old versions of
python(3)-gi were compiled against libffi7 (or older), but the new
libgirepository-1.0-1 exposes libffi8 in its ABI. The changes to struct
sizes between libffi7 and libffi8 would cause python-gi to crash on at
least some CPU architectures.

Breaks: python-gi (with no version constraint) would have the same
practical effect, except that if someone somehow brings back Python 2
support in pygobject, a non-versioned Breaks would require more
coordination.

If you have legacy code that requires python-gi, I would recommend
using it via a container or chroot (perhaps a Docker, Toolbx or schroot
environment with Debian 11 or older, or perhaps Flatpak or similar),
rather than on a host system that needs to run an up-to-date version
of Debian.

 smcv

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

2021-11-29 Thread Горбешко Богдан 

On 30.11.2021 01:57, Ben Hutchings wrote:


About 59 MiB, so again most of the increase.

It appears that BTF in modules was enabled in Linux 5.11 by



So the patch that was supposed to drastically reduce the size of modules 
by extracting the debugging info to a separate deduplicated file, 
actually increased it even more? Sounds pretty ironic.


Or did the deduplication finally make BTFs reasonably small to be 
included by default, as they were much larger before and thus were disabled?

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

2021-02-18 Thread Горбешко Богдан 

On 18.02.2021 16:27, Pino Toscano wrote:

In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto:

I had checked the upstream repository before reporting this issue
(that's where I got the filename), it still contains this version of the
icon. Reporting here, because I couldn't find an issue tracker on KDE
GitLab.

https://bugs.kde.org is the KDE upstream bug tracking system. Please
report it there, rather than on a downstream bug tracking system.

Reported to upstream https://bugs.kde.org/show_bug.cgi?id=433191, feel 
free to close it :)

Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon

2021-02-18 Thread Горбешко Богдан 

On 18.02.2021 15:53, Pino Toscano wrote:

Hi Bohdan,

In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto:

Package: kdeconnect
Version: 20.04.3-1
Severity: wishlist

Dear Maintainer,

the current icon looks very similar to a broken image icon. I thought it
was broken for several months, until I squinted and found out that × is
actually K. Though when I glance over it, I still subconciously percieve
it as a broken image icon. Please redesign it to something more contrast
and distinct; the light version of the icon does not have this issue.

Please note that we do not do upstream development, and this kind of
change (i.e. artwork) ought to be done by upstream, either in kdeconnect
itself or in the breeze icon theme.

Please note also:


Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kdeconnect depends on:
ii  kde-cli-tools 4:5.17.5-2
ii  kio   5.70.1-1
ii  libc6 2.31-3
ii  libfakekey0   0.3+git20170516-2
ii  libkf5configcore5 5.70.0-1

kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04:
your system is ~6 month behind of the current Debian testing.
Please fully dist-update your system when reporting bugs for
unstable or testing, as otherwise there is the risk of reporting
stale issues.

I had checked the upstream repository before reporting this issue 
(that's where I got the filename), it still contains this version of the 
icon. Reporting here, because I couldn't find an issue tracker on KDE 
GitLab.

Bug#980840: xfce4-genmon-plugin: The plugin is shoved into one row in sidebar mode in 4.16

2021-01-22 Thread Горбешко Богдан 

Package: xfce4-genmon-plugin
Version: 4.1.0-1
Severity: important

Dear Maintainer,

after upgrading the panel from 4.14.4, and all the applets (this one 
from 4.0.2 exactly), the displaying of the genmon plugin got broken.


Before: https://pic4a.ru/11/mtO.png
After: https://pic4a.ru/11/3lC.png

This sidebar has 5 rows, and genmon occupies only one of it, instead of 
expanding to the full width.




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-genmon-plugin depends on:
ii  libc6    2.31-3
ii  libglib2.0-0 2.66.0-2
ii  libgtk-3-0   3.24.23-1
ii  libpango-1.0-0   1.46.2-1
ii  libxfce4panel-2.0-4  4.16.0-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util7    4.16.0-1

xfce4-genmon-plugin recommends no packages.

xfce4-genmon-plugin suggests no packages.

-- no debconf information

Bug#975356: xfce4-panel: cairo_region_destroy crash

2020-11-20 Thread Горбешко Богдан 

Package: xfce4-panel
Version: 4.14.4-1
Severity: important

Dear Maintainer,

it just crashed in background (possibly during switching the windows, my 
WM is

compiz-reloaded 0.8.18), with the following error:

xfce4-panel: ../../../../src/cairo-region.c:428: cairo_region_destroy:
Проверочное утверждение «CAIRO_REFERENCE_COUNT_HAS_REFERENCE 
(®ion->ref_coun

t)» не выполнено.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-panel depends on:
ii  exo-utils    0.12.11-1
ii  libatk1.0-0  2.36.0-2
ii  libc6    2.31-3
ii  libcairo2    1.16.0-4
ii  libexo-2-0   0.12.11-1
ii  libgarcon-1-0    0.6.4-1
ii  libgarcon-gtk3-1-0   0.6.4-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.66.0-2
ii  libgtk-3-0   3.24.23-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.46.2-1
ii  libpangocairo-1.0-0  1.46.2-1
ii  libwnck-3-0  3.36.0-1
ii  libx11-6 2:1.6.12-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfce4panel-2.0-4  4.14.4-1
ii  libxfce4ui-2-0   4.14.1-1+b1
ii  libxfce4util7    4.14.0-1
ii  libxfconf-0-3    4.14.3-1

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#969044: pidgin: Segmentation fault in purple_proxy_connect_data_disconnect

2020-08-26 Thread Горбешко Богдан 

Package: pidgin
Version: 2.13.0-2.2+b1
Severity: important

Dear Maintainer,

I had Pidgin running in background and accidentally got this crash:

#0  0x7717b4bd in purple_proxy_connect_data_disconnect
(connect_data=0x1c8c0033, error_message=0x0) at 
././libpurple/proxy.c:612

#1  0x7717b480 in purple_proxy_connect_cancel
(connect_data=0x1c8c0033) at ././libpurple/proxy.c:2547
#2  0x7719e5a3 in purple_util_fetch_url_cancel
(gfud=gfud@entry=0x59175d70) at ././libpurple/util.c:4282
#3  0x71903c8a in url_fetch_recv_cb (url_data=0x59175d70,
source=, cond=cond@entry=PURPLE_INPUT_READ) at 
local_util.c:3940

#4  0x555cb1e2 in pidgin_io_invoke (source=,
condition=, data=0x5928afc0) at 
././pidgin/gtkeventloop.c:73

#5  0x772864de in g_main_dispatch (context=0x55684800) at
../../../glib/gmain.c:3309
#6  g_main_context_dispatch (context=context@entry=0x55684800) at
../../../glib/gmain.c:3974
#7  0x77286890 in g_main_context_iterate (context=0x55684800,
block=block@entry=1, dispatch=dispatch@entry=1, self=)
    at ../../../glib/gmain.c:4047
#8  0x77286b63 in g_main_loop_run (loop=0x55b91d40) at
../../../glib/gmain.c:4241
#9  0x7776212a in gtk_main () at /usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0
#10 0x55590970 in main (argc=, argv=out>) at

././pidgin/gtkmain.c:939



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pidgin depends on:
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.30-8
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.16-2
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-0    2.64.2-1
ii  libgstreamer1.0-0   1.16.2-2
ii  libgtk2.0-0 2.24.32-4
ii  libgtkspell0    2.0.16-1.3
ii  libice6 2:1.0.9-2
ii  libpango-1.0-0  1.42.4-8
ii  libpurple0  2.13.0-2.2+b1
ii  libsm6  2:1.2.3-1
ii  libx11-6    2:1.6.9-2+b1
ii  libxss1 1:1.2.3-1
ii  perl-base [perlapi-5.30.0]  5.30.3-4
ii  pidgin-data 2.13.0-2.2

Versions of packages pidgin recommends:
ii  gstreamer1.0-alsa  1.16.2-4
ii  gstreamer1.0-libav 1.16.2-2
ii  gstreamer1.0-plugins-base  1.16.2-4
ii  gstreamer1.0-plugins-good  1.16.2-3
ii  gstreamer1.0-pulseaudio    1.16.2-3

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.32.3-1

-- no debconf information

Bug#958477: libpango1.0-0: Please return the package to bullseye/sid

2020-04-22 Thread Горбешко Богдан 

Package: libpango1.0-0
Version: 1.42.4-8
Severity: wishlist

Dear Maintainer,

I have some packages installed that depend on this virtual package (cairo-
compmgr, deadbeef-static, flashplugin-nonfree). Thus I can't upgrade pango-
related packages to 1.44, because there is no 1.44 version for this virtual
package.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpango1.0-0 depends on:
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libpangoft2-1.0-0    1.42.4-8
ii  libpangox-1.0-0  0.0.2-5+b2
ii  libpangoxft-1.0-0    1.42.4-8

libpango1.0-0 recommends no packages.

libpango1.0-0 suggests no packages.

-- no debconf information

Bug#953479: mopidy: Please move fonts-lato dependency to the recommended section

2020-03-09 Thread Горбешко Богдан 

On 10.03.2020 00:39, Stein Magnus Jodal wrote:

reassign 953479 sphinx-rtd-theme
thanks

On Mon, Mar 09, 2020 at 11:26:22PM +0200, Горбешко Богдан wrote:

the fonts-lato is a pretty bloated dependency (more than 10 MB of disk
space).
It was mandatory for the ruby2.5 package when it just released, but then was
moved to recommended. Please do the same. I don't think that using a
fallback
font will affect user experience in any significant way (only maybe if
mopidy
uses some Lato-specific font features).

Hi!

Mopidy does not depend on fonts-lato directly, only via Suggests on
mopidy-doc, which Depends on sphinx-rtd-theme-common, which again
Depends on fonts-lato.

Thus, there is nothing that can be easily done with this from the
perspective of src:mopidy.

Reassigning to src:sphinx-rtd-theme.

--
Stein Magnus Jodal


Hmm, yes; though the reason is not the suggested mopidy-doc package, but 
the python3-pykka dependency, which started to depend on 
sphinx-rtd-theme-common. The latter is used by a lot of packages, so 
then I'm less sure that this change will have that minimal impact.

Bug#953479: mopidy: Please move fonts-lato dependency to the recommended section

2020-03-09 Thread Горбешко Богдан 

Package: mopidy
Version: 3.0.1-2
Severity: wishlist

Dear Maintainer,

the fonts-lato is a pretty bloated dependency (more than 10 MB of disk 
space).

It was mandatory for the ruby2.5 package when it just released, but then was
moved to recommended. Please do the same. I don't think that using a 
fallback
font will affect user experience in any significant way (only maybe if 
mopidy

uses some Lato-specific font features).



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mopidy depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]    1.5.73
ii  gir1.2-gst-plugins-base-1.0  1.16.2-2
ii  gir1.2-gstreamer-1.0 1.16.2-2
ii  gstreamer1.0-plugins-good    1.16.2-2
ii  gstreamer1.0-plugins-ugly    1.16.2-2
ii  lsb-base 11.1.0
ii  python-gst-1.0   1.16.2-1
ii  python-pkg-resources 44.0.0-1
ii  python-pykka 1.2.1-4
ii  python-requests  2.22.0-2
ii  python-tornado   6.0.3+really5.1.1-2
ii  python2  2.7.17-2

Versions of packages mopidy recommends:
ii  gstreamer1.0-alsa    1.16.2-2
ii  gstreamer1.0-pulseaudio  1.16.2-2
ii  gstreamer1.0-tools   1.16.2-2

Versions of packages mopidy suggests:
pn  mopidy-doc  

-- Configuration Files:
/etc/mopidy/mopidy.conf [Errno 13] Отказано в доступе: 
'/etc/mopidy/mopidy.conf'


-- debconf information:
  mopidy/daemon: false

Bug#952385: RFP: sslscan -- sslscan tests SSL/TLS enabled services to discover supported cipher suites

2020-02-23 Thread Горбешко Богдан 

Package: wnpp
Severity: wishlist

* Package name    : sslscan
  Version : 2.0.0-alpha1-4-ge4f0474
  Upstream Author : rbsec 
* URL : https://github.com/rbsec/sslscan/
* License : GPL-3.0
  Programming Lang: C
  Description : sslscan tests SSL/TLS enabled services to discover
supported cipher suites

The main changes in sslscan2 is a major rewrite of the backend scanning 
code,

which means that it is no longer reliant on the version of OpenSSL for many
checks. This means that it is possible to support legacy protocols 
(SSLv2 and

SSLv3), as well as supporting TLSv1.3 - regardless of the version of OpenSSL
that it has been compiled against.

This has been made possible largely by the work of jtesta, who has been
responsible for most of the backend rewrite.

Other key changes include:

Enumeration of server key exchange groups.
Enumeration of server signature algorithms.
SSLv2 and SSLv3 protocol support it scanned, but individual ciphers are not.
A test suite is included using Docker, to verify that sslscan is 
functionality

correctly.

Bug#948671: libsmbclient: mounting a share from Windows XP fails on timeout

2020-01-11 Thread Горбешко Богдан 

#samba:freenode.net, sorry.

On 11.01.2020 18:24, Горбешко Богдан wrote:

Package: libsmbclient
Version: 2:4.11.3+dfsg-1
Severity: important

Dear Maintainer,

after an upgrade to smbclient=2:4.11.3+dfsg-1 (actually, some earlier 
version
is affected too) I lost an ability to mount a share from Windows XP 
machine.

Several clients that utilize libsmbclient (smbclient, Double Commander's
"Windows Network" plugin, gio mount) hang for a while and fail on 
timeout. So I
had to roll smbclient back to 2:4.9.5+dfsg-5+deb10u1, as well as some 
other

dependencies, where it works well.

I have already asked about it on #smbclient:freenode.net, and qman__ 
told:


Jan 01 01:44:25     there have been several breaking security
patches to SMB both on windows and samba since Windows XP went EOL
Jan 01 01:44:55     I would be more surprised if you could 
get it

to work

But I couldn't see any CVE fixes in recent changelog that should 
prevent SMB1
from working at all, and the support for it doesn't seem to be removed 
from

libsmbclient yet, so it looks like an unintentional bug.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsmbclient depends on:
ii  dpkg    1.19.7
ii  libbsd0 0.10.0-1
ii  libc6   2.29-7
ii  libtalloc2  2.3.0-3
ii  libtevent0  0.10.1-4
hi  samba-libs  2:4.9.5+dfsg-5+deb10u1

libsmbclient recommends no packages.

libsmbclient suggests no packages.

-- no debconf information

Bug#948671: libsmbclient: mounting a share from Windows XP fails on timeout

2020-01-11 Thread Горбешко Богдан 

Package: libsmbclient
Version: 2:4.11.3+dfsg-1
Severity: important

Dear Maintainer,

after an upgrade to smbclient=2:4.11.3+dfsg-1 (actually, some earlier 
version

is affected too) I lost an ability to mount a share from Windows XP machine.
Several clients that utilize libsmbclient (smbclient, Double Commander's
"Windows Network" plugin, gio mount) hang for a while and fail on 
timeout. So I

had to roll smbclient back to 2:4.9.5+dfsg-5+deb10u1, as well as some other
dependencies, where it works well.

I have already asked about it on #smbclient:freenode.net, and qman__ told:

Jan 01 01:44:25     there have been several breaking security
patches to SMB both on windows and samba since Windows XP went EOL
Jan 01 01:44:55     I would be more surprised if you could 
get it

to work

But I couldn't see any CVE fixes in recent changelog that should prevent 
SMB1

from working at all, and the support for it doesn't seem to be removed from
libsmbclient yet, so it looks like an unintentional bug.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsmbclient depends on:
ii  dpkg    1.19.7
ii  libbsd0 0.10.0-1
ii  libc6   2.29-7
ii  libtalloc2  2.3.0-3
ii  libtevent0  0.10.1-4
hi  samba-libs  2:4.9.5+dfsg-5+deb10u1

libsmbclient recommends no packages.

libsmbclient suggests no packages.

-- no debconf information

Bug#941578: bluez: Can't connect to other bluetooth devices

2019-10-02 Thread Горбешко Богдан 

Package: bluez
Version: 5.50-1+b1
Severity: important

Dear Maintainer,

I don't remember exactly when bluetooth had broken, probably this year 
spring or even earlier.


Logs of bluetooth.service when the dongle is plugged:


окт 02 14:00:36 localhost.localdomain bluetoothd[26088]: RFCOMM server 
failed for Message Notification: rfcomm_bind: Address already in use (98)
окт 02 14:00:36 localhost.localdomain bluetoothd[26088]: RFCOMM server 
failed for Message Access: rfcomm_bind: Address already in use (98)
окт 02 14:00:36 localhost.localdomain bluetoothd[26088]: RFCOMM server 
failed for Phone Book Access: rfcomm_bind: Address already in use (98)
окт 02 14:00:36 localhost.localdomain bluetoothd[26088]: RFCOMM server 
failed for Synchronization: rfcomm_bind: Address already in use (98)
окт 02 14:00:36 localhost.localdomain bluetoothd[26088]: RFCOMM server 
failed for File Transfer: rfcomm_bind: Address already in use (98)
окт 02 14:00:36 localhost.localdomain bluetoothd[26088]: RFCOMM server 
failed for Object Push: rfcomm_bind: Address already in use (98)
окт 02 14:00:38 localhost.localdomain bluetoothd[26088]: Endpoint 
registered: sender=:1.502152 path=/MediaEndpoint/A2DPSource
окт 02 14:00:38 localhost.localdomain bluetoothd[26088]: Endpoint 
registered: sender=:1.502152 path=/MediaEndpoint/A2DPSink



No new log entries appear when I try to send some file via 
bluetooth-sendto, or blueman-sendto: they just hang at start and then 
show an error on timeout. Trying to connect via blueman-manager also 
fails on timeout with "input/output error".


Tried to send to several phones, all are paired with the dongle and 
trusted. The same dongle works well on a Windows XP system, so this is 
not a hardware issue.


Additional info:

$ LC_ALL=C pactl list modules|grep blue
    Name: module-bluetooth-policy
        module.description = "Policy module to make using bluetooth 
devices out-of-the-box easier"

    Name: module-bluetooth-discover
    Name: module-bluez5-discover

# rfkill
ID TYPE  DEVICE    SOFT  HARD
 0 wlan  ideapad_wlan unblocked unblocked
 1 wlan  phy0 unblocked   blocked
 4 bluetooth hci0 unblocked unblocked


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bluez depends on:
ii  dbus  1.12.16-1
ii  kmod  26-3
ii  libasound2    1.1.8-1
ii  libc6 2.29-1
ii  libdbus-1-3   1.12.16-1
ii  libdw1    0.176-1.1
ii  libglib2.0-0  2.60.6-2
ii  libreadline8  8.0-3
ii  libudev1  242-7
ii  lsb-base  11.1.0
ii  udev  242-7

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  1:12.2-9~cosmic1

-- Configuration Files:
/etc/dbus-1/system.d/bluetooth.conf changed:

1.0//EN"

 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>

  

  
    
    
    
    
    
    
    
    
    
    
    
  
  
  
    
  
  
    
  
  
  
    
  
  
    
  
    4096
    8192



-- no debconf information

Bug#939347: flatpak: prerm/postrm scripts don't remove /var/lib/flatpak

2019-09-03 Thread Горбешко Богдан 

Package: flatpak
Version: 1.4.2-2
Severity: normal

Dear Maintainer,

when I purged the flatpak package, /var/lib/flatpak and all of it's 
contents are still left here — 21 MB, quite a lot.




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii  adduser    3.118
ii  bubblewrap 0.3.3-2
pn  libappstream-glib8 
ii  libarchive13   3.3.3-4
ii  libc6  2.28-10
ii  libdconf1  0.30.1-2
ii  libfuse2   2.9.9-1
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.60.6-2
ii  libgpgme11 1.13.1-1
ii  libjson-glib-1.0-0 1.4.4-2
pn  libostree-1-1  
ii  libpolkit-agent-1-0    0.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libseccomp2    2.4.1-2
ii  libsoup2.4-1   2.64.2-2
ii  libsystemd0    242-4
ii  libxau6    1:1.0.8-1+b2
ii  libxml2    2.9.4+dfsg1-7+b3
pn  xdg-dbus-proxy 
pn  xdg-desktop-portal 

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.24-1
ii  gtk-update-icon-cache    3.24.10-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   242-4
ii  p11-kit 0.23.16.1-2
ii  policykit-1  0.105-26
ii  shared-mime-info 1.10-1
pn  xdg-desktop-portal-gtk | xdg-desktop-portal-backend 

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-4+b1

Bug#934590: [Mlt-devel] Bug#934590: libmlt-data: The package became bloated

2019-08-13 Thread Горбешко Богдан 

On 13.08.2019 22:22, Dan Dennedy wrote:
On Mon, Aug 12, 2019 at 5:27 AM Patrick Matthäi <mailto:pmatth...@debian.org>> wrote:


Am 12.08.2019 um 13:11 schrieb Горбешко Богдан:
> Package: libmlt-data
> Version: 6.16.0-3
> Severity: minor
>
> Dear Maintainer,
>
> After the last upgrade, the package became about 230 MBs larger,
> because of a lot of large lumas in PGM format, each about 4 MBs. Is
> there an important reason to keep them uncompressed on a disk? Even
> the fast GZip compression can drastically reduce their size.
>
Hi Dan,

what is your opionion about this? This is the list of the affected
files:


This was intentional to produce transitions with the correct aspect 
ratio. The PGM images cannot be simply gzip compressed because the PGM 
reader in MLT is not integrated with zlib. Instead, the package can 
use the configure option --luma-compress to output compressed PNG. 
However, these are 8-bit instead of the 16-bit PGM, which provides 
better quality transitions. Since these are procedurally-generated, I 
started working on a change to generate the image on-demand instead of 
reading a file. I plan to do that for the next release.



Okay; thanks for explanation!

Bug#934590: libmlt-data: The package became bloated

2019-08-12 Thread Горбешко Богдан 

Package: libmlt-data
Version: 6.16.0-3
Severity: minor

Dear Maintainer,

After the last upgrade, the package became about 230 MBs larger, because 
of a lot of large lumas in PGM format, each about 4 MBs. Is there an 
important reason to keep them uncompressed on a disk? Even the fast GZip 
compression can drastically reduce their size.




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#918854: [Pkg-rust-maintainers] Bug#918854: segfault updating crates.io index

2019-04-27 Thread Горбешко Богдан 

On 27.04.2019 20:33, Ximin Luo wrote:

Горбешко Богдан:

I get almost the same, with no proxies:


Sorry for late reply, I missed your messages back in March.

I still can't reproduce this on my end, so I won't be able to fix the problem. 
Can you try to collect more information?

- does the failure still occur with a fresh .cargo? (move it out of the way, 
rather than delete it, so you can still reproduce it case it goes away)

Yes.

- does it occur with upstream cargo? presumably not I guess...

No.

- Josh, what proxy are you using?

- are all your other packages up-to-date? what does apt-cache policy libssl-dev 
libssh-dev say?

libssl-dev:
  Installed: 1.1.1b-2
  Candidate: 1.1.1b-2
  Version table:
 *** 1.1.1b-2 500
    500 http://http.debian.net/debian buster/main amd64 Packages
    100 /var/lib/dpkg/status
 1.1.1b-1+ubuntu18.10.1+deb.sury.org+1 500
    500 http://ppa.launchpad.net/ondrej/php/ubuntu cosmic/main 
amd64 Packages

 1.0.1t-1+deb7u4 500
    500 http://mirrors.linode.com/debian-security 
wheezy/updates/main amd64 Packages

 1.0.1e-2+deb7u20 500
    500 http://mirrors.linode.com/debian wheezy/main amd64 Packages
libssh-dev:
  Installed: (none)
  Candidate: 0.8.6-3+b1
  Version table:
 0.8.6-3+b1 500
    500 http://http.debian.net/debian buster/main amd64 Packages
 0.5.4-1+deb7u3 500
    500 http://mirrors.linode.com/debian wheezy/main amd64 Packages
    500 http://mirrors.linode.com/debian-security 
wheezy/updates/main amd64 Packages

- try running with RUST_LOG=debug and what's the last few messages before it 
segfaults?

    Updating crates.io index
[2019-04-28T02:25:48Z DEBUG cargo::sources::git::utils] attempting 
GitHub fast path for https://github.com/rust-lang/crates.io-index
[2019-04-28T02:25:50Z DEBUG cargo::sources::git::utils] fast path 
failed, falling back to a git fetch
[2019-04-28T02:25:50Z DEBUG cargo::sources::git::utils] skipping gc as 
there's only 6 pack files
[2019-04-28T02:25:50Z DEBUG cargo::sources::git::utils] doing a fetch 
for https://github.com/rust-lang/crates.io-index
[2019-04-28T02:25:50Z DEBUG cargo::sources::git::utils] initiating fetch 
of refs/heads/master:refs/remotes/origin/master from 
https://github.com/rust-lang/crates.io-index
[2019-04-28T02:25:50Z INFO  git2_curl] action upload-pack 
/info/refs?service=git-upload-pack
[2019-04-28T02:25:50Z DEBUG git2_curl] request to 
https://github.com/rust-lang/crates.io-index/info/refs?service=git-upload-pack 


X

Bug#918854: segfault updating crates.io index

2019-04-27 Thread Горбешко Богдан 

I get almost the same, with no proxies:

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x55be142a in std::ffi::c_str::CStr::from_ptr ()
#2  0x55ae8013 in 
git2::transport::subtransport_action::{{closure}} ()
    at 
/usr/share/cargo/registry/cargo-0.33.0/vendor/git2/src/transport.rs:223
#3  git2::panic::wrap (f=...) at 
/usr/share/cargo/registry/cargo-0.33.0/vendor/git2/src/panic.rs:41
#4  0x55aeb0b9 in git2::transport::subtransport_action 
(stream=, raw_transport=0x563419f0,
    url=0x0, action=0) at 
/usr/share/cargo/registry/cargo-0.33.0/vendor/git2/src/transport.rs:222
#5  0x77f2b794 in git_smart__negotiation_step 
(transport=transport@entry=0x561b2ad0, data=0x58761120,

    len=1124) at ./src/transports/smart.c:333
#6  0x77f2d5e0 in git_smart__negotiate_fetch 
(transport=0x561b2ad0, repo=,

    wants=0x560fa210, count=1) at ./src/transports/smart_protocol.c:392
#7  0x77ec679e in git_fetch_negotiate 
(remote=remote@entry=0x56163530, opts=opts@entry=0x7fff2b80)

    at ./src/fetch.c:128
#8  0x77f0c9ef in git_remote_download 
(remote=remote@entry=0x56163530,
    refspecs=refspecs@entry=0x7fff2a90, 
opts=opts@entry=0x7fff2b80) at ./src/remote.c:929
#9  0x77f0d74e in git_remote_fetch (remote=0x56163530, 
refspecs=0x7fff2a90, opts=0x7fff2b80,

    reflog_message=0x0) at ./src/remote.c:969
#10 0x55aec767 in git2::remote::Remote::fetch 
(self=0x7fff2d20, refspecs=...,
    opts=/usr/lib/debug/.build-id/5a/dafb6a88215af9c0c802f3a7817d434ee4c89e.debug, 
CU 0x1b4d574, DIE 0x1b4fb9b>, reflog_msg=) at 
/usr/share/cargo/registry/cargo-0.33.0/vendor/git2/src/remote.rs:224
#11 0x556a8e92 in cargo::sources::git::utils::fetch::{{closure}} 
(opts=...)

    at src/cargo/sources/git/utils.rs:723
#12 0x556a6bd7 in 
cargo::sources::git::utils::with_fetch_options::{{closure}}::{{closure}} 
(f=...)

    at src/cargo/sources/git/utils.rs:653
#13 0x556a59b8 in 
cargo::sources::git::utils::with_authentication (url=..., cfg=out>, f=...)

    at src/cargo/sources/git/utils.rs:450
#14 cargo::sources::git::utils::with_fetch_options::{{closure}} () at 
src/cargo/sources/git/utils.rs:638
#15 core::ops::function::impls:: for 
&mut F>::call_once (self=,
    args=) at 
/usr/src/rustc-1.32.0/src/libcore/ops/function.rs:286
#16 cargo::util::network::Retry::try (f=, self=out>) at src/cargo/util/network.rs:25
#17 cargo::util::network::with_retry (config=, 
callback=...) at src/cargo/util/network.rs:87
#18 cargo::sources::git::utils::with_fetch_options 
(git_config=0x7fff3360, url=0x55e5e6e0,

    config=0x7fffdbc0, cb=...) at src/cargo/sources/git/utils.rs:637
#19 0x556a8319 in cargo::sources::git::utils::fetch 
(repo=, url=0x563419f0, refspec=...,

    config=) at src/cargo/sources/git/utils.rs:709
#20 0x55723f0e in 
 as 
cargo::sources::registry::RegistryDa
ta>::update_index (self=) at 
src/cargo/sources/registry/remote.rs:211
#21 0x5564e9ea in 
cargo::sources::registry::RegistrySource::do_update (self=0x55f14f20)

    at src/cargo/sources/registry/mod.rs:471
#22 0x55651202 in 
 as 
cargo::core::source::Source>::update (

    self=0x0) at src/cargo/sources/registry/mod.rs:562
#23 0x5590310b in 
cargo::core::registry::PackageRegistry::load::{{closure}} () at 
src/cargo/core/registry.rs:308
#24 cargo::core::registry::PackageRegistry::load (self=, 
source_id=...,
    kind=cargo::core::registry::Kind::Normal) at 
src/cargo/core/registry.rs:296
#25 cargo::core::registry::PackageRegistry::ensure_loaded 
(self=, namespace=...,
    kind=cargo::core::registry::Kind::Normal) at 
src/cargo/core/registry.rs:137
#26 0x55904e07 in  
as cargo::core::registry::Registry>::query (
    self=, dep=, f=..., fuzzy=false) at 
src/cargo/core/registry.rs:457
#27 0x556fe8a5 in 
cargo::core::resolver::types::RegistryQueryer::query (self=,

    dep=) at src/cargo/core/resolver/types.rs:115
#28 cargo::core::resolver::context::Context::build_deps::{{closure}} () 
at src/cargo/core/resolver/context.rs:113
#29 core::ops::function::impls:: for 
&mut F>::call_once (self=0x7fff4150,

    args=...) at /usr/src/rustc-1.32.0/src/libcore/ops/function.rs:286
#30 >::map (f=0x7fff4150, self=)
    at /usr/src/rustc-1.32.0/src/libcore/option.rs:424
#31  as core::iter::iterator::Iterator>::next 
(self=)

    at /usr/src/rustc-1.32.0/src/libcore/iter/mod.rs:1328
#32 < as 
core::iter::traits::FromIteratorE>>>::from_iter::Adapter as 
core::iter::iterator::Iterator>::next (self=)

    at /usr/src/rustc-1.32.0/src/libcore/result.rs:1232
#33 <&mut I as core::iter::iterator::Iterator>::next (self=)
    at /usr/src/rustc-1.32.0/src/libcore/iter/iterator.rs:2624
#34 0x5593cbf8 in  as 
alloc::vec::SpecExtend>::from_iter (iterator=)

    at /usr/src/rustc-1.32.0/src/liballoc/vec.rs:1788
#35 0x55715a59 in  as 
core::iter::

Bug#918854: segfault updating crates.io index

2019-03-05 Thread Горбешко Богдан 

Confirming this in 1.32.0.

Bug#923503: localepurge: Typo in README.dpkg-path

2019-02-28 Thread Горбешко Богдан 

Package: localepurge
Version: 0.7.3.5
Severity: minor

Dear Maintainer,

I found a typo: "lising".


-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  locales    2.28-6
ii  procps 2:3.3.15-2
ii  ucf    3.0038+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
ii  bleachbit  2.0-3
ii  debfoster  2.7-2.1+b1
ii  deborphan  1.7.31

-- debconf information excluded

Bug#919383: supercollider: unbuildable on several architectures due to qtwebengine5-dev

2019-02-19 Thread Горбешко Богдан 
Hi. Why did the package start depending on QtWebEngine at all? I had to 
hold it because of that. If I got the upstream README correctly, 
QtWebEngine is needed only for IDE, which is in another package.

Bug#921765: workrave: occasionally runs into false activity detection

2019-02-09 Thread Горбешко Богдан 

On 09.02.2019 13:10, Kees-Jan Dijkzeul wrote:
I have the same problem. I've found that actually becoming active 
(i.e. clicking on the break window that is in the "stuck" state) will 
usually restore normal operation.

Tried this almost every time — does not work for me.


Some mice, especially when placed on some surfaces, seem to generate 
continuous movement of a few pixels, enough to make workrave think you 
are still busy. Recent development snapshots have a "mouse 
sensitivity" field in the "Monitoring" tab, allowing you to tell 
workrave how small (or large) a movement it should ignore.



I don't have mouse, only touchpad. It does not send events when not touched.

Bug#921765: workrave: occasionally runs into false activity detection

2019-02-08 Thread Горбешко Богдан 

Package: workrave
Version: 1.10.23-2
Severity: important

Dear Maintainer,

Workrave can work well for hours or even days, but sometimes it falls into
unusable state. In that state, even when I don't touch input devices, it 
either

just keeps blinking again and again, finally deciding that it's ignored and
postponing a break, or enters a break but stucks after the first second. 
When I

close it via tray icon, the terminal that I ran it from prints that it have
exited with segmentation fault, which does not look normal. Moreover,
restarting Workrave does not help: it keeps behaving the same. But this 
issue
may evaporate during the session: when I recall about Workrave after a 
few days
and start it again, it may start working well again for some time. Looks 
like
this happens because of external factors, but I have no idea what 
exactly and

how to debug it.



-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages workrave depends on:
ii  libatk1.0-0   2.30.0-2
ii  libatkmm-1.6-1v5  2.28.0-2
ii  libc6 2.28-2
ii  libcairo-gobject2 1.16.0-2
ii  libcairo2 1.16.0-2
ii  libcairomm-1.0-1v5    1.12.2-4
ii  libdbusmenu-glib4 18.10.20180917~bzr490+repack1-1
ii  libdbusmenu-gtk3-4    18.10.20180917~bzr490+repack1-1
ii  libfontconfig1    2.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.2.0-14
ii  libgdk-pixbuf2.0-0    2.38.0+dfsg-7
ii  libgdome2-0   0.8.1+debian-6
ii  libglib2.0-0  2.58.2-3
ii  libglibmm-2.4-1v5 2.58.0-2
ii  libgstreamer1.0-0 1.14.4-1
ii  libgtk-3-0    3.24.2-3
ii  libgtk2.0-0   2.24.32-3
ii  libgtkmm-3.0-1v5  3.24.0-2
ii  libice6   2:1.0.9-2
ii  libindicator3-7   0.5.0-4
ii  libmate-panel-applet-4-1  1.20.3-1
ii  libpanel-applet3  3.30.0-2
ii  libpango-1.0-0    1.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libpangoft2-1.0-0 1.42.4-6
ii  libpangomm-1.4-1v5    2.42.0-2
ii  libpulse-mainloop-glib0   12.2-2
ii  libpulse0 12.2-2
ii  libsigc++-2.0-0v5 2.10.1-2
ii  libsm6    2:1.2.2-1+b3
ii  libstdc++6    8.2.0-14
ii  libx11-6  2:1.6.7-1
ii  libxfce4util7 4.12.1-3
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxss1   1:1.2.3-1
ii  libxtst6  2:1.2.3-1
ii  workrave-data 1.10.23-2
ii  xfce4-panel   4.12.2-1

workrave recommends no packages.

Versions of packages workrave suggests:
pn  gnome-panel  
ii  gnome-shell  3.30.1-2

-- no debconf information

Bug#915416: linux-image-amd64: Kernel panic again when uploading an image through Huawei E173 modem

2018-12-03 Thread Горбешко Богдан 

Package: linux-image-amd64
Version: 4.18+99
Severity: normal

Dear Maintainer,


This issue is similar to the Bug#893393 I reported before. Even the 
backtrace is almost the same. The only difference is that it started 
happening much rarely after the fix.


[717600.261489] BUG: unable to handle kernel paging request at 
9cc5f7129000

[717600.261505] PGD 6184b067 P4D 6184b067 PUD 189621063 PMD 77128063 PTE 0
[717600.261518] Oops: 0002 [#1] SMP NOPTI
[717600.261527] CPU: 0 PID: 32565 Comm: Socket Thread Kdump: loaded 
Tainted: G

W  O  4.18.0-2-amd64 #1 Debian 4.18.10-2
[717600.261531] Hardware name: LENOVO 20081   
/Inagua,

BIOS 41CN28WW(V2.04) 05/03/2012
[717600.261545] RIP: 0010:__memset+0x24/0x30
[717600.261547] Code: 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48 89 d1 
83 e2
07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 
 48 ab

89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
[717600.261597] RSP: 0018:bef58e957940 EFLAGS: 00010216
[717600.261601] RAX:  RBX:  RCX:
1ffa2600
[717600.261605] RDX: 0007 RSI:  RDI:
9cc5f7128ffa
[717600.261608] RBP: 9cc681fcbc00 R08: 304d434e R09:
9cc5f6e3c002
[717600.261611] R10: 0002 R11: 05ae R12:
9cc683ef3480
[717600.261614] R13: 9cc5a437b800 R14: 000c R15:
9cc5a437b500
[717600.261618] FS:  7ff137efe700() GS:9cc716c0()
knlGS:
[717600.261622] CS:  0010 DS:  ES:  CR0: 80050033
[717600.261624] CR2: 9cc5f7129000 CR3: 47f2 CR4:
06f0
[717600.261628] Call Trace:
[717600.261650]  cdc_ncm_fill_tx_frame+0x5f5/0x760 [cdc_ncm]
[717600.261661]  cdc_ncm_tx_fixup+0x57/0x70 [cdc_ncm]
[717600.261672]  usbnet_start_xmit+0x5d/0x720 [usbnet]
[717600.261682]  dev_hard_start_xmit+0xa1/0x200
[717600.261689]  sch_direct_xmit+0x14f/0x360
[717600.261695]  __qdisc_run+0x14d/0x500
[717600.261700]  __dev_queue_xmit+0x4d5/0x910
[717600.261708]  ? ip_finish_output2+0x25d/0x3b0
[717600.261712]  ip_finish_output2+0x25d/0x3b0
[717600.261717]  ? ip_output+0x6c/0xe0
[717600.261721]  ip_output+0x6c/0xe0
[717600.261726]  ? ip_fragment.constprop.48+0x80/0x80
[717600.261732]  __tcp_transmit_skb+0x555/0xad0
[717600.261738]  tcp_write_xmit+0x25e/0x1020
[717600.261743]  __tcp_push_pending_frames+0x31/0xd0
[717600.261747]  tcp_sendmsg_locked+0x3ff/0xd30
[717600.261753]  tcp_sendmsg+0x27/0x40
[717600.261759]  sock_sendmsg+0x36/0x40
[717600.261765]  __sys_sendto+0x10e/0x140
[717600.261772]  ? __schedule+0x2bf/0x880
[717600.261777]  __x64_sys_sendto+0x24/0x30
[717600.261784]  do_syscall_64+0x55/0x110
[717600.261790]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[717600.261796] RIP: 0033:0x7ff1451b09be
[717600.261798] Code: d5 53 49 89 f4 89 fb 48 83 ec 10 e8 6c f6 ff ff 45 
31 c9
89 c5 45 31 c0 45 89 f2 4c 89 ea 4c 89 e6 89 df b8 2c 00 00 00 0f 05 
<48> 3d 00

f0 ff ff 77 36 89 ef 48 89 44 24 08 e8 9e f6 ff ff 48 8b
[717600.261846] RSP: 002b:7ff137efd540 EFLAGS: 0246 ORIG_RAX:
002c
[717600.261850] RAX: ffda RBX: 0060 RCX:
7ff1451b09be
[717600.261853] RDX: 23d6 RSI: 7ff091d7f000 RDI:
0060
[717600.261856] RBP:  R08:  R09:

[717600.261859] R10:  R11: 0246 R12:
7ff091d7f000
[717600.261862] R13: 23d6 R14:  R15:
7ff0f4572190
[717600.261866] Modules linked in: bnep ctr ccm xt_state xt_conntrack
ipt_REJECT nf_reject_ipv4 nf_nat_h323 nf_conntrack_h323 nf_nat_pptp
nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_tftp
nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc
nf_nat_ftp nf_conntrack_ftp iptable_nat btusb btrtl btbcm btintel bluetooth
drbg ansi_cprng ecdh_generic snd_seq_dummy snd_hrtimer snd_seq_midi
snd_seq_midi_event snd_seq hid_generic snd_usb_audio snd_usbmidi_lib usbhid
snd_rawmidi hid snd_seq_device ppp_deflate bsd_comp ppp_async crc_ccitt
qmi_wwan ppp_generic slhc cdc_ether cdc_acm cpufreq_userspace
cpufreq_conservative nft_chain_route_ipv4 xt_CHECKSUM nft_chain_nat_ipv4
ipt_MASQUERADE nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat 
nf_conntrack

nft_counter xt_tcpudp
[717600.261936]  nft_compat bridge huawei_cdc_ncm cdc_wdm stp llc cdc_ncm
nf_tables option usbnet lz4 lz4_compress usb_wwan mii nfnetlink usbserial
zram zsmalloc cpufreq_powersave binfmt_misc rtsx_usb_ms memstick uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev
media uas usb_storage fuse xfs libcrc32c arc4 brcmsmac cordic brcmutil b43
mac80211 cfg80211 ssb pcmcia pcmcia_core kvm_amd ccp rng_core kvm
snd_hda_codec_conexant snd_hda_codec_generic irqbypass snd_hda_intel
snd_hda_codec k10temp evdev joydev serio_raw pcspkr ideapad_laptop 
snd_hda_core

bcma snd_hwdep snd_pcm_oss sparse_keymap radeon rfkill snd_mixer_

Bug#910280: pandoc: Please reduce the binary size

2018-10-04 Thread Горбешко Богдан 

Package: pandoc
Version: 2.2.1-2
Severity: wishlist

Dear Maintainer,

the pandoc binary is extremely large. It's the largest file in my 
/usr/bin, exceeding even blender's binary in almost 2 times.


From my experience, ghc is not good at making small binaries, and even 
stripping doesn't do much. However UPX does it's job great on binaries 
produced by ghc. I tried compressing pandoc in --best mode and achieved 
14% compression (from 141M to 20M); however the compression took more 
than an hour on my system.


If you are afraid of performance decreasing that may arise because of 
UPXing, you can make pandoc a virtual package, pointing by default to a 
non-compressed real package, but providing a compressed real package as 
well, for those who care about disk space.




-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pandoc depends on:
ii  libc6    2.27-6
ii  libffi6  3.2.1-8
ii  libgmp10 2:6.1.2+dfsg-3
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpcre3 2:8.39-11
ii  libyaml-0-2  0.2.1-1
ii  pandoc-data  2.2.1-2
ii  zlib1g   1:1.2.11.dfsg-1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  context    
ii  ghc    8.2.2-4
ii  groff  1.22.3-10
ii  libjs-mathjax  2.7.4+dfsg-1
pn  librsvg2-bin   
pn  node-katex 
ii  nodejs 8.12.0-1nodesource1
pn  pandoc-citeproc    
ii  perl   5.26.2-7
ii  php    1:7.2+62
ii  php7.2 [php]   7.2.9-1
ii  python 2.7.15-3
pn  r-base-core    
ii  ruby   1:2.5.1
ii  texlive-latex-extra    2018.20180824-1
ii  texlive-latex-recommended  2018.20180824-1
ii  texlive-luatex 2018.20180824-1
ii  texlive-xetex  2018.20180824-1
pn  wkhtmltopdf    

-- no debconf information

Bug#909808: compiz: Compiz started crashing 1-2 times a day

2018-09-28 Thread Горбешко Богдан 

Package: compiz
Version: 1:0.9.13.1+18.04.20180302-1
Severity: normal

Dear Maintainer,

as the package wasn't upgraded for a half of year, looks like this is caused
with some external factors. Here is a backtrace I catched with gdb:

#0  0x77d45536 in CompRect::operator==(CompRect const&) const () at
/usr/lib/x86_64-linux-gnu/libcompiz_core.so.ABI-20180221
#1  0x77d45569 in CompRect::operator!=(CompRect const&) const () at
/usr/lib/x86_64-linux-gnu/libcompiz_core.so.ABI-20180221
#2  0x7fffdd370846 in
PolygonAnim::addGeometry(std::vector > const&, CompRegion const&, CompRegion
const&, unsigned int, unsigned int) () at /usr/lib/x86_64-linux-
gnu/compiz/libanimationaddon.so
#3  0x7fffebdcabdd in
GLWindow::glAddGeometry(std::vector > const&, CompRegion const&, CompRegion
const&, unsigned int, unsigned int) () at /usr/lib/x86_64-linux-
gnu/compiz/libopengl.so
#4  0x7fffebdcb9e3 in GLWindow::glDraw(GLMatrix const&, 
GLWindowPaintAttrib

const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#5  0x7fffe4e017d7 in DecorWindow::glDraw(GLMatrix const&,
GLWindowPaintAttrib const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libdecor.so
#6  0x7fffebdcba72 in GLWindow::glDraw(GLMatrix const&, 
GLWindowPaintAttrib

const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#7  0x7fffdde67fc5 in WallpaperWindow::glDraw(GLMatrix const&,
GLWindowPaintAttrib const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libwallpaper.so
#8  0x7fffebdcba72 in GLWindow::glDraw(GLMatrix const&, 
GLWindowPaintAttrib

const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#9  0x7fffdd5c2b39 in PrivateAnimWindow::glPaint(GLWindowPaintAttrib
const&, GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libanimation.so
#10 0x7fffebdcbc8e in GLWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#11 0x7fffdc44f597 in FadeWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libfade.so
#12 0x7fffebdcbc8e in GLWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#13 0x7fffdc0233f9 in PrivateCubeWindow::glPaint(GLWindowPaintAttrib
const&, GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libcube.so
#14 0x7fffebdcbc8e in GLWindow::glPaint(GLWindowPaintAttrib const&,
GLMatrix const&, CompRegion const&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#15 0x7fffebdcc18e in PrivateGLScreen::paintOutputRegion(GLMatrix 
const&,

CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#16 0x7fffebdcce79 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#17 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#18 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#19 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#20 0x7fffd7bd5455 in RotateScreen::glPaintOutput(GLScreenPaintAttrib
const&, GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/librotate.so
#21 0x7fffebdccdb5 in GLScreen::glPaintOutput(GLScreenPaintAttrib 
const&,

GLMatrix const&, CompRegion const&, CompOutput*, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#22 0x7fffebdd2015 in
PrivateGLScreen::paintOutputs(std::__cxx11::list >&, unsigned int, CompRegion const&) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libopengl.so
#23 0x7fffdc023b54 in
PrivateCubeScreen::paint(std::__cxx11::list >&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libcube.so
#24 0x700f2d2f in
CompositeScreen::paint(std::__cxx11::list >&, unsigned int) ()
    at /usr/lib/x86_64-linux-gnu/compiz/libcomposite.so
#25 0x700f5d62 in CompositeScreen::handlePaintTimeout() () at
/usr/lib/x86_64-linux-gnu/compiz/libcomposite.so
#26 0x77d438af in CompTimer::triggerCallback() () at
/usr/lib/x86_64-linux-gnu/libcompiz_core.so.ABI-20180221
#27 0x77d43996 in CompTimeoutSource::c

Bug#908578: reportbug: crash on requesting madison

2018-09-11 Thread Горбешко Богдан 

Package: reportbug
Version: 7.5.0
Severity: normal

Dear Maintainer,

the reportbug package crashes on querying madison. So I had to compose 
this e-mail manually. Steps to reproduce:


* Start the reportbug master, proceed to the second step.
* Type in the package name, like `xfce4-panel` or `reportbug`, click on 
the needed package name in the list, proceed to the next step.

* The progressbar is shown for a while and then reportbug crashes:

```
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 
1049, in sync_pre_operation

    http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 
1072, in get_reports

    bugs = debianbts.get_bugs(pkg_filter, package)
  File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 
410, in get_bugs

    reply = soap_client.call('get_bugs', method_el)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 
260, in call

    self.xml_response = self.send(method, self.xml_request)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 
313, in send

    location, http_method, body=xml, headers=headers)
  File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 
1395, in request

    self.disable_ssl_certificate_validation)
  File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 978, 
in __init__

    timeout=timeout, context=context)
TypeError: fixer() missing 1 required positional argument: 'check_hostname'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2266, in 
    main()
  File "/usr/bin/reportbug", line 1109, in main
    return iface.user_interface()
  File "/usr/bin/reportbug", line 1722, in user_interface
    latest_first=self.options.latest_first)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 
1763, in func

    args, kwargs = op.sync_pre_operation(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 
1051, in sync_pre_operation

    error_dialog("Unable to connect to %s BTS." % sysinfo['name'])
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 
137, in error_dialog

    _assert_context(ui_context)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 
92, in _assert_context

    (_describe_context(really), _describe_context(expected)))
AssertionError: Function should be called in thread> but was called in 

```




-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable 
Architectures: i386


Kernel: Linux 4.17.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Bug#908145: gimp: hanged on calling the bent corner filter

2018-09-06 Thread Горбешко Богдан 

Package: gimp
Version: 2.10.6-2
Severity: normal

Dear Maintainer,

I called the filter once, then made a selection on its layer and tried 
to call it again.

Windows manager considered GIMP window unresponsible, I waited for a while
and killed the script-fu process. GIMP displayed the window about 
possibly broken

state, that window was not closable, and after a while GIMP crashed with the
following trace:

```
GNU Image Manipulation Program version 2.10.6
git-describe: GIMP_2_10_4-278-g0   COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
    OFFLOAD_TARGET_NAMES=nvptx-none
    OFFLOAD_TARGET_DEFAULT=1
   ugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-
l --program-prefix=x86_64-linux-gnu-
--enable-shared --enanable-nls --with-
sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-
time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-
vtable-verify --enable-libmpx --enable-plugin --enableb 
--enable-objc-gc=auto --enable-multiarch

--disable-werrnable-offload-
targets=nvptx-none --without-cuda-driver -Stack traces obtained from PID 
25312 - Thread 25312 #


[New LWP 26221]
[New LWP 26223]
[New LWP 26418]
[New LWP 26419]
[New LWP 29519]
[New LWP 5285]
[New LWP 26705]
[Threread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"7
  Id   Target Id Frame
* 1    Thread 0x7fc02fc2ae00 (LWP 25312) "gimp" 0x7fc033167394 in
__libc_read (fd=19, buf=0x7ffdf6ef2d90, nbytes=256) at
../sysdeps/unpoll.c:29
  4    Thread 0x7fc0148eb700 (LWP 26418) "asyncll () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

() at /usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x0reate.c:463
    pd = 0x7fbfebfff700
    now = 
#5  0x7fc033090edf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 7 (Thread 0x7fc011305700 (LWP 5285)):
#0  0x7fc03308ba79 in sysc#1  0x7fc03339ce0f in g_cond_wait () 
at /usr/lib/x86_64-linux-

gnu/libglib-2.0.so.0
#2  0x7fc034601f45 in  () at /usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3  0x0x7fc011305700) at
pthread_create.c:463
    pd = 0x7fc, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
    not_first_call = 
#5  0x7fc03309ne.S:95

Thread 6 (Thread 0x7fc0138e9700 (LWP 29519)):
#029
    resultvar = 18446744073709551100
    sc_ca-
gnu/libpulse.so.0
#5  0x7fc02e9f25b9 in  () at /usr8 in  () at /usr/lib/x86_64-linux-
gnu/pulseaudio/libpulsd_buf = {cancel_jmp_buf = {{jmp_buf = 
{140462938560256,

7783732442364401759, 140728746325118, 140728746325119, 140728746325120, 34,
-7816709123498551201, -78167786262214514/clone.S:95

Thread 5 (Thread 0x7fc0140ea700 (LWP 26419)x/sysv/linux/x86_64/syscall.S:38
#1  0x7fc03339ce0f i05 in  () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0

#9, 140728746325838, 140728746325839, 140728746325968, 0,
-7816710222473308065, -7816778626221451169}, mask_was_sav () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thre4/syscall.S:38
#1  0x7fc03339ce0f in g_cond_wait () a5afc132bb9a in  ()
#3  0x7fc03337ee05 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fc03315d = {140462955345664,
7783732442364401759, 140728746325854, 140728746325855, 140728746325984, 0,
-7816711321448064929, -7816778626221451169}, mask_was_saved = 0}}, priv 
= {unix/sysv/linux/x86_64/clone.S:95


Thread 3 (Thread 0x7fcpoll (fds=0x55afc20e5df0, nfds=2, timeout=-1)
at ../sysde073709551100
    sc_cancel_oldtype = 0
#1  0x7fc033357439 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fc0333577d2 in g_main_loop_run () at /usrc9e26 in  () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0

#4  0x7fc03337ee05 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7fc03315df2a in start_threanwind_buf = {cancel_jmp_buf = 
{{jmp_buf = {140463332501248,
7783732442364401759, 140728746325950, 140728746325951,451169}, 
mask_was_saved = 0}}, priv = {pad

= {0x0, 0x0, 06_64/clone.S:95

Thread 2 (Thread 0x7fc02b89b700 (LWP 262/poll.c:29
    resultvar = 18446744073709551100
    sc_cancel_oldtype = 0
#1  0x7fc033357439 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fc03335754c in g_main_context_iteration () at /usr/lib/x86_ 
() at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0

#4  0x0ib-2.0.so.0
#5  0x7fc03315df2a in start_thread (arg=0x7fc02b89b700) at
pthread_create.c:463
    pd = 0x7fc32442364401759, 140728746325566, 140728746325567, 
140728746325696, 0,
-7816832259137185697, -7816778626221451169},, data = {prev = 0x0, 
cleanup = 0x0, canceltype = 0}}}

  ne.S:95

Thread 1 (Thread 0x7fc02fc2ae00 (LWP 25312)):
#07
    resultvar = 18446744073709551104
    sc_cancel_oldtype = 1
    sc_ret = 
    sc_ret = 
    nbytes = 256
    fd 8e0 in  () at /lib/x86_64-linux-
gnu/libpthread.so.0
#6  0x7fc032fcef3b in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
    set = {__val = {0, 94213473785152, 14046347250541347378525

Bug#905924: bluez: Connections (such as file transfer, HID) stopped establishing but pairing works well

2018-08-11 Thread Горбешко Богдан 

Package: bluez
Version: 5.50-1
Severity: normal

Dear Maintainer,

today I discovered that bluetooth connections don't establish.
They worked fine near month ago. This is definitely not the
dongle issue, as it works well on Windows machine, and
unlikely the remote devices issue, as I tried several.
Re-pairing works successfully, but other activities, such as
sending a file via bluetooth-sendto, sending via blueman,
enabling HID via blueman, initiating HID from remote device —
fail after timeout. Blueman prints the following message after
a failed file transfer:

>Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security
policy blocked the reply, the reply timeout expired, or the
network connection was broken.

Output of btmon during bluetooth-sendto connection trial
attached.



-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bluez depends on:
ii  dbus  1.12.10-1
ii  kmod  25-1
ii  libasound2    1.1.6-1
ii  libc6 2.27-5
ii  libdbus-1-3   1.12.10-1
ii  libdw1    0.170-0.5
ii  libglib2.0-0  2.56.1-2
ii  libreadline7  7.0-5
ii  libudev1  239-7
ii  lsb-base  9.20170808
ii  udev  239-7

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  11.1-5

-- no debconf information

@ MGMT Command: Stop Discovery (0x0024) plen 1  
{0x0001} [hci0] 1301.687691
Address type: 0x01
  BR/EDR
< HCI Command: Inquiry Cancel (0x01|0x0002) plen 0  
  #8 [hci0] 1301.687771
> HCI Event: Command Complete (0x0e) plen 4 
>   #9 [hci0] 1301.690051
  Inquiry Cancel (0x01|0x0002) ncmd 1
Status: Success (0x00)
@ MGMT Event: Discovering (0x0013) plen 2   
{0x0002} [hci0] 1301.690132
Address type: 0x01
  BR/EDR
Discovery: Disabled (0x00)
@ MGMT Event: Discovering (0x0013) plen 2   
{0x0001} [hci0] 1301.690132
Address type: 0x01
  BR/EDR
Discovery: Disabled (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4  
{0x0001} [hci0] 1301.690192
  Stop Discovery (0x0024) plen 1
Status: Success (0x00)
Address type: 0x01
  BR/EDR
@ RAW Open: blueman-manager version 2.22
   {0x0003} 1301.719646
@ RAW Close: blueman-manager
   {0x0003} 1301.719830
< HCI Command: Create Connection (0x01|0x0005) plen 13  
 #10 [hci0] 1301.803590
Address: xx:xx:xx:xx:xx:xx (Sony Mobile Communications Inc)
Packet type: 0xcc18
  DM1 may be used
  DH1 may be used
  DM3 may be used
  DH3 may be used
  DM5 may be used
  DH5 may be used
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x
Role switch: Allow slave (0x01)
> HCI Event: Command Status (0x0f) plen 4   
>  #11 [hci0] 1301.806063
  Create Connection (0x01|0x0005) ncmd 1
Status: Success (0x00)
@ RAW Open: blueman-manager version 2.22
   {0x0003} 1302.719761
@ RAW Close: blueman-manager
   {0x0003} 1302.719792
@ RAW Open: blueman-manager version 2.22
   {0x0003} 1303.720970
@ RAW Close: blueman-manager
   {0x0003} 1303.721005
@ RAW Open: blueman-manager version 2.22
   {0x0003} 1304.722029
@ RAW Close: blueman-manager

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

2018-08-04 Thread Горбешко Богдан 
Unfortunately, I messed with it for several hours but couldn't reproduce 
the bug intentionally. Does anyone have any hints on how to do this more 
reliably? I tried to upload several files simultaneously, to fill the 
memory with tmpfs partitions for emulating high memory pressure 
condition, but nothing helped to trigger the crash.


On 8/3/18 12:19 AM, Горбешко Богдан wrote:
I upgraded the kernel to 4.17.8 and experienced the issue again. Not 
sure if the bug is the same technically, but the sympthomes are: I 
tried to upload a 30 MB file, and in the midst got a noisy screen. I 
will try to catch it with kdump to get the backtrace again later.


On 6/29/18 11:17 AM, Bjørn Mork wrote:

This issue should be fixed by commit

  49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb")

which has been backported to v4.17.3, v4.16.18 and v4.14.52. Please
check again with one of those kernel versions (or newer).

I see now that the fix doesn't apply cleanly to v4.9 stable due to
unrelated context changes.  I'll go fix that and resubmit a backport for
v4.9, so we get the fix into "stretch" too.  Thanks for reminding me.



Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

2018-08-02 Thread Горбешко Богдан 
I upgraded the kernel to 4.17.8 and experienced the issue again. Not 
sure if the bug is the same technically, but the sympthomes are: I tried 
to upload a 30 MB file, and in the midst got a noisy screen. I will try 
to catch it with kdump to get the backtrace again later.


On 6/29/18 11:17 AM, Bjørn Mork wrote:

This issue should be fixed by commit

  49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb")

which has been backported to v4.17.3, v4.16.18 and v4.14.52.  Please
check again with one of those kernel versions (or newer).

I see now that the fix doesn't apply cleanly to v4.9 stable due to
unrelated context changes.  I'll go fix that and resubmit a backport for
v4.9, so we get the fix into "stretch" too.  Thanks for reminding me.



Bjørn

Bug#893858: tilda: Tilda crashes sometimes

2018-03-23 Thread Горбешко Богдан 

Package: tilda
Version: 1.4.1-2
Severity: important

Dear Maintainer,

sometimes Tilda crashes with the message:
** (tilda:14324): ERROR **: X Error: BadMatch (invalid parameter attributes)

Not sure if this happens in background or when I try to unroll it. I
experienced this several times for the past days.



-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tilda depends on:
ii  libc6   2.27-2
ii  libconfuse2 3.2.1+dfsg-4
ii  libgdk-pixbuf2.0-0  2.36.11-1
ii  libglib2.0-0    2.54.3-2
ii  libgtk-3-0  3.22.29-1
ii  libpango-1.0-0  1.40.14-1
ii  libvte-2.91-0   0.52.0-1
ii  libx11-6    2:1.6.4-3

tilda recommends no packages.

tilda suggests no packages.

-- no debconf information

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

2018-03-19 Thread Горбешко Богдан 

On 3/19/18 2:18 AM, Bjørn Mork wrote:

Горбешко Богдан  writes:


vboxdrv(O)
binder_linux(O)
ashmem_linux(O)

Can you reproduce the problem without these modules loaded?
ashmem/binder were installed only 3 weeks ago. And Virtualbox VMs were 
run last time in July 2017, nothing other is expected to use its kernel 
module; however I'll try to blacklist it for now.


AFAICS there is no way the only memset in cdc_ncm can be called with
crashing input parameters. Unless something is scribbling over the
driver's data.
Maybe inspecting the crashdump would shed some light on the possible 
module conflict? If so, I'll try to upload it.


Bjørn

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

2018-03-18 Thread Горбешко Богдан 

Package: linux-image-amd64
Version: 4.14+89
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

This bothers me from November 2017, when wvdial broke and I moved to
NetworkManager. While wvdial uses only serial interface (ttyUSB),
NetworkManager sometimes recognizes the modem as ttyUSB and sometimes as 
cdc-
wdm. So maybe the bug is much older as I was not actively using 
huawei_cdc_nbm

module before.

Since that, I started to experience strange system crashes. The only common
thing for them is that HDD activity stops and the cooler keeps working; the
system doesn't respond to anything including REISUB. The screen image was
simply freezing for first weeks, then it started cluttering when crash 
happens.


I was not sure if this is a software problem or a hardware one. I 
couldn't even
strictly determine what conditions lead to this. The only mostly common 
thing

was that it happens on active outgoing traffic (file uploading, torrents
seeding and so). But not sure if every time. Sometimes the issue huddled 
and I

could calmly upload large files for several days or even several weeks, but
then crashes started happening again.

People on a forum suggested me to install crash/kdump. Sometimes kdump 
triggers

on kernel panic, sometimes it doesn't and I still get an unresponsive system
with a cluttered screen. When it triggers, systemd tries to start the 
bunch of
services in a small amount of RAM, so it proceeds very slowly and 
finally hangs
or fails to the maintenance mode because of expired timeouts. Today I 
found out

that in maintenance mode I still can run the kdump service and successfully
collect the kernel dump and dmesg.

[60103.825970] BUG: unable to handle kernel paging request at 
9641f2004000

[60103.825998] IP: __memset+0x24/0x30
[60103.826001] PGD a6a06067 P4D a6a06067 PUD 4f65a063 PMD 72003063 PTE 0
[60103.826013] Oops: 0002 [#1] SMP NOPTI
[60103.826018] Modules linked in: iptable_filter option huawei_cdc_ncm 
cdc_wdm

cdc_ncm usbnet usb_wwan usbserial mii lz4 lz4_compress zram zsmallo
c cpufreq_userspace cpufreq_powersave cpufreq_conservative rtsx_usb_ms 
memstick

uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobu
f2_core videodev media arc4 brcmsmac cordic brcmutil b43 mac80211 
binfmt_misc

cfg80211 fuse xfs ssb libcrc32c rng_core pcmcia pcmcia_core snd_hda_
codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec 
snd_hda_core

kvm_amd snd_hwdep kvm snd_pcm_oss snd_mixer_oss joydev irqbypass pcs
pkr snd_pcm bcma serio_raw ideapad_laptop sparse_keymap rfkill k10temp sg
snd_timer wmi snd shpchp sp5100_tco battery ac soundcore evdev acpi_cpuf
req vboxdrv(O) squashfs loop parport_pc ppdev lp parport sunrpc 
binder_linux(O)
[60103.826105]  ashmem_linux(O) ip_tables x_tables autofs4 ext4 crc16 
mbcache
jbd2 crc32c_generic fscrypto ecb crypto_simd cryptd glue_helper 
aes_x86_64 uas

usb_storage sr_mod sd_mod cdrom rtsx_usb_sdmmc mmc_core rtsx_usb mfd_core
amdkfd radeon psmouse ohci_pci ahci libahci i2c_algo_bit ttm atl1c libata
drm_kms_helper ohci_hcd ehci_pci ehci_hcd i2c_piix4 scsi_mod drm usbcore
usb_common video button thermal
[60103.826158] CPU: 0 PID: 5990 Comm: Chrome_DevTools Tainted: G   O
4.14.0-3-amd64 #1 Debian 4.14.17-1
[60103.826162] Hardware name: LENOVO 20081   
/Inagua,

BIOS 41CN28WW(V2.04) 05/03/2012
[60103.826166] task: 964193484fc0 task.stack: b2890137c000
[60103.826171] RIP: 0010:__memset+0x24/0x30
[60103.826174] RSP: :964316c03b68 EFLAGS: 00010216
[60103.826178] RAX:  RBX: fffd RCX:
1ffa5000
[60103.826181] RDX: 0005 RSI:  RDI:
9641f2003ffc
[60103.826184] RBP: 964192f6c800 R08: 304d434e R09:
9641f1d2c004
[60103.826187] R10: 0002 R11: 05ae R12:
9642e6957a80
[60103.826190] R13: 964282ff2ee8 R14: 000d R15:
9642e4843900
[60103.826194] FS:  7f395aaf6700() GS:964316c0()
knlGS:
[60103.826197] CS:  0010 DS:  ES:  CR0: 80050033
[60103.826200] CR2: 9641f2004000 CR3: 13b0c000 CR4:
06f0
[60103.826204] Call Trace:
[60103.826212]  
[60103.826225]  cdc_ncm_fill_tx_frame+0x5e3/0x740 [cdc_ncm]
[60103.826236]  cdc_ncm_tx_fixup+0x57/0x70 [cdc_ncm]
[60103.826246]  usbnet_start_xmit+0x5d/0x710 [usbnet]
[60103.826254]  ? netif_skb_features+0x119/0x250
[60103.826259]  dev_hard_start_xmit+0xa1/0x200
[60103.826267]  sch_direct_xmit+0xf2/0x1b0
[60103.826273]  __dev_queue_xmit+0x5e3/0x7c0
[60103.826280]  ? ip_finish_output2+0x263/0x3c0
[60103.826284]  ip_finish_output2+0x263/0x3c0
[60103.826289]  ? ip_output+0x6c/0xe0
[60103.826293]  ip_output+0x6c/0xe0
[60103.826298]  ? ip_forward_options+0x1a0/0x1a0
[60103.826303]  tcp_transmit_skb+0x516/0x9b0
[60103.826309]  tcp_write_xmit+0x1aa/0xee0
[60103.826313]  ? sch_direct_xmit+0x71/0x1b0
[60103.826318]  tcp_tasklet_func+0x177/0x180
[60103.826325]