[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-10049c7b14 libbsd-0.11.7-2.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0b26ab3924 xrdp-0.9.21-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing eggdrop-1.9.4-1.el7 Details about builds: eggdrop-1.9.4-1.el7 (FEDORA-EPEL-2022-9f1012a19f) World's most popular Open Source IRC bot Update Information: # Eggdrop v1.9.4 ## General changes - Fixed a DNS bug causing Eggdrop to often hang on DCC or telnet connections - BETA: Added `-systemd` option to `autobotchk` script to restart Eggdrop via systemd instead of cron - Reverted matchattr match syntax to previous functionality. Matching against `-` as a flag will once again successfully match against `no` flags, instead of returning an error. - Fixed some inaccurate log messages - Fixed some format specifiers that could cause crashes in certain situations - Fixed logging of `TAGMSG` messages - Fixed unspecified behavior of `freeaddrinfo()` on some BSD systems ## Tcl API changes - Moved the `gotmsg` function back as a raw bind. It was inadvertantly moved to a rawt bind in 1.9.3, causing issuse with scripts attempting to unbind this internal reference ChangeLog: * Thu Dec 15 2022 Robert Scheck 1.9.4-1 - Upgrade to 1.9.4 (#2142049) References: [ 1 ] Bug #2142049 - eggdrop-1.9.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=2142049 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> On Thu, 2022-12-15 at 00:11 +, Michael Catanzaro via devel wrote: > > Well, except that we ship Firefox in the default OS image and to make > that play video, overlaying openh264 is *exactly* what's needed. Ah, drat... well there's not a lot of great options, then. We can (a) change it to use Fedora Flatpak and convince Cisco to host an extension, or (b) give up on the goal of not having any default overlays, or (c) give up on users being able to watch most videos. Please let's not do (c)? ___ 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: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
On Thu, 2022-12-15 at 00:11 +, Michael Catanzaro via devel wrote: > For Fedora Flatpaks, the solution would have to be Flatpak extensions > hosted by Cisco: overlaying OpenH264 on the host system won't > actually accomplish anything useful. Even if you need it for a > command line tool like ffmpeg, you're probably using a toolbx > container for that, so again it's just not nearly so important on the > host system. Well, except that we ship Firefox in the default OS image and to make that play video, overlaying openh264 is *exactly* what's needed. That sucks, though. It needs fixing somehow. Hopefully not by just telling people to use the upstream Flathub Firefox, because I appreciate the work our maintainer does to provide a build with (IMHO) superior choices. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> One solution to reduce the time taken by client side layering and those > issues mentioned > above is to move the package overrides back to the server side by using a > layering > approach similar to the one used to build containers. This is the goal of > this change: > https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It > enables users to > make custom builds of Silverblue/Kinoite with their own selection of packages > and changes > and then to distribute them as an image to their systems, getting the full > benefits of > pure image based updates back if they don't do any local changes anymore. We can't do that on Fedora infrastructure, though, because we cannot distribute OpenH264. It would have to be done by Cisco. Seems like a no-go. But it might be OK to just not run fedora-autofirstboot for Silverblue/Kinoite. Thing is, system multimedia codecs are really a lot less important on Silverblue/Kinoite than they are on traditional desktops. What users really care most about is whether their _applications_ can play videos. That's a solved problem for anything using Flathub. For Fedora Flatpaks, the solution would have to be Flatpak extensions hosted by Cisco: overlaying OpenH264 on the host system won't actually accomplish anything useful. Even if you need it for a command line tool like ffmpeg, you're probably using a toolbx container for that, so again it's just not nearly so important on the host system. ___ 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: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
The main issue with this change for Silverblue/Kinoite is that this introduces client side layering by default for all users. To understand why this is not a good idea, I need to recap a few things: how rpm-ostree client side layering works, the general goal behind rpm-ostree and image based updates and what we're trying to do in https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. First, let's start with rpm-ostree client side layering. When you update a "pristine" Silverblue system, the following happens: 1. rpm-ostree looks into the remote ostree repo for the latest version commit and downloads all the files needed for it into the local repo. 2. Once this is done, it creates a new deployments, which is a new copy of /usr made mostly of hardlinks to the repo. 3. Then you can reboot and you're done. When you enable client side layering, because you want to change something in the image, remove a package, add a new one, etc., the following happens: 1. rpm-ostree has to fetch the needed files into the repo like in the previous case (step 1). 2. But then, instead of creating directly creating a new deployment, it creates a temporary one with the content of the latest commit. 3. From this temporary deployment, rpm-ostree is able to fetch all RPM metadata from the Fedora repos, then resolve the dependencies for the added/replaced/removed packages and download the RPMs as needed. 4. It will then create a temporary writable overlay on top of the temporary deployment, perform the package installations, replacements, removals and optionally rebuild the initrd. 5. Then it will process the files in this overlay to create a new ostree commit. 6. Finally, it will deploy this new commit into a new deployment to be used after a reboot. Given the additional steps required when client side layering is used, updates will take longer to be downloaded, prepared and installed and will require more CPU and memory. Additionally, any operation done on the temporary deployment may fail: missing dependencies, conflicts, wrong package signatures, etc. The idea behind rpm-ostree hybrid model is that you don't have to manage package conflicts, installation, etc. on the client side and instead rely on the server composing a working image for you. With client side layering, this guarantee goes away and the user will have to intervene when it fails. This is the main reason why we recommend to be careful with client side layering: it may fail and you'll have to figure out why, just like you need to figure out dependency resolutions issues on a classic DNF based system. The main goal of Silverblue is to get rid of this issue in the first place by relying only on images by default. Users may choose to override things in the image but they would have to do that on purpose, via the command line, hopefully knowing that they are now responsible when something fails. Note that neither GNOME Software nor Plasma Discover support managing client side layered packages right now. GNOME Sofware pre-downloads packages, essentially making the first step invisible to the user and only then notifies the user to trigger the 2nd and 3rd steps. Plasma Discover is not yet capable of doing that but I'm working on it. So yes, client side layering is fully supported in Silverblue/Kinoite as it enables debugging, testing, workarounds, etc. but we don't want to expose users to it by default as this is not a good user experience. One solution to reduce the time taken by client side layering and those issues mentioned above is to move the package overrides back to the server side by using a layering approach similar to the one used to build containers. This is the goal of this change: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It enables users to make custom builds of Silverblue/Kinoite with their own selection of packages and changes and then to distribute them as an image to their systems, getting the full benefits of pure image based updates back if they don't do any local changes anymore. I hope that explained things in more details. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Meeting for 2022-12-14
[2022-12-14-16:47] Meeting ended Wed Dec 14 21:47:14 2022 UTC. Information about Zodbot's MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions . [2022-12-14-16:47] Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2022-12-14/epel.2022-12-14-20.59.html [2022-12-14-16:47] Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2022-12-14/epel.2022-12-14-20.59.txt [2022-12-14-16:47] Log: https://meetbot.fedoraproject.org/fedora-meeting/2022-12-14/epel.2022-12-14-20.59.log.html Next meeting is 2022-12-21 -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
Fedora CoreOS Meeting Minutes 2022-12-14
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-12-14/fedora_coreos_meeting.2022-12-14-16.31.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-12-14/fedora_coreos_meeting.2022-12-14-16.31.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-12-14/fedora_coreos_meeting.2022-12-14-16.31.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:31:06 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-12-14/fedora_coreos_meeting.2022-12-14-16.31.log.html . Meeting summary --- * roll call (dustymabe, 16:31:10) * meetings for the remainder of 2022 (dustymabe, 16:36:53) * AGREED: the remaining meetings of the year, scheduled for 12/21 and 12/28 are canceled due to the holidays (dustymabe, 16:38:49) * tracker: Fedora 38 changes considerations (dustymabe, 16:40:04) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1357 (dustymabe, 16:40:13) * LINK: https://pagure.io/fedora-autofirstboot/issue/8 (travier, 16:58:06) * LINK: https://github.com/coreos/fedora-coreos-tracker/labels/F37-Changes (dustymabe, 17:16:01) * open floor (dustymabe, 17:18:12) * we will still attempt to put out a triple release on the week of the 26th (dustymabe, 17:18:58) * the console changes finally landed in stable (today) https://github.com/coreos/fedora-coreos-tracker/issues/567 (dustymabe, 17:20:11) * GCP SEV support landed in the triple release today too: https://github.com/coreos/fedora-coreos-tracker/issues/1202 (dustymabe, 17:20:50) * LINK: https://communityblog.fedoraproject.org/fedora-linux-38-development-schedule/ (dustymabe, 17:24:13) Meeting ended at 17:26:04 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * dustymabe (116) * jlebon (51) * travier (39) * zodbot (23) * walters (8) * ravanelli (2) * gursewak (1) * aaradhak (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Mail-IMAPTalk] PR #1: Update license to SPDX format
mspacek merged a pull-request against the project: `perl-Mail-IMAPTalk` that you are following. Merged pull-request: `` Update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Mail-IMAPTalk/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
[EPEL-devel] Re: Updating tox to 4 in EPEL 9
On Wed, 14 Dec 2022, Stephen Smoogen wrote: On Wed, 14 Dec 2022 at 09:45, Miro Hrončok wrote: Hello folks. A new major version of tox was released. The bump form version 3 to version 4 should be flawless to users but breaks all the plugins that have not been updated to the new API yet. I would like to avoid the need to maintain tox 3 in EPEL9 for many years after upstream abandoned it (they have no intention to do maintenance releases for tox 3.x). We are currently upgrading to tox 4 in Fedora Rawhide. When the dust settles I'd like to have the possibility to update it in EPEL too. One way to do it is to package a new tox4 component in EPEL 9 (and make it conflict with tox < 4) and keep the old tox around until it breaks (the breakage might mean it no longer supports a newly added Python version being added to RHEL 9). How does this sound? Add a tox4 which conflicts with tox3 and tox. Then release a tox3 which replaces tox and has a prominent END-OF-LIFE file and possibly in the Info that this is the last release of tox3 and it will be removed from EPEL around RHEL-9.2. Then set tox3's shelf-life to 2023-07-01 in pdc. (move dates to what you want). Then it goes and everyone knows why it went. Should tox3 and tox4 *provide* tox ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Curious how Upstream Release Monitoring works
There is a plan to automate that when you request a new package in Fedora [0], but it's still work in progress. The notification settings are now explained in the-new-hotness documentation [1] with new coming in upcoming release of src.fedoraproject.org. Michal [0] - https://pagure.io/releng/issue/10110 [1] - https://the-new-hotness.readthedocs.io/en/stable/user-guide.html#notifications-settings On 14. 12. 22 16:44, Sérgio Basto wrote: On Wed, 2022-12-14 at 09:36 -0600, Ron Olson wrote: Hey all- I’m curious how Upstream Monitoring works; I got a BZ filed that Swift 5.7.2 is available, which I’m building now, but what surprised me was how fast the new version was detected and brought to my attention. Does it use The New Hotness? I set that up awhile ago but I don’t think it files BZ tickets (and I must not have it set up correctly as it hasn’t notified me about any releases for the past year). To be clear this isn’t a complaint, if anything it’s an awesome feature and I’m just curious what the mechanism is that makes it work. Hi , what package is concrete ? you need mapping in https://release-monitoring.org/ for example https://release-monitoring.org/project/6221/ and in src.fedoraproject.org you need set scratch builds https://src.fedoraproject.org/rpms/smb4k Ron ___ 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: Curious how Upstream Release Monitoring works
On Wed, 2022-12-14 at 09:36 -0600, Ron Olson wrote: > Hey all- > > I’m curious how Upstream Monitoring works; I got a BZ filed that > Swift 5.7.2 is available, which I’m building now, but what surprised > me was how fast the new version was detected and brought to my > attention. Does it use The New Hotness? I set that up awhile ago but > I don’t think it files BZ tickets (and I must not have it set up > correctly as it hasn’t notified me about any releases for the past > year). > > To be clear this isn’t a complaint, if anything it’s an awesome > feature and I’m just curious what the mechanism is that makes it > work. Hi , what package is concrete ? you need mapping in https://release-monitoring.org/ for example https://release-monitoring.org/project/6221/ and in src.fedoraproject.org you need set scratch builds https://src.fedoraproject.org/rpms/smb4k > Ron > ___ > 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 -- Sérgio M. B. ___ 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: Curious how Upstream Release Monitoring works
On Wed, Dec 14, 2022 at 4:38 PM Ron Olson wrote: > > Hey all- > > I’m curious how Upstream Monitoring works; I got a BZ filed that Swift 5.7.2 > is available, which I’m building now, but what surprised me was how fast the > new version was detected and brought to my attention. Does it use The New > Hotness? I set that up awhile ago but I don’t think it files BZ tickets (and > I must not have it set up correctly as it hasn’t notified me about any > releases for the past year). > > To be clear this isn’t a complaint, if anything it’s an awesome feature and > I’m just curious what the mechanism is that makes it work. There's several components involved to make this work: - anitya, which powers release-monitoring.org: this is where you need to set up the project and set the Fedora package name for it, and which crawls projects for new versions regularly - the-new-hotness: the service which files bugs for new versions detected by anitya, if "Monitoring" is enabled for a package on src.fedoraproject.org I wonder why "(and I must not have it set up correctly as it hasn’t notified me about any releases for the past year)." happened, though. Fabio ___ 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
Curious how Upstream Release Monitoring works
Hey all- I’m curious how Upstream Monitoring works; I got a BZ filed that Swift 5.7.2 is available, which I’m building now, but what surprised me was how fast the new version was detected and brought to my attention. Does it use The New Hotness? I set that up awhile ago but I don’t think it files BZ tickets (and I must not have it set up correctly as it hasn’t notified me about any releases for the past year). To be clear this isn’t a complaint, if anything it’s an awesome feature and I’m just curious what the mechanism is that makes it work. Ron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Updating tox to 4 in EPEL 9
On Wed, 14 Dec 2022 at 09:45, Miro Hrončok wrote: > Hello folks. > > A new major version of tox was released. The bump form version 3 to > version 4 > should be flawless to users but breaks all the plugins that have not been > updated to the new API yet. > > I would like to avoid the need to maintain tox 3 in EPEL9 for many years > after > upstream abandoned it (they have no intention to do maintenance releases > for > tox 3.x). > > We are currently upgrading to tox 4 in Fedora Rawhide. When the dust > settles > I'd like to have the possibility to update it in EPEL too. > > One way to do it is to package a new tox4 component in EPEL 9 (and make it > conflict with tox < 4) and keep the old tox around until it breaks (the > breakage might mean it no longer supports a newly added Python version > being > added to RHEL 9). > > How does this sound? Add a tox4 which conflicts with tox3 and tox. Then release a tox3 which replaces tox and has a prominent END-OF-LIFE file and possibly in the Info that this is the last release of tox3 and it will be removed from EPEL around RHEL-9.2. Then set tox3's shelf-life to 2023-07-01 in pdc. (move dates to what you want). Then it goes and everyone knows why it went. > Is that a sensible approach for EPEL? > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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 > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
[rpms/perl-Mail-IMAPTalk] PR #1: Update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Mail-IMAPTalk` that you are following: `` Update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Mail-IMAPTalk/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
[EPEL-devel] Updating tox to 4 in EPEL 9
Hello folks. A new major version of tox was released. The bump form version 3 to version 4 should be flawless to users but breaks all the plugins that have not been updated to the new API yet. I would like to avoid the need to maintain tox 3 in EPEL9 for many years after upstream abandoned it (they have no intention to do maintenance releases for tox 3.x). We are currently upgrading to tox 4 in Fedora Rawhide. When the dust settles I'd like to have the possibility to update it in EPEL too. One way to do it is to package a new tox4 component in EPEL 9 (and make it conflict with tox < 4) and keep the old tox around until it breaks (the breakage might mean it no longer supports a newly added Python version being added to RHEL 9). Is that a sensible approach for EPEL? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Playing with cross-compilers for FPC
Hey all,
I've been maintaining the Free Pascal Compiler [0] in Fedora for some time now.
A couple of times I played around with the idea of building and packaging FPC
cross-compilers. Lately I gave it another go and arrived and some quite
workable results. If you're interested, you can check them out in COPR. [1]
During the process of packaging the cross-compilers, there were a couple of
issues I came across and wanted to ask for some opinion/guidance.
1. Separate package or not
The most basic issue would be whether the cross-compilers should be built from
a separate SRPM, or be a part of the main package. For both possibilities,
I see some pros and cons.
Cross-compilers in one package:
+ Everything's in one place
+ The cross-compilers are built from the same source
- Main .spec file becomes way more complicated
- Package for native compiler can get blocked by cross-compilers not building
Separate package for cross-compilers:
+ The spec for the native compiler can remain relatively simple
+ Worst case scenario, we can ship an updated version of the native compiler
and fix cross-compiler errors later
- A lot of duplication between native and cross .spec file
- Need to track sources/patches from main package in the cross package,
comes with a risk of things de-syncing
Personally I'd favour the "separate package" approach.
2. Naming - base name
Yes, the eternal problem. So far, I went with naming the cross-compiler package
"fpcross", which reflects what upstream does - e.g. if the native compiler
for aarch64 is "ppca64", the cross-compiler is "ppcrossa64".
I wonder if using "fpc-cross" would be more readable. Yet another solution
would be to hide the native/cross distinction and use "%package -n" to build
cross-compilers with just the "fpc-" prefix.
3. Naming - per arch
So far, for simplicity, I went with naming the cross-compilers
"fpcross-${ARCH}", e.g. "fpcross-aarch64", with packages for MS Windows
being named "fpcross-win32" and "fpcross-win64". Looking at some other
packages (like binutils), I wonder if it would be better to use the arch+os
format, like "fpcross-i386-linux" and "fpcross-i386-win32".
4. Configuration
FPC uses a configuration file, located at /etc/fpc.cfg (it can be overridden
by a user creating a file at ~/.fpc.cfg, but that's beside the point).
Inside said config file, there's this problematic bit:
#IFDEF CPU64
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/rtl
#ELSE
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
#ENDIF
This tells the compiler that, when compiling for 64-bit targets, it should
look for unit files in "/usr/lib64/fpc/...", and when compiling for 32-bit
targets, to look in "/usr/lib/fpc/...". The problem here is that this is
based on the *target* architecture, not the *host* architecture, so
cross-compiling from x86_64 for i386 will have the compiler look in /usr/lib/
instead of /usr/lib64/. Which brings the following dilemma:
a) Install stuff required to cross-compile for 32-bit targets in /usr/lib/,
instead of the more appropriate /usr/lib64/.
b) Instead of using the default config file, ship a custom one that makes
the compiler always look in /usr/lib64/ on 64-bit arches
and /usr/lib/ on 32-bit arches.
I think that from a packaging perspective, b) would be cleaner,
though it adds yet one more thing that needs maintaining.
Let me know what you think.
Cheers,
A.FI.
[0] https://src.fedoraproject.org/rpms/fpc
[1] https://copr.fedorainfracloud.org/coprs/suve/fpcross/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: libssh2 epel vs rhel-8-for-x86_64-appstream-rpms
On Tue, 13 Dec 2022 at 20:18, Maxwell G via epel-devel < epel-devel@lists.fedoraproject.org> wrote: > On Tue Dec 13, 2022 at 16:47 +0100, Leon Fauster via epel-devel wrote: > > Hi Leon, > > > I noticed that on a RHEL8 workstation the deprecated and removed package > > from EL8.0 - libssh2, does not get substituted by the package from epel: > > > > libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64 > > vs > > libssh2-1.9.0-5.el8.x86_64 > > > > only possible with > > > > yum update libssh2 --disablerepo=rhel-8-for-x86_64-appst* > > > > is this intentional? > > > > yum distrosync > > > > tries to install the obsolete version 1.8.0 again. > > > > How to solve this conflict? Its seems not to be a "module" problem > > otherwise it would not install the epel version at all, right? > > Have you tried adding `module_hotfixes=true` [1] to the EPEL repo > configuration file (/etc/yum.repos.d/epel.repo IIRC)? > > > [1]: > https://dnf.readthedocs.io/en/latest/modularity.html#hotfix-repositories It isn't going to help. The libssh2-1.8.0 is a dead package and no longer meant to be shipped in any module. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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
Fedora rawhide compose report: 20221214.n.0 changes
OLD: Fedora-Rawhide-20221213.n.0 NEW: Fedora-Rawhide-20221214.n.0 = SUMMARY = Added images:1 Dropped images: 5 Added packages: 4 Dropped packages:1 Upgraded packages: 190 Downgraded packages: 0 Size of added packages: 5.31 GiB Size of dropped packages:1.99 MiB Size of upgraded packages: 3.20 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 11.60 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20221214.n.0.iso = DROPPED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20221213.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20221213.n.0.s390x.tar.xz Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20221213.n.0.s390x.tar.xz Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20221213.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20221213.n.0.iso = ADDED PACKAGES = Package: java-latest-openjdk-portable-1:19.0.1.0.10-2.rolling.fc38 Summary: OpenJDK 19 Runtime Environment portable edition RPMs:java-latest-openjdk-portable java-latest-openjdk-portable-devel java-latest-openjdk-portable-devel-fastdebug java-latest-openjdk-portable-devel-slowdebug java-latest-openjdk-portable-fastdebug java-latest-openjdk-portable-slowdebug java-latest-openjdk-portable-static-libs java-latest-openjdk-portable-static-libs-fastdebug java-latest-openjdk-portable-static-libs-slowdebug Size:5.06 GiB Package: nodejs16-1:16.18.1-5.fc38 Summary: JavaScript runtime RPMs:nodejs16 nodejs16-devel nodejs16-docs nodejs16-full-i18n nodejs16-libs nodejs16-npm v8-9.4-devel Size:123.94 MiB Package: nodejs18-1:18.12.1-5.fc38 Summary: JavaScript runtime RPMs:nodejs nodejs-devel nodejs-docs nodejs-full-i18n nodejs-libs nodejs-npm v8-10.2-devel Size:127.03 MiB Package: rust-pep440-0.2.0-1.fc38 Summary: Parse and compare Python PEP440 style version numbers RPMs:rust-pep440+default-devel rust-pep440-devel Size:49.29 KiB = DROPPED PACKAGES = Package: spectral-0-18.20201224gitfba0df0.fc37 Summary: Glossy cross-platform Matrix client RPMs:spectral Size:1.99 MiB = UPGRADED PACKAGES = Package: annobin-10.95-1.fc38 Old package: annobin-10.94-1.fc38 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-libannocheck annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Size: 4.85 MiB Size change: -14.86 KiB Changelog: * Mon Dec 12 2022 Nick Clifton - 10.95-1 - Annocheck: Avoid using debug filename when parsing notes in a debuginfo file. (#2152280) Package: apptainer-1.1.4-1.fc38 Old package: apptainer-1.1.3-2.fc38 Summary: Application and environment virtualization RPMs: apptainer apptainer-suid Size: 106.46 MiB Size change: 13.66 KiB Changelog: * Tue Dec 13 2022 Dave Dykstra - 1.1.4 - Update to upstream 1.1.4. Package: ara-1.6.1-1.fc38 Old package: ara-1.5.7-5.fc37 Summary: Records Ansible playbooks and makes them easier to understand and troubleshoot RPMs: ara-doc python3-ara python3-ara+mysql python3-ara+postgresql python3-ara+server python3-ara-tests Added RPMs: python3-ara+mysql python3-ara+postgresql python3-ara+server Dropped RPMs: ara python3-ara-server Size: 15.60 MiB Size change: 7.33 MiB Changelog: * Tue Dec 06 2022 Maxwell G - 1.6.0-1 - Update to 1.6.0. * Tue Dec 13 2022 Maxwell G - 1.6.1-1 - Update to 1.6.1. Package: bcel-6.5.0-3.fc38 Old package: bcel-6.5.0-2.fc37 Summary: Byte Code Engineering Library RPMs: bcel bcel-javadoc Size: 1.43 MiB Size change: -31.54 KiB Changelog: * Thu Dec 01 2022 Mikolaj Izdebski - 6.5.0-3 - Fix arbitrary bytecode produced via out-of-bounds writing - Resolves: CVE-2022-42920 Package: breeze-icon-theme-5.101.0-1.fc38 Old package: breeze-icon-theme-5.100.0-1.fc38 Summary: Breeze icon theme RPMs: breeze-icon-theme breeze-icon-theme-rcc Size: 11.48 MiB Size change: 62.96 KiB Changelog: * Mon Dec 12 2022 Marc Deop - 5.101.0-1 - 5.101.0 - use new macros to simplify code Package: byacc-2.0.20221106-1.fc38 Old package: byacc-2.0.20220128-2.fc37 Summary: Berkeley Yacc, a parser generator RPMs: byacc Size: 467.64 KiB Size change: 2.37 KiB Changelog: * Tue Nov 29 2022 Arjun Shankar - 2.0.20221106-1 - Rebase to byacc-2.0-20221106 (#2141488) Package: cacti-spine-1.2.22-2.fc38 Old package: cacti-spine-1.2.22-1.fc38 Summary: Threaded poller for Cacti written in C RPMs: cacti-spine Size: 340.73 KiB Size change: -15 B Changelog: * Tue
[rpms/perl-Mail-JMAPTalk] PR #1: Package tests and update license to SPDX format
mspacek merged a pull-request against the project: `perl-Mail-JMAPTalk` that you are following. Merged pull-request: `` Package tests and update license to SPDX format `` https://src.fedoraproject.org/rpms/perl-Mail-JMAPTalk/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Upgrade ImageMagick to version 7 (Self-Contained Change proposal)
Good to see this proposal and I am glad that you have worked out the way
together.
Vít
Dne 12. 12. 22 v 17:43 Sérgio Basto napsal(a):
On Mon, 2022-12-12 at 10:57 -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/ImageMagick7
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 ==
Upgrade {{package|ImageMagick}} to the latest 7.x version.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]], [[User:Sergiomb| Sérgio Basto]],
[[User:Carlwgeorge| Carl George]]
* Email: ngomp...@gmail.com, ser...@serjux.com, c...@redhat.com
== Detailed Description ==
{{package|ImageMagick}} in Fedora is currently on the 6.x version
series. The latest version series is 7.x, and
[https://legacy.imagemagick.org/ upstream now recommends upgrading to
it]. Some of this work has been verified ahead of time in
[https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ a
COPR project], which will be the starting point for the transition.
We will attempt to avoid introducing an ImageMagick6
compatibility package, but if it is needed, it will be introduced.
== Feedback ==
This was
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproj
ect.org/thread/OO2IBDMPNSKAHCJF5QY27CNAJYAFPZBY/
discussed on the development mailing list prior to this Change] with
most commentators agreeing that upgrading the default package
("ImageMagick") and creating a compatibility package if needed of the
legacy version ("ImageMagick6") is the right approach for Fedora.
The Change Owners privately discussed and came to the conclusion we
should try this and proceed forward.
== Benefit to Fedora ==
This brings us in line with upstream recommendations on how to ship
ImageMagick, and gives users and developers access to the latest
features and fixes being made available in the ImageMagick software.
== Scope ==
* Proposal owners:
** Update {{package|ImageMagick}} to version 7:
https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10
** Rebuild reverse dependencies to link to v7 libraries
** Any packages that cannot build or be adapted to build for v7 will
need to switch to {{package|GraphicsMagick}} or an ImageMagick6
compatibility package will be introduced for them
** As much as possible will be done in a side-tag to merge into
Rawhide
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/11185 #11185]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The main compatibility impact will be that third party packages will
need to adapt to ImageMagick v7 or use alternatives instead. Within
Fedora itself, these choices will be handled already.
== How To Test ==
Install and use any of the packages
== User Experience ==
This is largely an invisible change, so as long as applications using
ImageMagick still work.
== Dependencies ==
Reverse dependencies of the ImageMagick libraries.
== Contingency Plan ==
* Contingency mechanism: In the event not everything can be migrated
to ImageMagick 7, then the ImageMagick6 compatibility package will be
introduced for them and they will be switched to that.
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The ImageMagick package is now based on the latest version 7 series.
This brings new enhancements, including support for more image
formats
and features like HDR.
Hi,
I talked to Neal yesterday and the result is this proposal .
We may provide a compat-ImageMagick if it is need, but the proposal is
betting that we won't need it.
F36 and F37 are out of scope for now, after "getting IM7 in F38 will
let us see how things go, and we can follow up from there"
Also later, EPEL Steering Committee will have to decide if want add
IM7 on EPEL 9 and 8 and how , or following this proposal or doing a new
package ImageMagick7
Best regards,
--
Sérgio M. B.
___
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
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
[Test-Announce] Fedora 38 Rawhide 20221214.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 38 Rawhide 20221214.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: lorax - 20221210.n.0: lorax-38.3-1.fc38.src, 20221214.n.0: lorax-38.4-2.fc38.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/38 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221214.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2153194] New: perl-libintl-perl-1.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2153194 Bug ID: 2153194 Summary: perl-libintl-perl-1.33 is available Product: Fedora Version: rawhide Status: NEW Component: perl-libintl-perl 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: 1.33 Upstream release that is considered latest: 1.33 Current version/release in rawhide: 1.32-7.fc37 URL: http://search.cpan.org/dist/libintl-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/5950/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-libintl-perl -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2153194 ___ 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: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On 14/12/2022 00:53, Michael Catanzaro via devel wrote: Thank you _very much_ Neal, Fabio, and Zbigniew for your efforts to revisit that decision. This proposal was rejected and you don't like it. So please please stop attacking other people. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Mail-JMAPTalk] PR #1: Package tests and update license to SPDX format
mspacek opened a new pull-request against the project: `perl-Mail-JMAPTalk` that you are following: `` Package tests and update license to SPDX format `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Mail-JMAPTalk/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
