Re: %find_lang does not find locale files
Hi, On Tue, May 23, 2023 at 11:58 PM Alexander Ploumistos < alex.ploumis...@gmail.com> 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. Regards, Parag. ___ 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 2209461] New: perl-Software-License-0.104004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2209461 Bug ID: 2209461 Summary: perl-Software-License-0.104004 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Software-License Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.104004 Upstream release that is considered latest: 0.104004 Current version/release in rawhide: 0.104003-1.fc39 URL: http://search.cpan.org/dist/Software-License/ 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/3325/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Software-License -- 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 2208828] perl-Crypt-URandom-0.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2208828 --- Comment #9 from Fedora Update System --- FEDORA-EPEL-2023-76e823780d has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-76e823780d 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
[Bug 2208828] perl-Crypt-URandom-0.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2208828 --- Comment #8 from Fedora Update System --- FEDORA-2023-1b6352567b has been pushed to the Fedora 37 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-1b6352567b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-1b6352567b 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
Fedora rawhide compose report: 20230523.n.1 changes
OLD: Fedora-Rawhide-20230522.n.0 NEW: Fedora-Rawhide-20230523.n.1 = SUMMARY = Added images:3 Dropped images: 2 Added packages: 4 Dropped packages:3 Upgraded packages: 242 Downgraded packages: 0 Size of added packages: 1.15 MiB Size of dropped packages:632.86 KiB Size of upgraded packages: 4.63 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 66.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230523.n.1.iso Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20230523.n.1.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230523.n.1.iso = DROPPED IMAGES = Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230522.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20230522.n.0.x86_64.vagrant-libvirt.box = ADDED PACKAGES = Package: belr-5.2.45-1.fc39 Summary: Language recognition library RPMs:belr belr-devel belr-tools Size:1001.45 KiB Package: hdmf-common-schema-1.6.0-1.fc39 Summary: Specifications for pre-defined data structures provided by HDMF RPMs:hdmf-common-schema Size:14.63 KiB Package: rust-termion1-1.5.6-1.fc39 Summary: Bindless library for manipulating terminals RPMs:rust-termion1+default-devel rust-termion1-devel Size:47.24 KiB Package: whichfont-1.0.5-2.fc39 Summary: Querying Fontconfig RPMs:whichfont Size:111.45 KiB = DROPPED PACKAGES = Package: morse2txt-1.0.0-36.fc38 Summary: A Morse Code Reader RPMs:morse2txt Size:188.32 KiB Package: numad-0.5-38.20150602git.fc38 Summary: NUMA user daemon RPMs:numad Size:151.00 KiB Package: yokadi-1.2.0-6.fc38 Summary: Command line oriented todo list system RPMs:yokadi Size:293.54 KiB = UPGRADED PACKAGES = Package: GitPython-3.1.31-1.fc39 Old package: GitPython-3.1.30-2.fc38 Summary: Python Git Library RPMs: python3-GitPython Size: 383.37 KiB Size change: 304 B Changelog: * Tue May 23 2023 Lubom??r Sedl - 3.1.31-1 - Update to 3.1.31 (#2170552) Package: R-igraph-1.4.3-1.fc39 Old package: R-igraph-1.4.1-2.fc39 Summary: Network Analysis and Visualization RPMs: R-igraph Size: 18.76 MiB Size change: 1.31 MiB Changelog: * Mon May 22 2023 Tom Callaway - 1.4.3-1 - update to 1.4.3 Package: alglib-4.00.0-1.fc39 Old package: alglib-3.20.0-2.fc38 Summary: A numerical analysis and data processing library RPMs: alglib alglib-devel alglib-doc Size: 8.91 MiB Size change: 287.75 KiB Changelog: * Tue May 23 2023 Sandro Mani - 4.0.0-1 - Update to 4.0.0 Package: anaconda-39.16-1.fc39 Old package: anaconda-39.15-1.fc39 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-webui anaconda-widgets anaconda-widgets-devel Size: 19.84 MiB Size change: 53.35 KiB Changelog: * Fri May 19 2023 Petr Pisar - 39.15-2 - Rebuild against rpm-4.19 (https://fedoraproject.org/wiki/Changes/RPM-4.19) * Tue May 23 2023 Packit - 39.16-1 - Change driver_updates exit info messages to debug (#2154904) (jkonecny) - Add readme for the conf.d drop dir (vslavik) - webui: use the reason in title of disabled partitioing warning (rvykydal) - WebUI: improve handling of removal of testvm's (jvanderwaa) - webui: [pixel-tests] update microcopy of "erase-all" storage scenario (rvykydal) - webui: update microcopy of "erase-all" storage scenario (rvykydal) - Add a draft release note for the Runtime module (vslavik) - Add tests for the Runtime and Dracut modules (vslavik) - Add the dracut command module (vslavik) - Add the Runtime module (vslavik) - Add release notes packaging Web UI (jkonecny) - Fix release notes link consistency (jkonecny) - docs: Add other f38 release notes (vslavik) - docs: Add vponcova f38 release notes (vslavik) - docs: Add F38 release notes for vslavik PRs (vslavik) - Create Fedora 38 release notes (jkonecny) - Remove link to the release notes template.rst (jkonecny) - WebUI: close embedded panel when clicking prev/next (jvanderwaa) - WebUI: update ESLINT to LINT (jvanderwaa) - WebUI: use StorageScenarioId in all components (jvanderwaa) - WebUI: set default storage scenario based on scenarios constant (jvanderwaa) - webui: use the same naming for disk images created in machine_install (rvykydal) - webui: consolidate creating images in machine_install (rvykydal) - Update translations from Weblate Package: annobin-12.1
[Bug 2203748] Upgrade perlbrew to 0.97
https://bugzilla.redhat.com/show_bug.cgi?id=2203748 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Fixed In Version|perlbrew-0.97-1.fc39|perlbrew-0.97-1.fc39 ||perlbrew-0.97-1.fc38 Last Closed||2023-05-24 01:16:40 --- Comment #3 from Fedora Update System --- FEDORA-2023-1e65128acf has been pushed to the Fedora 38 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=2203748 ___ 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 2208828] perl-Crypt-URandom-0.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2208828 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #7 from Fedora Update System --- FEDORA-EPEL-2023-f0df302bb8 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f0df302bb8 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
[Test-Announce] Fedora 39 Rawhide 20230523.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 39 Rawhide 20230523.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20230520.n.0: anaconda-39.15-1.fc39.src, 20230523.n.1: anaconda-39.16-1.fc39.src python-blivet - 20230520.n.0: python-blivet-3.7.1-2.fc39.src, 20230523.n.1: python-blivet-3.7.1-3.fc39.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/39 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230523.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, 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: U-Boot for x86 BIOS systems
s/Chromeboot/Chromebook/g lol ___ 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: U-Boot for x86 BIOS systems
I think this is a worthwhile effort if someone has the time to fill in the blanks, come up with a PoC, and test it with various versions of BIOS, it would accelerate deprecation of BIOS. BIOS holds us back when making decisions around boot stack, bootloader, firmware upgrade tools, etc. You may have to port u-boot to different versions of BIOS though. For example this chainloading technique was considered as a solution to make Chromebooks + Coreboot chainload a UEFI loader to install vanilla Fedora images, but the disadvantage is you'd have to port u-boot to every Chromeboot: https://github.com/eballetbo/chromebooks On the other hand chainloading a UEFI loader works great for Asahi even without the efi vars so... ___ 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
%find_lang does not find locale files
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 ___ 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?
In my experience, “colorblindness” is generally understood to include a range of color vision “anomalies.” I have the most common form, deuteranomaly. Green does not look as bright as other colors to me, and I have a hard time distinguishing greenish colors from reddish colors when they are desaturated (like greenish-brown versus reddish-brown), or when looking at fine points or lines rather than large areas of color. I can still easily distinguish bright green from bright red, even in a small area, but it’s very difficult to distinguish a small amber LED from a green one. It’s best to avoid using color to communicate essential information with no backup mechanism; to use something like the contrast ratio formulas from WCAG 2.2 to ensure adjacent colors contrast sufficiently in luminance and not only in hue; and to particularly avoid contrasting colors that are both reddish or greenish when possible, since these are the most troublesome for the largest number of people. 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 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). > 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. > > Jens > ___ > 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: Status of the forge macros?
Original Message From: Richard W.M. Jones [mailto:rjo...@redhat.com] Sent: Tuesday, May 23, 2023 at 1:27 PM EDT To: devel@lists.fedoraproject.org Subject: Status of the forge macros? I've been using the so-called forge macros in lots of packages: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. m_oO_m ?! Is this true, and if so can we actually document that? Else un-deprecate them as they are really useful. +1 to that. been similarly using them for ages, particularly given the i've been often pointed to the d.f.o link above as current :-/ imo, immensely useful, with unique capabilities (tho, similar to OBS) for forge src mgmt. ___ 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: mkosi-initrd (Self-Contained Change proposal)
I think this is a great idea by the way, funnily enough I had thought the same thoughts numerous times over the last 18 months. "Why does dracut do it's own job scheduling for generating initramfs, when systemd has all this job scheduling functionality already?" but now someone has actually made those thoughts come to real life :) ___ 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. 23 19:27, Richard W.M. Jones wrote: I've been using the so-called forge macros in lots of packages: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. Is this true, and if so can we actually document that? Else un-deprecate them as they are really useful. I'd say unmaintained rather than deprecated. See https://pagure.io/packaging-committee/pull-request/1270 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Status of the forge macros?
I've been using the so-called forge macros in lots of packages: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control ... so today I was taking part in a package review which uses these macros and was surprised to be told that they are deprecated. Is this true, and if so can we actually document that? Else un-deprecate them as they are really useful. 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: [Fedora-packaging] Re: RPM 4.19: Dynamic subpackages with Python extras
Hey,
On Mon, May 15, 2023, 22:04 Dan Čermák
wrote:
> Hi Igor,
>
> On May 15, 2023 6:24:07 PM UTC, Igor Raits wrote:
> >On Thu, Mar 30, 2023 at 11:56 PM Miro Hrončok
> wrote:
> >>
> >> Hello Python packagers.
> >>
> >> RPM 4.19 introduces this feature:
> >>
> >> https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html
> >>
> >> I decided to write this email to gather my thoughts. I believe that
> with this,
> >> we can turn manual Python extras subpackages like this:
> >
> >Is there a reason not to write a brp script so that users won't have
> >to do anything manually at all? Basically scan the sitelibdir for the
> >dist-info and create necessary parts from there?
>
> Don't the brp-scripts run after the build? I though the dynamic subpackage
> creation has to occur beforehand.
>
I think brp script runs exactly before subpackages are created.
> >>
> >>%package -n python3-...
> >>Summary:%{summary}
> >>
> >>%description -n python3-... %_description
> >>
> >>%pyproject_extras_subpkg -n python3-xxx extra1 extra2
> >>
> >> (See
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Extras
> >> for what that means.)
> >>
> >> Into something like this:
> >>
> >>%package -n python3-...
> >>Summary:%{summary}
> >>
> >>%description -n python3-... %_description
> >>...
> >>
> >>%install
> >>%pyproject_install
> >>...
> >>%pyproject_generate_extras_subpkgs -n python3-xxx
> >>
> >>
> >> The %pyproject_generate_extras_subpkgs macro would parse the installed
> >> .dist-info directory to find out what extras are available and generate
> >> subpackages for all of them.
> >>
> >> (Obviously, the macro name is open up for discussion.)
> >>
> >>
> >>
> >> An API would be required to exclude extras:
> >>
> >> - that are not useful for other packages
> >>(for example build/development requirements, commonly named dev, doc
> or test)
> >> - that have requirements that are not packaged in Fedora
> >>
> >> For example (mimicking the API of %pyproject_check_import):
> >>
> >>%pyproject_generate_extras_subpkgs -n python3-xxx -e test -e
> 'nonfree*'
> >>
> >>
> >>
> >> However, extras are also currently manually passed to
> %pyproject_buildrequires:
> >>
> >>%generate_buildrequires
> >>%pyproject_buildrequires -x extra1 -x extra2 -x test
> >>
> >> It should already be possible to implement automatic extras discovery in
> >> %pyproject_buildrequires with older RPM versions and allow it to be
> used this way:
> >>
> >>%generate_buildrequires
> >>%pyproject_buildrequires -X 'nonfree*'
> >>
> >> RPM macros can only accept short flags, so
> can
> >> either be -x '*' (if we start treating -x values as globs, which is
> backwards
> >> compatible and probably generally useful), or a single-letter switch
> such as -a
> >> (but honestly we are running out of meaningful letters).
> >>
> >> (When -X is used, can probably be implied.
> However,
> >> an explicit form needs to exist for packages that don't need to exclude
> any
> >> extras at all.)
> >>
> >>
> >> Eventually, I'd like to make the default,
> once RPM
> >> 4.19 is omnipresent.
> >>
> >>
> >>
> >> Combined, this would mean that the packager needs to:
> >>
> >> 1. specify extras that are not supposed to be used as BRs
> >> 2. specify extras that are not supposed to be packaged
> >>
> >> In the ideal word (2) is a superset of (1).
> >>
> >> Should %pyproject_generate_extras_subpkgs somehow inherit the -Xes from
> >> %pyproject_buildrequires?
> >>
> >> When a package has extra1, extra2, nonfree1, nonfree2 and test extras,
> one
> >> could do:
> >>
> >>%generate_buildrequires
> >>%pyproject_buildrequires -X 'nonfree*'
> >>
> >>...
> >>
> >>%pyproject_install
> >>...
> >>%pyproject_generate_extras_subpkgs -X test
> >>
> >> That would mean:
> >>
> >> - extra1 is BRed and packaged
> >> - extra2 is BRed and packaged
> >> - test is BRed but not packaged
> >> - nonfree1 is neither
> >> - nonfree2 is neither
> >>
> >>
> >>
> >> Alternatively the information could be supplied by %globals:
> >>
> >>%global _python_ignored_extras nonfree*
> >>%global _python_unpackaged_extras test
> >>
> >> However, I somehow dislike this approach.
> >>
> >>
> >>
> >> I'd appreciate your thoughts on the matter.
> >>
> >> --
> >> Miro Hrončok
> >> --
> >> Phone: +420777974800
> >> IRC: mhroncok
> >> ___
> >> packaging mailing list -- packag...@lists.fedoraproject.org
> >> To unsubscribe send an email to packaging-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/packag...@lists.fedoraproject.org
> >>
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2023-05-24 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: more distinct default bash prompt?
On Tue, May 23, 2023 at 07:07:17AM -0400, Neal Gompa wrote: > 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 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). > > 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. > > > > Basically, I mean "don't use red for root and green for regular user" > since that cannot be distinguished by red+green colorblind people. Colorblind person here. It's not a simple thing because everyone who has some level of color blindness will be different than someone else. I may be able to see more or different reds and greens than another person. I can say with 100% certainty that if default prompts are gain colors in Fedora, I will turn that off for myself. I try not to use colors for anything (again, special user case here...someone once described my mutt configuration as "brutalist"). That said, I don't care what the defaults are, just make it so I can easily turn that stuff off. Shell customizations are very personal anyway and everyone has favorites. I suggest packaging yours as an /etc/profile.d file in a Copr project, then enabling that repo when you install or set up a VM. > Purple may work for root to fix that. $ vs. # has long been established as the distinguisher between a non-root and root shell. That's what I would rely on. ¯\_(ツ)_/¯ Color wise, purple would actually be really bad for me because I can't distinguish that from red in many cases. But it usually registers as "different" than green. (with apologies to zsh, but we all have wild zshrc files anyway and some us spell "$" as "%".) -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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
[rpms/perl-DBM-Deep] PR #1: Fix test 01_basic.t to pass with Perl 5.38
jplesnik merged a pull-request against the project: `perl-DBM-Deep` that you are following. Merged pull-request: `` Fix test 01_basic.t to pass with Perl 5.38 `` https://src.fedoraproject.org/rpms/perl-DBM-Deep/pull-request/1 ___ 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: ppc64le builds taking ages
I ran a KiCad build yesterday on Copr [1] (so not the same as Koji), but while it all completed, curiously the rawhide PPC build took 6 hours while the f37 and f38 PPC builds only took 2 hours. The corresponding Koji build [2] took close to 4 hours, so it is in the ball-park. KiCad is a bit unique because it includes a data package that is close to 6 GB uncompressed and about 420 MB after compression. I don't know if that plays a role. [1] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad-stable/build/5942232/ [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2204170 On 5/23/23 05:41 AM, Miroslav Lichvar wrote: On Sat, May 20, 2023 at 02:51:06PM -0700, Kevin Fenzi wrote: I've moved all the power9 virthosts running builders over to a 6.3.x kernel. Please let me know if this helps or doesn't with slowness issues. It seems the execution is still freezing occasionally. My recent build of chrony failed on ppc in %check due to a test not being able to start and connect within 10 seconds. ___ 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?
Once upon a time, Jason Montleon said: > One of the things I discovered playing with tput last night trying > some of this is that it will error if you don't have a terminal. > ssh foo.example.com virsh start bar > tput: No value for $TERM and no -T specified My prompt manipulations are wrapped in a test like: if [ "$PS1" ]; then fi PS1 is not set on a non-interactive shell (no TTY assign), so don't do anything to manipulate it if it isn't already set to something. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Struct-Dumb] PR #1: Specify all dependencies
jplesnik merged a pull-request against the project: `perl-Struct-Dumb` that you are following. Merged pull-request: `` Specify all dependencies `` https://src.fedoraproject.org/rpms/perl-Struct-Dumb/pull-request/1 ___ 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
[rpms/perl-Data-Clone] PR #1: Fix test 07_stack.t to pass with Perl 5.38
jplesnik merged a pull-request against the project: `perl-Data-Clone` that you are following. Merged pull-request: `` Fix test 07_stack.t to pass with Perl 5.38 `` https://src.fedoraproject.org/rpms/perl-Data-Clone/pull-request/1 ___ 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: more distinct default bash prompt?
Once upon a time, Jens-Ulrik Petersen said: > Also while we are bike-shedding... What about \W vs \w ? > I think fedora has used \W "forever" - I am not a huge fan... > though I suppose its main merit is not over-flowing/extending for very long > dir paths. I use \w and set PROMPT_DIRTRIM=4. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-DBM-Deep] PR #1: Fix test 01_basic.t to pass with Perl 5.38
jplesnik opened a new pull-request against the project: `perl-DBM-Deep` that you are following: `` Fix test 01_basic.t to pass with Perl 5.38 `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-DBM-Deep/pull-request/1 ___ 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
[rpms/perl-Data-Clone] PR #1: Fix test 07_stack.t to pass with Perl 5.38
jplesnik opened a new pull-request against the project: `perl-Data-Clone` that you are following: `` Fix test 07_stack.t to pass with Perl 5.38 `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Data-Clone/pull-request/1 ___ 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: Salt is broken in Fedora 38 - asking a python-savvy provenpackager to help
I have not, but I was going to build 3006.1 for f39-37 and el9. I'll let you take it from here. :) -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Monday, May 22nd, 2023 at 10:22 PM, Jonathan Steffan wrote: > I've built an updated 3006.1 in rawhide with some comments > https://bugzilla.redhat.com/show_bug.cgi?id=2189782#c4 > Gwyn, > > Let me know if you've started on backporting the immediate fix for the 3005.1 > package branches affected yet or not. I could look at that next. > > Cheers, > > On Mon, May 22, 2023 at 8:56 PM Demi Marie Obenour > wrote: > > > On 5/22/23 19:17, Christopher wrote: > > > Hi, > > > > > > Is anybody able to help fix salt-minion in F38? It's been broken > > > because of a newer version of python setuptools in F38. There's a > > > patch upstream, and the newer version also includes that patch. It > > > just needs to be incorporated into Fedora. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2189782 > > > > > > The maintainer does not seem to have responded in at least several > > > months on bugzilla. I'm not really a python person, and don't know > > > much about salt, and am not a provenpackager. But my $dayjob uses Salt > > > for some things, and if it doesn't start working again soon, I'm > > > afraid they'll revoke my permission to use Fedora at work. So, any > > > help to get this fixed would be greatly appreciated. > > > > Qubes OS also uses Salt. CCing Marek Marczycowski-Górecki and > > Frédéric Pierret of Invisible Things Lab. > > -- > > Sincerely, > > Demi Marie Obenour (she/her/hers) > > ___ > > 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 > > > > -- > Jonathan Steffan > jonathanstef...@gmail.com signature.asc 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: more distinct default bash prompt?
One of the things I discovered playing with tput last night trying
some of this is that it will error if you don't have a terminal.
ssh foo.example.com virsh start bar
tput: No value for $TERM and no -T specified
To correct this using your example you can do:
if [ -t 0 ]
then
prompt_term[0]=$(tput bold)
prompt_term[1]=$(tput setaf 1) # red
prompt_term[2]=$(tput sgr0)
export PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'"
==> "
fi
On Tue, May 23, 2023 at 7:10 AM Nick Clifton wrote:
>
> >> What do people think overall? Are there other pros and cons of a color
> >> prompt?
> >> Any better ideas or direction?
>
> I like the idea of using tput to get the correct strings for
> setting different terminal effects, so I now use:
>
># Success prompt:
>prompt_term[0]=$(tput bold)
>
># Fail prompt:
>prompt_term[1]=$(tput setaf 1) # red
>
># Turn off all attributes
>prompt_term[2]=$(tput sgr0)
>
># Make the prompt reflect the exit status of the last command
>export PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'"
> ==> "
>
> Cheers
>Nick
> ___
> 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
--
Jason Montleon| email: jmont...@redhat.com
Red Hat, Inc. | gpg key: 0x069E3022
Cell: 508-496-0663| irc: jmontleo / jmontleon
___
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
[rpms/perl-Struct-Dumb] PR #1: Specify all dependencies
jplesnik opened a new pull-request against the project: `perl-Struct-Dumb` that you are following: `` Specify all dependencies `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Struct-Dumb/pull-request/1 ___ 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
[Canceled] Schedule for Tuesday's FESCo Meeting (2023-05-23)
This week's FESCo meeting is canceled due to a lack of agenda topics to discuss. I will chair next week's meeting. Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2023-05-23 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Change: Fedora Onyx https://pagure.io/fesco/issue/2996 APPROVED (+4, 0, 0) = Followups = = New business = = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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?
What do people think overall? Are there other pros and cons of a color prompt?
Any better ideas or direction?
I like the idea of using tput to get the correct strings for
setting different terminal effects, so I now use:
# Success prompt:
prompt_term[0]=$(tput bold)
# Fail prompt:
prompt_term[1]=$(tput setaf 1) # red
# Turn off all attributes
prompt_term[2]=$(tput sgr0)
# Make the prompt reflect the exit status of the last command
export PS1='\[${prompt_term[$(($??1:0))]}\]'"\w"'\[${prompt_term[2]}\]'" ==> "
Cheers
Nick
___
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 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). > 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. > Basically, I mean "don't use red for root and green for regular user" since that cannot be distinguished by red+green colorblind people. Purple may work for root to fix that. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Params-Check] PR #1: Modernize spec; Package tests
jplesnik merged a pull-request against the project: `perl-Params-Check` that you are following. Merged pull-request: `` Modernize spec; Package tests `` https://src.fedoraproject.org/rpms/perl-Params-Check/pull-request/1 ___ 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: more distinct default bash prompt?
On 22/05/2023 05:49, Jens-Ulrik Petersen wrote: What do people think overall? Are there other pros and cons of a color prompt? Any better ideas or direction? PS1 from all my systems: export PS1="\[\e[33m\][\[\e[36m\]\u\[\e[0m\]@\[\e[31m\]\h\[\e[0m\] \[\e[32m\]\W\[\e[33m\]]\[\e[35m\]\$\[\e[0m\] " -- 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
[rpms/perl-Params-Check] PR #1: Modernize spec; Package tests
jplesnik opened a new pull-request against the project: `perl-Params-Check` that you are following: `` Modernize spec; Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Params-Check/pull-request/1 ___ 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
Announcing fmt library soversion bump
Hello. fmt 10.0.x update will include a soversion bump from .9 to .10. It has both API and ABI changes. Changelog: https://github.com/fmtlib/fmt/releases/tag/10.0.0 The list of affected packages in Rawhide: 0ad OpenImageIO bear cachelib cantera ceph dnf5 dolphin-emu domoticz easyeffects easyrpg-player fb303 fbthrift fizz fmidi folly freeopcua gerbera giada gnuradio gr-funcube libsemigroups libsonata luxcorerender mcrouter mkvtoolnix nheko proxygen rstudio sdrpp spdlog vcpkg wangle watchman waybar zswap-cli I will use my proven-packager rights to rebuild all dependent packages in a separate side tag next week. -- 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: ppc64le builds taking ages
On Sat, May 20, 2023 at 02:51:06PM -0700, Kevin Fenzi wrote: > I've moved all the power9 virthosts running builders over to a 6.3.x > kernel. > > Please let me know if this helps or doesn't with slowness issues. It seems the execution is still freezing occasionally. My recent build of chrony failed on ppc in %check due to a test not being able to start and connect within 10 seconds. -- Miroslav Lichvar ___ 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: Self Introduction
Hello, Philipp! On Monday, 22 May 2023 at 12:24, Philipp Stanner wrote: > Hi Fedora Folks! > > As I am going to do some RPM packaging in the future (for my employer > and probably also a bit in private) I wanted to introduce me briefly. > I'm Philipp, based in southern Germany and have been an open source > enthusiast at least since 2016/17. I am currently working a lot with > RPMs and am therefore trying to gain knowledge and traction in that > area. Sounds great! > I hope I will be able to contribute a package or two during the next > months. We are looking forward to your contributions. Welcome to Fedora! 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
Re: more distinct default bash prompt?
On 5/22/23 16:42, Richard W.M. Jones wrote:
FWIW Haiku uses bash and has a prompt which changes colour (green/red)
depending on whether the status code of the last command was good or
bad. I found this surprisingly useful. They use:
\[`if [ $? = 0 ]; then echo "\e[32m"; else echo "\e[31m"; fi`\]\w[\e[0m\]>
(or, as another example, just a fat red $? if it's != 0,
PS1='\[\e[0;1;31m\]${?#0}\[\e[30m\]\w \[\e[0m\]'
which I've gotten really dependent on over the years)
___
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
[rpms/perl-constant] PR #1: Modernize spec; Package tests
jplesnik merged a pull-request against the project: `perl-constant` that you are following. Merged pull-request: `` Modernize spec; Package tests `` https://src.fedoraproject.org/rpms/perl-constant/pull-request/1 ___ 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
