Re: Plan to deprecate pytz in Fedora 35+
On Thu, Feb 18, 2021 at 05:39:30PM +0100, Miro Hrončok wrote: > On 18. 02. 21 17:16, Felix Schwarz wrote: > >Hi Miro, > > > >I can understand the desire to remove pytz and I have to mention > >that I don't have any specific upstream feedback. > > > >However certbot/babel do support pretty old versions of Python. > >Adding a separate code path for Python 3.x+ might be a pretty > >tough sell and might contribute to the "let's advertise snaps only > >for distribution" mindset. I think there shouldn't be resistance from certbot to drop the dependency. certbot should be deployable in really minimal environments, so I expect people would be happy to drop the dependency. Zbyszek > Hi Felix. > > Disclaimer: We are not removing pytz as long as there are packages > that depend on it. > > For babel, I follow this: https://github.com/python-babel/babel/issues/716 > > Since we have marked the pytz package unwanted for ELN and we have > babel in ELN (trough sphinx), we'll most likely try to help there > (or get rid of babel from ELN's sphinx). > > BTW There's backports.zoneinfo for Python 3.6+, so we'll see how > long babel needs to support Python 2. ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210219.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210218.0): ID: 782628 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/782628 ID: 782640 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/782640 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[389-devel] 389 DS nightly 2021-02-19 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/19/report-389-ds-base-2.0.3-20210219git845e0f9ff.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
License field correction: python-pyrsistent is now “MIT and BSD” instead of “MIT”
The License field for python-pyrsistent is now “MIT and BSD” instead of “MIT”; this is a correction rather than an upstream change. ___ 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 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-87e6bb3010 chromium-88.0.4324.150-1.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-610589457a prosody-0.11.8-1.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bfa4482ae0 libmysofa-1.2-4.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing koji-1.24.0-1.el8 Details about builds: koji-1.24.0-1.el8 (FEDORA-EPEL-2021-83d966f8b3) Build system tools Update Information: Update to 1.24.0 upstream release. See https://pagure.io/koji/blob/master/f/docs /source/release_notes/release_notes_1.24.rst for more details ChangeLog: * Thu Feb 18 2021 Kevin Fenzi - 1.24.0-1 - Update to 1.24.0. Fixes rhbz#1930032 ___ 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
Retired standalone man-pages-it in favor of man-pages-l10n subpackage
Hi, FYI, I have retired the standalone man-pages-it package, which is superseded by a recently added subpackage (with higher EVR) of man-pages-l10n, on F34/Branched and Rawhide. See: https://bugzilla.redhat.com/show_bug.cgi?id=1930270 man-pages-l10n is the new upstream for Italian translations of manpages. Kevin Kofler ___ 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 1919730] Please build perl-Net-XMPP for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1919730 Bug 1919730 depends on bug 1919731, which changed state. Bug 1919731 Summary: Please build perl-XML-Stream for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1919731 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1919731] Please build perl-XML-Stream for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1919731 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-XML-Stream-1.24-17.el8 Resolution|--- |ERRATA Last Closed||2021-02-19 01:10:58 --- Comment #6 from Fedora Update System --- FEDORA-EPEL-2021-c5324b6008 has been pushed to the Fedora EPEL 8 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. ___ 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
[389-devel] please review: PR 4636 - UI - Migrate Toast Notifications to PF4 Alerts
https://github.com/389ds/389-ds-base/pull/4636 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
OCaml 4.12
Richard, I see that the OCaml 4.12 release is not expected to happen until next week, after the beta freeze: https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294 Some of my OCaml packages are currently not installable, due to the dynlink hiccup, I think. Rather than enter beta freeze with them in this state, I would like to rebuild them. I was thinking about proceeding with the updates needed for OCaml 4.12, since I have to build these packages anyway, and the updated versions also work with OCaml 4.11. As a reminder, these are the updates: - ocaml-base: 0.14.0 -> 0.14.1 - ocaml-migrate-parsetree: 1.8.0 -> 2.1.0 - ocaml-ppxlib: 0.15.0 -> 0.22.0 - ocaml-bisect-ppx: 2.5.0 -> 2.6.0 - ocaml-tyxml: apply this pull request to switch to ppxlib: https://github.com/ocsigen/tyxml/pull/271 - ocaml-lwt: 5.3.0 -> 5.4.0 - ocaml-ppx-deriving: 5.1 -> 5.2.1 - ocaml-ppx-optcomp: 0.14.0 -> 0.14.1 - ocaml-ppx-sexp-conv: 0.14.1 -> 0.14.2 - ocaml-sedlex: 2.2 -> 2.3 - ocaml-ppx-custom-printf: 0.14.0 -> 0.14.1 - ocaml-ppx-fields-conv: 0.14.1 -> 0.14.2 - Retire ocaml-ppx-tools-versioned along with a number of other package builds just to fix dependencies. That would also simplify things for you when OCaml 4.12 is released, as all of these updates would already be in place. What do you think? Also, I would like to update ocaml-ocamlgraph to version 2.0.0 at some point. The only Fedora consumers are frama-c and ocaml-dose3. The current version of frama-c can already be built with either ocamlgraph 1.x or 2.x. The version of ocaml-dose3 in Fedora (5.0.1) cannot be built with ocamlgraph 2.x. However, upstream has moved here: https://gitlab.com/irill/dose3 and released a 6.x series that supports ocamlgraph 2.x. Unfortunately, there are issues with moving to version 6.x. First, and easiest, the new versions depend on camlbz2 and parmap, neither of which are in Fedora. I've put together spec files for those two and can submit them for review if nobody else wants to do so. Second, upstream removed support for RPM in this commit: https://gitlab.com/irill/dose3/-/commit/e656b5783f1fc5fd75e0e2716b0a40aca282ad72 I don't know why. The commit message does not give a reason, and this change is not mentioned in the project changelog. I assume RPM support is important for the Fedora build of ocaml-dose3. I don't know what the best approach is to resolve this issue, but it is blocking the ocamlgraph update. Any thoughts on the matter are appreciated. Regards, -- Jerry James http://www.jamezone.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
HEADS UP: Python dist RPM generators switched from "pkg_resources" to "packaging"
Hello Pythonistas, We have just shipped a medium size implementation chanage of Python dist RPM generators (the thing that automatically generates python3.Xdist(...) / python3dist(...) requires and provides). Details: https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/30 We don't anticipate issues, but if you see some troubles wrt python3.Xdist() or python3dist() dependencies in Fedora 34+, do let me know. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: granite soname bump and wingpanel library name change
On Fri, Feb 12, 2021 at 6:14 PM Fabio Valentini wrote: > > Hi everybody, > > The elementary OS 6 development is finally heading towards the finish > line, and the upcoming granite and wingpanel updates will have an > soname change (granite) and a renamed library (wingpanel-2 -> > wingpanel-3). In both cases, the ABI change is primarily caused by the > removal of long deprecated APIs. > > I have been doing nightly builds [0] of all elementary / Pantheon > components against the new versions of both libraries for a while, and > I have not seen any problems related to the use of those two > libraries. > > I will update granite and wingpanel next week for both Rawhide and > F34. If no stable release is available for granite and wingpanel at > that point (which is likely), I will use a pre-release snapshot > (upstream has assured me that no further ABI changes are planned > between now and the final release). I have been testing nightly > snapshots on Fedora 34 for a while, and the snapshot builds are > already comparable wrt. stability to the latest stable builds that are > currently available on Fedora. > > I know that this is kinda late for F34, but not doing it for F34 would > limit any future elementary / Pantheon updates to Fedora 35+. The > elementary OS 6 release (based on ubuntu 20.04 LTS) is coming together > much later than expected, and this is why I waited so long with > pushing these two library changes, but the upcoming F34 Beta Freeze > means there's no more waiting :) > > All builds will be done by me in side tags in the correct order > (granite ← plank ← gala ← wingpanel ← other builds). I am main > maintainer of most dependent packages (not listed below), but I will > also handle rebuilds of packages owned by other packagers: I have started the builds for rawhide and f34 today, and have not encountered any trouble so far. However, submitting all ~80 builds will take a while, since there are no stable releases of most components yet and I need to update most packages to git snapshots to get support for the latest libraries. After the builds that require switching to snapshot builds are done, I will submit the "plain rebuilds": > - agenda > - appeditor > - bookworm > - coin > - dippi > - elementary-planner > - ephemeral > - fondo > - harvey > - minder > - notes-up > - nutty > - optimizer > - quilter > - sequeler > - taxi > - vgrive I hope to be able to finish the side tag builds and submit bodhi updates for them by tomorrow or Saturday. 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-34-20210218.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Failed openQA tests: 25/183 (x86_64), 22/124 (aarch64) New failures (same test not failed in Fedora-34-20210217.n.0): ID: 781834 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/781834 ID: 781853 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/781853 ID: 781858 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/781858 ID: 781862 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/781862 ID: 781865 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/781865 ID: 781866 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/781866 ID: 781955 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/781955 ID: 782073 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/782073 ID: 782080 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/782080 ID: 782304 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/782304 ID: 782305 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/782305 Old failures (same test failed in Fedora-34-20210217.n.0): ID: 781783 Test: x86_64 Server-dvd-iso mediakit_repoclosure URL: https://openqa.fedoraproject.org/tests/781783 ID: 781896 Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi URL: https://openqa.fedoraproject.org/tests/781896 ID: 781902 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/781902 ID: 781907 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/781907 ID: 781908 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/781908 ID: 781914 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/781914 ID: 781916 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/781916 ID: 781917 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/781917 ID: 781928 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/781928 ID: 781932 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/781932 ID: 781933 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/781933 ID: 781952 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/781952 ID: 781975 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/781975 ID: 781982 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/781982 ID: 781990 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/781990 ID: 781991 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/781991 ID: 781992 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/781992 ID: 781995 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/781995 ID: 781996 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/781996 ID: 782022 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/782022 ID: 782034 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/782034 ID: 782047 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/782047 ID: 782054 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/782054 ID: 782062 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/782062 ID: 782065 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/782065 ID: 782067 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/782067 ID: 782069 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/782069 ID: 782079 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/782079 ID: 782085
Review swap
Hi all, Recent versions of jmol have a new dependency, jni-inchi: https://bugzilla.redhat.com/show_bug.cgi?id=1929958 Who would like to swap reviews? -- Jerry James http://www.jamezone.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-IoT-34-20210218.0 compose check report
No missing expected images. Failed openQA tests: 4/15 (aarch64), 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-34-20210215.0): ID: 782296 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/782296 ID: 782302 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/782302 Old failures (same test failed in Fedora-IoT-34-20210215.0): ID: 782283 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/782283 ID: 782288 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/782288 ID: 782297 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/782297 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-34-20210215.0): ID: 782273 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/782273 Passed openQA tests: 14/16 (x86_64), 11/15 (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
[389-devel] please review: PR 4635 - UI - Migrate CustomCollapse to PF4 ExpandableSection
https://github.com/389ds/389-ds-base/pull/4635 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-02-19 from 17:00:00 to 18:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ 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
[Test-Announce] Fedora-IoT 34 RC 20210218.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 34 RC 20210218.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/34iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20210218.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_34_RC_20210218.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org 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: Plan to deprecate pytz in Fedora 35+
On 18. 02. 21 17:16, Felix Schwarz wrote: Hi Miro, I can understand the desire to remove pytz and I have to mention that I don't have any specific upstream feedback. However certbot/babel do support pretty old versions of Python. Adding a separate code path for Python 3.x+ might be a pretty tough sell and might contribute to the "let's advertise snaps only for distribution" mindset. Hi Felix. Disclaimer: We are not removing pytz as long as there are packages that depend on it. For babel, I follow this: https://github.com/python-babel/babel/issues/716 Since we have marked the pytz package unwanted for ELN and we have babel in ELN (trough sphinx), we'll most likely try to help there (or get rid of babel from ELN's sphinx). BTW There's backports.zoneinfo for Python 3.6+, so we'll see how long babel needs to support Python 2. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Don't update to the latest f33! (fwd)
Thanks for this information. See in-line.
--
*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*
On Thu, 18 Feb 2021, Michael Catanzaro wrote:
Date: Thu, 18 Feb 2021 10:46:53
From: Michael Catanzaro
Reply-To: Development discussions related to Fedora
To: David Both
Cc: Development discussions related to Fedora
,
Steve Dickson
Subject: Re: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 10:39 am, David Both wrote:
Ok, so I manage my network using DHCP on an internal server for all except
that server and my Linux firewall/router which both use a complete static
configuration for networking.
My DHCP server does provide DNS resolver information which, in order, is
my internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4.
But my hosts were not getting that information. I think the difference
between the working and failing hosts is possibly (experiments required)
left-over ifcfg files some of which specified DHCP but also name servers
while others specified DHCP but did not specify name servers, as well as
some newer hosts that do not have any ifcfg files. I have also noticed
that ifcfg files are no longer created automatically but work when
created. I missed that information also.
OK, so DHCP is not working somehow. Are you running NetworkManager? That is
my #1 guess right now, because without NetworkManager, you have no easy way
to get DNS configuration from DHCP to systemd-resolved. systemd-resolved
doesn't configure itself: that's the responsibility of a higher-level
management layer, usually NetworkManager, or alternatively systemd-networkd.
You can configure it manually with your own scripts if you're really
hardcore. But if you have disabled NetworkManager, then my recommendation
would be to disable systemd-resolved as well. If you *are* running
NetworkManager, then unfortunately we're probably going to need to debug
NetworkManager to figure out why the configuration from DHCP is getting
dropped. I don't know how to help with that, but that also seems unlikely
because nobody has reported bugs related to that as far as I know.
If you are running NetworkManager, here are some more general
troubleshooting steps that I had typed up to send before reading the above:
I am running NetworkManager. I had disabled and stopped systemd-resolved on GP
after other hosts failed. After starting systemd-resolved everything looks to
be configured correctly:
[root@david ~]# resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
DNS Servers: 192.168.0.52
Fallback DNS Servers: 1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700::
2001:4860:4860:: 2606:4700:4700::1001 2001:4860:4860::8844
DNS Domain: both.org
Link 2 (enp0s31f6)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: 192.168.0.52 8.8.8.8 8.8.4.4
DNS Domain: both.org ~.
Link 3 (vboxnet0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
But everything is working and has been on my primary workstation - which is why
I did not see this until I upgraded to F33 on other hosts. This host has no
ifcfg file.
I really need to experiment with this a bit. I will get back to you with my
results.
The most important thing to do is to check the output of 'resolvectl' and
look for anything suspicious. Ideally the DNS server you want things going
to will be listed under each desired network interface with +DefaultRoute
set. Hopefully something will be obviously wrong there, but if not, you can
post the output of 'resolvectl' here for us to take a look.
To ensure systemd-resolved's configuration doesn't get bypassed, you'll also
want to ensure you're running Fedora's new default configuration, which you
should be, since users should be automatically upgraded. But just in case,
it's good to check:
* Ensure NetworkManager is running ('systemctl status
NetworkManager.service'). If not, you're on your own and should consider
disabling systemd-resolved since it's not worth trying to use manually.
* Ensure systemd-resolved is running: 'systemctl status
systemd-resolved.service'
* Ensure /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf (this ensures anything reading it
manually gets pointed to systemd-resolved's IP address, 127.0.0.53)
* Ensure the hosts line in
Re: Plan to deprecate pytz in Fedora 35+
Hi Miro, I can understand the desire to remove pytz and I have to mention that I don't have any specific upstream feedback. However certbot/babel do support pretty old versions of Python. Adding a separate code path for Python 3.x+ might be a pretty tough sell and might contribute to the "let's advertise snaps only for distribution" mindset. Felix ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 compose report: 20210218.n.0 changes
OLD: Fedora-34-20210217.n.0 NEW: Fedora-34-20210218.n.0 = SUMMARY = Added images:6 Dropped images: 0 Added packages: 11 Dropped packages:0 Upgraded packages: 103 Downgraded packages: 1 Size of added packages: 32.17 MiB Size of dropped packages:0 B Size of upgraded packages: 4.06 GiB Size of downgraded packages: 33.26 KiB Size change of upgraded packages: 73.05 MiB Size change of downgraded packages: -521 B = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-34-20210218.n.0.armhfp.raw.xz Image: Container_Base docker armhfp Path: Container/armhfp/images/Fedora-Container-Base-34-20210218.n.0.armhfp.tar.xz Image: Container_Minimal_Base docker armhfp Path: Container/armhfp/images/Fedora-Container-Minimal-Base-34-20210218.n.0.armhfp.tar.xz Image: Minimal raw-xz armhfp Path: Spins/armhfp/images/Fedora-Minimal-34-20210218.n.0.armhfp.raw.xz Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-34-20210218.n.0.armhfp.raw.xz Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-34-20210218.n.0.armhfp.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: efitools-1.9.2-3.fc34 Summary: Tools to manipulate EFI secure boot keys and signatures RPMs:efitools Size:479.56 KiB Package: ocaml-bigarray-compat-1.0.0-1.fc34 Summary: Compatibility library to use Stdlib.Bigarray when possible RPMs:ocaml-bigarray-compat ocaml-bigarray-compat-devel Size:252.48 KiB Package: ocaml-ctypes-0.18.0-1.fc34 Summary: Combinators for binding to C libraries without writing any C RPMs:ocaml-ctypes ocaml-ctypes-devel ocaml-ctypes-doc Size:8.07 MiB Package: ocaml-integers-0.4.0-1.fc34 Summary: Various signed and unsigned integer types for OCaml RPMs:ocaml-integers ocaml-integers-devel ocaml-integers-doc Size:1.69 MiB Package: ocaml-luv-0.5.7-1.fc34 Summary: OCaml binding to libuv for cross-platform asynchronous I/O RPMs:ocaml-luv ocaml-luv-devel ocaml-luv-doc Size:20.13 MiB Package: pdbg-3.2-2.fc34 Summary: PowerPC FSI Debugger RPMs:pdbg pdbg-devel pdbg-libs Size:161.86 KiB Package: perl-Crypt-PBKDF2-0.161520-12.fc34 Summary: The PBKDF2 password hashing algorithm RPMs:perl-Crypt-PBKDF2 Size:36.00 KiB Package: python-aexpect-1.5.1-5.module_f34+11433+fbb3f3ce Summary: A python library to control interactive applications RPMs:python3-aexpect Size:51.37 KiB Package: python-avocado-82.0-1.module_f34+11433+fbb3f3ce Summary: Framework with tools and libraries for Automated Testing RPMs:python-avocado-bash python-avocado-common python-avocado-examples python3-avocado python3-avocado-plugins-glib python3-avocado-plugins-golang python3-avocado-plugins-loader-yaml python3-avocado-plugins-output-html python3-avocado-plugins-result-upload python3-avocado-plugins-resultsdb python3-avocado-plugins-varianter-cit python3-avocado-plugins-varianter-pict python3-avocado-plugins-varianter-yaml-to-mux Size:891.13 KiB Package: python-tkrzw-0.1.4-2.fc34 Summary: TKRZW Python bindings RPMs:python-tkrzw-doc python3-tkrzw Size:435.68 KiB Package: rust-derive-new-0.5.9-1.fc34 Summary: Derive simple constructor functions for structs and enums RPMs:rust-derive-new+default-devel rust-derive-new+std-devel rust-derive-new-devel Size:29.94 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Lmod-8.4.23-1.fc34 Old package: Lmod-8.4.15-2.fc34 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.07 MiB Size change: 1.21 KiB Changelog: * Thu Feb 18 2021 Orion Poplawski - 8.4.23-1 - Update to 8.4.23 Package: accel-config-3.0.1-1.fc34 Old package: accel-config-2.8-2.fc34 Summary: Configure accelerator subsystem devices RPMs: accel-config accel-config-devel accel-config-libs Size: 183.71 KiB Size change: -61.26 KiB Changelog: * Thu Feb 18 2021 Yunying Sun - 3.0.1-1 - Updated to 3.0.1 release - Removed ix86 support as so far it supports x86_64 only - Updated licenses following upstream Package: appstream-0.14.1-1.fc34 Old package: appstream-0.14.0-1.fc34 Summary: Utilities to generate, maintain and access the AppStream database RPMs: appstream appstream-devel appstream-qt appstream-qt-devel Size: 12.66 MiB Size change: 58.90 KiB Changelog: * Wed Feb 17 2021 Rex Dieter - 0.14.1-1 - 0.14.1 Package: at-spi2-core-2.39.90-1.fc34 Old package: at-spi2-core-2.38.0-3.fc34 Summary: Protocol definitions and daemon for D-Bus at-spi RPMs: at-spi2-core at-spi2-core-devel Size: 1.84 MiB Size change: 64.52 KiB Changelog: * Wed Feb 17 2021 Kalev Lember - 2.39.90-1 - Update to 2.39.90 - Drop unused ldconfig_scriptlets macro call Package: beaker-28.2-1.fc34 Old package: beaker-28.1-1.fc34 Summary: Full-stack software and hardware integration testing system RPMs
Re: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 10:39 am, David Both
wrote:
Ok, so I manage my network using DHCP on an internal server for all
except that server and my Linux firewall/router which both use a
complete static configuration for networking.
My DHCP server does provide DNS resolver information which, in order,
is my internal BIND server (same physical server host), 8.8.8.8, and
8.8.4.4. But my hosts were not getting that information. I think the
difference between the working and failing hosts is possibly
(experiments required) left-over ifcfg files some of which specified
DHCP but also name servers while others specified DHCP but did not
specify name servers, as well as some newer hosts that do not have
any ifcfg files. I have also noticed that ifcfg files are no longer
created automatically but work when created. I missed that
information also.
OK, so DHCP is not working somehow. Are you running NetworkManager?
That is my #1 guess right now, because without NetworkManager, you have
no easy way to get DNS configuration from DHCP to systemd-resolved.
systemd-resolved doesn't configure itself: that's the responsibility of
a higher-level management layer, usually NetworkManager, or
alternatively systemd-networkd. You can configure it manually with your
own scripts if you're really hardcore. But if you have disabled
NetworkManager, then my recommendation would be to disable
systemd-resolved as well. If you *are* running NetworkManager, then
unfortunately we're probably going to need to debug NetworkManager to
figure out why the configuration from DHCP is getting dropped. I don't
know how to help with that, but that also seems unlikely because nobody
has reported bugs related to that as far as I know.
If you are running NetworkManager, here are some more general
troubleshooting steps that I had typed up to send before reading the
above:
The most important thing to do is to check the output of 'resolvectl'
and look for anything suspicious. Ideally the DNS server you want
things going to will be listed under each desired network interface
with +DefaultRoute set. Hopefully something will be obviously wrong
there, but if not, you can post the output of 'resolvectl' here for us
to take a look.
To ensure systemd-resolved's configuration doesn't get bypassed, you'll
also want to ensure you're running Fedora's new default configuration,
which you should be, since users should be automatically upgraded. But
just in case, it's good to check:
* Ensure NetworkManager is running ('systemctl status
NetworkManager.service'). If not, you're on your own and should
consider disabling systemd-resolved since it's not worth trying to use
manually.
* Ensure systemd-resolved is running: 'systemctl status
systemd-resolved.service'
* Ensure /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf (this ensures anything reading it
manually gets pointed to systemd-resolved's IP address, 127.0.0.53)
* Ensure the hosts line in /etc/nsswitch.conf looks like this: files
mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
(Remember to never edit /etc/nsswitch.conf manually, instead edit
/etc/authselect/user-nsswitch.conf and then run 'sudo authselect
apply-changes'.)
___
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: Don't update to the latest f33!
;-) Response to earlier email: Thanks for the informative response Michael. I plan to read the content at those links in some depth. What I see so far does describe how name resolution now works and hints at why this is being done. Even had I read that it would not have prepared me for the possibility that the resolver would fail so completely in my relatively simple environment. Nor does it suggest how to return to a working resolver, either by returning to either nss option or correcting the systemd-resolved configuration -- and I still do not know how to approach that. I will continue to read. I guess that there are more places to get the information than I have previously been aware, but that still doesn't mean that most users will find it or understand it. I read stuff like this all the time but totally missed that. I can't imagine how most regular users and busy-to-their-eyeballs sysadmins will run across this and then know how to connect the dots between change and symptom. It took me a good bit of experimenting to figure out that /etc/resolv.conf is now just a link and the specific link used defines how name resolution actually works. My usual procedure with resolver problems is to cat /etc/resolv.conf but that does not tell me it is a link. I only realized that a major change had been made by doing a long listing while looking for old or conflicting files. Then I was on track to figure it out. I think your statement about name resolution being bad would only be true if I were part of one of the edge cases for which the old way failed. This is from a user standpoint where "all is good until it fails" rather than a developer standpoint where "it suck behind the scenes so it needs fixed even if it breaks things for a while." I do like most of what systemd does. I do think that perhaps better testing of possible failure modes and circumstances as well as communication of possible problems, their symptoms, known fixes, and circumventions would help. And it needs to be obvious to anyone looking for that information. Response to this email: Ok, so I manage my network using DHCP on an internal server for all except that server and my Linux firewall/router which both use a complete static configuration for networking. My DHCP server does provide DNS resolver information which, in order, is my internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4. But my hosts were not getting that information. I think the difference between the working and failing hosts is possibly (experiments required) left-over ifcfg files some of which specified DHCP but also name servers while others specified DHCP but did not specify name servers, as well as some newer hosts that do not have any ifcfg files. I have also noticed that ifcfg files are no longer created automatically but work when created. I missed that information also. I am willing to help with this. Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 18 Feb 2021, Michael Catanzaro wrote: Date: Thu, 18 Feb 2021 09:34:52 From: Michael Catanzaro Reply-To: Development discussions related to Fedora To: David Both , Development discussions related to Fedora Cc: Steve Dickson Subject: Re: Don't update to the latest f33! On Thu, Feb 18, 2021 at 8:30 am, Michael Catanzaro wrote: We don't set DNS there intentionally because it eliminates any benefit of using split DNS. Your static global DNS= configuration in resolved.conf is used for *every* request, *in addition* to per-link DNS configuration. So if you have per-link DNS configuration from DHCP -- which almost everybody will except in cloud environments like this -- then you would wind up with two parallel DNS queries going out for every lookup, where whichever finishes first wins. That's not a good default. Well I should clarify: it *is* a good default for cloud or server environments where it is guaranteed that DHCP will not provide any DNS configuration and you just need a simple, static DNS config. So if the cloud provider inserted its DNS config here, that was probably the right thing to do. It just needs to not use commas. :P ___ 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:
Re: ELN SIG Launch
On Thu, Feb 18, 2021 at 07:19:13AM -0500, Stephen Gallagher wrote: > * All Fedora hardware resources are provided/funded by Red Hat, Inc. > * This project is taking place within the Fedora community and infrastructure. > * This project is clearly beneficial to Red Hat, Inc. > * Projects beneficial to Red Hat, Inc. tend to get additional funding > and personnel over time which benefits Fedora as a whole. I want to add an additional thing: Is Red Hat getting preferential treatment here? No. Anyone else wants to show up with hardware, funding, dedicated work time, and other resources to work on something in Fedora that fits within our mission and fits our values, and we'll work to figure out a way to fit it in. -- Matthew Miller Fedora Project Leader ___ 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: Status update for the new AAA system
Hey folks! Some update since last time: - we re-ran the import script with the suggested optimisation, it was faster but still took about 52 hours, so we'll run an incremental updater until we go to prod. There are still ways we can cut down on the number of imported accounts (not importing disabled accounts for example). - we're making progress on the 2FA issue, still ironing out the details - we're also hardening the security settings for the new webapp, Noggin, so that it fits our application security policy. At that point our aim is to migrate production early March. We'll keep you posted! Aurélien ___ 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: Don't update to the latest f33!
Dnia Thu, Feb 18, 2021 at 02:37:54PM +, Sven Kieske napisał(a): > On Do, 2021-02-18 at 08:30 -0600, Michael Catanzaro wrote: > > Fedora will never configure static DNS servers for you in > > > > resolved.conf. That config file was manually edited with improper > > > > syntax to wind up in this broken state. My guess is that it was edited > > > > by the VPS provider, but who knows. > > still, as a user and sysadmin I would expect > any service to loudly complain (at least in a logfile) > about syntax errors in it's configfile, no matter how > the wrong config got there in the end, if by cfgmgmt, hand edited > or other system tools. > > but there is no such warning, or did I miss this information? It complains for me: % rg ^DNS= /etc/systemd/resolved.conf 19:DNS=1.1.1.1,1.0.0.1 systemd-resolved[23515]: Failed to add DNS server address '1.1.1.1,1.0.0.1', ignoring: Invalid argument This is with systemd-246.10-1.fc33.x86_64 -- Tomasz Torcz“Funeral in the morning, IDE hacking to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox ___ 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: Don't update to the latest f33!
On Do, 2021-02-18 at 08:30 -0600, Michael Catanzaro wrote: > Fedora will never configure static DNS servers for you in > > resolved.conf. That config file was manually edited with improper > > syntax to wind up in this broken state. My guess is that it was edited > > by the VPS provider, but who knows. still, as a user and sysadmin I would expect any service to loudly complain (at least in a logfile) about syntax errors in it's configfile, no matter how the wrong config got there in the end, if by cfgmgmt, hand edited or other system tools. but there is no such warning, or did I miss this information? -- Mit freundlichen Grüßen / Regards Sven Kieske Systementwickler Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp Tel.: 05772 / 293-900 Fax: 05772 / 293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer, Florian Jürgens St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar. 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: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 8:30 am, Michael Catanzaro wrote: We don't set DNS there intentionally because it eliminates any benefit of using split DNS. Your static global DNS= configuration in resolved.conf is used for *every* request, *in addition* to per-link DNS configuration. So if you have per-link DNS configuration from DHCP -- which almost everybody will except in cloud environments like this -- then you would wind up with two parallel DNS queries going out for every lookup, where whichever finishes first wins. That's not a good default. Well I should clarify: it *is* a good default for cloud or server environments where it is guaranteed that DHCP will not provide any DNS configuration and you just need a simple, static DNS config. So if the cloud provider inserted its DNS config here, that was probably the right thing to do. It just needs to not use commas. :P ___ 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: Don't update to the latest f33!
Fedora will never configure static DNS servers for you in resolved.conf. That config file was manually edited with improper syntax to wind up in this broken state. My guess is that it was edited by the VPS provider, but who knows. We don't set DNS there intentionally because it eliminates any benefit of using split DNS. Your static global DNS= configuration in resolved.conf is used for *every* request, *in addition* to per-link DNS configuration. So if you have per-link DNS configuration from DHCP -- which almost everybody will except in cloud environments like this -- then you would wind up with two parallel DNS queries going out for every lookup, where whichever finishes first wins. That's not a good default. On Thu, Feb 18, 2021 at 6:52 am, David Both wrote: I do not believe that this is just about lack of fallback and the silent fail. Although that is probably true, it is also about the "silent" change from nss to systemd-resolved and THEN the silent change to zero default fallback. There was a series of silent changes that brought this failure to light. There are different opinions on the fallback. The opinion that won in the end was removing the fallback to expose problems rather than hide them. I think that's an OK end result, but I agree it's unfortunate that happened in a post-release update such that installing updates can break a "working" (sort of) configuration. There's not really anything to be done about it now. Everything still goes through nss, and you can switch from nss-resolve back to nss-dns if you want to (but it will be worse). Not only do I not see the need for a change to a new name service client, the lack of information about the changeover to users outside this list is a terrible example for its lack of communication. Although I try to read the release notes I sometimes seem to miss things or fail to read them altogether. In addition to the release notes: https://fedoraproject.org/wiki/Changes/systemd-resolved#Release_Notes And the discussion of upgrade/compatibility impact on the change page: https://fedoraproject.org/wiki/Changes/systemd-resolved#Upgrade.2Fcompatibility_impact We also have two blog posts: https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/ https://blogs.gnome.org/mcatanzaro/2020/12/17/understanding-systemd-resolved-split-dns-and-vpn-configuration/ In particular, my blog post attempts to explain how terrible our DNS resolution was without systemd-resolved. It was bad. Fedora users deserve a decent DNS resolver. Exception: I suspect we might have a real problem for cloud servers without DHCP, which I reported in https://pagure.io/fedora-server/issue/10. My remaining question is, where can I find a complete description of systemd-resolved and what its design goals are? systemd-resolved(8) There is also this upstream documentation on how systemd-resolved handles VPNs: https://github.com/systemd/systemd/blob/main/docs/RESOLVED-VPNS.md That's specific to VPN configuration and intended for people writing third-party VPN software, but it shows pretty clearly exactly how systemd-resolved decides where to send your DNS, so if you are really trying to understand it's good to read. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Plan to deprecate pytz in Fedora 35+
Hello Pythonistas, We (me and Gwyn) plan to deprecate pytz in Fedora 35+: https://fedoraproject.org/wiki/Changes/DeprecatePytz The change is not submitted yet because of missing content in this section: https://fedoraproject.org/wiki/Changes/DeprecatePytz#How_to_migrate_to_the_standard_library I'm sending it here to the Fedora's Python list for early feedback before I collect some links to put into that section. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Change in glibc about _STAT_VER in Fedora rawhide?
On Fri, 2020-11-27 at 12:28 +0100, Florian Weimer wrote: > * Jan Pazdziora: > > > So do you recommend for fakechroot to hardcode something like > > > > --- a/src/libfakechroot.h > > +++ b/src/libfakechroot.h > > @@ -224,4 +224,14 @@ int fakechroot_try_cmd_subst (char *, const > > char *, char *); > > int snprintf(char *, size_t, const char *, ...); > > #endif > > > > +#ifndef _STAT_VER > > +#if defined (__aarch64__) > > +#define _STAT_VER 0 > > +#elif defined (__x86_64__) > > +#define _STAT_VER 1 > > +#else > > +#define _STAT_VER 3 > > +#endif > > +#endif > > + > > #endif > > > > for all the arches? > > Yes, the fakeroot case is really quite unusual, I think. I just fixed fakeroot build on F35 , but the same fix doesn't work for F34 ?!? https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c16 > > > There's a Fedora-specific hack in rawhide glibc to bring back the > > > __xstat and related symbols for linking. This in the process of > > > being > > > upstreamed. > > > > Does that include __fxstatat64? And is the hack already in > > glibc-2.32.9000-16.fc34 or is it on the way to rawhide? > > Looking at the current rawhide buildroot, it's already there: > > # eu-readelf --symbols=.dynsym /lib64/libc.so.6 | grep __fxstat64 > 1059: 000f1880 84 FUNCGLOBAL DEFAULT 15 > __fxstat64@@GLIBC_2.2.5 > > The @@ means it's available for linking. > > It's missing from upstream right now, but we'll fix that before the > upstream release. > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, > Michael O'Neill > ___ > 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 -- 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: ELN SIG Launch
On Fri, Feb 12, 2021 at 10:25 AM Stephen Gallagher wrote: > Is this a Fedora project or a Red Hat project using Fedora resources? > > Yes. OK, so this was meant to be a tongue-in-cheek joke as a way to acknowledge the question that came up in the original ELN discussions and identify that the answer is essentially "both". This was much clearer in the original draft of this email that I wrote when it was followed by a FAQ entry titled "Can you just say the quiet part out loud, please?" I reworked that into the "What is the benefit of ELN?" section and the nuance of the relationship between the two questions was lost. I should have dropped the joke question to avoid side-tracking the conversation. FWIW, Stephen Smoogen had it mostly right in his response, but I'll state it here: * All Fedora hardware resources are provided/funded by Red Hat, Inc. * This project is taking place within the Fedora community and infrastructure. * This project is clearly beneficial to Red Hat, Inc. * Projects beneficial to Red Hat, Inc. tend to get additional funding and personnel over time which benefits Fedora as a whole. > What is the benefit of ELN? > > The advent and refocus of CentOS Stream has provided a clearer story around > RHEL development. Fedora remains the development hub for the next major RHEL > release, while CentOS Stream fills that upstream role for stabilization and > updates. Thus, some of us have started exploring ways to ensure that Fedora > builds on its valuable position in the ecosystem. > > > We decided to focus on streamlining the process by which Fedora is forked and > becomes Red Hat Enterprise Linux. Historically, we would pick a Fedora > release, replicate its dist-git history internally and then proceed to make > all the changes, tweaks, and hideous hacks needed to bootstrap RHEL. All of > this would take place “behind the firewall,” and while we would usually pull > in many of the changes from at least one subsequent Fedora release, for the > most part this was effectively closed-source development from this point > onwards until release. > > > With CentOS Stream on the horizon, plans are already in motion for more of > the internal mechanisms being made public and visible. Therefore we decided > to look at making the bootstrapping process a more continuous effort, rather > than a complex ritual performed once every three years at midnight during a > full moon. Thus, the seeds of ELN were born. ___ 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: Don't update to the latest f33!
I do not believe that this is just about lack of fallback and the silent fail. Although that is probably true, it is also about the "silent" change from nss to systemd-resolved and THEN the silent change to zero default fallback. There was a series of silent changes that brought this failure to light. Not only do I not see the need for a change to a new name service client, the lack of information about the changeover to users outside this list is a terrible example for its lack of communication. Although I try to read the release notes I sometimes seem to miss things or fail to read them altogether. I am not sure I know how that bit can be fixed but I think it is an organic part of this failure. Perhaps such deep and basic changes should be mentioned in the release announcements along with a BOLO for related failures. Do not misunderstand me. I really like systemd overall. Perhaps you have seen my series of articles about various systemd tools at Opensource.com. But this bit does seem a little extreme. I think I have an idea for a new article. "The layers of Linux." ;-) Anyway, my personal approach to this is a return to nss by disabling systemd-resolved until the problem is well and truly fixed. And my name resolution is now working exactly as it should. My remaining question is, where can I find a complete description of systemd-resolved and what its design goals are? Thanks! -- * David P. Both, RHCE He/Him/His * www.both.org - My personal web site www.Linux-Databook.info - Home of the DataBook for Linux DataBook is a Registered Trademark of David Both * The value of any software lies in its usefulness not in its price. — Linus Torvalds * On Thu, 18 Feb 2021, Ed Greshko wrote: Date: Wed, 17 Feb 2021 21:11:12 From: Ed Greshko Reply-To: Development discussions related to Fedora To: Steve Dickson , Development discussions related to Fedora Subject: Re: Don't update to the latest f33! On 18/02/2021 09:18, Steve Dickson wrote: On 2/17/21 6:55 PM, Ed Greshko wrote: On 18/02/2021 05:11, Steve Dickson wrote: I agree... ignoring syntax error or parsing error just does not seem like the appropriate thing to do... Error out! Tell me what is broken so I can fix it!! Replace the "," with a " " in the DNS= entry of /etc/systemd/resolved.conf file. And if you didn't format it that way, find out who did. That is the question!!! I upgraded and DNS broke! I didn't even know there was a /etc/systemd/resolved.conf file until this unfortunate experience... I know this won't make you feel any better. But the problem you've seen has probably always existed on your system but was "hidden" from view. Previously the default for FallbackDNS as shown in /etc/systemd/resolved.conf was #FallbackDNS=1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4 2606:4700:4700:: 2001:4860:4860:: 2606:4700:4700::1001 2001:4860:4860::884 But many folks complained that they didn't want a Fallback defined pointing to Google or other "services". So, it was removed and is now #FallbackDNS= Meaning none are defined. So, previously, if your DNS= entry was incorrect you'd be protected by the existence of the Fallback being defined. Now, they are not. So, whoever supplied the badly formatted /etc/systemd/resolved.conf file is the "real" culprit. If I recall, you're using a VM supplied by a vendor? If so, have you notified them? ___ 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-20210218.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 41/183 (x86_64), 27/124 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210217.n.0): ID: 781344 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/781344 ID: 781345 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/781345 ID: 781353 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/781353 ID: 781356 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/781356 ID: 781358 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/781358 ID: 781359 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/781359 ID: 781367 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/781367 ID: 781371 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/781371 ID: 781375 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/781375 ID: 781378 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/781378 ID: 781381 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/781381 ID: 781409 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/781409 ID: 781427 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/781427 ID: 781432 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/781432 ID: 781434 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/781434 ID: 781440 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/781440 ID: 781442 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/781442 ID: 781450 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/781450 ID: 781465 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/781465 ID: 781466 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/781466 ID: 781482 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/781482 ID: 781488 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/781488 ID: 781542 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/781542 ID: 781553 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/781553 ID: 781554 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/781554 ID: 781572 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/781572 ID: 781596 Test: aarch64 universal install_anaconda_text@uefi URL: https://openqa.fedoraproject.org/tests/781596 Old failures (same test failed in Fedora-Rawhide-20210217.n.0): ID: 781316 Test: x86_64 Server-dvd-iso mediakit_repoclosure URL: https://openqa.fedoraproject.org/tests/781316 ID: 781323 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/781323 ID: 781325 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/781325 ID: 781332 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/781332 ID: 781346 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/781346 ID: 781386 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/781386 ID: 781391 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/781391 ID: 781395 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/781395 ID: 781398 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/781398 ID: 781399 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/781399 ID: 781429 Test: aarch64
Fedora rawhide compose report: 20210218.n.0 changes
OLD: Fedora-Rawhide-20210217.n.0 NEW: Fedora-Rawhide-20210218.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 20 Dropped packages:2 Upgraded packages: 109 Downgraded packages: 3 Size of added packages: 35.10 MiB Size of dropped packages:7.73 MiB Size of upgraded packages: 4.65 GiB Size of downgraded packages: 8.55 MiB Size change of upgraded packages: -455.75 MiB Size change of downgraded packages: -5.00 KiB = ADDED IMAGES = Image: KDE_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210218.n.0-sda.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: cairomm1.16-1.16.0-2.fc35 Summary: C++ API for the cairo graphics library RPMs:cairomm1.16 cairomm1.16-devel cairomm1.16-doc Size:1.27 MiB Package: efitools-1.9.2-3.fc35 Summary: Tools to manipulate EFI secure boot keys and signatures RPMs:efitools Size:479.81 KiB Package: jo-1.4-1.fc35 Summary: Small utility to create JSON objects RPMs:jo Size:169.46 KiB Package: kuser-16.08.3-15.fc35 Summary: User Manager for KDE RPMs:kuser Size:1.22 MiB Package: ocaml-bigarray-compat-1.0.0-1.fc35 Summary: Compatibility library to use Stdlib.Bigarray when possible RPMs:ocaml-bigarray-compat ocaml-bigarray-compat-devel Size:252.58 KiB Package: ocaml-ctypes-0.18.0-1.fc35 Summary: Combinators for binding to C libraries without writing any C RPMs:ocaml-ctypes ocaml-ctypes-devel ocaml-ctypes-doc Size:8.07 MiB Package: ocaml-integers-0.4.0-1.fc35 Summary: Various signed and unsigned integer types for OCaml RPMs:ocaml-integers ocaml-integers-devel ocaml-integers-doc Size:1.69 MiB Package: ocaml-luv-0.5.7-1.fc35 Summary: OCaml binding to libuv for cross-platform asynchronous I/O RPMs:ocaml-luv ocaml-luv-devel ocaml-luv-doc Size:20.13 MiB Package: pdbg-3.2-2.fc35 Summary: PowerPC FSI Debugger RPMs:pdbg pdbg-devel pdbg-libs Size:161.90 KiB Package: python-aexpect-1.5.1-5.module_f35+11432+cbc1455d Summary: A python library to control interactive applications RPMs:python3-aexpect Size:51.37 KiB Package: python-avocado-82.0-1.module_f35+11432+cbc1455d Summary: Framework with tools and libraries for Automated Testing RPMs:python-avocado-bash python-avocado-common python-avocado-examples python3-avocado python3-avocado-plugins-glib python3-avocado-plugins-golang python3-avocado-plugins-loader-yaml python3-avocado-plugins-output-html python3-avocado-plugins-result-upload python3-avocado-plugins-resultsdb python3-avocado-plugins-varianter-cit python3-avocado-plugins-varianter-pict python3-avocado-plugins-varianter-yaml-to-mux Size:890.92 KiB Package: python-batalgorithm-0.3.1-1.fc35 Summary: Bat Algorithm for optimization RPMs:python3-batalgorithm Size:13.19 KiB Package: python-maya-0.6.1-1.fc35 Summary: Datetimes for Humans RPMs:python3-maya Size:29.55 KiB Package: python-requests-credssp-1.0.0-10.fc35 Summary: This package allows for HTTPS CredSSP authentication using the requests library. RPMs:python3-requests-credssp Size:38.85 KiB Package: python-tkrzw-0.1.4-2.fc35 Summary: TKRZW Python bindings RPMs:python-tkrzw-doc python3-tkrzw Size:435.57 KiB Package: rust-codespan-reporting-0.9.5-2.fc35 Summary: Beautiful diagnostic reporting for text-based programming languages RPMs:rust-codespan-reporting+default-devel rust-codespan-reporting+serde-devel rust-codespan-reporting+serialization-devel rust-codespan-reporting-devel Size:77.75 KiB Package: rust-cxxbridge-flags-0.5.10-1.fc35 Summary: Compiler configuration of the `cxx` crate (implementation detail) RPMs:rust-cxxbridge-flags+c++14-devel rust-cxxbridge-flags+c++17-devel rust-cxxbridge-flags+c++20-devel rust-cxxbridge-flags+default-devel rust-cxxbridge-flags-devel Size:37.79 KiB Package: rust-cxxbridge-macro-0.5.10-2.fc35 Summary: Implementation detail of the `cxx` crate RPMs:rust-cxxbridge-macro+default-devel rust-cxxbridge-macro-devel Size:49.83 KiB Package: rust-link-cplusplus-1.0.5-2.fc35 Summary: Link libstdc++ or libc++ automatically or manually RPMs:rust-link-cplusplus+default-devel rust-link-cplusplus+libc++-devel rust-link-cplusplus+libcxx-devel rust-link-cplusplus+libstdc++-devel rust-link-cplusplus+libstdcxx-devel rust-link-cplusplus+nothing-devel rust-link-cplusplus-devel Size:60.08 KiB Package: rust-proc-quote-0.3.2-4.fc35 Summary: Procedural macro implementation of quote! RPMs:rust-proc-quote+default-devel rust-proc-quote-devel Size:34.37 KiB = DROPPED PACKAGES = Package: gnome-getting-started-docs-3.38.0-2.fc34 Summary: Help a new user get started in GNOME RPMs:gnome-getting-started-docs gnome-getting-started-docs-cs gnome-getting-started-docs-de gnome-getting-started-docs-es gnome-getting-started-docs-fr gnome-getting-started-docs-gl gnome-getting-started-docs-hu gnome-getting-started-docs
Fedora-Cloud-32-20210218.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210217.0): ID: 781299 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/781299 ID: 781311 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/781311 Passed openQA tests: 6/7 (x86_64), 6/7 (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
[389-devel] 389 DS nightly 2021-02-18 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/18/report-389-ds-base-2.0.3-20210218gita355b30b2.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: restic update and src.fedoraproject.org and Self Introduction
On Wed, Feb 17, 2021 at 07:19:26PM -0500, Kevin Anderson wrote: > Thank you! I'm unsure of what I was doing wrong initially but I > appreciate your help in resolving it! As James pointed out you'll need to use fedpkg if you're not a packager. The workflow is documented at: https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager Pierre > On Tue, Feb 16, 2021 at 9:17 PM James Cassell > wrote: > > > > > > > > On Tue, Feb 16, 2021, at 8:06 PM, Kevin Anderson wrote: > > [...] > > > The issue is that when I attempt to push over HTTPS I get an > > > authentication failure. I have tried with an API key as well as with > > > my FAS password using my FAS username (kanderson) for both. Is it > > > expected that I can't push, even to a fork, if I am not a part of a > > > packagers group? > > > > re-clone the repo using `fedpkg clone --anonymous`, then `git remote add > > fork `, then you can follow the prompts when you attempt to > > push to your fork. (it'll get you to open a browser and sign-in there) > > > > V/r, > > James Cassell > > ___ > > 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 ___ 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
