Re: Decommissioning Nuancier
On 6/20/23 06:44, Ryan Lerch wrote: > Plans are underway to decommission Nuancier[1]. Nuancier was custom > built for the single task of voting for Fedora supplementary > wallpapers, and has not been used for this task since Fedora 32. > Had offered to update this. Would it be ok for me to write something new? Alternatively, Discourse does have some voting plugins. Could create another plugin if that would be helpful. Note that Discourse is used by the Krita community to enable discussions on artwork https://krita-artists.org/ though storage requirements can increase somewhat. To give better vote privacy, one typically has three separate databases, ideally run completely separately. One database contains eligible voters does vote verification, and a third contains a tally. A simpler but well tested system is implemented in: https://github.com/benadida/helios-server Maybe this could also be helpful for Fedora elections? > As such, Fedora Infra is moving towards decommissioning this > application, and archiving all the data, images, and voting > statistics. Also, the source of this application[2] will be archived > in GitHub. > > For ongoing information and discussion on this process please view the > fedora-infrastructure ticket [3] > > > > [1] - https://apps.fedoraproject.org/nuancier/ > [2] - https://github.com/fedora-infra/nuancier > [3] - https://pagure.io/fedora-infrastructure/issue/11371 ___ 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
Koji builders cannot build Wine Mono
Hi, I was attempting to push a Wine Mono update today but ran into a problem with all versions of Fedora when building in Koji. The Wine Mono update successfully compiles on my local system using "fedpkg mockbuild" for all versions of Fedora. The builds fail in similar ways but in different places. If anyone has a minute could they review the build logs and offer a clue as to what may be the cause? F39 build attempts: - https://koji.fedoraproject.org/koji/taskinfo?taskID=102372408 (x86_64) - https://koji.fedoraproject.org/koji/taskinfo?taskID=102373027 (aarch64) - https://koji.fedoraproject.org/koji/taskinfo?taskID=102373207 (x86_64) F38 build attempt: https://koji.fedoraproject.org/koji/taskinfo?taskID=102372475 (aarch64) F37 build attempt: https://koji.fedoraproject.org/koji/taskinfo?taskID=102372473 (x86_64) Thanks, 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
Re: SIG proposal: Multimedia SIG
Dominik, On 2023-06-20 05:32, Dominik 'Rathann' Mierzejewski wrote: Hello! With the growing number of multimedia packages in Fedora, mostly owing to the introduction of ffmpeg package and Legal permission to enable and ship many popular codecs, I think we've reached the critical mass of packages and maintainers that warrants the creation of a Multimedia SIG. I propose, similar to the recently established LibreOffice SIG, to create a FAS group, Bugzilla account and a private mailing list. Great idea! P. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: p...@pricom.com.au ___ 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: SIG proposal: Multimedia SIG
On Mon, 2023-06-19 at 18:01 -0400, JT wrote: > In the original post, I took private to mean its own dedicated list... not > that it'd be hidden > from view from everyone. IMHO everything with Fedora should be in the open. > Bugs should be > reported upstream, so I dont see why there would need to be any confidential > information dealt > with by the SIG. > Security exploits for upstream applications shouldnt be dealt with upstream > and not here with a > Fedora SIG. There's no reason for exploit discussion of that nature unless > its something Fedora > has introduced, at which point it's relevant and should be public so users > can be aware and > address/mitigate any potential threat. > JT > Hi, I agree. Regards Phil -- *** Playing the game for the games own sake. *** Associations: * Debian Maintainer (DM) * Fedora/EPEL Maintainer. * Contributor member of the AlmaLinux foundation. WWW: https://kathenas.org Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SIG proposal: Multimedia SIG
On Mon, 2023-06-19 at 22:36 +, Maxwell G wrote: > On Mon Jun 19, 2023 at 22:20 +0100, Philip Wyett wrote: > > On Mon, 2023-06-19 at 21:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > Hello! > > > > > > With the growing number of multimedia packages in Fedora, mostly owing > > > to the introduction of ffmpeg package and Legal permission to enable > > > and ship many popular codecs, I think we've reached the critical mass of > > > packages and maintainers that warrants the creation of a Multimedia SIG. > > > > > > I propose, similar to the recently established LibreOffice SIG, to > > > create a FAS group, Bugzilla account and a private mailing list. > > > > > > > Private mailing list? No part of this project should have private anything > > IMHO. > > This is how all Fedora packaging SIGs work. They have a private mailing > list that's only used for Bugzilla notifications that may contain > private bugs with sensitive information, and then everything else is > handled over standard, public channels. > > Using the Python SIG as an example: > > - python-de...@lists.fedoraproject.org -> Public discussion list > - python-packagers-...@lists.fedoraproject.org -> List used for the > Bugzilla account and nothing else. Only open to members of the > @python-packagers-sig FAS group. > - #python:fedoraproject.org / #fedora-python -> Synchronous > communication > > -- > Maxwell G (@gotmax23) > Pronouns: He/They > _ Hi, If for notification only of persons in a group that is more suitable and they are never used for reply/ongoing private group discussion. Thanks for the clarification. Regards Phil -- *** Playing the game for the games own sake. *** Associations: * Debian Maintainer (DM) * Fedora/EPEL Maintainer. * Contributor member of the AlmaLinux foundation. WWW: https://kathenas.org Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Decommissioning Nuancier
Plans are underway to decommission Nuancier[1]. Nuancier was custom built for the single task of voting for Fedora supplementary wallpapers, and has not been used for this task since Fedora 32. As such, Fedora Infra is moving towards decommissioning this application, and archiving all the data, images, and voting statistics. Also, the source of this application[2] will be archived in GitHub. For ongoing information and discussion on this process please view the fedora-infrastructure ticket [3] [1] - https://apps.fedoraproject.org/nuancier/ [2] - https://github.com/fedora-infra/nuancier [3] - https://pagure.io/fedora-infrastructure/issue/11371 ___ 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: SIG proposal: Multimedia SIG
On Mon Jun 19, 2023 at 22:20 +0100, Philip Wyett wrote: > On Mon, 2023-06-19 at 21:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > > Hello! > > > > With the growing number of multimedia packages in Fedora, mostly owing > > to the introduction of ffmpeg package and Legal permission to enable > > and ship many popular codecs, I think we've reached the critical mass of > > packages and maintainers that warrants the creation of a Multimedia SIG. > > > > I propose, similar to the recently established LibreOffice SIG, to > > create a FAS group, Bugzilla account and a private mailing list. > > > > Private mailing list? No part of this project should have private anything > IMHO. This is how all Fedora packaging SIGs work. They have a private mailing list that's only used for Bugzilla notifications that may contain private bugs with sensitive information, and then everything else is handled over standard, public channels. Using the Python SIG as an example: - python-de...@lists.fedoraproject.org -> Public discussion list - python-packagers-...@lists.fedoraproject.org -> List used for the Bugzilla account and nothing else. Only open to members of the @python-packagers-sig FAS group. - #python:fedoraproject.org / #fedora-python -> Synchronous communication -- 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: SIG proposal: Multimedia SIG
In the original post, I took private to mean its own dedicated list... not that it'd be hidden from view from everyone. IMHO everything with Fedora should be in the open. Bugs should be reported upstream, so I dont see why there would need to be any confidential information dealt with by the SIG. Security exploits for upstream applications shouldnt be dealt with upstream and not here with a Fedora SIG. There's no reason for exploit discussion of that nature unless its something Fedora has introduced, at which point it's relevant and should be public so users can be aware and address/mitigate any potential threat. JT On Mon, Jun 19, 2023 at 5:49 PM Philip Wyett wrote: > On Mon, 2023-06-19 at 23:39 +0200, Emmanuel Seyman wrote: > > * Philip Wyett [19/06/2023 22:20] : > > > Private mailing list? No part of this project should have private > anything IMHO. > > > > Bug reports can explain security flaws and lead to exploits. They can > > also contain confidentiel information. > > > > I would suggest a private ml dedicated to bugs and a public one for > > everything else, IMHO. > > > > Emmanuel > > > > Hi, > > Any bug report that contains sensitive data (exploitable or not) and is > deemed private, the > discussion should be done in that bug report. > > Private ML is always a bad idea as much discussion tends to end up on it > and the wider community is > excluded and I do not believe we are here to exclude. > > Regards > > Phil > > -- > *** Playing the game for the games own sake. *** > > > Associations: > > * Debian Maintainer (DM) > * Fedora/EPEL Maintainer. > * Contributor member of the AlmaLinux foundation. > > WWW: https://kathenas.org > > Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg > > Twitter: @kathenasorg > > Instagram: @kathenasorg > > IRC: kathenas > > GPG: 724AA9B52F024C8B > ___ > 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 > ___ 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: SIG proposal: Multimedia SIG
On Mon, 2023-06-19 at 23:39 +0200, Emmanuel Seyman wrote: > * Philip Wyett [19/06/2023 22:20] : > > Private mailing list? No part of this project should have private anything > > IMHO. > > Bug reports can explain security flaws and lead to exploits. They can > also contain confidentiel information. > > I would suggest a private ml dedicated to bugs and a public one for > everything else, IMHO. > > Emmanuel > Hi, Any bug report that contains sensitive data (exploitable or not) and is deemed private, the discussion should be done in that bug report. Private ML is always a bad idea as much discussion tends to end up on it and the wider community is excluded and I do not believe we are here to exclude. Regards Phil -- *** Playing the game for the games own sake. *** Associations: * Debian Maintainer (DM) * Fedora/EPEL Maintainer. * Contributor member of the AlmaLinux foundation. WWW: https://kathenas.org Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SIG proposal: Multimedia SIG
* Philip Wyett [19/06/2023 22:20] : > > Private mailing list? No part of this project should have private anything > IMHO. Bug reports can explain security flaws and lead to exploits. They can also contain confidentiel information. I would suggest a private ml dedicated to bugs and a public one for everything else, IMHO. Emmanuel ___ 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: SIG proposal: Multimedia SIG
On Mon, 2023-06-19 at 21:32 +0200, Dominik 'Rathann' Mierzejewski wrote: > Hello! > > With the growing number of multimedia packages in Fedora, mostly owing > to the introduction of ffmpeg package and Legal permission to enable > and ship many popular codecs, I think we've reached the critical mass of > packages and maintainers that warrants the creation of a Multimedia SIG. > > I propose, similar to the recently established LibreOffice SIG, to > create a FAS group, Bugzilla account and a private mailing list. > Private mailing list? No part of this project should have private anything IMHO. Regards Phil -- *** Playing the game for the games own sake. *** Associations: * Debian Maintainer (DM) * Fedora/EPEL Maintainer. * Contributor member of the AlmaLinux foundation. WWW: https://kathenas.org Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On Fri, 16 Jun 2023, Miro Hrončok wrote: On 16. 06. 23 17:16, Scott Talbert wrote: On Fri, 16 Jun 2023, Miro Hrončok wrote: Hi, I have the python-qcengine package, which is not rebuilt by python 3.12 yet. https://src.fedoraproject.org/rpms/python-qcengine Hello. This is waiting for: python-qcelemental python-pint Which is waiting for: python-matplotlib python-fs python-contourpy python-pillow python-pytest-mpl python-pillow is currently one of the biggest blockers, blocked on python-pyqt5-sip, which segfaults during build :/ Fixed python-pyqt5-sip. You are awesome! Fixed python-wxpython4 also, in case you have other packages blocked on that, too. (It was mostly broken by a recent doxygen upgrade in rawhide. :() Scott___ 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: SIG proposal: Multimedia SIG
As the current Maintainer of Fedora Jam... I'm on board with this idea. ~JT On Mon, Jun 19, 2023 at 3:33 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Hello! > > With the growing number of multimedia packages in Fedora, mostly owing > to the introduction of ffmpeg package and Legal permission to enable > and ship many popular codecs, I think we've reached the critical mass of > packages and maintainers that warrants the creation of a Multimedia SIG. > > I propose, similar to the recently established LibreOffice SIG, to > create a FAS group, Bugzilla account and a private mailing list. > > Regards, > Dominik > -- > Fedora https://fedoraproject.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > 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 > ___ 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
SIG proposal: Multimedia SIG
Hello! With the growing number of multimedia packages in Fedora, mostly owing to the introduction of ffmpeg package and Legal permission to enable and ship many popular codecs, I think we've reached the critical mass of packages and maintainers that warrants the creation of a Multimedia SIG. I propose, similar to the recently established LibreOffice SIG, to create a FAS group, Bugzilla account and a private mailing list. Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: 20230619.n.0 changes
OLD: Fedora-Rawhide-20230618.n.0 NEW: Fedora-Rawhide-20230619.n.0 = SUMMARY = Added images:4 Dropped images: 1 Added packages: 1 Dropped packages:0 Upgraded packages: 48 Downgraded packages: 0 Size of added packages: 297.96 KiB Size of dropped packages:0 B Size of upgraded packages: 581.50 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 2.43 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230619.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230619.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230619.n.0.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230619.n.0.iso = DROPPED IMAGES = Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20230618.n.0.s390x.tar.xz = ADDED PACKAGES = Package: phosh-mobile-settings-0.26.0-1.fc39 Summary: Mobile Settings App for phosh and related components RPMs:phosh-mobile-settings Size:297.96 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: asahi-scripts-20230606-5.fc39 Old package: asahi-scripts-20230606-4.fc39 Summary: Miscellaneous admin scripts for Asahi Linux RPMs: asahi-fwupdate asahi-scripts dracut-asahi linux-firmware-vendor update-m1n1 Size: 60.18 KiB Size change: 607 B Changelog: * Sun Jun 18 2023 Davide Cavalca - 20230606-5 - Expand fwupdate trigger to fire on fwextract updates Package: bash-completion-1:2.11-11.fc39 Old package: bash-completion-1:2.11-9.fc38 Summary: Programmable completion for Bash RPMs: bash-completion Size: 367.22 KiB Size change: -342 B Changelog: * Tue Apr 11 2023 Luk Zaoral - 1:2.11-10 - migrate to SPDX license format * Fri Jun 16 2023 Siteshwar Vashisht - 1:2.11-11 - Remove bash completions for javaws Resolves: #2188865 Package: ceph-2:18.1.1-0.1.fc39 Old package: ceph-2:18.1.0-0.3.fc39 Summary: User space components of the Ceph file system RPMs: ceph ceph-base ceph-common ceph-exporter ceph-fuse ceph-grafana-dashboards ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents ceph-mgr-modules-core ceph-mgr-rook ceph-mib ceph-mon ceph-osd ceph-prometheus-alerts ceph-radosgw ceph-resource-agents ceph-selinux ceph-test ceph-volume cephadm cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 libcephsqlite libcephsqlite-devel librados-devel librados2 libradospp-devel libradosstriper-devel libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados python3-rbd python3-rgw rados-objclass-devel rbd-fuse rbd-mirror rbd-nbd Size: 416.80 MiB Size change: 136.43 KiB Changelog: * Thu Jun 15 2023 Kaleb S. KEITHLEY - 2:18.1.0-0.4 - Rebuilt for Python 3.12 * Sun Jun 18 2023 Kaleb S. KEITHLEY - 2:18.1.1-0.1 - ceph-18.1.1 RC2 Package: distrobox-1.5.0-1.fc39 Old package: distrobox-1.4.2.1-2.fc38 Summary: Another tool for containerized command line environments on Linux RPMs: distrobox Size: 238.99 KiB Size change: -54.75 KiB Changelog: * Sun Jun 18 2023 Alessio - 1.5.0-1 - Update to 1.5.0 Package: fast_float-5.0.0-2.fc39 Old package: fast_float-5.0.0-1.fc39 Summary: Fast & exact implementation of C++ from_chars for float/double RPMs: fast_float-devel Size: 56.76 KiB Size change: 105 B Changelog: * Sun Jun 18 2023 Benjamin A. Beasley - 5.0.0-2 - Use new (rpm 4.17.1+) bcond style Package: gconfmm26-2.28.3-69.fc39 Old package: gconfmm26-2.28.3-68.fc39 Summary: C++ wrapper for GConf2 RPMs: gconfmm26 gconfmm26-devel gconfmm26-doc Size: 835.59 KiB Size change: -17.31 KiB Changelog: * Sun Jun 18 2023 Benjamin A. Beasley - 2.28.3-69 - Use new (rpm 4.17.1+) bcond style Package: gn-2109^20230618git4bd1a77e6795-1.fc39 Old package: gn-2106^20230529gite3978de3e8da-2.fc39 Summary: Meta-build system that generates build files for Ninja RPMs: gn gn-doc Size: 2.97 MiB Size change: 3.26 KiB Changelog: * Sun Jun 18 2023 Benjamin A. Beasley - 2106^20230529gite3978de3e8da-3 - Use new (rpm 4.17.1+) bcond style * Sun Jun 18 2023 Benjamin A. Beasley - 2109^20230618git4bd1a77e6795-1 - Update to version 2109 Package: golang-github-gorilla-websocket-1.5.0-1.fc39 Old package: golang-github-gorilla-websocket-1.4.2-7.fc38 Summary: A fast, well-tested and widely used WebSocket implementation for Go RPMs: golang-github-gorilla-websocket-devel
[Bug 2216016] perl-B-Keywords-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216016 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-B-Keywords-1.26-1.fc38.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=102358897 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216016 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216016%23c2 ___ 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 2216016] perl-B-Keywords-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216016 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1971591 --> https://bugzilla.redhat.com/attachment.cgi?id=1971591=edit Update to 1.26 (#2216016) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216016 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216016%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 2216016] New: perl-B-Keywords-1.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2216016 Bug ID: 2216016 Summary: perl-B-Keywords-1.26 is available Product: Fedora Version: rawhide Status: NEW Component: perl-B-Keywords Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.26 Upstream release that is considered latest: 1.26 Current version/release in rawhide: 1.24-5.fc38 URL: http://search.cpan.org/dist/B-Keywords/ 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/2662/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-B-Keywords -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2216016 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202216016%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
Rawhide update gating on openQA tests will be enabled Wednesday
Hey folks! So, as per https://pagure.io/fesco/issue/3011 , we plan to enable gating of Rawhide updates on openQA test results on Wednesday. What does this mean? For many updates, nothing at all: only updates on the critical path will be gated. For most critical path updates: instead of the build(s) being tagged and going into the buildroot immediately after the build, the update will go into a "waiting" state for about two hours, then - when the tests have all passed - the builds will be tagged and put in the buildroot. This is just the same as for branched and stable updates. For the few critical path updates where a gating test fails: the packages will not be tagged or reach the buildroot. The QA team should notice the failure, investigate, and either fix the problem or file some kind of issue report linked from the update on Bodhi within 24 hours. If this does not happen, or the update needs urgent attention, please contact the QA team on Fedora Chat, or by email to test@ . If you believe a gating failure may be a false alarm, you can click the "Re-Run Tests" button in Bodhi to have the test re-run. If you are *very very sure* it is a false alarm, and the need is urgent, you can click the "Waive Results" button in Bodhi to waive the failure and have the update tagged, but please only do this if there's really no alternative. Please note that waiving a failure comes with a risk that the same failure will happen for *every subsequent update*, causing each of them to be gated, because the waived update will immediately reach the buildroot, and openQA uses the buildroot as its "base" package set for testing. Really, please don't do this unless you're very sure! If you have a big set or chain of builds to do and you don't want to have to wait two hours between dependent builds: use a side tag! Side tags are self-service now. You can just request one, it will be created within minutes, and you can do your builds on the side tag. No gating applies to side tags. When you're done, create an update from the side tag in Bodhi (the web UI has support for this), and it will be tested and gated as a single unit (the openQA tests will run once on the update as a whole). See https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ for a walk-through of this process. The display of gating status and test results on the Bodhi web interface should be clear, consistent and accurate. If you find it is not in any way, please file a ticket on Bodhi and tag me on it. If this turns out to be a bad idea, we can and will easily revert it, so please don't panic. :) Thanks everyone! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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
Rawhide update gating on openQA tests will be enabled Wednesday
Hey folks! So, as per https://pagure.io/fesco/issue/3011 , we plan to enable gating of Rawhide updates on openQA test results on Wednesday. What does this mean? For many updates, nothing at all: only updates on the critical path will be gated. For most critical path updates: instead of the build(s) being tagged and going into the buildroot immediately after the build, the update will go into a "waiting" state for about two hours, then - when the tests have all passed - the builds will be tagged and put in the buildroot. This is just the same as for branched and stable updates. For the few critical path updates where a gating test fails: the packages will not be tagged or reach the buildroot. The QA team should notice the failure, investigate, and either fix the problem or file some kind of issue report linked from the update on Bodhi within 24 hours. If this does not happen, or the update needs urgent attention, please contact the QA team on Fedora Chat, or by email to test@ . If you believe a gating failure may be a false alarm, you can click the "Re-Run Tests" button in Bodhi to have the test re-run. If you are *very very sure* it is a false alarm, and the need is urgent, you can click the "Waive Results" button in Bodhi to waive the failure and have the update tagged, but please only do this if there's really no alternative. Please note that waiving a failure comes with a risk that the same failure will happen for *every subsequent update*, causing each of them to be gated, because the waived update will immediately reach the buildroot, and openQA uses the buildroot as its "base" package set for testing. Really, please don't do this unless you're very sure! If you have a big set or chain of builds to do and you don't want to have to wait two hours between dependent builds: use a side tag! Side tags are self-service now. You can just request one, it will be created within minutes, and you can do your builds on the side tag. No gating applies to side tags. When you're done, create an update from the side tag in Bodhi (the web UI has support for this), and it will be tested and gated as a single unit (the openQA tests will run once on the update as a whole). See https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ for a walk-through of this process. The display of gating status and test results on the Bodhi web interface should be clear, consistent and accurate. If you find it is not in any way, please file a ticket on Bodhi and tag me on it. If this turns out to be a bad idea, we can and will easily revert it, so please don't panic. :) Thanks everyone! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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
Heads-up: python-typeguard 4.0.0 coming to Rawhide
I plan to update python-typeguard from 2.12.3 to 4.0.0[1] in Rawhide. Version 3 of typeguard included a number of breaking changes[2], and 4.0.0 included a few as well[3]. Directly-dependent package compatibility with version 4.0.0 is as follows: - python-nptyping is compatible - python-signature-dispatch will be compatible with a concurrent update from 1.0.0 to 1.0.1[4] - python-stack-data has dropped the dependency in Rawhide - python-TestSlide is incompatible, but (1) the package already FTBFS in F38 and Rawhide, and (2) I opened PR’s to fix the existing FTBFS[5] and typeguard 4 compatibility[6] about a month ago. The maintainers can easily fix the incompatibility whenever they want to address the existing FTBFS. While the Updates Policy prescribes one week’s notice for API-incompatible updates like this[7], the intent of that rule is to avoid breaking packages without notice. In this case, python-typeguard already FTBFS in Rawhide since python-typing-extensions was updated from 4.5.0 to 4.6.2, and this incompatible update is required to fix that. If the package is not updated, python-typeguard and everything that directly or indirectly depends on it will fail in the Python 3.12 mass rebuild. I have therefore asked FESCo for permission to update immediately rather than waiting out the usual one-week notice period.[8] [1] https://src.fedoraproject.org/rpms/python-typeguard/pull-request/3 [2] https://github.com/agronholm/typeguard/blob/3.0.0/docs/versionhistory.rst#version-history [3] https://github.com/agronholm/typeguard/blob/4.0.0/docs/versionhistory.rst#version-history [4] https://src.fedoraproject.org/rpms/python-signature-dispatch/pull-request/1 [5] https://src.fedoraproject.org/rpms/python-TestSlide/pull-request/1 [6] https://src.fedoraproject.org/rpms/python-TestSlide/pull-request/2 [7] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide [8] https://pagure.io/fesco/issue/3014 ___ 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 2215501] perl-CPAN-Perl-Releases-5.20230616 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215501 --- Comment #1 from Fedora Update System --- FEDORA-2023-ad9351039a has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ad9351039a --- Comment #2 from Fedora Update System --- FEDORA-2023-40f234c0d3 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-40f234c0d3 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215501 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215501%23c2 ___ 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 2215501] perl-CPAN-Perl-Releases-5.20230616 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215501 --- Comment #1 from Fedora Update System --- FEDORA-2023-ad9351039a has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ad9351039a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215501 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215501%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 2215501] perl-CPAN-Perl-Releases-5.20230616 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215501 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-CPAN-Perl-Releases-5.2 ||0230616-1.fc39 Status|ASSIGNED|MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215501 ___ 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 2215981] perl-Crypt-OpenSSL-X509-1.915 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215981
--- Comment #1 from Upstream Release Monitoring
---
Scratch build failed. Details below:
BuilderException: Build failed:
Couldn't upload source
/var/tmp/thn-opszlu98/./SRPMS/perl-Crypt-OpenSSL-X509-1.915-1.fc38.src.rpm to
koji.
Traceback:
File
"/usr/local/lib/python3.11/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
^
File "/usr/local/lib/python3.11/site-packages/hotness/builders/koji.py", line
252, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
File "/usr/local/lib/python3.11/site-packages/hotness/builders/koji.py", line
477, in _scratch_build
raise BuilderException("Couldn't upload source {} to koji.".format(source))
If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2215981
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215981%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 2215981] New: perl-Crypt-OpenSSL-X509-1.915 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215981 Bug ID: 2215981 Summary: perl-Crypt-OpenSSL-X509-1.915 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Crypt-OpenSSL-X509 Keywords: FutureFeature, Triaged Assignee: wjhns...@hardakers.net Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, wjhns...@hardakers.net, xav...@bachelot.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.915 Upstream release that is considered latest: 1.915 Current version/release in rawhide: 1.914-1.fc39 URL: http://search.cpan.org/dist/Crypt-OpenSSL-X509/ 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/2749/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Crypt-OpenSSL-X509 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215981 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215981%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
[Bug 2215893] perl-RDF-NS-20230619 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215893 --- Comment #3 from Fedora Update System --- FEDORA-2023-45536c77fa has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-45536c77fa -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215893%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
[Bug 2215893] perl-RDF-NS-20230619 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215893 --- Comment #2 from Fedora Update System --- FEDORA-2023-db4da4d358 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-db4da4d358 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215893%23c2 ___ 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 2215893] perl-RDF-NS-20230619 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-RDF-NS-20230619-1.fc39 --- Comment #1 from Petr Pisar --- It only adds new prefixes. Suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215893%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
F39 Change Proposal: Passkey authentication for centrally managed users (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/Passkey_authentication_centrally_managed_users 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 == For centrally managed users on Fedora systems enrolled into Active Directory, FreeIPA, or LDAP, enable capability to log-in to desktop or a console terminal with a FIDO2-compatible device supported by the libfido2 library. For FreeIPA, additionally, once user has been authenticated with the FIDO2-compatible device, allow to issue a Kerberos ticket. Note: for the purpose of this feature, passkey is a FIDO2 compatible device supported by the libfido2 library. If a hardware token implements other authentication mechanisms aside from FIDO2, these aren't considered by this feature. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]], [[User:Abbra| Alexander Bokovoy]] * Email: , == Detailed Description == Passwordless authentication methods to log into Linux systems became a hot topic in the past few years. Various organizations started to mandate more secure methods of authentication, including governments and regulated industries. FIDO2 tokens, along with smartcards, represent two passwordless authentication methods mandated by the US government in their Zero Trust architecture, for example. While Fedora Project already provides a smartcard-based authentication method for all centrally-managed user accounts (LDAP, Active Directory, FreeIPA), support for FIDO2 tokens is rudimentary: only `pam_u2f` method is provided which currently only allows to define FIDO2 tokens associated with the users locally on the machine. No centralized storage of enrolled tokens is provided. SSSD and FreeIPA upstream projects have already implemented a way to authenticate a user with the help of the passkey and issue a Kerberos ticket. This change will make sure that this feature is enabled in Fedora, and that it works. == Feedback == == Benefit to Fedora == Integration of a passkey support in SSSD and FreeIPA to Fedora enables the possibility to configure a fully passwordless login experience in Fedora. While this will require few iterations to enable a complete passwordless deployment, allowing admins to start with centralized user accounts with passkeys will give a wider base to iterate from. The passkey authentication is in line with the modernization of the technology and security practices, as it enables stronger identity and access controls, including multi-factor authentication (MFA). This method of authentication protects the user and the organization against phishing attacks by providing a strong cryptography tied to an external hardware authenticator. In the future we expect to add support for increasingly popular passkey implementations on mobile devices. This, however, is not a focus of the initial release. FreeIPA extension to issue Kerberos tickets based on the passkey authentication allows to solve usability issues in accessing network resources in a passwordless way. This extension also provides Kerberos authentication indicator support, making passkey authentication visible to Kerberos services. This can be used, for example, for passwordless SUDO access with `pam_sss_gss` module when a Kerberos ticket was obtained with a specific (passkey) authentication mechanism. == Scope == * Proposal owners: # Enable passkey feature in SSSD # Enable passkey feature in FreeIPA # Adjust SELinux policies to allow access to USB-enabled passkeys through libfido2 * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == No impact is expected. sssd provides a new subpackage (`sssd-passkey`) that includes the new functionality. For FreeIPA environments the new subpackage will be automatically pulled in by the `freeipa-client` package as a dependency. == How To Test == The following instructions assume that you are using a SSSD and FreeIPA to manage users. # Install the `sssd-passkey` subpackage, and update the FreeIPA client and server. # Enable passkey authentication for the user, remember to replace the username where applicable. $ ipa user-mod USERNAME --user-auth-type=passkey # Connect the passkey to the system and register it. $ ipa user-add-passkey USERNAME --register # Log in. $ su - USERNAME@DOMAIN Insert your passkey device, then press ENTER. Enter PIN: ... If you are able to log in, then everything worked correctly. If it didn't work and you'd like to debug it, or you'd like to use another LDAP-like server, or you'd like to know more, then check [https://ikerexxe.github.io/idm/2022/12/19/passkey-central-auth.html| the blog post] I wrote about how to test this feature. == User Experience == A centrally managed
F39 Change Proposal: Passkey authentication for centrally managed users (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/Passkey_authentication_centrally_managed_users 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 == For centrally managed users on Fedora systems enrolled into Active Directory, FreeIPA, or LDAP, enable capability to log-in to desktop or a console terminal with a FIDO2-compatible device supported by the libfido2 library. For FreeIPA, additionally, once user has been authenticated with the FIDO2-compatible device, allow to issue a Kerberos ticket. Note: for the purpose of this feature, passkey is a FIDO2 compatible device supported by the libfido2 library. If a hardware token implements other authentication mechanisms aside from FIDO2, these aren't considered by this feature. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]], [[User:Abbra| Alexander Bokovoy]] * Email: , == Detailed Description == Passwordless authentication methods to log into Linux systems became a hot topic in the past few years. Various organizations started to mandate more secure methods of authentication, including governments and regulated industries. FIDO2 tokens, along with smartcards, represent two passwordless authentication methods mandated by the US government in their Zero Trust architecture, for example. While Fedora Project already provides a smartcard-based authentication method for all centrally-managed user accounts (LDAP, Active Directory, FreeIPA), support for FIDO2 tokens is rudimentary: only `pam_u2f` method is provided which currently only allows to define FIDO2 tokens associated with the users locally on the machine. No centralized storage of enrolled tokens is provided. SSSD and FreeIPA upstream projects have already implemented a way to authenticate a user with the help of the passkey and issue a Kerberos ticket. This change will make sure that this feature is enabled in Fedora, and that it works. == Feedback == == Benefit to Fedora == Integration of a passkey support in SSSD and FreeIPA to Fedora enables the possibility to configure a fully passwordless login experience in Fedora. While this will require few iterations to enable a complete passwordless deployment, allowing admins to start with centralized user accounts with passkeys will give a wider base to iterate from. The passkey authentication is in line with the modernization of the technology and security practices, as it enables stronger identity and access controls, including multi-factor authentication (MFA). This method of authentication protects the user and the organization against phishing attacks by providing a strong cryptography tied to an external hardware authenticator. In the future we expect to add support for increasingly popular passkey implementations on mobile devices. This, however, is not a focus of the initial release. FreeIPA extension to issue Kerberos tickets based on the passkey authentication allows to solve usability issues in accessing network resources in a passwordless way. This extension also provides Kerberos authentication indicator support, making passkey authentication visible to Kerberos services. This can be used, for example, for passwordless SUDO access with `pam_sss_gss` module when a Kerberos ticket was obtained with a specific (passkey) authentication mechanism. == Scope == * Proposal owners: # Enable passkey feature in SSSD # Enable passkey feature in FreeIPA # Adjust SELinux policies to allow access to USB-enabled passkeys through libfido2 * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == No impact is expected. sssd provides a new subpackage (`sssd-passkey`) that includes the new functionality. For FreeIPA environments the new subpackage will be automatically pulled in by the `freeipa-client` package as a dependency. == How To Test == The following instructions assume that you are using a SSSD and FreeIPA to manage users. # Install the `sssd-passkey` subpackage, and update the FreeIPA client and server. # Enable passkey authentication for the user, remember to replace the username where applicable. $ ipa user-mod USERNAME --user-auth-type=passkey # Connect the passkey to the system and register it. $ ipa user-add-passkey USERNAME --register # Log in. $ su - USERNAME@DOMAIN Insert your passkey device, then press ENTER. Enter PIN: ... If you are able to log in, then everything worked correctly. If it didn't work and you'd like to debug it, or you'd like to use another LDAP-like server, or you'd like to know more, then check [https://ikerexxe.github.io/idm/2022/12/19/passkey-central-auth.html| the blog post] I wrote about how to test this feature. == User Experience == A centrally managed
F39 Change Proposal: asskey authentication for centrally managed users (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/Passkey_authentication_centrally_managed_users 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 == For centrally managed users on Fedora systems enrolled into Active Directory, FreeIPA, or LDAP, enable capability to log-in to desktop or a console terminal with a FIDO2-compatible device supported by the libfido2 library. For FreeIPA, additionally, once user has been authenticated with the FIDO2-compatible device, allow to issue a Kerberos ticket. Note: for the purpose of this feature, passkey is a FIDO2 compatible device supported by the libfido2 library. If a hardware token implements other authentication mechanisms aside from FIDO2, these aren't considered by this feature. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]], [[User:Abbra| Alexander Bokovoy]] * Email: , == Detailed Description == Passwordless authentication methods to log into Linux systems became a hot topic in the past few years. Various organizations started to mandate more secure methods of authentication, including governments and regulated industries. FIDO2 tokens, along with smartcards, represent two passwordless authentication methods mandated by the US government in their Zero Trust architecture, for example. While Fedora Project already provides a smartcard-based authentication method for all centrally-managed user accounts (LDAP, Active Directory, FreeIPA), support for FIDO2 tokens is rudimentary: only `pam_u2f` method is provided which currently only allows to define FIDO2 tokens associated with the users locally on the machine. No centralized storage of enrolled tokens is provided. SSSD and FreeIPA upstream projects have already implemented a way to authenticate a user with the help of the passkey and issue a Kerberos ticket. This change will make sure that this feature is enabled in Fedora, and that it works. == Feedback == == Benefit to Fedora == Integration of a passkey support in SSSD and FreeIPA to Fedora enables the possibility to configure a fully passwordless login experience in Fedora. While this will require few iterations to enable a complete passwordless deployment, allowing admins to start with centralized user accounts with passkeys will give a wider base to iterate from. The passkey authentication is in line with the modernization of the technology and security practices, as it enables stronger identity and access controls, including multi-factor authentication (MFA). This method of authentication protects the user and the organization against phishing attacks by providing a strong cryptography tied to an external hardware authenticator. In the future we expect to add support for increasingly popular passkey implementations on mobile devices. This, however, is not a focus of the initial release. FreeIPA extension to issue Kerberos tickets based on the passkey authentication allows to solve usability issues in accessing network resources in a passwordless way. This extension also provides Kerberos authentication indicator support, making passkey authentication visible to Kerberos services. This can be used, for example, for passwordless SUDO access with `pam_sss_gss` module when a Kerberos ticket was obtained with a specific (passkey) authentication mechanism. == Scope == * Proposal owners: # Enable passkey feature in SSSD # Enable passkey feature in FreeIPA # Adjust SELinux policies to allow access to USB-enabled passkeys through libfido2 * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == No impact is expected. sssd provides a new subpackage (`sssd-passkey`) that includes the new functionality. For FreeIPA environments the new subpackage will be automatically pulled in by the `freeipa-client` package as a dependency. == How To Test == The following instructions assume that you are using a SSSD and FreeIPA to manage users. # Install the `sssd-passkey` subpackage, and update the FreeIPA client and server. # Enable passkey authentication for the user, remember to replace the username where applicable. $ ipa user-mod USERNAME --user-auth-type=passkey # Connect the passkey to the system and register it. $ ipa user-add-passkey USERNAME --register # Log in. $ su - USERNAME@DOMAIN Insert your passkey device, then press ENTER. Enter PIN: ... If you are able to log in, then everything worked correctly. If it didn't work and you'd like to debug it, or you'd like to use another LDAP-like server, or you'd like to know more, then check [https://ikerexxe.github.io/idm/2022/12/19/passkey-central-auth.html| the blog post] I wrote about how to test this feature. == User Experience == A centrally managed
[Bug 2215815] perl-re-engine-RE2-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215815 --- Comment #3 from Fedora Update System --- FEDORA-2023-6eae45b5b9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6eae45b5b9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215815 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215815%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
[Bug 2215815] perl-re-engine-RE2-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215815 --- Comment #2 from Fedora Update System --- FEDORA-2023-6dd1799c92 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6dd1799c92 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215815 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215815%23c2 ___ 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 2215893] perl-RDF-NS-20230619 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Petr Pisar changed: What|Removed |Added Doc Type|--- |If docs needed, set a value CC|ppi...@redhat.com | Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215893 ___ 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 2215815] perl-re-engine-RE2-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215815 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-re-engine-RE2-0.18-1.f ||c39 --- Comment #1 from Petr Pisar --- An enhancement release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215815 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215815%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: Releasing package updates in multiple Fedora releases
On 19-06-2023 12:51, Miroslav Suchý wrote: Sounds like these tools are worth mentioning in the docs, seeing how many people face the same challenge. We (I am part of Packit team) plan to do more noise about it later. Especially this feature - we have finished it in January and asked few people to try it. We have done several rounds of fix-and-try-again. Today, we have one outstanding issue "manually re-trigger event" and I believe that once implemented, it will be ready for wide audience. If you are brave and ready for bleeding edge, you can try it now. I didn't realize Packit is still very new. So new, it's still warm, like the blood dripping off its edge... ;) I'll certainly try it out and provide feedback should I have any. Thanks, Miro! -- Sandro ___ 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: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 13:02:45 +0200, Vít Ondruch wrote: > > Dne 19. 06. 23 v 11:55 Ankur Sinha napsal(a): > > > > > We're discussing a different topic now. > > > Sorry but we don't. The thread started with: "For the 99% of packages I > maintain I usually perform the same workflow > when updating them". I don't see that percentage could be in line with the > update policy. > It really depends on what these packages are (and had I assumed that was hyperbole anyway). It sure wouldn't apply to 99% of my (or the neuro-sig) packages, but would to quite a few. To re-iterate: everyone should remember to check what impact their package builds/updates have on other packages before building/pushing (even for rawhide). > > The thread was "these steps are > > repetitive, how do folks automate them", and we're now discussing > > "maintainers should remember to check the impact of update before > > pushing them". > > > Being maintainer of ~200 packages, I certainly don't suffer the > repetitiveness, because there is rarely need to update the stable releases, > following the update policy. Again, it really depends on your packages. You maintain lots of core libraries where API/ABI bumps etc. do not/should not be pushed to stable releases. For the neuro-sig, we do have quite a few python packages that have frequent minor/patch releases and we do push these as updates to stable branches also after doing impact checks. So, I do use my script for these. -- 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
Re: Releasing package updates in multiple Fedora releases
Dne 19. 06. 23 v 11:55 Ankur Sinha napsal(a): On Mon, Jun 19, 2023 11:22:35 +0200, Vít Ondruch wrote: Right, not pushing to all branches is in line with official guidelines: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases It's more nuanced than "don't push updates to all branches" though: ".. we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time." So minor/patch version updates, especially for things like Python packages that have frequent minor/patch releases is perfectly fine. Especially I don't like my packages being FTBFS due to other packagers pushing their updates everywhere. If there was at least included mass-prebuild step in the initial list to ensure there is no breakage in dependent packages. This is part of the "vetting the update before pushing" step. We have tools that package maintainers can/should use to see what packages depend on a particular one before updating it (fedrq is one I believe, but folks have their own dnf based scripts/commands). I've also filed an RFE to the-new-hotness to add dependency information to the "new package version is available" bug report some time ago, which would help ensure maintainers are aware of the update's impact: https://github.com/fedora-infra/the-new-hotness/issues/545 We're discussing a different topic now. Sorry but we don't. The thread started with: "For the 99% of packages I maintain I usually perform the same workflow when updating them". I don't see that percentage could be in line with the update policy. The thread was "these steps are repetitive, how do folks automate them", and we're now discussing "maintainers should remember to check the impact of update before pushing them". Being maintainer of ~200 packages, I certainly don't suffer the repetitiveness, because there is rarely need to update the stable releases, following the update policy. Vít OpenPGP_signature Description: OpenPGP digital 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: Releasing package updates in multiple Fedora releases
Dne 19. 06. 23 v 11:30 Sandro napsal(a): 2) Even better is Packit https://packit.dev/ You have many ways to use it. My favorite way is to use pull-from-upstream https://packit.dev/posts/pull-from-upstream/ You just make sure you have record in https://release-monitoring.org/ and then put .packit.yaml in Fedora's dist-git. And when upstream has a new release you will receive a pull request to src.fedoraproject.org for all configure branches. And when it merges it (can) build in Koji and submit Bodhi update for you. With Packit you can use full automation or only some steps. And combine it as you like it. If you do not like triggereing by release monitoring, you can initiate it from command line. It is up to you. Sounds like these tools are worth mentioning in the docs, seeing how many people face the same challenge. We (I am part of Packit team) plan to do more noise about it later. Especially this feature - we have finished it in January and asked few people to try it. We have done several rounds of fix-and-try-again. Today, we have one outstanding issue "manually re-trigger event" and I believe that once implemented, it will be ready for wide audience. If you are brave and ready for bleeding edge, you can try it now. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 08:28:23 +0200, Vitaly Zaitsev via devel wrote: > On 18/06/2023 17:42, Ankur Sinha wrote: > > I threw all the commands into a script with some optional arguments: > > Maybe this script can be added to fedora-packager? Sure, if folks find it useful enough. In the meantime, I added bits to run `fedrq` before each branch is worked upon to inform the user what packages would be affected: https://github.com/sanjayankur31/100_dotfiles/blob/main/bin/fedpkg-sync-build-all-branches.sh#L30 -- 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
[Bug 2215893] New: perl-RDF-NS-20230619 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Bug ID: 2215893 Summary: perl-RDF-NS-20230619 is available Product: Fedora Version: rawhide Status: NEW Component: perl-RDF-NS Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 20230619 Upstream release that is considered latest: 20230619 Current version/release in rawhide: 20190227-13.fc38 URL: http://search.cpan.org/dist/RDF-NS/ 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/10759/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-RDF-NS -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2215893 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202215893%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
[Bug 2215815] perl-re-engine-RE2-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2215815 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value CC|ppi...@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=2215815 ___ 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: update to jpegxl-0.8.1 with soname bump
Hi, Mass rebuild for jpegxl-0.8.1 finished, all packages built successfully and sent to rawhide: aom-3.6.0-2.fc39 darktable-4.2.1-4.fc39 ffmpeg-6.0-7.fc39 geeqie-2.0.1-5.fc39 gimp-2.10.34-5.fc39 gthumb-3.12.2-8.fc39 ImageMagick-7.1.1.11-2.fc39 imlib2-1.11.1-2.fc39 jpegxl-0.8.1-2.fc39 kf5-kimageformats-5.107.0-2.fc39 krita-5.1.5-3.fc39 SDL2_image-2.6.3-2.fc39 seamonkey-2.53.16-2.fc39 vips-8.13.3-8.fc39 webkitgtk-2.41.5-3.fc39 xine-lib-1.2.13-6.fc39 On Fri, 2023-06-16 at 14:50 +0100, Sérgio Basto wrote: > Hi, > > I'm going do a sidetag this weekend I will rebuild the 15 > dependencies > [1] let me know, if you know of any impediment. > > Thank you > > [1] > Depending on: jpegxl (15) > ImageMagick (maintained by: dcavalca, epel-packagers-sig, kalev, > luya, > ngompa, remi, salimma, sergiomb) > ImageMagick-1:7.1.1.11-1.fc39.src requires pkgconfig(libjxl) = 0.7.0 > ImageMagick-libs-1:7.1.1.11-1.fc39.i686 requires libjxl.so.0.7, > libjxl.so.0.7(JXL_0), libjxl_threads.so.0.7, > libjxl_threads.so.0.7(JXL_0) > ImageMagick-libs-1:7.1.1.11-1.fc39.x86_64 requires > libjxl.so.0.7()(64bit), libjxl.so.0.7(JXL_0)(64bit), > libjxl_threads.so.0.7()(64bit), libjxl_threads.so.0.7(JXL_0)(64bit) > > SDL2_image (maintained by: fcami, ngompa, pwalter, sergiomb) > SDL2_image-2.6.3-1.fc39.i686 requires libjxl.so.0.7, > libjxl.so.0.7(JXL_0) > SDL2_image-2.6.3-1.fc39.src requires libjxl-devel = 1:0.7.0-6.fc38 > SDL2_image-2.6.3-1.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit) > SDL2_image-devel-2.6.3-1.fc39.i686 requires pkgconfig(libjxl) = 0.7.0 > SDL2_image-devel-2.6.3-1.fc39.x86_64 requires pkgconfig(libjxl) = > 0.7.0 > > aom (maintained by: decathorpe, ngompa) > aom-3.6.0-1.fc39.src requires pkgconfig(libjxl) = 0.7.0 > libaom-3.6.0-1.fc39.i686 requires libjxl.so.0.7, libjxl.so.0.7(JXL_0) > libaom-3.6.0-1.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit) > libaom-devel-3.6.0-1.fc39.i686 requires pkgconfig(libjxl) = 0.7.0 > libaom-devel-3.6.0-1.fc39.x86_64 requires pkgconfig(libjxl) = 0.7.0 > > darktable (maintained by: aekoroglu, asn, germano, kalev) > darktable-4.2.1-1.fc39.src requires libjxl-devel = 1:0.7.0-6.fc38 > darktable-4.2.1-1.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit), libjxl_threads.so.0.7()(64bit), > libjxl_threads.so.0.7(JXL_0)(64bit) > > ffmpeg (maintained by: asn, ngompa, rathann) > ffmpeg-6.0-6.fc39.src requires pkgconfig(libjxl) = 0.7.0 > libavcodec-free-6.0-6.fc39.i686 requires libjxl.so.0.7, > libjxl.so.0.7(JXL_0), libjxl_threads.so.0.7, > libjxl_threads.so.0.7(JXL_0) > libavcodec-free-6.0-6.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit), libjxl_threads.so.0.7()(64bit), > libjxl_threads.so.0.7(JXL_0)(64bit) > > geeqie (maintained by: mattdm, zbyszek) > geeqie-2.0.1-4.fc38.src requires libjxl-devel = 1:0.7.0-6.fc38 > geeqie-2.0.1-4.fc38.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit) > > gimp (maintained by: jridky, nphilipp, zdohnal) > gimp-2:2.10.34-2.fc39.src requires libjxl-devel = 1:0.7.0-6.fc38 > gimp-2:2.10.34-2.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit), libjxl_threads.so.0.7()(64bit), > libjxl_threads.so.0.7(JXL_0)(64bit) > > gthumb (maintained by: alexl, caolanm, carlwgeorge, chkr, gnome-sig, > mbarnes, rhughes, rstrode) > gthumb-1:3.12.2-7.fc39.i686 requires libjxl.so.0.7, > libjxl.so.0.7(JXL_0), libjxl_threads.so.0.7, > libjxl_threads.so.0.7(JXL_0) > gthumb-1:3.12.2-7.fc39.src requires pkgconfig(libjxl) = 0.7.0 > gthumb-1:3.12.2-7.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit), libjxl_threads.so.0.7()(64bit), > libjxl_threads.so.0.7(JXL_0)(64bit) > > imlib2 (maintained by: awjb, leigh123linux, tdawson, tsmetana) > imlib2-1.11.1-1.fc39.i686 requires libjxl.so.0.7, > libjxl.so.0.7(JXL_0), > libjxl_threads.so.0.7, libjxl_threads.so.0.7(JXL_0) > imlib2-1.11.1-1.fc39.src requires libjxl-devel = 1:0.7.0-6.fc38 > imlib2-1.11.1-1.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit), libjxl_threads.so.0.7()(64bit), > libjxl_threads.so.0.7(JXL_0)(64bit) > > kf5-kimageformats (maintained by: jgrulich, kde-sig, rdieter, than) > kf5-kimageformats-5.107.0-1.fc39.i686 requires libjxl.so.0.7, > libjxl.so.0.7(JXL_0), libjxl_threads.so.0.7, > libjxl_threads.so.0.7(JXL_0) > kf5-kimageformats-5.107.0-1.fc39.src requires pkgconfig(libjxl) = > 0.7.0 > kf5-kimageformats-5.107.0-1.fc39.x86_64 requires > libjxl.so.0.7()(64bit), libjxl.so.0.7(JXL_0)(64bit), > libjxl_threads.so.0.7()(64bit), libjxl_threads.so.0.7(JXL_0)(64bit) > > krita (maintained by: heliocastro, kde-sig, rdieter) > krita-5.1.5-2.fc39.i686 requires libjxl.so.0.7, libjxl.so.0.7(JXL_0), > libjxl_threads.so.0.7, libjxl_threads.so.0.7(JXL_0) > krita-5.1.5-2.fc39.x86_64 requires libjxl.so.0.7()(64bit), > libjxl.so.0.7(JXL_0)(64bit), libjxl_threads.so.0.7()(64bit), > libjxl_threads.so.0.7(JXL_0)(64bit) > > seamonkey
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 11:22:35 +0200, Vít Ondruch wrote: > Right, not pushing to all branches is in line with official guidelines: > > https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases It's more nuanced than "don't push updates to all branches" though: ".. we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time." So minor/patch version updates, especially for things like Python packages that have frequent minor/patch releases is perfectly fine. > Especially I don't like my packages being FTBFS due to other packagers > pushing their updates everywhere. If there was at least included > mass-prebuild step in the initial list to ensure there is no breakage in > dependent packages. This is part of the "vetting the update before pushing" step. We have tools that package maintainers can/should use to see what packages depend on a particular one before updating it (fedrq is one I believe, but folks have their own dnf based scripts/commands). I've also filed an RFE to the-new-hotness to add dependency information to the "new package version is available" bug report some time ago, which would help ensure maintainers are aware of the update's impact: https://github.com/fedora-infra/the-new-hotness/issues/545 We're discussing a different topic now. The thread was "these steps are repetitive, how do folks automate them", and we're now discussing "maintainers should remember to check the impact of update before pushing them". -- 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
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 19 June (today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 19 June at 1300UTC in #fedora-neuro on Matrix or IRC (Libera.chat). The meeting is a public meeting, and open for everyone to attend. You can join us over: Matrix: https://matrix.to/#/#neuro:fedoraproject.org IRC: https://webchat.libera.chat/?channels=#fedora-neuro You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20230619T13=%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/06/19/next-open-neurofedora-meeting-19-June-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
Re: Releasing package updates in multiple Fedora releases
On 19-06-2023 11:04, Miroslav Suchý wrote: Dne 18. 06. 23 v 11:16 Mattia Verga via devel napsal(a): This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? I know several ways: 1) Tito https://github.com/rpm-software-management/tito This requires upstream modification. Namely .tito/releasers.conf https://github.com/rpm-software-management/tito/blob/master/.tito/releasers.conf Then you can (e.g. in the Tito git repo itself) run: tito release fedora or tito release copr and it will build the package in Fedora's Koji for all configured versions. Or in Copr. As you configure it. 2) Even better is Packit https://packit.dev/ You have many ways to use it. My favorite way is to use pull-from-upstream https://packit.dev/posts/pull-from-upstream/ You just make sure you have record in https://release-monitoring.org/ and then put .packit.yaml in Fedora's dist-git. And when upstream has a new release you will receive a pull request to src.fedoraproject.org for all configure branches. And when it merges it (can) build in Koji and submit Bodhi update for you. With Packit you can use full automation or only some steps. And combine it as you like it. If you do not like triggereing by release monitoring, you can initiate it from command line. It is up to you. Sounds like these tools are worth mentioning in the docs, seeing how many people face the same challenge. -- Sandro ___ 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: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 11:04:16 +0200, Miroslav Suchý wrote: > > 2) Even better is Packit > > https://packit.dev/ > > You have many ways to use it. My favorite way is to use pull-from-upstream > > https://packit.dev/posts/pull-from-upstream/ > > You just make sure you have record in https://release-monitoring.org/ and > then put .packit.yaml in Fedora's dist-git. And when upstream has a new > release you will receive a pull request to src.fedoraproject.org for all > configure branches. And when it merges it (can) build in Koji and submit > Bodhi update for you. > > With Packit you can use full automation or only some steps. And combine it > as you like it. If you do not like triggereing by release monitoring, you > can initiate it from command line. It is up to you. > This is awesome! I've been meaning to try Packit for a while now. Will try it asap. -- 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
Re: Releasing package updates in multiple Fedora releases
Right, not pushing to all branches is in line with official guidelines: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases Especially I don't like my packages being FTBFS due to other packagers pushing their updates everywhere. If there was at least included mass-prebuild step in the initial list to ensure there is no breakage in dependent packages. Vít Dne 19. 06. 23 v 9:22 Richard W.M. Jones napsal(a): On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: For the 99% of packages I maintain I usually perform the same workflow when updating them: 1. Update spec and source in Rawhide 2. commit and push 3. fedpkg build 4. fedpkg switch-branch f* 5. git merge rawhide 6. push and fedpkg build And repeat 4-5-6 for every f*/epel* branches where I want to push the update. This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? So one alternative is *not* to push the change to all branches. Unless it's really necessary, such as fixing an essential bug, I tend to leave older Fedora branches on a stable release, to reduce churn for users. eg: $ cd fedora/libnbd $ for f in f* rawhide ; do (cd $f && fedpkg verrel); done Using libnbd.spec libnbd-1.0.2-1.fc29 Using libnbd.spec libnbd-1.2.2-1.fc30 Using libnbd.spec libnbd-1.4.1-1.fc31 Using libnbd.spec libnbd-1.6.2-1.fc32 Using libnbd.spec libnbd-1.6.5-1.fc33 Using libnbd.spec libnbd-1.8.6-1.fc34 Using libnbd.spec libnbd-1.10.5-1.fc35 Using libnbd.spec libnbd-1.12.7-1.fc36 Using libnbd.spec libnbd-1.14.2-1.fc37 Using libnbd.spec libnbd-1.16.1-1.fc38 Using libnbd.spec libnbd-1.16.1-2.fc39 (Also note 'fedpkg clone -B' option to use a separate subdirectory for each branch, much more intuitive IMHO.) Rich. OpenPGP_signature Description: OpenPGP digital 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: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 08:46:47 -, Michael J Gruber wrote: > > On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: > > > > So one alternative is *not* to push the change to all branches. > > > > Unless it's really necessary, such as fixing an essential bug, I tend > > to leave older Fedora branches on a stable release, to reduce churn > > Exactly. Blindly pushing to all active releases is never a good idea. > Now, I'm not saying people here do that, but those shortcuts make it > too easy to do it in a rash ... > > In particular: Most proposals do it in the wrong order (old to new) > and some without error catching. You may end up with newer builds in > older releases - without an update yet, granted, but still. I think folks here on the list understand that each update needs to be vetted. Once it has been vetted and we know it can go to rawhide + other releases, it's nice to be able to do it quickly and move on to other packages. So shortcuts + automation is always welcome in cases where we know it's doing the right thing. -- 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
Re: Releasing package updates in multiple Fedora releases
On Mon, Jun 19, 2023 at 08:46:47AM -, Michael J Gruber wrote:
> > On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
> > (Also note 'fedpkg clone -B' option to use a separate subdirectory for
> > each branch, much more intuitive IMHO.)
>
> That creates a bunch of unrelated git repos. Maybe we should teach
> fedpkg to use current git's method for that, which is
> worktrees. That way you share not only the object store ("one fetch
> rules them all") but also config such as remote definitions (for
> forks) etc. The main worktree could be a main/rawhide checkout.
I actually thought it worked like this but I checked now and you're
right that it is creating multiple git repos. In practice it's not a
huge problem, but worktrees would be better.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Dne 18. 06. 23 v 11:16 Mattia Verga via devel napsal(a): This is quite boring and time wasting... is there a more efficient way to use my packaging time? Do you think fedpkg can be enhanced to have a single command which makes 4-5-6 to all specified branches? I know several ways: 1) Tito https://github.com/rpm-software-management/tito This requires upstream modification. Namely .tito/releasers.conf https://github.com/rpm-software-management/tito/blob/master/.tito/releasers.conf Then you can (e.g. in the Tito git repo itself) run: tito release fedora or tito release copr and it will build the package in Fedora's Koji for all configured versions. Or in Copr. As you configure it. 2) Even better is Packit https://packit.dev/ You have many ways to use it. My favorite way is to use pull-from-upstream https://packit.dev/posts/pull-from-upstream/ You just make sure you have record in https://release-monitoring.org/ and then put .packit.yaml in Fedora's dist-git. And when upstream has a new release you will receive a pull request to src.fedoraproject.org for all configure branches. And when it merges it (can) build in Koji and submit Bodhi update for you. With Packit you can use full automation or only some steps. And combine it as you like it. If you do not like triggereing by release monitoring, you can initiate it from command line. It is up to you. Miroslav -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys ___ 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: Releasing package updates in multiple Fedora releases
> On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
>
> So one alternative is *not* to push the change to all branches.
>
> Unless it's really necessary, such as fixing an essential bug, I tend
> to leave older Fedora branches on a stable release, to reduce churn
Exactly. Blindly pushing to all active releases is never a good idea. Now, I'm
not saying people here do that, but those shortcuts make it too easy to do it
in a rash ...
In particular: Most proposals do it in the wrong order (old to new) and some
without error catching. You may end up with newer builds in older releases -
without an update yet, granted, but still.
> ...
>
> (Also note 'fedpkg clone -B' option to use a separate subdirectory for
> each branch, much more intuitive IMHO.)
That creates a bunch of unrelated git repos. Maybe we should teach fedpkg to
use current git's method for that, which is worktrees. That way you share not
only the object store ("one fetch rules them all") but also config such as
remote definitions (for forks) etc. The main worktree could be a main/rawhide
checkout.
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
Re: Releasing package updates in multiple Fedora releases
On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote: > For the 99% of packages I maintain I usually perform the same workflow > when updating them: > > 1. Update spec and source in Rawhide > 2. commit and push > 3. fedpkg build > 4. fedpkg switch-branch f* > 5. git merge rawhide > 6. push and fedpkg build > > And repeat 4-5-6 for every f*/epel* branches where I want to push the > update. > > This is quite boring and time wasting... is there a more efficient way > to use my packaging time? Do you think fedpkg can be enhanced to have a > single command which makes 4-5-6 to all specified branches? So one alternative is *not* to push the change to all branches. Unless it's really necessary, such as fixing an essential bug, I tend to leave older Fedora branches on a stable release, to reduce churn for users. eg: $ cd fedora/libnbd $ for f in f* rawhide ; do (cd $f && fedpkg verrel); done Using libnbd.spec libnbd-1.0.2-1.fc29 Using libnbd.spec libnbd-1.2.2-1.fc30 Using libnbd.spec libnbd-1.4.1-1.fc31 Using libnbd.spec libnbd-1.6.2-1.fc32 Using libnbd.spec libnbd-1.6.5-1.fc33 Using libnbd.spec libnbd-1.8.6-1.fc34 Using libnbd.spec libnbd-1.10.5-1.fc35 Using libnbd.spec libnbd-1.12.7-1.fc36 Using libnbd.spec libnbd-1.14.2-1.fc37 Using libnbd.spec libnbd-1.16.1-1.fc38 Using libnbd.spec libnbd-1.16.1-2.fc39 (Also note 'fedpkg clone -B' option to use a separate subdirectory for each branch, much more intuitive IMHO.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ 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: Releasing package updates in multiple Fedora releases
On 19/06/2023 08:36, Mattia Verga via devel wrote:
I only need to find how to pass branch names to the alias, instead of
hardcoding them. From a quick search I need to create a function in
.bashrc rather than an alias.
Add to ~/.bashrc:
function fpr {
for i in f$(rpm -E %fedora) f$(($(rpm -E %fedora) - 1)) rawhide; do
fedpkg switch-branch $i
if [[ "$i" != "rawhide" ]]; then
git merge rawhide
fi
fedpkg push
fedpkg build --nowait
done
}
Usage:
cd ~/foo-bar
fpr
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
Il 19/06/23 08:26, Vitaly Zaitsev via devel ha scritto: > On 18/06/2023 14:51, Sandro wrote: >> Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb' >> alias would fail since no changes have been pushed to dist-git for koji >> to base a build on. > Good catch. Thanks: > > alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg > switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide > && git push" > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) Nice, thanks. I only need to find how to pass branch names to the alias, instead of hardcoding them. From a quick search I need to create a function in .bashrc rather than an alias. 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
Re: Releasing package updates in multiple Fedora releases
On 18/06/2023 17:42, Ankur Sinha wrote: I threw all the commands into a script with some optional arguments: Maybe this script can be added to fedora-packager? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Releasing package updates in multiple Fedora releases
On 18/06/2023 14:51, Sandro wrote: Aren't you missing the 'git push' (or 'fedpkg push')? IIRC, your 'fpb' alias would fail since no changes have been pushed to dist-git for koji to base a build on. Good catch. Thanks: alias fpm="fedpkg switch-branch f38 && git merge rawhide && fedpkg switch-branch f37 && git merge rawhide && fedpkg switch-branch rawhide && git push" -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
