Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Fri, Jun 3, 2022 at 12:19 AM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > It's not standard at all. We don't even test for this setup regularly. > > It's not a test case, and it's not even supposed to work right now. > > It’s standard as it is a typical use case in private or SME environments. > It's not *that* typical in my experience. Most of the SME server environments I know of don't have that. It's more common in larger server environments, but they also typically use hardware RAID there instead of software RAID. If we care about this behavior, we should have a test case to verify this behavior for all three Anaconda install modes (MBR+BIOS, GPT+BIOS, UEFI). If this is truly something we care about, then we should have communicated this need to the Anaconda team so that they would care about it, independent of this feature. > And do you really think we distribute dmraid for years now "and it's not even > supposed to work right now.“? > dmraid has been unmaintained for over 15 years, so yes I do. It was dropped from RHEL 8 as well. It only exists in Fedora because someone decided to not retire the package, but upstream has been dead since the early 2000s. > And don't hide behind formalistic arguments that just suit you by chance. > Your change proposal deliberately makes it impossible for existing server > users (or makes it unnecessarily overly difficult) who have relied (and could > rely) on us so far to continue using Fedora Server. I consider this > irresponsible. And I don't understand why you stubbornly insist on this > change proposal as is, instead of looking for solutions that keep mischief > away from our users and change to GPT as default (which is undoubtedly the > future standard). > Outside of having Anaconda create BIOS boot partitions and install the bootloader on every disk, there's no solution for this problem. Also, calling it "mischief" is disingenuous, since until this week, nobody ever mentioned this case at all. We even discussed the GPT thing before I proposed the Change and it did not come up. > > > Also, any system with drives >=2TB will get GPT automatically, you > > can't have MBR in those setups. All this does is remove the default > > special case for smaller disks. > > This is a completely different case. For disks > 2 TB simply nothing changes, > neither better nor worse. For disks < 2 TB your change proposal results in a > deterioration. Why do you want it so badly? > You know why I want this Change, and I even wrote it into the proposal. We have to do *something* to start preparing new installs for a world when legacy BIOS is *gone*, and switching to GPT is a simple first step to doing 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2092465] perl-Locale-Codes-3.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2092465 --- Comment #5 from Fedora Update System --- FEDORA-2022-395a54cbff has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-395a54cbff` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-395a54cbff 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=2092465 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2092465] perl-Locale-Codes-3.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2092465 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2022-7355a6763b has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-7355a6763b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7355a6763b 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=2092465 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2090523] [EPEL9] Please branch and build perl-DBD-ODBC in EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2090523 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-DBD-ODBC-1.61-7.el9 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2022-06-03 02:59:22 --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2022-70dd90a372 has been pushed to the Fedora EPEL 9 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=2090523 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: News from printing world aka PWG May 2022 meetup
On 5/19/22 3:27 AM, Zdenek Dohnal wrote: [Snip] - Till Kamppeter wrote printer applications which covers all printer drivers in Debian distribution - we don't have any additional printer driver package in Fedora, so all our driver packages are covered as well Since there were some questions the last time this came up, see this[0] gnome-control-center upstream discussion for how printer applications may be integrated into the desktop environment printer configuration. - printer applications (the solution for driver-only printers how to work with IPP-only CUPS) are available as SNAPs in Fedora (feel free to try them and leave feedback at the respective OpenPrinting project https://github.com/orgs/OpenPrinting/repositories ), packaging them as RPMs is blocked due dependency on cups-filters 2.0, which is not released yet (though IIRC someone from Fedora community - maybe Brandon Nielsen - has them in copr) That would be me[1], though I haven't been giving them the attention they need lately. [Snip] [0] - https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1878 [1] - https://copr.fedorainfracloud.org/coprs/nielsenb/printer-apps/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Copr login not working
On Thu, Jun 02, 2022 at 08:34:51PM -0400, Chris wrote: > Hi, > > Can't seem to log into COPR; I can log into everything else, but after > providing my correct user/pass combo and logging in, the screen just > returns back as though I never even attempted (the log in). > > I tried resetting my password, and all that accomplished is that I can > still log into every other site that uses the Fedora Account Credentials, > but still not Copr. > > The login i'm using is lead2gold (attemping to push some new changes and > test them out as i've done in the past to > https://copr.fedorainfracloud.org/coprs/lead2gold/apprise/). I'm okay with > using Koji for now. > > Advice/Thoughts? Please retry now. It should work. I was attempting to upgrade our idp, but it appears to have some issue around copr logins. ;( I'm rolled back to the old os for now, and it should be back working until we can sort it out. Sorry for the trouble. 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 on the list, report it: https://pagure.io/fedora-infrastructure
Copr login not working
Hi, Can't seem to log into COPR; I can log into everything else, but after providing my correct user/pass combo and logging in, the screen just returns back as though I never even attempted (the log in). I tried resetting my password, and all that accomplished is that I can still log into every other site that uses the Fedora Account Credentials, but still not Copr. The login i'm using is lead2gold (attemping to push some new changes and test them out as i've done in the past to https://copr.fedorainfracloud.org/coprs/lead2gold/apprise/). I'm okay with using Koji for now. Advice/Thoughts? Chris ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > It's not standard at all. We don't even test for this setup regularly. > It's not a test case, and it's not even supposed to work right now. It’s standard as it is a typical use case in private or SME environments. And do you really think we distribute dmraid for years now "and it's not even supposed to work right now.“? And don't hide behind formalistic arguments that just suit you by chance. Your change proposal deliberately makes it impossible for existing server users (or makes it unnecessarily overly difficult) who have relied (and could rely) on us so far to continue using Fedora Server. I consider this irresponsible. And I don't understand why you stubbornly insist on this change proposal as is, instead of looking for solutions that keep mischief away from our users and change to GPT as default (which is undoubtedly the future standard). > Also, any system with drives >=2TB will get GPT automatically, you > can't have MBR in those setups. All this does is remove the default > special case for smaller disks. This is a completely different case. For disks > 2 TB simply nothing changes, neither better nor worse. For disks < 2 TB your change proposal results in a deterioration. Why do you want it so badly? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2091511] Please branch and build perl-Net-LibIDN in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2091511 Robert Scheck changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2022-06-02 21:15:05 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2091511 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20220602.0 compose check report
No missing expected images. Failed openQA tests: 3/15 (aarch64) Old failures (same test failed in Fedora-IoT-36-20220529.0): ID: 1287919 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1287919 ID: 1287926 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1287926 ID: 1287933 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1287933 Passed openQA tests: 15/15 (x86_64), 12/15 (aarch64) New passes (same test not passed in Fedora-IoT-36-20220529.0): ID: 1287911 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1287911 ID: 1287918 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1287918 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.15 to 0.26 Previous test data: https://openqa.fedoraproject.org/tests/1282925#downloads Current test data: https://openqa.fedoraproject.org/tests/1287905#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.06 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/1282940#downloads Current test data: https://openqa.fedoraproject.org/tests/1287920#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 9:27 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > > : > > > > On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: > >> > >> ... > >> > >> And even those who can continue to use Fedora Server via update are under > >> the threat of having to switch distributions overnight in the event of a > >> technical error. Fedora will become unusable for them. A great "feature", > >> that you would like to introduce, obviously at all costs. > > > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > > the issue.) > > > According to the latest Anaconda documentation [1] there is no option > inst.mbr, there is just inst.gpt. Maybe, it is an undocumented feature. > It's going to replace inst.gpt. This is described in the Change document. > And do we really want our users to fiddle around with editing boot line > options as a standard procedure for using a standard use case? > It's not standard at all. We don't even test for this setup regularly. It's not a test case, and it's not even supposed to work right now. Also, any system with drives >=2TB will get GPT automatically, you can't have MBR in those setups. All this does is remove the default special case for smaller disks. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
FedoraRespin-36-updates-20220601.0 compose check report
No missing expected images. Failed openQA tests: 2/48 (x86_64) ID: 1287858 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1287858 ID: 1287895 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1287895 Soft failed openQA tests: 1/48 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 1287862 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1287862 Passed openQA tests: 45/48 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedocal] Reminder meeting : ELN SIG
Agenda Items: * The end of the Everything repo * Outstanding installation bugs Anything else? On Thu, Jun 2, 2022 at 8:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2022-06-03 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10133/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Virtualization has long been a steadily growing use case of Fedora Server Edition, but it is still time consuming and tedious for the system administrator to create a Fedora Server VM. Supplementing the downloads by a KVM VM image remedies the deficiency. == Owner == * Name: [[User:pboy| Peter Boy on behalf of Server WG]] * Email: p...@uni-bremen.de == Detailed Description == The creation of the VM disk image, uses the same kickstart files and installation groups as the standard full installation, except of course for the hardware-specific items. The image is optimized for KVM. That way, the VM resembles a default server installation as closely as possible. All administrative tools are available reliably from the beginning, all administrative routines and helps (scripts) can be used in the same way. All application services work in the identical way. A default VM installation takes 1-2 minutes instead of about 30 mins. == Feedback == The change proposal is based on an extensive discussion of the server WG and has become part of its work program. For example, the server documentation on virtualization has already been significantly expanded in parallel and will continue to be supplemented and updated on an ongoing basis. This is a response to the importance of the topic. == Benefit to Fedora == Significantly improves usability for Fedora Server Edition administrators when deploying a Fedora Server Edtion VM. It thus makes Fedora Server Edition more attractive, especially for new users without extensive experience with Fedora. It thus helps to expand our user base. Fedora finally provides an installation path for a Fedora Server VM that is built entirely on Fedora Resources, subject to Fedora quality control, and compliant with Fedora principles. Until now, if a system administrator has to install a VM preferable without the hassles of a full default installation, we could only recommend third party binary blob (e.g. virt-builder), which is a violation of our own core principles. In addition, the third party products do not provide a 'Fedora Server Edition', but their own different concept and vision of a server, under the name Fedora Server. == Scope == * Proposal owners: A kickstart file for ImageFactory is completed and locally tested. * Other developers: n/a * Release engineering: [https://pagure.io/releng/issues #10768] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: n/a == Upgrade/compatibility impact == none == How To Test == Basically, the same test procedures as for the full install apply. 1. Install a Fedora Server Edition including virtualization, follow the Server documentation 2. Import the Fedora Server disk image following the Server documentation (staging), either using Cockpit or cli virt-install 3. Use the VM with your intendend server applications. == User Experience == Users (system administrators) will have a VM install method available, which saves them a lot of time and efforts. == Dependencies == none == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) Fedora Server documentation is available. == Release Notes == TBD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: LLVM 15 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/LLVM-15 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update all llvm sub-projects in Fedora Linux to version 15. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: == Detailed Description == All llvm sub-projects in Fedora will be updated to version 15, and there will be a soname version change for the llvm libraries. Compatibility packages clang14 and llvm14 will be added to ensure that packages that currently depend on clang and llvm version 14 libraries will continue to work. == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build release candidates into @fedora-llvm-team/llvm15 COPR. ** Build final release (Sep 2022) into Rawhide and F37 branches. * Other developers: ** Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang14 and llvm14 compatibility packages if they want to rebuild their package and it does not work with LLVM 15 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 15 is added to Fedora. The compatibility packages will ensure that already built packages continue to work. * Release engineering: [https://pagure.io/releng/issues/10820 #10820] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This change should not impact upgradeability. == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 15. == User Experience == == Dependencies == This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 14 will need to update their spec file on their first rebuild after this change. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Contingency mechanism: (What to do? Who will do it?): If there are major problems with LLVM 15, the compatibility package provide a way for other packages to continue using LLVM 14. * Contingency deadline: Final Freeze * Blocks release? No == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 15: llvm clang lld lldb compiler-rt libomp llvm-test-suite libcxx libcxxabi python-lit flang mlir polly libclc llvm-unwind -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.spec#_6
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.
The proposed macros for adding new flags are:
%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags
These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.
%build_cflags %{optflags} %{_pkg_extra_cflags}
The proposed new macros to represent existing flags are:
%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects-ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions-fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches-grecord-gcc-switches
%_flag_pipe-pipe
%_flag_wall-Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard
With these new macros, the examples from above could be re-written as:
compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}
For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8c989b55c631f870ad311cdca87329034be?branch=macro-flags
Prototype Implementation].
In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.
== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.
== Scope ==
* Proposal owners:
** Proposal owners will update the redhat-rpm-config package and add
the new macros.
** Proposal owners will test the changes to ensure that the correct
flags are still being used.
* Other developers:
** Other developers may, but are not required to, update their
packages to use the new macros.
* Release engineering: [https://pagure.io/releng/issues/10819 #10819]
* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None.
== How To Test ==
* This can be tested by inspecting the value of the %{build_cflags},
%{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring
they are the same before and after the change.
* This can be tested by modifying some of
F37 proposal: Fallback Hostname (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/FallbackHostname This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This proposal is for the fallback hostname for server like variants of Fedora to use `localhost` as the fallback hostname. == Owner == * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) * Email: dustym...@redhat.com * Name: [[User:davdunc| David Duncan]] (Fedora Cloud) * Email: davd...@gmail.com * Name: [[User:pwhalen| Paul Whalen]] (Fedora IoT) * Email: pwha...@redhat.com * Name: [[User:salimma| Michel Alexandre Salim]] (Fedora Server) * Email: mic...@michel-slm.name * Name: [[User:ngompa| Neal Gompa]] (Fedora Workstation/KDE) * Email: ngomp...@gmail.com == Detailed Description == In Fedora 33 the default fallback hostname was changed from `localhost` to `fedora` for Fedora Linux instances that didn't get the hostname set in any other way (i.e. it's the fallback if it's not set anywhere else). This change came in a systemd update and was never proposed as a change in Fedora itself. The enablement upstream was in https://github.com/systemd/systemd/pull/5175 and the BZ requesting the change in Fedora was https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original reasoning being that `localhost` is a bad hostname for auto-discovery protocols (think `avahi`) that are useful for more desktop applications. Unfortunately, this caused issues because setting the hostname via reverse DNS lookups (via NetworkManager) stopped working along with breaking third party tools that set the hostname. The NetworkManager problem was subsequently fixed, but it still remains that a lot of third party software will check to see if an instance's hostname is "unset" by checking the current hostname against the string "localhost". Additionally it appears this change will never be picked up by Fedora's primary downstream in CentOS/RHEL (see https://src.fedoraproject.org/rpms/systemd/c/13d1341b108a24d13f5922054307b5c2efc6836a?branch=rawhide). The proposal here is to enable variants of Fedora Linux to configure their default/fallback hostname and to set the default for variants targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`. == Benefit to Fedora == With this change Fedora's server-like variants will become more compatible with third party tools that expect a hostname of `localhost` means the system is unconfigured. It also will mean system administrator's will see `localhost` and assume the hostname is unconfigured. == Scope == * Proposal owners: The feature owners will update the systemd compile time switch for fallback hostname back to `localhost`. The `fedora-release` package will be updated such that the Fedora Server, IoT, Cloud, and CoreOS editions will use `localhost` as the fallback hostname. All other variants of Fedora (the ones that target desktop/laptop uses) will default to `fedora` as the fallback hostname. The proposed changes are a relatively small amount of a work. * Other developers: For any variants other than Cloud, CoreOS, IoT, and Server they will see no change. Work with QA to verify other editions continue to have a fallback hostname of `fedora`. For Cloud, CoreOS, IoT, and Server the default fallback hostname would be `localhost`. * Release engineering: No changes needed for release engineering. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == There will be NO upgrade impact to systems where: * An admin statically set the hostname * A hostname was provided to a system via DHCP * A hostname was found for a system via reverse DNS lookup In the case where none of the above are true for a system (i.e. a fallback hostname will be used) the following upgrade impact will be observed: * Fedora Cloud: No impact. A booted Fedora Cloud 36 instance has `/etc/hostname` written by `cloud-init` on first boot. * Fedora CoreOS: No impact. Already using `localhost` as fallback hostname. * Fedora IoT: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. * Fedora Server: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. For Fedora IoT and Fedora Server we will announce the change and encourage users to statically set a hostname for their machines if they don't want the change in behavior. == How To Test == Boot an instance of the flavor of Fedora you are testing in an environment where there is no DHCP hostname provided and no answer to a reverse DNS lookup for the instance IP. Run `hostnamectl hostname` and verify that it matches expectation. For Fedora Cloud, CoreOS, IoT, Server it should be `localhost`. For all others it should be `fedora`. == User
F37 proposal: Supplement of Server distributables by a KVM VM disk image (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Supplement-server-by-kvm-vm-image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Virtualization has long been a steadily growing use case of Fedora Server Edition, but it is still time consuming and tedious for the system administrator to create a Fedora Server VM. Supplementing the downloads by a KVM VM image remedies the deficiency. == Owner == * Name: [[User:pboy| Peter Boy on behalf of Server WG]] * Email: p...@uni-bremen.de == Detailed Description == The creation of the VM disk image, uses the same kickstart files and installation groups as the standard full installation, except of course for the hardware-specific items. The image is optimized for KVM. That way, the VM resembles a default server installation as closely as possible. All administrative tools are available reliably from the beginning, all administrative routines and helps (scripts) can be used in the same way. All application services work in the identical way. A default VM installation takes 1-2 minutes instead of about 30 mins. == Feedback == The change proposal is based on an extensive discussion of the server WG and has become part of its work program. For example, the server documentation on virtualization has already been significantly expanded in parallel and will continue to be supplemented and updated on an ongoing basis. This is a response to the importance of the topic. == Benefit to Fedora == Significantly improves usability for Fedora Server Edition administrators when deploying a Fedora Server Edtion VM. It thus makes Fedora Server Edition more attractive, especially for new users without extensive experience with Fedora. It thus helps to expand our user base. Fedora finally provides an installation path for a Fedora Server VM that is built entirely on Fedora Resources, subject to Fedora quality control, and compliant with Fedora principles. Until now, if a system administrator has to install a VM preferable without the hassles of a full default installation, we could only recommend third party binary blob (e.g. virt-builder), which is a violation of our own core principles. In addition, the third party products do not provide a 'Fedora Server Edition', but their own different concept and vision of a server, under the name Fedora Server. == Scope == * Proposal owners: A kickstart file for ImageFactory is completed and locally tested. * Other developers: n/a * Release engineering: [https://pagure.io/releng/issues #10768] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: n/a == Upgrade/compatibility impact == none == How To Test == Basically, the same test procedures as for the full install apply. 1. Install a Fedora Server Edition including virtualization, follow the Server documentation 2. Import the Fedora Server disk image following the Server documentation (staging), either using Cockpit or cli virt-install 3. Use the VM with your intendend server applications. == User Experience == Users (system administrators) will have a VM install method available, which saves them a lot of time and efforts. == Dependencies == none == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) Fedora Server documentation is available. == Release Notes == TBD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: LLVM 15 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/LLVM-15 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update all llvm sub-projects in Fedora Linux to version 15. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: == Detailed Description == All llvm sub-projects in Fedora will be updated to version 15, and there will be a soname version change for the llvm libraries. Compatibility packages clang14 and llvm14 will be added to ensure that packages that currently depend on clang and llvm version 14 libraries will continue to work. == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build release candidates into @fedora-llvm-team/llvm15 COPR. ** Build final release (Sep 2022) into Rawhide and F37 branches. * Other developers: ** Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang14 and llvm14 compatibility packages if they want to rebuild their package and it does not work with LLVM 15 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 15 is added to Fedora. The compatibility packages will ensure that already built packages continue to work. * Release engineering: [https://pagure.io/releng/issues/10820 #10820] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This change should not impact upgradeability. == How To Test == The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 15. == User Experience == == Dependencies == This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 14 will need to update their spec file on their first rebuild after this change. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Contingency mechanism: (What to do? Who will do it?): If there are major problems with LLVM 15, the compatibility package provide a way for other packages to continue using LLVM 14. * Contingency deadline: Final Freeze * Blocks release? No == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 15: llvm clang lld lldb compiler-rt libomp llvm-test-suite libcxx libcxxabi python-lit flang mlir polly libclc llvm-unwind -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RPMMacrosForBuildFlags
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Create a corresponding macro for each compiler flag in the
redhat-rpm-config macro file and create "extra flag" macros to make it
easier for packages to add and remove compiler flags.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email:
== Detailed Description ==
The macros file in the redhat-rpm-config package contains a list of
default compiler flags for packages to use when compiling C, C++, and
Fortran packages. There is currently no standard way to remove or add
to the set of default flags. Most packages use a combination of echo
and sed to remove unwanted flags or add new ones. Some examples:
compiler-rt:
[https://src.fedoraproject.org/rpms/compiler-rt/blob/rawhide/f/compiler-rt.spec#_6
global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)]
julia:
[https://src.fedoraproject.org/rpms/julia/blob/rawhide/f/julia.spec#_267
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS
//')]
This change will add new macros which will make it easier for packages
to add and remove their own compiler flags. This strategy is already
used to some extent with feature macros like %{_lto_cflags},
%{_hardening_cflags}, etc, but these new macros will give packagers
even more fine-grained control over the options.
The proposed macros for adding new flags are:
%_pkg_extra_cflags
%_pkg_extra_cxxflags
%_pkg_extra_fflags
%_pkg_extra_ldflags
These will be added to %{build_cflags}, %{build_cxxflags},
%{build_fflags}, and %{build_ldflags} respectively to allow packges to
add their own flags to the default list: e.g.
%build_cflags %{optflags} %{_pkg_extra_cflags}
The proposed new macros to represent existing flags are:
%_flag_fstack_protector_strong -fstack-protector-strong
%_flag_z_now -Wl,-z,now
%_flag_z_defs -Wl,-z,defs
%_flag_flto_auto -flto=auto
%_flag_ffat_lto_objects-ffat-lto-objects
%_flag_o -O2
%_flag_f_exceptions-fexceptions
%_flag_g -g
%_flag_grecord_gcc_switches-grecord-gcc-switches
%_flag_pipe-pipe
%_flag_wall-Wall
%_flag_werror_format_security -Werror=format-security
%_flag_fortify_source -Wp,-D_FORTIFY_SOURCE=2
%_flag_glibcxx_assertions -Wp,-D_GLIBCXX_ASSERTIONS
%_flag_asynchronous_unwind_tables -fasynchronous-unwind-tables
%_flag_fstack_clash_protection -fstack-clash-protection
%_flag_fcf_protection -fcf-protection
%_flag_mbranch_protection_standard -mbranch-protection=standard
With these new macros, the examples from above could be re-written as:
compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
julia: %global _flag_glibcxx_assertions %{nil}
For more details see the
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/0ee9a8c989b55c631f870ad311cdca87329034be?branch=macro-flags
Prototype Implementation].
In addition to adding these new macros, the packaging guidelines will
be updated to require that all new flags added to redhat-rpm-config
have their own RPM macro.
== Benefit to Fedora ==
* It will provide a standard way to disable existing compiler flags or
enable new ones that is more simple and robust than the existing echo
+ sed solution.
* It will make it easier to determine which packages disable or add
compiler flags by doing a simple grep of the spec files.
* It will make it easier for toolchain developers to experiment with
adding new flags to the distribution as this can be done with a simple
macro definition instead of patching redhat-rpm-config.
== Scope ==
* Proposal owners:
** Proposal owners will update the redhat-rpm-config package and add
the new macros.
** Proposal owners will test the changes to ensure that the correct
flags are still being used.
* Other developers:
** Other developers may, but are not required to, update their
packages to use the new macros.
* Release engineering: [https://pagure.io/releng/issues/10819 #10819]
* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None.
== How To Test ==
* This can be tested by inspecting the value of the %{build_cflags},
%{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring
they are the same before and after the change.
* This can be tested by modifying some of
F37 proposal: Fallback Hostname (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/FallbackHostname This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This proposal is for the fallback hostname for server like variants of Fedora to use `localhost` as the fallback hostname. == Owner == * Name: [[User:dustymabe| Dusty Mabe]] (Fedora CoreOS) * Email: dustym...@redhat.com * Name: [[User:davdunc| David Duncan]] (Fedora Cloud) * Email: davd...@gmail.com * Name: [[User:pwhalen| Paul Whalen]] (Fedora IoT) * Email: pwha...@redhat.com * Name: [[User:salimma| Michel Alexandre Salim]] (Fedora Server) * Email: mic...@michel-slm.name * Name: [[User:ngompa| Neal Gompa]] (Fedora Workstation/KDE) * Email: ngomp...@gmail.com == Detailed Description == In Fedora 33 the default fallback hostname was changed from `localhost` to `fedora` for Fedora Linux instances that didn't get the hostname set in any other way (i.e. it's the fallback if it's not set anywhere else). This change came in a systemd update and was never proposed as a change in Fedora itself. The enablement upstream was in https://github.com/systemd/systemd/pull/5175 and the BZ requesting the change in Fedora was https://bugzilla.redhat.com/show_bug.cgi?id=1392925. The original reasoning being that `localhost` is a bad hostname for auto-discovery protocols (think `avahi`) that are useful for more desktop applications. Unfortunately, this caused issues because setting the hostname via reverse DNS lookups (via NetworkManager) stopped working along with breaking third party tools that set the hostname. The NetworkManager problem was subsequently fixed, but it still remains that a lot of third party software will check to see if an instance's hostname is "unset" by checking the current hostname against the string "localhost". Additionally it appears this change will never be picked up by Fedora's primary downstream in CentOS/RHEL (see https://src.fedoraproject.org/rpms/systemd/c/13d1341b108a24d13f5922054307b5c2efc6836a?branch=rawhide). The proposal here is to enable variants of Fedora Linux to configure their default/fallback hostname and to set the default for variants targetting servers (Cloud, CoreOS, IoT, Server) to `localhost`. == Benefit to Fedora == With this change Fedora's server-like variants will become more compatible with third party tools that expect a hostname of `localhost` means the system is unconfigured. It also will mean system administrator's will see `localhost` and assume the hostname is unconfigured. == Scope == * Proposal owners: The feature owners will update the systemd compile time switch for fallback hostname back to `localhost`. The `fedora-release` package will be updated such that the Fedora Server, IoT, Cloud, and CoreOS editions will use `localhost` as the fallback hostname. All other variants of Fedora (the ones that target desktop/laptop uses) will default to `fedora` as the fallback hostname. The proposed changes are a relatively small amount of a work. * Other developers: For any variants other than Cloud, CoreOS, IoT, and Server they will see no change. Work with QA to verify other editions continue to have a fallback hostname of `fedora`. For Cloud, CoreOS, IoT, and Server the default fallback hostname would be `localhost`. * Release engineering: No changes needed for release engineering. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == There will be NO upgrade impact to systems where: * An admin statically set the hostname * A hostname was provided to a system via DHCP * A hostname was found for a system via reverse DNS lookup In the case where none of the above are true for a system (i.e. a fallback hostname will be used) the following upgrade impact will be observed: * Fedora Cloud: No impact. A booted Fedora Cloud 36 instance has `/etc/hostname` written by `cloud-init` on first boot. * Fedora CoreOS: No impact. Already using `localhost` as fallback hostname. * Fedora IoT: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. * Fedora Server: Some impact. The fallback hostname will change from `fedora` to `localhost` after upgrade. For Fedora IoT and Fedora Server we will announce the change and encourage users to statically set a hostname for their machines if they don't want the change in behavior. == How To Test == Boot an instance of the flavor of Fedora you are testing in an environment where there is no DHCP hostname provided and no answer to a reverse DNS lookup for the instance IP. Run `hostnamectl hostname` and verify that it matches expectation. For Fedora Cloud, CoreOS, IoT, Server it should be `localhost`. For all others it should be `fedora`. == User
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > : > > On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: >> >> ... >> >> And even those who can continue to use Fedora Server via update are under >> the threat of having to switch distributions overnight in the event of a >> technical error. Fedora will become unusable for them. A great "feature", >> that you would like to introduce, obviously at all costs. > > Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger > the issue.) According to the latest Anaconda documentation [1] there is no option inst.mbr, there is just inst.gpt. Maybe, it is an undocumented feature. And do we really want our users to fiddle around with editing boot line options as a standard procedure for using a standard use case? [1] https://anaconda-installer.readthedocs.io/en/latest/boot-options.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 on the list, report it: https://pagure.io/fedora-infrastructure
Upcoming changes to Docs presentation
Hi friends! On behalf of the Docs team, I'd like to share with your our plans to reorganize how some documentation is presented to users. You can read about it on the Community Blog[1]. The short version is that we intend to replace the release-based focus with a focus on our variants. Behind the scenes, content will be reused as much as possible, but users will be presented with documentation focused on how they get Fedora Linux: as Workstation, Server, etc. You can see the proof of concept on Fedorapeople[2]. As part of this, we'd like your input and your help. You can always reach us on the #docs tag in Discussion[3] or in #docs:fedoraproject.org on Matrix (#fedora-docs on Libera.chat). We're also holding two office hours next week: * Tuesday June 7, 1500 UTC fedora-meetin...@libera.chat * Thursday June 9 1900 UTC fedora-meetin...@libera.chat [1] https://communityblog.fedoraproject.org/fedora-docs-is-about-to-change-significantly-check-it-out-still-in-statu-nascendi/ [2] https://pboy.fedorapeople.org/fedora/ [3] https://discussion.fedoraproject.org/tag/docs -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2093024] New: perl-Date-Manip-6.88 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2093024 Bug ID: 2093024 Summary: perl-Date-Manip-6.88 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Date-Manip Keywords: FutureFeature, Triaged Assignee: jpazdzi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: huzai...@redhat.com, jpazdzi...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 6.88 Upstream release that is considered latest: 6.88 Current version/release in rawhide: 6.86-2.fc36 URL: http://search.cpan.org/dist/Date-Manip/ 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://fedoraproject.org/wiki/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/2785/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Date-Manip -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2093024 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: > > > > Am 30.05.2022 um 04:28 schrieb Chris Murphy : > > > > On Sun, May 29, 2022 at 6:56 AM Peter Boy wrote: > >> > >> > >> > >> > >> Fedora Server WG discussed the proposal and insists that the proposal be > >> deferred until Anaconda can install software raid on biosboot systems with > >> GPT (see https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and > >> https://lists.fedoraproject.org/archives/list/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > >> - at least for Fedora Server where software raid is a common use. > > > > What's the basis for holding up this feature though? > > Sorry, under the current circumstances your „feature“ is effectively a > regression. It would make it impossible for many Fedora Server users to > continue using Fedora Server as soon as they have to re-install or just want > to set up a new additional server. > > And even those who can continue to use Fedora Server via update are under the > threat of having to switch distributions overnight in the event of a > technical error. Fedora will become unusable for them. A great "feature", > that you would like to introduce, obviously at all costs. Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger the issue.) 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
V Thu, Jun 02, 2022 at 04:33:23PM +0200, Antonio T. sagitter napsal(a):
> Hi all.
>
> rpmuncompress is failing in Rawhide i686 architecture only with:
>
> /usr/bin/tar: Archive value 4027676192 is out of time_t range
> -2147483648..2147483647
> /usr/bin/tar:
> icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js:
> implausibly old time stamp 1969-12-31 23:59:59
> ...
> (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)
>
> If it was an archive issue, it should happen in all architectures.
> Anyone know why this occurs?
>
I don't know tar format, so I cannot tell whether it's a broken archive or
not. Definitely the time stamps are unreal.
tar NEWS files mentions:
On 32-bit hosts, 'tar' now assumes that an incoming time stamp T in
the range 2**31 <= T < 2**32 represents the negative time (T -
2**32). This behavior is nonstandard and is not portable to 64-bit
time_t hosts, so 'tar' issues a warning.
I'm able to reproduce it with "tar tjf icecat-91.10.0-rh2.tar.bz2 >/dev/null"
where tar comes from tar-1.34-3.fc36.i686 and icecat-91.10.0-rh2.tar.bz2 from
currect icecat dist-git sources (SHA512 =
9b46b67d5a6206c491aa9285a361170420cc0b421acd46be8e658b39a26b75c07e89d201525fcbde7bec125699d52970f0fb3d5a7a00dad8408e2a1201ae2f9a).
tar internally stores time stamps in a variable of time_t type. That type is
by default 32-bit on i686 architecture. tar program indeed reports an error if
it cannot internally represent the values read from a tar achive headers.
A possible fix should be compile tar with -D_TIME_BITS=64
-D_FILE_OFFSET_BITS=64 CFLAGS:
$ cat main.c
#include
#include
int main(void) {
printf("sizeof(time_t)=%d\n", sizeof(time_t));
return 0;
}
$ gcc -m32 main.c
$ ./a.out
sizeof(time_t)=4
$ gcc -m32 -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 main.c
$ ./a.out
sizeof(time_t)=8
I recommend you to file a bug against tar in Fedora's Bugzilla. However, this
proposed solution would require rebuilding in the same way all libraries which
tar uses and which pass time_t and similar types in their interface. That
would probably break other packages. So maybe more realisic fix will enhancing
tar to ignore these time stamps when unpacking an archive.
-- 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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
On Thu, 2 Jun 2022 at 10:34, Antonio T. sagitter wrote: > Hi all. > > rpmuncompress is failing in Rawhide i686 architecture only with: > > /usr/bin/tar: Archive value 4027676192 is out of time_t range > -2147483648..2147483647 > /usr/bin/tar: > icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js: > implausibly old time stamp 1969-12-31 23:59:59 > ... > (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log) > > If it was an archive issue, it should happen in all architectures. > Anyone know why this occurs? > > So something seems odd with that file or some sort of conversion and I am guessing it is a 64bit to 32 bit conversion of some sort. [The other architecture it might happen on would be arm32bit which is not in rawhide anymore.] However those dates seem really weird to the point of a corrupt archive or something before that part causing an overflow. Again it is probably a 32 bit/64 bit ``` $ date --date='@4027676192' Sun 18 Aug 10:56:32 EDT 2097 ``` on a 64 bit architecture and on a 32 bit would wrap to -267291104 (?? I think I got that right). The error I see above is that should be a time stamp of 'Thu 13 Jul 04:28:16 EDT 1961' > Best, > -- > --- > Antonio Trande > Fedora Project > mailto: sagit...@fedoraproject.org > GPG key: 0xCC1CFEF30920C8AE > GPG key server: https://keyserver1.pgp.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 on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Archive value is out of time_t range
Antonio T. sagitter wrote on 2022/06/02 23:33: Hi all. rpmuncompress is failing in Rawhide i686 architecture only with: /usr/bin/tar: Archive value 4027676192 is out of time_t range -2147483648..2147483647 /usr/bin/tar: icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js: implausibly old time stamp 1969-12-31 23:59:59 ... (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log) If it was an archive issue, it should happen in all architectures. Anyone know why this occurs? Best, Perhaps it is 32 bit architecture. Actually: [tasaka1@localhost icecat-91.10.0]$ ls -al extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js -rw-r--r--. 1 tasaka1 tasaka1 433208 Jul 29 2114 extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js This is above year 2038. (Anyway the timestamp on this file seems strange.) Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Archive value is out of time_t range
Hi all. rpmuncompress is failing in Rawhide i686 architecture only with: /usr/bin/tar: Archive value 4027676192 is out of time_t range -2147483648..2147483647 /usr/bin/tar: icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js: implausibly old time stamp 1969-12-31 23:59:59 ... (https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log) If it was an archive issue, it should happen in all architectures. Anyone know why this occurs? Best, -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0xCC1CFEF30920C8AE GPG key server: https://keyserver1.pgp.com/ OpenPGP_0xCC1CFEF30920C8AE.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 on the list, report it: https://pagure.io/fedora-infrastructure
Take the Fedora Annual Contributor Survey 2022
Hello, everyone, Please participate in the Fedora Annual Contributor Survey 2022! * https://fedoraproject.limequery.com/2022 The survey is anonymous, it has 44 questions targeting Fedora contributors of all kinds and asks about your default choices of applications and services. This is the second run of the survey. The questions are the same as last year with more variants added according to the data we have collected. We will compare answers for this year with the previous year results. At the end of the survey you will get the claim link for the badge. For questions and feedback please refer to the forum thread: * https://discussion.fedoraproject.org/t/we-want-to-hear-from-you-take-the-fedora-annual-contributor-survey-for-2022/39576 Thank you for your contribution! -- Aleksandra Fedorova bookwar on Matrix/IRC ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Take the Fedora Annual Contributor Survey 2022
Hello, everyone, Please participate in the Fedora Annual Contributor Survey 2022! * https://fedoraproject.limequery.com/2022 The survey is anonymous, it has 44 questions targeting Fedora contributors of all kinds and asks about your default choices of applications and services. This is the second run of the survey. The questions are the same as last year with more variants added according to the data we have collected. We will compare answers for this year with the previous year results. At the end of the survey you will get the claim link for the badge. For questions and feedback please refer to the forum thread: * https://discussion.fedoraproject.org/t/we-want-to-hear-from-you-take-the-fedora-annual-contributor-survey-for-2022/39576 Thank you for your contribution! -- Aleksandra Fedorova bookwar on Matrix/IRC ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2092465] perl-Locale-Codes-3.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2092465 --- Comment #3 from Fedora Update System --- FEDORA-2022-7355a6763b has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-7355a6763b -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2092465 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2092465] perl-Locale-Codes-3.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2092465 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2022-395a54cbff has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-395a54cbff -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2092465 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Locale-Codes] PR #15: 3.71 bump
mspacek merged a pull-request against the project: `perl-Locale-Codes` that you are following. Merged pull-request: `` 3.71 bump `` https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/15 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Locale-Codes] PR #15: 3.71 bump
mspacek opened a new pull-request against the project: `perl-Locale-Codes` that you are following: `` 3.71 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/15 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-CPAN-FindDependencies] PR #2: Debug gating
ppisar closed without merging a pull-request against the project: `perl-CPAN-FindDependencies` that you are following. Closed pull-request: `` Debug gating `` https://src.fedoraproject.org/rpms/perl-CPAN-FindDependencies/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-CPAN-FindDependencies] PR #2: Debug gating
ppisar commented on the pull-request: `Debug gating` that you are following: `` Applied to rawhide. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-CPAN-FindDependencies/pull-request/2 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Locale-Codes] PR #14: 3.71 bump
mspacek merged a pull-request against the project: `perl-Locale-Codes` that you are following. Merged pull-request: `` 3.71 bump `` https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/14 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Locale-Codes] PR #14: 3.71 bump
mspacek opened a new pull-request against the project: `perl-Locale-Codes` that you are following: `` 3.71 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/14 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Locale-Codes] PR #13: 3.71 bump
mspacek merged a pull-request against the project: `perl-Locale-Codes` that you are following. Merged pull-request: `` 3.71 bump `` https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/13 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[rpms/perl-Locale-Codes] PR #13: 3.71 bump
mspacek opened a new pull-request against the project: `perl-Locale-Codes` that you are following: `` 3.71 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/13 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2092465] perl-Locale-Codes-3.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2092465 Michal Josef Spacek changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value --- Comment #1 from Michal Josef Spacek --- Changes: 3.71 2022-06-01 sbeck - NEW CODE(s) New languages codes. For f35, f36 and rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2092465 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Unretire Nebula (kind of)
Hi everyone, I have the intention of un-retiring the nebula package, but for a different software. In fact, the new software is github.com/slackhq/nebula while the previous one was downloads.sourceforge.net/nebula. Calling the package nebula, even if it's a golang packages is the correct behavior according to the documentation [0] since we are talking about a package that provide a well-known application. I've opened a releng ticket on this as well [1]. Best, Fale [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_source_packages_src_rpm [1] https://pagure.io/releng/issue/10822 -- Fabio Alessandro Locati fale.io ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20220602.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220601.0): ID: 1287611 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1287611 ID: 1287619 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1287619 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
the-new-hotness 1.2.0 released
Hello everyone, it's here! Hotness 1.2.0 was released! For those who don't know, the-new-hotness is the application that creates the notification for new releases on bugzilla for release-monitoring.org. The new version brings a lot of new things and I highlight some of them in this e-mail: * *Support for stable versions only* - now Hotness is supporting the settings to only notify about stable versions (only those that are recognized as stable by release-monitoring.org) * *Change in the-new-hotness to work with multiple versions notified at once* - Hotness is now able to notify you about multiple versions at once. This also adds new monitoring settings, where you can be notified about any newly retrieved version by Anitya regardless if it's considered newest or not (good for watching for new releases in old major versions) Both of the above changes are for now only in Hotness and PR is waiting on pagure [0] and dist-git [1]. * *Add link to monitoring setting to Bugzilla notification* - The Bugzilla notification generated by Hotness now contains link to dist-git so user can quickly change the monitoring settings if needed. Example on staging [2] To see full changelog, please look at the-new-hotness release [3]. The version is already running in the fedora infra, so you should already ripe the fruit of this work. :-) Michal Mage from release-monitoring.org [0] - https://pagure.io/pagure/pull-request/5294 [1] - https://pagure.io/pagure-dist-git/pull-request/151 [2] - https://bugzilla.stage.redhat.com/show_bug.cgi?id=1827715#c81 [3] - https://github.com/fedora-infra/the-new-hotness/releases/tag/1.2.0___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: intend to orphan python-cairosvg
Hi Neal, I made you an admin and orphaned python-cairosvg so you can claim it as "main admin" if you like. You should probably also take a look at cairocffi which is FTBFS due to failures in the test suite: https://src.fedoraproject.org/rpms/python-cairocffi Technically Eric Smith is the main admin for this package but he did not push any commits in the last months and there is a history of non-responsive maintainer requests so I consider the package as "unmaintained". Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Non-responsive maintainer for madko/glances
Hello I've sent a PR [1] for Glances and tried to reach madko but I didnt get any response. Meanwhile upstream released various new versions, and bugs were reported [2] + no package update since F33. So I started the non-responsive maintainer* process [3]. Does anyone know him, or if he is still active ? I would be happy to help or take over maintaining this package. 1 : https://src.fedoraproject.org/rpms/glances/pull-request/4 2 : https://bugzilla.redhat.com/show_bug.cgi?id=1870254 3 : https://bugzilla.redhat.com/show_bug.cgi?id=2088744 Best Regards, Ali Erdinc Koroglu - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-36-20220602.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-36-20220601.0): ID: 1287537 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1287537 ID: 1287545 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1287545 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 2092730] New: perl-Test-Compile-3.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2092730 Bug ID: 2092730 Summary: perl-Test-Compile-3.1.0 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Compile Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.1.0 Current version/release in rawhide: 3.0.1-2.fc36 URL: http://search.cpan.org/dist/Test-Compile/ 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://fedoraproject.org/wiki/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/3388/ -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2092730 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: intend to orphan python-cairosvg
On Thu, Jun 2, 2022 at 6:50 AM Julian Sikorski wrote: > > Am 31.05.22 um 12:44 schrieb Felix Schwarz: > > Hi *, > > > > I'd like to orphan python-cairosvg. This package was required by older > > WeasyPrint releases but WeasyPrint v53 (Fedora 35+) stopped using cairo > > so I don't use this package anymore. > > > > The package should be ok however I expect very little upstream > > maintainance as the code was maintained by the WeasyPrint. The most > > pressing problem is likely an FTBFS bug for python-cairocffi. > > > > If you need cairosvg, this is the time to step forward :-) > > > > Felix > > > Hello, > > thanks for the heads up. For python-sphinxcontrib-svg2pdfconverter > cairosvg is optional, so if it is more or less going to be abandoned > upstream, I will just drop the dependency. Buildbot requires cairosvg to be able to generate badges for embedding into sites, so I need this and can't drop the dependency. I guess you can add me as a maintainer. -- 真実はいつも一つ！/ 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 on the list, report it: https://pagure.io/fedora-infrastructure
