Bug#1055446: libervia-backend: requires python3-txdbus
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.
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
severity 945875 normal thanks Adjusting severity for openscenegraph.
Bug#945875: openmw: Crash when saving
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
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
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
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
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
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
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?
-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
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
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
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
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
>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
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
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
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
Hi, Robbie. Are you pressing the 'g' key (reload) after each change?
Bug#926864: python3-numba: Insufficiently recent colorama version found.
severity -1 normal thanks Sorry, I misread the warning (not error) message.
Bug#926864: python3-numba: Insufficiently recent colorama version found.
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
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
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
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
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
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
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
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
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
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-*
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
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"
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
> 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
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
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
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.
Package: wnpp Severity: wishlist Owner: Alberto Luaces * Package name: company-irony Version : 1.1.0 Upstream Author : Guillaume Papin * 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
O 24 Outubro 2016 19:11:07 CEST, Lev Lamberov 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
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
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
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
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
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+
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
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) { CalError::set
Bug#811667: Fix in upstream
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
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
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
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
D&P Dimov writes: > Alberto Luaces wrote: >> several other programs are already open >> >> reassign 827306 nautilus >> thanks >> >> D&P 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,