Bug#855434: chromium: Invalid SSL connection failure
This recent upstream report seems to be about the same problem: https://bugs.chromium.org/p/chromium/issues/detail?id=693943 A suggested solution in that thread, disabling TLS 1.3, works on my system running Debian 8.7 and Chromium 56.0.2924.76-1~deb8u1.
Bug#779427: geeqie: Esc in Really continue? copy confirmation dialog leads to crash
Package: geeqie Version: 1:1.2-3+b1 Severity: normal Dear Maintainer, Geeqie shows incorrect behavior and later crashes every time I perform the following steps: 1. Open the Copy files? dialog to copy an image file. 2. Choose a directory which already contains a file with the same name, such as the same directory. 3. A Really continue? confirmation dialog appears. Cancel this with the Esc key. (If I cancel it with the Cancel button, either with the mouse or with Alt-C, I don't observe any problems.) 4. Now we're back to the Copy files? dialog. Cancel this dialog. Now, I'm shown the Really continue? dialog again, even though I had chosen to cancel, not continue. This time, this dialog can't be closed with Esc. After canceling this dialog, Geeqie crashes. Sometimes the crash is immediate; sometimes it comes later, such as when browsing through images, or when closing Geeqie. Attached are two gdb traces of runs where I reproduced the crash. Thanks, - Daniel Getz -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages geeqie depends on: ii geeqie-common1:1.2-3 ii libatk1.0-0 2.14.0-1 ii libc62.19-15 ii libcairo21.14.0-2.1 ii libexiv2-13 0.24-4.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-2 ii libgcc1 1:4.9.1-19 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libjpeg62-turbo 1:1.3.1-11 ii liblcms2-2 2.6-3+b3 ii liblircclient0 0.9.0~pre1-1.2 ii liblua5.1-0 5.1.5-7.1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libstdc++6 4.9.1-19 ii libtiff5 4.0.3-12.1 Versions of packages geeqie recommends: ii exiftran 2.09-1+b1 ii exiv20.24-4.1 ii imagemagick 8:6.8.9.9-5 ii librsvg2-common 2.40.5-1 pn lpr none pn ufraw-batch none ii zenity 3.14.0-1 Versions of packages geeqie suggests: ii geeqie-dbg 1:1.2-3+b1 ii gimp 2.8.14-1+b1 ii libjpeg-turbo-progs [libjpeg-progs] 1:1.3.1-11 pn ufrawnone pn xpaint none -- no debconf information Starting program: /usr/bin/geeqie [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7fffee1e5700 (LWP 3155)] [New Thread 0x7fffed6f0700 (LWP 3156)] Program received signal SIGSEGV, Segmentation fault. 0x77531ea7 in gdk_event_translate (display=0x779020, event=0xac82a0, xevent=0x7fffdf00, return_exposes=11847440, return_exposes@entry=0) at /build/gtk+2.0-Gthrko/gtk+2.0-2.24.25/gdk/x11/gdkevents-x11.c:966 966 /build/gtk+2.0-Gthrko/gtk+2.0-2.24.25/gdk/x11/gdkevents-x11.c: No such file or directory. (gdb) thread apply all bt Thread 3 (Thread 0x7fffed6f0700 (LWP 3156)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x75ebe657 in g_cond_wait_until (cond=cond@entry=0xa56638, mutex=mutex@entry=0xa56630, end_time=end_time@entry=3442502005) at /tmp/buildd/glib2.0-2.42.1/./glib/gthread-posix.c:1443 #2 0x75e4ea69 in g_async_queue_pop_intern_unlocked (queue=queue@entry=0xa56630, wait=wait@entry=1, end_time=end_time@entry=3442502005) at /tmp/buildd/glib2.0-2.42.1/./glib/gasyncqueue.c:422 #3 0x75e4f08b in g_async_queue_timeout_pop (queue=0xa56630, timeout=timeout@entry=1500) at /tmp/buildd/glib2.0-2.42.1/./glib/gasyncqueue.c:543 #4 0x75ea138c in g_thread_pool_wait_for_new_pool () at /tmp/buildd/glib2.0-2.42.1/./glib/gthreadpool.c:167 #5 g_thread_pool_thread_proxy (data=optimized out) at /tmp/buildd/glib2.0-2.42.1/./glib/gthreadpool.c:364 #6 0x75ea0935 in g_thread_proxy (data=0x8f4770) at /tmp/buildd/glib2.0-2.42.1/./glib/gthread.c:764 #7 0x73cfb0a4 in start_thread (arg=0x7fffed6f0700) at pthread_create.c:309 #8 0x73a3004d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7fffee1e5700 (LWP 3155)): #0 0x73a2750d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x75e79ee4 in g_main_context_poll (priority=2147483647, n_fds=2, fds=0x7fffe80010e0, timeout=-1, context=0x7d1aa0) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:4076 #2 g_main_context_iterate (context=0x7d1aa0, block=block@entry=1, dispatch=dispatch@entry=1, self=optimized out) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3776 #3 0x75e7a272 in g_main_loop_run (loop=0xa11c30) at /tmp/buildd/glib2.0-2.42.1/./glib
Bug#768127: Fails to build the index when invalid UTF-8 is met
On Thu, Dec 18, 2014 at 4:30 PM, Yavor Doganov ya...@gnu.org wrote:
It seems that there are two different problems -- Santiago's failure
that he posted on the bug log is at dhelp.rb:185 while mine is at
debian.rb:914 (which is why I suggested it might be a ruby-debian
issue). If you and Daniel have reproduced and fixed Santiago's bug it
is not surprising that the NMU does not address the bug I am
observing. (At least that is how I explain the mystery for the time
being, with my limited knowledge.)
Yes, that's my understanding, too.
Can you run with the attached patch to debian.rb, and see if it will show
which entry of which file triggers the error?
--- /usr/lib/ruby/vendor_ruby/debian.rb.orig 2014-12-18 19:01:03.233496178 -0100
+++ /usr/lib/ruby/vendor_ruby/debian.rb.debug 2014-12-18 19:00:26.229041877 -0100
@@ -911,7 +911,14 @@
@provides = {}
@file = [file]
@lists = Archives.parseArchiveFile(file) {|info|
-info =~ /Package:\s(.*)$/;
+ begin
+ info =~ /Package:\s(.*)$/;
+rescue = e
+ puts Error parsing file #{file}
+ puts Contents of info:
+ puts info
+ raise e
+end
if pkgs.empty? || pkgs.include?($1)
d = Deb.new(info,fields)
add_provides(d)
Bug#768127: Fails to build the index when invalid UTF-8 is met
On Thu, Dec 18, 2014 at 8:49 PM, gregor herrmann gre...@debian.org wrote: Ok, so what are we doing now? While I would like dhelp to handle this situation a bit more gracefully, I suggest to downgrade the severity of the bug since it shouldn't affect anyone running packages contained in recent and upcoming Debian releases, and keeping it out of jessie for these cornercases seems a bit to strong for me. (Of course a fix would be best :)) In terms of fixing dhelp, we could in theory catch the UTF-8 error, log a warning somehow, and continue on to the next package description. One missing package from the documentation index isn't the end of the world (and in my experience, dhelp doesn't index all my HTML documentation anyway.) However, the code in question is in ruby-debian, which is a separate library used by other packages. Might not be correct behavior for other users of the library?
Bug#768127: Fails to build the index when invalid UTF-8 is met
UTF-8 should be the right format for doc-base files, according to https://lintian.debian.org/tags/doc-base-file-uses-obsolete-national-encoding.html I also don't know ruby, but from my research setting Encoding.default_external is considered the wrong thing to do, the right way being to pass -E UTF-8 as an option to ruby via the command line, or the environment variable RUBYOPT. I had to explicitly silence a warning because of this. See http://docs.ruby-lang.org/en/2.1.0/Encoding.html#method-c-default_external-3D However, neither of those right ways to set the encoding work well with using a ruby file directly as a script. (Is ruby not intended to be used in scripts?!) In the ruby docs, it says the problem is if code gets run before the change to the encoding. That's avoidable, and I believe I avoided it in my patch by placing the encoding change before any require imports. An alternative is to explicitly set the encoding to UTF-8 each time a file is opened. If someone feels that's a better way, I'm willing to do that and create a new patch. But like I said, I don't know ruby, so I can't guarantee correctness beyond trying it and seeing that it works. - Dan On Sun, Dec 7, 2014 at 2:06 PM, gregor herrmann gre...@debian.org wrote: Control: tag -1 - moreinfo Control: tag -1 + confirmed On Sat, 06 Dec 2014 01:33:58 -0100, Daniel Getz wrote: I can reproduce the problem with LC_ALL=C LANG=C /etc/cron.weekly/dhelp Attached is a diff with a change to dhelp_parse.rb which sets Encoding.default_external explicitly, so that even if LANG=C, it uses UTF-8 instead of US-ASCII as the default for opening files. By my (limited) understanding of Encoding.default_external, this should have the same effect on opening files as replacing LANG=C with LANG=xx_XX.UTF-8 would. On my machine, without the patch, I see the same errors with LANG=C as the others here. With the patch, I do not. Works for me as well. Since I don't speak any ruby I'm a bit hesitant to upload; maybe some ruby speaker knowing Encoding.default_external can confirm that's the correct way forwards? (And: Are we sure all doc-base files are us-ascii or utf-8 encoded? At least on my machine they are, so maybe that's a non-concern.) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Treibhaus: Yellowman Jamaica -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJUhGzpXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoG/LMP/2o9yR4MuLwI+uxzEq0sgiPW wz5K4/+98llYpEnHrcEzWIp5sdJF3NkMqEr8eqtycOUUdLismSp3MeH7DByxQX9H to/qFXpwM+qTf6dLiNrQykQzkBI+kTg7SszslTIdNbrOqSDR9UGOSZs2IX3OoKac N/651M1MfPz6EuyVehUEeLchUJWaiqz+XpLblV10FjnH8UxUzeMg6Dck7bYpGAuT +PLfNrurXx1ldoCkoqaCwCzBbKb0ZBu8A0AzdfgWUeudXwmgIF+u0Fs0rQMqUifS +QfcS0lMFAxBTBIimDogoyteLhxgE9OaNGqizZv2/xQPPvXOTrzF7BlKSr5SLWw0 A73YqAhrzU0Rxawl6i7+eKyEYUt59Cc7mJWAKCJ8o10QipDid90GPAJ78Rmjxo8W aWb/zGu/DJ70e+D1WEZ+VEwDQs6LgpibY10cjkLOH813b62DahDh9vuHIgvIc7Xa 3naQRh626lAmpxdCqqDobxMa3o8M2tcbqrIFrQRq69VarW2eDXJVT/MoCUy+vjCS Qu5t5vCX+qONuxYnGUAiHsnk7eSGh52EOUtaXjYFvqUA6YWFkSfy0+apaFD1nlj9 H93c1xAFfDFbE4Aue9oxIenIVXMEH/KtPqYikt0ApHH/IcYiMDc3nGNhUUL4Nvyc WuWu7s3lZpbMnI0Cgzly =pVVw -END PGP SIGNATURE-
Bug#768127: Fails to build the index when invalid UTF-8 is met
Attached is a diff with a change to dhelp_parse.rb which sets
Encoding.default_external explicitly, so that even if LANG=C, it uses UTF-8
instead of US-ASCII as the default for opening files. By my (limited)
understanding of Encoding.default_external, this should have the same
effect on opening files as replacing LANG=C with LANG=xx_XX.UTF-8 would.
On my machine, without the patch, I see the same errors with LANG=C as the
others here. With the patch, I do not.
Hope to help,
- Dan Getz
diff -Nru dhelp-0.6.21+nmu5/debian/changelog dhelp-0.6.21+nmu6/debian/changelog
--- dhelp-0.6.21+nmu5/debian/changelog 2014-10-15 06:35:28.0 -0100
+++ dhelp-0.6.21+nmu6/debian/changelog 2014-12-06 01:05:28.0 -0100
@@ -1,3 +1,10 @@
+dhelp (0.6.21+nmu6) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Load files as UTF-8, regardless of $LANG
+
+ -- Dan Getz tank...@gmail.com Sat, 06 Dec 2014 00:41:01 -0100
+
dhelp (0.6.21+nmu5) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru dhelp-0.6.21+nmu5/src/dhelp_parse.rb
dhelp-0.6.21+nmu6/src/dhelp_parse.rb
--- dhelp-0.6.21+nmu5/src/dhelp_parse.rb2014-10-15 06:12:27.0
-0100
+++ dhelp-0.6.21+nmu6/src/dhelp_parse.rb2014-12-06 01:05:04.0
-0100
@@ -24,6 +24,11 @@
PREFIX = '/usr'
DEFAULT_INDEX_ROOT = #{PREFIX}/share/doc/HTML
+# Set default file format as UTF-8, without printing a warning
+old_verbose, $VERBOSE = $VERBOSE, false
+Encoding.default_external = UTF-8
+$VERBOSE = old_verbose
+
require 'dhelp'
require 'dhelp/exporter/html'
include Dhelp
