To anyone still affected by this:
GNOME Color Manager developers are interested in verifying your
autogenerated display color profiles.
See https://bugzilla.gnome.org/show_bug.cgi?id=675645#c11 and
http://blog.pcode.nl/2013/04/14/display-profiles-generated-from-edid/
** Bug watch added: GNOME Bu
Hi Tom,
I stumbled over your patch by googling the maximum image dimensions error
message and I pulled it into our git:
http://git.gnome.org/browse/eog/commit/?id=11f05ec911b4208faa8f00ecd9f4830ca39fcb25
Thanks for investigating this.
Btw, we had to integrate the transupp.{c,h} files as these ro
** Bug watch added: GNOME Bug Tracker #675569
https://bugzilla.gnome.org/show_bug.cgi?id=675569
** Also affects: eog via
https://bugzilla.gnome.org/show_bug.cgi?id=675569
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Well, I wouldn't exclude eog as the culprit, but for now it looks like
an issue with the active display profile which appear to be
autogenerated by g-c-m. So the g-c-m people should at least be queried
for input on what could be wrong here (maybe it's just a simple fault).
But considering that the
You should probably contact gnome-color-manager developers about this as
g-c-m is IIRC able to autogenerate a profile from your display's EDID
data if display and driver support it.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to eog i
Could everyone still having the problem check if an ICC profile is set
for his display by running:
xprop -root | grep ICC_PROFILE
If none is set the grep should be empty (besides a possible
_ICC_PROFILE_IN_X_VERSION entry).
If one is set unset it with
xprop -root -remove _ICC_PROFILE
the chec
The wrong colors are what I meant in the last paragraph with libopenraw
not being entirely painless yet.
The reason for why it worked before could be changes in libtiff assuming the
library version changed between Ubuntu versions.
libtiff-3.9.5 apparently became a bit more strict regarding the TI
Please note that eog doesn't support RAW images out of the box. To have
it use the actual RAW data it needs the gdk-pixbuf loader from
libopenraw installed (which according to packages.ubuntu.com doesn't
seem to be shipped with Ubuntu).
If the loader is not installed, often the TIFF loader will ki
The problem was that the scrollbars limit values were not updated
correctly when the size of the display area changed. So you could either
not scroll far enough (like here) or you could scroll too far and would
produce garbage (the more commonly experienced variant, bugs #653920,
#768197).
That i
>From comment #1:
> libglib2.0-0 2.31.0-0ubuntu1~oneiric1
>From #6
> --4093-- Reading syms from /usr/lib/i386-linux-gnu/libgthread-2.0.so.0.3100.0
> (0x4c97000)
Is there a reason you are running using unstable glib releases?
Anyway glib-2.31.0 is known to deadlock eog. See bug 662630 in GNOME
Bu
JFYI, the differentiation is pretty easy here.
eog-2.32.1 has the workaround, while a stock 2.32.0 (as likely included in
Ubuntu 10.10) doesn't unless patched (like e.g. in Fedora 14).
Since the bug depends on the running order of the plugin thread and the
image loading thread the bug might not b
The lsof output in #3 suggests that you have the "Date in statusbar" plugin
enabled.
This plugin has a known race condition which could prevent the program window
from being shown on start.
To check you can try if it is still reproducible with the plugin
disabled.
Alternatively, the problem was
12 matches
Mail list logo
