Re: Election Status?
On Wed, May 24, 2023 at 6:35 PM Tom Stellard wrote: > I've filed a ticket here: > > https://pagure.io/Fedora-Council/tickets/issue/457 > > Thanks Kevin and Tom for getting this flagged as a Council ticket. -- *jwf* (*he/him*) || j...@redhat.com TZ=America/New_York (UTC-4) While I may be sending this email outside my normal office hours, I have no expectation to receive a reply outside yours. ___ 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: Election Status?
Hi Gary, hi all, Thanks for filing the Fedora Council ticket and flagging this. Ben trained me on the election process and transferred ACLs to me before his final day at Red Hat. I dropped the ball on continuity. I will run the elections this round. The timing with Red Hat Summit this week, the F38 release party next week, and ongoing Flock logistics ended up spilling over. On Wed, May 24, 2023 at 3:37 PM Tom Stellard wrote: > Maybe this has happened and I missed it, but it would nice if the Council > put > out a statement acknowledging the position has been eliminated and > explaining > what will happen next. > Matthew and I were working on something to share with the community and wanted to publish last week, but for several reasons, it hasn't been timely. I hope to have more in hand soon. -- *jwf* (*he/him*) || j...@redhat.com TZ=America/New_York (UTC-4) While I may be sending this email outside my normal office hours, I have no expectation to receive a reply outside yours. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-cd6dc8dccf wordpress-5.1.16-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-00ddf3658a dropbear-2017.75-3.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1388277bf4 chromium-113.0.5672.126-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-2455ae47ae godot-3.1.2-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing pgbouncer-1.19.0-1.el7 Details about builds: pgbouncer-1.19.0-1.el7 (FEDORA-EPEL-2023-cbd740d44d) Lightweight connection pooler for PostgreSQL Update Information: Update to 1.19.0. ChangeLog: * Wed May 24 2023 Simone Caronni - 1.19.0-1 - Update to 1.19.0. * Wed May 24 2023 Simone Caronni - 1.14.0-5 - Adjust python interpreter for mkauth.py. * Wed May 24 2023 Simone Caronni - 1.14.0-4 - Further cleanup. * Wed May 24 2023 Simone Caronni - 1.14.0-3 - Clean up SPEC file. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 69 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-78e9d2e031 dropbear-2019.78-5.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9f9a39afa5 editorconfig-0.12.6-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-2694488870 chromium-113.0.5672.126-1.el8 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-52d4a7be15 bitcoin-core-24.1-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing java-latest-openjdk-portable-20.0.1.0.9-4.rolling.el8 pack-0.30.0~pre2-1.el8 pgbouncer-1.19.0-2.el8 scorep-6.0-19.el8 Details about builds: java-latest-openjdk-portable-20.0.1.0.9-4.rolling.el8 (FEDORA-EPEL-2023-2e2d9da22d) OpenJDK 20 Runtime Environment portable edition Update Information: Introduction of java-latest-openjdk portable tarball for epel8. This update ensures the builds in epel are done in the same way as in Fedora. ChangeLog: * Thu May 18 2023 Petra Alice Mikova - 1:20.0.1.0.9-4.rolling - fix jdkportablename, jreportablename macro to apply also to epel - lower buildversion of jdk to 19 * Mon May 15 2023 Jiri Vanek - 1:20.0.1.0.9-3.rolling - no longer using system cacerts during build - they are already mv-ed as .upstream in rpms * Wed May 10 2023 Jiri Vanek - 1:20.0.1.0.9-2.rolling - enabled all crypto * Wed Apr 26 2023 Andrew Hughes - 1:20.0.1.0.9-1.rolling - Update to jdk-20.0.1+9 - Update release notes to 20.0.1+9 * Fri Apr 14 2023 Jiri Vanek - 1:20.0.0.0.36-3.rolling - introduced archfull src archive - replaced nasty handling of icons. - needed for icons and src reference for rpms (debuginfo, src subpkg) - licences moved to proper sharable noarch * Mon Apr 10 2023 Andrew Hughes - 1:20.0.0.0.36-2.rolling - Complete update to OpenJDK 20 - Update NEWS - Update system crypto policy & FIPS patch from new fips-20u tree - * RH2104724: Avoid import/export of DH private keys - * RH2092507: P11Key.getEncoded does not work for DH keys in FIPS mode - * Build the systemconf library on all platforms - Update generate_tarball.sh ICEDTEA_VERSION and add support for passing a boot JDK to the configure run - Revert changes to generate_tarball.sh which break error handling - Add POSIX-friendly error codes to generate_tarball.sh and fix whitespace - Remove .jcheck and GitHub support when generating tarballs, as done in upstream release tarballs - Revert changes to patch macro which break on older versions of rpm (4.16) - Revert changes to configure run - Revert RH1648429 patch changes - Update CLDR reference data following update to 42 (Rocky Mountain-Normalzeit => Rocky-Mountain-Normalzeit) - Re-enable disabled translation test - Automatically turn off building a fresh HotSpot first, if the bootstrap JDK is not the same major version as that being built * Tue Mar 28 2023 Jiri Vanek - 1:20.0.0.0.36-1.rolling - moved to jdk20 - remvoed already upstreamed patches patch2006,2007,2008,2009 - commented out not yet adapted patch1001 - fips support - removed --disable-sysconf-nss due to missing patch 1001 from configure -- todo return both patch1001 and disable-sysconf-nss! - adapted rh1648249-add_commented_out_nss_cfg_provider_to_java_security.patch and rh1750419-redhat_alt_java.patch patches - inverted fresh_libjvm behavior to be disabled by default. fails: -- See: https://koji.fedoraproject.org/koji/taskinfo?taskID=99242677 - commented out tzdata tests - moved from deprecated patchN to patch N * Tue Feb 7 2023 Jiri Vanel - 1:19.0.2.0.7-2.rolling - added png icons from x11 source package, so they can be reused by rpms * Thu Jan 26 2023 Andrew Hughes - 1:19.0.2.0.7-1.rolling - Update to jdk-19.0.2 release - Update release notes to 19.0.2 - Drop JDK-8293834 (CLDR update for Kyiv) which is now upstream - Drop JDK-8294357 (tzdata2022d), JDK-8295173 (tzdata2022e) & JDK-8296108 (tzdata2022f) local patches which are now upstream - Drop JDK-8296715 (CLDR update for 2022f) which is now upstream - Add local patch JDK-8295447 (javac NPE) which was accepted into 19u upstream but not in the GA tag - Add local patches for JDK-8296239 & JDK-8299439 (Croatia Euro update) which are present in 8u, 11u & 17u releases * Thu Jan 19 2023 Andrew Hughes - 1:19.0.1.0.10-3.rolling - Update in-tree tzdata & CLDR to 2022g with JDK-8296108, JDK-8296715 & JDK-8297804 - Update TestTranslations.java to test the new America/Ciudad_Juarez zone * Thu Jan 19 2023 Stephan Bergmann - 1:19.0.1.0.10-3.rolling - Fix flatpak builds by disabling TestTranslations test due to missing tzdb.dat * Thu Jan 19
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-734a94ae05 dropbear-2020.80-7.el9 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-6fba4b91e0 chromium-113.0.5672.126-1.el9 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5521054c04 bitcoin-core-24.1-1.el9 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-26dc71c550 wordpress-6.2.2-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing blender-3.3.7-1.el9 composer-2.5.7-1.el9 pack-0.30.0~pre2-1.el9 pgbouncer-1.19.0-2.el9 php-nikic-php-parser4-4.15.5-1.el9 Details about builds: blender-3.3.7-1.el9 (FEDORA-EPEL-2023-d1bd9a3c87) 3D modeling, animation, rendering and post-production Update Information: New update to version 3.3.7 long term release. ChangeLog: * Wed May 24 2023 Luya Tshimbalanga - 1:3.3.7-1 - Update to 3.3.7 composer-2.5.7-1.el9 (FEDORA-EPEL-2023-e6194ecd57) Dependency Manager for PHP Update Information: **Version 2.5.7** - 2023-05-24* Fixed regression preventing autoloading the dependencies of metapackages when running --no-dev (#11481) **Version 2.5.6** - 2023-05-24* BC Warning: Installers and `InstallationManager::getInstallPath` will now return `null` instead of an empty string for metapackages' paths. This may have adverse effects on plugin code using this expecting always a string but it is unlikely (#11455) * Fixed metapackages showing their install path as the root package's path instead of empty (#11455) * Fixed lock file verification on `install` to deal better with `replace`/`provide` (#11475) * Fixed lock file having a more recent modification time than the vendor dir when `require` guesses the constraint after resolution (#11405) * Fixed numeric default branches with a `v` prefix being treated as non-numeric ones and receiving an alias like e.g. dev-main would (e51d755a08) * Fixed binary proxies not being transparent when included by another PHP process and returning a value (#11454) * Fixed support for plugin classes being marked as `readonly` (#11404) * Fixed `getmypid` being required as it is not always available (#11401) * Fixed authentication issue when downloading several files from private Bitbucket in parallel (#11464) ChangeLog: * Wed May 24 2023 Remi Collet - 2.5.7-1 - update to 2.5.7 * Wed May 24 2023 Remi Collet - 2.5.6-1 - update to 2.5.6 pack-0.30.0~pre2-1.el9 (FEDORA-EPEL-2023-8b1e021021) Convert code into runnable images Update Information: auto bump to v0.30.0-pre2 ChangeLog: * Tue May 23 2023 RH Container Bot - 0.30.0~pre2-1 - auto bump to v0.30.0-pre2 * Mon Apr 3 2023 Lokesh Mandvekar - 0.30.0~pre1-2 - fix build dir * Thu Mar 30 2023 RH Container Bot - 0.30.0~pre1-1 - auto bump to v0.30.0-pre1 * Fri Mar 24 2023 RH Container Bot - 0.29.0-1 - auto bump to v0.29.0 pgbouncer-1.19.0-2.el9 (FEDORA-EPEL-2023-a59d920379) Lightweight connection pooler for PostgreSQL Update Information: Update to version 1.19.0. ChangeLog: * Wed May 24 2023 Simone Caronni - 1.19.0-2 - Adjust python interpreter for mkauth.py. * Wed May 24 2023 Simone Caronni - 1.19.0-1 - Update to 1.19.0. - Clean up SPEC file. php-nikic-php-parser4-4.15.5-1.el9 (FEDORA-EPEL-2023-66d6eb834e) A PHP parser written in PHP - version 4 Update Information: **Version 4.15.5** (2023-05-19) Added * Added `makePrivate()`, `makeProtected()`, `makePublic()` and `makeReadonly()` methods
Re: Election Status?
On Wed, May 24, 2023 at 9:50 PM Mattia Verga via devel wrote: > Wait, what?? Someone at RH wakes up in the morning and decides to cut > one of the key roles (or better, THE) of Fedora community and this goes > completely unannounced, unnoticed and without any backup plan? I do understand why RedHat itself will not announce who got laid off, but the Council members should have been informed (I hope!) at the time, and should have worked on an announcement to the community, even if all they could say was "stay tuned, we are working it out". I would like to believe this will be a learning opportunity for the Council to improve their communications for the next time something impacts their group (and the Fedora community). ___ 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On 5/24/23 08:44, Zdenek Kabelac wrote: > Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a): >> I noticed that by default, Qubes OS has voluntary kernel preemption >> as opposed to full preemption. I found that enabling full preemption >> (preempt=full on kernel command line) makes the system significantly >> more responsive under heavy I/O load. In particular, if I build a >> kernel in a Qubes OS VM, it significantly degrades responsiveness >> without preempt=full. With preempt=full, the system remains >> responsive. The storage stack used is LVM thin provisioning on LUKS, >> and I have observed significant CPU usage in dom0 kernel threads with >> names that indicate they are related to dm-thin and dm-crypt. >> >> The kernel config used by the Qubes kernel package I use (6.1.28) is >> based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) >> indicated that the same arguments apply to Fedora. Therefore, I am >> asking if Fedora should use full kernel preemption by default. > > > Hi Demi > > > Could you please provide 'dmsetup table' - so we could see how doe your > device stack looks like ? The output of 'dmsetup table' contains all qube names so I would prefer to not post it publicly. The device stack is NVMe -> crypt -> linear -> thin pool -> thin. > Aren't you disabling work-queues on the table line for crypt targets ? The only optional parameter passed to dm_crypt is allow_discards, so presumably no. -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key 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: Election Status?
On 5/24/23 13:00, Kevin Fenzi wrote: On Wed, May 24, 2023 at 12:36:58PM -0700, Tom Stellard wrote: On 5/24/23 12:31, Gary Buhrmaster wrote: On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. I agree with this. Maybe this has happened and I missed it, but it would nice if the Council put out a statement acknowledging the position has been eliminated and explaining what will happen next. Going back to the original topic, though, what is the best way to raise the issue of the elections being delayed, should I file a ticket for the Council? just as a note, our FPL (Fedora Project Leader) (Matthew) and FCA (Fedora community architect) (Justin) are both at Red Hat summit this week. So yeah, likely they are aware, but busy... but I guess a council ticket would be good to make sure. I've filed a ticket here: https://pagure.io/Fedora-Council/tickets/issue/457 -Tom kevin ___ 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: Election Status?
On 5/24/23 4:49 PM, Mattia Verga via devel wrote: Wait, what?? Someone at RH wakes up in the morning and decides to cut one of the key roles (or better, THE) of Fedora community and this goes completely unannounced, unnoticed and without any backup plan? I have seen other dumb decisions by RH about Fedora in the past, but I think this is the greatest one, both for Ben's role and for their person. I totally agree. I am pretty upset that they chose to let bcotton go. His work was top notch and I will miss him and his contributions. Losing him as the Fedora Program Manager is going to be very impacting to the project in the short to medium term. We are already seeing things fall through the cracks. What a short-sighted decision. Also finding out about this in a random thread is a bummer. There should have been an announcement. To the RH powers that be that made this decision. You chuckleheads dun goofed. Joe -- Joe Doss j...@solidadmin.com ___ 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: Election Status?
Il 24/05/23 21:19, Josh Boyer ha scritto: > On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: >> >> >>> Am 24.05.2023 um 20:30 schrieb Chris Murphy : >>> >>> I'm pretty sure we no longer have a program manager? >> What’s that about? > Red Hat recently announced a round of layoffs[1] and the Fedora > Program Manager role was impacted. > > Ben posted this blog: > https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ > > josh > > [1] https://www.redhat.com/en/blog/message-red-hat-associates-today Wait, what?? Someone at RH wakes up in the morning and decides to cut one of the key roles (or better, THE) of Fedora community and this goes completely unannounced, unnoticed and without any backup plan? I have seen other dumb decisions by RH about Fedora in the past, but I think this is the greatest one, both for Ben's role and for their person. 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: Election Status?
On Wed, May 24, 2023 at 12:36:58PM -0700, Tom Stellard wrote: > On 5/24/23 12:31, Gary Buhrmaster wrote: > > On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: > > > > > What's the process for selecting a new Program Manager? > > > > From the words that have been shared at: > > https://docs.fedoraproject.org/en-US/council/fpgm/ > > the position itself has been eliminated. > > > > The important responsibilities will (presumably) > > need to be passed to others on the Fedora Council, > > who will likely need to triage some of their current > > work to make room. > > > > I hope the Fedora Council members will soon > > share the updated roles and responsibilities > > of the remaining members. > > I agree with this. > > Maybe this has happened and I missed it, but it would nice if the Council put > out a statement acknowledging the position has been eliminated and explaining > what will happen next. > > Going back to the original topic, though, what is the best way to > raise the issue of the elections being delayed, should I file a ticket for > the Council? just as a note, our FPL (Fedora Project Leader) (Matthew) and FCA (Fedora community architect) (Justin) are both at Red Hat summit this week. So yeah, likely they are aware, but busy... but I guess a council ticket would be good to make sure. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
On 5/24/23 12:31, Gary Buhrmaster wrote: On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. I agree with this. Maybe this has happened and I missed it, but it would nice if the Council put out a statement acknowledging the position has been eliminated and explaining what will happen next. Going back to the original topic, though, what is the best way to raise the issue of the elections being delayed, should I file a ticket for the Council? -Tom ___ 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: Election Status?
On Wed, May 24, 2023 at 7:23 PM Tom Stellard wrote: > What's the process for selecting a new Program Manager? From the words that have been shared at: https://docs.fedoraproject.org/en-US/council/fpgm/ the position itself has been eliminated. The important responsibilities will (presumably) need to be passed to others on the Fedora Council, who will likely need to triage some of their current work to make room. I hope the Fedora Council members will soon share the updated roles and responsibilities of the remaining members. ___ 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: Election Status?
On Wed, May 24, 2023 at 3:23 PM Tom Stellard wrote: > > On 5/24/23 12:19, Josh Boyer wrote: > > On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: > >> > >> > >> > >>> Am 24.05.2023 um 20:30 schrieb Chris Murphy : > >>> > >>> I'm pretty sure we no longer have a program manager? > >> > >> What’s that about? > > > > Red Hat recently announced a round of layoffs[1] and the Fedora > > Program Manager role was impacted. > > > > Ben posted this blog: > > https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ > > > > What's the process for selecting a new Program Manager? The Fedora Program Manager was a paid Red Hat position before. We do not have a process defined for selecting one from the community. There are a few people trying to spread the responsibilities around in the meantime. josh ___ 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: Election Status?
On 5/24/23 12:19, Josh Boyer wrote: On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: Am 24.05.2023 um 20:30 schrieb Chris Murphy : I'm pretty sure we no longer have a program manager? What’s that about? Red Hat recently announced a round of layoffs[1] and the Fedora Program Manager role was impacted. Ben posted this blog: https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ What's the process for selecting a new Program Manager? -Tom josh [1] https://www.redhat.com/en/blog/message-red-hat-associates-today ___ 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: Election Status?
On Wed, May 24, 2023 at 2:55 PM Peter Boy wrote: > > > > > Am 24.05.2023 um 20:30 schrieb Chris Murphy : > > > > I'm pretty sure we no longer have a program manager? > > What’s that about? Red Hat recently announced a round of layoffs[1] and the Fedora Program Manager role was impacted. Ben posted this blog: https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/ josh [1] https://www.redhat.com/en/blog/message-red-hat-associates-today ___ 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: Election Status?
On Wed, May 24, 2023, at 2:55 PM, Peter Boy wrote: >> Am 24.05.2023 um 20:30 schrieb Chris Murphy : >> >> I'm pretty sure we no longer have a program manager? > > What’s that about? As I understand it, part of recent Red Hat layoffs. Red Hat and Fedora program/project managers were impacted. And also no emails or matrix messages from Ben Cotton in two weeks. He is the one who announces elections and sets up that whole system, reports the results, updates everything related to the subsequent changes, etc. That's all I know. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
On Tue, May 23, 2023, at 1:08 AM, Jens-Ulrik Petersen wrote: > On Tue, May 23, 2023 at 12:47 PM Neal Gompa wrote: >> I actually would prefer that we color both, and make it obvious that >> "root" is special. We should account for common color-blindness >> issues, though. > > Sure, I think I agree: perhaps purple for root? I think if we avoid the need to distinguish between redish and greenish, it's OK. Redish includes red, pink, magenta. Greenish includes green, cyan, sky blue. Ergo, you can use green or red, you just don't want to make the A vs B red and green because they will look the same to anyone with a red/green color discrimination limitation. Much less common is blue/yellow. I don't have data handy but off the top of my head, tritonopia and tritonomaly cases will notice the difference between purple vs orange OK. We do have publicly available math to predict the discrimination of various nopias and nomalies; I'm not sure exactly how it's implemented in GIMP but there is a "color deficient vision" filter should give an adequate idea whether or not a design has expected/sufficient/desired differentiation of elements based on color. (We don't actually know what anyone's color experience is, as it turns out. That's what I mean by this.) https://docs.gimp.org/2.10/en/gimp-display-filter-dialog.html > > I am all for "color blind testing" (though I am not completely sure that > "color-blind" is the right term here > though I am not an a11y expert - I thought color blind is more about > differentiating different colors like green and red, > but if you mean visual impairment/contrast/readability then I completely > agree). It's common vernacular. But it's more interesting than this term because it suggests one variety or effect. There are more than several. If we consider "color blind" means total lack of color discrimination, or monochromat - they are rare. I don't even know the number. Dichromats are much more common, where these are broken down into whether it's the long, medium, or short wavelngth cone is missing (entirely). The world does have some color, we think, at least there's discrimination possible. But it's of course limited without a third color receptor. Quite a lot more common are tricromats with anomalous spectral sensitivity of one of the receptors, i.e. the long wavelength cone might be green shifted, so it's more sensitive to yellows than the "standard observer". This then questions the whole age old concept of the standard observer, and for a while now it's been suspected we need more than one standard observer - because, well, they did all these tests in the early 1900's with something like 50 people. Seriously. And that's the data still largely used today. Anyway... I tend to call it a color discrimination variance. Or limitation. Oh and there are such folks as quadchromats. They have four color receptors. And then still there's the entire non-human animal kingdom full of completely different receptor peak wavelenth sensitivities, including tetrachromats and pentachromats. > I think in the end it will come down also to wider user testing since there > are so many different terminals > and color palettes around. > > Anyway that's why I proposed green since it seems to have reasonable contrast > for both light and dark terminals (unlike blue/cyan/yellow often). > I assume that may also be why Ubuntu and Nixos went with green. Green is an efficient color choice. It tends to appear to the brightest. Part of this relates to the luminosity function of human vision which has a peak wavelength that happens to be the same as the medium wavelength photo receptor (i.e. green). So given the same amount of radiant energy emitted across the visible spectrum, green will appear to be the brightest. Light purple is OK, Blue, indigo, or yellow tends to be harder to to detect complex shapes (like letters and numbers) but I'm not sure of the reason(s). -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
> Am 24.05.2023 um 20:30 schrieb Chris Murphy : > > I'm pretty sure we no longer have a program manager? What’s that about? -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[CoreOS] Fedora CoreOS Meeting Minutes 2023-05-24
#fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:29:48 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2023-05-24/fedora_coreos_meeting.2023-05-24-16.29.log.html . Meeting summary --- * roll call (dustymabe, 16:29:54) * Action items from last meeting (dustymabe, 16:35:18) * there was no need for jlebon to open a ticket for rpm-ostree dnf5 investigation because one already existed at https://github.com/coreos/rpm-ostree/issues/2139 (dustymabe, 16:35:35) * dustymabe opened a ticket to track us updating our RPMs to be SPDX compatible in https://github.com/coreos/fedora-coreos-tracker/issues/1497 (dustymabe, 16:35:42) * there was already a libdnf tracker issue at https://github.com/coreos/rpm-ostree/issues/2139 (jlebon, 16:35:57) * Enable libostree automatic early pruning (dustymabe, 16:38:53) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1495 (dustymabe, 16:38:58) * AGREED: We'll enable ostree autopruning for aarch64 in next for at least 3 cycles (6 weeks) then promote to testing. We'll enable it for ppc64le right away for the streams that we decide to release ppc64le for. (dustymabe, 17:17:14) * docs re-organize sections (dustymabe, 17:17:23) * LINK: https://github.com/coreos/fedora-coreos-docs/pull/538 (dustymabe, 17:17:26) * LINK: https://docs.fedoraproject.org/en-US/fedora-coreos/storage/ > The storage page is very long for example and has "unrelated" content (travier, 17:20:52) * AGREED: We like the nested topics idea from travier and have given him a lot of feedback on possible options. (dustymabe, 17:31:15) * open floor (dustymabe, 17:31:53) * LINK: https://accounts.fedoraproject.org/group/coreos/ and https://accounts.fedoraproject.org/group/sysadmin-coreos/ (bgilbert, 17:32:21) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1487 (quentin9696[m], 17:34:24) * LINK: https://github.com/coreos/fedora-coreos-docs/issues/286 (travier, 17:40:47) * fifofonix and I are thinking of doing a "How do you Fedora CoreOS?" session at the F38 release party next week. (dustymabe, 17:43:19) Meeting ended at 17:44:24 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (123) * bgilbert (50) * jlebon (49) * travier (32) * zodbot (26) * jdoss (21) * quentin9696[m] (14) * apiaseck (6) * ravanelli (2) * jmarrero (2) * marmijo[m] (1) * JasonBrooks[m] (1) * fifofonix (1) * mnguyen (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Election Status?
On Wed, May 24, 2023, at 12:03 PM, Tom Stellard wrote: > Hi, > > According to the schedule[1], the voting period was supposed to begin > on Friday, but elections.fedoraproject.org does not list any open elections > yet. Does anyone have an ETA for when voting will start? I'm pretty sure we no longer have a program manager? So I'm kinda expecting a lot of things to just silently break. I don't know what the fallback plan is. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On Sat, May 20, 2023, at 4:43 PM, Demi Marie Obenour wrote: Therefore, I am > asking if Fedora should use full kernel preemption by default. https://pagure.io/fedora-workstation/issue/228 The outstanding questions: a. Do we need some tests that help decide this with metrics? If so what should those be? b. Should it be restricted to the desktop edition/spins? Or Fedora wide? c. How do we make the change? I have no ideas for a.) and I don't know what would be a sufficient sample of workloads across all of Fedora; or whether to separately test the different editions. I think if the answer to b.) is it should be Fedora-wide, means there's more pressure to answer yes to a.) Whereas if it's focused on desktops, perhaps less testing is needed? Still another strategy might be to just make preempt full the default Fedora wide in Rawhide with enough advance notice (like, nowish or soon after Fedora 39 branches). And once it starts causing issues, revert. That's a bit spaghetti on the wall test strategy but it's also cheap. (I am aware this is not a good strategy for testing doneness of spaghetti.) Regarding c.) gets tricky if it's not Fedora wide. The simplest case is, the change applies only to desktops, everything else remains on voluntary. The only way I'm aware of we can change it on the desktops is to set a kernel parameter. This means we need to have Anaconda set it as a boot parameter, but only for desktops. There is a debugfs facility for changing it during runtime, but this is not reliable due to debugfs being disabled when kernel lockdown is in place, which is tied to Secure Boot being enabled. Hence, the lkml thread referenced in the issue. But the lkml thread went no where (no responses). Possibly it wasn't provocative enough. Or simply there are no plans to expose this switch anywhere else. https://lkml.org/lkml/2023/4/11/1291 Conversely if even two other Fedora editions/spins/variants want some kind of opt out or opt in, it quickly gets tricky to do all that unique work setting a boot parameter, rather than just flipping the default across the board and not having a boot parameter. Anyway, it seems like it would be semi-straightforward to do it in Anaconda just for desktops using kickstart `bootloader --append=` command. https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootloader -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)
On Tue, May 9, 2023 at 11:52 AM Kevin Fenzi wrote: > Just a general answer/info here at the bottom of the thread... > > I realize our container build pipeline is not great, but it's currently > working and I will keep it working until we replace it. > > I agree we should replace it, and there's lots of options, but I don't > think this thread is the place to go back and forth about them. > > I know of at least kiwi, osbuild, some other build systems that don't > fully exist yet, switching to use quay.io, osbs2 (based on openshift4), > and probibly others. > What if we made the Toolbox container image just one more base image and built it with ImageFactory? - Integrated into the compose process - Across all architectures - No OSBS dependency The main disadvantage is that it is no longer layered, so *if* you happen to have the exact same Fedora image version around for some other reason (a big if), you save a fraction of space: Fedora 38 container - 71M compressed, 201M uncompressed Toolbox add-on layer - 232M compressed, 753M uncompressed Toolbox squashed - 291M compressed, 884M uncompressed But generally seems like it would be a win. osbuild/kiwi/whatever can be left as a separate project. - Owen ___ 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 2184385] perl-Date-ICal-2.682 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2184385 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Date-ICal-2.681 is |perl-Date-ICal-2.682 is |available |available --- Comment #5 from Upstream Release Monitoring --- Releases retrieved: 2.682 Upstream release that is considered latest: 2.682 Current version/release in rawhide: 2.679-2.fc38 URL: http://search.cpan.org/dist/Date-ICal/ 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/2783/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Date-ICal -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2184385 ___ 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 2184385] perl-Date-ICal-2.682 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2184385 --- Comment #7 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Date-ICal-2.682-1.fc38.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=101517337 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2184385 ___ 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 2184385] perl-Date-ICal-2.682 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2184385 --- Comment #6 from Upstream Release Monitoring --- Created attachment 1966650 --> https://bugzilla.redhat.com/attachment.cgi?id=1966650=edit Update to 2.682 (#2184385) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2184385 ___ 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
Election Status?
Hi, According to the schedule[1], the voting period was supposed to begin on Friday, but elections.fedoraproject.org does not list any open elections yet. Does anyone have an ETA for when voting will start? Thanks, Tom [1] https://fedorapeople.org/groups/schedule/f-38/f-38-elections-tasks.html ___ 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: Status of the forge macros?
If the need to package a snapshot goes away
'need' is certainly one right operative question.
whose?
Redhat's?
official Fedora packaging's?
"just us COPR users"?
i'm in the last camp.
i build/package to scratch my own projects' requirements' itch(es).
here's one, below, that depends on forge macros, making the build
manageable/trivial
no, i don't expect this to be used by anyone else, especially not official
packaging
but, without the ease/convenience forge macros, the cost of building here rises
quickly
-
%{?_pgnd_macros}
%global _owner pgnd
%global _build_timestamp %( date +%%Y%%m%%d_%%H%%M%%S --utc )
%bcond_without testcondition 1
%define _ngx_namenginx
%define _ngx_comment Nginx Web Server
%define _ngx_version 1.25.0
%define _modsecurity_version 1.0.3
%define _ngx_usr wwwrun
%define _ngx_grp www
%define _ngx_prefix /usr/local/nginx
%define _ngx_logdir /var/log/nginx
%define _ngx_confdir /usr/local/etc/ORIG-nginx
%define _ngx_moddir /usr/local/nginx-modules
%define _ngx_tmpdir %{_localstatedir}/lib/nginx/tmp
%define _ngx_cc /usr/bin/gcc
%define _ngx_cpp /usr/bin/cpp
%define _ngx_debug_flags -Wp,-D_FORTIFY_SOURCE=2
%global forgeurl0 https://github.com/nginx/nginx
Version: %{_ngx_version}
%global tag0 release-%{version}
%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global branch1 master
%global forgeurl4 https://github.com/leev/ngx_http_geoip2_module
%global branch4 master
%global forgeurl5 https://github.com/vision5/ngx_devel_kit
%global branch5 master
%global forgeurl8 https://github.com/google/ngx_brotli
%global branch8 master
%global forgeurl9 https://github.com/nginx/njs
%global branch9 master
%global forgeurl11 https://github.com/GetPageSpeed/ngx_security_headers
%global branch11 master
%global forgeurl12 https://github.com/nulab/nginx-length-hiding-filter-module
%global branch12 master
%global forgeurl13 https://github.com/GetPageSpeed/ngx_immutable
%global branch13 master
%global forgeurl14 https://github.com/SpiderLabs/ModSecurity-nginx
%global tag14 v%{_modsecurity_version}
%forgemeta -i -a
%global dist .%{_owner}_%{_build_timestamp}.fc%{fedora}
Name: %{_ngx_name}
Release: 0%{?dist}
Summary: %{_ngx_comment}
License: BSD-2-Clause
URL: %{forgeurl0}
Source0: %{forgesource0}
Source1: %{forgesource1}
Source4: %{forgesource4}
Source5: %{forgesource5}
Source8: %{forgesource8}
Source9: %{forgesource9}
Source11: %{forgesource11}
Source12: %{forgesource12}
Source13: %{forgesource13}
Source14: %{forgesource14}
Source100: https://nginx.org/en/CHANGES
Source101: https://nginx.org/LICENSE
BuildRequires: brotli-devel
BuildRequires: coreutils
BuildRequires: gcc
BuildRequires: gd-devel
BuildRequires: git
BuildRequires: grep
BuildRequires: gnupg2
BuildRequires: libatomic_ops-devel
BuildRequires: libmaxminddb-devel
BuildRequires: libmodsecurity-devel
BuildRequires: libxml2-devel
BuildRequires: libxslt-devel
BuildRequires: make
BuildRequires: openssl-devel
BuildRequires: pcre2-devel
BuildRequires: perl-ExtUtils-Embed
BuildRequires: perl-generators
BuildRequires: pkgconf-pkg-config
BuildRequires: zlib-devel
Requires: nginx-filesystem
Requires: libmodsecurity
Requires: mod_security_crs
Requires: openssl
Requires: pcre2
BuildRequires: systemd
Requires(post):systemd
Requires(preun): systemd
Requires(postun): systemd
Provides: webserver
Conflicts: nginx-core
Conflicts: nginx-mimetypes
Obsoletes: nginx< %{_ngx_version}
Obsoletes: nginx-filesystem < %{_ngx_version}
%description
%{_ngx_comment}
%package filesystem
Summary: nginx directory layout
BuildArch: noarch
Requires(pre): shadow-utils
%description filesystem
nginx directory layout
dummy, to satisfy php-fpm reqt and prevent pulling distro pkg
%prep
%forgesetup -a
cp %{SOURCE100} %{SOURCE101} .
%build
export CFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export CPPFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export CXXFLAGS="%{_CFLAGS} -Wno-dangling-pointer"
export LDFLAGS="%{_LDFLAGS} -Wno-dangling-pointer"
export DESTDIR=%{buildroot}
cd %{_builddir}/%{name}-%{tag0}
export LUAJIT_LIB=""
export LUAJIT_INC=""
./auto/configure \
--with-debug \
--build="PGNd Custom Build" \
--user=%{_ngx_usr} --group=%{_ngx_grp} \
--prefix=%{_ngx_prefix} \
--conf-path=%{_ngx_confdir}/nginx.conf \
--error-log-path=%{_ngx_logdir}/main.error.log \
--http-log-path=%{_ngx_logdir}/main.access.log \
--modules-path=%{_ngx_moddir} \
--http-client-body-temp-path=%{_ngx_tmpdir}/client_body \
--http-proxy-temp-path=%{_ngx_tmpdir}/proxy \
Re: Status of the forge macros?
On Wed, May 24, 2023 at 11:13:15AM -0400, Ben Beasley wrote:
> In your example, the forge macros simplify the spec file only because a
> snapshot is involved; but the forge macros put the snapshot info in the
> Release field, which is still permissible but deprecated[1].
>
> Without the forge macros, the spec file would admittedly be a little more
> complex. I would probably do something like the following:
>
> %global commit 791953030836d39687688a8e7f1a3e708892cfa1
> %global snapdate 20230420
>
> Version: 1.2^%{snapdate}git%(echo '%{commit}' | cut -b -7)
> Release: 1%{?dist}
Minor comment:
%(c=%{commit}; echo ${c:0:7})
is a bit nicer because it doesn't require 'cut', it just uses 'echo',
which is a shell builtin.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Status of the forge macros?
In your example, the forge macros simplify the spec file only because a
snapshot is involved; but the forge macros put the snapshot info in the Release
field, which is still permissible but deprecated[1].
Without the forge macros, the spec file would admittedly be a little more
complex. I would probably do something like the following:
%global commit 791953030836d39687688a8e7f1a3e708892cfa1
%global snapdate 20230420
Version: 1.2^%{snapdate}git%(echo '%{commit}' | cut -b -7)
Release: 1%{?dist}
URL: https://github.com/riscv/opensbi
Source: %{url}/archive/%{commit}/opensbi-%{commit}.tar.gz
%prep
%autosetup -n opensbi-%{commit}
If the need to package a snapshot goes away, then the utility of the forge
macros does too, as the packaging without them is perhaps even simpler than
wirh them:
Version: 1.2.12345
Release: 1%{?dist}
URL: https://github.com/riscv/opensbi
Source: %{url}/archive/v%{version}/opensbi-%{version}.tar.gz
%prep
%autosetup
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#traditional-versioning
On Wed, May 24, 2023, at 9:32 AM, Richard W.M. Jones wrote:
> On Wed, May 24, 2023 at 09:56:30AM +0200, Vitaly Zaitsev via devel wrote:
>> On 23/05/2023 19:27, Richard W.M. Jones wrote:
>> >... so today I was taking part in a package review which uses these
>> >macros and was surprised to be told that they are deprecated.
>>
>> Their author left Fedora a few years ago. They're now unmaintained
>> and may be removed soon (see FPC ticket[1]).
>>
>> [1]: https://pagure.io/packaging-committee/pull-request/1270
>
> So the issue for me is I'm considering a new package (opensbi). It is
> greatly(?) simplified by using the forge macros. Nothing in official
> documentation says that new packages shouldn't use the forge macros,
> although the link above would add such a statement. There seems to be
> disagreement in this thread about the best way forwards.
>
> Proposed spec:
> http://git.annexia.org/?p=fedora-reviews.git;a=blob;f=opensbi/opensbi.spec
>
> 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
___
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 2208828] perl-Crypt-URandom-0.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2208828 --- Comment #10 from Fedora Update System --- FEDORA-2023-4194a84c82 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-4194a84c82` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-4194a84c82 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2208828 ___ 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: Obsolete of DNF by DNF5 in RAWHIDE
V Wed, May 24, 2023 at 02:34:57PM +0100, Richard W.M. Jones napsal(a): > On Wed, May 24, 2023 at 09:40:40AM +0200, Jaroslav Mracek wrote: > > I have great news that the upcoming release of DNF5 will obsolete DNF in > > rawhide (Fedora 39). The release is planned not before the end of May. The > > change was already announced in https://fedoraproject.org/wiki/Changes/ > > ReplaceDnfWithDnf5. > > This is quite an ambitious schedule. Bugs filed yesterday against > packages using dnf, for a change that is planned in 7 days time. If I understand the change correctly, packages are expected to RPM-depend on "dnf5", but to execute "dnf" command. That means the bugs are not actionable until the change is implemented in dnf5. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Obsolete of DNF by DNF5 in RAWHIDE
On Wed, May 24, 2023 at 09:40:40AM +0200, Jaroslav Mracek wrote: > Hello, > > I have great news that the upcoming release of DNF5 will obsolete DNF in > rawhide (Fedora 39). The release is planned not before the end of May. The > change was already announced in https://fedoraproject.org/wiki/Changes/ > ReplaceDnfWithDnf5. This is quite an ambitious schedule. Bugs filed yesterday against packages using dnf, for a change that is planned in 7 days time. And 'dnf download' is not as featureful as the old version of dnf so it really does require deeper changes to supermin. 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: Status of the forge macros?
On Wed, May 24, 2023 at 09:56:30AM +0200, Vitaly Zaitsev via devel wrote: > On 23/05/2023 19:27, Richard W.M. Jones wrote: > >... so today I was taking part in a package review which uses these > >macros and was surprised to be told that they are deprecated. > > Their author left Fedora a few years ago. They're now unmaintained > and may be removed soon (see FPC ticket[1]). > > [1]: https://pagure.io/packaging-committee/pull-request/1270 So the issue for me is I'm considering a new package (opensbi). It is greatly(?) simplified by using the forge macros. Nothing in official documentation says that new packages shouldn't use the forge macros, although the link above would add such a statement. There seems to be disagreement in this thread about the best way forwards. Proposed spec: http://git.annexia.org/?p=fedora-reviews.git;a=blob;f=opensbi/opensbi.spec 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: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a): I noticed that by default, Qubes OS has voluntary kernel preemption as opposed to full preemption. I found that enabling full preemption (preempt=full on kernel command line) makes the system significantly more responsive under heavy I/O load. In particular, if I build a kernel in a Qubes OS VM, it significantly degrades responsiveness without preempt=full. With preempt=full, the system remains responsive. The storage stack used is LVM thin provisioning on LUKS, and I have observed significant CPU usage in dom0 kernel threads with names that indicate they are related to dm-thin and dm-crypt. The kernel config used by the Qubes kernel package I use (6.1.28) is based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) indicated that the same arguments apply to Fedora. Therefore, I am asking if Fedora should use full kernel preemption by default. Hi Demi Could you please provide 'dmsetup table' - so we could see how doe your device stack looks like ? Aren't you disabling work-queues on the table line for crypt targets ? Regards Zdenek ___ 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: 20230524.n.0 changes
OLD: Fedora-Rawhide-20230523.n.1 NEW: Fedora-Rawhide-20230524.n.0 = SUMMARY = Added images:2 Dropped images: 7 Added packages: 1 Dropped packages:0 Upgraded packages: 49 Downgraded packages: 0 Size of added packages: 174.69 KiB Size of dropped packages:0 B Size of upgraded packages: 268.27 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.94 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230524.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230524.n.0.x86_64.vagrant-libvirt.box = DROPPED IMAGES = Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230523.n.1.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230523.n.1.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20230523.n.1.s390x.tar.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230523.n.1.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230523.n.1.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230523.n.1.iso Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230523.n.1.iso = ADDED PACKAGES = Package: rust-ratatui-0.20.1-1.fc39 Summary: Library to build rich terminal user interfaces or dashboards RPMs:rust-ratatui+crossterm-devel rust-ratatui+default-devel rust-ratatui+serde-devel rust-ratatui+termion-devel rust-ratatui-devel Size:174.69 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: academic-admin-0.8.1-2.fc39 Old package: academic-admin-0.8.1-1.fc39 Summary: Admin tool for the Academic website builder RPMs: academic-admin Size: 41.36 KiB Size change: 180 B Changelog: * Tue May 23 2023 W. Michael Petullo - 0.8.1-2 - Revise academic-admin-0.8.1-dependencies.patch to use more liberal dependencies Package: awscli-1.27.139-1.fc39 Old package: awscli-1.27.138-1.fc39 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.32 MiB Size change: 1.31 KiB Changelog: * Tue May 23 2023 Gwyn Ciesla - 1.27.139-1 - 1.27.139 Package: azure-cli-2.49.0-1.fc39 Old package: azure-cli-2.48.1-1.fc39 Summary: Microsoft Azure Command-Line Tools RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry python3-azure-cli-testsdk Size: 10.78 MiB Size change: 211.87 KiB Changelog: * Tue Apr 25 2023 Major Hayden - 2.48.1-2 - Allow older cryptography/pyOpenSSL * Wed May 17 2023 Major Hayden - 2.48.1-3 - Migrated to SPDX license * Tue May 23 2023 Major Hayden - 2.49.0-1 - Update to 2.49.0 rhbz#2209184 Package: babeltrace2-2.0.5-1.fc39 Old package: babeltrace2-2.0.4-9.fc39 Summary: A trace manipulation toolkit RPMs: babeltrace2 libbabeltrace2 libbabeltrace2-devel python3-bt2 Size: 5.50 MiB Size change: 8.12 KiB Changelog: * Tue May 23 2023 Michael Jeanson - 2.0.5-1 - New upstream release Package: bpftrace-0.18.0-1.fc39 Old package: bpftrace-0.17.0-1.fc38 Summary: High-level tracing language for Linux eBPF RPMs: bpftrace Size: 8.05 MiB Size change: 210.00 KiB Changelog: * Tue May 16 2023 Yaakov Selkowitz - 0.18.0-1 - Rebased to version 0.18.0 Package: iaito-5.8.6-1.fc39 Old package: iaito-5.8.4-2.fc39 Summary: GUI for radare2 reverse engineering framework RPMs: iaito Size: 5.52 MiB Size change: 3.52 KiB Package: kig-23.04.1-2.fc39 Old package: kig-23.04.1-1.fc39 Summary: Interactive Geometry RPMs: kig Size: 18.58 MiB Size change: -3.52 KiB Changelog: * Tue May 23 2023 Kevin Kofler - 23.04.1-2 - backport upstream patch for crash on startup (kde#469962, #2209374) Package: mingw-curl-8.1.1-1.fc39 Old package: mingw-curl-8.1.0-1.fc39 Summary: MinGW Windows port of curl and libcurl RPMs: mingw32-curl mingw32-curl-static mingw64-curl mingw64-curl-static Size: 1.62 MiB Size change: 595 B Changelog: * Tue May 23 2023 Sandro Mani - 8.1.1-1 - Update to 8.1.1 Package: nextcloud-client-3.8.2-1.fc39 Old package: nextcloud-client-3.8.1-1.fc39 Summary: The Nextcloud Client RPMs: nextcloud-client nextcloud-client-caja nextcloud-client-devel nextcloud-client-dolphin nextcloud-client-libs nextcloud-client-nautilus nextcloud-client-nemo Size: 12.70 MiB Size change: -163.38 KiB Changelog: * Wed May 24 2023 Mukundan Ragavan - 3.8.2-1 - Update
[Bug 2209461] perl-Software-License-0.104004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2209461 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Software-License-0.104 ||004-1.fc39 Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2023-05-24 09:28:25 --- Comment #2 from Fedora Update System --- FEDORA-2023-f214f95a5a has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2209461 ___ 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 2209461] perl-Software-License-0.104004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2209461 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-f214f95a5a has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f214f95a5a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2209461 ___ 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 2209461] perl-Software-License-0.104004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2209461 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value Assignee|emman...@seyman.fr |p...@city-fan.org -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2209461 ___ 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: Status of the forge macros?
On 24-05-2023 09:56, Vitaly Zaitsev via devel wrote: On 23/05/2023 19:27, Richard W.M. Jones wrote: ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. Their author left Fedora a few years ago. They're now unmaintained and may be removed soon (see FPC ticket[1]). [1]: https://pagure.io/packaging-committee/pull-request/1270 I don't infer a removal request from the ticket's title: "SourceURL: document that the forge macros are deprecated / unmaintained". Yes, it should be mentioned that they are currently unmaintained. I, for one, am a happy user of the forge macros and would like to keep using them. I probably started using them seeing examples, that did not have a deprecation warning. As mentioned in the ticket above and the PR [1] linked, separating the forge macros from redhat-rpm-config, may be the way forward. @gotmax23 already provided a PoC. I'd be willing to help out making this happen. That said, my knowledge of RPM macros is limited. [1] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/248 -- 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: Status of the forge macros?
On 23/05/2023 19:27, Richard W.M. Jones wrote: ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. Their author left Fedora a few years ago. They're now unmaintained and may be removed soon (see FPC ticket[1]). [1]: https://pagure.io/packaging-committee/pull-request/1270 -- 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
Obsolete of DNF by DNF5 in RAWHIDE
Hello, I have great news that the upcoming release of DNF5 will obsolete DNF in rawhide (Fedora 39). The release is planned not before the end of May. The change was already announced in https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5. Best regards Jaroslav Mracek ___ 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: %find_lang does not find locale files
On Wed, May 24, 2023 at 5:11 AM Parag Nemade wrote: > > Hi, > > > On Tue, May 23, 2023 at 11:58 PM Alexander Ploumistos > wrote: >> >> Hello, >> >> I know this has been asked before, more recently four years ago in >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OQDWCHFDTBKCPHWF2VLPUF74WC76TCNY/#6VUBRYAAZMX6SOREM7ZENDV44MIPE7WH >> >> I'm not sure what the "right" way of dealing with this is, so I would >> really appreciate any advice. >> >> I've recently packaged input-remapper[1] and during the review[2], >> Zbigniew pointed out that I had forgotten to use the %find_lang macro >> for the localization files. >> >> The translations are placed in /usr/share/input-remapper/lang/ and >> apparently, %find_lang does not want to find them there. Is there a >> standard location that works across linux distributions? I guess that >> if the answer is yes, I should get upstream to move their files there. >> If not, is there something else to be done? >> >> >> 1. https://github.com/sezanzeb/input-remapper/ >> 2. https://bugzilla.redhat.com/show_bug.cgi?id=2180418 >> ___ > > > I did a quick search and found this discussion > https://pagure.io/packaging-committee/issue/1058#comment-775111 > Maybe this will not help you but will give some insights. Thank you Parag, that was indeed enlightening. @churchyard: Miro, is it possible to tell %pyproject_save_files about the locale directory or should I resort to one of the workarounds mentioned in the ticket? Does the %lang tag serve any purpose when there aren't separate language-specific packages? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
