Bug#1063913: mutt: background_edit and sidebar_visible changes lead to corrup screen

2024-02-14 Thread Lionel Elie Mamane
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)

2023-03-20 Thread Lionel Elie Mamane
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

2023-03-20 Thread Lionel Elie Mamane
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

2022-07-26 Thread Lionel Elie Mamane
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

2022-03-01 Thread Lionel Elie Mamane
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)

2022-03-01 Thread Lionel Elie Mamane
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

2021-11-07 Thread Lionel Elie Mamane
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

2021-10-24 Thread Lionel Elie Mamane
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

2021-10-18 Thread Lionel Elie Mamane
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

2021-09-02 Thread Lionel Elie Mamane
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

2021-06-20 Thread Lionel Elie Mamane
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

2021-03-31 Thread Lionel Elie Mamane
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

2021-01-10 Thread Lionel Elie Mamane
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

2020-09-29 Thread Lionel Elie Mamane
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

2020-07-06 Thread Lionel Elie Mamane
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

2020-07-06 Thread Lionel Elie Mamane
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

2019-12-13 Thread Lionel Elie Mamane
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

2019-10-07 Thread Lionel Elie Mamane
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

2019-10-07 Thread Lionel Elie Mamane
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

2019-06-20 Thread Lionel Elie Mamane
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

2018-11-13 Thread Lionel Elie Mamane
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

2018-11-13 Thread Lionel Elie Mamane
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

2018-10-30 Thread Lionel Elie Mamane
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

2018-10-30 Thread Lionel Elie Mamane
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

2018-08-16 Thread Lionel Elie Mamane
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

2018-04-20 Thread Lionel Elie Mamane
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

2017-12-28 Thread Lionel Elie Mamane
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

2017-12-13 Thread Lionel Elie Mamane
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

2017-12-12 Thread Lionel Elie Mamane
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

2017-12-12 Thread Lionel Elie Mamane
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

2017-12-11 Thread Lionel Elie Mamane
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

2017-12-07 Thread Lionel Elie Mamane
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

2017-07-30 Thread Lionel Elie Mamane
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

2017-06-01 Thread Lionel Elie Mamane
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?

2017-03-09 Thread Lionel Elie Mamane
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

2017-03-07 Thread Lionel Elie Mamane
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

2016-12-22 Thread Lionel Elie Mamane
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

2016-12-05 Thread Lionel Elie Mamane
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

2016-11-20 Thread Lionel Elie Mamane
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

2016-11-09 Thread Lionel Elie Mamane
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

2016-08-18 Thread Lionel Elie Mamane
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

2016-08-18 Thread Lionel Elie Mamane
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

2016-08-18 Thread Lionel Elie Mamane
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?

2016-06-25 Thread Lionel Elie Mamane
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

2016-06-09 Thread Lionel Elie Mamane
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

2016-05-31 Thread Lionel Elie Mamane
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"

2016-05-12 Thread Lionel Elie Mamane
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

2016-04-21 Thread Lionel Elie Mamane
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

2016-04-21 Thread Lionel Elie Mamane
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

2016-04-21 Thread Lionel Elie Mamane
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

2016-01-29 Thread Lionel Elie Mamane
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

2016-01-29 Thread Lionel Elie Mamane
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)

2016-01-21 Thread Lionel Elie Mamane
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

2016-01-15 Thread Lionel Elie Mamane
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

2016-01-12 Thread Lionel Elie Mamane
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

2016-01-12 Thread Lionel Elie Mamane
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

2016-01-12 Thread Lionel Elie Mamane
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

2016-01-06 Thread Lionel Elie Mamane
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

2015-10-28 Thread Lionel Elie Mamane
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

2015-10-28 Thread Lionel Elie Mamane
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

2015-10-05 Thread Lionel Elie Mamane
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

2015-09-19 Thread Lionel Elie Mamane
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

2015-09-17 Thread Lionel Elie Mamane
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

2015-09-13 Thread Lionel Elie Mamane
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

2015-09-12 Thread Lionel Elie Mamane
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)

2015-08-15 Thread Lionel Elie Mamane
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

2015-07-21 Thread Lionel Elie Mamane
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)

2015-06-07 Thread Lionel Elie Mamane
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)

2015-06-07 Thread Lionel Elie Mamane
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

2015-06-03 Thread Lionel Elie Mamane
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

2015-04-29 Thread Lionel Elie Mamane
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

2015-04-28 Thread Lionel Elie Mamane
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

2015-04-28 Thread Lionel Elie Mamane
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

2015-04-28 Thread Lionel Elie Mamane
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)

2015-04-28 Thread Lionel Elie Mamane
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)

2015-04-28 Thread Lionel Elie Mamane
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

2015-04-28 Thread Lionel Elie Mamane
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

2015-04-27 Thread Lionel Elie Mamane
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

2015-01-09 Thread Lionel Elie Mamane
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

2014-12-01 Thread Lionel Elie Mamane
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

2014-12-01 Thread Lionel Elie Mamane
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

2014-10-09 Thread Lionel Elie Mamane
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

2014-09-27 Thread Lionel Elie Mamane
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?

2014-07-22 Thread Lionel Elie Mamane
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

2014-07-01 Thread Lionel Elie Mamane
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

2014-06-30 Thread Lionel Elie Mamane
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

2014-06-30 Thread Lionel Elie Mamane
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

2014-06-19 Thread Lionel Elie Mamane
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

2014-05-14 Thread Lionel Elie Mamane
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

2014-05-13 Thread Lionel Elie Mamane
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

2014-05-12 Thread Lionel Elie Mamane
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

2014-05-12 Thread Lionel Elie Mamane
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

2014-04-07 Thread Lionel Elie Mamane
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

2014-01-30 Thread Lionel Elie Mamane
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

2014-01-29 Thread Lionel Elie Mamane
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

2014-01-29 Thread Lionel Elie Mamane
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

2013-11-15 Thread Lionel Elie Mamane
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

2013-08-28 Thread Lionel Elie Mamane
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

2013-08-28 Thread Lionel Elie Mamane
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

2013-08-09 Thread Lionel Elie Mamane
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



  1   2   3   4   5   6   7   8   9   10   >