Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #228587 > unrolled thread

Re: GTK can't load images

Started bymmDebMail2020@marwedels.de
First post2020-11-12 00:20 +0100
Last post2020-11-13 09:30 +0100
Articles 6 — 5 participants

Back to article view | Back to linux.debian.user


Contents

  Re: GTK can't load images mmDebMail2020@marwedels.de - 2020-11-12 00:20 +0100
    Re: GTK can't load images The Wanderer <wanderer@fastmail.fm> - 2020-11-12 01:00 +0100
      Re: GTK can't load images dmacdoug <dmacdoug@usc.edu> - 2020-11-12 05:10 +0100
    Re: GTK can't load images <tomas@tuxteam.de> - 2020-11-12 09:40 +0100
      Re: GTK can't load images Malte Marwedel <mmDebMail2020@marwedels.de> - 2020-11-12 23:30 +0100
        Re: GTK can't load images <tomas@tuxteam.de> - 2020-11-13 09:30 +0100

#228587 — Re: GTK can't load images

FrommmDebMail2020@marwedels.de
Date2020-11-12 00:20 +0100
SubjectRe: GTK can't load images
Message-ID<Ba7zb-Qi-1@gated-at.bofh.it>
 > On Wednesday 11 November 2020 07:06:31 The Wanderer wrote:
 > > At a glance, this doesn't look like it means the program thinks the
 > > file isn't present, but that it thinks the file is in an invalid
 >> format.
 >
 >> Have you confirmed that this file is in fact a valid PNG, and can be
 >> opened and displayed correctly?
data=data@entry=0x555555c9120c "\211PNG\r\n\032\n"

I think is clearly png. Moreover ristrettro stopped to display all 
images I have tested so far.

 >> If it is, then I would suspect that something about GTK's ability to
 >> recognize and load that file format has become broken. The error
 >> messages from your compilation attempt seem to support that idea.

 > I can verify that same failure, but stretch at least then falls back
 > to gimp to display the image. Started at least a week ago. Seems to me
 > I saw a libpixbuf update go by.

I got so far as cache_get_mime_type_for_data in glib2.0-2.58.3 in 
xdgmimecache.c not finding a proper entry and then XDG_MIME_TYPE_UNKNOWN 
(=application/octet_stream) is reported. And there is obviously no 
loader for this fallback ;)

 > >  $ grep .-debug /etc/apt/sources.list
 > >  #deb http://debug.mirrors.debian.org/debian-debug/ stable-debug
 > > main non-free contrib
Thanks, I never knew about those repositories, this made debugging easier :)

[toc] | [next] | [standalone]


#228588

FromThe Wanderer <wanderer@fastmail.fm>
Date2020-11-12 01:00 +0100
Message-ID<Ba8bT-12B-1@gated-at.bofh.it>
In reply to#228587

[Multipart message — attachments visible in raw view] — view raw

On 2020-11-11 at 17:57, mmDebMail2020@marwedels.de wrote:

> On Wednesday 11 November 2020 07:06:31 The Wanderer wrote:
> 
>> At a glance, this doesn't look like it means the program thinks the
>> file isn't present, but that it thinks the file is in an invalid
>> format.
> 
>> Have you confirmed that this file is in fact a valid PNG, and can
>> be opened and displayed correctly?
> 
> data=data@entry=0x555555c9120c "\211PNG\r\n\032\n"

Where does this come from? I don't recognize it at a glance.

> I think is clearly png. Moreover ristrettro stopped to display all
> images I have tested so far.

I've never heard of 'ristrettro' before, and I don't find it mentioned
with 'apt-cache search'. A few of the Google results for that search
term look like they may be related, but don't seem helpful in finding
out what it actually is.

What I was thinking of as a way to confirm whether this is a PNG is to
A: first check e.g. the output of 'file' on the file, and then B: open
it in an image viewer which can handle PNGs and is known working, maybe
even one on a different computer.

>>  $ grep .-debug /etc/apt/sources.list
>>  #deb http://debug.mirrors.debian.org/debian-debug/ stable-debug main non-free contrib
> 
> Thanks, I never knew about those repositories, this made debugging
> easier :)

They're a comparatively recent addition to Debian; the idea as I
understand it is to both split out the debug-symbols packages so that
people who don't care about them don't need to have them show up in
package searches, and make it practical to have such packages be
autogenerated for all relevant packages rather than only existing if the
maintainer set things up to specifically generate one.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]


#228593

Fromdmacdoug <dmacdoug@usc.edu>
Date2020-11-12 05:10 +0100
Message-ID<Bac5P-3CK-1@gated-at.bofh.it>
In reply to#228588
On Wed, Nov 11, 2020 at 06:58:56PM -0500, The Wanderer wrote:
> On 2020-11-11 at 17:57, mmDebMail2020@marwedels.de wrote:
> 
> > On Wednesday 11 November 2020 07:06:31 The Wanderer wrote:
> > 
> >> At a glance, this doesn't look like it means the program thinks the
> >> file isn't present, but that it thinks the file is in an invalid
> >> format.
> > 
> >> Have you confirmed that this file is in fact a valid PNG, and can
> >> be opened and displayed correctly?
> > 
> > data=data@entry=0x555555c9120c "\211PNG\r\n\032\n"
> 
> Where does this come from? I don't recognize it at a glance.
> 
> > I think is clearly png. Moreover ristrettro stopped to display all
> > images I have tested so far.
> 
> I've never heard of 'ristrettro' before, and I don't find it mentioned
> with 'apt-cache search'. A few of the Google results for that search
> term look like they may be related, but don't seem helpful in finding
> out what it actually is.
> 
> What I was thinking of as a way to confirm whether this is a PNG is to
> A: first check e.g. the output of 'file' on the file, and then B: open
> it in an image viewer which can handle PNGs and is known working, maybe
> even one on a different computer.
> 
> >>  $ grep .-debug /etc/apt/sources.list
> >>  #deb http://debug.mirrors.debian.org/debian-debug/ stable-debug main non-free contrib
> > 
> > Thanks, I never knew about those repositories, this made debugging
> > easier :)
> 
> They're a comparatively recent addition to Debian; the idea as I
> understand it is to both split out the debug-symbols packages so that
> people who don't care about them don't need to have them show up in
> package searches, and make it practical to have such packages be
> autogenerated for all relevant packages rather than only existing if the
> maintainer set things up to specifically generate one.
> 
Ristretto (no r before the final o) is an image viewer.  It's in debian main

Maintainer: Debian Xfce Maintainers
Homepage:   https://docs.xfce.org/apps/ristretto/start

Cheers,
Don MacDougall

[toc] | [prev] | [next] | [standalone]


#228595

From<tomas@tuxteam.de>
Date2020-11-12 09:40 +0100
Message-ID<Bagj7-66M-1@gated-at.bofh.it>
In reply to#228587

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 11, 2020 at 11:57:08PM +0100, mmDebMail2020@marwedels.de wrote:

[...]

> I think is clearly png [...]

[...]

> I got so far as cache_get_mime_type_for_data in glib2.0-2.58.3 in
> xdgmimecache.c not finding a proper entry [...]

I don't know (not sure I'd want to) where Gtk keeps its MIME types
database these days. But, as a shot in the dark: have you checked
that your /etc/mime.types is sane? What does 'grep png /etc/mime.types'
say?

The file comes with Debian package mime-support, in case you need
a new one.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]


#228604

FromMalte Marwedel <mmDebMail2020@marwedels.de>
Date2020-11-12 23:30 +0100
Message-ID<Batgl-5sl-5@gated-at.bofh.it>
In reply to#228595
Am 12.11.20 um 09:35 schrieb tomas@tuxteam.de:
> On Wed, Nov 11, 2020 at 11:57:08PM +0100, mmDebMail2020@marwedels.de wrote:

> I don't know (not sure I'd want to) where Gtk keeps its MIME types
> database these days. But, as a shot in the dark: have you checked
> that your /etc/mime.types is sane? What does 'grep png /etc/mime.types'
> say?
> 
> The file comes with Debian package mime-support, in case you need
> a new one.

I fixed the error.
After figuring out, that glib2.0 had no data to compare the png data to 
in cache_get_mime_type_for_data, I stepped through 
xdg_mime_init_from_directory and discovered only a few data for 
mimetypes were added from my ~/.local/share directory. Stepping through 
the same code on a different computer, most data came from 
/usr/share/mime/mime.cache, but the file was missing on my computer.
Running update-mime-database /usr/share/mime/ as root solved the 
problem. Took me ~7 hours to figure this out ;) Maybe this was the 
result of an upgrade. Because this was when the error occurred the first 
time.

[toc] | [prev] | [next] | [standalone]


#228617

From<tomas@tuxteam.de>
Date2020-11-13 09:30 +0100
Message-ID<BaCCZ-2GQ-1@gated-at.bofh.it>
In reply to#228604

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 12, 2020 at 11:20:55PM +0100, Malte Marwedel wrote:
> Am 12.11.20 um 09:35 schrieb tomas@tuxteam.de:
> >On Wed, Nov 11, 2020 at 11:57:08PM +0100, mmDebMail2020@marwedels.de wrote:
> 
> >I don't know (not sure I'd want to) where Gtk keeps its MIME types
> >database these days. But, as a shot in the dark: have you checked
> >that your /etc/mime.types is sane? What does 'grep png /etc/mime.types'
> >say?
> >
> >The file comes with Debian package mime-support, in case you need
> >a new one.
> 
> I fixed the error.

[... mime.cache]

Thanks for reporting back. Much appreciated :)

Cheers
 - t

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web