Bug#1063941: libvte-2.91-common: /etc/profile.d/vte-2.91.sh dereferences undefined PS0
Package: libvte-2.91-common
Version: 0.75.91-2
Severity: important
Tags: patch
Dear Maintainer,
At the start of my $HOME/.bashrc I have configured "set -u" to catch the
use of undefined variables.
Whenever I open a new gnome-terminal window using bash as the shell, the
script vte-2.91.sh will emit two messages about dereferencing an
undefined variable PS0.
This is a recent regression and similar in nature to the earlier
bug #941247 that has been fixed.
The script appears to be part of the Debian packaging; I do not find it in
the upstream repository https://gitlab.gnome.org/GNOME/vte/-/tree/master
The attached patch fixes the problem for me. I think that it would be good
to test the script with "set -u" somehow, to prevent future regressions
like this.
Best regards,
Marko
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.15-amd64 (SMP w/40 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libvte-2.91-common depends on:
ii libc6 2.37-15
libvte-2.91-common recommends no packages.
libvte-2.91-common suggests no packages.
-- Configuration Files:
/etc/profile.d/vte-2.91.sh changed [not included]
-- no debconf information
--- /etc/profile.d/vte-2.91.sh
+++ /etc/profile.d/vte-2.91.sh
@@ -80,7 +80,7 @@
# the column, important for handling TAB followed by BS keypresses.
# Prepend to the user's PS0 to preserve whether it ends in '\r'.
# Note that bash doesn't support the \[ \] markers here.
-PS0='\e]133;C\e\\\r'"$PS0"
+PS0='\e]133;C\e\\\r'"${PS0:-}"
fi
elif [[ -n "${ZSH_VERSION:-}" ]]; then
Bug#1008750: Workaround: Disable VGA on the motherboard
The problem appears to be that a built-in unaccelerated graphics adapter
exists on the motherboard.
Adding file /etc/udev/rules.d/83-card0.rules
with the following contents allows GNOME to start on Wayland:
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x1a03", ATTR{class}=="0x03",
ATTR{remove}="1"
Some possibly relevant kernel startup messages (from dmesg) are as
follows:
[0.596600] pci :0a:00.0: vgaarb: VGA device added:
decodes=io+mem,owns=none,locks=none
[0.596600] pci :81:00.0: vgaarb: setting as boot VGA device
[0.596600] pci :81:00.0: vgaarb: VGA device added:
decodes=io+mem,owns=io+mem,locks=none
[0.596600] pci :0a:00.0: vgaarb: bridge control possible
[0.596600] pci :81:00.0: vgaarb: bridge control possible
[0.596600] vgaarb: loaded
...
[1.266286] efifb: probing for efifb
[1.266292] pmd_set_huge: Cannot satisfy [mem 0xe000-0xe020] with a h
uge-page mapping due to MTRR override.
[1.266304] efifb: framebuffer at 0xe000, using 8128k, total 8128k
[1.266306] efifb: mode is 1920x1080x32, linelength=7680, pages=1
[1.266307] efifb: scrolling: redraw
[1.266308] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[1.266434] Console: switching to colour frame buffer device 240x67
[1.270104] fb0: EFI VGA frame buffer device
...
[1.820564] checking generic (e000 7f) vs hw (c400 200)
[1.820589] ast :0a:00.0: enabling device ( -> 0003)
[1.820726] ast :0a:00.0: [drm] Using P2A bridge for configuration
[1.820729] ast :0a:00.0: [drm] AST 2400 detected
[1.820740] ast :0a:00.0: [drm] Analog VGA only
[1.820747] ast :0a:00.0: [drm] dram MCLK=408 Mhz type=6 bus_width=16
[1.821073] [drm] Initialized ast 0.1.0 20120228 for :0a:00.0 on minor 0
[1.825665] checking generic (e000 7f) vs hw (0 0)
[1.825787] ast :0a:00.0: [drm] fb1: astdrmfb frame buffer device
[1.900752] [drm] amdgpu kernel modesetting enabled.
[1.900933] amdgpu: CRAT table not found
[1.900936] amdgpu: Virtual CRAT table created for CPU
[1.900966] amdgpu: Topology: Add CPU node
[1.901234] checking generic (e000 7f) vs hw (e000 1000)
[1.901242] checking generic (e000 7f) vs hw (e000 1000)
[1.901245] fb0: switching to amdgpu from EFI VGA
[1.901428] Console: switching to colour dummy device 80x25
[1.901491] amdgpu :81:00.0: vgaarb: deactivate vga console
With best regards,
Marko
Bug#1008750: gnome-shell: SIGSEGV in libgbm1 prevents gdm3 Wayland startup
Package: gnome-shell Version: 42.0-2 Severity: important Dear Maintainer, For a long time, gdm3 has not let me choose a Wayland session. I finally decided to debug it, and the reason is that gnome-shell is crashing with SIGSEGV. So, gdm3 will silently fall back to X.org and not present any Wayland option. I installed systemd-coredump and a few debug symbol packages, to get a stack trace of the crashing thread in gnome-shell: #0 0x in () #1 0x7f15938eebf1 in gbm_dri_bo_import (gbm=0x556b52505cd0, type=, buffer=0x7ffc7a15eb80, usage=1) at ../src/gbm/backends/dri/gbm_dri.c:1026 #2 0x7f15970ef997 in dmabuf_to_gbm_bo (format=, stride=, height=, width=, dmabuf_fd=72, importer=0x556b52505cd0) at ../src/backends/native/meta-drm-buffer-import.c:132 #3 import_gbm_buffer (error=0x7ffc7a15ed90, importer=0x556b52505cd0, buffer_import=0x7f15840762b0 [MetaDrmBufferImport]) at ../src/backends/native/meta-drm-buffer-import.c:166 #4 meta_drm_buffer_import_new (device_file=device_file@entry=0x556b524bab50, gbm_device=0x556b52505cd0, buffer_gbm=, error=error@entry=0x7ffc7a15ed90) at ../src/backends/native/meta-drm-buffer-import.c:210 #5 0x7f159710995a in meta_render_device_gbm_import_dma_buf (render_device=, buffer=0x556b540eec90 [MetaDrmBufferGbm], error=0x7ffc7a15ed90) at ../src/backends/native/meta-render-device-gbm.c:101 #6 0x7f15971078ea in import_shared_framebuffer (secondary_gpu_state=0x556b5260daa0, onscreen=0x556b525e42d0 [MetaOnscreenNative]) at ../src/backends/native/meta-onscreen-native.c:588 #7 update_secondary_gpu_state_post_swap_buffers (egl_context_changed=, onscreen=0x556b525e42d0 [MetaOnscreenNative]) at ../src/backends/native/meta-onscreen-native.c:987 #8 meta_onscreen_native_swap_buffers_with_damage (onscreen=, rectangles=0x7ffc7a15ee50, n_rectangles=0, frame_info=0x556b53e2a0d0, user_data=0x7ffc7a15f070) at ../src/backends/native/meta-onscreen-native.c:1112 #9 0x7f1596a70ffd in cogl_onscreen_swap_buffers_with_damage (onscreen=onscreen@entry=0x556b525e42d0 [MetaOnscreenNative], rectangles=rectangles@entry=0x7ffc7a15ee50, n_rectangles=n_rectangles@entry=0, info=info@entry=0x556b53e2a0d0, user_data=user_data@entry=0x7ffc7a15f070) at ../cogl/cogl/cogl-onscreen.c:337 #10 0x7f1597019c92 in swap_framebuffer (stage_window=stage_window@entry=0x556b52501290, stage_view=stage_view@entry=0x556b525e7210 [MetaRendererView], swap_region=swap_region@entry=0x556b54704370, swap_with_damage=swap_with_damage@entry=0, frame=frame@entry=0x7ffc7a15f070) at ../src/backends/meta-stage-impl.c:306 #11 0x7f159701a581 in meta_stage_impl_redraw_view_primary (frame=0x7ffc7a15f070, stage_view=, stage_impl=) at ../src/backends/meta-stage-impl.c:665 #12 meta_stage_impl_redraw_view (stage_window=, stage_view=, frame=0x7ffc7a15f070) at ../src/backends/meta-stage-impl.c:736 #13 0x7f1597114ef7 in meta_stage_native_redraw_view (stage_window=, view=0x556b525e7210 [MetaRendererView], frame=0x7ffc7a15f070) at ../src/backends/native/meta-stage-native.c:139 #14 0x7f15972a9283 in handle_frame_clock_frame (frame_clock=0x556b525e8260 [ClutterFrameClock], frame_count=, user_data=0x556b525e7210) at ../clutter/clutter/clutter-stage-view.c:1191 #15 0x7f1597278a35 in clutter_frame_clock_dispatch (time_us=3057569224, frame_clock=0x556b525e8260 [ClutterFrameClock]) at ../clutter/clutter/clutter-frame-clock.c:701 #16 frame_clock_source_dispatch (source=, callback=, user_data=) at ../clutter/clutter/clutter-frame-clock.c:751 #17 0x7f1597d31f8b in g_main_dispatch (context=0x556b52426920) at ../../../glib/gmain.c:3417 #18 g_main_context_dispatch (context=0x556b52426920) at ../../../glib/gmain.c:4135 #19 0x7f1597d32238 in g_main_context_iterate (context=0x556b52426920, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4211 #20 0x7f1597d32523 in g_main_loop_run (loop=0x556b53a705e0) at ../../../glib/gmain.c:4411 #21 0x7f1597060a85 in meta_context_run_main_loop (context=, error=0x7ffc7a15f2e0) at ../src/core/meta-context.c:437 #22 0x556b51716931 in () #23 0x7f1596dc87fd in __libc_start_main (main=0x556b51716500, argc=1, argv=0x7ffc7a15f428, init=, fini=, rtld_fini=, stack_end=0x7ffc7a15f418) at ../csu/libc-start.c:332 #24 0x556b51716bda in () The crash probably is nothing new; I have experienced the lack of Wayland for several months if not a couple of years. Only once when I used a 5.15 pre-release kernel several months ago, gdm3 allowed me to use Wayland. Back then, I was normally using a Debian package of a 5.14 kernel. The kernel that I am currently using is one that I built from the source (tag: v5.17). The GPU is reported by "dmesg" as follows: [1.740044] [drm] amdgpu kernel modesetting enabled. [1.740198] amdgpu: CRAT table not found [1.740202] amdgpu: Virtual CRAT table created for CPU [1.740223] amdgpu: Topology: Add CPU node [
Bug#980110: gcc-10: The Debian addition --as-needed breaks -fsanitize=address
Package: gcc-10
Version: 10.2.1-6
Severity: normal
Dear Maintainer,
A program that uses the crypt() function will report SIGSEGV
due to jumping to address 0 when the program is compiled with
-fsanitize=address. This problem is not repeatable when using
the default options of upstream GCC
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98669 for
their resolution), nor with gcc-9.
Here is what I did:
cat > crypt.c << EOF
#include
#include
int main (int argc, char **argv)
{
puts(crypt(*argv, "salt"));
}
EOF
gcc -fsanitize=address crypt.c -lcrypt
./a.out
AddressSanitizer:DEADLYSIGNAL
=
==664877==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x bp 0x7fffb2b2b970 sp 0x7fffb2b2b958 T0)
==664877==Hint: pc points to the zero page.
==664877==The signal is caused by a READ memory access.
==664877==Hint: address points to the zero page.
#0 0x0 ()
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ()
==664877==ABORTING
I expected the program to terminate successfully, like this:
gcc-9 -fsanitize=address crypt.c -lcrypt && ./a.out
sasWQy9ecMDEs
(Same thing if I compile it with clang-10 or clang-11.)
According to upstream, this is a Debian packaging problem
that they refuse to fix.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-1-amd64 (SMP w/40 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.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 gcc-10 depends on:
ii binutils 2.35.1-7
ii cpp-10 10.2.1-6
ii gcc-10-base10.2.1-6
ii libc6 2.31-9
ii libcc1-0 10.2.1-6
ii libgcc-10-dev 10.2.1-6
ii libgcc-s1 10.2.1-6
ii libgmp10 2:6.2.1+dfsg-1
ii libisl23 0.23-1
ii libmpc31.2.0-1
ii libmpfr6 4.1.0-3
ii libstdc++6 10.2.1-6
ii libzstd1 1.4.8+dfsg-1
ii zlib1g 1:1.2.11.dfsg-2
Versions of packages gcc-10 recommends:
ii libc6-dev 2.31-9
Versions of packages gcc-10 suggests:
ii gcc-10-doc 10.2.0-1
pn gcc-10-locales
ii gcc-10-multilib 10.2.1-6
-- no debconf information
Bug#941248: Acknowledgement (bash.bashrc dereferences undefined variables)
Hi, I reported this bug along with a simple fix more than a year ago. A similar patch to fix Bug#941247 in vte2.91 was applied some months ago. As far as I can tell, the problem is still present in the file bash-5.1/debian/etc.bash.bashrc in the package that I get by running "apt source bash". In my opinion, every security-conscious user should have "set -u" (or "set -eu") in their private configuration. Could you please consider applying the patch? With best regards, Marko Mäkelä
Bug#961194: warning: Using the last argument as keyword parameters is deprecated
Package: jekyll
Version: 3.8.6+dfsg-3
Severity: important
Dear Maintainer,
At least a few weeks ago, after I updated my Sid system,
the command "jekyll build --incremental" for a nontrivial
input (287 *.html files, using some custom Jekyll code) would spew
deprecation warnings for a Ruby files in Jekyll.
Here is the summary, filtered by "sort|uniq -c":
187 /usr/lib/ruby/vendor_ruby/jekyll/convertible.rb:41: warning: Using the
last argument as keyword parameters is deprecated
120 /usr/lib/ruby/vendor_ruby/jekyll/document.rb:449: warning: Using the
last argument as keyword parameters is deprecated
329 /usr/lib/ruby/vendor_ruby/jekyll/tags/include.rb:194: warning: Using
the last argument as keyword parameters is deprecated
The following minimal set of input reproduces one of these deprecation
warnings:
#!/bin/sh
mkdir j
cd j
echo 'markdown: kramdown' > _config.yml
cat > index.html << EOF
---
layout: default
---
hello world
EOF
mkdir _layouts
echo '{{content}}' > _layouts/default.html
jekyll build
The above script outputs the following:
Configuration file: /dev/shm/j/_config.yml
Source: /dev/shm/j
Destination: /dev/shm/j/_site
Incremental build: disabled. Enable with --incremental
Generating...
/usr/lib/ruby/vendor_ruby/jekyll/convertible.rb:41: warning: Using the last argument as keyword parameters is deprecated
/usr/lib/ruby/vendor_ruby/jekyll/convertible.rb:41: warning: Using the last
argument as keyword parameters is deprecated
done in 0.014 seconds.
Auto-regeneration: disabled. Use --watch to enable.
The extra messages from Ruby are preventing me from noticing any Jekyll
warning messages about possible wrong syntax in my Jekyll source files.
Hence, I think that the severity is 'important'.
The generated output in the _site directory seems to be unaffected by this.
I do not know Ruby, so I cannot provide a patch. A common pattern
for these lines appears to be a File.read() invocation.
Best regards,
Marko Mäkelä
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.5.0-1-amd64 (SMP w/40 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8),
LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages jekyll depends on:
ii bundler 2.1.4-1
ii ruby1:2.7+1
ii ruby-addressable2.7.0-1
ii ruby-classifier-reborn 2.2.0-1
ii ruby-colorator 1.1.0-3
ii ruby-em-websocket 0.5.1-2
ii ruby-i18n 1.8.2-2
ii ruby-jekyll-sass-converter 1.5.2-2
ii ruby-jekyll-watch 2.2.1-1
ii ruby-kramdown 1.17.0-4
ii ruby-launchy-shim 2.3.0.1
ii ruby-liquid 4.0.3-2
ii ruby-mercenary 0.3.6-2
ii ruby-mime-types 3.3.1-1
ii ruby-pathutil 0.16.1-1
ii ruby-pygments.rb1.2.1-1
ii ruby-rdiscount 2.1.8-1+b7
ii ruby-redcarpet 3.5.0-1+b2
ii ruby-rouge 3.18.0-1
ii ruby-safe-yaml 1.0.5-1
ii ruby-toml 0.2.0-3
ii xdg-utils 1.1.3-2
jekyll recommends no packages.
Versions of packages jekyll suggests:
ii ruby-jekyll-coffeescript 1.2.2-2
pn ruby-jekyll-compose
ii ruby-jekyll-feed 0.13.0-2
ii ruby-jekyll-gist 1.5.0-2
pn ruby-jekyll-last-modified-at
ii ruby-jekyll-paginate 1.1.0-3
pn ruby-jekyll-redirect-from
pn ruby-jekyll-remote-theme
pn ruby-jekyll-seo-tag
pn ruby-jekyll-sitemap
-- no debconf information
Bug#941247: /etc/profile.d/vte-2.91.sh dereferences undefined BASH_VERSION, ZSH_VERSION
Package: libvte-2.91-common
Version: 0.58.0-1
Severity: important
Tags: patch
Dear Maintainer,
At the start of my $HOME/.bashrc I have configured "set -u" to catch the
use of undefined variables.
Whenever I open a new gnome-terminal window using bash as the shell, the
script vte-2.91.sh will emit two messages about dereferencing an
undefined variable ZSH_VERSION.
The script starts like this:
# Not bash or zsh?
[ -n "$BASH_VERSION" -o -n "$ZSH_VERSION" ] || return 0
# Not an interactive shell?
[[ $- == *i* ]] || return 0
# Not running under vte?
[ "${VTE_VERSION:-0}" -ge 3405 ] || return 0
Note: for VTE_VERSION, the correct pattern is being used. I believe that
that pattern is POSIX shell compliant; at least it works in /bin/dash.
The attached patch fixes the problem for me.
I hope that you can apply this patch to the Debian packages or submit it
upstream. I think that this bug has been present for years, but I did
not investigate or file it until now.
Best regards,
Marko
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.2.0-2-amd64
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8),
LANGUAGE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
--- /etc/profile.d/vte-2.91.sh
+++ /etc/profile.d/vte-2.91.sh
@@ -15,7 +15,7 @@
# along with this program. If not, see
Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'
ma 28. tammik. 2019 klo 18.45 Olaf van der Spek (olafvds...@gmail.com) kirjoitti: > > Op ma 28 jan. 2019 om 17:17 schreef Marko Mäkelä : > > > > I filed and fixed the following ticket in the upcoming MariaDB 10.3.13 > > release: > > https://jira.mariadb.org/browse/MDEV-18399 > > MDEV-18399 Recognize the deprecated parameters innodb_file_format, > > innodb_large_prefix > > Wow that was quick, thanks a lot! Got a link to the changes? https://github.com/MariaDB/server/commit/36be0a5aef0376c526d68007da1c11ac440f0d8b > I'm curious, what's the cost of retaining removed settings? Can't be > much more than a string in an array.. The cost is not that big. Unfortunately we do not have any common infrastructure for deprecated variables that have no effect. The code is scattered in a few places, as you can see in the above change. I guess that the problem mostly exists in InnoDB and XtraDB, where parameters have been added rather liberally, without carefully considering sensible default values or deprecation policies. When I was working on MySQL at Oracle until 2016, new parameters could be added pretty much arbitrarily, but removing the parameters involved following a more rigid procedure (which, as demonstrated by this bug report, might be too lenient). My pet hate are InnoDB parameters that affect the way how DDL statements work (such as these two). The first such parameter (innodb_file_per_table) is still there. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'
I filed and fixed the following ticket in the upcoming MariaDB 10.3.13 release: https://jira.mariadb.org/browse/MDEV-18399 MDEV-18399 Recognize the deprecated parameters innodb_file_format, innodb_large_prefix The parameter innodb_default_row_format has not been deprecated nor removed. It was introduced in MariaDB 10.2 and later backported to 10.1. The backward-compatible default value innodb_default_row_format=compact in 10.1 was overridden by the Debian-shipped configuration file. The default value since 10.2 is innodb_default_row_format=dynamic. -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'
Hi Olaf, > > The parameters innodb_large_prefix and innodb_file_format were > > deprecated in MySQL 5.7 and MariaDB 10.2, and removed in MySQL 8.0 and > > MariaDB 10.3. > > What's the deprecation policy? > I think the time between deprecation and removal is too short. For Oracle, the policy is to deprecate in an earlier version (possibly in an update to a GA release) and to remove in the next major version (which is not yet released as GA). > > How long should obscure parameters be preserved? > > Were large-prefix and file-format obscure? They were in the debian > default maria db conf files.. They should have been made default and deprecated way before version 5.7. The only reason for the parameters to exist was to theoretically allow downgrading to MySQL 5.1. I do not think that such downgrading was ever tested. > How long? Ideally until major distros have all shipped a MariaDB > version with the deprecation warnings. That is a good point. > Treating unknown settings as warnings rather then errors would work too. I think that this is too risky. We do want to catch typos. > > Forever? What about > > old syntax? The following worked in MySQL 5.0, but no longer in MySQL > > 5.1 or MariaDB: > > create table t(a int) type=innodb; > > Syntax is different, when did engine= become available? TYPE=InnoDB (or other storage engines) was deprecated in MySQL 4.1.2, in the same commit that introduced ENGINE=InnoDB syntax. So, at that time, the time frame from deprecation to removal was 2 major releases. The following were removed from InnoDB in MariaDB 10.3: innodb_support_xa innodb_use_mtflush, innodb_mtflush_threads innodb_file_format innodb_file_format_check innodb_file_format_max innodb_large_prefix innodb_instrument_semaphores innodb_use_fallocate Which removed parameters would you want to be recognized? Note: Many parameters are listed in removed_variables[] in sql/upgrade_conf_file.cc, used for building the mysql_upgrade_service executable. -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation
Bug#920608: [debian-mysql] Bug#920608: mariadb-server-10.3: unknown variable 'innodb-large-prefix=on'
I think that upstream has already addressed this issue by introducing the loose_ prefix for options in MySQL 4.0.2 (and in all MariaDB versions). If configuration files used that prefix for all options, there would be no issue when upgrading. Would it be thinkable to add the loose_ prefix to unknown options in configuration files? Or to ship a new version of the default configuration file, commenting out the old (now redundant) settings? Then those users who modified the configuration files would be alerted about the problem when upgrading the package. The parameters innodb_large_prefix and innodb_file_format were deprecated in MySQL 5.7 and MariaDB 10.2, and removed in MySQL 8.0 and MariaDB 10.3. Unfortunately, MariaDB 10.2 was not packaged in Debian, so the fact that 10.2 would have issued deprecation warnings on startup would not help Debian users. How long should obscure parameters be preserved? Forever? What about old syntax? The following worked in MySQL 5.0, but no longer in MySQL 5.1 or MariaDB: create table t(a int) type=innodb; Marko
Bug#852014: desktop-base: Boot hangs if plymouth is not installed
Hi Aurélien, Thank you for your response, and I am sorry for filing the bug against the wrong package. I hope that the log output in this message will help to narrow down the problem. But I fear that it may remain a mystery, and I accept that Debian unstable can sometimes be true to its name. :) TL;DR version: I would suggest that the systemd-based bootup should give up after 3 failed attempts of starting up gdm, like I believe it used to be in the past. Now it seems to be doing it forever. I'm not sure it's raised against the correct package tough, or I will need more information to analyze this problem. Unfortunately, I cannot reproduce the problem any more (even after removing plymouth and downgrading all systemd-related packages to 232-11 or 232-9). But see the /var/log/apt/history.log excerpt near the end of this message. After some analysis (booting into rescue mode and entering the root password, and following the instructions to view the systemd log), I figured out that the fatal error was that exec /bin/plymouth failed, because the program was not installed. Could you share more complete logs about that ? It seems that journalctl only keeps the systemd log since the system startup. I did not attempt to record any logs when the system did not boot beyond the single-user mode. I do have some kernel and user-space messages in /var/log/messages from the failed startup attempts. Maybe the real error was this one: Jan 20 14:39:17 hp org.gnome.Shell.desktop[1071]: /usr/bin/gnome-shell: error while loading shared libraries: libmutter-cogl.so: cannot open shared object file: No such file or directory Jan 20 14:39:17 hp gnome-session[1063]: gnome-session-binary[1063]: WARNING: App 'org.gnome.Shell.desktop' exited with code 127 Jan 20 14:39:17 hp gdm3: GdmDisplay: display lasted 0,106016 seconds Jan 20 14:39:17 hp gdm3: Child process -1059 was already dead. Jan 20 14:39:17 hp gdm3: Child process 1043 was already dead. Jan 20 14:39:17 hp gdm3: Unable to kill session worker process Jan 20 14:39:17 hp /usr/lib/gdm3/gdm-x-session[1090]: Unable to run X server … Jan 20 14:39:57 hp gdm3: GdmDisplay: display lasted 0,083347 seconds Jan 20 14:39:57 hp gdm3: Child process -13450 was already dead. Jan 20 14:39:57 hp gdm3: Child process 13437 was already dead. Jan 20 14:39:57 hp gdm3: Unable to kill session worker process Jan 20 14:39:57 hp /usr/lib/gdm3/gdm-x-session[13480]: Unable to run X server Jan 20 14:39:57 hp gdm3: Child process -13480 was already dead. Jan 20 14:39:57 hp gdm3: Child process 13465 was already dead. Jan 20 14:39:57 hp gdm3: Unable to kill session worker process Jan 20 14:39:57 hp org.gnome.Shell.desktop[13510]: /usr/bin/gnome-shell: error while loading shared libraries: libmutter-cogl.so: cannot open shared object file: No such file or directory Jan 20 14:39:57 hp gnome-session[13502]: gnome-session-binary[13502]: WARNING: App 'org.gnome.Shell.desktop' exited with code 127 Jan 20 14:39:57 hp gdm3: GdmDisplay: display lasted 0,079726 seconds Jan 20 14:39:57 hp gdm3: Could not start command '/usr/lib/gdm3/gdm-session-worker': Liian monta avointa tiedostoa Jan 20 14:39:57 hp gdm3: Child process -13498 was already dead. Jan 20 14:39:57 hp gdm3: Child process 13486 was already dead. Jan 20 14:39:57 hp gdm3: Unable to kill session worker process Back in the days before systemd, a failure to start up gdm3 or xdm or whatever would result in a text dialog after 3 or so failed attempts, and there would be getty listening to some virtual consoles at /dev/tty1 to /dev/tty6. But, when the above happened, the system was seemingly dead. It seems to me that it went into an infinite loop and eventually run out of file descriptors (or maybe I had pressed ctrl-alt-del which was obeyed after 1 or 2 seconds). "Liian monta avointa tiedostoa" is the Finnish translation of "Too many open files". On some occasion, I left the system there for 5 or 10 minutes, but there was no progress. (And on this laptop, the status LED for mass storage activity is pretty well hidden, so I did not even notice that there was constant SSD activity going on.) In /var/log/syslog there is a bit more detail of the above startup/shutdown loops of the gdm service: Jan 20 14:39:16 hp systemd[1]: Started Session c4 of user Debian-gdm. Jan 20 14:39:16 hp kernel: [ 35.891506] iwlwifi :02:00.0: L1 Enabled - LTR Enabled Jan 20 14:39:16 hp kernel: [ 35.891772] iwlwifi :02:00.0: L1 Enabled - LTR Enabled Jan 20 14:39:16 hp systemd[936]: Reached target Paths. Jan 20 14:39:16 hp systemd[936]: Reached target Timers. Jan 20 14:39:16 hp systemd[936]: Listening on GnuPG cryptographic agent (access for web browsers). Jan 20 14:39:16 hp systemd[936]: Listening on GnuPG network certificate management daemon. Jan 20 14:39:16 hp systemd[936]: Listening on GnuPG cryptographic agent and passphrase cache. Jan 20 14:39:16 hp systemd[936]: Listening on GnuPG cryptographic agent (ssh-agent
Bug#852014: desktop-base: Boot hangs if plymouth is not installed
Package: desktop-base
Version: 9.0.1
Severity: critical
Justification: breaks the whole system
Dear Maintainer,
I run Debian unstable on my desktop. Today, after "apt update& upgrade"
the system failed to boot.
After some analysis (booting into rescue mode and entering the root
password, and following the instructions to view the systemd log),
I figured out that the fatal error was that
exec /bin/plymouth failed, because the program was not installed.
Finally, I figured out how to manually bring up the Ethernet interface
and how to install plymouth. The next reboot worked.
The command
grep -lr plymouth /etc
suggests that the existence of files in /usr/share/plymouth/themes
led to the assumption that plymouth is available. I am filing this
bug against desktop-base because dpkg -S suggests that the directory
is associated with desktop-base.
Possibly this bug should be filed against grub-common instead, because
grub-common owns the file /etc/grub.d/05_debian_theme which references
the directory /usr/share/plymouth/themes.
Here are some versions of packages:
desktop-base: 9.0.1
grub-common: 2.02~beta3-3
systemd: 232-12
plymouth: 0.9.2-4
I got the hang with systemd 232-9 and 232-11 before installing plymouth.
Best regards,
Marko Mäkelä
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages desktop-base depends on:
ii dpkg 1.18.18
ii librsvg2-common 2.40.16-1
desktop-base recommends no packages.
Versions of packages desktop-base suggests:
pn gnome | kde-standard | xfce4 | wmaker
-- no debconf information
Bug#778916: Root cause found (camera settings)
The author of gphoto2 (Marcus Meissner) has tracked down this problem: http://permalink.gmane.org/gmane.comp.multimedia.gphoto.devel/8285 He suggests that the Continous AF needs to be set to Off in the camera menus. On my Canon EOS 650D it was not only that, but also AF method: Quick mode will be needed. When this setting is selected, the Continuous AF is grayed out in the camera menu. With the above two camera settings, I get both the coarse and fine focus working using darktable 1.6.6-2 and libgphoto2 2.5.7-5 and the following lenses: EF-S 18-135mm 1:3.5-5.6 IS STM EF-S 60mm 1:2.8 IS USM It works equally well with the lens in the AF or MF mode. The only focus-related setting in the Darktable GUI seems to be focus mode: One Shot. I think that Darktable should either try to ensure that these extra settings are configured to sane values (so that the manual focus control works at all), or it should expose these settings in the GUI. There is a related gphoto2 issue filed upstream: http://sourceforge.net/p/gphoto/bugs/978/ Best regards, Marko Mäkelä -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778916: manual focus still not working, in darktable 1.6.3-1
I just tried the most recent version of darktable from Debian experimental (1.6.3-1), and there, the manual focus control does not seem to work at all. Immediately before trying the new version, I checked with the previously installed 1.6.2-1 that the coarse focus control worked. To try to troubleshoot this a bit further, I started darktable -d camctl from the terminal and watched the output. According to the output, darktable claims to be trying to execute the commands, but nothing happens on the camera: [camera_control] Starting live view [camera_control] live view thread started [camera_control] executing set camera config job eosviewfinder=1 2 fps [camera_control] Camera configuration change event, lets update internal configuration cache. [camera_control] executing set camera config job manualfocusdrive=Far 3 Interestingly, after this experiment, when I try to execute gphoto2 --shell manually, the focus point refuses to move! This is version 2.5.4-1, the same version that worked last time. Power-cycling the camera (by removing and reinserting the battery) and disconnecting and reconnecting the USB cable had no effect. Maybe the Linux end of the USB stack is somehow corrupted? But dmesg does not show anything special. So, it seems that this might be an issue with gphoto2 rather than with darktable itself. I guess I could try rebooting Debian and recording the output of gphoto --debug --set-config manualfocusdrive=6, and comparing it to the output of the misbehaving session. Has this issue been forwarded to upstream authors (of darktable or gphoto2)? Could this be some kind of timing glitch or something that occasionally works, so that this failure is not seen by the developers themselves? Marko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778916: [Pkg-phototools-devel] Bug#778916: darktable: manual focus only works in big steps on Canon EF-S 60mm 1:2.8 USM macro
On Sat, Feb 21, 2015 at 08:21:23PM +0100, David Bremner wrote: I am trying to use Darktable with a Canon EOS 650D in tethered mode. When I enable the live viewfinder, I would expect the focus buttons to affect the picture. This is most likely an upstream issue, so can you try darktable from experimental to see if it has the same problem? Indeed, both the coarse and fine focus buttons do work with my macro lens and darktable_1.6.2-1_amd64.deb. But, the first time I tried it with 1.6.2, none of the focus buttons worked with my macro lens. I had to move the lens to AF mode and half-press the shutter button. Then, the focus controls from Darktable would start to have some effect (fighting against the AF of the camera). Finally, in MF mode, both the coarse and fine focus controls worked. I shortly went back to 1.4.2-1+b3 (which refused to start, until I removed $HOME/.cache/darktable) and then reinstalled 1.6.2-1. There could be some missing initialization step that causes the focus controls occasionally not to work. Power-cycling the camera and restarting Darktable could help. My zoom lens still does not work with Darktable 1.6.2. But, the focus point did move when I tested with the lens in MF mode, using gphoto2 --shell: capture-preview set-config /main/actions/manualfocusdrive 6 set-config /main/actions/manualfocusdrive 6 set-config /main/actions/manualfocusdrive 6 set-config /main/actions/manualfocusdrive 6 set-config /main/actions/manualfocusdrive 6 set-config /main/actions/manualfocusdrive 6 capture-preview My first tests with Darktable (when the focus controls worked) were with Debian unstable at the end of April 2014. I found a sequence of images that I had shot on 2014-05-01 with the macro lens, successfully using the fine focus control buttons from the Darktable GUI. I am not sure, but it could be that the focus controls did work even with the zoom lens (EF-S 18-135mm 1:3.5-5.6 IS STM) at that time. Marko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778916: darktable: manual focus only works in big steps on Canon EF-S 60mm 1:2.8 USM macro
Package: darktable Version: 1.4.2-1+b3 Severity: normal Dear Maintainer, I am trying to use Darktable with a Canon EOS 650D in tethered mode. When I enable the live viewfinder, I would expect the focus buttons to affect the picture. I tested this with two lenses today. EF-S 18-135 IS STM: When the lens is in MF mode, the buttons do not seem to have any effect. In AF mode, the focus buttons sometimes affect the image, but the autofocus algorithm of the camera interferes, trying to focus where it wants. Most of the time, the focus buttons seem to have no effect on the live viewfinder image. EF-S 60 IS USM 2.8: When the lens is in AF mode, the camera is playing its tricks as noted above. However, in MF mode, the coarse focus buttons do have the desired effect, and the fine focus buttons have no effect. I am sure that both the coarse and the fine focus buttons worked on this lens the first time when I tested Darktable, about 4 or 6 months ago. To diagnose the problem, I tested gphoto2 --shell and the following commands: capture-preview get-config /main/actions/manualfocusdrive set-config /main/actions/manualfocusdrive 6 ... The get-config command returns the following: Label: Drive Canon DSLR Manual focus Type: RADIO Current: None Choice: 0 Near 1 Choice: 1 Near 2 Choice: 2 Near 3 Choice: 3 None Choice: 4 Far 1 Choice: 5 Far 2 Choice: 6 Far 3 I tried set-config using the values 0 through 6. Values 0,3,4 had no noticeable effect. With the values 2 and 6, the focus moved in bigger steps and with 1 and 5, in smaller steps (as observed by looking through the indicator window on the lens barrel). So, I suspect that the mapping of the fine-focus buttons was changed from Near 2 and Far 2 to Near 1 and Far 1, which have no effect on my EOS 650D and EF-S 60 IS USM 2.8. If there is a configuration option to remap the focus buttons to the values supported by libgphoto2, then it seems to be well hidden from a newbie like me. For example, right-clicking the focus buttons does not pop up any menu, and the tooltip text (when hovering the mouse pointer over the buttons) only describes basic usage. -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages darktable depends on: ii gtk2-engines 1:2.20.2-3 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-15 ii libcairo2 1.14.0-2.1 ii libcolord21.2.1-1+b2 ii libcurl3-gnutls 7.38.0-4 ii libexiv2-13 0.24-4.1 ii libflickcurl0 1.25-3 ii libgcc1 1:4.9.2-10 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libgl1-mesa-glx [libgl1] 10.4.2-2 ii libglib2.0-0 2.42.1-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgnome-keyring0 3.12.0-1+b1 ii libgomp1 4.9.2-10 ii libgphoto2-6 2.5.4-1.1+b2 ii libgphoto2-port10 2.5.4-1.1+b2 ii libgtk2.0-0 2.24.25-1 ii libice6 2:1.0.9-1+b1 ii libilmbase6 1.0.1-6.1 ii libjpeg62-turbo 1:1.3.1-11 ii libjs-prototype 1.7.1-3 ii libjs-scriptaculous 1.9.0-2 ii libjson-glib-1.0-01.0.2-1 ii liblcms2-22.6-3+b3 ii liblensfun0 0.2.8-2 ii liblua5.2-0 5.2.3-1.1 ii libopenexr6 1.6.1-8 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpng12-01.2.50-2+b2 ii librsvg2-22.40.5-1 ii libsdl1.2debian 1.2.15-10+b1 ii libsm62:1.2.2-1+b1 ii libsoup2.4-1 2.48.0-1 ii libsqlite3-0 3.8.7.4-1 ii libstdc++64.9.2-10 ii libtiff5 4.0.3-12 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxml2 2.9.2+dfsg1-3 ii zlib1g1:1.2.8.dfsg-2+b1 darktable recommends no packages. darktable 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#764220: gcc incorrectly optimizes away parameter initialization
Package: gcc-4.6
Version: 4.6.3-14
This bug occurs on two gcc versions I tried on Debian Wheezy 7.6 x86:
g++-4.6 (Debian 4.6.3-14) 4.6.3
g++ (Debian 4.7.2-5) 4.7.2
and one version that I tried on Debian Jessie/Sid amd64:
gcc (Debian 4.9.1-15) 4.9.1
g++ (Debian 4.9.1-15) 4.9.1
I did not try other gcc versions. I would not be surprised if this bug
is present in all gcc 4.x versions, or in all gcc versions that accept
this code.
When my test program is compiled with
$ g++ -c test.C
the generated machine code looks sensible.
When it is compiled with
$ g++ -O -c test.C
the output will be too short, and there are no references to the
external variable g. You can verify this with
$ nm test.o
T _Z12test_gcc_bugj
U _Z3fooRK1c
$ objdump -d test.o
sql/gcc-bug.o: file format elf32-i386
Disassembly of section .text:
_Z12test_gcc_bugj:
0: 83 ec 2csub$0x2c,%esp
3: 8d 44 24 1c lea0x1c(%esp),%eax
7: 89 04 24mov%eax,(%esp)
a: e8 fc ff ff ff call b _Z12test_gcc_bugj+0xb
f: 83 c4 2cadd$0x2c,%esp
12: c3 ret
I have prepared both C and C++ versions of this test program:
cat test.c EOF
struct c {
unsigned a;
};
extern struct c g;
bool foo(const struct c* d) __attribute__((pure));
inline
const struct c*
bar(unsigned f)
{
struct c d {g.a};
return f ? d : g;
}
bool
test_gcc_bug(unsigned f)
{
return foo(bar(f));
}
EOF
cat test.C EOF
class c {
public:
c(unsigned b) : a(b) {}
unsigned a;
};
extern c g;
bool foo(const c d) __attribute__((const));
inline
const c
bar(unsigned f)
{
return f ? c(g.a) : g;
}
bool
test_gcc_bug(unsigned f)
{
return foo(bar(f));
}
EOF
When the __attribute__((pure)) or __attribute__((const)) is removed, all
code will be emitted properly.
In the C++ version, I guess it is borderline if the
__attribute__((const)) should be allowed. If the function accesses the
memory pointed to by the reference, does that count as 'global memory',
violating the 'const' attribute? If yes, then __attribute__((const))
should probably emit a warning when the function is taking references or
pointers as parameters. Anyway, incorrect code is being emitted also for
__attribute__((pure)).
This bug broke the MySQL 5.7.5 x86 build on Debian 7.6. The bug would
not manifest itself when using gcc 4.6 on that platform, but that was
only luck: gcc 4.6 would inline the problematic function call, while gcc
4.7 would inline it on this platform. The problematic code is this call
in storage/innobase/btr/btr0pcur.cc, function
btr_cur_pessimistic_insert():
if (page_zip_rec_needs_ext(rec_get_converted_size(index, entry, n_ext),
dict_table_is_comp(index-table),
dtuple_get_n_fields(entry),
dict_table_page_size(index-table)))
The function page_zip_rec_needs_ext() corresponds to foo in my test
programs. It is declared as __attribute__((const)). The initialization
of the object that is returned by dict_table_page_size() was omitted.
That would be page_size_t in the MySQL source code, and class c or
struct c in my test programs above. Space for the object was allocated
from the stack, but there was no code emitted for initializing the
object before page_zip_rec_needs_ext() was invoked.
With best regards,
Marko Makela
Senior Principal Software Engineer
InnoDB Group, MySQL Server, Oracle Corporation
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725978: Same issue with USB media; enabling kernel polling helped
Hi, I found this bug report when trying to figure out why USB devices are not showing up in the xfce4 file manager Thunar. It seems that udisks2 is detecting the insertion of the media (according to udevadm monitor), but it is missing some step that prevents gvfs from seeing the file system. As noted in http://forums.debian.net/viewtopic.php?t=104661 you can unblock it by issuing some command (an invalid mount command did it for me). My problem was solved by the workaround suggested by Tsu Jan: echo 2000 /sys/module/block/parameters/events_dfl_poll_msecs Best regards, Marko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659940: /etc/bash.bashrc dereferences undefined variable $debian_chroot
Package: bash
Version: 4.2-1
Severity: normal
Tags: patch
My $HOME/.bashrc does set -u, which causes it to warn about
dereferencing undefined variables. Whenever I start a shell, I get a
warning (in LANG=fi_FI.utf8) like this:
bash: debian_chroot: sitomaton muuttuja
The fix is simple. In /etc/bash.bashrc, replace $debian_chroot with
${debian_chroot:-}. This should work even in dash:
- if [ -z $debian_chroot ] [ -r /etc/debian_chroot ]; then
+ if [ -z ${debian_chroot:-} ] [ -r /etc/debian_chroot ]; then
There are similar problems in the bash-completion package, which prompted me
to uninstall it. (It spit out similar messages, and completion did not work
at all when the package was installed.)
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bash depends on:
ii base-files 6.5
ii dash 0.5.7-2
ii debianutils 4.2.1
ii libc62.13-26
ii libtinfo55.9-4
Versions of packages bash recommends:
pn bash-completion none
Versions of packages bash suggests:
pn bash-doc none
-- Configuration Files:
/etc/bash.bashrc changed:
[ -z $PS1 ] return
shopt -s checkwinsize
if [ -z ${debian_chroot:-} ] [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- $1
return $?
elif [ -x /usr/share/command-not-found ]; then
/usr/bin/python /usr/share/command-not-found -- $1
return $?
else
return 127
fi
}
fi
-- 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#160390: Fixed in libjpeg8
The jpegtran -crop functionality is included in Debian Squeeze: $dpkg --status libjpeg-progs Package: libjpeg-progs Status: install ok installed Priority: optional Section: graphics Installed-Size: 208 Maintainer: Bill Allombert ballo...@debian.org Architecture: i386 Source: libjpeg8 Version: 8b-1 Depends: libc6 (= 2.7), libjpeg8 In other words, this bug can be closed now. Regards, Marko -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512275: gcc-4.1 ICE on mixing typedef and enum names
Package: gcc-4.1
Version: 4.1.1-21
Severity: minor
This three-line test program will trigger an internal compiler error
when compiled with gcc -c /tmp/ice.c:
typedef enum { a } b;
extern enum b c;
int d(void) { return (c != a); }
/tmp/ice.c: In function ‘d’:
/tmp/ice.c:3: internal compiler error: in create_tmp_var, at gimplify.c:410
The bug has apparently been fixed by upstream, because GCC 4.3.2-1 on
Debian Lenny AMD64 duly flags the error:
bar.c: In function 'd':
bar.c:3: error: 'c' has an incomplete type
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-686
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Versions of packages gcc-4.1 depends on:
ii binutils 2.17-3The GNU assembler, linker and bina
ii cpp-4.14.1.1-21 The GNU C preprocessor
ii gcc-4.1-base 4.1.1-21 The GNU Compiler Collection (base
ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries
ii libgcc11:4.1.1-21GCC support library
ii libssp04.1.1-21 GCC stack smashing protection libr
Versions of packages gcc-4.1 recommends:
ii libc6-dev 2.3.6.ds1-13etch8 GNU C Library: Development Librari
pn libmudflap0-devnone(no description available)
-- debconf-show failed
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#160390: Ready for inclusion?
Hi, Would the jpegtran -drop patch be ready for release now? It's been over 5 years. I haven't had any problems with the patch, although I only use it on a few pictures per year. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461820: iceweasel: crash due to BadAlloc on www.news.com.au
Iceweasel crashes due to BadAlloc every time I try to visit the page http://www.news.com.au/adelaidenow/story/0,22606,23136307-5012985,00.html even without any extensions, themes, or language packs being enabled. I tried to get a stack trace like this: gdb /usr/lib/iceweasel/firefox-bin set env LD_LIBRARY_PATH=/usr/lib/iceweasel break gdk_x_error r -a firefox http://www.news.com.au/adelaidenow/story/0,22606,23136307-5012985,00.html I also tried to add --sync to the command line arguments, but it did not change the behaviour. Unfortunately, gdb was unable to resolve the symbol gdk_x_error(). Here is what Iceweasel printed out: error: duplicate affix flag H in line SFX H Y 200 S ... error: duplicate affix flag Z in line SFX Z Y 200 S The program 'gecko' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 48712 error_code 11 request_code 53 minor_code 0) (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 --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Please let me know if/how I can help further. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.23.13 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iceweasel depends on: ii debianutils2.28.2Miscellaneous utilities specific t ii fontconfig 2.5.0-2 generic font configuration library ii libatk1.0-01.20.0-1 The ATK accessibility toolkit ii libc6 2.7-6 GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libgcc11:4.2.2-4 GCC support library ii libglib2.0-0 2.14.5-2 The GLib library of C routines ii libgtk2.0-02.12.5-2 The GTK+ graphical user interface ii libhunspell-1.1-0 1.1.9-1 spell checker and morphological an ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libnspr4-0d4.7.0~1.9b1-2 NetScape Portable Runtime Library ii libnss3-0d 3.11.7-1 Network Security Service libraries ii libpango1.0-0 1.18.4-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-3PNG library - runtime ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxft22.1.12-2 FreeType-based font drawing librar ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxp6 1:1.0.0.xsf1-1X Printing Extension (Xprint) clie ii libxrender11:0.9.4-1 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii procps 1:3.2.7-5 /proc file system utilities ii psmisc 22.6-1Utilities that use the proc filesy ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime iceweasel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444695: Maybe related
I can't see such messages anywhere, but network-manager does not seem to notice when I flip the RF kill switch on my Thinkpad X60s (ipw3945, iwlwifi-1.1.17 on kernel 2.6.22.9). After enabling the radio interfaces by flipping the hardware switch, I will have to do /etc/init.d/hal restart to get wireless access. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440786: gnomebaker: crash when importing playlist
Goedson, When I tried gnomebaker a few months ago, importing a playlist sort of worked, but the music pieces were imported in reverse order. This time, gnomebaker crashed with the following stacktrace. The playlist was generated with totem, and it consisted solely of audio recordings in the Ogg FLAC (*.flac) format. Could you please try to reproduce this with gnomebaker 0.6.0-10 from Sid? Better yet if you do it with the package rebuilt with debug information enabled. It looks like there is a problem in decoding %-encoded bytes such as %20 and %26 and multibyte UTF-8 sequences. If really necessary, I will try to reproduce this on Sid, but I only have the media files on an Etch system. Also, please send the output produced by running gnomebaker --trace-on and trying to import your playlist. I have since then edited the playlist a little. Now it doesn't crash immediately, but it displayed some garbage strings, such as .../musiikki/Sotta%260xbfa8da84ytty/K (should be .../Sotta%20%26%20Pytty/...). It also displays empty dialogs and garbage like The file [/home/heli/Desktop/jumppa/vauva/file:///home/heli/Desktop/musiikki/Eeva armanto-Neuvonen/Viisi (nil)ient (sic). The string M. A. Numminen is displayed as M.0x0,0BDFA8DA84P-1022.%20Numminen. I can't see these errors in the --trace-on output; only in the dialog box. But I can see the Pango-WARNING about invalid UTF-8 string. The output of gnomebaker --trace-on and the playlist are attached. Marko gnomebaker.txt.gz Description: Binary data Vauvajumppa1-3.pls Description: audio/scpls
Bug#440786: gnomebaker: crash when importing playlist
Package: gnomebaker Version: 0.6.0-7 Severity: normal *** Please type your report below this line *** When I tried gnomebaker a few months ago, importing a playlist sort of worked, but the music pieces were imported in reverse order. This time, gnomebaker crashed with the following stacktrace. The playlist was generated with totem, and it consisted solely of audio recordings in the Ogg FLAC (*.flac) format. Marko Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224828640 (LWP 3812)] 0xb73b032d in gst_debug_level_get_name () from /usr/lib/libgstreamer-0.10.so.0 (gdb) bt #0 0xb73b032d in gst_debug_level_get_name () from /usr/lib/libgstreamer-0.10.so.0 #1 0xb73b1209 in gst_debug_add_log_function () from /usr/lib/libgstreamer-0.10.so.0 #2 0xb726fee8 in vfprintf () from /lib/tls/i686/cmov/libc.so.6 #3 0xb728fc7c in vasprintf () from /lib/tls/i686/cmov/libc.so.6 #4 0xb75cec97 in g_vasprintf () from /usr/lib/libglib-2.0.so.0 #5 0xb75c0c86 in g_strdup_vprintf () from /usr/lib/libglib-2.0.so.0 #6 0xb7a4ffbc in gtk_message_dialog_new () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x08062b53 in gnomebaker_show_msg_dlg () #8 0x08079b05 in audioproject_is_supported_playlist () #9 0x08079e1f in audioproject_is_supported_playlist () #10 0x08079f84 in audioproject_import_playlist () #11 0x08060727 in gnomebaker_on_import_playlist () #12 0xb7629e1b in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #13 0xb761c98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #14 0xb762cf2d in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #15 0xb762e429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #16 0xb762e5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #17 0xb7b2f042 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #18 0xb7a4d262 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #19 0xb7a4e810 in gtk_menu_shell_append () from /usr/lib/libgtk-x11-2.0.so.0 #20 0xb7a42d3f in gtk_menu_attach () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb7a41250 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #22 0xb761af49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 #23 0xb761c98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #24 0xb762d56f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0 #25 0xb762e208 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #26 0xb762e5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #27 0xb7b2af64 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7a3abd3 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #29 0xb7a3be07 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb78d4eea in _gdk_events_init () from /usr/lib/libgdk-x11-2.0.so.0 #31 0xb75a5b21 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #32 0xb75a8b96 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #33 0xb75a8f57 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #34 0xb7a3c281 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #35 0x080555db in main () -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages gnomebaker depends on: ii cdrdao 1:1.2.2-6 records CDs in Disk-At-Once (DAO) ii dvd+rw-tools 7.0-7 DVD+-RW/R tools ii genisoimage9:1.1.2-1 Creates ISO-9660 CD-ROM filesystem ii gstreamer0.10-ffmpeg 0.10.1-7 FFmpeg plugin for GStreamer ii gstreamer0.10-plugins- 0.10.10-4 GStreamer plugins from the base ii gstreamer0.10-plugins- 0.10.4-4 GStreamer plugins from the good ii gstreamer0.10-plugins- 0.10.4-5 GStreamer plugins from the ugly ii icedax 9:1.1.2-1 Creates WAV files from audio CDs ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.12.4-3 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-3 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-5 The Bonobo UI library ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libdbus-1-31.0.2-1 simple interprocess messaging syst ii libdbus-glib-1-2 0.71-3simple interprocess messaging syst ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libgconf2-42.16.1-1 GNOME configuration database syste ii libglade2-01:2.6.0-4 library to load .glade files at ru ii libglib2.0-0 2.12.6-2 The GLib library of C
Bug#406670: closed by Paul Brossier [EMAIL PROTECTED] (Bug#406670: fixed in kino 0.92-3)
On Wed, Feb 07, 2007 at 12:48:41AM -0800, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #406670: kino: Capture fails with dv1394 INIT ioctl: Invalid argument, which was filed against the kino package. It has been closed by Paul Brossier [EMAIL PROTECTED]. Thank you, capture works for me now. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406670: closed by Paul Brossier [EMAIL PROTECTED] (Bug#406670: fixed in kino 0.92-2)
On Fri, Jan 19, 2007 at 04:03:19AM -0800, Debian Bug Tracking System wrote: Subject: Bug#406670: fixed in kino 0.92-2 Date: Fri, 19 Jan 2007 11:47:03 + Source: kino Source-Version: 0.92-2 We believe that the bug you reported is fixed in the latest version of kino, which is due to be installed in the Debian FTP archive: Sorry, the bug persists with the original symptoms. * Compile with --with-dv1394 (closes: #406670, #400919) My suggestion was to compile without --with-dv1394. Also 0.92-1 was built with --with-dv. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406670: kino: Capture fails with dv1394 INIT ioctl: Invalid argument
Package: kino Version: 0.92-1 Severity: important I am unable to capture DV with Kino. The capture device in Kino is set to /dev/raw1394 and the user has permissions to access this device. dvgrab works fine, but Kino displays the standard message WARNING: raw1394 kernel module not loaded or failure to read/write /dev/raw1394! and keeps writing the message dv1394 INIT ioctl: Invalid argument to stderr as long as the Capture tab is open. When I built Kino from source without --with-dv1394 in debian/rules, I had to install an additional build dependency, libiec61883-dev. With that build, both AV/C controls and capture work fine. A side note: trying to read /dev/dv1394/0 will cause a kernel panic (a blinking caps lock LED). This might be due to the interrupt handling logic not being compatible with a dual core processor (Intel Core Duo L2400). I have so far tried this only on self-built kernels (2.6.18.x and 2.6.19.1). Please consider building Kino without dv1394. Marko -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.1 Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Versions of packages kino depends on: ii libasound21.0.13-1 ALSA library ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit ii libavc1394-0 0.5.3-1+b1 control IEEE 1394 audio/video devi ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libdv41.0.0-1software library for DV format dig ii libfontconfig12.4.2-1generic font configuration library ii libgcc1 1:4.1.1-21 GCC support library ii libglade2-0 1:2.6.0-4 library to load .glade files at ru ii libglib2.0-0 2.12.6-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libraw1394-8 1.2.1-2library for direct access to IEEE ii libsamplerate00.1.2-2audio rate conversion library ii libsm61:1.0.1-3 X11 Session Management library ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor1 1.1.7-4X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes31:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi61:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1 GNOME XML library ii libxrandr22:1.1.0.2-5X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxv11:1.0.2-1 X11 Video extension library ii zlib1g1:1.2.3-13 compression library - runtime kino recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406669: linux-image-2.6.18-2-686-bigmem: System freeze on read from /dev/dv1394/0
Package: linux-image-2.6.18-2-686-bigmem Version: 2.6.18-5 Severity: normal The kernel crashes when trying to capture digital video from a JVC GR-DVL9600 PAL DV camera connected to the built-in firewire port of a Lenovo Thinkpad X60s. I tried to track this down maybe one month ago, and it looked like a bug in the interrupt handling logic. Maybe the code breaks on multi-processor systems? How to repeat: cat /dev/dv1394/0 (the process blocks, waiting for data) start the DV stream from the camera (i.e., press play, or switch to shooting mode) - the Linux kernel hangs! If needed, I can repeat this on the text console and make a screen dump by digital camera. This is likely to be an upstream bug, because the crash also occurs on a self-built 2.6.19.1. DV capture via the lower-level interface /dev/raw1394 does work. Marko -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.1 Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-2-686-bigmem depends on: ii initramfs-tools [linux-initra 0.85e tools for generating an initramfs ii module-init-tools 3.3-pre4-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.18-2-686-bigmem recommends: ii libc6-i686 2.3.6.ds1-10 GNU C Library: Shared libraries [i -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-2-686-bigmem/postinst/bootloader-test-error-2.6.18-2-686-bigmem: linux-image-2.6.18-2-686-bigmem/postinst/kimage-is-a-directory: linux-image-2.6.18-2-686-bigmem/preinst/already-running-this-2.6.18-2-686-bigmem: linux-image-2.6.18-2-686-bigmem/preinst/bootloader-initrd-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/preinst/initrd-2.6.18-2-686-bigmem: linux-image-2.6.18-2-686-bigmem/postinst/depmod-error-2.6.18-2-686-bigmem: false linux-image-2.6.18-2-686-bigmem/preinst/abort-overwrite-2.6.18-2-686-bigmem: linux-image-2.6.18-2-686-bigmem/preinst/failed-to-move-modules-2.6.18-2-686-bigmem: linux-image-2.6.18-2-686-bigmem/postinst/old-system-map-link-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/preinst/abort-install-2.6.18-2-686-bigmem: linux-image-2.6.18-2-686-bigmem/postinst/old-initrd-link-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/postinst/depmod-error-initrd-2.6.18-2-686-bigmem: false linux-image-2.6.18-2-686-bigmem/preinst/elilo-initrd-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/postinst/create-kimage-link-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/prerm/removing-running-kernel-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/postinst/old-dir-initrd-link-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/preinst/lilo-initrd-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/preinst/lilo-has-ramdisk: linux-image-2.6.18-2-686-bigmem/prerm/would-invalidate-boot-loader-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/preinst/overwriting-modules-2.6.18-2-686-bigmem: true linux-image-2.6.18-2-686-bigmem/postinst/bootloader-error-2.6.18-2-686-bigmem: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400002: closed by Mark Doliner [EMAIL PROTECTED] (Re: Bug#400002: gaim segfaults in DigestCalcResponse())
On Mon, Nov 27, 2006 at 11:33:33PM -0800, Debian Bug Tracking System wrote: I justed fixed this with a commit to Gaim's SVN repo. It's revision 17834. Inquiring minds can grab a diff from http://svn.sourceforge.net/viewvc/gaim/trunk/libgaim/protocols/jabber/auth.c?r1=17834r2=17833view=patchpathrev=17834 I tried this patch. It won't crash any more, but it can't connect either. The symptoms are similar to gaim_2.0.0+beta5-2_i386.deb, i.e., it says something like unexpected response from the server. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400002: closed by Mark Doliner [EMAIL PROTECTED] (Re: Bug#400002: gaim segfaults in DigestCalcResponse())
On Tue, Nov 28, 2006 at 11:33:00AM -0500, Ari Pollak wrote: Could you try using the debian patch instead? You can retrieve it with the following command: svn cat svn://svn.debian.org/svn/pkg-gnome/unstable/gaim/debian/patches/09_jabber-sasl-crash.patch 09_jabber-sasl-crash.patch I can't: svn: File not found: revision 8018, path '/unstable/gaim/debian/patches/09_jabber-sasl-crash.patch' Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400002: gaim segfaults in DigestCalcResponse()
Package: gaim Version: 1:2.0.0+beta5-3 Severity: normal gaim segfaults when trying to connect to a Jabber server. The previous version (gaim 1:2.0.0+beta5-2) refused to connect but without crashing. The last version that works for me is gaim 1:2.0.0+beta5-1. Here is the stack trace for gaim 1:2.0.0+beta5-3: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1222560064 (LWP 11746)] 0xb6c8d732 in DigestCalcResponse () from /usr/lib/sasl2/libdigestmd5.so.2 (gdb) bt #0 0xb6c8d732 in DigestCalcResponse () from /usr/lib/sasl2/libdigestmd5.so.2 #1 0xb6ef03b3 in sasl_client_step () from /usr/lib/libsasl2.so.2 #2 0xb6f1332d in jabber_auth_handle_success () from /usr/lib/gaim/libjabber.so #3 0xb6f23772 in jabber_process_packet () from /usr/lib/gaim/libjabber.so #4 0xb6f26189 in jabber_parser_process () from /usr/lib/gaim/libjabber.so #5 0xb761ca99 in xmlParseXMLDecl () from /usr/lib/libxml2.so.2 #6 0xb76293c8 in xmlParseChunk () from /usr/lib/libxml2.so.2 #7 0xb6f2607f in jabber_parser_process () from /usr/lib/gaim/libjabber.so #8 0xb6f2309d in jabber_stream_set_state () from /usr/lib/gaim/libjabber.so #9 0xb79b235d in gaim_sound_play_file () from /usr/lib/libgaim.so.0 #10 0x08096913 in gaim_gtk_eventloop_get_ui_ops () #11 0xb78cbc7f in g_io_channel_unix_get_fd () from /usr/lib/libglib-2.0.so.0 #12 0xb78a2731 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #13 0xb78a57a6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #14 0xb78a5b67 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #15 0xb7cfb281 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x080ab495 in main () -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Versions of packages gaim depends on: ii gaim-data1:2.0.0+beta5-3 multi-protocol instant messaging c ii libatk1.0-0 1.12.3-1The ATK accessibility toolkit ii libavahi-compat-howl00.6.15-2Avahi Howl compatibility library ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libcairo21.2.4-4 The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.1-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.71-3 simple interprocess messaging syst ii libfontconfig1 2.4.1-2 generic font configuration library ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libglib2.0-0 2.12.4-2The GLib library of C routines ii libgnutls13 1.4.4-3 the GNU TLS library - runtime libr ii libgstreamer0.10-0 0.10.10-2 Core GStreamer libraries and eleme ii libgtk2.0-0 2.8.20-3The GTK+ graphical user interface ii libgtkspell0 2.0.10-3+b1 a spell-checking addon for GTK's T ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libpango1.0-01.14.7-1Layout and rendering of internatio ii libperl5.8 5.8.8-6.1 Shared Perl library ii libsasl2-2 2.1.22.dfsg1-4 Authentication abstraction library ii libsasl2-modules 2.1.22.dfsg1-4 Pluggable Authentication Modules f ii libsm6 1:1.0.1-3 X11 Session Management library ii libstartup-notification0 0.8-2 library for program launch feedbac ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-4 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-3 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxss1 1:1.1.0-1 X11 Screen Saver extension library Versions of packages gaim recommends: ii gstreamer0.10-alsa0.10.10-2 GStreamer plugin for ALSA ii gstreamer0.10-plugins-base0.10.10-2 GStreamer plugins from the base ii gstreamer0.10-plugins-good0.10.4-3 GStreamer plugins from the good -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400002: gaim segfaults in DigestCalcResponse()
On Thu, Nov 23, 2006 at 10:48:53AM -0500, Ari Pollak wrote:
Could you install the gaim-dbg and cyrus-sasl2-dbg packages and then paste the
output of a bt full in gdb? Thanks.
Attached.
Marko
#0 digestmd5_client_mech_step (conn_context=0x84af280, params=0x84aeff8,
serverin=0x0, serverinlen=0, prompt_need=0x0, clientout=0x0,
clientoutlen=0x0, oparams=0x84ae728) at digestmd5.c:3945
ctext = value optimized out
#1 0xb6e943b3 in sasl_client_step (conn=0x84adec8, serverin=0x0,
serverinlen=0, prompt_need=0x0, clientout=0x0, clientoutlen=0x0)
at client.c:658
result = value optimized out
#2 0xb6eb732d in jabber_auth_handle_success (js=0x8477198, packet=0x8472168)
at ../../../../libgaim/protocols/jabber/auth.c:756
ns = value optimized out
x = value optimized out
#3 0xb6ec7772 in jabber_process_packet (js=0x8477198, packet=0x8472168)
at ../../../../libgaim/protocols/jabber/jabber.c:198
No locals.
#4 0xb6eca189 in jabber_parser_element_end_libxml (user_data=0x8477198,
element_name=0x84a9dfe success, prefix=0x0,
namespace=0x84a9d6a urn:ietf:params:xml:ns:xmpp-sasl)
at ../../../../libgaim/protocols/jabber/parser.c:102
No locals.
#5 0xb75c0a99 in xmlParseXMLDecl () from /usr/lib/libxml2.so.2
No symbol table info available.
#6 0xb75cd3c8 in xmlParseChunk () from /usr/lib/libxml2.so.2
No symbol table info available.
#7 0xb6eca07f in jabber_parser_process (js=0x8477198, buf=0x0, len=8)
at ../../../../libgaim/protocols/jabber/parser.c:178
No locals.
#8 0xb6ec709d in jabber_recv_cb_ssl (data=0x8476c58, gsc=0x8493ee0,
cond=GAIM_INPUT_READ) at ../../../../libgaim/protocols/jabber/jabber.c:379
js = (JabberStream *) 0x8477198
len = 116
buf = success
xmlns=\urn:ietf:params:xml:ns:xmpp-sasl\cnNwYXV0aD1hYWIxMmQxY2YyNDFmYzg4MjkyYzkzZjVlNWEzMTg2OQ==/success\000GFxOTBlNFN6YjJLb0cxNXRZUFJDbCIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJt...
#9 0xb795635d in recv_cb (data=0x8493ee0, source=13, cond=GAIM_INPUT_READ)
at ../../libgaim/sslconn.c:138
No locals.
#10 0x08096913 in gaim_gtk_io_invoke (source=0x83d7400, condition=G_IO_IN,
data=0x8482ef8) at ../../gtk/gtkeventloop.c:77
gaim_cond = GAIM_INPUT_READ
#11 0xb786fc7f in g_io_channel_unix_get_fd () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#12 0xb7846731 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#13 0xb78497a6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#14 0xb7849b67 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#15 0xb7c9f281 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#16 0x080ab495 in main (argc=Cannot access memory at address 0x8
) at ../../gtk/gtkmain.c:801
saved_status = value optimized out
opt_help = value optimized out
opt_login = 0
opt_nologin = 0
opt_version = value optimized out
opt_config_dir_arg = 0x0
opt_login_arg = 0x0
opt_session_arg = 0x0
accounts = value optimized out
sig_indx = value optimized out
sigset = {__val = {91143, 0 repeats 31 times}}
prev_sig_disp = value optimized out
errmsg =
økº¿ÕMô·\b\000\000\000$\000\000\000ô¯ô·ø\211º¿4ôó·$\000\000\000$\000\000\000\000\000\000\000nâ,·Hõ\213·(l5·à÷\213·\000\000\000\000\000mº¿O\004ô·Ì\211º¿\000\000\000\000\000\000\000\000è\215\177· ñó·è\211º¿¡Lô·X´ô·dlº¿i\020ô·±#·\000\000\000\000ô¯ô·ô¯ô·\004\000\000\000ÜÃ,·|[EMAIL
PROTECTED]...
segfault_message_tmp = value optimized out
error = (GError *) 0x0
opt = value optimized out
gui_check = value optimized out
debug_enabled = 0
long_options = {{name = 0x80e2491 config, has_arg = 1, flag = 0x0,
val = 99}, {name = 0x80d5dcc debug, has_arg = 0, flag = 0x0, val = 100},
{name = 0x80d7a8d help, has_arg = 0, flag = 0x0, val = 104}, {
name = 0x80e2da9 login, has_arg = 2, flag = 0x0, val = 108}, {
name = 0x80df939 nologin, has_arg = 0, flag = 0x0, val = 110}, {
name = 0x80e2487 session, has_arg = 1, flag = 0x0, val = 115}, {
name = 0x80d8e4f version, has_arg = 0, flag = 0x0, val = 118}, {
name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
Bug#400095: mozilla-firefox-locale-all: Improved Finnish translations
Package: mozilla-firefox-locale-all Severity: normal Tags: patch As discussed in private mail, I am sending a patch for improving the Finnish translations. I have already submitted this patch upstream. Marko -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) diff -rpu locale.orig/browser/aboutDialog.dtd locale/browser/aboutDialog.dtd --- locale.orig/browser/aboutDialog.dtd 2006-06-01 15:22:08.0 +0300 +++ locale/browser/aboutDialog.dtd 2006-11-23 22:31:28.0 +0200 @@ -1,6 +1,6 @@ !ENTITY aboutDialog.title Tietoja brandFullName;ista !ENTITY copyright Tekijät -!ENTITY aboutLink lt; Tiedot brandFullName;ista +!ENTITY aboutLink lt; brandFullName;in tiedot !ENTITY aboutVersionversio !ENTITY copyrightText #169;1998-2006 Tekijät. Kaikki oikeudet pidätetään. Firefox ja Firefox-logo ovat Mozilla-säätiön tavaramerkkejä. Kaikki oikeudet diff -rpu locale.orig/browser/baseMenuOverlay.dtd locale/browser/baseMenuOverlay.dtd --- locale.orig/browser/baseMenuOverlay.dtd 2006-09-04 14:51:26.0 +0300 +++ locale/browser/baseMenuOverlay.dtd 2006-11-23 22:31:28.0 +0200 @@ -14,7 +14,7 @@ !ENTITY aboutCmd.accesskeyT !ENTITY helpContents.labelOhjeen aiheet !ENTITY helpContents.accesskeyO -!ENTITY helpContentsMac.label brandShortName; ohje +!ENTITY helpContentsMac.label brandShortName;in ohje !ENTITY helpForIEUsers.label Internet Explorerin käyttäjille !ENTITY helpForIEUsers.accesskey E !ENTITY openHelp.commandkey VK_F1 diff -rpu locale.orig/browser/help/help.rdf locale/browser/help/help.rdf --- locale.orig/browser/help/help.rdf 2006-06-08 14:18:44.0 +0300 +++ locale/browser/help/help.rdf2006-11-23 22:32:32.0 +0200 @@ -11,7 +11,7 @@ !-- MOZILLA MASTER HELP DOCUMENT -- Description rdf:about=urn:root -nc:title=brandFullName; ohje +nc:title=brandFullName;in ohje nc:defaulttopic=firefox-help nc:base=chrome://browser/locale/help/ nc:panellist diff -rpu locale.orig/browser/help/prefs.xhtml locale/browser/help/prefs.xhtml --- locale.orig/browser/help/prefs.xhtml2006-09-16 17:08:56.0 +0300 +++ locale/browser/help/prefs.xhtml 2006-11-23 22:31:28.0 +0200 @@ -56,7 +56,7 @@ säädettäviä asetuksia./p pVaihtoehtoisesti brandShortName; voi myös avata samat osoitteet, jotka olivat auki kun brandShortName; suljettiin viimeisen kerran. brandShortName; avaa nämä edellisen istunnon osoitteet sulkemistilannetta vastaaviin välilehtiin -ja ikkunoihin. Näin voit jatkaa selaamista kuin et olisi sammuttanutkaan +ja ikkunoihin. Näin voit jatkaa selaamista ikään kuin et olisi sulkenutkaan brandShortName;ia. Toiminnon avulla voit myös esimerkiksi tallentaa selaustilanteen järjestelmäpäivityksen ajaksi. Ota istunnon tallennus käyttöön valitsemalla pudotusvalikosta emAvaa viimeisen istunnon ikkunat ja välilehdet/em./p diff -rpu locale.orig/browser/help/using_firebird.xhtml locale/browser/help/using_firebird.xhtml --- locale.orig/browser/help/using_firebird.xhtml 2006-09-27 10:12:44.0 +0300 +++ locale/browser/help/using_firebird.xhtml2006-11-23 22:31:28.0 +0200 @@ -21,7 +21,7 @@ Contributors: body h1brandFullName;in käyttäminen/h1 -pTervetuloa brandFullName; käyttäjäksi! brandFullName;illa voit selata +pTervetuloa brandFullName;in käyttäjäksi! brandFullName;illa voit selata Internet-sivuja ja tehdä hakuja Internetistä./p div class=contentsBoxTässä osassa: diff -rpu locale.orig/fi/mozapps/extensions/update.dtd locale/fi/mozapps/extensions/update.dtd --- locale.orig/fi/mozapps/extensions/update.dtd2006-09-16 16:56:16.0 +0300 +++ locale/fi/mozapps/extensions/update.dtd 2006-11-23 22:31:28.0 +0200 @@ -43,7 +43,7 @@ !ENTITY adminDisabled.wizard.title Päivityksiä ei voida hakea !ENTITY adminDisabled.warning.label Epäyhteensopiviin lisäosiin ei voida hakea päivityksiä, koska ohjelmien - asentaminen brandShortName;iin on otettu pois päältä. + asentaminen brandShortName;iin on estetty. Ota yhteys järjestelmän ylläpitäjään. !ENTITY versioninfo.wizard.titleTarkistetaan lisäosien yhteensopivuutta
Bug#399923: iceweasel-locale-fi: The name Iceweasel should be localized
Package: iceweasel-locale-fi Version: 2.0-0.1 Severity: important Tags: l10n I installed iceweasel-locale-fi_2.0-0.1_all.deb from the location mentioned in the following bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399780 In this version, the About Iceweasel popup still says Firefox below the globe symbol. It also erroneously claims that Iceweasel and the Iceweasel logo are trademarks of the Mozilla Foundation. The name Iceweasel feels a bit difficult for Finnish users. Fire and fox are much more familiar words than weasel. I would suggest that the name be localized, given that it is not a trademark. In Finnish, it would be Jäänäätä or Debianin Jäänäätä, e.g.: brandShortName=J\u00E4\u00E4n\u00E4\u00E4t\u00E4 brandFullName=Debianin J\u00E4\u00E4n\u00E4\u00E4t\u00E4 vendorShortName=Debian in brand.properties. Generally, I would try to apply the following changes to the original translation and review the result: s/Firefoxi/Jäänäädä/g s/Firefox\/Jäänäätä/g -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Versions of packages iceweasel-locale-fi depends on: ii iceweasel 2.0+dfsg-1 lightweight web browser based on M iceweasel-locale-fi recommends no packages. -- no debconf information
Bug#395014: opcontrol: arith: syntax error: NR_CHOSEN - 1
Package: oprofile-common
Version: 0.9.2-1
Severity: important
Tags: patch
The /bin/sh script /usr/bin/opcontrol lacks some $ signs in $(( ))
expressions. Furthermore, I tend to believe that the construct does
not work in plain Bourne shells, meaning that the #!/bin/sh line
should be replaced with #!/bin/bash. However, I am unsure of that.
Here is the patch:
--- /usr/bin/opcontrol 2006-09-22 07:08:59.0 +0300
+++ opcontrol 2006-10-24 15:27:22.425303088 +0300
@@ -316,7 +316,7 @@ do_save_setup()
$SETUP_FILE
if test $NR_CHOSEN != 0; then
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
echo CHOSEN_EVENTS_${f}=$GOTEVENT $SETUP_FILE
done
@@ -537,7 +537,7 @@ verify_counters()
OPHELP_ARGS=
if test $NR_CHOSEN != 0; then
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
if test $GOTEVENT != ; then
OPHELP_ARGS=$OPHELP_ARGS $GOTEVENT
@@ -559,7 +559,7 @@ normalise_events()
return
fi
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
if test $GOTEVENT != ; then
EVENT=`echo $GOTEVENT | awk -F: '{print $1}'`
@@ -1106,7 +1106,7 @@ do_param_setup()
verify_counters
OPROFILED_EVENTS=
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
if test $GOTEVENT != ; then
EVENT=`echo $GOTEVENT | awk -F: '{print $1}'`
@@ -1238,7 +1238,7 @@ do_status()
fi
if test $NR_CHOSEN != 0; then
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
echo Event $f: $GOTEVENT
done
Best regards,
Marko
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18
Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8)
Versions of packages oprofile-common depends on:
ii binutils 2.17-3 The GNU assembler, linker and bina
ii debconf [debconf-2.0]1.5.6 Debian configuration management sy
ii libc62.3.6.ds1-7 GNU C Library: Shared libraries
ii libgcc1 1:4.1.1-17 GCC support library
ii libpopt0 1.10-3 lib for parsing cmdline parameters
ii libstdc++6 4.1.1-17The GNU Standard C++ Library v3
oprofile-common recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395014: [PATCH] Make opcontrol work with bash
After filing the report, I noticed other errors. With the attached
patch applied, I was able to run the following commands:
opcontrol --list-events
opcontrol --event CPU_CLK_UNHALTED:9:0:1:1
opcontrol --reset
opcontrol --start
opcontrol --stop
Best regards,
Marko
--- /usr/bin/opcontrol.orig 2006-09-22 07:08:59.0 +0300
+++ /usr/bin/opcontrol 2006-10-24 15:38:33.0 +0300
@@ -316,7 +316,7 @@ do_save_setup()
$SETUP_FILE
if test $NR_CHOSEN != 0; then
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
echo CHOSEN_EVENTS_${f}=$GOTEVENT $SETUP_FILE
done
@@ -537,7 +537,7 @@ verify_counters()
OPHELP_ARGS=
if test $NR_CHOSEN != 0; then
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
if test $GOTEVENT != ; then
OPHELP_ARGS=$OPHELP_ARGS $GOTEVENT
@@ -559,7 +559,7 @@ normalise_events()
return
fi
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
if test $GOTEVENT != ; then
EVENT=`echo $GOTEVENT | awk -F: '{print $1}'`
@@ -1106,7 +1106,7 @@ do_param_setup()
verify_counters
OPROFILED_EVENTS=
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
if test $GOTEVENT != ; then
EVENT=`echo $GOTEVENT | awk -F: '{print $1}'`
@@ -1119,7 +1119,7 @@ do_param_setup()
UNIT_MASK=`echo $GOTEVENT | awk -F: '{print $3}'`
KERNEL=`echo $GOTEVENT | awk -F: '{print $4}'`
USER=`echo $GOTEVENT | awk -F: '{print $5}'`
- CTR=`echo $HW_CTRS | awk {print \\$$((f + 1))}`
+ CTR=`echo $HW_CTRS | awk {print \\$$(($f + 1))}`
if test $EVENT = RTC_INTERRUPTS; then
set_param rtc_value $COUNT
@@ -1127,7 +1127,7 @@ do_param_setup()
else
set_ctr_param $CTR enabled 1
set_ctr_param $CTR event $EVENT_VAL
- let loop_count=1
+ loop_count=1
for i in ${EVENT_STR}; do
#Skip first argument of EVENT_STR
(event val) since we've already
#processed that value.
@@ -1136,7 +1136,7 @@ do_param_setup()
VAL=`echo $i | awk -F: '{print
$2}'`
set_ctr_param $KEY $VAL
fi
- let loop_count=$loop_count+1
+ loop_count=$loop_count+1
done
set_ctr_param $CTR count $COUNT
set_ctr_param $CTR kernel $KERNEL
@@ -1238,7 +1238,7 @@ do_status()
fi
if test $NR_CHOSEN != 0; then
- for f in `seq 0 $((NR_CHOSEN - 1))`; do
+ for f in `seq 0 $(($NR_CHOSEN - 1))`; do
get_event $f
echo Event $f: $GOTEVENT
done
Bug#374610: msmtp: TLS handshake failed: A TLS fatal alert has been received.
Hi Julien, Martin, others, On Sat, Jul 01, 2006 at 07:56:27PM +0300, Marko Mäkelä wrote: Hi Julien, Sorry, I do not remember receiving your message from June 20. Good that you followed up. Sorry, it must be something with my spam filter or the mail server. I did not receive any of the follow-up mails, and thus I didn't test the patches that you and others very helpfully provided. I can confirm that tls_force_sslv3 with msmtp 1.4.7-2 does the trick. Thank you very much! I will also try to point out this bug to the developers of the SMTP server. As far as I understand, the piece of software is under active development (and beta testing). Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363764: #363764 - thunderbird: Header charset conversion error from iso-8859-1 when replying
On Wed, Aug 16, 2006 at 02:52:21AM +0200, Alexander Sack - Debian Bugmail wrote: Sorry for the late answer, Does this problem still show up in new thunderbird versions? The bug appears to have been fixed. However, users of non-MIME-capable MUAs (or those who access their mail archives with traditional Unix text processing utilities) would probably appreciate it if Thunderbird didn't use =?UTF-8?B?..?= encoding in the headers. Mutt seems to only encode words containing non-ASCII characters, and it prefers ISO 8859-1 whenever possible. Example: Mutt encodes the From line Marko Mäkelä as From: Marko =?iso-8859-1?B?TeRrZWzk?= [EMAIL PROTECTED] while Thunderbird encodes the whole string in UTF-8: From: =?UTF-8?B?TWFya28gTcOka2Vsw6Q=?= [EMAIL PROTECTED] Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374610: msmtp: TLS handshake failed: A TLS fatal alert has been received.
On Mon, Jul 03, 2006 at 12:53:44AM +0200, Julien Louis wrote: On Sun, Jul 02, 2006 at 07:37:54PM +0300, Marko Mäkelä wrote: Indeed, replacing --with-ssl=gnutls in DEB_CONFIGURE_EXTRA_FLAGS with --with-ssl=openssl does the trick. I hope you can find out what gnutls is doing differently from openssl. it seems gnutls can open a new encrypted connection on your server. But it can't do it with the TLS protocol, try the following commands: gnutls-cli -s -p 1025 your.mailserver.com at prompt enter the following command (one for each prompt): EHLO example.com STARTTLS Ctrl-D The handshake negocation fails. I got a SIGSEGV, using the gnutls-cli from gnutls-bin Version: 1.4.0-2: STARTTLS 220 begin TLS *** Starting TLS handshake *** Fatal error: A TLS fatal alert has been received. *** Received alert [10]: Unexpected message *** Handshake has failed Program received signal SIGSEGV, Segmentation fault. 0x0804dcfa in ?? () (gdb) bt #0 0x0804dcfa in ?? () #1 0xb7eba740 in _IO_2_1_stdout_ () from /lib/tls/libc.so.6 #2 0x0001 in ?? () #3 0x0019 in ?? () #4 0xb7eba480 in _IO_list_all () from /lib/tls/libc.so.6 #5 0xbfff53f4 in ?? () #6 0x in ?? () Isn't this a potential security hole in gnutls-cli? Now try with the following command: gnutls-cli -s --protocols ssl3.0 -p 1025 your.mailserver.com at prompt enter the following command (one for each prompt): EHLO example.com STARTTLS Ctrl-D You get the server certificate, now look at the protocol version used. Indeed: SSL 3.0. it seems msmtp can't connect to server which use SSL 3.0 protocol. A solution might be to link against libgnutls-openssl to add support for openssl 3.0 compatibility layer. I'm glad to test any patches, if that is needed. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374610: msmtp: TLS handshake failed: A TLS fatal alert has been received.
On Sun, Jul 02, 2006 at 01:44:24AM +0200, Julien Louis wrote: I remember reporting a similar bug against mutt a couple of years ago. It wouldn't talk to imaps.hut.fi when linked against gnutls, but it worked when linked against libssl (built myself from the source). Some gnutls parameters were changed, and it has worked fine since. Interesting, i will try to reproduce this bug and find a fix for this issue. I meant that the mutt bug has been fixed in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196117;archive=yes I will rebuild msmtp from source and report the results. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374610: msmtp: TLS handshake failed: A TLS fatal alert has been received.
On Sun, Jul 02, 2006 at 01:44:24AM +0200, Julien Louis wrote: Did you try to rebuild against openssl, i've just rebuild against openssl and it seems to work. Indeed, replacing --with-ssl=gnutls in DEB_CONFIGURE_EXTRA_FLAGS with --with-ssl=openssl does the trick. I hope you can find out what gnutls is doing differently from openssl. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374610: msmtp: TLS handshake failed: A TLS fatal alert has been received.
Hi Julien, Sorry, I do not remember receiving your message from June 20. Good that you followed up. On Sat, Jul 01, 2006 at 06:05:05PM +0200, Julien Louis wrote: On Tue, Jun 20, 2006 at 10:19:23PM +0200, Julien Lousi wrote: [snip] On msmtp 1.4.5-1, the line 220 begin TLS is followed by TLS certificate information: etc. I have the same result with msmtp 1.4.6-1 and an exim4 server with a self-signed certificate. I can provide the server name in private email, if it is needed for troubleshooting. It seems to me that the username and password will be sent only after the TLS handshake has completed. Yes, please send me the server name, i try will do some checks. msmtp 1.4.5-1 was accidentally linked against libssl, did you remember if previous versions worked ? Same problem with 1.4.6-2. Originally, I tried msmtp somewhere last October or November, and it didn't work with this server. That may have been because of a bug in the server at that time; it is running kind of beta test code. I tried again on January 20, 2006, with success. So, it looks like only 1.4.5-1 has worked for me. The version I originally tried must have been 1.4.4-3. Does the bug still appear in the current (1.4.6-2) version ? Some more info about the server would be appreciated. I will send you my msmtp config in a private message. The connection fails before the username/password authentication. I remember reporting a similar bug against mutt a couple of years ago. It wouldn't talk to imaps.hut.fi when linked against gnutls, but it worked when linked against libssl (built myself from the source). Some gnutls parameters were changed, and it has worked fine since. Best regards, Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374610: msmtp: TLS handshake failed: A TLS fatal alert has been received.
Package: msmtp Version: 1.4.6-1 Severity: grave msmtp 1.4.6-1 refuses to initiate a STARTTLS connection to a server that works fine with msmtp 1.4.5-1. Downgrading to 1.4.5-1 worked around the problem. Here's what happens on 1.4.6-1. I replaced the addresses with example.com: msmtp -d -C example-msmtp [EMAIL PROTECTED] -f [EMAIL PROTECTED] ignoring system configuration file /etc/msmtprc: No such file or directory loaded user configuration file example-msmtp using account default from example-msmtp host= stmail.example.com. port= 1025 timeout = off protocol= smtp domain = example.com auth= PLAIN user= [EMAIL PROTECTED] password= * ntlmdomain = (not set) tls = on tls_trust_file = (not set) tls_key_file= (not set) tls_cert_file = (not set) tls_starttls= on tls_certcheck = off auto_from = off maildomain = (not set) from= [EMAIL PROTECTED] dsn_notify = (not set) dsn_return = (not set) keepbcc = off logfile = (not set) syslog = (not set) reading recipients from the command line -- 220 server ready. Unauthorized Access Prohibited. -- EHLO example.com -- 250-server.example.com Hello client.example.com, pleased to meet you -- 250-8BITMIME -- 250-SIZE 15728640 -- 250-DSN -- 250-ENHANCEDSTATUSCODES -- 250-STARTTLS -- 250-AUTH DIGEST-MD5 CRAM-MD5 -- 250-XAUTH -- 250 HELP -- STARTTLS -- 220 begin TLS msmtp: TLS handshake failed: A TLS fatal alert has been received. msmtp: could not send mail (account default from example-msmtp) On msmtp 1.4.5-1, the line 220 begin TLS is followed by TLS certificate information: etc. I can provide the server name in private email, if it is needed for troubleshooting. It seems to me that the username and password will be sent only after the TLS handshake has completed. Marko -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.16.19 Locale: LANG=fi_FI, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Versions of packages msmtp depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libgsasl7 0.2.12-1 GNU SASL library ii libssl0.9.8 0.9.8b-2 SSL shared libraries Versions of packages msmtp recommends: pn libgcrypt none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#201602: gnome-terminal cannot send NUL character
Hi, I tried to debug a microcontroller application with C-Kermit and gnome-terminal. I can send other control characters fine, but the NUL character (ctrl-2 on my keyboard), which works fine in xterm and (I think) has worked fine in previous versions of gnome-terminal, appears to be ignored by this version of gnome-terminal. This is not a bug, but a feature! :) It could also be that the bug has been fixed during the 2.5 years the report was open. In gnome-terminal 2.12.0-2 with the X11 or default input method selected, ctrl-2 through ctrl-7 do generate proper codes, i.e., the same ones the Linux console or a real Digital VT220 terminal would. (To see the NUL character, run something like od -t x1; bash would drop it.) It seems Ctrl+digit (or Ctrl+Shift+digit on french keyboards) is a way to type characters via their ASCII or UTF-8 code. This appears to be something else. Thanks for the tip; I wasn't aware of the ctrl+shift+digit feature. In any case, the bug can be closed. [It looks like you mistyped the control address in your message.] Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329618: Still terminates
On Sun, Jan 15, 2006 at 11:43:01PM -0500, Eric Dorland wrote: It still terminates when I visit the page. Attached is a simplified test case that refers to two files (CSS and a 10,000 by 1 bitmap) on the server. Note that the HTML is valid, and also the CSS looks valid to my untrained eye. Can you run from a terminal and see if you get any messages? Meanwhile, I've updated mozilla-firefox from 1.5.dfsg-3 to 1.5.dfsg-4, and neither my simplified test case nor the original page will cause Firefox to terminate. That is, the bug appears to be fixed in mozilla-firefox 1.5.dfsg-4. Of course, it is also possible that the CSS has been changed, or some data structures are aligned differently in the new build. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329618: Still terminates
Package: mozilla-firefox Version: 1.5.dfsg-3 It still terminates when I visit the page. Attached is a simplified test case that refers to two files (CSS and a 10,000 by 1 bitmap) on the server. Note that the HTML is valid, and also the CSS looks valid to my untrained eye. Marko Title: Suomen Pankki - Finlands Bank - Bank of Finland
Bug#334869: Header charset conversion error from iso-8859-1 when replying
Package: mozilla-thunderbird Version: 1.0.7-2 When I send a message with mutt, the From: field encodes my last name correctly as =?iso-8859-1?B?TeRrZWzk?=. When I start composing a reply in mozilla-thunderbird, the To: header in the composer contains Marko U+FFFD (where U+FFFD is the Unicode REPLACEMENT CHARACTER). If the reply is sent as such, the To: header will be encoded as =?UTF-8?B?TWFya28g77+9?=, or Marko U+FFFD. The same bug seems to occur whenever the From: header of the original message contains non-ASCII characters that are encoded in iso-8859-1. With best regards, Marko Mäkelä -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334869: Acknowledgement (Header charset conversion error from iso-8859-1 when replying)
Note that if the Subject: line contains an iso-8859-1 encoded string, it will appear correctly in the Composer when replying. Maybe this bug only affects headers that contain email addresses? Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329618: terminates when visiting http://www.bof.fi/fin/0_new/0.1_valuuttak/
Package: mozilla-firefox Version: 1.0.6-5 Severity: grave Firefox terminates without any warning when the currency conversion table of Bank of Finland http://www.bof.fi/fin/0_new/0.1_valuuttak/ is visited. I attached gdb to the mozilla-firefox process, but it wasn't very useful: the process would terminate with status 1. about:plugins does not report any installed plugins. Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
