[Bug 2058507] New: perl-PDL-2.076 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2058507 Bug ID: 2058507 Summary: perl-PDL-2.076 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PDL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jakub.jedel...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.076 Current version/release in rawhide: 2.75.0-1.fc37 URL: http://search.cpan.org/dist/PDL/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3205/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2058507 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: How long to update and reflash in rpms web
On Fri, 2022-02-25 at 07:15 +, Miao, Jun wrote: > Hi developers, > > I just update the tboot from 1.10.3-> 1.10.4 and "fedpkg build" successfully. > Got the email inform "[Fedora Update] [comment] tboot-1.10.4-2.fc37" and a > link https://bodhi.fedoraproject.org/updates/FEDORA-2022-df432d9356 > But from the web the Fedora37 is still xx.fc.36 like this: > [cid:image001.png@01D82A5A.87C07570] > > When the Fedora 37 -> xxx.fc37 After the next Rawhide compose completes, plus time for mirrors to sync. There is usually one compose per day, completing around 9-10am UTC. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
How long to update and reflash in rpms web
Hi developers, I just update the tboot from 1.10.3-> 1.10.4 and "fedpkg build" successfully. Got the email inform "[Fedora Update] [comment] tboot-1.10.4-2.fc37" and a link https://bodhi.fedoraproject.org/updates/FEDORA-2022-df432d9356 But from the web the Fedora37 is still xx.fc.36 like this: [cid:image001.png@01D82A5A.87C07570] When the Fedora 37 -> xxx.fc37 Thanks Jun ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0
Hello, all:
On f37 / f36 leptonica made some packaging change:
https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide
This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which I
guess is unexpected.
$ dnf repoquery --quiet --repo=koji-36 --qf '%{sourcerpm}' --whatrequires
"liblept.so.5()(64bit)" | cat -n
1 leptonica-1.82.0-2.fc36.src.rpm
2 mupdf-1.19.0-5.fc36.src.rpm
3 python-PyMuPDF-1.19.4-2.fc36.src.rpm
4 tesseract-5.0.1-2.fc36.src.rpm
5 zathura-pdf-mupdf-0.3.7-5.fc36.src.rpm
$ dnf repoquery --quiet --repo=koji-37 --qf '%{sourcerpm}' --whatrequires
"liblept.so.5()(64bit)" | cat -n
1 mupdf-1.19.0-5.fc36.src.rpm
2 python-PyMuPDF-1.19.5-1.fc37.src.rpm
3 zathura-pdf-mupdf-0.3.7-5.fc36.src.rpm
(Some of the package were rebuilt on f37 due to another reason, so depending
packages' number
differs here)
Currently I am not sure if we can just revert the above change.
Regards,
Mamoru
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220224.n.1 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 23/231 (x86_64), 21/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220222.n.1): ID: 1146875 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1146875 ID: 1146906 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1146906 ID: 1146910 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1146910 ID: 1146913 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1146913 ID: 1146916 Test: x86_64 KDE-live-iso desktop_printing_builtin URL: https://openqa.fedoraproject.org/tests/1146916 ID: 1146924 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1146924 ID: 1146933 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1146933 ID: 1146980 Test: aarch64 Server-dvd-iso base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1146980 ID: 1146999 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1146999 ID: 1147063 Test: aarch64 Workstation-upgrade base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1147063 ID: 1147064 Test: aarch64 Workstation-upgrade desktop_terminal@uefi URL: https://openqa.fedoraproject.org/tests/1147064 ID: 1147068 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1147068 ID: 1147080 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1147080 Old failures (same test failed in Fedora-Rawhide-20220222.n.1): ID: 1146859 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/1146859 ID: 1146881 Test: x86_64 Workstation-live-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1146881 ID: 1146887 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1146887 ID: 1146894 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1146894 ID: 1146897 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1146897 ID: 1146900 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1146900 ID: 1146901 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1146901 ID: 1146902 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1146902 ID: 1146965 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/1146965 ID: 1146976 Test: aarch64 Server-dvd-iso install_repository_nfsiso_variation@uefi URL: https://openqa.fedoraproject.org/tests/1146976 ID: 1146979 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/1146979 ID: 1147000 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1147000 ID: 1147019 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1147019 ID: 1147026 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1147026 ID: 1147028 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1147028 ID: 1147045 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1147045 ID: 1147047 Test: x86_64 Workstation-upgrade desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/1147047 ID: 1147054 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1147054 ID: 1147057 Test: x86_64 Workstation-upgrade apps_startstop URL: https://openqa.fedoraproject.org/tests/1147057 ID: 1147065 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1147065 ID: 1147077 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1147077 ID: 1147081 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/1147081 ID: 1147091 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1147091 ID: 1147110 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1147110 ID: 1147140 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/1147140 ID:
[Bug 2032430] perl-Type-Tiny for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2032430 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #20 from Fedora Update System --- FEDORA-EPEL-2022-844601896b has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-844601896b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2032430 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20220224.0 compose check report
No missing expected images. Failed openQA tests: 5/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20220223.0): ID: 1147239 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1147239 ID: 1147241 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1147241 ID: 1147246 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1147246 ID: 1147250 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/1147250 Old failures (same test failed in Fedora-IoT-36-20220223.0): ID: 1147237 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1147237 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-36-20220223.0): ID: 1147221 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1147221 Passed openQA tests: 15/16 (x86_64), 10/15 (aarch64) New passes (same test not passed in Fedora-IoT-36-20220223.0): ID: 1147234 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1147234 ID: 1147236 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1147236 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: System load changed from 0.01 to 0.40 Previous test data: https://openqa.fedoraproject.org/tests/1143976#downloads Current test data: https://openqa.fedoraproject.org/tests/1147222#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.01 to 0.15 Previous test data: https://openqa.fedoraproject.org/tests/1143977#downloads Current test data: https://openqa.fedoraproject.org/tests/1147223#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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
On Fri, 2022-02-25 at 02:43 +0300, Dmitry Butskoy wrote: > Sérgio Basto wrote: > > On Thu, 2022-02-24 at 21:20 +0300, Dmitry Butskoy wrote: > > > Miroslav Suchý wrote: > > > > > Second, the alternate Springdale Linux repo > > > > > http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ > > > > > see > > > > > ms > > > > > to have all the ones (which are provided in sources by > > > > > RedHat), > > > > > but > > > > > cannot be used in Copr. Springdale provides devtoolset-3- > > > > > elfutils > > > > > there, and it in some strange way badly correlates with the > > > > > initial > > > > > Copr build environment (even before the rpmbuild process > > > > > starts). > > > > > Some python2 module cannot find libelf.so.1 ... > > > > > > > > That is because it is SCL package. It installs the library to > > > > > > > > /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1 > > > > > > > > You have to run > > > > > > > > scl enable devtools-3 $COMMAND > > > > > > > But where to run it exactly? > > > > > yes is not easy find an example unfortunately , first line of > > %build > > %build is in the .spec file. It is readed after the start of the > build. > The start of the build is performed after the "bootstrap" stage. At > this > stage "yum install" creates an initial environment. Probably I'm > wrong . /opt/rh/devtoolset-9/enable before cd mozilla instead `source scl_source enable devtoolset-9` > -- could you pls look at: > > Start: yum install > > There was a problem importing one of the Python modules > > required to run yum. The error leading to this problem was: > > > > libelf.so.1: cannot open shared object file: No such file or > > directory > fragment in the correspond log: > https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz > > ? > > IOW: there is no "yum install" in the .spec file. So where to run > "scl-enable ..." to take it effect before that "yum install" ? > > > ~buc > > > > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-dc3bd1f656 llvm13-13.0.1-1.el7 rust-1.58.1-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-18ac3af1c8 varnish-4.0.5-3.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing seamonkey-2.53.11-1.el7 Details about builds: seamonkey-2.53.11-1.el7 (FEDORA-EPEL-2022-af77a11507) Web browser, e-mail, news, IRC client, HTML editor Update Information: Update to 2.53.11 Default version of Firefox for the User-Agent string has now been changed to 68.0 . This should provide better compatibility with modern sites. The value can be changed in Preferences-->Advanced-->HTTP Networking . Besides that, an alternate site-specific override machanism is now activated. (The idea comes from Waterfox-Classic project). The file ua-update.json in the application dir is now additionally used for a list of overrides. You can copy it into your profile and edit if needed (be careful with format.) The "general.useragent.override.*" way continues to work and takes precedence. The new mechanism can be toggled by "general.useragent.updates.enabled" prefs (in about:config). ChangeLog: * Wed Feb 23 2022 Dmitry Butskoy 2.53.11-1 - update to 2.53.11 - use ua-update.json mechanism for site-specific user-agent overrides - fix some minor issues ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051422] Please branch and build perl-Data-Serializer for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051422 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-Data-Serializer-0.65-7 ||.el9 Status|ON_QA |CLOSED Last Closed||2022-02-25 00:06:54 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-ca22384d83 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051422 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2051424] Please branch and build perl-Log-Trace for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2051424 Bug 2051424 depends on bug 2051422, which changed state. Bug 2051422 Summary: Please branch and build perl-Data-Serializer for EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2051422 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2051424 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2039718] Please branch and build perl-Mojolicious for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2039718 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Mojolicious-9.22-2.el9 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-02-25 00:06:51 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-ca22384d83 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2039718 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-36-20220224.n.0 compose check report
No missing expected images. Failed openQA tests: 10/229 (x86_64), 12/161 (aarch64) New failures (same test not failed in Fedora-36-20220223.n.0): ID: 1146404 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1146404 ID: 1146501 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1146501 ID: 1146560 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1146560 ID: 1146562 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/1146562 ID: 1146572 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/1146572 ID: 1146575 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1146575 ID: 1146641 Test: aarch64 Workstation-upgrade desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/1146641 Old failures (same test failed in Fedora-36-20220223.n.0): ID: 1146477 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1146477 ID: 1146478 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1146478 ID: 1146510 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1146510 ID: 1146594 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1146594 ID: 1146601 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1146601 ID: 1146652 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1146652 ID: 1146653 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1146653 ID: 1146685 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1146685 ID: 1146753 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1146753 ID: 1146782 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1146782 ID: 1146783 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1146783 ID: 1146792 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/1146792 ID: 1146793 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1146793 ID: 1146811 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1146811 ID: 1146813 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1146813 Soft failed openQA tests: 13/161 (aarch64), 15/229 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-36-20220223.n.0): ID: 1146762 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1146762 ID: 1146780 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1146780 Old soft failures (same test soft failed in Fedora-36-20220223.n.0): ID: 1146471 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1146471 ID: 1146508 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1146508 ID: 1146516 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1146516 ID: 1146603 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1146603 ID: 1146614 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1146614 ID: 1146615 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1146615 ID: 1146637 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1146637 ID: 1146640 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1146640 ID: 1146660 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1146660 ID: 1146661 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1146661 ID: 1146662 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1146662 ID: 1146670 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1146670 ID: 1146680 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/1146680 ID: 1146690 Test: x86_64
Re: future of dual-boot on the desktop
On Wed, Feb 23, 2022 at 05:56:14PM -0700, Chris Murphy wrote: > Hi, > > Dual boot has been a pretty important use case for Fedora Workstation > edition and the desktop spins. It sounds to me like it is time to punt the problem to the firmware on UEFI systems. Make sure we don't clobber existing Windows boot entries or partitions and let the firmware sort it out. Most of my UEFI systems have a boot menu that will list the entries and let you easily select them. I'd rather do that than depend on some kind of half-boot linux reboot into windows thing. Yeah, I know the firmware experience is inconsistent and terrible. But given the combination of TPM and bitlocker I don't see any other solution. Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
Sérgio Basto wrote: On Thu, 2022-02-24 at 21:20 +0300, Dmitry Butskoy wrote: Miroslav Suchý wrote: Second, the alternate Springdale Linux repo http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ see ms to have all the ones (which are provided in sources by RedHat), but cannot be used in Copr. Springdale provides devtoolset-3-elfutils there, and it in some strange way badly correlates with the initial Copr build environment (even before the rpmbuild process starts). Some python2 module cannot find libelf.so.1 ... That is because it is SCL package. It installs the library to /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1 You have to run scl enable devtools-3 $COMMAND But where to run it exactly? yes is not easy find an example unfortunately , first line of %build %build is in the .spec file. It is readed after the start of the build. The start of the build is performed after the "bootstrap" stage. At this stage "yum install" creates an initial environment. Probably I'm wrong -- could you pls look at: Start: yum install There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: libelf.so.1: cannot open shared object file: No such file or directory fragment in the correspond log: https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz ? IOW: there is no "yum install" in the .spec file. So where to run "scl-enable ..." to take it effect before that "yum install" ? ~buc ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
On Thu, 2022-02-24 at 21:20 +0300, Dmitry Butskoy wrote: > Miroslav Suchý wrote: > > > > > > > > Second, the alternate Springdale Linux repo > > > http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ see > > > ms > > > to have all the ones (which are provided in sources by RedHat), > > > but > > > cannot be used in Copr. Springdale provides devtoolset-3-elfutils > > > there, and it in some strange way badly correlates with the > > > initial > > > Copr build environment (even before the rpmbuild process starts). > > > Some python2 module cannot find libelf.so.1 ... > > > > > > That is because it is SCL package. It installs the library to > > > > /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1 > > > > You have to run > > > > scl enable devtools-3 $COMMAND > > > > But where to run it exactly? > yes is not easy find an example unfortunately , first line of %build see this example : https://src.fedoraproject.org/rpms/mkvtoolnix/blob/4400f88779be30d35d909545b76346dc218c24d4/f/mkvtoolnix.spec#_76 > It seems it happens on some early stage (so I cannot alter anything in > the .spec file). > > Could anybody look into the prolem log: > https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz > > ? > > > ~buc > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: future of dual-boot on the desktop
On Wed, Feb 23, 2022 at 6:35 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > A work around is having GRUB set an NVRAM variable indicating the next > > boot should be Windows. That's an instruction to the firmware, so > > there's no intermediary, thus measured boot works. The next boot (from > > Windows) would boot Fedora again. GRUB can't get or set EFI variables > > yet. systemd-boot, meanwhile, will be supporting BootNext in their > > next release. > > So, can we not, in GRUB, instead of chainloading the Windows bootloader, > chainload a systemd-boot copy preconfigured to BootNext to Windows? No because systemd-boot isn't signed with a Fedora Secure Boot signing key, so on systems with UEFI Secure Boot enabled, they'd fail to load systemd-boot. But also, this isn't an upstreamable solution, so the Fedora and Red Hat bootloader teams are unlikely to support it either. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 36 compose report: 20220224.n.0 changes
OLD: Fedora-36-20220223.n.0 NEW: Fedora-36-20220224.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B 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 = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On 2/22/22 1:56 PM, Jason L Tibbitts III wrote: Brandon Nielsen writes: I would like to see the forge macros removed from the guidelines if development truly has ceased. I would like to get into them and at least see what needs to change but... the internal implementation is somewhat baroque and my time is severely limited. I think there is good stuff there but I don't know how much work would be required to salvage it. One problem is that at least I thought that significant portions of the Go tooling relied on it, and there's no alternative that has any kind of automation. - J< Looking at this a little more, I'm not really sure we need to be discouraging their use. The code[0] doesn't look that bad to me, and there are only 2 issues open against it. The fact nobody is stepping up to at least comment on the two issues is a bit of a concern. The first one[1] looks really problematic, and I don't see how you can fix it without coordinating with any package using the broken behavior. Hopefully it isn't as bad as it looks? The second one[2] is an RFE, and looks like one I may try to address if nobody gets to it before I have some free time. I do agree with the sentiment elsewhere in this thread that for the majority of cases, it's easy enough to just work with the URLs directly. Maybe the git forge macro documentation moves somewhere else instead? [0] - https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/forge.lua [1] - https://bugzilla.redhat.com/show_bug.cgi?id=2048362 [2] - https://bugzilla.redhat.com/show_bug.cgi?id=2035935 ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: unsafe systemd setup in Fedora
Hi On Thu, Feb 24, 2022 at 2:14 PM Zbigniew Jędrzejewski-Szmek > > Systemd 250 (coming in F36), has --security-policy switch which can be > used to enable/disable some of the checks. There is no way to tell > systemd-analyze that things about a specific unit though. > Ability to modify these policies via configuration (the above one looks like a build config) and ability to do global overrides and set the hardening features across all services so distributions or sysadmins can configure those would be helpful Rahul ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: unsafe systemd setup in Fedora
On Thu, Feb 24, 2022 at 04:29:27PM +0100, Marius Schwarz wrote: > Hi Guys, > > running a hardening tool I stumpled about systemd own security analysis, systemd-analyze security shows whether units use systemd hardening features. Those units may well use other features, and may well be very secure. In general it is a good idea to use at least some of the systemd features, but not always. Sometimes the unit may need to implement its own harderning in a very special way, or it may legitimately need almost full privileges. (For example sshd is like this: it implements privilege separation and does other things for security, but it needs full privileges to be able to run things as arbitrary users.) High exposure scores mean only so much. It would probably be good to use more of those features, but you need to understand the service very well to know what systemd security features can be enabled for it. > Do those "insecure" units come from upstream projects, or is Fedora lagging > behind some patches? Fedora usually uses service files straight from upstream, if upstream provides them. > Is there a way to find out, if missing restrictions options are a problem > for the service and if not, any way to tell that analyse tool about it? Systemd 250 (coming in F36), has --security-policy switch which can be used to enable/disable some of the checks. There is no way to tell systemd-analyze that things about a specific unit though. Zbyszek ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Once upon a time, Vitaly Zaitsev via devel said: > Now we can drop FTP support from libcurl safely. I still disagree, since dnf is not the sole user of curl/libcurl. Making libcurl tiny for containers is one thing, but replacing a commonly-used command with an intentionally-limited version is bad. IMHO that doesn't just go for curl/libcurl, or just the libcurl FTP support (I definitely think IDN support should be everywhere practical). I think curl is the only FTP client installed in a minimal config, so dropping that support shouldn't be taking lightly. At a minimum, I think there'd need to be buy-in from other distributions to have a common set of functionality in the base. Otherwise, this is just going to result in "curl in Fedora is broken, use Ubuntu" type psts. -- Chris Adams ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On 24/02/2022 19:05, Kevin Fenzi wrote: Odd. There shouldn't be any. Can you paste/post what you are seeing? Sorry, my bad. I've seen errors like "Timeout was reached for ftp.example.org". There are a lot of mirrors with ftp subdomain: - ftp.lysator.liu.se - ftp.nluug.nl - ftp.fau.de - ftp.lip6.fr - ftp.halifax.rwth-aachen.de - ftp.acc.umu.se - ftp.byfly.by - ftp.fi.muni.cz - ftp.plusline.net - ftp.upjs.sk I checked metalink and all of these servers use only http and rsync protocols. Now we can drop FTP support from libcurl safely. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Feb 24, 2022 at 07:16:26PM +0100, Ralf Corsépius wrote: > > > Am 24.02.22 um 19:05 schrieb Kevin Fenzi: > > On Wed, Feb 23, 2022 at 10:19:33AM +0100, Vitaly Zaitsev via devel wrote: > > > On 22/02/2022 21:45, Peter Robinson wrote: > > > > Does it make sense to keep FTP with most browsers obsoleting the > > > > protocol due to lack of security? > > > > > > Many Fedora mirrors still use FTP. You can check metalink file. > > > > Odd. There shouldn't be any. Can you paste/post what you are seeing? > > > > We disabled and removed all ftp:// urls in mirrormanager in 2016: > > https://github.com/fedora-infra/mirrormanager2/issues/99#issuecomment-222630215 > > dnf isn't restricted to using "official" mirrors, but is also used for 3rd > party add-on-repos and for private repos. > > For them, disabling ftp is pretty much a massive regression. This feels like it is overstating the severity to a large degree. Removing FTP from official Fedora mirror manager was not a massive regression because so few of our mirrors were FTP-only in 2016. Another 6 years later, the number of sites with FTP-only can only have decreased. So while there certainly could be 3rd party repos which have one or more mirrors which are FTP only, if they exist they will surely be a tiny minority in the big picture. Their loss would simply mean it picked a different mirror. If someone is setting up a personal private mirror, I struggle to understand a reason why they would pick FTP over HTTP(S) today. Perhaps someone will have a FTP only mirror that's existed for years and simply haven't got around to enabling HTTP, but addressing that is not an unreasonable expectation. IMHO explicitly disabling FTP in dnf would be fine, as any fallout could be easily dealt with by enabling HTTP. Just ensure we announce such intent ahead of time via a Fedora feature proposal. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
Miroslav Suchý wrote: Second, the alternate Springdale Linux repo http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ seems to have all the ones (which are provided in sources by RedHat), but cannot be used in Copr. Springdale provides devtoolset-3-elfutils there, and it in some strange way badly correlates with the initial Copr build environment (even before the rpmbuild process starts). Some python2 module cannot find libelf.so.1 ... That is because it is SCL package. It installs the library to /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1 You have to run scl enable devtools-3 $COMMAND But where to run it exactly? It seems it happens on some early stage (so I cannot alter anything in the .spec file). Could anybody look into the prolem log: https://download.copr.fedorainfracloud.org/results/buc/seamonkey-generic/epel-7-x86_64/03543870-seamonkey/builder-live.log.gz ? ~buc ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Am 24.02.22 um 19:05 schrieb Kevin Fenzi: On Wed, Feb 23, 2022 at 10:19:33AM +0100, Vitaly Zaitsev via devel wrote: On 22/02/2022 21:45, Peter Robinson wrote: Does it make sense to keep FTP with most browsers obsoleting the protocol due to lack of security? Many Fedora mirrors still use FTP. You can check metalink file. Odd. There shouldn't be any. Can you paste/post what you are seeing? We disabled and removed all ftp:// urls in mirrormanager in 2016: https://github.com/fedora-infra/mirrormanager2/issues/99#issuecomment-222630215 dnf isn't restricted to using "official" mirrors, but is also used for 3rd party add-on-repos and for private repos. For them, disabling ftp is pretty much a massive regression. Ralf ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Wed, Feb 23, 2022 at 10:19:33AM +0100, Vitaly Zaitsev via devel wrote: > On 22/02/2022 21:45, Peter Robinson wrote: > > Does it make sense to keep FTP with most browsers obsoleting the > > protocol due to lack of security? > > Many Fedora mirrors still use FTP. You can check metalink file. Odd. There shouldn't be any. Can you paste/post what you are seeing? We disabled and removed all ftp:// urls in mirrormanager in 2016: https://github.com/fedora-infra/mirrormanager2/issues/99#issuecomment-222630215 kevin signature.asc Description: 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
Miroslav Suchý writes: > You have to run > > scl enable devtools-3 $COMMAND > > to make this library available. I used to do that, but it's rather easier to source the enable script (conditionally) in %build and perhaps %check or %install. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
[epel-devel seems a better place for this.] Dmitry Butskoy writes: > Ben Beasley wrote: >> Yes, the devtoolsets work nicely if you supply the appropriate >> incantations. I haven’t tried in COPR specifically > I've just tried and it seems that devtoolset are not available for > epel7 builds in Copr. (For epel7, I successfully build seamonkey with > devtoolset already for years :) ) > > There is a possibility to use an additional external repo for > Copr. But there are issues with this. I'm unclear what's actually required, but CentOS 7 has up to devtoolset-11, and some version worked for me whenever I last did a build in copr which needed it. > First, the appropriate CentOS repo > http://mirror.centos.org/centos/7/sclo/x86_64/rh/ does not have the > latest llvm packages (for clang) -- say, llvm-toolset-11-* . (BTW, why??) There's no RHEL7 llvm-toolset as far as I know, so if you want exactly that you'll have to build it, which is probably non-trivial. EPEL 7 has llvm11, but I don't know where to find a recent clang, if that's what you actually want. EL7 development is a losing battle at this stage, though. We're even forced off it by IBM saying RHEL 7.9 for POWER doesn't exist. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
On Thu, Feb 24, 2022 at 04:30:53PM +, Tom Hughes via devel wrote: > On 24/02/2022 16:28, Tom Hughes wrote: > > On 24/02/2022 16:25, Cole Robinson wrote: > > > On 2/23/22 5:22 PM, Tom Hughes via devel wrote: > > > > On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > > a) change libvirt-daemon-driver-storage > > > > > Requires:libvirt-daemon-driver-storage-iscsi > > > > > to Suggests:libvirt-daemon-driver-storage-iscsi, > > > > > > > > More generally why does installing libvirt neeed to force > > > > installation of about ten storage drivers and all their > > > > dependencies - why can't the user choose to remove some of > > > > the more obscure ones? > > > > > > > > > > libvirt has a modularized packaging split. libvirt-daemon-driver-storage > > > pulls in every possible storage driver + lib that libvirt can use. Or > > > you can install libvirt-daemon-driver-storage-XXX individual sub > > > packages to get only the bits your app will use. > > > > I was basing what I said on the fact that trying to remove > > libvirt-daemon-driver-storage-iscsi wanted to remove the whole > > of libvirt on my machine: > > Ah but that is mostly auto clean. Yes, that is dnf being too aggressive in removing stuff. > Though libvirt-daemon-kvm is a dependency as you say and > don't I need that to run any kvm based vm? Correct, it is merely a metapackage that is intended to pull in all libvirt sub-RPMs that are compatible with KVM usage. If you remove that package, you can choose exactly which individual sub-RPM features you desire. The same applies for QEMU, libvirt-daemon-kvm depends on qemu-kvm which pulls in all the QEMU sub-RPMs that are compatible with KVM. If you remove libvirt-daemon-kvm you can also choose a qemu-kvm-core and whateever other features are desired. We could none the less still consider use of Suggests in libvirt-dameon-kvm. Will have a think if that could have a negative impact on any apps currently depending on libvirt. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
On 24/02/2022 16:28, Tom Hughes wrote: On 24/02/2022 16:25, Cole Robinson wrote: On 2/23/22 5:22 PM, Tom Hughes via devel wrote: On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: a) change libvirt-daemon-driver-storage Requires:libvirt-daemon-driver-storage-iscsi to Suggests:libvirt-daemon-driver-storage-iscsi, More generally why does installing libvirt neeed to force installation of about ten storage drivers and all their dependencies - why can't the user choose to remove some of the more obscure ones? libvirt has a modularized packaging split. libvirt-daemon-driver-storage pulls in every possible storage driver + lib that libvirt can use. Or you can install libvirt-daemon-driver-storage-XXX individual sub packages to get only the bits your app will use. I was basing what I said on the fact that trying to remove libvirt-daemon-driver-storage-iscsi wanted to remove the whole of libvirt on my machine: Ah but that is mostly auto clean. Though libvirt-daemon-kvm is a dependency as you say and don't I need that to run any kvm based vm? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
On 24/02/2022 16:25, Cole Robinson wrote: On 2/23/22 5:22 PM, Tom Hughes via devel wrote: On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: a) change libvirt-daemon-driver-storage Requires:libvirt-daemon-driver-storage-iscsi to Suggests:libvirt-daemon-driver-storage-iscsi, More generally why does installing libvirt neeed to force installation of about ten storage drivers and all their dependencies - why can't the user choose to remove some of the more obscure ones? libvirt has a modularized packaging split. libvirt-daemon-driver-storage pulls in every possible storage driver + lib that libvirt can use. Or you can install libvirt-daemon-driver-storage-XXX individual sub packages to get only the bits your app will use. I was basing what I said on the fact that trying to remove libvirt-daemon-driver-storage-iscsi wanted to remove the whole of libvirt on my machine: % sudo dnf erase libvirt-daemon-driver-storage-iscsi* Dependencies resolved. Package Arch Version Repo Size Removing: libvirt-daemon-driver-storage-iscsi x86_64 7.6.0-5.fc35 @updates 24 k libvirt-daemon-driver-storage-iscsi-direct x86_64 7.6.0-5.fc35 @updates 32 k Removing dependent packages: libvirt-daemon-kvm x86_64 7.6.0-5.fc35 @updates 0 vagrant-libvirt noarch 0.4.1-3.fc35 @fedora 229 k Removing unused dependencies: glusterfs-cli x86_64 9.5-1.fc35 @updates 493 k guestfs-tools x86_64 1.47.3-1.fc35 @updates 25 M hexedit x86_64 1.5-2.fc35 @fedora 77 k libacl i686 2.3.1-2.fc35 @fedora 35 k libglusterd0x86_64 9.5-1.fc35 @updates 15 k libguestfs x86_64 1:1.46.2-1.fc35 @updates 3.8 M libguestfs-appliancex86_64 1:1.46.2-1.fc35 @updates 2.3 M libguestfs-xfs x86_64 1:1.46.2-1.fc35 @updates 9 libtpms x86_64 0.9.2-0.20220106gite81d634c27.fc35.0 @updates 986 k libvirt-daemon-driver-interface x86_64 7.6.0-5.fc35 @updates 593 k libvirt-daemon-driver-nodedev x86_64 7.6.0-5.fc35 @updates 650 k libvirt-daemon-driver-nwfilter x86_64 7.6.0-5.fc35 @updates 683 k libvirt-daemon-driver-qemu x86_64 7.6.0-5.fc35 @updates 2.5 M libvirt-daemon-driver-secretx86_64 7.6.0-5.fc35 @updates 585 k libvirt-daemon-driver-storage x86_64 7.6.0-5.fc35 @updates 0 libvirt-daemon-driver-storage-core x86_64 7.6.0-5.fc35 @updates 767 k libvirt-daemon-driver-storage-disk x86_64 7.6.0-5.fc35 @updates 32 k libvirt-daemon-driver-storage-gluster x86_64 7.6.0-5.fc35 @updates 40 k libvirt-daemon-driver-storage-logical x86_64 7.6.0-5.fc35 @updates 32 k libvirt-daemon-driver-storage-mpath x86_64 7.6.0-5.fc35 @updates 16 k libvirt-daemon-driver-storage-rbd x86_64 7.6.0-5.fc35 @updates 44 k libvirt-daemon-driver-storage-scsi x86_64 7.6.0-5.fc35 @updates 24 k libvirt-daemon-driver-storage-sheepdog x86_64 7.6.0-5.fc35 @updates 20 k libvirt-daemon-driver-storage-zfs x86_64 7.6.0-5.fc35 @updates 24 k qemu-kvm-core x86_64 2:6.1.0-14.fc35 @updates 0 rubygem-excon noarch 0.79.0-1.fc35 @fedora 98 k rubygem-fog-corenoarch 2.2.4-2.fc35 @fedora 118 k rubygem-fog-jsonnoarch 1.2.0-7.fc35 @fedora 3.9 k rubygem-fog-libvirt noarch 0.8.0-2.fc35 @fedora 73 k rubygem-fog-xml noarch 0.1.3-7.fc35 @fedora 8.3 k rubygem-formatador noarch 0.2.5-12.fc35 @fedora 9.9 k rubygem-multi_json noarch 1.15.0-3.fc35 @fedora 33 k rubygem-rexml noarch 3.2.5-151.fc35 @fedora 399 k rubygem-ruby-libvirtx86_64 0.7.1-13.fc35 @fedora 288 k superminx86_64 5.3.1-1.fc35 @fedora 1.5 M swtpm x86_64 0.7.0-2.20211109gitb79fd91.fc35 @updates 218 k swtpm-libs x86_64 0.7.0-2.20211109gitb79fd91.fc35 @updates 99 k swtpm-tools x86_64 0.7.0-2.20211109gitb79fd91.fc35 @updates 272 k zerofreex86_64 1.1.1-8.fc35 @fedora 54 k zfs-fusex86_64 0.7.2.2-20.fc35 @fedora 6.0 M Transaction Summary
Re: Is NetworkManager-wait-online.service necessary by default?
On 2/23/22 5:22 PM, Tom Hughes via devel wrote: > On 23/02/2022 21:23, Zbigniew Jędrzejewski-Szmek wrote: > >> a) change libvirt-daemon-driver-storage >> Requires:libvirt-daemon-driver-storage-iscsi >> to Suggests:libvirt-daemon-driver-storage-iscsi, > > More generally why does installing libvirt neeed to force > installation of about ten storage drivers and all their > dependencies - why can't the user choose to remove some of > the more obscure ones? > libvirt has a modularized packaging split. libvirt-daemon-driver-storage pulls in every possible storage driver + lib that libvirt can use. Or you can install libvirt-daemon-driver-storage-XXX individual sub packages to get only the bits your app will use. gnome-boxes which is in the default workstation package set has a dep on libvirt-daemon-kvm which is itself a metapackage which pulls in libvirt-daemon-driver-storage. gnome-boxes dep could be made more granular, it uses libvirt storage APIs but I think only libvirt-daemon-driver-storage-file - Cole ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On 2/24/22 10:12 AM, Fabio Valentini wrote: On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev wrote: especially since they don't really provide value for standard GitHub tarball downloads etc. compared to the "old" SourceURL some of us strongly disagree. admittedly, with no weight ... Admittedly, packages like the .spec for nginx you linked are very far outliers regarding package complexity. Perhaps very far outliers for _your_ use cases. Quite common, here. Especially for numbers of enterprise packages that, for better or worse, lag upstream in either versions, or capabilities. And the flexibility to address that level of 'complexity' is exactly what we look to a major-distro's build systems for. My wholesale move(s) to Fedora from Opensuse were well-considered -- and long overdue. For a large number of reasons. The biggest risk was the drop in functionality/flexibility of the build system -- for end-user use cases, NOT necessarily (just) for official packaging. COPR + the forgemeta stuff gets a heck of a lot closer to par, than not. I doubt there's many packages that need to reference *that* many different source repos and tarballs ... For these really complex cases, the forge macros are ~fine~, I guess. But you really don't - and shouldn't - need to rely on hundreds of lines of complex lua macros to be able to specify one or two GitHub tarballs. With that I don't disagree in the slightest. I've repeatedly advocated for a different approach, similar to OBS' capabilities. It got zero traction/interest. So forgemeta seems to be "functionally best available" option, currently. It would be far less of a concern if ANY of those discussions had gotten any traction, and there was a good/flexible ALTERNATIVE to forgemeta, rather than simply talk of deprecating current capabilities, without a good option. There _are_ options, of course. And I have two in place -- our own, LFS distro with rpm build system, and building Fedora+pkgs on OBS. Neither are optimal, both are costly, and in both cases I'd prefer something @Fedora buildsys. But again, i ACK that 'my' needs have little weight. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
unsafe systemd setup in Fedora
Hi Guys, running a hardening tool I stumpled about systemd own security analysis, which doesn't look good: $ systemd-analyze security UNIT EXPOSURE PREDICATE HAPPY NetworkManager.service 7.8 EXPOSED abrt-journal-core.service 9.6 UNSAFE abrt-oops.service 9.6 UNSAFE abrt-xorg.service 9.6 UNSAFE abrtd.service 9.6 UNSAFE accounts-daemon.service 9.6 UNSAFE alsa-state.service 9.6 UNSAFE atd.service 9.6 UNSAFE auditd.service 8.7 EXPOSED avahi-daemon.service 9.6 UNSAFE chronyd.service 8.9 EXPOSED colord.service 8.8 EXPOSED crond.service 9.6 UNSAFE cups.service 9.6 UNSAFE dbus-:1.8-org.freedesktop.problems@0.service 9.6 UNSAFE dbus-broker.service 8.7 EXPOSED dm-event.service 9.5 UNSAFE emergency.service 9.5 UNSAFE fail2ban.service 9.6 UNSAFE fcoe.service 9.6 UNSAFE flatpak-system-helper.service 9.6 UNSAFE gdm.service 9.8 UNSAFE getty@tty1.service 9.6 UNSAFE irqbalance.service 6.2 MEDIUM iscsid.service 9.5 UNSAFE iscsiuio.service 9.5 UNSAFE libvirtd.service 9.6 UNSAFE lvm2-lvmpolld.service 9.5 UNSAFE mdmonitor.service 9.6 UNSAFE multipathd.service 9.5 UNSAFE network.service 9.6 UNSAFE nmb.service 9.6 UNSAFE nscd.service 9.6 UNSAFE ntpd.service 9.2 UNSAFE lines 1-35...skipping... UNIT EXPOSURE PREDICATE HAPPY NetworkManager.service 7.8 EXPOSED abrt-journal-core.service 9.6 UNSAFE abrt-oops.service 9.6 UNSAFE abrt-xorg.service 9.6 UNSAFE abrtd.service 9.6 UNSAFE accounts-daemon.service 9.6 UNSAFE alsa-state.service 9.6 UNSAFE atd.service 9.6 UNSAFE auditd.service 8.7 EXPOSED avahi-daemon.service 9.6 UNSAFE chronyd.service 8.9 EXPOSED colord.service 8.8 EXPOSED crond.service 9.6 UNSAFE cups.service 9.6 UNSAFE dbus-:1.8-org.freedesktop.problems@0.service 9.6 UNSAFE dbus-broker.service 8.7 EXPOSED dm-event.service 9.5 UNSAFE emergency.service 9.5 UNSAFE fail2ban.service 9.6 UNSAFE fcoe.service 9.6 UNSAFE flatpak-system-helper.service 9.6 UNSAFE gdm.service 9.8 UNSAFE getty@tty1.service 9.6 UNSAFE irqbalance.service 6.2 MEDIUM iscsid.service 9.5 UNSAFE iscsiuio.service 9.5 UNSAFE libvirtd.service 9.6 UNSAFE lvm2-lvmpolld.service 9.5 UNSAFE mdmonitor.service 9.6 UNSAFE multipathd.service 9.5 UNSAFE network.service 9.6 UNSAFE nmb.service 9.6 UNSAFE nscd.service 9.6 UNSAFE ntpd.service 9.2 UNSAFE nvidia-powerd.service 9.6 UNSAFE plymouth-start.service 9.5 UNSAFE polkit.service $ systemd-analyze security UNIT
Re: Unannounced soname bump: libwebsockets.so.18 -> libwebsockets.so.19
On Tue, Feb 22, 2022 at 3:22 PM Mamoru TASAKA wrote: > > Hello, all: > > On f37 / f36 two days ago libwebsockets was updated from 4.2.2 to 4.3.1 > which causes unannounced soname bump from libwebsockets.so.18 to > libwebsockets.so.19 > > What is strange here is that the committer seems aware of this change: > https://src.fedoraproject.org/rpms/libwebsockets/c/ad122ba347b290d1221fe6fee1c4194ac74c2719?branch=rawhide Yeah, this is really strange. *Techically*, the soname bump was announced, 6 months ago: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6M5NRYF7EGU62KKG56L72K6WGHWH5V2L/ But then the announced update to 4.3.0 was never pushed. And now 4.3.1 was pushed to F36+ without further warnings, and not by the package maintainer, but by pbrobinson, apparently using his provenpackager privileges ... Fabio ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
I have stopped using the “forge” macros in most cases where I am packaging a
release/tag, since the URLs are simple enough without them, usually something
like
URL: https://github.com/foo/bar
Source0: %{url}/archive/v%{version}/bar-%{version}.tar.gz
However, when I need to package an untagged commit, the ability of the “forge”
macros to automatically construct and apply the snapshot information field,
including picking up the date from the primary source’s mtime, is *awesome*,
even if it’s not that much harder to do it by hand. It’s also nice to write
“%forgeautosetup” instead of “%autosetup -n bar-%{commit}”.
I guess I’m saying that I could easily live without these macros, but I do find
them occasionally useful in several small ways.
– Ben
On Thu, Feb 24, 2022, at 10:00 AM, PGNet Dev wrote:
>> especially since they don't really provide value for
>> standard GitHub tarball downloads etc. compared to the "old" SourceURL
>
> some of us strongly disagree. admittedly, with no weight ...
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
On Thu, Feb 24, 2022, at 6:17 AM, Benjamin Berg wrote: > network-online-waitonly.target with > After=network-online.target > StopWhenUnneeded=yes > > which is then used inside iscsi.service > ExecStartPre=/usr/bin/systemctl start network-online-waitonly.target No, avoid such things unless absolutely necessary - it makes the dependency graph dynamic, which systemd does support but doing so brings a vast amount of complexity. I think instead you can use e.g. a systemd generator: https://www.freedesktop.org/software/systemd/man/systemd.generator.html The generator (which can be the same binary) can then enable iscsi.service only if the directory is non-empty. (Which is making things dynamic, but all dynamic computation happens at a well-defined eraly fixed point and is acted on together thereafter) Now I'd agree this behavior is not obvious, and perhaps systemd should gain something like EnableConditionDirectoryNotEmpty= that is defined to be evaluated at the same time as generators or so, and if the conditions evaluate to false then none of the unit dependencies will be pulled in either. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On Thu, Feb 24, 2022 at 4:00 PM PGNet Dev wrote: > > > especially since they don't really provide value for > > standard GitHub tarball downloads etc. compared to the "old" SourceURL > > some of us strongly disagree. admittedly, with no weight ... Admittedly, packages like the .spec for nginx you linked are very far outliers regarding package complexity. I doubt there's many packages that need to reference *that* many different source repos and tarballs ... For these really complex cases, the forge macros are ~fine~, I guess. But you really don't - and shouldn't - need to rely on hundreds of lines of complex lua macros to be able to specify one or two GitHub tarballs. Fabio ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
especially since they don't really provide value for standard GitHub tarball downloads etc. compared to the "old" SourceURL some of us strongly disagree. admittedly, with no weight ... ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for %{forgemeta} GitHub example
On Tue, Feb 22, 2022 at 8:57 PM Jason L Tibbitts III wrote: > > > Brandon Nielsen writes: > > > I would like to see the forge macros removed from the guidelines if > > development truly has ceased. > > I would like to get into them and at least see what needs to change > but... the internal implementation is somewhat baroque and my time is > severely limited. I think there is good stuff there but I don't know > how much work would be required to salvage it. > > One problem is that at least I thought that significant portions of the > Go tooling relied on it, and there's no alternative that has any kind of > automation. I don't think removing the forge macros would be possible at this point, exactly for this reason. However, Go and Font packaging macros are the only things where using those macros is not optional, and in both cases, you're supposed to use wrapper macros so you're not even using the %forgefoo macros directly. So I don't think they need to be documented as a standalone feature any longer, especially since they don't really provide value for standard GitHub tarball downloads etc. compared to the "old" SourceURL guidelines we've had for years, and are no longer maintained. Should we remove documentation for them from the SourceURL guidelines page? It seems to cause more confusion than it solves problems. Fabio ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora CoreOS Meeting Minutes 2022-02-23
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-23/fedora_coreos_meeting.2022-02-23-16.29.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-23/fedora_coreos_meeting.2022-02-23-16.29.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-23/fedora_coreos_meeting.2022-02-23-16.29.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:29:31 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-23/fedora_coreos_meeting.2022-02-23-16.29.log.html . Meeting summary --- * roll call (dustymabe, 16:29:37) * Action items from last meeting (dustymabe, 16:33:40) * jlebon opened https://github.com/coreos/rpm-ostree/issues/3465 (jlebon, 16:34:06) * jlebon started email draft in https://github.com/coreos/fedora-coreos-tracker/issues/1106#issuecomment-1048901881 (jlebon, 16:34:33) * dustymabe opened a ticket to discuss podmanv4 coming to FCOS in F36 https://github.com/coreos/fedora-coreos-tracker/issues/1106 (dustymabe, 16:34:59) * ACTION: ravanelli to look into the F36 changes 127 to see if this change affects us on ppc64le (dustymabe, 16:37:41) * RFC: A new continuous mechanical FCOS stream (dustymabe, 16:38:13) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/910 (dustymabe, 16:38:18) * AGREED: While we see value in a continuous stream we aren't wholly convinced the benefits qualify adding another stream at this point. We'd like to continue discussion in the ticket and collect examples of issues we think would have been caught by a continuous stream before landing in testing-devel. (dustymabe, 17:05:35) * tracker: Fedora 36 changes considerations (dustymabe, 17:06:00) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/918 (dustymabe, 17:06:05) * tracker: This Month in Fedora CoreOS February 2022 (dustymabe, 17:08:10) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1107 (dustymabe, 17:08:16) * open floor (dustymabe, 17:11:44) * LINK: https://github.com/coreos/zincati/issues/539 (dustymabe, 17:14:23) * LINK: https://github.com/coreos/coreos-installer/issues/792 (bgilbert, 17:17:41) Meeting ended at 17:30:02 UTC. Action Items * ravanelli to look into the F36 changes 127 to see if this change affects us on ppc64le Action Items, by person --- * ravanelli * ravanelli to look into the F36 changes 127 to see if this change affects us on ppc64le * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (90) * jlebon (41) * zodbot (31) * bgilbert (24) * travier (11) * miabbott (10) * fifofonix_ (8) * lucab (5) * jaimelm (4) * saqali (2) * jmarrero (2) * ravanelli (1) * jbrooks (1) * gursewak (0) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Feb 24, 2022 at 8:58 AM Richard W.M. Jones wrote: > > On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote: > > On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote: > > > Did you discuss modularising curl itself upstream? > > > > It was added to their wish list but I do not remember anybody working on it: > > > > https://github.com/curl/curl/commit/8204844f > > > > > That would be a better idea. > > > > Not necessarily. Each approach has its pros and cons. > > I'm intrigued by what you think the cons would be. AFAICT if curl was > modular in this way already we wouldn't be discussing this proposal at all, > but a different and better one around packaging splits. > It would also avoid the usability nightmare that comes with trying to trigger switching implementations. This is a very big hammer that basically tells people that we're crippling curl by default for users and it has very large network effects across the entire distribution. It's quite one thing to use curl-minimal for containers where people expect tools to be broken in the endless pursuit of smaller base images, but when real people need to use real systems in complex configurations, having a reduced functionality curl by default is just going to lead to support nightmares and complaints about random breakages in applications on Fedora. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
Once upon a time, Zbigniew Jędrzejewski-Szmek said: > Conditions are evaluated when the service would be exectued, so a unit > which is (eventually) skipped because of Conditions still has effect on > the boot ordering and may add additional jobs to the transaction. Okay, that's a nuance I didn't realize. My guess would be that the iscsi maintainer(s) didn't realize it either, and thought it would be okay to have the service always enabled, so it would "just work" when needed and also stay out of the way when not. -- Chris Adams ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thu, Feb 24, 2022 at 02:28:08PM +0100, Kamil Dudka wrote: > On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote: > > Did you discuss modularising curl itself upstream? > > It was added to their wish list but I do not remember anybody working on it: > > https://github.com/curl/curl/commit/8204844f > > > That would be a better idea. > > Not necessarily. Each approach has its pros and cons. I'm intrigued by what you think the cons would be. AFAICT if curl was modular in this way already we wouldn't be discussing this proposal at all, but a different and better one around packaging splits. Rich. > Kamil > > > Then we could package up the various *.so drivers into separate packages. > > > > Also I think this whole business of minimizing Fedora is getting way > > out of hand. > > > > Rich. > -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Thursday, February 24, 2022 1:35:38 PM CET Richard W.M. Jones wrote: > Did you discuss modularising curl itself upstream? It was added to their wish list but I do not remember anybody working on it: https://github.com/curl/curl/commit/8204844f > That would be a better idea. Not necessarily. Each approach has its pros and cons. Kamil > Then we could package up the various *.so drivers into separate packages. > > Also I think this whole business of minimizing Fedora is getting way > out of hand. > > Rich. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : ELN SIG
I will not be able to attend this week. If someone else is willing to act as chair, please feel free to hold it without me. On Thu, Feb 24, 2022 at 7:00 AM wrote: > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2022-02-25 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10133/ > > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
Kamil Dudka wrote: > There seems to be demand for libcurl with IDN support on minimal Fedora > installations, so I created a pull request to enable it in libcurl-minimal: > > https://src.fedoraproject.org/rpms/curl/pull-request/13 Thank you. Björn Persson pgp2ZEu96gtIM.pgp Description: OpenPGP digital signatur ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Devtoolset for epel7 for build in Copr
Dne 23. 02. 22 v 19:22 Dmitry Butskoy napsal(a): Ben Beasley wrote: Yes, the devtoolsets work nicely if you supply the appropriate incantations. I haven’t tried in COPR specifically I've just tried and it seems that devtoolset are not available for epel7 builds in Copr. (For epel7, I successfully build seamonkey with devtoolset already for years :) ) There is a possibility to use an additional external repo for Copr. But there are issues with this. First, the appropriate CentOS repo http://mirror.centos.org/centos/7/sclo/x86_64/rh/ does not have the latest llvm packages (for clang) -- say, llvm-toolset-11-* . (BTW, why??) Second, the alternate Springdale Linux repo http://springdale.princeton.edu/data/springdale/SCL/7/x86_64/ seems to have all the ones (which are provided in sources by RedHat), but cannot be used in Copr. Springdale provides devtoolset-3-elfutils there, and it in some strange way badly correlates with the initial Copr build environment (even before the rpmbuild process starts). Some python2 module cannot find libelf.so.1 ... That is because it is SCL package. It installs the library to /opt/rh/devtoolset-3/root/usr/lib64/libelf.so.1 You have to run scl enable devtools-3 $COMMAND to make this library available. More about SCL here: https://www.softwarecollections.org/en/ including Packaging guide. So the general questions are: - Whether it is possible to enable "rhel7-server-rhscl-7" and friends for epel7 builds in Copr? (See https://koji.fedoraproject.org/koji/taginfo?tagID=259 for more info); Copr tries to use as much as possible upstream Mock's config. AFAIK it is enabled there: https://github.com/rpm-software-management/mock/blob/main/mock-core-configs/etc/mock/templates/centos-7.tpl#L81 Miroslav___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Tue, Feb 22, 2022 at 12:00:06PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/CurlMinimal_as_Default > > == Summary == > `libcurl-minimal` and `curl-minimal` will be installed by default > instead of `libcurl` and `curl`. > The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP). > The full versions can be explicitly requested as `libcurl-full` and > `curl-full`. > > == Owner == > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in.waw.pl > * Name: [[User:Kdudka| Kamil Dudka]] > * Email: kdudka at redhat.com > > > == Detailed Description == > > The `curl` package provides two sets of subpackages: `curl`+`libcurl` > and `curl-minimal`+`libcurl+minimal`. > `curl-minimal`+`libcurl-minimal` are compiled with various > semi-obsolete protocols and infrequently-used features disabled: > DICT, GOPHER, IMAP, LDAP, LDAPS, MQTT, NTLM, POP3, RTSP, SMB, SMTP, > SFTP, SCP, TELNET, TFTP, brotli compression, IDN2 names. Did you discuss modularising curl itself upstream? That would be a better idea. Then we could package up the various *.so drivers into separate packages. Also I think this whole business of minimizing Fedora is getting way out of hand. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Fedocal] Reminder meeting : ELN SIG
Dear all, You are kindly invited to the meeting: ELN SIG on 2022-02-25 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/10133/ ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Is NetworkManager-wait-online.service necessary by default?
Hi, On Thu, 2022-02-24 at 07:47 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Feb 24, 2022 at 12:17:27AM +, Gary Buhrmaster wrote: > > On Wed, Feb 23, 2022 at 11:55 PM Chris Adams wrote: > > > > > > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > > > So this is the culprit. iscsi.service has Before=remote-fs-pre.target, > > > > After=network-online.target, which means that it'll delay the boot. > > > > > > If that's the problem, there's some other issue. On my up-to-date F35 > > > system, iscsi.service also has: > > > > > > ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes > > > > > > And on my systems, that directory is empty, so iscsi.service shouldn't > > > be holding up anything. > > Conditions are evaluated when the service would be exectued, so a unit > which is (eventually) skipped because of Conditions still has effect on > the boot ordering and may add additional jobs to the transaction. We want to wait for network-online.target only if the service is actually started. One way to achieve this might be to move waiting into ExecStartPre=. I imagine this could work by creating a new unit network-online-waitonly.target with After=network-online.target StopWhenUnneeded=yes which is then used inside iscsi.service ExecStartPre=/usr/bin/systemctl start network-online-waitonly.target Not great, but should work. I suppose the ideal solution would be that the iscsi service handles waiting internally and only becomes ready when the configured nodes are available or a timeout happens. Benjamin > systemd.unit(5) says: > > The conditions and asserts are checked at the time the queued > start job is to be executed. The ordering dependencies are > still respected, so other units are still pulled in and ordered > as if this unit was successfully activated, and the conditions > and asserts are executed the precise moment the unit would > normally start and thus can validate system state after the > units ordered before completed initialization. > > > How can one be sure that (in the general case) that one of the units > > that you are running After will not create the files/directories > > that will impact the test Condition(s)? > > We aren't. In fact the conditions are checked later as described above. > > > Those tests occur before the unit is actually started, but not > > before the ordering is performed. > > Yes. > > Zbyszek > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On 22/02/2022 18:00, Ben Cotton wrote: The "minimal" variants provide only a subset of protocols (HTTP, HTTPS, FTP). The full versions can be explicitly requested as `libcurl-full` and `curl-full`. Let's also drop FTP support both from libcurl and dnf (including all ftp:// mirrors from metalink). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220224.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-20220223.0): ID: 1145601 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1145601 ID: 1145614 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1145614 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-35-20220224.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220223.0): ID: 1145352 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1145352 ID: 1145365 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1145365 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2031800] perl-GD-SecurityImage for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2031800 Emmanuel Seyman changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Emmanuel Seyman --- https://pagure.io/releng/fedora-scm-requests/issue/42553 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2031800 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Curl-minimal as default (System-Wide Change proposal)
On Wednesday, February 23, 2022 7:01:26 PM CET Björn Persson wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > According to ICANN [1], there were 8.3 mln IDN domains worldwide. > > And that's presumably only second-level domains. Nobody knows how many > non-ASCII subdomains exist under ASCII second-level domains, since > domain holders define subdomains at will without telling anybody. > > There are currently 153 non-ASCII top-level domains out of 1486 total, > which is 10.3%: > https://data.iana.org/TLD/tlds-alpha-by-domain.txt > > > Apparently .рф is fairly popular, with 1/5th of .ru registrations [3]. > > And that was eight years ago, only four years after рф was opened for > registrations. > > > But from what I have seen, all those internationalized domains serve > > as a redirect or backup to sites also available as ascii. > > In 2013 11% of рф domains redirected to ASCII domains, 50% were in use > and not redirecting, and 39% were only registered but unused. Already > in 2011, the year after the floodgates were opened, 34% were in use and > not redirecting. This is according to page 116 of this report: > https://web.archive.org/web/20141210151244/http://www.eurid.eu/files/publ/ID > NWorldReport2014_Interactive.pdf > > But yes, it's still often necessary to resort to ASCII, either the ACE > form (xn--gobbledygook) or a separate ASCII-only fallback domain. Email > in particular remains a major drag. Only in 2012 was there enough > consensus to publish a proposed standard for SMTPUTF8. Extensions to > IMAP and POP followed in 2013. Support in various email-handling > programs is still lacking. As long as people feel that they must have > an ASCII domain for email, some will naturally choose to use that same > domain for their website rather than using two separate domains. > > > And for command-line > > tools or scripting, using those ascii versions seems quite likely… > > That's another area where support for IDNA is spotty, yes. OpenSSH > still lacks support for example. So does Nmap. The Bind utils have > incomplete and inconsistent support. "dig", "host" and "nslookup" can > look up non-ASCII domain names, but if a server to query is specified, > then they expect the server to have an ASCII-only name. "delv" lacks > support entirely. > > This is the problem that you're about to make worse. People will find > that support for IDNA is unreliable in various programs that use Curl > under the hood. To work around the problem they'll resort to the ACE > form, or to an ASCII-only domain they have for precisely that purpose. > Thus you end up hampering the adoption of international domains even > more. > > > So I'd definitely vote to enable libidn2 in curl-minimal, > > _if_ there are people who'd actually use this for real. > > People can't use it until it's consistently supported, and you won't > support it until people use it. Do you mean to wait for all the other > command line programs to support IDNA first, and then, when the whole > world is waiting for you, then you'll turn it on in Curl and people > will start using it? Guess what – everybody else is also waiting for > everybody else. > > This is the same deadlock that hampers IPv6, encrypted email and many > other things. Everybody's waiting for everybody else to move first. > > Björn Persson There seems to be demand for libcurl with IDN support on minimal Fedora installations, so I created a pull request to enable it in libcurl-minimal: https://src.fedoraproject.org/rpms/curl/pull-request/13 Kamil ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
