On Thu, 2014-07-03 at 00:37 +0200, wwp wrote:
> Hello there!
>
>
> I'm trying to get sound from applications running from other users bug
> the one who owns the current GNOME sessions.
>
> Typically, my default user is "A" and he's running the GNOME session,
> logged in graphically. From this se
On 7/2/2014 3:37 PM, wwp wrote:
> Adding those users to the "audio" group didn't help. Any idea how to do
> this?
some google-fu suggests group 'pulse-access' should be used. no idea
if thats actually legit.
--
john r pierce 37N 122W
somewhere on the
On 07/03/2014 12:37 AM, wwp wrote:
> Hello there!
>
>
> I'm trying to get sound from applications running from other users bug
> the one who owns the current GNOME sessions.
>
> Typically, my default user is "A" and he's running the GNOME session,
> logged in graphically. From this session, I op
Hello there!
I'm trying to get sound from applications running from other users bug
the one who owns the current GNOME sessions.
Typically, my default user is "A" and he's running the GNOME session,
logged in graphically. From this session, I open terminals, su to other
users (B or C, non-root)
I am experimenting with tmux. I have run into a behaviour that I would like
to change. Idf I connect to a single host multiple times via tmux, when I
exit one tmux window then all the windows report their session closed. Is
there anyway of changing this behaviour in .tmux.conf so that only the s
On Wed, Jul 2, 2014 at 2:53 PM, Lists wrote:
> I'm trying to streamline a backup system using ZFS. In our situation,
> we're writing pg_dump files repeatedly, each file being highly similar
> to the previous file. Is there a file system (EG: ext4? xfs?) that, when
> re-writing a similar file, will
Lists wrote:
> I'm trying to streamline a backup system using ZFS. In our situation,
> we're writing pg_dump files repeatedly, each file being highly similar
> to the previous file. Is there a file system (EG: ext4? xfs?) that, when
> re-writing a similar file, will write only the changed blocks an
I'm trying to streamline a backup system using ZFS. In our situation,
we're writing pg_dump files repeatedly, each file being highly similar
to the previous file. Is there a file system (EG: ext4? xfs?) that, when
re-writing a similar file, will write only the changed blocks and not
rewrite the
Lists wrote:
> On 07/01/2014 06:41 PM, Lists wrote:
>> Am I being optimistic to think that I should be generally able to
>> identify and/or log ECC error correction events with EL6?
>
> I've found the answer to my question, replying for future reference.
> EDAC really only applies to older systems.
On 07/01/2014 06:41 PM, Lists wrote:
> Am I being optimistic to think that I should be generally able to
> identify and/or log ECC error correction events with EL6?
I've found the answer to my question, replying for future reference.
EDAC really only applies to older systems. Use mcelog for newer
On 07/02/2014 10:50 AM, Reindl Harald wrote:
>
> Am 02.07.2014 16:41, schrieb Robert Moskowitz:
>> So I made sure that all the packages were reinstalled. I did it step by
>> step and did 'yum install' on:
>>
>> kernel-headers
>> glibc-devel
>> irqbalance
>> mod_perl
>> perl-Test-Simple
>> redhat-
On 07/02/2014 10:33 AM, Reindl Harald wrote:
>
> Am 02.07.2014 16:31, schrieb Reindl Harald:
>>
>> Am 02.07.2014 16:27, schrieb Reindl Harald:
>>> Am 02.07.2014 16:20, schrieb Robert Moskowitz:
On 07/02/2014 09:35 AM, Reindl Harald wrote:
> Am 02.07.2014 15:19, schrieb Robert Moskowitz:
>
On 07/02/2014 10:25 AM, Robert Moskowitz wrote:
> On 07/02/2014 10:20 AM, Robert Moskowitz wrote:
>> On 07/02/2014 09:35 AM, Reindl Harald wrote:
>>> Am 02.07.2014 15:19, schrieb Robert Moskowitz:
On 07/02/2014 08:41 AM, Reindl Harald wrote:
> Am 02.07.2014 14:32, schrieb Robert Moskowitz
m.r...@5-cent.us wrote:
> Robert Moskowitz wrote:
>>
>> On 07/01/2014 06:25 PM, Frank Cox wrote:
>>> On Tue, 01 Jul 2014 18:19:32 -0400
>>> Robert Moskowitz wrote:
>>>
How do I trouble shoot this? I am assuming that I only got a
partially completed update.
>>> Try yum-complete-transactio
Robert Moskowitz wrote:
>
> On 07/01/2014 06:25 PM, Frank Cox wrote:
>> On Tue, 01 Jul 2014 18:19:32 -0400
>> Robert Moskowitz wrote:
>>
>>> How do I trouble shoot this? I am assuming that I only got a partially
>>> completed update.
>> Try yum-complete-transaction and see what happens.
>
> Well i
On 07/02/2014 10:20 AM, Robert Moskowitz wrote:
> On 07/02/2014 09:35 AM, Reindl Harald wrote:
>> Am 02.07.2014 15:19, schrieb Robert Moskowitz:
>>> On 07/02/2014 08:41 AM, Reindl Harald wrote:
Am 02.07.2014 14:32, schrieb Robert Moskowitz:
> On 07/01/2014 06:25 PM, Frank Cox wrote:
>
On 07/02/2014 09:35 AM, Reindl Harald wrote:
>
> Am 02.07.2014 15:19, schrieb Robert Moskowitz:
>> On 07/02/2014 08:41 AM, Reindl Harald wrote:
>>> Am 02.07.2014 14:32, schrieb Robert Moskowitz:
On 07/01/2014 06:25 PM, Frank Cox wrote:
> On Tue, 01 Jul 2014 18:19:32 -0400
> Robert Mos
On 07/02/2014 09:35 AM, Reindl Harald wrote:
>
> Am 02.07.2014 15:19, schrieb Robert Moskowitz:
>> On 07/02/2014 08:41 AM, Reindl Harald wrote:
>>> Am 02.07.2014 14:32, schrieb Robert Moskowitz:
On 07/01/2014 06:25 PM, Frank Cox wrote:
> On Tue, 01 Jul 2014 18:19:32 -0400
> Robert Mos
On 07/02/2014 09:10 AM, Ljubomir Ljubojevic wrote:
> On 07/02/2014 02:32 PM, Robert Moskowitz wrote:
>> On 07/01/2014 06:25 PM, Frank Cox wrote:
>>> On Tue, 01 Jul 2014 18:19:32 -0400
>>> Robert Moskowitz wrote:
>>>
How do I trouble shoot this? I am assuming that I only got a partially
On 07/02/2014 08:41 AM, Reindl Harald wrote:
>
> Am 02.07.2014 14:32, schrieb Robert Moskowitz:
>> On 07/01/2014 06:25 PM, Frank Cox wrote:
>>> On Tue, 01 Jul 2014 18:19:32 -0400
>>> Robert Moskowitz wrote:
>>>
How do I trouble shoot this? I am assuming that I only got a partially
compl
On 07/02/2014 02:32 PM, Robert Moskowitz wrote:
>
> On 07/01/2014 06:25 PM, Frank Cox wrote:
>> On Tue, 01 Jul 2014 18:19:32 -0400
>> Robert Moskowitz wrote:
>>
>>> How do I trouble shoot this? I am assuming that I only got a partially
>>> completed update.
>> Try yum-complete-transaction and see
On 07/01/2014 06:25 PM, Frank Cox wrote:
> On Tue, 01 Jul 2014 18:19:32 -0400
> Robert Moskowitz wrote:
>
>> How do I trouble shoot this? I am assuming that I only got a partially
>> completed update.
> Try yum-complete-transaction and see what happens.
Well it looks like all the updates 'took'
- Original Message -
| On 7/1/2014 9:40 PM, James A. Peltier wrote:
| > inode64 is a mount time option and it is a one way option as well.
| > Once you mounted a filesystem with inode64 you can't go back. It
| > has to do with inode allocation. If you have older operating
| > systems mou
On 07/02/2014 03:55 AM, Always Learning wrote:
>
> On Wed, 2014-07-02 at 00:42 +0200, Ljubomir Ljubojevic wrote:
>
>> You can do "yum history list" to see the number of the last command,
>
> Nice advice :-) but does not work for C 5.10
>
> http://www.if-not-true-then-false.com/2010/yum-history-
On 7/1/2014 9:40 PM, James A. Peltier wrote:
> inode64 is a mount time option and it is a one way option as well. Once you
> mounted a filesystem with inode64 you can't go back. It has to do with inode
> allocation. If you have older operating systems mounting a filesystem with
> inode64 will
25 matches
Mail list logo
