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
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
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
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
Bugs, which is subscribed to Ubuntu.
https
** 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
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
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
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
** Bug watch added: GNOME Bug Tracker #616832
https://bugzilla.gnome.org/show_bug.cgi?id=616832
** Also affects: eog via
https://bugzilla.gnome.org/show_bug.cgi?id=616832
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
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
>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
13 matches
Mail list logo
