Hello there,
I've just submitted an update[0] to EPEL 9 using the incompatible upgrade process. This includes three packages:
* python-botocore
* python-s3transfer
* python-boto3
I've disabled the auto-push-to-stable in Bodhi.
[0] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-5b0a00e926
--
Major Hayden
This is the first year[1] we are having elections for the EPEL Steering
Committee members.
We are still in the nomination phase and have a week to go.
If you want to be nominated, or want to nominate someone with their
consent, please add them to the Nomination wiki page by May 8, 2024.
https://fedoraproject.org/wiki/EPEL/Nominations
There are four seats being voted for and currently six people running.
Thank You
Troy
[1] - First election for a very long time
I have just submitted for testing
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4b1b8b8b25,
which updates llhttp from 8.1.1 to 9.1.3 in EPEL9. This is an
ABI-incompatible update, and the SONAME version changes. There are also
some minor API changes.
The only package in EPEL9 that uses llhttp is python-aiohttp, and the
update also compatibly updates it from 3.8.5 to its latest release, 3.9.1.
Together, these updates fix a number of security issues, including
CVE-2023-47627, CVE-2023-49081, and CVE-2023-49082.
A COPR impact check in
https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/ indicates
there should be no impact on any dependent packages in EPEL9.
If you have software not packaged in EPEL9 that depends directly on
llhttp, you will need to rebuild it due to the ABI changes. It is
possible that source code changes may be required if (like
python-aiohttp) you use almost the entire API of llhttp, or if you have
very thorough tests that reveal small changes in llhttp’s behavior.
Straightforward uses of llhttp are likely to recompile without modification.
If you have software not packaged in EPEL9 that depends directly on
python-aiohttp, you should not need to do anything, but you might choose
to review the changelogs for releases 3.8.6, 3.9.0, and 3.9.1 here for
full details on the changes included in this update:
https://github.com/aio-libs/aiohttp/blob/v3.9.1/CHANGES.rst#391-2023-11-26
I have no plans to attempt a build of llhttp or any update of
python-aiohttp in EPEL8.
This is an incompatible update under the EPEL Incompatible Upgrades
Policy,
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/.
It was approved by the EPEL Steering Committee:
https://pagure.io/epel/issue/262.
After approval in the last EPEL meeting [1], I have submitted an incompatible upgrade of singularity-ce to testing for EPEL 7, 8 & 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-cbd86d2020https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f299fbc570https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-05e20edbbf
These updates upgrade singularity-ce from v3.11.5 to v4.1.1.
The following incompatibilities should be noted by users:
1) Some functionality previously provided by the `singularity remote` command is split into new `singularity registry` and `singularity keyserver` commands.
2) The `singularity remote add` command now sets a newly added remote as the default (unless suppressed). Previously the user had to set the default remote manually.
3) The deprecated and unmaintained `—vm` flag to start singularity inside a Virtual Machine has been removed.
4) Bind mounts are now performed in the order in which they are specified. Previously, image based bind mounts were performed before others.
5) Current working directory on the host is now created in the container, restoring a behaviour from Singularity <3.6.0 unless suppressed.
6) If the current directory paths on the container and host contains symlinks to different locations, the current working directory is not mounted.
Changes 1,2,3 are expected to have minimal impact, and 4,5,6 are likely to be considered bug fixes by many users.
No changes are required to existing configuration files for this update.
A complete description of changes and additions between v3.11 and v4.1.1 is available in the upstream documentation at https://sylabs.io/docs/
In the absence of any issues, the updates will be pushed to stable after a one week testing period has passed, with a follow-up notification here.
Cheers,
David Trudgian
[1] https://pagure.io/epel/issue/265#comment-894790
At last weeks EPEL Steering Committee meeting it was decided to move from
Libera IRC #fedora-meeting to Fedora Matrix #meeting.[1]
This week (November 15, 2023) will be our first meeting on the new Matrix
channel.
This is the link:
https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org
Documentation changes are still being worked on.
Thank You
EPEL Steering Committee
[1] - This channel was originally called #fedora-meeting, but the 'fedora'
was considered redundant and dropped.
> The link is incorrect and should be https://fedoraproject.limequery.com/epelsurvey2023
Yes, my mistake. The correct link is
https://fedoraproject.limequery.com/epelsurvey2023 :)
> None of them is available, it seems.
We had some problems with Fedora's LimeSurvey account that limited the
amount of responses we could receive per day. This problem has been
addressed, so you should be able to take the survey without problems
now.
Just to clarify on this, none of the already made entries were lost in
this process, so we do not believe it will be necessary to extend the
duration of the survey for now.
On Sat, Sep 2, 2023 at 6:26 AM Michael J Gruber <mjg(a)fedoraproject.org> wrote:
>
> Am Fr., 1. Sept. 2023 um 22:09 Uhr schrieb Stephen Smoogen
> <ssmoogen(a)redhat.com>:
> >
> >
> >
> > On Fri, 1 Sept 2023 at 16:03, Diego Herrera <dherrera(a)redhat.com> wrote:
> >>
> >> Hello, everyone
> >>
> >> The Fedora EPEL SIG is asking for feedback to improve EPEL via this survey!
> >>
> >> * https://fedoraproject.limequery.com/2023
> >>
> >
> > The link is incorrect and should be https://fedoraproject.limequery.com/epelsurvey2023
> >
> None of them is available, it seems.
>
> Cheers
> Michael
> _______________________________________________
> epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)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.fedoraprojec…
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue