$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu karmic (development branch)
Release:9.10
Codename: karmic
$ uname -a
Linux ayaki 2.6.31-6-generic #25-Ubuntu SMP Fri Aug 14 16:25:04 UTC 2009 i686
GNU/Linux
** Attachment added: "dmesg.txt
** Attachment added: "lspci -vvnn"
http://launchpadlibrarian.net/30692914/lspci.txt
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/30692915/Dependencies.txt
--
ALSA/PulseAudio output connector identification wrong on Dell XPS M1330 (Karmic
A3)
https://bugs.launchpa
Public bug reported:
Binary package hint: gnome-media
gnome-volume-control or the underlying PulseAudio / ALSA system(s)
misidentify the output channels on this Dell XPS M1330 laptop.
The "Analog Output" connector, which is selected by default, is the
2ndary headphone / line out port.
The "Anal
Further investigation reveals that the issue is mostly (entirely?)
confined to one user account. While many accounts have messages with the
IMAP "Junk" flag set, most are older messages that could well have been
manually set by the user with Thunderbird. However, they could also have
been set by Ev
It's a bug alright, though the original reporter may not have been as
clear about it as they should.
Junk filtering is DISABLED in evolution (edit -> preferences -> junk,
ensure "check incoming messages for junk" is unchecked and to be safe
uncheck "check custom headers for junk"). Despite that, m
hardy-updates? Sorry, brain fart. jaunty-updates is a lot saner, given
that the package in question is 2.26.1-0ubuntu2 in Jaunty.
--
Upstream evolution patch rel 2.26.2 fixes messages marked read in junk folder
https://bugs.launchpad.net/bugs/401442
You received this bug notification because you
Public bug reported:
Binary package hint: evolution
I'm being bitten by an issue where Evolution is "helpfully" marking
messages it filters into the user's junk folder as read. This makes it
much harder for the user to occasionally check the junk folder to see if
legit messages have been trapped.
Please disregard my previous report. The CUPS server was finding
printers exported by a Debian Lenny box. Lenny's poppler source package
lacks debian/patches/63_do-not-make-ps-arrays-bigger-than-64k-from-big-
images-in-patterns.patch .
** Changed in: eog (Ubuntu)
Status: New => Invalid
**
Ah - I only just noticed that this bug had been targeted specifically at
poppler. The issue is on eog 2.26.1 on Jaunty with all updates. I'll
file a new bug.
--
Array too big when printing large image
https://bugs.launchpad.net/bugs/311982
You received this bug notification because you are a memb
eog also appears to produce oversize arrays when printing large images,
resulting in errors like:
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Error: /limitcheck in --array--
D [25/Jun/2009:16:53:00 +0800] [Job 172688] Operand stack:
D [25/Jun/2009:16:53:00 +0800] [Job 172688] 90223
D [25/Jun/2009:
Matthias Clasen from Red Hat tackled the underlying gtk+ bug (
http://bugzilla.gnome.org/show_bug.cgi?id=585626 ) and has committed a
patch to gtk+ head that dramatically improves things.
See the gtk+ bug I've linked to for his patch, and some instructions
I've written on easily applying the fix t
It's a gtkhtml bug, or possibly a libgtk+ bug.
A workaround is to patch libgtkhtml and rebuild it. Instructions:
$ sudo apt-get install fakeroot build-essential wget
$ sudo apt-get build-dep gtkhtml3.14
$ mkdir $HOME/gtkhtml
$ cd $HOME/gtkhtml
$ apt-get source gtkhtml3.14
$ wget http://launchpadl
** Attachment added: "Quick gtkhtml hack/workaround"
http://launchpadlibrarian.net/27859768/bug585626.diff
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug
** Bug watch added: GNOME Bug Tracker #585626
http://bugzilla.gnome.org/show_bug.cgi?id=585626
** Also affects: gtkhtml via
http://bugzilla.gnome.org/show_bug.cgi?id=585626
Importance: Unknown
Status: Unknown
--
Long delay before new/compose window appears
https://bugs.launchpad.
Cloning my comment from the GNOME bug, since I've identified pretty much
exactly what factor controls whether or not this issue happens:
If you enable your local X server to listen on TCP/IP (on most GNOME desktops,
edit /etc/gdm/gdm.conf (may be /etc/X11/gdm/gdm.conf depending on
distro/ve
** Bug watch added: GNOME Bug Tracker #585624
http://bugzilla.gnome.org/show_bug.cgi?id=585624
** Also affects: evolution via
http://bugzilla.gnome.org/show_bug.cgi?id=585624
Importance: Unknown
Status: Unknown
--
Long delay before new/compose window appears
https://bugs.launchpa
A sequence of backtraces taken across all threads while waiting for the
compose window to appear.
I can do more specific, or controlled, debugging if someone can offer a
suggestion as to where to start. Right now, I don't know evo's guts well
enough to have much idea, though I haven't yet dug thro
Forgot to mention:
libx11-6
2:1.1.99.2-1ubuntu2
libgtk2.0-0
2.16.1-0ubuntu2
libglib2.0-0
2.20.1-0ubuntu2
running kernel: 2.6.28-11-server
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a member of Ubunt
** Attachment added: "Repeated section, evo only traffic, one repeat (pcap)"
http://launchpadlibrarian.net/27806581/trace_repeated_section.pcap
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a member of
As you can see the packets per second graph is rather more interesting.
When we look at what the traffic actually is (note: using "view -> time
display format -> time of day" is useful), it's possible to see the same
sequence of packets repeated during the long delay:
(C: client; S: server)
C ->
** Attachment added: "I/O, packets per second, during session (evo traffic
only)"
http://launchpadlibrarian.net/27806288/iograph_evoonly_packets.png
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a mem
In the trace attached to the last comment, the new button click is
packet 3664 at 11:37:30.98 . The window appears, as noted, around
11:37:47.
The attached graph and the one in the next comment show I/O in
packets/second and bytes/second during this period.
** Attachment added: "I/O, bytes per se
I've attached a better trace now. It contains a full Evolution session
from start to finish, and excludes X11 traffic from the rest of the
desktop. I used `netstat' to see which clients were connected to the
Xephyr server before starting evo, fired up a tcpdump, started evo, did
the testing, used '
** Attachment added: "Repeated grab/pointer query messages"
http://launchpadlibrarian.net/27805937/trace_repeated_section.txt
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a member of Ubuntu
Desktop Bu
** Attachment added: "tcpdump of x11 traffic for whole X session during compose
window open"
http://launchpadlibrarian.net/27805934/trace.pcap
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a member of
To examine the libpcap trace, open it with Wireshark, right-click on the
first packet, and choose "Decode as". In the window that appears select
the "Transport" tab, then the "X11" protocol in the list. Hit apply,
then close.
You'll now see the decoded X11 traffic. (Note that this traffic is for
t
** Attachment added: "libpcap format protocol trace of X11 network comms during
compose window open."
http://launchpadlibrarian.net/27805425/trace.pcap
--
Long delay before new/compose window appears
https://bugs.launchpad.net/bugs/386199
You received this bug notification because you are a
Public bug reported:
On my remote X11 clients, Evolution takes 20 - 30 seconds to display the
compose / reply window. This happens on all clients, including a PXE-
booted KVM virtual machine and a Xephyr X server. The problem occurs
whether the X11 connection is ssh-tunneled or is a direct connect
Tested OK on an LTSP server with Via and Intel thin clients.
--
[new-upstream] Firefox 3.0 RC1 is available
https://bugs.launchpad.net/bugs/233922
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to devhelp in ubuntu.
--
desktop-bugs mailin
29 matches
Mail list logo
