test April 2009

test@lists.fedoraproject.org

218 participants
451 discussions

Re: Fedora 11 Beta - Installation problem
by Gaurav Prabhu 07 Apr '09

07 Apr '09

It's not a case of damaged or improperly burnt CD, because the CD works well on my Dell Laptop. ________________ Website : http://www.gauravlive.com Fedora Ambassador : coolg5 --- On Tue, 7/4/09, Gianluca Sforna <giallu(a)gmail.com> wrote: >To me, sounds like a damaged cd support -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna -- fedora-test-list mailing list fedora-test-list(a)redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/

1 0

evdev run amuck?
by Tom Horsley 07 Apr '09

07 Apr '09

I was just looking through my X log file to see that the nvidia driver I installed from rpmfusion was actually being used, and I spotted this in the log: (II) config/hal: Adding input device UVC Camera (046d:08c9) (**) UVC Camera (046d:08c9): always reports core events (**) UVC Camera (046d:08c9): Device: "/dev/input/event11" (II) UVC Camera (046d:08c9): Found keys (II) UVC Camera (046d:08c9): Configuring as keyboard (II) XINPUT: Adding extended input device "UVC Camera (046d:08c9)" (type: KEYBOARD) I don't see no keyboard on my webcam :-). Has someone got an experimental image processor layer that looks for your hands in captured video frames and reads sign language?

2 2

Triage Day tomorrow @ 1600 UTC
by Adam Williamson 07 Apr '09

07 Apr '09

Quick reminder - tomorrow after the meeting is Triage Day as always, we had more new folks join the group this week and I alerted them to the day so hopefully some will show up and we can help them get started. Big thanks to iarly, john and matej for helping out Gireesh during last week's triage day! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

1 0

Fedora 11 Beta - Installation problem
by Gaurav Prabhu 07 Apr '09

07 Apr '09

Hello, I went about Installing Fedora 11 Beta, just a few minutes ago but was unable to boot from the Fedora 11 Beta KDE LIVE CD. After loading the vmlinuz & initrd0.img.... It gave the following error. ACPI : Denied BIOS AML access to invalid port 0x40+0x2 (ELCR) After waiting for a while the CD proceeded showing me the progress bars, but once the bar gets to full progress, the CD fails to go any further. I tried prefixing "noacpi" just after the rhgb quiet, but no use. I tried prefixing noacpi option to the boot line. It did not gave the above error but some other like; Buffer I/o error on device sr1, logical block 335331 Buffer I/O error,dev sr1, sector 1341492 [The messages continue with the end sector no changing] SQUASHFS error : Unable to read page, block 2868a66, size cab SQUASHFS error : Unable to read data cache entry [28686a66] SQUASHFS error : squashfs_read_data failed to read block 0x2866db9a SELinux : Could not load policy file /etc/selinux/targeted/policy/policy.24 : Bad address Unable to load SELinux policy(Bad address). Halting now. I even tried with nodma,selinux=0 but then after loading all the process the screen goes blank. Any solutions? Regards, Gaurav Prabhu Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

2 1

Kernel Builds Producing Corrupt RPMs On F-11 Beta
by Janina Sajka 06 Apr '09

06 Apr '09

We've been attempting to build kernels on our fully updated F-11 Beta installation (x86_64). The kernel builds, but produces a corrupt System.map. Thus we can't unpack/install. Anyone else seeing this? Should we file a bug? Janina -- Janina Sajka, Phone: +1.202.595.7777; sip:janina@CapitalAccessibility.Com Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina(a)a11y.org Linux Foundation http://a11y.org

1 0

installation issues
by Craig White 06 Apr '09

06 Apr '09

probably related to the fact that I'm trying to install on my Acer Aspire One (1024x600) I created a USB disk... mount -o loop \ Fedora-11-Beta-i386-DVD.iso /mnt/iso livecd-iso-to-disk --reset-mbr \ /mnt/iso/images/boot.iso /dev/sdb1 livecd-iso-to-disk \ Fedora-11-Beta-i386-DVD.iso /dev/sdb1 Then I booted it on the Aspire One using alternate boot, USB HDD It seems to come up with a text screen that's immediately replaced by a graphic screen that's blank and until I touch any key and what appears to be the grub screen scrolls up saying something like Press [TAB] to enter options. If I press the <Enter> key, I am given a box that says 'Password Required' - wtf? What am I doing wrong? Craig -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

6 10

python-libs segfault during setroubleshoot
by Allen Kistler 06 Apr '09

06 Apr '09

When I try to run setroubleshoot browser ("sealert -b"), it fails. Error messages in /var/log/messages report a segfault in libpython, as follows: Apr 5 23:24:15 localhost kernel: setroubleshootd[2964]: segfault at 95 ip 05f81ca2 sp bfacf980 error 4 in libpython2.6.so.1.0[5f01000+14f000] Apr 5 23:24:15 localhost setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.Spawn.ChildSignaled: Process /lib/dbus-1/dbus-daemon-launch-helper received signal 11 Apr 5 23:24:15 localhost setroubleshoot: [dbus.proxies.ERROR] Introspect error on :1.44:/org/fedoraproject/Setroubleshootd: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) Apr 5 23:24:15 localhost setroubleshoot: [dbus.ERROR] could not start dbus: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.44 was not provided by any .service files My test install is pretty vanilla from the i386 Beta DVD, then kept up to date from rawhide as of this posting. There's been a bug report filed by others (https://bugzilla.redhat.com/show_bug.cgi?id=492737) that seems to assert that the problem is fixed, but I still see it. Anyone else, or am I alone?

1 0

missing dependency kernel >= 2.6.29.1-52.fc11
by Robert P. J. Day 06 Apr '09

06 Apr '09

a small set of packages in this morning's update can't be updated, looking for that dependency. i'm assuming i can just give it a while and things will correct themselves? rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================

4 4

Reminder: Bug Triage Meeting Tomorrow (Tuesday) @ 15:00 UTC/11 AM EDT
by John Poelstra 06 Apr '09

06 Apr '09

Bug Triage Meeting irc.freenode.net #fedora-meeting Tuesday @ 15:00 UTC/11 AM EDT Agenda--Continue discussing improvements to the wiki as proposed by beland: 1) https://fedoraproject.org/wiki/User:Beland/How_to_Triage to replace https://fedoraproject.org/wiki/BugZappers/ How_to_Triage * adamw emailing fedora-test-list with draft email to fedora-devel-list with outstanding questions, including process for deciding which bugs to upstream * Should a check for bugs filed in upstream Bugzillas be mandatory? (conflicting opinions so far) * Should NEW triagers be asked to do NEEDINFO updates in 30 and 60 days if needed, or should this be left to triagers following the NEEDINFO checklist? (Beland doesn't, other people do) * We went over all sections up to 2.0.7 in the last meeting. Please review the remainder of the document before the meeting if you haven't already, and have comments ready. You can also e-mail comments now, and non-controversial improvements will get implemented sooner. * After these issues are decided, is this draft ready to go live? * Later improvements: o Add references to GreaseMonkey buttons in checklist instructions (adamw said he would do so) o Reorganize (poelcat proposes http://fpaste.org/paste/7456 ) 2) https://fedoraproject.org/wiki/User:Beland/Bugzilla_Legend * Consensus seems to be to try come up with unified definitions across both RHEL and Fedora. * adamw is sending email to fedora-devel-list (with draft to fedora-test-list) regarding this issue See you tomorrow, John

1 0

Draft for 'Bugzilla processes and procedures' mail to developers
by Adam Williamson 06 Apr '09

06 Apr '09

Hi, guys. As discussed in this morning's meeting, I'm sending a draft of a mail I propose to send to fedora-devel-list to ask for the opinions of the developer group on what we should do about Bugzilla policies and procedures. Does it look OK to everyone? Any suggestions to refine or improve it? Thanks! --------------------------------- Hi, -devel-list folks! We in the Bugzappers team (part of the QA group) are working to revise our Wiki space, and as part of that, various questions have arisen with regards to Bugzilla procedures. A lot of the same issues have come up on this list in the recent past. In general, it seems like Fedora doesn't really have a properly defined procedure for exactly how a bug should flow. Every maintainer, reporter and triager has a slightly different idea of what each status or resolution or keyword means, and when and by whom they should be applied. This is obviously confusing and problematic for any attempt to manage or monitor Fedora bugs in a systematic way. We should have a consistent procedure which works for reporters and developers and can be monitored and managed by the Bugzappers group. So, to arms! General bug flow ---------------- This section covers things like "what do all the statuses mean" and "what do all the resolutions mean" and "who changes what from what to what, and when". There is a very well-defined procedure for handling bugs in RHEL. The first proposal is that we simply use the same procedure (and hence the same statuses and resolutions) for Fedora. This has the advantage of giving us a well-defined and tested process which some maintainers will already be familiar with. The disadvantage of this is that the RHEL process is probably in some ways over-engineered for Fedora: it uses several stages managed by different teams which don't really exist so far as Fedora is concerned, and relies on certain automatic steps which aren't, AFAIK, actually automated for Fedora. The second proposal would be to adopt some kind of simplified version of the RHEL process, using a subset of the same statuses and resolutions, usually to mean the same thing RHEL uses, with a less complex procedure for getting all the way from file to fix. The third proposal would be just to come up with a process for Fedora from scratch, based probably on some kind of consensus around the current practices used by various groups. Specific issues --------------- So, that's the overview. To get down to some specific issues, here's the two big ones that have come up: 1) How to handle bugs that occur in multiple releases There's no obvious One Good Fix for this one, because Bugzilla just isn't designed to handle it. The two options most heavily discussed within Bugzappers so far have been: i) have reporters file separate bugs for each affected release that someone cares about ii) track all affected releases via one bug, using comments or keywords Myself and Vincent Danen tried to come up with a flag-based system for Mandriva to solve this problem once, but we couldn't really come up with something that would work better than issue ii) above. Personally I happen to prefer option i), but either can be made to work. The most important thing is to pick one option or the other and apply it consistently. This would mostly be the Bugzappers team's job, but maintainers obviously have to know the policy chosen and work with it, and Bugzappers don't want to try and just impose one choice or the other, we want to know what would be most comfortable for maintainers. 2) What do we do with the Severity and Priority fields At present these are pretty much roundly ignored by everyone (mostly on the basis that they're initially set by reporters, who don't follow any particular procedure, and so they don't convey any useful information). I personally favour a policy whereby the Bugzappers group would set these as a part of triage (their choices could be overridden later by the package maintainer or RelEng). Severity should indicate the importance of the issue *in the context of the package*, while Priority indicates the importance of the issue *in the context of the distribution as a whole*. So a crasher bug in a package only two people in the world ever use may be High severity but Low priority, while say a missing icon for Firefox might be Low severity but High priority. In my experience, if these fields are consistently set by triagers according to an agreed policy, they do convey valuable information to maintainers and maintainers (and RelEng) find them useful. Please, any feedback from active maintainers is most valuable - what I'm trying to do here is find out what those who use Bugzilla at the sharp end most need it to work like, to make their work most efficient. We in Bugzappers see our mission as helping reporters to file useful reports and maintainers to fix bugs as quickly and easily as possible, so we want to set our policy based on what will work best for reporters and maintainers. Thanks! ---------------------------- -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

4 8

← Newer
1
...
33
34
35
36
37
38
39
...
46
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test April 2009