[Test-Announce] [Test Week] F33 Btrfs by default starts 2020-08-31
Hey All, A new change proposal has been submitted for the Fedora 33 release cycle which entails the usage of Btrfs by default [0] for Workstations and Spins across x86_64 and ARM architectures, As a result, we have organized a test week from Monday, Aug 31, 2020. As a part of this test week, we will aim at folks running a VM or bare metal install with Btrfs as storage and sharing their experience for the following scenarios: 1. Install use it normally for a week and report any and all issues, concerns, questions that come up 2. Testing the BlivetGUI installer options along with the Custom 3. Suspend to RAM 4. Suspend to Disk 5. Reinstalling F33 on an installed Fedora partition and preserving /home and its data 6. Help find outdated docs and report them to QA team and WS team Results can be submitted for the test cases[2] Refer to the wiki page[1] for links to the test cases and materials you’ll need to participate! As usual, we will hang out on the #fedora-test-day over Freenode to address questions [0] https://fedoraproject.org/wiki/Changes/BtrfsByDefault [1] https://fedoraproject.org/wiki/Test_Day:2020-08-31_Btrfs_default [2]https://testdays.fedorainfracloud.org/events/92 Thanks -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
services impact on startup times
Hi, These are based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso in a VM. The numbers are different on bare metal but correlate. The only standout is rngd.service. That's a pretty big single hit, percentage wise. And I don't know if we even need it anymore. Among the rest, perhaps atd.service and crond.service could be disabled by default on new installations, in favor of systemd timers. Startup finished in 1.320s (kernel) + 1.344s (initrd) + 7.727s (userspace) = 10.392s disable atd.service Startup finished in 1.308s (kernel) + 1.310s (initrd) + 7.557s (userspace) = 10.176s disable dbxtool.service Startup finished in 1.302s (kernel) + 1.291s (initrd) + 7.527s (userspace) = 10.120s disable import-state.service Startup finished in 1.308s (kernel) + 1.326s (initrd) + 7.410s (userspace) = 10.044s disable iscsi.service Startup finished in 1.316s (kernel) + 1.303s (initrd) + 7.177s (userspace) = 9.797s disable libvirtd.service Startup finished in 1.316s (kernel) + 1.266s (initrd) + 6.779s (userspace) = 9.361s disable lvm2-monitor.service Startup finished in 1.315s (kernel) + 1.323s (initrd) + 6.750s (userspace) = 9.389s disable mdmonitor.service Startup finished in 1.316s (kernel) + 1.350s (initrd) + 6.675s (userspace) = 9.342s disable ModemManager.service Startup finished in 1.270s (kernel) + 1.305s (initrd) + 7.052s (userspace) = 9.629s disable nfs-convert.service Startup finished in 1.312s (kernel) + 1.343s (initrd) + 6.958s (userspace) = 9.614s disable rngd.service Startup finished in 1.308s (kernel) + 1.277s (initrd) + 5.247s (userspace) = 7.833s disable switcheroo-control.service Startup finished in 1.308s (kernel) + 1.334s (initrd) + 5.223s (userspace) = 7.867s disable vboxservice.service Startup finished in 1.301s (kernel) + 1.302s (initrd) + 5.176s (userspace) = 7.780s disable crond.service Startup finished in 1.310s (kernel) + 1.278s (initrd) + 5.076s (userspace) = 7.665s preset-all Startup finished in 1.316s (kernel) + 1.312s (initrd) + 7.869s (userspace) = 10.498s ##stopwatch 11.35 disable atd.service crond.service iscsi.service rngd.service vboxservice.service Startup finished in 1.305s (kernel) + 1.294s (initrd) + 5.505s (userspace) = 8.105s ##stopwatch 8.89 All of these times are based on 'systemd-analyze'. The stopwatch method is less precise but still demonstrates the difference is real. It may not be a big enough deal to do anything about it this cycle, but could be something to look at for the next. Maybe more opportunities are available. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: %lua_requires behaves differently in F33+
On Sat, 2020-08-29 at 19:16 +0200, Miro Hrončok wrote: > On 29. 08. 20 4:43, Michel Alexandre Salim wrote: > > - I'll refactor lua in Fedora so lua-devel pulls in lua-rpm-macros > > rather than shipping macros.lua, then enable shipping macros.lua in > > lua-rpm-macros (right now it's excluded on Fedora to avoid file > > conflicts) > > Please make it conditional on rpm-build. That way, Lua developers not > interested > in RPM packaging won't get unneeded packages. > Definitely. Right now anyone pulling in lua-devel gets the macros which is not ideal. > See python3-devel: > > Requires: (python3-rpm-macros if rpm-build) > Yup, I've been borrowing liberally from the Python rpm-macros package (and the updated packaging guideline I'm working on is also liberally borrowing from the Python guidelines. Thanks for this pointer though, I've not started looking at python-devel yet! > (BTW count me in for the SIG) > Will do, thanks for the interest! I figured some core developers will be interested given how critical some Lua scripts are for packaging. Quick question: for Python there's both python-devel and python-sig -- this seems overkill for Lua, right? Would starting lua@lists be enough? (Also, I couldn't find documentation on starting a new mailing list. Presumably an Infra pagure ticket?) Thanks, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: Switching package to fragmented default configuration
On Sat, Aug 29, 2020, at 2:19 PM, Igor Raits wrote: > And only way to get to the distribution defaults is to download RPM > with matching version, unpack it and get its /etc/foo.conf. On ostree-based systems, the defaults for /etc are in /usr/etc, so you always have them - it needs this to do the "3 way merge" upgrade for config files. > > What is the actual benefit of this? Needlessly breaking existing > > configuration, making it impossible to cleanly upgrade systems, > > or write logic that takes into account the existing configuration of > > a given > > program? If you blow away /etc/, you will have a well and truly > > broken system. > > If you want to start a configuration from scratch, re-install. > > There's nothing > > wrong with that approach, and it works very well. This has been the > > case for > > nearly three decades now https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ touches on some of the benefits of "fragmented" configs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
Observations based on Fedora-Workstation-Live-x86_64-33-20200828.n.0.iso 1. The ext4+squashfs image on media has no /etc/resolv.conf at all; this is what forms the basis of /dev/mapper/live-base, and is the source for installations (copied by rsync). 2. The installation live environment uses /dev/mapper/live-rw as system root; it has an /etc/resolv.conf symlink pointed to /run/systemd/resolve/stub-resolv.conf 3. The installed system has an /etc/resolv.conf file following installation (while still in the installation environment). First line is: # This file is managed by man:systemd-resolved(8). Do not edit. 4. Following a reboot, the system has an /etc/resolv.conf file. First line is: # Generated by NetworkManager Are these the expected behavior? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: Switching package to fragmented default configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-08-29 at 11:02 -0700, John M. Harris Jr wrote: > On Saturday, August 29, 2020 1:00:17 AM MST Samuel Sieb wrote: > > On 8/28/20 9:40 PM, John M. Harris Jr wrote: > > > > > Please don't invent a new logic, especially the one that systemd > > > does. > > > This makes it very difficult to figure out where in the world the > > > configuration file for a given program is. With systemd, sure, > > > it's not > > > so bad, as the > > > > System defaults go in /usr/share/. Admin overrides go in > > /etc. > > If you're going to put defaults anywhere, /etc is the most logical > place. When > admins want to override, they'll modify the files that are there. > See, for > example, /etc/resolv.conf, the file used to tell the system resolver > what DNS > servers to use. By default, it's generated by your installer or by > NetworkManager. When modified, it's now using "admin overrides". And only way to get to the distribution defaults is to download RPM with matching version, unpack it and get its /etc/foo.conf. When default distribution configs are in /usr, then you can easily remove config from /etc and that's it. > > > command will tell you where the unit file is. There's no such > > > command for, > > > for example, chronyd, httpd or any other program that itself > > > isn't using > > > such a convoluted configuration system. Even systemd wouldn't > > > work if you > > > blew away / etc. > > > > > > It should. If not, that's where they want to get to. > > What is the actual benefit of this? Needlessly breaking existing > configuration, making it impossible to cleanly upgrade systems, > or write logic that takes into account the existing configuration of > a given > program? If you blow away /etc/, you will have a well and truly > broken system. > If you want to start a configuration from scratch, re-install. > There's nothing > wrong with that approach, and it works very well. This has been the > case for > nearly three decades now. First of all, as long as /etc/foo.conf location stays same, it takes precedence over the /usr configuration, so nothing will be broken on the update. > -- > John M. Harris, Jr. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9KnEoACgkQEV1auJxc Hh7/lg/9HGg1AQL/xLQbYqq7iyta/dMxEoPslIMuMFo5q2Q5c4WkvIWRXBXTYdRU hPE9KeM2byOcQU6q3OVg6Rs6XsBDX9uCjPNYjLcMf/tOLBZ5YjGXqXcotbGRpj2q dJK4J8skSW2VybaFO0Gm7gygFZwJoWQqK/G/n3tfhNp4C2PFE//PJDzUP0hsZlgM S5K5qnpIW3JPIk9bnDBK8AUeJwZIXoDkzPX+rLUXv4RjmB+/vnNk5Qupbewq8uRT WHu+YdZNeFdq4PpUvb1zVZgbXBgg+kHpdd75Rmf2hgFsl33ZGTkjgNYFkSzxYaPt vY7728B5Y951dYASvlL/V0yWjtTplTOxySPTgCTMrOgBjvQQZW2cdGINSXT5UmHn tHlAGh+lrSIorLLN8tGHKr4nDAEv2VUIb87/K3rGABEQ41yXiSul+vDR/hdiXqai 3l5ksSu4hvNwU1R5kPjfFEW6soIjP8smplbyDXjSfzO5rUhZbxA+YjEcwOVBOtuv CJgKham4RXmVbPtXPHnsBL9YsDvhcH3SIzVZkpzPFCbJDYzJFbfI78n1J4cacxnF UWJN/+9HGvRSFAa9oiNR6Lprx3dX3Uo1DCT4+TL8aZsRFSd9UrblJ/loUALwxkpz QEYNRSH8c3SpPUhr8xsJZBKHbHQrX27L7Pyz1v9u/HoXBTb4HEQ= =mzaL -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: Switching package to fragmented default configuration
On Saturday, August 29, 2020 1:00:17 AM MST Samuel Sieb wrote: > On 8/28/20 9:40 PM, John M. Harris Jr wrote: > > > Please don't invent a new logic, especially the one that systemd does. > > This makes it very difficult to figure out where in the world the > > configuration file for a given program is. With systemd, sure, it's not > > so bad, as the > > System defaults go in /usr/share/. Admin overrides go in /etc. If you're going to put defaults anywhere, /etc is the most logical place. When admins want to override, they'll modify the files that are there. See, for example, /etc/resolv.conf, the file used to tell the system resolver what DNS servers to use. By default, it's generated by your installer or by NetworkManager. When modified, it's now using "admin overrides". > > command will tell you where the unit file is. There's no such command for, > > for example, chronyd, httpd or any other program that itself isn't using > > such a convoluted configuration system. Even systemd wouldn't work if you > > blew away / etc. > > > It should. If not, that's where they want to get to. What is the actual benefit of this? Needlessly breaking existing configuration, making it impossible to cleanly upgrade systems, or write logic that takes into account the existing configuration of a given program? If you blow away /etc/, you will have a well and truly broken system. If you want to start a configuration from scratch, re-install. There's nothing wrong with that approach, and it works very well. This has been the case for nearly three decades now. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: %lua_requires behaves differently in F33+
On 29. 08. 20 4:43, Michel Alexandre Salim wrote: - I'll refactor lua in Fedora so lua-devel pulls in lua-rpm-macros rather than shipping macros.lua, then enable shipping macros.lua in lua-rpm-macros (right now it's excluded on Fedora to avoid file conflicts) Please make it conditional on rpm-build. That way, Lua developers not interested in RPM packaging won't get unneeded packages. See python3-devel: Requires: (python3-rpm-macros if rpm-build) (BTW count me in for the SIG) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: %lua_requires behaves differently in F33+
On 29. 08. 20 3:36, Michel Alexandre Salim wrote: Somehow this seems to be automatically applied on Fedora 33 and above -- without adding any manual require on lua(abi) Yes, this is done by the automatic dependency generator in Fedora 33+: https://src.fedoraproject.org/rpms/lua/pull-request/3 It is written in Lua (ha!), so it requires RPM 4.16+ (for parametric dependency generators). It could be backported to Fedora 31/32 if rewritten as a Shell script. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Fri, Aug 28, 2020 at 7:52 pm, Chris Murphy wrote: 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. I don't know how to test mDNS, but it has been reported that it's broken in F33: https://bugzilla.redhat.com/show_bug.cgi?id=1867830 That and the openconnect bug currently threaten the systemd-resolved change proposal. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Fedora-IoT-33-20200829.0 compose check report
No missing expected images. Soft failed openQA tests: 3/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-33-20200828.0): ID: 650863 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/650863 ID: 650864 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/650864 ID: 650868 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/650868 Passed openQA tests: 13/16 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Fedora 33 compose report: 20200829.n.0 changes
OLD: Fedora-33-20200828.n.0 NEW: Fedora-33-20200829.n.0 = SUMMARY = Added images:1 Dropped images: 4 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:11.96 KiB Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-33-20200829.n.0-sda.raw.xz = DROPPED IMAGES = Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20200828.n.0.ppc64le.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20200828.n.0.ppc64le.qcow2 Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-33-20200828.n.0.ppc64le.tar.xz Image: Cloud_Base vmdk ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20200828.n.0.ppc64le.vmdk = ADDED PACKAGES = = DROPPED PACKAGES = Package: php-phpunit-php-timer3-3.1.4-2.fc33 Summary: PHP Utility class for timing RPMs:php-phpunit-php-timer3 Size:11.96 KiB = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Fedora-IoT-34-20200829.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 2/16 (x86_64) New failures (same test not failed in Fedora-IoT-34-20200824.0): ID: 650671 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/650671 ID: 650673 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/650673 Passed openQA tests: 14/16 (x86_64) New passes (same test not passed in Fedora-IoT-34-20200824.0): ID: 650666 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/650666 ID: 650667 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/650667 ID: 650670 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/650670 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: 2 services(s) removed since previous compose: getty@tty6.service, zram-swap.service System load changed from 0.05 to 0.31 Previous test data: https://openqa.fedoraproject.org/tests/646824#downloads Current test data: https://openqa.fedoraproject.org/tests/650666#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: 2 services(s) removed since previous compose: getty@tty6.service, zram-swap.service System load changed from 0.06 to 0.36 Previous test data: https://openqa.fedoraproject.org/tests/646810#downloads Current test data: https://openqa.fedoraproject.org/tests/650667#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Fedora-Cloud-31-20200829.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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Fedora-Cloud-32-20200829.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-20200828.0): ID: 650649 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/650649 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
ocrmypdf license change
Version 11 of ocrmypdf changes license from "LGPLv2 and CC-BY-SA and Public Domain" to "MPL2.0 and MIT and BSD and CC-BY-SA and Public Domain" The main code switched licenses (to MPL2.0), and I found a few files imported from elsewhere that had a different license (MIT/BSD). It will be built for F33+ only. -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: Switching package to fragmented default configuration
On 8/28/20 9:40 PM, John M. Harris Jr wrote: Please don't invent a new logic, especially the one that systemd does. This makes it very difficult to figure out where in the world the configuration file for a given program is. With systemd, sure, it's not so bad, as the System defaults go in /usr/share/. Admin overrides go in /etc. command will tell you where the unit file is. There's no such command for, for example, chronyd, httpd or any other program that itself isn't using such a convoluted configuration system. Even systemd wouldn't work if you blew away / etc. It should. If not, that's where they want to get to. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Fedora-Rawhide-20200828.n.2 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 11/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20200823.n.2): ID: 650464 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/650464 ID: 650490 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/650490 ID: 650498 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/650498 ID: 650518 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/650518 Old failures (same test failed in Fedora-Rawhide-20200823.n.2): ID: 650434 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/650434 ID: 650438 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/650438 ID: 650492 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/650492 ID: 650524 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/650524 ID: 650534 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/650534 ID: 650565 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/650565 ID: 650592 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/650592 Soft failed openQA tests: 25/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20200823.n.2): ID: 650415 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/650415 ID: 650416 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/650416 ID: 650455 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/650455 ID: 650456 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/650456 ID: 650460 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/650460 ID: 650461 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/650461 ID: 650496 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/650496 ID: 650497 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/650497 ID: 650507 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/650507 ID: 650514 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/650514 ID: 650516 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/650516 ID: 650519 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/650519 ID: 650525 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/650525 ID: 650526 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/650526 ID: 650528 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/650528 ID: 650529 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/650529 ID: 650530 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/650530 ID: 650532 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/650532 ID: 650535 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/650535 ID: 650540 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/650540 ID: 650550 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/650550 ID: 650551 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/650551 ID: 650575 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/650575 ID: 650576 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/650576 ID: 650593 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/650593 Passed openQA tests: 145/181 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200823.n.2): ID: 650418 Test: x86_64 Server-dvd-iso
