Re: Anyone interested in packaging + maintaining the nimble language?
> Maxwell G writes: > IIRC, we used to have nim in Fedora and then it was retired. Yes, it was in Fedora 33 but orphaned for some time and then retired. The last version packaged was 1.0.4. The final spec doesn't look very complicated but of course it's tough to say how that would apply to a current version of the language. The bug list shows that a number of CVEs went unresolved and were auto-closed after aging out. I would assume that most if not all of those would have been resolved by a simple update since upstream is active. - J< ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4cc86adbd2 chromium-116.0.5845.179-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9c17eb827f borgbackup-1.1.18-2.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing appx-util-0.5-2.el8 icewm-3.4.2-2.el8 openscap-report-0.2.5-1.el8 rust-difftastic-0.51.1-1.el8 Details about builds: appx-util-0.5-2.el8 (FEDORA-EPEL-2023-b28c63ddc3) Utility to create Microsoft .appx packages Update Information: New release with OpenSSL 3.x support included ChangeLog: * Mon Sep 11 2023 Neal Gompa - 0.5-2 - Fix BR for Python 3 for EL8 (RH#2237698) * Mon Sep 11 2023 Neal Gompa - 0.5-1 - Update to 0.5 - Migrate to SPDX license identifiers * Wed Jul 19 2023 Fedora Release Engineering - 0.4-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild * Wed Jan 18 2023 Fedora Release Engineering - 0.4-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Wed Jul 20 2022 Fedora Release Engineering - 0.4-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Wed Jan 19 2022 Fedora Release Engineering - 0.4-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Thu Dec 30 2021 Neal Gompa - 0.4-5 - Backport fix for OpenSSL 3.0 compatibility (RH#2018887) * Tue Sep 14 2021 Sahana Prasad - 0.4-4 - Rebuilt with OpenSSL 3.0.0 * Wed Jul 21 2021 Fedora Release Engineering - 0.4-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild References: [ 1 ] Bug #2237698 - appx-util should not BuildRequire /usr/bin/python3 https://bugzilla.redhat.com/show_bug.cgi?id=2237698 [ 2 ] Bug #2238252 - appx-util-0.5 is available https://bugzilla.redhat.com/show_bug.cgi?id=2238252 icewm-3.4.2-2.el8 (FEDORA-EPEL-2023-5e0fafc2f7) Window manager designed for speed, usability, and consistency Update Information: Update to latest version ChangeLog: * Mon Sep 11 2023 Artem Polishchuk - 3.4.2-1 - chore: Update to 3.4.2 (rh#2238422) openscap-report-0.2.5-1.el8 (FEDORA-EPEL-2023-1542786b65) A tool for generating human-readable reports from (SCAP) XCCDF and ARF results Update Information: 0.2.5 (Jan Rodak) ChangeLog: * Mon Sep 11 2023 Packit - 0.2.5-1 - 0.2.5 (Jan Rodak) - Show referenced OVAL State (Jan Rodak) - Parse reference in filter (Jan Rodak) - Show OVAL Variables and referenced OVAL endpoints in report (Jan Rodak) - Remove UUID from headings (Jan Rodak) - Move function (Jan Rodak) - Display in report OVAL object that references to other OVAL Objects (Jan Rodak) - Resolve parsing of referenced OVAL Objects and OVAL Variables (Jan Rodak) - Add OVAL Variable structure and parser (Jan Rodak) - Rework OVAL Object and State (Jan Rodak) - Parse mapping between OVAL var and values and propagate them (Jan Rodak) - Remove namesapace for attributes (Jan Rodak) - Show OVAL states in report (Jan Rodak) - Parse attributes of elements in OVAL state and Parse all OVAL states in OVAL test (Jan Rodak) - Show OVAL objects in report (Jan Rodak) - Parse attributes of elements in OVAL object (Jan Rodak) - Removing the processing of collected objects (Jan Rodak) - Use an empty string instead of None when the text of the set-value element is empty (Jan Rodak) - Fix deprecation warning (Jan Rodak) - Remove product detection from the tmt plan (Jan Rodak) - Increase vm memory (Jan Rodak) - Add python3 dependency (Jan Rodak) - Adjust the build of content (Jan Rodak) - Automatic product detection to build content by CPE identifier (Jan Rodak) - Remove whitespaces (Jan Rodak) - Show explanation of score computation in report (Jan Rodak) - Add explanation of score computation (Jan Rodak) - Parse system attribute from score element (Jan Rodak)
[Bug 2215048] Please build perl-EV for EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2215048 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-79b7ab6dab 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-2023-79b7ab6dab 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=2215048 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215048%23c3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Anyone interested in packaging + maintaining the nimble language?
On Sun Sep 10, 2023 at 22:04 +0100, Ankur Sinha wrote: > Hi folks, > > I have a package that has begun to use the nimble language in its new > version: > https://bugzilla.redhat.com/show_bug.cgi?id=2181693 > https://nim-lang.org/ > > It isn't packaged for Fedora yet, though. Is anyone using it, and would > like to package + maintain it for Fedora? IIRC, we used to have nim in Fedora and then it was retired. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
On Mon, 2023-09-11 at 09:40 -0700, Kevin Fenzi wrote: > These are the things that fedfind/qa users? Do we have examples of this > data? Okay, here is (again) a list of the stuff fedfind uses. You can see sample data for each compose in the web UI itself, PDC actually has a rather good interactive API view. 1. WHAT: https://pdc.fedoraproject.org/rest_api/v1/composes/ HOW: ?release=fedora-NN_label=label ?compose_id=cid WHY: To find a compose's compose ID from its label, or a compose's label from its compose ID. These functions are used on various paths. The most important one in real life is probably when we are creating and updating validation event pages for candidate composes, between the time the compose exists and the time it is synced to alt.fp.o - during this time wikitcms may need to look the compose up by label, but for fedfind to actually find it, cid_from_label has to work, because it can only 'natively' find a compose by label if it's been synced to alt.fp.o; if the compose has not yet been synced, the only way fedfind can find the compose is to use cid_from_label then locate it on kojipkgs under its compose ID. WORKAROUND: it would be difficult to work around this if we did not have the ability. For wikitcms we could try 'embedding' the compose ID in the event pages somehow. For some other less important uses there is probably no workaround. 2. WHAT: https://pdc.fedoraproject.org/rest_api/v1/compose-images/ HOW: compose-images/(composeid) WHY: To provide image metadata for nightly composes that have been garbage-collected, and releases in the mirror system after they have been split across directories and their metadata stripped WORKAROUND: if there is no store of metadata by compose ID then fedfind just can't do this any more. It's not critical functionality to anything important I'm aware of, though - it's just a nice feature that can be used to e.g. run long-term analysis of image size changes across multiple releases, stuff like that. If this goes away I will just drop this feature from fedfind and you will no longer be able to find the real metadata for these composes (it would provide synthesized metadata for mirrored releases, but not garbage-collected nightlies). Note, retrieving the original metadata for mirrored releases depends on the cid_from_label feature (see 1). 3. WHAT: https://pdc.fedoraproject.org/rest_api/v1/releases/ HOW: ?version=39=Fedora (for e.g.) WHY: To find the compose that was "previous" to any given compose. The first result for this PDC query for any given release is a dict with a handy 'compose_set' key whose value is a list of all the composes for that release, in reverse order by date. So we can easily find the compose that came 'before' any given compose. This is, I *think*, only used by the 'check-compose' script which sends out those "compose check report" emails. WORKAROUND: fedfind has a hideous alternative implementation of this which involves just blindly trying possible decrements and seeing if they exist. e.g. if you ask for the compose previous to Fedora-39- 20230911.n.1, it will try 20230911.n.0, if that doesn't exist, it will try 20230910.n.5 (we start counting backwards from 5 because, hey, gotta start somewhere, and doing more than 5 composes on one day is unlikely), then 20230910.n.4, and so on, until it hits something that exists. So, if we can't get a nice data set like this any more...we'll just have to use that. Bleh. We might also just drop check-compose and kill the feature, I suppose. I don't pay as much attention to those reports as I used to. 4. WHAT: https://pdc.fedoraproject.org/rest_api/v1/rpms/ HOW: ?compose=cid=src=^package1$=^package2$ WHY: To get the NEVR (name, epoch, version, release) for a given set of packages from a compose. This can be used by relvalconsumer (the thing that creates the wiki validation events) to decide whether any "important" packages changed between the last tested compose and the compose it's currently deciding whether to create a validation event for: if it's been more than 3 days but less than 14 days since the last event, it will create a new event *if* any important package's version changed. WORKAROUND: Looking back on the history of this, I don't think anything's actually using it right now. There is an ugly alternative version of this one, too, which scrapes dl.fedoraproject.org's HTML output (told you it was ugly!). I initially replaced that version with the PDC one for some compose types, but then ran into problems with that, and ultimately decided to provide both side-by-side; I think relvalconsumer is the only thing that actually uses this feature, and it currently uses the ugly HTML scraping version, not the PDC version. I probably meant to try and make it use the PDC version but never got around to it. The ugly version is working okay in practice, so I suppose the workaround here would just be to drop the
Re: Fedora rawhide compose report: 20230911.n.1 changes
On Mon, Sep 11, 2023 at 3:16 PM Fedora Rawhide Report wrote: > = ADDED PACKAGES = [snip] > Package: python-sphinx_reredirects-0.1.2-2.fc40 > Summary: Handles redirects for moved pages in Sphinx documentation projects > RPMs:python3-sphinx_reredirects > Size:21.18 KiB This appears to be a duplicate of the existing python-sphinx-reredirects package. Please retire this one. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230911.n.1 changes
OLD: Fedora-Rawhide-20230910.n.0 NEW: Fedora-Rawhide-20230911.n.1 = SUMMARY = Added images:8 Dropped images: 1 Added packages: 3 Dropped packages:0 Upgraded packages: 86 Downgraded packages: 0 Size of added packages: 485.92 KiB Size of dropped packages:0 B Size of upgraded packages: 3.03 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.06 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230911.n.1.iso Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20230911.n.1.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230911.n.1.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230911.n.1.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230911.n.1.iso Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230911.n.1.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230911.n.1.iso Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20230911.n.1.iso = DROPPED IMAGES = Image: Onyx dvd-ostree x86_64 Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20230910.n.0.iso = ADDED PACKAGES = Package: plog-1.1.10-1.fc40 Summary: Portable, simple and extensible C++ logging library RPMs:plog-devel Size:399.91 KiB Package: python-sphinx_reredirects-0.1.2-2.fc40 Summary: Handles redirects for moved pages in Sphinx documentation projects RPMs:python3-sphinx_reredirects Size:21.18 KiB Package: python-svg2tikz-2.1.0-1.fc40 Summary: Convert SVG to TikZ/PGF code RPMs:inkscape-svg2tikz python3-svg2tikz Size:64.82 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 64tass-1.59.3120-1.fc40 Old package: 64tass-1.58.2974-3.fc39 Summary: 6502 assembler RPMs: 64tass Size: 1.49 MiB Size change: 46.73 KiB Changelog: * Mon Sep 11 2023 Filipe Rosset - 1.59.3120-1 - update to 64tass-1.59.3120 fixes rhbz#2238230 Package: acl-2.3.1-9.fc40 Old package: acl-2.3.1-8.fc39 Summary: Access control list utilities RPMs: acl libacl libacl-devel Size: 796.85 KiB Size change: 7.48 KiB Changelog: * Mon Sep 11 2023 Temuri Doghonadze - 2.3.1-9 - Backport Georgian locale from git - Note, it will not be needed after release of new version of acl Package: atomes-1.1.12-1.fc40 Old package: atomes-1.1.11-9.fc39 Summary: An atomistic toolbox RPMs: atomes Size: 9.20 MiB Size change: 14.11 KiB Changelog: * Mon Sep 11 2023 S??bastien Le Roux - 1.1.12-1 - Several bug corrections and improvements (see: https://github.com/Slookeur/Atomes-GNU/releases/tag/v1.1.12) Package: attr-2.5.1-9.fc40 Old package: attr-2.5.1-8.fc39 Summary: Utilities for managing filesystem extended attributes RPMs: attr libattr libattr-devel Size: 474.07 KiB Size change: 6.74 KiB Changelog: * Fri Sep 08 2023 Temuri Doghonadze - 2.5.1-9 - Backporting Georgian language for RHEL10 until next release of attr Package: awscli2-2.13.17-1.fc40 Old package: awscli2-2.13.12-1.fc40 Summary: Universal Command Line Environment for AWS, version 2 RPMs: awscli2 Size: 11.75 MiB Size change: 52.47 KiB Changelog: * Sat Sep 09 2023 Packit - 2.13.17-1 - [packit] 2.13.17 upstream release Package: blueman-1:2.3.5-6.fc40 Old package: blueman-1:2.3.5-5.fc39 Summary: GTK+ Bluetooth Manager RPMs: blueman blueman-caja blueman-nautilus blueman-nemo Size: 6.26 MiB Size change: 34.71 KiB Changelog: * Sun Sep 10 2023 Artur Frenszek-Iwicki - 1:2.3.5-6 - Fix nautilus integration (rhbz#2238225) Package: c-icap-0.5.11-16.20230905git49b6801.fc40 Old package: c-icap-0.5.11-15.20230621git7a7b929.fc40 Summary: An implementation of an ICAP server RPMs: c-icap c-icap-devel c-icap-libs c-icap-perl Size: 1.90 MiB Size change: 14.61 KiB Changelog: * Sun Sep 10 2023 Simone Caronni - 0.5.11-16.20230905git49b6801 - Update to latest snapshot. Package: cppcheck-2.12.0-1.fc40 Old package: cppcheck-2.11-2.fc39 Summary: Tool for static C/C++ code analysis RPMs: cppcheck cppcheck-gui cppcheck-htmlreport Size: 18.50 MiB Size change: 409.55 KiB Changelog: * Sun Sep 10 2023 Wolfgang St??ggl - 2.12.0-1 - Update to 2.12.0 (#2165211) Package: e16-1.0.28-1.fc40 Old package: e16-1.0.23-6.fc39 Summary: The Enlightenment window manager, DR16 RPMs: e16 Size: 4.40 MiB Size change: 18.47 KiB Changelog: * Sun Sep 10 2023 Terje Rosten - 1.0.28-1 - 1.0.28
[Bug 2238414] perl-Mojolicious-9.34 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238414 Emmanuel Seyman changed: What|Removed |Added Resolution|--- |RAWHIDE Fixed In Version||perl-Mojolicious-9.34-1.fc4 ||0 Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Last Closed||2023-09-11 21:09:20 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2287937 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238414 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238414%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238261] perl-Mail-DKIM-1.20230911 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238261 Emmanuel Seyman changed: What|Removed |Added Fixed In Version||perl-Mail-DKIM-1.20230911-1 ||.fc40 Resolution|--- |RAWHIDE Status|NEW |CLOSED Last Closed||2023-09-11 21:08:24 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2287935 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238261 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238261%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238020] perl-HTTP-BrowserDetect-3.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238020 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Fixed In Version||perl-HTTP-BrowserDetect-3.3 ||9-1.fc40 Doc Type|--- |If docs needed, set a value Last Closed||2023-09-11 21:07:04 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2287901 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238020 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238020%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238186] perl-JSON-Any-1.40 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238186 Emmanuel Seyman changed: What|Removed |Added Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Fixed In Version||perl-JSON-Any-1.40-1.fc40 Last Closed||2023-09-11 21:07:40 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2287912 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238186 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238186%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
> Am 11.09.2023 um 18:14 schrieb Neal Gompa : > > What it did do was make my life harder trying to build up and sustain > the pagure contributor community. > > Thankfully, pagure development *isn't* dead and after the mailman > stack stuff is sorted out, I can go back to working on Pagure 6.0. Maybe a bit OT: I like that and I am very glad to hear that (the continuous development of pagure, not the harder life). Pagure is very efficient and straightforward to use. And at least for what I do for Fedora, it is (almost) perfect and Gitlab a pain the … I’m not a python developer, but maybe I can help otherwise (testing, documentation,…) -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238421] New: perl-version-0.9930 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238421 Bug ID: 2238421 Summary: perl-version-0.9930 is available Product: Fedora Version: rawhide Status: NEW Component: perl-version Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.9930 Upstream release that is considered latest: 0.9930 Current version/release in rawhide: 0.99.29-501.fc39 URL: http://search.cpan.org/dist/version/ 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://docs.fedoraproject.org/en-US/package-maintainers/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/3551/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-version -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238421 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238421%23c0 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Anyone interested in packaging + maintaining the nimble language?
Hi Ankur, On Sun, Sep 10, 2023 at 10:04:18PM +0100, Ankur Sinha wrote: > Hi folks, > > I have a package that has begun to use the nimble language in its new > version: > https://bugzilla.redhat.com/show_bug.cgi?id=2181693 > https://nim-lang.org/ > > It isn't packaged for Fedora yet, though. Is anyone using it, and would > like to package + maintain it for Fedora? > This looks like an interesting language, so #whynot (famous last words). Would you be interested in co-maintaining? Going to try and beat this into shape for packaging, I've already discovered that the official tarball is missing files needed for rebuilding from source :( https://github.com/nim-lang/Nim/issues/22692 Best regards, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238414] New: perl-Mojolicious-9.34 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238414 Bug ID: 2238414 Summary: perl-Mojolicious-9.34 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com, yan...@declera.com Target Milestone: --- Classification: Fedora Releases retrieved: 9.34 Upstream release that is considered latest: 9.34 Current version/release in rawhide: 9.33-2.fc39 URL: https://metacpan.org/release/Mojolicious 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://docs.fedoraproject.org/en-US/package-maintainers/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/5966/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Mojolicious -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238414 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238414%23c0 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal:PHP 8.3 (Self Contained)
The discussion thread to provide feedback on this proposed change can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-php-8-3-self-contained/89611/1 ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal:PHP 8.3 (Self Contained)
The discussion thread to provide feedback on this proposed change can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-php-8-3-self-contained/89611/1 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal:PHP 8.3 (Self Contained)
Wiki https://fedoraproject.org/wiki/Changes/php83 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the PHP stack in Fedora to the latest version 8.3.x == Owner == * Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]] * Email: remi at fedoraproject dot org == Current status == * A testing SCL and a testing module are available in my [https://blog.remirepo.net/post/2023/08/31/PHP-on-the-road-to-the-8.3.0-release repository] * List of [https://github.com/remicollet/remirepo/issues/237 extensions compatibility list] * [https://wiki.php.net/todo/php83 Upstream schedule for 8.3] First RC is planed for August 31th, GA is planed for November 23th. == Detailed Description == Update the PHP stack in Fedora to latest version 8.3.x. Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice for some years: * 2 Fedora cycles for each PHP minor release (exceptions below) * 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time before next major * 1 Fedora cycle for first major (e.g. 7.0 or 8.0) Fedora 37 has PHP 8.1, Fedora 38 and 39 have PHP 8.2. == Benefit to Fedora == Provides the latest PHP version to developers and system administrators. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * The PHP stack (extensions and libraries) are monitored by Koschei, see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started Koschei PHP group] * install and play with your web applications == User Experience == Developers and system administrators will have the great benefit or running the latest PHP version. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == * [https://raw.githubusercontent.com/php/php-src/PHP-8.3/UPGRADING UPGRADING] * [https://raw.githubusercontent.com/php/php-src/PHP-8.3/UPGRADING.INTERNALS UPGRADING.INTERNALS] == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal:Passim Peer-to-Peer Metadata (Self Contained)
The discussion thread for feedback on this change proposal can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-passim-peer-to-peer-metadata-self-contained/89608/1 ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal:PHP 8.3 (Self Contained)
Wiki https://fedoraproject.org/wiki/Changes/php83 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the PHP stack in Fedora to the latest version 8.3.x == Owner == * Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]] * Email: remi at fedoraproject dot org == Current status == * A testing SCL and a testing module are available in my [https://blog.remirepo.net/post/2023/08/31/PHP-on-the-road-to-the-8.3.0-release repository] * List of [https://github.com/remicollet/remirepo/issues/237 extensions compatibility list] * [https://wiki.php.net/todo/php83 Upstream schedule for 8.3] First RC is planed for August 31th, GA is planed for November 23th. == Detailed Description == Update the PHP stack in Fedora to latest version 8.3.x. Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice for some years: * 2 Fedora cycles for each PHP minor release (exceptions below) * 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time before next major * 1 Fedora cycle for first major (e.g. 7.0 or 8.0) Fedora 37 has PHP 8.1, Fedora 38 and 39 have PHP 8.2. == Benefit to Fedora == Provides the latest PHP version to developers and system administrators. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * The PHP stack (extensions and libraries) are monitored by Koschei, see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started Koschei PHP group] * install and play with your web applications == User Experience == Developers and system administrators will have the great benefit or running the latest PHP version. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == * [https://raw.githubusercontent.com/php/php-src/PHP-8.3/UPGRADING UPGRADING] * [https://raw.githubusercontent.com/php/php-src/PHP-8.3/UPGRADING.INTERNALS UPGRADING.INTERNALS] == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal:Passim Peer-to-Peer Metadata (Self Contained)
The discussion thread for feedback on this change proposal can be found here https://discussion.fedoraproject.org/t/f40-change-proposal-passim-peer-to-peer-metadata-self-contained/89608/1 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal:Switch pam_userdb from BerkeleyDB to GDBM (System Wide)
The discussion thread is now available for feedback on this proposed change here https://discussion.fedoraproject.org/t/f40-change-proposal-switch-pam-userdb-from-berkeleydb-to-gdbm-system-wide/89606/1 ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal:Passim Peer-to-Peer Metadata (Self Contained)
Wiki https://fedoraproject.org/wiki/Changes/Passim_P2P_Metadata This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Passim is a local caching server that broadcasts specific shared metadata to other clients on your local network to reduce the amount of duplicate data downloaded from the internet. == Owner == * Name: [[User:rhughes| Richard Hughes]] * Email: rich...@hughsie.com == Detailed Description == Much of the software running on your computer that connects to other systems over the Internet needs to periodically download metadata or information needed to perform other requests. Everybody downloads the same file from a CDN, and although a CDN is not super-expensive, it's certainly not free. Everybody on your current network (perhaps thousands of users) has to download the same 1MB blob of metadata from a CDN over a perhaps-expensive internet link. What if we could download the file from the CDN on one machine, and the next machine on the local network that needs it instead downloads it from the first machine? We could put a limit on the number of times it can be shared, and the maximum age so that we don't store yesterday's metadata forever, and so that we don't turn a ThinkPad X220 into a machine distributing 1Gb/s to every other machine in the office. We could cut the CDN traffic by at least one order of magnitude, but possibly much more. This is better for the person paying the cloud bill, the person paying for the internet connection, and the planet as a whole. == Feedback == IPFS is an existing project that's existed for many years and allows sharing with other users not on your local network. It's not packaged in any distributions and not trivial to install correctly. Its main drawback is that it requires an internet to IPFS "gateway" which costs a large amount of money for the LVFS, and that it's not EAR/ITAR compliant. I've asked for feedback already on fedora-devel and have already started making changes and suggestions from that discussion -- for instance splitting out a -libs subpackage. See https://www.spinics.net/lists/fedora-devel/msg315078.html for the discussion. == Benefit to Fedora == Fedora will consume less bandwidth when checking for firmware updates. Per user there is only a 2MB/day saving, but for millions of Fedora users this adds up to a huge amount of saved data (and money) globally. == Scope == The code is already written, tested and ready to go. The passim package is already included in Fedora (although not installed by default) and fwupd needs an upstream release which includes this functionality -- which is scheduled for 2 weeks time. == Upgrade/compatibility impact == Old versions of fwupd will be updated and start sharing metadata with other local users with no changes required. == How To Test == Install two physical machines or VMs with Fedora 40 that are both on the local network. Run `fwupdmgr refresh` on the first, and observe that `passim dump` or `https://localhost:27500/` lists the published metadata file . Then run `fwupdmgr refresh --verbose` on the second machine and see that the file is downloaded from https://localhost:27500 rather than `cdn.fwupd.org`. Avahi needs to be enabled and running, as does `passimd` although both are autostarted as required. == User Experience == Each user will use 2MB less bandwidth per day when there are other users on the local network with the same metadata file. There is no user-visible difference to any operation. == Dependencies == None; fwupd will recommend passim to be installed by default and autolaunch it as required. == Contingency Plan == Change `Recommends: passim` to `Suggests: passim` in the `fwupd.spec` file so that it's not autoinstalled by default. In this case fwupd will fall back to downloading from the CDN every day. == Documentation == * https://github.com/hughsie/passim/blob/main/README.md == Release Notes == Fedora now uses a peer-to-peer service called Passim to reduce the amount of bandwidth used when downloading metadata. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel
Re: F40 Change Proposal:Switch pam_userdb from BerkeleyDB to GDBM (System Wide)
The discussion thread is now available for feedback on this proposed change here https://discussion.fedoraproject.org/t/f40-change-proposal-switch-pam-userdb-from-berkeleydb-to-gdbm-system-wide/89606/1 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal:Passim Peer-to-Peer Metadata (Self Contained)
Wiki https://fedoraproject.org/wiki/Changes/Passim_P2P_Metadata This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Passim is a local caching server that broadcasts specific shared metadata to other clients on your local network to reduce the amount of duplicate data downloaded from the internet. == Owner == * Name: [[User:rhughes| Richard Hughes]] * Email: rich...@hughsie.com == Detailed Description == Much of the software running on your computer that connects to other systems over the Internet needs to periodically download metadata or information needed to perform other requests. Everybody downloads the same file from a CDN, and although a CDN is not super-expensive, it's certainly not free. Everybody on your current network (perhaps thousands of users) has to download the same 1MB blob of metadata from a CDN over a perhaps-expensive internet link. What if we could download the file from the CDN on one machine, and the next machine on the local network that needs it instead downloads it from the first machine? We could put a limit on the number of times it can be shared, and the maximum age so that we don't store yesterday's metadata forever, and so that we don't turn a ThinkPad X220 into a machine distributing 1Gb/s to every other machine in the office. We could cut the CDN traffic by at least one order of magnitude, but possibly much more. This is better for the person paying the cloud bill, the person paying for the internet connection, and the planet as a whole. == Feedback == IPFS is an existing project that's existed for many years and allows sharing with other users not on your local network. It's not packaged in any distributions and not trivial to install correctly. Its main drawback is that it requires an internet to IPFS "gateway" which costs a large amount of money for the LVFS, and that it's not EAR/ITAR compliant. I've asked for feedback already on fedora-devel and have already started making changes and suggestions from that discussion -- for instance splitting out a -libs subpackage. See https://www.spinics.net/lists/fedora-devel/msg315078.html for the discussion. == Benefit to Fedora == Fedora will consume less bandwidth when checking for firmware updates. Per user there is only a 2MB/day saving, but for millions of Fedora users this adds up to a huge amount of saved data (and money) globally. == Scope == The code is already written, tested and ready to go. The passim package is already included in Fedora (although not installed by default) and fwupd needs an upstream release which includes this functionality -- which is scheduled for 2 weeks time. == Upgrade/compatibility impact == Old versions of fwupd will be updated and start sharing metadata with other local users with no changes required. == How To Test == Install two physical machines or VMs with Fedora 40 that are both on the local network. Run `fwupdmgr refresh` on the first, and observe that `passim dump` or `https://localhost:27500/` lists the published metadata file . Then run `fwupdmgr refresh --verbose` on the second machine and see that the file is downloaded from https://localhost:27500 rather than `cdn.fwupd.org`. Avahi needs to be enabled and running, as does `passimd` although both are autostarted as required. == User Experience == Each user will use 2MB less bandwidth per day when there are other users on the local network with the same metadata file. There is no user-visible difference to any operation. == Dependencies == None; fwupd will recommend passim to be installed by default and autolaunch it as required. == Contingency Plan == Change `Recommends: passim` to `Suggests: passim` in the `fwupd.spec` file so that it's not autoinstalled by default. In this case fwupd will fall back to downloading from the CDN every day. == Documentation == * https://github.com/hughsie/passim/blob/main/README.md == Release Notes == Fedora now uses a peer-to-peer service called Passim to reduce the amount of bandwidth used when downloading metadata. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal:Switch pam_userdb from BerkeleyDB to GDBM (System Wide)
Wiki https://fedoraproject.org/wiki/Changes/PamBerkeleyDBtoGdbm == Summary == pam_userdb was built with support for BerkeleyDB, but this project is no longer maintained as open source, so it is replaced by GDBM. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]] [[User:fjanus| Filip Janus]] * Email: ipedr...@redhat.com fja...@redhat.com == Detailed Description == Currently, the Fedora provided BerkeleyDB versions is 5.x, which has been unmaintained upstream for several years. BerkeleyDB v6.x is license incompatible, so moving to that version is not an option. The proposal is to switch to GDBM, which has upstream support and whose license is compatible with Fedora. == Feedback == This proposal contains manual steps to be executed by system administrators in the upgrade path. It is a risky point, as it relies on sysadmins reading the documentation, but it's the best solution so far. The database location is defined in the PAM stack, and the system administrator can set it to any value. Therefore, the only way to automate this would be to embed the database port in the PAM module code. But the port should be handled by libdb as this will allow it to concentrate all the effort on a single binary, which will do this job for other packages as well. An [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HXK2RS7IBCRRYAQEYP2P66T6W4ONFBAZ/ email thread] was opened in Fedora devel to discuss this topic. Steve Grubb mentioned that this approach was used in the past to update other PAM modules. So even if the solution is not ideal, the best approach is to document the database porting process and let the system administrator run it manually. == Benefit to Fedora == * This change uses a database that is Fedora license compatible. * This changes uses an upstream maintained database version, with new features and bug fixing. pam_userdb controls user authentication, and a bug in the database could lead to a security vulnerability. == Scope == * Proposal owners: ** libdb includes a new subpackage libdb-convert-util, that provides db_converter, a program to port a BerkeleyDB database to GDBM. ** Change PAM database build option to GDBM. * Other developers: N/A * Release engineering: https://pagure.io/releng/issue/11649 * Policies and guidelines: Yes. Opened a [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 MR in the System Administrator’s Guide] with the documentation proposal. * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == === Upgrade === * If the pam_userdb module is used by the system, then the user/sysadmin will have to run the conversion tool. This can't be done automatically because the database location is configurable, and the conversion tool will need manual intervention. === Compatibility === * pam_userdb module is mainly used in vsftpd environments. If this module is used by the system and the database isn't converted, then the user won't be able to authenticate in vsftpd environments. The user would still be able to authenticate using other methods (i.e. su, ssh) and run the conversion tool. == How To Test == * Run `db_converter` to convert the database. Example `db_converter --src /etc/vsftpd/login.db --dest /etc/vsftpd/login.gdbm` * vsftpd login * Check that the user is authenticated == User Experience == Users won't experience any change. == Dependencies == vsftpd depends on this change, but nothing needs to be done in this package. == Contingency Plan == * Contingency mechanism: Postpone to the next release. * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 MR in the System Administrator’s Guide] with the documentation proposal. == Release Notes == pam_userdb switches database provider to GDM. [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 Instructions on how to update in the System Administrator’s Guide] -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora
Re: F40 Change Proposal: Dropping sshd.socket file (Self Contained)
The discussion thread is now available for feedback at https://discussion.fedoraproject.org/t/f40-change-proposal-drop-sshd-socket-self-contained/89604/1 ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal:Switch pam_userdb from BerkeleyDB to GDBM (System Wide)
Wiki https://fedoraproject.org/wiki/Changes/PamBerkeleyDBtoGdbm == Summary == pam_userdb was built with support for BerkeleyDB, but this project is no longer maintained as open source, so it is replaced by GDBM. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]] [[User:fjanus| Filip Janus]] * Email: ipedr...@redhat.com fja...@redhat.com == Detailed Description == Currently, the Fedora provided BerkeleyDB versions is 5.x, which has been unmaintained upstream for several years. BerkeleyDB v6.x is license incompatible, so moving to that version is not an option. The proposal is to switch to GDBM, which has upstream support and whose license is compatible with Fedora. == Feedback == This proposal contains manual steps to be executed by system administrators in the upgrade path. It is a risky point, as it relies on sysadmins reading the documentation, but it's the best solution so far. The database location is defined in the PAM stack, and the system administrator can set it to any value. Therefore, the only way to automate this would be to embed the database port in the PAM module code. But the port should be handled by libdb as this will allow it to concentrate all the effort on a single binary, which will do this job for other packages as well. An [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/HXK2RS7IBCRRYAQEYP2P66T6W4ONFBAZ/ email thread] was opened in Fedora devel to discuss this topic. Steve Grubb mentioned that this approach was used in the past to update other PAM modules. So even if the solution is not ideal, the best approach is to document the database porting process and let the system administrator run it manually. == Benefit to Fedora == * This change uses a database that is Fedora license compatible. * This changes uses an upstream maintained database version, with new features and bug fixing. pam_userdb controls user authentication, and a bug in the database could lead to a security vulnerability. == Scope == * Proposal owners: ** libdb includes a new subpackage libdb-convert-util, that provides db_converter, a program to port a BerkeleyDB database to GDBM. ** Change PAM database build option to GDBM. * Other developers: N/A * Release engineering: https://pagure.io/releng/issue/11649 * Policies and guidelines: Yes. Opened a [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 MR in the System Administrator’s Guide] with the documentation proposal. * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == === Upgrade === * If the pam_userdb module is used by the system, then the user/sysadmin will have to run the conversion tool. This can't be done automatically because the database location is configurable, and the conversion tool will need manual intervention. === Compatibility === * pam_userdb module is mainly used in vsftpd environments. If this module is used by the system and the database isn't converted, then the user won't be able to authenticate in vsftpd environments. The user would still be able to authenticate using other methods (i.e. su, ssh) and run the conversion tool. == How To Test == * Run `db_converter` to convert the database. Example `db_converter --src /etc/vsftpd/login.db --dest /etc/vsftpd/login.gdbm` * vsftpd login * Check that the user is authenticated == User Experience == Users won't experience any change. == Dependencies == vsftpd depends on this change, but nothing needs to be done in this package. == Contingency Plan == * Contingency mechanism: Postpone to the next release. * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 MR in the System Administrator’s Guide] with the documentation proposal. == Release Notes == pam_userdb switches database provider to GDM. [https://gitlab.com/fedora/docs/fedora-linux-documentation/fedora-linux-sysadmin-guide/-/merge_requests/14 Instructions on how to update in the System Administrator’s Guide] -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Dropping sshd.socket file (Self Contained)
The discussion thread is now available for feedback at https://discussion.fedoraproject.org/t/f40-change-proposal-drop-sshd-socket-self-contained/89604/1 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
On Mon, Sep 11, 2023 at 03:08:50PM +0200, Tomas Hrcka wrote: > Sorry for the confusion with work that is already done, > We can drop the critpath thanks Adam! > > > As it goes for EoL and package retirement we for the past few releases we > are saving EOL date in bodhi. > So getting EOL for specific release is not a problem once the release is > out. yeah, the reason we needed it in pdc before was stream branches. I think once flatpaks are moved to the new setup we won't have any _new_ stream branches. However, if we are going to support updating modules for f37/f38, we may need to figure out something there... > > For storing the orphaning reason and other potential metadata. We can store > some of it in git in form of notes on branches not necessarily in > pagure-disgit specific code-base. yeah, I think moving some of this that makes sense into git is reasonable. > > With toddlers i think the path is clear we need to use bodhi as a source of > truth about releases. > Similar work as on toddlers will need to be done on mdapi > > For the compose metadata we can store the the json blobs on fedorapeople > for now and search for some stable place. I don't think we should use fedorapeople for anything like this. If we need just a space we could use /pub/alt/something/ ? These are the things that fedfind/qa users? Do we have examples of this data? Thanks for working on this! kevin -- > On Wed, Sep 6, 2023 at 12:23 PM Pierre-Yves Chibon > wrote: > > > On Tue, Sep 05, 2023 at 11:35:19AM -0700, Kevin Fenzi wrote: > > > On Mon, Sep 04, 2023 at 04:51:22PM +0200, Tomas Hrcka wrote: > > > > Hello all, it took us a few years but we are finally getting rid of > > the PDC > > > > project. Thanks to the ARC research we identified use cases in our > > tooling > > > > and proposed solution. > > > > > > > > The essential functionalities currently provided by PDC will be > > > > re-implemented in other applications within our release > > infrastructure, as > > > > there are no immediate plans for their replacement and are currently > > > > maintained > > > > > > > > This work is anticipated to span several months for completion. > > However, > > > > before we embark on this endeavor, > > > > > > > > we would like to proactively share our proposed solution with all of > > you > > > > and gather your valuable feedback. > > > > > > > > Below, we outline our strategy to preserve the core functionality of > > PDC by > > > > leveraging existing applications within our ecosystem. > > > > > > > > Current uses of PDC: > > > > > > > > Currently, we rely on the Package Database (PDC) for various data > > > > management tasks, including: > > > > > > > > > > > >1. > > > > > > > >Critical Path Package Tracking: Bodhi leverages PDC to track > > packages on > > > >the critical path. > > > > > > As Adam mentioned this is already not in pdc. ;) > > > > > > >2. > > > > > > > >Retirement of Packages and Service Level Agreements (SLAs): PDC > > assists > > > >in managing the retirement of packages and their associated SLAs. > > > > > > Yeah. The super big one is that its queried from a git commit hook for > > > all src.fedoraproject.org git commits. Right now if pdc is down, no one > > > could commit anything. > > > > > > > > > >3. > > > > > > > >Metadata for Nightly Composes: Our Release Engineering and Fedora > > > >Quality Assurance teams rely on PDC for metadata related to nightly > > > >composes. > > > > > > > > > > > > More info on the usage can be found here: > > > > https://fedora-arc.readthedocs.io/en/latest/pdc/users.html > > > > > > mass rebuild of modules can be dropped. ;) > > > > > > fedscm-admin is now the scm requests toddler. It still uses pdc tho > > > of course. > > > > > > > Specific Endpoints in Use: > > > > > > ...snip... > > > > > > > Upcoming Changes > > > > > > > > Bodhi: > > > > > > > > Bodhi will assume responsibility for the following tasks, reducing our > > > > reliance on PDC: > > > > > > > > /rest_api/v1/releases/: Bodhi will now manage release-related data. > > > > > > Do note that bodhi still has a window after we are 'go' for a relase > > > where it thinks it's released, but it's not yet. We probibly need to > > > address this if we are moving this to bodhi. > > > > > > > /rest_api/v1/component-branches/: Specifically, Bodhi will handle the > > > > critical-path flag. > > > > > > Already done. > > > > > > ...snip... > > > > > > > > Pagure-dist-git: > > > > > > > > Pagure-dist-git will take over several responsibilities from PDC, > > including: > > > > > > > > /rest_api/v1/product-versions > > > > > > > > /rest_api/v1/global-components > > > > > > > > /rest_api/v1/component-branches/ > > > > > > > > /rest_api/v1/component-branch-slas/ > > > > > > > > Pagure already has a robust database of global components > > (repositories) > > > > and product versions (repository branches). > > > > > > > > It utilizes the PDC API to query component branches when a package
F40 Change Proposal: Dropping sshd.socket file (Self Contained)
== Summary == The sshd.socket behavior may cause the remote DoS and require a manual intervention to make the server accepting the ssh connections back. sshd.service doesn't have these downsides == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == A while ago, a dropping the sshd.socket from the openssh package was suggested in [https://bugzilla.redhat.com/show_bug.cgi?id=2025716 BZ#2025716] as there are several shortcomings with this approach that could lead to situations where users would lose access to a system while under DoS or memory pressure. This change was implemented in rawhide & f39 and discussed on the devel list in a [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O6V7ZH3BMCWOREDWXOIAPUG7PGMWIBVR/#BQPRQLXPBKPQL7KR62GUR5H7EEAS2CUN thread]. This change was reverted in f39 according to the [https://pagure.io/fesco/issue/3062 FESCO decision]. == Feedback == The change as implemented does not include a migration path for existing users of the sshd.socket unit to the sshd.service unit. We need some migration path, also suitable for OSTree This means that systems updating from 38 to 39 and relying on sshd.socket for openssh access to the system will end up unreachable via SSH. This is notably important for Fedora CoreOS where we will automatically update systems to the next Fedora version shortly after the release: https://github.com/coreos/fedora-coreos-tracker/issues/1558 We think this change needs to get more visibility and should go through the change process and be evaluated for inclusion in Fedora 40. See also the mentioned before [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O6V7ZH3BMCWOREDWXOIAPUG7PGMWIBVR/#BQPRQLXPBKPQL7KR62GUR5H7EEAS2CUN thread]. == Benefit to Fedora == This change will prevent remote DoS in the case the sshd.socket is activated. == Scope == * Proposal owners: the migration scriptlet is the best solution. * Other developers: check the dependencies on sshd.socket * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == The worst case the remote access to the system will be lost of sshd.socket is enabled and the system is not switched to using sshd.service before upgrade == How To Test == Enable sshd.socket Upgrade Check remote access over sshd == User Experience == See "Benefit for Fedora" == Dependencies == == Contingency Plan == Reverting the change * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == The change should be mentioned in the Release Notes. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: Dropping sshd.socket file (Self Contained)
== Summary == The sshd.socket behavior may cause the remote DoS and require a manual intervention to make the server accepting the ssh connections back. sshd.service doesn't have these downsides == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == A while ago, a dropping the sshd.socket from the openssh package was suggested in [https://bugzilla.redhat.com/show_bug.cgi?id=2025716 BZ#2025716] as there are several shortcomings with this approach that could lead to situations where users would lose access to a system while under DoS or memory pressure. This change was implemented in rawhide & f39 and discussed on the devel list in a [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/O6V7ZH3BMCWOREDWXOIAPUG7PGMWIBVR/#BQPRQLXPBKPQL7KR62GUR5H7EEAS2CUN thread]. This change was reverted in f39 according to the [https://pagure.io/fesco/issue/3062 FESCO decision]. == Feedback == The change as implemented does not include a migration path for existing users of the sshd.socket unit to the sshd.service unit. We need some migration path, also suitable for OSTree This means that systems updating from 38 to 39 and relying on sshd.socket for openssh access to the system will end up unreachable via SSH. This is notably important for Fedora CoreOS where we will automatically update systems to the next Fedora version shortly after the release: https://github.com/coreos/fedora-coreos-tracker/issues/1558 We think this change needs to get more visibility and should go through the change process and be evaluated for inclusion in Fedora 40. See also the mentioned before [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/O6V7ZH3BMCWOREDWXOIAPUG7PGMWIBVR/#BQPRQLXPBKPQL7KR62GUR5H7EEAS2CUN thread]. == Benefit to Fedora == This change will prevent remote DoS in the case the sshd.socket is activated. == Scope == * Proposal owners: the migration scriptlet is the best solution. * Other developers: check the dependencies on sshd.socket * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == The worst case the remote access to the system will be lost of sshd.socket is enabled and the system is not switched to using sshd.service before upgrade == How To Test == Enable sshd.socket Upgrade Check remote access over sshd == User Experience == See "Benefit for Fedora" == Dependencies == == Contingency Plan == Reverting the change * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == The change should be mentioned in the Release Notes. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 11:43:55AM -0400, Solomon Peachy via devel wrote: > On Mon, Sep 11, 2023 at 07:58:03AM -0500, Michael Catanzaro wrote: > > No? All of our packages are on https://src.fedoraproject.org/ and our > > Fedora-specific source code goes on https://pagure.io/. These are both > > Pagure, not GitLab. It is open source. > > https://lwn.net/Articles/817426/ > https://communityblog.fedoraproject.org/making-a-git-forge-decision/ > > "After evaluating over 300 user stories from multiple stakeholders, the > Community Platform Engineering (CPE) team have aligned on a decision for > the git forge that CPE will operate for the coming years. We are opting > for GitLab for our dist git and project hosting and will continue to run > pagure.io with community assistance." > > That was back in 2020. Clearly this hasn't happened yet, but there's > been almost no communication about the status of this migration since > then. The way it was presented was that this was already a done deal, > and we could either accept it or GTFO. Well, here's my understanding of things. That decision was made, but then when discussing with gitlab and doublechecking all requirements, we couldn't get something that met all the requirements we had. disclaimer: I was not involved in these talks, nor do I have exact details. I think we need to figure out the way forward, but... I don't think we should do it here and now. Please go test f39. ;) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, 2023-09-11 at 11:43 -0400, Solomon Peachy via devel wrote: > On Mon, Sep 11, 2023 at 07:58:03AM -0500, Michael Catanzaro wrote: > > No? All of our packages are on https://src.fedoraproject.org/ and our > > Fedora-specific source code goes on https://pagure.io/. These are both > > Pagure, not GitLab. It is open source. > > https://lwn.net/Articles/817426/ > https://communityblog.fedoraproject.org/making-a-git-forge-decision/ > > "After evaluating over 300 user stories from multiple stakeholders, the > Community Platform Engineering (CPE) team have aligned on a decision for > the git forge that CPE will operate for the coming years. We are opting > for GitLab for our dist git and project hosting and will continue to run > pagure.io with community assistance." > > That was back in 2020. Clearly this hasn't happened yet, but there's > been almost no communication about the status of this migration since > then. The way it was presented was that this was already a done deal, > and we could either accept it or GTFO. IIRC it was a condition of that proposal that we wind up on a hosted version of the *open source* release of gitlab, which is something we managed to talk gitlab into doing for us. IMBW, though, it was a while ago. The status of that plan has been kinda up in the air for a while, AIUI. For a while it was an ENOTIME thing, then there was talk about getting around to actually doing it, then at Flock I heard rumours that somebody's interested in picking up Pagure maintenance again, so...*shrug emoji* -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Drop Delta RPMs (System-Wide)
The discussion thread is now available a thttps://discussion.fedoraproject.org/t/f40-change-proposal-drop-delta-rpms/89601/1 for feedback ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 11:44 AM Solomon Peachy via devel wrote: > > On Mon, Sep 11, 2023 at 07:58:03AM -0500, Michael Catanzaro wrote: > > No? All of our packages are on https://src.fedoraproject.org/ and our > > Fedora-specific source code goes on https://pagure.io/. These are both > > Pagure, not GitLab. It is open source. > > https://lwn.net/Articles/817426/ > https://communityblog.fedoraproject.org/making-a-git-forge-decision/ > > "After evaluating over 300 user stories from multiple stakeholders, the > Community Platform Engineering (CPE) team have aligned on a decision for > the git forge that CPE will operate for the coming years. We are opting > for GitLab for our dist git and project hosting and will continue to run > pagure.io with community assistance." > > That was back in 2020. Clearly this hasn't happened yet, but there's > been almost no communication about the status of this migration since > then. The way it was presented was that this was already a done deal, > and we could either accept it or GTFO. > That was a sham decision process and the resulting thread from that demonstrated that in spades. It almost entirely failed to consider what Fedora needed, does, and how the project currently works. What it did do was make my life harder trying to build up and sustain the pagure contributor community. Thankfully, pagure development *isn't* dead and after the mailman stack stuff is sorted out, I can go back to working on Pagure 6.0. -- 真実はいつも一つ！/ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Drop Delta RPMs (System-Wide)
The discussion thread is now available a thttps://discussion.fedoraproject.org/t/f40-change-proposal-drop-delta-rpms/89601/1 for feedback ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238253] perl-CBOR-XS-1.87 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238253 Petr Pisar changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |RAWHIDE Last Closed||2023-09-11 16:13:19 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238253 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
F40 Change Proposal: Drop Delta RPMs (System-Wide)
Wiki https://fedoraproject.org/wiki/Changes/Drop_Delta_RPMs
== Summary ==
Stop producing Delta RPMs during the compose process, and disable deltarpm
support in the default configuration of DNF / DNF5.
== Owner ==
* Name: [[User:decathorpe| Fabio Valentini]]
* Email: decatho...@gmail.com
* Targeted release:
[https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* [ devel thread]
* FESCo issue:
* Tracker bug:
* Release notes tracker:
== Detailed Description ==
Delta RPMs are an optimization that reduces the amount of data that needs to be
downloaded for package updates, by only downloading the parts of the package
that have changed between the locally installed version and the new version, and
reassembling a complete RPM package for the new version locally.
Due to the way they are generated during the compose process, it is not possible
to produce Delta RPMs for all packages that are involved in an upgrade (since
only one previous version is considered for delta generation). This can lead to
upgrades that involve hundreds of packages, but only a tiny fraction of them (or
none at all) also have appropriate Delta RPMs available in the repository.
Additionally, reconstruction of the new version of the RPM from the currently
installed version and the Delta RPM can fail, causing an additional download of
the complete RPM for the new version, wasting bandwidth.
On top of these issues, the presence of Delta RPMs in package repositories also
inflates the size of the repository metadata, which needs to be downloaded by
all users, whether the actual upgrade involves Delta RPMs or not. This most
affects users that upgrade via GUI utilities like GNOME Software - because the
PackageKit libdnf backend has no support for Delta RPMs at all, or users of
OSTree based variants / spins of Fedora - where Delta RPMs are not used either.
According to early feedback from Release Engineering, it looks like it will not
be feasible to address the shortcomings of Delta RPMs as they are currently
implemented, and since they often no longer result in a net reduction in
download sizes for upgrades, this Change proposes both to disable the generation
of DeltaRPMs during the compose process, and to disable the deltarpm support in
dnf / dnf5 by default.
=== Some statistics ===
I have collected data for system upgrades with dnf across three different Fedora
installs (Fedora 38 Workstation, Fedora 37 KDE, and Fedora 38 KDE, respectively,
all with the "updates-testing" repository enabled) for two months, with varying
intervals between upgrades (between one day and one month) in an attempt to
capture different situations. To summarize the results:
* Delta RPMs were available for only 25 out of 42 upgrades
* Delta RPMs saved 7.5 MB / 8% of downloads on average
* Delta RPMs saved 22.5 MB of download on average (if there were no failures)
* Delta RPMs wasted 52.7 MB of download on average (if there were failures)
As an anecdote, most of the savings are attributable to one package (firefox).
For reference, the current sizes of repository metadata for Fedora 38 (as of
2023-09-07):
* fedora: 86.8 MB
* updates: 33.2 MB
* updates-testing: 13.3 MB
Note that refreshing repository metadata only causes deltas to be downloaded,
not a full re-download (due to using zchunk for repodata).
== Feedback ==
N/A
== Benefit to Fedora ==
Benefits for Fedora infrastucture:
* simplification of the compose process for "updates" and
"updates-testing" repositories (generation of Delta RPMs will be
skipped)
* reduction of storage requirements in Fedora infrastructure and on
repository mirrors (both due to smaller metadata and dropped Delta
RPMs)
* reduction in bandwith use for repository metadata updates
Benefits for Fedora users:
* more reliable upgrades (i.e. failures to re-assemble RPMs from Delta
RPMs are eliminated)
* reduction in bandwith use for repository metadata updates
* reduction in CPU usage for package upgrades (local re-assembly of
RPMs from on-disk data and Delta RPMs is eliminated)
== Scope ==
* Proposal owners:
** modify compose configuration to skip generation of Delta RPMs for Fedora 40+
** modify default configuration for dnf / dnf5 to disable deltarpm support
* Other developers:
** coordination with dnf and dnf5 developers and / or package maintainers
* Release engineering: [https://pagure.io/releng/issue/11665 releng#11665]
** merge compose changes to skip generation of Delta RPMs for Fedora 40+
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A (no currently active initiatives)
== Upgrade/compatibility impact ==
Installations that get upgraded to Fedora 40 should not be negatively affected
by this Change. The configuration change for dnf / dnf5 will only be
automatically applied if there were no modifications to
F40 Change Proposal: Drop Delta RPMs (System-Wide)
Wiki https://fedoraproject.org/wiki/Changes/Drop_Delta_RPMs
== Summary ==
Stop producing Delta RPMs during the compose process, and disable deltarpm
support in the default configuration of DNF / DNF5.
== Owner ==
* Name: [[User:decathorpe| Fabio Valentini]]
* Email: decatho...@gmail.com
* Targeted release:
[https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]
* Last updated: {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* [ devel thread]
* FESCo issue:
* Tracker bug:
* Release notes tracker:
== Detailed Description ==
Delta RPMs are an optimization that reduces the amount of data that needs to be
downloaded for package updates, by only downloading the parts of the package
that have changed between the locally installed version and the new version, and
reassembling a complete RPM package for the new version locally.
Due to the way they are generated during the compose process, it is not possible
to produce Delta RPMs for all packages that are involved in an upgrade (since
only one previous version is considered for delta generation). This can lead to
upgrades that involve hundreds of packages, but only a tiny fraction of them (or
none at all) also have appropriate Delta RPMs available in the repository.
Additionally, reconstruction of the new version of the RPM from the currently
installed version and the Delta RPM can fail, causing an additional download of
the complete RPM for the new version, wasting bandwidth.
On top of these issues, the presence of Delta RPMs in package repositories also
inflates the size of the repository metadata, which needs to be downloaded by
all users, whether the actual upgrade involves Delta RPMs or not. This most
affects users that upgrade via GUI utilities like GNOME Software - because the
PackageKit libdnf backend has no support for Delta RPMs at all, or users of
OSTree based variants / spins of Fedora - where Delta RPMs are not used either.
According to early feedback from Release Engineering, it looks like it will not
be feasible to address the shortcomings of Delta RPMs as they are currently
implemented, and since they often no longer result in a net reduction in
download sizes for upgrades, this Change proposes both to disable the generation
of DeltaRPMs during the compose process, and to disable the deltarpm support in
dnf / dnf5 by default.
=== Some statistics ===
I have collected data for system upgrades with dnf across three different Fedora
installs (Fedora 38 Workstation, Fedora 37 KDE, and Fedora 38 KDE, respectively,
all with the "updates-testing" repository enabled) for two months, with varying
intervals between upgrades (between one day and one month) in an attempt to
capture different situations. To summarize the results:
* Delta RPMs were available for only 25 out of 42 upgrades
* Delta RPMs saved 7.5 MB / 8% of downloads on average
* Delta RPMs saved 22.5 MB of download on average (if there were no failures)
* Delta RPMs wasted 52.7 MB of download on average (if there were failures)
As an anecdote, most of the savings are attributable to one package (firefox).
For reference, the current sizes of repository metadata for Fedora 38 (as of
2023-09-07):
* fedora: 86.8 MB
* updates: 33.2 MB
* updates-testing: 13.3 MB
Note that refreshing repository metadata only causes deltas to be downloaded,
not a full re-download (due to using zchunk for repodata).
== Feedback ==
N/A
== Benefit to Fedora ==
Benefits for Fedora infrastucture:
* simplification of the compose process for "updates" and
"updates-testing" repositories (generation of Delta RPMs will be
skipped)
* reduction of storage requirements in Fedora infrastructure and on
repository mirrors (both due to smaller metadata and dropped Delta
RPMs)
* reduction in bandwith use for repository metadata updates
Benefits for Fedora users:
* more reliable upgrades (i.e. failures to re-assemble RPMs from Delta
RPMs are eliminated)
* reduction in bandwith use for repository metadata updates
* reduction in CPU usage for package upgrades (local re-assembly of
RPMs from on-disk data and Delta RPMs is eliminated)
== Scope ==
* Proposal owners:
** modify compose configuration to skip generation of Delta RPMs for Fedora 40+
** modify default configuration for dnf / dnf5 to disable deltarpm support
* Other developers:
** coordination with dnf and dnf5 developers and / or package maintainers
* Release engineering: [https://pagure.io/releng/issue/11665 releng#11665]
** merge compose changes to skip generation of Delta RPMs for Fedora 40+
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A (no currently active initiatives)
== Upgrade/compatibility impact ==
Installations that get upgraded to Fedora 40 should not be negatively affected
by this Change. The configuration change for dnf / dnf5 will only be
automatically applied if there were no modifications to
Re: PDC replacement proposal
Il 11/09/23 15:08, Tomas Hrcka ha scritto: > Sorry for the confusion with work that is already done, > We can drop the critpath thanks Adam! > > As it goes for EoL and package retirement we for the past few releases we are > saving EOL date in bodhi. > So getting EOL for specific release is not a problem once the release is out. > > For storing the orphaning reason and other potential metadata. We can store > some of it in git in form of notes on branches not necessarily in > pagure-disgit specific code-base. > > With toddlers i think the path is clear we need to use bodhi as a source of > truth about releases. > Similar work as on toddlers will need to be done on mdapi > > For the compose metadata we can store the the json blobs on fedorapeople for > now and search for some stable place. > -- > > Tomas Hrcka > fas: humaton > libera.CHAT: jednorozec To bring some more information from PDC into Bodhi, I'm working on a couple of PRs which will add the following information to Bodhi output: - New Release property "released_on", to show the final release date of a release - New Release property "setting_status", to show the status of the release between Branched and Final. This will use the 'pre-beta' / 'post-beta' settings in Bodhi with the meaning pre-beta=branched, post-beta=beta. - New Bodhi json endpoint to provide the list of critpath components for each release (this is also available through a pagure repository, but I think it would be nice nonetheless) Let me know if there's some other info which would be nice to migrate from PDC to Bodhi... Mattia___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238253] perl-CBOR-XS-1.87 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238253 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-CBOR-XS-1.87-1.fc40 --- Comment #1 from Petr Pisar --- This version corrected how shared references are handled. That could be perceived as a regression. Hence safer for Rawhide only. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238253 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202238253%23c1 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 07:58:03AM -0500, Michael Catanzaro wrote: > No? All of our packages are on https://src.fedoraproject.org/ and our > Fedora-specific source code goes on https://pagure.io/. These are both > Pagure, not GitLab. It is open source. https://lwn.net/Articles/817426/ https://communityblog.fedoraproject.org/making-a-git-forge-decision/ "After evaluating over 300 user stories from multiple stakeholders, the Community Platform Engineering (CPE) team have aligned on a decision for the git forge that CPE will operate for the coming years. We are opting for GitLab for our dist git and project hosting and will continue to run pagure.io with community assistance." That was back in 2020. Clearly this hasn't happened yet, but there's been almost no communication about the status of this migration since then. The way it was presented was that this was already a done deal, and we could either accept it or GTFO. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
perl-CBOR-XS license corrected
I corrected perl-CBOR-XS license from: GPLv3+ and (BSD or GPLv2+) to: GPL-1.0-or-later AND (BSD-2-Clause OR GPL-2.0-or-later) -- Petr 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238253] perl-CBOR-XS-1.87 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238253 Petr Pisar changed: What|Removed |Added CC|ppi...@redhat.com | Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238253 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2231263] perl-Text-CSV-2.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2231263 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Text-CSV-2.03-1.fc40 Resolution|--- |ERRATA Status|MODIFIED|CLOSED Last Closed||2023-09-11 14:46:35 --- Comment #4 from Fedora Update System --- FEDORA-2023-29fd1d7f95 has been pushed to the Fedora 40 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=2231263 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202231263%23c4 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2231263] perl-Text-CSV-2.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2231263 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2023-29fd1d7f95 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-29fd1d7f95 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2231263 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202231263%23c3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
On Mo, 21.08.23 11:07, Lennart Poettering (mzerq...@0pointer.de) wrote: > On Do, 17.08.23 08:25, Chris Adams (li...@cmadams.net) wrote: > > > Once upon a time, Lennart Poettering said: > > > Yes, and if this is not what you want, then disable the > > > ratelimit. That's what I am saying? > > > > It would be useful for systemd to have "cooldown periods" for things, > > similar to inetd and classic init, where misbehaving things (whether > > services or sockets) were paused for a time (configurable even) and then > > returned to service. AFAIK this is a flaw in general in systemd's > > limits; if something exceeds them, it takes manual intervention to reset > > them. > > There's a TODO list item for that upstream already. > > https://github.com/systemd/systemd/blob/main/TODO#L153 > > Definitely makes sense, and should be very easy to add, the underlying > concepts are all implemented, it's just a matter of exposing this > under new options. I started working on this now: https://github.com/systemd/systemd/pull/29159 Lennart -- Lennart Poettering, Berlin ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224550] Upgrade perl-Net-CLI-Interact to 2.400002
https://bugzilla.redhat.com/show_bug.cgi?id=2224550 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-2023-8a54d72383 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-8a54d72383 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224550 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224550%23c4 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224550] Upgrade perl-Net-CLI-Interact to 2.400002
https://bugzilla.redhat.com/show_bug.cgi?id=2224550 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Net-CLI-Interact-2.400 ||002-1.fc40 Resolution|--- |ERRATA Status|MODIFIED|CLOSED Last Closed||2023-09-11 13:19:34 --- Comment #5 from Fedora Update System --- FEDORA-2023-8a54d72383 has been pushed to the Fedora 40 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=2224550 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224550%23c5 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: PDC replacement proposal
Sorry for the confusion with work that is already done, We can drop the critpath thanks Adam! As it goes for EoL and package retirement we for the past few releases we are saving EOL date in bodhi. So getting EOL for specific release is not a problem once the release is out. For storing the orphaning reason and other potential metadata. We can store some of it in git in form of notes on branches not necessarily in pagure-disgit specific code-base. With toddlers i think the path is clear we need to use bodhi as a source of truth about releases. Similar work as on toddlers will need to be done on mdapi For the compose metadata we can store the the json blobs on fedorapeople for now and search for some stable place. On Wed, Sep 6, 2023 at 12:23 PM Pierre-Yves Chibon wrote: > On Tue, Sep 05, 2023 at 11:35:19AM -0700, Kevin Fenzi wrote: > > On Mon, Sep 04, 2023 at 04:51:22PM +0200, Tomas Hrcka wrote: > > > Hello all, it took us a few years but we are finally getting rid of > the PDC > > > project. Thanks to the ARC research we identified use cases in our > tooling > > > and proposed solution. > > > > > > The essential functionalities currently provided by PDC will be > > > re-implemented in other applications within our release > infrastructure, as > > > there are no immediate plans for their replacement and are currently > > > maintained > > > > > > This work is anticipated to span several months for completion. > However, > > > before we embark on this endeavor, > > > > > > we would like to proactively share our proposed solution with all of > you > > > and gather your valuable feedback. > > > > > > Below, we outline our strategy to preserve the core functionality of > PDC by > > > leveraging existing applications within our ecosystem. > > > > > > Current uses of PDC: > > > > > > Currently, we rely on the Package Database (PDC) for various data > > > management tasks, including: > > > > > > > > >1. > > > > > >Critical Path Package Tracking: Bodhi leverages PDC to track > packages on > > >the critical path. > > > > As Adam mentioned this is already not in pdc. ;) > > > > >2. > > > > > >Retirement of Packages and Service Level Agreements (SLAs): PDC > assists > > >in managing the retirement of packages and their associated SLAs. > > > > Yeah. The super big one is that its queried from a git commit hook for > > all src.fedoraproject.org git commits. Right now if pdc is down, no one > > could commit anything. > > > > > > >3. > > > > > >Metadata for Nightly Composes: Our Release Engineering and Fedora > > >Quality Assurance teams rely on PDC for metadata related to nightly > > >composes. > > > > > > > > > More info on the usage can be found here: > > > https://fedora-arc.readthedocs.io/en/latest/pdc/users.html > > > > mass rebuild of modules can be dropped. ;) > > > > fedscm-admin is now the scm requests toddler. It still uses pdc tho > > of course. > > > > > Specific Endpoints in Use: > > > > ...snip... > > > > > Upcoming Changes > > > > > > Bodhi: > > > > > > Bodhi will assume responsibility for the following tasks, reducing our > > > reliance on PDC: > > > > > > /rest_api/v1/releases/: Bodhi will now manage release-related data. > > > > Do note that bodhi still has a window after we are 'go' for a relase > > where it thinks it's released, but it's not yet. We probibly need to > > address this if we are moving this to bodhi. > > > > > /rest_api/v1/component-branches/: Specifically, Bodhi will handle the > > > critical-path flag. > > > > Already done. > > > > ...snip... > > > > > > Pagure-dist-git: > > > > > > Pagure-dist-git will take over several responsibilities from PDC, > including: > > > > > > /rest_api/v1/product-versions > > > > > > /rest_api/v1/global-components > > > > > > /rest_api/v1/component-branches/ > > > > > > /rest_api/v1/component-branch-slas/ > > > > > > Pagure already has a robust database of global components > (repositories) > > > and product versions (repository branches). > > > > > > It utilizes the PDC API to query component branches when a package is > > > retired, and an auxiliary table in Pagure-dist-git will store the > reasons > > > for orphaning these components. > > > > So, I know this will work... but it means more closely tying ourselves > > to pagure-dist-git. ;( > > > > With modules going out of the picture, most branches just have the > > release cycle of the fedora or rhel release they are based on, so > > couldn't we just default that somewhere? > > In the pkgdb time, the EOL status was basically simply computed from the > release > status, ie: what we still have at: > https://admin.fedoraproject.org/pkgdb/api/collections > (looks like we should fix the branchname in that json) > but we could just go back to this :) > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct:
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11 2023 at 08:00:29 AM -0400, Solomon Peachy via devel wrote: Not to retread old drama, but doesn't Fedora now rely on a proprietary version of Gitlab? No? All of our packages are on https://src.fedoraproject.org/ and our Fedora-specific source code goes on https://pagure.io/. These are both Pagure, not GitLab. It is open source. I think we *should* move to GitLab, but only if it's an open source GitLab instance like most other major open source projects use (GNOME, KDE, freedesktop.org, Debian, etc.) We should not depend on proprietary services to build Fedora unless there is no suitable alternative, and there are *many* suitable alternatives here. This is core to Fedora's mission and identity. It wouldn't be strategic to compromise on this. 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2238261] perl-Mail-DKIM-1.20230911 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2238261 František Hrdina changed: What|Removed |Added Doc Type|--- |If docs needed, set a value CC||fhrd...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2238261 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2224550] Upgrade perl-Net-CLI-Interact to 2.400002
https://bugzilla.redhat.com/show_bug.cgi?id=2224550 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade |Upgrade |perl-Net-CLI-Interact to|perl-Net-CLI-Interact to |2.40|2.42 --- Comment #3 from Jitka Plesnikova --- Latest Fedora delivers 2.34 version. Upstream released 2.42. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2224550 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224550%23c3 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: An update on RHEL moving to issues.redhat.com
On Mon, Sep 11, 2023 at 04:35:50AM +0200, Kevin Kofler via devel wrote: > +1, Fedora MUST NOT rely on proprietary infrastructure. IMHO, it is a > mistake that Red Hat is doing so, and Fedora should not follow that > unfortunate move. Not to retread old drama, but doesn't Fedora now rely on a proprietary version of Gitlab? - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) Dowling Park, FL speachy (libera.chat) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Potential changes to systemd RPM macros
On Wed, Aug 09, 2023 at 08:34:59AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 26, 2023 at 06:06:45AM -0400, Andrea Bolognani wrote: > > On Wed, Jul 26, 2023 at 07:15:42AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > %systemd_postun_with_restart, so adding %systemd_postun_with_reload > > > > or something along those lines doesn't seem like a stretch. > > > > > > → https://github.com/systemd/systemd/pull/28521 > > This is now merged. The new macros are: > %systemd_postun_with_reload, %systemd_user_postun_with_reload, > %systemd_user_daemon_reexec. That last one is now used in > the systemd.spec file in rawhide to properly reexec user@.service > instances after package upgrade. > > Somebody needs to file an FPC pull request now ;) https://pagure.io/packaging-committee/pull-request/1301 Reviews welcome ;) 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 11 September (today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 11 September at 1300UTC in #fedora-neuro on IRC (Libera.chat). The meeting is a public meeting, and open for everyone to attend. You can join us over: IRC: https://webchat.libera.chat/?channels=#fedora-neuro (We will return to Matrix once the matrix meetbot is ready/deployed) You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20230911T13=%3A=1 or you can use this command in a terminal: $ date --date='TZ="UTC" 1300 Monday' The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F39: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2023/09/11/next-open-neurofedora-meeting-11-September-1300-utc.html You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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, report it: https://pagure.io/fedora-infrastructure/new_issue
