Re: Gimp broken in Debian Sid?
- Date: Fri, 6 Jul 2018 18:44:20 -0400
- From: Cindy-Sue Causey <butterflybytes@xxxxxxxxx>
- Subject: Re: Gimp broken in Debian Sid?
On 7/6/18, Thierry Rascle <thierr26@xxxxxxx> wrote:
> On Fri, 6 Jul 2018 07:33:16 +0100
> Joe <joe@xxxxxxxxxxxxxx> wrote:
>> On Fri, 6 Jul 2018 07:58:41 +0200
>> Thierry Rascle <thierr26@xxxxxxx> wrote:
>> > Hi,
>> > I'm using Debian Sid. Gimp does not seem to work any more (the user
>> > interface does not show up). I've tried in Xmonad and in Openbox.
>> > I have no idea what causes this. I don't see any error message.
>> > Does anyone else have the same problem ?
>> > Thanks!
>> > Thierry
>> No. 2.10 behaves differently, and I find the toolbox much harder to
>> use, as I only use GIMP occasionally, but it's working. My sid is up
>> to date, but of course will be very different from your sid.
> Yes, I noticed that the toolbox has changed with 2.10 two months ago.
> There was also a new issue with the gimp-ufraw plugin, forcing the user
> to use the standalone ufraw application instead. But Gimp was usable.
> Now it is totally unusable for me. A 'ps -ef' shows a gimp process
> running but I don't see any windows in any workspace. A 'xwininfo -tree
> -root' does not list any Gimp windows. Launching Gimp from a terminal
> does not give any error message.
A half-baked memory is coming back about Thunar giving me ghost
instances in unstable or Sid, I don't remember which..
I can't quite remember, but it was something about Thunar wasn't being
properly shut down when I rebooted. Yeah, I know, I don't know if
Thunar was still open when I rebooted or if it wasn't completely
shutting down and then the reboot still didn't finish the shut down
process on top of that.
I think I learned that because Thunar wasn't coming coming up for me
in a similar way as is being described here about GIMP. However it was
happening is why there was a "ghost" lingering in the background *for
me*. I never got around to reporting a bug, and it eventually resolved
itself via some one or another upgrades back then (maybe a couple
With respect to dealing with that ghost, I have two things I do in
these kinds of instances. The first one I do is kill that ghost
instance then relaunch the problem program from within a terminal
window. Sometimes you get lucky and see a bunch of error messages that
can possibly help solve the problem.
The second thing I do... out of exasperation... is purge the problem
program THEN secondarily ALSO PURGE all the various dependency
packages. Apt-get is very neighborly about presenting that dependency
list when a user is trying to upgrade or install just after having
purged a primary package.
There's also a remove option instead of purge that may be more
appropriate. I just like the sound of *PURGE IT!* and have never had
any problems going that route. :)
The reason I purge instead of "install --reinstall" is because
"install --reinstall" *ONLY* reinstalls the specifically named
package, i.e. *no dependencies*. There may be an option that triggers
the reinstallation of dependencies, too, but I've never encountered it
I just went into "man apt-get" for a second. That reminded me that
users sometimes have good luck simply deleting existing config files
and NOT the whole program.
Those config files are the kind found in our /home directories unless
we've defined them to set up some place else. They're sometimes
(often?) only visible if we toggle CTRL+H on and off in our favorite
If that seems like a friendly option, I'd make a backup copy of the
files I intend to delete just in case that doesn't work/turns out to
be a wasted effort. Moving those out of the way while simultaneously
making a backup is as simple as renaming the file or entire folder. We
can call them anything we want, but I tend to like to rename mine with
the date last used as a point of reference.
One of the things I've learned while deliberately pushing my copies to
the limit here is that there can be upgrade/downgrade(/crossgrade)
incompatibility problems with those config files. I learned that while
working through problems with the Opera-Beta browser.
Once the config file(s) became "contaminated" with new features while
older features started falling by the wayside, that's when I first
started seeing the problems AND then tied OTHER problems to how config
files MIGHT cause our programs' success and failures over a very
extended period of time...
Talking Rock, Pickens County, Georgia, USA
* runs with duct tape *