Re: Proposal: let's just use the FAS group already
On Mon, 2013-12-16 at 23:26 -0500, John Dulaney wrote: Ahoy, So, I am with Adam on this one (I'm not a mod?). You weren't actually in the group when I checked, IIRC, and I didn't want to start adding many more people until I floated the idea on the list first. Seems like most everyone is positive about it, so I guess we (admins/mods) can add more people in the next few days. I've been +1 for this idea for quite some time now. Johann, I've been around for a long time, even longer than Adam, and I don't remember the original purpose for the QA group; I do vaguely recall James Laska telling me it had some purpose or other when I asked him about it (oddly enough so I could be in more than the CLA group). Thanks for the feedback. I think I checked with James last time this idea came up, and he said it didn't have a specific purpose any more. -- 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: Proposal: let's just use the FAS group already
On Tue, 2013-12-17 at 10:15 +0530, Akshay Vyas wrote: So I'm proposing we do something simple: let's just go ahead and stick everyone who can reasonably be considered a 'QA team member' in the FAS 'qa' group. This wouldn't be hard to do, I can make sure sufficient people within and outside RH have moderator status in the qa group, and then those of us who are mods can just add people appropriately. Anyone who files karma regularly, or validation test results, or posts to test@, or attends QA team meetings, anything like that - let's just stick 'em in QA group, and then for the future we can just say 'moderators can give anyone who's obviously a QA person membership in the QA group at any time, and when someone sends a self-introduction mail and doesn't completely disappear, the QA group mods should stick that person in the group'. If we can do every QA stuff without being a part of QA group then what's the use of creating a QA group As explained a few times: there are things within Fedora as a whole (not the QA group) which you need to be a member of a FAS group other than 'cla_done' to get access to - the intent being that only people who are 'members' of Fedora in some way should get them. Space on fedorapeople.org and voting rights are the two examples I've cited, I think there may be more than that. -- 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 validation test case: root on LVM thinp
On Tue, 2013-12-17 at 00:57 -0700, Chris Murphy wrote: On Dec 16, 2013, at 6:33 PM, Adam Williamson awill...@redhat.com wrote: Actually - it'd basically just be the 'guided installation' table from https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout all the other bits, basically. I basically get this. I expect there'll be separate matrices or pages for the archs? oh, god, handwave handwave. That's the 'matrix needs to exist in three dimensions' problem: there's just too many damn variables. What do we do if for a given test it matters what storage format you use, *and* whether you're UEFI or BIOS, *and* whether you, I dunno, pick encryption or not? The fundamental problem that makes storage validation design such a hard problem to solve is there's just too many inter-related factors. If you draw up the table to test every operation under all the different possible conditions in which you could test it, it's just unmanageable. So...I'm not sure if there would be separate pages per arch, no. But please, if you have a viable design which covers as many variables as possible without producing just too many tests for us to have a hope of covering, please suggest it! On a meta level, though, I think it's not possible for us to come up with the perfect storage validation test plan and have it be actually viable to accomplish: we're going to have to cut out _some_ variables. It's just a question of which combinations are the most important and practical to test, and which we have to pass on. Question for EFI as an arch, we haven't been testing every layout presumably because of overlap with x86_64. More or less. The current greying out of EFI tests was drawn up by me running through the table very hurriedly one afternoon in the middle of the F20 cycle, making a quick call as to what things it was most important to test separately on EFI and BIOS. It's almost certainly not perfect - please do contribute improvements / corrections to this determination. But I'd guess the QA:Testcase_dualboot_with_windows tests for existing GPT, and EFI System partition, rather than actually creating them (correctly). I'll bet the code that does that is called once for all of the guided partition schemes. So it seems like if we check the Windows case to make sure it doesn't break Windows, we also get a use existing GPT and ESP test of code; but still need one that creates new GPT and ESP layout test of the code. Yes? I did that on Mac EFI, but it's got slightly different code. Well, define 'need' :/ It's the same problem as above - too many damn paths, too much stuff that we would _like_ to cover in an ideal world. We have to somehow make a determination about what we don't cover, because we can't cover everything. Do we think it's worth taking that bit out of the larger storage rework proposal and sticking it in the current matrix, replacing the appropriate existing test cases? It would be an hour or two's work for me, I guess. Eh, I guess I'll just draft it up and send it out and see what you all think. Why not just delete the appropriate existing test cases rather than merging them? That was what I meant by 'replacing the appropriate existing test cases' - if we like this plan we put the new matrix in and take the old test cases out. -- 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 validation test case: root on LVM thinp
On Dec 17, 2013, at 12:57 AM, Chris Murphy li...@colorremedies.com wrote: On Dec 16, 2013, at 6:33 PM, Adam Williamson awill...@redhat.com wrote: Actually - it'd basically just be the 'guided installation' table from https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout all the other bits, basically. I basically get this. I expect there'll be separate matrices or pages for the archs? Question for EFI as an arch, we haven't been testing every layout presumably because of overlap with x86_64. But I'd guess the QA:Testcase_dualboot_with_windows tests for existing GPT, and EFI System partition, rather than actually creating them (correctly). I'll bet the code that does that is called once for all of the guided partition schemes. So it seems like if we check the Windows case to make sure it doesn't break Windows, we also get a use existing GPT and ESP test of code; but still need one that creates new GPT and ESP layout test of the code. Yes? I did that on Mac EFI, but it's got slightly different code. Another one I'm thinking of is software RAID. On BIOS, it must be the case that every member drive is getting a copy of grub2 core.img in the MBR gap, because when I yank a virtio drive, the system still boots (slowly). I haven't tested this for EFI or how that could even work because if a member drive goes away and yet the NVRAM entry is pointing to that particular (bad luck) drive, now what? I guess there's a fallback NVRAM entry that would be needed pointing to one of the other drives's EFI System partitions. I don't know that this works. I assume we want it to work one day. Might also look at the prebaked grubx64.efi file for what modules are being put into it. Unlike BIOS which can find all grub modules, it's not working that way on x86 EFI due to Secure Boot, the grubx64.efi has to be signed. But that package isn't baking all modules in it. Why I don't know. But the missing ones might indicate things that work on BIOS that probably break on EFI. The only one I ran into a while ago was LVM, but funny enough now that lvm.mod is baked into the grub efi bootloader, we dropped /boot on LVs in anaconda for F20. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
As explained a few times: there are things within Fedora as a whole (not the QA group) which you need to be a member of a FAS group other than 'cla_done' to get access to - the intent being that only people who are 'members' of Fedora in some way should get them. Space on fedorapeople.org and voting rights are the two examples I've cited, I think there may be more than that. well i think there is some kind of role associated with every group like ambassadors are suppose to do a promotion and organize events, adding some one to QA group doesn't make any changes in user privileges or any other things, well if we talk about fedorapeople.org or voting then its for every one and there is no group for some regular voters On Tue, Dec 17, 2013 at 1:30 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 10:15 +0530, Akshay Vyas wrote: So I'm proposing we do something simple: let's just go ahead and stick everyone who can reasonably be considered a 'QA team member' in the FAS 'qa' group. This wouldn't be hard to do, I can make sure sufficient people within and outside RH have moderator status in the qa group, and then those of us who are mods can just add people appropriately. Anyone who files karma regularly, or validation test results, or posts to test@, or attends QA team meetings, anything like that - let's just stick 'em in QA group, and then for the future we can just say 'moderators can give anyone who's obviously a QA person membership in the QA group at any time, and when someone sends a self-introduction mail and doesn't completely disappear, the QA group mods should stick that person in the group'. If we can do every QA stuff without being a part of QA group then what's the use of creating a QA group As explained a few times: there are things within Fedora as a whole (not the QA group) which you need to be a member of a FAS group other than 'cla_done' to get access to - the intent being that only people who are 'members' of Fedora in some way should get them. Space on fedorapeople.org and voting rights are the two examples I've cited, I think there may be more than that. -- 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 -- Akshay vyas (http://www.gofedora.in) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Mon, Dec 16, 2013 at 8:32 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2013-12-16 at 12:23 -0800, Adam Williamson wrote: Right now me, James Laska, Will Woods and Jesse Keating are the admins of the QA group. This is obviously a bit silly. I'll drop jlaska's, wwoods' and jesses' admin roles, and make some more appropriate people admins and moderators instead. I'll do that right now, since it's clearly the right thing to do... For now I've made me, tflink, kparal and viking-ice administrators and cmurf a moderator, just as raptor-proofing. You could consider the same style sponsorship system that the main packagers group uses so there's then no real need for raptor proofed admins as it would sort of be self administoring. Peter -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposed validation test case: root on LVM thinp
On Dec 17, 2013, at 1:07 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 00:57 -0700, Chris Murphy wrote: On Dec 16, 2013, at 6:33 PM, Adam Williamson awill...@redhat.com wrote: Actually - it'd basically just be the 'guided installation' table from https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix#Guided_installationwithout all the other bits, basically. I basically get this. I expect there'll be separate matrices or pages for the archs? oh, god, handwave handwave. That's the 'matrix needs to exist in three dimensions' problem: there's just too many damn variables. What do we do if for a given test it matters what storage format you use, *and* whether you're UEFI or BIOS, *and* whether you, I dunno, pick encryption or not? The fundamental problem that makes storage validation design such a hard problem to solve is there's just too many inter-related factors. If you draw up the table to test every operation under all the different possible conditions in which you could test it, it's just unmanageable. And we're just talking guided partitioning right now, and yet we need to put it in a hecatonicosachoron to visualize the ensuing matrix. But yeah other than ostrich maneuver what's the alternative? The storage layouts are in fact different between x86_64 and EFI as are the bootloaders. The least difference is i386 and x86_64, but then there could be a unique bug (?) that only affects one arch? I dunno that's far fetched but I suppose it could happen. On a meta level, though, I think it's not possible for us to come up with the perfect storage validation test plan and have it be actually viable to accomplish: we're going to have to cut out _some_ variables. It's just a question of which combinations are the most important and practical to test, and which we have to pass on. I'm not looking for perfect. I'm just trying to get an idea of what there really is to test. I haven't gotten to triaging it yet. I think we need to see the liabilities, show which ones we'll test, and the rest of of that f'n hecatonicosachoron's cells are holes for someone else to decide the consequences. As in, get more QA people. Stop the feature creep. Placard Manual Partitioning as best effort, or spun out into a separate project. Manual Partitioning is highly vertical use case, OS install only, it doesn't help people create storage for general purpose scenarios. Yet it could. And further vertical use case, is that it's Fedora/RHEL specific. So I just don't see how the wider community really contributes to that in terms of either code or testing. Difficult to imagine. But I'd guess the QA:Testcase_dualboot_with_windows tests for existing GPT, and EFI System partition, rather than actually creating them (correctly). I'll bet the code that does that is called once for all of the guided partition schemes. So it seems like if we check the Windows case to make sure it doesn't break Windows, we also get a use existing GPT and ESP test of code; but still need one that creates new GPT and ESP layout test of the code. Yes? I did that on Mac EFI, but it's got slightly different code. Well, define 'need' :/ Need defined by an answer of no to the question, do we want to ship a release where an install fails (including fails to boot) on EFI because an ESP wasn't created for some reason? Another way to do this is have the full matrix of possibilities but so long as each arch has *one* guided partitioning method that's known to work, we are a go even if the other possibilities aren't tested. If it turns out that one option was LVM thinp and everything else was busted, well so be it. More than likely we're going to have alarm bells going off in the community during beta if the basic paths are busted, so I don't know that we need to exercise those that much. It's the same problem as above - too many damn paths, too much stuff that we would _like_ to cover in an ideal world. We have to somehow make a determination about what we don't cover, because we can't cover everything. One of the LVM options in guided needs to go. Once LVM thinp is mature enough, it's better for all use cases. But until then there should be one LVM option in guided partitioning. Do we think it's worth taking that bit out of the larger storage rework proposal and sticking it in the current matrix, replacing the appropriate existing test cases? It would be an hour or two's work for me, I guess. Eh, I guess I'll just draft it up and send it out and see what you all think. Why not just delete the appropriate existing test cases rather than merging them? That was what I meant by 'replacing the appropriate existing test cases' - if we like this plan we put the new matrix in and take the old test cases out. I read yours has moving bits from the new larger matrix to the existing matrix, taking about 2 hours of work. I'm suggesting just keep the
Re: xfce does not remember saved sessions on Fedora 20
On 12/16/2013 11:38 PM, Kevin Fenzi wrote: I'm still scratching my head over the other applications not saving/restoring correctly, Next probably genuine xfce bug: thunar File Manager windows do not get restored to their position they had carried before. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043806 Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On þri 17.des 2013 04:26, John Dulaney wrote: Ahoy, So, I am with Adam on this one (I'm not a mod?). I've been +1 for this idea for quite some time now. Johann, I've been around for a long time, even longer than Adam, and I don't remember the original purpose for the QA group; I do vaguely recall James Laska telling me it had some purpose or other when I asked him about it (oddly enough so I could be in more than the CLA group). Purpose and a fact of being//elitist group which caused more harm then good in the QA community and what I'm worried about is that Adam is resurrecting it for other then purpose after he joined the WG's. If we agree it serves only the purpose to allow QA members to overcome other limitation in the project and we ensure that it will *only* serve and being used for that purpose I'm fine with resurrecting it but as soon as Adam or any other RH employee starts to mutilate it to serve it's corporate purpose we put it down. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Announcing the release of Fedora 20.
Greetings! We can say with great certainty the Fedora Project is pleased to announce the release of Fedora 20 (Heisenbug), which coincides with the 10th anniversary of the creation of the Fedora Project. Download this leading-edge, free and open source operating system now: http://fedoraproject.org/get-fedora Detailed information about this release can be seen in the release notes: http://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/index.html *** Dedicated to Seth Vidal *** On July 8, the Fedora Project lost Seth Vidal, a dedicated, tireless, and brilliant contributor. Seth was a lead developer of Yum and the Fedora update repository system. He worked to ensure that the technical and community infrastructure of Fedora worked well and consistently for users and contributors around the world. Seth touched the lives of hundreds of Fedora contributors directly and millions of others indirectly by improving the experience of using and updating Fedora. The Fedora Project dedicates the Fedora 20 release to Seth and asks that you join us in remembering his generous spirit and incredible work that helped make Fedora what it is today. We miss you, Seth. *** 10 Years of Fedora *** The Fedora 20 release coincides with Fedora's tenth anniversary. The first Fedora release (then called Fedora Core 1) came out on November 6, 2003. The Fedora Project community has grown into an active and vibrant one that produces a new version of this leading-edge, free and open source operating system around every six months. *** Desktop Environments and Spins *** The Fedora Project strives to provide the best desktop experiences possible for users, from desktop environment to application selection. We also produce nearly a dozen spins tailor-made for desktop users, hardware design, gaming, musicians, artists, and early classroom environments. Spins are available for download here: https://fedoraproject.org/wiki/Releases/20/Spins == GNOME 3.10 == Fedora 20 comes with GNOME 3.10, which has several new applications and features that will please GNOME-lovers. This release includes a new music application (gnome-music), a new maps application (gnome-maps), a revamp for the system status menu, and Zimbra support in Evolution. == KDE Plasma Workspaces 4.11 == The Fedora KDE SIG has rebased to KDE 4.11 for Fedora 20. This release includes faster Nepomuk indexing, improvements to Kontact, KScreen integration in KWin, Metalink/HTTP support for KGet, and much more. == Spins == Spins are alternate versions of Fedora. In addition to various desktop environments for Fedora, spins are also available as tailored environments for various types of users via hand-picked application sets or customizations. See all of the Fedora 20 Release Spins here: https://fedoraproject.org/wiki/Releases/20/Spins *** ARM as a Primary Architecture *** While Fedora has supported a number of hardware architectures over the years, x86/x86_64 has been the default for the majority of Fedora users and for the Linux community in general. ARM, however, has been making massive strides. It already dominates the mobile market, is becoming a go-to platform for hobbyists and makers, and is showing enormous promise for the server market as well. In keeping with Fedora's commitment to innovation, the Fedora community has been pushing to make ARM a primary architecture to satisfy the needs of users and developers targeting the ARM platform. *** Cloud and Virtualization Improvements *** The Fedora 20 release continues the Fedora tradition of adopting and integrating leading edge technologies used in cloud computing. This release includes features that will make working with virtualization and cloud computing much easier. == First-Class Cloud Images == The Fedora Cloud SIG has been working hard to provide images that are well-suited for running as guests in public and private clouds like Amazon Web Services (AWS) and OpenStack. If you're using public or private cloud, you should grab one of the downloadable Cloud Images or find a supported EC2 image, here: http://fedoraproject.org/en/get-fedora-options#clouds == VM Snapshot UI with virt-manager == Taking VM snapshots is now much easier. Though qemu and libvirt have all the major pieces in place for performing safe VM snapshots/checkpoints, there isn't any simple, discoverable UI. This feature will track adding that UI to virt-manager and any other virt stack bits that need to be fixed/improved, including adding functionality to libvirt to support deleting and rebasing to external snapshots. == ARM on x86 with libvirt/virt-manager == You can now run ARM VMs on x86 hosts using standard libvirt tools: libvirt virsh, virt-manager and virt-install. *** Big Data *** The Fedora 20 release includes all the packages you need to run Apache Hadoop 2.2.0. Hadoop is a widely used, increasingly complete big data platform with a strong, growing
any report of fedup f19-f20?
success/failure? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
Failed for me on 64-bit. However, error was 'no updates for following pckgs' and pckgs in question(allot) were almost all non-stock/post install. This was about 3 days ago. Thanks, Phil On Tue, Dec 17, 2013 at 9:13 AM, Neal Becker ndbeck...@gmail.com wrote: success/failure? -- 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: any report of fedup f19-f20?
Yes and no. I couldn't boot into 20 at all. But I easily recovered by simply choosing the previous F19 entry in GRUB. Thanks, Phil On Tue, Dec 17, 2013 at 9:25 AM, Neal Becker ndbeck...@gmail.com wrote: Did it fail badly - leaving you a mess? Philippe LeCavalier wrote: Failed for me on 64-bit. However, error was 'no updates for following pckgs' and pckgs in question(allot) were almost all non-stock/post install. This was about 3 days ago. Thanks, Phil On Tue, Dec 17, 2013 at 9:13 AM, Neal Becker ndbeck...@gmail.com wrote: success/failure? -- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Tue, 2013-12-17 at 09:19 -0600, Philippe LeCavalier wrote: Failed for me on 64-bit. However, error was 'no updates for following pckgs' and pckgs in question(allot) were almost all non-stock/post install. That's not an error, it's just an informational message. If that was the _only_ message you got (aside from 'reboot now to upgrade!'), it didn't fail. -- 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: any report of fedup f19-f20?
On Tue, 2013-12-17 at 10:13 -0500, Neal Becker wrote: success/failure? Quite a few people have reported success on G+ and in the forums, that I've seen. Aside from validation testing (where it worked, of course) I fedup'ed my server VM host from 18 to 20 without issues yesterday. Heck, I fedup'ed my desktop from 20 to Rawhide. fedup for life, yo. -- 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: any report of fedup f19-f20?
Sure but I still couldn't successfully complete the fedup 20 due to the notice. On Dec 17, 2013 11:14 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 09:19 -0600, Philippe LeCavalier wrote: Failed for me on 64-bit. However, error was 'no updates for following pckgs' and pckgs in question(allot) were almost all non-stock/post install. That's not an error, it's just an informational message. If that was the _only_ message you got (aside from 'reboot now to upgrade!'), it didn't fail. -- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Dec 14, 2013, at 12:25 PM, Adam Williamson awill...@redhat.com wrote: I really would like to see other people's proposals in this area. I'm not at all convinced I'm going to be the person who comes up with the best idea. I'd love to know what cmurf would suggest as an overall approach to designing a set of Final release criteria or a storage validation test plan, for instance. What do you think of moving any blocking storage related criteria and tests, from final to beta or even alpha? Why not move as much potential for blockers to alpha and beta releases as possible? An example of this is moving resize test and criterion to beta (or split between alpha and beta if that's sensible and helpful). If resize were busted, do we really only want to find out and start dealing with it, and maybe slipping on it, during final? Seems risky, especially if a fix depends on upstream developers. Or public beta eats OS X or Windows for lunch. Since alpha and beta blocking criteria are still in effect post-beta, there will still be storage related blocking bugs after beta release. But there wouldn't be new blockers based on additional criteria. Rather than increasing the quality of beta, the main idea is to increase the predictability of final and reduce risk of regressions and final release slip. I think guided partitioning should be fairly rock solid, and even though it's the simple path, it's still a beast of a matrix. I mentioned this in a different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We don't need two LVM options in Guided. And if we can't get buy off on that, then we'll have to just eat that extra testing, because I think Guided shouldn't get people into trouble. Custom partitioning needs to be triaged for certain use cases we really want to work, and make those blocking if they fail. It may not be the same list for i386, x86_64/EFI, and ARM. e.g. we supposedly block on raid5 for x86_64, but does that make sense for ARM? Other combinations, even if there's a crash, would be non-blocking bugs, and only the subjective FE determination applies. Obviously the data corruption proscription is still in place, so crashes that lead to mangled partition tables or previously working file systems, presumably would block. However, I wonder if that criterion should be split in two: clearly not OK block worthy cases probably ought to be an alpha or beta blocker at the latest; and those that are suitable for FE or merely being documented could be permitted post-beta since they're unlikely to block. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On 12/17/2013 07:13 AM, Neal Becker wrote: success/failure? Success on two machines. I did have to import keys for the rpmfusion repos, though. Otherwise, worked like a charm. Fedup is a huge improvement over preupgrade. -- Joel -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote: On Dec 14, 2013, at 12:25 PM, Adam Williamson awill...@redhat.com wrote: I really would like to see other people's proposals in this area. I'm not at all convinced I'm going to be the person who comes up with the best idea. I'd love to know what cmurf would suggest as an overall approach to designing a set of Final release criteria or a storage validation test plan, for instance. What do you think of moving any blocking storage related criteria and tests, from final to beta or even alpha? Why not move as much potential for blockers to alpha and beta releases as possible? An example of this is moving resize test and criterion to beta (or split between alpha and beta if that's sensible and helpful). If resize were busted, do we really only want to find out and start dealing with it, and maybe slipping on it, during final? Seems risky, especially if a fix depends on upstream developers. Or public beta eats OS X or Windows for lunch. Since alpha and beta blocking criteria are still in effect post-beta, there will still be storage related blocking bugs after beta release. But there wouldn't be new blockers based on additional criteria. Rather than increasing the quality of beta, the main idea is to increase the predictability of final and reduce risk of regressions and final release slip. I think guided partitioning should be fairly rock solid, and even though it's the simple path, it's still a beast of a matrix. I mentioned this in a different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We don't need two LVM options in Guided. And if we can't get buy off on that, then we'll have to just eat that extra testing, because I think Guided shouldn't get people into trouble. Custom partitioning needs to be triaged for certain use cases we really want to work, and make those blocking if they fail. It may not be the same list for i386, x86_64/EFI, and ARM. e.g. we supposedly block on raid5 for x86_64, but does that make sense for ARM? Other combinations, even if there's a crash, would be non-blocking bugs, and only the subjective FE determination applies. Obviously the data corruption proscription is still in place, so crashes that lead to mangled partition tables or previously working file systems, presumably would block. However, I wonder if that criterion should be split in two: clearly not OK block worthy cases probably ought to be an alpha or beta blocker at the latest; and those that are suitable for FE or merely being documented could be permitted post-beta since they're unlikely to block. Chris Murphy +1. Move as much as makes sense in the storage testing to as early as possible. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Tue, 2013-12-17 at 11:30 -0500, Philippe LeCavalier wrote: Sure but I still couldn't successfully complete the fedup 20 due to the notice. I don't think that's correct. I had one of these notices on my upgrade, and the upgrade worked. I'm not saying you didn't have a problem, I'm saying that the problem you saw is probably not related to the note about non-updatable packages. The difference between correlation and causation. -- 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: any report of fedup f19-f20?
Agreed. I only supplied the info that was given on the screen. When I boot into F20 to perform the fedup I don't get past the progress-bar-type splash screen and thus have no details to provide other than the aforementioned. Perhaps calling it an error was an error ;) On the same note; how do I get the real error to you guys? None of the TTYs seem to respond to alt+1/2/3...etc. I appeared stuck on that progress-bar screen. Thanks, Phil On Tue, Dec 17, 2013 at 11:23 AM, Adam Williamson awill...@redhat.comwrote: On Tue, 2013-12-17 at 11:30 -0500, Philippe LeCavalier wrote: Sure but I still couldn't successfully complete the fedup 20 due to the notice. I don't think that's correct. I had one of these notices on my upgrade, and the upgrade worked. I'm not saying you didn't have a problem, I'm saying that the problem you saw is probably not related to the note about non-updatable packages. The difference between correlation and causation. -- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Tue, 2013-12-17 at 11:29 -0600, Philippe LeCavalier wrote: Agreed. I only supplied the info that was given on the screen. When I boot into F20 to perform the fedup I don't get past the progress-bar-type splash screen and thus have no details to provide other than the aforementioned. Perhaps calling it an error was an error ;) On the same note; how do I get the real error to you guys? None of the TTYs seem to respond to alt+1/2/3...etc. I appeared stuck on that progress-bar screen. Try booting the upgrade session with the 'rhgb quiet' parameters removed, and see if that provides more useful information. -- 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: any report of fedup f19-f20?
Okay. Thanks! I'll try that tonight. Thanks, Phil On Tue, Dec 17, 2013 at 11:39 AM, Adam Williamson awill...@redhat.comwrote: On Tue, 2013-12-17 at 11:29 -0600, Philippe LeCavalier wrote: Agreed. I only supplied the info that was given on the screen. When I boot into F20 to perform the fedup I don't get past the progress-bar-type splash screen and thus have no details to provide other than the aforementioned. Perhaps calling it an error was an error ;) On the same note; how do I get the real error to you guys? None of the TTYs seem to respond to alt+1/2/3...etc. I appeared stuck on that progress-bar screen. Try booting the upgrade session with the 'rhgb quiet' parameters removed, and see if that provides more useful information. -- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Proposal: let's just use the FAS group already
On Tue, 17 Dec 2013, Akshay Vyas wrote: If we can do every QA stuff without being a part of QA group then what's the use of creating a QA group How do you STOP people from doing QA, and reporting stuff either to bugzilla or the mailing list? But I think the issue is that at least one element of 'every' role for a Fedora contributor is not open to me (i.e., voting) without some additional group membership beyond Looking at my accout page at fedoraproject,org, I show only: Signed CLA Group (user) Signers of the Fedora Project Contributor Agreement (user) I have one request not acted upon by a functionally dead sub project, and recall making another request to another which I never heard back on ... but last time that voting time came around, I was unable to do so. My participation in making RH derived distributions predates even the Fedora project itself, having been active since RHL's inception. I was one of the early if not original 'invited' cohort of external 'testers-list' members (2001 era as I recall), former editor of rpm.org, more bug filings thatn I care to count, the first commit for 'sqlite' when it came in for RPM purposes, and so forth Adam, to the extent I am not a formal member of QA group, please take this as my request for addition to such -- Russ herrold -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 18 updates-testing report
On Tue, 2013-12-17 at 13:29 -0600, Michael Cronenworth wrote: upda...@fedoraproject.org wrote: The following Fedora 18 Security updates need testing: Age URL 241 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 88 https://admin.fedoraproject.org/updates/FEDORA-2013-17195/spice-gtk-0.18-3.fc18 82 https://admin.fedoraproject.org/updates/FEDORA-2013-17635/wireshark-1.10.2-4.fc18 80 https://admin.fedoraproject.org/updates/FEDORA-2013-17853/davfs2-1.4.7-3.fc18 Just a friendly reminder that these updates are still waiting for Fedora 18, which will be EOL soon. I can try and test at least wireshark and spice-gtk in a VM. But euca and davfs might be tricky. It may be a good idea to just push all queued security updates without negative karma stable before F18 EOL. -- 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: any report of fedup f19-f20?
On Tue, Dec 17, 2013 at 10:13 AM, Neal Becker ndbeck...@gmail.com wrote: success/failure? I had total success about 10 days ago with fedup f19-f20 on two different x86_64 systems: a Thinkpad 400 and an el-cheapo Acer AMD dual-core desktop. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
More on storage validation strategy (was: Re: Criterion revision proposal: KDE default applications)
On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote: On Dec 14, 2013, at 12:25 PM, Adam Williamson awill...@redhat.com wrote: I really would like to see other people's proposals in this area. I'm not at all convinced I'm going to be the person who comes up with the best idea. I'd love to know what cmurf would suggest as an overall approach to designing a set of Final release criteria or a storage validation test plan, for instance. What do you think of moving any blocking storage related criteria and tests, from final to beta or even alpha? Why not move as much potential for blockers to alpha and beta releases as possible? An example of this is moving resize test and criterion to beta (or split between alpha and beta if that's sensible and helpful). If resize were busted, do we really only want to find out and start dealing with it, and maybe slipping on it, during final? Seems risky, especially if a fix depends on upstream developers. Or public beta eats OS X or Windows for lunch. Personally, no, I don't think that's correct. In fact we just got done doing the opposite change (after F18, we weakened the Alpha storage criteria quite a lot). My take is this: the criteria define what needs to be working for us to release. They do not define what we ought to be testing at each milestone. We ought to be testing everything at each milestone, ideally. If that's not possible we need to test as much as we can. I'm not a huge fan of the Release Level column in the matrices, because it kinda gives the wrong impression. Even if a given test would only block Final release if it failed, not Alpha or Beta, *that doesn't mean we should only run it at Final*. We should run it at Alpha and Beta too, so we know if it's broken. I'm as guilty of taking the shortcut and punting on doing early tests as anyone. We're all human. But conceptually, the questions of 'what needs testing when?' and 'what do we block the release on?' are separate questions, and it is incorrect to make modifications to the release criteria simply to 'force' us to test stuff earlier. The correct question to be answering when deciding what should be in the Alpha release criteria? is, simply, what needs to be working for us to ship a product labelled Alpha? It's that simple. Since alpha and beta blocking criteria are still in effect post-beta, there will still be storage related blocking bugs after beta release. But there wouldn't be new blockers based on additional criteria. Just to reiterate the above, *that shouldn't be happening now anyway* (except when the code actually breaks between Beta and Final, which does happen). We should be doing the testing by Beta and identifying all the Final blockers that exist by Beta. This is the goal I'm trying to work towards with all the revisions I'm proposing and thinking about, insofar as that's plausible with fedora.next hanging over us. We should be able to run our entire set of validation tests at Alpha and Beta, we should not be staging the test workload. Rather than increasing the quality of beta, the main idea is to increase the predictability of final and reduce risk of regressions and final release slip. I think this is a great goal indeed. I think guided partitioning should be fairly rock solid, and even though it's the simple path, it's still a beast of a matrix. Yup. That's definitely one of the problems. I mentioned this in a different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We don't need two LVM options in Guided. And if we can't get buy off on that, then we'll have to just eat that extra testing, because I think Guided shouldn't get people into trouble. I broadly agree with this. If we were designing to the test cases, I'd say we should just throw that damn dropdown out entirely. You want something other than our default filesystem (whatever it is), you go to custom partitioning. But the best design for testers is not necessary the best design for users :) It's possibly worth considering, though. As I mentioned, oldUI only let you pick LVM or ext4. newUI added btrfs, with the 'everything's going btrfs!' plan in mind, I think. And F20 added LVM thinp. So now we have 2x what oldUI had. (And actually, I think the 'don't use LVM' checkbox was only added to oldUI in like F15 or something). We did have a kind of clear policy with oldUI, which is that we tested its version of 'guided' partitioning quite extensively, and custom partitioning got a lot less in terms of testing and criteria guarantees. We've been pushing that boat out since F18; maybe we need to pull it back in again. newUI guided does, I think, provide just about all the same possibilities oldUI non-custom did, with a slightly different approach. I think, whatever the details we come up with, the broad direction emphasize testing of guided, de-emphasize testing of custom - along with the improvements to the guided UI that Mo is currently working on
Re: Fedora 18 updates-testing report
On Tue, 2013-12-17 at 21:21 +0100, Christophe Fergeau wrote: On Tue, Dec 17, 2013 at 12:17:37PM -0800, Adam Williamson wrote: On Tue, 2013-12-17 at 13:29 -0600, Michael Cronenworth wrote: upda...@fedoraproject.org wrote: The following Fedora 18 Security updates need testing: Age URL 241 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 88 https://admin.fedoraproject.org/updates/FEDORA-2013-17195/spice-gtk-0.18-3.fc18 82 https://admin.fedoraproject.org/updates/FEDORA-2013-17635/wireshark-1.10.2-4.fc18 80 https://admin.fedoraproject.org/updates/FEDORA-2013-17853/davfs2-1.4.7-3.fc18 Just a friendly reminder that these updates are still waiting for Fedora 18, which will be EOL soon. I can try and test at least wireshark and spice-gtk in a VM. But euca and davfs might be tricky. It may be a good idea to just push all queued security updates without negative karma stable before F18 EOL. You've already commented in the spice-gtk one: adamwill (proventesters) - 2013-09-27 20:00:27 my testing VM is fine I can't push this update myself it seems :( The submitter has just submitted it for stable, so it should make it on the next push. -- 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: Fedora 18 updates-testing report
Adam Williamson wrote: The submitter has just submitted it for stable, so it should make it on the next push. Thanks, Adam. People are usually responsive to my e-mails and the ball starts rolling. Wireshark is the last update that needs attention. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 18 updates-testing report
On Tue, 2013-12-17 at 14:59 -0600, Michael Cronenworth wrote: Adam Williamson wrote: The submitter has just submitted it for stable, so it should make it on the next push. Thanks, Adam. People are usually responsive to my e-mails and the ball starts rolling. Wireshark is the last update that needs attention. I've just fired up an F18 VM to do a fedora-easy-karma run... -- 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: Fedora 18 updates-testing report
upda...@fedoraproject.org wrote: The following Fedora 18 Security updates need testing: Age URL 241 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 88 https://admin.fedoraproject.org/updates/FEDORA-2013-17195/spice-gtk-0.18-3.fc18 82 https://admin.fedoraproject.org/updates/FEDORA-2013-17635/wireshark-1.10.2-4.fc18 80 https://admin.fedoraproject.org/updates/FEDORA-2013-17853/davfs2-1.4.7-3.fc18 Just a friendly reminder that these updates are still waiting for Fedora 18, which will be EOL soon. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Thanks, Phil On Tue, Dec 17, 2013 at 12:41 PM, Philippe LeCavalier supp...@plecavalier.com wrote: Okay. Thanks! I'll try that tonight. Thanks, Phil On Tue, Dec 17, 2013 at 11:39 AM, Adam Williamson awill...@redhat.comwrote: On Tue, 2013-12-17 at 11:29 -0600, Philippe LeCavalier wrote: Agreed. I only supplied the info that was given on the screen. When I boot into F20 to perform the fedup I don't get past the progress-bar-type splash screen and thus have no details to provide other than the aforementioned. Perhaps calling it an error was an error ;) On the same note; how do I get the real error to you guys? None of the TTYs seem to respond to alt+1/2/3...etc. I appeared stuck on that progress-bar screen. Try booting the upgrade session with the 'rhgb quiet' parameters removed, and see if that provides more useful information. -- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 18 updates-testing report
The following Fedora 18 Security updates need testing: Age URL 241 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 88 https://admin.fedoraproject.org/updates/FEDORA-2013-17195/spice-gtk-0.18-3.fc18 82 https://admin.fedoraproject.org/updates/FEDORA-2013-17635/wireshark-1.10.2-4.fc18 80 https://admin.fedoraproject.org/updates/FEDORA-2013-17853/davfs2-1.4.7-3.fc18 23 https://admin.fedoraproject.org/updates/FEDORA-2013-21875/389-ds-base-1.3.0.9-1.fc18 10 https://admin.fedoraproject.org/updates/FEDORA-2013-22949/net-snmp-5.7.2-7.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23215/php-5.4.23-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23299/libreswan-3.7-1.fc18 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23378/openttd-1.3.3-1.fc18 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23401/v8-3.14.5.10-3.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23479/nss-util-3.15.3-1.fc18,nss-3.15.3-1.fc18,nss-softokn-3.15.3-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23504/quagga-0.99.21-6.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23466/xen-4.2.3-12.fc18 The following Fedora 18 Critical Path updates have yet to be approved: Age URL 311 https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18 10 https://admin.fedoraproject.org/updates/FEDORA-2013-22918/opus-1.1-1.fc18 10 https://admin.fedoraproject.org/updates/FEDORA-2013-22917/colord-1.0.5-1.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-23224/openssh-6.1p1-11.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23312/dracut-029-1.fc18.3 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23306/abrt-2.1.10-1.fc18,libreport-2.1.10-1.fc18,satyr-0.12-1.fc18 4 https://admin.fedoraproject.org/updates/FEDORA-2013-23297/libfm-1.1.4-1.fc18 2 https://admin.fedoraproject.org/updates/FEDORA-2013-23381/cryptsetup-1.6.3-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-23479/nss-util-3.15.3-1.fc18,nss-3.15.3-1.fc18,nss-softokn-3.15.3-1.fc18 The following builds have been pushed to Fedora 18 updates-testing bugwarrior-0.6.3-2.fc18 mate-file-manager-1.6.3-1.fc18 ndjbdns-1.05.9-1.fc18 quagga-0.99.21-6.fc18 slapi-nis-0.52-1.fc18 Details about builds: bugwarrior-0.6.3-2.fc18 (FEDORA-2013-23497) Sync github, bitbucket, and trac issues with taskwarrior Update Information: Disable jira support to solve dep problems. ChangeLog: * Mon Dec 16 2013 Ralph Bean rb...@redhat.com - 0.6.3-2 - Patch to disable jira support since it creates a dep nightmare for f19/f18. References: [ 1 ] Bug #1036078 - bugwarrior does not work on Fedora 19 -- missing deps - conflicting requirement https://bugzilla.redhat.com/show_bug.cgi?id=1036078 mate-file-manager-1.6.3-1.fc18 (FEDORA-2013-23493) File manager for MATE Update Information: - update to 1.6.3 release - add patch to surpress x-caja-window issue ChangeLog: * Mon Dec 16 2013 Wolfgang Ulbrich chat-to...@raveit.de - 1.6.3-1 - update to 1.6.3 release References: [ 1 ] Bug #886029 - ten x-caja-desktop windows are opened after first login https://bugzilla.redhat.com/show_bug.cgi?id=886029 ndjbdns-1.05.9-1.fc18 (FEDORA-2013-23488) New djbdns: usable djbdns Update Information: Bug fix enhancements.
Re: xfce does not remember saved sessions on Fedora 20
On 17/12/13 22:46, Ralf Corsepius wrote: On 12/16/2013 11:38 PM, Kevin Fenzi wrote: I'm still scratching my head over the other applications not saving/restoring correctly, Well, some of these obviously are Gnome3 regressions: Next bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043817 Ralf The whole of GNOME 3 is a regression! I used to use GNOME 2 exclusively. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Tue, 2013-12-17 at 16:02 -0500, Philippe LeCavalier wrote: So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Can you get the precise message, and/or a picture of the screen? 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
fedup f19-f20 success (sort of)
It did succeed. But I thought it wasn't going to. After reboot into fedup, it gave *no indication at all* that it was doing anything. I was sure it was hosed, but left and went to lunch. No visual indication anything was happening, no flickering of the disk activity light. I switched consoles and all I saw no updates to any messages. I don't know how (or if it's even possible) to switch to a console and run top to see what is happening. Not a good user experience. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f19-f20 success (sort of)
On Tue, 2013-12-17 at 14:07 -0500, Neal Becker wrote: It did succeed. But I thought it wasn't going to. After reboot into fedup, it gave *no indication at all* that it was doing anything. I was sure it was hosed, but left and went to lunch. No visual indication anything was happening, no flickering of the disk activity light. I switched consoles and all I saw no updates to any messages. I don't know how (or if it's even possible) to switch to a console and run top to see what is happening. Not a good user experience. It should show a graphical bootsplash with a progress bar on tty1, and if you hit esc, a text boot screen with more detailed info. did for me, in testing. sounds like somehow that didn't work for you? -- 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: Proposal: let's just use the FAS group already
Date: Tue, 17 Dec 2013 12:52:16 + From: johan...@gmail.com To: test@lists.fedoraproject.org Subject: Re: Proposal: let's just use the FAS group already Purpose and a fact of being elitist group which caused more harm then good in the QA community and what I'm worried about is that Adam is resurrecting it for other then purpose after he joined the WG's. If we agree it serves only the purpose to allow QA members to overcome other limitation in the project and we ensure that it will *only* serve and being used for that purpose I'm fine with resurrecting it but as soon as Adam or any other RH employee starts to mutilate it to serve it's corporate purpose we put it down. JBG What do you mean, mutilate it to serv it's corporate purpose? Are you stating that since I now work for Red Hat, I'm evil? Since I've started working for Red Hat, I've not seen any wanting to contort Fedora to RH's nefarious ends. In fact, I've seen a lot of effort to get work done internally into Fedora as quickly as possible so that Fedora may benefit. I seriously don't understand where you get these ideas from. Along those lines, now that I work for Red Hat, does that make me evil? Am I now a corporate minion? You do realize that my job at RH has nothing to do with Fedora; I continue to be involved with Fedora purely because I want to. You don't see me slapping my @redhat.com email around. In fact, the only account I've switched over is my bugzilla account, and that was purely for convenience. John -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
Pics are awaiting approval by the moderator... Thanks, Phil On Tue, Dec 17, 2013 at 4:20 PM, Adam Williamson awill...@redhat.comwrote: On Tue, 2013-12-17 at 16:02 -0500, Philippe LeCavalier wrote: So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Can you get the precise message, and/or a picture of the screen? 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f19-f20 success (sort of)
On Tue, Dec 17, 2013 at 11:59:20AM -0800, Adam Williamson wrote: On Tue, 2013-12-17 at 14:07 -0500, Neal Becker wrote: After reboot into fedup, it gave *no indication at all* that it was doing anything. I was sure it was hosed, It should show a graphical bootsplash with a progress bar on tty1, and if you hit esc, a text boot screen with more detailed info. I run into an experience similar to Neal's when trying a f17-f19 fedup upgrade. A splash screen, no progress bar of any kind, no reaction to whatever one is trying on a keyboard. A drive light was flickering from time to time, though, so I left it sit for a looong time before eventually rebooting with a help of a power switch. From a timestamp on a new initramfs it was good that I was really patient. :-) An automatic reboot was supposed to happen according to logs but reality was different. OTOH the whole upgrade was eventually performed and this was still a very early fedup (but run actually so late that results were likely not that interesting) so I did not bother anybody with this mixed impressions. sounds like somehow that didn't work for you? Difficult to say what as afterwards everything looked normal. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f19-f20 success (sort of)
On Tue, 2013-12-17 at 16:45 -0700, Michal Jaegermann wrote: On Tue, Dec 17, 2013 at 11:59:20AM -0800, Adam Williamson wrote: On Tue, 2013-12-17 at 14:07 -0500, Neal Becker wrote: After reboot into fedup, it gave *no indication at all* that it was doing anything. I was sure it was hosed, It should show a graphical bootsplash with a progress bar on tty1, and if you hit esc, a text boot screen with more detailed info. I run into an experience similar to Neal's when trying a f17-f19 fedup upgrade. A splash screen, no progress bar of any kind, no reaction to whatever one is trying on a keyboard. A drive light was flickering from time to time, though, so I left it sit for a looong time before eventually rebooting with a help of a power switch. From a timestamp on a new initramfs it was good that I was really patient. :-) An automatic reboot was supposed to happen according to logs but reality was different. F17's fedup was much more primitive code, the progress stuff wasn't implemented till later. OTOH the whole upgrade was eventually performed and this was still a very early fedup (but run actually so late that results were likely not that interesting) so I did not bother anybody with this mixed impressions. sounds like somehow that didn't work for you? Difficult to say what as afterwards everything looked normal. Michal -- 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: Proposal: let's just use the FAS group already
On þri 17.des 2013 23:05, John Dulaney wrote: What do you mean, mutilate it to serv it's corporate purpose? Are you stating that since I now work for Red Hat, I'm evil? No I'm stating that because of the history and that history should not be allowed to be forgotten and you are not suddenly evil you came from the community just like RH would hire a an upstream developer there is quite the difference of that and RH inventing leadership positions and plant individuals outside the community in that position which has happened on more then one occasion here with us as well as project wide. Not all Red Hat employees care for Fedora and just use it to their and their teams and RHEL advantage ( just look at the WG effort more closely ) even if it's clearly against the best interest of the project as a part of their 9 - 5 job and then there are many that do care alot for Fedora and are working on it on their own free time ( like you are doing ) and are looking out for it's interest within RH. The work the arm team has been doing becoming primary, is the latest success lesson in how to do it right in working *with* the community as well as *for it* from the RH camp and all RH employees as well as community members that are part of that effort should take pride in that work. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f19-f20 success (sort of)
Adam Williamson wrote: On Tue, 2013-12-17 at 16:45 -0700, Michal Jaegermann wrote: On Tue, Dec 17, 2013 at 11:59:20AM -0800, Adam Williamson wrote: On Tue, 2013-12-17 at 14:07 -0500, Neal Becker wrote: After reboot into fedup, it gave *no indication at all* that it was doing anything. I was sure it was hosed, It should show a graphical bootsplash with a progress bar on tty1, and if you hit esc, a text boot screen with more detailed info. I run into an experience similar to Neal's when trying a f17-f19 fedup upgrade. A splash screen, no progress bar of any kind, no reaction to whatever one is trying on a keyboard. A drive light was flickering from time to time, though, so I left it sit for a looong time before eventually rebooting with a help of a power switch. From a timestamp on a new initramfs it was good that I was really patient. :-) An automatic reboot was supposed to happen according to logs but reality was different. F17's fedup was much more primitive code, the progress stuff wasn't implemented till later. OTOH the whole upgrade was eventually performed and this was still a very early fedup (but run actually so late that results were likely not that interesting) so I did not bother anybody with this mixed impressions. sounds like somehow that didn't work for you? Difficult to say what as afterwards everything looked normal. Michal There was a graphical bootsplash with a progress bar - but it appearted to be frozen for a very long time. Hit esc and a text boot screen was there, but appeared to be frozen for a very long time. Sure looked like it was just stuck. The drive light did not flicker as long as I was looking. I guess it eventually did something once I walked away and went to lunch, because when I came back f20 was booted up just fine. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Tue, Dec 17, 2013 at 4:20 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 16:02 -0500, Philippe LeCavalier wrote: So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Can you get the precise message, and/or a picture of the screen? Thanks! On Dec 17, 2013, at 4:17 PM, Philippe LeCavalier supp...@plecavalier.com wrote: Pics are awaiting approval by the moderator… Please no, don't attach pics and send it to 3000 people on a list serve. It's 2013. Stick it in dropbox public and post a link, or google drive, or it doesn't really matter. That's faster than waiting for a moderate who really shouldn't approve attachments anyway. Thanks, Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Tue, 2013-12-17 at 23:07 -0700, Chris Murphy wrote: On Tue, Dec 17, 2013 at 4:20 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 16:02 -0500, Philippe LeCavalier wrote: So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Can you get the precise message, and/or a picture of the screen? Thanks! On Dec 17, 2013, at 4:17 PM, Philippe LeCavalier supp...@plecavalier.com wrote: Pics are awaiting approval by the moderator… Please no, don't attach pics and send it to 3000 people on a list serve. It's 2013. Stick it in dropbox public and post a link, or google drive, or it doesn't really matter. That's faster than waiting for a moderate who really shouldn't approve attachments anyway. I saw them on the moderation request. Looks like the same issue several people have hit today. It's kinda curious that this is suddenly happening, I know we tested 0.7 and it worked. Oh, well. So, yeah, Philippe, try the standard advice of the day: upgrade to fedup 0.8 and try again. Seems to be working for people. -- 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: any report of fedup f19-f20?
On Dec 17, 2013, at 11:13 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 23:07 -0700, Chris Murphy wrote: On Tue, Dec 17, 2013 at 4:20 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 16:02 -0500, Philippe LeCavalier wrote: So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Can you get the precise message, and/or a picture of the screen? Thanks! On Dec 17, 2013, at 4:17 PM, Philippe LeCavalier supp...@plecavalier.com wrote: Pics are awaiting approval by the moderator… Please no, don't attach pics and send it to 3000 people on a list serve. It's 2013. Stick it in dropbox public and post a link, or google drive, or it doesn't really matter. That's faster than waiting for a moderate who really shouldn't approve attachments anyway. I saw them on the moderation request. Looks like the same issue several people have hit today. It's kinda curious that this is suddenly happening, I know we tested 0.7 and it worked. Oh, well. So, yeah, Philippe, try the standard advice of the day: upgrade to fedup 0.8 and try again. Seems to be working for people. Yeah I just did an F18 live desktop install to kvm, installed 0.7.3-4, ran it with: fedup --network 20 --debuglog fedupdebug.log The download is fine. The grub.cfg is correct. The reboot fails and before I can read anything it reboots and the grub.cfg has changed such that the fedup option isn't present. The screen shots I captured of the reboot failure shows a couple hints: https://dl.dropboxusercontent.com/u/3253801/fedupfailss1.png https://dl.dropboxusercontent.com/u/3253801/fedupfailss2.png That looks to me like the initramfs possibly doesn't contain the right root. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] PSA: Use fedup 0.8 for upgrades to Fedora 20! (was Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?)
On Tue, 2013-12-17 at 21:47 -0800, Adam Williamson wrote: On Tue, 2013-12-17 at 15:16 -0800, Andrew Lutomirski wrote: I have a tendency to upgrade to a new Fedora release as soon as it's final, and I sometimes upgrade even sooner. ISTM that the official upgrade process is almost always broken, often for known reasons. Should one of the criteria for releasing Fedora N+1 be that a fully-updated Fedora N must be able to successfully complete 'fedup' or whatever the current preferred upgrade program is? (FWIW, the current bug is particularly nasty -- fedup 0.7.0 apparently can't actually update anything, and the sequence: - Install fedup 0.7.0 - Try it and watch it fail or hang - Update to fedup 0.8.0 from updates-testing - Run fedup ends up downloading all rpms *twice* a sucking up a correspondingly immense amount of disk space. Um, I'm fairly sure it doesn't. It only re-downloads stuff that's different from the previous run. We did test upgrades to F20 with 0.7, and they did work in testing, and quite a lot of people reported success with fedup in the last two weeks when at least some of them likely used 0.7. You have to bear in mind it's release day today, and there's always weirdness on release day, and people who have success generally don't report it while those who hit failure almost always do. I've been advising people to upgrade to 0.8 and retry just as a kind of generic piece of advice; for many of them, it'd probably work if they just retried with 0.7. 0.8 does fix several bugs compared to 0.7, but 0.7 wasn't entirely broken. Eh, that'll teach me to talk before thoroughly testing: these words are delicious! Om nom nom. I just poked it a bit and it sure seems like upgrades with fedup 0.7 to F20 are busted. They definitely worked when we tested shortly before release, though. I can only think that using fedup 0.7 against upgrade kernel/image built with fedup-dracut 0.8 doesn't work. FranciscoD also points out that the location of files downloaded by fedup changed between 0.7 and 0.8, so if you do a run with 0.7 then try with 0.8, it'll re-download all the updates, which is a waste of space and bandwidth. So, here's the news: do your upgrades to F20 with fedup 0.8, yo. It's in updates-testing for F18 and F19 at present, but will go to stable for F19 tomorrow. If you're upgrading from F18, you'll need to pass '--nogpgcheck' to fedup, because of https://bugzilla.redhat.com/show_bug.cgi?id=1040689 . If you did an unsuccessful run with fedup 0.7, then you can do: mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade mv /var/lib/fedora-upgrade /var/lib/system-upgrade before running fedup 0.8, to save it downloading all the packages again, and make sure it cleans up nicely when it's done. I've just tested this, and it works. If you've already done an unsuccessful run with fedup 0.7 and then a successful run with 0.8, you may have files from the 0.7 run hanging around in /var/lib/fedora-upgrade and /var/tmp/fedora-upgrade. It is entirely safe and, indeed, advised to rm -rf these directories. Sorry for the mess, folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Wed, Dec 18, 2013 at 1:37 AM, Chris Murphy li...@colorremedies.comwrote: On Dec 17, 2013, at 11:13 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 23:07 -0700, Chris Murphy wrote: On Tue, Dec 17, 2013 at 4:20 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-12-17 at 16:02 -0500, Philippe LeCavalier wrote: So it appears I'm stuck at mounted /boot. At the top I can see an error Start Load Kernel Modules FAILED or something similar. Can you get the precise message, and/or a picture of the screen? Thanks! On Dec 17, 2013, at 4:17 PM, Philippe LeCavalier supp...@plecavalier.com wrote: Pics are awaiting approval by the moderator… Please no, don't attach pics and send it to 3000 people on a list serve. It's 2013. Stick it in dropbox public and post a link, or google drive, or it doesn't really matter. That's faster than waiting for a moderate who really shouldn't approve attachments anyway. I saw them on the moderation request. Looks like the same issue several people have hit today. It's kinda curious that this is suddenly happening, I know we tested 0.7 and it worked. Oh, well. So, yeah, Philippe, try the standard advice of the day: upgrade to fedup 0.8 and try again. Seems to be working for people. Yeah I just did an F18 live desktop install to kvm, installed 0.7.3-4, ran it with: fedup --network 20 --debuglog fedupdebug.log The download is fine. The grub.cfg is correct. The reboot fails and before I can read anything it reboots and the grub.cfg has changed such that the fedup option isn't present. The screen shots I captured of the reboot failure shows a couple hints: https://dl.dropboxusercontent.com/u/3253801/fedupfailss1.png https://dl.dropboxusercontent.com/u/3253801/fedupfailss2.png That looks to me like the initramfs possibly doesn't contain the right root. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test I am getting a weird error message. Not sure what it means exactly. sudo fedup -v --iso ~/Downloads/Fedora-Live-Desktop-i686-20/Fedora-Live-Desktop-i686-20-1.iso fedup INFO: /bin/fedup starting at Wed Dec 18 02:09:15 2013 setting up repos... fedup.yum INFO: FedupDownloader(version=None, cachedir=/var/tmp/fedora-upgrade) fedup.yum INFO: checking repos fedup.yum INFO: repo fedupiso seems OK getting boot images... Downloading failed: couldn't get boot images: Local file does not exist: /tmp/fedup.mnt.lwL9hb/.treeinfo fedup INFO: Downloading failed: couldn't get boot images: Local file does not exist: /tmp/fedup.mnt.lwL9hb/.treeinfo fedup INFO: /bin/fedup exiting at Wed Dec 18 02:09:15 2013 -- Will Morris Fedora Bugzapper, Amabasador irc: wmorri -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Dec 17, 2013, at 11:37 PM, Chris Murphy li...@colorremedies.com wrote: Yeah I just did an F18 live desktop install to kvm, installed 0.7.3-4, ran it with: fedup --network 20 --debuglog fedupdebug.log The download is fine. The grub.cfg is correct. The reboot fails and before I can read anything it reboots and the grub.cfg has changed such that the fedup option isn't present. The screen shots I captured of the reboot failure shows a couple hints: https://dl.dropboxusercontent.com/u/3253801/fedupfailss1.png https://dl.dropboxusercontent.com/u/3253801/fedupfailss2.png That looks to me like the initramfs possibly doesn't contain the right root. Weird. /system-upgrade-root exists so the 2nd screen shot complaint indicating it doesn't is bogus. The next complaint, that /system-upgrade-root/sysimage is true, it doesn't exist. The debug log shows: [ 5678.220] (II) fedup.sysprep:setup_upgraderoot() creating upgraderoot dir: /system-upgrade-root An earlier screenshot of boot shows: dracut-pre-pivot: Warning: UPGRADEROOT isn't unset, can't save initramfs If anyone else is having such errors, is your rootfs btrfs by any chance? It's possible for a couple things to get confused about where the real root is if it's not groking it's on its own subvolume. (I'm not sure that's the problem, still looking and may even give up if no else is having this problem or if 0.8 solves it.) Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On 12/18/2013 08:12 AM, Chris Murphy wrote: On Dec 17, 2013, at 11:37 PM, Chris Murphy li...@colorremedies.com wrote: Yeah I just did an F18 live desktop install to kvm, installed 0.7.3-4, ran it with: fedup --network 20 --debuglog fedupdebug.log The download is fine. The grub.cfg is correct. The reboot fails and before I can read anything it reboots and the grub.cfg has changed such that the fedup option isn't present. The screen shots I captured of the reboot failure shows a couple hints: https://dl.dropboxusercontent.com/u/3253801/fedupfailss1.png https://dl.dropboxusercontent.com/u/3253801/fedupfailss2.png That looks to me like the initramfs possibly doesn't contain the right root. Weird. /system-upgrade-root exists so the 2nd screen shot complaint indicating it doesn't is bogus. The next complaint, that /system-upgrade-root/sysimage is true, it doesn't exist. The debug log shows: [ 5678.220] (II) fedup.sysprep:setup_upgraderoot() creating upgraderoot dir: /system-upgrade-root An earlier screenshot of boot shows: dracut-pre-pivot: Warning: UPGRADEROOT isn't unset, can't save initramfs If anyone else is having such errors, is your rootfs btrfs by any chance? I am also observing these messages. No, my rootfs is ext4, not btrfs. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On Dec 18, 2013, at 12:12 AM, Chris Murphy li...@colorremedies.com wrote: If anyone else is having such errors, is your rootfs btrfs by any chance? On Dec 17, 2013, at 11:57 PM, Adam Williamson awill...@redhat.com wrote: I can only think that using fedup 0.7 against upgrade kernel/image built with fedup-dracut 0.8 doesn't work. That seems more plausible. This: mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade mv /var/lib/fedora-upgrade /var/lib/system-upgrade Plus updating to fedup 0.8 and reattempting works for me. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] PSA: Use fedup 0.8 for upgrades to Fedora 20! (was Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?)
On Tue, 2013-12-17 at 21:47 -0800, Adam Williamson wrote: On Tue, 2013-12-17 at 15:16 -0800, Andrew Lutomirski wrote: I have a tendency to upgrade to a new Fedora release as soon as it's final, and I sometimes upgrade even sooner. ISTM that the official upgrade process is almost always broken, often for known reasons. Should one of the criteria for releasing Fedora N+1 be that a fully-updated Fedora N must be able to successfully complete 'fedup' or whatever the current preferred upgrade program is? (FWIW, the current bug is particularly nasty -- fedup 0.7.0 apparently can't actually update anything, and the sequence: - Install fedup 0.7.0 - Try it and watch it fail or hang - Update to fedup 0.8.0 from updates-testing - Run fedup ends up downloading all rpms *twice* a sucking up a correspondingly immense amount of disk space. Um, I'm fairly sure it doesn't. It only re-downloads stuff that's different from the previous run. We did test upgrades to F20 with 0.7, and they did work in testing, and quite a lot of people reported success with fedup in the last two weeks when at least some of them likely used 0.7. You have to bear in mind it's release day today, and there's always weirdness on release day, and people who have success generally don't report it while those who hit failure almost always do. I've been advising people to upgrade to 0.8 and retry just as a kind of generic piece of advice; for many of them, it'd probably work if they just retried with 0.7. 0.8 does fix several bugs compared to 0.7, but 0.7 wasn't entirely broken. Eh, that'll teach me to talk before thoroughly testing: these words are delicious! Om nom nom. I just poked it a bit and it sure seems like upgrades with fedup 0.7 to F20 are busted. They definitely worked when we tested shortly before release, though. I can only think that using fedup 0.7 against upgrade kernel/image built with fedup-dracut 0.8 doesn't work. FranciscoD also points out that the location of files downloaded by fedup changed between 0.7 and 0.8, so if you do a run with 0.7 then try with 0.8, it'll re-download all the updates, which is a waste of space and bandwidth. So, here's the news: do your upgrades to F20 with fedup 0.8, yo. It's in updates-testing for F18 and F19 at present, but will go to stable for F19 tomorrow. If you're upgrading from F18, you'll need to pass '--nogpgcheck' to fedup, because of https://bugzilla.redhat.com/show_bug.cgi?id=1040689 . If you did an unsuccessful run with fedup 0.7, then you can do: mv /var/tmp/fedora-upgrade /var/tmp/system-upgrade mv /var/lib/fedora-upgrade /var/lib/system-upgrade before running fedup 0.8, to save it downloading all the packages again, and make sure it cleans up nicely when it's done. I've just tested this, and it works. If you've already done an unsuccessful run with fedup 0.7 and then a successful run with 0.8, you may have files from the 0.7 run hanging around in /var/lib/fedora-upgrade and /var/tmp/fedora-upgrade. It is entirely safe and, indeed, advised to rm -rf these directories. Sorry for the mess, folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce