Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #228587 > unrolled thread
| Started by | mmDebMail2020@marwedels.de |
|---|---|
| First post | 2020-11-12 00:20 +0100 |
| Last post | 2020-11-13 09:30 +0100 |
| Articles | 6 — 5 participants |
Back to article view | Back to linux.debian.user
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
| From | mmDebMail2020@marwedels.de |
|---|---|
| Date | 2020-11-12 00:20 +0100 |
| Subject | Re: 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]
| From | The Wanderer <wanderer@fastmail.fm> |
|---|---|
| Date | 2020-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]
| From | dmacdoug <dmacdoug@usc.edu> |
|---|---|
| Date | 2020-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]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-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]
| From | Malte Marwedel <mmDebMail2020@marwedels.de> |
|---|---|
| Date | 2020-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]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2020-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