Re: BZ 523646 - F13Blocker?
On Tue, Dec 29, 2009 at 15:38, Paul p...@all-the-johnsons.co.uk wrote: Hi, I originally reported this bug in September 2009 when f12 was rawhide. It was fixed but has recently resurfaced for both F12 and rawhide users leaving anyone with an intel chipset for video with unusable systems. Given that this kills quite a few laptop users, can this be escalated to F13Blocker? It is already listed as high for both priority and severity. I've not tried booting a live distro that is not a fedora one as to be honest, I'd rather not sully my machines! However, I've not heard of anyone using Ubuntu with the same kernel and xorg-x11-drv-intel version having the same problems. Thoughts folks? You're lucky to have X working slowly on your Intel card. It has been broken completely for me and others on all the 2.6.32 kernels in rawhide (but apparently not in the stock kernel) https://bugzilla.redhat.com/show_bug.cgi?id=542264 https://bugzilla.redhat.com/show_bug.cgi?id=546721 Given the Christmas season, I wasn't expecting any resolution until the new year. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: upstart-0.6.3 in rawhide, tomorrow 2009-12-10
On Thu, Dec 10, 2009 at 12:32, Bill Nottingham nott...@redhat.com wrote: Bill Nottingham (nott...@redhat.com) said: It's going to be a bit of a bumpy first yum upgrade. You will likely have to reboot with 'reboot -f', as the job formats have changed slightly, and the communication with init(8) has changed. Once you reboot, things should work pretty much the same. One notable change that was made is that we were able to simplify the jobs to the point where the number of login consoles is now configurable, without editing or removing upstart job definitions. This is done by the ACTIVE_CONSOLES parameter in /etc/sysconfig/init; the default value is /dev/tty/[1-6], which means that mingetty will be started on ttys 1 through 6. Shell globs are accepted. I updated from my machine from koji (yes, I know, even more insane than from rawhide) After plymouth there is no X and no consoles. Rebooting at runlevel 3 and doing a startx works. Rebooting at runlevel 3 and doing a telinit 5 works. https://bugzilla.redhat.com/show_bug.cgi?id=546721 (Filed against initscripts rather than upstart) darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 checksum file says it is SHA1 but it is SHA256
On Wed, Nov 18, 2009 at 11:27, Rahul Sundaram sunda...@fedoraproject.orgwrote: On 11/19/2009 12:54 AM, Stefan Grosse wrote: Hi, the file Fedora-12-i386-CHECKSUM which is on the mirrors and included in the torrents says: Hash: SHA1 f0ad929cd259957e160ea442eb80986b5f01daaffdbcc7e5a1840a666c4447c7 *Fedora-12-i386-DVD.iso But the truth is that it is SHA256. (I downloaded the DVD twice because of this...) So maybe someone could change that if I am right? It is a SHA256 and the CHECKSUM file is gpg signed. SHA1 in the top indicates the hash of the gpg key and not the checksum file. Perhaps it could be made more clear. I almost made the same double download mistake. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can't login to F11 - how to report bug?
On Tue, Sep 22, 2009 at 11:24, Andreas Tunek andreas.tu...@gmail.com wrote: On my other computer running F11 with GNOME and Compiz enabled I can't log in to GNOME any more. When GNOME tries to load I get the screen goes black and I am sent out to the GDM login screen. Any idea where the problem could be? I kind of suspect Compiz, but since I can't disable Compiz I don't know. And if I don't know I can't file a bug... Anyone have any ideas on how to proceed? You can log in to a text terminal and change from compiz to metacity. gconftool-2 --set /desktop/gnome/session/required_components/windowmanager --type string 'metacity' You could also take a look at the xorg log and the .xsession-errors file to see if they give you a hint. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing glibc 2.10.90-10 hosed my system last night
On Thu, Jul 30, 2009 at 15:42, Lennart Poetteringmzerq...@0pointer.de wrote: On Thu, 30.07.09 15:40, Adam Williamson (awill...@redhat.com) wrote: On Thu, 2009-07-30 at 23:00 +0200, Lennart Poettering wrote: On Thu, 30.07.09 21:25, Richard W.M. Jones (rjo...@redhat.com) wrote: On Thu, Jul 30, 2009 at 01:12:25PM +0200, nicolas.mail...@laposte.net wrote: but X / GNOME is still severely broken. GNOME has been broken in rawhide for a week now https://www.redhat.com/archives/fedora-devel-list/2009-July/msg01500.html It was pulseaudio BTW. Oh my. PA's not at fault here. PI mutexes are broken in the rawhide kernel/glibc. It's simply PA which triggers that. This would explain why I'm not seeing it - I'm still on kernel 2.6.30, as my wireless driver won't build with 2.6.31. This is supposed to be fixed now in glibc 2.10.90-10 and later. Yes, with glibc-2.10.90-11 libcanberra has stopped looping and gnome seems to have returned to normal. (kernel 2.6.31-0.94.rc4.fc12) darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090724 changes
2009/7/25 Nicolas Mailhot nicolas.mail...@laposte.net: Here anything that initialises GConfd causes every single GNOME app to start eating all the CPU it can while becoming unresponsive So rawhide is dead again. Can we switch to Fedora 13 at once? Fedora 12 cycle has not been lucky Yes, it is particularly bad at the moment. I backed out pretty much all of the changes for the day and it still remains broken. xsession-errors shows gnome-settings-manager failing to start but that's about it. Usually I will wander over to kde as a backup, but it is also failing to start. The workaround for me is: It is easier to use runlevel 3 and startx, because when it dies it is much easier to restart. Much of the looping seems to be canberra. You can kill it. Use compiz since it allows the lower ribbon bar to work. Don't touch anything that changes settings (so can't use volume control, etc) - GConf changed a day or so ealier so I haven't backed it out. Maybe it is an actual setting that changed, which would explain why backing things out didn't help me. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
gnome applications failing to start
In rawhide gnome applications are failing to start. type array 97 not a basic type D-Bus not built with -rdynamic so unable to print a backtrace It seems to be related to attempting to open a file. eog dies at startup but works when double-clicking a file. gedit just always dies. What component should get the bug report? darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnome applications failing to start
On Tue, Jul 14, 2009 at 14:49, darrell pfeiferdarrel...@gmail.com wrote: In rawhide gnome applications are failing to start. type array 97 not a basic type D-Bus not built with -rdynamic so unable to print a backtrace It seems to be related to attempting to open a file. eog dies at startup but works when double-clicking a file. gedit just always dies. gnome-settings-daemon 2.27.4-1.fc12 fixes the problem. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
inotify and gnome authorization
Over the last few months I've had problems with the gnome authorization dialog failing, sometimes intermittently and sometimes consistently for long periods of time. The dialog I'm referring to is the one that pops up when root access is needed to run an application or control panel. Examples are System/Preferences/Authorizations, running the virtual machine manager, running lots of control panels from System/Administration/* It turns out that eventually polkit-gnome-manager is called. It uses inotify to put a watch on /etc/PolicyKit/PolicyKit.conf. In my case, placing the watch was failing, which meant no authorization. A workaround is to bump up the 8192 limit to something higher echo 16384 /proc/sys/fs/inotify/max_user_watches I'm still a bit mystified as to what is using all the watches. Before and after the echo lsof only reports less than 32 watches on my system. Other than lsof there don't appear to be an tools to show who is consuming the watches. If nobody has an suggestions, I may try systemtap. I'm not sure at this point that it makes sense to bump up the kernel default without knowing the current culprit. The bottom line: with policykit being used more heavily in rawhide, if you're getting strange intermittent permissions failures, try the workaround. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
ck-list-sessions shows active = false
Using rawhide and gdm-2.26.1-13.fc12.i586 when I do a ck-list-sessions I see Session4: unix-user = '500' realname = 'darrell pfeifer' seat = 'Seat5' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-07-06T15:56:08.908744Z' login-session-id = '' Currently almost all my device-related functionality is not working (including pulseaudio, mounting usb sticks, starting virtual machines). In addition, polkit-gnome-authorization and polkit-gnome-authorization are crashing. Am I on the right track thinking that the problem is gdm related? darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X11 on intel (rawhide)
On Tue, Jun 23, 2009 at 14:12, Paul p...@all-the-johnsons.co.uk wrote: Hi, Following the last official rawhide update (21st was it?), my desktop has been hosed. I've updated to the latest xorg-server and intel drivers (plus a few others) as well as gdm and anything else I can think off. All updates have been pulled from koji between 4pm and 10.30pm (UK, GMT) All I'm now getting is gdm failing to start (it shows a box where the usernames are normally, but it's blank, then restarts X). When I look at the logs, I'm seeing the following at the bottom (xorg.0.log) Backtrace 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x80a3afb] 1: /usr/bin/Xorg [0x80a71b5] 2: [0xd09410] 3: /usr/lib/libdrm_intel.so.1 [0xe44750] 4: /usr/lib/libdrm_intol.so.1.(drm_intel_bufmgr_destroy+0xf)[0xe412bf] 5: /usr/lib/xorg/modules/drivers/intel_drv.so [0xf80132] 6: /usr/bin/Xorg [0x80fbdfe] 7: /usr/bin/Xorg [0x80c4cc5] 8: /usr/bin/Xorg [0x80b200c] 9: /usr/lib/xorg/modules/extensions/libextmod.so [0x1753a1] 10:/usr/bin/Xorg [0x816f1a2] 11:/usr/bin/Xorg [0x80e4bc0] 12:/usr/bin/Xorg [0x81a9459] 13:/usr/bin/Xorg [0x80e1fc2] 14:/usr/lib/xorg/modules/extensions/libglx.so [0x2792ba] 15:/usr/bin/Xorg [0x8063238] 16:/lib/libc.so.6 (__libc_start_main+0xe6) [0x8c0a66] 17:/usr/bin/Xorg [0x8062d91] Segmentation fault at address 0xfa4 Chipset 965GM Any ideas on what can be causing gdm/x to behave like this and more over, how do I fix it? I also have a 965GM. For the last six months the intel driver has been pretty flaky with it. My current working config is with 2.6.30-6.fc12.i686.PAE intel driver 2.7.0-6.fc12 xorg-x11-server-common-1.6.1.901-5.fc11.i586 (et al) libdrm-2.4.12-0.1.fc12.i586 (note that I have to boot with mem=3G on a 4 gig machine, running in 32 bit, not 64 bit) The newer 2.6.31 kernels work but show Jun 22 18:57:23 localhost kernel: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 (rant: why anyone would put debugging in a vertical blanking area i don't know, but it sure fills up the log quickly) The newer intel drivers past 2.7.0-6 don't work. Newer versions of xorg are also broken for me. Sometimes booting with nomodeset also helps, but again the recent versions have been painful for that. Things have been quite unstable for about six months for this chip, so don't expect anything to change quickly. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, Jun 3, 2009 at 06:46, Ralf Corsepius rc040...@freenet.de wrote: Michael Schwendt wrote: On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: I consider users (esp. bug reporters) not to be the dumb pigs eating the hog wash they get for free, or clueless comsumer masses aborbing anything they don't pay for with money, but them to be the foundation of your work and them to be valuable business partners, paying in immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. Well, whether it's idealistic or not is irrelevant. It's one of the foundations of open source. Or less abstract: I stopped reporting bugs against Fedora's evolution, because its @RH maintainer preferred to close bugs and tried to push me around to upstream. Wrt. evolution, I was an ordinary user and am not interested in getting further involved. As simple as it is: I felt sufficiently pissed of by this guy to leave him and his upstream alone, ... so be it, he wanted it this way. There are other packages and packagers (noteworthy many of the @RH) who exhibit the same push reporters around behavior. So is still anybody wondering why Fedora is permanently lacking people? This is one cause. Now combine this with the report bugs phrases certain people tend to reiterate? ... Experiences, such as the one I encountered with the evolution maintainer, are the cause why at least some people sense a foul taste when listening to them. As a bug reported I've come to peace with the concept that maintainers and upstream have personalities too. Sometimes people are happy to see bug reports, sometimes they ignore them and sometimes they seem to go out of their way to be unhelpful. For the same reason it can be difficult to report bugs since different packages can have wide variations in the amount of information they want you to collect, and strange incantations and commands you've never seen before. (Often of the gee I never knew that was even possible variety). The ones that get to me are 1) Bugs return over and over again with each new latest and greatest version or rewrite of previously working code. A few years ago it was USB devices that would mount one day on the desktop, then not mount, then mount, etc. Today it might be screen display powers off (or doesn't), battery level is correct (or reports battery-critical), sound works (or doesn't), compiz works (or doesn't), boot with graphic boot (or nomodeset yet again). 2) Bugs that get no attention, not even an acknowledgement. 3) Bugs where the maintainer (or triager) seems to go out of their way to be completely unhelpful. I think it is easy to forget how difficult and time-consuming it can be to produce a really good bug report. I'd say that 9 out of 10 bugs that I report leave me feeling that the not much was accomplished. It is that tenth bug report, the one where there is a reasonable interaction, where a problem gets resolved (and doesn't seem to reappear) that keeps me doing them. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
The joys of rawhide returning to form
For the last couple of weeks as rawhide settled into FC5 I had a completely working system. Now that the freeze has been lifted for a couple of days I yum updated this morning. Printing broke. There was a cups update. I think I saw a scriptlet fail. There appears to be no default printer. Using the control panel to remove the current (USB) printer and remake a new one doesn't help. Test printing fails. X broke There was an X server update. I have an ATI Radeon R300 so am involved in the DRI fray. In previous versions commenting out the load of the DRI module worked but in the new version DRI looks like it is still attempted and I get the black screen of death. Reverted to the X server rpm off the FC5 cd. ipw2200 broke There was a kernel upgrade (2074) and now the driver won't load. Booted the 2064 kernel which continues to work. So that was no X, no wireless and no printing. Eeeks. I'll try to file some bug reports when I get a chance. darrell
