Bug#1019891: mycli: Always crashes at runtime because the module 'sqlglot' is missing

[François Gannaz]

Package: mycli
Version: 1.26.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading the package `mycli`, the command fails to run.

❯ mycli
Traceback (most recent call last):
  File "/usr/bin/mycli", line 33, in 
sys.exit(load_entry_point('mycli==1.26.1', 'console_scripts',
'mycli')()) File "/usr/bin/mycli", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in
load module = import_module(match.group('module'))
  File "/usr/lib/python3.10/importlib/__init__.py", line 126, in
import_module return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1050, in _gcd_import
  File "", line 1027, in _find_and_load
  File "", line 1006, in
_find_and_load_unlocked File "", line 688,
in _load_unlocked File "", line
883, in exec_module File "", line 241, in
_call_with_frames_removed File
"/usr/lib/python3/dist-packages/mycli/main.py", line 27, in 
import sqlglot ModuleNotFoundError: No module named 'sqlglot'

Here is the upstream commit that added this dependency:
https://github.com/dbcli/mycli/commit/b8411836350923528ecdb0c92f22d26d012c1c89

I couldn't find 'sqlglot' anywhere among the Debian packages, so I
suppose there is no easy workaround for this missing dependency.

Thank you for maintaining this.
Regards,

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.utf8, LC_CTYPE=C.UTF-8
(charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mycli depends on:
ii  python3 3.10.6-1
ii  python3-cli-helpers 2.2.1-1
ii  python3-click   8.0.3-1
ii  python3-configobj   5.0.6-5
ii  python3-cryptography3.4.8-2
ii  python3-pkg-resources   59.6.0-1.2
ii  python3-prompt-toolkit  3.0.31-1
ii  python3-pyaes   1.6.1-4
ii  python3-pygments2.12.0+dfsg-2
ii  python3-pymysql 1.0.2-2
ii  python3-pyperclip   1.8.2-2
ii  python3-sqlparse0.4.2-1
ii  python3-tabulate0.8.9-1
ii  python3-terminaltables  3.1.0-4

mycli recommends no packages.

mycli suggests no packages.

-- no debconf information

Bug#941572: gitinspector: --format=html crashes

[François Gannaz]

Package: gitinspector
Version: 0.4.4+dfsg-6
Severity: important

Dear Maintainer,

The command line option that outputs HTML instead of plain text
always leads to a crash. Here is the command and its output:

% gitinspector --since 2019-09-01 --format=html
Traceback (most recent call last):
  File "/usr/bin/gitinspector", line 11, in 
load_entry_point('gitinspector==0.4.4', 'console_scripts', 'gitinspector')()
  File "/usr/lib/python3/dist-packages/gitinspector/gitinspector.py", line 184, 
in main
__run__.output()
  File "/usr/lib/python3/dist-packages/gitinspector/gitinspector.py", line 74, 
in output
format.output_header()
  File "/usr/lib/python3/dist-packages/gitinspector/format.py", line 70, in 
output_header
tablesorter_js = js.read().decode("utf-8", "replace")
AttributeError: 'str' object has no attribute 'decode'

Removing the `.decode(...` after each `.read()` in this file fixes the
problem, but I am not experienced enough with Python3 to submit it as
a patch.

Thank you for maintaining this package.

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

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

Versions of packages gitinspector depends on:
ii  git   1:2.23.0-1
ii  libjs-jquery  3.3.1~dfsg-3
ii  libjs-jquery-flot 0.8.3+dfsg-1
ii  libjs-jquery-tablesorter  1:2.31.1+dfsg1-1
ii  python3   3.7.3-1
ii  python3-pkg-resources 41.2.0-1

gitinspector recommends no packages.

gitinspector suggests no packages.

-- no debconf information

Bug#941283: libvte: terminal crashes after a VTE error

[François Gannaz]

Package: libvte-2.91-0
Version: 0.58.0-1
Severity: important
File: libvte

Dear maintainer,

since last week, I've seen several terminal windows crash, with
gnome-terminal (official Debian testing) and roxterm (unofficial).
This happened on two computers, both using Debian testing and the same
terminal emulators. The WM is XMonad (tiling WM).

Unfortunately, I haven't seen any common cause. I've never had a crash
while typing. When I switch to a virtual desktop, the terminal windows
are gone or disappear immediately.

I saw nothing relevant in the logs, except for the last crash. From
journalctl:

sept. 27 20:37:45 org.gnome.Terminal[1063]: **
sept. 27 20:37:45 org.gnome.Terminal[1063]:t
VTE:ERROR:../src/vte.cc:555:void
vte::terminal::Terminal::set_hard_wrapped(vte::grid::row_t): assertion
failed (row < m_screen->insert_delta + m_row_count): (3091 < 3091)
sept. 27 20:37:45 sudo[6290]: pam_unix(sudo:session): session closed for
user root

I'd be glad to provide any detail you'd like.

Thanks

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

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

Versions of packages libvte-2.91-0:amd64 depends on:
ii  libatk1.0-0  2.34.0-1
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libfribidi0  1.0.5-3.1
ii  libglib2.0-0 2.60.6-2
ii  libgnutls30  3.6.9-5
ii  libgtk-3-0   3.24.11-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpcre2-8-0 10.32-5+b1
ii  libstdc++6   9.2.1-8
ii  libvte-2.91-common   0.58.0-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

libvte-2.91-0:amd64 recommends no packages.

libvte-2.91-0:amd64 suggests no packages.

-- no debconf information

Bug#901793: Info received (Bug#901793: certbot: Fails to renew because of a SSL/TLSv1 error and more)

[François Gannaz]

Here is the explanation: the /etc/hosts files had lines that gave static
IPs to the servers that renew certificates:

# /etc/hosts
104.85.23.247  acme-v01.api.letsencrypt.org
104.85.23.247  acme-staging.api.letsencrypt.org

These point to Akamai server. They were probably proxing letsencrypt
servers until last month, since renewing certificates worked for the last
10 months with this config.

I can't trace precisely the origin of those 2 lines, but etckeeper shows
they were introduced at the same time certbot was installed (2017-08). And
I certainly did not write them myself. I suppose certbot's install was a
bit flawed at that time.

You may close the ticket. Thank you for you help.

Bug#901793: certbot: Fails to renew because of a SSL/TLSv1 error and more

[François Gannaz]

Thank you for your help, this non-sense was driving me crazy!

Unfortunately, this server is nothing special. It's an OVH VPS, with its 
default Debian install. Network is configured with OVH's DHCP. No proxy, 
but that does not mean OVH isn't mangling somewhere in the middle.


I'll reach OVH's bugtracker tonight, and update this ticket if there's 
something on their side.


Many thanks again, now I have a faint hope to make sense of all this.
--
François Gannaz

Bug#901793: certbot: Fails to renew because of a SSL/TLSv1 error and more

[François Gannaz]

Package: certbot
Version: 0.10.2-1
Severity: important

Dear Maintainer,

On a stretch server, with no change of configuration, the certbot 
service failed repeatedly since it entered the renew process on
2018-06-05, 30 days before the certificates expires.

The cause may be that the version certbot is too old, as in bug 888703,
but in my case the error messages are different and sometimes they don't
make any sense to me.


From 2018-06-05 to 2018-06-08 (boundaries included), the log was like:

certbot[31803]: Attempting to renew cert from 
/etc/letsencrypt/renewal/littre.org.conf produced an unexpected error: ("bad 
handshake: Error([('SSL routines', 'ssl3_read_bytes', 'tlsv1 alert internal 
error')],)",). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/littre.org/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

From 2018-06-09 to 2018-06-12 the error log changed:

Certificate did not match expected hostname: acme-v01.api.letsencrypt.org. 
Certificate: {'subjectAltName': [('DNS', '*.rodanandfields.com'), ('DNS', 
'rodanandfields.com')], 'subject': ((('commonName', 
u'*.rodanandfields.com'),),)}
Attempting to renew cert from /etc/letsencrypt/renewal/littre.org.conf produced 
an unexpected error: hostname 'acme-v01.api.letsencrypt.org' doesn't match 
either of '*.rodanandfields.com', 'rodanandfields.com'. Skipping.

From 2018-06-12 to 2018-06-15, back to the SSL error.

From 2018-06-16 to now, a new DNS error appeared:

Certificate did not match expected hostname: acme-v01.api.letsencrypt.org. 
Certificate: {'subjectAltName': [('DNS', '*.cinemaspathegaumont.com'), ('DNS', 
'cinemaspathegaumont.com')], 'subject': ((('commonName', 
u'*.cinemaspathegaumont.com'),),)}
Attempting to renew cert from /etc/letsencrypt/renewal/littre.org.conf produced 
an unexpected error: hostname 'acme-v01.api.letsencrypt.org' doesn't match 
either of '*.cinemaspathegaumont.com', 'cinemaspathegaumont.com'. Skipping.


This server has no relation to the two domains that were referred in
the logs. These domains do not appear anywhere under /etc/.

Sincerly,

François Gannaz


-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages certbot depends on:
ii  init-system-helpers  1.48
ii  python   2.7.13-2
ii  python-certbot   0.10.2-1

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-apache  
pn  python-certbot-doc 

-- no debconf information

Bug#893865: claws-mail: Fetching emails crashes with a X Window System error

[François Gannaz]

Hi.

Claws-mail does not crash anymore on my system. I suppose one of its 
dependencies got updated recently, because my Debian is a frequently 
updated testing release, but I have no real clue.


When it crashed, I had of course restarted the whole system, and it 
still crashed every time. I should have run a debugger then, but didn't 
take the time to do so.


You can close this ticket. Sorry for the noise.
--
François

Bug#834527: claws-mail: Deleting a message used to move the cursor to the next message, now it's the previous one

[François Gannaz]

Thanks to both of you for your fast responses.

Le 2016-08-17, Paul  a écrit :
> From this I deduce that you sort with the newest messages at the top
> and oldest at the bottom. (Which is not the default, btw.)

No, this folder was sorted by threads with the newest messages at the
bottom (the default sort order). It's the same  in another folder (no
threads, newest at bottom): it used to go to the next/newer message by
default, before the update that made the cursor move to the
previous/older one by default.

> [...]
> I hope this puts to bed this (unexpectedly) contentious issue.

The behaviour changed when I upgraded Claws-mail and it made me delete the
wrong files. I could find no setting for this in the GUI, so I had to
search the documentation for a solution and then update a configuration
file. It was of course a very minor issue, but I am surprised it was
unexpected.

Regards

Bug#834527: claws-mail: Deleting a message used to move the cursor to the next message, now it's the previous one

[François Gannaz]

Package: claws-mail
Version: 3.14.0-1
Severity: normal
Tags: upstream

Dear Maintainer,

I updated Claws-mail to 3.14, and the behaviour of deletions changed.
After selecting a read message whose neighbours had also been read, I
pressed 3 times on the "delete" key. The selected message and the
two messages _above_ it were deleted. I expected the two messages
_below_ it to be deleted.

The only documentation I could find about this was in the changelog
http://claws-mail.org/NEWS on 3.13.1.

```
* A hidden pref has been added, 'next_on_delete'. This controls the
  message selection when a message is deleted. A setting of '0'
  which cause the previous, older message to be selected, a setting
  of '1' will cause the next, newer message to be selected.
```

Unfortunately, this minimal documentation seems wrong. In my case,
`next_on_delete` was set to 0 by default, yet the behaviour had changed.
Setting the line `next_on_delete=1` in `~/.claws-mail/clawsrc` reverted
to the old behaviour once I restarted claws-mail.

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

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

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libcompfaceg11:1.5.2-5
ii  libdb5.3 5.3.28-12
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libenchant1c2a   1.6.0-11+b1
ii  libetpan17   1.6-1+b1
ii  libfontconfig1   2.11.0-6.5
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgnutls30  3.5.2-2
ii  libgtk2.0-0  2.24.30-4
ii  libice6  2:1.0.9-1+b1
ii  libldap-2.4-22.4.42+dfsg-2+b2
ii  liblockfile1 1.09-6
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpangoft2-1.0-01.40.1-1
ii  libpisock9   0.12.5-dfsg-2+b1
ii  libsasl2-2   2.1.26.dfsg1-15
ii  libsm6   2:1.2.2-1+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages claws-mail recommends:
ii  aspell-de [aspell-dictionary]  20160407-1
ii  aspell-en [aspell-dictionary]  2016.06.26-0-0.1
ii  aspell-fr [aspell-dictionary]  0.50-3-8
ii  claws-mail-i18n3.14.0-1
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 52.0.2743.82-2
pn  claws-mail-doc 
ii  claws-mail-tools   3.14.0-1
ii  elinks [www-browser]   0.12~pre6-11+b2
ii  firefox-esr [www-browser]  45.3.0esr-1
pn  gedit | kwrite | mousepad | nedit  
ii  links2 [www-browser]   2.13-1
ii  lynx [www-browser] 2.8.9dev9-1
ii  opera [www-browser]12.16.1860
ii  w3m [www-browser]  0.5.3-29

-- no debconf information

Bug#809719: roxterm: Most shortcuts are ineffective

[François Gannaz]

Le 2016-01-06, Tony Houghton  a écrit :
> On 05/01/16 18:32, François Gannaz wrote:
> > Removing the locale with `LANG=C roxterm --separate` does fix it.
> >
> > And just as you suggested, the problem lies within the matching of
> > action names. The strange part is that only part of it is
> > translated:
> >
> > File/New Tab=t
> > File/Nouvel Onglet=t
> >
> > "File" is translated into "Fichier" in roxterm's menu, but
> > "Fichier/Nouvel Onglet" was ignored.  
> 
> So the submenu strings have to be translated, but not the top-level
> menus? Strange. I might be able to at least correct that for
> consistency, but I don't know what the ultimate solution would be. It
> doesn't help that it's years since I worked on the relevant parts of
> the code! If I make it so that the shortcuts are English then the
> standard ones will work no matter what the language, but that will
> make it harder for non-English users to configure their own. Is it
> normal for the keystrokes to stay the same no matter what language is
> used, or for those to be changed to match the words in other
> languages? For example, would you expect to use t to
> match the English version, or o for "onglet".

I'm very reluctant to a localized configuration, with keyboard shortcuts
would vary with the locale. When I switch to another system, I expect
an application to behave similarly: I've used Ctrl-Shift-t with several
terminal emulators, and I did not care much which locale was declared,
it was always the same shortcuts in every terminal.

I would also get very confused if my config file were to break when the
locale changes.

I suspect some people pay more attention to menus and consistency
between labels and shortcuts, but probably not that much for something
as technical as a terminal emulator.

That's my opinion, you decide.
--
François

Bug#809719: roxterm: Most shortcuts are ineffective

[François Gannaz]

Le 2016-01-06, Tony Houghton  a écrit :
> So for the moment you would prefer the config to be in English, I
> think. Even that will be a bit difficult to fix and test, but ideally
> there should be some sort of system to allow users to edit the
> shortcuts in their own language and store the results in English.
> Solving this might have to wait until if and when I do a major rewrite
>  

I've had a look at the code yesterday, to see if I could submit an easy
patch, but I was cast away by the mix of GTK's map_accelerators and
gettext. I could not even plan a pretty way out.

> but at the moment I'm leaning towards discontinuing roxterm and
> trying to get more involved with gnome-terminal and vte development
> if the current team are willing to let me add some features from
> roxterm. If not, I suppose I could fork it.

I'd read about this in roxterm's forum before reporting the bug. That's
sad because I think roxterm is good, better than xfce4-terminal that I
was using a few years ago. Yet I understand the move. I may try again
gnome-terminal on the next roxterm bug ;-)

--
François

Bug#809719: roxterm: Most shortcuts are ineffective

[François Gannaz]

Le 2016-01-05, Tony Houghton  a écrit :
> 
> Can you try building replacement debian packages to test? You should
> just be able to run debuild -b in the git/source directory.

I had to install itstool and po4a. The resulting package had no keyboard
shortcuts.

The new roxterm executable was the same size as the official one, though
the MD5 sum was different. The locally-compiled (outside debuild) file was
43% larger.

> > The keypad decimal bug is not affected by this, so it should go in
> > another bug report.  
> 
> Could you test that in gnome-terminal instead of xfce4-terminal?  I
> think xfce4 is still based on GTK+2.0 with a much older version of vte.
> Also try other text fields from gnome-terminal, roxterm and/or other
> GTK+3.0-based programs.

To sum it up:

xev:.
xfce4-terminal: . (GTK+2, libvte 0.28)
gnome-terminal: ,
roxterm 3.3.1:  , (libvte 0.42)

Unless you suggest something else, I suppose I shall open a new ticket
in libgtk-3-0.

Bug#809719: roxterm: Most shortcuts are ineffective

[François Gannaz]

On my laptop, I compiled roxterm from the source, using the git tag 3.3.1.
I wanted to bisect the bug, but shortcuts worked flawlessly with this
self-compiled roxterm. I followed the default process, didn't set any
configuration option, and simply run `./build/roxterm --separate`.

If I copy this new roxterm binary to my desktop computer (both are
Testing Debian amd64) in /usr/bin/, shortcuts are also fixed.

The keypad decimal bug is not affected by this, so it should go in
another bug report.

Le 2016-01-04, Tony Houghton  a écrit :
> tags 809719 - moreinfo
> thanks
> 
> It looks like there's a problem in roxterm's locale handling, maybe 
> specifically fr_FR.utf8. The reporter of #804144, which looks related, 
> has the same locale.

Bug#809719: roxterm: Most shortcuts are ineffective

[François Gannaz]

Thank you for your quick response.

The diff between /usr and ~/.config shortcuts is one line long:
9d8
< Edit/Select All=a

Removing the user config file or copying over it has no visible effect.

I don't know if it is related, but KP_Decimal outputs a comma "," within
roxterm. It printed a dot "." before the upgrade, like xfce4-terminal
still does. My config has not changed, and `setxkbmap -query` confirms
that "option kpdl:dot" is still active. `xev` also sees a "." for this
keypress.

Le 2016-01-04, Tony Houghton  a écrit :
> tags 809719 + unreproducible moreinfo
> thanks
> 
> On 03/01/16 11:13, François Gannaz wrote:
> 
> > After updating my distribution, most shortcuts defined in the default
> > profile of roxterm are ineffective. The same behaviour occurs on my
> > laptop, after updating it to the latest Stretch.
> >
> > The configuration file for shortcuts is unchanged:
> > `~/.config/roxterm.sourceforge.net/Shortcuts/Default`  
> 
> Please post that file here here. It's possible there might have been a 
> format change over the years, or at least I can try the config here and 
> hopefully be able to reproduce the problem.
> 
> If the shortcuts are unchanged you shouldn't need that config file and 
> it will use the one from /usr/share/roxterm/Config. Does removing the 
> one in ~/.config/ fix it? If so, does editing the shortcuts break it again?

Bug#809719: roxterm: Most shortcuts are ineffective

[François Gannaz]

Package: roxterm
Version: 3.3.1-1
Severity: important

Dear Maintainer,

After updating my distribution, most shortcuts defined in the default
profile of roxterm are ineffective. The same behaviour occurs on my
laptop, after updating it to the latest Stretch.

The configuration file for shortcuts is unchanged:
`~/.config/roxterm.sourceforge.net/Shortcuts/Default`

I tried each of them (21 shortcuts) and the only definitions that worked
were: Tabs/Previous Tab=Page_Up
Tabs/Next Tab=Page_Down

It seems the keys are simply sent to the shell. Ctrl-Shit-t behaves like
Ctrl-t (transpose). C-S-c is like Ctrl-c. Ctrl-- or F1 have no visible
effect. I tried to change the most needed "File/New Tab" shortcut, but
it made no difference.

I suspected libvte was in fault, but Ctrl-Shift-t does work in
xfce4-terminal 0.6.3-2 and gnome-terminal 3.18.2-1.

Regards,

F. G.

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

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

Versions of packages roxterm depends on:
ii  libc6   2.21-6
ii  libcairo2   1.14.4-1
ii  libdbus-1-3 1.10.6-1
ii  libdbus-glib-1-20.102-1
ii  libgdk-pixbuf2.0-0  2.32.3-1
ii  libglib2.0-02.46.2-3
ii  libgtk-3-0  3.18.6-1
ii  libice6 2:1.0.9-1+b1
ii  libpango-1.0-0  1.38.1-1
ii  librsvg2-common 2.40.11-2
ii  libsm6  2:1.2.2-1+b1
ii  libvte-2.91-0   0.42.1-2
ii  libx11-62:1.6.3-1
ii  roxterm-data3.3.1-1

roxterm recommends no packages.

roxterm suggests no packages.

-- no debconf information

Bug#806415: mycli: No way to execute the query

[François Gannaz]

Package: mycli
Version: 1.5.2-1
Severity: important

Dear Maintainer,

Launching `mycli mydb` connects to the DB and I am able to write a SQL
query with proper completion. Yet I cannot execute it.

Placing `;` at the end of the line is ineffective. Pressing Enter or
Ctrl-j has no visible consequence. I tried several times with Smart
completion off, Multiline off, and vi mode, but it had no effect on
this.

Incidently, I could not execute "quit" so I had to kill mycli.

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

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

Versions of packages mycli depends on:
ii  python3-click   5.1-1
ii  python3-configobj   5.0.6-2
ii  python3-crypto  2.6.1-5+b3
ii  python3-prompt-toolkit  0.53-1
ii  python3-pygments2.0.1+dfsg-1.1
ii  python3-pymysql 0.6.2-2
ii  python3-sqlparse0.1.18-1
pn  python3:any 

mycli recommends no packages.

mycli suggests no packages.

-- no debconf information

Bug#779836: mumble: Hibernation floods ~/.xsession-errors with messages

[François Gannaz]

Greetings Chris, and thank you for your quick answer.

I confirm that, when I resumed my hibernated Linux, your patched version
of Mumble did not flood my partition. But it still smelled on the ALSA
side: no sound in Mumble, trying to change the settings froze it.
So I had to kill Mumble, unload the sound module and reload it.

For reference, here is the hook I now use for systemd, in
/etc/systemd/system/root-suspend.service:

```
[Unit]
Description=Suspend hook
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill mumble

[Install]
WantedBy=sleep.target
```

Hook enabled with `systemctl enable root-suspend`, then `systemctl
hibernate` will kill Mumble. This workaround is okay, I just need to
launch it on resume.
--
François

Le 2015-03-07, Chris Knadle  a écrit :
> Greetings François.
> 
> On 03/05/2015 06:27 AM, François Gannaz wrote:
> > Package: mumble
> > Version: 1.2.8-2
> > Severity: important
> > Tags: upstream
> > 
> > Dear Maintainer,
> > 
> > when running Mumble with an ALSA backend, after hibernation, resuming
> > the system causes Mumble to flood ~/.xsession-errors with ALSA
> > warning messages. In a few minutes, several GB of text are written,
> > until the partition is full.
> 
> Yikes.  Yes obviously this is an issue I want to fix.
> 
> > The bug was notified upstream by someone else, with a proposed patch:
> > https://github.com/mumble-voip/mumble/issues/1381
> > 
> > I marked the bug as "important" because the flooding of the home
> > partition can cause important nuisances. The first time I encountered
> > this bug, I lost some data in other applications that had opened files.
> > This time, I lost Mumble's configuration (empty .config file).
> 
> I think the "important" severity is correct, IMHO.  (If not higher,
> as it can cause data loss as you experienced.)
> 
> From the upstream response it sounds like they plan to use a broader
> fix than the currently proposed patch, so for Debian proper I'm more
> likely going to wait for their chosen fix.
> 
> For Jessie (which is what t looks like you're mainly using) any fix
> will have to wait for a point release, which happens about every three
> months after the release.
> 
> That's too long to wait IMHO so I have an alternative available if
> you want to try it.  Besides maintaining the Mumble package in Debian
> I also maintain a "fully embedded codec" version in my own personal
> repository of Debian packages -- and I've included the current patch
> for this problem in that package for version 1.2.8-2+0cdu0 (for Sid
> and Jessie so far), if you want to try it.
> 
>http://debian-packages.coredump.us/
> 
> to load the package without installing the repo, the Mumble packages
> are here:
> 
>http://debian-packages.coredump.us/debian/pool/main/m/mumble/
> 
> > Up to now, I was using kill hooks with pm-hibernate, but it seems that
> > `systemctl hibernate` does not run them, so my ugly hack is no more a
> > solution.
> 
> If you let me know the hook you used with pm-hibernate before I'll
> see if I can find a similar trick for doing it under systemd.
> 
>-- Chris
> 


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

Bug#779836: mumble: Hibernation floods ~/.xsession-errors with messages

[François Gannaz]

Package: mumble
Version: 1.2.8-2
Severity: important
Tags: upstream

Dear Maintainer,

when running Mumble with an ALSA backend, after hibernation, resuming
the system causes Mumble to flood ~/.xsession-errors with ALSA
warning messages. In a few minutes, several GB of text are written,
until the partition is full.

The bug was notified upstream by someone else, with a proposed patch:
https://github.com/mumble-voip/mumble/issues/1381

I marked the bug as "important" because the flooding of the home
partition can cause important nuisances. The first time I encountered
this bug, I lost some data in other applications that had opened files.
This time, I lost Mumble's configuration (empty .config file).

Up to now, I was using kill hooks with pm-hibernate, but it seems that
`systemctl hibernate` does not run them, so my ugly hack is no more a
solution.

Regards

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

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

Versions of packages mumble depends on:
ii  gconf2 3.2.6-3
ii  libasound2 1.0.28-1
ii  libavahi-client3   0.6.31-4+b2
ii  libavahi-common3   0.6.31-4+b2
ii  libavahi-compat-libdnssd1  0.6.31-4+b2
ii  libc6  2.19-15
ii  libg15daemon-client1   1.9.5.3-8.3
ii  libgcc11:4.9.1-19
ii  libopus0   1.1-2
ii  libprotobuf9   2.6.1-1
ii  libpulse0  5.0-13
ii  libqt4-dbus4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-sql-sqlite  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-svg 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libqtgui4  4:4.8.6+git64-g5dc8b2b+dfsg-2+b1
ii  libsndfile11.0.25-9.1
ii  libspeechd20.8-7
ii  libspeex1  1.2~rc1.2-1
ii  libspeexdsp1   1.2~rc1.2-1
ii  libssl1.0.01.0.1k-1
ii  libstdc++6 4.9.1-19
ii  libx11-6   2:1.6.2-3
ii  libxi6 2:1.7.4-1+b2
ii  lsb-release4.1+Debian13+nmu1

mumble recommends no packages.

Versions of packages mumble suggests:
pn  mumble-server  
ii  speech-dispatcher  0.8-7

-- 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#774697: xmobar: Localized dates are disabled

[François Gannaz]

Package: xmobar
Severity: wishlist

Dear Maintainer,

please compile xmobar with the parameter `with_datezone`.

Currently the following configuration is not allowed with the Debian
package:

, Run DateZone "%a %F %H:%M" "fr_FR.utf8" "Europe/Paris" "date" 10

Regards

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

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

Versions of packages xmobar depends on:
ii  libc6 2.19-13
ii  libffi6   3.1-2+b2
ii  libgmp10  2:6.0.0+dfsg-6
ii  libiw30   30~pre9-8
ii  libx11-6  2:1.6.2-3
ii  libxft2   2.3.2-1
ii  libxinerama1  2:1.1.3-1+b1
ii  libxml2   2.9.1+dfsg1-4
ii  libxrandr22:1.4.2-1+b1

xmobar recommends no packages.

Versions of packages xmobar suggests:
ii  xmonad  0.11-9


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

Bug#729503: Backtrace

[François Gannaz]

Dear Maintainer,

I compiled Tellico from source (tellico-2.3.8+dfsg.2), with the symbols.
Then I run it inside gdb to get a meaningfull backtrace. I just chose a
CSV file, waited for 20 seconds with no reaction, then hit Ctrl-C.

Tellico gets stuck as soon as I choose a CSV file. The dialog window that
maps columns does not appear. It seems Tellico is lost within the
function csv_parse() of "src/3rdparty/libcsv/libcsv.c".

Regards0x00664d6b in csv_parse (p=0x2c8cd30, s=0x132eb48 "\n", len=1, 
cb1=0x5ce5e9 , cb2=0x5ce63f , 
data=0x3410430) at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/3rdparty/libcsv/libcsv.c:274
274 } else if (is_term ? is_term(c) : c == CSV_CR || c == CSV_LF) { 
/* Carriage Return or Line Feed */
(gdb) backtrace
#0  0x00664d6b in csv_parse (p=0x2c8cd30, s=0x132eb48 "\n", len=1, 
cb1=0x5ce5e9 , cb2=0x5ce63f , 
data=0x3410430) at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/3rdparty/libcsv/libcsv.c:274
#1  0x005ce55f in Tellico::CSVParser::nextTokens (this=0x3410430) at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/translators/csvparser.cpp:102
#2  0x005cc91a in Tellico::Import::CSVImporter::fillTable 
(this=0xe66480)
at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/translators/csvimporter.cpp:369
#3  0x005cd045 in Tellico::Import::CSVImporter::slotDelimiter 
(this=0xe66480)
at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/translators/csvimporter.cpp:429
#4  0x005cc7bd in Tellico::Import::CSVImporter::widget (this=0xe66480, 
parent_=0x1522070)
at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/translators/csvimporter.cpp:344
#5  0x004c78a7 in Tellico::ImportDialog::ImportDialog 
(this=0x7fffcb00, format_=Tellico::Import::CSV, urls_=..., parent_=0xb77f00)
at /home//src/Tellico/tellico-2.3.8+dfsg.2/src/importdialog.cpp:110
#6  0x004e0e56 in Tellico::MainWindow::importFile (this=0xb77f00, 
format_=Tellico::Import::CSV, urls_=...)
at /home//src/Tellico/tellico-2.3.8+dfsg.2/src/mainwindow.cpp:2155
#7  0x004de7b0 in Tellico::MainWindow::slotFileImport (this=0xb77f00, 
format_=3) at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/src/mainwindow.cpp:1749
#8  0x004e18e6 in Tellico::MainWindow::qt_static_metacall (_o=0xb77f00, 
_c=QMetaObject::InvokeMetaMethod, _id=26, _a=0x7fffcd70)
at 
/home//src/Tellico/tellico-2.3.8+dfsg.2/obj-x86_64-linux-gnu/src/mainwindow.moc:182
#9  0x71d3f77a in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#10 0x71d46ebe in QSignalMapper::mapped(int) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#11 0x71d46fc6 in QSignalMapper::map(QObject*) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#12 0x71d3f77a in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#13 0x7272a572 in QAction::triggered(bool) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#14 0x7272bf43 in QAction::activate(QAction::ActionEvent) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#15 0x72b562f9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#16 0x72b5a829 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#17 0x77a68ac5 in KMenu::mouseReleaseEvent(QMouseEvent*) () from 
/usr/lib/libkdeui.so.5
#18 0x7277fc9a in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#19 0x72b5e62b in QMenu::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#20 0x727306cc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#21 0x72736e7d in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x779b249a in KApplication::notify(QObject*, QEvent*) () from 
/usr/lib/libkdeui.so.5
#23 0x71d2b4ed in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x72736633 in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#25 0x727a862c in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#26 0x727a6d6c in QApplication::x11ProcessEvent(_XEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#27 0x727ce6c2 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#28 0x7fffeb644e04 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x7fffeb645048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x7fffeb6450ec in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x71d58746 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#32 0x000

Bug#711329: chktex: ChkTeX complains about ASC codes of character I don't type

[François Gannaz]

Package: chktex
Version: 1.7.2-1
Followup-For: Bug #711329

Dear Maintainer,

I suffer from the same problem: chktex warns about a bad apostrophe
on each line that contains a "ô" character. My files are encoded with
UTF-8. I suppose UTF-8's "ô" share a byte with the offending apostrophe
in some encoding that is hardcoded into chktex.

To mitigate this bug, I disabled this particular check.
My $HOME/.chktexrc contains:

```
CmdLine
{
-n19
}
```

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

Kernel: Linux 3.4.74-fg (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored:
LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash

Versions of packages chktex depends on:
ii  libc6  2.17-97
ii  libpcre3   1:8.31-2
ii  libtinfo5  5.9+20140118-1


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

Bug#729503: tellico: Import CSV from the menu hangs on loading the file

[François Gannaz]

My bad. Here is the file.ISBN#
978-2-253-15781-6

Bug#729503: tellico: Import CSV from the menu hangs on loading the file

[François Gannaz]

Package: tellico
Version: 2.3.8+dfsg.1-2
Severity: normal

Dear Maintainer,

I select the entry "Import CSV data..." from the "File" menu,
then I select a file, then tellico hangs.
Tested with several CSV files.

One core reports an activity of 100%, and ltrace seems to point out
an infinite loop on reading lines of the file.

Regards


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

Kernel: Linux 3.4.68-fg (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages tellico depends on:
ii  kde-runtime4:4.10.5-1
ii  libc6  2.17-93
ii  libexempi3 2.2.1-1
ii  libkabc4   4:4.10.5-1
ii  libkcal4   4:4.10.5-1
ii  libkcddb4  4:4.10.5-1
ii  libkdecore54:4.10.5-1+b1
ii  libkdeui5  4:4.10.5-1+b1
ii  libkhtml5  4:4.10.5-1+b1
ii  libkio54:4.10.5-1+b1
ii  libknewstuff3-44:4.10.5-1+b1
ii  libkparts4 4:4.10.5-1+b1
ii  libkresources4 4:4.10.5-1
ii  libksane0  4:4.10.5-1
ii  libkxmlrpcclient4  4:4.10.5-1
ii  libnepomuk44:4.10.5-1+b1
ii  libpoppler-qt4-3   0.18.4-8
ii  libqimageblitz41:0.0.6-4
ii  libqjson0  0.8.1-3
ii  libqt4-dbus4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqt4-network 4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqt4-xml 4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqtcore4 4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqtgui4  4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libsolid4  4:4.10.5-1+b1
ii  libstdc++6 4.8.2-1
ii  libtag1c2a 1.8-dmo1
ii  libxml22.9.1+dfsg1-3
ii  libxslt1.1 1.1.28-2
ii  libyaz44.2.30-2.1
ii  tellico-data   2.3.8+dfsg.1-2
ii  tellico-scripts2.3.8+dfsg.1-2

Versions of packages tellico recommends:
pn  khelpcenter4  
pn  tellico-doc   

tellico 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#729499: tellico: segfaults on each CSV import by CLI (option --ris)

[François Gannaz]

Package: tellico
Version: 2.3.8+dfsg.1-2
Severity: normal

Dear Maintainer,

here is the command I used: tellico --nocrashhandler --nofile --ris t.csv

It segfaults almost immediately after displaying the application window.
Tested with several CSV files, including some exported from Tellico.
Here is an sample file:

ISBN#
978-2-253-15781-6

I also ran tellico under ltrace: the crash occurs very soon after
each line of the file has been read.
I haven't seen any tellico-dbg package, so I don't how to produce
better information on this bug.

Regards


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

Kernel: Linux 3.4.68-fg (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored:
LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash

Versions of packages tellico depends on:
ii  kde-runtime4:4.10.5-1
ii  libc6  2.17-93
ii  libexempi3 2.2.1-1
ii  libkabc4   4:4.10.5-1
ii  libkcal4   4:4.10.5-1
ii  libkcddb4  4:4.10.5-1
ii  libkdecore54:4.10.5-1+b1
ii  libkdeui5  4:4.10.5-1+b1
ii  libkhtml5  4:4.10.5-1+b1
ii  libkio54:4.10.5-1+b1
ii  libknewstuff3-44:4.10.5-1+b1
ii  libkparts4 4:4.10.5-1+b1
ii  libkresources4 4:4.10.5-1
ii  libksane0  4:4.10.5-1
ii  libkxmlrpcclient4  4:4.10.5-1
ii  libnepomuk44:4.10.5-1+b1
ii  libpoppler-qt4-3   0.18.4-8
ii  libqimageblitz41:0.0.6-4
ii  libqjson0  0.8.1-3
ii  libqt4-dbus4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqt4-network 4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqt4-xml 4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqtcore4 4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libqtgui4  4:4.8.5+git121-g2a9ea11+dfsg1-2
ii  libsolid4  4:4.10.5-1+b1
ii  libstdc++6 4.8.2-1
ii  libtag1c2a 1.8-dmo1
ii  libxml22.9.1+dfsg1-3
ii  libxslt1.1 1.1.28-2
ii  libyaz44.2.30-2.1
ii  tellico-data   2.3.8+dfsg.1-2
ii  tellico-scripts2.3.8+dfsg.1-2

Versions of packages tellico recommends:
pn  khelpcenter4  
pn  tellico-doc   

tellico 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#686454: CVE-2011-5129: xchat buffer overflow

[François Gannaz]

Hi,

I can't reproduce this bug on my amd64 testing debian, using XFCE and
xchat 2.8.8-6.

With the "proof of concept" script referenced in the CVE, I get no crash.
Only the following line on STDERR repeated thousands of times:
*** XCHAT WARNING: Buffer overflow - shit server!

The part of the code that handles this security concern is:
http://xchat.svn.sourceforge.net/viewvc/xchat/src/common/server.c?revision=1502&view=markup#l410
It first fills a buffer with recv() from sys/socket, then reads it char
by char untill the destination is full (line 472).

Hope that helps


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

Bug#613602: reminiscence: Crash at menu "start" with the message "Bad CRC for collision data"

[François Gannaz]

Package: reminiscence
Version: 0.1.9-1
Severity: important
Tags: patch

On an amd64 debian, I can start the application, but each time I select
"start" in the menu, it crashes with the message: "Bad CRC for collision
data".

This bug is known and fixed in Gentoo, see
http://bugs.gentoo.org/show_bug.cgi?id=120787
I took part of their patch (see comment #5 in the above link) and
completed it to avoid a few compilation warnings.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (600, 'stable'), (500, 'oldstable'), (300, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.36.3-fg
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages reminiscence depends on:
ii  libc6   2.11.2-10Embedded GNU C Library: Shared lib
ii  libgcc1 1:4.4.5-10   GCC support library
ii  libsdl1.2debian 1.2.14-6.1   Simple DirectMedia Layer
ii  libstdc++6  4.4.5-10 The GNU Standard C++ Library v3
ii  perl5.10.1-17Larry Wall's Practical Extraction 
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

reminiscence recommends no packages.

reminiscence suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/games/rs (from reminiscence package)
diff -r e133af627c1c game.cpp
--- a/game.cpp	Tue Feb 15 23:39:22 2011 +0100
+++ b/game.cpp	Wed Feb 16 01:15:23 2011 +0100
@@ -292,7 +292,7 @@ void Game::drawCurrentInventoryItem() {
 void Game::showFinalScore() {
 	playCutscene(0x49);
 	char textBuf[50];
-	sprintf(textBuf, "SCORE %08lu", _score);
+	sprintf(textBuf, "SCORE %08lu", (unsigned long)_score);
 	_vid.drawString(textBuf, (256 - strlen(textBuf) * 8) / 2, 40, 0xE5);
 	strcpy(textBuf, _menu._passwords[7][_skillLevel]);
 	_vid.drawString(textBuf, (256 - strlen(textBuf) * 8) / 2, 16, 0xE7);
@@ -425,7 +425,7 @@ bool Game::handleContinueAbort() {
 		_vid.drawString(str, (256 - strlen(str) * 8) / 2, 104, colors[0]);
 		str = _res.getMenuString(LocaleData::LI_04_ABORT);
 		_vid.drawString(str, (256 - strlen(str) * 8) / 2, 112, colors[1]);
-		sprintf(textBuf, "SCORE  %08lu", _score);
+		sprintf(textBuf, "SCORE  %08lu", (unsigned long)_score);
 		_vid.drawString(textBuf, 64, 154, 0xE3);
 		if (_stub->_pi.dirMask & PlayerInput::DIR_UP) {
 			_stub->_pi.dirMask &= ~PlayerInput::DIR_UP;
@@ -1292,7 +1292,7 @@ void Game::handleInventory() {
 }
 			} else {
 char textBuf[50];
-sprintf(textBuf, "SCORE %08lu", _score);
+sprintf(textBuf, "SCORE %08lu", (unsigned long)_score);
 _vid.drawString(textBuf, (114 - strlen(textBuf) * 8) / 2 + 72, 158, 0xE5);
 sprintf(textBuf, "%s:%s", _res.getMenuString(LocaleData::LI_06_LEVEL), _res.getMenuString(LocaleData::LI_13_EASY + _skillLevel));
 _vid.drawString(textBuf, (114 - strlen(textBuf) * 8) / 2 + 72, 166, 0xE5);
diff -r e133af627c1c sys.h
--- a/sys.h	Tue Feb 15 23:39:22 2011 +0100
+++ b/sys.h	Wed Feb 16 01:15:23 2011 +0100
@@ -19,12 +19,14 @@
 #ifndef __SYS_H__
 #define __SYS_H__
 
-typedef unsigned char uint8;
-typedef signed char int8;
-typedef unsigned short uint16;
-typedef signed short int16;
-typedef unsigned long uint32;
-typedef signed long int32;
+#include 
+
+typedef uint8_t uint8;
+typedef int8_t int8;
+typedef uint16_t uint16;
+typedef int16_t int16;
+typedef uint32_t uint32;
+typedef int32_t int32;
 
 inline uint16 READ_BE_UINT16(const void *ptr) {
 	const uint8 *b = (const uint8 *)ptr;

Bug#499399: phpmyadmin: Ignores LoginCookieValidity

[François Gannaz]

Hi Thijs

Le sam 20 sep 12:49, Thijs Kinkhorst a écrit :
> 
> Thank you for your report. I looked into this, but could confirm that setting 
> LoginCookieValidity in /etc/phpmyadmin/config.inc.php does indeed cause that 
> information to end up in the appropriate function.
> 
> Are you sure that your PHP configuration doesn't clean up the session before 
> the timeout happens? Check the session session.gc_maxlifetime parameter 
> in /etc/php5/*/php.ini, Could you check for me what value it has and if 
> raising the value (and restarting Apache) has any effect?

Thank you for taking time in investigating this. That's right, my global
php.ini sets this parameter to 1800.

But phpMyAdmin doesn't have to follow this default parameter. IIRC, it
can use ini_set() to locally change the value of session.gc_maxlifetime.
If it doesn't, it should at least mention this in its user
documentation.

If phpMyAdmin uses the default session parameters (lifetime, path,
handler...) then any php application running on the same server can
delete its sessions anytime. I still think it's a bug, or at least a
lacking feature.

Thanks again
--
François



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#499399: phpmyadmin: Ignores LoginCookieValidity

[François Gannaz]

Package: phpmyadmin
Version: 4:2.11.8.1-1
Severity: normal

phpMyAdmin ignores the configuration parameters that extend the duration
of a session.

In my /et/phpmyadmin/config.inc.php:
$cfg['Servers'][$i]['LoginCookieValidity'] = 72000; // 20 h
$cfg['LoginCookieValidity'] = 72000; // 20 h

But I still get disconnected after 1800 s (30 minutes). I also tried to
change the 'LoginCookieStore' parameter, or to use another browser
(firefox 3, opera 9.52).

I could reproduce this on another lenny. I googled for it, and some
Ubuntu fellows seem to have the same problem:
http://ubuntuforums.org/showthread.php?t=743991

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (600, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.25.16-FG
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages phpmyadmin depends on:
ii  debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii  libapache2-mod-php5   5.2.6-3server-side, HTML-embedded scripti
ii  perl  5.10.0-13  Larry Wall's Practical Extraction 
ii  php5-mcrypt   5.2.6-3MCrypt module for php5
ii  php5-mysql5.2.6-3MySQL module for php5

Versions of packages phpmyadmin recommends:
ii  apache2   2.2.9-7Apache HTTP Server metapackage
ii  apache2-mpm-prefork [httpd]   2.2.9-7Apache HTTP Server - traditional n
ii  php5-gd   5.2.6-3GD module for php5

Versions of packages phpmyadmin suggests:
ii  mysql-server  5.0.51a-12 MySQL database server (metapackage
ii  mysql-server-5.0 [mysql-serve 5.0.51a-12 MySQL database server binaries

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]