Bug#1063913: mutt: background_edit and sidebar_visible changes lead to corrup screen
Package: mutt Version: 2.2.12-0.1 Severity: normal :set background_edit :set sidebar_visible # start a new message; invoke "mail" or "reply" or "group-reply" or ... # actually enter edition of the message with external editor, # not merely mutt Compose screen q # press q to background the message edition - invoke exit :unset sidebar_visible B # press B to invoke background-compose-menu # select the backgrounded message edition if necessary # this enters the mutt Compose screen The left part of the Compose screen is garbled (the sidebar is superimposed upon the Compose screen). Pressing ^L does not solve the issue. On has to: :set sidebar_visible and then after exiting the Compose screen (sending the message or aborting it or postponing it), again a second time :set sidebar_visible -- Package-specific info: Mutt 2.2.12 (2023-09-09) Copyright (C) 1996-2023 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 5.10.0-27-amd64 (x86_64) ncurses: ncurses 6.2.20201114 (compiled with 6.4) libidn2: 2.3.0 (compiled with 2.3.4) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 13.2.0-3' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-13-13.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=3 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (Debian 13.2.0-3) Configure options: --build=x86_64-linux-gnu --prefix=/usr '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu' --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-mailpath=/var/mail --enable-compressed --enable-debug --enable-fcntl --enable-hcache --enable-gpgme --enable-imap --enable-smtp --enable-pop --enable-sidebar --enable-dotlock --disable-fmemopen --with-curses --with-gnutls --with-gss --with-idn2 --with-mixmaster --with-gsasl --without-gdbm --without-bdb --without-qdbm --with-tokyocabinet build_alias=x86_64-linux-gnu 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 -ffile-prefix-map=/build/reproducible-path/mutt-2.2.12=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS -USE_SASL +USE_GSASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +HAVE_FUTIMENS +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_LIBIDN2 +HAVE_GETSID +USE_HCACHE +USE_SIDEBAR +USE_COMPRESSED +USE_INOTIFY -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To
Bug#1033260: libpython3.11-minimal: should Break: python3-pysimplesoap (<< 1.16.2-5)
Package: libpython3.11-minimal Version: 3.11.2-4 Severity: normal Control: affects -1 python3-pysimplesoap python3.11 breaks python3-pysimplesoap (versions prior to 1.16.2-5) but doesn't declare so. Trying to use python3-pysimplesoap with python3.11 gives error: File "/usr/lib/python3/dist-packages/pysimplesoap/__init__.py", line 16, in from . import client, server, simplexml, transport File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 33, in from .transport import get_http_wrapper, set_http_wrapper, get_Http File "/usr/lib/python3/dist-packages/pysimplesoap/transport.py", line 109, in if 'timeout' in inspect.getargspec(httplib2.Http.__init__)[0]: ^^ AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 'getargs'? pysimplesoap version 1.16.2-5 has the fix for that -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpython3.11-minimal depends on: ii libc62.36-8 ii libssl3 3.0.8-1 Versions of packages libpython3.11-minimal recommends: ii libpython3.11-stdlib 3.11.2-4 libpython3.11-minimal suggests no packages. -- no debconf information
Bug#1033259: lists.debian.org: vgui-discuss archive is heavily spam-infested
Package: lists.debian.org Severity: normal I've patiently clicked on a few years worth of archives "report as spam" message per message, but I've run out of steam after doing December 2005 and have stopped going into older messages. I've found *one* non-spam message since December 2005, that is https://lists.debian.org/vgui-discuss/2006/01/msg00019.html
Bug#1016085: libqt5network5: depends on libssl3 but loads (wrong) file provided by libssl-dev instead
Package: libqt5network5 Version: 5.15.4+dfsg-4 Severity: serious Justification: Policy 3.5 I have libssl 3.0.4-2 (satisfying the dependency of libqt5network5), but libssl-dev 1.1.1n-0+deb11u3. Starting QT applications gets on stdout/stderr stuff like 07-26 20:08:33:071 [ warning qt.network.ssl ]: QSslSocket: cannot resolve SSL_get1_peer_certificate 07-26 20:08:33:071 [ warning qt.network.ssl ]: QSslSocket: cannot resolve EVP_PKEY_get_base_id 07-26 20:08:33:071 [ warning qt.network.ssl ]: QSslSocket: cannot resolve SSL_CTX_load_verify_dir 07-26 20:08:46:405 [ warning qt.network.ssl ]: QSslSocket: cannot call unresolved function SSL_CTX_load_verify_dir 07-26 20:08:46:405 [ warning qt.network.ssl ]: An error encountered while to set root certificates location: "" 07-26 20:08:46:409 [ warning qt.network.ssl ]: QSslSocket: cannot call unresolved function SSL_get1_peer_certificate 07-26 20:08:46:409 [ warning qt.network.ssl ]: QSslSocket: cannot call unresolved function SSL_get1_peer_certificate and then the application fails to recognise any certificate as valid, since it doesn't recognise any root CA. An strace shows that it loads (my guess if with dlopen()) /usr/lib/x86_64-linux-gnu/libssl.so That file is _not_ provided by _any_ direct or indirect dependency of libqt5network5 but by libssl-dev. So from a policy standpoint: * libqt5network5 _must_ _not_ require that file to function since it does not depend on libssl-dev; formally that is fulfilled since it will fallback to libssl.so.3 when libssl.so is not found. * libqt5network5 _must_ _not_ be broken by the presence of any particular version of that file since it does not conflict with any particular version of libssl-dev; that is the policy requirement that is not fulfilled. In my opinion the best solution is to _never_ dlopen("libssl.so"), but only every dlopen("libssl.so.3") since that is the ABI that you expect, and what the package depends on. >From a policy standpoint, it would also be acceptable (as in non-RC buggy) to instead conflict on any version of libssl-dev that one is not compatible with, but IMO that would be a pity. -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-15-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.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 libqt5network5 depends on: ii libc6 2.33-8 ii libgssapi-krb5-2 1.18.3-6+deb11u1 ii libqt5core5a [qtbase-abi-5-15-4] 5.15.4+dfsg-4 ii libqt5dbus5 5.15.4+dfsg-4 ii libssl3 3.0.4-2 ii libstdc++612.1.0-7 ii zlib1g1:1.2.11.dfsg-2+deb11u1 libqt5network5 recommends no packages. libqt5network5 suggests no packages. -- no debconf information -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#1006644: RFA: dvidvi -- Manipulate .dvi files
Package: wnpp Severity: normal Control: affects -1 src:dvidvi Having dropped off from active participation in Debian, I request an adopter for the dvidvi package. The package description is: Allows you to select, change the order, and/or shift the pages in a .dvi file. . This can for example be used to print an A5 booklet on A4 paper, in such a way that you can put a staple through the bundle. A shell script that does just that is provided. -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#1006643: RFA: ifrench-gut -- French dictionary for ispell (GUTenberg version)
Package: wnpp Severity: normal X-Debbugs-Cc: agmar...@debian.org Control: affects -1 src:ifrench-gut Having dropped away from active participation in Debian, I request an adopter for the ifrench-gut package. The package description is: This is a French dictionary, to be used with the ispell program, version 3.1.20 and following. . This is the GUTenberg version. -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#998755: xscreensaver: nothing is added to logfile after settings file change
Package: xscreensaver Version: 5.45+dfsg1-2 Severity: normal Running "xscreensaver -log FOO", then xscreensaver-demo and changing some settings, then locking the screen, deactivating it, unlocking it, etc, the last message in the FOO logfile is: xscreensaver: 18:03:29: file "/home/master/.xscreensaver" has changed, reloading. xscreensaver: 18:03:58: not launching hack (throttled.) Nothing in the log file for the *later* lock/unlock, while previous lock/unlock cycles had messages like: xscreensaver: 18:00:24: SUSPEND ClientMessage received. xscreensaver: 18:00:24: locking. xscreensaver: 18:00:24: 0: locked mode switching. xscreensaver: 18:00:24: user is idle (ClientMessage) xscreensaver: 18:00:24: blanking screen at Sun Nov 7 18:00:24 2021. xscreensaver: 18:00:24: mouse is on screen 1 of 2 xscreensaver: 18:00:24: 1: grabbing keyboard on 0x55a... GrabSuccess. xscreensaver: 18:00:24: 1: grabbing mouse on 0x55a... GrabSuccess. xscreensaver: 18:00:24: not launching hack (throttled.) xscreensaver: 18:02:21: user is active (mouse motion) xscreensaver: 18:02:21: pam_start ("xscreensaver", "master", ...) ==> 0 (Success) xscreensaver: 18:02:21: pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success) xscreensaver: 18:02:21: pam_authenticate (...) ... xscreensaver: 18:02:21: pam_conversation (ECHO_OFF="Password: ") ... xscreensaver: 18:02:21: mouse is on screen 1 of 2 xscreensaver: 18:02:21: mouse is on screen 1 of 2 xscreensaver: 18:02:21: 1: mouse is at 2085,627. xscreensaver: 18:02:21: 1: creating password dialog ("") xscreensaver: 18:02:21: mouse is on screen 1 of 2 xscreensaver: 18:02:21: grabbing server... xscreensaver: 18:02:21: 1: ungrabbing mouse (was 0x55a). xscreensaver: 18:02:21: 1: grabbing mouse on 0x2a00403... GrabSuccess. xscreensaver: 18:02:21: ungrabbing server. xscreensaver: 18:02:26: input finished. xscreensaver: 18:02:26: pam_conversation (...) ==> PAM_SUCCESS xscreensaver: 18:02:26: pam_authenticate (...) ==> 0 (Success) xscreensaver: 18:02:26: pam_acct_mgmt (...) ==> 0 (Success) xscreensaver: 18:02:26: pam_setcred (...) ==> 0 (Success) xscreensaver: 18:02:26: pam_end (...) ==> 0 (Success) xscreensaver: 18:02:26: grabbing server... xscreensaver: 18:02:26: 1: ungrabbing mouse (was 0x2a00403). xscreensaver: 18:02:26: 1: grabbing mouse on 0x55a... GrabSuccess. xscreensaver: 18:02:26: ungrabbing server. xscreensaver: 18:02:26: 1: moving mouse back to 2085,627. xscreensaver: 18:02:26: discarding MotionNotify event. xscreensaver: 18:02:26: 1: destroying password dialog. xscreensaver: 18:02:26: unblanking screen at Sun Nov 7 18:02:26 2021. xscreensaver: 18:02:26: 1: ungrabbing mouse (was 0x55a). xscreensaver: 18:02:26: 1: ungrabbing keyboard (was 0x55a). xscreensaver: 18:02:27: 0: unlocked mode switching. xscreensaver: 18:02:27: unthrottled. xscreensaver: 18:02:27: starting de-race timer (10 seconds.) xscreensaver: 18:02:27: awaiting idleness. xscreensaver: 18:02:37: de-race completed. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u2 ii libcrypt11:4.4.18-4 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libpam0g 1.4.0-9+deb11u1 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.3-6 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.7 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-2 Versions of packages xscreensaver recommends: ii gsfonts-x110.27 ii libjpeg-turbo-progs1:2.0.6-4 ii perl 5.32.1-4+deb11u2 ii wamerican [wordlist] 2019.10.06-1 ii wamerican-huge [wordlist] 2019.10.06-1 ii wbritish-huge [wordlist] 2019.10.06-1 ii wcanadian-huge [wordlist] 2019.10.06-1 ii wfrench [wordlist] 1.2.6-1 ii wngerman [wordlist]20161207-9 ii xfonts-100dpi 1:1.0.4+nmu1.1 Versions of packages xscreensaver suggests: ii chromium [www-browser] 90.0.4430.212-1 ii firefox-esr [www-browser] 78.15.0esr-1~deb11u1 ii fortune-mod [fortune] 1:1.99.1-7.1 pn gdm3 | kdm-gdmcompat ii lynx [www-browser] 2.9.0dev.6-3~deb11u1 pn qcam | streamer ii w3m [www-browser] 0.5.3+git20210102-6 ii xdaliclock
Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop
Package: xscreensaver Version: 5.45+dfsg1-2 Severity: important I took the habit of running "xscreensaver-command -suspend" when leaving my desk. However, after ten(s of) seconds, xscreensaver unblanks and shows the password prompt screen. After timeout, it blanks again, and after some time, unblanks again, in a never-ending cycle. This keeps the screens on a cycle of going into sleep and waking up. My first guess was that random mouse movements were above xscreensaver's ignore threshold; however, an "xev" window having the focus shows no event at all for minutes as long as I don't touch mouse or keyboard. Killing the "xscreensaver-systemd" process fixed it. Being an always-running desktop, it is never suspended, so from reading its man page, I gather xscreensaver-systemd doesn't do anything useful for that particular machine. Let me know what else I can do to help debug the problem. -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xscreensaver depends on: ii init-system-helpers 1.60 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u2 ii libcrypt11:4.4.18-4 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libpam0g 1.4.0-9+deb11u1 ii libpango-1.0-0 1.46.2-3 ii libsystemd0 247.3-6 ii libx11-6 2:1.7.2-1 ii libxext6 2:1.3.3-1.1 ii libxi6 2:1.7.10-1 ii libxinerama1 2:1.1.4-2 ii libxml2 2.9.10+dfsg-6.7 ii libxmu6 2:1.1.2-2+b3 ii libxrandr2 2:1.5.1-1 ii libxt6 1:1.2.0-1 ii libxxf86vm1 1:1.1.4-1+b2 ii xscreensaver-data5.45+dfsg1-2 Versions of packages xscreensaver recommends: ii gsfonts-x110.27 ii libjpeg-turbo-progs1:2.0.6-4 ii perl 5.32.1-4+deb11u2 ii wamerican [wordlist] 2019.10.06-1 ii wamerican-huge [wordlist] 2019.10.06-1 ii wbritish-huge [wordlist] 2019.10.06-1 ii wcanadian-huge [wordlist] 2019.10.06-1 ii wfrench [wordlist] 1.2.6-1 ii wngerman [wordlist]20161207-9 ii xfonts-100dpi 1:1.0.4+nmu1.1 Versions of packages xscreensaver suggests: ii chromium [www-browser] 90.0.4430.212-1 ii firefox-esr [www-browser] 78.15.0esr-1~deb11u1 ii fortune-mod [fortune] 1:1.99.1-7.1 pn gdm3 | kdm-gdmcompat ii lynx [www-browser] 2.9.0dev.6-3~deb11u1 pn qcam | streamer ii w3m [www-browser] 0.5.3+git20210102-6 ii xdaliclock 2.44+debian-2 ii xfishtank 2.5-1+b1 pn xscreensaver-data-extra pn xscreensaver-gl pn xscreensaver-gl-extra -- no debconf information
Bug#996755: post-el: switch to Boruch-Baum upstream
Source: post-el Version: 1:2.6-1 Severity: wishlist The upstream listed in /usr/share/doc/post-el/copyright seems rather inactive. https://github.com/Boruch-Baum/post-mode/ has several updates and enhancements. Please consider switching to it. -- System Information: Debian Release: 10.10 APT prefers oldstable APT policy: (600, 'oldstable'), (500, 'oldstable-updates'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#993507: libgnutls30: fails to negotiate X25519 where NSS & OpenSSL succeed, success with X448
Package: libgnutls30 Version: 3.7.2-2 Severity: normal $ gnutls-cli --priority 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1' fxtop.com Processed 138 CA certificate(s). Resolving 'fxtop.com:443'... Connecting to '5.39.68.178:443'... *** Fatal error: An illegal parameter has been received. $ openssl s_client -curves X25519 -connect fxtop.com:443 CONNECTED(0003) (... snip ...) --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- (... snip ...) I attach a pcapng of network corresponding traffic. The same is reproducible with www.collaboraoffice.com instead of fxtop.com Note, though (not included in pcapng file): $ gnutls-cli --priority 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1:-GROUP-X25519' fxtop.com (...) Resolving 'fxtop.com:443'... Connecting to '5.39.68.178:443'... (...) - Description: (TLS1.3)-(ECDHE-X448)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) -- System Information: Debian Release: 10.10 APT prefers oldstable APT policy: (600, 'oldstable'), (500, 'oldstable-updates'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgnutls30 depends on: ii libc6 2.31-13 ii libgmp10 2:6.1.2+dfsg-4 ii libhogweed63.7.3-1 ii libidn2-0 2.0.5-1+deb10u1 ii libnettle8 3.7.3-1 ii libp11-kit00.23.22-1 ii libtasn1-6 4.16.0-2 ii libunistring2 0.9.10-1 libgnutls30 recommends no packages. Versions of packages libgnutls30 suggests: ii gnutls-bin 3.6.7-4+deb10u7 -- no debconf information -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability. gnutls_openssl_x25519.pcapng Description: Binary data
Bug#990112: installation-report: 10.10.0-amd64-DVD-1 booted in Xen PV mode
Package: installation-reports Version: 2.71 Severity: normal (report done from another macn -- Package-specific info: Boot method: DVD (Xen PV mode) Image version: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debian-10.10.0-amd64-DVD-1.iso.torrent 2021-06-19 19:20 Date: 2021-06-20 evening Machine: Xen PV DomU Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [E] Load installer modules: [E] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [E] Install boot loader:[E] Overall install:[E] Comments/Problems: Problem 1: The CD is not recognised as a valid source of package, and thus grub installation fails; my assumption is that it requires grub-common from the CD but doesn't have it. So I loaded the extra installer module pppoe in order to get an Internet connection and use a network mirror to get packages. That failed to work, because the pppoe kernel module failed to load, which is: Problem 2: the ppoe installer module needs "depmod" but doesn't run it "depmod" run from the shell fixed that. Then I selected a network mirror, namely http / Luxembourg / deb.debian.org Problem 3: the selected network mirror is not used. I ended up going to the shell again, chrooting into /target, editing /etc/sources.lst with nano to put the requested deb.debian.org mirror source, and after "apt-get update && apt-get install grub-xen" the installer finished correctly. Note also that the "security updates" and "updates" lines in source.list were commented out "because they failed to validate". "Install tasks" worked OK, but the only task available was "basic system utilities" or something like that, again that's because nothing in sources.list, not the CD and not the network mirror.
Bug#986192: gimp: refuses to run with LittleCMS 2.9, thinks 2.9 < 2.2
Package: gimp Version: 2.10.22-3 Severity: important Gimp refuses to start with LittleCMS 2.9 installed, saying it needs "LittleCMS version at least 2.2". It seems to mistakenly believe 2.9 is not "at least 2.2". -- System Information: Debian Release: 10.9 APT prefers stable APT policy: (600, 'stable'), (500, 'stable-updates'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.22-3 ii graphviz 2.40.1-6 ii libaa1 1.4p5-46 ii libbabl-0.1-01:0.1.82-1 ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.31-10 ii libcairo21.16.0-4+deb10u1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libgegl-0.4-01:0.4.26-2 ii libgexiv2-2 0.10.9-1 ii libgimp2.0 2.10.22-3 ii libglib2.0-0 2.66.7-2 ii libgs9 9.27~dfsg-2+deb10u4 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.3.1-1 ii libheif1 1.11.0-1 ii libilmbase25 2.5.4-1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libjson-glib-1.0-0 1.6.2-1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.4-1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.5-1 1.6.0-2 ii libopenexr25 2.5.4-1 ii libopenjp2-7 2.4.0-3 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpangoft2-1.0-01.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libpoppler-glib8 0.71.0-5 ii librsvg2-2 2.44.10-2.1 ii libstdc++6 10.2.1-6 ii libtiff5 4.1.0+git191117-2~deb10u2 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.7.0-2 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1+deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.27~dfsg-2+deb10u4 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help ii gvfs-backends 1.38.1-5 ii libasound21.1.8-1 -- no debconf information -- Lionel Mamane Tél: +352 46 67 74 Fax: +352 46 67 76 This message and any attachments may be intended to be confidential, intended solely for the addressee and/or contain legally privileged information. Any unauthorised use or dissemination is prohibited. Unless cryptographically protected, emails are susceptible to interception, alteration and spoofing, so in case of doubt, please check by independent means. We do not make any commitment by email, ever; if this emails appears to contain a commitment, we will not recognise the latter as valid, nor as engaging our liability. We make commitments only by a written paper document signed by at least one person entitled to engage our liability.
Bug#979701: geeqie: menu bar limited to left panel
Package: geeqie Version: 1:1.6-5 Severity: important In geeqie 1.6, the menu bar is limited in width to the left panel, and thus is truncated when the left panel is narrower than the menu bar needs to be. In geeqie 1.5, the menu bar was always full width, which suits layouts with a narrow left panel much better. See the circled red areas in the attached screenshots. -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geeqie depends on: ii geeqie-common1:1.6-5 ii libc62.31-9 ii libcairo21.16.0-4 ii libchamplain-0.12-0 0.12.16-3 ii libchamplain-gtk-0.12-0 0.12.16-3 ii libclutter-1.0-0 1.26.2+dfsg-10 ii libclutter-gtk-1.0-0 1.8.4-4 ii libcogl201.22.2-6 ii libdjvulibre21 3.5.28-1 ii libexiv2-27 0.27.3-3 ii libffmpegthumbnailer4v5 2.1.1-0.2+b1 ii libgcc-s110.2.1-3 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.4-1 ii libgtk-3-0 3.24.5-1 ii libheif1 1.10.0-2 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii liblcms2-2 2.9-3 ii liblirc-client0 0.10.1-6.2~deb10u1 ii liblua5.1-0 5.1.5-8.1+b2 ii libopenjp2-7 2.3.0-2+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpoppler-glib8 0.71.0-5 ii libstdc++6 10.2.1-3 ii libtiff5 4.1.0+git191117-2~deb10u1 ii libwebp6 0.6.1-2 ii sensible-utils 0.0.12 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.2.10-6+deb10u4 ii exiftran 2.10-3 ii exiv20.25-4+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii librsvg2-common 2.44.10-2.1 ii ufraw-batch 0.22-4 ii zenity 3.30.0-2 Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.10.22-2 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.5.2-2+deb10u1 ii ufraw0.22-4 ii xpaint 2.9.1.4-3.2+b1 -- no debconf information
Bug#971403: geeqie: fails to start with X error
Package: geeqie Version: 1:1.5.1+git20200808-2a27c9ab-1 Severity: grave Justification: renders package unusable Seems to be since upgrade from 1:1.5.1-9 to 1:1.5.1+git20200808-2a27c9ab-1 $ geeqie (geeqie:26619): Gdk-ERROR **: 00:31:08.776: The program 'geeqie' received an X Window System error. This probably reflects a bug in the program. The error was 'GLXBadContext'. (Details: serial 185 error_code 161 request_code 152 (GLX) minor_code 6) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Trace/breakpoint trap -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geeqie depends on: ii geeqie-common1:1.5.1+git20200808-2a27c9ab-1 ii libc62.31-3 ii libcairo21.16.0-4 ii libchamplain-0.12-0 0.12.16-3 ii libchamplain-gtk-0.12-0 0.12.16-3 ii libclutter-1.0-0 1.26.2+dfsg-10 ii libclutter-gtk-1.0-0 1.8.4-4 ii libcogl201.22.2-6 ii libdjvulibre21 3.5.27.1-10 ii libexiv2-27 0.27.3-3 ii libffmpegthumbnailer4v5 2.1.1-0.2+b1 ii libgcc-s110.2.0-7 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.66.0-2 ii libgtk-3-0 3.24.5-1 ii libheif1 1.8.0-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblirc-client0 0.10.1-6.2~deb10u1 ii liblua5.1-0 5.1.5-8.1+b2 ii libopenjp2-7 2.3.0-2+deb10u1 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpoppler-glib8 0.71.0-5 ii libstdc++6 10.2.0-7 ii libtiff5 4.1.0+git191117-2~deb10u1 ii libwebp6 0.6.1-2 ii libx11-6 2:1.6.7-1 ii sensible-utils 0.0.12 Versions of packages geeqie recommends: ii cups-bsd [lpr] 2.2.10-6+deb10u3 ii exiftran 2.10-3 ii exiv20.25-4+deb10u1 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+deb10u1 ii librsvg2-common 2.44.10-2.1 ii ufraw-batch 0.22-4 ii zenity 3.30.0-2 Versions of packages geeqie suggests: pn geeqie-dbg ii gimp 2.10.18-1+b1 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.5.2-2+b1 ii ufraw0.22-4 ii xpaint 2.9.1.4-3.2+b1 -- no debconf information
Bug#964410: traceroute: fails to recognise ICMPv6 type 1 code 6
Package: traceroute Version: 1:2.1.0-2 Severity: normal When a router on the path returns ICMPv6 type 1 (Destination unreachable) code 6 (reject route to destination), traceroute fails to recognise that as an error condition and soldiers on with higher TTLs, thus giving the impression of a routing loop where there is none. Probably traceroute should treat _all_ type 1 packets as an error condition and stop there, whether it knows about the code or not. $ traceroute6 2a0b:b880:1000::1 traceroute to 2a0b:b880:1000::1 (2a0b:b880:1000::1) from 2001:470:c82d:ff:56a0:50ff:fe85:3b43, 30 hops max, 24 byte packets 1 tikva.mamane.lu (2001:470:c82d:ff::1) 0,328 ms 0,305 ms 0,302 ms 2 tunnel336250.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:c7::1) 16,034 ms 12,795 ms 13,55 ms 3 10ge7-3.core1.par2.he.net (2001:470:0:7b::1) 12,157 ms 12,981 ms 13,717 ms 4 100ge2-2.core1.fra1.he.net (2001:470:0:2d5::2) 22,788 ms 22,361 ms 22,879 ms 5 2001:7e8:0:1101::2 (2001:7e8:0:1101::2) 28,984 ms 25,824 ms 26,438 ms 6 2001:7e8:1:11fe::b (2001:7e8:1:11fe::b) 24,868 ms 26,235 ms 25,95 ms 7 2001:7e8:82e4:200::1 (2001:7e8:82e4:200::1) 51,211 ms 40,831 ms 28,758 ms 8 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 24,976 ms 25,688 ms 67,135 ms 9 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 48,039 ms 47,38 ms 47,983 ms 10 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 48,418 ms 47,022 ms 48,012 ms etc $ ping6 2a0b:b880:1000::1 PING 2a0b:b880:1000::1(2a0b:b880:1000::1) 56 data bytes >From 2001:7e8:8f03:10f::2: icmp_seq=1 Destination unreachable: Unknown code 6 >From 2001:7e8:8f03:10f::2: icmp_seq=2 Destination unreachable: Unknown code 6 >From 2001:7e8:8f03:10f::2: icmp_seq=3 Destination unreachable: Unknown code 6 -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages traceroute depends on: ii libc6 2.30-8 traceroute recommends no packages. traceroute suggests no packages. -- no debconf information
Bug#964409: iputils-tracepath: fails to recognise ICMPv6 type 1 code 6
Package: iputils-tracepath Version: 3:20190709-3 Severity: normal When a router on the path returns ICMPv6 type 1 (Destination unreachable) code 6 (reject route to destination), traceroute fails to recognise that as an error condition and soldiers on with higher TTLs, thus giving the impression of a routing loop where there is none. Probably traceroute should treat _all_ type 1 packets as an error condition and stop there, whether it knows about the code or not. $ traceroute6.iputils 2a0b:b880:1000::1 traceroute to 2a0b:b880:1000::1 (2a0b:b880:1000::1) from 2001:470:c82d:ff:56a0:50ff:fe85:3b43, 30 hops max, 24 byte packets 1 tikva.mamane.lu (2001:470:c82d:ff::1) 0,3552 ms 0,2890 ms 0,2921 ms 2 tunnel336250.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:c7::1) 11,4314 ms 12,3330 ms 13,4509 ms 3 10ge7-3.core1.par2.he.net (2001:470:0:7b::1) 11,6243 ms 12,3697 ms 66,5686 ms 4 100ge2-2.core1.fra1.he.net (2001:470:0:2d5::2) 22,1802 ms 22,1087 ms 21,3588 ms 5 2001:7e8:0:1101::2 (2001:7e8:0:1101::2) 28,2449 ms 26,3862 ms 26,3117 ms 6 2001:7e8:1:11fe::b (2001:7e8:1:11fe::b) 24,7129 ms 25,7440 ms 26,5004 ms 7 2001:7e8:82e4:200::1 (2001:7e8:82e4:200::1) 28,8680 ms 26,9187 ms 26,3931 ms 8 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 28,0338 ms 25,6848 ms 26,5857 ms 9 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 26,4234 ms 25,7886 ms 26,6329 ms 10 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 26,4964 ms 52,6529 ms 26,2147 ms 11 2001:7e8:8f03:10f::2 (2001:7e8:8f03:10f::2) 26,2990 ms 26,7112 ms 27,6096 ms $ ping6 2a0b:b880:1000::1 PING 2a0b:b880:1000::1(2a0b:b880:1000::1) 56 data bytes >From 2001:7e8:8f03:10f::2: icmp_seq=1 Destination unreachable: Unknown code 6 >From 2001:7e8:8f03:10f::2: icmp_seq=2 Destination unreachable: Unknown code 6 >From 2001:7e8:8f03:10f::2: icmp_seq=3 Destination unreachable: Unknown code 6 -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages iputils-tracepath depends on: ii libc62.30-8 ii libcap2 1:2.25-2 iputils-tracepath recommends no packages. Versions of packages iputils-tracepath suggests: ii traceroute 1:2.1.0-2 -- no debconf information
Bug#946669: vlc: silently fails to play 32bit 48kHz Opus audio from mkv container
Package: vlc-plugin-base Version: 3.0.8-0+deb10u1 Severity: serious Justification: depend on libmatroska6v5 versioned too loosely Playing an mkv video with 48kHz 32 bit Opus Audio results in total silence. I tried alsa audio output, I tried pulseaudio output. Videos with other codecs work correctly. I didn't try: * other sampling frequency, or other bit depth, of Opus Audio * Opus Audio in another container than mkv I tried upgrading libopus0 to 1.3-1, same result. vlc -vvv output: This is caused by: [556bdfd5bc60] main libvlc warning: cannot load module `/usr/lib/x86_64-linux-gnu/vlc/plugins/demux/libmkv_plugin.so' (/usr/lib/x86_64-linux-gnu/vlc/plugins/demux/libmkv_plugin.so: undefined symbol: _ZN11libmatroska27KaxVideoProjectionPosePitch10ClassInfosE) which is solved by upgrading libmatroska6v5 from version 1.4.5-2 to 1.4.9-1. This suggests that the depends of vlc-plugin-base on libmatroska6v5 (>= 1.4.5) should be versioned more strictly, to require a higher version, making this a Policy-serious bug. Note that the "messages" window of vlc didn't show any error, nor did stderr. They should have, which would have clued me in as to the problem, before I ran with "-vvv" as instructed by reportug for this bug report. -- System Information: Debian Release: 9.11 APT prefers oldstable-updates APT policy: (600, 'oldstable-updates'), (600, 'oldstable'), (500, 'stable-updates'), (400, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-11-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vlc depends on: ii vlc-bin 3.0.8-0+deb10u1 ii vlc-plugin-base 3.0.8-0+deb10u1 ii vlc-plugin-qt3.0.8-0+deb10u1 ii vlc-plugin-video-output 3.0.8-0+deb10u1 Versions of packages vlc recommends: ii vlc-l10n 3.0.8-0+deb10u1 ii vlc-plugin-notify 3.0.8-0+deb10u1 ii vlc-plugin-samba 3.0.8-0+deb10u1 ii vlc-plugin-skins2 3.0.8-0+deb10u1 ii vlc-plugin-video-splitter 3.0.8-0+deb10u1 ii vlc-plugin-visualization 3.0.8-0+deb10u1 vlc suggests no packages. Versions of packages libvlc-bin depends on: ii libc62.28-10 ii libvlc5 3.0.8-0+deb10u1 Versions of packages libvlc5 depends on: ii libc62.28-10 ii libvlccore9 3.0.8-0+deb10u1 Versions of packages libvlc5 recommends: ii libvlc-bin 3.0.8-0+deb10u1 Versions of packages vlc-bin depends on: ii libc6 2.28-10 ii libvlc-bin 3.0.8-0+deb10u1 ii libvlc5 3.0.8-0+deb10u1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-19 ii libaom0 1.0.0-3 ii libarchive13 3.2.2-2+deb9u2 ii libaribb24-0 1.0.3-2 ii libasound2 1.1.8-1 ii libass9 1:0.14.0-2 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavc1394-0 0.5.4-4+b1 ii libavcodec58 7:4.1.4-1~deb10u1 ii libavformat587:4.1.4-1~deb10u1 ii libavutil56 7:4.1.4-1~deb10u1 ii libbasicusageenvironment12018.11.26-1.1 ii libbluray2 1:1.1.0-1 ii libc62.28-10 ii libcairo21.16.0-4 ii libcddb2 1.3.2-5 ii libchromaprint1 1.4.3-3 ii libcrystalhd31:0.0~git20110715.fdd2f19-12 ii libdbus-1-3 1.10.28-0+deb9u1 ii libdc1394-22 2.2.5-1 ii libdca0 0.0.5-10 ii libdvbpsi10 1.3.0-5 ii libdvdnav4 5.0.3-3 ii libdvdread4 5.0.3-2 ii libebml4v5 1.3.6-2 ii libfaad2 2.8.0~cvs20161113-1+deb9u2 ii libflac8 1.3.2-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libfribidi0 1.0.5-3.1+deb10u1 ii libgcc1 1:8.3.0-6 ii libgcrypt20 1.8.4-5 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgnutls30 3.6.7-4 ii libgpg-error01.35-1 ii libgroupsock82018.11.26-1.1 ii libharfbuzz0b2.3.1-1 ii libixml101:1.8.4-2 ii libjpeg62-turbo 1:1.5.1-2 ii libkate1 0.4.1-7+b1 ii liblirc-client0 0.9.4c-9 ii liblivemedia64
Bug#941932: firefox: bug reporting instructions say to install non-existing firefox-dbg package
Package: firefox Version: 69.0.1-1 Severity: normal The instructions given by reportbug say to "alternatively" install firefox-dbg for crashes. There is no such package in the repository. Since I want to report a bug that happens only in headless mode, run from a fresh temporary profile that is automatically deleted after the crash, the solution of "about:crashes" does not work for me. -- Package-specific info: -- Extensions information Name: Amazon.com Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Bing Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Dark theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: user-disabled Name: Default theme Location: /usr/lib/firefox/omni.ja Package: firefox Status: enabled Name: DuckDuckGo Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: eBay Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Firefox Monitor Location: /usr/lib/firefox/browser/features/fxmoni...@mozilla.org.xpi Package: firefox Status: enabled Name: Firefox Screenshots Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi Package: firefox Status: enabled Name: Form Autofill Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi Package: firefox Status: enabled Name: Google Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Light theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: user-disabled Name: Twitter Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Web Compat Location: /home/master/.mozilla/firefox/8nobfoud.default-release/features/{2d31bdd3-1486-4ea7-bb62-61338e8f7d96}/webcom...@mozilla.org.xpi Status: enabled Name: WebCompat Reporter Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi Package: firefox Status: user-disabled Name: Wikipedia (en) Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled -- Plugins information Name: Shockwave Flash (32.0.0.142) Location: /usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so Package: browser-plugin-freshplayer-pepperflash Status: enabled -- Addons package information ii browser-plugin 0.3.9-2 amd64PPAPI-host NPAPI-plugin adapter f ii firefox69.0.1-1 amd64Mozilla Firefox web browser -- System Information: Debian Release: 9.11 APT prefers oldstable APT policy: (550, 'oldstable'), (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libasound21.1.3-5 ii libatk1.0-0 2.34.0-1 ii libc6 2.29-2 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.10.28-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-6 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.58.3-2+deb10u1 ii libgtk-3-03.24.5-1 ii libnspr4 2:4.21-2 ii libnss3 2:3.45-1 ii libpango-1.0-01.42.4-7~deb10u1 ii libsqlite3-0 3.29.0-2 ii libstartup-notification0 0.12-4+b2 ii libstdc++69.2.1-8 ii libx11-6 2:1.6.4-3+deb9u1 ii libx11-xcb1 2:1.6.4-3+deb9u1 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-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 libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3+deb9u1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox recommends: ii libavcodec-extra57 7:3.4.3-1 ii libavcodec587:4.1.4-1~deb10u1 Versions of packages firefox suggests: ii fonts-lmodern 2.004.5-3 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.17-3 ii libgtk2.0-02.24.31-2 ii otf-stix 1.1.1-1 ii pulseaudio 10.0-1+deb9u1 -- no debconf information
Bug#941931: firefox: loading nm.eurocontrol.int javascript-heavy page in headless mode fails in Firefox, but not in Firefox ESR
Package: firefox Version: 69.0.1-1 Severity: normal Tags: upstream Tested with upstream 69.0.2, reproduced. Reported at https://github.com/webcompat/web-bugs/issues/41756 Note that Debian package of Firefox 69.0.1 will produce about 2GB of logs in geckodriver.log, while upstream firefox 69.0.2 will be far more brief. Problem web page: https://www.public.nm.eurocontrol.int/PUBPORTAL/gateway/spec/index.html Loading through selenium / geckodriver / marionette the above website crashes Firefox 69.0.1 (Debian package) and 69.0.2 (tar.bz2 download from mozilla.org) on amd64 architecture. The very same selenium / geckodriver / marionette script in non-headless mode (just comment out the config line for headless) works correctly. The very same selenium / geckodriver / marionette script in headless mode with Firefox ESR 60.9.0esr (Debian package 60.9.0esr-1~deb9u1) (just change the binary_location option to point to it) works correctly. Loading the very same website in Firefox in normal user mode (not scripted through marionette) works fine (all tested versions). Reproduction needs python3-selenium firefoxdriver Debian packages and geckodriver from https://github.com/mozilla/geckodriver/releases (my understanding is that source code for these downloads is in the mozilla tree, building instructions at https://firefox-source-docs.mozilla.org/testing/geckodriver/Building.html the binary download page link to the exact revision of the tree they are built from) -- Package-specific info: -- Extensions information Name: Amazon.com Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Bing Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Dark theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: user-disabled Name: Default theme Location: /usr/lib/firefox/omni.ja Package: firefox Status: enabled Name: DuckDuckGo Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: eBay Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Firefox Monitor Location: /usr/lib/firefox/browser/features/fxmoni...@mozilla.org.xpi Package: firefox Status: enabled Name: Firefox Screenshots Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi Package: firefox Status: enabled Name: Form Autofill Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi Package: firefox Status: enabled Name: Google Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Light theme Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: user-disabled Name: Twitter Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled Name: Web Compat Location: /home/master/.mozilla/firefox/8nobfoud.default-release/features/{2d31bdd3-1486-4ea7-bb62-61338e8f7d96}/webcom...@mozilla.org.xpi Status: enabled Name: WebCompat Reporter Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi Package: firefox Status: user-disabled Name: Wikipedia (en) Location: /usr/lib/firefox/browser/omni.ja Package: firefox Status: enabled -- Plugins information Name: Shockwave Flash (32.0.0.142) Location: /usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so Package: browser-plugin-freshplayer-pepperflash Status: enabled -- Addons package information ii browser-plugin 0.3.9-2 amd64PPAPI-host NPAPI-plugin adapter f ii firefox69.0.1-1 amd64Mozilla Firefox web browser -- System Information: Debian Release: 9.11 APT prefers oldstable APT policy: (550, 'oldstable'), (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libasound21.1.3-5 ii libatk1.0-0 2.34.0-1 ii libc6 2.29-2 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.10.28-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-6 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.58.3-2+deb10u1 ii libgtk-3-03.24.5-1 ii libnspr4 2:4.21-2 ii libnss3 2:3.45-1 ii libpango-1.0-01.42.4-7~deb10u1 ii libsqlite3-0 3.29.0-2 ii libstartup-notification0 0.12-4+b2 ii libstdc++69.2.1-8 ii libx11-6
Bug#930785: mutt: "file exists" error when saving attachment to CIFS share
Package: mutt Version: 1.7.2-1+deb9u1 Severity: important When saving an attachment from into a directory on a CIFS share (Windows 2012R2 server), mutt creates an empty file and then fails with the error message "file exists (errno=17)". Saving is successful if one tries again to same filename and then chooses "overwrite". Here's the relevant part of an strace: 25780 restart_syscall(<... resuming interrupted poll ...>) = 1 25780 read(0, "\r", 1) = 1 25780 rt_sigaction(SIGINT, {sa_handler=0x556436f378e0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f374591b840}, NULL, 8) = 0 25780 access("vente-2019/filename.pdf", F_OK) = -1 ENOENT (No such file or directory) 25780 write(1, "\rSaving...\33[37m\33[40m\33[K\33(B\33[m\33[3"..., 47) = 47 25780 getpid() = 25780 25780 mkdir("vente-2019/.muttySzSP2", 0700) = 0 25780 openat(AT_FDCWD, "vente-2019/.muttySzSP2/filename.pdf", O_WRONLY|O_CREAT|O_EXCL|O_NOFOLLOW, 0600) = 5 25780 close(5) = 0 25780 link("vente-2019/.muttySzSP2/filename.pdf", "vente-2019/filename.pdf") = 0 25780 lstat("vente-2019/.muttySzSP2/filename.pdf", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 25780 lstat("vente-2019/filename.pdf", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 25780 unlink("vente-2019/.muttySzSP2/filename.pdf") = 0 25780 rmdir("vente-2019/.muttySzSP2") = 0 25780 write(1, "\7", 1) = 1 25780 write(1, "\rfopen: File exists (errno = 17)", 32) = 32 -- Package-specific info: NeoMutt 20170113 (1.7.2) Copyright (C) 1996-2016 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 4.9.0-9-amd64 (x86_64) libidn: 1.33 (compiled with 1.33) hcache backends: tokyocabinet Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' '--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' '--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--with-mailpath=/var/mail' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/mutt-bO92sq/mutt-1.7.2=. -fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 -fdebug-prefix-map=/build/mutt-bO92sq/mutt-1.7.2=. -fstack-protector-strong -Wformat -Werror=format-security -fno-delete-null-pointer-checks Compile options: +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME +DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK -SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_FUTIMENS +HAVE_GETADDRINFO +HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP
Bug#913641: libreoffice-report-builder: report builder reports fail to run
On Tue, Nov 13, 2018 at 12:58:02PM +0100, rene.engelh...@mailbox.org wrote: > Am 13. November 2018 12:13:52 MEZ schrieb Lionel Elie Mamane > : >> Package: libreoffice-report-builder >> Version: 1:6.1.3-1 >> Severity: normal > Huh, what? On a stable? Seriousl Yes, I'm dogfooding more recent version of LibreOffice. Seriously, that's how one gets early testers and bug reports before release. >> Trying to run any report (a report builder one, not a legacy one) >> fails with error message: >> Can not activate the factory for >> org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory > I assume it's related to stables openjdk 8 update and the discussion > in https://gerrit.libreoffice.org/63118. Hmmm... Switching LibreOffice to use OpenJDK 7 solves that issue. I guess this confirms your assumption? > Need to file a bug on openjdk... Not clear if you are saying I need to do it, or you need to do it. I don't quite understand the issue, you do, so I assume you will, you will be able to explain to the Java package maintainers the issue? Please CC me, I'd like to be educated on that. > >-- System Information: > >Debian Release: 9.6 > > APT prefers stable-updates > >APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), > >(300, 'unstable'), (1, 'experimental') > >Architecture: amd64 (x86_64) > >Foreign Architectures: i386 > > [...] > >Versions of packages libreoffice-report-builder depends on: > >ii libbase-java 1.1.6-2 > >ii libcommons-logging-java1.2-1 > >ii libflute-java 1:1.1.6-3 > >ii libfonts-java 1.1.6.dfsg-3 > >ii libformula-java1.1.7.dfsg-2 > >ii liblayout-java 0.2.10-2 > >ii libloader-java 1.1.6.dfsg-4 > >ii libpentaho-reporting-flow-engine-java 0.9.4-4 > >ii libreoffice-common 1:6.1.3-1 > >ii libreoffice-core 1:6.1.3-1 > >ii libreoffice-java-common1:6.1.3-1 > >ii libreoffice-report-builder-bin 1:6.1.3-1 > >ii librepository-java 1.1.6-3 > >ii libsac-java1.3+dfsg-2 > >ii libserializer-java 1.1.6-4 > >ii libxml-java1.1.6.dfsg-3 > This honestly is Soo broken. Ok, the backport will have the same problem > (that's why I needed +2 there) but.. That's honestly not broken at all. That's why our packages have dependencies, so that they can have what they require. >> ii openjdk-8-jre [java6-runtime] 8u181-b13-2~deb9u1 > This is probably the cause What happens with the old openjdk 8 on > stretch or openjdk 11.0.1+13? Downgrading to 8u171-b11-2 makes this problem disappear.
Bug#913641: libreoffice-report-builder: report builder reports fail to run
Package: libreoffice-report-builder Version: 1:6.1.3-1 Severity: normal Trying to run any report (a report builder one, not a legacy one) fails with error message: Can not activate the factory for org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory Nothing particular on stderr. -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice-report-builder depends on: ii libbase-java 1.1.6-2 ii libcommons-logging-java1.2-1 ii libflute-java 1:1.1.6-3 ii libfonts-java 1.1.6.dfsg-3 ii libformula-java1.1.7.dfsg-2 ii liblayout-java 0.2.10-2 ii libloader-java 1.1.6.dfsg-4 ii libpentaho-reporting-flow-engine-java 0.9.4-4 ii libreoffice-common 1:6.1.3-1 ii libreoffice-core 1:6.1.3-1 ii libreoffice-java-common1:6.1.3-1 ii libreoffice-report-builder-bin 1:6.1.3-1 ii librepository-java 1.1.6-3 ii libsac-java1.3+dfsg-2 ii libserializer-java 1.1.6-4 ii libxml-java1.1.6.dfsg-3 libreoffice-report-builder recommends no packages. libreoffice-report-builder suggests no packages. Versions of packages libreoffice-base depends on: ii libc6 2.27-8 ii libgcc1 1:8.2.0-9 ii libreoffice-base-core 1:6.1.3-1 ii libreoffice-base-drivers 1:6.1.3-1 ii libreoffice-core 1:6.1.3-1 ii libstdc++68.2.0-9 ii uno-libs3 6.1.3-1 ii ure 6.1.3-1 Versions of packages libreoffice-base recommends: ii default-jre [java6-runtime]2:1.8-58 ii libreoffice-java-common1:6.1.3-1 ii libreoffice-writer 1:6.1.3-1 ii openjdk-7-jre [java6-runtime] 7u151-2.6.11-3 ii openjdk-8-jre [java6-runtime] 8u181-b13-2~deb9u1 Versions of packages libreoffice-base suggests: ii unixodbc 2.3.4-1 -- no debconf information
Bug#857467: Postgresql — Cannot enter or edit data or edit table columns in absence of Primary Key
On Sat, Mar 18, 2017 at 11:35:36AM +0100, Dr. Axel Stammler wrote: > I actually believe the authors think this bug is a feature as table > data can be entered and edited only if the table has a primary key. Yes, it is a design choice of LibreOffice, and is not in any way specific to any DBMS. No Primary Key means read-only for that table. Unlikely to change. > Although this is a very sensible restriction it should be > accompanied by some kind of warning explaining this. That's a good idea. If you decide to submit a patch upstream for this, you are welcome to put me as a reviewer. -- Lionel
Bug#857467: libreoffice-base: Postgresql — Cannot enter or edit data or edit table columns without primary key
On Tue, Oct 30, 2018 at 01:17:49AM +0100, Stéphane Aulery wrote: > forwarded 857467 https://bugs.documentfoundation.org/show_bug.cgi?id=45252 No, that upstream bug is about something else, namely that the PostgreSQL SDBC driver does not implement changing table structure, creating tables, deleting tables, etc. Only data manipulation (adding rows, changing rows, deleting rows). This Debian bug is that data manipulation is not possible without a primary key on the table. -- Lionel
Bug#770641: bash-completion: mv --target-directory=dest/ only looks for directories for first source
Package: bash-completion Version: 1:2.8-1 Followup-For: Bug #770641 Note that completion of mv --target-directory dest/ does not have the same bug. -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#895823: cannot purge dovecot-common
severity 895823 serious thanks On Mon, Apr 16, 2018 at 03:41:19PM +0200, Harald Dunkel wrote: > The unattended upgrades removed my dovecot.conf file. This broke my dovecot install with a delay of several days (maybe linked to log rotation interval, when dovecot is instructed to read configuration files again?) In my opinion, this warrants a higher severity for the bug. > this, I stumbled over this: > stagemail:/etc/dovecot# dpkg -P dovecot-common Indeed, the "rm -f" of dovecot.conf is in dovecot-common's purge action in the postrm file. It looks like every purge attempt will delete the configuration file again (!) -- Lionel
Bug#885688: sensible-utils: sensible-browser launches $BROWSER with empty argument
Package: sensible-utils Version: 0.0.9+deb9u1 Severity: normal Tags: patch when environmental variable BROWSER is set to value FOO (and FOO is i /usr/bin/FOO) $ sensible-browser does execve("/usr/bin/FOO", ["FOO", ""], ...) execve("/usr/bin/FOO", ["FOO", ""], ...) instead of execve("/usr/bin/FOO", ["FOO"], ...) That is, in sh notation, it does $ FOO '' instead of $ FOO In particular, it causes firefox to open with a directory listing of getcwd() instead of its configured start page. I attach two patches: a minimal patch that uses the same solution as the rest of the script (maybe good for security update, to correct the regression introduced by the security update), and a better patch that also allows passing sensible-browser multiple URLs (maybe good for sid). -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) -- no debconf information --- sensible-utils-0.0.11/sensible-browser 2017-11-15 16:30:02.0 +0100 +++ sensible-utils-0.0.11.foo/sensible-browser 2017-12-29 05:38:26.658192505 +0100 @@ -1,13 +1,11 @@ #!/bin/sh -URL="$1" - # Prevent recursive loops, where these values are set to this script p="$(which sensible-browser)" [ "$(which $BROWSER || true)" = "$p" ] && BROWSER= if test -n "$BROWSER"; then -${BROWSER} "$1" +${BROWSER} "$@" ret="$?" if [ "$ret" -ne 126 ] && [ "$ret" -ne 127 ]; then exit "$ret" @@ -17,20 +15,20 @@ if test -n "$DISPLAY"; then if test -n "$GNOME_DESKTOP_SESSION_ID"; then if test -x /usr/bin/gnome-www-browser; then -exec /usr/bin/gnome-www-browser ${URL:+"$URL"} +exec /usr/bin/gnome-www-browser "$@" elif test -x /usr/bin/x-www-browser; then -exec /usr/bin/x-www-browser ${URL:+"$URL"} +exec /usr/bin/x-www-browser "$@" elif test -x /usr/bin/gnome-terminal && test -x /usr/bin/www-browser; then -exec /usr/bin/gnome-terminal -e "/usr/bin/www-browser ${URL:+\"$URL\"}" +exec /usr/bin/gnome-terminal -x /usr/bin/www-browser "$@" fi fi if test -x /usr/bin/x-www-browser; then -exec /usr/bin/x-www-browser ${URL:+"$URL"} +exec /usr/bin/x-www-browser "$@" elif test -x /usr/bin/x-terminal-emulator && test -x /usr/bin/www-browser; then -exec /usr/bin/x-terminal-emulator -e /usr/bin/www-browser ${URL:+"$URL"} +exec /usr/bin/x-terminal-emulator -x /usr/bin/www-browser "$@" fi elif test -x /usr/bin/www-browser; then -exec /usr/bin/www-browser ${URL:+"$URL"} +exec /usr/bin/www-browser "$@" fi printf "Couldn't find a suitable web browser!\n" >&2 --- sensible-browser~ 2017-11-15 16:30:02.0 +0100 +++ sensible-browser 2017-12-29 05:32:11.183127131 +0100 @@ -7,7 +7,7 @@ [ "$(which $BROWSER || true)" = "$p" ] && BROWSER= if test -n "$BROWSER"; then -${BROWSER} "$1" +${BROWSER} ${URL:+"$URL"} ret="$?" if [ "$ret" -ne 126 ] && [ "$ret" -ne 127 ]; then exit "$ret"
Bug#875688: libreoffice-report-builder: report builder inactive in 5.4
On Wed, Dec 13, 2017 at 09:20:57AM +0100, Rene Engelhard wrote: > On Wed, Dec 13, 2017 at 04:43:36AM +0100, Lionel Elie Mamane wrote: >> On Tue, Dec 12, 2017 at 11:35:29PM +0100, Rene Engelhard wrote: >>> On Thu, Dec 07, 2017 at 04:28:10PM +0100, Lionel Elie Mamane wrote: >>>> The Debian package of 5.4 behaves as if the optional part of >>>> LibreOffice "Report Builder" was not installed, although the >>>> packages libreoffice-report-builder and >>>> libreoffice-report-builder-bin are installed. I haven't diagnosed >>>> why. >>> Interestingly, in my sid test vm, the 5.4.4 packages from >>> https://people.debian.org/~rene/libreoffice/5.4/ do show it again >>> *but* you marked it as found in 6.0.0 beta2 and yes, I don't see >>> it there either anymore... >> This starts to look like there is some non-determinism in the build >> process, and depending on more-or-less random choices made, the bug is >> there or not. > This was the case since ages (3.6.1 if I am right), but maybe something in > 5.4 changed wrt how it detects/runs the report builder? Not that I'm aware of, but it could be a change made by another developer that I didn't see. > Maybe it's the following: > https://anonscm.debian.org/cgit/pkg-openoffice/libreoffice.git/tree/rules#n1965 > is build-arch. Due to build time (and Build-Depends:, one can move those > to -Indep) optimization we build with > -disable-ext-wiki-publisher \ > --disable-report-builder --disable-scripting-javascript \ > --disable-scripting-beanshell > here and only later > (https://anonscm.debian.org/cgit/pkg-openoffice/libreoffice.git/tree/rules#n2002) > we do the full build with the report builder. I wondered how this could ever work, since report builder (the "*report*builder*" packages) contains .so files. Confusingly, it seems that these parts are built even on a --disable-report-builder build. -- Lionel
Bug#875688: libreoffice-report-builder: report builder inactive in 5.4
On Tue, Dec 12, 2017 at 11:35:29PM +0100, Rene Engelhard wrote: > On Thu, Dec 07, 2017 at 04:28:10PM +0100, Lionel Elie Mamane wrote: > > The Debian package of 5.4 behaves as if the optional part of > > LibreOffice "Report Builder" was not installed, although the packages > > libreoffice-report-builder and libreoffice-report-builder-bin are > > installed. I haven't diagnosed why. > Interestingly, in my sid test vm, the 5.4.4 packages from > https://people.debian.org/~rene/libreoffice/5.4/ do show it again *but* > you marked it as found in 6.0.0 beta2 and yes, I don't see it there > either anymore... This starts to look like there is some non-determinism in the build process, and depending on more-or-less random choices made, the bug is there or not. If that's the case, it will a PITA to debug... But since AFAIK that bug happens only on Debian, we should concentrate on the Debian-specific patches. Or the non-determinism is in the install process? It depends in what order the packages are installed / upgraded? -- Lionel
Bug#875688: libreoffice-report-builder: report builder inactive in 5.4
On Tue, Dec 12, 2017 at 11:35:29PM +0100, Rene Engelhard wrote: > On Thu, Dec 07, 2017 at 04:28:10PM +0100, Lionel Elie Mamane wrote: >> The immediate cause is that in file >> dbaccess/source/ui/misc/linkeddocuments.cxx >> function OLinkedDocumentsAccess::open, the call to impl_open throws a >> css::io::WrongFormatException, >> but what is the underlying reason for that? Probably the internal >> LibreOffice registry doesn't have properly registered the optional >> "Report Builder" part (could be an error in >> /usr/lib/libreoffice/share/registry/reportbuilder.xcd or that file is >> not loaded), or it fails to load for some reason. > But it is there and was there. And if it was that, why is it > different between versions and without any change to what we do with > that file? When I wrote "it fails to load for some reason", I meant "Report Builder fails to load for some reason", and that's the following files: /usr/lib/libreoffice/program/librptlo.so /usr/lib/libreoffice/program/librptuilo.so /usr/lib/libreoffice/program/librptxmllo.so -- Lionel
Bug#882792: xfce4-panel: some icons not appearing in notification panel
Package: xfce4-panel Version: 4.12.1-2 Followup-For: Bug #882792 I got the same bug after upgrading from jessie to stretch. VLC 2.2.8-1 doesn't display in notification area. Telegram Desktop 1.1.23-3 doesn't display in notificaiton area. Orage 4.12.1-3 displays in notification area. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xfce4-panel depends on: ii exo-utils0.10.7-1 ii libatk1.0-0 2.22.0-1 ii libc62.25-3 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.24-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libexo-1-0 0.10.7-1 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.6.3-3.2 ii libgarcon-1-00.4.0-2 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u1 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libice6 2:1.0.9-2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libsm6 2:1.2.2-1+b3 ii libwnck222.30.7-5.1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfce4ui-1-0 4.12.1-2 ii libxfce4util74.12.1-3 ii libxfconf-0-24.12.1-1 xfce4-panel recommends no packages. xfce4-panel suggests no packages. -- no debconf information
Bug#875688: libreoffice-report-builder: report builder inactive in 5.4
retitle 875688 report builder inactive; only legacy reports can be created and run thanks For clarity, there are two reporting systems in LibreOffice: 1) Report Design (entirely in C++), the "old legacy one". 2) Report Builder, which used to be an extension, then was a bundled extension, and then became an optional but integrated part of LibreOffice (installed by default, but optional). The Debian package of 5.4 behaves as if the optional part of LibreOffice "Report Builder" was not installed, although the packages libreoffice-report-builder and libreoffice-report-builder-bin are installed. I haven't diagnosed why. The immediate cause is that in file dbaccess/source/ui/misc/linkeddocuments.cxx function OLinkedDocumentsAccess::open, the call to impl_open throws a css::io::WrongFormatException, but what is the underlying reason for that? Probably the internal LibreOffice registry doesn't have properly registered the optional "Report Builder" part (could be an error in /usr/lib/libreoffice/share/registry/reportbuilder.xcd or that file is not loaded), or it fails to load for some reason.
Bug#794502: openjdk-8-jre-headless: /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64 symlink also dangling
Package: openjdk-8-jre-headless Followup-For: Bug #794502 The same problem exists with the /usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64 symlink, which makes sense only if openjdk-8-dbg is installed. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8), LANGUAGE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages openjdk-8-jre-headless depends on: ii ca-certificates-java 20170531+nmu1 ii java-common 0.58 ii libc6 2.24-11+deb9u1 ii libcups2 2.2.1-8 ii libfontconfig12.12.3-0.2 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18 ii libjpeg62-turbo 1:1.5.1-2 ii liblcms2-22.8-4 ii libnss3 2:3.26.2-1.1 ii libpcsclite1 1.8.20-1 ii libstdc++66.3.0-18 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxi62:1.7.9-1 ii libxrender1 1:0.9.10-1 ii libxtst6 2:1.2.3-1 ii multiarch-support 2.24-11+deb9u1 ii util-linux2.29.2-1 ii zlib1g1:1.2.8.dfsg-5 openjdk-8-jre-headless recommends no packages. Versions of packages openjdk-8-jre-headless suggests: ii fonts-dejavu-extra2.37-1 pn fonts-indic pn fonts-ipafont-gothic pn fonts-ipafont-mincho pn fonts-wqy-microhei pn fonts-wqy-zenhei ii libnss-mdns 0.10-8 -- no debconf information
Bug#863904: vacation: matches address in name when absent in address
Package: vacation Version: 3.3.1 Severity: normal this should not send a vacation message ("john" does not appear as a localpart in an address in the To or Cc header), but does (presumably because the string appears in the Cc header): printf 'From t...@example.org\nTo: Sara Red\nCc: John Dukes \nSubject: Tst\n\nTst' | vacation john -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing-updates'), (400, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vacation depends on: ii libc6 2.19-18+deb8u6 ii libdb5.3 5.3.28-9 vacation recommends no packages. vacation suggests no packages. -- no debconf information
Bug#857293: asterisk-chan-capi: should it be removed from Debian?
On Thu, Mar 09, 2017 at 06:32:56PM +0100, Mattia Rizzolo wrote: > Therefor, I'm suggesting to just remove this package from the > archive. I was probably the only uploaded to somewhat care about this package or with the hardware to make any test. Basically, I don't use the hardware anymore, it is in a retired computer, so I think nobody's left in Debian with the capacity to maintain this. Removal is a good idea. (Plus I'm quasi-inactive in Debian these days.) -- Lionel
Bug#857039: linux-latest: xen-linux-system packages
Source: linux-latest Version: 79 The changelog says: linux-latest (77) unstable; urgency=medium * Re-introduce xen-linux-system packages, accidentally dropped in version 75 But as of version 79, no xen-linux-system seems to be available, in particular xen-linux-system-amd64 The changelog entries of version 78 and 79 don't mention any removal. Were they accidentally dropped or was this on purpose? -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#843346: dvidvi: diff for NMU version 1.0-8.2
It is fine. You can even make a non-delayed upload. Thanks, Lionel On Thu, Dec 22, 2016 at 06:24:17PM -0200, Joao Eriberto Mota Filho wrote: > Control: tags 843346 + pending > > Dear maintainer, > > I've prepared an NMU for dvidvi (versioned as 1.0-8.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. > > Regards, > > Eriberto > > diff -u dvidvi-1.0/debian/changelog dvidvi-1.0/debian/changelog > --- dvidvi-1.0/debian/changelog > +++ dvidvi-1.0/debian/changelog > @@ -1,3 +1,12 @@ > +dvidvi (1.0-8.2) unstable; urgency=medium > + > + * Non-maintainer upload. > + * Fix the NMU version. > + * Fix FTCBFS: Use triplet-prefixed compiler. Thanks to > +Helmut Grohne. (Closes: #843346) > + > + -- Joao Eriberto Mota Filho Thu, 22 Dec 2016 > 18:12:22 -0200 > + > dvidvi (1.0-8etch2.1) unstable; urgency=medium > >* Non-maintainer upload. > diff -u dvidvi-1.0/debian/rules dvidvi-1.0/debian/rules > --- dvidvi-1.0/debian/rules > +++ dvidvi-1.0/debian/rules > @@ -1,5 +1,10 @@ > #!/usr/bin/make -f > > +include /usr/share/dpkg/architecture.mk > +ifeq ($(origin CC),default) > +CC := $(DEB_HOST_GNU_TYPE)-gcc > +endif > + > CFLAGS := -Wall -g -O$(if $(findstring noopt,$(DEB_BUILD_OPTIONS)),0,2) > > build: build-arch build-indep >
Bug#847128: evince: different rendering of two copies of same PDF
On Mon, Dec 05, 2016 at 03:20:46PM -0600, Jason Crain wrote: > On Mon, Dec 05, 2016 at 09:49:30PM +0100, Lionel Elie Mamane wrote: >> When I load >> https://www.belgocontrol.be/html/belgocontrol_static/eaip/eAIP_Main/pdf/EB_Amdt_2016_012_en.pdf >> in Iceweasel, which is configured to open PDF files with Evince, the >> PDF opens in evince and displays bad. > Your images looks similar to https://bugzilla.gnome.org/775123, > where the text is stretched oddly. Yes, exactly. I have the same behaviour on the attachment in that bug: - directly from iceweasel -> stretched - wget + open in evince : normal -- Lionel
Bug#845086: myspell-tools: truncates long replacement rules
Package: myspell-tools Version: 1:3.1-24.2 Severity: normal Tags: patch is2my-spell.pl transforms: suffixes flag *g: S I E D S > -IEDS,EYENT\-ELLES into SFX g Y 185 SFX g ieds eyent\-ell sieds it should be SFX g Y 185 SFX g ieds eyent\-elles sieds I attach the corresponding patch. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages myspell-tools depends on: ii libc6 2.23-4 myspell-tools recommends no packages. myspell-tools suggests no packages. -- no debconf information --- /usr/bin/is2my-spell.pl 2016-09-25 17:11:41.0 +0200 +++ is2my-spell.pl 2016-11-20 10:13:36.243699763 +0100 @@ -52,7 +52,7 @@ for my $def (@flgdefs) { #print $afxtype, ' ', $flgname, ' ', $def->{remove}, "\t", # $def->{replace}, "\t", $def->{match}, "\n"; -printf "%-3.3s %-1.1s %-10.10s %-10.10s %s\n", +printf "%-3.3s %-1.1s %-20.20s %-20.20s %s\n", $afxtype, $flgname, $def->{remove}, $def->{replace}, $def->{match}; } print "\n";
Bug#825929: initramfs-tools-core - incorrect busybox relations
Package: initramfs-tools Version: 0.125 Followup-For: Bug #825929 You might want to consider changing the NEWS entry to say that BUSYBOX=y requires busybox version 1:1.22.0-17~ or later installed, not just "modify /etc/initramfs-tools/initramfs.conf or install busybox". The paragraph could read: * If initramfs-tools is configured to use busybox but it is not installed or the installed version is too old, mkinitramfs will now fail. Previously it would quietly use klibc instead, sometimes producing a broken initramfs. You may need to modify /etc/initramfs-tools/initramfs.conf or install busybox 1:1.22.0-17~ or later when upgrading. Also, the automatic y to auto did not happen for me. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 18M Sep 29 20:04 /boot/initrd.img-4.6.0-1-amd64 -rw-r--r-- 1 root root 18M Nov 9 10:48 /boot/initrd.img-4.7.0-1-amd64 -- /proc/cmdline placeholder root=/dev/mapper/fort-root ro quiet -- resume RESUME=/dev/mapper/fort-swap -- /proc/filesystems ext3 ext2 ext4 fuseblk xfs udf iso9660 jfs msdos vfat ntfs minix hfs hfsplus qnx4 ufs btrfs -- lsmod Module Size Used by cpuid 16384 0 btrfs1007616 0 xor24576 1 btrfs raid6_pq 102400 1 btrfs ufs73728 0 qnx4 16384 0 hfsplus 102400 0 hfs57344 0 minix 36864 0 ntfs 98304 0 vfat 20480 0 msdos 20480 0 fat69632 2 vfat,msdos jfs 176128 0 isofs 40960 0 udf90112 0 crc_itu_t 16384 1 udf xfs 958464 0 libcrc32c 16384 1 xfs crc32c_generic 16384 0 xt_physdev 16384 4 br_netfilter 24576 1 xt_physdev iptable_filter 16384 1 ip_tables 24576 1 iptable_filter x_tables 36864 3 xt_physdev,ip_tables,iptable_filter xen_netback49152 1 tun28672 2 xen_blkback45056 0 nls_utf8 16384 7 cifs 630784 14 sha256_ssse3 32768 0 cmac 16384 0 md416384 0 ecb16384 0 des_generic24576 0 arc4 16384 0 dns_resolver 16384 1 cifs fscache61440 1 cifs joydev 20480 0 hid_microsoft 16384 0 bridge126976 1 br_netfilter stp16384 1 bridge llc16384 2 stp,bridge xen_gntdev 20480 2 xen_evtchn 16384 4 xenfs 16384 1 xen_privcmd16384 5 xenfs binfmt_misc20480 1 amdkfd126976 1 radeon 1490944 3 intel_rapl 20480 0 x86_pkg_temp_thermal16384 0 intel_powerclamp 16384 0 coretemp 16384 0 crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 ghash_clmulni_intel16384 0 ttm94208 1 radeon hmac 16384 9 drbg 24576 1 ansi_cprng 16384 0 drm_kms_helper147456 1 radeon aesni_intel 167936 0 aes_x86_64 20480 1 aesni_intel iTCO_wdt 16384 0 iTCO_vendor_support16384 1 iTCO_wdt drm 360448 7 ttm,drm_kms_helper,radeon lrw16384 1 aesni_intel gf128mul 16384 1 lrw fujitsu_laptop 20480 0 glue_helper16384 1 aesni_intel ablk_helper16384 1 aesni_intel cryptd 20480 3 ghash_clmulni_intel,aesni_intel,ablk_helper evdev 24576 26 pcspkr 16384 0 serio_raw 16384 0 sb_edac32768 0 edac_core 57344 1 sb_edac i2c_algo_bit 16384 1 radeon sg 32768 0 video 40960 1 fujitsu_laptop wmi20480 0 8250_fintek16384 0 tpm_infineon 20480 0 snd_hda_codec_conexant24576 1 snd_hda_codec_hdmi 45056 1 snd_hda_codec_generic69632 1 snd_hda_codec_conexant snd_hda_intel 36864 7 snd_hda_codec 135168 4 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_codec_generic,snd_hda_intel mei_me 32768 0 tpm_tis20480 0 tpm45056 2 tpm_tis,tpm_infineon snd_hda_core 81920 5 snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel mei94208 1 mei_me snd_hwdep 16384 1 snd_hda_codec processor 36864 0 lpc_ich24576 0 mfd_core
Bug#834706: libc6-dev: needs versioned dependency on linux-libc-dev for SYS_getrandom
On Thu, Aug 18, 2016 at 03:52:48PM +0200, Aurelien Jarno wrote: > On 2016-08-18 09:53, Lionel Elie Mamane wrote: >> /usr/include/x86_64-linux-gnu/bits/syscall.h >> contains >> #define SYS_getrandom __NR_getrandom >> but that is not defined in stable's linux-libc-dev (version >> 3.16.7-ckt25-2 and security update 3.16.7-ckt25-2+deb8u3). >> For this #define to work, libc6-dev needs a versioned depends on a >> newer version of linux-libc-dev. The version now in sid and testing >> (4.6.4-1) works but probably the requirement is more lax than that. > I am not sure about that. This kind of new features are usually > detected by the configure scripts of the software, given anyway that > the presence of the syscall definition doesn't imply that the > running kernel has support for it. I encountered this issue when compiling mutt. It contains this code: #if defined(SYS_getrandom) && defined(__linux__) long ret; do { ret = syscall(SYS_getrandom, out, len, 0, 0, 0, 0); } while ((ret == -1) && (errno == EINTR)); if (ret == len) return; // more stuff, removed here because not useful to the point #endif That code fails to compile with a new libc6-dev and old linux-libc-dev, with an error message along the lines of symbol __NR_getrandom not defined If you mean to say this mutt code is buggy, then fine, I defer to your expertise. You can reassign this bug to mutt with an explanation of what it _should_ do. > Also I am not sure Policy 3.5 applies there, most of the packages > work correctly there, so the dependency is not "required" for > packages to "work correctly". I understand "work correctly" as "works completely correctly", not "most of the package works correctly", and always have. I won't fight you if you disagree and downgrade the severity. -- Lionel
Bug#834706: libc6-dev: needs versioned dependency on linux-libc-dev for SYS_getrandom
On Thu, Aug 18, 2016 at 09:53:20AM +0200, Lionel Elie Mamane wrote: > libc6-dev needs a versioned depends on a newer version of > linux-libc-dev. The version now in sid and testing (4.6.4-1) works > but probably the requirement is more lax than that. Rumours suggest that 3.6.17 would be enough, since that's when the getrandom() syscall was introduced. -- Lionel
Bug#834706: libc6-dev: needs versioned dependency on linux-libc-dev for SYS_getrandom
Package: libc6-dev Version: 2.23-4 Severity: serious Justification: Policy 3.5 /usr/include/x86_64-linux-gnu/bits/syscall.h contains #define SYS_getrandom __NR_getrandom but that is not defined in stable's linux-libc-dev (version 3.16.7-ckt25-2 and security update 3.16.7-ckt25-2+deb8u3). For this #define to work, libc6-dev needs a versioned depends on a newer version of linux-libc-dev. The version now in sid and testing (4.6.4-1) works but probably the requirement is more lax than that. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libc6-dev depends on: ii libc-dev-bin2.23-4 ii libc6 2.23-4 ii linux-libc-dev 4.6.4-1 libc6-dev recommends no packages. Versions of packages libc6-dev suggests: ii glibc-doc 2.19-18+deb8u4 ii manpages-dev 3.74-1 -- no debconf information
Bug#260193: Updated sawfish, does this bug still applies?
On Sat, Jun 25, 2016 at 05:50:29PM +0100, j...@calhariz.com wrote: > The sawfish was updated, can you check if this bug still applies? No idea. I don't use gabber anymore. There isn't anymore even a package by this name in Debian. -- Lionel
Bug#673991: hypertex: too much vspace before theorem if previous line full
On Wed, May 23, 2012 at 07:57:44AM +0900, Norbert Preining wrote: > On Di, 22 Mai 2012, Hilmar Preuße wrote: >> You love to open bugs for Debian stable, right? Please note that we >> don't deal with bug severity < RC in Debian stable, i.e. if that >> problem would have been solved in Debian sid we'd have closed that >> bug immediately. > And, in addition, did you read the reportbug message: > *We*are*not*a*TeX*Help*Desk* > Bugs should be concerning the packaging, not concerning bugs within > packages (like interoperabillity etc). Yes, I did. The reportbug message I got (with texlive version 2009-11) was very exactly: begin quote If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.latex-einfuehrung.de/mini-en.html (english) or http://www.latex-einfuehrung.de/mini.html (german) --- end quote --- I see that in a *later* version this text was added, but _it was not in the message I got_: --- begin quote --- IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** --- end quote --- I understand that either your policy changed, or you documented it more clearly, between these two points in time. But I _did_ read the reportbug message in its entirety! When I entered Debian, it was very much the general policy that users should report the bug to the Debian BTS, and the maintainer would separate upstream issues from Debian-specific issues and interact with upstream, the user not being expected to by able to do that; on the contrary we kinda protected upstream from users (which were not in a very good position to know if the problem was upstream or Debian-specific). It has become popular for maintainers of "big" packages to have another policy, that they won't do that and ask users to speak to upstream directly. I respect that (and I understand the "lack of resources" reasons), but when that policy is not clearly documented (as it was in the version of the TeX Live packages I had at that time) and I'm not knowledgeable enough about the program to make a good bug report upstream, yes, I do fall back on what I understand to be the default policy. In the specific case of (La)TeX I (at the time) found it sometimes highly not obvious how to find the upstream of this or that LaTeX package... If I remember well, maintainership changed hands by announcement on some Usenet newsgroup, so you kinda had to search the archives, ... Maybe hypertex was more clearly maintained, but I must admit that I felt quite overwhelmed by all this (La)TeX galaxy, and that in 2012 I was emptying the "found during my thesis writing" pipeline and was not as available as before to launch into investigations. Also, IMHO it is to be expected to have bug reports about the version in stable, since that's what users not interested in the risk of "how broken is my system today" supposedly run... If the user gets as an answer "bug fixed in unstable", that's rather good news! But IMHO expecting every single user to balance several different VMs or jails or ... is not that user-friendly. While I sympathise with the lack of manpower, in the abstract I wish Debian would be more user-friendly in that way. No, I don't have a solution to give package maintainers the resources to fulfil my wish. Thank you very much Hilmar that you exceptionally took the time to handle my bug report anyway. -- Lionel
Bug#471958: openssl: Generated private keys world-readable by default
On Sat, May 28, 2016 at 09:52:30PM +0200, Sebastian Andrzej Siewior wrote: > On 2008-04-06 15:04:58 [+0200], Lionel Elie Mamane wrote: >> OK, fair enough. If only Debian patches it, people using Debian >> will write scripts using genrsa that are dangerous on other >> OSes. I've emailed upstream with the suggestion, we'll see what >> they think of it. > Upstream suggested to use safe umask. Are you fine with me closing > this bug? I disagree with upstream but am not going to fight it. Leaving this bug open indefinitely without intending to ever fix it does not make sense indeed. -- Lionel
Bug#824103: ifrench-gut: missing word "inféodation"
Package: ifrench-gut Version: 1:1.0-31 Severity: normal See http://www.larousse.fr/dictionnaires/francais/inf%C3%A9odation/42903 for a dictionary reference on this word. -- System Information: Debian Release: 8.4 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages ifrench-gut depends on: ii debconf [debconf-2.0] 1.5.56 ii dictionaries-common1.23.17 ii ispell 3.3.02-6 ifrench-gut recommends no packages. Versions of packages ifrench-gut suggests: ii wfrench 1.2.3-10 -- debconf information: ifrench-gut/languages: francais GUTenberg TeX8b (French GUTenberg TeX8b), francais GUTenberg latin1 (French GUTenberg latin1), francais GUTenberg (French GUTenberg) shared/packages-ispell:
Bug#822086: RM: scsh-0.6 -- ROM; in statis upstream; portability problems
Package: ftp.debian.org Severity: normal Hasn't seen an upstream release since 2006. Has portability problems to 64 bit platforms, and handling 64 bit integers in general. The idea (specification) and design is quite nice, but the implementation has slipped into obsolescence.
Bug#822088: RM: scsh-install-lib -- ROM; dependency being removed
Package: ftp.debian.org Severity: normal scsh-0.6 is being removed, so this one serves no purpose anymore.
Bug#822087: RM: scsh-defaults -- ROM; dependency being removed
Package: ftp.debian.org Severity: normal scsh-0.6 is being removed, so this one serves no purpose anymore.
Bug#813104: units: µs and µsecond handled inconsistently
Package: units Version: 2.11-1 Severity: normal units handles "s" for second, "µ" for "micro" as is SI standard. But the combination of the two is not handled correctly. For example: $ units µg Definition: micro g = 1e-09 kg $ units µg ng * 1000 / 0.001 And: $ units ms ns * 100 / 1e-06 But: $ units µs ns conformability error 1e-06 1e-09 s By contrast: $ units µsecond ns * 1000 / 0.001 -- System Information: Debian Release: 8.3 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages units depends on: ii libc6 2.19-18+deb8u2 ii libreadline6 6.3-8+b3 Versions of packages units recommends: pn python:any units suggests no packages. -- no debconf information
Bug#410935: incorrect package description
On Mon, Feb 26, 2007 at 11:30:08AM -0600, John Hasler wrote: >> The package description says that the conversion from Fahrenheit to >> Celsius is "nonlinear". > This is the terminology used upstream. It may not be pedantically correct, > but I think people will know what we mean. How about we replace "not linear" by "not proportional"? -- Lionel
Bug#783029: maintainer change (was: Please use a maintained soap library instead of deprecated python-suds)
On Thu, Jan 21, 2016 at 05:58:58PM +0800, Thomas Goirand wrote: > Gentle ping? > We're now 6 months later after the last entry of this discussion, and > nothing has been done so far. Yet, there's some activity on the > suds-jurko fork: > https://bitbucket.org/jurko/suds/commits/all > So, please go ahead and do something for the Python 3. If you don't, > then please orphan the suds package and let someone else take over the > maintenance (I'm volunteering). > In the event nothing was done in the next following weeks, and with no > reply on this bug tracker entry, I'll take over the maintenance myself > and package suds-jurko as a drop-in replacement for suds. Nolo contendere, which I'm not in a position to do anyway. -- Lionel
Bug#811079: RM: xchat-guile -- ROM; plugin for to-be-removed package
Package: ftp.debian.org Severity: normal Since: * xchat is slated for removal * xchat-guile is a plug-in for it * The xchat-guile upstream is not active, so a port to hexchat is probably not going to happen. (I'm not using it anymore, so also not going to do the port.) Please remove xchat-guile.
Bug#791491: lives: Crashes on startup
Package: lives Followup-For: Bug #791491 This looks similar to upstream bug https://sourceforge.net/p/lives/bugs/205/ If it is, in fact, the same, then it it is fixed upstream. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages lives depends on: ii frei0r-plugins1.4-3+b1 ii imagemagick 8:6.8.9.9-5 ii libasound21.0.28-1 ii libatk1.0-0 2.18.0-1 ii libavc1394-0 0.5.4-2 ii libavutil-ffmpeg547:2.8.2-1 ii libc6 2.19-18+deb8u1 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-02.31.1-2+deb8u3 ii libglib2.0-0 2.46.2-1 ii libgtk-3-03.18.5-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libmjpegutils-2.1-0 1:2.1.0+debian-3 ii libpango-1.0-01.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii libpng12-01.2.50-2+deb8u1 ii libpulse0 5.0-13 ii libraw1394-11 2.1.0-3 ii libswscale-ffmpeg37:2.8.2-1 ii libunicap20.9.12-2 ii libweed0 2.4.0~ds0-1+b1 ii libx11-6 2:1.6.2-3 ii lives-data2.4.0~ds0-1 ii lives-plugins 2.4.0~ds0-1+b1 ii mplayer2 [mplayer]2.0-728-g2c378c7-4+b1 ii ogmtools 1:1.5-3+b1 ii perl 5.20.2-3+deb8u1 ii procps2:3.3.9-9 ii python2.7.9-1 ii sox 14.4.1-5 Versions of packages lives recommends: ii dvgrab 3.5-2+b2 ii icedax 9:1.1.11-3 ii libogg01.3.2-1 ii libtheora-bin 1.1.1+dfsg.1-6 ii libtheora0 1.1.1+dfsg.1-7 ii mencoder 2:1.2-1 ii mkvtoolnix 8.5.2-1 ii pulseaudio 5.0-13 ii x11-utils 7.7+2 ii youtube-dl 2015.11.10-1 Versions of packages lives suggests: ii libdv-bin 1.0.0-6 ii mjpegtools 1:2.1.0+debian-3 -- no debconf information
Bug#810876: lives: watch file points to non-existing (outdated?) location
Package: lives Version: 2.4.0~ds0-1+b1 Severity: normal The watch file points to http://www.xs4all.nl/%7Esalsaman/lives/current/ but that doesn't exit (anymore). Download location is (now) http://lives-video.com/index.php?do=downloads -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages lives depends on: ii frei0r-plugins1.4-3+b1 ii imagemagick 8:6.8.9.9-5 ii libasound21.0.28-1 ii libatk1.0-0 2.18.0-1 ii libavc1394-0 0.5.4-2 ii libavutil-ffmpeg547:2.8.2-1 ii libc6 2.19-18+deb8u1 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-02.31.1-2+deb8u3 ii libglib2.0-0 2.46.2-1 ii libgtk-3-03.18.5-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libmjpegutils-2.1-0 1:2.1.0+debian-3 ii libpango-1.0-01.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii libpng12-01.2.50-2+deb8u1 ii libpulse0 5.0-13 ii libraw1394-11 2.1.0-3 ii libswscale-ffmpeg37:2.8.2-1 ii libunicap20.9.12-2 ii libweed0 2.4.0~ds0-1+b1 ii libx11-6 2:1.6.2-3 ii lives-data2.4.0~ds0-1 ii lives-plugins 2.4.0~ds0-1+b1 ii mplayer2 [mplayer]2.0-728-g2c378c7-4+b1 ii ogmtools 1:1.5-3+b1 ii perl 5.20.2-3+deb8u1 ii procps2:3.3.9-9 ii python2.7.9-1 ii sox 14.4.1-5 Versions of packages lives recommends: ii dvgrab 3.5-2+b2 ii icedax 9:1.1.11-3 ii libogg01.3.2-1 ii libtheora-bin 1.1.1+dfsg.1-6 ii libtheora0 1.1.1+dfsg.1-7 ii mencoder 2:1.2-1 ii mkvtoolnix 8.5.2-1 ii pulseaudio 5.0-13 ii x11-utils 7.7+2 ii youtube-dl 2015.11.10-1 Versions of packages lives suggests: ii libdv-bin 1.0.0-6 ii mjpegtools 1:2.1.0+debian-3 -- no debconf information
Bug#810874: lives: new upstream version
Package: lives Version: 2.4.0~ds0-1+b1 Severity: wishlist Over the last few months, several new upstream version have come out. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages lives depends on: ii frei0r-plugins1.4-3+b1 ii imagemagick 8:6.8.9.9-5 ii libasound21.0.28-1 ii libatk1.0-0 2.18.0-1 ii libavc1394-0 0.5.4-2 ii libavutil-ffmpeg547:2.8.2-1 ii libc6 2.19-18+deb8u1 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-02.31.1-2+deb8u3 ii libglib2.0-0 2.46.2-1 ii libgtk-3-03.18.5-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libmjpegutils-2.1-0 1:2.1.0+debian-3 ii libpango-1.0-01.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii libpng12-01.2.50-2+deb8u1 ii libpulse0 5.0-13 ii libraw1394-11 2.1.0-3 ii libswscale-ffmpeg37:2.8.2-1 ii libunicap20.9.12-2 ii libweed0 2.4.0~ds0-1+b1 ii libx11-6 2:1.6.2-3 ii lives-data2.4.0~ds0-1 ii lives-plugins 2.4.0~ds0-1+b1 ii mplayer2 [mplayer]2.0-728-g2c378c7-4+b1 ii ogmtools 1:1.5-3+b1 ii perl 5.20.2-3+deb8u1 ii procps2:3.3.9-9 ii python2.7.9-1 ii sox 14.4.1-5 Versions of packages lives recommends: ii dvgrab 3.5-2+b2 ii icedax 9:1.1.11-3 ii libogg01.3.2-1 ii libtheora-bin 1.1.1+dfsg.1-6 ii libtheora0 1.1.1+dfsg.1-7 ii mencoder 2:1.2-1 ii mkvtoolnix 8.5.2-1 ii pulseaudio 5.0-13 ii x11-utils 7.7+2 ii youtube-dl 2015.11.10-1 Versions of packages lives suggests: ii libdv-bin 1.0.0-6 ii mjpegtools 1:2.1.0+debian-3 -- no debconf information
Bug#810146: lives: encoding fails because empty audio wav file beyond some specific length
Package: lives Version: 2.4.0~ds0-1+b1 Severity: normal Some of my clips fail to encode (with the x264 encoder) because the generated audiodump.wav is empty (44 bytes long, which I expect is the wav header, no actual data). I've traced that to smogrify being called with a negative value for "end of audio". For example with arguments: save 483408242 25.000 /home/master/Videos/FOO.mp4 1 54931 44100 2 16 1 0. -1698.4000 I first thought of an integer overflow, because: - a clip of 1200 seconds works - a clip of 2197.24 seconds fails So I thought maybe overflow at 2048 (11 bits?), but then I tried a clip of 2000 seconds, and then smogrify is called with: save 927025633 25.000 /home/master/Videos/FOO.mp4 1 5 0 0 0 1 -nan -nan This seems to be linked to the end of the to-be-encoded selection audio being more than some specific value of seconds after the beginning of the clip seconds... Further observations: - 1800s works - 1920s works - 1999.96s doesn't work - 1999s doesn't work - 1998.96s doesn't work - 1997.28s doesn't work - 1960s doesn't work - 1940s works - 1950s doesn't work - 1946s works - 1948s doesn't work - 1947s works - 1947.40s works - 1947.80s doesn't work - 1947.60s works - 1947.68s works - 1947.76s works And that's it... 1947.80s is 48695 frames and 1947.76s is 48694 frames. That's where the overflow/NaN starts to happen. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages lives depends on: ii frei0r-plugins1.4-3+b1 ii imagemagick 8:6.8.9.9-5 ii libasound21.0.28-1 ii libatk1.0-0 2.18.0-1 ii libavc1394-0 0.5.4-2 ii libavutil-ffmpeg547:2.8.2-1 ii libc6 2.19-18+deb8u1 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libgdk-pixbuf2.0-02.31.1-2+deb8u3 ii libglib2.0-0 2.46.2-1 ii libgtk-3-03.18.5-1 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-2 ii libmjpegutils-2.1-0 1:2.1.0+debian-3 ii libpango-1.0-01.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii libpng12-01.2.50-2+deb8u1 ii libpulse0 5.0-13 ii libraw1394-11 2.1.0-3 ii libswscale-ffmpeg37:2.8.2-1 ii libunicap20.9.12-2 ii libweed0 2.4.0~ds0-1+b1 ii libx11-6 2:1.6.2-3 ii lives-data2.4.0~ds0-1 ii lives-plugins 2.4.0~ds0-1+b1 ii mplayer2 [mplayer]2.0-728-g2c378c7-4+b1 ii ogmtools 1:1.5-3+b1 ii perl 5.20.2-3+deb8u1 ii procps2:3.3.9-9 ii python2.7.9-1 ii sox 14.4.1-5 Versions of packages lives recommends: ii dvgrab 3.5-2+b2 ii icedax 9:1.1.11-3 ii libogg01.3.2-1 ii libtheora-bin 1.1.1+dfsg.1-6 ii libtheora0 1.1.1+dfsg.1-7 ii mencoder 2:1.2-1 ii mkvtoolnix 8.5.2-1 ii pulseaudio 5.0-13 ii x11-utils 7.7+2 ii youtube-dl 2015.11.10-1 Versions of packages lives suggests: ii libdv-bin 1.0.0-6 ii mjpegtools 1:2.1.0+debian-3 -- no debconf information
Bug#803316: python-stdnum: new feature eu.vat.check_vies does not work
Package: python-stdnum Version: 1.2-1 Severity: normal $ python Python 2.7.9 (default, Mar 1 2015, 12:57:24) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import stdnum.eu.vat >>> stdnum.eu.vat.check_vies_approx('BE555445','BE87785') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/stdnum/eu/vat.py", line 157, in check_vies_approx return _get_client.checkVatApprox( AttributeError: 'function' object has no attribute 'checkVatApprox' -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.utf8, LC_CTYPE=fr_LU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-stdnum depends on: ii python-pkg-resources 5.5.1-1 pn python:any python-stdnum recommends no packages. Versions of packages python-stdnum suggests: ii python-suds-jurko [python-suds] 0.6-1 -- no debconf information
Bug#803316: python-stdnum: new feature eu.vat.check_vies does not work
tags 803316 +patch thanks here's a patch On Wed, Oct 28, 2015 at 06:19:26PM +0100, Lionel Elie Mamane wrote: > $ python > Python 2.7.9 (default, Mar 1 2015, 12:57:24) > [GCC 4.9.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import stdnum.eu.vat > >>> stdnum.eu.vat.check_vies_approx('BE555445','BE87785') > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/dist-packages/stdnum/eu/vat.py", line 157, in > check_vies_approx > return _get_client.checkVatApprox( > AttributeError: 'function' object has no attribute 'checkVatApprox' --- /usr/lib/python2.7/dist-packages/stdnum/eu/vat.py~ 2015-10-11 11:18:46.0 +0200 +++ /usr/lib/python2.7/dist-packages/stdnum/eu/vat.py 2015-10-28 18:24:14.451553932 +0100 @@ -154,6 +154,6 @@ # network access for the tests and unnecessarily load the VIES website number = compact(number) requester = compact(requester) -return _get_client.checkVatApprox( +return _get_client().checkVatApprox( countryCode=number[:2], vatNumber=number[2:], requesterCountryCode=requester[:2], requesterVatNumber=requester[2:])
Bug#798936: youtube-dl: Expect ffmpeg version numbers, rather than libav
On Mon, Sep 14, 2015 at 11:36:00AM +0200, Ralf Jung wrote: > When downloading a video from YouTube, youtube-dl complains > WARNING: Your copy of avconv is outdated and unable to properly mux > separate video and audio files, > youtube-dl will download single file media. Update avconv to version 10-0 > or newer to fix this. > "Version 10-0 or newer" does not exist since Debian switched back to > ffmpeg. Use "youtube-dl --prefer-ffmpeg". Maintainer: I suggest to make that the default on Debian. -- Lionel
Bug#602649: upstream WONTFIX
It looks like this bug / feature request will "never" be implemented upstream... The chromium rendering engine *removed* support, webkit itself (apparently the source of the feature) followed suit, ... https://bugs.webkit.org/show_bug.cgi?id=127874 -- Lionel
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Here is my patch ported to cups 2.1.0-4. I reproduced the bug with unpatched 2.1.0-4. On Mon, Apr 27, 2015 at 03:44:06PM +0200, Lionel Elie Mamane wrote: > Ping? I still patch my cups (1.7.5-11) locally with the attached > patch, and this bug is still reproduced with unpatched 1.7.5-11. > > Any progress on this? > > For reminder, the problem is that when (a program using) libcupsys2 > wants to retrieve the PPD for a printer whose device URI is > "ipp://something", libcupsys2 tries to connect to the device URI > instead of to the cups server. This makes sense when the device URI is > actually another CUPS server, but *not* when, as in my case, it is a > network-attached printer that "talks" IPP natively. It will *not* have > the PPD at the CUPS-specific URL. > > On Tue, Jul 01, 2014 at 04:24:58PM +0200, Lionel Elie Mamane wrote: > > Control: unarchive -1 > > Control: found -1 1.7.2-3 > > Control: found -1 1.7.3-6 > > Control: notfixed -1 1.7.1-1 > > Control: reopen -1 > > > > It seems the below test was mistaken. I had the problem again with > > 1.7.3-3, so I downgraded to 1.7.2-3, but I still get the problem. > > > > I think I had temporarily changed my printer to not use ipp:// but > > socket:// to work around the problem, and got confused in my > > tests... This bug is *not* fixed. > > > > On Tue, May 13, 2014 at 04:55:52PM +0200, Lionel Elie Mamane wrote: > > > Control: tags -1 -moreinfo > > > > > > On Sun, Jan 05, 2014 at 12:45:10PM +0100, Didier 'OdyX' Raboud wrote: > > > > > > > thanks for your detailed bugreports and proposed patch. > > > > > > > Le dimanche, 5 janvier 2014, 01.44:37 Wolfgang Walter a écrit : > > > >> We modified libcups in the same way as Lionel. I don't know why this > > > >> has been changed from 1.5 to 1.6 but it seems buggy. Most > > > >> ipp-printers don't provide a PPD. And even if the do there is no > > > >> guarantie the client is allowed to communicate directly with the > > > >> printer. > > > > > > > Lionel & Wolfgang: can you try to rebuild and try unstable's cups > > > > (1.7.0-2) without the get-ppd-file-for-statically-configured-ipp-shared- > > > > queues patch and report back if this works as expected? > > > > > > I upgraded to cups 1.7.2-3, which does not anymore have > > > get-ppd-file-for-statically-configured-ipp-shared-queues, and it works > > > as expected. > > > > Index: cups-1.7.5/cups/util.c > === > --- cups-1.7.5.orig/cups/util.c > +++ cups-1.7.5/cups/util.c > @@ -1718,6 +1718,7 @@ cups_get_printer_uri( > IPP_TAG_URI)) != NULL) >device_uri = attr->values[0].string.text; > > +#if 0 > if (device_uri && > (!strncmp(device_uri, "ipp://", 6) || > !strncmp(device_uri, "ipps://", 7) || > @@ -1738,7 +1739,9 @@ cups_get_printer_uri( > >return (1); > } > -else if ((attr = ippFindAttribute(response, "member-uris", > +else > +#endif > +if ((attr = ippFindAttribute(response, "member-uris", >IPP_TAG_URI)) != NULL) > { > /* Index: cups-2.1.0/cups/util.c === --- cups-2.1.0.orig/cups/util.c +++ cups-2.1.0/cups/util.c @@ -1529,6 +1529,7 @@ cups_get_printer_uri( DEBUG_printf(("5cups_get_printer_uri: device-uri=\"%s\"", device_uri)); } +#if 0 if (device_uri && (!strncmp(device_uri, "ipp://", 6) || !strncmp(device_uri, "ipps://", 7) || @@ -1546,7 +1547,9 @@ cups_get_printer_uri( DEBUG_printf(("5cups_get_printer_uri: Resolved to host=\"%s\", port=%d, resource=\"%s\"", host, *port, resource)); return (1); } -else if ((attr = ippFindAttribute(response, "member-uris", IPP_TAG_URI)) != NULL) +else +#endif +if ((attr = ippFindAttribute(response, "member-uris", IPP_TAG_URI)) != NULL) { /* * Get the first actual printer name in the class...
Bug#798763: vlc: segfault if vlc and libvlc5/libvlccore8/vlc-data out of sync
On Sun, Sep 13, 2015 at 01:33:51PM +0200, Sebastian Ramacher wrote: > Control: severity -1 normal > Control: tags -1 + moreinfo unreproducible > > On 2015-09-12 13:21:58, Lionel Elie Mamane wrote: >> after upgrade, vlc started segfaulting on startup. This was solved by: >> [UPGRADE] libvlc5:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 >> [UPGRADE] libvlccore8:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 >> [UPGRADE] vlc-data:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 >> [UPGRADE] vlc-plugin-pulse:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 > I am unable to reproduce the issue. I've installed vlc, vlc-plugin-pulse and > vlc-plugin-sambda in jessie, marked vlc-data, vlc-plugin-pulse, libvlc5 and > libvlccore5 as hold and upgraded to unstable. > Please provide the output of vlc -vvv until the crash and a backtrace > including > symbols (by installing vlc-dbg and liblua5.2-0-dbg). Downgrading only libvlc5 was not enough to reproduce, and downgrading libblccore8 forced me to downgrade also vlc-data and vlc-plugin-pulse. vlc -vvv output attached. I installed vlc-dbg version 2.2.1-3 (not 2.2.0~rc2-2+deb8u1) since that's the one the dependencies let me install. Here is the backtrace: (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:106 #1 0x704e6954 in luaS_new (L=L@entry=0x70ca90, str=0x7200656d ) at lstring.c:171 #2 0x704d961f in lua_pushstring (L=L@entry=0x70ca90, s=) at lapi.c:522 #3 0x7071a90a in vlclua_input_metas_internal (p_item=, L=0x70ca90) at lua/libs/input.c:159 #4 vlclua_input_item_metas (L=0x70ca90) at lua/libs/input.c:297 #5 0x704ddc4d in luaD_precall (L=L@entry=0x70ca90, func=, func@entry=0x70cd90, nresults=nresults@entry=1) at ldo.c:319 #6 0x704e983d in luaV_execute (L=L@entry=0x70ca90) at lvm.c:709 #7 0x704ddf8e in luaD_call (L=0x70ca90, func=, nResults=, allowyield=) at ldo.c:402 #8 0x704dd5cf in luaD_rawrunprotected (L=L@entry=0x70ca90, f=f@entry=0x704d8b70 , ud=ud@entry=0x7fffdae0) at ldo.c:131 #9 0x704de1d1 in luaD_pcall (L=L@entry=0x70ca90, func=func@entry=0x704d8b70 , u=u@entry=0x7fffdae0, old_top=32, ef=) at ldo.c:603 #10 0x704da0f1 in lua_pcallk (L=L@entry=0x70ca90, nargs=nargs@entry=0, nresults=nresults@entry=1, errfunc=errfunc@entry=0, ctx=ctx@entry=0, k=k@entry=0x0) at lapi.c:949 #11 0x707110d3 in run (p_context=0x0, luafunction=0x7072563c "read_meta", L=0x70ca90, psz_filename=0x70c870 "/usr/lib/vlc/lua/meta/reader/filename.luac", p_this=0x703218) at lua/meta.c:128 #12 read_meta (p_this=0x703218, psz_filename=0x70c870 "/usr/lib/vlc/lua/meta/reader/filename.luac", p_context=) at lua/meta.c:213 #13 0x70713880 in vlclua_scripts_batch_execute (p_this=0x703218, luadirname=, func=0x70711010 , user_data=0x0) at lua/vlc.c:299 #14 0x7717bee5 in ?? () from /usr/lib/libvlccore.so.8 #15 0x7717c4ae in vlc_module_load () from /usr/lib/libvlccore.so.8 #16 0x7713fca3 in ?? () from /usr/lib/libvlccore.so.8 #17 0x77142604 in ?? () from /usr/lib/libvlccore.so.8 #18 0x7714673d in input_Read () from /usr/lib/libvlccore.so.8 #19 0x7711c775 in ?? () from /usr/lib/libvlccore.so.8 #20 0x77117af8 in ?? () from /usr/lib/libvlccore.so.8 #21 0x77113838 in libvlc_InternalAddIntf () from /usr/lib/libvlccore.so.8 #22 0x77bc345c in libvlc_add_intf () from /usr/lib/libvlc.so.5 #23 0x004012c2 in main (i_argc=, ppsz_argv=) at vlc.c:237 -- Lionel [0067b058] core libvlc debug: VLC media player - 2.2.0-rc2 Weatherwax [0067b058] core libvlc debug: Copyright © 1996-2014 the VideoLAN team [0067b058] core libvlc debug: revision 2.2.0-rc1-118-g22fda39 [0067b058] core libvlc debug: configured with ./configure '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--localstatedir=/var' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-dependency-tracking' '--build=x86_64-linux-gnu' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-z,relro' '--config-cache' '--disable-maintainer-mode' '--disable-silent-rules' '--disable-update-check' '--enable-fast-install' '--prefix=/usr' '--docdir=/usr/share/doc/vlc-nox' '--libdir=/usr/lib' '--sysconfdir=/etc' '--with-binary-version=2+deb8u1' '--enable-a52' '--enable-aa' '--enable-bluray' '--enable-bonjour' '--enable-caca' '--enable-chromaprint' '--enable-dbus' '--enable-dca' '--enable-directfb' '--enable-dvbpsi' '--enable-dvdnav' '--enable-faad' '--enable-flac' '--enable-fluidsynth' '--enable-freerdp' '--enable-freetype' '--enable-fribidi' '--enable-gles1' '--enable-gles2' '--enable-glx' '--enable-gnutls' '--enable-jack' '--enable-kate' '--enable-libass' '--enable-libmpeg2' '--enable-libxml2' '--enable-lirc' '--enable-
Bug#798763: vlc: segfault if vlc and libvlc5/libvlccore8/vlc-data out of sync
Package: vlc Version: 2.2.1-3 Severity: serious Justification: Policy 3.5 after upgrade, vlc started segfaulting on startup. This was solved by: [UPGRADE] libvlc5:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 [UPGRADE] libvlccore8:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 [UPGRADE] vlc-data:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 [UPGRADE] vlc-plugin-pulse:amd64 2.2.0~rc2-2+deb8u1 -> 2.2.1-3 which suggests that dependency on at least one of these packages is too lax (should be more strictly versioned). here's the backtrace for reference (without symbols) (gdb) bt #0 strlen () at ../sysdeps/x86_64/strlen.S:106 #1 0x7fb7fdb24954 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #2 0x7fb7fdb1761f in lua_pushstring () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #3 0x7fb7fdd5890a in ?? () from /usr/lib/vlc/plugins/lua/liblua_plugin.so #4 0x7fb7fdb1bc4d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #5 0x7fb7fdb2783d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #6 0x7fb7fdb1bf8e in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #7 0x7fb7fdb1b5cf in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #8 0x7fb7fdb1c1d1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #9 0x7fb7fdb180f1 in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 #10 0x7fb7fdd4f0d3 in ?? () from /usr/lib/vlc/plugins/lua/liblua_plugin.so #11 0x7fb7fdd51880 in ?? () from /usr/lib/vlc/plugins/lua/liblua_plugin.so #12 0x7fb8047b9ee5 in ?? () from /usr/lib/libvlccore.so.8 #13 0x7fb8047ba4ae in vlc_module_load () from /usr/lib/libvlccore.so.8 #14 0x7fb80477dca3 in ?? () from /usr/lib/libvlccore.so.8 #15 0x7fb804780604 in ?? () from /usr/lib/libvlccore.so.8 #16 0x7fb80478473d in input_Read () from /usr/lib/libvlccore.so.8 #17 0x7fb80475a775 in ?? () from /usr/lib/libvlccore.so.8 #18 0x7fb804755af8 in ?? () from /usr/lib/libvlccore.so.8 #19 0x7fb804751838 in libvlc_InternalAddIntf () from /usr/lib/libvlccore.so.8 #20 0x7fb80520145c in libvlc_add_intf () from /usr/lib/libvlc.so.5 #21 0x004012c2 in ?? () #22 0x7fb804a50b45 in __libc_start_main (main=0x4010f0, argc=1, argv=0x7fff440fef88, init=, fini=, rtld_fini=, stack_end=0x7fff440fef78) at libc-start.c:287 #23 0x004014bc in ?? () -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages vlc depends on: ii fonts-freefont-ttf 20120503-4 ii libaa1 1.4p5-43 ii libavcodec-ffmpeg56 7:2.7.2-2+b1 ii libavutil-ffmpeg54 7:2.7.2-2+b1 ii libc6 2.19-18+deb8u1 ii libcaca00.99.beta19-2 ii libcairo2 1.14.0-2.1 ii libegl1-mesa [libegl1-x11] 10.3.2-1+deb8u1 ii libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-4 ii libfreerdp-core1.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libfreerdp-gdi1.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libfreetype62.5.2-3 ii libfribidi0 0.19.6-3 ii libgcc1 1:5.2.1-16 ii libgl1-mesa-glx [libgl1]10.3.2-1+deb8u1 ii libgles1-mesa [libgles1]10.3.2-1+deb8u1 ii libgles2-mesa [libgles2]10.3.2-1+deb8u1 ii libglib2.0-02.44.1-1.1 ii libpulse0 5.0-13 ii libqt5core5a5.4.2+dfsg-9 ii libqt5gui5 5.4.2+dfsg-9 ii libqt5widgets5 5.4.2+dfsg-9 ii libqt5x11extras55.3.2-2 ii librsvg2-2 2.40.5-1 ii libsdl-image1.2 1.2.12-5+b5 ii libsdl1.2debian 1.2.15-10+b1 ii libstdc++6 5.2.1-16 ii libva-drm1 1.4.1-1 ii libva-x11-1 1.4.1-1 ii libva1 1.4.1-1 ii libvlccore8 2.2.1-3 ii libvncclient1 0.9.10+dfsg-3 ii libx11-62:1.6.2-3 ii libxcb-composite0 1.10-3+b1 ii libxcb-keysyms1 0.4.0-1 ii libxcb-randr0 1.10-3+b1 ii libxcb-shm0 1.10-3+b1 ii libxcb-xv0 1.10-3+b1 ii libxcb1 1.10-3+b1 ii libxext62:1.3.3-1 ii libxinerama12:1.1.3-1+b1 ii libxpm4 1:3.5.11-1+b1 ii vlc-nox 2.2.1-3 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages vlc recommends: ii vlc-plugin-notify 2.2.1-3 ii vlc-plugin-samba 2.2.1-3 ii xdg-utils 1.1.0~rc1+git20111210-7.4 Versions of packages vlc suggests: pn videolan-doc -- no debconf information
Bug#660691: [myspell-fr-gut] fr.aff file is buggy (forth column of PFX/SFX is too short)
Sorry it took so long to fix... Went into quasi-hibernation and stuff slid away. On Mon, Feb 20, 2012 at 11:56:32PM +0100, Bastien Montagne wrote: Le 20/02/2012 23:15, Lionel Elie Mamane a écrit : On Mon, Feb 20, 2012 at 10:45:08PM +0100, Bastien Montagne wrote: Package: myspell-fr-gut Version: 1:1.0-30 The fr.aff file of that package is buggy. The “replacement” column of PFX/SFX rules is too short, which leads to truncating long ones (eg. eyent\-ell instead of eyent\-elles…). eyentelles does not sound like a French word to me, but from context I expected it to be a word that should be recognised as correctly spelt, but is not. What do you mean? It won’t give eyentelles, but eyent-elles, like in asseyent-elles (verb, and pronoun subject after it, linked with a -). So it would e.g. recognize asseyent-ell (wrong!), but not asseyent-elles (good)... ;) Attached a fixed version of this file It seems to have been wrongfully coded by your MUA or recoded in transit. The MIME headers say it is us-ascii, but I expect it should be iso8859-15. Please resend, possibly protecting it against recoding by compressing it or putting it in a tarfile or some such. Also, patch is usually better than resending whole file :) Woops! Sorry! I did attached a latin-15 file, though… So, here is a compressed patch, should be fine this time! (but patch is bigger than whole file...) :)
Bug#678279: with newer X, keyboard input does not reset xscreensaver idle timer
On Tue, Jul 21, 2015 at 12:10:39AM +0200, Tormod Volden wrote: Since I upgraded a bunch of things (X, gtk, ...) xscreensaver sometimes locks my screen when I don't touch the mouse for a few minutes, even if I use the keyboard constantly. That's rather annoying, since at that moment I'm typically in the middle of typing a rather long text. Thanks for your bug report. Is this still a problem? Anyway lowering severity until it has been confirmed by others. Well, I switched to X Input Method, also for other bugs of, or linked to, Cedilla, so I wouldn't naturally encounter the bug anymore. I tried to reproduce now, but switching back to Cedilla (*locally* in *one* xfce4-terminal window, not the whole session) I couldn't. This might mean it is fixed, but also that: 1) It happens only when Cedilla is the default (no GTK_IM_MODULE envvar set), for the whole session 2) It happens with Gnome Terminal, but not with xfce4-terminal 3) Some other difference in how my setup has changed in three years make a difference. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788005: libfreerdp-plugins-standard: urbdrc-client.so missing (USB redirection)
Package: libfreerdp-plugins-standard Version: 1.1.0~git20140921.1.440916e+dfsg1-4 Severity: normal The client channel urbdrc, which is used for USB redirection is missing. $ xfreerdp /v:host /usb:id,dev:091e:260f Loading Dynamic Virtual Channel urbdrc LoadLibraryA: /usr/lib/x86_64-linux-gnu/freerdp/urbdrc-client.so: cannot open shared object file: No such file or directory -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: unable to detect Versions of packages libfreerdp-plugins-standard depends on: ii libasound2 1.0.28-1 ii libavcodec56 6:11.3-1+deb8u1 ii libavutil54 6:11.3-1+deb8u1 ii libc62.19-18 ii libcups2 1.7.5-11 ii libfreerdp-common1.1.0 1.1.0~git20140921.1.440916e+dfsg1-4 ii libfreerdp-utils1.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libglib2.0-0 2.42.1-1 ii libgstreamer-plugins-base0.10-0 0.10.36-2 ii libgstreamer0.10-0 0.10.36-1.5 ii libpcsclite1 1.8.13-1 ii libpulse05.0-13 ii libssl1.0.0 1.0.1k-3 ii libwinpr-crt0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-environment0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-file0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-handle0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-heap0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-interlocked0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-library0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-path0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-synch0.11.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-sysinfo0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-thread0.1 1.1.0~git20140921.1.440916e+dfsg1-4 ii libwinpr-utils0.11.1.0~git20140921.1.440916e+dfsg1-4 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxml2 2.9.1+dfsg1-5 ii libxrandr2 2:1.4.2-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 libfreerdp-plugins-standard recommends no packages. libfreerdp-plugins-standard suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788005: libfreerdp-plugins-standard: urbdrc-client.so missing (USB redirection)
tags 788005 +patch thanks On Sun, Jun 07, 2015 at 06:34:01PM +0200, Lionel Elie Mamane wrote: The client channel urbdrc, which is used for USB redirection is missing. $ xfreerdp /v:host /usb:id,dev:091e:260f Loading Dynamic Virtual Channel urbdrc LoadLibraryA: /usr/lib/x86_64-linux-gnu/freerdp/urbdrc-client.so: cannot open shared object file: No such file or directory Here's a patch that works for me, but is not tested in a chroot. Possible missing/incorrect builddeps: libusb-1.0-0-dev instead of libusb-dev libdbus-glib-1-dev -- Lionel diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog --- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog 2015-03-10 21:29:17.0 +0100 +++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/changelog 2015-06-07 18:24:22.0 +0200 @@ -1,3 +1,9 @@ +freerdp (1.1.0~git20140921.1.440916e+dfsg1-4.0) unstable; urgency=medium + + * Enable URBDRC (USB redirection) channel + + -- Lionel Elie Mamane lmam...@debian.org Sun, 07 Jun 2015 18:24:22 +0200 + freerdp (1.1.0~git20140921.1.440916e+dfsg1-4) unstable; urgency=medium * debian/patches: diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/control freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/control --- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/control 2014-10-07 10:06:28.0 +0200 +++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/control 2015-06-07 18:27:13.0 +0200 @@ -29,6 +29,8 @@ libavcodec-dev, libxi-dev, libgstreamer-plugins-base0.10-dev, + libusb-dev, + uuid-dev Standards-Version: 3.9.5 Homepage: http://www.freerdp.com/ Vcs-Browser: http://anonscm.debian.org/gitweb?p=collab-maint/freerdp.git diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/libusb_debug freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/libusb_debug --- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/libusb_debug 1970-01-01 01:00:00.0 +0100 +++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/libusb_debug 2015-06-07 19:03:53.0 +0200 @@ -0,0 +1,12 @@ +Description: fixup libusb subchannel to use libusb_debug, not urbdrc_debug +--- freerdp-1.1.0~git20140921.1.440916e+dfsg1.orig/channels/urbdrc/client/libusb/libusb_udevman.c freerdp-1.1.0~git20140921.1.440916e+dfsg1/channels/urbdrc/client/libusb/libusb_udevman.c +@@ -550,7 +550,7 @@ static void urbdrc_udevman_parse_addin_a + + CommandLineSwitchCase(arg, dbg) + { +- urbdrc_debug = 0; ++ libusb_debug = 0; + } + CommandLineSwitchCase(arg, dev) + { diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/series freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/series --- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/series 2015-03-10 21:20:50.0 +0100 +++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/patches/series 2015-06-07 19:02:16.0 +0200 @@ -10,3 +10,4 @@ 0001_fix-cmdline-parser.patch 0002_handle-old-style-cmdline-options.patch 0003_copy-data-when-adding-glyph-to-cache.patch +libusb_debug diff -Nru freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/rules freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/rules --- freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/rules 2014-09-22 21:58:42.0 +0200 +++ freerdp-1.1.0~git20140921.1.440916e+dfsg1/debian/rules 2015-06-07 18:19:51.0 +0200 @@ -32,6 +32,7 @@ -DWITH_CUPS=on \ -DWITH_PCSC=on \ -DWITH_JPEG=on \ + -DCHANNEL_URBDRC_CLIENT=on $(ARM_FLOAT_ABI) \ $(NULL)
Bug#774948: [tryton-debian][py3porters-devel] Packaging of suds-jurko
On Mon, Jun 01, 2015 at 10:24:57AM +0200, Mathias Behrle wrote: * Mathias Behrle: [tryton-debian] Bug#783029: Bug#783029: [py3porters-devel] Packaging of suds-jurko (Wed, 29 Apr 2015 11:46:01 +0200): * Lionel Elie Mamane: Re: [tryton-debian] Bug#783029: [py3porters-devel] Packaging of suds-jurko (Tue, 28 Apr 2015 16:32:23 +0200): On Tue, Apr 28, 2015 at 03:27:12PM +0200, Mathias Behrle wrote: * Lionel Elie Mamane: [tryton-debian] suds in Debian (Tue, 28 Apr 2015 13:24:25 +0200): I just uploaded the jurko fork of suds (the latter you are maintainer of in Debian) to Debian. The killer feature for me was compatibility with Python 3. It installs as python module suds, for drop-in replacement of suds. The killer feature of suds-jurko those days may turn out to be that it tends to be as unmaintained as the original suds. sigh Time has passed and re-evaluating suds-jurko still shows no maintainer activity. I don't get feedback on mails written directly to Jurko neither there is action on patches or development on the bitbucket project. So my personal decision is to not use suds-jurko as a drop-in for suds. Further action now depends on your answer, Lionel: Do you still want to maintain a suds-jurko package in Debian? I'm not going to turn into a new upstream for suds-jurko. Maintaining a package without an upstream is never very attractive. So let's say no. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774948: [tryton-debian] Bug#783029: [py3porters-devel] Packaging of suds-jurko
On Wed, Apr 29, 2015 at 11:46:01AM +0200, Mathias Behrle wrote: * Lionel Elie Mamane: Re: [tryton-debian] Bug#783029: [py3porters-devel] Packaging of suds-jurko (Tue, 28 Apr 2015 16:32:23 +0200): On Tue, Apr 28, 2015 at 03:27:12PM +0200, Mathias Behrle wrote: * Lionel Elie Mamane: [tryton-debian] suds in Debian (Tue, 28 Apr 2015 13:24:25 +0200): I just uploaded the jurko fork of suds (the latter you are maintainer of in Debian) to Debian. I am quite surprised to hear that. Your package even doesn't seem to close an ITP bug. Could you please provide the link to your packaging sources? https://people.debian.org/~lmamane/suds/ You don't have permission to access /~lmamane/suds/suds-jurko_0.6-2.dsc on this server. Fixed. Sorry, coordinating before uploading to NEW would have been much more appropriate, (...). Before commenting further I would like to hear about your motivations: My motivation is purely having a working suds for Python3 so that I can use stdnum.eu.vat.check_vies in Python3 (see https://bugs.debian.org/774948 ). If my work is useful to others, then I'm happy to share it, if not I'll keep it is a local package for me. Since you seem to have good not-too-long-term plans, I'm happy if we ask ftpmaster to reject my upload to make way for your plans. The current state is: - pysimplesoap[0] seems to be a promising and maintained project. I think - provided pysimplesoap qualifies as a replacement for suds It seems to present a different API, though? (...) I ask you indeed to wait with your package (i.e. to ask ftp-masters to not consider it for the moment). I just asked them to reject it. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783029: [tryton-debian] Bug#783029: [py3porters-devel] Packaging of suds-jurko
On Tue, Apr 28, 2015 at 04:32:23PM +0200, Lionel Elie Mamane wrote: On Tue, Apr 28, 2015 at 03:27:12PM +0200, Mathias Behrle wrote: * Lionel Elie Mamane: [tryton-debian] suds in Debian (Tue, 28 Apr 2015 13:24:25 +0200): I just uploaded the jurko fork of suds (the latter you are maintainer of in Debian) to Debian. Before commenting further I would like to hear about your motivations: My motivation is purely having a working suds for Python3 so that I can use stdnum.eu.vat.check_vies in Python3 (see https://bugs.debian.org/774948 ). If my work is useful to others, then I'm happy to share it, if not I'll keep it is a local package for me. I mean: if not, I'll keep it is a local package for me in the immediate future and happily switch back to your suds-in-Debian when it works with Python3. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783029: [tryton-debian] Bug#783029: [py3porters-devel] Packaging of suds-jurko
On Tue, Apr 28, 2015 at 03:27:12PM +0200, Mathias Behrle wrote: * Lionel Elie Mamane: [tryton-debian] suds in Debian (Tue, 28 Apr 2015 13:24:25 +0200): I just uploaded the jurko fork of suds (the latter you are maintainer of in Debian) to Debian. I am quite surprised to hear that. Your package even doesn't seem to close an ITP bug. Could you please provide the link to your packaging sources? https://people.debian.org/~lmamane/suds/ The killer feature for me was compatibility with Python 3. It installs as python module suds, for drop-in replacement of suds. The killer feature of suds-jurko those days may turn out to be that it tends to be as unmaintained as the original suds. sigh For now, the Python2 package of suds-jurko provides and conflicts with python-suds (your package). Let me know whether you think something more soft, like e.g. collaborating through update-alternatives, would be more appropriate. Sorry, coordinating before uploading to NEW would have been much more appropriate, (...). Before commenting further I would like to hear about your motivations: My motivation is purely having a working suds for Python3 so that I can use stdnum.eu.vat.check_vies in Python3 (see https://bugs.debian.org/774948 ). If my work is useful to others, then I'm happy to share it, if not I'll keep it is a local package for me. - Are you aware of the work in progress at [1]? No. - Are you aware of the planning to prepare suds-jurko as a drop-in replacement for suds with coordinating to migrate also the project at pypi [2][3]? No. Since you seem to have good not-too-long-term plans, I'm happy if we ask ftpmaster to reject my upload to make way for your plans. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774948: python3-stdnum: stdnum.eu.vat.check_vies needs suds
On Tue, Apr 28, 2015 at 11:14:32AM +0200, Lionel Elie Mamane wrote: On Fri, Apr 17, 2015 at 02:43:11PM +0200, Arthur de Jong wrote: On Fri, 2015-01-09 at 12:40 +0100, Lionel Elie Mamane wrote: ImportError: No module named 'suds' An Internet search suggests suds itself is not available for Python3, but there seems to be several forks that are. From the SOAP libraries available in Debian it seemed that SUDS was the easiest to use. From a quick search I can't find any Python SOAP library for Python3. If they are not in Debian, at least one needs to be added to Debian ;-) Using one of the forks of suds for Python 3 would probably be the least work as far as stdnum is concerned. https://pypi.python.org/pypi/suds-py3/ https://pypi.python.org/pypi/suds-jurko/ I just uploaded suds-jurko to Debian. When it is accepted, I suppose this bug becomes fixed. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783644: python-stdnum: new feature: EU VAT VIES check _with_ proof (certificate)
On Tue, Apr 28, 2015 at 10:53:17PM +0200, Arthur de Jong wrote: On Tue, 2015-04-28 at 19:09 +0200, Lionel Elie Mamane wrote: Please add a new function to stdnum.eu.vat so that when one does a VIES VAT number check, one gets a proof (certificate) that one did the check, as defence against the VAT administration later putting this in doubt. This certificate is provided by the VIES service, if one provides one's own VAT number. Thanks for the patch. What do you think about combining it in one function (see attachment)? There was no attachment to your email. The returned tuple is a bit different: name - traderName address - traderAddress I'm not eager for a single function to return differently structured data depending on an argument that does not look like it should influence this part of the structure. Having two functions emphasises the difference.. I would like to include this upstream. Yes, that's the end goal obviously :) -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783644: python-stdnum: new feature: EU VAT VIES check _with_ proof (certificate)
Package: python-stdnum Version: 1.0-1.0 Severity: wishlist Tags: patch Please add a new function to stdnum.eu.vat so that when one does a VIES VAT number check, one gets a proof (certificate) that one did the check, as defence against the VAT administration later putting this in doubt. This certificate is provided by the VIES service, if one provides one's own VAT number. Compare: stdnum.eu.vat.check_vies('BEXX') (reply){ countryCode = BE vatNumber = XXX requestDate = 2015-04-28 valid = True name = SPRL FAFA address = RUE DE FAFA 18 6000 NAMUR } and stdnum.eu.vat.check_vies_certificate('BEXXX', 'LUXX') (reply){ countryCode = BE vatNumber = requestDate = 2015-04-28 valid = True traderName = SPRL FAFA traderCompanyType = --- traderAddress = RUE DE FAFA 18 6000 NAMUR requestIdentifier = WAPIU0A9f1Hu } The requestIdentifier is the proof certificate. Patch attached. Thanks, Lionel -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (600, 'testing-updates'), (600, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.utf8, LC_CTYPE=fr_LU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-stdnum depends on: ii python2.7.9-1 ii python-pkg-resources 5.5.1-1 python-stdnum recommends no packages. Versions of packages python-stdnum suggests: ii python-suds-jurko [python-suds] 0.6-1 -- no debconf information diff -Nru python-stdnum-1.0/debian/changelog python-stdnum-1.0/debian/changelog --- python-stdnum-1.0/debian/changelog 2014-10-19 23:46:28.0 +0200 +++ python-stdnum-1.0/debian/changelog 2015-04-28 15:44:16.0 +0200 @@ -1,3 +1,10 @@ +python-stdnum (1.0-1.0) unstable; urgency=medium + + * Local fork (call it NMU to keep lintian happy) +- New feature: add stdnum.eu.vat.check_vies_certificate + + -- Lionel Elie Mamane lmam...@debian.org Tue, 28 Apr 2015 15:44:16 +0200 + python-stdnum (1.0-1) unstable; urgency=medium * New upstream release: diff -Nru python-stdnum-1.0/debian/patches/eu.var.check_vies_certificate python-stdnum-1.0/debian/patches/eu.var.check_vies_certificate --- python-stdnum-1.0/debian/patches/eu.var.check_vies_certificate 1970-01-01 01:00:00.0 +0100 +++ python-stdnum-1.0/debian/patches/eu.var.check_vies_certificate 2015-04-28 19:01:35.0 +0200 @@ -0,0 +1,50 @@ +Index: python-stdnum-1.0/stdnum/eu/vat.py +=== +--- python-stdnum-1.0.orig/stdnum/eu/vat.py python-stdnum-1.0/stdnum/eu/vat.py +@@ -114,14 +114,7 @@ def guess_country(number): + if _get_cc_module(cc).is_valid(number)] + + +-def check_vies(number): # pragma: no cover (no tests for this function) +-Queries the online European Commission VAT Information Exchange +-System (VIES) for validity of the provided number. Note that the +-service has usage limitations (see the VIES website for details). +-This returns a dict-like object. +-# this function isn't automatically tested because it would require +-# network access for the tests and unnecessarily load the VIES website +-number = compact(number) ++def _check_vies_common(): + global _vies_client + if not _vies_client: + from suds.client import Client +@@ -130,4 +123,29 @@ def check_vies(number): # pragma: no co + except ImportError: + from urllib.request import getproxies + _vies_client = Client(vies_wsdl, proxy=getproxies()) ++ ++def check_vies(number): # pragma: no cover (no tests for this function) ++Queries the online European Commission VAT Information Exchange ++System (VIES) for validity of the provided number. Note that the ++service has usage limitations (see the VIES website for details). ++This returns a dict-like object. ++# this function isn't automatically tested because it would require ++# network access for the tests and unnecessarily load the VIES website ++_check_vies_common() ++number = compact(number) + return _vies_client.service.checkVat(number[:2], number[2:]) ++ ++def check_vies_certificate(number, requester): # pragma: no cover (no tests for this function) ++Queries the online European Commission VAT Information Exchange ++System (VIES) for validity of the provided number, providing a ++validity certificate as proof. You will need to give your own VAT ++number for this to work. Note that the service has usage limitations ++(see the VIES website for details). This returns a dict-like object. ++# this function isn't automatically tested because it would require ++# network access for the tests and unnecessarily load the VIES website ++_check_vies_common() ++number
Bug#774948: python3-stdnum: stdnum.eu.vat.check_vies needs suds
On Fri, Apr 17, 2015 at 02:43:11PM +0200, Arthur de Jong wrote: On Fri, 2015-01-09 at 12:40 +0100, Lionel Elie Mamane wrote: ImportError: No module named 'suds' An Internet search suggests suds itself is not available for Python3, but there seems to be several forks that are. From the SOAP libraries available in Debian it seemed that SUDS was the easiest to use. From a quick search I can't find any Python SOAP library for Python3. If they are not in Debian, at least one needs to be added to Debian ;-) Using one of the forks of suds for Python 3 would probably be the least work as far as stdnum is concerned. https://pypi.python.org/pypi/suds-py3/ https://pypi.python.org/pypi/suds-jurko/ -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Ping? I still patch my cups (1.7.5-11) locally with the attached patch, and this bug is still reproduced with unpatched 1.7.5-11. Any progress on this? For reminder, the problem is that when (a program using) libcupsys2 wants to retrieve the PPD for a printer whose device URI is ipp://something, libcupsys2 tries to connect to the device URI instead of to the cups server. This makes sense when the device URI is actually another CUPS server, but *not* when, as in my case, it is a network-attached printer that talks IPP natively. It will *not* have the PPD at the CUPS-specific URL. On Tue, Jul 01, 2014 at 04:24:58PM +0200, Lionel Elie Mamane wrote: Control: unarchive -1 Control: found -1 1.7.2-3 Control: found -1 1.7.3-6 Control: notfixed -1 1.7.1-1 Control: reopen -1 It seems the below test was mistaken. I had the problem again with 1.7.3-3, so I downgraded to 1.7.2-3, but I still get the problem. I think I had temporarily changed my printer to not use ipp:// but socket:// to work around the problem, and got confused in my tests... This bug is *not* fixed. On Tue, May 13, 2014 at 04:55:52PM +0200, Lionel Elie Mamane wrote: Control: tags -1 -moreinfo On Sun, Jan 05, 2014 at 12:45:10PM +0100, Didier 'OdyX' Raboud wrote: thanks for your detailed bugreports and proposed patch. Le dimanche, 5 janvier 2014, 01.44:37 Wolfgang Walter a écrit : We modified libcups in the same way as Lionel. I don't know why this has been changed from 1.5 to 1.6 but it seems buggy. Most ipp-printers don't provide a PPD. And even if the do there is no guarantie the client is allowed to communicate directly with the printer. Lionel Wolfgang: can you try to rebuild and try unstable's cups (1.7.0-2) without the get-ppd-file-for-statically-configured-ipp-shared- queues patch and report back if this works as expected? I upgraded to cups 1.7.2-3, which does not anymore have get-ppd-file-for-statically-configured-ipp-shared-queues, and it works as expected. Index: cups-1.7.5/cups/util.c === --- cups-1.7.5.orig/cups/util.c +++ cups-1.7.5/cups/util.c @@ -1718,6 +1718,7 @@ cups_get_printer_uri( IPP_TAG_URI)) != NULL) device_uri = attr-values[0].string.text; +#if 0 if (device_uri (!strncmp(device_uri, ipp://, 6) || !strncmp(device_uri, ipps://, 7) || @@ -1738,7 +1739,9 @@ cups_get_printer_uri( return (1); } -else if ((attr = ippFindAttribute(response, member-uris, +else +#endif +if ((attr = ippFindAttribute(response, member-uris, IPP_TAG_URI)) != NULL) { /*
Bug#774948: python3-stdnum: stdnum.eu.vat.check_vies needs suds
Package: python3-stdnum Version: 1.0-1 Severity: important $ python3 import stdnum.eu.vat stdnum.eu.vat.check_vies('LUXX') Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3/dist-packages/stdnum/eu/vat.py, line 127, in check_vies from suds.client import Client ImportError: No module named 'suds' An Internet search suggests suds itself is not available for Python3, but there seems to be several forks that are. http://www.gossamer-threads.com/lists/python/python/1140616 https://pypi.python.org/pypi/suds-jurko/0.6 https://pypi.python.org/pypi/suds-py3 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (600, 'testing-updates'), (600, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_LU.utf8, LC_CTYPE=fr_LU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python3-stdnum depends on: ii python3-pkg-resources 5.5.1-1 pn python3:anynone python3-stdnum recommends no packages. python3-stdnum suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771669: segfaults with trivial usage
rename 771669 segfault on SQLPrepare SELECT with expression result column thanks On Mon, Dec 01, 2014 at 02:31:22PM +0200, Enrico Zini wrote: sqlite3+odbc segfaults with this simple test case, which as far as I understand ODBC is just a standard connect and prepare sequence. $ cat sqlite-odbc.c (...) // Prepare a query assert(SQLPrepare(stm, (SQLCHAR*)SELECT COUNT(*) FROM sqlite_master WHERE type='table' AND name=?, SQL_NTS) == SQL_SUCCESS); Reproduced; the trigger for this segfault is that a column in the result of the select is an expression, as opposed to a straight column reference from a table. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771669: segfaults with trivial usage
Hi Christian, May I draw your attention on Debian bug number 771669, which I quote below and which can be read in full at http://bugs.debian.org/771669 ? It was reported against 0.992, but I have reproduced it with 0.999 (which I'm shortly going to upload to Debian). I also attach a backtrace with sqliteodbc and libsqlite3 compiled in full debug mode. The trigger for this segfault seems to me to be that a column in the result of the select is an expression, as opposed to a straight column reference from a table, leading to sqlite3_column_(database|table|origin)_name to return NULL, which is then passed to sqlite3_table_column_metadata. I'm not 100% sure if that is to be considered a bug in sqliteodbc or in libsqlite3; even if a bug in libsqlite3, it would probably be good to work around it in sqliteodbc, additionally to having it fixed in libsqlite3. Please keep 771...@bugs.debian.org in CC of your replies, so that they are filed by our bug tracking system and forwarded to the right people. Best Regards and Thanks, Lionel Mamane On Mon, Dec 01, 2014 at 02:31:22PM +0200, Enrico Zini wrote: Package: libsqliteodbc Version: 0.992-2 Severity: grave Hello, sqlite3+odbc segfaults with this simple test case, which as far as I understand ODBC is just a standard connect and prepare sequence. The segfault happens in the current Jessie and in Fedora 20. $ cat sqlite-odbc.c #include sql.h #include sqlext.h #include assert.h #include stdlib.h int main() { // Allocate ODBC environment handle and register version SQLHENV od_env; assert(SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, od_env) == SQL_SUCCESS); assert(SQLSetEnvAttr(od_env, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0) == SQL_SUCCESS); SQLHDBC od_conn; assert(SQLAllocHandle(SQL_HANDLE_DBC, od_env, od_conn) == SQL_SUCCESS); // Connect to the DSN char sdcout[1024]; SQLSMALLINT outlen; assert(SQLDriverConnect(od_conn, NULL, (SQLCHAR*)Driver=SQLite3;Database=test.sqlite;, SQL_NTS, (SQLCHAR*)sdcout, 1024, outlen, SQL_DRIVER_NOPROMPT) == SQL_SUCCESS); // Create a statement SQLHSTMT stm; assert(SQLAllocHandle(SQL_HANDLE_STMT, od_conn, stm) == SQL_SUCCESS); // Prepare a query assert(SQLPrepare(stm, (SQLCHAR*)SELECT COUNT(*) FROM sqlite_master WHERE type='table' AND name=?, SQL_NTS) == SQL_SUCCESS); // All good, deallocate things SQLFreeHandle(SQL_HANDLE_STMT, stm); SQLFreeHandle(SQL_HANDLE_DBC, od_conn); SQLFreeHandle(SQL_HANDLE_ENV, od_env); } $ gcc -g sqlite-odbc.c -o sqlite-odbc -lodbc $ rm -f test.sqlite # Not needed, but it keeps the tests stateless $ ./sqlite-odbc Segmentation fault $ rm -f test.sqlite # Not needed, but it keeps the tests stateless $ gdb ./sqlite-odbc GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 [...] (gdb) run Starting program: /home/enrico/lavori/arpa/dballe/sqlite-odbc [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. 0x76abc537 in sqlite3_stricmp () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (gdb) where #0 0x76abc537 in sqlite3_stricmp () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #1 0x76abd485 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #2 0x76abecf6 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #3 0x76b29188 in sqlite3_table_column_metadata () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #4 0x76d8180d in ?? () from /usr/lib/x86_64-linux-gnu/odbc/libsqlite3odbc.so #5 0x76d882d0 in ?? () from /usr/lib/x86_64-linux-gnu/odbc/libsqlite3odbc.so #6 0x76d88965 in ?? () from /usr/lib/x86_64-linux-gnu/odbc/libsqlite3odbc.so #7 0x77b94481 in SQLPrepare () from /usr/lib/x86_64-linux-gnu/libodbc.so.2 #8 0x00400957 in main () at sqlite-odbc.c:30 (gdb) Regards, Enrico -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsqliteodbc depends on: ii libc6 2.19-13 ii libsqlite0 2.8.17-12 ii libsqlite3-0 3.8.7.1-1 ii multiarch-support 2.19-13 libsqliteodbc recommends no packages. Versions of packages libsqliteodbc suggests: ii unixodbc-bin 2.3.0-4 -- no debconf information Program received signal SIGSEGV, Segmentation fault. 0x76aaa487 in sqlite3_stricmp (zLeft=0x62b758 sqlite_temp_master, zRight=zRight@entry=0x0) at sqlite3.c:23042 23042while( *a!=0 UpperToLower[*a]==UpperToLower[*b]){ a++; b++; } (gdb)
Bug#764624: g++-4.9: ICE compiling (upstream) LibreOffice
On Thu, Oct 09, 2014 at 06:45:11PM +0200, Lionel Elie Mamane wrote: /home/master/src/libreoffice/workdirs/libreoffice-4-4/sal/qa/osl/process/osl_process.cxx:487:27: internal compiler error: in should_move_die_to_comdat, at dwarf2out.c:6846 CPPUNIT_PLUGIN_IMPLEMENT(); ^ Here's the compilation line: S=/home/master/src/libreoffice/workdirs/libreoffice-4-4 I=$S/instdir W=$S/workdir mkdir -p $W/CxxObject/sal/qa/osl/process/ $W/Dep/CxxObject/sal/qa/osl/process/ cd /home/master/src/libreoffice/workdirs/libreoffice-4-4/usr/bin/ccache g++ -DCPPU_ENV=gcc3 -DDBG_UTIL -DLIBO_INTERNAL_ONLY -DLINUX -DOSL_DEBUG_LEVEL=1 -DSAL_LOG_INFO -DSAL_LOG_WARN -DSUPD=440 -DUNIX -DUNX -DX86_64 -D_DEBUG -D_GLIBCXX_DEBUG -D_PTHREADS -D_REENTRANT-DCPPUNIT_PLUGIN_EXPORT='extern C SAL_DLLPUBLIC_EXPORT' -DHAVE_GCC_VISIBILITY_FEATURE -fvisibility=hidden -Wall -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunused-macros -fmessage-length=0 -fno-common -pipe -fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual -std=gnu++11 -DEXCEPTIONS_ON -fexceptions -O0 -fstrict-aliasing -fstrict-overflow -gdwarf-4 -g3 -fvar-tracking-assignments -fvar-tracking -fdebug-types-section -finline-limit=0 -fno-inline -c $S/sal/qa/osl/process/osl_process.cxx -o $W/CxxObject/sal/qa/osl/process/osl_process.o -MMD -MT $W/CxxObject/sal/qa/osl/process/osl_process.o -MP -MF $W/Dep/CxxObject/sal/qa/osl/process/osl_process.d_ -I$S/sal/qa/osl/process/ -I$W/UnpackedTarball/cppunit/include -I$S/include -I/usr/lib/jvm/java-7-openjdk-amd64/include -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux -I$S/config_host mv $W/Dep/CxxObject/sal/qa/osl/process/osl_process.d_ $W/Dep/CxxObject/sal/qa/osl/process/osl_process.d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763010: xchat-guile: debian/control still depends on guile-1.8
On Fri, Sep 26, 2014 at 10:41:15PM -0500, Rob Browning wrote: Package: xchat-guile Version: 0.3-3 Severity: serious I suspect this was just overlooked in the 2.0 migration. Thank you for your bug report. Indeed, this dependency was left there, but xchat-guile was already using guile 2.0. It turns out it doesn't even need the guile-2.0 package (which contains the command-line interface interpreter) since it uses the library directly. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#250850: myodbc: register to ODBC default to yes?
Hi, I come back to this old bug. Ping? Can we make progress on this? On Mon, Nov 28, 2011 at 12:05:26PM +0100, Lionel Elie Mamane wrote: Steve Langasek wrote: I don't know what ODBC is, I just install and it asks: Do you want MyODBC to be registered as an ODBC driver? With default to No. I think the default should be yes, so it will just work for most users. Unless you have a reason, of course. The reason for this is that handing over control of the driver entries to the package will result in any local changes to the entry in /etc/odbcinst.ini being overwritten. I believe this is a policy violation, so am not willing to enable this by default. The other ODBC drivers packaged in Debian that I tried (PostgreSQL, SQLite) register to ODBC by default or unconditionally. So either this is a policy violation and all other ODBC driver packages are RC-buggy (file bugs then!), or change the default to yes for MyODBC, so that Debian users get an easy and uniform experience. I've started a thread on debian-devel looking for input on this. And? What was the outcome of that? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Control: unarchive -1 Control: found -1 1.7.2-3 Control: found -1 1.7.3-6 Control: notfixed -1 1.7.1-1 Control: reopen -1 It seems the below test was mistaken. I had the problem again with 1.7.3-3, so I downgraded to 1.7.2-3, but I still get the problem. I think I had temporarily changed my printer to not use ipp:// but socket:// to work around the problem, and got confused in my tests... This bug is *not* fixed. On Tue, May 13, 2014 at 04:55:52PM +0200, Lionel Elie Mamane wrote: Control: tags -1 -moreinfo On Sun, Jan 05, 2014 at 12:45:10PM +0100, Didier 'OdyX' Raboud wrote: thanks for your detailed bugreports and proposed patch. Le dimanche, 5 janvier 2014, 01.44:37 Wolfgang Walter a écrit : We modified libcups in the same way as Lionel. I don't know why this has been changed from 1.5 to 1.6 but it seems buggy. Most ipp-printers don't provide a PPD. And even if the do there is no guarantie the client is allowed to communicate directly with the printer. Lionel Wolfgang: can you try to rebuild and try unstable's cups (1.7.0-2) without the get-ppd-file-for-statically-configured-ipp-shared- queues patch and report back if this works as expected? I upgraded to cups 1.7.2-3, which does not anymore have get-ppd-file-for-statically-configured-ipp-shared-queues, and it works as expected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753303: avconv: in best video stream selection, please break resolution ties by bitrate
Package: libav-tools Version: 6:10.1-1 Severity: normal Take for example the video at http://player.ooyala.com/player/ipad/NoMndlbDpMPxEDCuGI2hYTcaQwVSQUBO.m3u8?js=1 (originally from http://www.aopa.org/Education/Safety-Videos.aspx?ipp=100) It is served over applehttp through ooyala. It has 5 variants of differing encoding, resolution and bitrate, *but* among same resolution (and encoding), there are sometimes multiple bitrate choices. For example: Program 0 Metadata: variant_bitrate : 123 Stream #0.0: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 123 Stream #0.1: Audio: aac, 44100 Hz, stereo, fltp, 133 kb/s Metadata: variant_bitrate : 123 (...) Program 3 Metadata: variant_bitrate : 1746000 Stream #0.6: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 1746000 Stream #0.7: Audio: aac, 44100 Hz, stereo, fltp, 133 kb/s Metadata: variant_bitrate : 1746000 Program 4 Metadata: variant_bitrate : 2798000 Stream #0.8: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 2798000 Stream #0.9: Audio: aac, 44100 Hz, stereo, fltp, 133 kb/s Metadata: variant_bitrate : 2798000 Program 4 is better than Program 0, but avconv selects Program 0, probably because it is the first among the ones that have highest resolution (Program 1 and 2 have resolution 480x270 and 640x360, respectively, and have ' h264 (Constrained Baseline)' video). The avconf manpage says: By default avconv tries to pick the best stream of each type present in input files and add them to each output file. For video, this means the highest resolution, (...) That's a good start, but to handle the above scenario well, please change avconv to select the highest bitrate among the videos that have the same (highest) resolution. About audio, I suppose it would be best to (by default) favour the audio that comes with the selected best Program. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (600, 'testing-updates'), (600, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libav-tools depends on: ii dpkg 1.17.10 ii libavcodec55 6:10.1-1 ii libavdevice54 6:10.1-1 ii libavfilter4 6:10.1-1 ii libavformat55 6:10.1-1 ii libavresample1 6:10.1-1 ii libavutil536:10.1-1 ii libbz2-1.0 1.0.6-5 ii libc6 2.19-4 ii libgnutls262.12.23-16 ii libgsm11.0.13-4 ii libmp3lame03.99.5+repack1-3 ii libopenjpeg5 1.5.2-2 ii libopus0 1.1-1 ii librtmp1 2.4+20131018.git79459a2-2 ii libschroedinger-1.0-0 1.0.11-2 ii libsdl1.2debian1.2.15-9 ii libspeex1 1.2~rc1.1-1 ii libswscale26:10.1-1 ii libtheora0 1.1.1+dfsg.1-3.2 ii libva1 1.3.1-3 ii libvdpau1 0.7-2 ii libvorbis0a1.3.2-1.4 ii libvorbisenc2 1.3.2-1.4 ii libvpx11.3.0-2 ii libx11-6 2:1.6.2-2 ii libx264-1422:0.142.2389+git956c8d8-5 ii libxvidcore4 2:1.3.3-1 ii zlib1g 1:1.2.8.dfsg-1 libav-tools recommends no packages. Versions of packages libav-tools suggests: pn frei0r-plugins none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753309: youtube-dl: please support choosing stream in hls downloads
Package: youtube-dl Version: 2014.06.19-1 Severity: normal $ youtube-dl -F http://www.aopa.org/AOPA-Live.aspx?watch={153E8150-DE50-4658-9377-9C05DB2E60D6} [generic] AOPA-Live: Requesting header WARNING: Falling back on generic information extractor. [generic] AOPA-Live: Downloading webpage [generic] AOPA-Live: Extracting information [Ooyala] NoMndlbDpMPxEDCuGI2hYTcaQwVSQUBO: Downloading webpage [Ooyala] NoMndlbDpMPxEDCuGI2hYTcaQwVSQUBO: Downloading webpage [info] Available formats for NoMndlbDpMPxEDCuGI2hYTcaQwVSQUBO: format code extension resolution note 0 mp4 unknown That is, youtube-dl doesn't know about the underlying format, resolution, etc. *But* the information is readily available: $ avprobe http://player.ooyala.com/player/ipad/NoMndlbDpMPxEDCuGI2hYTcaQwVSQUBO.m3u8?js=1 Input #0, hls,applehttp, from 'http://player.ooyala.com/player/ipad/NoMndlbDpMPxEDCuGI2hYTcaQwVSQUBO.m3u8?js=1': Duration: 00:05:42.00, start: 0.00, bitrate: N/A Program 0 Metadata: variant_bitrate : 123 Stream #0.0: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 123 Stream #0.1: Audio: aac, 44100 Hz, stereo, fltp, 133 kb/s Metadata: variant_bitrate : 123 Program 1 Metadata: variant_bitrate : 634000 Stream #0.2: Video: h264 (Constrained Baseline), yuv420p, 480x270 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 634000 Stream #0.3: Audio: aac, 44100 Hz, stereo, fltp, 161 kb/s Metadata: variant_bitrate : 634000 Program 2 Metadata: variant_bitrate : 939000 Stream #0.4: Video: h264 (Constrained Baseline), yuv420p, 640x360 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 939000 Stream #0.5: Audio: aac, 44100 Hz, stereo, fltp, 161 kb/s Metadata: variant_bitrate : 939000 Program 3 Metadata: variant_bitrate : 1746000 Stream #0.6: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 1746000 Stream #0.7: Audio: aac, 44100 Hz, stereo, fltp, 133 kb/s Metadata: variant_bitrate : 1746000 Program 4 Metadata: variant_bitrate : 2798000 Stream #0.8: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 23.98 fps, 90k tbn, 47.95 tbc Metadata: variant_bitrate : 2798000 Stream #0.9: Audio: aac, 44100 Hz, stereo, fltp, 133 kb/s Metadata: variant_bitrate : 2798000 Please import that information into youtube-dl (use avprobe, or implement your own .m3u8 parser if you prefer) so that one can: 1) use youtube-dl's -f, --prefer-free-formats, --max-quality, -F options to control the downloaded format. 2) youtube-dl can do its usual select the best by default job (which, I hope, it does a better job at than avconv, which does it purely based on resolution, without any tie-breaker in case of multiple choices with same resolution as above). -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (600, 'testing-updates'), (600, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages youtube-dl depends on: ii python2.7.6-2 ii python-pkg-resources 4.0.1-1 Versions of packages youtube-dl recommends: ii libav-tools 6:10.1-1 ii mplayer2 [mplayer] 2.0-728-g2c378c7-2 ii rtmpdump2.4+20131018.git79459a2-2 youtube-dl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752104: systemd: tries to run fsck on a mounted filesystem
Package: systemd Version: 204-8 Severity: normal Just switched to systemd (installed systemd-sysv), on an up-to-date jessie system. On reboot, I notice: Jun 19 17:53:02 fort systemd-fsck[959]: /dev/mapper/fort-root is mounted. Jun 19 17:53:02 fort systemd-fsck[959]: e2fsck: Cannot continue, aborting. Jun 19 17:53:02 fort systemd-fsck[959]: fsck failed with error code 8. Jun 19 17:53:02 fort systemd-fsck[959]: Ignoring error. AFAIK, it should run fsck with the root filesystem mounted read-only, this error message suggests the root filesystem was already mounted read/write. Maybe linked to the root filesystem being an lvm logical volume. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (600, 'testing-updates'), (600, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.2 ii libacl1 2.2.52-1 ii libaudit11:2.3.6-1 ii libc62.19-1 ii libcap2 1:2.22-1.2 ii libcap2-bin 1:2.22-1.2 ii libcryptsetup4 2:1.6.4-4 ii libdbus-1-3 1.8.4-1 ii libgcrypt11 1.5.3-4 ii libkmod2 16-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-3 ii libselinux1 2.3-1 ii libsystemd-daemon0 204-8 ii libsystemd-journal0 204-8 ii libsystemd-login0204-8 ii libudev1 204-8 ii libwrap0 7.6.q-25 ii sysv-rc 2.88dsf-53.2 ii udev 204-8 ii util-linux 2.20.1-5.8 Versions of packages systemd recommends: ii libpam-systemd 204-8 Versions of packages systemd suggests: pn systemd-ui none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533840: #533840 - gnome-session: switches to metacity from other window manager on upgrade
On Wed, May 14, 2014 at 05:07:54PM +0100, althaser wrote: Could you please still reproduce this issue with newer gnome-session version like 3.4.2.1-4 or 3.8.4-4 ? I'm not using Gnome anymore. Didn't survive the Gnome 3 changes. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Control: tags -1 -moreinfo On Sun, Jan 05, 2014 at 12:45:10PM +0100, Didier 'OdyX' Raboud wrote: thanks for your detailed bugreports and proposed patch. Le dimanche, 5 janvier 2014, 01.44:37 Wolfgang Walter a écrit : We modified libcups in the same way as Lionel. I don't know why this has been changed from 1.5 to 1.6 but it seems buggy. Most ipp-printers don't provide a PPD. And even if the do there is no guarantie the client is allowed to communicate directly with the printer. Lionel Wolfgang: can you try to rebuild and try unstable's cups (1.7.0-2) without the get-ppd-file-for-statically-configured-ipp-shared- queues patch and report back if this works as expected? I upgraded to cups 1.7.2-3, which does not anymore have get-ppd-file-for-statically-configured-ipp-shared-queues, and it works as expected. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747928: libglib2.0-dev: fails to configure - unmet python:any dependency
Package: libglib2.0-dev Version: 2.40.0-3 Severity: serious libglib2.0-dev fails to configure: dpkg: dependency problems prevent configuration of libglib2.0-dev: libglib2.0-dev depends on python:any (= 2.6.6-7~). Well, the package name is python, not python:any. I thought it might be related to multiarch and maybe a newer dpkg would parse the python:any, but nope, even with dpkg from unstable, still same error message. -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libglib2.0-dev depends on: ii libc6 2.17-3 ii libglib2.0-02.40.0-3 ii libglib2.0-bin 2.40.0-3 ii libpcre3-dev1:8.31-2 ii pkg-config 0.26-1 pn python:any none ii zlib1g-dev 1:1.2.7.dfsg-13 libglib2.0-dev recommends no packages. Versions of packages libglib2.0-dev suggests: ii libglib2.0-doc 2.33.12+really2.32.4-5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747928: libglib2.0-dev: fails to configure - unmet python:any dependency
On Tue, May 13, 2014 at 05:23:09AM +0200, Lionel Elie Mamane wrote: Package: libglib2.0-dev Version: 2.40.0-3 Severity: serious libglib2.0-dev fails to configure: dpkg: dependency problems prevent configuration of libglib2.0-dev: libglib2.0-dev depends on python:any (= 2.6.6-7~). Well, the package name is python, not python:any. I thought it might be related to multiarch and maybe a newer dpkg would parse the python:any, but nope, even with dpkg from unstable, still same error message. Upgrading *python* helped. So it seems there is a missing dependency on new-enough python. See e.g. https://bugs.debian.org/724705 for a similar situation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743893: mediawiki: postinst uses php5enmod, but fails to depend on a php5-common that has it
Package: mediawiki Version: 1:1.19.15+dfsg-1 Severity: serious Justification: Policy 3.5 Setting up mediawiki (1:1.19.15+dfsg-1) ... /var/lib/dpkg/info/mediawiki.postinst: 78: php5enmod: not found dpkg: error processing mediawiki (--configure): subprocess installed post-installation script returned error exit status 127 $ dpkg -l php5-common Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii php5-common 5.3.3-7+squeeze19Common files for packages built from the php5 source Apparently, mediawiki needs a newer php5-common than that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737088: libglm-dev: please ship glm.pc for pkg-config
On Thu, Jan 30, 2014 at 01:42:54PM +0100, Guus Sliepen wrote: On Thu, Jan 30, 2014 at 07:20:39AM +0100, Lionel Elie Mamane wrote: Please enable libglm-dev in pkg-config by shipping a glm.pc (it seems other distros do that, since libreoffice upstream master branch is trying to use pkg-config tu find glm; maybe upstream glm even builds a glm.pc and it only needs to be installed in debian/rules?) Upstream does not provide a glm.pc. Which other distros provide a glm.pc file? It was an assumption because LibreOffice is looking for one (development branch since 23 December 2013). I assumed that the developer that made that had it working on his machine, which thus had a glm.pc file. OTOH, now that I think of it, it is more probable that the LibreOffice developer only tested the use the bundled copy of glm scenario, not use the glm provided by the distro. If LibreOffice is depending on it, then I believe it is a bug in their configure.ac. Indeed. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737087: autoconf-archive: ax_boost_date_time broken by multiarch
Package: autoconf-archive Version: 20130609-2 Severity: important 1) Install libboost-date-time1.54-dev 1.54.0-4+b1 which is multiarch enabled; the library is in (e.g.) /usr/lib/x86_64-linux-gnu/ not in /usr/lib/ 2) cp /usr/share/aclocal/ax_boost_date_time.m4 aclocal.m4 3) Put in configure.ac AX_BOOST_DATE_TIME 4) autoconf ./configure Result: checking whether the Boost::Date_Time library is available... yes configure: error: Could not find a version of the library! Expected result: success That's because AX_BOOST_DATE_TIME looks for libboost_date_time*.so in /usr/lib instead of in /usr/lib/$(dpkg-architecture -qDEB_BUILD_MULTIARCH) How to achieve that in a cross-distro manner is another question entirely :) -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages autoconf-archive depends on: ii dpkg 1.17.5 ii install-info 4.13a.dfsg.1-10 Versions of packages autoconf-archive recommends: ii autoconf 2.69-1 autoconf-archive suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737088: libglm-dev: please ship glm.pc for pkg-config
Package: libglm-dev Version: 0.9.5.0-1 Severity: normal Many programs use pkg-config in their build system to find libraries. Please enable libglm-dev in pkg-config by shipping a glm.pc (it seems other distros do that, since libreoffice upstream master branch is trying to use pkg-config tu find glm; maybe upstream glm even builds a glm.pc and it only needs to be installed in debian/rules?) -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729713: libcups2: fails to fetch ppd of ipp:// device
Package: libcups2 Version: 1.6.3-1 Severity: normal Let FOO be a printer configured in CUPS with an ipp://foo.localdomain.tld/something device uri. Mine is a Konica Minolto C353. All cups clients fail to show printing options. lpoptions -d FOO -l says: lpoptions: Unable to get PPD file for FOO: Not Found A wireshark shows a request for http://device_ip:631/ipp.ppd, to which the printer replies by a 404. The attached patch disables that undesirable behaviour, which is new in 1.6 (did not happen in 1.5). -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (600, 'testing-updates'), (600, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcups2 depends on: ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libc6 2.17-93 ii libgnutls262.12.23-8 ii libgssapi-krb5-2 1.11.3+dfsg-3 ii multiarch-support 2.17-93 ii zlib1g 1:1.2.8.dfsg-1 libcups2 recommends no packages. Versions of packages libcups2 suggests: ii cups-common 1.6.3-1 -- no debconf information Index: cups-1.6.3/cups/util.c === --- cups-1.6.3.orig/cups/util.c 2013-11-15 11:25:51.0 +0100 +++ cups-1.6.3/cups/util.c 2013-11-15 16:41:31.456593720 +0100 @@ -1713,6 +1713,7 @@ IPP_TAG_URI)) != NULL) device_uri = attr-values[0].string.text; +#if 0 if (device_uri (!strncmp(device_uri, ipp://, 6) || !strncmp(device_uri, ipps://, 7) || @@ -1749,7 +1750,9 @@ return (1); } -else if ((attr = ippFindAttribute(response, member-uris, +else +#endif +if ((attr = ippFindAttribute(response, member-uris, IPP_TAG_URI)) != NULL) { /*
Bug#721120: libmyodbc: column names don't follow charset setting
Package: libmyodbc Version: 5.1.10-3 Severity: normal Bug originally hit in my role of LibreOffice/Base developer, treating issues connecting to MySQL over ODBC. The problem is that column names in result sets are *not* transcoded to the value of MyODBC's charset option, but (apparently) just copied byte-for-byte as what the MySQL server gives. Because MyODBC sets the server variable character_set_results to NULL, that is the value of character_set_system, which is usually (always?) utf8. Precise example: Make an entry in .odbc.ini like: [MySQL test] Driver = MySQL Server = localhost Database = test charset = latin1 (and create the test database in MySQL) Open a ISO8859-1 shell; for example: $ export LC_ALL=fr_LU # or any supported/enabled ISO8859-1 locale $ xterm ### switch to the new xterm $ isql 'MySQL test' user password SQL CREATE TABLE élément ( numÉlément INT NOT NULL PRIMARY KEY ); SQL SHOW TABLES; +-+ | Tables_in_test | +-+ | élément | +-+ SQLRowCount returns 1 1 rows fetched SQL SELECT * FROM élément; +-+ | numÃlément| +-+ +-+ SQLRowCount returns 0 SQL SELECT numÉlément FROM élément; +-+ | numÃlément| +-+ +-+ SQLRowCount returns 0 SQL SELECT numÉlément AS numéro_de_l_élément FROM élément; +---+ | numéro_de_l_élément| +---+ +---+ SQLRowCount returns 0 SQL Note how: 1) The table name appears correctly in output of SHOW TABLES; (MyODBC presumably does the transcoding there) 2) The column name is parsed correctly from the SQL command 3) The column name appears wrongly in the result. (MyODBC should do transcoding, but does not. Or alternatively, MyODBC should set character_set_results to the value of its charset parameter, and not do any transcoding itself.) -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libmyodbc:amd64 depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.17-92 ii libmysqlclient18 5.5.31+dfsg-0+wheezy1 ii odbcinst1debian2 2.2.14p2-5 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages libmyodbc:amd64 recommends: ii libodbc1 2.2.14p2-5 libmyodbc:amd64 suggests no packages. -- debconf information: * libmyodbc/addtoodbc: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721145: odbc-postgresql: generates queries like where ctid = (0, 1) on update
On Wed, Aug 28, 2013 at 03:38:27PM +0200, Lionel Elie Mamane wrote: When SQLBulkOperations(handle,SQL_UPDATE_BY_BOOKMARK) is called, odbc-postgresql sends to PostgreSQL a query like where ctid = '(0, 1)' returning ctid which is incomplete, and thus gives a syntax error and makes the update operation fail. I haven't completely understood the said circumstances, but they are hit with LibreOffice in its default configuration (which has some arguably dubious don't trust what the driver says workarounds for buggy drivers). As far as LibreOffice is concerned, this bug is worked around by enabling its Respect the result set type from the database driver setting. Forgot to give the ~/.odbc.ini entry: [Villages-local] Description = Connection to postgresql Villages database (local copy) Driver = PostgreSQL Unicode Trace = No TraceFile = /tmp/psqlodbc.log Database = Villages Servername = pgsql.gestman UserName = Password= Port = ReadOnly= No RowVersioning = No ShowSystemTables= No ShowOidColumn = No FakeOidIndex= No ConnSettings = Protocol= 7.4 This bug also does not appear when adding UpdatableCursors = Yes there. -- Lionel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719205: bugs.debian.org: sends mail with non-RFC compliant envelope sender address
Package: bugs.debian.org Severity: important 2013-08-08 17:42:33 H=buxtehude.debian.org [140.211.166.26] sender verify fail for debb...@buxtehude.debian.org: response to RCPT TO:postmas...@buxtehude.debian.org from mailly.debian.org [2001:41b8:202:deb:6564:a62:52c3:4b72] was: 550-Callout verification failed:\n550 550 Unknown or archived bug As per RFC 5321, sections 2.3.5, 3.1, 4.1.1.3, 4.5.1 and RFC 2142 sections 1, 4, domains used for sending mail should have a working postmaster address; buxtehude.debian.org does not. -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org