RE: Kernel-2.6.31.6-134 seems to have a bug on R600 DRM

2009-11-23 Thread Rodd Clarkson

That has absolutely nothing to do with what Liang posted, but please
  do
file a separate bug report for it:
   
https://fedoraproject.org/wiki/How_to_debug_Xorg_problems
   
thanks!
   again criticizing the reporter for reporting his case.  That was what he
  was
  
  Um, where did I criticize anyone? I just told the reporter it wasn't the
  same bug.
  
 from the descriptions I have seen on this thread there is a possibility that
 it was, although remote.  Maybe it is the tone of what you are saying. Tone
 it down and be more tolerant is by far a more rational approach.  People
 won't report their observation then where will you be.

Otto, what monitor do you have?  Mine is just an ordinary flat panel
display and doesn't show the 'tone' of a message.  I'd love a display
like yours since text is such an awkward medium and I often find myself
adding 'tone' while reading emails, only to wonder if I've got the tone
right.

sincerely ;-]


Rodd

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Fedora 12 has gone gold

2009-11-09 Thread Rodd Clarkson
On Mon, 2009-11-09 at 17:29 -0800, Jesse Keating wrote:
 We have just completed our Go / No Go meeting for Fedora 12 and have
 reached the decision to Go.  Fedora 12's package set is golden and we're
 ready to stage things for shipping.  Great work all around, I'm very
 proud of this release.  I'm sure there will be more back patting and
 hand shaking to come, but Will Woods would like to remind everybody that
 it's just 11 weeks until Fedora 13 Alpha freeze!

I'd just like to say a big thank you to all involved in F12.

Over the development cycle I couldn't get my system to boot, then I
couldn't get X running, and then I couldn't keep it running and finally
the ATI issues I and others were having were resolved.

I'm pleased to say that while I didn't get to see it evolve from f11 to
f12, when it finally worked, it was far better than I ever expected, and
many of the issues I've had with f11 have been resolved which is great
(and yes, I had filed bugs ;-])


Rodd

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Help with debuging Xserver / Goes in an infinite loop

2009-10-13 Thread Rodd Clarkson
On Mon, 2009-10-05 at 23:05 +0200, Joshua C. wrote:
 2009/10/5 Adam Jackson a...@redhat.com:
  On Mon, 2009-10-05 at 19:19 +0200, Joshua C. wrote:
 
  (gdb) bt
  #0  0x003cc3cd70b3 in __select_nocancel () from /lib64/libc.so.6
  #1  0x004e615a in WaitForSomething (
  pClientsReady=value optimized out) at WaitFor.c:228
  #2  0x00446ef2 in Dispatch () at dispatch.c:386
  #3  0x0042d205 in main (argc=value optimized out,
  argv=0x7fffa2ac9218, envp=value optimized out) at main.c:397
 
  Okay, this isn't the server actually taking 100% of the CPU (almost
  certainly), it's before that.  If you type 'cont' to resume, and then ^C
  the gdb process once the CPU goes wild, you should break back to the gdb
  prompt; _that_'s the backtrace I need.
 
  Of course, you might not, in which case debugging this gets a bit
  harder.
 
  - ajax
 
  --
  fedora-devel-list mailing list
  fedora-devel-list@redhat.com
  https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
 
 (gdb) handle SIGUSR1 nostop
 SignalStop  Print   Pass to program Description
 SIGUSR1   NoYes Yes User defined signal 1
 (gdb) handle SIGUSR2 nostop
 SignalStop  Print   Pass to program Description
 SIGUSR2   NoYes Yes User defined signal 2
 (gdb) handle SIGPIPE nostop
 SignalStop  Print   Pass to program Description
 SIGPIPE   NoYes Yes Broken pipe
 (gdb) cont
 Continuing.
 ^C
 Program received signal SIGINT, Interrupt.
 0x003cc3cd6827 in ioctl () from /lib64/libc.so.6
 (gdb) bt
 #0  0x003cc3cd6827 in ioctl () from /lib64/libc.so.6
 #1  0x003cd6003113 in drmIoctl (fd=8, request=3221775460,
 arg=0x7fff78cabbc0) at xf86drm.c:187
 #2  0x003cd600335c in drmCommandWriteRead (fd=8,
 drmCommandIndex=value optimized out, data=0x7fff78cabbc0,
 size=value optimized out)
 at xf86drm.c:2363
 #3  0x7f6c6a6b3f08 in radeon_bufmgr_gem_wait_rendering (buf=value
 optimized out) at radeon_bufmgr_gem.c:282
 #4  0x7f6c6a69a51a in RADEONPrepareAccess (pPix=0x243c2d0,
 index=0) at radeon_exa.c:279
 #5  0x7f6c69be43b4 in ExaDoPrepareAccess (pDrawable=0x243c2d0,
 index=0) at exa.c:523
 #6  0x7f6c69be44b8 in exaPrepareAccessReg (pDrawable=0x243c2d0,
 index=0, pReg=0x0) at exa.c:543
 #7  0x7f6c69beceac in ExaCheckComposite (op=value optimized out,
 pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=value optimized
 out,
 ySrc=value optimized out, xMask=0, yMask=0, xDst=19, yDst=85,
 width=55, height=18) at exa_unaccel.c:342
 #8  0x7f6c69beb564 in exaComposite (op=value optimized out,
 pSrc=0x24430a0, pMask=0x2397610, pDst=0x27a04b0, xSrc=value optimized
 out,
 ySrc=value optimized out, xMask=0, yMask=0, xDst=19, yDst=85,
 width=55, height=18) at exa_render.c:967
 #9  0x0052eb90 in damageComposite (op=8 '\b', pSrc=value
 optimized out, pMask=value optimized out, pDst=0x27a04b0, xSrc=1,
 ySrc=0,
 xMask=value optimized out, yMask=value optimized out, xDst=19,
 yDst=85, width=55, height=value optimized out) at damage.c:643
 #10 0x0052720c in ProcRenderComposite (client=0x2625310) at 
 render.c:720
 #11 0x004471d4 in Dispatch () at dispatch.c:456
 #12 0x0042d205 in main (argc=value optimized out,
 argv=0x7fff78cac198, envp=value optimized out) at main.c:397
 

Hmmm, I wonder if you're not having the same issues (or similar) to me.

See: https://bugzilla.redhat.com/show_bug.cgi?id=528593

If I run gdb I get the following:

#0  0x0032c16d9717 in ioctl () at ../sysdeps/unix/syscall-template.S:82
#1  0x0032dec03203 in drmIoctl (fd=9, request=3221775460, 
arg=0x7fff192a1ab0) at xf86drm.c:188
#2  0x0032dec0344c in drmCommandWriteRead (fd=value optimized out, 
drmCommandIndex=value optimized out, data=value optimized out, 
size=value optimized out) at xf86drm.c:2394
#3  0x7f7cc9f81f59 in bo_wait (bo=0x1cdc780) at radeon_bo_gem.c:206
#4  0x7f7cc9f82035 in bo_map (bo=0x1cdc780, write=value optimized out)
at radeon_bo_gem.c:181
#5  0x7f7cca24f36d in _radeon_bo_map (line=2320, 
func=value optimized out, file=0x1 Address 0x1 out of bounds, write=0, 
bo=value optimized out) at /usr/include/drm/radeon_bo.h:151
#6  R600DownloadFromScreenCS (line=2320, func=value optimized out, 
file=0x1 Address 0x1 out of bounds, write=0, bo=value optimized out)
at r600_exa.c:2320
#7  0x7f7cc9545100 in exaGetImage (pDrawable=0x1b37dc0, x=1536, y=704, 
w=256, h=64, format=value optimized out, 
planeMask=value optimized out, d=value optimized out)
at exa_accel.c:1283
#8  0x00552a94 in miSpriteGetImage (pDrawable=0x1b37dc0, sx=1536, 
sy=704, w=256, h=64, format=value optimized out, 
planemask=value optimized out, pdstLine=value optimized out)
at misprite.c:425
#9  0x0042dec0 in DoGetImage (planemask=value optimized out, 
height=value optimized out, width=value optimized 

Re: Mouse pointer freezing in f12 and f11

2009-09-17 Thread Rodd Clarkson
On Wed, 2009-09-16 at 21:15 +1000, Rodd Clarkson wrote:

  You could verify this with DISPLAY=:0 xinput list when the mouse
  pointer stops.  If you don't see the bluetooth mouse in the list, then
  the kernel is refusing to re-plug it right.  If you _do_ see the mouse
  in the list, then X is confused somewhere.
  
  Does keyboard navigation still work when this happens?  Does alt-tab
  switch windows, etc.
 
 I'll give this a try when I next have a lock-up.
 
 I'm pretty sure that this problem only occurs before I've cycled through
 a suspend-resume.
 
 I suspect bluetooth issues because the bluetooth icon appears until I do
 the suspend-resume cycle and then the icon doesn't appear and bluetooth
 doesn't work (but the mouse does).
 
 Keyboard navigation still works, and I can switch to a VT too.

Ajax

Alright, I've had this happen after a suspend-resume cycle, and it
appears that it's not bluetooth related as the output of xinput is the
same before as after.

Do you want me to file a bug on this and then work from there?

Rodd

Virtual core pointer  id=0[XPointer]
Num_buttons is 32
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is -1
Max_value is -1
Resolution is 0
Axis 1 :
Min_value is -1
Max_value is -1
Resolution is 0
Virtual core keyboard id=1[XKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
AT Translated Set 2 keyboard  id=2[XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Macintosh mouse button emulation  id=3[XExtensionPointer]
Num_buttons is 5
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is -1
Max_value is -1
Resolution is 1
Axis 1 :
Min_value is -1
Max_value is -1
Resolution is 1
HID 413c:8157 id=4[XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
SynPS/2 Synaptics TouchPadid=5[XExtensionPointer]
Num_buttons is 12
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is 1472
Max_value is 5472
Resolution is 1
Axis 1 :
Min_value is 1408
Max_value is 4448
Resolution is 1
Integrated Webcam id=6[XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Sleep Button  id=7[XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Power Button  id=8[XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Video Bus id=9[XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
Power Button  id=10   [XExtensionKeyboard]
Num_keys is 248
Min_keycode is 8
Max_keycode is 255
-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: Mouse pointer freezing in f12 and f11

2009-09-16 Thread Rodd Clarkson
On Tue, 2009-09-15 at 09:42 -0400, Adam Jackson wrote:
 On Thu, 2009-09-10 at 19:29 +1000, Rodd Clarkson wrote:
  I've had a problem with X in f12 or some time that sees the mouse
  pointer freezing.  I'm now having the same issue in f11.
  
  I'm happy to file a bug in bugzilla, but I'm hoping someone mught be
  able to point me in the right direction.
  
  After some time after running X the mouse pointer will freeze.
  Switching to a VT doesn't help, but I can use the keyboard to close apps
  and do a little navigation.  Also pushing the power button will see a
  dialog to allow me to shutdown, suspend, etc.  I can suspend and resume
  and this fixes the problem.
  
  I'm not however convinced that it's an X bug.  I think it might be
  related to bluetooth (I believe that my mouse and keyboard have
  something to do with bluetooth on this laptop) and that the suspend
  resume cycle restarts bluetooth and fixes the problem.
 
 You could verify this with DISPLAY=:0 xinput list when the mouse
 pointer stops.  If you don't see the bluetooth mouse in the list, then
 the kernel is refusing to re-plug it right.  If you _do_ see the mouse
 in the list, then X is confused somewhere.
 
 Does keyboard navigation still work when this happens?  Does alt-tab
 switch windows, etc.

I'll give this a try when I next have a lock-up.

I'm pretty sure that this problem only occurs before I've cycled through
a suspend-resume.

I suspect bluetooth issues because the bluetooth icon appears until I do
the suspend-resume cycle and then the icon doesn't appear and bluetooth
doesn't work (but the mouse does).

Keyboard navigation still works, and I can switch to a VT too.


R.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Graphics Test Week (ATI, NVIDIA and Intel graphics Test Days)

2009-09-10 Thread Rodd Clarkson
On Tue, 2009-09-08 at 14:26 -0700, Adam Williamson wrote:
 Yes, it is now that legendary time, well loved by the hearts of men for
 millennia(*): Graphics Test Week!
 
 Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1).

I would love to help test, but I'm unable to get X to start with current
kernels in rawhide.

The specifics of the bug are:
https://bugzilla.redhat.com/show_bug.cgi?id=513528

It's possible that the start of the bug and the end of the bug are
unrelated, but...

I can run X using an older kernel: 2.6.31-0.125.4.2.rc5.git2.fc12.x86_64
However, current kernels will boot at runlevel 3, however X fails to
start and running startx from level 3 sees it fail.

There are dmesg and Xorg.0.logs in this bug, so it might be nice if
someone who has something to do with X could take a look and see if this
needs to be moved to X (from the kernel).

Then I could run the tests as requested.


Rodd


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Mouse pointer freezing in f12 and f11

2009-09-10 Thread Rodd Clarkson
I've had a problem with X in f12 or some time that sees the mouse
pointer freezing.  I'm now having the same issue in f11.

I'm happy to file a bug in bugzilla, but I'm hoping someone mught be
able to point me in the right direction.

After some time after running X the mouse pointer will freeze.
Switching to a VT doesn't help, but I can use the keyboard to close apps
and do a little navigation.  Also pushing the power button will see a
dialog to allow me to shutdown, suspend, etc.  I can suspend and resume
and this fixes the problem.

I'm not however convinced that it's an X bug.  I think it might be
related to bluetooth (I believe that my mouse and keyboard have
something to do with bluetooth on this laptop) and that the suspend
resume cycle restarts bluetooth and fixes the problem.

Could this be right.  Or should I just file against X.


Rodd

[r...@moose ~]$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory 
Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express 
Graphics Port (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio 
Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 
(rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 
(rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 
(rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 
(rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 
03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility HD 3670
01:00.1 Audio device: ATI Technologies Inc RV635 Audio device [Radeon HD 3600 
Series]
04:00.0 Network controller: Intel Corporation PRO/Wireless 5300 AGN [Shiloh] 
Network Connection
08:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5784M Gigabit 
Ethernet PCIe (rev 10)
09:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
09:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 22)
09:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
09:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter 
(rev 12)
09:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)
[r...@moose ~]$ lsusb
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 05ca:18a1 Ricoh Co., Ltd 
Bus 001 Device 003: ID 2040:1801 Hauppauge 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 413c:8157 Dell Computer Corp. 
Bus 003 Device 004: ID 413c:8158 Dell Computer Corp. 
Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. 
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Kernel 2.6.29 for F10

2009-08-19 Thread Rodd Clarkson
On Wed, 2009-08-19 at 14:16 +1000, Rodd Clarkson wrote:

 Dave,
 
 Is this an offer to try and help me get the f12 kernel to boot on my
 system so that I can test it for you? ;-]
 
 https://bugzilla.redhat.com/show_bug.cgi?id=513528
 
 
 Rodd
 

I'd just like to thank Kyle McMartin for giving me a little help with
this (maybe with a little prompting from Dave???)

I can now boot rawhide so I can now help with testing.

thanks


Rodd

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Kernel 2.6.29 for F10

2009-08-18 Thread Rodd Clarkson

   I too would like to see F10 move up to 2.6.29+  
   prior to end-of-life.
 
 In days of old, we were able to get rebases out pretty quickly after
 their upstream release.  These days, we're hindered by the kernel modesetting
 stuff we're carrying.  It's closely tied to the userspace X drivers,
 and isn't easy to retrofit to a different kernel.
 One of the reasons we haven't pushed them as proper updates is that
 getting the regressions fixed is pretty time consuming, and the limited
 X/KMS manpower we have is better focused on making the F12 stuff work right,
 and getting it upstream.

Dave,

Is this an offer to try and help me get the f12 kernel to boot on my
system so that I can test it for you? ;-]

https://bugzilla.redhat.com/show_bug.cgi?id=513528


Rodd

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

2009-08-01 Thread Rodd Clarkson
On Wed, 2009-07-29 at 20:20 +0200, Nicolas Mailhot wrote:
 Le mercredi 29 juillet 2009 à 17:49 +0100, Bastien Nocera a écrit :
  On Wed, 2009-07-29 at 12:42 -0400, Jeff Garzik wrote:
 
   Problem is...  removing or disabling PA often -does- solve a problem.
  
  Rather, it works around it. The problems in the kernel drivers are
  usually still there...
 
 Before PA a sound problem didn't freeze the GUI (effectively bricking
 the system for normal users). Now it can. In my case, a few months ago,
 it was doing so because a new PA version could not parse a manual config
 change advertised in Fedora's own Glitch-free audio feature page a
 release before.

Oh, you must not have been around when esound was used in gnome.  esd
used to die all the time and drag down applications with it as it went.
The app would sit there waiting to ring it's bell (or whatever) and
since esd wasn't responding, it would just stop.

Of course, you might blame the application (or maybe gnome) for assuming
that the app couldn't go on until that little bell chime rang.


R.


-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

2009-08-01 Thread Rodd Clarkson
On Wed, 2009-07-29 at 12:25 -0500, Dr. Diesel wrote:


 PA, how are they going to get fixed? Telepathy?
 
 
 How long do we expect people to tolerate these bugs before they move
 on? 

I agree, there's only so long that people are willing to wait.  But you
actually have to file a bug before you move on or you haven't
contributed at all.

I have bugs all over my now laptop and I could just switch OSes, but I'm
willing to be a little patient to allow things to catch up.  More
importantly, I'm willing to file bugs and let someone address them.

But when you have a problem and go to a forum and find a solution and
don't ever report a bug, then you've got no right to bitch and whine
that bugs never get fixed and you get sick of waiting.

This of course is just good advice and has nothing to do with
pulseaudio, other then making the point in this thread.


R.



-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12

2009-08-01 Thread Rodd Clarkson
On Fri, 2009-07-31 at 11:10 +, Thomas Janssen wrote:

  I'd like to ask everyone to test this new volume logic. If you don't
  raise your voice now that some output port is not properly detected or
  audio is too faint then later on you won't have any right to complain.
 
 I think you do what you can to make an excellent job on PA.
 
 What i really dont like is this quoted part. Not everybody is able to
 test that right now. Means all that people who can't (for whatever
 reasons), are screwed later (whatever later means).

Two points.

Firstly, that's the nature of testing.  Not everyone can test things and
sometimes some peoples situations get missed.

Secondly, Lennart posted this to fedora-devel-list which is for people
willing to test the current version of fedora.  So everyone on this list
who interested in this can test it should they wish.


R.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: Fit and Finish test day: batteries and suspend

2009-07-20 Thread Rodd Clarkson
I'd really like to join in with this having experienced issues with
suspend/resume with:

* Dell Inspiron 9300 (using nvidia driver as nouveau/nv don't support
suspend/resume)
* Dell Studion XPS 16 (using either radeon or radionhd as the catalyst
driver won't compile on kernel 2.6.29)
* EeePC 1000 series with the 160GB HDD (using the default x driver)

However, I'm a little confused how to build myself a livecd with rawhide
on is and to be honest, I don't have the time to figure it out (as it
appears it's going to take some investigation).

It would be great if the test day (and others) could link to a iso for
rawhide that fits on a CD to make this part of the process simple.

hint, hint ;-]


Rodd


On Fri, 2009-07-17 at 12:50 -0400, Matthias Clasen wrote:
 Just a reminder: 
 
 The next 'fit and finish' test day will take place on July 21, which is
 next Tuesday. We want to look at issues with the user experience around
 batteries, suspend and power management in general.
 
 https://fedoraproject.org/wiki/Test_Day:2009-07-21_Fit_and_Finish:Batteries_and_Suspend
 
 Please join us in #fedora-fit-and-finish.
 
 
 Matthias
 
-- 
MOOSE technology
po box 6061, north croydon, vic 3136 mobile: 0403 338 731
http://www.moosetech.com.au   phone: 03 9726 9457
mailto:r...@moosetech.com.aufax: 03 9726 9456

Share your knowledge.  It is a way to achieve immortality.
-- The Dalai Lama

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


OT: why aren't we campaigning against Apple/Nokia's fight against the use of OGG? (was Re: the end of life for flash player (HTML5))

2009-06-08 Thread Rodd Clarkson
On Mon, 2009-06-08 at 17:30 -0400, Gregory Maxwell wrote:
 2009/6/8 Kelly Miller lightsolphoe...@gmail.com:
  Thanks to Apple, that isn't going to be happening.  Apple's pushing for the
  required default video codec to be the aforementioned nonfree MPEG4/H.264
  codec, and they don't seem to care whether it can be shipped by anybody
  else.
 
 Perhaps pedantry but for the sake of accuracy:
 
 Some of the patent holders in the MPEG-LA patent pool (Apple and
 Nokia) pushed hard for there to be no royalty-free baseline
 recommended in the standard. I'm not aware of anyone, Apple included,
 pushing for H.264 in the standard since the adoption of an encumbered
 format as formal formal default is simply a complete non-starter.

I'm sick of Apple and Nokia's bullcrap about OGG being encumbered and
constantly fighting against it.  I think it's a clear sign that OGG is
better and the they (Apple particularly) don't want people knowing that
they don't have to be locked into Apple's mini-monopoly.

So, after having given so much to Apple and Nokia (you can mount a very
sound argument that without OSS, Apple would be a backwater stuck with
OS9) why aren't we making noise about it being time that Apple and Nokia
give a little back.

I for one am sick of knowing we enabled them, but in a way that they
seem to feel it's fine to lock us out.


R.

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


Re: rawhide report: 20060309 changes

2006-03-09 Thread Rodd Clarkson
 gnome-applets-1:2.13.90-6
 -
 * Wed Mar 08 2006 Ray Strode rstr...@redhat.com - 2.13.90-6
 - improve package installation time by running gconftool-2 only
   once in %post
 
 * Wed Mar 08 2006 Matthias Clasen mcla...@redhat.com - 2.13.90-5
 - Fix a crash in the mixer applet (#184285, #182957)


Hmmm,

Lots of ...

Installed schema `/schemas/apps/cpufreq-applet/prefs/selector_mode' for locale 
`hi'
Installed schema `/schemas/apps/cpufreq-applet/prefs/selector_mode' for locale 
`pt'

and then ...

I/O warning : failed to load external entity 
/etc/gconf/schemas/divemount.schemas
Failed to open `/etc/gconf/schemas/divemount.schemas': No such file or directory
/var/tmp/rpm-tmp.87020: line 17: /etc/gconf/schemas/gtik.schemas: Permission 
denied
/var/tmp/rpm-tmp.87020: line 18: /etc/gconf/schemas/gweather.schemas: 
Permission denied
/var/tmp/rpm-tmp.87020: line 19: 
/etc/gconf/schemas/mini-commander-global.schemas: Permission denied
/var/tmp/rpm-tmp.87020: line 20: /etc/gconf/schemas/mini-commander.schemas: 
Permission denied
/var/tmp/rpm-tmp.87020: line 21: /etc/gconf/schemas/mixer.schemas: Permission 
denied/var/tmp/rpm-tmp.87020: line 22: /etc/gconf/schemas/modemlights.schemas: 
Permission denied
/var/tmp/rpm-tmp.87020: line 23: /etc/gconf/schemas/multiload.schemas: 
Permission denied
/var/tmp/rpm-tmp.87020: line 24: /etc/gconf/schemas/stickynotes.schemas: 
Permission denied


R.
-- 
It's a fine line between denial and faith.
 It's much better on my side