Peter Moulder | 15 Mar 07:03
Picon
Picon

Bug#238073: gcm: Please remove (or update) unhelpful README document

Package: gcm
Version: 2.1.0+20031016.1-2
Severity: wishlist

The README installed in /usr/share/doc/gcm refers to a non-existent
"doc/" directory.  Presumably the user who has already found that README
file already knows that /usr/share/doc/gcm is a good place to look for
documentation, or else they probably wouldn't have found that README
file in the first place.  (If there is some other place that refers the
user to /usr/share/doc/gcm/README then perhaps that reference should
instead "inline" the README contents.)

Without having looked at the gcm source package, I'd guess that you can
avoid the README being installed by editing debian/docs or
debian/gcm.docs.

pjrm.

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Peter Moulder | 15 Mar 07:20
Picon
Picon

Bug#238075: gcm man page refers to no-longer-existent gcm-applet package

Package: gcm
Version: 2.1.0+20031016.1-2
Severity: minor

The parenthesis "(provided by the \fIgcm-applet\fP package in Debian)"
should probably be deleted from the gcm.1 and gcmui.1 man pages, so that
users do not search in vain for the no-longer-existent gcm-applet
package.

Also I'd suggest converting a couple of hyphens in the man pages to
ascii dashes / minus signs, by preceding with a backslash: "two dashes
(`\-')", "Panel \-> Utility \-> Clipboard".  In some locales (e.g.
uxterm with LC_CTYPE=fr_FR.UTF-8), hyphen (plain dash in roff) is
rendered with a different character from "\-", which hinders copy &
paste from the rendered man page, and doesn't look as good (the hyphen
is shorter than an ascii minus sign).  Whereas the phrase
"right-clicking" should remain as a hyphen.

Thanks,

pjrm.

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Philip Van Hoof | 15 Mar 10:35

Re: gcm documentation

On Mon, 2004-03-15 at 08:14, Peter Moulder wrote:
> The mechanism for learning of applications becoming selection owner
> seems clever, though I think you should document whether it is subject
> to race conditions.  The normal sequence is:
> 
>    1. gcm is the selection owner.
>    2. Another application does a Copy operation, and becomes selection
>       owner.
>    3. X informs gcm that gcm is no longer the selection owner.
>    4. gcm requests the new selection of the new selection owner.
>    5. gcm becomes selection owner again.

Indeed, and before I do the rest of my reply I would like to inform you
that I dislike how gcm needs to perform this trick in order to get
Clipboard Management working.

Therefor I decided to halt development of gcm until a better mechanism
is possible in Gtk+. For example, if it would be possible for any
application to know when the Clipboard Owner is changed, the application
would be much cleaner and nicer. Now, the only way to know when the
clipboard owner changes, it to try being the clipboard owner at all
times, stealing the ownership right after the owner changed.

> I wonder what happens if more than one other application does a Copy
> operation during that sequence (perhaps due to scheduling decisions of
> the operating system if the system is heavily loaded).

Between 3 and 4 gcm will request the clipboard from the selection owner
and will wait with any operation until it is fully received. Gcm will
then, no matter what, try to put selection ownership on the newly
(Continue reading)

Luk Claes | 15 Mar 14:28
Picon
Favicon

Bug#230821: gcm_2.1.0+20031016.1-2(unstable/arm): needs libtool update for arm


Hi

I think you can solve this bug by:
* making sure you have installed the build-deps, libtool, autotools-dev
and autoconf installed
* running the folowing commands in the root source dir

libtoolize -f -c
aclocal
automake
autoheader
autoconf

Cheers

Luk
Andreas Metzler | 18 Mar 12:08

Bug#238672: gcm: Links against libgnutls5 on ARM. Please rebuild.

Package: gcm
Version: N/A; reported 2004-03-18
Severity: minor

gcm on ARM is one of the 6 packages still linking against libgnutls5
(instead of at least libgnutls7). 5 and and 7 are API-compatibel.

On a sidenote I wonder what busines gcm has in linking against
libgnutls at all. It is not encrypting the clipboard, is it?
              cu andreas

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Frank Lichtenheld | 20 Mar 00:08
Picon
Favicon
Gravatar

Bug#230821: Patch

tags 230821 patch
thanks

I prepared a patch for a NMU of this package. However, as I'm not very
confident in this libtools stuff and I had to add an additional
build-depends (seems related to intltool) after regenerating the files
I'm not sure if I should upload.

So only sending the patch for now.

Gruesse,
--

-- 
Frank Lichtenheld <djpig <at> debian.org>
www: http://www.djpig.de/
diff -Naur gcm-2.1.0+20031016.1.bak/Makefile.in gcm-2.1.0+20031016.1/Makefile.in
--- gcm-2.1.0+20031016.1.bak/Makefile.in	Wed Oct 15 18:51:26 2003
+++ gcm-2.1.0+20031016.1/Makefile.in	Fri Mar 19 21:43:08 2004
 <at>  <at>  -86,6 +86,7  <at>  <at> 
 INTLTOOL_DESKTOP_RULE =  <at> INTLTOOL_DESKTOP_RULE <at> 
 INTLTOOL_DIRECTORY_RULE =  <at> INTLTOOL_DIRECTORY_RULE <at> 
 INTLTOOL_EXTRACT =  <at> INTLTOOL_EXTRACT <at> 
+INTLTOOL_KBD_RULE =  <at> INTLTOOL_KBD_RULE <at> 
 INTLTOOL_KEYS_RULE =  <at> INTLTOOL_KEYS_RULE <at> 
 INTLTOOL_MERGE =  <at> INTLTOOL_MERGE <at> 
 INTLTOOL_OAF_RULE =  <at> INTLTOOL_OAF_RULE <at> 
diff -Naur gcm-2.1.0+20031016.1.bak/aclocal.m4 gcm-2.1.0+20031016.1/aclocal.m4
--- gcm-2.1.0+20031016.1.bak/aclocal.m4	Wed Oct 15 18:51:15 2003
+++ gcm-2.1.0+20031016.1/aclocal.m4	Fri Mar 19 21:43:05 2004
(Continue reading)

Yann Dirson | 24 Mar 20:52

Bug#230821: patch looks ok

Hi Frank,

You wrote:
>I prepared a patch for a NMU of this package. However, as I'm not very
>confident in this libtools stuff and I had to add an additional
>build-depends (seems related to intltool) after regenerating the files
>I'm not sure if I should upload.

This looks like an intltool issue, but until intltool gets eventually
changed it looks like the right solution to add this build-dep.  I can
remember doing that once, at least :)

Regards,
--

-- 
Yann Dirson    <ydirson <at> altern.org> |    Why make M$-Bill richer & richer ?
Debian-related: <dirson <at> debian.org> |   Support Debian GNU/Linux:
Pro:    <yann.dirson <at> fr.alcove.com> |  Freedom, Power, Stability, Gratuity
     http://ydirson.free.fr/        | Check <http://www.debian.org/>

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Andrew Lau | 24 Mar 22:51
Picon

Bug#230821: patch looks ok

On Wed, Mar 24, 2004 at 08:52:08PM +0100, Yann Dirson wrote:
> >I prepared a patch for a NMU of this package. However, as I'm not very
> >confident in this libtools stuff and I had to add an additional
> >build-depends (seems related to intltool) after regenerating the files
> >I'm not sure if I should upload.
> 
> This looks like an intltool issue, but until intltool gets eventually
> changed it looks like the right solution to add this build-dep.  I can
> remember doing that once, at least :)

Hey guys,

The reason that I haven't uploaded a fixed version of gcm is because
that it's broken in CVS right now. Try checking out from
anoncvs.gnome.org and attempt to fix the intltool problems currently in
that tree. Regenerating the libtool files only created more errors.  I'm
struggling to actually find enough free time to solve all the problems
I'm facing right now, and it seems like GCM is a now an obsolete project
(until the C# version comes out -- months off).

Cheers,
Andrew "Netsnipe" Lau

--

-- 
---------------------------------------------------------------------------
	Andrew "Netsnipe" Lau	<http://www.cse.unsw.edu.au/~alau/>
 Debian GNU/Linux Maintainer & UNSW Computing Students' Society President
				     -
		  "Nobody expects the Debian Inquisition!
     Our two weapons are fear and surprise...and ruthless efficiency!"
(Continue reading)

Philip Van Hoof | 24 Mar 23:48

Re: Bug#230821: patch looks ok

On Wed, 2004-03-24 at 22:51, Andrew Lau wrote:

> Hey guys,
> 
> The reason that I haven't uploaded a fixed version of gcm is because
> that it's broken in CVS right now. Try checking out from
> anoncvs.gnome.org and attempt to fix the intltool problems currently in
> that tree. Regenerating the libtool files only created more errors.  I'm
> struggling to actually find enough free time to solve all the problems
> I'm facing right now, and it seems like GCM is a now an obsolete project
> (until the C# version comes out -- months off).
> 

Indeed,

The basic concept of gcm is wrong. It's unwise to let an application
harvest clipboards unless some more intelligent API in X is created at
some point.

I know, I created gcm and hell I dislike it a lot. But it's the only way
to do it.

Therefor I gave up all efforts to build a Clipboard Manager, until a
improved Clipboard Mechanism is introduced by for example
freedesktop.org AND I find some free time to rebuild the concept around
a better mechanism.

The current problem is that one application just cannot know when
another application gains Clipboard Ownership. Well thats not entirely
true, the one application can know it by being clipboard owner at all
(Continue reading)

Andrew Lau | 25 Mar 14:46
Picon

Bug#240042: ftp.debian.org: Removal of gcm from archives

Package: ftp.debian.org
Severity: normal

Hi ftpmaster crew,

After some discussion with the GNOME Clipboard Manager's upstream
author, we both agree that the best way to current to deal with the RC
bugs in the gcm package is to remove it altogether from Debian until
freedesktop.org can formalise a new X11 clipboard standard.

Thanks in advanced,
Andrew "Netsnipe" Lau

----- Forwarded message from Philip Van Hoof <spamfrommailing <at> freax.org> -----

Subject: Re: [Gcm-devel] Bug#230821: patch looks ok
From: Philip Van Hoof <spamfrommailing <at> freax.org>
To: gcm-devel <at> lists.sourceforge.net
Cc: Yann Dirson <ydirson <at> altern.org>, 230821 <at> bugs.debian.org,
	Frank Lichtenheld <djpig <at> debian.org>, spitzak <at> d2.com
On Wed, 2004-03-24 at 22:51, Andrew Lau wrote:
> Hey guys,
> 
> The reason that I haven't uploaded a fixed version of gcm is because
> that it's broken in CVS right now. Try checking out from
> anoncvs.gnome.org and attempt to fix the intltool problems currently in
> that tree. Regenerating the libtool files only created more errors.  I'm
> struggling to actually find enough free time to solve all the problems
> I'm facing right now, and it seems like GCM is a now an obsolete project
> (until the C# version comes out -- months off).
(Continue reading)


Gmane