test January 2016

test@lists.fedoraproject.org

31 participants
163 discussions

NVIDIA Question
by David St.Clair 17 Jan '22

17 Jan '22

This may be a dumb question, but why can't Redhat distribute NVIDIA binary drivers? In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it says: "2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux operating system may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files)." So, what's keeping RedHat from putting the drivers in the distribution? If it's a GPL thing, would it be easy to just download it during installation or at least give the option to the user? Thanks, -- David St.Clair dstclair(a)cs.wcu.edu

10 20

Mouse goes crazy
by Jonathan Villa 17 Jan '22

17 Jan '22

Ok, I have had Yarrow working well for a while now, but yesterday I started experiencing some odd issues with my mouse. All of a sudden it stops working correctly. The only thing that seems to fix is to kill X and run mouse-test, then restart. Any ideas? Also, I have FC 1 running on a desktop which is hooked up to a KVM switch. Whenever I go to another PC, and return, the same thing happens, the mouse goes crazy. ???

8 7

Criteria proposal: remove media part of release notes criterion
by Adam Williamson 26 Oct '17

26 Oct '17

Per https://fedorahosted.org/fedora-qa/ticket/471 and https://bugzilla.redhat.com/show_bug.cgi?id=1221920 , it seems we no longer want to require release notes to be present on all media. For simplicity's sake, I suggest we simply remove the media section of the criterion entirely. We could I suppose require that media include some kind of pointer to the release notes, but this seems difficult in the case of e.g. cloud images. Anyone have comments, alternative proposals? Thanks! For the record, the criterion is https://fedoraproject.org/wiki/Fedora_ 23_Final_Release_Criteria#Release_notes : "The final branded release notes must be present on release-blocking images and the appropriately versioned generic release notes must be available in the release repository." I propose amending it to: "The final branded and generic release notes must be present in the release repository." -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

3 10

[Fedora QA] #472: create testcase for resizing in custom partitioning
by fedora-badges 15 Aug '16

15 Aug '16

#472: create testcase for resizing in custom partitioning ------------------------+------------------------ Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 22 Component: Test cases | Version: Keywords: | Blocked By: Blocking: | ------------------------+------------------------ After discovering https://bugzilla.redhat.com/show_bug.cgi?id=1221247 it seems reasonable we should test this more properly in the future. Currently we seem to have no test case about resizing partitions in manual part dialog. We probably should, and test it against at least a standard partition and a logical volume. Optionally, we can split standard partitions into ext4 and ntfs, to cover similar use cases as in our QA:Testcase_partitioning_guided_shrink . -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/472> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

Fedora 24: i686 images no longer 'release blocking'
by Adam Williamson 01 Apr '16

01 Apr '16

Hi, folks! As discussed at last week's meeting, it seemed a good idea to flag this up on the list for anyone who missed it. From Fedora 24 onwards, FESCo has decided that i686 (32-bit x86) images are no longer 'release blocking', by policy: https://fedorahosted.org/fesco/ticket/1469 I have tweaked the release criteria 'preamble' text slightly to mention this explicitly, and also to link to the canonical list of release- blocking images that the program manager is maintaining now (the F24 list is https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fe… ). I noted that the question of whether we 'support' / block on 32-bit *upgrades* is not yet resolved, so I've filed a FESCo ticket for that: https://fedorahosted.org/fesco/ticket/1539 What this means to us is pretty simple: we no longer have to worry about getting all the validation tests done for 32-bit images. Woot! We still *can* test them, if we want, but we don't have to. They're just like the LXDE live, or any other non-blocking image. An outstanding question is what we do with the validation matrices. Cloud was easy enough - I just marked all rows in the i386 table as 'Optional'. Base, Server and Desktop don't really split out x86_64 and i386/i686 (sidebar: the best thing about ditching i386/i686/x86_32 is we no longer have to be terminally confused about what it's freaking *called*...), so they're OK too. However, Installation is a bit of a problem: https://fedoraproject.org/wiki/Template:Installation_test_matrix quite a lot of the tables have 'i386' and 'x86_64' as environments. Especially with the Milestone column, listing i386 alongside x86_64 is a bit misleading if i386 is no longer blocking. I can see a few options: 1) just ditch the i386 columns entirely; openQA can continue testing it, and people can test manually if they want, but we don't bother tracking the results in the validation pages 2) stick an admon template at the top of the page saying 'the i386 tests aren't blocking', with links out to the criteria and/or the FESCo ticket 3) Duplicate each table which distinguishes between 'i386' and 'x86_64', so we have one table with just an 'i386' column and all tests marked Optional, and another table with the other columns and the appropriate milestone I can see arguments for any of those approaches. #1 is nice and simple and reduces the scariness of the page, but I guess means we don't get a quick overview of i386 status and probably means fewer people bothering to do i386 tests. I don't know how much we care about that. #2 is also simple and keeps the tests around, but people are probably going to miss the admon note and will therefore be confused about whether we're "missing" a lot of required results, if i386 isn't done. #3 is probably the most 'theoretically correct', but would probably be something of a giant PITA to read. I suppose we could have the i386 tables collapsed by default. That might work. Now I think about it, though, I think having rows that are identical except for their environments might confuse python-wikitcms, I'd have to look into it. If you're thinking "4) change the Milestone column", I'd rather not, because those values are somewhat significant to Wikitcms. Other ideas welcome! If anyone can think of any other system/process which might need adjusting for this change, too, please do let us know! Or just go fix it. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

6 17

Non-image blocker process change proposal
by Adam Williamson 03 Mar '16

03 Mar '16

Hi, folks! It's been a recurring issue in the blocker review / release validation process in recent times that we run across bugs that qualify as blockers, but for which the fix does not need to be in the final frozen media or install trees. Common cases are bugs related to upgrading, especially since the introduction of fedup and even more so of dnf-system-upgrade; most upgrade-related issues can now be sufficiently fixed by package updates to either the source or target release. Bugs to do with writing USB media from the previous release, for instance, also often fall in this category. Up until now we've been sort of handwaving these as 'special blockers', following the regular blocker process but noting in comments that they don't block the compose. We haven't been tracking very hard if they actually *are* being fixed with updates promptly, we've just been sort of waving a magic wand and assuming it will happen. I just found one which was supposed to be fixed with a 0-day update for Beta, but hadn't been fixed yet: https://bugzilla.redhat.com/show_bug.cgi?id=1263230 So, we kinda need to do this better. Up top I'd like to note there are really kind of two buckets of 'special blockers' for any given release. If the release being validated is N, they are: 1) Bugs for which the fix must be in the 0-day update set for N 2) Bugs for which the fix must be stable in N-1 and N-2 by N release day There will be a lot of process nerd detail involved in any fix, but before any detailed drafts I'd like to suggest two broad possible approaches and see what people think: #1 Separate trackers -------------------- As a sort of on-the-spot PoC for F23 Beta, I created a new tracker bug for bucket 1: https://bugzilla.redhat.com/show_bug.cgi?id=1264167 We could formalize that approach, and have a '0-day' blocker tracker for each milestone. We could either just have one '0-day' tracker and throw bugs for both the pending release and previous stable releases on the same tracker and keep track of what needs updating where in each bug, or we could have two 0-day trackers for each milestone, one for the pending release, and one for previous stable releases. So we'd have something like: F24AlphaBlocker F24AlphaFreezeException F24Alpha0Day (F24AlphaStable) (? - better alias suggestions welcome) and so on. This is a lot of bugs, but there is a script to create them, so we're not adding a bunch of onerous work. So far as proposing bugs goes, I think we'd probably want to extend the current somewhat flexible approach; formally you would nominate a bug as a particular type of blocker/FE (by marking it as blocking the appropriate tracker), but we would move things around in blocker review meetings sensibly, as we currently do (when something is nominated as FE but should really be a blocker, or vice versa). In blocker review we'd go through all bugs nominated for any of the trackers, probably starting with 'Blocker', then '0Day' and 'Stable', then 'FreezeException'. #2 MOAR METADATA ---------------- The alternative is to make the existing Blocker trackers do more work. In this model we wouldn't add any new tracker bugs; we'd just add new 'magic words' in the Whiteboard field. Right now, an accepted blocker is identified by the string 'AcceptedBlocker' appearing in the whiteboard field. We could simply add some more magical strings like that: 'Accepted0Day' and 'AcceptedStable', say (better suggestions welcome). I kind of like this idea as it's less change and involves creating fewer new bugs. We'd have to make some changes to blockerbugs either way - tflink can say if either approach would be more work in blockerbugs, but I'm gonna guess they'd be fairly similar. With either approach, the basic goal is to make it more feasible to keep an eye on each of the different categories of 'release blocker' bugs; right now we have solid processes in place for ensuring the 'normal' blockers are all addressed in the release media, but we don't have any processes in place for ensuring 0Day and Stable bugs actually get updates shipped when we say they must. My suggestion would be that we make sure 'blockerbugs' includes lists of each type of blocker. Ahead of and at Go/No-Go meetings, we would want to have a formal assurance from the person responsible for fixing the bug that the fix would be provided by a certain time - say, one day or two days ahead of the release date - and it would be QA's responsibility to ensure the updates are tested promptly, and releng's responsibility to ensure they are pushed on time after being tested. I would suggest the Program Manager ought to have overall responsibility for keeping an eye on the 0Day and Stable blocker lists and making sure the maintainer, QA, and releng all did their jobs on time. It'd be great if folks could post their general thoughts on this, and any preference for option 1 or option 2. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

11 39

Criteria proposal: applying 'post-install' criteria to live and appliance images
by Adam Williamson 01 Mar '16

01 Mar '16

Hi, folks! I'm working through some criteria issues that came up during F23 validation. Here's one: a few times, we hit issues on live images which would have been violations of the 'post-install' release criteria, except those are explicitly for 'installed' systems. We generally felt that the relevant 'post-install' criteria should also apply to live boots. Here's a top-level idea for handling that: 1. Rename the 'Post-install requirements' section on each criteria page to 'Post-deployment and live requirements' 2. Add some text at the top of the section explaining the general idea: the requirements in the section apply to installed systems, 'appliance' environments like the cloud images, *and* live environments, where appropriate 3. Adjust the wording of each individual criterion in the sections, where appropriate. Just to give an example: "Unless explicitly specified otherwise, after system installation SELinux must be enabled and in enforcing mode." would become something like: "Unless explicitly specified otherwise, SELinux must be enabled and in enforcing mode in live environments and after system installation." Does this general approach sound good? If so, I'll post some drafts later in the week. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

7 13

GStreamermm
by Russel Winder 15 Feb '16

15 Feb '16

Hi, Debian Sid and Fedora Rawhide both have gstreamer-0.10 and gstreamer- 1.0 libraries, seemingly the full set. However Sid only has Gstreamermm 1.0 and Rawhide only has Gstreamermm 0.10. Is this intentional? It does make things somewhat awkward creating Gstreamer application with C++. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel(a)winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

3 6

criterion proposal: upgrading across 2 releases
by Kamil Paral 09 Feb '16

09 Feb '16

Our current upgrade criterion says: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Upgrade_requ… Currently we have no criterion that would cover upgrading across 2 releases, e.g. from F21 to F23 (directly, not one by one). But in the real world this very often happens. It's even one of the reasons we support our releases until N+2 release is available + 1 month (i.e. F21 is supported until F23 is out + 1 month). The often cited reason is for people to be upgrading just once per year (and have one month to do that). And of course many (probably most) of them don't upgrade one by one, but skip a release. I feel that for something as important as system upgrade, we should provide a better level of quality and assurance for upgrading across 2 releases. Currently we have no criterion and testing it is just an afterthought, not even tracked anywhere. I'd like to amend the existing criterion to include N-2 release as well, i.e.: "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of any of the two previous stable Fedora releases with that package set installed." (language corrections very welcome) We can discuss whether N+2 upgrading should be a separate Final criterion, not joined with the Beta one. I don't feel strongly either way. I'd also set up a new test case in our installation matrix in the upgrade section: https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade Something like QA:Testcase_upgrade_dnf_skip_release. The question is whether to have just a single test case and let people choose which package set they test, or whether to pick some particular package set. We probably don't want to test all combinations, at least not manually. Just a single "please test something" test case would be satisfactory here, I think. Something will get tested, and we will block on important bugs we discover, that's the important change. If we decide to not go this route for some reason, I think we should adjust our tools (system-upgrade) and documentation (wiki, fedora docs) and provide very clear and visible warning that the only officially supported means of upgrading is to go up releases one by one. And that skipping releases might be dangerous (considerably more than doing it the recommended way). Because I feel we would be doing our users a disservice if we neither tested skipping releases nor warned them against doing that. Thoughts? Kamil

6 35

[Fedora QA] #478: Proposed Test Day: Cloud
by fedora-badges 08 Feb '16

08 Feb '16

#478: Proposed Test Day: Cloud ----------------------+------------------------ Reporter: roshi | Owner: Type: defect | Status: new Priority: major | Milestone: Fedora 23 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ It would be good to have a test day for the cloud image. The Cloud WG will coordinate and host. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/478> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test January 2016