Re: Problem booting/install Fedora-Server-netinst-x86_64-21_Alpha.iso
On Mon, 2014-09-29 at 20:32 -0700, Adam Williamson wrote: When I tryed to boot the CD on HP Compaq DC5850 it just restart again and again (looping). On the Dell Dimension 3100 it just stoped displaying: ISOLINUX 6.02 There was no problem making netinstall on VM in KVM/qemu. So the question is what can be wrong? I will burn Fedora-Server-DVD-x86_64-21_Alpha.iso on DVD and see if I can install F21-Alpha from thw DVD. I have now burn the DVD with same result as before. Are I the onlyone having this problem? Probably no! See https://lists.fedoraproject.org/pipermail/test/2014-September/122716.html That definitely is not the same bug. It occurred much later in boot, and anyway its cause was definitely identified and definitely does not exist in RC1. or https://bugzilla.redhat.com/show_bug.cgi?id=1135793. This one also seems to occur slightly later, and also the reporter is booting from USB, not a DVD. I did not in fact test 21 Alpha on a real silver round spinny disc thing (the first build since F12 I haven't tested that on :) Did anyone else? So this is definitely not precisely our finest hour: I've just confirmed that neither the Server x64 netinst image nor the Workstation x64 live image from Alpha boots on my laptop when written to a DVD-R. As described, they hit 'SYSLINUX' then reboot. I will note for posterity that since joining Fedora I've tested every single bleeding milestone this way *except F21 Alpha* and of course that's the single solitary one which decided to break. I further note that the effect of the wording of the 'Default boot and install' matrix and 'QA:Testcase_Boot_default_install' is to hedge between optical and USB media - on a very strict reading, we don't require optical media testing to occur (only *either* optical media *or* USB media), but that wasn't actually the intent. We really should be testing both. The criteria clearly require that both should work at Alpha. So, yeah, that's a bit of a brown paper bag :| The bug report is https://bugzilla.redhat.com/show_bug.cgi?id=1141496 , and I've nominated it as a Beta blocker, obviously. I'll put a big warning in Common Bugs. It is pretty amusing that it seems that like five people have noticed this so far, and none of the press coverage mentions it. Useful anecdata for the 'optical media vs. USB' debate if nothing else =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Installing nvidia driver on Fedora 21 crashes my system
I have been using Fedora 21 since the alpha release and overall it has worked wonderfully (it has never one crashed and I use it every day), even to the extent of noticing a reduction in the memory consumed and processor usage when I have all my usual application up and running. One thing though is, I find my screen is kind of jerky when I scroll and this has never happened with other Fedora releases. I therefore tried to install nvidia. I have always followed the steps from http://www.if-not-true-then-false.com/2014/fedora-20-nvidia-guide/. It basically boils down to: Install RPMFusion *yum install akmod-nvidia xorg-x11-drv-nvidia-libs kernel-devel acpid* yum install kernel-PAE-devel mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img dracut /boot/initramfs-$(uname -r).img $(uname -r) *reboot* However, after reboot, I get the rather interesting message: Oh no something has gone wrong A problem has occured and the system can't recover. Please logout and try again. I've never had any issues installing nvidia in the past on any Fedora release. Hoping for some solutions on how to fix this. Thanks in the meantime. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installing nvidia driver on Fedora 21 crashes my system
On 09/30/2014 03:38 AM, Napoleon Quashie wrote: I have been using Fedora 21 since the alpha release and overall it has worked wonderfully (it has never one crashed and I use it every day), even to the extent of noticing a reduction in the memory consumed and processor usage when I have all my usual application up and running. One thing though is, I find my screen is kind of jerky when I scroll and this has never happened with other Fedora releases. I therefore tried to install nvidia. I have always followed the steps from http://www.if-not-true-then-false.com/2014/fedora-20-nvidia-guide/. It basically boils down to: Install RPMFusion *yum install akmod-nvidia xorg-x11-drv-nvidia-libs kernel-devel acpid* yum install kernel-PAE-devel mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img dracut /boot/initramfs-$(uname -r).img $(uname -r) *reboot* However, after reboot, I get the rather interesting message: Oh no something has gone wrong A problem has occured and the system can't recover. Please logout and try again. I've never had any issues installing nvidia in the past on any Fedora release. Hoping for some solutions on how to fix this. Thanks in the meantime. Installing the Nvidia driver has always been a bit tricky at best. This is complicated by the recent tendency to boot the wrong kernel. I run a 64 bit system so my current routine is: (install rpmfusion) yum install xorg-x11-dev-nvidia edit /boot/g*2/*cfg - replace rhgb quiet with nomodeset reboot, taking care to boot the correct entry. So far this works for me. If the kernel is updated, I usually have to remove xorg-x11-drv-nvidia, reboot, and install xorg-x11-drv-nvidia all over. The Nvidia driver is so much nicer than Nouveau it's worth the fuss to get it installed. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installing nvidia driver on Fedora 21 crashes my system
On Tue, Sep 30, 2014 at 11:38:12AM +0100, Napoleon Quashie wrote: I have been using Fedora 21 since the alpha release and overall it has worked wonderfully (it has never one crashed and I use it every day), even to the extent of noticing a reduction in the memory consumed and processor usage when I have all my usual application up and running. One thing though is, I find my screen is kind of jerky when I scroll and this has never happened with other Fedora releases. I therefore tried to install nvidia. I have always followed the steps from http://www.if-not-true-then-false.com/2014/fedora-20-nvidia-guide/. It basically boils down to: Install RPMFusion *yum install akmod-nvidia xorg-x11-drv-nvidia-libs kernel-devel acpid* yum install kernel-PAE-devel mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img dracut /boot/initramfs-$(uname -r).img $(uname -r) *reboot* However, after reboot, I get the rather interesting message: Oh no something has gone wrong A problem has occured and the system can't recover. Please logout and try again. I've never had any issues installing nvidia in the past on any Fedora release. Hoping for some solutions on how to fix this. Thanks in the meantime. nVidia drivers only work with certain kernels, and it looks to me like that's your issue. I run the nvidia drivers, but I don't use RPMFusion. For me the workflow looks like this (starting from nouveau): 1 - sudo yum update 2 - reboot and download nVidia drivers 3 - ctrl-alt-f2 and log in again 4 - sudo init 3 5 - install nVidia drivers (this will autobackup your x conf) 6 - sudo init 5 (will work if the kernel matches what nVidia provides) 7 - ctrl-alt-f2 and log out of that terminal 8 - ctrl-alt-f1 to get back to the GUI and your day If you get the same error after completing step 6, then you just have to wait until nVidia provides new drivers for updated kernels. If you have to recover, follow these steps (assuming you're starting from a failed step 6): 1 - ctrl-alt-f2 2 - sudo init 3 3 - uninstall the nvidia drivers (run with --uninstall), this will ask you if you want to restore your previous settings, pick yes 4 - sudo init 5 (this should bring you back to the GUI) 5 - ctrl-alt-f2 and log out of that terminal 6 - ctrl-alt-f1 to get back to the GUI With running the nVidia blobs you're at the mercy of nVidia for support and which kernel the driver works with. If you use RPMFusion, you're also at the mercy of the RPMFusion packagers. AIUI they do a pretty good job of keeping the packages up to date, but I prefer to just do it myself and remove that extra level. If you get a working kernel, you can always '-X kernel*' when you do a yum update to not include kernel updates. Though, if the kernel update has security fixes, skipping it is probably a bad idea and you should just wait on nVidia to publish new drivers. Hope that helps. If you still want to use the RPMFusion repos, then you could probably get help filing a bug [0] with them, in #rpmfusion on freenode, or mailing their list [1]. But this doesn't look or feel like a bug with *Fedora* but rather that the nVidia drivers don't support the kernel you have. [0] http://rpmfusion.org/ReportingBugs [1] http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Installing nvidia driver on Fedora 21 crashes my system
On 09/30/2014 09:24 AM, Mike Ruckman wrote: On Tue, Sep 30, 2014 at 11:38:12AM +0100, Napoleon Quashie wrote: I have been using Fedora 21 since the alpha release and overall it has worked wonderfully (it has never one crashed and I use it every day), even to the extent of noticing a reduction in the memory consumed and processor usage when I have all my usual application up and running. One thing though is, I find my screen is kind of jerky when I scroll and this has never happened with other Fedora releases. I therefore tried to install nvidia. I have always followed the steps from http://www.if-not-true-then-false.com/2014/fedora-20-nvidia-guide/. It basically boils down to: Install RPMFusion *yum install akmod-nvidia xorg-x11-drv-nvidia-libs kernel-devel acpid* yum install kernel-PAE-devel mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img dracut /boot/initramfs-$(uname -r).img $(uname -r) *reboot* However, after reboot, I get the rather interesting message: Oh no something has gone wrong A problem has occured and the system can't recover. Please logout and try again. I've never had any issues installing nvidia in the past on any Fedora release. Hoping for some solutions on how to fix this. Thanks in the meantime. nVidia drivers only work with certain kernels, and it looks to me like that's your issue. I run the nvidia drivers, but I don't use RPMFusion. For me the workflow looks like this (starting from nouveau): 1 - sudo yum update 2 - reboot and download nVidia drivers 3 - ctrl-alt-f2 and log in again 4 - sudo init 3 5 - install nVidia drivers (this will autobackup your x conf) 6 - sudo init 5 (will work if the kernel matches what nVidia provides) 7 - ctrl-alt-f2 and log out of that terminal 8 - ctrl-alt-f1 to get back to the GUI and your day If you get the same error after completing step 6, then you just have to wait until nVidia provides new drivers for updated kernels. If you have to recover, follow these steps (assuming you're starting from a failed step 6): 1 - ctrl-alt-f2 2 - sudo init 3 3 - uninstall the nvidia drivers (run with --uninstall), this will ask you if you want to restore your previous settings, pick yes 4 - sudo init 5 (this should bring you back to the GUI) 5 - ctrl-alt-f2 and log out of that terminal 6 - ctrl-alt-f1 to get back to the GUI With running the nVidia blobs you're at the mercy of nVidia for support and which kernel the driver works with. If you use RPMFusion, you're also at the mercy of the RPMFusion packagers. AIUI they do a pretty good job of keeping the packages up to date, but I prefer to just do it myself and remove that extra level. If you get a working kernel, you can always '-X kernel*' when you do a yum update to not include kernel updates. Though, if the kernel update has security fixes, skipping it is probably a bad idea and you should just wait on nVidia to publish new drivers. Hope that helps. If you still want to use the RPMFusion repos, then you could probably get help filing a bug [0] with them, in #rpmfusion on freenode, or mailing their list [1]. But this doesn't look or feel like a bug with *Fedora* but rather that the nVidia drivers don't support the kernel you have. [0] http://rpmfusion.org/ReportingBugs [1] http://lists.rpmfusion.org/mailman/listinfo/rpmfusion-users I have been using Fedora 21 Alpha workstation since it was released and have an NVIDIA driver ( 343.13 - BETA 64bit) installed that is working fine. I'll try to run through the steps I did to install the driver. using yum or dnf update #install kernel-devel gcc download NVIDIA driver #chmod +x NVIDIA.run (make driver executable) #vi /etc/modeprobe.d/blacklist.conf and insert blacklist nouveau (less quotes) #vi /etc/sysconfig/grub and insert rd.driver.blacklist=nouveau (less quotes) and the end of the line GRUB_CMDLINE_LINUX refresh grub #grub2-mkconfig -o /boot/grub2/grub.cfg #remove xorg-x11-drv-nouveau.x86_64 reboot to init 3 (for instance in grub menu with version highlighted hit e to edit and insert init 3 at the end of the linux line and then F10 cd to where you downloaded NVIDIA driver #./NVIDIA.run let NVIDIA install 32 bit compatibility and update xconfig utility reboot system or init 5 and you will find a properties page for the NVIDIA driver Reynold DeMarco Jr. reynoldli...@gmail.com mailto:reynoldli...@gmail.com Mobile: 858-603-1725 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta / Final release criteria for Workstation
On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote: All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy. [1] (This is already mentioned at the very bottom of the policy.) That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :) We used to have polish criteria for the desktop, and then we'd inevitably find issues late in Final testing and no-one would want to block release for them, it got to be a bit absurd, which is why we dropped those criteria a couple of releases back. I'm fine with having them, but it needs a concerted effort to actually live up to them, and to really consider them to block the release. On Mon, 2014-09-29 at 17:27 -0700, Adam Williamson wrote: We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting? a11y is a good target not just for release criteria, because it is absolutely essential for a few users, but also for a test plan, since an a11y regression is quite likely to be missed by developers. Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet. This may be too subjective for a release criterion. How would we phrase it? Qt apps must not look terrible doesn't seem quite right The Tech Spec I was reading as I wrote my mail (sorry if I didn't make that clear) states that GNOME and KDE must use a unified appearance. That's what I was referring to. [1] https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launchers -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta / Final release criteria for Workstation
On Tue, 2014-09-30 at 09:50 -0700, Adam Williamson wrote: On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote: All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy. [1] (This is already mentioned at the very bottom of the policy.) That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :) Further note: the agreed upon core desktop experience *really* needs to be a link pointing to a formal definition of what that includes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Problem booting/install Fedora-Server-netinst-x86_64-21_Alpha.iso
On Mon, 2014-09-29 at 23:41 -0700, Adam Williamson wrote: On Mon, 2014-09-29 at 20:32 -0700, Adam Williamson wrote: When I tryed to boot the CD on HP Compaq DC5850 it just restart again and again (looping). On the Dell Dimension 3100 it just stoped displaying: ISOLINUX 6.02 There was no problem making netinstall on VM in KVM/qemu. So the question is what can be wrong? I will burn Fedora-Server-DVD-x86_64-21_Alpha.iso on DVD and see if I can install F21-Alpha from thw DVD. I have now burn the DVD with same result as before. Are I the onlyone having this problem? Probably no! See https://lists.fedoraproject.org/pipermail/test/2014-September/122716.html That definitely is not the same bug. It occurred much later in boot, and anyway its cause was definitely identified and definitely does not exist in RC1. or https://bugzilla.redhat.com/show_bug.cgi?id=1135793. This one also seems to occur slightly later, and also the reporter is booting from USB, not a DVD. I did not in fact test 21 Alpha on a real silver round spinny disc thing (the first build since F12 I haven't tested that on :) Did anyone else? So this is definitely not precisely our finest hour: I've just confirmed that neither the Server x64 netinst image nor the Workstation x64 live image from Alpha boots on my laptop when written to a DVD-R. As described, they hit 'SYSLINUX' then reboot. For the record, pjones says it works for him, so this seems at least to be somehow hardware dependent (and it means that possibly someone *did* test it for Alpha, just not someone with an affected system). We're continuing to investigate. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Problem booting/install Fedora-Server-netinst-x86_64-21_Alpha.iso
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 30 Sep 2014 10:20:58 -0700 Adam Williamson adamw...@fedoraproject.org wrote: On Mon, 2014-09-29 at 23:41 -0700, Adam Williamson wrote: On Mon, 2014-09-29 at 20:32 -0700, Adam Williamson wrote: When I tryed to boot the CD on HP Compaq DC5850 it just restart again and again (looping). On the Dell Dimension 3100 it just stoped displaying: ISOLINUX 6.02 There was no problem making netinstall on VM in KVM/qemu. So the question is what can be wrong? I will burn Fedora-Server-DVD-x86_64-21_Alpha.iso on DVD and see if I can install F21-Alpha from thw DVD. I have now burn the DVD with same result as before. Are I the onlyone having this problem? Probably no! See https://lists.fedoraproject.org/pipermail/test/2014-September/122716.html That definitely is not the same bug. It occurred much later in boot, and anyway its cause was definitely identified and definitely does not exist in RC1. or https://bugzilla.redhat.com/show_bug.cgi?id=1135793. This one also seems to occur slightly later, and also the reporter is booting from USB, not a DVD. I did not in fact test 21 Alpha on a real silver round spinny disc thing (the first build since F12 I haven't tested that on :) Did anyone else? So this is definitely not precisely our finest hour: I've just confirmed that neither the Server x64 netinst image nor the Workstation x64 live image from Alpha boots on my laptop when written to a DVD-R. As described, they hit 'SYSLINUX' then reboot. For the record, pjones says it works for him, so this seems at least to be somehow hardware dependent (and it means that possibly someone *did* test it for Alpha, just not someone with an affected system). We're continuing to investigate. I did test the install DVD on a supermicro 1u server I have in the basement. It doesnt pxe boot at all. It booted and installed fine. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUKulsAAoJEH7ltONmPFDR3gcP/0TIFvX/SSlUBEPWpkDBw6fN DoZxDpuDk0Op6+wyoyuOlp09RO+mjZXw9D3MShoI2+zsnA4VR9djVyA7YfpKCgPW bVc4nzqbhXR5va1I6AVx1YAj6sGEe9nm9eMpUUydSH50gv2ufo/4WkCoAZ96s9YG gY3qB4NXgvixDXjtDXhffjvDiE1Do8ftMxuWy72XaHWFAyP7uOpg85PvsYYr4Rhq OkzemlqP34rawq+tA9JMBIPDgiS4H3yLJ41HrpDTM8OaH8JPjyE/svW+JElZb1SH QWStXquAlp/mHNzMkBLMWOUSfJ/6UuMaHRJXVJsI1kCaKiZMVpOf5x+LYcuNudep dVdAbZycGD2W58DZT8nKRla8k+fRorXEOHkftKffxcQF58/8VR0mLRCEDae7nz34 JZskONKoOWIlixAkHgRZ1zWiUYDuUculrJfr/arfXfbNfkKzuirbqE14wK7mF7lF mJ/C4vv63Un7h3V8De9wZLFiCVvdmiRGxIq2kQcpm8VpcF+er4q32Snu/66KDoWg xN7iRhStZZBX/iwpk+vZLj0X3TaVtUIKuCfeD7zlyDJ2R/bOyuIfDvM6Lj/rdsdm MZ71dXKMAjkPCu3iRN0zZEiMNRkLLR4gt50HhDPMlfD3+psI7j50y/qb6GVVoMdG XvrViVAUU7J5F2u/LIvu =HWdY -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Yumex
Yumex should work fine in F21, could be a problem with Policykit, please make a bugzilla report and I will help you track down the issue. My plan is to replace yumex 3.0.x, with the 4.x version based on dnf at F22, http://www.yumex.dk/2014/09/yum-extender-407-released-dnf.html Tim On Tue, Sep 30, 2014 at 12:18 AM, Reynold reynoldli...@gmail.com wrote: I am trying to use yumex on fedora 21 alpha workstation. Every time I try to install a package with it I get this error message: Backend not running as expected Yum Extender will terminate -- exit code : 1 I would like to know if yumex will run on fedora 21 or if it will be dropped in the future. If anyone knows of this error and can lead me to a fix please reply. Thanks in advance. Reynold -- 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: Beta / Final release criteria for Workstation
On Tue, 2014-09-30 at 09:50 -0700, Adam Williamson wrote: That sounds workable, so long as someone's actually making sure we *do* comply with those. Has anyone checked that yet? I'd rather not throw it in the criteria and then have to fudge it immediately :) I don't think all apps are currently in compliance. There were some issues with high contrast support, last I checked, but those apps may all have been dropped already. And the LibreOffice apps' names are too long. The thinking behind these requirements is not the release is blocked until the app is fixed, but the release is blocked until the app is fixed OR the app is dropped -- there's flexibility to choose the best approach on a per-app basis. If Weather or Music is still missing a high contrast icon, we'd probably just drop the app and move on with our lives. If the issue is with a more important app outside our control (e.g. if LibreOffice were to regain a dependency on OpenJDK Policy Editor), then the blocker criterion is good incentive for the problem to be fixed. 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: Proposing new dual booting release criteria
On Sep 29, 2014, at 3:32 AM, Adam Williamson adamw...@fedoraproject.org wrote: 1. The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. This one is simply dropping the UEFI get-out clause from the current Final criterion. I am a big solid +1 to this. If no-one has any objections let's get this one implemented this week. Agreed. 2. The installer must be able to install into free space alongside an existing OS X installation, install and configure a bootloader that will boot Fedora; if the boot menu presents OS X entries, they should boot OS X. (so far as I could see on a quick skim back through the thread, this was the most recent version of the OS X proposal). I am +1 to this too, it seems reasonable. We could perhaps insert that the Fedora install process should not render the OS X install unbootable from the EFI boot manager? If you want to, I won't oppose it. But it's really corner case to make it unbootable from the built-in boot manager, to the degree the installation is probably damaged which then triggers the corruption criterion. So we could just cross this land mine if we ever get to it, and call it corruption and pull that card out to block on. 3. The installer must be able to install into free space alongside an existing GNU/Linux installation, install and configure a bootloader that will boot both systems, within the limitations of the upstream bootloader. Within the limitations? [show] Purpose of this clause is to not require us to fix upstream bootloader bugs or design limitations. This is the complex one we're still struggling with. I think the above is possibly a little broad and could do with either limiting to stock-ish installs of 'commonly-used' or 'popular' distributions, or some more vaguely-worded wiggle room clause. I don't want to have to come up with some kind of criterion judo to justify us not slipping Final release three weeks to fix, I don't know, dual-boot with an xfs install of Fermi or something (no disrespect intended, Fermi users…) I understand the logic. I just think that if we step on Fermi's tail and it's self-evidently our fault, we should block on that. I mean, the only way this gets better is if distros agree to standardize on something: either on a handful of layouts (probably fat chance at that) or on a self-describing system that allows arbitrary yet sane layouts. But right now distros are comfortable stepping on each others tails (sometimes their own). Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-21 Branched report: 20140930 changes
Compose started at Tue Sep 30 16:27:39 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [check-mk] check-mk-agent-1.2.4p5-1.fc21.armv7hl requires /usr/bin/ksh check-mk-multisite-1.2.4p5-1.fc21.noarch requires /usr/bin/ksh [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gdb-heap] gdb-heap-0.5-18.fc21.armv7hl requires glibc(armv7hl-32) = 0:2.19.90 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [glite-px-proxyrenewal] glite-px-proxyrenewal-1.3.35-4.fc21.armv7hl requires libmyproxy.so.5 glite-px-proxyrenewal-libs-1.3.35-4.fc21.armv7hl requires libmyproxy.so.5 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [js-of-ocaml] js-of-ocaml-1.3.2-4.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-pa-monad] ocaml-pa-monad-6.0-15.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-pgocaml] ocaml-pgocaml-1.6-7.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [ocaml-pxp] ocaml-pxp-1.2.4-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5
rawhide report: 20140930 changes
Compose started at Tue Sep 30 17:31:06 UTC 2014 Broken deps for i386 -- [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [eclipse-rse] eclipse-rse-3.6.0-2.fc22.noarch requires osgi(org.eclipse.rse.services) = 0:3.3.0 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia]
Validation results categories: just have Alpha, Beta and Final?
Hi, folks. So as I've been playing with relval, I've been wondering why we have 'TC' and 'RC' results page categories. That is, we have a top-level 'Test Results' category, then we have a category for each release which is a member of that category (e.g. Category:Fedora_20_Test_Results ) , and then under that we have: Fedora 20 Alpha RC Test Results Fedora 20 Alpha TC Test Results Fedora 20 Beta RC Test Results Fedora 20 Beta TC Test Results Fedora 20 Final RC Test Results Fedora 20 Final TC Test Results I'm not sure there's any real reason to split them between TC and RC like that. I'd think it'd be more likely someone would want to see all the Alpha validation pages, not *just* the TC or RC pages. What do people think? Should we just have: Fedora 20 Alpha Test Results Fedora 20 Beta Test Results Fedora 20 Final Test Results ? It wouldn't be too difficult to convert existing results to this layout, I don't think. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposed Server release criteria for F21 Beta and Final
On Mon, 2014-09-29 at 17:19 -0700, Adam Williamson wrote: Hi, folks. So, I drew up a rough draft of the Server release criteria for Beta and Final as I suggest they might be. We could kick it around at tomorrow's meeting if desired. Here we go: So, here's the second draft of the Beta criteria, with input from today's meeting incorporated. TC1 is rolling now or soon, so I'd like to put these into effect ASAP - if no-one has objections, I'll probably push them out live tomorrow. For now I suggest we stuff the FreeIPA requirements into the criteria explicitly denoted as a temporary measure, and for Final or F22 we implement the plan to have role requirements defined somewhere else for the criteria to reference. - CUT HERE --- === Remote logging === It must be possible to forward system logs to a remote system using Server packages. === Firewall configuration === Release-blocking roles must be able to report their status in regard to the system firewall as described in the [[Server/Technical_Specification#Firewall|technical specification]]. === Roles === Release-blocking roles and the supported role configuration interfaces must meet the core functional [[Server/Technical_Specification#Role_Definition_Requirements|Role Definition Requirements]] to the extent that supported roles can be successfully started, stopped, brought to a working configuration, and queried. === Cockpit management interface === It must be possible to log in to the default Cockpit instance and use it to: * View the system's logs * View the system's running services * Enrol the system to a FreeIPA or Active Directory domain === Domain controller role === '''Note''': role requirements are not expected to live in the Release Criteria in future. The inclusion of requirements for the Server product's initial role is a one-time exception for Fedora 21. With the Domain Controller role active and correctly configured: * Multiple clients must be able to enrol and unenrol in the domain * Client systems must be able to authenticate users with Kerberos * The FreeIPA configuration web UI must be available and allow at least basic configuration of user accounts and permissions - CUT HERE --- How does that sound to everyone? Good enough for a go? Thanks! We also need test cases to back these criteria. I can work on those, but help would certainly be appreciated. Creating test cases is a basic use of mediawiki templating, but it's pretty easy, and explained at http://fedoraproject.org/wiki/QA:SOP_test_case_creation . You can also simply take a look at the source of a simple existing test case, like https://fedoraproject.org/wiki/QA:Testcase_Server_cockpit_default or https://fedoraproject.org/wiki/QA:Testcase_kickstart_firewall , and base your test case off of that. I'm available on IRC for any questions, and remember any little detail things can be fixed up later, don't sweat them too much. If you do take a cut at creating a test case, please mail the list so I or someone else can check it does the little things right! Thanks :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta / Final release criteria for Workstation
On Mon, 2014-09-29 at 20:41 -0500, Michael Catanzaro wrote: All applications installed by default in Fedora Workstation must comply with each MUST and MUST NOT guideline in the Applications and Launchers policy. [1] (This is already mentioned at the very bottom of the policy.) So Beta TC1 request is filed now, and I'd like to get the criteria in place (and then test cases) ASAP. I'm therefore proposing to make this a Beta criterion tomorrow or so if no objections are filed. (We can always adjust later). We can then write a test case for it. On Mon, 2014-09-29 at 17:27 -0700, Adam Williamson wrote: We don't really have criteria relating to a11y or complex input methods; this isn't Workstation-y in particular, but something that might be interesting? a11y is a good target not just for release criteria, because it is absolutely essential for a few users, but also for a test plan, since an a11y regression is quite likely to be missed by developers. I'd just want to be sure we're actually in shape to enforce any requirements we decide to set. If anyone has a realistic criterion / set of criteria for a11y stuff they'd like to propose, we can certainly look at including that. This has to be stuff we can *actually stand behind* for F21 Beta / Final (as appropriate). It's generally expected that all release criteria are backed by test cases, there are conventions/templates for both associating criteria with test cases (the References sub-note for all criteria is expected to cite at least one associated test case) and test cases with criteria (test cases that enforce release criteria are expected to include a template which produces an admon/info notice explaining which release criterion they enforce, see https://fedoraproject.org/wiki/QA:Testcase_kickstart_firewall for an example). So, I'd certainly be intending that we create test cases (or appropriately extend existing ones with the template and categorization, where they exist) for any criteria we add. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta / Final release criteria for Workstation
On Mon, Sep 29, 2014 at 5:27 PM, Adam Williamson adamw...@fedoraproject.org wrote: Appearance is something we'd want to enforce if it were actually done, but I get the impression the Qt variant of Adwaita isn't actually written yet. There's no need for such a thing. Qt renders apps with native GTK widgets when run in a GTK environment like GNOME. The only caveat is Qt 4 only supports GTK 2, so the vast majority of Qt apps will get rendered with GTK2 at the present time. As stuff moves to Qt 5, it will start getting rendered with GTK 3 when run in GNOME. So unless you consider GTK2 Adwaita ugly, a criterion for this should be okay. ;-) -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Validation results categories: just have Alpha, Beta and Final?
On Tue, Sep 30, 2014 at 05:29:07PM -0700, Adam Williamson wrote: Hi, folks. So as I've been playing with relval, I've been wondering why we have 'TC' and 'RC' results page categories. That is, we have a top-level 'Test Results' category, then we have a category for each release which is a member of that category (e.g. Category:Fedora_20_Test_Results ) , and then under that we have: Fedora 20 Alpha RC Test Results Fedora 20 Alpha TC Test Results Fedora 20 Beta RC Test Results Fedora 20 Beta TC Test Results Fedora 20 Final RC Test Results Fedora 20 Final TC Test Results I'm not sure there's any real reason to split them between TC and RC like that. I'd think it'd be more likely someone would want to see all the Alpha validation pages, not *just* the TC or RC pages. What do people think? Should we just have: Fedora 20 Alpha Test Results Fedora 20 Beta Test Results Fedora 20 Final Test Results ? It wouldn't be too difficult to convert existing results to this layout, I don't think. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net It makes sense to me. I'm a +1 to having less pages tracking the same thing - you know, until we have a proper TCMS that isn't a wiki :P -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 20 updates-testing report
The following Fedora 20 Security updates need testing: Age URL 152 https://admin.fedoraproject.org/updates/FEDORA-2014-5897/nrpe-2.15-2.fc20 46 https://admin.fedoraproject.org/updates/FEDORA-2014-9474/pipelight-0.2.7.3-3.fc20 21 https://admin.fedoraproject.org/updates/FEDORA-2014-10458/torque-3.0.4-5.fc20 21 https://admin.fedoraproject.org/updates/FEDORA-2014-10451/geary-0.6.3-1.fc20 21 https://admin.fedoraproject.org/updates/FEDORA-2014-10468/icecream-1.0.1-8.20140822git.fc20 17 https://admin.fedoraproject.org/updates/FEDORA-2014-10790/squid-3.3.13-2.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11353/xen-4.3.3-2.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11415/nginx-1.4.7-3.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11376/nodejs-qs-0.6.6-3.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11421/nodejs-send-0.3.0-4.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11462/suricata-2.0.4-1.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11430/ca-certificates-2014.2.1-1.1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11744/seamonkey-2.29.1-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11641/qemu-1.6.2-9.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11630/rubygem-bundler-1.7.3-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11697/openstack-glance-2013.2.4-1.fc20 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11727/mediawiki-1.23.4-1.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-11850/fish-2.1.1-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11886/golang-1.3.2-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11892/openstack-neutron-2013.2.4-4.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11895/check-mk-1.2.4p5-2.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11924/ctags-5.8-16.fc20 The following Fedora 20 Critical Path updates have yet to be approved: Age URL 11 https://admin.fedoraproject.org/updates/FEDORA-2014-11014/squashfs-tools-4.3-8.fc20 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11482/libdvdnav-5.0.1-1.fc20,libdvdread-5.0.0-1.fc20 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11519/tracker-0.16.4-3.fc20 1 https://admin.fedoraproject.org/updates/FEDORA-2014-11843/dash-0.5.8-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11928/sudo-1.8.11-1.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11884/emacs-24.3-25.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11932/selinux-policy-3.12.1-188.fc20 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11857/cheese-3.10.2-2.fc20 The following builds have been pushed to Fedora 20 updates-testing atril-1.8.1-1.fc20 autotrash-0.1.5-2.fc20 caja-1.8.2-1.fc20 check-mk-1.2.4p5-2.fc20 cheese-3.10.2-2.fc20 ctags-5.8-16.fc20 dreamchess-0.2.1-5.RC1.fc20 emacs-24.3-25.fc20 engrampa-1.8.1-1.fc20 golang-1.3.2-1.fc20 ibus-table-1.9.1-1.fc20 ibus-table-others-1.3.5-1.fc20 jss-4.2.6-35.fc20 mock-1.1.41-3.fc20 nfs-ganesha-2.1.0-7.fc20 openstack-neutron-2013.2.4-4.fc20 openstack-sahara-2014.1.0-14.fc20 perl-Digest-SHA3-0.22-1.fc20 perl-Excel-Writer-XLSX-0.78-1.fc20 perl-Tangerine-0.05-1.fc20 python-bugzilla2fedmsg-0.2.0-1.fc20 python-drat-0.4.1-1.fc20 python-fedmsg-meta-fedora-infrastructure-0.3.2-1.fc20 python-ldap-2.4.17-1.fc20 rubygem-apipie-bindings-0.0.10-2.fc20 salt-2014.1.11-1.fc20 scons-2.3.4-1.fc20 selinux-policy-3.12.1-188.fc20 sigil-0.8.0-1.fc20 sudo-1.8.11-1.fc20 vdr-scraper2vdr-0.1.4-1.fc20 Details about builds: atril-1.8.1-1.fc20 (FEDORA-2014-11901) Document viewer Update Information: - update to 1.8.1 release ChangeLog: * Mon Sep 29 2014 Wolfgang Ulbrich chat-to...@raveit.de - 1.8.1-1 - update to 1.8.1 release autotrash-0.1.5-2.fc20 (FEDORA-2014-11888) Automatically take-out the trash Update Information: Version Bump of Initial Fedora package References: [ 1 ] Bug #1144000 - Review Request: autotrash - Automatically take-out the trash https://bugzilla.redhat.com/show_bug.cgi?id=1144000
Fedora 21 updates-testing report
The following Fedora 21 Security updates need testing: Age URL 18 https://admin.fedoraproject.org/updates/FEDORA-2014-10766/mod_gnutls-0.5.10-13.fc21 18 https://admin.fedoraproject.org/updates/FEDORA-2014-10767/squid-3.4.7-2.fc21 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11677/rubygem-bundler-1.7.3-1.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11940/krb5-1.12.2-9.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11896/check-mk-1.2.4p5-2.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11915/fish-2.1.1-1.fc21 The following Fedora 21 Critical Path updates have yet to be approved: Age URL 11 https://admin.fedoraproject.org/updates/FEDORA-2014-11103/cronie-1.4.12-1.fc21 11 https://admin.fedoraproject.org/updates/FEDORA-2014-11161/anaconda-21.48.7-1.fc21 11 https://admin.fedoraproject.org/updates/FEDORA-2014-11127/python-blivet-0.61.2-2.fc21 11 https://admin.fedoraproject.org/updates/FEDORA-2014-11108/python-backports-ssl_match_hostname-3.4.0.2-4.fc21 6 https://admin.fedoraproject.org/updates/FEDORA-2014-11279/qtwebkit-2.3.3-18.fc21 6 https://admin.fedoraproject.org/updates/FEDORA-2014-11214/xdg-utils-1.1.0-0.28.rc2.fc21 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11698/util-linux-2.25.1-1.fc21 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11636/dnsmasq-2.72-1.fc21 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11707/samba-4.1.12-1.fc21 1 https://admin.fedoraproject.org/updates/FEDORA-2014-11810/dash-0.5.8-1.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11856/sudo-1.8.11-1.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11866/dracut-038-30.git20140903.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11923/emacs-24.3-27.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11862/shared-mime-info-1.3-15.fc21 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11940/krb5-1.12.2-9.fc21 The following builds have been pushed to Fedora 21 updates-testing atril-1.8.1-1.fc21 autotrash-0.1.5-2.fc21 caja-1.8.2-1.fc21 check-mk-1.2.4p5-2.fc21 dracut-038-30.git20140903.fc21 dreamchess-0.2.1-5.RC1.fc21 emacs-24.3-27.fc21 engrampa-1.8.1-1.fc21 fish-2.1.1-1.fc21 geary-0.8.0-2.fc21 gtk2-2.24.24-4.fc21 gtk3-3.14.1-1.fc21 hadoop-2.4.1-3.fc21 hbase-0.98.3-2.fc21 krb5-1.12.2-9.fc21 libev-4.19-1.fc21 mingw-id3lib-3.8.3-33.fc21 mingw-poppler-0.26.5-1.fc21 mock-1.1.41-3.fc21 nfs-ganesha-2.1.0-7.fc21 nodejs-chai-1.9.2-1.fc21 nodejs-mbtiles-0.6.0-1.fc21 nodejs-sqlite3-3.0.2-1.fc21 nodejs-tilelive-mapnik-0.6.12-2.fc21 oozie-4.0.1-2.fc21 pdns-3.4.0-1.fc21 perl-B-Lint-1.18-1.fc21 perl-Digest-SHA3-0.22-1.fc21 perl-EV-4.18-1.fc21 perl-Excel-Writer-XLSX-0.78-1.fc21 perl-Inline-0.77-1.fc21 perl-Inline-C-0.64-1.fc21 perl-Inline-Struct-0.11-1.fc21 perl-Set-Tiny-0.02-1.fc21 perl-Tangerine-0.05-1.fc21 perl-Test-Modern-0.012-1.fc21 python-bugzilla2fedmsg-0.2.0-1.fc21 python-drat-0.4.1-1.fc21 python-fedmsg-meta-fedora-infrastructure-0.3.2-1.fc21 python-ldap-2.4.17-1.fc21 rcs-5.9.3-1.fc21 rrdtool-1.4.9-1.fc21 rubygem-apipie-bindings-0.0.10-2.fc21 salt-2014.1.11-1.fc21 scons-2.3.4-1.fc21 selinux-policy-3.13.1-84.fc21 shared-mime-info-1.3-15.fc21 sigil-0.8.0-1.fc21 stellarium-0.13.0-3.fc21 sudo-1.8.11-1.fc21 vdr-scraper2vdr-0.1.4-1.fc21 Details about builds: atril-1.8.1-1.fc21 (FEDORA-2014-11909) Document viewer Update Information: - update to 1.8.1 release ChangeLog: * Mon Sep 29 2014 Wolfgang Ulbrich chat-to...@raveit.de - 1.8.1-1 - update to 1.8.1 release autotrash-0.1.5-2.fc21 (FEDORA-2014-11867) Automatically take-out the trash Update Information: Version Bump of Initial Fedora package References: [ 1 ] Bug #1144000 - Review Request: autotrash - Automatically take-out the trash https://bugzilla.redhat.com/show_bug.cgi?id=1144000 caja-1.8.2-1.fc21 (FEDORA-2014-11920) File manager for MATE Update Information: -
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 340 https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19 152 https://admin.fedoraproject.org/updates/FEDORA-2014-5896/nrpe-2.15-2.fc19 103 https://admin.fedoraproject.org/updates/FEDORA-2014-7496/readline-6.2-8.fc19 101 https://admin.fedoraproject.org/updates/FEDORA-2014-6774/claws-mail-3.10.1-1.fc19,claws-mail-plugins-3.10.0-1.fc19,libetpan-1.5-1.fc19 92 https://admin.fedoraproject.org/updates/FEDORA-2014-7939/lzo-2.08-1.fc19 54 https://admin.fedoraproject.org/updates/FEDORA-2014-9162/xulrunner-31.0-1.fc19 46 https://admin.fedoraproject.org/updates/FEDORA-2014-9427/pipelight-0.2.7.3-3.fc19 33 https://admin.fedoraproject.org/updates/FEDORA-2014-9830/glibc-2.17-21.fc19 33 https://admin.fedoraproject.org/updates/FEDORA-2014-9703/cups-1.6.4-10.fc19 21 https://admin.fedoraproject.org/updates/FEDORA-2014-10491/torque-3.0.4-4.fc19 21 https://admin.fedoraproject.org/updates/FEDORA-2014-10366/icecream-1.0.1-8.20140822git.fc19 20 https://admin.fedoraproject.org/updates/FEDORA-2014-10640/libreoffice-4.1.6.2-8.fc19 18 https://admin.fedoraproject.org/updates/FEDORA-2014-10714/curl-7.29.0-23.fc19 17 https://admin.fedoraproject.org/updates/FEDORA-2014-10794/squid-3.3.13-2.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11348/kdelibs-4.11.5-5.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11370/nginx-1.4.7-3.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11428/perl-Data-Dumper-2.154-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11483/xen-4.2.5-2.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11464/krfb-4.11.5-4.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11495/nodejs-send-0.3.0-4.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11399/nodejs-qs-0.6.6-3.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11565/nss-softokn-3.17.1-2.fc19,nss-util-3.17.1-1.fc19,nss-3.17.1-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11522/python-2.7.5-14.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11544/drupal6-6.33-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11541/libvncserver-0.9.10-0.6.20140718git9453be42.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11649/rubygem-bundler-1.7.3-1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11745/seamonkey-2.29.1-1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11582/mediawiki-1.23.4-1.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-11838/fish-2.1.1-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11855/golang-1.3.2-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2014-11929/check-mk-1.2.4p5-2.fc19 The following Fedora 19 Critical Path updates have yet to be approved: Age URL 288 https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19 214 https://admin.fedoraproject.org/updates/FEDORA-2014-3245/testdisk-6.14-2.fc19.1,ntfs-3g-2014.2.15-1.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-10986/kde-workspace-4.11.12-1.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-10971/man-db-2.6.3-8.fc19 11 https://admin.fedoraproject.org/updates/FEDORA-2014-10968/squashfs-tools-4.3-8.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11348/kdelibs-4.11.5-5.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11443/firefox-32.0.2-1.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2014-11394/thunderbird-31.1.1-1.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11522/python-2.7.5-14.fc19 4 https://admin.fedoraproject.org/updates/FEDORA-2014-11565/nss-softokn-3.17.1-2.fc19,nss-util-3.17.1-1.fc19,nss-3.17.1-1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2014-11671/koji-1.9.0-5.fc19 1 https://admin.fedoraproject.org/updates/FEDORA-2014-11828/dash-0.5.8-1.fc19 The following builds have been pushed to Fedora 19 updates-testing check-mk-1.2.4p5-2.fc19 golang-1.3.2-1.fc19 ibus-table-1.9.1-1.fc19 ibus-table-others-1.3.5-1.fc19 mock-1.1.41-3.fc19 python-bugzilla2fedmsg-0.2.0-1.fc19 python-fedmsg-meta-fedora-infrastructure-0.3.2-1.fc19 salt-2014.1.11-1.fc19 Details about builds: check-mk-1.2.4p5-2.fc19 (FEDORA-2014-11929) A new general purpose Nagios-plugin for retrieving data Update Information: Do not require any other shell than bash since that's the default shell for the Fedora / RHEL distributions New upstream release providing many security fixes. New upstream release providing many security fixes.
