Bug#1055446: libervia-backend: requires python3-txdbus

[Alberto Luaces]

Package: libervia-backend
Version: 0.9.0~hg3993-4
Severity: normal
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

When starting libervia-backend, I get this error, and the command stops:

> 2023-11-06T12:55:38+0100 Can't import bridge 'dbus': No module named 'txdbus'
> 2023-11-06T12:55:38+0100 /!\ Can't find bridge module of name dbus

Installing python3-txdbus fixes the problem, that's why I think this
package should be set as a dependency.

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libervia-backend depends on:
ii  python3   3.11.4-5+b1
ii  python3-aiosqlite 0.17.0-2
ii  python3-alembic   1.8.1-2
ii  python3-babel 2.10.3-2
ii  python3-dateutil  2.8.2-3
ii  python3-dbus  1.3.2-5
ii  python3-idna  3.3-2
ii  python3-lxml  4.9.3-1
ii  python3-mutagen   1.46.0-2
ii  python3-openssl   23.2.0-1
ii  python3-pil   10.0.0-1
ii  python3-potr  1.0.2-5
ii  python3-pycryptodome  3.11.0+dfsg1-4
ii  python3-service-identity  23.1.0-1
ii  python3-shortuuid 1.0.11-2
ii  python3-sqlalchemy1.4.47+ds1-1
ii  python3-treq  22.2.0-0.1
ii  python3-twisted   22.4.0-4
ii  python3-wokkel18.0.0-4
ii  python3-xdg   0.28-2
ii  python3-xmlschema 1.10.0-6
ii  python3-zope.interface5.5.2-1+b1

Versions of packages libervia-backend recommends:
ii  dbus-x11   1.14.10-3
ii  libervia-tui   0.9.0~hg3993-4
ii  python3-cairosvg   2.7.1-1
ii  python3-html2text  2020.1.16-2
ii  python3-markdown   3.4.4-1
ii  python3-miniupnpc  2.2.5-1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-oldmemo1.0.3-2
ii  python3-omemo  1.0.2-3
ii  python3-twomemo1.0.3-2

libervia-backend suggests no packages.

-- no debconf information

Bug#1055445: libervia-backend: manual page says it is autorun, but it is not.

[Alberto Luaces]

Package: libervia-backend
Version: 0.9.0~hg3993-4
Severity: minor
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

The manual page of libervia-backend says

> note that you don't have to run sat manually, it will be started
> whenever you launch one of the frontends.

However, when trying to run libervia-tui, one is greeted with

> Can't connect to SàT backend, are you sure it's launched ?

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libervia-backend depends on:
ii  python3   3.11.4-5+b1
ii  python3-aiosqlite 0.17.0-2
ii  python3-alembic   1.8.1-2
ii  python3-babel 2.10.3-2
ii  python3-dateutil  2.8.2-3
ii  python3-dbus  1.3.2-5
ii  python3-idna  3.3-2
ii  python3-lxml  4.9.3-1
ii  python3-mutagen   1.46.0-2
ii  python3-openssl   23.2.0-1
ii  python3-pil   10.0.0-1
ii  python3-potr  1.0.2-5
ii  python3-pycryptodome  3.11.0+dfsg1-4
ii  python3-service-identity  23.1.0-1
ii  python3-shortuuid 1.0.11-2
ii  python3-sqlalchemy1.4.47+ds1-1
ii  python3-treq  22.2.0-0.1
ii  python3-twisted   22.4.0-4
ii  python3-wokkel18.0.0-4
ii  python3-xdg   0.28-2
ii  python3-xmlschema 1.10.0-6
ii  python3-zope.interface5.5.2-1+b1

Versions of packages libervia-backend recommends:
ii  dbus-x11   1.14.10-3
ii  libervia-tui   0.9.0~hg3993-4
ii  python3-cairosvg   2.7.1-1
ii  python3-html2text  2020.1.16-2
ii  python3-markdown   3.4.4-1
ii  python3-miniupnpc  2.2.5-1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-oldmemo1.0.3-2
ii  python3-omemo  1.0.2-3
ii  python3-twomemo1.0.3-2

libervia-backend suggests no packages.

-- no debconf information

Bug#1035471: revolt no longer starts up on bookworm

[Alberto Luaces]

Package: revolt
Followup-For: Bug #1035471
X-Debbugs-Cc: alua...@udc.es

I have two computers with the same debian version (testing currently).

- On one it works (KDE+i3 wm)
- On the other (i3 wm) it starts, but the window hangs forever.  I have tried 
to delete ~/.cache/revolt, but it does not help.

Just to add a bit more of information.

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

Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages revolt depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-webkit2-4.0   2.42.0-1
ii  python3  3.11.4-5+b1
ii  python3-gi   3.46.0-1

revolt recommends no packages.

revolt suggests no packages.

-- no debconf information

Bug#1036288: blender: cycles renderer does not work

[Alberto Luaces]

Package: blender
Version: 3.4.1+dfsg-2+b1
Severity: important
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

while trying to bake some textures I realized that the cycles renderer does not 
work at all.

Steps to reproduce: new file → set renderer to cycles → render → nothing is 
shown in the render window.

I have tested upstream's 3.4.1 binary and it works fine.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blender depends on:
ii  blender-data  3.4.1+dfsg-2
ii  fonts-dejavu  2.37-6
ii  libavcodec59  7:5.1.2-3
ii  libavdevice59 7:5.1.2-3
ii  libavformat59 7:5.1.2-3
ii  libavutil57   7:5.1.2-3
ii  libboost-locale1.74.0 1.74.0+ds1-20
ii  libc6 2.36-9
ii  libembree3-3  3.13.5+dfsg-2
ii  libepoxy0 1.5.10-1
ii  libfftw3-double3  3.3.10-1
ii  libfreetype6  2.12.1+dfsg-5
ii  libgcc-s1 12.2.0-14
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libgomp1  12.2.0-14
ii  libimath-3-1-29   3.1.6-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  libjemalloc2  5.3.0-1
ii  libjpeg62-turbo   1:2.1.5-2
ii  libopenal11:1.19.1-2
ii  libopencolorio2.1 2.1.2+dfsg1-4+b3
ii  libopenexr-3-1-30 3.1.5-5
ii  libopenimageio2.4 2.4.7.1+dfsg-2
ii  libopenjp2-7  2.5.0-1+b1
ii  libopenvdb10.010.0.1-2
ii  libosdcpu3.5.03.5.0-2
ii  libosdgpu3.5.03.5.0-2
ii  libpcre3  2:8.39-15
ii  libpng16-16   1.6.39-2
ii  libpotrace0   1.16-2
ii  libpugixml1v5 1.13-0.2
ii  libpulse0 16.1+dfsg1-2+b1
ii  libpython3.11 3.11.2-6
ii  libsdl2-2.0-0 2.26.5+dfsg-1
ii  libsndfile1   1.2.0-1
ii  libspnav0 1.0-1
ii  libstdc++612.2.0-14
ii  libswscale6   7:5.1.2-3
ii  libtbb12  2021.8.0-1
ii  libtiff6  4.5.0-5
ii  libwebp7  1.2.4-0.1
ii  libx11-6  2:1.8.4-2
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1.2
ii  libxxf86vm1   1:1.1.4-1+b2
ii  libzstd1  1.5.4+dfsg2-5
ii  zlib1g1:1.2.13.dfsg-1

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#988260: guix: GNOME sessions crash with mismatched glib-2.0 schemas

[Alberto Luaces]

Package: guix
Version: 1.3.0-5+b1
Followup-For: Bug #988260
X-Debbugs-Cc: alua...@udc.es

Just confirming this issue also affects debian's emacs.

/etc/profile.d/guix.sh implicitly sets up EMACSLOADPATH when sourcing
the profile.

I think that emacs only reads dirs in EMACSLOADPATH if it is set, so
after that any .el files under /usr/ are not found.  Even if that were
not the case, I also think that it would be still undesirable for
debian emacs to look first into the guix profile directories, since it
could cause mixed version .el file loads.

I am a new guix user, so maybe I am not understanding something, but I
tend to believe that currently the rationale is that it is not
expected that the user can have co-existing guix and debian versions
of the same software.

So far I have deleted /etc/profile.d/guix.sh and I am proceeding to
activate guix profiles only when I am needing them.

Regards.

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

Kernel: Linux 6.0.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guix depends on:
ii  guile-3.0   3.0.8-2
ii  guile-3.0-libs  3.0.8-2
ii  guile-gcrypt0.4.0-2
ii  guile-git   0.5.2-5
ii  guile-gnutls3.7.8-4
ii  guile-json  4.7.3-2
ii  guile-lzlib 0.0.2-3
ii  guile-sqlite3   0.1.3-3
ii  guile-ssh   0.16.0-2
ii  guile-zlib  0.1.0-4
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.36-6
ii  libgcc-s1   12.2.0-9
ii  libgcrypt20 1.10.1-3
ii  libsqlite3-03.40.0-1
ii  libssh-dev  0.10.4-2
ii  libstdc++6  12.2.0-9
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages guix recommends:
ii  ca-certificates  20211016
ii  less 590-1
ii  nscd 2.36-6
ii  systemd  252.2-2

guix suggests no packages.

-- Configuration Files:
/etc/profile.d/guix.sh [Errno 2] No existe el fichero o el directorio: 
'/etc/profile.d/guix.sh'

-- no debconf information

Bug#1004634: A way to include openscenegraph in bookworm?

[Alberto Luaces]

control: severity -1 important

I agree, thanks for noting that as well.  Let's see if I do this 
correctly, I always have problems recalling the details of operating 
with cont...@bugs.debian.org.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: A way to include openscenegraph in bookworm?

[Alberto Luaces]

No problem!

Yes, it was more of a philosophical issue.  That is the reason why I am 
leaving this bug report open, in case we get a patch in time or if some 
dependency really needs this plugin.


Regards,

Alberto


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: A way to include openscenegraph in bookworm?

[Alberto Luaces]

Hi, those are currently my thoughts as well.

I'm going to prepare a release like that, and we can see if any of the 
reverse dependencies is actively using this plugin; maybe some games as 
openmw are displaying movies, we will see.


Regards,

Alberto


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: openscenegraph: FTBFS with ffmpeg 5.0

[Alberto Luaces]

Hi PaulLi,

this is highly appreciated.  Thanks a lot for your effort!

I have stored the patch in the repo for reference:

https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/commit/d5babb29f1233a9b111be88fd1037aebb5211c54

Regards,

Alberto

On 20/9/22 19:56, Ying-Chun Liu (PaulLiu) wrote:

Hi all,

I've patched the audio part. But not completed. The video part needs 
more changes. But I don't have enough time now.


Just attach the partial patch I made so that when someone has time or I 
have time then we can continue it.


Yours,
Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1009195: blueprint-compiler: The homepage address leads to 404

[Alberto Luaces]

Source: blueprint-compiler
Version: 0~20220302-3
Severity: minor
Tags: upstream
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

upstream's address (https://github.com/mjakeman/blueprint-compiler) leads to a 
404 in github.

Is it possible that the project has moved elsewhere?

Bug#1004634: openscenegraph: FTBFS with ffmpeg 5.0

[Alberto Luaces]

On 1/2/22 21:21, Sebastian Ramacher wrote:

Hi Alberto,

On 2022-01-31 09:31:52 +0100, Alberto Luaces wrote:

Hi Sebastian,

This looks like an API breakage from ffmpeg versions 4 to 5.  I have seen no
transition for this, but in the meantime, do you have any pointer about the
old removed functions and their replacements?


Yes, ffmpeg 5 removed some functions that were deprecated in ffmpeg 4
and constified some return values and arguments. I haven't seen a guide
to update though.


Thanks! I have located https://ffmpeg.org/doxygen/4.1/deprecated.html 
were some are covered, but others aren't.  I will look for some others 
doing the transition as well.  So far, upstream is unchanged in that regard.


Cheers,

Alberto


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004634: openscenegraph: FTBFS with ffmpeg 5.0

[Alberto Luaces]

Hi Sebastian,

This looks like an API breakage from ffmpeg versions 4 to 5.  I have 
seen no transition for this, but in the meantime, do you have any 
pointer about the old removed functions and their replacements?


Thanks,

Alberto


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002726: webext-quicktext: Please upgrade to 4.1

[Alberto Luaces]

Package: webext-quicktext
Followup-For: Bug #1002726
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

This is not a "wishlist", the package is genuinely broken and doesn't work with 
current thunderbird from debian.

If help is needed, I can maintain it.  Otherwise it's best to keep it out of 
the archive.

Bug#1002726: webext-quicktext: Please upgrade to 4.1

[Alberto Luaces]

Package: webext-quicktext
Version: 3.5-1
Severity: important
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

current debian version of the package is disabled for thunderbird 91.x (current 
version in testing), so it cannot be used.

Upstream released version 4.1 fixing that problem.

Thanks.

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages webext-quicktext depends on:
ii  thunderbird  1:91.4.1-1

webext-quicktext recommends no packages.

webext-quicktext suggests no packages.

-- no debconf information

Bug#1001059: elpa-lsp-mode: dash-functional dependency is dropped, but it is needed anyway

[Alberto Luaces]

Package: elpa-lsp-mode
Version: 7.0.1-3
Severity: normal
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

The last version removes the dash-functional dependency, but it is still 
required by the code, otherwise activating the mode chokes on `-const' function 
not being defined.

(require 'dash-functional) alleviates the problem in the meantime.

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

Kernel: Linux 5.14.0-4-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-lsp-mode depends on:
ii  dh-elpa-helper  2.0.9
ii  elpa-dash   2.19.1+dfsg-1
ii  elpa-f  0.20.0-3
ii  elpa-ht 2.3-2
ii  elpa-lv 0.15.0-3
ii  elpa-markdown-mode  2.4-1
ii  elpa-spinner1.7.3-3
ii  emacsen-common  3.0.4

Versions of packages elpa-lsp-mode recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1

elpa-lsp-mode suggests no packages.

-- no debconf information

Bug#988031: ITP: youtubedl-gui -- GUI on youtube-dl to download videos from a variety of sites

[Alberto Luaces]

Hi, maybe you are aware of https://github.com/mhogomchungu/media-downloader

It serves the very same purpose, but it seems to have much more options
for controlling the exact format you want to download.

It is also a simple C++, Qt based project, but it is not packaged yet,
so maybe it is a better option.

Regards,

Alberto

Bug#961083: blender: Crash during importing wrong .stl

[Alberto Luaces]

Package: blender
Followup-For: Bug #961083
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

I can confirm this bug is solved with the current version, so it can be closed.


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blender depends on:
ii  blender-data  2.83.5+dfsg-5
ii  fonts-dejavu  2.37-2
ii  libavcodec58  7:4.3.1-5
ii  libavdevice58 7:4.3.1-5
ii  libavformat58 7:4.3.1-5
ii  libavutil56   7:4.3.1-5
ii  libboost-locale1.74.0 1.74.0-3+b1
ii  libc6 2.31-5
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-1
ii  libgl11.3.2-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.2.1-1
ii  libilmbase25  2.5.3-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.16~dfsg-1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libopenal11:1.19.1-2
ii  libopencolorio1v5 1.1.1~dfsg0-6+b3
ii  libopenexr25  2.5.3-2
ii  libopenimageio2.2 2.2.9.0+dfsg-1+b1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.1 7.1.0-2+b3
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.1-1
ii  libsdl2-2.0-0 2.0.12+dfsg1-4
ii  libsndfile1   1.0.28-8
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.2.1-1
ii  libswscale5   7:4.3.1-5
ii  libtbb2   2020.3-1
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.12-1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxml2   2.9.10+dfsg-6.3+b1
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#957037: biboumi: ftbfs with GCC-10

[Alberto Luaces]

Package: biboumi
Followup-For: Bug #957037

I have checked that current upstream (9.0) builds flawlessly, and made my 
release available at https://salsa.debian.org/aluaces-guest/biboumi .

Can I be sponsored so we can upload to at least experimental?

Thanks!

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Alberto Luaces]

On 27/11/20 9:37, Rafael Laboissière wrote:
> 
> I can reproduce the bug if I include the following in my ~/.inputrc.:
> 
>     set enable-bracketed-paste on
> 
> Could you please check that this is what is happening with your setting?

Thank you a lot for tracking this!

Well, I do not have a ~/.inputrc file, but if I create it and write

set enable-bracketed-paste off

the problem indeed goes away!

I also have opened my /etc/inputrc and I did not find any "set
enable-bracketed-paste on" line.

Regards.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Alberto Luaces]

On 26/11/20 20:11, Rafael Laboissière wrote:
> 
> I cannot reproduce this bug.  Could you please provide a litte bit more
> information, please.  For instance, do you observe the same behavior with:
> 
>     octave --gui --no-history --no-init-file  --no-site-file --norc

Thank you for your prompt reply!

Unfortunately, the result is the same.  Is there any global
configuration or package that octave gui is relying in?  What can I try
next?

Regards.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975902: octave-gui always shows "undecodable token: \001b(hex)[?2004h" in the prompt

[Alberto Luaces]

Package: octave
Version: 5.2.0-3+b1
Severity: important
X-Debbugs-Cc: alua...@udc.es

Dear Maintainer,

octave --gui is always showing "undecodable token: \001b(hex)[?2004h" at the 
prompt, hindering the edition commands since one cannot see where one is 
typing, and garbling the display.

Otherwise the rest of the program works ok as far as I know, and the CLI 
interface is not affected.

I have also tried in a new, fresh user account in order to see if it is related 
to my personal configuration, but I get the same results. 

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages octave depends on:
ii  libamd21:5.8.1+dfsg-2
ii  libbz2-1.0 1.0.8-4
ii  libc6  2.31-4
ii  libccolamd21:5.8.1+dfsg-2
ii  libcholmod31:5.8.1+dfsg-2
ii  libcolamd2 1:5.8.1+dfsg-2
ii  libcxsparse3   1:5.8.1+dfsg-2
ii  libfftw3-double3   3.3.8-2
ii  libfftw3-single3   3.3.8-2
ii  libfltk-gl1.3  1.3.5-2
ii  libfltk1.3 1.3.5-2
ii  libgcc-s1  10.2.0-16
ii  libgl1 1.3.2-1
ii  libglpk40  4.65-2
ii  liboctave7 5.2.0-3+b1
ii  libportaudio2  19.6.0-1.1
ii  libqhull8.02020.2-2
ii  libqscintilla2-qt5-15  2.11.5+dfsg-3+b1
ii  libqt5core5a   5.15.1+dfsg-2
ii  libqt5gui5 5.15.1+dfsg-2
ii  libqt5help55.15.1-2
ii  libqt5network5 5.15.1+dfsg-2
ii  libqt5printsupport55.15.1+dfsg-2
ii  libqt5widgets5 5.15.1+dfsg-2
ii  libqt5xml5 5.15.1+dfsg-2
ii  libsndfile11.0.28-8
ii  libstdc++6 10.2.0-16
ii  libsuitesparseconfig5  1:5.8.1+dfsg-2
ii  libx11-6   2:1.6.12-1
ii  octave-common  5.2.0-3
ii  texinfo6.7.0.dfsg.2-5+b1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages octave recommends:
ii  default-jre-headless  2:1.11-72
ii  epstool   3.09-2
ii  gnuplot-qt [gnuplot-x11]  5.4.0+dfsg1-1
ii  libatlas3-base3.10.3-10
ii  libopenblas0  0.3.12+ds-2
ii  octave-doc5.2.0-3
ii  pstoedit  3.75-1

Versions of packages octave suggests:
ii  liboctave-dev  5.2.0-3+b1

-- no debconf information

Bug#961083: blender: Crash during importing wrong .stl

[Alberto Luaces]

Package: blender
Version: 2.83.5+dfsg-4+b1
Followup-For: Bug #961083
X-Debbugs-Cc: alua...@udc.es

Hello, the STL import is still failing: just opening a file of that
type will crash blender.

Moreover, at least the STL, OBJ and PLY export is also failing: you
can just try saving the initial cube straight away into one of these
formats and reproduce the error.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blender depends on:
ii  blender-data  2.83.5+dfsg-4
ii  fonts-dejavu  2.37-2
ii  libavcodec58  7:4.3.1-5
ii  libavdevice58 7:4.3.1-5
ii  libavformat58 7:4.3.1-5
ii  libavutil56   7:4.3.1-5
ii  libboost-locale1.71.0 1.71.0-7+b1
ii  libc6 2.31-4
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.10.2+dfsg-4
ii  libgcc-s1 10.2.0-16
ii  libgl11.3.2-1
ii  libglew2.12.1.0-4+b1
ii  libgomp1  10.2.0-16
ii  libilmbase25  2.5.3-2
ii  libjack0 [libjack-0.125]  1:0.125.0-3+b1
ii  libjemalloc2  5.2.1-1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libopenal11:1.19.1-2
ii  libopencolorio1v5 1.1.1~dfsg0-6+b2
ii  libopenexr25  2.5.3-2
ii  libopenimageio2.2 2.2.7.0+dfsg-2+b1
ii  libopenjp2-7  2.3.1-1
ii  libopenvdb7.1 7.1.0-2+b1
ii  libosdcpu3.4.33.4.3-3
ii  libosdgpu3.4.33.4.3-3
ii  libpcre3  2:8.39-13
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.0-5
ii  libsdl2-2.0-0 2.0.12+dfsg1-4
ii  libsndfile1   1.0.28-8
ii  libspnav0 0.2.3-1+b2
ii  libstdc++610.2.0-16
ii  libswscale5   7:4.3.1-5
ii  libtbb2   2020.3-1
ii  libtiff5  4.1.0+git191117-2
ii  libx11-6  2:1.6.12-1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxml2   2.9.10+dfsg-6.2
ii  libxrender1   1:0.9.10-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  zlib1g1:1.2.11.dfsg-2

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#969415: xfstt: Tiny typo in the description

[Alberto Luaces]

Package: xfstt
Severity: minor
Tags: patch

There is a tiny typo in the description: remove → remote.
>From e15c7a04acc724100c517feec21e4f2c0a8a8f16 Mon Sep 17 00:00:00 2001
From: Alberto Luaces 
Date: Wed, 2 Sep 2020 13:37:54 +0200
Subject: [PATCH] =?UTF-8?q?fix=20git=20typo:=20remove=20=E2=86=92=20remote?=
 =?UTF-8?q?.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 1547385..cc39d3d 100644
--- a/debian/control
+++ b/debian/control
@@ -28,6 +28,6 @@ Description: X Font Server for TrueType fonts
  as the TrueType fonts used on Windows operating systems.
  .
  Note: On Debian and derivatives, the X.Org server has the font server support
- disabled, so xfstt is mostly useful to serve fonts to remove systems.
+ disabled, so xfstt is mostly useful to serve fonts to remote systems.
  .
  Note: This package does not contain fonts. They must be obtained separately.
-- 
2.28.0

Bug#961997: openscenegraph: Cannot migrate to testing (Not built on buildd)

[Alberto Luaces]

Hi,

> Please do a source-only upload to unstable

Yes, I always do, including this release.  But this time there was some
hiccup on the ftp queue that silently held the release, so the last
thing I tried was to see if the source-only upload was being the culprit.

> and coordinate transitions in
> the future. Be sure to read the related documentation:
> 
>  https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> 

Sorry about that, I missed that one.  Now I even remember that you
helped me with the last one :-)

In fact part of the reasons for updating was a request from the openmw
team.  I have seen that they say the FTBFS will be fixed with the new
release of openmw.  I will see if that is also true for flightgear.

Regards,

Alberto

Bug#955727: fotoxx: dcraw is required, but it is not yet a dependency

[Alberto Luaces]

Source: fotoxx
Version: 20.08-1
Severity: grave
Justification: renders package unusable

When starting the program, it checks if "dcraw" executable is found,
and if that it not the case, the program is closed, hence the severity
of the bug report.
   
The solution is to add the package "dcraw" to the list of
dependencies.

A patch is submitted as a MR in salsa.

Regards.

Bug#945875: openmw: Crash when saving

[Alberto Luaces]

severity 945875 normal
thanks

Adjusting severity for openscenegraph.

Bug#945875: openmw: Crash when saving

[Alberto Luaces]

On 27/3/20 10:57, Bret Curtis wrote:
> Man, it's be in there a month. It would be a pity to see OSG be broken
> in Buster, but hopefully we get it in before Ubuntu's LTS 20.04 Focal
> release. :/
> 
> I hope it gets uploaded soon.

Well, you know that people have lives outside this scene :-)

Nevertheless, if any DD is willing to do the uploading, we would also be
grateful -- just tell us beforehand in order to not collide.

Bug#945875: openmw: Crash when saving

[Alberto Luaces]

On 27/3/20 8:26, Bret Curtis wrote:
> The best way forward in resolving this bug is to get OpenSceneGraph
> package bumped to 3.6.5 right away. This requires the help of Alberto
> Fernández, it's package maintainer.
> https://tracker.debian.org/pkg/openscenegraph

Him, OSG 3.6.5 is ready
(https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/blob/master/debian/changelog),
I'm just waiting for Manuel to upload it.

Regards,

Alberto

Bug#947008: sendxmpp: Formatting codes leak into the man page

[Alberto Luaces Fernández]

Hi, it is the first one:

https://salsa.debian.org/xmpp-team/sendxmpp/merge_requests/1

Regards,

Alberto

Bug#947790: openscenegraph-3.4: osgPlugins-3.4.1/osgdb_png.so not build on ARM

[Alberto Luaces Fernández]

Hi, Gaetan:

This seems like something in the toolchain or the 3.4 version of OSG.  I
have checked in the 3.6 version of the package
(https://packages.debian.org/bullseye/armhf/libopenscenegraph160/filelist)
and the plugin is there.

I will try at least to make it build the plugin in stable as you did.

Regards,

Alberto

Bug#947008: sendxmpp: Formatting codes leak into the man page

[Alberto Luaces]

Package: sendxmpp
Version: 1.24-2
Severity: minor
Tags: patch upstream a11y

Some formatting characters in the POD are not interpreted in the
configuration section, so the user is mislead into thinking that each
value has to be prepended by "I<".

I have made a pull request in salsa, and a similar fix is also present
in upstream:

https://github.com/lhost/sendxmpp/commit/9186b8c49e54cf59ace4e5ddf52aa10b1a386fa5

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sendxmpp depends on:
ii  libnet-xmpp-perl  1.05-1
ii  perl  5.30.0-9

sendxmpp recommends no packages.

sendxmpp suggests no packages.

-- no debconf information

Bug#945598: openscenegraph: Plugin detection for movie files fails to select osgdb_ffmpeg.so

[Alberto Luaces]

Package: openscenegraph
Version: 3.6.4+dfsg1-2
Severity: normal
Tags: upstream

Movie files cannot be played with present3D or osgmovie since the plugin 
subsystem is unable to match popular extensions to the ffmpeg plugin:

strace -e trace=openat osgmovie file.avi

...
openat(AT_FDCWD, "osgPlugins-3.6.4/osgdb_avi.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT
...

Nevertheless, forcing the plugin selection by using the ffmpeg extension works:

osgmovie file.avi.ffmpeg


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openscenegraph depends on:
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-19
ii  libgl11.1.0-1+b1
ii  libopenscenegraph160  3.6.4+dfsg1-2
ii  libopenthreads21  3.6.4+dfsg1-2
ii  libstdc++69.2.1-19

openscenegraph recommends no packages.

openscenegraph suggests no packages.

-- no debconf information

Bug#944741: transition: openscenegraph

[Alberto Luaces]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi, the package openscenegraph-3.4 is being replaced by
openscenegraph, already in the archives.  Their rdeps build fine
against openscenegraph.

The plan is to eventually remove openscenegraph-3.4 since it is not
used anymore.

Can you issue the transition for me, please?

Thank you!

Ben file:

title = "openscenegraph-3.4-rm";
is_affected = (.build-depends ~ 
/\b(libopenscenegraph\-3\.4\-dev|openscenegraph\-3\.4)\b/)|(.depends ~ 
/\b(libopenscenegraph\-3\.4\-(131|dev)|openscenegraph\-3\.4(\-(doc|examples))?)\b/);
is_good = false
is_bad = .depends ~ 
/\b(libopenscenegraph\-3\.4\-(131|dev)|openscenegraph\-3\.4(\-(doc|examples))?)\b/;

Bug#944550: openscenegraph-3.4: should this package be removed?

[Alberto Luaces Fernández]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Andreas Beckmann writes:

> Source: openscenegraph-3.4
> Version: 3.4.1+dfsg1-5
> Severity: serious
> Tags: sid
>
> with openscenegraph 3.6 uploaded to sid, should the now older
> openscenegraph-3.4 be removed?

Yes, please! :-)
-BEGIN PGP SIGNATURE-

iJUEARMJAB0WIQQAkrD2fjOKzJT6ErrYoCh5SUbfSgUCXcnH3AAKCRDYoCh5SUbf
SloqAYDFvJcsgSAEylwA0hG/nh1/qNMCTpOhwaNRH3BjYdeQ/oqScocI3POP4A5x
ECG4YSYBgNb4xbBcunxTN4fbf7q1EfBxt7ZiJob4ka1EAJyeKvJ5b9zk7GZtVg1E
+YQt2GreOA==
=8Hj3
-END PGP SIGNATURE-

Bug#944529: osgearth: Please upgrade to OSG 3.6

[Alberto Luaces]

Package: osgearth
Severity: normal
Tags: patch

Dear Maintainer,

openscenegraph version 3.6 is available in the archive under the package 
"openscenegraph".

A patch is attached with the required changes.

Thank you!
>From b4567970d0ae8b99af23e93ae3d340659aafe3bc Mon Sep 17 00:00:00 2001
From: Alberto Luaces 
Date: Fri, 8 Nov 2019 13:57:56 +0100
Subject: [PATCH] Summary: 3.6

---
 debian/control | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/debian/control b/debian/control
index 22e255e..cae7f5a 100644
--- a/debian/control
+++ b/debian/control
@@ -7,8 +7,8 @@ Priority: optional
 Build-Depends: debhelper (>= 9),
dpkg-dev (>= 1.16.1.1),
cmake,
-   openscenegraph-3.4,
-   libopenscenegraph-3.4-dev,
+   openscenegraph,
+   libopenscenegraph-dev,
libcurl4-gnutls-dev | libcurl-ssl-dev,
libgdal-dev (>= 1.10.1~),
libgeos-dev,
@@ -62,7 +62,7 @@ Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Suggests: openscenegraph-3.4
+Suggests: openscenegraph
 Breaks: libosgearth1 (<< 2.4.0+dfsg-4~),
 osgearth (<< 1.4-2)
 Replaces: libosgearth1 (<< 2.4.0+dfsg-4~),
@@ -82,7 +82,7 @@ Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Suggests: openscenegraph-3.4
+Suggests: openscenegraph
 Description: Dynamic 3D terrain rendering toolkit for OpenSceneGraph 
(osgEarthAnnotation)
  osgEarth is a scalable terrain rendering toolkit for OpenSceneGraph
  (OSG), an open source, high performance, 3D graphics toolkit. Just create a
@@ -98,7 +98,7 @@ Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Suggests: openscenegraph-3.4
+Suggests: openscenegraph
 Description: Dynamic 3D terrain rendering toolkit for OpenSceneGraph 
(osgEarthFeatures)
  osgEarth is a scalable terrain rendering toolkit for OpenSceneGraph
  (OSG), an open source, high performance, 3D graphics toolkit. Just create a
@@ -114,7 +114,7 @@ Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Suggests: openscenegraph-3.4
+Suggests: openscenegraph
 Description: Dynamic 3D terrain rendering toolkit for OpenSceneGraph 
(osgEarthSplat)
  osgEarth is a scalable terrain rendering toolkit for OpenSceneGraph
  (OSG), an open source, high performance, 3D graphics toolkit. Just create a
@@ -130,7 +130,7 @@ Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Suggests: openscenegraph-3.4
+Suggests: openscenegraph
 Description: Dynamic 3D terrain rendering toolkit for OpenSceneGraph 
(osgEarthSymbology)
  osgEarth is a scalable terrain rendering toolkit for OpenSceneGraph
  (OSG), an open source, high performance, 3D graphics toolkit. Just create a
@@ -146,7 +146,7 @@ Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Suggests: openscenegraph-3.4
+Suggests: openscenegraph
 Description: Dynamic 3D terrain rendering toolkit for OpenSceneGraph 
(osgEarthUtil)
  osgEarth is a scalable terrain rendering toolkit for OpenSceneGraph
  (OSG), an open source, high performance, 3D graphics toolkit. Just create a
@@ -180,7 +180,7 @@ Depends: libosgearth5 (= ${binary:Version}),
  libosgearthsplat5 (= ${binary:Version}),
  libosgearthsymbology5 (= ${binary:Version}),
  libosgearthutil5 (= ${binary:Version}),
- libopenscenegraph-3.4-dev,
+ libopenscenegraph-dev,
  libgeos-dev,
  ${misc:Depends}
 Replaces: osgearth-dev
-- 
2.24.0

Bug#944526: simgear: Please upgrade to OSG 3.6

[Alberto Luaces]

Package: simgear
Severity: normal
Tags: patch

Dear Maintainer,

openscenegraph version 3.6 is available in the archive under the package 
"openscenegraph".

A patch is attached with the required changes.

Thank you!
>From 4d35d1f66479ecb2c8ae47565c2581889759a1c2 Mon Sep 17 00:00:00 2001
From: Alberto Luaces 
Date: Fri, 8 Nov 2019 13:47:31 +0100
Subject: [PATCH] Summary: 3.6

---
 debian/control | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 2906c0f..5cc7643 100644
--- a/debian/control
+++ b/debian/control
@@ -13,8 +13,7 @@ Build-Depends: cmake,
libgl1-mesa-dev,
libglu1-mesa-dev,
libopenal-dev,
-   libopenscenegraph-3.4-dev [!armel !armhf],
-   libopenscenegraph-dev [armel armhf],
+   libopenscenegraph-dev,
libudns-dev,
libutfcpp-dev,
netbase,
@@ -29,8 +28,7 @@ Architecture: any
 Multi-Arch: same
 Section: libdevel
 Depends: libc6-dev,
- libopenscenegraph-3.4-dev [!armel !armhf],
- libopenscenegraph-dev [armel armhf],
+ libopenscenegraph-dev,
  ${misc:Depends}
 Description: Simulator Construction Gear -- development files
  SimGear is a collection of libraries useful for constructing
-- 
2.24.0

Bug#944524: openmw: Please upgrade to OSG 3.6

[Alberto Luaces]

Package: openmw
Severity: normal
Tags: patch

Dear Maintainer,

openscenegraph version 3.6 is available in the archive under the package 
"openscenegraph".

A patch is attached with the required changes.

Thank you!
>From 17a9d59db1c91a07998c77f33ff6bf4f2e80dd2c Mon Sep 17 00:00:00 2001
From: Alberto Luaces 
Date: Fri, 8 Nov 2019 13:44:06 +0100
Subject: [PATCH] 3.6

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 911d392..6a8b3e8 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends: debhelper (>= 9~), cmake (>= 3) | cmake3,
  libboost-filesystem-dev, libboost-iostreams-dev, 
libboost-program-options-dev, libboost-thread-dev,
  libopenal-dev, libtinyxml-dev, libavcodec-dev, libavformat-dev,
  libavutil-dev, libswscale-dev, libswresample-dev, libsdl2-dev,
- libmygui-dev (>= 3.2.1), libunshield-dev, libopenscenegraph-3.4-dev,
+ libmygui-dev (>= 3.2.1), libunshield-dev, libopenscenegraph-dev,
  libqt5opengl5-dev, libqt5opengl5-desktop-dev [armel armhf]
 Standards-Version: 4.3.0
 Homepage: http://openmw.org
-- 
2.24.0

Bug#944517: openscenegraph-3.4: FTBFS in sid after latest openscenegraph

[Alberto Luaces Fernández]

Thank you for the report.

The plan is to remove this package altogether from the archive and
replace it with openscenegraph.

I am going to fill the bug reports for the rdeps, and then ask for the
removal of 3.4.

Regards,

Alberto

On 11/11/19 10:32, Gianfranco Costamagna wrote:
> Source: openscenegraph-3.4
> Version: 3.4.1+dfsg1-5
> Severity: serious
> 
> Hello, looks like there is some thread link problem in the package after the 
> latest openscenegraph upload in sid:
> 
> [snip]
> dpkg-shlibdeps: error: cannot find library libOpenThreads.so.20 needed by 
> debian/libopenscenegraph-3.4-131/usr/lib/x86_64-linux-gnu/libosgText.so.3.4.1 
> (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
> dpkg-shlibdeps: error: cannot find library libOpenThreads.so.20 needed by 
> debian/openscenegraph-3.4/usr/bin/osgtext (ELF format: 'elf64-x86-64' abi: 
> '0201003e'; RPATH: '')
> dpkg-shlibdeps: error: cannot find library libOpenThreads.so.20 needed by 
> debian/libopenscenegraph-3.4-131/usr/lib/x86_64-linux-gnu/libosg.so.3.4.1 
> (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
> [snip]
> 
> the library seems to be now at SONAME 21, but I have no clue about what might 
> be wrong...
> 
> G.
> 



signature.asc
Description: OpenPGP digital signature

Bug#875075: [openscenegraph] Future Qt4 removal from Buster

[Alberto Luaces Fernández]

>See `dak rm -Rn openscenegraph-3.4` on mirror.ftp-master.debian.org.

If somebody can do it, I would be grateful. I am a DM and I lack the required 
permissions.

Bug#875075: [openscenegraph] Future Qt4 removal from Buster

[Alberto Luaces Fernández]

Hi, openscenegraph-3.4 can be removed from the archive safely.
Initially we planned to supersede it with src:openscenegraph-3.6, but we
are finally updating the original src:openscenegraph package.

The release is ready and waiting for being uploaded:

https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2



signature.asc
Description: OpenPGP digital signature

Bug#875075: [openscenegraph] Future Qt4 removal from Buster

[Alberto Luaces Fernández]

On 18/8/19 9:02, Sebastiaan Couwenberg wrote:
> On Sat, 23 Sep 2017 11:47:59 +0200 "Manuel A. Fernandez Montecelo" wrote:
>> This package will be removed after rdeps migrate to openscenegraph-3.4 or a 
>> later version (which does support Qt5), or rdeps are removed, or if nothing 
>> else, when the removal of Qt4 happens.
>>
>> (We plan to poke rdeps withing a few months, we don't want this version 
>> shipped in Buster).
> 
> The only remaining libopenscenegraph100v5 rdeps are opensurgsim & kido,
> I wouldn't wait for them to stop using openscenegraph.
> 
> More problematic is that the libopenthreads packages are still only
> provided by openscenegraph and not openscenegraph-3.4. Please stop
> providing those packages from src:openscenegraph and build them from
> src:openscenegraph-3.4 instead.
> 
> This RC bug affects all rdeps of openscenegraph-3.4 too because of that.
> 

Hi, Bas.

Our plan is to replace everything with the latest stable version of OSG
(3.6.4), whose packaging is almost complete.  It will provide
OpenThreads as well.

Regards,

Alberto

Bug#917516: anbox: does not pull binder or ashmem kernel drivers as dependency

[Alberto Luaces Fernández]

What is the status of the user unit?

systemctl --user status anbox-session-manager

Can you verify both kernel modules are loaded correctly?

ls /dev/{binder,ashmem}

Bug#928356: elpa-magit: diff buffer when committing is often useless/wrong

[Alberto Luaces Fernández]

Hi, Robbie.  Are you pressing the 'g' key (reload) after each change?

Bug#926864: python3-numba: Insufficiently recent colorama version found.

[Alberto Luaces Fernández]

severity -1 normal
thanks

Sorry, I misread the warning (not error) message.

Bug#926864: python3-numba: Insufficiently recent colorama version found.

[Alberto Luaces Fernández]

severity 926864 grave
thanks

Raising the severity of the bug, since it renders the package unusable.
 The module cannot be even loaded.

Bug#927966: kdiff3: Outdated Homepage: field in debian/control

[Alberto Luaces]

Package: kdiff3
Version: 1.7.90-3
Severity: minor

Dear Maintainer,

the Homepage field in d/control is outdated, pointing to the
sourceforge respository which got stalled at version 0.9.98
(2014-07-04).

In the same spirit as the current update of d/copyright for the same
reason, I think it would be sensible to also set that field to
https://kde.org/applications/development/kdiff3 .

Bug#921431: hotspot: perf parsing is failing: no symbols are shown

[Alberto Luaces]

Package: hotspot
Version: 1.1.0+git20180816-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

when capturing or reading laready existent "perf.data" files, Debian's
hotspot does not shown any information in any tab, except for the
graph showing the CPU use.  Upstream performs fine with the same
scenario.

Maybe it is related to the fact that upstream is using a patched
perfparser library, since I am having notifications like this when
running Debian's package:

hotspot.perfparser: Unexpected attribute id: -1 Only know about 1 attributes so 
far

I am tagging this bug as grave since with no symbol information
available, no profiling can be done at all, since the bottlenecks
cannot be shown.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hotspot depends on:
ii  kio   5.54.1-1
ii  libc6 2.28-5
ii  libdw10.175-2
ii  libelf1   0.175-2
ii  libgcc1   1:8.2.0-16
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5itemmodels5 5.54.0-1
ii  libkf5itemviews5  5.54.0-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5solid5  5.54.0-1
ii  libkf5threadweaver5   5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libqt5core5a  5.11.3+dfsg-2
ii  libqt5gui55.11.3+dfsg-2
ii  libqt5network55.11.3+dfsg-2
ii  libqt5widgets55.11.3+dfsg-2
ii  libstdc++68.2.0-16
ii  linux-perf4.19+101
ii  policykit-1   0.105-25

hotspot recommends no packages.

hotspot suggests no packages.

-- no debconf information

Bug#917553: org-mode: sb-html.el required for exporting to html format

[Alberto Luaces Fernández]

close -1
thanks

On 28/12/18 17:59, Bastien wrote:
> Hi Alberto,
> 
> Alberto Luaces  writes:
> 
>> when exporting any .org file to .html (C-c C-e h h), an error is
>> issued about a non-existent sb-html file or directory.
> 
> there is no sb-html file in Org's source.  Maybe this is a local
> problem, due to a buffer referring to a non-existent file in your
> system?  Can you reproduce the problem with emacs -Q and loading
> your current Org config?
> 

I found the cause: an old configuration file in /etc/emacs/site-start.d/
from the now non-existent speedbar package was setting html-mode-hook.
Purging that package solved the problem.

I realized that after seeing that emacs -Q did not expose the problem,
but emacs -q did.

Thanks, Bastien!

Bug#917553: org-mode: sb-html.el required for exporting to html format

[Alberto Luaces]

Package: org-mode
Version: 9.1.14+dfsg-3
Severity: normal

Dear Maintainer,

when exporting any .org file to .html (C-c C-e h h), an error is
issued about a non-existent sb-html file or directory.

I have not found any emacs package that provides that file in Debian.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages org-mode depends on:
ii  elpa-org  9.1.14+dfsg-3

org-mode recommends no packages.

org-mode suggests no packages.

-- no debconf information

Bug#916997: clang-tidy: manpage is empty

[Alberto Luaces]

Package: clang-tidy
Version: 1:7.0-46
Severity: minor

Dear Maintainer,

the manpage is empty (size 0 bytes).  That confused me since "man
clang-tidy" displayed an empty page.

"help2man" can be useful to create one from "--help".

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-tidy depends on:
ii  clang-tidy-7  1:7.0.1-1

clang-tidy recommends no packages.

clang-tidy suggests no packages.

-- no debconf information

Bug#915390: clazy: Segmentation fault compiling any file

[Alberto Luaces Fernández]

Hi, Lisandro:

On 3/12/18 22:55, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi Alberto!
> 
> El lun., 3 dic. 2018 09:48, Alberto Luaces  <mailto:alua...@udc.es>> escribió:
> 
> Package: clazy
> Version: 1.4-3
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> attempting to compile any file on my system results in a segfault.
> Could it be that a runtime dependency is missing from d/control?
> 
> 
> Clazy calls clang, so maybe that's what's missing. I can't tell you
> right now which package it is, but should be easy to find.

I had clang (and thus clang-6.0) installed.  I tried again by installing
clang-7, but with similar results.

In fact, the clazy script makes this call, as shown in the original report:

/usr/lib/llvm-6.0/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj ...

so it seems it is using clang-6.  However,

> ldd /usr/lib/x86_64-linux-gnu/ClangLazy.so
linux-vdso.so.1 (0x7fff6b6da000)
libLLVM-7.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1 ...

so the plugin is built against LLVM 7.

Chaging the script to call clang-7 instead results in no errors, so it
should be a matter of adjusting it and requiring clang-7 in d/control as
a dependency.

Regards,

Alberto

Bug#915390: clazy: Segmentation fault compiling any file

[Alberto Luaces]

Package: clazy
Version: 1.4-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

attempting to compile any file on my system results in a segfault.
Could it be that a runtime dependency is missing from d/control?

Steps to reproduce:

> touch a.cpp
> clazy a.cpp 
#0 0x7f825a95352a llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x92152a)
#1 0x7f825a95164e llvm::sys::RunSignalHandlers() 
(/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x91f64e)
#2 0x7f825a9517dd (/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x91f7dd)
#3 0x7f825dc2b8e0 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x128e0)
#4 0x7f8254bc6ac4 (/usr/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x106dac4)
#5 0x7f82543e9c78 
llvm::WebAssemblyTargetWasmStreamer::emitGlobalImport(llvm::StringRef) 
(/usr/lib/x86_64-linux-gnu/libLLVM-7.so.1+0x890c78)
#6 0x7f825dca90ca (/lib64/ld-linux-x86-64.so.2+0xf0ca)
#7 0x7f825dca91d6 (/lib64/ld-linux-x86-64.so.2+0xf1d6)
#8 0x7f825dcad253 (/lib64/ld-linux-x86-64.so.2+0x13253)
#9 0x7f8259a41adf _dl_catch_exception 
(/lib/x86_64-linux-gnu/libc.so.6+0x133adf)
#10 0x7f825dcacb1a (/lib64/ld-linux-x86-64.so.2+0x12b1a)
#11 0x7f82594a0276 __asprintf (/lib/x86_64-linux-gnu/libdl.so.2+0x1276)
#12 0x7f8259a41adf _dl_catch_exception 
(/lib/x86_64-linux-gnu/libc.so.6+0x133adf)
#13 0x7f8259a41b6f _dl_catch_error 
(/lib/x86_64-linux-gnu/libc.so.6+0x133b6f)
#14 0x7f82594a0975 (/lib/x86_64-linux-gnu/libdl.so.2+0x1975)
#15 0x7f82594a0331 dlopen (/lib/x86_64-linux-gnu/libdl.so.2+0x1331)
#16 0x7f825a93dc53 llvm::sys::DynamicLibrary::HandleSet::DLOpen(char 
const*, std::__cxx11::basic_string, 
std::allocator >*) (/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x90bc53)
#17 0x7f825a93def2 llvm::sys::DynamicLibrary::getPermanentLibrary(char 
const*, std::__cxx11::basic_string, 
std::allocator >*) (/usr/lib/x86_64-linux-gnu/libLLVM-6.0.so.1+0x90bef2)
#18 0x55d0d6d7daba 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
(/usr/lib/llvm-6.0/bin/clang+0x8e9aba)
#19 0x55d0d68d8678 cc1_main(llvm::ArrayRef, char const*, 
void*) (/usr/lib/llvm-6.0/bin/clang+0x444678)
#20 0x55d0d68c8117 main (/usr/lib/llvm-6.0/bin/clang+0x434117)
#21 0x7f8259930b17 __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x22b17)
#22 0x55d0d68d665a _start (/usr/lib/llvm-6.0/bin/clang+0x44265a)
Stack dump:
0.  Program arguments: /usr/lib/llvm-6.0/bin/clang -cc1 -triple 
x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier 
-discard-value-names -main-file-name a.cpp -mrelocation-model static 
-mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose 
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 
-dwarf-column-info -debugger-tuning=gdb -resource-dir 
/usr/lib/llvm-6.0/lib/clang/6.0.1 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8 
-internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8
 -internal-isystem 
/usr/bin/../lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/backward 
-internal-isystem /usr/include/clang/6.0.1/include/ -internal-isystem 
/usr/local/include -internal-isystem /usr/lib/llvm-6.0/lib/clang/6.0.1/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-fdeprecated-macro -fdebug-compilation-dir /home/alberto/tmp/biolim/build_clazy 
-ferror-limit 19 -fmessage-length 190 -fobjc-runtime=gcc -fcxx-exceptions 
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -load ClangLazy.so 
-add-plugin clang-lazy -o /tmp/a-239fc9.o -x c++ a.cpp 
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see 
invocation)
clang version 6.0.1-9.2 (tags/RELEASE_601/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to 
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and 
associated run script.
clang: error: unable to execute command: Bus error
clang: note: diagnostic msg: Error generating preprocessed source(s).

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clazy depends on:
ii  libc6   2.27-8
ii  libgcc1 1:8.2.0-9
ii  libllvm71:7-6
ii  libstdc++6  8.2.0-9

clazy recommends no packages.

clazy suggests no packages.

Bug#909797: valgrind: Assertion 'cfsi_fits' fails when debugging BLAS-dependent programs

[Alberto Luaces]

Package: valgrind
Version: 1:3.13.0-2.1
Severity: important
Tags: upstream patch

Dear Maintainer,

programs that link to BLAS library make valgrind fail with the assertion in the 
subject.

It seems that upstream has solved it in

https://bugs.kde.org/show_bug.cgi?id=398028#c13

Can you please backport the fix?

Thanks!

This is the complete error output:

valgrind ./lapack
==26588== Memcheck, a memory error detector
==26588== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26588== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26588== Command: ./lapack
==26588== 

valgrind: m_debuginfo/debuginfo.c:551 (check_CFSI_related_invariants): 
Assertion 'cfsi_fits' failed.

host stacktrace:
==26588==at 0x5804503A: show_sched_status_wrk (m_libcassert.c:355)
==26588==by 0x58045154: report_and_quit (m_libcassert.c:426)
==26588==by 0x580452D9: vgPlain_assert_fail (m_libcassert.c:492)
==26588==by 0x58079BEF: check_CFSI_related_invariants (debuginfo.c:551)
==26588==by 0x58079BEF: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:766)
==26588==by 0x58079BEF: vgPlain_di_notify_mmap (debuginfo.c:1061)
==26588==by 0x580A5381: vgModuleLocal_generic_PRE_sys_mmap 
(syswrap-generic.c:2388)
==26588==by 0x580DC2C4: vgSysWrap_amd64_linux_sys_mmap_before 
(syswrap-amd64-linux.c:400)
==26588==by 0x580A1B13: vgPlain_client_syscall (syswrap-main.c:1857)
==26588==by 0x5809E37A: handle_syscall (scheduler.c:1126)
==26588==by 0x5809FAA6: vgPlain_scheduler (scheduler.c:1443)
==26588==by 0x580AFC40: thread_wrapper (syswrap-linux.c:103)
==26588==by 0x580AFC40: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 26588)
==26588==at 0x401A693: mmap (mmap64.c:52)
==26588==by 0x40060AD: _dl_map_segments (dl-map-segments.h:94)
==26588==by 0x40060AD: _dl_map_object_from_fd (dl-load.c:1181)
==26588==by 0x400890E: _dl_map_object (dl-load.c:2461)
==26588==by 0x400D061: openaux (dl-deps.c:63)
==26588==by 0x401950A: _dl_catch_exception (dl-error-skeleton.c:196)
==26588==by 0x400D2F2: _dl_map_object_deps (dl-deps.c:249)
==26588==by 0x4003D95: dl_main (rtld.c:1726)
==26588==by 0x401862F: _dl_sysdep_start (dl-sysdep.c:253)
==26588==by 0x40020D7: _dl_start_final (rtld.c:414)
==26588==by 0x40020D7: _dl_start (rtld.c:521)
==26588==by 0x4001217: ??? (in /lib/x86_64-linux-gnu/ld-2.27.so)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

Bug#909061: ITP: openscenegraph-3.6 -- 3D scene graph C++ framework

[Alberto Luaces]

Package: wnpp
Severity: wishlist
Owner: Alberto Luaces 

* Package name: openscenegraph-3.6
  Version : 3.6.3
  Upstream Author : Robert Osfield 
* URL : http://www.openscenegraph.org/
* License : OpenSceneGraph Public License, OSGPL
  Programming Lang: C++
  Description : 3D scene graph C++ framework

 A portable, high level graphics toolkit for the development of high
 performance graphics applications such as flight simulators, games,
 virtual reality or scientific visualization.  Providing an object
 orientated framework on top of OpenGL, it frees the developer from
 implementing and optimizing low level graphics calls, and provide
 many additional utilities for rapid development of graphics
 applications.

This package intends to bring the new stable 3.6 series, replacing 3.4
and 3.2 already present in the repository.

Bug#908664: collada-dom: Please use this patch to fix FTBFS on kfreebsd-*

[Alberto Luaces]

Source: collada-dom
Severity: serious
Tags: patch upstream
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Since the package openscenegraph-3.4 now depends on collada-dom, its FTBFS on 
kfreebsd-* makes it unavailable as well.

The fix is really straigthforward, and it has been submitted as a Salsa Pull 
Request (#1).

Can you please make a release addressing this point?

Thanks!

Bug#814190: tails-installer: Fails to unmount USB: Not authorized

[Alberto Luaces]

Package: tails-installer
Version: 5.0.8+dfsg-1
Followup-For: Bug #814190

Another i3wm user here.

I read somewhere a solution for an unrelated policykit problem: just have 
running

/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1

before and meanwhile tails-installer is called.  A graphical
authentication dialog shows up, instead of asking it directly on the
console, and furthermore it works this time.

As other users have stated, when issuing "pkexec whoami" I get an
authentication error.  If I have running
"polkit-gnome-authentication-agent-1" as shown above, the graphical
dialog is also issued and then the answer is "root".

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tails-installer depends on:
ii  dosfstools 4.1-2
ii  gdisk  1.0.3-1+b1
ii  genisoimage9:1.1.11-3+b2
ii  gir1.2-glib-2.01.56.1-1
ii  gir1.2-gtk-3.0 3.22.30-2
ii  gir1.2-udisks-2.0  2.7.6-3
ii  mtools 4.0.18-2+b1
ii  p7zip-full 16.02+dfsg-6
ii  policykit-10.105-21
ii  python 2.7.15-3
ii  python-configobj   5.0.6-2
ii  python-gi  3.28.2-1+b1
ii  python-urlgrabber  3.10.2-1
ii  syslinux   3:6.03+dfsg1-2
ii  syslinux-common3:6.03+dfsg1-2
ii  udisks22.7.6-3

tails-installer recommends no packages.

tails-installer suggests no packages.

-- no debconf information

Bug#902845: simplesnap: Typo in debian/control: "nlike"

[Alberto Luaces]

Package: simplesnap
Severity: minor

Dear Maintainer,

There is a typo in the description of the package (debian/control):

nlike → Unlike.

Regards.

Bug#886243: freerdp2-shadow-x11 on startuo

[Alberto Luaces Fernández]

> Can you guys try again with the latest freerdp2 version in Debian
> testing? I don't get this issue anymore.

Now it is not SIGSEVing for me anymore as well, but I cannot connect to the 
server, possibly an unrelated issue.

I never used this feature before, so I don't know if my setup is to blame.  I'd 
better wait for other users that have been using the server feature before to 
confirm if everything is back to normal.

Bug#893600: clang-tidy-4.0: Should depend on clang-tools-4.0

[Alberto Luaces]

Package: clang-tidy-4.0
Version: 1:4.0.1-10
Severity: normal

Dear Maintainer,

if clang-tools-4.0 is not installed, running `run-clang-tidy` and the
option `-fix` results in an unhandled python exception about a missing
file.  Upon closer examination with the debugger, it is apparent that
the missing script/file is provided by the other package.

Installing it makes `-fix` work again.

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

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

Versions of packages clang-tidy-4.0 depends on:
ii  libc6   2.27-2
ii  libgcc1 1:8-20180312-2
ii  libllvm4.0  1:4.0.1-10
ii  libstdc++6  8-20180312-2
ii  python  2.7.14-4

clang-tidy-4.0 recommends no packages.

clang-tidy-4.0 suggests no packages.

-- no debconf information

Bug#890878: RFS: company-irony

[Alberto Luaces]

Hi Nicholas,

Nicholas D Steeves writes:

[...]

Thanks again for your advice!

>> > I: company-irony source: testsuite-autopkgtest-missing
>> 
>> This is N/A, I think.
>
> It's not required at this point in time, but someday it's possible
> that self tests will be required.  Dh_elpa_test runs the tests as part
> of a package build, and autopkgtest is a framework that automates
> testing of packages in a container or virtual machine.  Because this
> is Informational level lint it's not high priority for Lintian, but if
> you ever want to write a test that gets an company-irony autocompleted
> list for something, and then compares that against the expected list,
> in the expected order.  Tests that provide assurances it won't do
> hilarious/embarrassing autocompletion like cell phones do.  A Nice to
> have, later, if you have time and find the challenge interesting ;-)
>

Ok.  I don't have currently the skills for writing those tests, but
maybe in the future I can try to learn from some other packages.

[...]

>
> Because for now the most pressing issue is that it doesn't initialise
> properly...
>
>   Company backend 'company-clang' could not be initialized:
>   Company found no clang executable
>
> This was both with no configuration (and M-x company-mode), and with
> following upstream's README in a clean sid chroot.  I opened a random
> cpp from kdeconnect to test.  I suspect a documentation of
> configuration issue because I would have expected company-irony to
> load rather than company-clang...but it's possibly a bug.
>
> Please let me know how you made company-irony work.

Oh, yes, I think this is expected.  From the documentation at

/usr/share/doc/elpa-company-irony/README.md

--8<---cut here---start->8---

## Configuration

Add `company-irony` to your company backends.

~~~el
(eval-after-load 'company
  '(add-to-list 'company-backends 'company-irony))
~~~

--8<---cut here---end--->8---


Regards,

Alberto

Bug#890878: RFS: company-irony

[Alberto Luaces]

Thanks again, Nicholas:

Nicholas D Steeves writes:

> W: company-irony source: out-of-date-standards-version 4.1.1 (current is 
> 4.1.3)

Ok.  Upgraded to 4.1.3 while checking that it complains with the Policy
upgrades: basically none of them applied, except for the Vcs-* one, that
this package is already compliant with.

> I: company-irony source: testsuite-autopkgtest-missing

This is N/A, I think.

> W: elpa-company-irony: new-package-should-close-itp-bug

Now I have a number assigned.

> I: elpa-company-irony: extended-description-is-probably-too-short

Ok.  Rephrased.

Regards,

Alberto

Bug#892377: ITP: company-irony -- C, C++ and Objective-C completion tooltips for emacs.

[Alberto Luaces]

Package: wnpp
Severity: wishlist
Owner: Alberto Luaces <alua...@udc.es>

* Package name: company-irony
  Version : 1.1.0
  Upstream Author : Guillaume Papin <guillaume.pa...@epitech.eu>
* URL : https://github.com/Sarcasm/company-irony/
* License : GPL-3+
  Programming Lang: elisp
  Description : C, C++ and Objective-C completion tooltips for emacs.

 This package uses "irony-mode", a libclang-based code analyzer, as a
 back-end for the "company-mode" emacs completion system.

This package is meant to be maintained by the Debian Emacs Addons Team.

Bug#890878: RFS: company-irony

[Alberto Luaces]

Nicholas D Steeves writes:

[...]

>
> Hi Alberto,
>
> Welcome to the team, and thank you for packaging company-irony!  I
> consider it a valuable addition to the archive :-)  The following
> might be something you already know, but if not, here's a neat trick:
>
> Make your changes, and then while in emacs, M-x magit-status, then d u
> (diff unstaged).  Stage the changes that are part of one logical
> operation with C-, select region, then s (or just s on a hunk to
> stage the whole hunk).  Finally c c (commit staged), write your commit
> message, and finally C-c C-c.  Later you can use gbp dch -a [-N
> $upstream_version-$debian_revision, if necessary] to generate a nice 
> changelog.
>

Thanks for the tips!

>
> Hi Sean and David,
>
> I'm willing to do reviews, and want to encourage best practises and our
> team's high standards.  Please feel free to comment.
>
> debian/copyright:
>   Author's email is directly underneath Copyright in
>   company-irony.el's header.  I would either Add it to the Copyright:
>   for the 'Files: *' section, or add an Upstream-Contact field. (
>   https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#examples
>   ) Sean, what's your best practices stance on this?  I'm guessing
>   Upstream-Contact.
>

I went the route of adding the email address, but of course it can be
changed at any time.

>
> debian/gbp.conf:
>   gbp:info: Tarballs 'company-irony_1.1.0.orig.tar.xz' not found
>   gbp:warning: Pristine-tar branch "pristine-tar" not found
>   gbp:info: Creating
>   /home/sten/devel/build-area/company-irony_1.1.0.orig.tar.xz
>   gbp:error: v1.1.0 is not a valid treeish
>
>   Alberto, if you're using pristine-tar you need to push the branch;
>   alternatively, if you got upstream source from git and are not using
>   pristine-tar you need to push the upstream tag to our repo and also
>   modify gbp.conf to indicate you're not using pristine-tar.  Also,
>   for future reference, if you choose the git-only workflow you'll
>   need to push each new upstream version tag as you update the
>   package.
>

Ok, I pushed a "upstream" branch and all of its tags, so gbp should not
choke this time. 

> debian/watch:
>   Missing, please add one.  Between the one for irony-mode (watch
>   version 3, Guillaume is also the upstream for this one) and
>   fountain-mode (version 4) you should be able to figure out how to
>   produce a working v4 one ;-)  The only reason I mention
>   fountain-mode is because it's the one I've checked most recently.
>

I think I managed to get one working, from reading other packages and
the uscan manpage.

Regards,

Alberto

Bug#890878: RFS: company-irony

[Alberto Luaces]

Sean Whitton writes:

> Hello,
>
> On Wed, Feb 21 2018, Alberto Luaces wrote:
>
>> Thanks, Sean.  It is now located at
>>
>> https://salsa.debian.org/aluaces-guest/company-irony
>>
>> I guess someone else has to clone it under the team project folders,
>> so I created that personal repository first.
>
> You should be able to do it yourself... are you saying that you were
> unable to create a repo under emacsen-team?  I just bumped your
> permission level.
>

Thanks for that.  Yes, I think salsa's default permissions for non-DDs
are much more stricter than Alioth were.  Nevertheless, I have been able
to create and populate the repository under the Team's group.

>
> I don't want to upload the package with the wrong Vcs-* headers, so
> let's get this fixed first.

I have refreshed those fields.  I have not still refreshed the changelog
date in order to wait for more potential changes.

Bug#890878: RFS: company-irony

[Alberto Luaces]

Sean Whitton writes:

> Hello,
>
> On Tue, Feb 20 2018, Alberto Luaces wrote:
>
>> I would need someone to sponsor "company-irony", which is now packaged
>> and uploaded to Alioth.
>
> It should be on salsa.  alioth is shutting down in a matter of weeks.
>
> If you request access to https://salsa.debian.org/emacsen-team/ I'll
> grant it.

Thanks, Sean.  It is now located at

https://salsa.debian.org/aluaces-guest/company-irony

I guess someone else has to clone it under the team project folders, so
I created that personal repository first.

Bug#890878: RFS: company-irony

[Alberto Luaces]

Geert Stappers writes:

> On Tue, Feb 20, 2018 at 10:15:37AM +0100, Alberto Luaces wrote:
>> I would need someone to sponsor "company-irony",
>
> What is "company-irony"?
> Please tell more about it  ( think "try to sell it" )
>

Sorry about that: "company" is a completion framework for emacs.
"irony" is a completion system for C++.  "company-irony" makes irony
analysis of the source code available to the company framework, so it
makes emacs behave as a sort of IDE for C++. 

>
>> which is now packaged and uploaded to Alioth.
>
> Where?
> Please provide URL  ( think "help those you want to help you" )
>

It is in the debian-emacsen git repo:

https://anonscm.debian.org/git/pkg-emacsen/pkg/company-irony.git/

Sorry again for the confusion: the guidelines I followed implied that I
had to fill a RFS, CCing to debian-emacsen.  I understand that for other
people it can be a bit cryptic.

Alberto

Bug#890878: RFS: company-irony

[Alberto Luaces]

Package: sponsorship-requests
Severity: normal

Hello,

I would need someone to sponsor "company-irony", which is now packaged and 
uploaded to Alioth.

Thank you!

P.S.: I have followed the guidelines at the dh-make-elpa manpage.

Bug#886243: freerdp2-shadow-x11: SIGSEVs on start

[Alberto Luaces]

Package: freerdp2-shadow-x11
Version: 2.0.0~git20170725.1.1648deb+dfsg1-6
Severity: normal

Dear Maintainer,

The command just segfaults after starting it with the suggested example in the 
manual page,

freerdp-shadow-cli /port:12345

there is no difference whether it is running as a normal user or root.

The backtrace:

(gdb) bt
#0  0x756e56f0 in RSA_generate_key_ex () at 
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
#1  0x75e58344 in makecert_context_process () at 
/usr/lib/x86_64-linux-gnu/libwinpr-tools2.so.2
#2  0x779c840b in shadow_server_init () at 
/usr/lib/x86_64-linux-gnu/libfreerdp-shadow2.so.2
#3  0x4e2d in  ()
#4  0x77346561 in __libc_start_main (main=
0x4db0, argc=2, argv=0x7fffe8e8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe8d8) at 
../csu/libc-start.c:297
#5  0x50aa in _start ()

And the last line of strace points to a non-existent file, but maybe this is a 
red herring:

open("/etc/winpr/HKLM.reg", O_RDONLY)   = -1 ENOENT (No such file or directory)

Thanks!

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

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

Versions of packages freerdp2-shadow-x11 depends on:
ii  libc6   2.25-5
ii  libfreerdp-shadow-subsystem2-2  2.0.0~git20170725.1.1648deb+dfsg1-6
ii  libfreerdp-shadow2-22.0.0~git20170725.1.1648deb+dfsg1-6
ii  libwinpr2-2 2.0.0~git20170725.1.1648deb+dfsg1-6

freerdp2-shadow-x11 recommends no packages.

freerdp2-shadow-x11 suggests no packages.

-- no debconf information

Bug#884731: ITP: libpostal -- parse and normalise street addresses around the world

[Alberto Luaces]

Andrew Shadura writes:

> Package: wnpp
> Severity: wishlist
> Owner: Andrew Shadura 
>
> * Package name: libpostal
>   Version : 1.0.0
>   Upstream Author : openvenues, Mapzen
> * URL : https://github.com/openvenues/libpostal
> * License : MIT
>   Programming Lang: C
>   Description : parse and normalise street addresses around the world
>
> libpostal is a C library for parsing/normalizing street addresses around
> the world using statistical NLP and open data. The goal of this project
> is to understand location-based strings in every language, everywhere.
>
> libpostal's international address parser uses machine learning
> (Conditional Random Fields) and is trained on over 1 billion addresses
> in every inhabited country on Earth. It uses use OpenStreetMap and
  
There is a typo in the description.

-- 
Alberto

Bug#884720: borgbackup: do not run borg 1.1.x check --repair

[Alberto Luaces]

Package: borgbackup
Version: 1.1.3-2
Severity: critical
Tags: upstream
Justification: causes serious data loss

Dear Maintainer,

just in case you missed it, there is a upstream warning about data
loss when using "check --repair" on 1.1.x series:

https://mail.python.org/pipermail/borgbackup/2017q4/000949.html

A suggested fix is pointed as well in the linked mail.

Regards,

Alberto

Bug#883452: libtommath: The homepage link points to an unrelated site

[Alberto Luaces]

Source: libtommath
Severity: minor

Dear Maintainer,

The correct link to the homepage should be http://www.libtom.net/LibTomMath/

I think it is an org/net mistake.

Bug#882594: use-package: Homepage link is incorrect

[Alberto Luaces]

Source: use-package
Severity: normal

Dear Maintainer,

the homepage link listed in the debian/control file is pointing to a
different software repository (emacs-deferred).

Bug#869742: openscenegraph-3.4: GLESv2 detection compatibility with cmake >= 3.8

[Alberto Luaces]

Steve Langasek writes:

> The attached patch maintains compatibility with current cmake, while
> continuing to use GLES instead of GL on armhf.  Despite the hard-coding of
> paths this should remain fairly reliable on Debian armhf systems.
>

Thank you for the patch, Steve.  I will apply it in the incoming 3.4.1
release.

>
> You also have bug #852423 filed which is asking to use libGL instead of
> libGLESv2.  I think that would be generally disadvantageous for ARM users of
> Debian, since there exist hardware-accelerated GLES drivers for ARM but
> TTBOMK no hardware-accelerated GL drivers.  If you did decide to switch back
> to libGL, then you could also close this bug (though Ubuntu would carry a
> delta in order to continue leveraging GLES).

I agree with you.  I have done some additional research, and I will post
the conclusions there.

Bug#845054: openscenegraph-3.4 FTBFS on armel

[Alberto Luaces]

Emilio Pozuelo Monfort writes:

> I believe the attached patch should fix this bug (untested). The problem is 
> that
> Qt is using GLES on armel, but you're using big GL, and you can't mix them.

Emilio, thank you for investigating the issue and for the patch.  It
will be included in the next 3.4.1 release.

Bug#863891: /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server

[Alberto Luaces]

Oops, since reportbug only shows the first message in the bug report, I
missed the description of the workaround.

It works as well for me.

Sorry for the noise.

Bug#863891: /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server

[Alberto Luaces]

Package: xpra
Version: 0.17.6+dfsg-1
Followup-For: Bug #863891

Dear Maintainer,

this is a «me too» post in order to add some more information.

I also cannot start a new session (xpra start :20) when sitting at my
desktop from a graphical environment, unlike the original reporter
who worked from a SSH connection.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages xpra depends on:
ii  adduser   3.115
ii  libavcodec57  7:3.2.5-1
ii  libavutil55   7:3.2.5-1
ii  libc6 2.24-11+deb9u1
ii  libgtk2.0-0   2.24.31-2
ii  libswscale4   7:3.2.5-1
ii  libvpx4   1.6.1-3
ii  libx11-6  2:1.6.4-3
ii  libx264-148   2:0.148.2748+git97eaef2-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxkbfile1   1:1.0.9-2
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  python2.7.13-2
ii  python-gi-cairo   3.22.0-2
ii  python-gtk2   2.24.0-5.1
ii  python-rencode1.0.5-1
ii  x11-xserver-utils 7.7+7+b1
ii  xserver-xorg-input-void   1:1.4.1-1+b2
ii  xserver-xorg-video-dummy  1:0.3.8-1

Versions of packages xpra recommends:
ii  keyboard-configuration 1.164
ii  ksshaskpass [ssh-askpass]  4:5.8.4-1
ii  openssh-client 1:7.4p1-10
ii  python-dbus1.2.4-1+b1
ii  python-gtkglext1   1.1.0-9.1
ii  python-imaging 4.0.0-4
ii  python-lz4 0.8.2+dfsg-2
ii  python-lzo 1.08-1
ii  python-pil 4.0.0-4
ii  ssh-askpass1:1.2.4.1-9+b2

Versions of packages xpra suggests:
ii  cups-common2.2.1-8
ii  cups-filters   1.11.6-3
pn  cups-pdf   
ii  gstreamer1.0-plugins-bad   1.10.4-1
ii  gstreamer1.0-plugins-base  1.10.4-1
ii  gstreamer1.0-plugins-good  1.10.4-1
ii  gstreamer1.0-plugins-ugly  1.10.4-1
ii  openssh-server 1:7.4p1-10
ii  pulseaudio 10.0-1
ii  pulseaudio-utils   10.0-1
ii  python-avahi   0.6.32-2
ii  python-cups1.9.73-1
ii  python-gst-1.0 1.10.4-1
ii  python-netifaces   0.10.4-0.1+b2
ii  python-opencv  2.4.9.1+dfsg1-2
pn  python-pyopencl
ii  python-yaml3.12-1
pn  v4l2loopback-dkms  

-- no debconf information

Bug#859512: heaptrack: Could not find heaptrack interpreter executable: heaptrack_interpret

[Alberto Luaces]

Package: heaptrack
Version: 1.0.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

sorry I cannot be of more help since I was merely evaluating the
package, but when I try to trace the execution of any program, I get
the error:

$ heaptrack /bin/ls
Could not find heaptrack interpreter executable: 
/usr/bin/../lib/heaptrack/libexec/heaptrack_interpret

Certainly, I cannot find any heaptrack_interpret file on my system.

I am using the fish shell, but nothing changed when using bash.

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages heaptrack depends on:
ii  libboost-iostreams1.62.01.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libc6   2.24-9
ii  libgcc1 1:6.3.0-11
ii  libstdc++6  6.3.0-11
ii  zlib1g  1:1.2.8.dfsg-5

heaptrack recommends no packages.

heaptrack suggests no packages.

-- no debconf information

Bug#858171: openscenegraph outdated

[Alberto Luaces Fernández]

Dear Peter,

please use the 3.4 package, available in testing:

https://packages.qa.debian.org/o/openscenegraph-3.4.html

Regards,

Alberto

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Alberto Luaces]

Sean Whitton writes:


[... Elided completed tasks ...]

>
> Please accept my apologies for not raising these suggestions in a
> previous e-mail, and thank you for your patience with this sponsorship
> process -- I'm confident I'll be able to upload after your next update.
>
> (don't forget dch -r)

Quite the contrary, I am grateful for your guidance so far.

This time I have not set the git tag just in case some more
modifications are needed.  Now I see that it is better to leave it unset
since the uploader is the one that has the last word about it.  Please
feel free to set it if you think the package is ready for uploading.

Thanks!

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Alberto Luaces]

Hello Sean,

Sean Whitton writes:

> Hello Alberto,
>
> On Wed, Dec 28, 2016 at 11:43:29PM +0100, Alberto Luaces wrote:
>> I have now pushed a new release.
>
> Did someone else upload 0~git20161123-1?
>

No...

>
> If not, you should merge the changelog entries for -1 and -2.  It's just
> confusing to have changlog entries that never made it into the Debian
> archive.
>

Well, it seemed cleaner than modifying an already published history, but
I understand no solution is immune to drawbacks.  I have now pushed the
new, fixed branch.  Please note that you will have to re-synchronise, or
clone the repository again from scratch.

>
> After merging them, be sure to run `dch -r` to update the timestamp.
>

Done.  The timestamp is refreshed.

>
> Also, I think you need to put a tag '0_git20161123' on the upstream
> branch.  That's how gbp generates a tarball.

Done as well: upstream/0_git20161123, as gbp expects.

Thanks!

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Alberto Luaces]

Sean Whitton writes:

> Hello Alberto,
>
> On Wed, Dec 28, 2016 at 09:31:53PM +0100, Alberto Luaces wrote:
>> Thanks, Sean.  I have addressed the gbp.conf and changelog issues and I
>> think the realease is ready to go.
>
> Thanks again for your work.
>
> gbp.conf says upstream-branch=upstream but your upstream sources are on
> a branch called 'master' ...

Thanks for noticing!  Strangely enough, I missed that because gbp
buildpackage was successful nevertheless.

I have now pushed a new release.

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Alberto Luaces]

Thanks, Sean.  I have addressed the gbp.conf and changelog issues and I
think the realease is ready to go.

Please tell me if you think that something is still missing.

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Alberto Luaces]

Thanks, Sean.

After cloning the mentioned repository, one can generate both the source
and the binary packages from it issuing

gbp buildpackage --git-debian-branch=debian --git-upstream-branch=master

Bug#848687: RFS: yasnippet-snippets_0~git20161123-1

[Alberto Luaces]

Package: sponsorship-requests
Severity: normal

Hello,

I have packaged a new version of yasnippet-snippets:

https://anonscm.debian.org/git/pkg-emacsen/pkg/yasnippet-snippets.git/

I am looking for someone in the Debian Emacsen team to sponsor this
upload.

Thanks!

Bug#845061: yasnippet: Broken with emacs25

[Alberto Luaces]

Hi Sean,

actually I am in the process of packaging the most recent version with
dh_elpa, so I guess I can fix this soon.

Regards,

Alberto

Bug#843968: tipp10: The localization is always set to DE, ignoring system settings.

[Alberto Luaces]

Thank you, Christoph.

May I suggest you to at least compile those instructions into a
README.Debian file?  Otherwise, people like me, who is unable to read
German, will have a hard time trying to understand how to set the
language and use the package at all.

Bug#843968: tipp10: The localization is always set to DE, ignoring system settings.

[Alberto Luaces]

Package: tipp10
Version: 2.1.0-2
Severity: important
Tags: l10n

Dear Maintainer,

When running the program all the messages and menus are displayed in German 
regardless of the system language.

I have tried to launch it whith LANG=C or LANG=EN with the same result.

Thanks!

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

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

Versions of packages tipp10 depends on:
ii  libc6  2.24-5
ii  libgcc11:6.2.0-10
ii  libqt4-network 4:4.8.7+dfsg-9
ii  libqt4-sql 4:4.8.7+dfsg-9
ii  libqt4-sql-sqlite  4:4.8.7+dfsg-9
ii  libqtcore4 4:4.8.7+dfsg-9
ii  libqtgui4  4:4.8.7+dfsg-9
ii  libstdc++6 6.2.0-10

tipp10 recommends no packages.

tipp10 suggests no packages.

-- no debconf information

Bug#841659: ITP: zzz-to-char -- fancy version of `zap-to-char' command

[Alberto Luaces]

O 24 Outubro 2016 19:11:07 CEST, Lev Lamberov <dogs...@riseup.net> escribiu:
>Hi Alberto,
>
>
>24.10.2016 20:14, Alberto Luaces пишет:
>> Hi, I think it could be beneficial to mention in the description that
>> this is an emacs package.  Otherwise, users not familiar with it or
>with
>> "avy" will not have a clue of what is its purpose.
>
>This package is team maintained by Emacs Addons team. The policy of the
>team is that binary packages names are prefixed with elpa-, which is an
>indicator of Emacs addon.
>

Makes sense. Thanks!

Bug#841659: ITP: zzz-to-char -- fancy version of `zap-to-char' command

[Alberto Luaces]

Lev Lamberov writes:

> Package: wnpp
> Severity: wishlist
> Owner: Lev Lamberov 
>
> * Package name: zzz-to-char
>   Version : 0.1.1
>   Upstream Author : Mark Karpov 
> * URL : https://github.com/mrkkrp/zzz-to-char
> * License : GPL-3+
>   Programming Lang: Emacs Lisp
>   Description : fancy version of `zap-to-char' command
>
> This package provides two new commands `zzz-to-char' and `zzz-up-to-char'
> which work like built-ins `zap-to-char' and `zap-up-to-char', but allow you
> quickly select exact character you want to “zzz” to.
>
> The commands are minimalistic and often work like built-in ones when there is
> only one occurrence of target character (except they automatically work in
> backward direction too). You can also specify how many characters to scan from
> each side of point.
>
> This package uses avy as a backend.

Hi, I think it could be beneficial to mention in the description that
this is an emacs package.  Otherwise, users not familiar with it or with
"avy" will not have a clue of what is its purpose.

-- 
Alberto

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[Alberto Luaces]

bret curtis writes:

> With the attached patch to OSG, I can get it to compile on armhf with
> GLESv1 (libgles1-mesa-dev). It disables GLESv2 however, I got an error
> while they were both enabled.
>
> I installed the resulting packages on my RPi2 without a problem and
> got OpenMW to compile on there as well.
>
> Was there a reason why GLESv2 as chosen over GLESv1?  Are there any
> other packages that depend on OSG-3.4?  Can we use GLESv1 instead of
> GLESv2? It would be even better if we can just use "Desktop OpenGL" on
> armhf instead of the GLESvX.
>

Bret, when you asked about the armhf I gave my answer to the best of my
knowledge.  Unfortunately, I do not own any armhf device, so I cannot
carry any kind of tests more than checking the build logs.  Your testing
is much appreciated, though.

You keep mentioning "desktop OpenGL" on the armhf platform, but so far
you have not shown any snippet of code not involving GLES1 or GLES2.
Again to the best of my knowledge those platforms implement those GL
versions accelerated, while "traditional" GL is software-emulated.  This
is what I have read, but I may be wrong.

This is a list of facts that I know:

- OSG "as is" does FTBFS on arm platforms.  You can verify that reading
  the logs for 3.4: armhf (configured for GLES2) succeeds while armel
  (default configuration) breaks.

- The decision of using GLES2 was already made by the Ubuntu team from
  whom I took the patches that I told you I was going to apply
  beforehand.  I suppose they choose GLES2 because nowadays it is rare
  to find new hardware supporting GLES1 but not GLES2, but this is mere
  speculation.

- On Debian and for 3.4, which depends on Qt5, the decision of using
  GLES2 is also taken already for us.  See their dependencies on armhf
  and armel:

https://sources.debian.net/src/qtbase-opensource-src/5.6.1%2Bdfsg-3/debian/control/#L309

I do not know what would happen if we build OSG with GLES1 but linking
to GLES2-enabled Qt5.  Does it have any chances of not breaking at
run-time?  I am not sure.

To me this looks like a packaging problem, because we have to decide
what dependencies we need from a global point of view, instead of in
a case-by-case basis.

In my opinion, that tiny patch for OpenMW on Debian looks like a good
compromise.

Regards,

Alberto

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[Alberto Luaces]

Andreas Beckmann writes:

> On 2016-09-27 12:12, bret curtis wrote:
>> To put it simply, upstream (OpenMW) has no plans to support GLESv2 at
>> this time. Since OSG-3.4 for armhf is compiled only for GLESv2, this
>> complicates things drastically and at this point I'm in over my head.
>
> IIRC, quite some packages have been removed from arm* over the last year
> that require Desktop OpenGL and don't work with "just" GLES.
> I just cannot remember (or find) concrete examples.
> So openmw is probably another RM candidate.
>

I agree with that.  As far as I know, Desktop OpenGL is not usually
hardware-accelerated on those SOC platforms, so having OpenMW available
there would be a moot point.

Regards,

Alberto

Bug#838685: myrescue: There are some typos in the description

[Alberto Luaces]

Package: myrescue
Severity: minor

In the last paragraph of the description of this package, "midia" should be 
"media" and maybe "forensics investigations" should be "forensic 
investigations".

Bug#833719: firefox: NS_ERROR_NET_INADEQUATE_SECURITY on Google & Facebook

[Alberto Luaces]

Package: firefox
Version: 48.0-2
Followup-For: Bug #833719

Nicholas's recipe works for me, too.

-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: /usr/share/xul-ext/adblock-plus
Package: xul-ext-adblock-plus
Status: enabled

Name: Debian buttons
Location: /usr/share/xul-ext/debianbuttons
Package: xul-ext-debianbuttons
Status: enabled

Name: Default theme
Location: 
/usr/lib/firefox/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox
Status: enabled

Name: Element Hiding Helper para Adblock Plus
Location: /usr/share/xul-ext/adblock-plus-element-hiding-helper
Package: xul-ext-adblock-plus-element-hiding-helper
Status: enabled

Name: Firebug
Location: /usr/share/xul-ext/firebug
Package: xul-ext-firebug
Status: enabled

Name: Firefox Hello
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

Name: Flashblock
Location: /usr/share/xul-ext/flashblock
Package: xul-ext-flashblock
Status: enabled

Name: FlashGot
Location: /usr/share/xul-ext/flashgot
Package: xul-ext-flashgot
Status: enabled

Name: HTTPS-Everywhere
Location: /usr/share/xul-ext/https-everywhere
Package: xul-ext-https-everywhere
Status: enabled

Name: It's All Text!
Location: /usr/share/xul-ext/itsalltext
Package: xul-ext-itsalltext
Status: enabled

Name: Live HTTP headers(Fixed By Danyial.com)
Location: /usr/share/xul-ext/livehttpheaders
Package: xul-ext-livehttpheaders
Status: enabled

Name: Multi-process staged rollout
Location: ${PROFILE_EXTENSIONS}/e10sroll...@mozilla.org.xpi
Status: enabled

Name: Org-mode Capture
Location: ${PROFILE_EXTENSIONS}/jid1-3fq9ogte8vw...@jetpack.xpi
Status: enabled

Name: Pocket
Location: ${PROFILE_EXTENSIONS}/fire...@getpocket.com.xpi
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpn...@jetpack.xpi
Status: enabled

Name: TinEye Reverse Image Search
Location: ${PROFILE_EXTENSIONS}/tin...@ideeinc.com.xpi
Status: enabled

Name: Uppity
Location: /usr/share/xul-ext/uppity
Package: xul-ext-uppity
Status: enabled

Name: Zotero
Location: /usr/share/xul-ext/zotero
Package: xul-ext-zotero
Status: user-disabled

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled

Name: Java(TM) Plug-in 11.77.2 (11.77.2)
Location: /home/alberto/jre1.8.0_77/lib/amd64/libnpjp2.so
Status: enabled


-- Addons package information
ii  firefox48.0-2   amd64Mozilla Firefox web browser
ii  icedtea-8-plug 1.6.2-3  amd64web browser plugin based on OpenJ
ii  xul-ext-adbloc 2.7.3+dfsg-1 all  advertisement blocking extension 
ii  xul-ext-adbloc 1.3.8-1  all  companion for Adblock Plus to cre
ii  xul-ext-debian 1.11-3   all  Buttons for querying Debian-relat
ii  xul-ext-firebu 2.0.17-1 all  web development plugin for Firefo
ii  xul-ext-flashb 1.5.20-2 all  Mozilla extension to block Adobe 
ii  xul-ext-flashg 1.5.6.13+dfs all  Extension to handle downloads wit
ii  xul-ext-https- 5.1.1-2  all  extension to force the use of HTT
ii  xul-ext-itsall 1.9.2-2  all  extension to edit textareas using
ii  xul-ext-liveht 0.17.1-2 all  add information about HTTP header
ii  xul-ext-uppity 1.5.8-5  all  toolbar button to "go up" on the 
ii  xul-ext-zotero 4.0.29.5+dfs all  Firefox extension to organize and

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

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

Versions of packages firefox depends on:
ii  debianutils   4.8
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.21.90-2
ii  libc6 2.23-5
ii  libcairo2 1.14.6-1+b1
ii  libdbus-1-3   1.10.10-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-11
ii  libgdk-pixbuf2.0-02.34.0-1
ii  libglib2.0-0  2.49.6-1
ii  libgtk2.0-0   2.24.30-4
ii  libhunspell-1.4-0 1.4.1-2
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.26-1
ii  libpango-1.0-01.40.2-1
ii  libsqlite3-0  3.14.1-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-11
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  

Bug#831631: libopenscenegraph-dev: Please upgrade to 3.4.x+

[Alberto Luaces]

The GZeus writes:

> I've had multiple bugs related to this closed by a more recent 3.2.x release, 
> which as been somewhat frustrating, so I'm being as clear as I can this time:
> 3.4.x is the most recent _stable_ release. I beg of you: update the package. 
> ;_;

Hi, 3.4 is already in experimental, and it is expected for 3.6 to be
packaged as soon as it is released by the end of this month.

Please take also into account that although newer packages can benefit
from fixes in newer versions, debian packages *currently* in the archive
may break when upgrading from 3.2.

Let me know if this addresses your concerns.

Bug#811667: cal3d: Patch

[Alberto Luaces]

Source: cal3d
Followup-For: Bug #811667

I spoke too soon: recent code does not show those errors, but the rest
does have them.

Anyway, here is a patch that solves the issue.
diff -ruN cal3d-0.11.0/src/cal3d/loader.cpp cal3d-0.11.0-changes/src/cal3d/loader.cpp
--- cal3d-0.11.0/src/cal3d/loader.cpp	2006-06-08 17:12:13.0 +0200
+++ cal3d-0.11.0-changes/src/cal3d/loader.cpp	2016-07-01 13:04:45.732750815 +0200
@@ -886,7 +886,7 @@
   if(!dataSrc.ok())
   {
 dataSrc.setError();
-return false;
+return 0;
   }
 
   // allocate a new core keyframe instance
@@ -1338,13 +1338,13 @@
 		if(stricmp(skeleton->Attribute("MAGIC"),Cal::SKELETON_XMLFILE_MAGIC)!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		if(atoi(skeleton->Attribute("VERSION")) < Cal::EARLIEST_COMPATIBLE_FILE_VERSION )
 		{
 			CalError::setLastError(CalError::INCOMPATIBLE_FILE_VERSION, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		skeleton = skeleton->NextSiblingElement();
@@ -1353,19 +1353,19 @@
 	if(!skeleton || stricmp(skeleton->Value(),"SKELETON")!=0)
 	{
 		CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-		return false;
+		return 0;
 	}
 
 	if(skeleton->Attribute("MAGIC")!=NULL && stricmp(skeleton->Attribute("MAGIC"),Cal::SKELETON_XMLFILE_MAGIC)!=0)
 	{
 		CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-		return false;
+		return 0;
 	}
 
 	if(skeleton->Attribute("VERSION")!=NULL && atoi(skeleton->Attribute("VERSION")) < Cal::EARLIEST_COMPATIBLE_FILE_VERSION )
 	{
 		CalError::setLastError(CalError::INCOMPATIBLE_FILE_VERSION, __FILE__, __LINE__, strFilename);
-		return false;
+		return 0;
 	}
 
 
@@ -1383,7 +1383,7 @@
 		if(stricmp(bone->Value(),"BONE")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		std::string strName=bone->Attribute("NAME");
@@ -1395,7 +1395,7 @@
 		if(!translation || stricmp( translation->Value(),"TRANSLATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float tx, ty, tz;
@@ -1404,13 +1404,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* translationdata = node->ToText();
 		if(!translationdata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << translationdata->Value();
@@ -1422,7 +1422,7 @@
 		if(!rotation || stricmp(rotation->Value(),"ROTATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float rx, ry, rz, rw;
@@ -1431,13 +1431,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* rotationdata = node->ToText();
 		if(!rotationdata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << rotationdata->Value();
@@ -1450,7 +1450,7 @@
 		if(!rotation || stricmp(translationBoneSpace->Value(),"LOCALTRANSLATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float txBoneSpace, tyBoneSpace, tzBoneSpace;
@@ -1459,13 +1459,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* translationBoneSpacedata = node->ToText();
 		if(!translationBoneSpacedata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << translationBoneSpacedata->Value();
@@ -1477,7 +1477,7 @@
 		if(!rotationBoneSpace || stricmp(rotationBoneSpace->Value(),"LOCALROTATION")!=0)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 
 		float rxBoneSpace, ryBoneSpace, rzBoneSpace, rwBoneSpace;
@@ -1486,13 +1486,13 @@
 		if(!node)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		TiXmlText* rotationBoneSpacedata = node->ToText();
 		if(!rotationBoneSpacedata)
 		{
 			CalError::setLastError(CalError::INVALID_FILE_FORMAT, __FILE__, __LINE__, strFilename);
-			return false;
+			return 0;
 		}
 		str.clear();
 		str << rotationBoneSpacedata->Value();
@@ -1504,7 +1504,7 @@
 		if(!parent ||stricmp(parent->Value(),"PARENTID")!=0)
 		{
 			

Bug#811667: Fix in upstream

[Alberto Luaces]

Upstream's SVN has fixed this, however there are no new releases.  We
can either cherry pick those changes (just substituting false by 0) or
use the tip of the repository.

Bug#827740: isympy start fails: No module named sympy.interactive

[Alberto Luaces]

Francesco Poli writes:

> Yes, that's why I suggested you to install python-sympy.
>

I do not want to do that :)  I want to use python3.

>
> You can also keep python3-sympy installed, if you like (in case you
> want to load the sympy module from python3), but isympy is a script
> designed to be interpreted by /usr/bin/python, which is Python v2.7.x
> and not v3.x ...
>

There is were we disagree.  From the description of the package and its
dependencies, it is not said that it is exclusive for python2.

>
> I don't know whether there is an elegant way to make isympy
> automatically figure out whether you would prefer using python or
> python3.
>

[...]

>
> Maybe another binary package could be added (named isympy3), including
> an appropriate isympy3 script...
> At that point isympy would depend on python-sympy (without
> python3-sympy as an alternative dependency) and isympy3 would depend on
> python3-sympy.

I guess a good solution could be one along the lines you are posting:
having two packages with no intermixed dependencies, with some aid of
the dpkg alternative system (that is used, for example, to set the
default version of gcc).  Unfortunately, I currently do not know enough
of that system in order to send a patch right now.

Francesco, thanks for your help and sorry for my stubbornness, but I
want to make clear that this is a bug, although for sure it can be
overcome by tinkering.

Bug#827740: isympy start fails: No module named sympy.interactive

[Alberto Luaces]

Francesco Poli writes:

> On Thu, 23 Jun 2016 11:55:38 +0200 Alberto Luaces wrote:
>
>> Francesco Poli writes:
> [...]
>> > I see that you have python3-sympy installed.
>> >
>> > What's the output of
>> >
>> >   $ /usr/bin/python --version
>> >
>> > on your system?
>> 
>> $ python -V
>> Python 2.7.12rc1
>> $ python3 -V
>> Python 3.5.2rc1
>
> Mmmh, then I am under the impression that you should try again after
> installing python-sympy ...
>

The error persists after re-installation.  The problem is that the
shebang line of isympy calls /usr/bin/python regardless if python3-sympy
was installed as its dependency.

>
> Or otherwise, you could maybe try with the following command (that may
> be automated with an alias or with a wrapper script...):
>
>   $ python3 /usr/bin/isympy

Thank you.  Of course that works, but the bug remains: isympy is that
wrapper script :)

Bug#827740: isympy start fails: No module named sympy.interactive

[Alberto Luaces]

Francesco Poli writes:

>> trying to start isympy fails with the error in the subject line.
> [...]
>> ii  python3-sympy1.0-1
> [...]
>
> I see that you have python3-sympy installed.
>
> What's the output of
>
>   $ /usr/bin/python --version
>
> on your system?

$ python -V
Python 2.7.12rc1
$ python3 -V
Python 3.5.2rc1

Bug#827306: general: won't open file browser/manager if several other programs are already open

[Alberto Luaces]

D Dimov writes:

> Alberto Luaces  wrote:
>> several other programs are already open
>>
>> reassign 827306 nautilus
>> thanks
>>
>> D Dimov writes:
>>
>>> Dear Alberto,
>>>
>>> I am using GNOME.
>>> When I type nautilus in terminal, and I already have a few programs
>>> running, it doesn't open.
>>> When I type nautilus after fresh restart, I get:
>>>
>>> $ nautilus
>>>
>>> (nautilus:2059): GLib-GIO-CRITICAL **:
>>> g_dbus_interface_skeleton_unexport: assertion
>>> 'interface_->priv->connections != NULL' failed
>>>
>>> (nautilus:2059): GLib-GIO-CRITICAL **:
>>> g_dbus_interface_skeleton_unexport: assertion
>>> 'interface_->priv->connections != NULL' failed
>>> Could not register the application: Timeout was reached
>>>
>>> (nautilus:2059): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen:
>>> assertion 'GDK_IS_SCREEN (screen)' failed
>>>
>>> (nautilus:2059): GLib-GObject-WARNING **: invalid (NULL) pointer
>>> instance
>>>
>>> (nautilus:2059): GLib-GObject-CRITICAL **: g_signal_connect_object:
>>> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
>>
>> Those messages seem harmless. From your post, I understand that when
>> it fails, the program just does not output anything to the console and
>> it stays frozen.
>>
>> You can try to see where it is getting stuck by launching it with the
>> debugger:
>>
>> $ gdb nautilus
>>
>> At the gdb prompt, type "r" and then ENTER. When it gets stuck, press
>> ctrl-C and then type "bt" and ENTER. Please post the results.
>
>
>
> Dear Alberto,
> Since the gdb didn't work (see my message below from June 16), is
> there something else I can try to fix the problem? 
> Thanks,
> Luben

Ok, it seems your debugger is not installed.  Please follow the
instructions given in another nautilus reported bug:

"Looks like a livelock. Please install nautilus-dbg and gvfs-dbg, and
obtain a gdb backtrace of the locked process.

See http://wiki.debian.org/HowToGetABacktrace for more information."

In addition, please reply to the bug report address and not directly to
me (I am subscribed to this bug) since otherwise the maintainers of the
package will not see any of your replies since they are held out of the
bug tracking system.

Regards,