Re: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
On Wed, Jun 22, 2022 at 06:18:08PM -0700, Adam Williamson wrote: > On Thu, 2022-06-09 at 12:48 -0700, Adam Williamson wrote: > > Hi folks! > ... > > I think doing this could really help us keep Rawhide solid and avoid > > introducing major compose-breaking bugs, at minimal cost. But it's a > > significant change and I wanted to see what folks think. In particular, > > if you find the existing gating of updates for stable/branched releases > > to cause problems in any way, I'd love to hear about it. > > > > Thanks folks! > > One thing I forgot to mention in the original email, the benefit here > isn't theoretical - I've already caught several Rawhide-breaking bugs > early, or been able to identify the cause more easily, because we have > the tests running in staging. Here's an example I just caught: a new > popt version that was sent out today seems to break authselect, which > is a critical problem and breaks all new installs: > > https://bugzilla.redhat.com/show_bug.cgi?id=2100287 > > if nirik catches my message in time before the next compose runs, he'll > be able to untag the new build and the compose won't be completely > broken. If we had this testing deployed in prod and gating turned on, > the update would be blocked automatically. It's been untagged from rawhide and eln. kevin signature.asc Description: PGP signature ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
On Thu, 2022-06-09 at 12:48 -0700, Adam Williamson wrote: > Hi folks! ... > I think doing this could really help us keep Rawhide solid and avoid > introducing major compose-breaking bugs, at minimal cost. But it's a > significant change and I wanted to see what folks think. In particular, > if you find the existing gating of updates for stable/branched releases > to cause problems in any way, I'd love to hear about it. > > Thanks folks! One thing I forgot to mention in the original email, the benefit here isn't theoretical - I've already caught several Rawhide-breaking bugs early, or been able to identify the cause more easily, because we have the tests running in staging. Here's an example I just caught: a new popt version that was sent out today seems to break authselect, which is a critical problem and breaks all new installs: https://bugzilla.redhat.com/show_bug.cgi?id=2100287 if nirik catches my message in time before the next compose runs, he'll be able to untag the new build and the compose won't be completely broken. If we had this testing deployed in prod and gating turned on, the update would be blocked automatically. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Future of Test Cases and their Management in Fedora QA
On Wed, 2022-06-22 at 08:57 -0600, Tim Flink wrote: > > 3. Continue Using WikiTCMS > > > Advantages: > - Doesn't require any changes to how we're doing things > - Is very flexible - can do pretty much whatever we want to without a ton > of code > - Doesn't require much maintenance or custom code beyond wikitcms Another advantage of the current system that I'd like to highlight is that it allows us to synthesize manual and automated test results. That is, in the current wiki results pages, you see the results from openQA and human testers together. I would definitely want any replacement for it to preserve this advantage - i.e., I would want it to be able to track results from both human testers and automated systems. Ideally, this would be achieved by resultsdb integration - it's a bit difficult to imagine technically how this could work, but it would be nice for results from both human testers and automated systems to be in resultsdb, and for any human- readable representation of the validation state to pull both sets of results from resultsdb. wikitcms gives us the integration of the two types of result, but it does not currently forward results from human testers to resultsdb. So we only have the results from automated systems in resultsdb. openQA reports its results to *both* resultsdb and the wiki, so the wiki is the only canonical store of *both* human and bot results. I've toyed in the past with the idea of having `relval report-results` also submit the result to resultsdb, but it requires solving authentication and we still wouldn't capture human test results submitted by editing the wiki directly. Another option would be a wikitcms-based bot which monitored result pages for edits and forwarded any 'new results' to resultsdb... > > Disadvantages: > - More difficult to analyze data contained in the wiki > - Only one person can report results in a given matrix at a time > - QA is the only group still using the Fedora wiki > > This kinda started a while back when CPE started asking about whether > we still needed the wiki or not. The current Fedora wiki is a source > of frustration for them due to the amount of spam and bot issues that > they have to deal with. Seeing as how QA is one of the only (if not > the only) groups left using the wiki, it's worth asking whether we > really still need it or not. It does sound like most of CPE's > concerns could be satisfied with a new wiki instance which could be > locked down to only allow pages with a certain format but I don't > believe that conversation has even been started with them. If they do get to the point where they really, really want to turn the wiki off, I'm willing to try and handle this (setting up a reduced wiki instance specifically for this purpose, with restrictions to allowable page names and so on). -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Future of Test Cases and their Management in Fedora QA
On Wed, 2022-06-22 at 11:55 -0400, Matthew Miller wrote: > On Wed, Jun 22, 2022 at 08:57:04AM -0600, Tim Flink wrote: > > > > 3. Continue Using WikiTCMS > > > > > > Advantages: > > - Doesn't require any changes to how we're doing things > > - Is very flexible - can do pretty much whatever we want to without a ton > > of code > > - Doesn't require much maintenance or custom code beyond wikitcms > > > > Disadvantages: > > - More difficult to analyze data contained in the wiki > > - Only one person can report results in a given matrix at a time > > - QA is the only group still using the Fedora wiki > > From a user perspective, I discovered the QA test matrix pages long before I > realized that they weren't actually meant to be used as wiki pages, and that > they were actually managed by a tool. It's easy to mess things up. And the > tool is somewhat klunky if you're not used to it. Well, hand editing them is still Officially Supported(tm). You're just supposed to *not* screw it up. If you do screw it up, one of two things will happen. If one of the tools that uses wikitcms noticeably chokes on it, I'll probably notice at some point, grumble a bit, and fix it. If I'm feeling super enthusiastic I might fix wikitcms to handle whatever you did wrong (it handles quite a lot of common human errors/inconsistencies). If nothing that uses wikitcms chokes *obviously* on it, we might never notice and it'll just be there forever! I try to steer people to using `relval report-results` because it should be *somewhat* easier than hand-editing the pages, and it should not ever write things in a way wikitcms doesn't parse properly. But you are "allowed" to edit the pages by hand, too. (I actually do this myself quite a lot, still). Just please don't screw it up. :P There are ways to improve on this that *don't* involve switching tools, of course. One option would be to enhance the testdays webapp quite a bit and use it for this too. We could also make `relval report-results` better, write a more graphical/web-y version of it, or something. I have never put *that* much work into it, honestly. It's not that far evolved beyond "just enough to do the job for the guy who wrote it". If someone felt inclined, you could improve its interface quite a bit. If we got either of those approaches far enough along, we could consider locking out direct editing of the wiki pages somehow, if that's plausible in mediawiki, and only allowing tools/bots to edit them. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Future of Test Cases and their Management in Fedora QA
On 6/22/22 09:55, Matthew Miller wrote: On Wed, Jun 22, 2022 at 08:57:04AM -0600, Tim Flink wrote: 3. Continue Using WikiTCMS Advantages: - Doesn't require any changes to how we're doing things - Is very flexible - can do pretty much whatever we want to without a ton of code - Doesn't require much maintenance or custom code beyond wikitcms Disadvantages: - More difficult to analyze data contained in the wiki - Only one person can report results in a given matrix at a time - QA is the only group still using the Fedora wiki From a user perspective, I discovered the QA test matrix pages long before I realized that they weren't actually meant to be used as wiki pages, and that they were actually managed by a tool. It's easy to mess things up. And the tool is somewhat klunky if you're not used to it. That's a good point. I guess I've been using the wiki matrices for so long that I don't think about it much anymore. Do we have any reasonable way of estimating how many testers/results we lose because of the current interface? I suspect that anything we end up using is going to have a learning curve for new people but in this case, I'm not really sure which is the best/worst. Tim ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Future of Test Cases and their Management in Fedora QA
On Wed, Jun 22, 2022 at 08:57:04AM -0600, Tim Flink wrote: > > 3. Continue Using WikiTCMS > > > Advantages: > - Doesn't require any changes to how we're doing things > - Is very flexible - can do pretty much whatever we want to without a ton of > code > - Doesn't require much maintenance or custom code beyond wikitcms > > Disadvantages: > - More difficult to analyze data contained in the wiki > - Only one person can report results in a given matrix at a time > - QA is the only group still using the Fedora wiki From a user perspective, I discovered the QA test matrix pages long before I realized that they weren't actually meant to be used as wiki pages, and that they were actually managed by a tool. It's easy to mess things up. And the tool is somewhat klunky if you're not used to it. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Kiwi TCMS Demo Access
This is a follow on from the thread about TCMSs in general. I have a demo of Kiwi TCMS set up if anyone wants to poke at it: - https://kiwidemo.fedorainfracloud.org/ Things which aren't available now but would be fixed if we choose to use Kiwi TCMS going forward: - anonymous read access is not currently working - Authentication with FAS Seeing as how the demo system is not capable of authenticating against FAS, there's no easy way to grant access other than by request. If you want access to the system, send me an email (not to the list) containing your fas username and I'll create an account for you. There is a short tutorial/reference available at: - https://tflink.fedorapeople.org/kiwi-demo-docs/ Thanks, Tim ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Future of Test Cases and their Management in Fedora QA
This is a conversation which has started a few times but not in anything close to a formal way. Let's fix that so we at least have an answer of why we're doing what we're doing :) A test case management system (TCMS) is pretty much what it sounds like - a system which manages at least test cases for an organization. In general, a TCMS is going to also manage test plans and many also keep track of results. Fedora doesn't have a traditional TCMS - we use the wiki to store our test cases and the test matrices which roughly align to test cases, test plans and results. The basic question is: "should we be using a more traditional TCMS instead of the wiki?". There aren't a ton of alternatives available to us, so the comparison list is pretty short. As far as I know, our options are: 1. Start using Kiwi TCMS 2. Create, deploy and maintain our own custom TCMS 3. Keep using the wiki for our TCMS If anyone is aware of other options which don't sacrifice the functionality we use for release validation, are open source and aren't abandoned upstream, please reply to this thread. Just because these 3 are the only options I could find doesn't mean that there aren't others. I've written up a brief summary of what I see of the advantages and disadvantages to the three approaches to start the conversation. What are peoples' thoughts on our options going forward? Should we look at moving on from our existing wiki-based TCMS? If so, do either of the alternatives appear promising enough to move forward with? Thanks in advance for everyone's time and thoughts, Tim 1. Start using Kiwi TCMS Advantages: - Has an existing user base, we wouldn't have to create/maintain an entire TCMS alone - Uses a more structured format which can be easier to analyze - Allows multiple people to report results at the same time Disadvantages: - Has strict relationships between products, test cases and test plans which don't align well to how Fedora QA currently does things - Is currently missing some vital features (FAS integration) - Would require us to deploy and maintain an instance - Would likely require some custom patches/plutins that we'd have to keep working with any changes in upstream KiwiTCMS - Does not support testcases in multiple languages KiwiTCMS (https://kiwitcms.org/) is an open source (GPL2) TCMS which started life inside Red Hat managing test cases for RHEL. As far as I know, it's the only open source TCMS out there which is still maintained and is even close to our workflow. I have set up a demo instance for people to poke at, details are in a separate email to this list. Kiwi is written in Django so that wouldn't be a huge hurdle for our currently available development skills but it is currently missing at least one feature before we could use it in production (FAS authentication). That being said, Kiwi is rather opinionated on what the relationship between testcases, test plans, builds and results should look like. We would have to make some non-trivial changes to how we do things like release validation and that's a non-trivial cost. 2. Create, deploy and maintain our own custom TCMS Advantages: - Could be whatever we wanted it to be - Would integrate well with existing Fedora systems Disadvantages: - Writing our own, custom TCMS would be expensive and take time - We'd have another system to maintain There's always the option of writing our own TCMS. While it'd be great to have something that uses ResultsDB out of the box and works perfectly with our workflows, that would come at a cost. The question comes down to whether we'd gain enough from a custom TCMS to justify the work we'd have to put into the system. 3. Continue Using WikiTCMS Advantages: - Doesn't require any changes to how we're doing things - Is very flexible - can do pretty much whatever we want to without a ton of code - Doesn't require much maintenance or custom code beyond wikitcms Disadvantages: - More difficult to analyze data contained in the wiki - Only one person can report results in a given matrix at a time - QA is the only group still using the Fedora wiki This kinda started a while back when CPE started asking about whether we still needed the wiki or not. The current Fedora wiki is a source of frustration for them due to the amount of spam and bot issues that they have to deal with. Seeing as how QA is one of the only (if not the only) groups left using the wiki, it's worth asking whether
Re: dependency problems in rawhide as of 20220614
On Wed, 22 Jun 2022 11:39:53 +0100 Sérgio Basto wrote: > Hi, ok , RPMFusion started perl mass rebuild yesterday, the perl > maintainer notice that > "at least some of the perl packages in this output have been retired > in Fedora, e.g. > > * perl-HTML-Tidy > * perl-Math-Pari > * perl-Crypt-Random > * perl-Crypt-Primes > * perl-Crypt-RSA > > Things might look a bit better after removing those. " > > I removed the following perl packages, just because they were from fc36 and were causing problems. I don't know a quick and easy way to identify if a package has been retired, so some of these might still be active but not updated to the latest version. 2022-06-22T07:18:28-0700 SUBDEBUG Erase: perl-Crypt-RSA-1.99-36.fc36.noarch 2022-06-22T07:18:28-0700 SUBDEBUG Erase: perl-Crypt-Primes-0.50-45.fc36.noarch 2022-06-22T07:18:28-0700 SUBDEBUG Erase: perl-Crypt-Random-1.54-3.fc36.noarch 2022-06-22T07:18:28-0700 SUBDEBUG Erase: perl-Math-Pari-2.030523-1.fc37.x86_64 2022-06-22T07:18:28-0700 SUBDEBUG Erase: perl-HTML-Tidy-1.60-14.fc36.x86_64 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-voms-server-0.20-25.fc36.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-VOMS-Lite-tests-0.20-25.fc36.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-VOMS-Lite-0.20-25.fc36.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-Wx-Perl-ProcessStream-0.32-27.fc36.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-Verilog-CodeGen-0.9.4-38.fc36.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-Pod-Tests-1.20-9.fc35.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-ParseLex-2.21-19.fc36.noarch 2022-06-22T07:30:43-0700 SUBDEBUG Erase: perl-File-Inplace-0.20-31.fc36.noarch 2022-06-22T07:30:44-0700 SUBDEBUG Erase: perl-File-Finder-0.53-32.fc36.noarch That helps but there are still several problems. I think that they are because of library version mismatches between fedora and rpmfusion. I've attached the error output. Every error with perl-libs in it is probably relevant, as well as gdal-perl. I notice srt-libs is quite prominent in the list also. I'll post a copy of this email to the rpmfusion user list as well. Problem 1: cannot install both gdal-libs-3.5.0-4.fc37.x86_64 and gdal-libs-3.4.3-1.fc37.x86_64 - package gdal-perl-3.4.3-1.fc37.x86_64 requires gdal-libs(x86-64) = 3.4.3-1.fc37, but none of the providers can be installed - package gdal-perl-3.4.3-1.fc37.x86_64 requires libgdal.so.30()(64bit), but none of the providers can be installed - cannot install the best update candidate for package gdal-libs-3.4.3-1.fc37.x86_64 - problem with installed package gdal-perl-3.4.3-1.fc37.x86_64 Problem 2: cannot install both perl-libs-4:5.36.0-488.fc37.x86_64 and perl-libs-4:5.34.1-486.fc37.x86_64 - package amanda-3.5.1-33.fc36.x86_64 requires perl(:MODULE_COMPAT_5.34.0), but none of the providers can be installed - cannot install the best update candidate for package perl-libs-4:5.34.1-486.fc37.x86_64 - cannot install the best update candidate for package amanda-3.5.1-33.fc36.x86_64 Problem 3: cannot install both qt5-qtbase-5.15.4-3.fc37.x86_64 and qt5-qtbase-5.15.3-2.fc37.x86_64 - package qt5-qtenginio-1:1.6.2-38.fc37.x86_64 requires libQt5Core.so.5(Qt_5.15.3_PRIVATE_API)(64bit), but none of the providers can be installed - package qt5-qtenginio-1:1.6.2-38.fc37.x86_64 requires qt5-qtbase(x86-64) = 5.15.3, but none of the providers can be installed - cannot install the best update candidate for package qt5-qtbase-5.15.3-2.fc37.x86_64 - problem with installed package qt5-qtenginio-1:1.6.2-38.fc37.x86_64 Problem 4: package vlc-core-1:3.0.17.4-2.fc37.x86_64 requires libsrt.so.1.4()(64bit), but none of the providers can be installed - cannot install both srt-libs-1.5.0-1.fc37.x86_64 and srt-libs-1.4.4-2.fc36.x86_64 - cannot install the best update candidate for package vlc-core-1:3.0.17.4-1.fc37.x86_64 - cannot install the best update candidate for package srt-libs-1.4.4-2.fc36.x86_64 Problem 5: cannot install both wxBase-3.1.7-1.fc37.x86_64 and wxBase-3.1.5-6.fc36.x86_64 - package audacity-freeworld-3.1.3-3.fc37.x86_64 requires libwx_baseu-3.1.so.5()(64bit), but none of the providers can be installed - package audacity-freeworld-3.1.3-3.fc37.x86_64 requires libwx_baseu-3.1.so.5(WXU_3.1)(64bit), but none of the providers can be installed - package audacity-freeworld-3.1.3-3.fc37.x86_64 requires libwx_baseu_net-3.1.so.5()(64bit), but none of the providers can be installed - package audacity-freeworld-3.1.3-3.fc37.x86_64 requires libwx_baseu_net-3.1.so.5(WXU_3.1)(64bit), but none of the providers can be installed - package audacity-freeworld-3.1.3-3.fc37.x86_64 requires libwx_baseu_xml-3.1.so.5()(64bit), but none of the providers can be installed - cannot install the best update candidate for package wxBase-3.1.5-6.fc36.x86_64 - cannot install the best update candidate for package audacity-freeworld-3.1.3-3.fc37.x86_64 Problem 6: package
Re: dependency problems in rawhide as of 20220614
On Wed, 2022-06-15 at 08:50 -0700, stan via test wrote: > On Wed, 15 Jun 2022 08:12:57 -0700 > stan via test wrote: > > > On Tue, 14 Jun 2022 19:20:22 +0100 > > Sérgio Basto wrote: > > > > > On Tue, 2022-06-14 at 07:05 -0700, stan via test wrote: > > > > There are a lot of dependency problems in rawhide after a large > > > > update > > > > a few days ago. I'm attaching the list in case anyone is > > > > interested in > > > > pursuing them at this early date. One, that seems to be with > > > > gdal- libs, > > > > is holding up a perl update, and there also seems to be a kde > > > > conflict. > > > > > > First you should report is on Rpmfusion mailing list , > > > I think Rpmfusion need rebuild his perl packages > > PS Becuase of your suggestion, in future, I will copy the rpmfusion > list when I make such posts. Hi, ok , RPMFusion started perl mass rebuild yesterday, the perl maintainer notice that "at least some of the perl packages in this output have been retired in Fedora, e.g. * perl-HTML-Tidy * perl-Math-Pari * perl-Crypt-Random * perl-Crypt-Primes * perl-Crypt-RSA Things might look a bit better after removing those. " -- Sérgio M. B. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220621.n.3 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 4 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 26/161 (aarch64), 26/231 (x86_64) New failures (same test not failed in Fedora-Rawhide-20220619.n.0): ID: 1304214 Test: aarch64 Minimal-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1304214 ID: 1304225 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/1304225 ID: 1304228 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1304228 ID: 1304229 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1304229 ID: 1304241 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/1304241 ID: 1304247 Test: aarch64 Server-dvd-iso base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1304247 ID: 1304275 Test: aarch64 Server-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1304275 ID: 1304284 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1304284 ID: 1304291 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1304291 ID: 1304292 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1304292 ID: 1304294 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1304294 ID: 1304298 Test: aarch64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1304298 ID: 1304303 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1304303 ID: 1304336 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1304336 ID: 1304389 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1304389 ID: 1304402 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1304402 ID: 1304435 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1304435 ID: 130 Test: aarch64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/130 ID: 1304492 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1304492 ID: 1304493 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/1304493 ID: 1304494 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1304494 ID: 1304495 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1304495 ID: 1304496 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/1304496 ID: 1304497 Test: x86_64 Server-dvd-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/1304497 ID: 1304499 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1304499 ID: 1304503 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1304503 ID: 1304504 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1304504 ID: 1304505 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1304505 ID: 1304506 Test: x86_64 Workstation-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/1304506 ID: 1304508 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1304508 ID: 1304509 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/1304509 Old failures (same test failed in Fedora-Rawhide-20220619.n.0): ID: 1304177 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1304177 ID: 1304182 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1304182 ID: 1304280 Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1304280 ID: 1304293 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1304293 ID: 1304306 Test: x86_64 Workstation-upgrade desktop_login URL: https://openqa.fedoraproject.org/tests/1304306 ID: 1304314 Test: x86_64 Workstation-upgrade desktop_fprint URL:
Fedora-Cloud-35-20220622.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220621.0): ID: 1304534 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1304534 ID: 1304542 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1304542 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-36-20220622.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-36-20220621.0): ID: 1304518 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1304518 ID: 1304526 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1304526 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
