Re: Release criteria proposal: networking requirements
On Fri, Aug 28, 2020 at 7:52 PM Chris Murphy wrote: > The IPP Everywhere specification requires clients to support DNS-SD > (mDNS is part of that) or WS-Discovery. Printers are required to > support both DNS-SD and WS-Discovery. Avahi and systemd-resolved > support DNS-SD, functionally equating DNS-SD and mDNS. From the spec: "Printers MUST publish a text (TXT) record that provides service information over mDNS. Printers that support dynamic DNS updates MUST publish separate TXT records for each domain that is updated." I'm not completely certain, but I'm wondering whether it's possible to print IPP Everywhere at all, if DNS-SD or WS-Discovery aren't working on the client. Even having the IP address might not be enough. I guess one way to test it would be to run the printing test case with an IPP Everywhere printer, and try to print with avahi stopped. -- Chris Murphy ___ 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
Re: Release criteria proposal: networking requirements
[Sorry for the double post, somewhere along the way desktop@ and kde@ were dropped, so I'm re-adding them and that means double post for test@ and devel@.] Re: add working mDNS to the criterion The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS. Final release criterion says printing via the generic IPP driver must work. This implies discovery or you can't print. Or accept a craptastic user experience by fudging the requirement to say, well as long as an IP address works, the criterion is met. It's even less of a leap if folks can't discover other services like SMB shares. That's more common than printing. Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal. -- Chris Murphy ___ 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
Re: Release criteria proposal: networking requirements
On Fri, Aug 28, 2020 at 5:56 PM Adam Williamson wrote: > > On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote: > > On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson > > wrote: > > > > > > Basic networking > > > > > > It must be possible to establish both IPv4 and IPv6 network connections > > > using DHCP and static addressing. The default network configuration > > > tools for the console and for release-blocking desktops must work well > > > enough to allow typical network connection configuration operations > > > without major workarounds. Standard network functions such as address > > > resolution and connections with common protocols such as ping, HTTP and > > > ssh must work as expected. > > > > What about mDNS? > > ehhh > > I am probably a bit biased on this front because I always found mDNS to > be a pile of garbage and gave up trying to use it a while back. :P But > if a significant amount of people are actually using it and relying on > it, adding it might make sense. Anyone else have input on this? Who out > there does use mDNS? The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS. Final release criterion says printing via the generic IPP driver must work. This implies discovery or you can't print. Or accept a craptastic user experience by fudging the requirement to say, well as long as an IP address works, the criterion is met. It's even less of a leap if folks can't discover other services like SMB shares. That's more common than printing. Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal. -- Chris Murphy ___ 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
[Test-Announce] 2020-08-31 @ 16:00 UTC - Fedora 33 Blocker Review Meeting
# F33 Blocker Review meeting # Date: 2020-08-31 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 3 proposed Beta blockers, 1 proposed Final blocker and 4 proposed Beta freeze exceptions to review, so let's have a Fedora 33 blocker review meeting on Monday! If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F33 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- 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 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
[Test-Announce] Proposal to CANCEL: 2020-08-31 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't have anything urgent this week. We can discuss the network criterion in the blocker review meeting, I think. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks! -- 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 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
Re: Release criteria proposal: networking requirements
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > Hi folks! > > So at this week's blocker review meeting, the fact that we don't have > explicit networking requirements in the release criteria really started > to bite us. In the past we have squeezed networking-related issues in > under other criteria, but for some issues that's really difficult, > notably VPN issues. So, we agreed we should draft some explicit > networking criteria. Update: here's a second draft with feedback so far incorporated, thanks to everyone. Still mulling over whether/how to split it more across milestones. === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). Basic networking It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking VPN connections Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations. Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. -- 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 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
Re: Release criteria proposal: networking requirements
On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote: > On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson > wrote: > > > > Basic networking > > > > It must be possible to establish both IPv4 and IPv6 network connections > > using DHCP and static addressing. The default network configuration > > tools for the console and for release-blocking desktops must work well > > enough to allow typical network connection configuration operations > > without major workarounds. Standard network functions such as address > > resolution and connections with common protocols such as ping, HTTP and > > ssh must work as expected. > > What about mDNS? ehhh I am probably a bit biased on this front because I always found mDNS to be a pile of garbage and gave up trying to use it a while back. :P But if a significant amount of people are actually using it and relying on it, adding it might make sense. Anyone else have input on this? Who out there does use mDNS? -- 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 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
Re: Fedora 33 MATE Compix
hello, q\well that command shows; "Removing: f32-backgrounds-mate noarch 32.2.2-2.fc33 @anaconda 2.0 k Removing dependent packages: mate-system-monitor x86_64 1.24.1-1.fc33 @fedora 11 M Removing unused dependencies: f32-backgrounds-animated noarch 32.2.2-2.fc33 @anaconda 40 M mate-desktop x86_64 1.24.1-1.fc33 @anaconda 183 k which is a bad idea ___ 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
Libreport not working properly on F33 KDE
I already posted this on the IRC channel, but here on mailing it's more appropriate. While trying to send crash-reports this morning, report-gtk stoped working, several times. report-gtk killed by SIGABRT / crash_function: __libc_calloc / package: libreport-gtk-2.14.0-4.fc33 / component: libreport Kernel 5.8.3-300.fc33.x86_64 / Plasma 5.19.4 / kde frameworks 5.73.0 / Qt 5.14.2 / My installation is a F33 kde upgraded yesterday with dnf- plugin-system-upgrade thanks Geraldo ___ 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
Re: Reboot and poweroff commands not working in Rawhide
On Fri, Aug 28, 2020 at 5:59 AM Ifejika Somtochukwu Noble wrote: > > Hi Everyone, > Does anyone know why i experience this once in a while? > I am running Fedora Rawhide > > [noble@noblecontracts ~]$ su > Password: > [root@noblecontracts noble]# reboot > [root@noblecontracts noble]# poweroff > [root@noblecontracts noble]# > > The commands don't seem to have any effect. Why? Top suspects are kernel and systemd. What versions of each? Does 'reboot -f' work? That'll pretty much bypass systemd and do a kernel reboot. If that doesn't work, it's likely kernel. If it does work, the issue is likely systemd related It might be systemd is waiting on something. Try systemctl list-jobs -- Chris Murphy ___ 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
Re: F33 install minimum memory requirements?
On Fri, Aug 28, 2020 at 7:29 AM Alexey A. wrote: > > In fact, the compression ratio is higher when same_pages is taken into > account: > ``` > orig_data_size uncompressed size of data stored in this disk. > This excludes same-element-filled pages (same_pages) since > *no memory is allocated for them*. > same_pages the number of same element filled pages written to this > disk. > *No memory is allocated for such pages*. > ``` > https://www.kernel.org/doc/Documentation/blockdev/zram.txt > Check `SwapTotal - SwapFree` instead of DATA if you want to check real > compression ratio. Good to know! Thanks! -- Chris Murphy ___ 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
Re: Fedora 33 MATE Compix
On Fri, 2020-08-28 at 14:38 +, Coz_DS wrote: > Clean install, F33 Mate, rpmfusion installed plus free and non free tainted. > I do " sudo dnf upgrade --refresh" and det this error; > Error: Transaction test error: > file /usr/share/backgrounds/mate/default.xml from install of > f33-backgrounds-mate-33.0.2-1.fc33.noarch conflicts with file from package > f32-backgrounds-mate-32.2.2-2.fc33.noarch What does 'dnf remove f32-backgrounds-mate' say? -- 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 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
Fedora 33 MATE Compix
Clean install, F33 Mate, rpmfusion installed plus free and non free tainted. I do " sudo dnf upgrade --refresh" and det this error; Error: Transaction test error: file /usr/share/backgrounds/mate/default.xml from install of f33-backgrounds-mate-33.0.2-1.fc33.noarch conflicts with file from package f32-backgrounds-mate-32.2.2-2.fc33.noarch ___ 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
Fedora-33-20200828.n.0 compose check report
No missing expected images. Failed openQA tests: 9/181 (x86_64) New failures (same test not failed in Fedora-33-20200827.n.0): ID: 650037 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/650037 Old failures (same test failed in Fedora-33-20200827.n.0): ID: 649972 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/649972 ID: 649978 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/649978 ID: 650010 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/650010 ID: 650020 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/650020 ID: 650021 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/650021 ID: 650051 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/650051 ID: 650078 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/650078 ID: 650079 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/650079 Soft failed openQA tests: 92/181 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-33-20200827.n.0): ID: 649961 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/649961 Old soft failures (same test soft failed in Fedora-33-20200827.n.0): ID: 649901 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/649901 ID: 649902 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/649902 ID: 649904 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/649904 ID: 649905 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/649905 ID: 649906 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/649906 ID: 649907 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/649907 ID: 649908 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/649908 ID: 649909 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/649909 ID: 649912 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/649912 ID: 649913 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/649913 ID: 649914 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/649914 ID: 649915 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/649915 ID: 649930 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/649930 ID: 649936 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/649936 ID: 649941 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/649941 ID: 649942 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/649942 ID: 649946 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/649946 ID: 649947 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/649947 ID: 649959 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/649959 ID: 649982 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/649982 ID: 649983 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/649983 ID: 649993 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/649993 ID: 65 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/65 ID: 650001 Test: x86_64 universal install_blivet_with_swap URL: https://openqa.fedoraproject.org/tests/650001 ID: 650002 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/650002 ID: 650004 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/650004 ID: 650005 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/650005 ID: 650007 Test: x86_64 universal upgrade_2_minimal_64bit URL:
Re: Reboot and poweroff commands not working in Rawhide
On Fri, 2020-08-28 at 12:58 +0100, Ifejika Somtochukwu Noble wrote: > Hi Everyone,Does anyone know why i experience this once in a while? > I am running Fedora Rawhide > > [noble@noblecontracts ~]$ su > Password: > [root@noblecontracts noble]# reboot > [root@noblecontracts noble]# poweroff > [root@noblecontracts noble]# > > The commands don't seem to have any effect. Why? and systemctl reboot ? and systemctl poweroff ? BTW even in Centos 7, I noticed or I have the imprecision that systemctl commands works better , but now reboot is a symbol link to bin/systemctl -- 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
Fedora 33 compose report: 20200828.n.0 changes
OLD: Fedora-33-20200827.n.0 NEW: Fedora-33-20200828.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:3 Upgraded packages: 1 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:889.49 KiB Size of upgraded packages: 60.82 KiB Size of downgraded packages: 0 B Size change of upgraded packages: 802 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-33-20200828.n.0.iso = DROPPED IMAGES = Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-33-20200827.n.0-sda.raw.xz = ADDED PACKAGES = = DROPPED PACKAGES = Package: geronimo-interceptor-1.0.1-24.fc33 Summary: Java EE: Interceptor API v3.0 RPMs:geronimo-interceptor geronimo-interceptor-javadoc Size:275.13 KiB Package: geronimo-jaxrpc-2.1-27.fc33 Summary: Java EE: Java API for XML Remote Procedure Call v1.1 RPMs:geronimo-jaxrpc geronimo-jaxrpc-javadoc Size:364.13 KiB Package: istack-commons-3.0.11-1.fc33 Summary: Common code for some Glassfish projects RPMs:import-properties-plugin istack-commons istack-commons-buildtools istack-commons-maven-plugin istack-commons-runtime istack-commons-soimp istack-commons-test istack-commons-tools Size:250.22 KiB = UPGRADED PACKAGES = Package: appliance-tools-011.1-1.fc33 Old package: appliance-tools-010.2-1.fc33 Summary: Tools for building Appliances RPMs: appliance-tools Size: 60.82 KiB Size change: 802 B Changelog: * Wed Aug 26 2020 Neal Gompa - 010.2-2 - Add proposed patch to fix configuring fstab and grub for btrfs (#1855034) * Wed Aug 26 2020 Neal Gompa - 010.2-3 - Refresh patches for fixing bootloader config for btrfs * Wed Aug 26 2020 Neal Gompa - 011.0-1 - Update to 011.0 release - Drop merged patches * Thu Aug 27 2020 Neal Gompa - 011.1-1 - Update to 011.1 release = DOWNGRADED PACKAGES = ___ 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
Reboot and poweroff commands not working in Rawhide
Hi Everyone, Does anyone know why i experience this once in a while? I am running Fedora Rawhide [noble@noblecontracts ~]$ su Password: [root@noblecontracts noble]# reboot [root@noblecontracts noble]# poweroff [root@noblecontracts noble]# The commands don't seem to have any effect. Why? -- FAS: noblesomto IRC: noble ___ 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
Re: Release criteria proposal: networking requirements
On Thu, Aug 27, 2020 at 6:08 PM Chris Murphy wrote: > What about mDNS? > > Something to the effect that if it's installed and enabled by a > default package set for an edition, it should work (resolve and > respond). That means it would apply to Workstation and KDE. It > wouldn't apply to Cloud, or Server. I'm not sure if IoT enables it. > That sounds good to me, but it seems to belong to the Final milestone rather than Basic or Beta. Can be proposed separately. ___ 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
Re: Release criteria proposal: networking requirements
On Thu, Aug 27, 2020 at 8:37 PM Adam Williamson
wrote:
> > > It must be possible to establish both IPv4 and IPv6 network connections
> > > using DHCP and static addressing. The default network configuration
> > > tools for the console and for release-blocking desktops must work well
> > > enough to allow typical network connection configuration operations
> > > without major workarounds.
> >
> >
> > I'm a bit confused here. If you specifically say "for the console and for
> > release-blocking desktops", does that mean it doesn't apply to the
> > installer? Because at the top you say it applies to both, but here it
> > sounds very specific.
>
> No, I didn't intend that, I was just making sure to cover both console
> and desktop. We can make it "for the console, for release-blocking
> desktops and for installer environments" if you like.
>
I guess it would help to avoid the confusion.
> > If it applies to the installer, does this mean that *all* ways to
> configure
> > this in the installer must work (i.e. kernel cmdline, kickstart, gui,
> tui)?
> > That seems quite demanding for a Basic criterion.
>
> That's kind of a tricky one, because I agree it's broad, but on the
> other hand there are situations where you kinda need each of them. You
> can't always have a monitor and a human to do it interactively in the
> install environment, and if you're retrieving a kickstart or the
> installer environment itself (after a PXE boot, say) over the network,
> you need the kernel cmdline case to work.
> So, I mean, it's difficult. We *could* split it across Basic and Final,
> but I can't immediately see a clear rationale for how to do that. Any
> ideas? I guess we could look at what the criteria require for things
> like kickstart and PXE boot and try to align them...
>
PXE is Beta, kickstart *delivery* is Beta. There are no further criteria
related to kickstarts, I think I had I have an #action to propose that
criterion that's a few years old now.
The "obvious" split would be to require user-related actions (gui/tui)
sooner and professional-related actions later (kickstarts, cmdline). But at
the same time, specifically for the installer, the professional-related
actions are pretty important for QA to deliver a decent test coverage.
Which coincidentally is also Beta ("Bug hinders execution of required Beta
test plans or dramatically reduces test coverage"), but that doesn't feel
right, if we truly want to aim for having Basic criteria valid all the time
and applying Basic tests during package gating.
In the past, user actions took precedence over e.g. mass deployment
features, because we tested manually first among local testers, and only
then made public Alpha/Beta/Final releases for the mass audience. But with
continuous testing through automation, the picture is reversed, and we need
features like kickstarts and kernel cmdline options sooner than we need
manual user actions.
So... I don't know, this is tricky :) Putting it all under Basic is of
course ideal for us, and since there's still no meaningful difference
between Basic and Beta, I guess it's good enough for now. Once there is
some difference (like build gating rejection when these criteria are
violated), the installer team might push for moving some of those
requirements to a later stage.
___
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
Fedora-Cloud-31-20200828.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64) -- 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
Fedora-IoT-33-20200828.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-33-20200826.0): ID: 649883 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/649883 Soft failed openQA tests: 2/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20200826.0): ID: 649878 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/649878 ID: 649879 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/649879 Passed openQA tests: 13/16 (x86_64) -- 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
Fedora-Cloud-32-20200828.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20200827.0): ID: 649871 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/649871 Passed openQA tests: 6/7 (x86_64) -- 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
