Glipper dies when desktop starting

[Sam Williams]

I use glipper all the time and I find it to be the clipboard application that has been missing from Linux desktops for the longest time. In the recent Hardy development I find that glipper dies when the desktop starts. I receive the following message in an error dialog window:

The panel encountered a problem while loading OAFIID:Glipper....

The is asks if I want to remove glipper from the panel. I find this very frustrating. What is more frustrating is that once the desktop is up and running I can then install the glipper applet back on the panel and it works properly. I have only installed this as an applet and I have never tried setting up a custom launcher.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

glipper:
  Installed: 1.0-1
  Candidate: 1.0-1
  Version table:
 *** 1.0-1 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status

Traceback originally from Bug #222846:

ProblemType: Crash
Architecture: i386
Date: Sun Apr 27 03:59:12 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/lib/glipper/glipper
InterpreterPath: /usr/bin/python2.5
Package: glipper 1.0-1ubuntu1
PackageArchitecture: i386
ProcCmdline: python /usr/lib/glipper/glipper
--oaf-activate-iid=OAFIID:Glipper_Factory --oaf-ior-fd=33
ProcEnviron:
 LANG=en_US.UTF-8

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 SHELL=/bin/bash
PythonArgs: ['/usr/lib/glipper/glipper',
'--oaf-activate-iid=OAFIID:Glipper_Factory', '--oaf-ior-fd=33']
SourcePackage: glipper
Title: glipper crashed with ValueError in load()
Uname: Linux 2.6.24-16-386 i686
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev
sambashare scanner video

Traceback (most recent call last):
  File "/usr/lib/glipper/glipper", line 53, in applet_factory
    glipper.Applet.Applet(applet)
  File "/var/lib/python-support/python2.5/glipper/Applet.py", line 50, in __init__
    get_glipper_history().load()
  File "/var/lib/python-support/python2.5/glipper/History.py", line 89, in load
    self.history.append(file.read(int(length)))
ValueError: invalid literal for int() with base 10: '\x14\x0b'

Proposed Workaround:
So what to do: Look up Glipper and add a wait statement:

sudo gedit /usr/lib/glipper/glipper

Make sure the code in the beginning looks like this:

#!/usr/bin/env python

# Glipper - Clipboardmanager for GNOME
# Copyright (C) 2007 Glipper Team
# bla bla bla
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#

import time # <-- This line is new
time.sleep(8) # <-- This line is new. Change the 8 to for instance 30 if it did not help

import gobject
gobject.threads_init()

import gtk, gnomeapplet, gnome
import getopt, sys
from os.path import *

Proposed Solution(? needs to be verified):
Crashing in Intrepid too. It needs to be rebiult againsta libffi5 instead of libffi4

[Sam Williams (sam-williams)]

After I re-add the glipper applet to the panel I check ps and this is the result ( get back:

sam 5994 1 0 13:20 ? 00:00:00 python /usr/lib/glipper/glipper --oaf-activate-iid=OAFIID:Glipper_Factory --oaf-ior-fd=53

[Brewster Malevich (brews)]

I get the same. If I select the "don't delete" option when the error pops up, then log out, and log back in the same account. I do not have this same error. It is only after I reboot, or shutdown.

[Sebastien Wains (sebastienw-deactivatedaccount)]

not really helpful, but I get exactly the same problem as Sam

[Andy Lawrence (amlawrence)]

I am still getting this error also. It seems to crash about 1 out of every 3 times I boot my laptop.

[Radu Cristescu (radu.c)]

I'm running a 64bit installation of 8.04 and glipper doesn't crash. It doesn't start either. I have to kill it myself, otherwise it freezes gnome-panel.

[Radu Cristescu (radu.c)]

Just an update. Bug #205507 explained my condition. Deleting the old .glipper directory solved my problem.

[Florian Kisser (flok)]

This one, Bug #220709 and #222846 all seem to be duplicates of Bug #205507.

[Florian Kisser (flok)]

Sry, missed the "Bug" in Bug #222846 ;)

[Andrew Starr-Bochicchio (andrewsomething)]

 Florian,

I think you're right but I'm going to consolidate them here as this one already has more attention (ie was confirmed) and has been forwarded upstream. Traceback from Bug #222846 and work around from Bug #205507 have been add to this bug's description.

[Robin Sheat (eythian)]

Just a note: deleting ~/.glipper doesn't seem to be a reliable solution. I still get crashes of glipper on login much of the time.

[yop (yop)]

Maybe a other choice of clipboard manager.

Like Parcellite http://code.google.com/p/xyhthyx/

It would be nice to see that in the repo.

[Andrew Starr-Bochicchio (andrewsomething)]

yop,

Please see Bug #176485 [needs-packaging] Parcellite

A package is already availiable in my ppa: https://edge.launchpad.net/~andrewsomething/+archive

[Jean-Francois Saucier (jfsaucier)]

I can confirm this bug. If I can be of any help, just write it and I will provide what you need as soon as I can.

[Juan J. Martínez (jjmartinez)]

I confirm this bug.

From my ~/.xsession-errors:

** (gnome-panel:6362): WARNING **: panel-applet-frame.c:1270: failed to load applet OAFIID:Glipper:
System exception: IDL:Bonobo/GeneralError:1.0 : El proceso hijo no dio ningún mensaje de error, ha ocurrido un fallo desconocido

(the system exception says about an unknown error because the child didn't gave a error message, sorry because I run my system in spanish)

The problem is random and it SEEMS not related to Bug #222846 and Bug #205507.

I don't know how to get extra information from an applet, but I'll be glad to help.

[franganghi (joered)]

I will describe the solution i adopted to get glipper perfectly working on my panel.

I stopped gdm:
from terminal <sudo /etc/init.d/gdm stop>

And then gconftool:
from normal user <gconftool-2 --shutdown>

So i removed the glipper hidden dir:
from normal user <cd; rm -r .glipper>

Then restarting gdm i didn't have any crash/restart:
<sudo /etc/init.d/gdm start>

If previously added to the panel glipper in now perfectly running on my bar.
If not you have to manually re-add it to the panel by using the specific tool.

Ciao!

Franga

[Robin Sheat (eythian)]

On Tuesday 20 May 2008 21:18:14 franganghi wrote:
> If previously added to the panel glipper in now perfectly running on my
> bar. If not you have to manually re-add it to the panel by using the
> specific tool.

I did that, and it worked on one of my computers, but on another it still
crashes reliably on startup. If I re-add it it is fine until the next
startup.

--
Robin <email address hidden> JabberID: <email address hidden>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D

[SXW (ubuntu-sxw)]

I have a temporary fix for this problem. The fact that it happens sometimes led me to believe that apparently there is some daemon or environment that has not been started yet at the moment that Glipper loads (so, Glipper is "too fast" with starting). So I added a wait period in the starting of Glipper, and that fixed the problem. The time-out is in itself not a problem, I don't mind that Glipper starts for instance half a minute later, as long as I do not have to re-add it every time I boot my laptop.

So what to do: Look up Glipper and add a wait statement:

sudo gedit /usr/lib/glipper/glipper

Make sure the code in the beginning looks like this:

#!/usr/bin/env python

# Glipper - Clipboardmanager for GNOME
# Copyright (C) 2007 Glipper Team
# bla bla bla
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#

import time # <-- This line is new
time.sleep(8) # <-- This line is new. Change the 8 to for instance 30 if it did not help

import gobject
gobject.threads_init()

import gtk, gnomeapplet, gnome
import getopt, sys
from os.path import *

[Michael Nagel (nailor)]

probably the same workaround as SXW's but i can get it running by simply logging out and logging in again... it works then. only the first login is problematic. SXW's approach is less user-involving but on the long run one should find out what service glipper is expecting and explicitly wait for it.

[Jean-Francois Saucier (jfsaucier)]

I can confirm that the sleep fix work fine here.

[steve burdine (highfructose327)]

I can also confirm the SXW's sleep fix has worked great on repeated start up's , thanks SXW.

[Valent (valent-redhat-bugs)]

Description of problem:
I have added glipper widget to gnome panel and it works until I reboot and login
for the first time. Then I get an error saying that glipper has made an error
and that I get offered to delete it off the gnome panel.

If I just add it again it works ok. It seams to have some issue with gnome
during login.

Version-Release number of selected component (if applicable):

How reproducible:
50% of the time.

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:

[Pedro Fragoso (ember)]

For those on Hardy i've set up a PPA with this fix in.

http://launchpadlibrarian.net/14965046/glipper_1.0-1ubuntu2%7Eppa1_i386.deb

[leslie (laszlo-karpati)]

Thanks SXW, thats works for me!

[Derek (derek-redhat-bugs)]

Fwiw, I'm seeing this as well. Was going to raise a bug until I found this one.

[Juan (juan-redhat-bugs)]

Me too...

[Valent (valent-redhat-bugs)]

Damien do you need some feedback, logs or something to fix this issue?

[Richard (richard-redhat-bugs)]

Ditto here.
I have a couple of bugreports from bugbuddy to attach...

[Richard (richard-redhat-bugs)]

Created attachment 309677
First crash report

c/o bugbuddy

[Richard (richard-redhat-bugs)]

Created attachment 309678
Second crash report

c/o bugbuddy... I could post heaps of these, but I won't.

[Valent (valent-redhat-bugs)]

do you need some more feedback for fixing this bug?

[Radu Cristescu (radu.c)]

That sleep worked for me for a while too. Then I have no idea what I did, but at login, my drive is getting hammered, enough to make that sleep useless. I happen to be seeing trackerd using a lot of CPU at login, so I wonder if that has anything to do with the delay.

Is there a way to start the applet in debug mode to see where exactly does it crash? It's only 123 lines long, so it can't be that hard to debug it, can it?

[Martin Schaaf (mascha)]

This patch works for me.
Copy the patch go to the directory "/usr/share/python-support/glipper/glipper/".
Apply it with "patch <glipperNotStarting.patch" as root.
If this does not work made the change by hand in the History.py file.

[Emanuele Gentili (emgent)]

@ember: can you take a look ?

[Andrew Conkling (andrewski)]

Is this a duplicate of bug 175490?

[Pedro Fragoso (ember)]

@emgent, yeah we can use this too, but i'm leaving the sleep() to not crashing when trying to get before the applets.

glipper (1.0-1ubuntu2) intrepid; urgency=low

  * debian/control:
    - Bump Standards-Version to 3.8.0
    - Moved Homepage to Homepage field
  * debian/control, debian/rules:
    - Added shlibdeps and shlibs to make Lintian happy
  * debian/patches/03_minor_fix.dpatch:
    - Fix some Python warnings
    - /usr/bin/env python -> /usr/bin/python
    - Add timer to stop glipper to fail starting on reboot
      Thanks SXW, (LP: #213494)
  * debian/patches/04_glippernotstarting.dpatch
    - Patch by Martin Schaaf

 -- Pedro Fragoso <email address hidden> Fri, 01 Aug 2008 00:11:04 +0100

[Radu Cristescu (radu.c)]

Hi all,

Guess what happened to me today: other applets wanted to be deleted. Most of the applets in my bar. And that's after I removed glipper from there.

This makes me think that this is not a bug in glipper, but rather a condition in the gnome panel that spawns the applets before it is ready to handle them.

One particular thing I noticed when this happened is that gnome took a lot longer to start, which doesn't happen every time. This also sustains the idea that the problem may be somewhere else.

Cheers

[Andrew Conkling (andrewski)]

Uplink, that sounds like a different issue. Please report a new bug.

On 8/1/08, Uplink <email address hidden> wrote:
> Hi all,
>
> Guess what happened to me today: other applets wanted to be deleted.
> Most of the applets in my bar. And that's after I removed glipper from
> there.
>
> This makes me think that this is not a bug in glipper, but rather a
> condition in the gnome panel that spawns the applets before it is ready
> to handle them.
>
> One particular thing I noticed when this happened is that gnome took a
> lot longer to start, which doesn't happen every time. This also sustains
> the idea that the problem may be somewhere else.
>
> Cheers
>
> --
> [Hardy] Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Radu Cristescu (radu.c)]

Andrew, it actually sounds like the same issue, generalized.

The way I see it, the issue goes like this:

Gnome panel starts the applets too early. Glipper is "lucky" enough to start faster than the rest of the applets, so it fails to start almost every first login after powering on the system. If you log out and log back in again, most of the stuff is already in RAM, and Gnome starts a lot faster, enough for the issue to no longer reproduce.

The "sleep(8)" workaround mentioned above delays the startup of glipper. That, the way I see it, delays glipper enough so Gnome panel can set up its things. Well, until you get Gnome to start even more slowly, like I did, in which case that sleep(8) doesn't fix the issue (unless you increase it to a bigger value), and you get the failure to start again. That's what happened to me anyway.

One day, after I had glipper removed, Gnome decided to take a heck of a lot more time to boot. The effect? The same bug reported for glipper here manifested for most of the other applets. That means I was kindly offered to delete everything from the menu to the clock applet :) This happened only once, but I think I can add something that can slow down gnome panel's startup time and reproduce this issue reliably.

I also took a crash course in python the past few days, and glipper's code doesn't seem to have any bug related to its startup problem in it. The problem can occur in the bonobo initialization part, which is outside of glipper's control. I didn't read all the code though, so I can't say 100% sure that what I just said is right, but chances are high that it is.

This makes me think that this bug should be renamed and assigned to gnome panel.

Can you see my logic in here? I hope I'm not too far off from the truth.

[Radu Cristescu (radu.c)]

Oh yeah, can bugs really be renamed? Or do I have to open a new bug and reference this thread?

[Michael Nagel (nailor)]

bugs can be renamed, the description can be edited and you can mark other packages (gnome-panel!) as affected. click the yellowish thing on the right side of the title or search for " Update description / tags (see original description)" below the description (another yellowish bubble will be there)

[Andrew Conkling (andrewski)]

On Mon, Aug 4, 2008 at 5:55 PM, Uplink <email address hidden> wrote:

> One day, after I had glipper removed, Gnome decided to take a heck of a
> lot more time to boot. The effect? The same bug reported for glipper
> here manifested for most of the other applets. That means I was kindly
> offered to delete everything from the menu to the clock applet :) This
> happened only once, but I think I can add something that can slow down
> gnome panel's startup time and reproduce this issue reliably.

I think that sounds like the same surface problem (the generic error
message), but take a look at the traceback in the description and a lot of
the duplicates; it seems very specific to Glipper. The reason I suggested
posting a new bug is that Apport (and triagers) can analyze the bug to see
whether it's a duplicate of this—or any other bug.

I also took a crash course in python the past few days, and glipper's
> code doesn't seem to have any bug related to its startup problem in it.

The traceback does. Right?

[Michael Nagel (nailor)]

glipper is not actively maintained right now:
see Bug 255060

[Radu Cristescu (radu.c)]

Hmm... looks like the message trail for this bug entry treats two bugs:
- one about glipper having trouble reading stuff from a .glipper directory after upgrading (which has nothing to do with gnome panel, as you have to delete the .glipper directory for things to work out) -- looks like what is being said in the description; and
- another about glipper starting up (which I tied to gnome panel rather than being glipper's fault, because it works if you log out and then log back in without deleting the .glipper directory, yet adding a small(!) delay at the top of the script) -- which is mentioned when the time.sleep(8) workaround is suggested;

At first I had the first issue, deleted the .glipper directory, and the problem was solved forever. Then the second mentioned issue crawled in.

I renamed /usr/lib/glipper/glipper to glipper.real and put a bash script named glipper in its place, which looks like this:

#!/bin/bash
exec 1> >(tee /tmp/glipper.out) 2> >(tee /tmp/glipper.err)
exec /usr/lib/glipper/glipper.real "$@"

So now I have this text in both glipper.out and glipper.err:

 Bonobo-Activation-ERROR **: This process has not registered the required OAFIID your source code should register 'OAFIID:Glipper_Factory'. If your code is performing delayed registration and this message is trapped in error, see bonobo_activation_idle_reg_check_set.
 aborting...

With glipper.out also having a line saying "SHARED_DATA_DIR: /usr/share/glipper" before this message.

And there's no stack trace in any of those files. Unless glipper is killed because of its failure to start (on grounds that failure cannot be tolerated perhaps), a stack trace should show up if one was printed by python.

So I logged out, logged back in, glipper started this time, and I have the "normal" messages in glipper.out and glipper.err:

** (glipper.real:6500): WARNING **: Binding '<Ctrl><Alt>v' failed!

which is normal, because I have that combination bound to something else.

Sorry for turning the bug comments into a forum if I'm not supposed to do so, but it seems to me that something's not right with this entry, and debate about what should happen to it (possibly split it? send part of it to gnome-panel?).

Wish I knew that that Bonobo error meant, so I could dig deeper before posting something to gnome-panel.

[Jimmy Merrild Krag (beruic)]

I can confirm this issue from a fresh install of Hardy. Glipper dies a lot of times when logging in for the first time.

After reading everything here, I'm a bit confused on what to do and think of this problem. Should I apply the sleep solution, or install Parcellite instead? Will somebody fix Glipper?

[Tom Arnold (g0tt)]

Why hasn't the fix come with an official update yet?

[Michael Nagel (nailor)]

this is not a fix but merely a workaround. glipper is dead - (undecided) Bug 255060:

[Tom Arnold (g0tt)]

OK, I see.

But is shipping a broken version the right solution?

Installing Parcellite does not seem to be that easy.

I can see that going forward Parcellite might be the better solution ( maintained, C instead of Python ), but for now Glipper works fine with the workaround ..

[Simone Tolotti (simontol)]

Crashing in Intrepid too. It needs to be rebiult againsta libffi5 instead of libffi4

[Jacob Chappelle (circuitdesoleil)]

I have fixed the glipper start up problem with an easier solution.

First of all after installing 'glipper' with 'sudo apt-get install glipper' when we do a 'which glipper' we see that it is not found in the PATH. Hmm interesting... When I do a 'whereis glipper' it shows...

glipper: /usr/lib/glipper /usr/share/glipper

Then it is not available unless the full path is specified... so, here is the solution. We want to create a soft link to a new /usr/bin/glipper from /usr/lib/glipper/glipper. This will allow glipper to be found in our existing path.

1) First create a soft link to the glipper executable...

sudo ln -s -T /usr/lib/glipper/glipper /usr/bin/glipper

now if you do a 'which glipper' you will see it is found at /usr/bin/glipper

2) Of course we know that glipper is supposed to be a gnome applet, however it will still have the "The panel encountered a problem while loading OAFIID:Glipper...." problem unless we ensure it will start properly from /usr/bin/glipper so... go to System > Preferences > Sessions and on the Startup Programs tab click the +Add button

3) With the Add Startup Program box open

Name: glipper
Command: /usr/bin/glipper
Comment: Glipper Clipboard Manager etc....

...and click OK

4) now, we want the applet to start so...

right click your panel and select Clipboard manager then +Add button

5) ok you are pretty much done. To make sure everything is good to go on startup, restart your computer and
    you will have glipper available on your Gnome panel... the Glipper pop-up shortcut is <ctrl>+<alt>+<c>
    so make sure you did not set those keys for another shortcut combo.

6) Done..!

Hope that helps every one who wants to use Glipper on Ubuntu Hardy Heron... it's a great simple tool..!

Jake

[Simone Tolotti (simontol)]

@chappejw:
I think you're wrong. If it is supposed to be a panel applet we don't need it to be in /usr/bin/. Besides, the fact it crashes on startup is not related to its path. Please read comments above.

[Jacob Chappelle (circuitdesoleil)]

Simone: You are right, if it is supposed to be a panel applet we don't need it to be in /usr/bin/. Actually that soft link I sugguested is irrelavent. However, I was not presenting that fix as a path only issue. From reading all the posts here it appears that glipper starts before some arbitrary resource is available. So, by adding the glipper executable /usr/lib/glipper/glipper to startup programs in System > Preferences > Sessions we can ensure that it will start in a reliable order once it's required resource is available. There are other applets which startup in Session Startup Programs as well. Of course as others have done we could just hard code a sleep time of 8 to 30 seconds into glipper to rig it to work, however this is not a reliable solution since your system may change the amount of time required to startup occasionally and cause something else to out synch glippers startup once again. Perhaps this would be the simplest solution to fixing this applet without having to dive into code.

...If your lazy and you know it click your mouse.... hehe...

[Luca Carrogu (motoplux)]

I solved with this workaround
sudo ln -s /usr/lib/libffi.so.5 /usr/lib/libffi.so.4
maybe glipper should be compiled against that library version

[Simone Tolotti (simontol)]

@motoplux: are you on Intrepid?
Yes it needs to be rebuilt against libffi5.
You can find a working package for intrepid in my ppa archive.
https://launchpad.net/~simontol/+archive

[Vinicius Massuchetto (viniciusandre)]

Solved this problem installing parcellite...
http://www.gnomefiles.org/app.php/Parcellite

[sibidiba (sibidiba)]

Bug still present in current Hardy. Annoying.

[David Rahrer (david-rahrer)]

Can the rebuild against libffi.so.5 solution be backported to Hardy?

[James Westby (james-w)]

Hi,

Could someone who can trigger this problem please attach
your ~/.glipper/history file to the bug report please?

Thanks,

James

[marco.pallotta (marco-pallotta)]

@chappejw, I tried your workaround but it doesn't run for me.

- I made the soft link
- I added glipper to System > Preferences > Sessions
- I added the applet to my panel
- I restarted my PC

At the end I have the same issue.
What mistakes may I have done?

Moreover I have a doubt about you solution: why have I to make soft link if then, in system > Preferences > Sessions, in the command field, I can input the absolute path of glipper (/usr/lib/glipper/glipper instead of /usr/bin/glipper)?

[James Westby (james-w)]

On Sun, 2008-10-05 at 10:55 +0000, marco.pallotta wrote:
> @chappejw, I tried your workaround but it doesn't run for me.
>
> - I made the soft link
> - I added glipper to System > Preferences > Sessions
> - I added the applet to my panel
> - I restarted my PC
>
> At the end I have the same issue.
> What mistakes may I have done?
>
> Moreover I have a doubt about you solution: why have I to make soft link
> if then, in system > Preferences > Sessions, in the command field, I
> can input the absolute path of glipper (/usr/lib/glipper/glipper instead
> of /usr/bin/glipper)?

Hi Marco,

If you are seeing this issue could you please provide your
~/.glipper/history file, this will allow us to try and fix
it for everybody, rather than trying to find a workaround.

Once I understand the problem, which will hopefully be easy
once I can see that file, I will post detailed instructions
for a workaround.

Thanks,

James

[Robin Sheat (eythian)]

I'm running Intrepid, and glipper still crashes on login.

My history file is attached (there's nothing sensitive in there, so it's unmodified).

[marco.pallotta (marco-pallotta)]

Ok James. This is my glipper history file. I'm working on Hardy x86_64.

[James Westby (james-w)]

Thanks,

It appears to be a problem when you copy something with a newline.

I should be able to come up with a patch for this in the next couple of
days.

Thanks,

James

[Jacob Chappelle (circuitdesoleil)]

Hi Marco,

Yes, you're right about the softlink. It was not necessary as Simone also
mentioned earlier in this mailing list. Glipper used to be an application
instead of an applet, that's why I thought I thought the glipper executable
should be found in the PATH initially. However, yes you can just use the
path to the executable for this workaround it should be fine. Note that if
this doesn't work and you still would like to use Glipper, you may also try
the sleep time fix that is also mentioned on this mailing list. Again these
are workarounds and some do not work for others. I have since stopped using
Glipper because whenever I have used it lately it has been eating up my CPU
to about 85% as soon as I copy anything into my clipboard. I am now trying
Klipper which is the KDE equivalent. Others have noted that Parcelite is
another similar tool which can manage your clipboard. Please let us know if
you find any other solution to this as it is an indespensable tool.

Jake

On Sun, Oct 5, 2008 at 3:55 AM, marco.pallotta <email address hidden>wrote:

> @chappejw, I tried your workaround but it doesn't run for me.
>
> - I made the soft link
> - I added glipper to System > Preferences > Sessions
> - I added the applet to my panel
> - I restarted my PC
>
> At the end I have the same issue.
> What mistakes may I have done?
>
> Moreover I have a doubt about you solution: why have I to make soft link
> if then, in system > Preferences > Sessions, in the command field, I
> can input the absolute path of glipper (/usr/lib/glipper/glipper instead
> of /usr/bin/glipper)?
>
> --
> [Hardy] Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Glipper: Unknown
> Status in "glipper" source package in Ubuntu: Triaged
> Status in glipper in Ubuntu Hardy: New
>
> Bug description:
> I use glipper all the time and I find it to be the clipboard application
> that has been missing from Linux desktops for the longest time. In the
> recent Hardy development I find that glipper dies when the desktop starts. I
> receive the following message in an error dialog window:
>
> The panel encountered a problem while loading OAFIID:Glipper....
>
> The is asks if I want to remove glipper from the panel. I find this very
> frustrating. What is more frustrating is that once the desktop is up and
> running I can then install the glipper applet back on the panel and it works
> properly. I have only installed this as an applet and I have never tried
> setting up a custom launcher.
>
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
>
> glipper:
> Installed: 1.0-1
> Candidate: 1.0-1
> Version table:
> *** 1.0-1 0
> 500 http://us.archive.ubuntu.com hardy/universe Packages
> 100 /var/lib/dpkg/status
>
>
>
> Traceback originally from Bug #222846:
>
> ProblemType: Crash
> Architecture: i386
> Date: Sun Apr 27 03:59:12 2008
> DistroRelease: Ubuntu 8.04
> ExecutablePath: /usr/lib/glipper/glipper
> InterpreterPath: /usr/bin/python2.5
> Package: glipper 1.0-1ubuntu1
> Pack...

[Valent (valent-redhat-bugs)]

I'm seeing this still in F9 but also in Fedora 10 beta. Please look at this.

Cheers.

[Pierre-Alexis (pierre-alexis)]

Hi,

I'm afraid the .glipper/history file has nothing to do with this bug : mine is empty, 0 bytes size, and I have this bug. I hope it helps...

PA.

[sibidiba (sibidiba)]

Can someone confirm the suggested workaround in the upstream bugreport (http://sourceforge.net/support/tracker.php?aid=1940578)?

/usr/share/python-support/glipper/glipper/History.py

--- History.py.orig 2008-07-29 00:16:26.000000000 +0200
+++ History.py 2008-07-29 00:15:55.000000000 +0200
@@ -86,7 +86,10 @@

       length = file.readline()
       while length:
- self.history.append(file.read(int(length)))
+ try:
+ self.history.append(file.read(int(length)))
+ except ValueError:
+ print "readline() gaves none int back " + str(length)
          file.read(1) # This is for \n
          length = file.readline()

Can this be a real fix for this problem? I am not a Python expert, but it seems there is common confusion about how readline works:
http://www.tablix.org/~avian/blog/archives/2008/08/05/T21_01_42/
even related to handling Unicode characters:
http://www.tablix.org/~avian/blog/archives/2008/08/05/T21_01_42/

All the tracebacks in the duplicates of this bugs show an exception in the file /var/lib/python-support/python2.5/glipper/History.py line number 89, which is a symlink to the latter.

 80 def load(self):
 81 try:
 82 file = open(glipper.HISTORY_FILE, "r")
 83 except IOError:
 84 self.emit('changed', self.history)
 85 return # Cannot read history file
 86
 87 length = file.readline()
 88 while length:
 89 self.history.append(file.read(int(length)))
 90 file.read(1) # This is for \n
 91 length = file.readline()
 92
 93 file.close()
 94 self.emit('changed', self.history)

All the trackebacks start this way:

Traceback (most recent call last):
  File "/usr/lib/glipper/glipper", line 53, in applet_factory
    glipper.Applet.Applet(applet)
  File "/var/lib/python-support/python2.5/glipper/Applet.py", line 50, in __init__
    get_glipper_history().load()
  File "/var/lib/python-support/python2.5/glipper/History.py", line 89, in load
    self.history.append(file.read(int(length)))

and differ only in the single last line, for example on of these:

ValueError: invalid literal for int() with base 10: '\x14\x1b'

ValueError: invalid literal for int() with base 10: '\x14\x0c'

ValueError: invalid literal for int() with base 10: '\x14('

ValueError: invalid literal for int() with base 10: '\x14W'

ValueError: invalid literal for int() with base 10: '\x14\x0b'

ValueError: invalid literal for int() with base 10: '\x14\x07'

ValueError: invalid literal for int() with base 10: '\x14\x0f'

[Jacob Chappelle (circuitdesoleil)]

I tried the sugguested workaround and it did not work. As soon as I copy
something to the clipboard Glipper begins Glipping out and eating about 85%
of my CPU bogging down everything else on the system. I also start Glipper
from the command line to see any output that can help trace down the issue,
but the line "*print "readline() gaves none int back " + str(length)*" in
the following change never prints which indicates an exception is not raised
here. I have started using Klipper for now, but I will check back on Glipper
to help debug this annoying problem. Glipper's popup is more appealing than
Klipper's since it does not also contain several options which get in the
way of selecting your current history item. If anyone knows of a clipboard
manager that also has hot keys to move forward and back through history
please let us know.

* /usr/share/python-support/**glipper/glipper/History.py

--- History.py.orig 2008-07-29 00:16:26.000000000 +0200
+++ History.py 2008-07-29 00:15:55.000000000 +0200
@@ -86,7 +86,10 @@

      length = file.readline()
      while length:
- self.history.append(file.read(* *int(length)))
+ try:
+ self.history.append(file.read(**int(length)))
+ except ValueError:
+ print "readline() gaves none int back " + str(length)
         file.read(1) # This is for \n
         length = file.readline()
*

Jacob Chappelle
><((((º<`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º<¸.
`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º<`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º<

On Sun, Oct 5, 2008 at 6:59 PM, sibidiba <email address hidden> wrote:

> Can someone confirm the suggested workaround in the upstream bugreport
> (http://sourceforge.net/support/tracker.php?aid=1940578)?
>
> /usr/share/python-support/glipper/glipper/History.py
>
> --- History.py.orig 2008-07-29 00:16:26.000000000 +0200
> +++ History.py 2008-07-29 00:15:55.000000000 +0200
> @@ -86,7 +86,10 @@
>
> length = file.readline()
> while length:
> - self.history.append(file.read(int(length)))
> + try:
> + self.history.append(file.read(int(length)))
> + except ValueError:
> + print "readline() gaves none int back " + str(length)
> file.read(1) # This is for \n
> length = file.readline()
>
> Can this be a real fix for this problem? I am not a Python expert, but it
> seems there is common confusion about how readline works:
> http://www.tablix.org/~avian/blog/archives/2008/08/05/T21_01_42/<http://www.tablix.org/%7Eavian/blog/archives/2008/08/05/T21_01_42/>
> even related to handling Unicode characters:
> http://www.tablix.org/~avian/blog/archives/2008/08/05/T21_01_42/<http://www.tablix.org/%7Eavian/blog/archives/2008/08/05/T21_01_42/>
>
> All the tracebacks in the duplicates of this bugs show an exception in
> the file /var/lib/python-support/python2.5/glipper/History.py line
> number 89, which is a symlink to the latter.
>
> 80 def load(self):
> 81 try:
> 82 file = open(glipper.HISTORY_FILE, "r")
> 83 except IOError:
> 84 self.emit('changed', self.history)
> 85 return # Cannot read history file
> 86
> 87 length = file.readline()
> 8...

[Troels Knak-Nielsen (troelskn)]

Yeah, when I get the error, it can be resolved by simply restarting X.
I tried saving the history file and compare them, and restarting
doesn't affect the history file, so that can't be it.

--
troels

On Sun, Oct 5, 2008 at 11:55 PM, Pulp
<email address hidden> wrote:
> Hi,
>
> I'm afraid the .glipper/history file has nothing to do with this bug :
> mine is empty, 0 bytes size, and I have this bug. I hope it helps...
>
> PA.
>
> --
> [Hardy] Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[James Westby (james-w)]

Hi,

Thanks for the help everybody, I see now what a strange bug
this is.

I spent some time this morning reproducing this error, and though
I could trigger it I couldn't find problems in the reading of the history
file. I'll try again, but I don't know whether that will reveal anything.

I don't want to upload the sleep() patch, as that won't fix it for everyone,
and will just tend to slow things down.

The try: patch would be more acceptable, but as the applet can be
added once the session is up and running it seems that it would
only lose things from the history when it doesn't need to.

Writing this made me realise that this could well be caused by reading
from the file from two different threads, and I have just checked and
the applet does indeed use threads, so that would be an avenue worthy
of investigation.

Thanks,

James

[eugrus (eugrus)]

This bug is extremely easy to reproduce!!!

You should just open OpenOffice.org and use "Select all" option - Glipper dies even before I copy the text!

[unf (unfito)]

I tried this and Glipper didn't crash.

On Tue, Oct 7, 2008 at 9:06 PM, eugrus <email address hidden> wrote:

> This bug is extremely easy to reproduce!!!
>
> You should just open OpenOffice.org and use "Select all" option -
> Glipper dies even before I copy the text!
>
> ** Attachment added: "I attach the history file, but looks like nothing is
> added there when Glipper dies."
> http://launchpadlibrarian.net/18299381/history
>
> --
> [Hardy] Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Omk (ossi-viljakainen)]

Sama here. Select all in OO, No crash.

On Tue, Oct 7, 2008 at 11:37 PM, unf <email address hidden> wrote:

> I tried this and Glipper didn't crash.
>
> On Tue, Oct 7, 2008 at 9:06 PM, eugrus <email address hidden> wrote:
>
> > This bug is extremely easy to reproduce!!!
> >
> > You should just open OpenOffice.org and use "Select all" option -
> > Glipper dies even before I copy the text!
> >
> > ** Attachment added: "I attach the history file, but looks like nothing
> is
> > added there when Glipper dies."
> > http://launchpadlibrarian.net/18299381/history
> >
> > --
> > [Hardy] Glipper dies when desktop starting
> > https://bugs.launchpad.net/bugs/213494
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>
> --
> [Hardy] Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
-Ossi Viljakainen
[phone] (mobile) - <email address hidden> -
http://www.ayur-jooga.fi/

[Valent (valent-redhat-bugs)]

is there a way I can capture this crash and provide more feedback for you?

[Valent (valent-redhat-bugs)]

I read on the glipper mailing list glipper is not maintained anymore :(

Is it possible to revert to older version of glipper? Older versions worked better and are written in C, new one is written in Python.

[Valent (valent-redhat-bugs)]

message about glipper not being maintained anymore:
http://snipurl.com/glipper [sourceforge_net]

[James (james-redhat-bugs)]

Hi,

This bug has been reported in Ubuntu too, you can read it at

  https://bugs.launchpad.net/bugs/213494

we've got some way to debugging it, but no real fix yet.

Apparently inserting a delay in to the applet makes it work. My
current guess is a race condition between threads reading from
the history file.

Thanks,

James

[Valent (valent-redhat-bugs)]

http://kernelreloaded.blog385.com/index.php/archives/glipper-is-dead-long-live-glipper/

on my blog Jean-François Martin suggested using Parcellite (http://parcellite.sourceforge.net)

[Christoph (christoph-redhat-bugs)]

(In reply to comment #13)
> on my blog Jean-François Martin suggested using Parcellite

Although I agree with Jean-François this is no fix for this big, so no need eo mention it here.

Could somebody please test, if the packages from
http://koji.fedoraproject.org/koji/taskinfo?taskID=873927
fix the problem? TIA!

[Valent (valent-redhat-bugs)]

It looks like it is fixed, thanks Christoph!

[Valent (valent-redhat-bugs)]

Hold the presses, it seams that it still doesn't work :(

I tried logging off and logging on, that worked ok, but now that I have rebooted the laptop I still get the error :(

Look at the screenshot.

[Valent (valent-redhat-bugs)]

Created attachment 320142
error message

error message after rebooting and logging in...

[Benedikt Wegmann (benny-wegmann)]

Affects me, too, with Intrepid (upgrade from Hardy).

[Jacob Chappelle (circuitdesoleil)]

Ok Glipper fans.... one thing I have seen discussed here as a means of
finding out what is wrong with Glipper is the posting of the history file
and looking at the history file...... So, why would the history file have
anything to do with Glipper crashing on boot to desktop? The history file is
readable writeable by the glipper applet/application, but Glipper dies when
the gnome panel is starting. Another person here thought that when glipper
copies anything that has a newline it causes Glipper to crash.... ....o...
kaayy... I have not observed this.... I used Glipper at work for weeks
without a crash using my original solution of starting glipper via startup
on session load and this worked flawlessly for over a month of serious
usage. I'm sure I had copied many new lines by that time. Then for whatever
reason glipper died again on startup, I believe once I started using another
package such as apache2 or vmware which was set to start on boot up. So
again, no solution. Another thing someone mentioned was that selecting all
in OO causes glipper to crash... but did not specify if the crash occurred
when trying to copy the selected data or the crash occured just from doing a
select all. The fact that Glipper uses threads could be an area to
investigate if there is some kind of race condition or dead lock causing the
crash on boot.

Has anyone done any more testing on this bug?

Jake

On Sun, Nov 9, 2008 at 6:43 AM, Benedikt Wegmann <email address hidden>wrote:

> Affects me, too, with Intrepid (upgrade from Hardy).
>
> --
> [Hardy] Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Glipper: Unknown
> Status in "glipper" source package in Ubuntu: Triaged
> Status in glipper in Ubuntu Hardy: New
> Status in "glipper" source package in Debian: New
> Status in Fedora: Confirmed
>
> Bug description:
> I use glipper all the time and I find it to be the clipboard application
> that has been missing from Linux desktops for the longest time. In the
> recent Hardy development I find that glipper dies when the desktop starts. I
> receive the following message in an error dialog window:
>
> The panel encountered a problem while loading OAFIID:Glipper....
>
> The is asks if I want to remove glipper from the panel. I find this very
> frustrating. What is more frustrating is that once the desktop is up and
> running I can then install the glipper applet back on the panel and it works
> properly. I have only installed this as an applet and I have never tried
> setting up a custom launcher.
>
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
>
> glipper:
> Installed: 1.0-1
> Candidate: 1.0-1
> Version table:
> *** 1.0-1 0
> 500 http://us.archive.ubuntu.com hardy/universe Packages
> 100 /var/lib/dpkg/status
>
>
>
> Traceback originally from Bug #222846:
>
> ProblemType: Crash
> Architecture: i386
> Date: Sun Apr 27 03:59:12 2008
> DistroRelease: Ubuntu 8.04
> ExecutablePath: /usr/lib/glipper/glipper
> InterpreterPath: /usr/bin/python2.5
> Pac...

[Scott Lewin (sclewin)]

+1 here on intrepid. If Glipper is dead and not working, what are we suppose to use then?

[Benedikt Wegmann (benny-wegmann)]

"parcellite" does the job just as well for me:
http://packages.ubuntu.com/intrepid/parcellite

[Scott Lewin (sclewin)]

Benedikt Wegmann wrote:
> "parcellite" does the job just as well for me:
> http://packages.ubuntu.com/intrepid/parcellite

I will check it out, but I prefer a clipboard manager with extra features.

[Richard (richard-redhat-bugs)]

Just out of curiosity, any chance you guys are using synergy as well?

I've noticed some strangeness with synergy and clipboard guff recently and was thinking it might be causing glipper to crash somehow...

[Valent (valent-redhat-bugs)]

I'm not using synergy.

[Richard (richard-redhat-bugs)]

K. Never mind :-)

[Jem (jemwallis-deactivatedaccount)]

I would recommend that people here use the recompiled version for Intrepid, courtesy Simone, @ https://launchpad.net/~simontol/+archive

Simone's post above seems to have been largely ignored which is a shame as it seems to fix the problem currently. Don't forget to lock the Glipper version in Synaptic when installed to stop it nagging you constantly to upgrade.

Glipper offers more functionality than Parcellite currently so it's my choice. I'd like to see Glipper properly maintained - Simone...? :) with bitmap captures added at some point.

[Troels Knak-Nielsen (troelskn)]

On Sun, Nov 9, 2008 at 7:37 PM, chappejw <email address hidden> wrote:
> reason glipper died again on startup, I believe once I started using another
> package such as apache2 or vmware which was set to start on boot up. So

That makes sense. I've recently switched my machine and installed it
with Intrepid, and I have no problems with Glipper. I have however not
yet installed any of apache2, vmware or sendmail - all of which were
installed on my previous machine (Which had the problem with Glipper)

--
troels

[Sympy (sympathy4no1)]

I can also confirm that Simone's package fixed the problem of glipper crashing on first login for me.

[Kevin (kevin-redhat-bugs)]

This bug reproduces in F10 still, is there a build of glipper-1.0-5 for fc10 ?

[Christoph (christoph-redhat-bugs)]

No, because the patch I applied in 1.0-5 definitely does not fix the problem. I have to admit that I'm a clueless here, but someone else on #fedora-devel said he wanted to look at it. Sorry I forgot who it was. :(

BTW: What is with the owner of this package? Damien, are you still around?

[Kevin (kevin-redhat-bugs)]

Not sure if anyone has comeup with a workaround to at-least make this applet reload when it fails completely on startup of gnome-session.

I think it will be a good to explore workaround if a fix can't be developed, however even I failed to work a workaround.

But for now I found an alternative app which looks to be working fine with Gnome so far, thought I'll let others know as well.

# yum install parcellite

Cheers !

[Uqbar (uqbar)]

At the desktop boot in Intrepid the CPU show a 100% load with the notorious error message.
https://bugs.launchpad.net/ubuntu/+source/glipper/+bug/213494/comments/15 solved this problem to me.
And Parcellite implements what I'd expect from a clipboard manager.
The bug, however, is still here.

[Iain Lane (laney)]

Hi,

I am unsubscribing the sponsors from this bug, as it appears there is not a definitive solution (with patch) available per James's comments. Please resubscribe when one is ready.

Thanks.

[Chuck Hamilton (chuck-hamilton)]

I've noticed this too in Ubuntu 8.10 Intrepid, but only when visual effects (compiz-fusion) are enabled. With visual effects disabled it starts up correctly every time.

[Arthur (moz-liebesgedichte)]

Non of my machines have compiz-fusion or any other visual effects enabled and I see random Glipper startup crashes. It feels less often than some months ago but still from time to time.

[Jacob Chappelle (circuitdesoleil)]

I believe this is some sort of a race condition. Originally I thought... oh,
this looks like a simple bug to find, it's written in Python, how hard can
it be?..... well.... Nearly everyone watching this bug has tried one thing
or another and the bug persists... For all we know the bug is caused by
something in the way Gnome Desktop loads panel applets. I have since moved
on to Klipper, although it's not as usuable as Glipper (when it works)...
Jacob

On Thu, Apr 2, 2009 at 12:18 PM, Arthur <email address hidden>wrote:

> Non of my machines have compiz-fusion or any other visual effects
> enabled and I see random Glipper startup crashes. It feels less often
> than some months ago but still from time to time.
>
> --
> Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Glipper: Unknown
> Status in “glipper” source package in Ubuntu: Triaged
> Status in glipper in Ubuntu Hardy: Confirmed
> Status in “glipper” source package in Debian: New
> Status in Fedora: Confirmed
>
> Bug description:
> I use glipper all the time and I find it to be the clipboard application
> that has been missing from Linux desktops for the longest time. In the
> recent Hardy development I find that glipper dies when the desktop starts. I
> receive the following message in an error dialog window:
>
> The panel encountered a problem while loading OAFIID:Glipper....
>
> The is asks if I want to remove glipper from the panel. I find this very
> frustrating. What is more frustrating is that once the desktop is up and
> running I can then install the glipper applet back on the panel and it works
> properly. I have only installed this as an applet and I have never tried
> setting up a custom launcher.
>
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
>
> glipper:
> Installed: 1.0-1
> Candidate: 1.0-1
> Version table:
> *** 1.0-1 0
> 500 http://us.archive.ubuntu.com hardy/universe Packages
> 100 /var/lib/dpkg/status
>
>
>
> Traceback originally from Bug #222846:
>
> ProblemType: Crash
> Architecture: i386
> Date: Sun Apr 27 03:59:12 2008
> DistroRelease: Ubuntu 8.04
> ExecutablePath: /usr/lib/glipper/glipper
> InterpreterPath: /usr/bin/python2.5
> Package: glipper 1.0-1ubuntu1
> PackageArchitecture: i386
> ProcCmdline: python /usr/lib/glipper/glipper
> --oaf-activate-iid=OAFIID:Glipper_Factory --oaf-ior-fd=33
> ProcEnviron:
> LANG=en_US.UTF-8
>
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
> SHELL=/bin/bash
> PythonArgs: ['/usr/lib/glipper/glipper',
> '--oaf-activate-iid=OAFIID:Glipper_Factory', '--oaf-ior-fd=33']
> SourcePackage: glipper
> Title: glipper crashed with ValueError in load()
> Uname: Linux 2.6.24-16-386 i686
> UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev
> sambashare scanner video
>
>
> Traceback (most recent call last):
> File "/usr/lib/glipper/glipper", line 53, in applet_factory
> glipper.Applet.Applet(applet)
> File "/var/lib/python-support/python2.5...

[Shane Rice (shane2peru)]

This is pretty crazy that this is a problem for so long. Doesn't the sleep method work for everyone? I just have to edit it every time and set the sleep time to 30 seconds and that fixes it for me. Of course I always have to look up this bug or on the forums to find the answer. I would suggest putting the sleep time in the distributed package and see if the bug goes away, it is a pretty harmless solution or at least a workaround.

Shane

[Andrew Conkling (andrewski)]

It's not a solution, it's a (good, usually sufficient) workaround. This is
why it hasn't been placed in the actual package. I believe previous comments
have addressed the specific reasons.

[Shane Rice (shane2peru)]

This bug is not a new one, and seems to be stalled as far as a fix, if it is a sufficient workaround (are there any cases where this doesn't workaround the problem?) It seems that usability would be key, and that workaround fixes it on several of my machines, I know that is slightly limited, but seems like a very viable workaround. It doesn't seem that collecting any further data is going to result in a solution that will come around any time soon, because as stated, this isn't new. Perhaps I missed the previous reasons, I did breeze through them, and mostly it is talk of using something different (parcelite klipper, etc.) those aren't even workarounds, they are abandonment. I believe that actually the times it didn't work are not related to the glipper startup crashing bug, but rather a memory limitation type bug. I too have crashed glipper in this way, however playing around with the settings has stopped that problem. I'm not a programmer, so it is only my observations and opinions take it for what it is worth. I think end userability ranks higher than attempting to milk a dry cow for more information. The majority of users (of which I venture to guess don't even visit this page) just delete it and install parcelite or klipper without a second thought. Don't take this as a reproach, it is just my opinion from one of the end users.

Shane

[Spang (hetkot)]

Jaunty AMD64
For me the sleep thing doesn't seem to fix it.
On the contrary, it stalls the rest of my gnome from loading.

[Spang (hetkot)]

I Give up for now.
Switched to parcelite.

[Shane Rice (shane2peru)]

Spang, Does glipper keep gnome from loading, or just slow it down? I too have Jaunty AMD64 and mine seems to work, perhaps it delays gnome startup a little bit, not sure, but it does seem to work at least here.

Shane

[®om (rom1v)]

I have Jaunty 32 bits and glipper crashes on boot… but not always, I would say 1/3.

[Udo Güngerich (ug78)]

Hi there,

I'm running Jaunty and are (since Hardy) experiencing the same problems.

I followed this thread which I only found today (luckily).

I spent some two hours to dig a little into the problem and found that its got to do (as others above pointed out already) with some little gnome inside the code ;)

I first suspected gobject.threads_init() as other resources pointed out, that time and order of calls matter in PyGTK.

Then, as a first step, I added logging to see how far Glipper would fare:

It is merely starting up before it crashes.

Being intrigued by this and by the fact that it really only happens at boot time, I started to write this patch (see attachment).

For now after the first successful (re-)boot (done a far few by now) test, Glipper *did not* crash with this code in place!

I'd be really curious whether it'll help others, so please give it a try!

Best regards,

Udo

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Udo Güngerich (ug78)]

btw: did a couple of restarts since and no crash happened anymore :)

Happy glipping!

[Andii (andiibowsher)]

It's become much more intermittent since upgrade, say one in five start ups. If I press 'don't delete' it seems to run fine anyway: almost as if it's a phantom message.

[mwaechter (matthias-waechter)]

I experienced this bug since I switched to gnome with intrepid. Tried Udo Güngerichs patch today and no more crashes since then. Congratulations to Udo so far, and I will keep watching it.

Greetings, Matthias

[James Westby (james-w)]

On Tue, 2009-06-09 at 11:44 +0000, Udo Güngerich wrote:
> For now after the first successful (re-)boot (done a far few by now)
> test, Glipper *did not* crash with this code in place!

Could you provide the log output that you get with your patch
applied please?

Thanks,

James

[eugrus (eugrus)]

For me it crashes as I try to copy some pages in OpenOffice.org.

So, looks like BIG text is a reason.

[Shane Rice (shane2peru)]

If you right click on the glipper icon and select preference, you can change the size of the clipboard manager. This will help with BIG text issues. I also have crashed glipper that way in the past. Mine is set to Lenght of one history entry 35 . You can up that or make it less, I can't remember which way to fix that.

Shane

[mwaechter (matthias-waechter)]

Since yesterday I had some more crashes at startup. Thus the problem still remains. The logfile created by Udo's patch is attached, but it doesn't tell me anything. I will probably switch to parcellite soon, which seems to work perfectly.
Greetings, Matthias

[Udo Güngerich (ug78)]

Right. So now I had another crash :(

Happened after my notebook did not properly wake up after suspend because of lack of power.

I then had to do a normal boot and glipper crashed after log in to GNOME.

So it's about one crash for maybe 4 times booting.

My log file says the crash happened right after the first message.

So the error must happen between "Trying to start glipper..." and

 while not ready:
     try:
         import gobject
         gobject.threads_init()
         import gtk, gnomeapplet, gnome
         ready = True

Logical next step is to make one debug line per code. We'll then be able to tell where it crashes if there is only one place in the code or at least know that there are many lines that make it crash or different situations.

My log is attached. Crash happened at 2009-06-12T15:23:11.300143

I will provide a more verbose version in a while. Maybe we can track it down...

[Udo Güngerich (ug78)]

I added another couple of loggings :)

I attach my log (the relevant bit).

It seems that - contrary to what I wrote above - Glipper crashes after importing glipper, glipper.Applet and glipper.defs:

DEBUG:root:Importing glipper, glipper.Applet, glipper.defs... 2009-06-17T23:00:50.232058

I'll provide the (non-incremental) current patch in the next post :)

[Udo Güngerich (ug78)]

This is the current patch to glipper.

At the moment it does not yet write one line of log per line of code, but I'll get to that somewhen, I reckon :(

Maybe someone else will provide his log after applying the patch and we'll eventually get to the core of the problem?!

Oh, and beware - the patch seems to be big. This is because the authors of glipper used tabs for indentation *brrrr* and I cleaned it ;)

[Bug (bug-redhat-bugs)]

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Shane Rice (shane2peru)]

This fix:

sudo gedit /usr/lib/glipper/glipper

Make sure the code in the beginning looks like this:

#!/usr/bin/env python

# Glipper - Clipboardmanager for GNOME
# Copyright (C) 2007 Glipper Team
# bla bla bla
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
#

import time # <-- This line is new
time.sleep(8) # <-- This line is new. Change the 8 to for instance 30 if it did not help

import gobject
gobject.threads_init()

import gtk, gnomeapplet, gnome
import getopt, sys
from os.path import *

Worked for me, I had it set to 30, and then started crashing it regularly at startup. I upped it to 90 seconds, and that is working now. I also went through a bunch of stuff in my startup and eliminated bunch of things that shouldn't have been starting anyway.

Shane

[Jacob Chappelle (circuitdesoleil)]

But why does that work? If it sleeps for 8, 30, 90 seconds and then starts
reliably? what was it that caused it to crash in the first place?

Jacob

On Thu, Jul 30, 2009 at 8:15 AM, Shane Rice <email address hidden> wrote:

> This fix:
>
> sudo gedit /usr/lib/glipper/glipper
>
> Make sure the code in the beginning looks like this:
>
> #!/usr/bin/env python
>
> # Glipper - Clipboardmanager for GNOME
> # Copyright (C) 2007 Glipper Team
> # bla bla bla
> # License along with this library; if not, write to the
> # Free Software Foundation, Inc., 59 Temple Place - Suite 330,
> # Boston, MA 02111-1307, USA.
> #
>
> import time # <-- This line is new
> time.sleep(8) # <-- This line is new. Change the 8 to for instance 30 if it
> did not help
>
> import gobject
> gobject.threads_init()
>
> import gtk, gnomeapplet, gnome
> import getopt, sys
> from os.path import *
>
> Worked for me, I had it set to 30, and then started crashing it
> regularly at startup. I upped it to 90 seconds, and that is working
> now. I also went through a bunch of stuff in my startup and eliminated
> bunch of things that shouldn't have been starting anyway.
>
> Shane
>
> --
> Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Glipper: Unknown
> Status in “glipper” package in Ubuntu: Triaged
> Status in glipper in Ubuntu Hardy: Confirmed
> Status in “glipper” package in Debian: New
> Status in Fedora: Won't Fix
>
> Bug description:
> I use glipper all the time and I find it to be the clipboard application
> that has been missing from Linux desktops for the longest time. In the
> recent Hardy development I find that glipper dies when the desktop starts. I
> receive the following message in an error dialog window:
>
> The panel encountered a problem while loading OAFIID:Glipper....
>
> The is asks if I want to remove glipper from the panel. I find this very
> frustrating. What is more frustrating is that once the desktop is up and
> running I can then install the glipper applet back on the panel and it works
> properly. I have only installed this as an applet and I have never tried
> setting up a custom launcher.
>
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
>
> glipper:
> Installed: 1.0-1
> Candidate: 1.0-1
> Version table:
> *** 1.0-1 0
> 500 http://us.archive.ubuntu.com hardy/universe Packages
> 100 /var/lib/dpkg/status
>
>
>
> Traceback originally from Bug #222846:
>
> ProblemType: Crash
> Architecture: i386
> Date: Sun Apr 27 03:59:12 2008
> DistroRelease: Ubuntu 8.04
> ExecutablePath: /usr/lib/glipper/glipper
> InterpreterPath: /usr/bin/python2.5
> Package: glipper 1.0-1ubuntu1
> PackageArchitecture: i386
> ProcCmdline: python /usr/lib/glipper/glipper
> --oaf-activate-iid=OAFIID:Glipper_Factory --oaf-ior-fd=33
> ProcEnviron:
> LANG=en_US.UTF-8
>
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
> SHELL=/bin/bash
> PythonArgs: ['/usr/lib/glipper/glipper',
> '--oaf-activate-iid=OAFIID:Glipper_Factory', '...

[Shane Rice (shane2peru)]

I really cannot give an answer. It must clash with something, but no
one has been able to figure it out. It is a real pain, because I really
like glipper. This has been a bug for years, and no answer better than
that has been presented.

Shane

On Fri, 2009-07-31 at 00:21 +0000, chappejw wrote:

> But why does that work? If it sleeps for 8, 30, 90 seconds and then starts
> reliably? what was it that caused it to crash in the first place?
>
> Jacob
>

[marco.pallotta (marco-pallotta)]

Txs Shane, your workaround also works for me on Hardy (I set a time of 15).

[Shane Rice (shane2peru)]

On Tue, 2009-08-11 at 21:24 +0000, marco.pallotta wrote:

> Txs Shane, your workaround also works for me on Hardy (I set a time of
> 15).
>

I didn't come up with it, I just echoed what someone else taught me. :)
Glad it worked for you.

Shane

[Helder Fraga (whise)]

hello, im the developer of gnomenu , i also have the error, if there is any debugging help it would be apreciated, my main concern is that some python applets load without the error and others dont... so what is causing this??

[Udo Güngerich (ug78)]

Hi, it is been a long time since I cared about this bug, but the last comment made me investigate again.

For all I can say now: The bug does not occur anymore on my machine with my glipper version.

I think it extremely likely that this is indeed a race condition as many others already pointed out. The lacking of my glipper crashing almost proves it.

I changed the import order of these gnome, gtk and glipper libraries and thus avoided the crash:

gobject
gtk
gnome
gnomeapplet
glipper
glipper.defs
glipper.Applet

I provided a try-except-block for each import with according logging.

As I said, I experience no crashes anymore, so this might be a solution.

I will attach my changed glipper script.

Regards, Udo

[Udo Güngerich (ug78)]

Ok, it crashed again, I removed the import of glipper (it's a directory) and no crash so far, but I have to behold it for a while further...

[Jacob Chappelle (circuitdesoleil)]

I believe this project has pretty much been abandoned. I have been using
Parcellite for a long time now and it is pretty much the same thing, and
doesn't crash.

Jacob

On Fri, Jul 31, 2009 at 5:29 AM, Shane Rice <email address hidden> wrote:

> I really cannot give an answer. It must clash with something, but no
> one has been able to figure it out. It is a real pain, because I really
> like glipper. This has been a bug for years, and no answer better than
> that has been presented.
>
> Shane
>
>
> On Fri, 2009-07-31 at 00:21 +0000, chappejw wrote:
>
> > But why does that work? If it sleeps for 8, 30, 90 seconds and then
> starts
> > reliably? what was it that caused it to crash in the first place?
> >
> > Jacob
> >
>
> --
> Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Glipper: Unknown
> Status in “glipper” package in Ubuntu: Triaged
> Status in glipper in Ubuntu Hardy: Confirmed
> Status in “glipper” package in Debian: New
> Status in Fedora: Won't Fix
>
> Bug description:
> I use glipper all the time and I find it to be the clipboard application
> that has been missing from Linux desktops for the longest time. In the
> recent Hardy development I find that glipper dies when the desktop starts. I
> receive the following message in an error dialog window:
>
> The panel encountered a problem while loading OAFIID:Glipper....
>
> The is asks if I want to remove glipper from the panel. I find this very
> frustrating. What is more frustrating is that once the desktop is up and
> running I can then install the glipper applet back on the panel and it works
> properly. I have only installed this as an applet and I have never tried
> setting up a custom launcher.
>
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
>
> glipper:
> Installed: 1.0-1
> Candidate: 1.0-1
> Version table:
> *** 1.0-1 0
> 500 http://us.archive.ubuntu.com hardy/universe Packages
> 100 /var/lib/dpkg/status
>
>
>
> Traceback originally from Bug #222846:
>
> ProblemType: Crash
> Architecture: i386
> Date: Sun Apr 27 03:59:12 2008
> DistroRelease: Ubuntu 8.04
> ExecutablePath: /usr/lib/glipper/glipper
> InterpreterPath: /usr/bin/python2.5
> Package: glipper 1.0-1ubuntu1
> PackageArchitecture: i386
> ProcCmdline: python /usr/lib/glipper/glipper
> --oaf-activate-iid=OAFIID:Glipper_Factory --oaf-ior-fd=33
> ProcEnviron:
> LANG=en_US.UTF-8
>
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
> SHELL=/bin/bash
> PythonArgs: ['/usr/lib/glipper/glipper',
> '--oaf-activate-iid=OAFIID:Glipper_Factory', '--oaf-ior-fd=33']
> SourcePackage: glipper
> Title: glipper crashed with ValueError in load()
> Uname: Linux 2.6.24-16-386 i686
> UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev
> sambashare scanner video
>
>
> Traceback (most recent call last):
> File "/usr/lib/glipper/glipper", line 53, in applet_factory
> glipper.Applet.Applet(applet)
> File "/var/lib/python-support/python2.5/glipper/A...

[Andii (andiibowsher)]

I've also given up on glipper. Been using Parcellite for a year or so and it's not let me down. I'd suggest that glipper should be dropped and migration to parcellite encouraged.

[Eric (weisscoder)]

Parcellite uses the notification area, rather than being a panel applet or sitting in the indicator applet in Ubuntu. With Ubuntu's plan to remove the notification area, this still leaves a use for Glipper. Further, Parcellite actually has been abandoned: http://parcellite.sourceforge.net/?p=89 .

[Shane Rice (shane2peru)]

Yes, last news on glipper was back in 07! Seems as though the parcellite has just announced that it will no longer be maintained either as of (April 2010). I too have abandonded the glipper route and settled with parcellite. Sure hope either someone picks up parcellite, or something else comes a long. You would have to think that if glipper has not been touched since 2007, it probably would have a security hole or something. Perhaps not, but I would think it would.

Shane

[marco.pallotta (marco-pallotta)]

I installed glipper on 10.04 x86 and it didn't crash yet.
Can someone else confirm this?

[Omk (ossi-viljakainen)]

Yes it crashes, sometimes. I have removed it from my panel and I am using
Parcellite instead.

On Mon, Jun 21, 2010 at 12:26 AM, marco.pallotta
<email address hidden>wrote:

> I installed glipper on 10.04 x86 and it didn't crash yet.
> Can someone else confirm this?
>
> --
> Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
-Ossi Viljakainen
Jooga-opettaja, Ayurveda-konsultti
[phone] (Finland mobile)skype: ossiviljakainen
<email address hidden> - http://www.ayur-jooga.fi/

[John Cottier (j-cottier)]

This is still a problem in 10.04, I get "The panel encountered a problem...." error message for Glipper at every bootup. I tried using klipper instead, but then when shutting down Ubuntu Klipper "fails to respond". The after system startup, its gone from the panel (and takes kmail tray icon with it). So we have the two major clip board apps, one fails at boot, the other fails at shutdown. Since I use clipboards all the time at work this is a problem for me as a business user. How many years do we have to wait for a bugfix?

[Jacob Chappelle (circuitdesoleil)]

parcelite

http://parcellite.sourceforge.net/

Jacob

On Tue, Jun 29, 2010 at 4:45 AM, John Cottier <email address hidden>wrote:

> This is still a problem in 10.04, I get "The panel encountered a
> problem...." error message for Glipper at every bootup. I tried using
> klipper instead, but then when shutting down Ubuntu Klipper "fails to
> respond". The after system startup, its gone from the panel (and takes
> kmail tray icon with it). So we have the two major clip board apps, one
> fails at boot, the other fails at shutdown. Since I use clipboards all
> the time at work this is a problem for me as a business user. How many
> years do we have to wait for a bugfix?
>
> --
> Glipper dies when desktop starting
> https://bugs.launchpad.net/bugs/213494
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Glipper: Unknown
> Status in “glipper” package in Ubuntu: Triaged
> Status in “glipper” source package in Hardy: Confirmed
> Status in “glipper” package in Debian: New
> Status in Fedora: Won't Fix
>
> Bug description:
> I use glipper all the time and I find it to be the clipboard application
> that has been missing from Linux desktops for the longest time. In the
> recent Hardy development I find that glipper dies when the desktop starts. I
> receive the following message in an error dialog window:
>
> The panel encountered a problem while loading OAFIID:Glipper....
>
> The is asks if I want to remove glipper from the panel. I find this very
> frustrating. What is more frustrating is that once the desktop is up and
> running I can then install the glipper applet back on the panel and it works
> properly. I have only installed this as an applet and I have never tried
> setting up a custom launcher.
>
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=8.04
> DISTRIB_CODENAME=hardy
> DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
>
> glipper:
> Installed: 1.0-1
> Candidate: 1.0-1
> Version table:
> *** 1.0-1 0
> 500 http://us.archive.ubuntu.com hardy/universe Packages
> 100 /var/lib/dpkg/status
>
>
>
> Traceback originally from Bug #222846:
>
> ProblemType: Crash
> Architecture: i386
> Date: Sun Apr 27 03:59:12 2008
> DistroRelease: Ubuntu 8.04
> ExecutablePath: /usr/lib/glipper/glipper
> InterpreterPath: /usr/bin/python2.5
> Package: glipper 1.0-1ubuntu1
> PackageArchitecture: i386
> ProcCmdline: python /usr/lib/glipper/glipper
> --oaf-activate-iid=OAFIID:Glipper_Factory --oaf-ior-fd=33
> ProcEnviron:
> LANG=en_US.UTF-8
>
>
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
> SHELL=/bin/bash
> PythonArgs: ['/usr/lib/glipper/glipper',
> '--oaf-activate-iid=OAFIID:Glipper_Factory', '--oaf-ior-fd=33']
> SourcePackage: glipper
> Title: glipper crashed with ValueError in load()
> Uname: Linux 2.6.24-16-386 i686
> UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev
> sambashare scanner video
>
>
> Traceback (most recent call last):
> File "/usr/lib/glipper/glipper", line 53, in applet_factory
> glipper.Applet.Applet(applet)
> File "/var/lib/python-support/python2.5/glipper/Applet.py", line 50, in
> __init__
> get_...

[Marc MAURICE (dooblem)]

Parcellite doesn't seem to support copy on selection. It only supports "ctrl+c copy".

Maybe this is related ? :
https://bugs.launchpad.net/gnomenu/+bug/347777

[Fredrik Normann (smartypants)]

TTT wow

On Thu, Apr 21, 2011 at 2:38 PM, Laszlo Pandy <email address hidden> wrote:
> ** Changed in: glipper (Ubuntu)
>       Status: Triaged => Fix Released
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (175490).
> https://bugs.launchpad.net/bugs/213494
>
> Title:
>  Glipper dies when desktop starting
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/glipper/+bug/213494/+subscribe
>

--
Mvh
-fredrik-normann-
Sent from my Gmail Account

[unf (unfito)]

Dear friend,
Just got an Nikon D80 10.2MP Digital SLR Camera on this website: bihoir.com
Much cheaper than the market price. If you want to buy digital products,
just order online and you will get the high quality products.
Hope you can enjoy shopping!
Thanks & Regards!

[Daniel Hahler (blueyed)]

Yes, there's still a problem, if there's "strange" history data, which cannot be loaded correctly.

See bug #833629 about this.

[David Kaplan (dmkaplan)]

I have glipper installed and recently updated to precise pangolin. Regularly, I get a message that glipper died after logging in to my machine. The little glipper icon remains in the bar at the top of the screen, but it is unreactive. This sounds pretty similar to the original bug report even though a fix has supposedly been released.

[Laszlo Pandy (laszlok)]

@David, what version of glipper? What is the exact message? Are you using Unity, or a different desktop?

[Andrea Corbellini (andrea.corbellini)]

Hi David. Please open a new bug report for your issue. To report a new bug, press Alt+F2 (or open a terminal) and type:

  ubuntu-bug glipper

You can have more information about how bug reports are reported and handled here:

  https://help.ubuntu.com/community/ReportingBugs

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".