Bug#960301: cannot reproduce issue anymore

[Javier Cantero]

On Wed, Jun 03, 2020 at 09:20:14AM +0200, Andreas B. Mundt wrote:
> Hi Mike,
> 
> I reported problems with webRTC above (related or not with the
> 'microphone'-issue at hand).

For the record, it's the same bug, and it's related to a change in
libnss3:

 - upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1636632
 - Firefox 76 bug (already closed): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959971

By the way, bug #961762 "firefox-esr: WebRTC broken"[1] should have been
merged with this one.

 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961762


> However, somehow the problem has
> disappeared here after one of the many upgrades (not the firefox-esr
> package).  I tried to figure out the package that made the difference,
> but there where to many changes.

The "culprit" is libnss3, which unstable has a new version of it since
saturday[2]. You can check it by downgrading to the 2:3.49.1-1 version
from testing and see if that undoes the fix.

 [2]: https://tracker.debian.org/pkg/nss


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Javier Cantero]

On Thu, May 14, 2020 at 06:42:30PM +0200, Francesco Poli wrote:
> By looking at the bug log, I see that at least two other users confirm
> they also experience the issue.

BTW, I've tested the official Linux-64 bit Mozilla 68.8-esr binary[*],
and the microphone is working (at least in my use case). You could try
to recompile without the Debian additional patches and see if that
helps.

[*] https://www.mozilla.org/en-US/firefox/68.0esr/releasenotes/


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Javier Cantero]

Package: firefox-esr
Version: 68.8.0esr-1
Followup-For: Bug #960301

Dear Maintainer,

I can confirm this bug.

The microphone was working fine in web pages just before the upgrade to
68.8.0esr-1 (in my case, I was using it with https://meet.jit.si/ ).
When tried to downgrade to 68.7.0esr-1 it started working again. There
have not been paralell dependency upgrades in my system related to
firefox-esr, the only ones were:

libapt-pkg6.0 amd64 2.1.1 [985 kB]
apt amd64 2.1.1 [1.439 kB]
apt-utils amd64 2.1.1 [433 kB]
groff-base amd64 1.22.4-5 [920 kB]
cmake amd64 3.16.3-3 [3.674 kB]
cmake-data all 3.16.3-3 [1.628 kB]
firefox-esr-l10n-es-es all 68.8.0esr-1 [505 kB]
libgtk-3-common all 3.24.20-1 [3.724 kB]
libgtk-3-0 amd64 3.24.20-1 [2.671 kB]
firefox-esr amd64 68.8.0esr-1 [48,2 MB]
gir1.2-gtk-3.0 amd64 3.24.20-1 [256 kB]
gtk-update-icon-cache amd64 3.24.20-1 [85,7 kB]
libflite1 amd64 2.1-release-4 [12,8 MB]
libfluidsynth2 amd64 2.1.2-1 [228 kB]   
 
libgtk-3-bin amd64 3.24.20-1 [122 kB]   
 
node-jquery all 3.5.1+dfsg-3 [309 kB]   
 
libjs-jquery all 3.5.1+dfsg-3 [3.548 B] 
 
make amd64 4.2.1-2+b1 [342 kB]  
 
pinentry-curses amd64 1.1.0-4 [64,9 kB] 
 
pinentry-gtk2 amd64 1.1.0-4 [71,0 kB] 
libvulkan1 amd64 1.2.135.0-3 [101 kB]

As you can see, nothing of these can be related to the bug, not even
libvulkan (that I don't use) or GTK+3. The only possible culprit is
firefox itself.

-- Addons package information

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

Kernel: Linux 5.6.12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox-esr depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-4
ii  libasound21.2.2-2.1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-7
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-4
ii  libfontconfig12.13.1-4
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10.1.0-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-4
ii  libglib2.0-0  2.64.2-1
ii  libgtk-3-03.24.20-1
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.44.7-4
ii  libsqlite3-0  3.31.1-5
ii  libstartup-notification0  0.12-6
ii  libstdc++610.1.0-1
ii  libx11-6  2:1.6.9-2+b1
ii  libx11-xcb1   2:1.6.9-2+b1
ii  libxcb-shm0   1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.16-4
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.2.2-1+b1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-6
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-7
ii  libgtk2.0-02.24.32-4
ii  pulseaudio 13.0-5

-- no debconf information

Bug#940091: debianutils: update-mime error upgrading to version 4.9

[Javier Cantero]

Package: debianutils
Version: 4.9
Severity: minor

Dear Maintainer,

This is what happened when the package was updated today in bullseye
(I've traslated it to english):

   Unpacking debianutils (4.9) over (4.8.6.3) ...
   Configuring debianutils (4.9) ...
   Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime 
line 43.

I think it's harmless, but that you should know regardless.


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

Kernel: Linux 5.2.14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), 
LANGUAGE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debianutils depends on:
ii  libc6  2.28-10

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

Bug#839384: livestreamer: include several fixes before Stretch freeze

[Javier Cantero]

Package: livestreamer
Version: 1.13~fix1-1
Severity: wishlist

Dear Maintainer,

Several livestreamer plugins (including the one used for Twitch) need
recent patches in order to work. Unfortunately, upstream is inactive
since February, and apparently not inclined to resume working on the
project (source: comments in [1]).

I've collected fixes for 14 livestreamer plugins from the project's
pending PR list and push them into a single big PR/patchset[2] to be
applied on top of the lastest released version of the upstream `develop`
branch (commit ab80dbd on 2 Feb 2016). These commits neither include new
code/features nor new plugins, only fixes to existing plugins so they
hopefully shouldn't introduce new bugs. Perhaps it would be useful to
add these fixes to the current packaged version so they can make it into
the next Debian stable release.

There is also an effort to fork and continue developing and maintaining
livestreamer called streamlink[3]. However, the developers still have to
go through the RFP/ITP process, and I don't know if there is enough time
to get into the archive before the Stretch freeze.

 [1]: https://github.com/chrippa/livestreamer/issues/1427
 [2]: https://github.com/chrippa/livestreamer/pull/1495
 [3]: https://github.com/streamlink/streamlink

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

[Javier Cantero]

On Wed, Aug 17, 2016 at 10:46:59PM +0100, Manuel A. Fernandez Montecelo wrote:
 
> - somehow try to use the same width of the current terminal, with
>  possible truncation (would work fine in pipes for which the ultimate
>  output is the same terminal, but not if redirected and processed/seen
>  from another terminal/computer, unless the width is the same)

A way to get the width of the current terminal even when stdout was
redirected/piped is read it from stdin (fd 0) instead. With the
advantage that, unlike stdout, most of the times the standard input is
going to be connected directly to the terminal (I don't see actual cases
where somebody would want to redirect the standard input of aptitude to a
file/pipe, but maybe I'm wrong).

A simple proof of concept:

#include 
#include 
#include 

void check_term_size( int fd )
{
struct winsize ws;

if ( isatty(fd) )
{
printf( "tty at FD %d\n", fd );
if ( ioctl(fd, TIOCGWINSZ, ) != -1 )
{
printf( "ROWS=%d\n", ws.ws_row );
printf( "COLUMNS=%d\n", ws.ws_col );
}
}
}

int main( int argc, char* argv[] )
{
check_term_size( 1 ); /* stdout */
check_term_size( 0 ); /* stdin  */

return 0;
}


The downside is that the problem persists with redirections: they are
again dependent on the size of the terminal --meaning "aptitude search
 > kk" would be different depending on the current width of the
terminal where the command is executed. But that is the case the -w
option was created for, right?

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#800459: aptitude: Auto-flagged dependencies of a renaming package get lost during an upgrade

[Javier Cantero]

Package: aptitude
Followup-For: Bug #800459

Dear Maintainer,

The bug is fixed in the current version of testing (0.8.3). I haven't
checked it using the versions from 0.7.6 to 0.8.2 (since those versions
never went to testing) so I don't know what specific version/patch fixed
it. But it's fixed now and the Auto flags don't get lose with the
described situation during an `aptitude upgrade`.

Anyway I'll keep monitoring if any package loses the Auto indicator.

Best regards.


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.3
Compiler: g++ 6.1.1 20160802
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.8.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160625
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffeff658000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f74a5cb2000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f74a5a82000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f74a5857000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f74a565)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f74a5353000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f74a504f000)
libboost_iostreams.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.61.0 (0x7f74a4e37000)
libboost_filesystem.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.61.0 (0x7f74a4c1e000)
libboost_system.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.61.0 (0x7f74a4a19000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7f74a4615000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f74a43f8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f74a4076000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f74a3d71000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f74a3b5b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f74a37b9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f74a35b5000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f74a339e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f74a3182000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f74a2f72000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f74a2d4f000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f74a2b3c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f74a2934000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f74a272e000)
/lib64/ld-linux-x86-64.so.2 (0x5585aed46000)

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

Kernel: Linux 4.6.7-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common0.8.3-1
ii  libapt-pkg5.0  1.3~rc2
ii  libboost-filesystem1.61.0  1.61.0+dfsg-2.1
ii  libboost-iostreams1.61.0   1.61.0+dfsg-2.1
ii  libboost-system1.61.0  1.61.0+dfsg-2.1
ii  libc6  2.23-5
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.1.1-11
ii  libncursesw5   6.0+20160625-1
ii  libsigc++-2.0-0v5  2.8.0-2
ii  libsqlite3-0   3.14.1-1
ii  libstdc++6 6.1.1-11
ii  libtinfo5  6.0+20160625-1
ii  libxapian22v5  1.2.23-1

Versions of packages aptitude recommends:
pn  libparse-debianchangelog-perl  
ii  sensible-utils 0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.35

-- no debconf information

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped

[Javier Cantero]

On Mon, Aug 15, 2016 at 11:25:40PM +0100, Manuel A. Fernandez Montecelo wrote:
> The reasoning for the change was that with pipes/redirections the
> concept of "terminal" and consequently "width" is lost.  If it's
> redirected it's possibly/likely that it's because it's moved and
> processed elsewhere (where the new terminal size will likely be
> different), or that the further processing doesn't bother with terminal
> columns or uses smarter methods like using '|' as field separators.

Counterexamples: any PAGER (more, less, ...), grep, sed, and virtually any
filter can interact with the terminal in a later stage of the pipeline.
In some cases like pagers there is *always* a terminal at the end.

> In other words, trying to columnize the output when the width is unknown
> (pipes or redirections) is a bit hacky and doesn't make much sense to
> me, and forcing it to be 80 for a lack of better default is not always a
> good solution as it might have been back in ~2000 (I think).

I agree that forcing to be 80 is hacky. But there is a better solution:
if the output isn't to a terminal (and -w is not passed), write the
entire output without truncating to any width size and let the next
process in the pipeline deal with it. If it's the last process before
going to terminal, I'm sure that program will have code to properly
adapt its output to the actual terminal size. In one sentence: delegate
the job to the process dealing with the terminal.


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#834402: aptitude: search loses column format when redirected or piped

[Javier Cantero]

Package: aptitude
Version: 0.8.3-1
Severity: normal

Dear Maintainer,

Compare this:

$  aptitude search "~i aptitude"
i   aptitude0.8.3-1 
   - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 
   - architecture independent files for the aptitude package manager

with the same output piped through `less`:

$  aptitude search "~i aptitude" | less
i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 - architecture independent files for the 
aptitude package manager

The same happens if the output is redirected to a file:

$  aptitude search "~i aptitude" > kk.txt
$  cat kk.txt 
i  aptitude 0.8.3-1 - gestor de paquetes basado en terminal
i A aptitude-common 0.8.3-1 - architecture independent files for the 
aptitude package manager

I've already read the discussion in #815690. but the thing is: piping to
more/less is a very common usage of aptitude search (since the lists of
packages tend to be very long), not just a special case for automatic
processing of the output. It's really annoying to have to remember to add
an arbitrary[*] width using `-w` in every `aptitude search ... | less`,
especially when it's a significant deviation from previous behaviour.


[*] arbitrary because usually it doesn't matter the actual width


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.3
Compiler: g++ 6.1.1 20160802
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.8.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160625
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fffd27cc000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7faf90684000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7faf90454000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7faf90229000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7faf90022000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7faf8fd25000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7faf8fa2)
libboost_iostreams.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.61.0 (0x7faf8f808000)
libboost_filesystem.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.61.0 (0x7faf8f5ef000)
libboost_system.so.1.61.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.61.0 (0x7faf8f3ea000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7faf8efe6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7faf8edc9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7faf8ea47000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf8e742000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7faf8e52c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf8e18a000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7faf8df87000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7faf8dd83000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7faf8db6b000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faf8d95)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7faf8d74)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7faf8d51c000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7faf8d30a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7faf8d101000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7faf8cefc000)
/lib64/ld-linux-x86-64.so.2 (0x5571f0e7b000)

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

Kernel: Linux 4.6.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages aptitude depends on:
ii  aptitude-common0.8.3-1
ii  libapt-pkg5.0  1.3~pre3
ii  libboost-filesystem1.61.0  1.61.0+dfsg-2.1
ii  libboost-iostreams1.61.0   1.61.0+dfsg-2.1
ii  libboost-system1.61.0  1.61.0+dfsg-2.1
ii  libc6  2.23-4
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.1.1-11
ii  libncursesw5   6.0+20160625-1
ii  libsigc++-2.0-0v5  2.8.0-2
ii  libsqlite3-0   3.13.0-1
ii  libstdc++6   

Bug#804170: workrave: Workrave resets system volume levels

[Javier Cantero]

Followup-For: Bug #804170
Package: workrave
Version: 1.10.15-3

Dear Maintainer,

I got this behaviour in the last version of workrave too. Luckily I
have found the source of the problem: pulseaudio flat volumes. To avoid
it, I have set "flat-volumes = no" in my ~/.config/pulse/daemon.conf
(/etc/pulse/daemon.conf also works for a system-wide solution instead of
an per-user one).

For a more comprehensive discussion about the use of pulseaudio flat
volumes by default in Debian see bug #541538:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541538


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

Kernel: Linux 4.6.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages workrave depends on:
ii  libatk1.0-0   2.20.0-1
ii  libatkmm-1.6-1v5  2.24.2-1
ii  libc6 2.23-1
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libcairomm-1.0-1v51.12.0-1+b1
ii  libdbusmenu-glib4 12.10.2-1
ii  libdbusmenu-gtk3-412.10.2-1
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-9
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libgdome2-0   0.8.1+debian-6
ii  libglib2.0-0  2.48.1-2
ii  libglibmm-2.4-1v5 2.48.1-1
ii  libgstreamer1.0-0 1.8.2-1
ii  libgtk-3-03.20.6-2
ii  libgtk2.0-0   2.24.30-2
ii  libgtkmm-3.0-1v5  3.20.1-1
ii  libice6   2:1.0.9-1+b1
ii  libindicator3-7   0.5.0-3
ii  libmate-panel-applet-4-1  1.14.1-1
ii  libpanel-applet0  3.20.0-1+b2
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpangomm-1.4-1v52.40.0-1
ii  libpulse-mainloop-glib0   9.0-1.1
ii  libpulse0 9.0-1.1
ii  libsigc++-2.0-0v5 2.8.0-1
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.1.1-9
ii  libx11-6  2:1.6.3-1
ii  libxfce4util7 4.12.1-2
ii  libxml2   2.9.3+dfsg1-1.2
ii  libxss1   1:1.2.2-1
ii  libxtst6  2:1.2.2-1+b1
ii  workrave-data 1.10.15-3
ii  xfce4-panel   4.12.0-4

workrave recommends no packages.

Versions of packages workrave suggests:
pn  gnome-panel  
pn  gnome-shell  

-- no debconf information

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#804170: workrave: Workrave resets system volume levels

[Javier Cantero]

Package: workrave
Version: 1.10.15-3
Followup-For: Bug #804170

Dear Maintainer,

I had also this behaviour in the last version of workrave. Luckily I
have found the source of the problem: pulseaudio flat volumes. To avoid
it, one simply can set "flat-volumes = no" in his/her
~/.config/pulse/daemon.conf (or /etc/pulse/daemon.conf if (s)he wants a
system-wide solution, instead of an per-user one).

For a more comprehensive discussion about pulseaudio flat volumes in Debian
by default, see bug #541538 [1]


 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541538

-- 
   Saludos de Javier 


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

Kernel: Linux 4.6.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages workrave depends on:
ii  libatk1.0-0   2.20.0-1
ii  libatkmm-1.6-1v5  2.24.2-1
ii  libc6 2.23-1
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libcairomm-1.0-1v51.12.0-1+b1
ii  libdbusmenu-glib4 12.10.2-1
ii  libdbusmenu-gtk3-412.10.2-1
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-9
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libgdome2-0   0.8.1+debian-6
ii  libglib2.0-0  2.48.1-2
ii  libglibmm-2.4-1v5 2.48.1-1
ii  libgstreamer1.0-0 1.8.2-1
ii  libgtk-3-03.20.6-2
ii  libgtk2.0-0   2.24.30-2
ii  libgtkmm-3.0-1v5  3.20.1-1
ii  libice6   2:1.0.9-1+b1
ii  libindicator3-7   0.5.0-3
ii  libmate-panel-applet-4-1  1.14.1-1
ii  libpanel-applet0  3.20.0-1+b2
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpangomm-1.4-1v52.40.0-1
ii  libpulse-mainloop-glib0   9.0-1.1
ii  libpulse0 9.0-1.1
ii  libsigc++-2.0-0v5 2.8.0-1
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.1.1-9
ii  libx11-6  2:1.6.3-1
ii  libxfce4util7 4.12.1-2
ii  libxml2   2.9.3+dfsg1-1.2
ii  libxss1   1:1.2.2-1
ii  libxtst6  2:1.2.2-1+b1
ii  workrave-data 1.10.15-3
ii  xfce4-panel   4.12.0-4

workrave recommends no packages.

Versions of packages workrave suggests:
pn  gnome-panel  
pn  gnome-shell  

-- no debconf information

Bug#803405: does not properly restore console colors on exit anymore

[Javier Cantero]

On Mon, Jul 18, 2016 at 12:33:37PM +0200, Evgeni Golov wrote:
> does that mean the bug against mutt can just be closed?

I would say yes (but I'm not the one who opened the bug).

Bug#803405: does not properly restore console colors on exit anymore

[Javier Cantero]

This bug has been fixed since the upload of ncurses 6.0+20160625-1. See
Bug #816887[1] for more details.

 [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816887

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#816887: libncursesw5: background color of mutt's message is black

[Javier Cantero]

Ok, I've been able to isolate the bug that sets the xfce4-term with
ncurses's default COLOR_WHITE/COLOR_BLACK foreground/background colors
after running a program using (colored) ncurses. This small example is
enough to trigger the incorrect behaviour:

#include 

int main(int argc, char **argv)
{
initscr();
if ( argc > 1 )
{
start_color();
if ( argc > 2 )
use_default_colors();
}

/*refresh();*/ /* this doesn't affect */
endwin();
/*refresh();*/ /* uncomment to fix */
endwin();

printw("This is a test\n");
getch();

endwin();

return 0;
}

Note: the number of arguments is used as a quickest way to change the
behaviour of the program in this way:

  ./test-ncurses # doesn't invoke start_color()
  ./test-ncurses foo # invokes start_color() but not use_default_colors()
  ./test-ncurses foo bar # invokes start_color() and use_default_colors()

The error is caused by the two consecutive endwin() function calls, but
only if start_color() has been previously called AND
use_default_colors() hasn't. So the bug is only reproducible using the
second of the 3 cases above (./test-ncurses foo). The other two cases
are provided only to prove the difference in behaviour.

One way to solve the problem is to ensure that use_default_colors() is
called after start_color(). Another way is to avoid any consecutive
calls to endwin() by introducing a wrefresh() call between them. In that
regard, the bug can also be fixed in the example above by uncommenting
the second call to refresh() (the one between both endwins).

This behaviour happens specifically in mutt because it doesn't
usually[1] call use_default_colors(), and because it calls endwin() a
lot[2]. The mutt developers have written a mutt_endwin() function,
supposedly to ensure that refresh() is always called before endwin(),
but there are still some locations in the code from where endwin() is
directly called, and unfortunately one of them[3] is the source of this
bug.

I'm explaining all of this because, from my current point of view, the
error is rather on the side of mutt than ncurses (and therefore it
should be fixed in mutt), but others may disagree. Perhaps Mr. Dickey
could bring some light on this, and about the expected behavior of the
endwind() function.


 [1]: for some reason use_default_colors() is not called just after
  start_color(), but delayed until the color settings have been read
  from the configuration files. The function is not even called
  except if one of the defined colors the "default" special value.
  Considering the default configuration doesn't use this "default"
  color, it's easy to see why mutt usually ends up not calling
  use_default_colors().

 [2]: mainly to execute external command line programs such as gpg or
  ispell

 [3]: http://sources.debian.net/src/mutt/1.6.0-1/init.c/#L3251

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#803405: does not properly restore console colors on exit anymore

[Javier Cantero]

I've found a way to fix this bug reverting a change in libncursesw5
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816887 ) but note
that this is not the definitive fix but a workaround (it's not clear
that the failure is in the library or because mutt is misusing it
somehow).

Another analysis of the bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825054#15

(Also #825054 should be merged here)


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#816887: libncursesw5: background color of mutt's message is black

[Javier Cantero]

I've found that the bug has been happening since this change:

http://invisible-island.net/ncurses/NEWS.html#t20151017

+ remove an early-return from _nc_do_color, which can interfere with
  data needed by bkgd when ncurses is configured with extended colors
  (patch by Denis Tikhomirov).

I've applied this patch (to undo it) and now mutt is working as before:

8<8<8<8<8<8<
diff -ru ncurses-6.0+20160319/ncurses/base/lib_color.c 
ncurses-6.0+20160319.new/ncurses/base/lib_color.c
--- ncurses-6.0+20160319/ncurses/base/lib_color.c   2015-10-17 
22:39:18.0 +0200
+++ ncurses-6.0+20160319.new/ncurses/base/lib_color.c   2016-06-07 
18:21:35.366456528 +0200
@@ -858,6 +858,8 @@
}
 } else {
reset_color_pair(NCURSES_SP_ARG);
+if (old_pair < 0)
+   return;
 }
 
 #if NCURSES_EXT_FUNCS
8<8<8<8<8<8<

Other ncurses applications don't exhibit the same behaviour, so maybe something
is wrong with mutt (but it's not easy to follow due to the large amount of
calls to refresh() and endwin() present in its code).


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#816887: libncursesw5: background color of mutt's message is black

[Javier Cantero]

Related bug report (against mutt):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803405

Note that this behaviour is happening since the upgrade to ncurses5
6.0+20151024-1 (the previous one was 6.0+20150810-1), for all the
recent versions of mutt including 1.6.1-1 (experimental).

For an in-depth analysis of the bug see this message:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825054#15


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#819164: fonts-texgyre: Error post-installation script (update-texmf-config: not found)

[Javier Cantero]

Package: fonts-texgyre
Version: 20150923-2
Severity: important

Dear Maintainer,

The recent version 20150923-2 can fail when configuring the package because the
postinst script calls to update-texmf-config, a script from the tex-common
package that can be no longer installed since #818548 removed the dependency
(that's my case):

# dpkg --configure --pending
Setting up fonts-texgyre (20150923-2) ...
/var/lib/dpkg/info/fonts-texgyre.postinst: 17: 
/var/lib/dpkg/info/fonts-texgyre.postinst: update-texmf-config: not found
dpkg: error processing package fonts-texgyre (--configure):
 subprocess installed post-installation script returned error exit 
status 127
Errors were encountered while processing:
 fonts-texgyre
#

Seems that the call to the script should be removed or alternatively the
tex-common dependency restored.


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

Kernel: Linux 4.4.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information




signature.asc
Description: PGP signature

Bug#816125: libsdl1.2debian: Remove DirectFB dependency

[Javier Cantero]

Package: libsdl1.2debian
Version: 1.2.15+dfsg1-2
Severity: wishlist

Dear Maintainer,

Due to the current status of DirectFB (the project seems dead) and also
the status of the debian package (currently unfit for release), can I
suggest that future releases drop the dependency by not compiling SDL
1.2 with DirectFB support?

Thank you for your time and consideration.

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

Kernel: Linux 4.4.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsdl1.2debian depends on:
ii  libasound2 1.1.0-1
ii  libc6  2.21-9
ii  libcaca0   0.99.beta19-2+b1
ii  libdirectfb-1.2-9  1.2.10.0-5.2
ii  libpulse0  8.0-1
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1

libsdl1.2debian recommends no packages.

libsdl1.2debian suggests no packages.

-- no debconf information

Bug#807403: wine: Sound doesn't work anymore with Windows games

[Javier Cantero]

Package: wine
Version: 1.8~rc3-1
Followup-For: Bug #807403

I can confirm this bug, from 1.7.55 (the first version with winepulse)
to the current 1.8-rc3. I can also confirm that the proposed solution
works fine.

Note that despite the bug, certain games with certain sound formats
(i.e. 8bit instead 32bit) the buffer size with PULSE_LATENCY_MSEC=60 can
be enough and the sound works (for instance this happens to me with the
intro part of certain game). For a 32bit-stereo format (4*2 = 8 bytes)
you need to set PULSE_LATENCY_MSEC=200 at least. I rather prefer to let
pulseaudio to calculate itself the size of the buffer automatically
(that's what the proposed fix is doing, getting rid of the environment
variable at all). There is so much documentation out there advising to
change that value that I think the problem is going to stay with us for
a while until all the people using winepulse change their configs. Maybe
it's worth to annotate this somewhere (in the Debian Wine wiki page?).

An alternative solution is to configure wine to use winealsa.drv again,
by changing the value of the "Audio" key to "alsa" in the
HKEY_CURRENT_USER\Software\Wine\Drivers directory of the registry. This
is usually done with the regedit.exe tool (wine regedit.exe). The value
"pulse" restore the use of winepulse.drv.

Using winealsa.drv the sound should work exactly as it worked in prior
versions to 1.7.55. It works even if you are using alsa-libs wrapper to
send the audio to pulseaudio daemon (so actually using PA, not ALSA)
with libasound2-plugins:i386 package. I don't think it's worth to use
with this configuration, it adds an extra level with no gain. However,
some people may prefer to use ALSA directly -without the wrapper thing-,
to avoid completely PA (note this has certain disadvantages which I will
not enumerate here).


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

Kernel: Linux 4.2.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wine depends on:
ii  wine32  1.8~rc3-1

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox   
pn  wine-binfmt  

Versions of packages wine is related to:
ii  fonts-wine1.8~rc3-1
ii  libwine   1.8~rc3-1
pn  libwine-dbg   
pn  libwine-dev   
ii  wine  1.8~rc3-1
ii  wine321.8~rc3-1
pn  wine32-preloader  
pn  wine32-tools  
pn  wine64
pn  wine64-preloader  
pn  wine64-tools  

-- no debconf information




signature.asc
Description: PGP signature

Bug#800723: thunar: intermittent segfault on file drag and drop

[Javier Cantero]

On Sun, Nov 15, 2015 at 05:46:27PM +1300, Ben Caradoc-Davies wrote:
> Today I saw a single crash with Drag, so this bug does still occur, but
> only when not trying to reproduce it.  :-|

Sounds like the bug should be reopened.

More info from the Xfce bugtracker:
https://bugzilla.xfce.org/show_bug.cgi?id=12260
https://bugzilla.xfce.org/show_bug.cgi?id=12264




signature.asc
Description: PGP signature

Bug#800723: thunar: intermittent segfault on file drag and drop

[Javier Cantero]

On Fri, Nov 13, 2015 at 02:43:06PM +1300, Ben Caradoc-Davies wrote:
 
Thank you Ben for the info.

I've trying to reproduce your package versions, picking up the different
ones from unstable (see below my current versions). I even have removed
gvfs* packages (they are Recommends:, not dependencies) but the bug is
still reproducible here.

However, I'd like to note that I'm using Cut context menu
operations rather than Drag to trigger it. With Drag is hardly
reproducible (I've only seen 1 time since the change to glib 2.46.2-1),
but I can easily crash Thunar simply by cutting and pasting a pair of
small files (a text file and an image file) in other directory. 

> This failure looked to me like heap corruption caused by a thread race
> condition while moving files.

Agree.I suspect the memory corruption could have several sources, and
the 2.46.2 update fixes a few, but not all.

Also #804816 is suspiciously similar.


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

Kernel: Linux 4.2.6-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunar depends on:
ii  desktop-file-utils  0.22-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.19-22
ii  libcairo2   1.14.4-1
ii  libdbus-1-3 1.10.2-1
ii  libdbus-glib-1-20.102-1
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.32.2-1
ii  libglib2.0-02.46.2-1
ii  libgtk2.0-0 2.24.28-1
ii  libgudev-1.0-0  230-2
ii  libice6 2:1.0.9-1+b1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.38.1-1
ii  libsm6  2:1.2.2-1+b1
ii  libthunarx-2-0  1.6.10-2
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2
ii  libxfconf-0-2   4.12.0-2+b1
ii  shared-mime-info1.5-2
ii  thunar-data 1.6.10-2

Versions of packages thunar recommends:
ii  dbus-x11 1.10.2-1
pn  gvfs 
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  thunar-volman0.8.1-2
ii  tumbler  0.1.31-2+b2
ii  xdg-user-dirs0.15-2
ii  xfce4-panel  4.12.0-3

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information


-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#723990: youtube-dl: python3+ requirement

[Javier Cantero]

> The problem is that I don't know how to make it work with both Python 2 or
> Python 3, while still satisfying the following two points:
> 
> * Without creating extra binary packages (and having to go through the NEW
>   queue of the ftp-masters).
> 
> * Without making any use of any hackish, non-readable tricks.  Note that the
>   package currently has modules that should be usable for any version of
>   Python that we propose to support.
> 
> I would love some help with this.

There is an easy solution: to make it only a python 3 package, since the
Debian Python Policy[1] says[2]: "Packages in Debian should use Python 3
if Python 3 is supported." And also in the same page: "Programs should
use Python 3, and should not be packaged for Python 2 as well."

I think that youtube-dl supports python 3.2+ (or at least that says the
homepage). If it works with python 3, it's the perfect excuse to make
the transition now rather than wait until year 2020, and you don't need
to worry about maintaining duplicated packages or anything hackish.


 [1]: https://www.debian.org/doc/packaging-manuals/python-policy/
 [2]: https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#800723: thunar: intermittent segfault on file drag and drop

[Javier Cantero]

El Thu, Nov 12, 2015 at 11:39:57AM +1300, Ben Caradoc-Davies dice:
> I can no longer reproduce this failure on unstable. It may have been fixed
> upstream. (In glib, perhaps?)
> 
> Kind regards,

I've manually installed libglib2.0-0_2.46.2-1_amd64.deb (and -bin and
-dev) from unstable, but the bug is still reproducible here. Do you know
of other changes apart from the upgrade to glib 2.46.2?

-- 
   Saludos de Javier 




signature.asc
Description: PGP signature

Bug#803405: does not properly restore console colors on exit anymore

[Javier Cantero]

Package: mutt
Version: 1.5.24-1
Followup-For: Bug #803405

Dear Maintainer,

This bug is also in Stretch since the upgrade of ncurses5/libtinfo5
(occurred on November 5) from the previous version 6.0+20150810-1 to the
current 6.0+20151024-1.

-- Package-specific info:
Mutt 1.5.24 (2015-08-30)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.2.5-amd64 (x86_64)
ncurses: ncurses 6.0.20151024 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-17' 
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-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 --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20150911 (Debian 5.2.1-17) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch
debian-specific/document_debian_defaults.patch
debian-specific/assumed_charset-compat.patch
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.patch
misc/gpg.rc-paths.patch
misc/smime.rc.patch
misc/fix-configure-test-operator.patch
upstream/531430-imapuser.patch
upstream/543467-thread-segfault.patch
upstream/548577-gpgme-1.2.patch
upstream/553321-ansi-escape-segfault.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/603288-split-fetches.patch
upstream/611410-no-implicit_autoview-for-text-html.patch
upstream/771125-CVE-2014-9116-jessie.patch
upstream/path_max.patch

Bug#804581: redshift-gtk: python-gtk2 dependency is no longer needed

[Javier Cantero]

Package: redshift-gtk
Version: 1.10-5
Severity: minor

Dear Maintainer,

Please consider to drop python-gtk2 dependency from redshift-gtk. PyGTK2
is not longer used as a python GTK+ binding in redshift-gtk since the
upstream commit b436a6cd8ecee8a15686f3da92f2c66d0b4aa8af [1] where it
was migrated to the new GObject Introspection (GI) binding mechanism
[2][3].

Also note that python-gtk2 nowadays is a deprecated package. Dropping
the already settled dependency facilitates the future transition to
python-gi/python3-gi.

  [1]: 
https://github.com/jonls/redshift/commit/b436a6cd8ecee8a15686f3da92f2c66d0b4aa8af
  [2]: https://wiki.gnome.org/Projects/GObjectIntrospection
  [3]: https://wiki.gnome.org/Projects/PyGObject/IntrospectionPorting


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

Kernel: Linux 4.2.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages redshift-gtk depends on:
ii  gir1.2-appindicator3-0.1  0.4.92-3.1
ii  python-gtk2   2.24.0-4
ii  python3   3.4.3-7
ii  python3-gi3.18.2-2
ii  python3-xdg   0.25-4
pn  python3:any   
ii  redshift  1.10-5

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.18.1-2

redshift-gtk suggests no packages.

-- no debconf information





signature.asc
Description: PGP signature

Bug#800723: intermittent segfault on file drag and drop

[Javier Cantero]

On Fri, Oct 30, 2015 at 10:50:39AM +0100, jEsuSdA 8) wrote:
> I try to downgrade libglib2 to 2.44 from 2.46 and there is impossible. The
> new packages depends on 2.46 and if I downgrade the system brokes.

The downgrade was just to check what package was the source of the bug,
not to solve it. I don't recommend you to downgrade any packages, but to
wait that Thunar developers and package maintainers release a patched
version.

> Maybe the bug must solved from Thunar itself.
 
Indeed.




signature.asc
Description: PGP signature

Bug#800723: intermittent segfault on file drag and drop

[Javier Cantero]

Additional info:

This bug seems to be related to upstream bug #12253:
https://bugzilla.xfce.org/show_bug.cgi?id=12253

So I've downgraded glib-2.0 to the previous testing package
(libglib2.0-0_2.44.1-1.1_amd64.deb from snapshot.d.o) and I found that
the bug is not present with that version. Then I upgraded to glib 2.46
again, and the bug reappears.

Bug#800723: intermittent segfault on file drag and drop

[Javier Cantero]

Package: thunar
Version: 1.6.10-2
Followup-For: Bug #800723

Dear Maintainer,

I found the same error here. When I try to cut and paste a pair of files
into a subdirectory, Thunar crashes:

$ /usr/bin/Thunar 

(Thunar:7281): GLib-GObject-WARNING **: invalid uninstantiatable type 
'(null)' in cast to 'GObject'

(Thunar:7281): GLib-GObject-CRITICAL **: g_object_set_qdata: assertion 
'G_IS_OBJECT (object)' failed

(Thunar:7281): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed
*** Error in `/usr/bin/Thunar': malloc(): smallbin double linked list 
corrupted: 0x561632084230 ***
Aborted

Not every run shows the same final error message:

$ /usr/bin/Thunar 

(Thunar:7290): GLib-GObject-WARNING **: invalid uninstantiatable type 
'(null)' in cast to 'GObject'

(Thunar:7290): GLib-GObject-CRITICAL **: g_object_set_qdata: assertion 
'G_IS_OBJECT (object)' failed

(Thunar:7290): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed
*** Error in `/usr/bin/Thunar': munmap_chunk(): invalid pointer: 
0x55a982e4f7e0 ***
Aborted

Sometimes it's a segmentation fault:

$ /usr/bin/Thunar 

(Thunar:7296): GLib-GObject-WARNING **: invalid uninstantiatable type 
'' in cast to 'GObject'

(Thunar:7296): GLib-GObject-CRITICAL **: g_object_set_qdata: assertion 
'G_IS_OBJECT (object)' failed

(Thunar:7296): GLib-GObject-CRITICAL **: g_object_unref: assertion 
'G_IS_OBJECT (object)' failed

(Thunar:7296): GLib-GIO-CRITICAL **: g_file_query_info: assertion 
'G_IS_FILE (file)' failed



(Thunar:7296): GLib-GIO-CRITICAL **: g_file_get_basename: assertion 
'G_IS_FILE (file)' failed
Segmentation fault

And sometimes Thunar doesn't crash at first try. Here I had to repeat
the operation before I got the crash:

$ /usr/bin/Thunar 

(Thunar:7316): GLib-GObject-WARNING **: invalid uninstantiatable type 
'(null)' in cast to 'GObject'

(Thunar:7316): GLib-GObject-CRITICAL **: g_object_set_qdata: assertion 
'G_IS_OBJECT (object)' failed
Segmentation fault

It has to be some recent change because I didn't see this behaviour
until today.


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

Kernel: Linux 4.2.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages thunar depends on:
ii  desktop-file-utils  0.22-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.19-22
ii  libcairo2   1.14.2-2
ii  libdbus-1-3 1.10.0-3
ii  libdbus-glib-1-20.102-1
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.32.1-1
ii  libglib2.0-02.46.0-2
ii  libgtk2.0-0 2.24.28-1
ii  libgudev-1.0-0  230-2
ii  libice6 2:1.0.9-1+b1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.38.0-3
ii  libsm6  2:1.2.2-1+b1
ii  libthunarx-2-0  1.6.10-2
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-2
ii  libxfconf-0-2   4.12.0-2+b1
ii  shared-mime-info1.5-2
ii  thunar-data 1.6.10-2

Versions of packages thunar recommends:
ii  dbus-x11 1.10.0-3
ii  gvfs 1.26.0-2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libpangocairo-1.0-0  1.38.0-3
ii  libpangoft2-1.0-01.38.0-3
ii  thunar-volman0.8.1-2
ii  tumbler  0.1.31-2+b1
ii  xdg-user-dirs0.15-2
ii  xfce4-panel  4.12.0-3

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.3.1-4
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#800459: aptitude: Auto-flagged dependencies of a renaming package get lost during an upgrade

[Javier Cantero]

Package: aptitude
Version: 0.7.2-1
Severity: normal

Dear Maintainer,


There are a quite number of bug reports in the BTS about the loss of the
Auto flag of package dependencies in several scenarios using aptitude.
I've found a totally reproducible scenario that might or might not be
the root cause of one or several of those bugs, so I've decided to open
a new separate bug report for this case. Please merge it to the
appropiate bug report if you consider it's the same problem.

Also note that this is the only case that I've found that causes the
loss of the Auto flag (at least nowadays), but that doesn't mean that
there is the only one that exists.

In all the scenarios that I've found, an `aptitude upgrade' that caused
the loss of the Auto flags always have a renaming package involved, such
as python-pelican to pelican, or the transition from libav* to
libav*-ffmpeg. To prove my suspicions, I built a synthetic test case in
which a package called A with several dependencies is renamed (and
replaced) by a package A'. The exact dependencies between packages I've
choose to test are better described with a diagram (more about the
selected configuration later):

   http://www.escomposlinux.org/jcantero/ld/images/aptitude-bug-3.png

(Grey box means the package has the Auto flag set)

For the procedure of renaming the package I've followed the
recommendations and practices described in the Debian wiki[1].

The results show that aptitude loses the Auto flag of all the
dependencies of the renaming package A', not only the direct
dependencies that migrate from the "Depends:" of package A to the
"Depends:" of package A', but also the dependencies of these
dependencies, and so on (recursively). This applies in the above diagram
to B, C, D, E, F, G, H and J packages.

But there is one important exception to this behavior: a package with a
reverse dependence from a different package doesn't lose its Auto flag.
This seems to happen regardless of its position in the dependency graph.
In the above diagram the package Z prevents D (and therefore H) to lose
their Auto flag.

The final state of the package Auto flags after the `aptitude upgrade'
is:

   http://www.escomposlinux.org/jcantero/ld/images/aptitude-bug-4.png

You can build and test yourself that configuration (or one equivalent),
for instance using equivs to create the packages. I have done my own
source packages (you can find them in my git repo[2] ready to be built
with a `make packages') and all the tests that I've done with them
confirm the hypothesis. I can send you the logs with the output of the
different aptitude commands if you want, but you should be able to
reproduce them by your own using the information provided.

One more thing: I've tested apt-get too, and it's not affected. After
the `apt-get upgrade' the Auto flags remains in place.


 [1]: https://wiki.debian.org/Renaming_a_Package
 [2]: 
https://github.com/javiercantero/apt-repo-testsuite/tree/master/tests/renaming-package


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.7.2 compiled at Sep 19 2015 16:51:55
Compiler: g++ 5.2.1 20150903
Compiled against:
  apt version 4.16.0
  NCurses version 6.0
  libsigc++ version: 2.4.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20150810
  cwidget version: 0.5.17
  Apt version: 4.16.0

aptitude linkage:
linux-vdso.so.1 (0x7ffeedb57000)
libapt-pkg.so.4.16 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.16 
(0x7fc62c69a000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7fc62c46a000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fc62c23f000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fc62c039000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7fc62bd3a000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fc62ba6c000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7fc62b853000)
libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7fc62b451000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fc62b233000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fc62aeb8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc62abb7000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fc62a9a)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc62a5f7000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc62a3f4000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc62a1ef000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc629fd4000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fc629dc4000)
liblzma.so.5 => 

Bug#654633: XFCE4-VOLUMED: mute and set the volume to 0, when I unmute it, it leave the volume in 0

[Javier Cantero]

The solution to this bug:

  1.- Install gstreamer0.10-pulseaudio (if it's not installed)
  2.- Logoff from yout Xfce session and login again (this is to make
  Xfce aware of the change)
  3.- Choose the PulseAudio Mixer you want to use from the mixer
  selection list[1] of xfce4-mixer (if xfce4-mixer doesn't let you
  change the mixer, that's because you skipped step 2.)

Now the volume and mute multimedia keys should work as intended, but
they **only work with the selected PulseAudio device**, not with any PA
sink (specifically not with a global scope).

Also, if you have pluggable devices (like a bluetooth headset), the
device is listed when it's on, but xfce4-mixer doesn't going to let you
select it. The device should be connected **before** you log in the Xfce
session in order to xfce4-mixer let you choose its mixer. This of course
is not very useful with a dynamic pluggable-style device.


[1]: 
http://www.escomposlinux.org/jcantero/ld/images/xfce4-mixer-pulseaudio-choice.png

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#754155: xfce4-volumed: Volume notify pops up every time a system event sound is playing

[Javier Cantero]

I was also suffering this bug since I recently installed PulseAudio, and
I only got rid of it when I installed the package
gstreamer0.10-pulseaudio (it was not installed by pulseaudio
dependencies) and I was able to configure xfce4-mixer with a PulseAudio
Mixer instead of the Alsa Mixer (see [1])

Like I said in bug #654633, in order to xfce4-mixer let you select the
right option, after installing the package, a restart of the Xfce
session (just a logoff and relogin) is required, or it won't work.

I hope this also fix the bug in your system.


[1]: 
http://www.escomposlinux.org/jcantero/ld/images/xfce4-mixer-pulseaudio-choice.png

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#777178: pulseaudio: Pulseaudio often crashes. Makes crackling sound on (re)start

[Javier Cantero]

I have been bitten by this bug as well. pavucontrol provokes the death
of PA daemon due to the failed assertion, then PA is relaunched, but
dies again when pavucontrol reconnects, and so on in an infinite loop .
Visually, pavucontrol seems frozen, but in the background PA is
continuously dying and restarting.

The bug was fixed in this commit[1]: the asserts triggering the
situation are removed there. The commit is present from version 5.99.1
onwards (the github interface shows the tags where the commit is
included).

The commit message links to this bug in FO bugzilla[2]. The source of
the bug, according to that, is the supported rate reported by the kernel
module snd-pcsp to PA.

Now, as I see, there are two solutions to this bug. The obvious is to
use pulseaudio 6.0. But what I have done is to compile my kernel without
snd-pcsp module. The reason is the Kconfig help message:

 CONFIG_SND_PCSP:

  If you don't have a sound card in your computer, you can include a
  driver for the PC speaker which allows it to act like a primitive
  sound card.
  This driver also replaces the pcspkr driver for beeps.

  You can compile this as a module which will be called snd-pcsp.

  WARNING: if you already have a soundcard, enabling this
  driver may lead to a problem. Namely, it may get loaded
  before the other sound driver of yours, making the
  pc-speaker a default sound device. Which is likely not
  what you want. To make this driver play nicely with other
  sound driver, you can add this in a configuration file under
  /etc/modprobe.d/ directory:
  options snd-pcsp index=2

  You don't need this driver if you only want your pc-speaker to beep.
  You don't need this driver if you have a tablet piezo beeper
  in your PC instead of the real speaker.

  Say N if you have a sound card.
  Say M if you don't.
  Say Y only if you really know what you do.

Note that Debian standard kernels include this option by default.

Without CONFIG_SND_PCSP in the kernel, now pavucontrol and pulseaudio 5.0-13
are working.


[1]: 
https://github.com/pulseaudio/pulseaudio/commit/42c814b9f320c5868fac98b4291265ca00e79fde
[2]: https://bugs.freedesktop.org/show_bug.cgi?id=48109

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#778692: lincity: Wrong Version value in the lincity.desktop file

[Javier Cantero]

Package: lincity
Version: 1.13.1-11
Severity: minor

Dear Maintainer,

The Version field of the lincity.desktop file contains a wrong
value. It should contain the version of the Desktop Entry Specification
used in the .desktop file (see [1]), not the version of the program.
It's common to use the value 1.0 (see [2] for an example of .desktop
files for games) but there is a more recent 1.1 version from 2014, so
either of two, 1.0 or 1.1, is perfectly valid.

May I also suggest two additional changes in the lincity.desktop file?
First, the GenericName key is defined in the specification as 'Generic
name of the application, for example Web Browser.' I suggest to use
the value City Simulation Game instead Lincity there. It may also be
worth to add the TryExec key pointing to the executable (if the
executable is not found, the menu entry is hidden).

I am sending the proposed changes to lincity.desktop in patch format for
your consideration.

[1]: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
[2]: https://wiki.debian.org/Games/JessieReleaseGoal

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.7-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lincity depends on:
ii  libc6   2.19-13
ii  libice6 2:1.0.9-1+b1
ii  libpng12-0  1.2.50-2+b2
ii  libsm6  2:1.2.2-1+b1
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

lincity recommends no packages.

lincity suggests no packages.

-- no debconf information

-- 
   Saludos de Javier jcant...@escomposlinux.org


2c2
 Version=1.13.1
---
 Version=1.0
5c5
 GenericName=Lincity
---
 GenericName=City Simulation Game
7a8
 TryExec=xlincity


signature.asc
Description: Digital signature

Bug#778684: beneath-a-steel-sky: SVG icon installed on wrong resolution directory

[Javier Cantero]

Package: beneath-a-steel-sky
Version: 0.0372-5
Severity: minor

Dear Maintainer,

This is a bit nitpick, but the SVG icon should be installed in:

   /usr/share/icons/hicolor/scalable/apps/beneath-a-steel-sky.svg

with the rest of .svg icons, not in /usr/share/icons/hicolor/128x128/
(that's for fixed resolution icons in .png and .xpm formats).

See [1] for the FreeDesktop standard Icon Theme Specification.

 [1]: 
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.7-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beneath-a-steel-sky depends on:
ii  scummvm  1.7.0+dfsg-1+b1

beneath-a-steel-sky recommends no packages.

beneath-a-steel-sky suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778687: scummvm-data: Icons installed in wrong directory

[Javier Cantero]

Package: scummvm-data
Version: 1.7.0+dfsg-1
Severity: minor

Dear Maintainer,

The icon files scummvm.svg and scummvm.xpm are installed in the wrong
directory /usr/share/icons. That is the base directory for themes, one
subdirectory for each theme plus the default hicolor subdirectory.
They instead should be installed in:

   /usr/share/icons/hicolor/scalable/apps/scummvm.svg
   /usr/share/pixmaps/scummvm.xpm

The .xpm file can alternative be installed in
/usr/share/icons/hicolor/32x32/apps/ but /usr/share/pixmaps/ is a better
choice because it complies with Debian Menu System guidelines[1] and
acts as a fallback in the FreeDesktop Icon Theme Specification[2].

[1]: https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.7
[2]: http://standards.freedesktop.org/icon-theme-spec/latest/ar01s03.html

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (600, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.7-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#730405: freeorion: input textfields doesn't work after a while.

[Javier Cantero]

Since libOIS upstream is apparently dead, and the projects that use it (mostly
games[1] using Ogre3D libraries like freeorion) are gradually abandoning this
library (including Ogre3D), clearly the bug will never be resolved.

So I want to sumarize my last discoveries about the bug itself. First, 
the bug is caused by a weird interaction with xscreensaver. The behaviour of
xscreensaver in some way causes the appearance of the unexpected KeyRelease
events that leads to the libOIS misbehaviour already explained. More details
here: http://www.freeorion.org/forum/viewtopic.php?p=70165#p70165

My suspects of the root of the problem are detailed here:
http://www.freeorion.org/forum/viewtopic.php?p=71435#p71435 Long explanation
short: I think the bug could be in X.Org Server event queue handling code, but
that code is too complex (and prone to errors) to be worth check it without a
good reason (and there is no good reason if upstream and dowstream are not going
to apply any patches).

So I recommend to anyone affected by this bug to talk to the developers of the
application to move away from libOIS to another library with actual suport (like
SDL). It's going to be a better solution in the long term.


[1] By the way, it's a bit strange that libOIS is under the umbrella of Debian
Multimedia Maintainers instead of Debian Games Team due to its nature and
users.



signature.asc
Description: Digital signature

Bug#559927: /usr/lib/avahi/avahi-daemon-check-dns.sh significantly delays the boot sequence

[Javier Cantero]

Package: avahi-daemon
Version: 0.6.31-4
Followup-For: Bug #559927

Dear Maintainer,

This bug is still present in the current version of avahi-daemon. In my case,
the delay introduced by the 'host -t soa local.' of avahi-daemon-check-dns.sh is
exactly of 10 seconds, always. I've patched the script to measure the elapsed
time (the patch is attached below), and logged the boot sequence using 
bootlogd. I
include you an example of the output (ASCII color codes removed).

The thing is I am using my own DNS server, so I have in my /etc/resolv.conf:

nameserver 127.0.0.1

When the ifup of the eth0 invokes avahi-daemon-check-dns.sh, the bind9 daemon is
not running yet, and probably the 'host' command is running out its timeouts
trying to resolve the .local zone without success. If I use remote DNS servers
in /etc/resolv.conf, the script is working as intended and the delayed time is
about 2 seconds (that time depends of the latency of the DNS server responses
obviously).

Note that later, when the system already boots up and bind9 is running, the time
of a invocation to 'host -t soa local.' is less than 0.1 seconds, 0.01 in the
median time (when cached):

$ time host -t soa local.
Host local. not found: 3(NXDOMAIN)

real0m0.088s
user0m0.008s
sys 0m0.000s

I know this delay can be avoided by disabling the check of the unicast .local
zone using AVAHI_DAEMON_DETECT_LOCAL=0 in /etc/default/avahi-daemon. But I'd
like to say that the assumption that you can always make a DNS resolution after
the interface is up is a risky one, and in a local DNS configuration is
blantanly false. Perhaps you could consider to move the checking just when the
avahi daemon is launched, and not as a part of the ifupdown process (that can
also introduce the delay not only in the boot sequence but also in the shutdown
process).


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.15.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages avahi-daemon depends on:
ii  adduser  3.113+nmu3
ii  bind9-host [host]1:9.9.5.dfsg-4
ii  dbus 1.8.4-1
ii  init-system-helpers  1.19
ii  libavahi-common3 0.6.31-4
ii  libavahi-core7   0.6.31-4
ii  libc62.19-1
ii  libcap2  1:2.22-1.2
ii  libdaemon0   0.14-6
ii  libdbus-1-3  1.8.4-1
ii  libexpat12.1.0-6
ii  lsb-base 4.1+Debian13

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.10-6

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  none

-- no debconf information
57a58,59
   DEBUG_HOST_CMD_TIME=`LC_ALL=C date +%T`
   echo \n[$DEBUG_HOST_CMD_TIME] Before calling host -t soa local.
59a62,63
 DEBUG_HOST_CMD_TIME=`LC_ALL=C date +%T`
 echo [$DEBUG_HOST_CMD_TIME] After calling host -t soa local.
63a68,69
 DEBUG_HOST_CMD_TIME=`LC_ALL=C date +%T`
 echo [$DEBUG_HOST_CMD_TIME] After calling host -t soa local.
Sun Jun 22 09:27:08 2014: [] Setting parameters of disc: (none) [ok] .
Sun Jun 22 09:27:08 2014: [] Setting preliminary keymap... [ok] done.
Sun Jun 22 09:27:08 2014: [] Activating swap... [ok] done.
Sun Jun 22 09:27:08 2014: [] Checking root file system...fsck from 
util-linux 2.20.1
Sun Jun 22 09:27:09 2014: /dev/sda2: clean, 155869/3055616 files, 
2107894/12207104 blocks
Sun Jun 22 09:27:09 2014:  [ok] done.
Sun Jun 22 09:27:09 2014: [] Activating lvm and md swap... [ok] done.
Sun Jun 22 09:27:09 2014: [] Checking file systems...fsck from util-linux 
2.20.1
Sun Jun 22 09:27:10 2014: /dev/sda3: clean, 239788/12214272 files, 
16711162/48828160 blocks
Sun Jun 22 09:27:10 2014:  [ok] done.
Sun Jun 22 09:27:10 2014: [] Cleaning up temporary files... /tmp [ok] .
Sun Jun 22 09:27:10 2014: Loading kernel module firewire-sbp2.
Sun Jun 22 09:27:10 2014: modprobe: FATAL: Module firewire-sbp2 not found.
Sun Jun 22 09:27:10 2014: Loading kernel module loop.
Sun Jun 22 09:27:10 2014: Loading kernel module coretemp.
Sun Jun 22 09:27:10 2014: Loading kernel module f71882fg.
Sun Jun 22 09:27:10 2014: Loading kernel module coretemp.
Sun Jun 22 09:27:10 2014: Loading kernel module f71882fg.
Sun Jun 22 09:27:10 2014: Loading kernel module fuse.
Sun Jun 22 09:27:10 2014: [] Mounting local filesystems... [ok] done.
Sun Jun 22 09:27:10 2014: [] Activating swapfile swap... [ok] done.
Sun Jun 22 09:27:10 2014: [] Cleaning up temporary files... [ok] .
Sun Jun 22 09:27:11 2014: [] Setting kernel variables ... [ok] done.
Sun Jun 22 09:27:14 2014: [] Configuring network interfaces...
Sun Jun 22 09:27:14 2014: [09:27:12] Before calling host -t soa local.
Sun Jun 22 09:27:22 2014: [09:27:22] After calling host -t soa local.
Sun Jun 22 09:27:22 2014:  [ok] done.
Sun Jun 22 

Bug#750907: kernel-package 13.013 has xmlto as a Dependency instead a Suggestion

[Javier Cantero]

After a litte digging in the BTS, I just found that the option I was using in
.aptitude/config was WRONG, and I should use another option to not install the
Recommends packages. Now, the upgrade of kernel-package seems fine:

   # aptitude upgrade
   Resolving dependencies...
   The following NEW packages will be installed:
 docbook-xsl{a} libxml2-utils{a} xmlto{a} xsltproc{a} 
   The following packages will be upgraded:
 kernel-package 
   The following packages are RECOMMENDED but will NOT be installed:
 dblatex docbook-utils fop kernel-common 

   # aptitude install kernel-package
   The following NEW packages will be installed:
 docbook-xsl{a} libxml2-utils{a} xmlto{a} xsltproc{a} 
   The following packages will be upgraded:
 kernel-package 
   The following packages are RECOMMENDED but will NOT be installed:
 dblatex docbook-utils fop kernel-common 
   
Sorry, It's my fault to not recheck what's going on before opening the bug.

Now the number of packages involved seems rather small (but maybe I already
have installed the XML/docbook stuff), so I don't know what to say, if it's
better a Depends: or a Recommends: to xmlto package. In any case, I consider
this bug solved.

Thank you for your patience.

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#750907: kernel-package 13.013 has xmlto as a Dependency instead a Suggestion

[Javier Cantero]

On Sun, Jun 08, 2014 at 11:22:24PM -0700, Manoj Srivastava wrote:
 
Hi,

 Perhaps a compromise might be to move the dependency to
  recommends, and make a note in the man page and coumentation about the
  need for xmlto in order build all the documentation?

I've researching a bit more, and I've found that the Recommends: dblatex | fop
part of the xmlto dependencies is what causes the behaviour (fop depends on Java
and dblatex, well, on LaTeX and so). So I guess there is not much difference
between having a Depends: or a Recommends: to xmlto.

I already have aptitude::Ignore-Recommends-Important to true in the aptitude
config file, but clearly it's not working as intended, because if I use a
explicit --without-recommends:

   # aptitude upgrade --without-recommends
   Resolving dependencies...
   The following NEW packages will be installed:
 docbook-xsl{a} libxml2-utils{a} xmlto{a} xsltproc{a} 
   The following packages will be upgraded:
 kernel-package 
   The following packages are RECOMMENDED but will NOT be installed:
 dblatex docbook-utils fop kernel-common 

Now it's ignoring fop and dblatex and their dependencies. And also does the
manual upgrade:

   # aptitude install kernel-package --without-recommends
   The following NEW packages will be installed:
 docbook-xsl{a} libxml2-utils{a} xmlto{a} xsltproc{a} 
   The following packages will be upgraded:
 kernel-package 
   The following packages are RECOMMENDED but will NOT be installed:
 dblatex docbook-utils fop kernel-common 

Ok, sorry for the inconvenience, you can close the bug. I going to look if this 
behaviour is what aptitude is suppose to do, or it's a bug.



signature.asc
Description: Digital signature

Bug#750907: kernel-package 13.013 has xmlto as a Dependency instead a Suggestion

[Javier Cantero]

Package: kernel-package
Version: 13.003
Severity: normal

Dear Maintainer,

The recenctly introduced 13.013 version has a Depends: dependency with the
xmlto package, while the previous version in testing (13.003) it was a
Suggests:

   Package: kernel-package  
   New: yes
   State: installed [held]
   Automatically installed: no
   Version: 13.003
   Priority: optional
   Section: kernel
   Maintainer: Manoj Srivastava srivasta@...
   Architecture: all
   Uncompressed Size: 1798 k
   Depends: build-essential, make (= 3.80-10), po-debconf, gettext, file,
 debianutils (= 2.30), binutils (= 2.12), util-linux (= 2.10o), kmod, bc
   Recommends: docbook-utils, cpio
   Suggests: linux-source, e2fsprogs (= 1.41.4), libncurses-dev, xmlto, bzip2,
 linux-initramfs-tool, grub (= 0.93) | grub2, jfsutils (= 1.1.3), mcelog
 (= 0.6), oprofile (= 0.9), pcmciautils (= 004), ppp (= 2.4.0), procps
 (= 3.2.0), reiserfsprogs (= 3.6.3), squashfs-tools (= 4.0), udev (=
 081), xfsprogs (= 2.6.0), quota, btrfs-tools, liblz4-tool

This means that the last update of kernel-package is trying to install a bunch
of new packages including Java Run Time environment and its dependencies:

   # aptitude upgrade
   Resolving dependencies...
   The following NEW packages will be installed:
 docbook-xsl{a} fop{a} gcj-4.9-jre-headless{a} gcj-4.9-jre-lib{a} 
 java-wrappers{a} libapache-pom-java{a} libavalon-framework-java{a} 
 libbatik-java{a} libbsf-java{a} libcommons-io-java{a} 
 libcommons-logging-java{a} libcommons-parent-java{a} libfop-java{a} 
 libgcj-common{a} libgcj15{a} libjaxp1.3-java{a} libjline-java{a} 
 librhino-java{a} libsaxon-java{a} libxalan2-java{a} libxerces2-java{a} 
 libxml-commons-external-java{a} libxml-commons-resolver1.1-java{a} 
 libxml2-utils{a} libxmlgraphics-commons-java{a} rhino{a} xmlto{a} 
 xsltproc{a} 
   The following packages will be upgraded:
 kernel-package 
   The following packages are RECOMMENDED but will NOT be installed:
 default-jre docbook-utils kernel-common

And trying to install it by hand doesn't help: it wants to install LaTeX, ruby,
tlc among other things:

   # aptitude install kernel-package
   The following NEW packages will be installed:
 dblatex{a} docbook-xsl{a} fonts-lmodern{a} javascript-common{a} 
 kernel-common{a} libjs-jquery{a} libpoppler-qt4-4{a} libpotrace0{a} 
 libptexenc1{a} libruby2.1{a} libtcl8.6{a} libtk8.6{a} libxml2-utils{a} 
 lmodern{a} prerex{a} preview-latex-style{a} prosper{a} ps2eps{a} ruby{a} 
 ruby2.1{a} rubygems-integration{a} tcl{a} tcl8.6{a} tex-gyre{a} 
 texlive{a} texlive-base{a} texlive-bibtex-extra{a} texlive-binaries{a} 
 texlive-extra-utils{a} texlive-font-utils{a} texlive-fonts-recommended{a} 
 texlive-fonts-recommended-doc{a} texlive-generic-recommended{a} 
 texlive-latex-base{a} texlive-latex-base-doc{a} texlive-latex-extra{a} 
 texlive-latex-extra-doc{a} texlive-latex-recommended{a} 
 texlive-latex-recommended-doc{a} texlive-math-extra{a} 
 texlive-pictures{a} texlive-pictures-doc{a} texlive-pstricks{a} 
 texlive-pstricks-doc{a} tipa{a} tk{a} tk8.6{a} vprerex{a} xmlto{a} 
 xsltproc{a} 
   The following packages will be upgraded:
 kernel-package 
   The following packages are RECOMMENDED but will NOT be installed:
 docbook-utils

I think you'll agree with me that that's a lot of unnecessary dependencies to
compile a kernel, and that keep the package xmlto as a suggestion was the right
decision then and now.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (600, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kernel-package depends on:
ii  bc   1.06.95-8
ii  binutils 2.24.51.20140425-1
ii  build-essential  11.6
ii  debianutils  4.4
ii  file 1:5.18-1
ii  gettext  0.18.3.2-1
ii  kmod 16-2
ii  make 4.0-7
ii  po-debconf   1.0.16+nmu2
ii  util-linux   2.20.1-5.8

Versions of packages kernel-package recommends:
ii  cpio   2.11+dfsg-2
pn  docbook-utils  none

Versions of packages kernel-package suggests:
pn  btrfs-tools none
ii  bzip2   1.0.6-5
ii  e2fsprogs   1.42.10-1
pn  grub | grub2none
ii  initramfs-tools [linux-initramfs-tool]  0.115
pn  jfsutilsnone
pn  liblz4-tool none
ii  libncurses5-dev [libncurses-dev]5.9+20140118-1
pn  linux-sourcenone
pn  mcelog  none
pn  oprofilenone
pn  pcmciautils   

Bug#721996: udisks2/udev bug

[Javier Cantero]

This bug can be closed, since it seems that is a udisks2/udev bug rather than a
thunar-volman bug:

   * #725978 udisks2 bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725978
   * #713877 udev bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713877

There is a couple of workarounds in those bugs that do udev (and thus
thunar-volman) work as intended with CDs/DVDs and also with my Android phone
mass storage. Also there is a related fix in the udev most recent package, but
only for systemd users. The sysvinit users don't have their udev rules updated,
so the bug is still there.


 Saludos de Javier jcant...@escomposlinux.org



signature.asc
Description: Digital signature

Bug#719496: freeorion: input textfields doesn't work after a while.

[Javier Cantero]

El Sun, Oct 06, 2013 at 12:58:12PM +0200, Markus Koschany dice:
 Thanks for your offer. If you find out what option or program causes
 this behaviour on Xfce and interferes with Freeorion, respectively OIS,
 please let me know.

Definitely it's a libOIS related issue. There are several messages in
the libois forums with the same symptoms, for example this:
http://www.wreckedgames.com/forum/index.php/topic,5851.0.html

I've got a way to go around it, applying one of the pending pull
requests from
https://github.com/wgois/Object-oriented-Input-System--OIS-/pulls ).
But before that, let me say that the libOIS version packaged in Debian
testing and the version in the FreeOrion sources are not exactly the
same. The debian version is based in the 1.3.0 stable (with some
additional fixes), but FO uses the actual HEAD of SourceForge (r40 in
http://sourceforge.net/p/wgois/code/40/log/ or master branch of GitHub.

So the first thing I made was to patch libois-1.3.0 package with the
changes of the FreeOrion version. Since the most of them are W32 stuff,
and the non-linux related source files are removed from debian source
package, I only had to patch this:

  https://gist.github.com/javiercantero/7628876

With this patch the behaviour of FO didn't change, but at least we have
the same source base to compare. Then I tried to merge this pull
request:

  https://github.com/wgois/Object-oriented-Input-System--OIS-/pull/3

The change is trivial, it only deletes the XNextEvent() call next to
XPeekEvent() in _isKeyRepeat() method of LinuxKeyboard class. You can
get the patch from the pull request, or cloning the k1ll's repository
v(x11_key_repeat_fix branch). But for simplicity, I also put the exact
patch I applied here:

  https://gist.github.com/javiercantero/7629235

With this small change FreeOrion input texts are working fine. The
OISInput.cfg sets x11_keyboard_grab=false (and x11_mouse_grab=false). I
can change the window focus, and the keyboard comes with me. When I
return to FO, the keyboard also returns, and everything seems fine.
Except Alt-TAB. If I do an Alt-TAB switch and return to FO, the keyboard
doesn't return.

Although this patch works, even me can see that this is a dirty hack,
hard to say why it works, or what it fixes. At least I can't. That is
why I'm going to test another two patches to see what it does.
Specifically the OIS version of worldforge project has some promising
changes I'd like to test: https://github.com/worldforge/ois 

I'm going to post this in the FO forum thread, to see what they think
about it.

Any comments are welcome.

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#719496: freeorion: input textfields doesn't work after a while.

[Javier Cantero]

Package: freeorion
Version: 0.4.3-1
Followup-For: Bug #719496

I can confirm this bug ( I'm using Xfce).

I tried to change the x11_keyboard_grab to true in OISInput.cfg and that
allowed me to input text in freeorion, but then the keyboard didn't work 
with any other app outside freeorion: xterms, editors, firefox, ... When I
close freeorion, the keyboard works again.

I am available to do more extensive tests if you want.


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

Kernel: Linux 3.11.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages freeorion depends on:
ii  freeorion-data0.4.3-1
ii  libalut0  1.1.0-3
ii  libboost-filesystem1.53.0 1.53.0-6
ii  libboost-python1.53.0 1.53.0-6
ii  libboost-serialization1.53.0  1.53.0-6
ii  libboost-signals1.53.01.53.0-6
ii  libboost-system1.53.0 1.53.0-6
ii  libboost-thread1.53.0 1.53.0-6
ii  libbulletcollision2.812.81-rev2613+dfsg-3
ii  libc6 2.17-93
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.8.1-10
ii  libgl1-mesa-glx [libgl1]  9.1.6-2+b1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libjpeg8  8d-1
ii  liblinearmath2.81 2.81-rev2613+dfsg-3
ii  libogre-1.8.0 1.8.0+dfsg1-6
ii  libois-1.3.0  1.3.0+dfsg0-5
ii  libopenal11:1.14-4
ii  libpng12-01.2.49-4
ii  libpython2.7  2.7.5-8
ii  libstdc++64.8.1-10
ii  libtiff4  3.9.7-2
ii  libvorbisfile31.3.2-1.3
ii  zlib1g1:1.2.8.dfsg-1

freeorion recommends no packages.

freeorion suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713898: Tumbler segfaults on video files

[Javier Cantero]

I've realized there is no more tumbler-gst segfaults messages in
kernel.log since August 25. That day was an update of the packages
gstreamer1.0-x, gstreamer1.0-plugins-base and gstreamer1.0-plugins-good
version 1.0.8-1.

So this bug can be closed (although the video thumbnails still are not
generated in my system).

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#721996: [Pkg-xfce-devel] Bug#721996: thunar-volman: confirm XFCE bug #9193

[Javier Cantero]

El Sun, Sep 08, 2013 at 09:27:06AM +0200, Yves-Alexis Perez va y dice:
 Ok. And does udisk2 correctly detects disks?

Tests I've done using udisksctl monitor:

 * Android-phone_udisks2.log - the Android phone Thunar-volman doesn't
show up

 * USB-pen-drive_udisks2.log - a generic USB pen drive that
appears in Thunar (but with a delay of 15-20 seconds)

 * USB-another-pen-drive_udisks2.log - another USB pen drive that is
showed, but without any delay (maybe the previous one is a hardware
issue, so I included this too; their behaviour changes from one to
another)

 * USB-External-HD_udisks2.log - this is an external hard drive (ext2
format) through a USB interface. It shows up inmediately.

 * CDs and DVDs inserted in the CD/DVD drive - they don't register anything
with this tool (?), so no logs

(The serial numbers of the units are masked for security reasons)

-- 
Javier jcant...@escomposlinux.org


javier@hogwarts:~$ udisksctl monitor 
Monitoring the udisks daemon. Press Ctrl+C to exit.
10:15:46.295: The udisks-daemon is running (name-owner :1.19).
10:15:53.254: Added 
/org/freedesktop/UDisks2/drives/LGE_Android_Platform_
  org.freedesktop.UDisks2.Drive:
CanPowerOff:true
Configuration:  {}
ConnectionBus:  usb
Ejectable:  true
Id: LGE-Android-Platform-
Media:  
MediaAvailable: false
MediaChangeDetected:true
MediaCompatibility: 
MediaRemovable: true
Model:  Android Platform
Optical:false
OpticalBlank:   false
OpticalNumAudioTracks:  0
OpticalNumDataTracks:   0
OpticalNumSessions: 0
OpticalNumTracks:   0
Removable:  true
Revision:   0100
RotationRate:   -1
Seat:   seat0
Serial: 
SiblingId:  
/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.4
Size:   0
SortKey:01hotplug/1378628153252732
TimeDetected:   1378628153252732
TimeMediaDetected:  0
Vendor: LGE
WWN:
10:15:53.256: Added /org/freedesktop/UDisks2/block_devices/sdb
  org.freedesktop.UDisks2.Block:
Configuration:  []
CryptoBackingDevice:'/'
Device: /dev/sdb
DeviceNumber:   2064
Drive:  
'/org/freedesktop/UDisks2/drives/LGE_Android_Platform_'
HintAuto:   true
HintIconName:   
HintIgnore: false
HintName:   
HintPartitionable:  true
HintSymbolicIconName:   
HintSystem: false
Id: 
IdLabel:
IdType: 
IdUUID: 
IdUsage:
IdVersion:  
MDRaid: '/'
MDRaidMember:   '/'
PreferredDevice:/dev/sdb
ReadOnly:   false
Size:   0
Symlinks:   
/dev/disk/by-id/usb-LGE_Android_Platform_-0:0

/dev/disk/by-path/pci-:00:1a.0-usb-0:1.5:1.4-scsi-0:0:0:0javier@hogwarts:~$ udisksctl monitor 
Monitoring the udisks daemon. Press Ctrl+C to exit.
10:21:56.989: The udisks-daemon is running (name-owner :1.19).
10:22:01.894: Added /org/freedesktop/UDisks2/block_devices/sdb_1
  org.freedesktop.UDisks2.Block:
Configuration:  []
CryptoBackingDevice:'/'
Device: /dev/sdb
DeviceNumber:   2064
Drive:  
'/org/freedesktop/UDisks2/drives/SanDisk_Cruzer_Micro_XXYYYXX'
HintAuto:   false
HintIconName:   
HintIgnore: false
HintName:   
HintPartitionable:  true
HintSymbolicIconName:   
HintSystem: true
Id: 
by-id-usb-SanDisk_Cruzer_Micro_XXYYYXX-0:0
IdLabel:
IdType: 
IdUUID: 
IdUsage:
IdVersion:  
MDRaid: '/'
MDRaidMember:   '/'
PreferredDevice:/dev/sdb
ReadOnly:   false
Size:   0
Symlinks:   
/dev/disk/by-id/usb-SanDisk_Cruzer_Micro_XXYYYXX-0:0

/dev/disk/by-path/pci-:00:1a.0-usb-0:1.5:1.0-scsi-0:0:0:0
10:22:02.729: 

Bug#721996: [Pkg-xfce-devel] Bug#721996: thunar-volman: confirm XFCE bug #9193

[Javier Cantero]

El Fri, Sep 06, 2013 at 09:18:26PM +0200, Yves-Alexis Perez va y dice:
 The bug says “automount doesn't work”. Here, it's about the device not
 beeing detected at all in Thunar.

It seems that people is mixing the automount feature with the volume
disk feature. But, see the comments #7 and #8 of that bug, that's
exactly my problem.

can't see removable devices is probably a better description, like in
this ArchLinux forum thread:
https://bbs.archlinux.org/viewtopic.php?id=111867p=1

But they use a weird workaround to avoid the problem.

 Is the mass storage device actually correctly detected by the kernel and
 udisks?

Yes, it is. At least udisks is receiving the notification via udev when
I plug the android phone:

javier@hogwarts:~$ udisks --monitor
Monitoring activity from the disks daemon. Press Ctrl+C to cancel.
added: /org/freedesktop/UDisks/devices/sdb
changed: /org/freedesktop/UDisks/devices/sdb
changed: /org/freedesktop/UDisks/devices/sdb

I can attach the udevadm monitor --environment logs if you want, but
they seem normal (and they are big). The kernel logs are also right, the
only missing lines are the corresponding ones to the mount syscall.

-- 
 Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#721996: [Pkg-xfce-devel] Bug#721996: thunar-volman: confirm XFCE bug #9193

[Javier Cantero]

El Sat, Sep 07, 2013 at 08:21:53PM +0200, Yves-Alexis Perez va y dice:
 On sam., 2013-09-07 at 18:34 +0200, Javier Cantero wrote:
  javier@hogwarts:~$ udisks --monitor
 
 Is udisks2 installed?

Yes

javier@hogwarts:~$  dpkg -l | grep udisks
ii  libudisks2-0:amd642.1.0-4
amd64GObject based library to access udisks2
ii  udisks1.0.4-7
amd64storage media interface
ii  udisks2   2.1.0-4
amd64D-BUS service to access and manipulate storage devices

-- 
   Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#721996: thunar-volman: confirm XFCE bug #9193

[Javier Cantero]

Package: thunar-volman
Version: 0.8.0-2
Severity: important

Dear Maintainer,

Both USB mass storage devices (especially Android phones) and CD/DVDs
failed to be detected and showed in Thunar when plugged. This is already
reported upstream in several bugs, the most important #9193:

   https://bugzilla.xfce.org/show_bug.cgi?id=9193

In .xsession-errors (sorry, messages localized to spanish):

   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Tipo de dispositivo por bloque desconocido.
   thunar-volman: No se pudo detectar el volumen en el dispositivo.
   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Dispositivo USB no soportado.
   thunar-volman: Tipo de dispositivo por bloque desconocido.

These are the equivalent english messages:

   thunar-volman: Unsupported USB device type.
   thunar-volman: Unknown block device type.
   thunar-volman: Could not detect the volume corresponding to the device.

This is not a consistent bug. sometimes the unit appears, vmost times,
not. It depends of the type of device. USB flash disks tend to show, but
not always.

Also this bug didn't exist in Debian Wheezy.


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

Kernel: Linux 3.10.10-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages thunar-volman depends on:
ii  exo-utils   0.10.2-2
ii  libc6   2.17-92
ii  libexo-1-0  0.10.2-2
ii  libglib2.0-02.36.4-1
ii  libgtk2.0-0 2.24.20-1
ii  libgudev-1.0-0  175-7.2
ii  libnotify4  0.7.5-2
ii  libpango1.0-0   1.32.5-5+b1
ii  libxfce4ui-1-0  4.10.0-3
ii  libxfce4util6   4.10.1-1
ii  libxfconf-0-2   4.10.0-2
ii  thunar  1.6.3-1

thunar-volman recommends no packages.

thunar-volman suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713898: [Pkg-xfce-devel] Bug#713898: Tumbler segfaults on video files

[Javier Cantero]

I've looking after this bug using dbus-monitor[*] but everything I can see is
that they are neither Error signals in D-Bus for the video files nor the
final Finished signal after the Ready responses. Simply some of the files
in the Ready signal are missing (all the videos, and sometimes other
non-video thumbnails that the service had no time to process)

It seems that, when the thumbnailer gst plugin dies on segfault, the
general service can't continue and the Queue request remains
incomplete.


[*] dbus-monitor --session --monitor 
interface=org.freedesktop.thumbnails.Thumbnailer1

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#713898: Tumbler segfaults on video files

[Javier Cantero]

Package: tumbler
Version: 0.1.29-1
Followup-For: Bug #713898

Dear Maintainer,

This bug is also present in Jessie:

[ 9696.193804] pool[4896]: segfault at 40 ip 7f7b9c5ab047 sp 
7f7b97bccc20 error 4 in tumbler-gst-thumbnailer.so[7f7b9c5a8000+5000]
[10307.656870] pool[4938]: segfault at 40 ip 7f9906cc5047 sp 
7f99022e6c20 error 4 in tumbler-gst-thumbnailer.so[7f9906cc2000+5000]
[10461.865382] pool[5043]: segfault at 40 ip 7f7d488c8047 sp 
7f7d43ee9c20 error 4 in tumbler-gst-thumbnailer.so[7f7d488c5000+5000]
[10680.487960] pool[5102]: segfault at 40 ip 7fd7aac55047 sp 
7fd7a6276c20 error 4 in tumbler-gst-thumbnailer.so[7fd7aac52000+5000]


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

Kernel: Linux 3.9.8-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages tumbler depends on:
ii  libc6   2.17-6
ii  libcairo2   1.12.14-4
ii  libdbus-1-3 1.6.12-1
ii  libdbus-glib-1-20.100.2-1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.36.1-2build1
ii  libgstreamer-plugins-base1.0-0  1.0.7-1
ii  libgstreamer1.0-0   1.0.7-1
ii  libjpeg88d-1
ii  libpng12-0  1.2.49-4
ii  libpoppler-glib80.18.4-6
ii  libtumbler-1-0  0.1.29-1
ii  tumbler-common  0.1.29-1
ii  zlib1g  1:1.2.8.dfsg-1

tumbler recommends no packages.

Versions of packages tumbler suggests:
pn  tumbler-plugins-extra  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#713898: [Pkg-xfce-devel] Bug#713898: Tumbler segfaults on video files

[Javier Cantero]

El Mon, Jul 01, 2013 at 09:26:59PM +0200, Yves-Alexis Perez va y dice:
 Could you provide a backtrace or at least a file which causes the
 issue?

Any video causes it.

For example, I just tested a very simple video that is already in the
Debian repository: /usr/share/pyshared/pygame/examples/data/blue.mpg (in
the python-pygame package):

   $ thunar /usr/share/pyshared/pygame/examples/data
   $ dmesg | tail 
   ...
   [   17.905943] lp0: using parport0 (polling).
   [   17.906052] initcall parport_pc_init+0x0/0xf50 [parport_pc] returned 0 
after 95386 usecs
   [  313.345594] pool[3620]: segfault at 40 ip 7fca7bd1b047 sp 
7fca7733cc20 error 4 in tumbler-gst-thumbnailer.so[7fca7bd18000+5000]
   [  384.440708] pool[3923]: segfault at 40 ip 7f1672c7e047 sp 
7f166e29fc20 error 4 in tumbler-gst-thumbnailer.so[7f1672c7b000+5000]
   [  725.827205] pool[3951]: segfault at 40 ip 7fa1e1f79047 sp 
7fa1dd59ac20 error 4 in tumbler-gst-thumbnailer.so[7fa1e1f76000+5000]


   The 3 lines are from 3 different executions of the thunar over that
directory.

 Does the file play fine with a gstreamer based video player?

Yes, all of them.

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#708676: /etc/init.d/alsa-utils: default start runlevel arguments (2 3 4 5) do not match alsa-utils Default-Start values (S)

[Javier Cantero]

Package: alsa-utils
Version: 1.0.27.1-1
Followup-For: Bug #708676

Dear Maintainer,

I can confirm this message still outputs in the installation of
the last testing package (1.0.27.1-1) of alsa-utils.

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

Kernel: Linux 3.9.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages alsa-utils depends on:
ii  kmod9-3
ii  libasound2  1.0.27.1-1
ii  libc6   2.17-3
ii  libncursesw55.9+20130504-1
ii  libsamplerate0  0.1.8-5
ii  libtinfo5   5.9+20130504-1
ii  lsb-base4.1+Debian11
ii  whiptail0.52.15-1

Versions of packages alsa-utils recommends:
ii  alsa-base  1.0.25+3

alsa-utils suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695353: Confirmed and already fixed bug in another distros

[Javier Cantero]

I can confirm this bug. Some tumbler instances trying to generate a
thumbnail of a video file prevent the file system to be unmounted. This
happens with a USB memory stick, for example.

The bug is also reported in another debian based distros with the same
package version, and already fixed (see Ubuntu bug #995918,
02_set-gststate-on-error.patch: close file on error. and related
Xfce bug #8303 https://bugzilla.xfce.org/show_bug.cgi?id=8303 )

This is a quite annoying issue and should be considered to be fixed before
the stable release is launched.


-- 
   Saludos de Javier jcant...@escomposlinux.org



signature.asc
Description: Digital signature

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Javier Cantero]

Just a little bit of info I found reading the last changes to the
X intel driver:

Release 2.20.9 (2012-09-29)
===
And so it came to pass that a critical bug was uncovered in UXA. The
kernel does not like to pageflip when the pipe is off, yet due to the
delayed nature of a pageflip and the relaxed checking performed by UXA,
we could request a pageflip after turning off the display (DPMS). The
kernel rejected that pageflip and the error handling path failed to
restore sanity, and when the screen came back it was stuck on the image
seen before it went to sleep. (Note that there are also some related
kernel bugs, but this update should prevent the most conspicious of the
freezes.) Many thanks to Timo Aaltonen for his efforts in tracking down
the issue.
[...]

This is not the kernel bug, but the graphics bug. However, maybe is not
a bad idea to upgrade the X driver and see what happen with 3.2.x.

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Javier Cantero]

Sorry, I didn't receive the last 2 msgs in my mailbox, (especifically the
questions Ingo asks me). Here the answers:

a) Yes, I am using iceweasel.
b) my phisical RAM is 8 GB

The related kernel info is below, first kernel 3.5 related and then
standard wheezy 3.2 kernel related. Note that with kernel 3.5 I don't
have the MTRR allocation failed error.

My integrated graphics BIOS configuration:

Virtu Technology   [Disabled]
Integrated Graphics Share Memory   [64MB]
DVMT Memory   [256MB]
IGD Multimonitor   [Disabled]


--
  Kernel 3.5
--

$ dmesg | grep mtrr
$

$ dmesg | grep drm
[3.749099] [drm] Initialized drm 1.1.0 20060810
[3.947156] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[3.947156] [drm] Driver supports precise vblank timestamp query.
[4.004585] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[4.373533] fbcon: inteldrmfb (fb0) is primary device
[4.554815] fb0: inteldrmfb frame buffer device
[4.554817] drm: registered panic notifier
[4.555909] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

$ dmesg | grep i915
[3.690617] i915 :00:02.0: setting latency timer to 64
[3.707470] i915 :00:02.0: irq 43 for MSI/MSI-X
[4.328751] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

$ dmesg | grep agp
[0.459118] Linux agpgart interface v0.103
[0.459169] agpgart-intel :00:00.0: Intel Ivybridge Chipset
[0.459210] agpgart-intel :00:00.0: detected gtt size: 2097152K total, 
262144K mappable
[0.459842] agpgart-intel :00:00.0: detected 65536K stolen memory
[0.459931] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000


The memory info:

$ cat /proc/mtrr
reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x0dc00 ( 3520MB), size=   64MB, count=1: uncachable
reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable

$ cat /proc/meminfo
MemTotal:8081148 kB
MemFree: 7392304 kB
Buffers:   14852 kB
Cached:   280924 kB
SwapCached:0 kB
Active:   395024 kB
Inactive: 214096 kB
Active(anon): 313884 kB
Inactive(anon):42596 kB
Active(file):  81140 kB
Inactive(file):   171500 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:   7811068 kB
SwapFree:7811068 kB
Dirty:12 kB
Writeback: 0 kB
AnonPages:313372 kB
Mapped:64608 kB
Shmem: 43120 kB
Slab:  26992 kB
SReclaimable:  11196 kB
SUnreclaim:15796 kB
KernelStack:1808 kB
PageTables:10844 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:11851640 kB
Committed_AS:1004672 kB
VmallocTotal:   34359738367 kB
VmallocUsed:  366716 kB
VmallocChunk:   34359355879 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   55296 kB
DirectMap2M: 7192576 kB


--
  Kernel 3.2
--

$ dmesg | grep mtrr
[5.001176] mtrr: type mismatch for e000,1000 old: write-back new: 
write-combining

$ cat /proc/mtrr
reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x0dc00 ( 3520MB), size=   64MB, count=1: uncachable
reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable

$ dmesg | grep drm
[4.960827] [drm] Initialized drm 1.1.0 20060810
[5.001178] [drm] MTRR allocation failed.  Graphics performance may suffer.
[5.001350] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[5.001351] [drm] Driver supports precise vblank timestamp query.
[5.344345] fbcon: inteldrmfb (fb0) is primary device
[5.523815] fb0: inteldrmfb frame buffer device
[5.523816] drm: registered panic notifier
[5.585070] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

$ dmesg | grep i915
[4.973200] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[4.973202] i915 :00:02.0: setting latency timer to 64
[5.001347] i915 :00:02.0: irq 43 for MSI/MSI-X
[5.585070] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0

$ dmesg | grep agp
[0.977765] Linux agpgart 

Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze

[Javier Cantero]

I can also confirm this bug. My hardware: i5-3570K MoBo: MSI Z77A-G65.

If it helps, I am using now linux-image-3.5-trunk-amd64
(3.5.2-1~experimental.1) kernel with no freezes since the change.

-- 
   Saludos de Javier jcant...@escomposlinux.org




signature.asc
Description: Digital signature