Fedora-Cloud-33-20211110.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-33-20211109.0): ID: 1059220 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1059220 ID: 1059229 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1059229 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
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Tue, Nov 09, 2021 at 02:38:59PM +0100, Kamil Paral wrote:
> 1. In the Proposed Common Issues category, how are the topics intended to
> look like? Will the initial topic description be a question ("my sound is
> broken, how do I fix it?") and then somebody will provide a solution which
> will get marked as such, or will the initial topic description be already a
> solution (i.e. a similar text to what is currently on the CommonBugs wiki)?
I think the topic titles will be the same as with Common Bugs now, like
"Configured repositories in Discover jump around in the list" or "Clipboard
is not shared with KDE virtual machines".
The site name, "Ask Fedora", makes me _want_ to force them into the form of
a question just... to make it all nice... but in practice most topic tiles
are in the form of a problem summary already. ("Closing the laptop lid does
not turn off the screen", "2-finger scroll occasionally disabled".) So I
think that keeping to the current title format is good.
I can go either way on whether the first post in the topic should also
provide the solution, or whether we should used the answer-solution format.
As I'm reviewing some of the previous wiki pages now, I actually am kind of
inclined to think that it's better to have stronger problem/solution
separation. But I could be convinced either way.
> 2. In the Common Issues category, will the topics look the same as in 1)
> (we'll simply re-tag them there), or differently? (e.g. a question-style in
> Proposed, a solution-style in actual Common Issues).
I was thinking just move them, yeah.
> 3. Can we easily move a topic (or add a tag to it) into the Proposed Common
> Issues category, when it is currently in a completely different one? And
> similarly, we can easily move out a topic from Proposed Common Issues to
> some generic "Ask" category?
Yes to both. And URLs for topics do not include the category, so moving them
will not break any existing external links.
> 4. The solution text often needs maintenance. Some clarifications, newly
> discovered workarounds, etc. If the original solution text was created by a
> community member, is it expected that we'll simply edit his/her post? Or
> what do we do? On wiki, it is owner-less, which avoids the problem
> "somebody edited my post, and it's still displayed under my name, but those
> aren't my words, and I don't like it".
There is a setting "Make new topics wikis by default" which we would enable
for these categories. It doesn't make the post ownerless, though. I think we
could set these expectations reasonably in the description of the category.
And if someone at some point really doesn't want their name attached, we can
always move the Solved check.
> I'm sure I'll have more questions after I think about it a bit more :-)
Sure. :)
> Overall, I don't have strong opinions on the proposal. A wiki is easier for
> us, but otoh more community involvement would definitely be nice. We could
> try a different approach as an experiment. If we do, it might be good to
> start it right away, so that some initial problems are resolved before the
> F36 cycle runs in full swing.
That does seem like a good idea. Maybe not quite _right away_, but soon.
Would you suggest duplicating the F35 Common Bugs, or making some _possible_
F36 ones based on Rawhide issues?
--
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
Re: Perpetual Fedora
On Mon, Nov 08, 2021 at 11:38:27PM +, Rick Marshall wrote: > At times we can be managing several hundred desktops. They get > installed over time and with a script that makes sure they > auto-update packages and reboot if there is a kernel update. For > systems that can't be allowed to reboot we get an email advising us. > All of that is good. Okay, this is a tangent, but: have you considered using `dnf offline-update` on the systems where a reboot is okay? That minimizes the chances of problems from updates happening underneath something that expected them to not change. And back off the tangent: if you did that, the version upgrade is usually just a matter of using `dnf system-upgrade` instead, once or twice a year. > I guess what I was really thinking about was a version free > repository. Similar to the no_arch repository. > > This would be for application developers etc who don't need to rely > on distribution version. It could even apply to kernels. I guess I don't get how this would help. It isn't the _number_ that causes incompatibility, but rather accumulated underlying changes. A rolling/perpetual version still has those changes, but unpredictably. > As a package developer my biggest issue has always been keeping > enough versions of Fedora and RH on machines to create versions of > the product. A single release will always need 3-6 OS packages. I'm > not sure this is either productive or efficient. I can't do anything about different versions of RHEL, although there are possible solutions here which generalize. Rather than targetting multiple releases, build against RHEL UBI* and distribute your application as a container image (or Flatpak, if it's a desktop application). Or, if that doesn't work for you, you could just say that you only support the latest Fedora release? I think it's _nicer_ to provide users with options, but that's always a possibility. I'd love to say "we can offer a stable API that doesn't change for years", but... well, that's expensive to do, which is why there is RHEL. :) > PS really appreciate the work you guys do. On behalf of everyone, thanks! * https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image -- 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
Notice: openQA test failures today - expected
Hey folks! Just a heads up about test failures in openQA overnight and today. The server_cockpit_updates test was failing overnight; this was because I switched from virtio to qxl graphics to work around a bug in Rawhide. Unfortunately there seems to be a bug in qxl with a specific thing that test does (snapshot the machine, run X from a console, restore the snapshot, run X from a console again). I've switched that test back to virtio graphics and re-triggered all the failed runs, but since then the planned Koji outage has started. All update tests that run during the Koji outage will fail because the test process relies on downloading the update packages from Koji. So some of the re-runs for the other bug failed. We will not be able to get successful runs until the Koji outage is over. Basically, if you're seeing an openQA failure on your update, hang tight for the end of the Koji outage. There are two updates with other issues (a Pango update that changes font rendering and so will need a lot of openQA screenshots to be re- taken, and a Python update that seems to break `systemctl stop ipa.service` for some reason), but again I can't really work on those with Koji down, so will wait for it to be back. Thanks folks! -- 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: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 8:37 AM Kamil Paral wrote: > > I find it hard to draw the line somewhere between all these cases. So > aborting a previous operation is not ok, but not even starting a second > operation is ok? Installing and removing the same package is not blocking? > What about installing two different packages, would that block? What about > installing A and removing B? I don't honestly think it's a good idea to dig > into the million of sub-cases here. > Just imagine we're not talking about the package manager but a file manager > instead. If you could either create a file, or remove a file, but you > couldn't create the file, or you couldn't remove 2 different either > sequentially or together, that would clearly be a blocker (I hope). It would > be quite obvious that this is a basic functionality. So why isn't this a > basic functionality for the package manager? And why do we have (it seems) a > different quality bar for dnf vs graphical package managers? I don't think > these bugs would be waived for dnf. > I agree with František's comment that the DNF case is different enough in how it functions that it's not a fair comparison. I do think that aborting a previous operation is not okay, but refusing to start a second operation until the first is done is. Ideally with a clear message explaining why, but not necessarily. So I still disagree with you, but my position is softening. I'd rather we have a clearly-defined and understood set of criteria that I disagree with in some places than to try to make every criterion match my preferences. :-) So while I disagree, I'm happy to move forward with this. > So let's reduce the original requirement into something like this: > * configure software sources by enabling/disabling pre-defined official > repositories and then adjust the available software pool accordingly > > Does it sound better? Yes, that works for me. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Thu, Nov 4, 2021 at 4:43 PM Matthew Miller
wrote:
> Specifics
> -
>
> We’d create a new top-level category, “Common Issues”. Posting directly
> in the category would not be allowed. Instead, there would be a
> *subcategory*, “Proposed Common Issues”.
>
> New topics in “Proposed Common Issues” would use the template feature,
> prompting for the necessarily information and keeping the format
> consistent. Unfortunately, there are no macros to do the fancy things
> the current wiki process uses, which I will freely admit is a drawback.
>
> Each topic would be tagged with the release that it corresponds to
> (and, ideally other tags, like the installation / upgrade / workstation
> / etc. sections on the wiki — we could make that mandatory or just by
> convention).
>
> Members of the QA team (based on group membership, automatically once
> [Does `sso overrides groups` work with Oauth2? - sso - Discourse
> Meta][4] is fixed upstream) and possibly other volunteers will be
> marked as category moderators, and so can promote topics to the
> higher-level “Common Issues” after vetting them.
>
> And, we’d turn on voting, and ask people to vote for issues that they
> have also experienced. Not scientific, but gives a measure that we
> don’t have now.
>
Soo... I finally had time to read this. I need a few things clarified:
1. In the Proposed Common Issues category, how are the topics intended to
look like? Will the initial topic description be a question ("my sound is
broken, how do I fix it?") and then somebody will provide a solution which
will get marked as such, or will the initial topic description be already a
solution (i.e. a similar text to what is currently on the CommonBugs wiki)?
2. In the Common Issues category, will the topics look the same as in 1)
(we'll simply re-tag them there), or differently? (e.g. a question-style in
Proposed, a solution-style in actual Common Issues).
3. Can we easily move a topic (or add a tag to it) into the Proposed Common
Issues category, when it is currently in a completely different one? And
similarly, we can easily move out a topic from Proposed Common Issues to
some generic "Ask" category?
4. The solution text often needs maintenance. Some clarifications, newly
discovered workarounds, etc. If the original solution text was created by a
community member, is it expected that we'll simply edit his/her post? Or
what do we do? On wiki, it is owner-less, which avoids the problem
"somebody edited my post, and it's still displayed under my name, but those
aren't my words, and I don't like it".
I'm sure I'll have more questions after I think about it a bit more :-)
Overall, I don't have strong opinions on the proposal. A wiki is easier for
us, but otoh more community involvement would definitely be nice. We could
try a different approach as an experiment. If we do, it might be good to
start it right away, so that some initial problems are resolved before the
F36 cycle runs in full swing.
___
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-20211109.n.0 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 8/192 (x86_64), 73/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211108.n.0): ID: 1058419 Test: x86_64 universal install_shrink_ntfs URL: https://openqa.fedoraproject.org/tests/1058419 ID: 1058464 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1058464 ID: 1058487 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1058487 Old failures (same test failed in Fedora-Rawhide-20211108.n.0): ID: 1058213 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/1058213 ID: 1058236 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1058236 ID: 1058242 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1058242 ID: 1058262 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1058262 ID: 1058274 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1058274 ID: 1058299 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1058299 ID: 1058306 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/1058306 ID: 1058307 Test: aarch64 Server-dvd-iso install_repository_nfsiso_variation@uefi URL: https://openqa.fedoraproject.org/tests/1058307 ID: 1058310 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi URL: https://openqa.fedoraproject.org/tests/1058310 ID: 1058319 Test: aarch64 Server-dvd-iso install_repository_nfs_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1058319 ID: 1058320 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi URL: https://openqa.fedoraproject.org/tests/1058320 ID: 1058367 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1058367 ID: 1058371 Test: aarch64 Cloud_Base-qcow2-qcow2 base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/1058371 ID: 1058372 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1058372 ID: 1058373 Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1058373 ID: 1058374 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1058374 ID: 1058375 Test: aarch64 Cloud_Base-qcow2-qcow2 base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1058375 ID: 1058376 Test: aarch64 Cloud_Base-qcow2-qcow2 base_system_logging@uefi URL: https://openqa.fedoraproject.org/tests/1058376 ID: 1058377 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1058377 ID: 1058378 Test: aarch64 Cloud_Base-qcow2-qcow2 base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1058378 ID: 1058412 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/1058412 ID: 1058441 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/1058441 ID: 1058463 Test: aarch64 universal upgrade_server_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1058463 ID: 1058470 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1058470 ID: 1058473 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1058473 ID: 1058490 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1058490 ID: 1058504 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1058504 ID: 1058507 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1058507 ID: 1058508 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1058508 ID: 1058509 Test: aarch64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1058509 ID: 1058510 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/1058510 ID: 1058511 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/1058511 ID: 1058512 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/1058512 ID: 1058513 Test: aarch64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1058513 ID: 1058516 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL:
Fedora rawhide compose report: 20211109.n.0 changes
OLD: Fedora-Rawhide-20211108.n.0 NEW: Fedora-Rawhide-20211109.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 4 Dropped packages:5 Upgraded packages: 90 Downgraded packages: 0 Size of added packages: 123.44 KiB Size of dropped packages:5.86 MiB Size of upgraded packages: 1.77 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.51 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20211108.n.0.iso = ADDED PACKAGES = Package: python-azure-mgmt-servicelinker-1.0.0b1-2.fc36 Summary: Microsoft Azure Servicelinker Management Client Library for Python RPMs:python3-azure-mgmt-servicelinker Size:45.99 KiB Package: python-cro-0.0.5.0-1.fc36 Summary: An implementation of CRO metaheuristic algorithm RPMs:python3-cro Size:28.83 KiB Package: rust-dirs3-3.0.2-1.fc36 Summary: Platform abstractions for common directories RPMs:rust-dirs3+default-devel rust-dirs3-devel Size:27.42 KiB Package: rust-open1-1.7.1-1.fc36 Summary: Open a path or URL using the program configured on the system RPMs:rust-open1+default-devel rust-open1-devel Size:21.20 KiB = DROPPED PACKAGES = Package: kdocker-5.3-4.fc35 Summary: Dock any application in the system tray RPMs:kdocker Size:699.88 KiB Package: perl-Nagios-Plugin-0.37-21.fc35 Summary: Family of perl modules to streamline writing Nagios plugins RPMs:perl-Nagios-Plugin Size:26.70 KiB Package: python-email_reply_parser-0.3.0-20140523git76e9481.fc35.24 Summary: Email reply parser library for Python 2 RPMs:python3-email_reply_parser Size:15.52 KiB Package: python-power-1.4-24.fc35 Summary: Cross-platform system power status information RPMs:python3-power Size:28.30 KiB Package: yarock-1.4.0-13.fc35 Summary: Lightweight, beautiful music player RPMs:yarock Size:5.11 MiB = UPGRADED PACKAGES = Package: NetworkManager-strongswan-1.5.2-1.fc36 Old package: NetworkManager-strongswan-1.5.0-4.fc35 Summary: NetworkManager strongSwan IPSec VPN plug-in RPMs: NetworkManager-strongswan NetworkManager-strongswan-gnome Size: 203.80 KiB Size change: 437 B Changelog: * Mon Nov 08 2021 Petr Menk - 1.5.2-1 - Update to 1.5.2 Package: apache-commons-pool-1.6-27.fc36 Old package: apache-commons-pool-1.6-26.fc35 Summary: Apache Commons Pool Package RPMs: apache-commons-pool apache-commons-pool-javadoc Size: 491.56 KiB Size change: -41 B Changelog: * Mon Nov 08 2021 Christian Schuermann 1.6-27 - Cleanup spec file - Enable tests Package: awscli-1.22.0-1.fc36 Old package: awscli-1.21.12-1.fc36 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.13 MiB Size change: 22.18 KiB Changelog: * Mon Nov 08 2021 Gwyn Ciesla - 1.22.0-1 - 1.22.0 Package: catatonit-0.1.7-1.fc36 Old package: catatonit-0.1.6-1.fc36 Summary: A signal-forwarding process manager for containers RPMs: catatonit Size: 1.42 MiB Size change: 12.49 KiB Changelog: * Mon Nov 01 2021 RH Container Bot - 0.1.7-1 - autobuilt v0.1.7 Package: containers-common-4:1-35.fc36 Old package: containers-common-4:1-34.fc36 Summary: Common configuration and documentation for containers RPMs: containers-common Size: 73.15 KiB Size change: 318 B Changelog: * Mon Nov 08 2021 Dan Walsh - 4:1-35 - Update to grab latest man pages and configuration files Package: dialog-1.3-38.20211107.fc36 Old package: dialog-1.3-37.20210621.fc35 Summary: A utility for creating TTY dialog boxes RPMs: dialog dialog-devel Size: 1.71 MiB Size change: -2.09 KiB Changelog: * Mon Nov 08 2021 Miroslav Lichvar - 1.3-38.20211107 - update to 1.3-20211107 Package: dkms-3.0.0-1.fc36 Old package: dkms-2.8.8-1.fc36 Summary: Dynamic Kernel Module Support Framework RPMs: dkms Size: 57.56 KiB Size change: -422 B Changelog: * Mon Nov 08 2021 Simone Caronni - 3.0.0-1 - Update to 3.0.0. Package: dummy-test-package-gloster-0-5716.fc36 Old package: dummy-test-package-gloster-0-5696.fc36 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 349.47 KiB Size change: 1.24 KiB Changelog: * Mon Nov 08 2021 packagerbot - 0-5697 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5698 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5699 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5700 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5701 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5702 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5703 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5704 - rebuilt * Mon Nov 08 2021 packagerbot - 0-5705
[Test-Announce] [Fedora 36] Call for Test Days
Hi Fedora users, developers, and friends! It's time to start thinking about Test Days for Fedora 36. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance, we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization or any combination of the two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's an example https://pagure.io/fedora-qa/issue/624 . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days . There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Beta release or the time after the feature freeze or the Final Freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or time frame you'd like, and we'll figure it out from there. If you don't want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days: GNOME Test Day* i18n Test Day* Kernel Test Week(s)* Upgrade Test Day* IoT Test Week* Cloud Test Day* Fedora CoreOS Test Week* And don't be afraid, there are a lot of more slots available for your own Test Day! [*] These are the test days we run generally to make sure everything is working fine, the dates get announced as we move into the release cycle. If you have any questions about the Test Day process, please don't hesitate to contact me or any member of the Fedora QA team on test at lists.fedoraproject.org or in #fedora-qa on IRC. Thanks! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Fedora 36] Call for Test Days
Hi Fedora users, developers, and friends! It's time to start thinking about Test Days for Fedora 36. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance, we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization or any combination of the two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's an example https://pagure.io/fedora-qa/issue/624 . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days . There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Beta release or the time after the feature freeze or the Final Freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or time frame you'd like, and we'll figure it out from there. If you don't want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days: GNOME Test Day* i18n Test Day* Kernel Test Week(s)* Upgrade Test Day* IoT Test Week* Cloud Test Day* Fedora CoreOS Test Week* And don't be afraid, there are a lot of more slots available for your own Test Day! [*] These are the test days we run generally to make sure everything is working fine, the dates get announced as we move into the release cycle. If you have any questions about the Test Day process, please don't hesitate to contact me or any member of the Fedora QA team on test at lists.fedoraproject.org or in #fedora-qa on IRC. Thanks! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ 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-34-20211109.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-34-20211108.0): ID: 1057799 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1057799 ID: 1057806 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1057806 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
Re: new criterion proposal: Graphical package managers
On Tue, Nov 9, 2021 at 4:47 AM Chris Murphy wrote: > When installing, removing, or updating software? If I click an install > button, the selected app should be installed or it's a blocking bug. > Same for removal, same for updating. If it lets you click install for > multiple programs in sequence, they should all be successfully > installed. If that's not possible, then don't let users queue up > multiple programs for installation. > I tend to agree, but others don't: https://pagure.io/fedora-qa/blocker-review/issue/560 https://meetbot.fedoraproject.org/fedora-meeting/2021-10-21/f35-final-go_no_go-meeting.2021-10-21-17.00.log.html#l-130 That's why an explicit action list seems like the best forward, if we can agree on it. ___ 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-35-20211109.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (aarch64) New failures (same test not failed in Fedora-Cloud-35-20211108.0): ID: 1057790 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1057790 Soft failed openQA tests: 1/8 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211108.0): ID: 1057783 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1057783 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
