Re: [Dorset] Terminal beep in Xwindows

2011-05-24 Thread Tim Allen

Hi Ralph

On 24/05/11 10:45, Ralph Corderoy wrote:

Hi Tim,


If you haven't resolved this yet, how about using xkbevd(1).

 xkbevd -bg -cfg<(printf 'bell("ImAlive") ignore
 bell() shell "xkbbell -force"\n')

It doesn't seem to cause recursion here.


I haven't a clue how, but it does actually work!


The<(printf ...) syntax is just a bashism to avoid me creating a
configuration file for -cfg.  If there was a config. file it would have

 bell("ImAlive") ignore
 bell() shell "xkbbell -force"

An X client, e.g. terminal, causes an XkbBell event to be sent to the X
server where it's passed on to all those that have registered an
interest.  For some reason nothing on your system is picking it up and
wanting to beep so we're running our own listening daemon for X keyboard
events, xkbevd, and telling it what to do in the config. file.

That file is a bit like the `pattern {action}' of an awk(1) script.  The
first pattern to match has its action executed and, unlike awk, no more
are tested.  You'd think we'd just need to say "on any bell event get a
shell to run `xkbbell -force'",

 bell() shell "xkbbell -force"

but for some annoying reason on starting xkbevd there seems to be an
XkbBell event for a bell named "ImAlive".  Bells can have names so an X
client might ring the Ink Low bell one minute and the Carriage Return
bell the next.  So an earlier pattern is needed that's more specific.
Instead of the `any bell' stated by the empty parenthesis above, the
bell name is given and the action is to ignore it.

 bell("ImAlive") ignore

Since a pattern has matched the following ones aren't tested and the
annoying beep on starting xkbevd stops.



Many thanks for such a detailed explanation - learned a lot from that. 
I've stuck this in ~/.bashrc


Cheers

Tim

--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Ubuntu 11.04 file problem

2011-05-24 Thread John Carlyle-Clarke

On 24/05/11 11:08, CPK Smithies wrote:

Symptom: 10.10 upgraded to 11.04, now everything very slow.

My experience: on booting 11.04 off disk for the first time, I found
that my swap partition now had a different UUID. Consequently, I had a
zero-size swap.

Suggestion: the same may have happened in this case. If there's not a
lot of RAM on the machine, then a non-zero swap space may be essential
in order to run a GUI. This can be checked from the command line by
comparing the output of:

$ grep swap /etc/fstab # shows the configured UUID
$ blkid |grep swap # shows the correct UUID

If the two differ, I recommend copying the correct UUID, using

$ sudo nano /etc/fstab

to edit the config. file, and then restarting the system.

I would be interested to know if that was the problem in this case, and
if so, whether the proposed solution cured it.



The swapon command can be helpful here too.

sudo swapon -s

will show swap partitions in use.

sudo swapon -L 

will start using the partition with the specified label as a swap partition.

sudo swapon -U 

will start using the partition with the specified uuid as a swap partition.

You can also do:-

sudo swapon /dev/sda3

or similar.

As you say, to make it permanent you need to edit /etc/fstab but for 
testing the above might help.


--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Ubuntu 11.04 file problem

2011-05-24 Thread CPK Smithies
Symptom: 10.10 upgraded to 11.04, now everything very slow.

My experience: on booting 11.04 off disk for the first time, I found
that my swap partition now had a different UUID. Consequently, I had a
zero-size swap.

Suggestion: the same may have happened in this case. If there's not a
lot of RAM on the machine, then a non-zero swap space may be essential
in order to run a GUI. This can be checked from the command line by
comparing the output of:

$ grep swap /etc/fstab # shows the configured UUID
$ blkid |grep swap # shows the correct UUID

If the two differ, I recommend copying the correct UUID, using

$ sudo nano /etc/fstab

to edit the config. file, and then restarting the system.

I would be interested to know if that was the problem in this case, and
if so, whether the proposed solution cured it.


--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Ubuntu 11.04 file problem

2011-05-24 Thread John Carlyle-Clarke

On 24/05/11 11:04, John Carlyle-Clarke wrote:


Just be aware that if you do this:-

cd ~
cp -a * /media/backup/myhomebackup

You will lose a lot of data, because the * won't match any file or
directory starting with a ".", and there are quite a few crucial ones in
your home directory.


Sorry, I should clarify that.  When I say "you will lose a lot of data" 
I mean that your backup will be incomplete.


--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Ubuntu 11.04 file problem

2011-05-24 Thread John Carlyle-Clarke

On 24/05/11 10:52, Peter wrote:

On Mon, 2011-05-23 at 20:46 +0100, Keith Edmunds wrote:

Peter, you need to use the -a switch (although there are other ways):

cp -a from-here to-here

That will copy all directories recursively.


Thanks Keith&  Tim.  I now have the latest backup on a separate hard
disk so I can start to sort out the other problems



Just be aware that if you do this:-

cd ~
cp -a * /media/backup/myhomebackup

You will lose a lot of data, because the * won't match any file or 
directory starting with a ".", and there are quite a few crucial ones in 
your home directory.


DAMHIKT

A better way to do this is:-

cd /home
cp -a $USER /media/backup

Finally, be aware that if you have symbolic links to data _outside_ your 
/home/$USER directory, that data will not be copied.  The links will be 
preserved - that is to say, the backup will contain a link to that data, 
not the actual data.



--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Ubuntu 11.04 file problem

2011-05-24 Thread Peter
On Mon, 2011-05-23 at 20:46 +0100, Keith Edmunds wrote:
> Peter, you need to use the -a switch (although there are other ways):
> 
>   cp -a from-here to-here
> 
> That will copy all directories recursively.

Thanks Keith & Tim.  I now have the latest backup on a separate hard
disk so I can start to sort out the other problems

Peter.


--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Terminal beep in Xwindows

2011-05-24 Thread Ralph Corderoy
Hi Tim,

> > If you haven't resolved this yet, how about using xkbevd(1).
> >
> > xkbevd -bg -cfg <(printf 'bell("ImAlive") ignore
> > bell() shell "xkbbell -force"\n')
> >
> > It doesn't seem to cause recursion here.
>
> I haven't a clue how, but it does actually work!

The <(printf ...) syntax is just a bashism to avoid me creating a
configuration file for -cfg.  If there was a config. file it would have

bell("ImAlive") ignore
bell() shell "xkbbell -force"

An X client, e.g. terminal, causes an XkbBell event to be sent to the X
server where it's passed on to all those that have registered an
interest.  For some reason nothing on your system is picking it up and
wanting to beep so we're running our own listening daemon for X keyboard
events, xkbevd, and telling it what to do in the config. file.

That file is a bit like the `pattern {action}' of an awk(1) script.  The
first pattern to match has its action executed and, unlike awk, no more
are tested.  You'd think we'd just need to say "on any bell event get a
shell to run `xkbbell -force'",

bell() shell "xkbbell -force"

but for some annoying reason on starting xkbevd there seems to be an
XkbBell event for a bell named "ImAlive".  Bells can have names so an X
client might ring the Ink Low bell one minute and the Carriage Return
bell the next.  So an earlier pattern is needed that's more specific.
Instead of the `any bell' stated by the empty parenthesis above, the
bell name is given and the action is to ignore it.

bell("ImAlive") ignore

Since a pattern has matched the following ones aren't tested and the
annoying beep on starting xkbevd stops.

Cheers, Ralph.

--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue


Re: [Dorset] Terminal beep in Xwindows

2011-05-24 Thread Tim Allen

Hi Ralph

On 21/05/11 10:33, Ralph Corderoy wrote:

Hi Tim,


Given that xkbbell -force does sound the bell, does that provide a
clue as to how to fix this (sorry, the man page is over my head!).


- is there some means of querying/changing XkbAudibleBellMask or is
this a red herring?


XkbAudibleBellMask is just a constant,

 $ g -rw2 XkbAudibleBellMask /usr/include/X11
 /usr/include/X11/extensions/XKB.h-#define   XkbAccessXTimeoutMask
(1L<<  7)
 /usr/include/X11/extensions/XKB.h-#define   XkbAccessXFeedbackMask   
(1L<<  8)
 /usr/include/X11/extensions/XKB.h:#define   XkbAudibleBellMask   
(1L<<  9)
 /usr/include/X11/extensions/XKB.h-#define   XkbOverlay1Mask  
(1L<<  10)
 /usr/include/X11/extensions/XKB.h-#define   XkbOverlay2Mask  
(1L<<  11)
 $

but I can't see an obvious way of finding out what X clients are
interested in it other than gdb, as that post suggests.

If you haven't resolved this yet, how about using xkbevd(1).

 xkbevd -bg -cfg<(printf 'bell("ImAlive") ignore
 bell() shell "xkbbell -force"\n')

It doesn't seem to cause recursion here.




I haven't a clue how, but it does actually work! Looked at the man page 
and did find


http://wiesmann.codiferes.net/wordpress/?p=4536&lang=en

but I'm seriously out of my depth here!


Cheers

Tim




Cheers, Ralph.

--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue




--
Tim Allen
D.C. Allen Ltd
9 Didcot Road
Nuffield Industrial Estate
Poole
Dorset
England
BH17 0GD

Tel: +44 (0)1202 671666
Fax: +44 (0)1202 671668
Email: timal...@dcallen.co.uk

--
Next meeting:  Bournemouth, Tuesday 2011-06-07 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
How to Report Bugs Effectively:  http://goo.gl/4Xue