Re: [Test-Announce] Fedora 16 Final Test Compose 1 (TC1) Available Now!
On Fri, 2011-10-14 at 19:40 -0300, Itamar Reis Peixoto wrote: > I am not able to see the x86-64 iso. >From the announce: "*NOTE*: The x86_64 install images are currently missing due to trouble making efiboot.img. Hopefully they will be added later." -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Fedora 16 Final Test Compose 1 (TC1) Available Now!
On Fri, Oct 14, 2011 at 7:34 PM, Andre Robatino wrote: > As per the Fedora 16 schedule [1], Fedora 16 Final Test Compose 1 (TC1) > is now available for testing. Please see the following pages for > download links (including delta ISOs) and testing instructions. > Serverbeach1 is still available as a mirror (but with approximately a 1 > hour lag behind dl), so if you are getting a slow download, try > replacing "dl" with "serverbeach1" in the download URL. > > *NOTE*: The x86_64 install images are currently missing due to trouble > making efiboot.img. Hopefully they will be added later. > > Installation: > > https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test > > Base: > > https://fedoraproject.org/wiki/Test_Results:Current_Base_Test > > Desktop: > > https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test > > Security Lab: > > https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test > > Ideally, all Alpha, Beta, and Final priority test cases for Installation > [2], Base [3], Desktop [4], and Security Lab [5] should pass in order to > meet the Final Release Criteria [6]. Help is available on #fedora-qa on > irc.freenode.net [7], or on the test list [8]. > > Create Fedora 16 Final test compose (TC) - live and traditional > https://fedorahosted.org/rel-eng/ticket/4951 > > F16 Final Blocker tracker bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713568 > > F16 Final Nice-To-Have tracker bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713566 > > [1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html > [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing > [3] https://fedoraproject.org/wiki/QA:Base_validation_testing > [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing > [5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing > [6] https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria > [7] irc://irc.freenode.net/fedora-qa > [8] https://admin.fedoraproject.org/mailman/listinfo/test > > > ___ > test-announce mailing list > test-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/test-announce > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test > I am not able to see the x86-64 iso. -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Fedora 16 Final Test Compose 1 (TC1) Available Now!
As per the Fedora 16 schedule [1], Fedora 16 Final Test Compose 1 (TC1) is now available for testing. Please see the following pages for download links (including delta ISOs) and testing instructions. Serverbeach1 is still available as a mirror (but with approximately a 1 hour lag behind dl), so if you are getting a slow download, try replacing "dl" with "serverbeach1" in the download URL. *NOTE*: The x86_64 install images are currently missing due to trouble making efiboot.img. Hopefully they will be added later. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Security Lab: https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test Ideally, all Alpha, Beta, and Final priority test cases for Installation [2], Base [3], Desktop [4], and Security Lab [5] should pass in order to meet the Final Release Criteria [6]. Help is available on #fedora-qa on irc.freenode.net [7], or on the test list [8]. Create Fedora 16 Final test compose (TC) - live and traditional https://fedorahosted.org/rel-eng/ticket/4951 F16 Final Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713568 F16 Final Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713566 [1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing [6] https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria [7] irc://irc.freenode.net/fedora-qa [8] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criteria: virtualization tweak
On Fri, 2011-10-14 at 16:02 -0600, Eric Blake wrote: > On 10/14/2011 03:48 PM, Adam Williamson wrote: > > Thanks again for this suggestion, Albert. Following this discussion I > > went ahead and amended the Beta criteria to: > > > > The release must be able host virtual guest instances of the same > > release, using Fedora's current preferred virtualization technology > > What happens if we have multiple supported virt technology (that is, > suppose F17 supports both xen dom0 and kvm out of the box) - should the > be worded to cover all supported virt tech, or is it limited to just one > technology (and if so, which)? 'Preferred' is distinct from 'supported'. KVM is the current preferred virt technology for Fedora. That's the tech the criterion currently refers to. This is why we wrote a separate criterion for Xen. > > > > The release must install and boot successfully as a virtual guest in a > > situation where the virtual host is running the previous stable Fedora > > release, using Fedora's current preferred virtualization technology > > That's confusing, as the preferred virtualization technology may have > changed between releases. > > For arguments sake, we know F16 prefers kvm, and let's suppose F17 goes > back to xen as default. Does that mean F17 has to boot successfully as > a guest in an F16 xen situation, or that F17 has to boot successfully > both as a xen guest of F17 and as a kvm guest of F16? > > Given both those points, I suggest we alter the wording to something > like this: > > The release must be able host virtual guest instances of the same > release, using each of Fedora's current preferred virtualization > technologies. I think you wanted to say 'supported' there, because we don't _have_ multiple preferred technologies. > The release must install and boot successfully as a virtual guest in a > situation where the virtual host is running the previous stable Fedora > release, using each of the preferred virtualization technologies of that > prior release. It's interesting, but I'm not sure it's quite what we want, because we didn't really write this criterion to cover all the virt technologies we to some extent support: it's specifically supposed to be about the _one_ virt technology Fedora prefers and recommends at any given time, viz, currently, KVM. We've added Xen to the criteria mostly on the grounds of its important for cloud services, it's a somewhat different case, and I think it makes sense in that context to give it a separate criterion, as we have. I'd be welcome to any patch which simply addresses the problem of the preferred technology changing between releases, though, that is indeed a weak point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criteria: virtualization tweak
On 10/14/2011 03:48 PM, Adam Williamson wrote: > Thanks again for this suggestion, Albert. Following this discussion I > went ahead and amended the Beta criteria to: > > The release must be able host virtual guest instances of the same > release, using Fedora's current preferred virtualization technology What happens if we have multiple supported virt technology (that is, suppose F17 supports both xen dom0 and kvm out of the box) - should the be worded to cover all supported virt tech, or is it limited to just one technology (and if so, which)? > > The release must install and boot successfully as a virtual guest in a > situation where the virtual host is running the previous stable Fedora > release, using Fedora's current preferred virtualization technology That's confusing, as the preferred virtualization technology may have changed between releases. For arguments sake, we know F16 prefers kvm, and let's suppose F17 goes back to xen as default. Does that mean F17 has to boot successfully as a guest in an F16 xen situation, or that F17 has to boot successfully both as a xen guest of F17 and as a kvm guest of F16? Given both those points, I suggest we alter the wording to something like this: The release must be able host virtual guest instances of the same release, using each of Fedora's current preferred virtualization technologies. The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release, using each of the preferred virtualization technologies of that prior release. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criteria: virtualization tweak
Thank you adam - Original Message - From: "Adam Williamson" To: agra...@g-b.net Cc: pjo...@redhat.com, "For testing and quality assurance of Fedora releases" Sent: Friday, October 14, 2011 3:48:29 PM Subject: Re: Release criteria: virtualization tweak On Thu, 2011-09-08 at 19:19 +0100, agraham wrote: > On 09/08/2011 02:20 AM, Adam Williamson wrote: > > Hey, all. pjones pointed out at a recent blocker review meeting that the > > Beta virt criterion: > > > > "The release must boot successfully as a virtual guest in a situation > > where the virtual host is running the same release (using Fedora's > > current preferred virtualization technology)" > > > > doesn't really imply that virtual host functionality must work; only > > that _if_ virtual host functionality is working, then virtual guest > > functionality must work. This was not really our intent with the > > criterion, we intended to require both to work at Beta stage. So here's > > a proposed improvement: > > > > "The release must be able to self-host using Fedora's current preferred > > virtualization technology: that is, the release must be able to act as a > > virtual host, and must also successfully install and boot as a virtual > > guest when running on a host which is also running the release" > > > > I'm still not super happy with the wording, but I guess it's clearer. > > Any better ideas? > > Suggestions: > > A Fedora release must be able host virtual guest instances of the same > Fedora release. Thanks again for this suggestion, Albert. Following this discussion I went ahead and amended the Beta criteria to: The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release, using Fedora's current preferred virtualization technology This should cover all the situations it's intended to cover. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criteria: virtualization tweak
On Thu, 2011-09-08 at 19:19 +0100, agraham wrote: > On 09/08/2011 02:20 AM, Adam Williamson wrote: > > Hey, all. pjones pointed out at a recent blocker review meeting that the > > Beta virt criterion: > > > > "The release must boot successfully as a virtual guest in a situation > > where the virtual host is running the same release (using Fedora's > > current preferred virtualization technology)" > > > > doesn't really imply that virtual host functionality must work; only > > that _if_ virtual host functionality is working, then virtual guest > > functionality must work. This was not really our intent with the > > criterion, we intended to require both to work at Beta stage. So here's > > a proposed improvement: > > > > "The release must be able to self-host using Fedora's current preferred > > virtualization technology: that is, the release must be able to act as a > > virtual host, and must also successfully install and boot as a virtual > > guest when running on a host which is also running the release" > > > > I'm still not super happy with the wording, but I guess it's clearer. > > Any better ideas? > > Suggestions: > > A Fedora release must be able host virtual guest instances of the same > Fedora release. Thanks again for this suggestion, Albert. Following this discussion I went ahead and amended the Beta criteria to: The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release, using Fedora's current preferred virtualization technology This should cover all the situations it's intended to cover. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criteria proposal: i18n criteria
On Wed, 2011-10-12 at 12:44 -0700, Adam Williamson wrote: > During Final blocker review meetings, we've come up against a couple of > bugsto do with missing translations that we'd like to consider for Final > blocker status: > > https://bugzilla.redhat.com/show_bug.cgi?id=706756 > https://bugzilla.redhat.com/show_bug.cgi?id=676488 > > however we don't currently actually have any criteria that cover i18n > (translation) issues. We should probably require some basic level of > translation to be in place for particularly popular languages. How about > a Final criterion, something like: > > * The installer, bootup and login processes should correctly display all > translations that are available for use > > the intent is that where the translation team has actually provided > translations of this key content, they should be displayed, but we're > not going to block on no translations being available for some language > or another. Taking into consideration the list feedback, and some issues that came up at the meeting, we agreed to accept this substantially modified text during the blocker review meeting today: "All critical path actions on release-blocking desktop environments should correctly display all sufficiently complete translations available for use" this covers updating, and re-uses the existing critpath definition so we're not re-inventing it. 'critical path actions' will be a link to the critpath wiki page. I'll add this to the Final criteria shortly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release Criteria Proposal: Xen DomU
On Thu, 2011-10-13 at 13:24 -0600, Tim Flink wrote: > On Thu, 13 Oct 2011 13:18:39 -0600 > Tim Flink wrote: > > > My intention was to include issues with DomU running locally (with an > > already functional Fedora Dom0) or on a Xen based cloud provider. My > > implicit assumption was that Dom0 would already be working but since > > F16 is the first supported Dom0 since F8, that could be problematic. > > For F17 and later, I imagine that we could just say that it needs to > > run with a previous release as Dom0. > > How about: > - The release must boot successfully as Xen DomU with releases > providing a functional, supported Xen Dom0 and cloud providers > utilizing Xen. This does not include any issues limited to the > release functioning as Xen Dom0. At today's blocker review meeting, taking into account all the feedback from this thread and the devel list thread, we accepted the following text as a Final release criterion: "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0" I will add it to the 16 and 17 pages shortly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 Final Blocker Bug Review #3 Minutes
== #fedora-bugzappers: f16-final-blocker-review-3 == Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-10-14/f16-final-blocker-review-3.2011-10-14-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2011-10-14/f16-final-blocker-review-3.2011-10-14-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-10-14/f16-final-blocker-review-3.2011-10-14-17.00.log.html Meeting summary --- * roll call (tflink, 17:01:24) * introduction (tflink, 17:05:36) * Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. (tflink, 17:05:45) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers (tflink, 17:06:13) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (tflink, 17:06:42) * 10 proposed blockers (tflink, 17:07:06) * 4 proposed NTH (tflink, 17:07:14) * 14 accepted blockers (tflink, 17:07:22) * i18n criteria for Fedora 16 Final (tflink, 17:11:22) * proposed criterion: The installer, bootup and login processes should correctly display all translations that are available for use (tflink, 17:14:34) * LINK: http://lists.fedoraproject.org/pipermail/test/2011-October/103588.html (tflink, 17:14:42) * AGREED: - "The installer, bootup and login processes should correctly display all sufficiently complete translations available for use" is accepted as a release criterion for Fedora 16 Final (tflink, 17:19:24) * Xen Criterion for Fedora 16 Final (tflink, 17:19:41) * proposed criterion: The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0. (tflink, 17:20:16) * LINK: http://lists.fedoraproject.org/pipermail/test/2011-October/103624.html (tflink, 17:20:29) * AGREED: - "The release must boot successfully as Xen DomU with releases providing a functional, supported Xen Dom0 and widely used cloud providers utilizing Xen. This does not include any issues limited to the release functioning as Xen Dom0." is accepted as a release criterion for Fedora 16 Final (tflink, 17:23:53) * (706756) No translation on Login-Page of the reboot-menu (tflink, 17:25:43) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=706756 (tflink, 17:25:44) * Proposed Blocker, NEW (tflink, 17:25:44) * AGREED: - 706756 - AcceptedBlocker - The installer, bootup and login processes should correctly display all sufficiently complete translations available for use. (tflink, 17:27:42) * (737508) grub2 cannot install when /boot is md and first partition starts at sector 63 (tflink, 17:27:51) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=737508 (tflink, 17:27:54) * Proposed Blocker, NEW (tflink, 17:27:56) * AGREED: - 737508 - We need input from the anaconda team to decide on blocker status, will ask for input and revisit next week (tflink, 17:35:20) * (742226) /sbin/grub2-probe: error: cannot find a GRUB drive for /dev/mapper/nvidia_cjfffajep2 (tflink, 17:35:36) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=742226 (tflink, 17:35:40) * Proposed Blocker, NEW (tflink, 17:35:42) * AGREED: - 742226 - AcceptedBlocker - The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above (tflink, 17:40:45) * (743273) grub2 fails to install on IMSM raid device (tflink, 17:40:59) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=743273 (tflink, 17:40:59) * Proposed Blocker, NEW (tflink, 17:40:59) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=744054 (adamw, 17:43:59) * AGREED: - 743273 - Duplicate of 744054 (tflink, 17:51:05) * (744054) Cannot install to MBR of an Intel BIOS RAID-0 array (Sony Vaio Z stock layout) (tflink, 17:51:17) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=744054 (tflink, 17:51:20) * Proposed Blocker, NEW (tflink, 17:51:22) * AGREED: - 744054 - Still need more information on this, hopefully some dev input, will revisit next week (tflink, 17:51:52) * (745246) Need automatic conversion from grub1 to grub2 for all possible cases (tflink, 17:52:01) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=745246 (tflink, 17:52:04) * Proposed Blocker, NEW (tflink, 17:52:06) * AGREED: - 745246 - RejectedBlocker - There are already release criteria that cover grub upgrades and yum is not a supported upgrade method (tflink, 17:55:10) * (676488) updat
Re: Hello World!
Not sure if I recognize the nick from IRC, but welcome - Original Message - From: "Nicolas Corrarello" To: test@lists.fedoraproject.org Sent: Friday, October 14, 2011 12:39:19 PM Subject: Hello World! Hey, Some of you have probably seen me on IRC right now, I want to help in the Fedora Bug Zappers Team. I have working with Fedora and Red Hat Linux for years, and, as most of us, I want to give something back. I've a lot of experience as a SysAdmin (right now I'm working as a Solution Architect). My name is Nicolas, I'm 26 years old and live at Buenos Aires, Argentina. I started with Linux 12 years ago... and I have been around it ever since. Feel free to contact me with anything, I'll do my best to help. IRC: sgtpepper (in irc.freenode.net) GTalk: ncorrare at gmail dot com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Hello World!
Hey, Some of you have probably seen me on IRC right now, I want to help in the Fedora Bug Zappers Team. I have working with Fedora and Red Hat Linux for years, and, as most of us, I want to give something back. I've a lot of experience as a SysAdmin (right now I'm working as a Solution Architect). My name is Nicolas, I'm 26 years old and live at Buenos Aires, Argentina. I started with Linux 12 years ago... and I have been around it ever since. Feel free to contact me with anything, I'll do my best to help. IRC: sgtpepper (in irc.freenode.net) GTalk: ncorrare at gmail dot com signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dbus-daemon logging
On Fri, 14 Oct 2011 12:24:22 -0500 Bruno Wolff III wrote: > Is the level of dbus-daemon logging scheduled to be cut back soon? > Currently there is still a large amount of logging going on and it is > getting close to final freeze. Yea, I see vast amounts of messages with DEBUG in them talking about things like backlight power management (and I'm not on a laptop :-). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Hello world!
Hey, Some of you have probably seen me on IRC right now, I want to help in the Fedora Bug Zappers Team. I have working with Fedora and Red Hat Linux for years, and, as most of us, I want to give something back. I've a lot of experience as a SysAdmin (right now I'm working as a Solution Architect). My name is Nicolas, I'm 26 years old and live at Buenos Aires, Argentina. I started with Linux 12 years ago... and I have been around it ever since. Feel free to contact me with anything, I'll do my best to help. IRC: sgtpepper (in irc.freenode.net) GTalk: ncorrare at gmail dot com signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
dbus-daemon logging
Is the level of dbus-daemon logging scheduled to be cut back soon? Currently there is still a large amount of logging going on and it is getting close to final freeze. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum / grub[2] problem ?
On 10/14/2011 12:26 PM, Dave Jones wrote: > With todays f16 yum update, first I saw this.. > > ERROR with transaction check vs depsolve: > grub2 conflicts with (installed) grub-1:0.97-80.fc16.x86_64 > > Which I got around by doing --exclude=grub2 > When everything else had updated, I did another yum update. > This is what it did.. > > $ sudo yum -y update --skip-broken > Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package grub.x86_64 1:0.97-82.fc16 will be obsoleted > ---> Package grub2.x86_64 1:1.99-9.fc16 will be obsoleting > --> Processing Dependency: os-prober for package: 1:grub2-1.99-9.fc16.x86_64 > --> Running transaction check > ---> Package os-prober.x86_64 0:1.48-1.fc16 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > > Package Arch > Version Repository >Size > > Installing: > grub2 x86_64 > 1:1.99-9.fc16 updates-testing > 1.2 M > replacing grub.x86_64 1:0.97-82.fc16 > Installing for dependencies: > os-prober x86_64 > 1.48-1.fc16 fedora >30 k > > Transaction Summary > > Install 2 Packages > > Total size: 1.2 M > Total download size: 30 k > Downloading Packages: > Running Transaction Check > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Installing : os-prober-1.48-1.fc16.x86_64 > > 1/2 > Installing : 1:grub2-1.99-9.fc16.x86_64 > > 2/2 > 1:grub-0.97-82.fc16.x86_64 was supposed to be removed but is not! > > Installed: > grub2.x86_64 1:1.99-9.fc16 > > > > Dependency Installed: > os-prober.x86_64 0:1.48-1.fc16 > > > > Failed: > grub.x86_64 1:0.97-82.fc16 > > > > Complete! > > > So now I have grub, and grub2 installed. I guess this isn't intended ? > Should I rpm -e grub ? Should just have grub2 and not grub - looks like a yum or rpm problem? > Additionally, I have a 0 byte /boot/grub2/grub.cfg, so grub2-mkconfig > isn't getting run during an update. Should it be ? Yum updates are something I intent to look and see if there's anything we can do to make them work, but right now there are a lot of things that are higher priority. It might be possible to do something with rpm triggers to fix the yum update case; I'm not sure yet. > Or is the plan for yum update'd systems to continue using grub1 ? You know all those times in the past when we (the anaconda group) have said that there are just some things yum upgrade can't get right? Just sayin'. -- Peter -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum / grub[2] problem ?
On Fri, 2011-10-14 at 12:26 -0400, Dave Jones wrote: > With todays f16 yum update, first I saw this.. > > ERROR with transaction check vs depsolve: > grub2 conflicts with (installed) grub-1:0.97-80.fc16.x86_64 > > Which I got around by doing --exclude=grub2 > When everything else had updated, I did another yum update. > This is what it did.. Looks like your mirror has grub -82, which is one of the bad builds (-81 and -82 got the phrasing of the Obsoletes: statement for grub-efi wrong). The 'working' builds (so far as we know) are grub2 1.99-9 and grub 0.97-83: if your mirror doesn't have those, wait till you do, or set up a side repo. > So now I have grub, and grub2 installed. I guess this isn't intended ? > Should I rpm -e grub ? What we 'intend' to happen is for you to wind up with both grub-efi and grub2 installed, but in fact you only need one or the other - grub2 if you boot BIOS, grub-efi if you boot EFI. > Additionally, I have a 0 byte /boot/grub2/grub.cfg, so grub2-mkconfig > isn't getting run during an update. Should it be ? That's not implemented yet. Spot filed a report requesting it, pjones says he will look at it soon: https://bugzilla.redhat.com/show_bug.cgi?id=745246 > Or is the plan for yum update'd systems to continue using grub1 ? For now this is what should happen - even with the grub *package* removed, grub will be installed in the MBR (or boot sector) until you overwrite it and grub's config will be present in /boot, so grub will continue to work. You can manually migrate to grub2 any time you choose by doing grub2-mkconfig -o /boot/grub2/grub.cfg then grub2-install /dev/foo . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
yum / grub[2] problem ?
With todays f16 yum update, first I saw this.. ERROR with transaction check vs depsolve: grub2 conflicts with (installed) grub-1:0.97-80.fc16.x86_64 Which I got around by doing --exclude=grub2 When everything else had updated, I did another yum update. This is what it did.. $ sudo yum -y update --skip-broken Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package grub.x86_64 1:0.97-82.fc16 will be obsoleted ---> Package grub2.x86_64 1:1.99-9.fc16 will be obsoleting --> Processing Dependency: os-prober for package: 1:grub2-1.99-9.fc16.x86_64 --> Running transaction check ---> Package os-prober.x86_64 0:1.48-1.fc16 will be installed --> Finished Dependency Resolution Dependencies Resolved Package Arch Version Repository Size Installing: grub2 x86_64 1:1.99-9.fc16 updates-testing 1.2 M replacing grub.x86_64 1:0.97-82.fc16 Installing for dependencies: os-prober x86_64 1.48-1.fc16 fedora 30 k Transaction Summary Install 2 Packages Total size: 1.2 M Total download size: 30 k Downloading Packages: Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Installing : os-prober-1.48-1.fc16.x86_64 1/2 Installing : 1:grub2-1.99-9.fc16.x86_64 2/2 1:grub-0.97-82.fc16.x86_64 was supposed to be removed but is not! Installed: grub2.x86_64 1:1.99-9.fc16 Dependency Installed: os-prober.x86_64 0:1.48-1.fc16 Failed: grub.x86_64 1:0.97-82.fc16 Complete! So now I have grub, and grub2 installed. I guess this isn't intended ? Should I rpm -e grub ? Additionally, I have a 0 byte /boot/grub2/grub.cfg, so grub2-mkconfig isn't getting run during an update. Should it be ? Or is the plan for yum update'd systems to continue using grub1 ? Dave -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /etc/default/grub is supposed to be where I put changes, right?
On Fri, 2011-10-14 at 10:14 +0200, Matej Cepl wrote: > Dne 14.10.2011 01:45, Tom Horsley napsal(a): > > Every time I get a new grub2 update, it resets the > > /etc/default/grub file, wiping out all my customizations, > > Why in the world it is /etc/default (which is coming from the Debian > world) and not /etc/sysconfig? Maybe that way it'll escape Lennart's notice? =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any nouveau refresh in f16 beta?
On Fri, 2011-10-14 at 14:30 +0200, Gianluca Cecchi wrote: > On Wed Oct 12 01:30:57 UTC 2011 Adam Williamson wrote: > > There's nothing really interesting in the xorg-x11-drv package any more. > > All the interesting bits are in the kernel module, which gets updated > > very frequently. > > Ok. > So the link I gave: > http://nouveau.git.sourceforge.net/git/gitweb.cgi?p=nouveau/envytools;a=commitdiff;h=b645e6f7d9f204a9176747f129e9e365dcd877ce > is somethng about kernel part of nouveau? envytools isn't actually part of the driver, it's a set of little tools which can help in driver development, sometimes - basically ways to get information out of cards that can help the devs. See the README file in the envytools dir. > In this case how can I know if there should be any support for NVD9 > (GT520 on a laptop... GF119 chipset) in my current kernel in F15 ( > 2.6.40.6-0.fc15.x86_64) or current kernel available in F16? > Any modinfo switch ? Or should I download source.rpm? I'd say the easiest thing is just to get one of those kernels and try. I think the F16 kernel may have a shot. > rpm -q --changelog against 2.6.40.6-0.fc15.x86_64 gives only: > > * Thu Aug 25 2011 Ben Skeggs > - nouveau: add patch fixing ttm issues that lead to oopses/corruption > (rhbz#699551) > > * Tue Aug 23 2011 Ben Skeggs > - nouveau: pull patches from 3.1 to fix some suspend/hibernate > problems (rhbz#730582) Yeah - most of the changes happen upstream and simply get pulled downstream into the Fedora kernel builds, so you won't find the info in the Fedora kernel package changelogs but in the upstream kernel changelogs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
SOLVED Re: F16 grub2 prompt, help needed
On 14/10/11 12:11, Michael Schwendt wrote: > > Running grub2-mkconfig without options does only print the config file > to standard output. You would need > >grub2-mkconfig -o /boot/grub2/grub.cfg > > to actually overwrite your GRUB 2 config file. Thanks Michael, That was it, > >> grub2-install /dev/vda >> no errors reported. >> >> rebooted got: >> grub> > > A working command-line? If so, you could use GRUB's commands to search > for and load the grub.cfg file manually, then boot it. Never liked command-line, outside of X, Need my security blanket. Used an iso to do a rescue boot, then fixed config from within X. -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20111014 changes
Compose started at Fri Oct 14 08:16:10 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46 389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46 389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46 389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46 389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicudata.so.46()(64bit) aeolus-all-0.4.0-1.fc17.noarch requires rubygem(aeolus-cli) aeolus-all-0.4.0-1.fc17.noarch requires imagefactory-jeosconf-ec2-rhel aeolus-all-0.4.0-1.fc17.noarch requires imagefactory-jeosconf-ec2-fedora aeolus-conductor-0.4.0-1.fc17.noarch requires rubygem(oauth) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) darcs-2.5.2-6.fc17.x86_64 requires libHShashed-storage-0.5.8-ghc7.0.4.so()(64bit) darcs-2.5.2-6.fc17.x86_64 requires ghc(hashed-storage-0.5.8) = 0:e1882773781422b999d06ce926333663 dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_imgproc.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_highgui.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_flann.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_features2d.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_core.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_contrib.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_calib3d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-firevision-0.4.2-4.fc16.i68
Re: openSUSE announces release of openqa
On Thu, Oct 13, 2011 at 2:35 PM, Adam Williamson wrote: > On Thu, 2011-10-13 at 08:35 -0400, Neal Becker wrote: >> http://news.opensuse.org/2011/10/11/opensuse-announces-first-public-release-of- >> openqa/ > > saw it! > > in fact, we've talked to one of the lead developers before. > > it's got some cool design features, a reasonably nice results interface, > and it's somewhat more mature than AutoQA at present: these are good > points about it. > > it relies on screenshot validation for pass/fail and it's written in > freakin' perl: these are bad points about it. =) Well, we have developed a system to do some part of the KVM VM based tests that is also based on screenshot validation, and it's written in python, so it does pretty much what OpenQA does. And it was developed on top of autotest, the same system where AutoQA is developed. Now, I also don't like the screenshot validation thing. It is fragile, and it has sort of a maintenance burden. Yet it'd be interesting to look at our py based infra as well as looking into OpenQA. I am not in favor of NIH syndrome, but at least let's consider both systems carefully :) I've given a brief look, and it indeed has some really nice features, I specially like the video output generation. I remember the anaconda developers had made a test suite for anaconda, also, at some point it was also discussed implementing anaconda using a MVC pattern approach, which means the interactions with anaconda UI could be recorded and replayed, at least in theory. But well, let's focus on what already exists and works. -- Lucas -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Working hard to lock myself out of my system
On 10/14/2011 01:51 AM, Frederic Muller wrote: > On 10/13/2011 04:03 PM, Erinn Looney-Triggs wrote: >> So I go in with my fingerprint to see what is happening, and I run a >> sudo command (really slick the fingerprint auth with sudo, kudos), >> trouble is it tells me I am not in the sudoers file. Well that is odd it >> used to work. My sudoers is based off of group membership, a member in >> wheel gets sudo access if not then no. > So this might give you an insight: I just did an install from RC4 and my > user was in the sudo group. Then a yum update and tada: no more. I mean > using sudo just tells me my user is not in the sudo group. > > Among the changes between RC4 and yum update until today I saw the power > off menu disappearing again (I am very sad about that one, I thought we > understand users wanted it badly) and online accounts time out was fixed > (couldn't get the google page from RC4, can now). > > I'll check if there is a bug filed for the sudo group thingy and for the > power off option... well we all know about it so I will just pray while > burning 2/3 Windows installed PCs as a worthy sacrifice ;-) > > Fred Yeah it looks like the group issue is here: https://bugzilla.redhat.com/show_bug.cgi?id=745675 stems from the glibc update. It all just came together at a funny time. Bummer about the power off icon, mine continues to show up. -Erinn -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any nouveau refresh in f16 beta?
On Fri Oct 14 12:48:32 UTC 2011 drago01 wrote: > > So the link I gave: > > http://nouveau.git.sourceforge.net/git/gitweb.cgi?p=nouveau/envytools;a=commitdiff;h=b645e6f7d9f204a9176747f129e9e365dcd877ce > > is somethng about kernel part of nouveau? > > No this is completely unrelated. Ok. I see only now that I missed the envytools part of the link path So the added support is about these tools only and not the driver itself... sorry At http://nouveau.freedesktop.org/wiki/CodeNames my card NVD9 (GF119) appears inside the section: "Not all of these cards already work well using Nouveau, development is in progress" So I'll keep up checking if there is improved support in the near future. Thanks, Gianluca -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any nouveau refresh in f16 beta?
On Fri, Oct 14, 2011 at 2:30 PM, Gianluca Cecchi wrote: > On Wed Oct 12 01:30:57 UTC 2011 Adam Williamson wrote: >> There's nothing really interesting in the xorg-x11-drv package any more. >> All the interesting bits are in the kernel module, which gets updated >> very frequently. > > Ok. > So the link I gave: > http://nouveau.git.sourceforge.net/git/gitweb.cgi?p=nouveau/envytools;a=commitdiff;h=b645e6f7d9f204a9176747f129e9e365dcd877ce > is somethng about kernel part of nouveau? No this is completely unrelated. > In this case how can I know if there should be any support for NVD9 > (GT520 on a laptop... GF119 chipset) in my current kernel in F15 ( > 2.6.40.6-0.fc15.x86_64) or current kernel available in F16? > Any modinfo switch ? Or should I download source.rpm? > > rpm -q --changelog against 2.6.40.6-0.fc15.x86_64 gives only: > > * Thu Aug 25 2011 Ben Skeggs > - nouveau: add patch fixing ttm issues that lead to oopses/corruption > (rhbz#699551) > > * Tue Aug 23 2011 Ben Skeggs > - nouveau: pull patches from 3.1 to fix some suspend/hibernate > problems (rhbz#730582) The rpm changelog does not contain all the changes made upstream. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any nouveau refresh in f16 beta?
On Wed Oct 12 01:30:57 UTC 2011 Adam Williamson wrote: > There's nothing really interesting in the xorg-x11-drv package any more. > All the interesting bits are in the kernel module, which gets updated > very frequently. Ok. So the link I gave: http://nouveau.git.sourceforge.net/git/gitweb.cgi?p=nouveau/envytools;a=commitdiff;h=b645e6f7d9f204a9176747f129e9e365dcd877ce is somethng about kernel part of nouveau? In this case how can I know if there should be any support for NVD9 (GT520 on a laptop... GF119 chipset) in my current kernel in F15 ( 2.6.40.6-0.fc15.x86_64) or current kernel available in F16? Any modinfo switch ? Or should I download source.rpm? rpm -q --changelog against 2.6.40.6-0.fc15.x86_64 gives only: * Thu Aug 25 2011 Ben Skeggs - nouveau: add patch fixing ttm issues that lead to oopses/corruption (rhbz#699551) * Tue Aug 23 2011 Ben Skeggs - nouveau: pull patches from 3.1 to fix some suspend/hibernate problems (rhbz#730582) Thanks, Gianluca -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-16 Branched report: 20111014 changes
Compose started at Fri Oct 14 08:16:19 UTC 2011 Broken deps for x86_64 -- assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.90-1.fc16.x86_64 requires libchamplain-0.10.so.0()(64bit) emerillon-0.1.90-1.fc16.x86_64 requires libcogl.so.2()(64bit) emerillon-0.1.90-1.fc16.x86_64 requires libchamplain-gtk-0.10.so.0()(64bit) emerillon-devel-0.1.90-1.fc16.i686 requires pkgconfig(champlain-0.10) emerillon-devel-0.1.90-1.fc16.x86_64 requires pkgconfig(champlain-0.10) fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_imgproc.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_contrib.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_core.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_highgui.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_flann.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_features2d.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_calib3d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-firevision-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_imgproc.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_highgui.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_features2d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_calib3d.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_contrib.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_flann.so.2.2()(64bit) fawkes-firevision-0.4.2-4.fc16.x86_64 requires libopencv_core.so.2.2()(64bit) fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis
Re: rhgb boot -> monitor losing signal (sometimes)
On Mon, 10 Oct 2011 09:42:44 -0400, AJ (Adam) wrote: > On Sun, 2011-10-09 at 17:26 +0200, Michael Schwendt wrote: > > > Shortly before the Plymouth LUKS passphrase prompt, the screen turns black, > > the monitor reports "No signal" and enters power-saving mode. The system > > hasn't crashed, because instead of pressing Ctrl+Alt+Del I can also enter > > the passphrase blindly for the boot procedure to continue. However, > > nothing "wakes up" the monitor afterwards. Switching to a virtual console > > causes the signal to return, and what is displayed on the screen is not > > GDM but the gray background with the central animation having reached > > 100% or nearly that. There is no virtual console available, and one cannot > > return to GDM either. > > Plymouth is just a KMS client like the X server. Normally it tries to > avoid setting a video mode if it can (so boot flickers less) but it will > do in some cases. So this sounds like it's a bug in the kernel driver. > > Much of the info from the Xorg debugging guide: > > http://fedoraproject.org/wiki/How_to_debug_Xorg_problems > > is relevant here, although obviously the X log and etc aren't. In > addition, booting with "plymouth:debug" on the kernel command line will > dump debugging output to /var/log/plymouth-debug.log, which should show > the mode setup that plymouth is trying for. Boot with that flag set > once, then either boot again without plymouth.debug or rhgb set, or > simply ssh into the machine and copy the log file aside. Thanks. This sounded promising, but funnily since I've added plymouth:debug permanently, I haven't managed to reproduce the issue. Instead, I've encountered a few different issues. Once only: 1) The GDM background picture was divided into a few big rectangular areas which were shifted by 1/5 screen width. Looked like an unfinished slider puzzle. ;) 2) A completely corrupted GDM background picture. Red/white/black noise, but a working login. 3) The boot not continueing after the LUKS passphrase prompt. The saved plymouth-debug.log files don't contain any obviously dangerous errors. Just lots of ply-event-loop.c debug msgs including (always) many [ply-event-loop.c] ply_event_loop_remove_source_node:failed to delete fd 11 from epoll watch list: Bad file descriptor ... [ply-boot-server.c]ply_boot_connection_on_request:could not finish writing update reply: Broken pipe Now, this morning I've taken out the option again to find out whether the primary issue would return. Perhaps it is influenced by interrupting the GRUB timeout with key presses (although I think I haven't done that with F-15 often). Or my earlier GRUB chainloading. Recently I've stored GRUB 2 in MBR. It's a tough case, but any idea might help in collecting data *if* it will happen again or if a test-case is found. -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc9.git0.0.fc16.x86_64 loadavg: 0.13 0.06 0.05 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 grub2 prompt, help needed
On Fri, 14 Oct 2011 10:22:21 +0100, FM (Frank) wrote: > After todays update. > > Grub2 replaced grub. > > rebooted grub menu still loading. > So did. > grub2-mkconfig > done. Running grub2-mkconfig without options does only print the config file to standard output. You would need grub2-mkconfig -o /boot/grub2/grub.cfg to actually overwrite your GRUB 2 config file. > grub2-install /dev/vda > no errors reported. > > rebooted got: > grub > A working command-line? If so, you could use GRUB's commands to search for and load the grub.cfg file manually, then boot it. > Where do I go from here, > to get a booting vm back. > -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc9.git0.0.fc16.x86_64 loadavg: 0.00 0.04 0.05 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Working hard to lock myself out of my system
On 10/14/2011 06:46 PM, Scott Robbins wrote: > On Fri, Oct 14, 2011 at 06:37:22AM -0400, Scott Robbins wrote: >> On Fri, Oct 14, 2011 at 05:51:15PM +0800, Frederic Muller wrote: >> >>> >>> So this might give you an insight: I just did an install from RC4 and my >>> user was in the sudo group. Then a yum update and tada: no more. I mean >>> using sudo just tells me my user is not in the sudo group. >> >> This is a known bug in glibc, which will, hopefully, be fixed quickly. >> Otherwise, you can downgrade glibc. Not sure about the bugzilla number, >> it's mentioned on Fedora Forums in the F16 section. > > Here's the bugzilla. > > https://bugzilla.redhat.com/show_bug.cgi?id=745675 > Thank you. I must have missed the discussion. Fred -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Working hard to lock myself out of my system
On Fri, Oct 14, 2011 at 06:37:22AM -0400, Scott Robbins wrote: > On Fri, Oct 14, 2011 at 05:51:15PM +0800, Frederic Muller wrote: > > > > > So this might give you an insight: I just did an install from RC4 and my > > user was in the sudo group. Then a yum update and tada: no more. I mean > > using sudo just tells me my user is not in the sudo group. > > This is a known bug in glibc, which will, hopefully, be fixed quickly. > Otherwise, you can downgrade glibc. Not sure about the bugzilla number, > it's mentioned on Fedora Forums in the F16 section. Here's the bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=745675 -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Oz: Looks dead, smells dead, yet it's moving around. That's interesting. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Working hard to lock myself out of my system
On Fri, Oct 14, 2011 at 05:51:15PM +0800, Frederic Muller wrote: > > So this might give you an insight: I just did an install from RC4 and my > user was in the sudo group. Then a yum update and tada: no more. I mean > using sudo just tells me my user is not in the sudo group. This is a known bug in glibc, which will, hopefully, be fixed quickly. Otherwise, you can downgrade glibc. Not sure about the bugzilla number, it's mentioned on Fedora Forums in the F16 section. > I'll check if there is a bug filed for the sudo group thingy and for the > power off option... well we all know about it so I will just pray while > burning 2/3 Windows installed PCs as a worthy sacrifice ;-) The bug (as well as several duplicates) has been filed. Apparently the glibc upgrade broke groups. This also broke sound for me as I was no longer in the audio group. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Xander: You're considered somewhat cool. Oz: I am? Xander: Is it because you always tend to express yourself in short, non-commital sentences? Oz: Could be. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Working hard to lock myself out of my system
On 10/13/2011 04:03 PM, Erinn Looney-Triggs wrote: > So I go in with my fingerprint to see what is happening, and I run a > sudo command (really slick the fingerprint auth with sudo, kudos), > trouble is it tells me I am not in the sudoers file. Well that is odd it > used to work. My sudoers is based off of group membership, a member in > wheel gets sudo access if not then no. So this might give you an insight: I just did an install from RC4 and my user was in the sudo group. Then a yum update and tada: no more. I mean using sudo just tells me my user is not in the sudo group. Among the changes between RC4 and yum update until today I saw the power off menu disappearing again (I am very sad about that one, I thought we understand users wanted it badly) and online accounts time out was fixed (couldn't get the google page from RC4, can now). I'll check if there is a bug filed for the sudo group thingy and for the power off option... well we all know about it so I will just pray while burning 2/3 Windows installed PCs as a worthy sacrifice ;-) Fred -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 grub2 prompt, help needed
After todays update. Grub2 replaced grub. rebooted grub menu still loading. So did. grub2-mkconfig done. grub2-install /dev/vda no errors reported. rebooted got: grub > Where do I go from here, to get a booting vm back. -- Regards, Frank Murphy UTF_8 Encoded Friend of fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /etc/default/grub is supposed to be where I put changes, right?
Dne 14.10.2011 01:45, Tom Horsley napsal(a): > Every time I get a new grub2 update, it resets the > /etc/default/grub file, wiping out all my customizations, Why in the world it is /etc/default (which is coming from the Debian world) and not /etc/sysconfig? Matěj -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
