[Bug 2158523] perl-MCE-1.884 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158523 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Fixed In Version||perl-MCE-1.884-1.fc38 Resolution|--- |RAWHIDE Last Closed||2023-01-06 06:55:33 --- Comment #1 from Paul Howarth --- Already built: https://koji.fedoraproject.org/koji/buildinfo?buildID=2107184 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158523 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: static USERMODEHELPER_PATH
On 6/1/23 10:12, Steve Grubb wrote: Hello, I want to add some missing information... On Thursday, January 5, 2023 8:43:34 PM EST Ian Kent wrote: On 6/1/23 09:17, Steve Grubb wrote: I work on RHEL security problems. I have been looking into a number of exploits and I think we have a problem that has an easy fix. Here's some examples of what I'm look in at: https://twitter.com/ETenal7/status/1506708119757328385 https://lkmidas.github.io/posts/20210223-linux-kernel-pwn-modprobe/ https://etenal.me/archives/1825 https://twitter.com/ky1ebot/status/1539820418479009792 https://github.com/theori-io/CVE-2022-32250-exploit https://seclists.org/oss-sec/2022/q3/154 etc We are not using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number of exploits that overwrite the path to modprobe and then pass something weird that causes modprobe to be invoked. But instead of modprobe, it's their reverse shell. If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/ kernel/core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, then it limits any exploits to programs that are in /usr. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ kernel/umh.c?h=v5.15#n371 Right, but the above description isn't quite how these config options are meant to work. To be maintainable in Fedora the way in which we utilize the bits that are setup to do this type of thing would need to be inline with the way they are intended to be used. CONFIG_STATIC_USERMODEHELPER enables this, CONFIG_STATIC_USERMODEHELPER_PATH allows you to specify the path to the binary through with "all" usermode helper invocations are done. So we would need to write something that validates its own path and the path of the thing to be invoked and, if all is ok, execute the program. The problem I see with this is that modprobe isn't the only thing used with umh, there are a number of other things that use this so some care is going to be needed in what is done and how it's done. The idea of only allowing specific path prefixes sounds ok since it's simple, fairly safe, umh kernel users really should be using programs in "safe" locations, so this all sounds doable ... I'm sure there will be a bunch of gotchas ... Ian Only root can write here, therefore no escalation. Typically, an exploit changes modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and an area the attacker can control. For this mitigation, we'd need to: 1) set the config option in the kernel build 2) update /proc/sys/kernel/modprobe however it's set (CONFIG_MODPROBE_PATH) 3) update /proc/sys/kernel/core_pattern however it's set If we fix the modprobe path issue, there are a couple other areas that call usermode helper such as handle_initrd, fork_usermode_driver, CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch ups. The benefit is a lot of privilege escalation attacks are taken away. Does this sound worthwhile? Would people support this? Does this need to be filed as a system wide change? Who could help make this happen if approved? It sounds worth while to me, ;) Thanks for the initial vote of confidence. It's 3 am in Europe, so I'll wait a bit for feedback. -Steve I'd be up for helping with it. As much as I hate working in the proc file system I can try and work out what needs to be done for the proc file system bits. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158668] New: perl-Test-Routine-0.030 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158668 Bug ID: 2158668 Summary: perl-Test-Routine-0.030 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Routine Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.030 Upstream release that is considered latest: 0.030 Current version/release in rawhide: 0.029-1.fc38 URL: https://metacpan.org/dist/Test-Routine Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/12627/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Test-Routine -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158668 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158661] New: perl-Modern-Perl-1.20230106 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158661 Bug ID: 2158661 Summary: perl-Modern-Perl-1.20230106 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Modern-Perl Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.20230106 Upstream release that is considered latest: 1.20230106 Current version/release in rawhide: 1.20220515-3.fc37 URL: http://search.cpan.org/dist/Modern-Perl/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3076/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Modern-Perl -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158661 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158661] perl-Modern-Perl-1.20230106 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158661
--- Comment #1 from Upstream Release Monitoring
---
Scratch build failed. Details below:
GenericError: File upload failed:
cli-build/1672970949.5317044.avYDYBuB/perl-Modern-Perl-1.20230106-1.fc36.src.rpm
Traceback:
File
"/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3083, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
File "/usr/lib/python3.10/site-packages/koji/__init__.py", line 3018, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))
If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2158661
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: static USERMODEHELPER_PATH
Hello, I want to add some missing information... On Thursday, January 5, 2023 8:43:34 PM EST Ian Kent wrote: > On 6/1/23 09:17, Steve Grubb wrote: > > I work on RHEL security problems. I have been looking into a number of > > exploits and I think we have a problem that has an easy fix. Here's some examples of what I'm look in at: https://twitter.com/ETenal7/status/1506708119757328385 https://lkmidas.github.io/posts/20210223-linux-kernel-pwn-modprobe/ https://etenal.me/archives/1825 https://twitter.com/ky1ebot/status/1539820418479009792 https://github.com/theori-io/CVE-2022-32250-exploit https://seclists.org/oss-sec/2022/q3/154 etc > > We are not > > using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There > > are a number of exploits that overwrite the path to modprobe and then > > pass something weird that causes modprobe to be invoked. But instead of > > modprobe, it's their reverse shell. > > > > If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and > > we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/ > > kernel/core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, > > then it limits any exploits to programs that are in /usr. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ kernel/umh.c?h=v5.15#n371 > > Only root can > > write here, therefore no escalation. Typically, an exploit changes > > modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and > > an area the attacker can control. > > > > For this mitigation, we'd need to: > > > > 1) set the config option in the kernel build > > 2) update /proc/sys/kernel/modprobe however it's set > > (CONFIG_MODPROBE_PATH) > > 3) update /proc/sys/kernel/core_pattern however it's set > > > > If we fix the modprobe path issue, there are a couple other areas that > > call usermode helper such as handle_initrd, fork_usermode_driver, > > CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch > > ups. > > > > The benefit is a lot of privilege escalation attacks are taken away. > > > > Does this sound worthwhile? Would people support this? Does this need to > > be filed as a system wide change? Who could help make this happen if > > approved? > > It sounds worth while to me, ;) Thanks for the initial vote of confidence. It's 3 am in Europe, so I'll wait a bit for feedback. -Steve > I'd be up for helping with it. > > As much as I hate working in the proc file system I can try > and work out what needs to be done for the proc file system > bits. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: static USERMODEHELPER_PATH
On 6/1/23 09:17, Steve Grubb wrote: Hello, I work on RHEL security problems. I have been looking into a number of exploits and I think we have a problem that has an easy fix. We are not using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number of exploits that overwrite the path to modprobe and then pass something weird that causes modprobe to be invoked. But instead of modprobe, it's their reverse shell. If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/kernel/ core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, then it limits any exploits to programs that are in /usr. Only root can write here, therefore no escalation. Typically, an exploit changes modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and an area the attacker can control. For this mitigation, we'd need to: 1) set the config option in the kernel build 2) update /proc/sys/kernel/modprobe however it's set (CONFIG_MODPROBE_PATH) 3) update /proc/sys/kernel/core_pattern however it's set If we fix the modprobe path issue, there are a couple other areas that call usermode helper such as handle_initrd, fork_usermode_driver, CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch ups. The benefit is a lot of privilege escalation attacks are taken away. Does this sound worthwhile? Would people support this? Does this need to be filed as a system wide change? Who could help make this happen if approved? It sounds worth while to me, ;) I'd be up for helping with it. As much as I hate working in the proc file system I can try and work out what needs to be done for the proc file system bits. Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
static USERMODEHELPER_PATH
Hello, I work on RHEL security problems. I have been looking into a number of exploits and I think we have a problem that has an easy fix. We are not using the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number of exploits that overwrite the path to modprobe and then pass something weird that causes modprobe to be invoked. But instead of modprobe, it's their reverse shell. If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and we change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/kernel/ core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, then it limits any exploits to programs that are in /usr. Only root can write here, therefore no escalation. Typically, an exploit changes modprobe path to /tmp/ foo which is shorter than /usr/sbin/modprobe and an area the attacker can control. For this mitigation, we'd need to: 1) set the config option in the kernel build 2) update /proc/sys/kernel/modprobe however it's set (CONFIG_MODPROBE_PATH) 3) update /proc/sys/kernel/core_pattern however it's set If we fix the modprobe path issue, there are a couple other areas that call usermode helper such as handle_initrd, fork_usermode_driver, CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch ups. The benefit is a lot of privilege escalation attacks are taken away. Does this sound worthwhile? Would people support this? Does this need to be filed as a system wide change? Who could help make this happen if approved? Thanks, -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote: > On Thu, 5 Jan 2023 at 08:20, David Cantrell wrote: > > > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > > [...] > > > > > So I guess this means no remoting into ppc64 or s390x machines from > > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > > > We don't have ppc64 builds anymore and I don't know the last release > > we had > > > > that was ppc64, but it was a long time ago now. All current POWER > > systems are > > > > ppc64le. > > > > > > > > And everything else we have as primary or alternative architectures is > > little > > > > endian, except s390x. I do view this as a risk for s390x because of > > all the > > > > architectures we build for, this one is the most difficult to use > > graphically. > > > > Exporting your display is still the convenient method for this > > platform. > > > > > > > > Given that this change proposal affects default behavior, I don't see a > > > > problem with it. s390x users can drop the configuration change in > > xorg.conf.d > > > > to regain the functionality. If that can be conditionally enabled for > > s390x > > > > at package build time, that might make things easier (but wouldn't you > > need to > > > > make the change on both the s390x host and your non-s390x > > workstation?). > > > > > > The X protocol works that the first byte of the connection request is a > > > either 'l' or 'B', telling the server that the client is little or Big > > > endian. The client has no information on the server's endianess. > > > > > > This means the configuration needs to be done wherever your X server > > > runs, so the (little-endian) thing you're sitting in front of. Which is > > > also why compile-time defaults are difficult, at compile time we cannot > > > know that eventually you may want to connect from an s390x. > > > > Reasonable. The runtime configuration change I can make locally to allow > > me > > to run X programs on an s390x and display them locally is sufficient for > > me. > > > > Wasn't there a concern that you can do this if you are running a desktop > with X, but if you are using Xwayland it isn't easy (or maybe possible) as > the configuration to do that was either hardcoded or not fully documented > on how to do that? > > From Peter Hutterer earlier: > ``` > but you don't necessarily have > access to how Xwayland is started (mutter certainly is hard-coded). > ``` Correct, the Wayland compositor is responsible for starting up XWayland and that's not always configurable. I've filed bugs for mutter, kwin and wlroots so the developers are aware and that should cover the majority of Wayland use-cases once fixed. Cheers, Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158129] Add perl-Lexical-Persistence to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2158129 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-4f0fce78cf has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4f0fce78cf 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=2158129 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158091] Add perl-Graphics-TIFF to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2158091 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-2eb0e878bc has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-2eb0e878bc 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=2158091 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158130] Add perl-MooseX-Object-Pluggable to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2158130 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-fcf15307d5 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-fcf15307d5 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=2158130 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e9a9c081af novnc-1.3.0-5.el7 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-afa80a1455 cacti-1.2.23-1.el7 cacti-spine-1.2.23-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing mock-core-configs-36.14-1.el7 python-importlib-metadata-0.23-4.el7 viewvc-1.1.30-1.el7 Details about builds: mock-core-configs-36.14-1.el7 (FEDORA-EPEL-2023-85babda35e) Mock core config files basic chroots Update Information: - missmatching gpg key and rpms in openEuler 20.03 LTS (pkwarcr...@gmail.com) - drop unneccessary module docs from configuration files (nka...@gmail.com) ChangeLog: * Thu Jan 5 2023 Pavel Raiskup 36.14-1 - missmatching gpg key and rpms in openEuler 20.03 LTS (pkwarcr...@gmail.com) - drop unneccessary module docs from configuration files (nka...@gmail.com) python-importlib-metadata-0.23-4.el7 (FEDORA-EPEL-2023-4039c7d8b9) Read metadata from Python packages Update Information: Reenable test as dependencies now available SPDX license update ChangeLog: * Thu Jan 5 2023 Frank Crawford - 0.23-4 - Reenable test as dependencies now available - SPDX license update References: [ 1 ] Bug #2128811 - Need build for EPEL7 for Chromium to keep building https://bugzilla.redhat.com/show_bug.cgi?id=2128811 viewvc-1.1.30-1.el7 (FEDORA-EPEL-2023-96ef72f1b2) Browser interface for CVS and SVN version control repositories Update Information: Two security fixes: - CVE-2023-22456: https://github.com/viewvc/viewvc/releases/tag/1.1.29 - CVE-2023-22464: https://github.com/viewvc/viewvc/releases/tag/1.1.30 ChangeLog: * Thu Jan 5 2023 Bojan Smojver - 1.1.30-1 - bump up to 1.1.30 - CVE-2023-22464 * Wed Jan 4 2023 Bojan Smojver - 1.1.29-1 - bump up to 1.1.29 - CVE-2023-22456 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158640] New: perl-Moo-2.005005 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158640 Bug ID: 2158640 Summary: perl-Moo-2.005005 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Moo Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 2.005005 Upstream release that is considered latest: 2.005005 Current version/release in rawhide: 2.005004-6.fc37 URL: http://search.cpan.org/dist/Moo/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/3123/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Moo -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158640 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedoras GnuPG default option is deprecated
Indeed, makes sense. It is not reported atm in bugzilla, but I just had a few minutes time. I filed it against gnupg2 and referred to this mailing list topic and to the upstream link Todd provided: https://bugzilla.redhat.com/show_bug.cgi?id=2158627 On 05/01/2023 04:05, Peter Robinson wrote: On Wed, Jan 4, 2023 at 3:37 PM Christopher Klooz wrote: A fresh installation of Fedora 37 has by default the "--supervised" option active in its gpg-agent systemd file (/usr/lib/systemd/user/gpg-agent.service). According to GnuPG Docs [1], this option is deprecated. Once gpg-agent is invoked, the log of "systemctl --user status gpg-agent.service" confirms that with: "gpg-agent[2022]: WARNING: "--supervised" is a deprecated option" Is this intended? Off the cuff I do not see an immediate security issue, but I guess it makes sense to get over deprecated options. I would check bug reports [1] and file a bug if there's not one already so it can be tracked, the maintainer may not follow this list closely. [1] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=gnupg2=Fedora=Fedora%20EPEL ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On 5/01/2023 01:52, Tom Callaway wrote: Hi Fedora, TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in rawhide today. I've done extensive local testing in mock to try to make sure it doesn't break anything obvious... but the size and scope of TL means that there are probably still some bugs introduced by this update. Please let me know if something stops building as a result of the new texlive packages, either via email, bugzilla, twitter, mastodon, or carrier pigeon, with as much detail as you can provide. I do not plan to push this to any stable Fedora, BUT, I have tested with it installed over Fedora 37 and it seems to work okay for me. Apologies on the delay in getting this done. I realize TL 2023 is probably coming out in a few months, hopefully, it will not take a year for me to get that update in place. Hi Spot, Thank you for your hard work! I use texlive daily and really appreciate it. I'm not sure if this is helps you, but I compiled a few of my largest documents (~600 pages in total with lots of math and figures) and visually compared one of them without any errors. -- Arthur Bols fas/irc: principis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Heads-up: libfplll 5.4.4 coming to Rawhide
That should have been python-fpylll, not python-fplll. On 1/5/23 14:29, Ben Beasley wrote: In one week (2023-01-12), or slightly later, I plan to build libfplll 5.4.4[1] in a side tag for Rawhide. This release is API-compatible with 5.4.2, but there is an ABI-breaking change[2], so the .so version increases from 7 to 8. I have verified compatibility with dependent packages in COPR[3]. Maintainers of affected packages should have received a copy of this email directly: - gap-pkg-float - linbox - Macaulay2 - python-fplll - sagemath When the side tag is ready, I will send another email to these packages’ maintainers so they can do the necessary rebuilds. If some maintainers are unavailable and it looks like I won’t be able to close the side tag before the F38 mass rebuild begins on 2023-01-18, I will ask a provenpackager to finish the rebuilds. [1] https://src.fedoraproject.org/rpms/libfplll/pull-request/2 [2] https://github.com/fplll/fplll/issues/502 [3] https://copr.fedorainfracloud.org/coprs/music/libfplll/packages/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads-up: libfplll 5.4.4 coming to Rawhide
In one week (2023-01-12), or slightly later, I plan to build libfplll 5.4.4[1] in a side tag for Rawhide. This release is API-compatible with 5.4.2, but there is an ABI-breaking change[2], so the .so version increases from 7 to 8. I have verified compatibility with dependent packages in COPR[3]. Maintainers of affected packages should have received a copy of this email directly: - gap-pkg-float - linbox - Macaulay2 - python-fplll - sagemath When the side tag is ready, I will send another email to these packages’ maintainers so they can do the necessary rebuilds. If some maintainers are unavailable and it looks like I won’t be able to close the side tag before the F38 mass rebuild begins on 2023-01-18, I will ask a provenpackager to finish the rebuilds. [1] https://src.fedoraproject.org/rpms/libfplll/pull-request/2 [2] https://github.com/fplll/fplll/issues/502 [3] https://copr.fedorainfracloud.org/coprs/music/libfplll/packages/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: TeXLive2022 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/TeXLive2022 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the TeXLive engines and components in Fedora to the 2022 version. This will improve TeX document processing, conversion, and internationalization, which is used by some Fedora packages (and users). == Owner == * Name: [[User:spot| Tom Callaway]] * Email: spo...@gmail.com == Detailed Description == The goal is to update Fedora to the latest available version of TeXLive (2022), including its large number of associated components. This will resolve outstanding bugs in the existing TeXLive (2021) packages, add new features, improve performance, and expand internationalization support. == Benefit to Fedora == Updating to TeXLive 2022 brings the latest versions of the TeX engines and components into Fedora, which improves document rendering and conversion. A number of Fedora packages include TeX support, which depend on the TeXLive utilities. In each TeXLive release, a large (hundreds) number of TeX components are updated, a significant (~100) number of new TeX components are added, and core functionality is enhanced and optimized. Documents should render properly and export into various formats without issues. == Scope == * Proposal owners: The necessary changes are contained to the texlive and texlive-base packages. These changes have already landed in rawhide. * Other developers No changes should be necessary for other packagers/developers. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: It does not align with any current Objectives. == Upgrade/compatibility impact == Users will need to delete old TexLive 2021 cache in order to properly use TeXLive 2022 upon an upgrade. To do this, a user simply (and carefully) needs to run: rm -rf ~/.texlive2021 A new ~/.texlive2022 directory will be generated and used when the user invokes TeXLive related functionality, but TeXLive will attempt to use the older cache directory and it will not work properly. == How To Test == Packagers who have packages that use TeX to generate documentation should simply attempt to rebuild their package in rawhide with the TeXLive 2022 packages. If it succeeds and the documents generated are correct, nothing further is necessary. If it fails or the documents generated are corrupted/damaged, please open a bug against the texlive component. == User Experience == The way that the user interacts with TeX/TeXLive does not change in this release. A very small number of components (~10) in TeXLive have been obsoleted and removed, but they have either been silently replaced by other functionality or they were outdated documentation. == Dependencies == While other packages in Fedora do depend on texlive component packages, this is almost always for build-time generation of documentation, and not in a traditional "linking to library" approach. Packages with tex() or texlive dependencies should not need to make any changes to use TeXLive 2022. == Contingency Plan == * Contingency mechanism: Roll back to latest texlive/texlive-base 2021 packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == https://tug.org/texlive/bugs.html == Release Notes == Fedora 38 has updated its TeXLive support to 2022. Users who upgrade from older versions of Fedora and who have used TeXLive previously may need to delete the ~/.texlive2021 cache directory in order to have a working TeXLive environment. A new ~/.texlive2022 cache directory will be generated on first use of TeXLive 2022, but TeX will attempt to use older cache directories if they exist. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: TeXLive2022 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/TeXLive2022 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the TeXLive engines and components in Fedora to the 2022 version. This will improve TeX document processing, conversion, and internationalization, which is used by some Fedora packages (and users). == Owner == * Name: [[User:spot| Tom Callaway]] * Email: spo...@gmail.com == Detailed Description == The goal is to update Fedora to the latest available version of TeXLive (2022), including its large number of associated components. This will resolve outstanding bugs in the existing TeXLive (2021) packages, add new features, improve performance, and expand internationalization support. == Benefit to Fedora == Updating to TeXLive 2022 brings the latest versions of the TeX engines and components into Fedora, which improves document rendering and conversion. A number of Fedora packages include TeX support, which depend on the TeXLive utilities. In each TeXLive release, a large (hundreds) number of TeX components are updated, a significant (~100) number of new TeX components are added, and core functionality is enhanced and optimized. Documents should render properly and export into various formats without issues. == Scope == * Proposal owners: The necessary changes are contained to the texlive and texlive-base packages. These changes have already landed in rawhide. * Other developers No changes should be necessary for other packagers/developers. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: It does not align with any current Objectives. == Upgrade/compatibility impact == Users will need to delete old TexLive 2021 cache in order to properly use TeXLive 2022 upon an upgrade. To do this, a user simply (and carefully) needs to run: rm -rf ~/.texlive2021 A new ~/.texlive2022 directory will be generated and used when the user invokes TeXLive related functionality, but TeXLive will attempt to use the older cache directory and it will not work properly. == How To Test == Packagers who have packages that use TeX to generate documentation should simply attempt to rebuild their package in rawhide with the TeXLive 2022 packages. If it succeeds and the documents generated are correct, nothing further is necessary. If it fails or the documents generated are corrupted/damaged, please open a bug against the texlive component. == User Experience == The way that the user interacts with TeX/TeXLive does not change in this release. A very small number of components (~10) in TeXLive have been obsoleted and removed, but they have either been silently replaced by other functionality or they were outdated documentation. == Dependencies == While other packages in Fedora do depend on texlive component packages, this is almost always for build-time generation of documentation, and not in a traditional "linking to library" approach. Packages with tex() or texlive dependencies should not need to make any changes to use TeXLive 2022. == Contingency Plan == * Contingency mechanism: Roll back to latest texlive/texlive-base 2021 packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == https://tug.org/texlive/bugs.html == Release Notes == Fedora 38 has updated its TeXLive support to 2022. Users who upgrade from older versions of Fedora and who have used TeXLive previously may need to delete the ~/.texlive2021 cache directory in order to have a working TeXLive environment. A new ~/.texlive2022 cache directory will be generated on first use of TeXLive 2022, but TeX will attempt to use older cache directories if they exist. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On 1/5/23 11:08, Frank Ch. Eigler wrote: > >> Of course, but the benefit is to fix performance bugs in applications >> or maybe the desktop itself. [...] > >>> Let's be firm in testing this empirically rather than aspirationally. >> I really don't know how. Suggestions welcome. > > I'd put the onus on the proponents of the Change, who made predictions > like "I'm confident that over the course of the next year, we'll recover > performance that was lost by FORTIFY_SOURCE=3 and frame pointers" and > "The optimizations enabled by profiling can be much larger than 3-10%." As the one who made this statement: Profiling can result in very large gains. I cannot predict what the actual gains will be. > There needs to be substance behind such predictions if they are going > to be used as justification for slowing things down in the mean time. I agree. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157775] Please branch and build cpanspec in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2157775 --- Comment #3 from Michal Josef Spacek --- Branch requested: https://pagure.io/releng/fedora-scm-requests/issue/50279 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157775 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157775] Please branch and build cpanspec in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2157775 Michal Josef Spacek changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157775 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On 04. 01. 23 17:29, Jonathan Wakely wrote: On Tue, 3 Jan 2023 at 09:39, Miro Hrončok wrote: = New business = #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to default compilation flags https://pagure.io/fesco/issue/2923 Given the controversial nature of this one, why was it re-litigated at short notice when a large number of the stakeholders were still on vacation? Presumably because it now had majority support in FESCo and waiting extra week would collie with the mass rebuild. See https://pagure.io/fesco/issue/2923#comment-833432 and the meting logs https://meetbot.fedoraproject.org/fedora-meeting/2023-01-03/fesco.2023-01-03-17.01.log.html -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2140480] perl-Dist-Zilla-6.029 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2140480 Michal Josef Spacek changed: What|Removed |Added Resolution|--- |RAWHIDE Status|ASSIGNED|CLOSED Last Closed||2023-01-05 16:31:40 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2140480 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #1: 6.029 bump
mspacek merged a pull-request against the project: `perl-Dist-Zilla` that you are following. Merged pull-request: `` 6.029 bump `` https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158523] New: perl-MCE-1.884 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158523 Bug ID: 2158523 Summary: perl-MCE-1.884 is available Product: Fedora Version: rawhide Status: NEW Component: perl-MCE Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.884 Upstream release that is considered latest: 1.884 Current version/release in rawhide: 1.883-1.fc38 URL: http://search.cpan.org/dist/MCE/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5965/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-MCE -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158523 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
> Of course, but the benefit is to fix performance bugs in applications > or maybe the desktop itself. [...] >> Let's be firm in testing this empirically rather than aspirationally. > I really don't know how. Suggestions welcome. I'd put the onus on the proponents of the Change, who made predictions like "I'm confident that over the course of the next year, we'll recover performance that was lost by FORTIFY_SOURCE=3 and frame pointers" and "The optimizations enabled by profiling can be much larger than 3-10%.", and that's just in the last few days. There needs to be substance behind such predictions if they are going to be used as justification for slowing things down in the mean time. - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Dist-Zilla] PR #1: 6.029 bump
mspacek opened a new pull-request against the project: `perl-Dist-Zilla` that you are following: `` 6.029 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Dist-Zilla/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2140480] perl-Dist-Zilla-6.029 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2140480 Michal Josef Spacek changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value --- Comment #4 from Michal Josef Spacek --- Changes: 6.029 2022-11-25 17:02:33-05:00 America/New_York - update some links to use https instead of http (thanks, Elvin Aslanov) - turn on strict and warnings in generated author tests (thanks, Mark Flickinger) - use "v1.2.3" for multi-dot versions in "package NAME VERSION" formats (thanks, Branislav Zahradník) - fixes to operation on msys (thanks, Paulo Custodio) - add "main_module" option to MakeMaker (thanks, Tatsuhiko Miyagawa) - fix authordeps behavior; don't add an object to @INC (thanks, Shoichi Kaji) 6.028 2022-11-09 10:54:14-05:00 America/New_York - remove bogus work-in-progress signatures-using commit from 6.027; that was a bad release! thanks for the heads-up about it to Gianni "dakkar" Ceccarelli! 6.027 2022-11-06 17:52:20-05:00 America/New_York - if DZIL_COLOR is set to 0, override auto-detection For rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2140480 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On Wed, Jan 04, 2023 at 02:30:07PM +0100, Vitaly Zaitsev via devel wrote: > On 03/01/2023 18:42, Miro Hrončok wrote: > > * AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora > > Linux 38 and we evaluate whether to retain it by Fedora Linux 40. > > This Change must be implemented in a manner which packages are able > > to trivially opt-out of retaining frame pointers during compilation > > so that packages that take larger performance hits can easily > > revert. (mhroncok, 17:20:38) > > Already rejected proposal was submitted because big corporations > weren't happy with the results. This is a VERY BAD precedent for > Fedora. Not sure who the big bad corps are, but adding frame pointers is a very good idea if you've ever tried using perf. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-generators] PR #2: 1.16 bump
jplesnik opened a new pull-request against the project: `perl-generators` that you are following: `` 1.16 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-generators/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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Thu, Dec 22, 2022 at 12:35:54PM -0500, Ben Cotton wrote: > The most common service to cause this issue is PackageKit, but there > are others. NFSv4 unmounts too. I think there's some ordering issue. I use NFS everywhere and this delay is frustrating, so a shorter delay would be welcome. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS UP] Clamping build mtimes to $SOURCE_DATE_EPOCH now enabled in Rawhide
The following change proposal has been shipped in redhat-rpm-config-238-1.fc38. If you need to opt-out, you can %undefine clamp_mtime_to_source_date_epoch or define it to 0. If you encounter problems, report them in Bugzilla and preferably make it block the change tracking https://bugzilla.redhat.com/2149310 Or reply to this thread on the devel list. On 10. 11. 22 21:23, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes 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 == The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. When an RPM package is built, mtimes of packaged files will be clamped to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest `%changelog` entry. As a result, more RPM packages will be reproducible: The actual modification time of files that are e.g. modified in the `%prep` section or built in the `%build` section will not be reflected in the resulting RPM packages. Files in RPM packages will have mtimes that are independent of the time of the actual build. == Owner == * Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: mhroncok at redhat.com, zbyszek at in.waw.pl == Detailed Description == This change exists to make RPM package builds more reproducible. A common problem that prevents [https://reproducible-builds.org/ build reproducibility] is the mtime (modification times) of the packaged files. Suppose we package an RPM package of software called `skynet` in version `1.0`. Upstream released this version at datetime A. A Fedora packager creates the RPM package at datetime B. Unfortunately, the packager needs to patch the sources in the RPM `%prep` section. When the build runs at datetime C, the modification datetime of the patched file is set to C. When the build runs again in an otherwise identical environment at datetime D, the modification datetime of the patched file is set to D. As a result, the build is not bit-by-bit reproducible, because the datetime of the build is saved in the resulting package. Patching is not necessary to make this happen. When a source file is compiled into a binary file, the modification datetime is also set to the datetime of the build. In practice, the modification datetime of many files packaged in RPM packages is dependent on when the package was actually built. To eliminate this problem, we propose to clamp build mtimes to `$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the `$SOURCE_DATE_EPOCH` environment variable based on the latest `%changelog` entry because the `%source_date_epoch_from_changelog` macro is set to `1`. We will also set the `%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when files are packaged to the RPM package, their modification datetimes will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry datetime). Clamping means that all files which would otherwise have a modification datetime higher than `$SOURCE_DATE_EPOCH` will have the modification datetime changed to `$SOURCE_DATE_EPOCH`; files with mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the original mtimes. This functionality is already implemented in RPM. We will enable it by setting `%clamp_mtime_to_source_date_epoch` to `1`. === Non-goal === We do not aim to make all Fedora packages reproducible (at least not as part of this change proposal). We just eliminate one problem that we consider the biggest blocker for reproducible builds. === Python bytecode === When Python bytecode cache (a `.pyc` file) is built, the mtime of the corresponding Python source file (`.py`) is included in it for invalidation purposes. Since the `.pyc` file is created before RPM clamps the mtime of the `.py` file, the mtime stored in the `.pyc` file might be higher than the corresponding mtime of the `.py` file. With the previous example, if `skynet` is written in Python: # `skynet.py` is modified in `%prep` and hence has mtime set to the time of the build # `skynet.pyc` is generated in `%install` and the mtime of `skynet.py` is saved in it # RPM clamps the mtime of `skynet.py` # `skynet.pyc` is considered invalid by Python on runtime, as the stored and actual mtime of `skynet.py` don't match To solve this, we will modify Python to clamp the stored mtime to `$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream Python chooses to invalidate bytecode cache based on hashes instead of mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause performance issues for big files, so Fedora's Python already deviates from upstream behavior when building RPM packages. To avoid accidentally breaking the behavior when `%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and buildroot policy
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Wed, Dec 21, 2022 at 04:49:17PM -0500, Ben Cotton wrote: > The use-case for clients with different endianess is ''very'' niche. > It was common in the 1980s when X was originally developed but at this > point a vanishingly small number of users run clients and X servers on > different machines, I doubt this part is true. Have you measured it? Anyway I use this all the time (though not with different endianness). > * this only affects use-cases where the server runs on a little endian > host and the client on a Big Endian host (or vice versa). I guess this affects something like x86 server running a client on s390x (which is very rare indeed). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[HEADS UP] Clamping build mtimes to $SOURCE_DATE_EPOCH now enabled in Rawhide
The following change proposal has been shipped in redhat-rpm-config-238-1.fc38. If you need to opt-out, you can %undefine clamp_mtime_to_source_date_epoch or define it to 0. If you encounter problems, report them in Bugzilla and preferably make it block the change tracking https://bugzilla.redhat.com/2149310 Or reply to this thread on the devel list. On 10. 11. 22 21:23, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes 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 == The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. When an RPM package is built, mtimes of packaged files will be clamped to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest `%changelog` entry. As a result, more RPM packages will be reproducible: The actual modification time of files that are e.g. modified in the `%prep` section or built in the `%build` section will not be reflected in the resulting RPM packages. Files in RPM packages will have mtimes that are independent of the time of the actual build. == Owner == * Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: mhroncok at redhat.com, zbyszek at in.waw.pl == Detailed Description == This change exists to make RPM package builds more reproducible. A common problem that prevents [https://reproducible-builds.org/ build reproducibility] is the mtime (modification times) of the packaged files. Suppose we package an RPM package of software called `skynet` in version `1.0`. Upstream released this version at datetime A. A Fedora packager creates the RPM package at datetime B. Unfortunately, the packager needs to patch the sources in the RPM `%prep` section. When the build runs at datetime C, the modification datetime of the patched file is set to C. When the build runs again in an otherwise identical environment at datetime D, the modification datetime of the patched file is set to D. As a result, the build is not bit-by-bit reproducible, because the datetime of the build is saved in the resulting package. Patching is not necessary to make this happen. When a source file is compiled into a binary file, the modification datetime is also set to the datetime of the build. In practice, the modification datetime of many files packaged in RPM packages is dependent on when the package was actually built. To eliminate this problem, we propose to clamp build mtimes to `$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the `$SOURCE_DATE_EPOCH` environment variable based on the latest `%changelog` entry because the `%source_date_epoch_from_changelog` macro is set to `1`. We will also set the `%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when files are packaged to the RPM package, their modification datetimes will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry datetime). Clamping means that all files which would otherwise have a modification datetime higher than `$SOURCE_DATE_EPOCH` will have the modification datetime changed to `$SOURCE_DATE_EPOCH`; files with mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the original mtimes. This functionality is already implemented in RPM. We will enable it by setting `%clamp_mtime_to_source_date_epoch` to `1`. === Non-goal === We do not aim to make all Fedora packages reproducible (at least not as part of this change proposal). We just eliminate one problem that we consider the biggest blocker for reproducible builds. === Python bytecode === When Python bytecode cache (a `.pyc` file) is built, the mtime of the corresponding Python source file (`.py`) is included in it for invalidation purposes. Since the `.pyc` file is created before RPM clamps the mtime of the `.py` file, the mtime stored in the `.pyc` file might be higher than the corresponding mtime of the `.py` file. With the previous example, if `skynet` is written in Python: # `skynet.py` is modified in `%prep` and hence has mtime set to the time of the build # `skynet.pyc` is generated in `%install` and the mtime of `skynet.py` is saved in it # RPM clamps the mtime of `skynet.py` # `skynet.pyc` is considered invalid by Python on runtime, as the stored and actual mtime of `skynet.py` don't match To solve this, we will modify Python to clamp the stored mtime to `$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream Python chooses to invalidate bytecode cache based on hashes instead of mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause performance issues for big files, so Fedora's Python already deviates from upstream behavior when building RPM packages. To avoid accidentally breaking the behavior when `%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and buildroot policy
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Fri, Dec 23, 2022 at 08:13:49AM +, Zbigniew Jędrzejewski-Szmek wrote: > Quoting Daniel Berrange from the other part of the thread: > > This is the same situation we already have in Fedora with > > libguestfs, where we're building a disk image inside Koji bundling > > various binaries. FWIW libguestfs does not do this. The disk image is built on the end user machine. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: TeXLive 2022 landing in rawhide today
On Wed, Jan 4 2023 at 11:46:26 PM -0500, Tom Callaway wrote: Despite the size, I don't think TL updates have ever gone through that process before. Not opposed to doing it though, do we need to revert those builds from rawhide? Seems excessive to use the change process for "Update component to new version." GNOME and KDE don't do that because writing a change proposal is a bunch of extra work and there's not a ton of value from it. Cases where we do this (e.g. Boost, python, GCC/toolchain) are more exceptions rather than the rule, where the package maintainers think it's especially useful to have broader coordination and awareness. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On Wed, Jan 4 2023 at 11:10:54 PM -0500, Frank Ch. Eigler wrote: If I understood it correctly, the claim was that enabling this distro-user-penalizing option would make it back in terms of performance optimizations. Of course, but the benefit is to fix performance bugs in applications or maybe the desktop itself. It's not going to result in general improvements that benefit benchmarks. Benchmarks will surely get worse, not better. That it was an investement that would have a positive return. Let's be firm in testing this empirically rather than aspirationally. I really don't know how. Suggestions welcome. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
On Thu, Jan 05, 2023 at 12:56:31AM -0800, Luya Tshimbalanga wrote: > An issue with the testing method from the proposal: secure boot prevents the > resulting unsigned unified kernel to boot. It is signed, but with the test key. You can get the x509 ca cert for that using: certutil -L -d /etc/pki/pesign-rh-test -n "Red Hat Test CA" -a After enrolling the cert the kernel should boot fine. Doing that on a non-test system is a bad idea though. The qemu test images (https://www.kraxel.org/fedora-uki/) come with a edk2 vars file which has secure boot enabled and the test key enrolled. > It will be great to obtain a > scratch-build from koji for users running with enabled secured boot. scratch builds would get a test key signature only too I think. HTH, Gerd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, 5 Jan 2023 at 08:20, David Cantrell wrote: > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > [...] > > > > So I guess this means no remoting into ppc64 or s390x machines from > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > We don't have ppc64 builds anymore and I don't know the last release > we had > > > that was ppc64, but it was a long time ago now. All current POWER > systems are > > > ppc64le. > > > > > > And everything else we have as primary or alternative architectures is > little > > > endian, except s390x. I do view this as a risk for s390x because of > all the > > > architectures we build for, this one is the most difficult to use > graphically. > > > Exporting your display is still the convenient method for this > platform. > > > > > > Given that this change proposal affects default behavior, I don't see a > > > problem with it. s390x users can drop the configuration change in > xorg.conf.d > > > to regain the functionality. If that can be conditionally enabled for > s390x > > > at package build time, that might make things easier (but wouldn't you > need to > > > make the change on both the s390x host and your non-s390x > workstation?). > > > > The X protocol works that the first byte of the connection request is a > > either 'l' or 'B', telling the server that the client is little or Big > > endian. The client has no information on the server's endianess. > > > > This means the configuration needs to be done wherever your X server > > runs, so the (little-endian) thing you're sitting in front of. Which is > > also why compile-time defaults are difficult, at compile time we cannot > > know that eventually you may want to connect from an s390x. > > Reasonable. The runtime configuration change I can make locally to allow > me > to run X programs on an s390x and display them locally is sufficient for > me. > Wasn't there a concern that you can do this if you are running a desktop with X, but if you are using Xwayland it isn't easy (or maybe possible) as the configuration to do that was either hardcoded or not fully documented on how to do that? >From Peter Hutterer earlier: ``` but you don't necessarily have access to how Xwayland is started (mutter certainly is hard-coded). ``` -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > [...] > > > So I guess this means no remoting into ppc64 or s390x machines from > > > x86_64 or ppc64le machines without a configuration tweak? > > > > We don't have ppc64 builds anymore and I don't know the last release we had > > that was ppc64, but it was a long time ago now. All current POWER systems > > are > > ppc64le. > > > > And everything else we have as primary or alternative architectures is > > little > > endian, except s390x. I do view this as a risk for s390x because of all the > > architectures we build for, this one is the most difficult to use > > graphically. > > Exporting your display is still the convenient method for this platform. > > > > Given that this change proposal affects default behavior, I don't see a > > problem with it. s390x users can drop the configuration change in > > xorg.conf.d > > to regain the functionality. If that can be conditionally enabled for s390x > > at package build time, that might make things easier (but wouldn't you need > > to > > make the change on both the s390x host and your non-s390x workstation?). > > The X protocol works that the first byte of the connection request is a > either 'l' or 'B', telling the server that the client is little or Big > endian. The client has no information on the server's endianess. > > This means the configuration needs to be done wherever your X server > runs, so the (little-endian) thing you're sitting in front of. Which is > also why compile-time defaults are difficult, at compile time we cannot > know that eventually you may want to connect from an s390x. Reasonable. The runtime configuration change I can make locally to allow me to run X programs on an s390x and display them locally is sufficient for me. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158383] Upgrade perl-Config-Model-TkUI to 1.376
https://bugzilla.redhat.com/show_bug.cgi?id=2158383 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE Fixed In Version||perl-Config-Model-TkUI-1.37 ||6-1.fc38 Assignee|david.hanneq...@gmail.com |jples...@redhat.com Status|NEW |CLOSED Last Closed||2023-01-05 11:57:54 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158383 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158390] perl-Mixin-ExtraFields-0.140003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158390 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE Fixed In Version||perl-Mixin-ExtraFields-0.14 ||0003-1.fc38 Status|ASSIGNED|CLOSED Last Closed||2023-01-05 11:41:18 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158390 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Mixin-ExtraFields] PR #1: 0.140003 bump; Package tests
jplesnik merged a pull-request against the project: `perl-Mixin-ExtraFields` that you are following. Merged pull-request: `` 0.140003 bump; Package tests `` https://src.fedoraproject.org/rpms/perl-Mixin-ExtraFields/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Mixin-ExtraFields] PR #1: 0.140003 bump; Package tests
jplesnik opened a new pull-request against the project: `perl-Mixin-ExtraFields` that you are following: `` 0.140003 bump; Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Mixin-ExtraFields/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-IO-Zlib] PR #1: 1.12 bump; Package tests
jplesnik merged a pull-request against the project: `perl-IO-Zlib` that you are following. Merged pull-request: `` 1.12 bump; Package tests `` https://src.fedoraproject.org/rpms/perl-IO-Zlib/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158345] perl-Test-Deep-1.202 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158345 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Test-Deep-1.202-1.fc38 Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2023-01-05 10:56:22 --- Comment #2 from Fedora Update System --- FEDORA-2023-f0792a8f5b has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158345 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-IO-Zlib] PR #1: 1.12 bump; Package tests
jplesnik opened a new pull-request against the project: `perl-IO-Zlib` that you are following: `` 1.12 bump; Package tests `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-IO-Zlib/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158345] perl-Test-Deep-1.202 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158345 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-f0792a8f5b has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0792a8f5b -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158345 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158345] perl-Test-Deep-1.202 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158345 Paul Howarth changed: What|Removed |Added Assignee|jples...@redhat.com |p...@city-fan.org Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158345 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158393] New: Upgrade perl-Search-Elasticsearch to 8.00
https://bugzilla.redhat.com/show_bug.cgi?id=2158393 Bug ID: 2158393 Summary: Upgrade perl-Search-Elasticsearch to 8.00 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Search-Elasticsearch Status: NEW Component: perl-Search-Elasticsearch Assignee: emman...@seyman.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 7.717 version. Upstream released 8.00. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158393 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158391] New: Upgrade perl-MooseX-SetOnce to 0.203
https://bugzilla.redhat.com/show_bug.cgi?id=2158391 Bug ID: 2158391 Summary: Upgrade perl-MooseX-SetOnce to 0.203 Product: Fedora Version: rawhide URL: https://metacpan.org/release/MooseX-SetOnce Status: NEW Component: perl-MooseX-SetOnce Assignee: emman...@seyman.fr Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.201000 version. Upstream released 0.203. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158391 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158390] New: perl-Mixin-ExtraFields-0.140003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2158390 Bug ID: 2158390 Summary: perl-Mixin-ExtraFields-0.140003 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mixin-ExtraFields Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 0.140003 Upstream release that is considered latest: 0.140003 Current version/release in rawhide: 0.140002-24.fc37 URL: https://metacpan.org/release/Mixin-ExtraFields Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/319287/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Mixin-ExtraFields -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158390 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Starting Flatpak SIG
Hi all, Hopefully most people are back from vacations now so I think we can go on with organizing the first Flatpak SIG meeting. I have created a whenisgood poll for the next week: https://whenisgood.net/s3rzh5h Please put your name in there and what times would work for you. I am thinking that a weekly meeting would be too often, but maybe bi-weekly? So that we do one next week, and then again two weeks after etc. 10 people have already signed up on the https://fedoraproject.org/wiki/SIGs/Flatpak page so I suspect it's going to be hard to make it work for everybody, but hopefully we can find something that would work for most of the group. I'll collect the results later this week when it looks like most of the people have replied. Thanks and Happy New Year everybody! -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158385] New: Upgrade perl-Data-GUID to 0.051
https://bugzilla.redhat.com/show_bug.cgi?id=2158385 Bug ID: 2158385 Summary: Upgrade perl-Data-GUID to 0.051 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Data-GUID Status: NEW Component: perl-Data-GUID Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.050 version. Upstream released 0.051. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158385 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158384] New: Upgrade perl-Convert-Color to 0.14
https://bugzilla.redhat.com/show_bug.cgi?id=2158384 Bug ID: 2158384 Summary: Upgrade perl-Convert-Color to 0.14 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Convert-Color Status: NEW Component: perl-Convert-Color Assignee: rc040...@freenet.de Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.13 version. Upstream released 0.14. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158384 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158383] New: Upgrade perl-Config-Model-TkUI to 1.376
https://bugzilla.redhat.com/show_bug.cgi?id=2158383 Bug ID: 2158383 Summary: Upgrade perl-Config-Model-TkUI to 1.376 Product: Fedora Version: rawhide URL: https://metacpan.org/release/Config-Model-TkUI Status: NEW Component: perl-Config-Model-TkUI Assignee: david.hanneq...@gmail.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: david.hanneq...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest Fedora delivers 1.375 version. Upstream released 1.376. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158383 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158183] Upgrade perl-Type-Tiny to 2.002000
https://bugzilla.redhat.com/show_bug.cgi?id=2158183 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2023-01-05 09:24:22 --- Comment #1 from Jitka Plesnikova --- perl-Type-Tiny-2.002000-1.fc38 built by corsepiu -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158183 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158129] Add perl-Lexical-Persistence to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2158129 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-4f0fce78cf has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4f0fce78cf -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158129 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
An issue with the testing method from the proposal: secure boot prevents the resulting unsigned unified kernel to boot. It will be great to obtain a scratch-build from koji for users running with enabled secured boot. My laptop currently uses systemd-boot as default following this instruction[1] due to the lack of support from shim. References: [1] https://haavard.name/2022/06/22/full-uefi-secure-boot-on-fedora-using-signed-initrd-and-systemd-boot/ -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help needed triaging build failures without distutils
Added for kig in https://src.fedoraproject.org/rpms/kig/c/d1d0c99facdb10dce32a8bf583750efaa565eefe?branch=rawhide ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158130] Add perl-MooseX-Object-Pluggable to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2158130 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-fcf15307d5 has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-fcf15307d5 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158130 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2158091] Add perl-Graphics-TIFF to EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2158091 --- Comment #2 from Fedora Update System --- FEDORA-EPEL-2023-2eb0e878bc has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-2eb0e878bc -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2158091 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
