Re: F17 installation on an Apple Macbook Pro
On Mon, Sep 24, 2012 at 9:02 AM, Zoltan Kota zolt...@gmail.com wrote: Hi, I've tried to follow the discussions related to Fedora and Apple hardware in these lists. Some days ago I decided to try to install F17 on my Macbook Pro. Maybe it is useful to share my experiences. The initial state was: Apple Macbook Pro 3.1, a Triple-boot system with Mac OSX, WindowsXP, Fedora 14, booting through ReFit For Fedora I had a separate 'root', 'swap' and 'home' partitiion. My plan was to do a fresh installation on the existing root partition keeping the home partition as is. The istallation media was F17 i386 DVD. 1. The system booted from DVD correctly, graphical setup was OK. 2. At selecting partitions I choose custom setup, and selected my existing /, swap, and /home partitions for installation. At this point I had to stop, because setup needed a bios boot partition that I didn'h have. 3. As I didn't want to mess up my partitions completely / to have more control, I manipulated my partition table out of the graphical setup. I used gdisk in command line from the DVD. I removed my linux root partition and created a 1MB Bios boot partition and a new root partition. The other partitions were not touched. With gdisk I could set the hybrid MBR as well. 4. Starting setup again, selecting custom disk layout with grub installed on the boot partition, the installation was OK. 5. However the hybrid MBR of the disk was cleared. So I had to setup again the hybrid MBR with gdisk. After that I could boot all the 3 systems with ReFit. (ReFit now shows an extra starting icon however, that seems to start windows or fedora depending on which one was booted last time. I don't know where comes this from.) But finally I have bootable Fedora 17 system, hurrah. And my existing other OS-es survived. :-) I think Soory, accidentally I sent it before I could finish my email. So, I think would be nice to try F17_x86_64 as well? I have never tried EFI installation of fedora before. Is it possible to install grub efi in the root/boot partition during setup? ReFit should find it as I know. Zoltan -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The new installer
Hi, What kind of impression do you think people get when, after hearing that Fedora defines itself as bleeding edge technology, they are presented with an installer interface designed and written more than ten years ago? and the wheel was invented more than ten *thousand* years ago is that a reason we need to use something else than wheels? take a look here: http://www.motortrend.com/features/consumer/1107_2012_2013_new_cars_ultimate_buyers_guide/viewall.html - don't they look modern enough? yet they all use those obsolete wheels, ouch /me goes to swallow Zyrtec, getting hives each time someone says we need to replace something just because it is old http://www.joelonsoftware.com/articles/fog69.html K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: Never attribute to malice what can :: easily be explained by stupidity. 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
rawhide report: 20120924 changes
Compose started at Mon Sep 24 08:15:06 UTC 2012 Broken deps for x86_64 -- [almanah] almanah-0.8.0-7.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libecal-1.2.so.12()(64bit) almanah-0.8.0-7.fc18.x86_64 requires libebook-1.2.so.13()(64bit) [clutter-gtk010] clutter-gtk010-0.11.4-6.fc17.i686 requires libcogl.so.9 clutter-gtk010-0.11.4-6.fc17.x86_64 requires libcogl.so.9()(64bit) [dogtag-pki] dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-util-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-tools = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-tks = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-symkey = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-silent = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-setup = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-server = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-selinux = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-ocsp = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-kra = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-java-tools-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-console = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-common-javadoc = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-ca = 0:10.0.0 dogtag-pki-10.0.0-0.8.a1.fc19.noarch requires pki-base = 0:10.0.0 [ease] ease-0.4-18.fc17.i686 requires libcogl.so.9 ease-0.4-18.fc17.x86_64 requires libcogl.so.9()(64bit) [emacs-spice-mode] emacs-spice-mode-1.2.25-9.fc18.noarch requires gwave [evolution-exchange] evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserverui-3.0.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedataserver-1.2.so.16()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-cal-1.2.so.17()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libedata-book-1.2.so.14()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libecal-1.2.so.12()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebook-1.2.so.13()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libebackend-1.2.so.3()(64bit) evolution-exchange-3.5.2-1.fc18.x86_64 requires libcamel-1.2.so.36()(64bit) [fedora-ksplice] fedora-ksplice-0.5-10.fc18.x86_64 requires ksplice [flush] flush-0.9.10-7.fc18.x86_64 requires libboost_thread-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_system-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_signals-mt.so.1.48.0()(64bit) flush-0.9.10-7.fc18.x86_64 requires libboost_filesystem-mt.so.1.48.0()(64bit) [freeipa] freeipa-server-3.0.0-0.8.fc19.x86_64 requires selinux-policy = 0:3.11.1-21 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-symkey = 0:10.0.0-0.33.a1 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-silent = 0:10.0.0-0.33.a1 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-setup = 0:10.0.0-0.33.a1 freeipa-server-3.0.0-0.8.fc19.x86_64 requires pki-ca = 0:10.0.0-0.33.a1 [gcc-python-plugin] gcc-python2-debug-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python2-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python3-debug-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 gcc-python3-plugin-0.9-4.fc19.x86_64 requires gcc = 0:4.7.1-7.fc19 [gcstar] gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Table) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::HBox) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::Frame) gcstar-1.7.0-2.fc19.noarch requires perl(Gtk2::EventBox) [gdb-heap] gdb-heap-0.5-9.fc18.x86_64 requires glibc(x86-64) = 0:2.15 [gearmand] gearmand-0.33-3.fc18.x86_64 requires libmemcached.so.10()(64bit) [glom] glom-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) glom-libs-1.18.6-1.fc17.i686 requires libboost_python.so.1.48.0 glom-libs-1.18.6-1.fc17.x86_64 requires libboost_python.so.1.48.0()(64bit) [gnome-applets] 1:gnome-applets-3.5.1-1.fc18.x86_64 requires libgweather-3.so.0()(64bit) [gnome-pilot] gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserverui-3.0.so.1()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libedataserver-1.2.so.16()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libecal-1.2.so.11()(64bit) gnome-pilot-eds-2.91.93-5.fc17.x86_64 requires libebook-1.2.so.13()(64bit)
Release criterion proposal: upgrade methods
As currently written, the upgrade criterion in the Fedora 18 beta release requirements [1] reads: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. As we aren't sure if preupgrade will continue to be an officially supported upgrade mechanism for F18, I propose to change that criterion such that specific upgrade mechanisms are omitted. The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release via any officially supported upgrade mechanism. The upgraded system must meet all release criteria. Since this is a pretty minor change, I'll wait one week before changing the wiki page. If there are no objections by then, I'll go through and change it. Tim [1] https://fedoraproject.org/wiki/Fedora_18_Beta_Release_Criteria signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, Sep 24, 2012 at 6:32 PM, Tim Flink tfl...@redhat.com wrote: As currently written, the upgrade criterion in the Fedora 18 beta release requirements [1] reads: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. As we aren't sure if preupgrade will continue to be an officially supported upgrade mechanism for F18, I propose to change that criterion such that specific upgrade mechanisms are omitted. Neither will the installer. For F18 a new tool will be written that acts like preupgrade (downloads packages; reboots; upgrades), it might use preupgrade but this isn't decided yet. So I suggest to rewrite the text to say The upgrade tool. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On 09/24/2012 04:32 PM, Tim Flink wrote: As we aren't sure if preupgrade will continue to be an officially supported upgrade mechanism for F18, I propose to change that criterion such that specific upgrade mechanisms are omitted. Does not QA need sanction what ever upgrade mechanism they are coming up with this time? ( When preupgrade was accepted by whomever that took decision they did not even bother to a) ask us b) prepare for it ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, 24 Sep 2012 18:40:08 +0200 drago01 drag...@gmail.com wrote: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. Neither will the installer. For F18 a new tool will be written that acts like preupgrade (downloads packages; reboots; upgrades), it might use preupgrade but this isn't decided yet. So I suggest to rewrite the text to say The upgrade tool. Point taken - there are few details available (that I'm aware of) which describe how any upgrades will work for F18. How about: A clean, fully updated default installation (done with any official install method) of the previous stable Fedora release must be upgradable via any officially supported upgrade mechanism. The upgraded system must meet all release criteria. Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, Sep 24, 2012 at 7:03 PM, Tim Flink tfl...@redhat.com wrote: On Mon, 24 Sep 2012 18:40:08 +0200 drago01 drag...@gmail.com wrote: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. Neither will the installer. For F18 a new tool will be written that acts like preupgrade (downloads packages; reboots; upgrades), it might use preupgrade but this isn't decided yet. So I suggest to rewrite the text to say The upgrade tool. Point taken - there are few details available (that I'm aware of) which describe how any upgrades will work for F18. https://fedorahosted.org/fesco/ticket/946 See 2012-09-05 FESCo meeting logs for details. How about: A clean, fully updated default installation (done with any official install method) of the previous stable Fedora release must be upgradable via any officially supported upgrade mechanism. The upgraded system must meet all release criteria. s/any/all/ (in case we happen to support multiple methods). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On 09/24/2012 05:05 PM, drago01 wrote: s/any/all/ (in case we happen to support multiple methods). If we start supporting more then one official way of upgrading the distribution then we should be using either or in all release blocking criteria. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 16:56 +, Jóhann B. Guðmundsson wrote: On 09/24/2012 04:32 PM, Tim Flink wrote: As we aren't sure if preupgrade will continue to be an officially supported upgrade mechanism for F18, I propose to change that criterion such that specific upgrade mechanisms are omitted. Does not QA need sanction what ever upgrade mechanism they are coming up with this time? ( When preupgrade was accepted by whomever that took decision they did not even bother to a) ask us b) prepare for it ) I'm sure we've had this go-round before, but my opinion is no. QA does not get to veto engineering decisions. However, there is a more general requirement for transparency in new features that I'm really not convinced has been properly followed for newUI. The feature page does not at present contain any description or discussion of several fairly significant features of the new design, including this new upgrade tool and the change in how the root account is handled. I'd say if there's a problem here it's less that QA should get specific sign-off on things like this and more that: https://fedoraproject.org/wiki/Features/NewInstallerUI is extremely vague and really gave no one in the project (this affects all groups, really, not just QA) an understanding that things like 'no more root password by default' and 'completely different upgrade system' were coming. Some of that information might have been buried somewhere in https://fedoraproject.org/wiki/Anaconda/UX_Redesign , but I'd really expect the feature page to be more detailed and organized, I don't think regular Fedorans should be expected to dig into the background documentation for any given feature to understand broadly what it involves. It's easy to point fingers, but I think FESCo might want to take a lesson from this newUI process for future releases and that lesson should be that major disruptive features should have _much_ better and more definite feature pages. -- 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 criterion proposal: upgrade methods
On Mon, 2012-09-24 at 17:17 +, Jóhann B. Guðmundsson wrote: On 09/24/2012 05:05 PM, drago01 wrote: s/any/all/ (in case we happen to support multiple methods). If we start supporting more then one official way of upgrading the distribution then we should be using either or in all release blocking criteria. I think Tim's 'any' was intentional. I think the idea would be that for Beta we should require 'any' method to work, and for Final we should require 'all' methods to work. Along the model we decided on for USB boot methods at Alpha/Beta. -- 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 criterion proposal: upgrade methods
The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release via any officially supported upgrade mechanism. The upgraded system must meet all release criteria. Sounds like a political statement - good words with almost no content. It would be nearly as useful, and easier to say Everything that has to work will work. If there is no reasonable way to explicitly say in this criterion what should work, at least add references to specific documents that define official install media and officially supported upgrade mechanism. I think it better to accept that criteria may have to be revised for a new release than to craft criteria so general they never need to change, or so empty of detail they have little direct value and require research to understand what they actually mean. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 11:03 -0600, Tim Flink wrote: On Mon, 24 Sep 2012 18:40:08 +0200 drago01 drag...@gmail.com wrote: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. Neither will the installer. For F18 a new tool will be written that acts like preupgrade (downloads packages; reboots; upgrades), it might use preupgrade but this isn't decided yet. So I suggest to rewrite the text to say The upgrade tool. Point taken - there are few details available (that I'm aware of) which describe how any upgrades will work for F18. How about: A clean, fully updated default installation (done with any official install method) of the previous stable Fedora release must be upgradable via any officially supported upgrade mechanism. The upgraded system must meet all release criteria. I was thinking along the same lines, but I think I'd prefer: It must be possible to successfully complete an upgrade from a clean, fully updated default installation of the previous stable Fedora release, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. I just like it more that way around, still. I'm also favouring 'officially recommended' over 'officially supported' because, let's be honest, our 'support' for upgrades is pretty nominal (the testing that backs this criterion is pretty much the extent of our 'support'). It's a bit bikeshed-y I know, in the end I'd be okay with either. -- 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 criterion proposal: upgrade methods
On 09/24/2012 05:20 PM, Adam Williamson wrote: is extremely vague and really gave no one in the project (this affects all groups, really, not just QA) an understanding that things like 'no more root password by default' and 'completely different upgrade system' were coming. Some of that information might have been buried somewhere inhttps://fedoraproject.org/wiki/Anaconda/UX_Redesign , but I'd really expect the feature page to be more detailed and organized, I don't think regular Fedorans should be expected to dig into the background documentation for any given feature to understand broadly what it involves. It's easy to point fingers, but I think FESCo might want to take a lesson from this newUI process for future releases and that lesson should be that major disruptive features should have_much_ better and more definite feature pages. I would be happy to have a single finger point me to the discussion that took place when that decision was made. The main problem I have is that we weren't even included in the discussion so we could not even properly prepare for it to be officially supported. Today it matters less since we are a bit better prepare I just hope that they have gather some input from the front line ( #fedora ) on how the upgrade process has been turning out for people, What have been the major issue people have had etc. to take into account when developing the new upgrade process that is as you have pointed extremely vague and to be honest I'm a bit vary of given Anconda's rough start this development cycle to me this news is coming as a bit of surprise. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 installation on an Apple Macbook Pro
On Sep 24, 2012, at 1:02 AM, Zoltan Kota wrote: 3. As I didn't want to mess up my partitions completely / to have more control, I manipulated my partition table out of the graphical setup. I used gdisk in command line from the DVD. I removed my linux root partition and created a 1MB Bios boot partition and a new root partition. The other partitions were not touched. With gdisk I could set the hybrid MBR as well. Yeah pointless. Even if no changes to partitioning are needed, parted still overwrites the GPT and nukes the hybrid MBR. You have to recreate the hybrid MBR post-install. 4. Starting setup again, selecting custom disk layout with grub installed on the boot partition, the installation was OK. I don't understand what this means. The point of BIOS Boot is to install GRUB 2's core image there. Installing GRUB bits elsewhere isn't recommended. For MBR disks, it's not recommended for core.img to go anywhere but in the MBR gap. 5. However the hybrid MBR of the disk was cleared. So I had to setup again the hybrid MBR with gdisk. After that I could boot all the 3 systems with ReFit. (ReFit now shows an extra starting icon however, that seems to start windows or fedora depending on which one was booted last time. I don't know where comes this from.) But finally I have bootable Fedora 17 system, hurrah. And my existing other OS-es survived. :-) I think Yeah it's fine, but what's intended for F17 is EFI boot which creates totally different partitions, does not rely on either rEFIt (which BTW is no longer maintained, rEFInd is current) or hybrid MBR. But of course as you found, that's only for x86_64 builds. I have never tried EFI installation of fedora before. Is it possible to install grub efi in the root/boot partition during setup? ReFit should find it as I know. GRUB Legacy EFI is installed on its own HFS+ partition, this is unique to Mac installs of F17. I actually don't know if rEFIt will find it or not,but I think it does. For this to work, you need to let anaconda do it automatically. Custom partitioning doesn't work. So you first nuke all partitions from the previous Linux installation from the GPT, leaving free space. Then have anaconda use the Free Space installation type and it will create all of the correct partitions for Mac EFI boot. You'll even get a Fedora option in the Startup Disk panel in Mac OS. A small limitation is that the HFS+ bootloader partition is named Untitled in the Mac OS GUI. You can rename it if you want with no ill effect. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
Hello, this Tuesday starts Fedora X Test Week which is one of the most popular testing events among Fedora users and developers. Do you have any old or new graphic hardware, working or not? Join this test week and help us to hunt down driver bugs before Fedora 18 Beta release! For more informations how to attend this test week, look at the following schedule: 2012-09-25 Nouveau - https://fedoraproject.org/wiki/Test_Day:2012-09-25_Nouveau 2012-09-26 Radeon - https://fedoraproject.org/wiki/Test_Day:2012-09-26_Radeon 2012-09-27 Intel - https://fedoraproject.org/wiki/Test_Day:2012-09-27_Intel Join IRC #fedora-test-day on FreeNode and ask QA or developers for help, if you get into trouble. We can try to find workarounds and help with debugging. Please report all bugs at http://bugzilla.redhat.com/ under appropriate component. You can also report other Fedora 18 bugs not related to this Test Week, ask QA, if you don't know against which component you should fill the report. See you in Bugzilla! Best Regards, Martin Holec Desktop QE, Red Hat Brno -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 13:33 -0400, Richard Ryniker wrote: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release via any officially supported upgrade mechanism. The upgraded system must meet all release criteria. Sounds like a political statement - good words with almost no content. It would be nearly as useful, and easier to say Everything that has to work will work. If there is no reasonable way to explicitly say in this criterion what should work, at least add references to specific documents that define official install media and officially supported upgrade mechanism. I think it better to accept that criteria may have to be revised for a new release than to craft criteria so general they never need to change, or so empty of detail they have little direct value and require research to understand what they actually mean. Is the concept of 'official install media' and a 'supported/recommended upgrade mechanism' really so vague as to be meaningless? I don't think I'd agree with that. It seems fairly clear to me. I do think in principle we should have documents that define what currently fulfils generic definitions like that, but the problem is that when you think about it, those documents very rarely ought to be ones QA 'owns', so it's not always straightforward to ensure it happens. For this specific case though, I think we could link to https://fedoraproject.org/wiki/Upgrading to define 'supported/recommendation upgrade mechanism' - that's clearly the 'official' page for such things and should be updated whenever it changes. 'official install media' is not quite as obvious; maybe it should be a link to the Deliverables SOP when I or someone else finally gets that done (my last draft is still at https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables ). -- 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 criterion proposal: upgrade methods
On 09/24/2012 05:35 PM, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a clean, fully updated default installation of the previous stable Fedora release, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. The default should be removed and changed to offered DE install ( excluding any additional group individual packages user might select in the new software spoke ) to reflect changes to the installer ( which should also cover live ) + minimal installs JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
The future of how to debug pages
A while back I started the initiative and writing how to debug pages for QA Community to use and was about to write another when I noticed when there has been put a big fat banner referring to upstream wiki page on it. So my question here should we continue with this initiative which was aimed at better documentation in the project and to improve general reporting or should we simply drop the effort? JBG 1. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 19:18 +, Jóhann B. Guðmundsson wrote: On 09/24/2012 05:35 PM, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a clean, fully updated default installation of the previous stable Fedora release, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. The default should be removed and changed to offered DE install ( excluding any additional group individual packages user might select in the new software spoke ) to reflect changes to the installer ( which should also cover live ) + minimal installs Right, for 18 the 'default installation' wording would work because there was still a 'default installation' of Fedora 17, but it wouldn't work after 18, so we should change it. It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. ? -- 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 criterion proposal: upgrade methods
On 09/24/2012 07:34 PM, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. I would like to replace/drop release-blocking desktop and or add something that covers all the official media that get handed out at various events. I kinda feel that we are obligated to cover that since the projects representatives are putting that directly in the hands of end users JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, Sep 24, 2012 at 12:34:34PM -0700, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. +1 Is it worth leaving an out for corner cases? What about situations like oh, we don't support a separate /usr anymore? What level of (possibly-crazy) customization is allowed between the initial installation + updates and upgrading? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On 09/24/2012 07:54 PM, Matthew Miller wrote: On Mon, Sep 24, 2012 at 12:34:34PM -0700, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. +1 Is it worth leaving an out for corner cases? What about situations like oh, we don't support a separate /usr anymore? What level of (possibly-crazy) customization is allowed between the initial installation + updates and upgrading? None we only support package selection that we have *pre* selected for the user to choose from in the software spoke ( which should be the same as what we hand out in the form of live media at various events thus we kill two birds with one criteria ;) ). I'm not sure how far back that release wise that support is suppose to go as in do we support ( or should support since package selection might differ between release ) F15 -- F18 ( GA + 1 unsupported release ) or F16 -- F18 ( Between GA releases ) or only F17 -- F18 ( latest GA release ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Selinux in development releases
I hereby propose that we default selinux to permissive mode up to final which should just get rid of unneeded nuance during testing. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On Mon, Sep 24, 2012 at 10:13 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I hereby propose that we default selinux to permissive mode up to final which should just get rid of unneeded nuance during testing. -1 This would just mean we test something different then we actually ship. If there are selinux bugs they are supposed to be cough during testing and reported like any other bugs. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
drago01 wrote: This would just mean we test something different then we actually ship. If there are selinux bugs they are supposed to be cough during testing and reported like any other bugs. +1 There are instances of SELinux rules (bug or intentional) that only occur under Enforcing. The SELinux team is very speedy IMHO. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On Mon, 24 Sep 2012 19:29:39 + Jóhann B. Guðmundsson johan...@gmail.com wrote: A while back I started the initiative and writing how to debug pages for QA Community to use and was about to write another when I noticed when there has been put a big fat banner referring to upstream wiki page on it. So my question here should we continue with this initiative which was aimed at better documentation in the project and to improve general reporting or should we simply drop the effort? JBG 1. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems I think if upstream projects want to provide information on this, that should be preferred. In cases where they don't for whatever reason, I think a page on our wiki is fine. The problem will end up being knowing where to go... perhaps we could make a single page on the wiki about debugging and point to the various upstream or local debugging pages? kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On 09/24/2012 08:16 PM, drago01 wrote: On Mon, Sep 24, 2012 at 10:13 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I hereby propose that we default selinux to permissive mode up to final which should just get rid of unneeded nuance during testing. -1 This would just mean we test something different then we actually ship. If there are selinux bugs they are supposed to be cough during testing and reported like any other bugs. With permissive mode we should still be able to catch all those errors and report them without all the downside that comes with having it in enforcing mode during our development releases... JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On 09/24/2012 08:19 PM, Michael Cronenworth wrote: drago01 wrote: This would just mean we test something different then we actually ship. If there are selinux bugs they are supposed to be cough during testing and reported like any other bugs. +1 There are instances of SELinux rules (bug or intentional) that only occur under Enforcing. The SELinux team is very speedy IMHO. Do you have any reference for such bugs that only happen when selinux is in enforcing mode but not when it is in enforcing mode? Yeah the whole project is aware of Dan's superhuman ability to quickly fix things through and during our release and development cycles. A while back I suggested he should be offered a metal for his efforts. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
Do you have any old or new graphic hardware, working or not? Join this test week and help us to hunt down driver bugs before Fedora 18 Beta release! There is doubt about whether this particular test day is worth the time. At a minimum, don't bother with any Radeon card that is less than a Radeon 9600. Fedora pays no attention to bugs on such hardware, not even saying Sorry, this hardware is too old; we will increase the minimum hardware requirement or This is hardware bug, and a software workaround is not feasible. For instance: radeon_rendercheck 152752 failures; pci:1002:5157 Radeon RV200 QW [Radeon 7500] https://bugzilla.redhat.com/show_bug.cgi?id=638758 This card still is usable in XFCE. Gnome3 is not putting any effort into fallback mode. So my Radeon 9250 purchased new in 2006 as a mid-life upgrade for a box with 1.6GHz Pentium 4 (well above the Fedora minimum CPU) also runs only XFCE. Gnome3 forces fallback mode, where some Desktop features are *dropped* instead of emulated. Also forget about any card+monitor which does not report EDID/DCC. The Xorg.0.log may note the true resolution of the panel (for instance, 1024x768), but the driver gives only 800x600: rage128 uses 800x600 resolution for LCD panel with 1024x768 native resolution https://bugzilla.redhat.com/show_bug.cgi?id=493441 The nouveau driver also ignores reports, even on current-generation cards. For instance: glxgears framerate 12X faster than video refresh https://bugzilla.redhat.com/show_bug.cgi?id=639415 -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On 09/24/2012 08:25 PM, Kevin Fenzi wrote: On Mon, 24 Sep 2012 19:29:39 + Jóhann B. Guðmundsson johan...@gmail.com wrote: A while back I started the initiative and writing how to debug pages for QA Community to use and was about to write another when I noticed when there has been put a big fat banner referring to upstream wiki page on it. So my question here should we continue with this initiative which was aimed at better documentation in the project and to improve general reporting or should we simply drop the effort? JBG 1. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems I think if upstream projects want to provide information on this, that should be preferred. In cases where they don't for whatever reason, I think a page on our wiki is fine. The problem will end up being knowing where to go... perhaps we could make a single page on the wiki about debugging and point to the various upstream or local debugging pages? The general idea was to increase activity within the QA community and improve reporting at the same time without having them running around the whole internet while doings so. If the community prefers to run to various upstreams for this info we can just as well stop reporting to Red Hat's bugzilla and report directly upstream instead. ( something I have been very much against in the past for the very same reasons ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On Mon, 24 Sep 2012 20:31:41 + Jóhann B. Guðmundsson johan...@gmail.com wrote: The general idea was to increase activity within the QA community and improve reporting at the same time without having them running around the whole internet while doings so. Sure, but duplicating upstream work seems not very productive to me. If the community prefers to run to various upstreams for this info we can just as well stop reporting to Red Hat's bugzilla and report directly upstream instead. ( something I have been very much against in the past for the very same reasons ) Well, in the case of bugs there's give and take and bidirectional communication. In the case of debugging info/steps it's more of a static list. If upstream already produces such a list, shouldn't we just point to that? kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: The future of how to debug pages
On 09/24/2012 08:59 PM, Kevin Fenzi wrote: On Mon, 24 Sep 2012 20:31:41 + Jóhann B. Guðmundsson johan...@gmail.com wrote: The general idea was to increase activity within the QA community and improve reporting at the same time without having them running around the whole internet while doings so. Sure, but duplicating upstream work seems not very productive to me. Less about duplication more about increasing our own local activity and knowledge base where we can write those pages based on the experience level we expect ( which should always be the lowest one hence I have always written those pages with spoon feeding information ). If the community prefers to run to various upstreams for this info we can just as well stop reporting to Red Hat's bugzilla and report directly upstream instead. ( something I have been very much against in the past for the very same reasons ) Well, in the case of bugs there's give and take and bidirectional communication. In the case of debugging info/steps it's more of a static list. If upstream already produces such a list, shouldn't we just point to that? There is nothing that says that list is more up2date than what we have locally and based on your logic if upstream has test cases should we just point reporters to that? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
Jóhann B. Guðmundsson wrote: Do you have any reference for such bugs that only happen when selinux is in enforcing mode but not when it is in enforcing mode? Yes, here is one bug[1] to get you started. [1] https://bugzilla.redhat.com/show_bug.cgi?id=638511 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
On 09/24/2012 09:21 PM, Michael Cronenworth wrote: Jóhann B. Guðmundsson wrote: Do you have any reference for such bugs that only happen when selinux is in enforcing mode but not when it is in enforcing mode? Yes, here is one bug[1] to get you started. [1] https://bugzilla.redhat.com/show_bug.cgi?id=638511 This bug is filed against RHEL in any case just have it in permissive mode up to beta should suffice and prevent any RC_N surprises It would be good to get feed back from Dan what's his taken on this JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Selinux in development releases
Jóhann B. Guðmundsson wrote: This bug is filed against RHEL in any case just have it in permissive mode up to beta should suffice and prevent any RC_N surprises Jóhann, I didn't blindly post the first bug I found. I ran into this bug on a Fedora system, which is the only reason I knew about it in the first place. If you read the bug comments you will find: * With Enforcing: No AVC messages were output, but dirsrv-admin could not be started * With Permissive: No AVC messages where output, but dirsrv-admin started If you default to Permissive then you *will* miss possible policy bugs. Some of these are hidden in dontaudit messages such as the bug I linked. It would be good to get feed back from Dan what's his taken on this Good. I know I'm Mr. Nobody here, but his answer would be definitive. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 15:54 -0400, Matthew Miller wrote: On Mon, Sep 24, 2012 at 12:34:34PM -0700, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. +1 Is it worth leaving an out for corner cases? What about situations like oh, we don't support a separate /usr anymore? What level of (possibly-crazy) customization is allowed between the initial installation + updates and upgrading? Oh, I think I dropped the word 'clean', which was code for 'we'll reject all the stuff Matthew just wrote about'. We can add that back in. We've always interpreted the criterion quite strictly, in practice. -- 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 criterion proposal: upgrade methods
On Mon, 2012-09-24 at 20:02 +, Jóhann B. Guðmundsson wrote: On 09/24/2012 07:54 PM, Matthew Miller wrote: On Mon, Sep 24, 2012 at 12:34:34PM -0700, Adam Williamson wrote: It must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with the 'minimal' package set or the package set for a release-blocking desktop, using any officially recommended upgrade mechanism. The upgraded system must meet all release criteria. +1 Is it worth leaving an out for corner cases? What about situations like oh, we don't support a separate /usr anymore? What level of (possibly-crazy) customization is allowed between the initial installation + updates and upgrading? None we only support package selection that we have *pre* selected for the user to choose from in the software spoke ( which should be the same as what we hand out in the form of live media at various events thus we kill two birds with one criteria ;) ). I'm not sure how far back that release wise that support is suppose to go as in do we support ( or should support since package selection might differ between release ) F15 -- F18 ( GA + 1 unsupported release ) or F16 -- F18 ( Between GA releases ) or only F17 -- F18 ( latest GA release ) Only 17-18: using the definite article 'the' rather than the indefinite article 'a' implies this. It says 'the previous stable Fedora release' - which strictly means only the single preceding release - not 'a previous stable Fedora release' or 'any previous stable Fedora release' or anything like that. I suppose it's a distinction which is clearer to a native speaker, admittedly, it's a bit of a fine point in English. That's definitely why it's written that way, though. -- 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: Selinux in development releases
On 09/24/2012 09:39 PM, Michael Cronenworth wrote: Good. I know I'm Mr. Nobody here, but his answer would be definitive. There is no Mr. Nobody in the QA community ;) Having selinux in permissive mode ( especially during alpha ) is from my pov more likely to hinder participation than to increase it. And this has been exceptionally bad since the introduction of systemd and most notable because of lack of communication from the three amigos to Dan. ( they make changes without notifying Dan about it, not giving him enough time to act on it ) JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: upgrade methods
On 09/24/2012 09:43 PM, Adam Williamson wrote: Only 17-18: using the definite article 'the' rather than the indefinite article 'a' implies this. It says 'the previous stable Fedora release' - which strictly means only the single preceding release - not 'a previous stable Fedora release' or 'any previous stable Fedora release' or anything like that. I suppose it's a distinction which is clearer to a native speaker, admittedly, it's a bit of a fine point in English. That's definitely why it's written that way, though. Arguably we should actually be covering both GA release. ( everyone I know do it at EOL time ) Do you know if we keep log in our infrastructure that shows how many are actually upgrading on which version they do it from? JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On Mon, 2012-09-24 at 13:30 -0700, John Reiser wrote: Do you have any old or new graphic hardware, working or not? Join this test week and help us to hunt down driver bugs before Fedora 18 Beta release! There is doubt about whether this particular test day is worth the time. You're free to doubt whatever you like, but the experiences you appear to be citing as evidence are not especially relevant. At a minimum, don't bother with any Radeon card that is less than a Radeon 9600. Fedora pays no attention to bugs on such hardware, not even saying Sorry, this hardware is too old; we will increase the minimum hardware requirement or This is hardware bug, and a software workaround is not feasible. For instance: radeon_rendercheck 152752 failures; pci:1002:5157 Radeon RV200 QW [Radeon 7500] https://bugzilla.redhat.com/show_bug.cgi?id=638758 This card still is usable in XFCE. a) You're calling out a test you ran once nearly two years ago. Pretty sure we've fixed at least one RV200 bug since then. b) rendercheck is just a test battery. Passing all of its tests is not necessarily a prerequisite for correct rendering of any desktop; if you don't hit cases that fail, you'd never notice they were broken. c) I'm fairly sure zero of the tests you've shown to fail there _do_ matter. They all happen when you do a Render operation directly to a window, and nobody does that. Drawing straight to a window is unbelievably flickery, that's why everybody buffers things up to an offscreen pixmap and then blits across to the window (using core CopyArea, not Render). Gnome3 is not putting any effort into fallback mode. So my Radeon 9250 purchased new in 2006 as a mid-life upgrade for a box with 1.6GHz Pentium 4 (well above the Fedora minimum CPU) also runs only XFCE. Gnome3 forces fallback mode, where some Desktop features are *dropped* instead of emulated. Why do you feel this is relevant? X bugs are X bugs. Also forget about any card+monitor which does not report EDID/DCC. Forget about broken hardware? Yeah, please do. The Xorg.0.log may note the true resolution of the panel (for instance, 1024x768), but the driver gives only 800x600: rage128 uses 800x600 resolution for LCD panel with 1024x768 native resolution https://bugzilla.redhat.com/show_bug.cgi?id=493441 Your comparison between F17 and F18 therein is interesting but a bit off the mark. In F17 you're using vesa for some reason; in F18 you're not. The nouveau driver also ignores reports, even on current-generation cards. For instance: glxgears framerate 12X faster than video refresh https://bugzilla.redhat.com/show_bug.cgi?id=639415 vsync support isn't something nouveau has always done. But it turns out things have gotten a lot better since F15; I really wouldn't take a report of this vintage as indicative of how well things currently work. - ajax 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: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On Mon, 2012-09-24 at 17:59 -0400, Adam Jackson wrote: On Mon, 2012-09-24 at 13:30 -0700, John Reiser wrote: Do you have any old or new graphic hardware, working or not? Join this test week and help us to hunt down driver bugs before Fedora 18 Beta release! There is doubt about whether this particular test day is worth the time. You're free to doubt whatever you like, but the experiences you appear to be citing as evidence are not especially relevant. At a minimum, don't bother with any Radeon card that is less than a Radeon 9600. Fedora pays no attention to bugs on such hardware, not even saying Sorry, this hardware is too old; we will increase the minimum hardware requirement or This is hardware bug, and a software workaround is not feasible. For instance: radeon_rendercheck 152752 failures; pci:1002:5157 Radeon RV200 QW [Radeon 7500] https://bugzilla.redhat.com/show_bug.cgi?id=638758 This card still is usable in XFCE. a) You're calling out a test you ran once nearly two years ago. Pretty sure we've fixed at least one RV200 bug since then. b) rendercheck is just a test battery. Passing all of its tests is not necessarily a prerequisite for correct rendering of any desktop; if you don't hit cases that fail, you'd never notice they were broken. c) I'm fairly sure zero of the tests you've shown to fail there _do_ matter. They all happen when you do a Render operation directly to a window, and nobody does that. Drawing straight to a window is unbelievably flickery, that's why everybody buffers things up to an offscreen pixmap and then blits across to the window (using core CopyArea, not Render). We added the rendercheck test to the list just to provide the data for you folks (X devs) to look through if you thought it might be useful. I'll see if I can do something (more) on the test day pages to indicate that failures in rendercheck aren't always bugs per se and not to worry too much if some of the tests fail, and that it's not usually necessary to open a bug just for rendercheck failing. Gnome3 is not putting any effort into fallback mode. So my Radeon 9250 purchased new in 2006 as a mid-life upgrade for a box with 1.6GHz Pentium 4 (well above the Fedora minimum CPU) also runs only XFCE. Gnome3 forces fallback mode, where some Desktop features are *dropped* instead of emulated. Why do you feel this is relevant? X bugs are X bugs. Right, this is mostly out of scope. The actual bug here is well-known, btw - there's a blacklist for adapters that do 3D but are known not to be capable of rendering Shell properly. Currently, if your card is on that blacklist, you wind up with fallback mode, but what we really want to happen is for it to fall back to software rendering, like it does on systems where there's no 3D capability at all. That's the bug here. As ajax says it's nothing to do with X or the X test days, it's a bug in the GNOME fallback logic. Ajax replied to your specific points, but there's an underlying general point, and here it is: not all bugs reported as part of Test Days will be fixed. Even some 'valid' ones will probably wind up withering. It's unfortunate but for zillions of reasons - each individual case has an explanation, as the specific examples cited here show - it happens. We don't expect 100% response rate for Test Day bugs, it'd be unrealistic. I'd only be worried if the rate was extremely low or dropping fast. Since X Test Week is a large and regularly repeated event it's actually possible to look at those numbers, and indeed we do: I post a statistical breakdown of various things, including a look at the outcome of the filed bugs, after each Test Day. Look through the archives for these posts: Very belated 2011-09 Graphics Test Week recap - Wed, 30 Nov 2011 11:41:20 -0800 2011-02 Graphics Test Week recap - Thu, 03 Mar 2011 03:22:49 + 2010-09 Graphics Test Week recap - Tue, 05 Oct 2010 14:50:19 -0700 2010-04-13 to 2010-04-15 Graphics Test Week recap - Tue, 20 Apr 2010 15:11:55 -0700 In the 2011-09 one you can see the numbers for what's happened to all the bugs reported in all the test days from Fedora 11 cycle through Fedora 15 cycle. They go up and down, but there isn't any clear worrying trend there, and a decent number of bugs was fixed in almost every cycle. As long as that's happening, the event has value. From the F15 cycle, in total across all three test days, 123 bugs were reported, 34 were closed as 'fixed'...fixing 34 bugs isn't a bad outcome from such an event, I don't think. (if you're wondering where the F16 numbers are - they would have been in the recap for the f17 X test week, but there was no f17 X test week because I never quite got around to running it. I'll do the f16 numbers in the f18 test week recap.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 21:52 +, Jóhann B. Guðmundsson wrote: On 09/24/2012 09:43 PM, Adam Williamson wrote: Only 17-18: using the definite article 'the' rather than the indefinite article 'a' implies this. It says 'the previous stable Fedora release' - which strictly means only the single preceding release - not 'a previous stable Fedora release' or 'any previous stable Fedora release' or anything like that. I suppose it's a distinction which is clearer to a native speaker, admittedly, it's a bit of a fine point in English. That's definitely why it's written that way, though. Arguably we should actually be covering both GA release. ( everyone I know do it at EOL time ) You could certainly make the case, yeah. Given that our excuse for people who say 'you have to upgrade every six months' is to say 'no you don't, because we support releases for 12, you can just upgrade every second release!', so we kinda do tell people that. Do you know if we keep log in our infrastructure that shows how many are actually upgrading on which version they do it from? I don't know that, no. I don't think we do. I suppose it might be possible to infer such information from the yum records, with a careful analysis, by looking at installations with reliable IP addresses and seeing their upgrade patterns. That might actually be kinda interesting, but I don't know if it's really possible. In general Fedora is pretty conservative about logging user information. As a F/OSS project, you run the risk of a bad case of Slashdotitis if you do anything else =) -- 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 criterion proposal: upgrade methods
On 24 September 2012 17:06, Adam Williamson awill...@redhat.com wrote: On Mon, 2012-09-24 at 21:52 +, Jóhann B. Guðmundsson wrote: Do you know if we keep log in our infrastructure that shows how many are actually upgrading on which version they do it from? I don't know that, no. I don't think we do. I suppose it might be possible to infer such information from the yum records, with a careful analysis, by looking at installations with reliable IP addresses and seeing their upgrade patterns. That might actually be kinda interesting, but I don't know if it's really possible. In general Fedora is pretty conservative about logging user information. As a F/OSS project, you run the risk of a bad case of Slashdotitis if you do anything else =) We do not have a simple way of tracking upgrade methods nor users to do so. Mainly for the reasons that IPs change a lot, what looks like an upgrade turns out to be users behind a NAT, etc etc. 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 -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On 09/24/2012 02:59 PM, Adam Jackson wrote: On Mon, 2012-09-24 at 13:30 -0700, John Reiser wrote: Do you have any old or new graphic hardware, working or not? Join this test week and help us to hunt down driver bugs before Fedora 18 Beta release! There is doubt about whether this particular test day is worth the time. You're free to doubt whatever you like, but the experiences you appear to be citing as evidence are not especially relevant. Fedora graphics don't just work across the entire range of specified compatible hardware. The end-user experience is horrible for newcomers on low-end hardware which meets the listed requirements. Current requirements are: http://docs.fedoraproject.org/en-US/Fedora/17/html/Release_Notes/sect-Release_Notes-Welcome_to_Fedora_17.html#sect-Release_Notes-Hardware_Overview If it is known that any Radeon card less than Radeon 9600 won't work satisfactorily in the default Gnome3 desktop, then Fedora should admit it up front, and raise the minimum stated requirements. At a minimum, don't bother with any Radeon card that is less than a Radeon 9600. Fedora pays no attention to bugs on such hardware, not even saying Sorry, this hardware is too old; we will increase the minimum hardware requirement or This is hardware bug, and a software workaround is not feasible. For instance: radeon_rendercheck 152752 failures; pci:1002:5157 Radeon RV200 QW [Radeon 7500] https://bugzilla.redhat.com/show_bug.cgi?id=638758 This card still is usable in XFCE. a) You're calling out a test you ran once nearly two years ago. Pretty sure we've fixed at least one RV200 bug since then. Please give a specific reference. Here are all the CLOSED bugs with RV200. I don't see a single one that is RV200-specific that was fixed after October 2010. Only 680651 and 493328 were fixed; the rest are WONT FIX. 680651 is not specific to RV200, and 493328 was more than two years ago. - 680651 Fedora xorg-x11-drv-atiairl...@redhat.com CLOSED ERRA [Redwood][RV280][RV200] oops Radeon ttm_bo_ref_bug 2011-06-25 638758 Fedora xorg-x11-drv-atijgli...@redhat.com CLOSED WONT radeon_rendercheck 152752 failures; pci:1002:5157 Radeon RV200 QW [Radeon 7500] 2012-08-16 583826 Fedora xorg-x11xgl-ma...@redhat.comCLOSED WONTF13 i686: Radeon RV200 - Firefox+NoScript in Release notes - Crash X in libc.so 2011-06-27 566970 Fedora xorg-x11-drv-atijgli...@redhat.com CLOSED WONT KMS:RV200|M7:7500 Npviewer segfaults and restarts Xorg 2010-12-03 549622 Fedora kernel kernel-ma...@redhat.com CLOSED NOTAWhen an external monitor is connected to RV200 video card, KMS fails. 2009-12-22 547598 Fedora xorg-x11-drv-atixgl-ma...@redhat.comCLOSED DUPL KMS:RV200:M7:7500 resolution switching doesn't work 2010-07-21 533615 Fedora xorg-x11-drv-atijgli...@redhat.com CLOSED WONT KMS:Rv200|M7:7500:Mesa fonts rendering issues and gnome-shell blackness 2010-12-03 533314 Fedora xorg-x11-drv-atijgli...@redhat.com CLOSED CURR KMS:RV200:7500 Graphics corruption (LVDS wrong reg programming ?) 2010-03-12 493328 Fedora xorg-x11-drv-atiairl...@redhat.com CLOSED ERRA KMS:RV200:7500:MESA Compiz: corrupted menu borders 2010-01-13 446596 Fedora kernel kernel-ma...@redhat.com CLOSED WONT framebuffer video mode selection Radeon RV200, EDID pb? 2009-07-14 - b) rendercheck is just a test battery. Passing all of its tests is not necessarily a prerequisite for correct rendering of any desktop; if you don't hit cases that fail, you'd never notice they were broken. Nevertheless, known failures in a designated test case should be listed and explained, whether hardware is confirmed to be buggy, or Gnome3 Desktop never uses this drawing mode, or ... (or We don't know why.) c) I'm fairly sure zero of the tests you've shown to fail there _do_ matter. They all happen when you do a Render operation directly to a window, and nobody does that. Drawing straight to a window is unbelievably flickery, that's why everybody buffers things up to an offscreen pixmap and then blits across to the window (using core CopyArea, not Render). When I run the anaconda installer for Fedora 18 Alpha, then I see bad _graphics_. It's not clear where the problems lie, and this is Alpha. Nevertheless, I expected better _graphics_. Gnome3 is not putting any effort into fallback mode. So my Radeon 9250 purchased new in 2006 as a mid-life upgrade for a box with 1.6GHz Pentium 4 (well above the Fedora minimum CPU) also runs only XFCE. Gnome3 forces fallback mode, where some Desktop features are *dropped* instead of emulated. Why do you feel this is relevant? X bugs are X bugs. Also forget about any card+monitor which does not report EDID/DCC. Forget about broken
Re: Release criterion proposal: upgrade methods
I think we could link to https://fedoraproject.org/wiki/Upgrading to define 'supported/recommendation upgrade mechanism' OK, but to illustrate the problem with indirect references: the Upgrading page you cite above says to read http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/index.html for details. This document says (Chapter 20): Before upgrading to Fedora 17 you should first bring your current version up to date. However, it is not then necessary to upgrade to intermediate versions. For example, you can upgrade from Fedora 14 to Fedora 17 directly. Therefore, it seems your recent post to this list: http://lists.fedoraproject.org/pipermail/test/2012-September/110331.html may be incorrect. I think you are right, but the quotation above contradicts your statement: Only 17-18: using the definite article 'the' rather than the indefinite article 'a' implies this. It says 'the previous stable Fedora release' - which strictly means only the single preceding release My point here is that details in the QA criteria that specify explicitly what operations must work are valuable. Indirect references to dynamic documents (which you properly describe as not owned by QA) mean somebody else, who may have different interests and objectives than QA and does not intend to write a QA criterion, defines what your criteria are. 'official install media' is not quite as obvious; maybe it should be a link to the Deliverables SOP when I or someone else finally gets that done (my last draft is still at https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables Your draft makes no mention of LiveUSB Creator or livecd-tools. It only mentions 'dd' or similar tools. Does this mean persistent storage, encrypted /home, and other features, are no longer supported on live media (or perhaps are simply not of concern to QA)? I gather there has been a lot of back and forth in this area of late - perhaps another case where explicit language in QA criteria may be valuable, even if it has to track evolving decisions about what sophisticated live system features will be supported. It is unlikely there will ever be perfect QA criteria, but these criteria are important: the value of the QA effort depends in significant ways on their quality. Whatever their eventual form, I hope my comments help to make them a little better. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
Gnome3 is not putting any effort into fallback mode. So my Radeon 9250 purchased new in 2006 as a mid-life upgrade for a box with 1.6GHz Pentium 4 (well above the Fedora minimum CPU) also runs only XFCE. Gnome3 forces fallback mode, where some Desktop features are *dropped* instead of emulated. Why do you feel this is relevant? X bugs are X bugs. Right, this is mostly out of scope. The actual bug here is well-known, btw - there's a blacklist for adapters that do 3D but are known not to be capable of rendering Shell properly. Currently, if your card is on that blacklist, you wind up with fallback mode, but what we really want to happen is for it to fall back to software rendering, like it does on systems where there's no 3D capability at all. That's the bug here. As ajax says it's nothing to do with X or the X test days, it's a bug in the GNOME fallback logic. Please give a specific link to a bug report which contains a similarly- succinct description, in order to make tracking easier. Thank you. -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On Mon, 2012-09-24 at 17:29 -0700, John Reiser wrote: Gnome3 is not putting any effort into fallback mode. So my Radeon 9250 purchased new in 2006 as a mid-life upgrade for a box with 1.6GHz Pentium 4 (well above the Fedora minimum CPU) also runs only XFCE. Gnome3 forces fallback mode, where some Desktop features are *dropped* instead of emulated. Why do you feel this is relevant? X bugs are X bugs. Right, this is mostly out of scope. The actual bug here is well-known, btw - there's a blacklist for adapters that do 3D but are known not to be capable of rendering Shell properly. Currently, if your card is on that blacklist, you wind up with fallback mode, but what we really want to happen is for it to fall back to software rendering, like it does on systems where there's no 3D capability at all. That's the bug here. As ajax says it's nothing to do with X or the X test days, it's a bug in the GNOME fallback logic. Please give a specific link to a bug report which contains a similarly- succinct description, in order to make tracking easier. Thank you. I don't have one offhand - I know the GNOME team knows about it (one of them explained it to me in the first place), and it's not any kind of release-blocking issue, so I've never really needed to find The Bug, if there is one. I expect mclasen or drago01 would know where it is, though. -- 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 criterion proposal: upgrade methods
On Mon, 2012-09-24 at 20:21 -0400, Richard Ryniker wrote:
I think we could link to
https://fedoraproject.org/wiki/Upgrading to define
'supported/recommendation upgrade mechanism'
OK, but to illustrate the problem with indirect references: the
Upgrading page you cite above says to read
http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/index.html
for details. This document says (Chapter 20):
Before upgrading to Fedora 17 you should first bring your current version
up to date. However, it is not then necessary to upgrade to intermediate
versions. For example, you can upgrade from Fedora 14 to Fedora 17
directly.
Therefore, it seems your recent post to this list:
http://lists.fedoraproject.org/pipermail/test/2012-September/110331.html
may be incorrect. I think you are right, but the quotation above
contradicts your statement:
Only 17-18: using the definite article 'the' rather than the indefinite
article 'a' implies this. It says 'the previous stable Fedora release' -
which strictly means only the single preceding release
My point here is that details in the QA criteria that specify explicitly
what operations must work are valuable. Indirect references to dynamic
documents (which you properly describe as not owned by QA) mean somebody
else, who may have different interests and objectives than QA and does
not intend to write a QA criterion, defines what your criteria are.
Well, to an extent, yeah. To me that's not really a problem as much as
it is an opportunity, though. ;) It's a left hand, right hand issue; the
one should know what the other is doing. As you explain above, obviously
that's not quite the case there. I don't think that's an inherent
weakness of the idea as much as it is a case where we should correct
something, though. Either we should start testing upgrades from ancient
releases and taking it seriously when they fail, or we should stop
advising people to do so in the installation guide.
Another way to put it...I'd say that interlinking the criteria and the
installation guide, as you outline it above, has provided us with a
*benefit*: we have identified an inconsistency between what the
installation guide reckons is reliable and what QA and devel are making
any kind of effort to ensure actually is reliable. If we just wrote the
criteria in some kind of silo where we had our own definitions of
everything, it wouldn't make that problem go away, would it? The
installation guide would still be out there and would still be advising
people to do something that maybe it shouldn't be advising people to do.
Given that Fedora's a collaborative effort, I'd say we should be
consciously trying to interlink between teams as much as possible as a
way to ensure we're all on the same page, not silo'ing off our efforts
from each other because we're scared of what we might find out from
working together...
'official install media' is not quite as obvious; maybe it
should be a link to the Deliverables SOP when I or someone else finally
gets that done (my last draft is still at
https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables
Your draft makes no mention of LiveUSB Creator or livecd-tools. It only
mentions 'dd' or similar tools. Does this mean persistent storage,
encrypted /home, and other features, are no longer supported on live
media (or perhaps are simply not of concern to QA)?
Before this goes viral, let me provide the all-important context. This
is the text Richard's referring to:
All image files for PC architectures should be prepared for writing to
USB directly with 'dd' or similar tools, and should be prepared for both
EFI and BIOS booting whether written to an optical disc or a USB disk.
The answer to your question is no, it doesn't mean I don't care about
litd or livecd-creator. It just means there isn't any 'preparation' work
that has to be done to an image to make it writeable via
livecd-iso-to-disk. Our images are litd-able as they pop out of the
creator. That's not the case for dd; releng has to run mkisohybrid on
the images at some point to make them dd'able. Once or twice this hasn't
got done, hence I decided to specify it in the SOP.
I gather there has
been a lot of back and forth in this area of late - perhaps another
case where explicit language in QA criteria may be valuable, even if it
has to track evolving decisions about what sophisticated live system
features will be supported.
We do in fact have this. At Alpha:
The installer must boot (if appropriate) and run on all primary
architectures, with all system firmware types that are common on those
architectures, from default live image, DVD, and boot.iso install media
when written to an optical disc and when written to a USB stick with at
least one of the officially supported methods
('at least one' is in boldface, and 'officially supported methods' links
to
Re: Release criterion proposal: upgrade methods
On Mon, 2012-09-24 at 18:15 -0700, Adam Williamson wrote: Another way to put it...I'd say that interlinking the criteria and the installation guide, as you outline it above, has provided us with a *benefit*: we have identified an inconsistency between what the installation guide reckons is reliable and what QA and devel are making any kind of effort to ensure actually is reliable. If we just wrote the criteria in some kind of silo where we had our own definitions of everything, it wouldn't make that problem go away, would it? The installation guide would still be out there and would still be advising people to do something that maybe it shouldn't be advising people to do. Given that Fedora's a collaborative effort, I'd say we should be consciously trying to interlink between teams as much as possible as a way to ensure we're all on the same page, not silo'ing off our efforts from each other because we're scared of what we might find out from working together... Not to hammer the point too much, but there's another reason, now I come to think of it. It's _precisely_ the same reason we require packages to use shared system libraries, not static linking. Let's say instead of referring to the 'Upgrading' wiki page for the definition of Fedora's 'officially recommended upgrade methods', we just read it once and write whatever it says into the criteria pages instead. What did we just do? We static linked the officially recommended upgrade methods. Now, if that's the way Fedora as a project is going to do things, we're not going to be the only ones! The installation guide will likely do the same. I'm sure releng has some document somewhere which refers to upgrade methods; that one will static link them too. The forums will probably do the same thing in a sticky thread somewhere. Now imagine we as a project decide to change our officially recommended installation method - as, indeed, it appears we are currently doing. What has to happen? Same exact problem you have when there's a vulnerability in a statically linked library: we have to go around and change every damn instance. We have to change the Upgrading page's text, the criteria page's text, the releng page's text, the installation guide, the forum sticky thread... It's a different area but the same exact problem. As a general principle, we should have *one* canonical reference point for things like this, which everything else should refer to. Then when it changes, you only have to update the canonical definition. -- 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: Selinux in development releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/24/2012 04:23 PM, Jóhann B. Guðmundsson wrote: On 09/24/2012 08:16 PM, drago01 wrote: On Mon, Sep 24, 2012 at 10:13 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: I hereby propose that we default selinux to permissive mode up to final which should just get rid of unneeded nuance during testing. -1 This would just mean we test something different then we actually ship. If there are selinux bugs they are supposed to be cough during testing and reported like any other bugs. With permissive mode we should still be able to catch all those errors and report them without all the downside that comes with having it in enforcing mode during our development releases... JBG Definitely not. Enforcing mode and Permissive mode are not equivalent. SELinux/Permission Denied can cause things to crash. I have been working since last week on SELinux/Systemd problems that happen in early boot, and would only be seen in enforcing mode. For some reason avc messages were not showup in early boot, so no one would have known about it. Dontaudit rules can cover up messages that cause applications bugs. We have been working with SELinux in enforcing mode for years now, why change now. Do you have specific errors that SELinux is causing in Fedora 18? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBhEpAACgkQrlYvE4MpobOi3ACg0sP2FGp1DbfX4knGU5nArkHh 18sAoOKKA5V/VPpQdXcZO1nyxlwzEjAG =fp0T -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On Mon, 2012-09-24 at 14:37 -0400, Martin Holec wrote: 2012-09-25 Nouveau - https://fedoraproject.org/wiki/Test_Day:2012-09-25_Nouveau Hi folks, I was just looking to start the test for Nouveau. It appears the links to the liveCDs aren't functional. Can someone please check them up once? https://fedoraproject.org/wiki/Test_Day:2012-09-25_Nouveau#Live_image -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.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: [Test-Announce] Join Fedora X Test Week - Nouveau, Radeon, Intel (2012-09-25 - 2012-09-27)
On Tue, 2012-09-25 at 12:37 +1000, Ankur Sinha wrote: On Mon, 2012-09-24 at 14:37 -0400, Martin Holec wrote: 2012-09-25 Nouveau - https://fedoraproject.org/wiki/Test_Day:2012-09-25_Nouveau Hi folks, I was just looking to start the test for Nouveau. It appears the links to the liveCDs aren't functional. Can someone please check them up once? https://fedoraproject.org/wiki/Test_Day:2012-09-25_Nouveau#Live_image I haven't built them yet. I should probably do that, shouldn't I. And send out the announcements. Sigh. Somehow, I thought this wasn't happening till Thursday... -- 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: Selinux in development releases
On Mon, 2012-09-24 at 20:13 +, Jóhann B. Guðmundsson wrote: I hereby propose that we default selinux to permissive mode up to final which should just get rid of unneeded nuance during testing. for the record, I'm -1 for the reasons stated later in the thread. -- 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
Fedora 16 updates-testing report
The following Fedora 16 Security updates need testing: Age URL 6 https://admin.fedoraproject.org/updates/FEDORA-2012-14363/phpldapadmin-1.2.2-3.gitbbedf1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-14295/moodle-2.1.8-1.fc16 6 https://admin.fedoraproject.org/updates/FEDORA-2012-14322/pcp-3.6.8-1.fc16 78 https://admin.fedoraproject.org/updates/FEDORA-2012-10402/bcfg2-1.2.3-1.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-14452/bacula-5.0.3-33.fc16 50 https://admin.fedoraproject.org/updates/FEDORA-2012-11526/dokuwiki-0-0.11.20120125.b.fc16 13 https://admin.fedoraproject.org/updates/FEDORA-2012-13839/ghostscript-9.05-2.fc16 13 https://admin.fedoraproject.org/updates/FEDORA-2012-13824/libxml2-2.7.8-8.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-14462/fetchmail-6.3.22-1.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14048/libxslt-1.1.26-9.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14102/seamonkey-2.12.1-1.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-14076/dhcp-4.2.4-1.P2.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14030/bind-9.8.3-4.P3.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14046/spice-gtk-0.11-5.fc16 81 https://admin.fedoraproject.org/updates/FEDORA-2012-10314/revelation-0.4.14-1.fc16 1 https://admin.fedoraproject.org/updates/FEDORA-2012-14654/tor-0.2.2.39-1600.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14097/libguac-0.6.3-1.fc16,libguac-client-vnc-0.6.0-8.fc16,guacd-0.6.1-3.fc16,guacamole-common-0.6.1-2.fc16,guacamole-ext-0.6.1-2.fc16,guacamole-common-js-0.6.1-2.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14126/dbus-1.4.10-4.fc16 0 https://admin.fedoraproject.org/updates/FEDORA-2012-14707/openjpeg-1.4-14.fc16 The following Fedora 16 Critical Path updates have yet to be approved: Age URL 2 https://admin.fedoraproject.org/updates/FEDORA-2012-14626/qrencode-3.3.1-4.fc16 2 https://admin.fedoraproject.org/updates/FEDORA-2012-14613/xorg-x11-drv-intel-2.20.8-1.fc16 3 https://admin.fedoraproject.org/updates/FEDORA-2012-14509/poppler-data-0.4.5-6.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14170/perl-5.14.2-201.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14126/dbus-1.4.10-4.fc16 7 https://admin.fedoraproject.org/updates/FEDORA-2012-14186/nspr-4.9.2-1.fc16 13 https://admin.fedoraproject.org/updates/FEDORA-2012-13824/libxml2-2.7.8-8.fc16 The following builds have been pushed to Fedora 16 updates-testing couchdb-1.1.1-4.fc16.1 dhcp-4.2.4-1.P2.fc16 fedora-review-0.3.0-1.fc16 openjpeg-1.4-14.fc16 paps-0.6.8-22.fc16 pdns-3.1-3.fc16 pekwm-0.1.15-1.fc16 perl-GraphViz-2.11-1.fc16 php-phpunit-File-Iterator-1.3.2-1.fc16 postgresql-9.1.6-1.fc16 Details about builds: couchdb-1.1.1-4.fc16.1 (FEDORA-2012-14711) A document database server, accessible via a RESTful JSON API Update Information: * Fixed compatibility with R15B ChangeLog: * Mon Sep 24 2012 Peter Lemenkov lemen...@gmail.com - 1.1.1-4.1 - Rebuild * Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1.1-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Wed Jul 4 2012 Peter Lemenkov lemen...@gmail.com - 1.1.1-3 - Improve systemd support * Wed May 16 2012 Peter Lemenkov lemen...@gmail.com - 1.1.1-2 - Updated systemd files (added EnvironmentFile option) References: [ 1 ] Bug #859863 - F16 RPM version of couchdb compiled with wrong version of Erlang https://bugzilla.redhat.com/show_bug.cgi?id=859863 dhcp-4.2.4-1.P2.fc16 (FEDORA-2012-14076) Dynamic host configuration protocol software Update Information: This is security bugfix release fixing a security vulnerability. ChangeLog: * Mon Sep 24 2012 Jiri Popelka jpope...@redhat.com - 12:4.2.4-1.P2 - 4.2.4-P2 (#786023) * Thu Sep 13 2012 Tomas Hozza tho...@redhat.com - 12:4.2.3-12.P2 - fix for CVE-2012-3955 (#856770) References: [ 1 ] Bug #856766 - CVE-2012-3955 dhcp: reduced expiration time of an IPv6 lease may cause dhcpd to crash https://bugzilla.redhat.com/show_bug.cgi?id=856766
Re: Release criterion proposal: upgrade methods
You have convinced me, Adam. How much does it contribute to release quality if excellent test criteria are perfectly validated, but the documentation the end-user reads says Fedora does something different? To that user, what he sees is clearly a fault. QA may not be explicitly requested to vet end-user documentation, but your admonition to have one shared description, not multiple and possibly divergent descriptions, makes a lot of sense. If a situation arises where inconsistent documentation cannot be reconciled, that is the time to seek a modification to QA criteria to make clear what tests will be performed and what function validated.. You have played trump cards, and converted my problems into benefits. Wow. I worry some documentaiton pages may not make clear exactly what Fedora version or time they describe, especially when they are located by search engines that process queries with no specification about what Fedora version is of interest, but this may actually make your position more relevant. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
