Heads-up: rapidyaml 0.6.0 and c4core 0.2.0 coming to Rawhide

[Ben Beasley]

In one week (2024-05-06), or slightly later, I plan to update the 
rapidyaml package to 0.6.0[1] and the c4core package to 0.2.0[2] in 
F41/Rawhide. This includes an SONAME version bump in both cases, with 
specific breaking changes documented in the upstream release 
notes[3][4]. An impact check in COPR did not reveal any problems[5].


I will use a side tag for the update, and I will rebuild dependent 
packages c4fs and c4log as primary maintainer. Unless I’m asked not to, 
I will also rebuild jsonnet using provenpackager privilege. No other 
packages should be affected.


[1] https://src.fedoraproject.org/rpms/rapidyaml/pull-request/2

[2] https://src.fedoraproject.org/rpms/c4core/pull-request/9

[3] https://github.com/biojppm/rapidyaml/releases/tag/v0.6.0

[4] https://github.com/biojppm/c4core/releases/tag/v0.2.0

[5] https://copr.fedorainfracloud.org/coprs/music/rapidyaml/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

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Ben Beasley]

Josef,

I finished rebuilding everything in the side tag f41-build-side-88169. 
Please create the Bodhi update.


The packages cinelerra-gg and olive are RPMFusion packages, so there is 
nothing to do in Fedora; any coordination you want to do with RPMFusion 
is up to you.


For the curious, further details follow below.

– Ben Beasley (FAS music)



I double-checked the packages that were in your original list but not in 
the output of "fedrq wrsrc -s openexr":


    - The CTL package BuildRequires the compat package openexr2 
instead, so it did not need to be rebuilt.


    - The synfig package also BuildRequires the compat package, and one 
can see that it links the compat libraries (e.g. libIlmImf-2_5.so.26), 
but it does depend *indirectly* on the current openexr via its 
dependencies. I think it did not need to be rebuilt, but an attempt was 
made to rebuild it in the side tag, which failed because the 
dependencies were not rebuilt yet – so I rebuilt it again, successfuly.


    - The cinelerra-gg and olive packages belong to RPMFusion, so there 
is nothing to do in Fedora.


    - The synfigstudio package really did need to be rebuilt! The 
source RPM does not depend on openexr, but the binary packages do.


To look for other cases like synfigstudio, I tried this:

    fedrq wr openexr-libs | xargs repoquery --repo=rawhide --qf 
'%{source_name}'


Other than synfigstudio, all of the resulting packages were in the 
original list.


On 4/25/24 11:20 AM, Ben Beasley wrote:


The side tag is nearly complete. I have finished rebuilding all of the 
packages in “my” list for openexr except Blender (which I’ll tackle soon).


I discovered that an ABI-incompatible update was committed to the 
Rawhide branch for OpenColorIO, but never built, about two months ago. 
Since I needed to rebuild OpenColorIO in the side tag, I raised the 
issue[1] with the OpenColorIO maintainer and—after a quick, successful 
trial-run in COPR—we ultimately decided to include the OpenColorIO 
update in side tag rather than trying to revert it before rebuilding.


Therefore, OpenImageIO, krita, and luxcorerender received a second 
rebuild commit for OpenColorIO 2.3.2 and a second build in the side 
tag. The calligra and usd packages are also rebuilding for OpenColorIO 
2.3.2 in the side tag. Once everything else is done, I will build Blender.


Finally, I will double-check the packages that were in Josef’s list 
but not mine (CTL, cinelerra-gg, olive, synfig, and synfigstudio; 
libjxl is just a binary package of jpegxl), to make sure I haven’t 
missed any additional packages that really do need to be rebuilt.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239262#c15

On 4/24/24 8:13 AM, Ben Beasley wrote:


I rebuilt openvdb. I am finding that the dependency chains in this 
set of packages are even longer than I expected. Considering that, 
and how “heavy” some of these packages are – and in the interest of 
not keeping this side tag open for too long – I am going to go ahead 
and start using provenpackager privilege to carefully work through 
the packages that can be rebuilt with a simple release bump. 
(Hopefully that means all of them!)



On 4/23/24 7:21 PM, Ben Beasley wrote:


I get a slightly larger list with fedrq:

$ fedrq wrsrc -s openexr -F name
CImg
Field3D
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph
YafaRay
blender
darktable
enblend
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
jpegxl
kdelibs3
kf5-kimageformats
kf6-kimageformats
kio-extras
kio-extras-kf5
krita
luxcorerender
ogre
opencv
openvdb
pfstools
povray
prusa-slicer
vigra
vips

I BCC’d all of the foo-maintain...@fedoraproject.org aliases in case 
anyone missed the original email.


I am happy to work as provenpackager to help with some of these 
rebuilds, but I want to allow a *little* time for anyone who wants 
to rebuild their own package.


That said, I’m going to go ahead and rebuild some of the packages 
that are in or adjacent to the Blender stack, because I co-maintain 
a few of them and have recently had to touch a few more of them due 
to other ABI changes – also, there are some long dependency chains 
involved.


On 4/22/24 12:33 PM, Josef Řídký wrote:
Well good news, the F40 rebuild is not needed. It looks like there 
was an issue with proper bug report reference.


Sorry for the disturbance about that in F40. But the Rawhide 
rebuild is still in place so please use f41-build-side-88169 for 
rebuild of dependent packages.


Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 6:11 PM Josef Řídký  wrote:

Hi Ben,

thanks for the notice. I'll fill the FESCO ticket right away
and wait for their decision. So let's call F40 only (not
Rawhide) side tags builds on hold till the decision is made.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


O

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Ben Beasley]

The side tag is nearly complete. I have finished rebuilding all of the 
packages in “my” list for openexr except Blender (which I’ll tackle soon).


I discovered that an ABI-incompatible update was committed to the 
Rawhide branch for OpenColorIO, but never built, about two months ago. 
Since I needed to rebuild OpenColorIO in the side tag, I raised the 
issue[1] with the OpenColorIO maintainer and—after a quick, successful 
trial-run in COPR—we ultimately decided to include the OpenColorIO 
update in side tag rather than trying to revert it before rebuilding.


Therefore, OpenImageIO, krita, and luxcorerender received a second 
rebuild commit for OpenColorIO 2.3.2 and a second build in the side tag. 
The calligra and usd packages are also rebuilding for OpenColorIO 2.3.2 
in the side tag. Once everything else is done, I will build Blender.


Finally, I will double-check the packages that were in Josef’s list but 
not mine (CTL, cinelerra-gg, olive, synfig, and synfigstudio; libjxl is 
just a binary package of jpegxl), to make sure I haven’t missed any 
additional packages that really do need to be rebuilt.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2239262#c15

On 4/24/24 8:13 AM, Ben Beasley wrote:


I rebuilt openvdb. I am finding that the dependency chains in this set 
of packages are even longer than I expected. Considering that, and how 
“heavy” some of these packages are – and in the interest of not 
keeping this side tag open for too long – I am going to go ahead and 
start using provenpackager privilege to carefully work through the 
packages that can be rebuilt with a simple release bump. (Hopefully 
that means all of them!)



On 4/23/24 7:21 PM, Ben Beasley wrote:


I get a slightly larger list with fedrq:

$ fedrq wrsrc -s openexr -F name
CImg
Field3D
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph
YafaRay
blender
darktable
enblend
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
jpegxl
kdelibs3
kf5-kimageformats
kf6-kimageformats
kio-extras
kio-extras-kf5
krita
luxcorerender
ogre
opencv
openvdb
pfstools
povray
prusa-slicer
vigra
vips

I BCC’d all of the foo-maintain...@fedoraproject.org aliases in case 
anyone missed the original email.


I am happy to work as provenpackager to help with some of these 
rebuilds, but I want to allow a *little* time for anyone who wants to 
rebuild their own package.


That said, I’m going to go ahead and rebuild some of the packages 
that are in or adjacent to the Blender stack, because I co-maintain a 
few of them and have recently had to touch a few more of them due to 
other ABI changes – also, there are some long dependency chains involved.


On 4/22/24 12:33 PM, Josef Řídký wrote:
Well good news, the F40 rebuild is not needed. It looks like there 
was an issue with proper bug report reference.


Sorry for the disturbance about that in F40. But the Rawhide rebuild 
is still in place so please use f41-build-side-88169 for rebuild of 
dependent packages.


Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 6:11 PM Josef Řídký  wrote:

Hi Ben,

thanks for the notice. I'll fill the FESCO ticket right away and
wait for their decision. So let's call F40 only (not Rawhide)
side tags builds on hold till the decision is made.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 5:04 PM Ben Beasley
 wrote:

Is there a specific reason that an ABI-breaking update in
required in the stable F40 release? And would you consider
asking FESCo for approval as required by the Updates Policy?


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

Note that if this update happens in F40 now, it will have
very messy interactions with other updates in other side
tags, e.g.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9
for blender. Even if this update is truly required in F40, I
would advocate for delaying it by at least one week.

Thanks,

Ben Beasley (FAS music)

On 4/22/24 8:14 AM, Josef Řídký wrote:

Hi folks,

this is in advance notice about the upcoming rebase of the
openexr package in Fedora Rawhide and f40.

List of dependent package should be following (please,
correct me if I haven't found all):
CTL
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph-OpenEXR
blender
cinelerra-gg
darktable
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
kf5-kimageformats
kio-extras
krita
libjxl
olive
opencv
pfstools
povray
synfig
synfigstudio

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Ben Beasley]

I rebuilt openvdb. I am finding that the dependency chains in this set 
of packages are even longer than I expected. Considering that, and how 
“heavy” some of these packages are – and in the interest of not keeping 
this side tag open for too long – I am going to go ahead and start using 
provenpackager privilege to carefully work through the packages that can 
be rebuilt with a simple release bump. (Hopefully that means all of them!)



On 4/23/24 7:21 PM, Ben Beasley wrote:


I get a slightly larger list with fedrq:

$ fedrq wrsrc -s openexr -F name
CImg
Field3D
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph
YafaRay
blender
darktable
enblend
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
jpegxl
kdelibs3
kf5-kimageformats
kf6-kimageformats
kio-extras
kio-extras-kf5
krita
luxcorerender
ogre
opencv
openvdb
pfstools
povray
prusa-slicer
vigra
vips

I BCC’d all of the foo-maintain...@fedoraproject.org aliases in case 
anyone missed the original email.


I am happy to work as provenpackager to help with some of these 
rebuilds, but I want to allow a *little* time for anyone who wants to 
rebuild their own package.


That said, I’m going to go ahead and rebuild some of the packages that 
are in or adjacent to the Blender stack, because I co-maintain a few 
of them and have recently had to touch a few more of them due to other 
ABI changes – also, there are some long dependency chains involved.


On 4/22/24 12:33 PM, Josef Řídký wrote:
Well good news, the F40 rebuild is not needed. It looks like there 
was an issue with proper bug report reference.


Sorry for the disturbance about that in F40. But the Rawhide rebuild 
is still in place so please use f41-build-side-88169 for rebuild of 
dependent packages.


Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 6:11 PM Josef Řídký  wrote:

Hi Ben,

thanks for the notice. I'll fill the FESCO ticket right away and
wait for their decision. So let's call F40 only (not Rawhide)
side tags builds on hold till the decision is made.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 5:04 PM Ben Beasley
 wrote:

Is there a specific reason that an ABI-breaking update in
required in the stable F40 release? And would you consider
asking FESCo for approval as required by the Updates Policy?


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

Note that if this update happens in F40 now, it will have
very messy interactions with other updates in other side
tags, e.g.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9
for blender. Even if this update is truly required in F40, I
would advocate for delaying it by at least one week.

Thanks,

Ben Beasley (FAS music)

On 4/22/24 8:14 AM, Josef Řídký wrote:

Hi folks,

this is in advance notice about the upcoming rebase of the
openexr package in Fedora Rawhide and f40.

List of dependent package should be following (please,
correct me if I haven't found all):
CTL
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph-OpenEXR
blender
cinelerra-gg
darktable
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
kf5-kimageformats
kio-extras
krita
libjxl
olive
opencv
pfstools
povray
synfig
synfigstudio
vigra
vips

I would like to ask responsible maintainers (or kind proven
packager) to rebuild their packages for Rawhide and f40 with
following side-tags:

F40 -> f40-build-side-88171
Rawhide -> f41-build-side-88169

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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:
   

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Ben Beasley]

I get a slightly larger list with fedrq:

$ fedrq wrsrc -s openexr -F name
CImg
Field3D
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph
YafaRay
blender
darktable
enblend
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
jpegxl
kdelibs3
kf5-kimageformats
kf6-kimageformats
kio-extras
kio-extras-kf5
krita
luxcorerender
ogre
opencv
openvdb
pfstools
povray
prusa-slicer
vigra
vips

I BCC’d all of the foo-maintain...@fedoraproject.org aliases in case 
anyone missed the original email.


I am happy to work as provenpackager to help with some of these 
rebuilds, but I want to allow a *little* time for anyone who wants to 
rebuild their own package.


That said, I’m going to go ahead and rebuild some of the packages that 
are in or adjacent to the Blender stack, because I co-maintain a few of 
them and have recently had to touch a few more of them due to other ABI 
changes – also, there are some long dependency chains involved.


On 4/22/24 12:33 PM, Josef Řídký wrote:
Well good news, the F40 rebuild is not needed. It looks like there was 
an issue with proper bug report reference.


Sorry for the disturbance about that in F40. But the Rawhide rebuild 
is still in place so please use f41-build-side-88169 for rebuild of 
dependent packages.


Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 6:11 PM Josef Řídký  wrote:

Hi Ben,

thanks for the notice. I'll fill the FESCO ticket right away and
wait for their decision. So let's call F40 only (not Rawhide) side
tags builds on hold till the decision is made.

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.


On Mon, Apr 22, 2024 at 5:04 PM Ben Beasley
 wrote:

Is there a specific reason that an ABI-breaking update in
required in the stable F40 release? And would you consider
asking FESCo for approval as required by the Updates Policy?


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

Note that if this update happens in F40 now, it will have very
messy interactions with other updates in other side tags, e.g.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9
for blender. Even if this update is truly required in F40, I
would advocate for delaying it by at least one week.

Thanks,

Ben Beasley (FAS music)

On 4/22/24 8:14 AM, Josef Řídký wrote:

Hi folks,

this is in advance notice about the upcoming rebase of the
openexr package in Fedora Rawhide and f40.

List of dependent package should be following (please,
correct me if I haven't found all):
CTL
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph-OpenEXR
blender
cinelerra-gg
darktable
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
kf5-kimageformats
kio-extras
krita
libjxl
olive
opencv
pfstools
povray
synfig
synfigstudio
vigra
vips

I would like to ask responsible maintainers (or kind proven
packager) to rebuild their packages for Rawhide and f40 with
following side-tags:

F40 -> f40-build-side-88171
Rawhide -> f41-build-side-88169

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email tode

Re: [HEADS-UP] openexr so name bump heading Rawhide and f40

[Ben Beasley]

You can use:

https://koji.fedoraproject.org/koji/builds?order=-tag_name=88169=1=1

So far it looks like we have openexr, gegl04, and jpegxl.

On 4/23/24 7:13 AM, Tomas Smetana wrote:

Dne Mon, 22 Apr 2024 19:02:07 +
Gwyn Ciesla via devel  napsal(a):


I tried to so synfig and gstreamer1-plugins-bad-free, and they need some of
the others rebuilt first:

https://kojipkgs.fedoraproject.org//work/tasks/2955/116742955/root.log
https://kojipkgs.fedoraproject.org//work/tasks/3027/116743027/root.log


Similar for pfstools: I have not tried to rebuild the packages yet, but they
depend on ImageMagick, so unless that one is finished, the build would fail.

Is there a way to find out what's been already rebuilt?

Thanks and regards,

--
___
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] openexr so name bump heading Rawhide and f40

[Ben Beasley]

Is there a specific reason that an ABI-breaking update in required in 
the stable F40 release? And would you consider asking FESCo for approval 
as required by the Updates Policy?


https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

Note that if this update happens in F40 now, it will have very messy 
interactions with other updates in other side tags, e.g. 
https://bodhi.fedoraproject.org/updates/FEDORA-2024-45862e3ed9 for 
blender. Even if this update is truly required in F40, I would advocate 
for delaying it by at least one week.


Thanks,

Ben Beasley (FAS music)

On 4/22/24 8:14 AM, Josef Řídký wrote:

Hi folks,

this is in advance notice about the upcoming rebase of the openexr 
package in Fedora Rawhide and f40.


List of dependent package should be following (please, correct me if I 
haven't found all):

CTL
ImageMagick
OpenColorIO
OpenEXR_Viewers
OpenImageIO
OpenSceneGraph-OpenEXR
blender
cinelerra-gg
darktable
freeimage
gdal
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
kf5-kimageformats
kio-extras
krita
libjxl
olive
opencv
pfstools
povray
synfig
synfigstudio
vigra
vips

I would like to ask responsible maintainers (or kind proven packager) 
to rebuild their packages for Rawhide and f40 with following side-tags:


F40 -> f40-build-side-88171
Rawhide -> f41-build-side-88169

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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

[EPEL-devel] Incompatible update of llhttp from 9.1.3 to 9.2.1 in EPEL9

[Ben Beasley]

I have just submitted for testing 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ce142428af, 
which updates llhttp in EPEL9 from 9.1.3 to 9.2.1 and fixes 
CVE-2024-27982[1], an HTTP request smuggling vulnerability. Version 
9.2.0 also included a number of bug fixes[2]. This is an 
ABI-incompatible update, and the SONAME version changes.


Because the EPEL Steering Committee has previously approved a permanent 
exception for incompatible upgrades of llhttp, I have bypassed the usual 
proposal and discussion of this update on the epel-devel mailing list. 
However, I am following the other parts of the incompatible updates 
process: this announcement, at least one week in testing with auto-push 
disabled, and a follow-up announcement on this list once I have pushed 
the update to stable.


The only package in EPEL9 that uses llhttp is python-aiohttp; the update 
also backports support for llhttp 9.2.1 to the current aiohttp release, 
3.9.3. I expect that the aiohttp project will soon release a compatible 
patch release 3.9.4 that directly supports llhttp 9.2.1.


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 very likely to recompile without 
modification.


I have no plans to attempt a build of llhttp or any update of 
python-aiohttp in EPEL8.


[1] 
https://nodejs.org/en/blog/vulnerability/april-2024-security-releases/#http-request-smuggling-via-content-length-obfuscation---cve-2024-27982---medium


[2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.2.0
--
___
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: Rust Stack Spring Cleaning - 2024 Edition

[Ben Beasley]

The rust-circular-buffer crate was packaged as a dependency for bpftop, 
https://github.com/Netflix/bpftop.


I won’t necessarily be packaging bpftop myself, but I know several 
parties are interested in doing so, and I expect it will happen soon one 
way or the other.


A few existing dependencies still need to be updated first:

 Problem 1: nothing provides requested (crate(anyhow/default) >= 1.0.81 
with crate(anyhow/default) < 2.0.0~)
 Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 
0.23.0 with crate(libbpf-rs/default) < 0.24.0~)
 Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 
1.4.0 with crate(libbpf-sys/default) < 2.0.0~)
 Problem 4: nothing provides requested (crate(ratatui) >= 0.26.1 with 
crate(ratatui) < 0.27.0~)
 Problem 5: nothing provides requested (crate(ratatui/crossterm) >= 
0.26.1 with crate(ratatui/crossterm) < 0.27.0~)
 Problem 6: nothing provides requested (crate(tui-input/default) >= 
0.8.0 with crate(tui-input/default) < 0.9.0~)


Some of these might just reflect over-aggressive bounds from dependabot 
that could be loosened downstream, but other minimum versions are likely 
real.


On 4/11/24 9:26 AM, Fabio Valentini wrote:

Hello Rust packagers,

I'm continuously working on reducing unnecessary accumulation of cruft
in the Rust package stack in Fedora, and I have been keeping track of
unused library packages for almost three years now.

Some of these packages have been unused leaves for over two years!

I will again start being more proactive with orphaning / retiring
affected packages where I am the primary maintainer, starting
incrementally from the packages which have been unused for the longest
time - unless I know of a reason to keep a specific package, for
example:

- something that depends on the package is still going through package review
- the package was updated to a "breaking" release and a compat package
was created, and now the "main" package is not depended on while the
compat package is in use

If you know of a reason why a leaf package where I am the primary
maintainer should not be retired, please let me know, and I will
exclude it from the list.

For packages where I am *not* the primary maintainer, I need help:

- Is this package still required for something that I don't know
about, or can it be dropped?
- Was it added as a dependency for something else, but packaging this
"something else" was abandoned?
- Was it needed at the time, but is the library no longer needed now?

Keeping unused packages around only makes maintenance of the Rust
stack more difficult due to the more "dense" dependency graph that
needs to be considered when pushing "breaking" changes. Over the past
year or so, the number of Rust packages in Fedora has grown by almost
50% from about 2200 to over 3000, which is making this issue worse.

Full report included below (view in monospace font for correct formatting).

Thank you for your help,
Fabio

+--++---+--+
| Package  | Leaf since | Leaf days | Maintainer   |
+--++---+--+
| rust-curve25519-dalek| 2021-11-18 |   875 | dcavalca |
| rust-gstreamer-editing-services  | 2021-11-18 |   875 | atim |
| rust-gstreamer-player| 2021-11-18 |   875 | atim |
| rust-rand_jitter | 2021-11-18 |   875 | jistone  |
| rust-rand_os | 2021-11-18 |   875 | jistone  |
| rust-tower-test  | 2021-11-18 |   875 | decathorpe   |
| rust-tower-util  | 2021-11-18 |   875 | decathorpe   |
| rust-partial-io  | 2022-02-06 |   795 | decathorpe   |
| rust-minimad | 2022-02-18 |   783 | dcavalca |
| rust-libhandy| 2022-02-20 |   781 | decathorpe   |
| rust-tiger   | 2022-02-20 |   781 | decathorpe   |
| rust-rand_hc | 2022-02-21 |   780 | jistone  |
| rust-benfred-read-process-memory | 2022-02-27 |   774 | dcavalca |
| rust-custom_error| 2022-02-27 |   774 | dcavalca |
| rust-madvr_parse | 2022-02-27 |   774 | dcavalca |
| rust-os-release  | 2022-02-27 |   774 | dcavalca |
| rust-strict  | 2022-02-27 |   774 | dcavalca |
| rust-subprocess  | 2022-02-27 |   774 | dcavalca |
| rust-libxml  | 2022-04-07 |   735 | decathorpe   |
| rust-snake_case  | 2022-04-25 |   717 | decathorpe   |
| rust-openat-ext  | 2022-04-28 |   714 | walters  |
| rust-log-mdc | 2022-05-05 |   707 | decathorpe   |
| 

Re: Idea: pynose as drop-in replacement for nose

[Ben Beasley]

For a proposed nose successor, pynose doesn’t seem to have gained much 
community traction so far: it has seven stars on GitHub[1] (compared to 
770 for nose2, which itself was never that widely adopted and has fewer 
than ten dependent packages in Fedora); and the imperfect but fairly 
useful reverse dependency index at Wheelodex[2] shows only three 
packages that explicitly depend on it.


As far as I can tell, pynose exists because SeleniumBase[3] found it 
easier to fork nose than to port away from it. I’m *definitely* not 
saying we should only package things with a bunch of GitHub stars, but I 
do have some concerns about whether or not pynose is going to remain a 
generally-useful project in the medium-to-long term.


[1] https://github.com/mdmintz/pynose/stargazers

[2] https://www.wheelodex.org/projects/pynose/rdepends/

[3] https://github.com/seleniumbase/SeleniumBase

On 4/11/24 9:17 AM, Miro Hrončok wrote:

On 11. 04. 24 15:05, Sandro wrote:

On 11-04-2024 13:54, Miro Hrončok wrote:

On 11. 04. 24 11:55, Sandro wrote:
While I ponder those thoughts some more, moving forward in either 
direction, the next step would be writing a change proposal?


I'd start by:

Packaging pynose without hacks (only making it Conflict with nose, 
no compatibility Provides, Obsoletes or dist-infos).


That way, pro-active packagers can switch already.


That makes sense. Review is up [1]. If enough packagers adapt, I may 
not need to go through the changes process.


And the change proposal can then describe what will be *added* to 
pynose, rather than describing the approach from scratch.


Since predicting the future is difficult, I'll start on writing up a 
proposal while the package is being introduced, anyway.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514


I see "# Package doesn't provide any tests" in the %check section.
That certainly feels a bit dodgy. This successor of a test framework 
decided to ditch all of the tests it used to have? That is certainly a 
red flag.



--
___
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

Heads-up: python-typer 0.12.1 coming to Rawhide with a significant reorganization

[Ben Beasley]

In 0.12.1, Typer was significantly reorganized.

- `typer-slim` is the library (for `import typer`)
- `typer-slim[standard]` adds optional dependencies (currently `rich`
  and `shellingham`, basically equivalent to the old `typer[all]`)
- `typer-cli` is the `typer` command-line tool
- `typer` is now basically a metapackage that brings in *all of the
  above*, and it no longer has an `all` extra

Seehttps://typer.tiangolo.com/release-notes/#0121  and
https://github.com/tiangolo/typer/discussions/785  for further
discussion and details, and
https://src.fedoraproject.org/rpms/python-typer/pull-request/3
for the proposed update.

Unfortunately, this impacts projects that depended on `typer[all]`.
Pip will warn about this and proceed,

```
WARNING: typer 0.12.1 does not provide the extra 'all'
```

but the RPM builds would fail hard when asked to resolve a (now)
nonexistent extra.

As such, I’m treating this as an incompatible update, even though
the actual API appears to remain backwards-compatible. There are
three dependent packages that *need* to be changed as part of the
update. For each, I’ve prepared a dist-git PR and (where I thought
it made sense) an upstream PR.

- ocrmypdf
  dist-git:https://src.fedoraproject.org/rpms/ocrmypdf
  upstream:https://github.com/ocrmypdf/OCRmyPDF
  dist-git PR:https://src.fedoraproject.org/rpms/ocrmypdf/pull-request/4
  upstream PR:https://github.com/ocrmypdf/OCRmyPDF/pull/1287
- pgadmin4
  dist-git:https://src.fedoraproject.org/rpms/pgadmin4
  upstream:https://github.com/pgadmin-org/pgadmin4
  dist-git PR::https://src.fedoraproject.org/rpms/pgadmin4/pull-request/7
- python-openneuro
  dist-git:https://src.fedoraproject.org/rpms/python-openneuro
  upstream:https://github.com/hoechenberger/openneuro-py
  downstream 
PR:https://src.fedoraproject.org/rpms/python-openneuro/pull-request/1
  upstream PR:https://github.com/hoechenberger/openneuro-py/pull/155

The following requires `typer` but not `typer[all]`, so it isn’t
required to do anything; however, a change to `typer-slim` would
keep the package from starting to pull in the command-line tool.
Since nothing breaks, I’m offering that suggestion only via this
email and will not be opening PR’s.

- osbuild
  dist-git:https://src.fedoraproject.org/rpms/ocrmypdf
  upstream:https://github.com/osbuild/osbuild

If you are a maintainer of one of the above packages, you should
have received a copy of this email by CC.

I plan to update python-typer in about one week, no earlier than
2024-04-13. At that point, if there has been no feedback, I will
use python-packagers-sig membership and/or provenpackager
privilege to merge the PR’s for pgadmin4 and python-openneuro,
and for ocrmypdf if and only if the maintainer reviews my PR to
fix the pre-existing FTBFS first.
--
___
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

Orphaning vim-editorconfig

[Ben Beasley]

I’m orphaning vim-editorconfig.

While it’s probably still useful in EPEL8 and EPEL9, it is (according to 
https://github.com/editorconfig/editorconfig-vim/issues/234) no longer 
needed by users of recent versions of vim and neovim since those editors 
now include its functionality. It’s therefore not clear that it needs to 
have a future in Fedora.


The package is in good condition and requires minimal maintenance; if 
anyone knows of a reason why it might still have users in Fedora, feel 
free to pick it up. Otherwise, it can fade away quietly.

--
___
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: Three steps we could take to make supply chain attacks a bit harder

[Ben Beasley]

On 3/31/24 2:12 PM, Kevin Kofler via devel wrote:

But the fact is:

What WOULD have stopped this attack: (one or more of:)
* Deleting ALL unit tests in %prep (and then of course not trying to run
them later).
While it’s technically correct that deleting tests would have disrupted 
this specific attack, a policy of deleting and and never running 
upstream test code would have prevented me from finding and helping 
upstreams fix dozens and dozens of bugs due to accidentally faulty 
assumptions that turned out to be violated on different architectures, 
in different system environments, or with various allegedly-compatible 
dependency versions. There are even GCC bugs (miscompilations, not only 
failures to compile) that were discovered and fixed only because 
packages I maintain were running upstream unit and integration tests. 
Frankly, “testing the packages we ship, as built in our distribution, is 
actually bad” seems like a pretty strange and extreme conclusion to draw 
from all of this.

--
___
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

Orphaning python-jose because it is unmaintained upstream

[Ben Beasley]

For some time, I have been maintaining python-jose[1] since it is a 
minor test dependency for python-fastapi. While the Fedora package for 
python-jose is in good condition, the project has been unmaintained 
upstream for some time[2][3].


I have just chosen to skip the FastAPI tests that require python-jose 
and orphan the python-jose package with the expectation that it will be 
retired for F41. As an unmaintained security library, I do *not* 
recommend picking it up and keeping it in Fedora – although I did not 
feel strongly enough to choose immediate retirement over orphaning.


One package, python-social-auth-core[4], still depends on python-jose. 
However, this dependency is removed upstream in social-auth-core release 
4.5.0[5], so I recommend that the maintainers of that package update 
it[6] rather than keeping python-jose around.


[1] https://src.fedoraproject.org/rpms/python-jose

[2] https://github.com/mpdavis/python-jose/issues/332

[3] https://github.com/mpdavis/python-jose/issues/340

[4] https://src.fedoraproject.org/rpms/python-social-auth-core

[5] 
https://github.com/python-social-auth/social-core/blob/4.5.3/CHANGELOG.md#450---2023-10-31


[6] https://bugzilla.redhat.com/show_bug.cgi?id=2178870
--
___
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: Updating python-keyring to 25.0.0 in F41/Rawhide

[Ben Beasley]

In one week (2024-04-04), or slightly later, I plan to update the 
python-keyring package to 25.0.0 in F41/Rawhide[1]. Upstream reports[2]:


v25.0.0
===

Deprecations and Removals
-

- Removed check for config in XDG_DATA_HOME on Linux systems. (#99)
- In platform config support, remove support for Windows XP, now 10 years 
sunset.

All dependent packages rebuilt successfully in a COPR impact check[3], 
except yubikey-manager, which can be fixed by removing an upper-bound on 
the version of typer[4]. If there is no response to that PR by 
2024-04-04, I will use provenpackager privileges to merge and build it 
along with the python-keyring update.


[1] https://src.fedoraproject.org/rpms/python-keyring/pull-request/26

[2] https://github.com/jaraco/keyring/blob/v25.0.0/NEWS.rst#v2500

[3] https://copr.fedorainfracloud.org/coprs/music/python-keyring/packages/

[4] https://src.fedoraproject.org/rpms/yubikey-manager/pull-request/5
--
___
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: updating flatbuffers to 24.3.25 in F41/Rawhide

[Ben Beasley]

I know, we just did flatbuffers 24.3.7, but there is a bugfix update, 
24.3.25, and the ABI and SONAME version always break, so here we go again!


In one week (2024-04-04), or slightly later, I plan to update the 
flatbuffers package to 24.3.25 in F41/Rawhide[1]. As usual, this 
includes an SONAME version bump. Upstream follows calendar versioning 
and does not attempt to keep the ABI stable across releases.


Unless a maintainer asks me to do otherwise, I will use provenpackager 
privileges to rebuild the dependent packages in a side tag:


    - hyperhdr

    - onnxruntime

    - qdigidoc

All of these are expected to rebuild successfully in a COPR impact 
check[2], currently in progress.


[1] https://src.fedoraproject.org/rpms/flatbuffers/pull-request/9

[2] https://copr.fedorainfracloud.org/coprs/music/flatbuffers/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

Heads-up: updating flatbuffers to 24.3.7 in F41/Rawhide

[Ben Beasley]

In one week (2024-03-25), or slightly later, I plan to update the 
flatbuffers package to 24.3.7 in F41/Rawhide[1]. As usual, this includes 
an SONAME version bump. Upstream follows calendar versioning and does 
not attempt to keep the ABI stable across releases.


Unless a maintainer asks me to do otherwise, I will use provenpackager 
privileges to rebuild the dependent packages in a side tag:


    - hyperhdr

    - onnxruntime

    - qdigidoc

All of these rebuilt successfully in a COPR impact check[2].

I will *not* build this version for F40/Branched (even though there is 
time before the Final Freeze), because python-torch in F40 depends on an 
exact version of flatbuffers. This could be fixed by running flatc as 
part of the python-torch build, but an unrelated FTBFS would have to be 
fixed first. In F41, python-torch bundles the same version of 
flatbuffers that upstream used to pre-generate the flatbuffers bindings, 
and it does not depend on the system flatbuffers package.


[1] https://src.fedoraproject.org/rpms/flatbuffers/pull-request/8

[2] https://copr.fedorainfracloud.org/coprs/music/flatbuffers/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

Re: SPDX Statistics - Please Please Me edition

[Ben Beasley]

Going purely by upstream support status, yes, GConf2 should be retired; 
it’s been obsolete for a decade.


Going by dependent packages, it’s not so simple. Some of these 
dependencies are no doubt spurious, optional, or otherwise “removable;” 
others are real hard dependencies from outdated-but-still-useful 
application packages.


$ repoquery --repo=rawhide -q --whatrequires GConf2 --recursive
GConf2-devel-0:3.2.6-41.fc40.i686
GConf2-devel-0:3.2.6-41.fc40.x86_64
GtkAda-devel-0:2.24.2-48.fc40.i686
GtkAda-devel-0:2.24.2-48.fc40.x86_64
GtkAda-gnome-0:2.24.2-48.fc40.i686
GtkAda-gnome-0:2.24.2-48.fc40.x86_64
alexandria-0:0.7.9-7.fc40.noarch
apcupsd-gui-0:3.14.14-31.fc40.x86_64
cbrpager-0:0.9.22-31.fc40.x86_64
ccgo-0:0.3.6.5-22.fc40.x86_64
cdcollect-0:0.6.0-42.fc40.x86_64
fantasdic-0:1.0-0.25.beta7.fc40.noarch
gconf-editor-0:3.0.1-29.fc40.x86_64
gconfmm26-0:2.28.3-72.fc40.i686
gconfmm26-0:2.28.3-72.fc40.x86_64
gconfmm26-devel-0:2.28.3-72.fc40.i686
gconfmm26-devel-0:2.28.3-72.fc40.x86_64
giver-0:0.1.8-38.fc40.x86_64
gnome-desktop-sharp-devel-0:2.26.0-49.fc40.i686
gnome-desktop-sharp-devel-0:2.26.0-49.fc40.x86_64
gnome-do-0:0.95.3-27.fc40.x86_64
gnome-do-devel-0:0.95.3-27.fc40.i686
gnome-do-devel-0:0.95.3-27.fc40.x86_64
gnome-phone-manager-0:0.69-45.fc40.x86_64
gnome-sharp-0:2.24.2-34.fc40.x86_64
gnome-sharp-devel-0:2.24.2-34.fc40.i686
gnome-sharp-devel-0:2.24.2-34.fc40.x86_64
gnome-translate-0:0.99-43.fc39.x86_64
gnome-vfs2-0:2.24.4-45.fc40.i686
gnome-vfs2-0:2.24.4-45.fc40.x86_64
gnome-vfs2-common-0:2.24.4-45.fc40.noarch
gnome-vfs2-devel-0:2.24.4-45.fc40.i686
gnome-vfs2-devel-0:2.24.4-45.fc40.x86_64
gnome-vfs2-monikers-0:2.15.3-37.fc40.x86_64
gnome-vfs2-smb-0:2.24.4-45.fc40.x86_64
gphotoframe-0:2.0.2-24.hg2084299dffb6.fc40.noarch
grhino-0:0.16.1-19.fc40.x86_64
gtk-sharp-beans-0:2.14.0-35.fc40.x86_64
gtk-sharp-beans-devel-0:2.14.0-35.fc40.i686
gtk-sharp-beans-devel-0:2.14.0-35.fc40.x86_64
icedtea-web-0:1.8.8-4.fc40.x86_64
icedtea-web-devel-0:1.8.8-4.fc40.noarch
icedtea-web-javadoc-0:1.8.8-4.fc40.noarch
ignuit-0:2.24.3-16.fc40.x86_64
libbonoboui-0:2.24.5-25.fc39.i686
libbonoboui-0:2.24.5-25.fc39.x86_64
libbonoboui-devel-0:2.24.5-25.fc39.i686
libbonoboui-devel-0:2.24.5-25.fc39.x86_64
libgnome-0:2.32.1-30.fc40.i686
libgnome-0:2.32.1-30.fc40.x86_64
libgnome-devel-0:2.32.1-30.fc40.i686
libgnome-devel-0:2.32.1-30.fc40.x86_64
libgnomeui-0:2.24.5-32.fc40.i686
libgnomeui-0:2.24.5-32.fc40.x86_64
libgnomeui-devel-0:2.24.5-32.fc40.i686
libgnomeui-devel-0:2.24.5-32.fc40.x86_64
librawstudio-0:2.1-0.35.20210527.gitc140a5e.s20231112gitc753388.fc40.i686
librawstudio-0:2.1-0.35.20210527.gitc140a5e.s20231112gitc753388.fc40.x86_64
librawstudio-devel-0:2.1-0.35.20210527.gitc140a5e.s20231112gitc753388.fc40.i686
librawstudio-devel-0:2.1-0.35.20210527.gitc140a5e.s20231112gitc753388.fc40.x86_64
linsmith-0:0.99.33-7.fc40.x86_64
mail-notification-0:5.4-111.git.9ae8768.fc40.x86_64
mono-addins-devel-0:1.3.3-6.fc40.i686
mono-addins-devel-0:1.3.3-6.fc40.x86_64
mono-tools-0:4.2-30.fc40.x86_64
mono-tools-devel-0:4.2-30.fc40.i686
mono-tools-devel-0:4.2-30.fc40.x86_64
mono-tools-gendarme-0:4.2-30.fc40.x86_64
mono-tools-monodoc-0:4.2-30.fc40.x86_64
monodevelop-0:5.10.0-27.fc40.x86_64
monodevelop-debugger-gdb-0:5.0.1-16.fc40.x86_64
monodevelop-devel-0:5.10.0-27.fc40.i686
monodevelop-devel-0:5.10.0-27.fc40.x86_64
mtn-browse-0:1.20-18.fc40.noarch
pdfmod-0:0.9.1-32.fc40.x86_64
perl-Gnome2-0:1.048-12.fc40.x86_64
perl-Gnome2-GConf-0:1.047-12.fc40.x86_64
perl-Gnome2-VFS-0:1.084-12.fc40.x86_64
pinta-0:1.7.1-7.fc40.x86_64
rawstudio-0:2.1-0.35.20210527.gitc140a5e.s20231112gitc753388.fc40.x86_64
ruby-bonoboui2-0:0.90.4-19.fc40.x86_64
ruby-bonoboui2-devel-0:0.90.4-19.fc40.i686
ruby-bonoboui2-devel-0:0.90.4-19.fc40.x86_64
ruby-gconf2-0:0.90.4-19.fc40.x86_64
ruby-gconf2-devel-0:0.90.4-19.fc40.i686
ruby-gconf2-devel-0:0.90.4-19.fc40.x86_64
ruby-gnome2-0:0.90.4-19.fc40.x86_64
ruby-gnome2-devel-0:0.90.4-19.fc40.i686
ruby-gnome2-devel-0:0.90.4-19.fc40.x86_64
ruby-gnomevfs-0:0.90.4-19.fc40.x86_64
ruby-gnomevfs-devel-0:0.90.4-19.fc40.i686
ruby-gnomevfs-devel-0:0.90.4-19.fc40.x86_64
ruby-libglade2-0:0.90.4-19.fc40.x86_64
ruby-libglade2-devel-0:0.90.4-19.fc40.i686
ruby-libglade2-devel-0:0.90.4-19.fc40.x86_64
sirius-0:0.8.0-46.fc40.x86_64
teg-0:0.12.0-7.fc40.x86_64
tomboy-0:1.15.9-20.fc40.x86_64
tomboy-devel-0:1.15.9-20.fc40.i686
tomboy-devel-0:1.15.9-20.fc40.x86_64
tomoe-gtk-devel-0:0.6.0-44.fc40.i686
tomoe-gtk-devel-0:0.6.0-44.fc40.x86_64
ucview-0:0.33-27.fc40.i686
ucview-0:0.33-27.fc40.x86_64
ucview-devel-0:0.33-27.fc40.i686
ucview-devel-0:0.33-27.fc40.x86_64
ufraw-0:0.23-0.17.20210425.fc39.x86_64
ufraw-common-0:0.23-0.17.20210425.fc39.x86_64
ufraw-gimp-0:0.23-0.17.20210425.fc39.x86_64
verbiste-gnome-0:0.1.48-3.fc40.x86_64
wallpapoz-0:0.6.2-16.fc40.noarch
xoo-0:0.8-23.fc40.x86_64

Looking only at direct dependencies:

$ fedrq wrsrc -s GConf2
GtkAda-2.24.2-48.fc40.src
alexandria-0.7.9-7.fc40.src
apcupsd-3.14.14-31.fc40.src
cdrdao-1.2.5-9.fc40.src

License change: python-email-validator 2.1.1 is Unlicense (was CC0-1.0)

[Ben Beasley]

Beginning with version 2.1.1, the license of python-email-validator has 
changed from CC0-1.0 to Unlicense.


Note that CC0-1.0 is no longer allowed for code in Fedora, but 
python-email-validator was covered by the exception for pre-existing 
code in Fedora.


Version 2.1.1 will be built as an update for F39 and later; F38 and 
EPEL8/EPEL9 will remain on older 1.x releases.

--
___
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: Updating python-fastapi to 0.110.0 in F41/Rawhide and F40/Branched

[Ben Beasley]

In one week, 2024-03-03, or slightly later, I will update python-fastapi 
to 0.110.0[1] (or later if another release appears) in F41/Rawhide and 
F40/Branched. Upstream reports that this release contains a small 
breaking change[2]. I used local mock builds to verify compatibility 
with dependent packages python-openapi-core, 
python-opentelemetry-contrib, and python-sentry-sdk.


[1] https://src.fedoraproject.org/rpms/python-fastapi/pull-request/25

[2] https://github.com/tiangolo/fastapi/releases/tag/0.110.0

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads-up: Updating llhttp to 9.2.0 in F40/Branched and F41/Rawhide

[Ben Beasley]

In one week, 2024-02-15, or slightly later, I plan to update llhttp to 
9.2.0[1] in (what will then be) F40/Branched and F41/Rawhide.


Based on the release notes[2], this release contains some bug fixes, but 
no security fixes or exceptionally serious bug fixes. Therefore, 
although this package has a permanent exception under the Updates 
Policy[3], I currently have no plans to update llhttp to 9.2.0 in F39, 
F38, or EPEL9. This could change in the future if I learn that this 
release did in fact fix a serious bug or security flaw.


All dependent packages (tang, python-aiohttp, and uxplay) rebuilt 
successfully in COPR[4].


I will use side tags to rebuild the dependent packages, using either 
co-maintainer or provenpackager privileges. (If you have special 
instructions or want to do the build yourself for some reason, please 
contact me by 2024-02-15.)


[1] https://src.fedoraproject.org/rpms/llhttp/pull-request/21

[2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.2.0

[3] https://pagure.io/fesco/issue/3115

[4] https://copr.fedorainfracloud.org/coprs/music/llhttp/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

Re: google-re2 pacakge update and facebook vs google python bindings ?

[Ben Beasley]

I’m not aware of anything in grpc that would require re2 to be held 
back. If there is, I’d hope it could be resolved.


An impact check in COPR would be wise for any update.

I’ve CC’d the appropriate aliases to make sure *all* of the maintainers 
of the re2 and python-fb-re2 packages are aware of this conversation.


On 2/6/24 13:36, Paul Wouters wrote:


Hi,

At $dayjob we are running into issues with re2 and python bindings.

Fedora has a fairly old version of re2 with so.9 while upstream is at
so.11. Is there a reason for this? If it is just time, I'd like to
help bumping the package in rawhide.

Originally, facebook creating python bindings for this, which are
packaged in python-fb-re2, but this package is no longer updated
as google're2 now has native python bindings (I think the fb one
was pulled in and maintained and so the fb one is abandoned upsteam)

I'd like to see:

- google-re2 updated to version 2024-02-04
- python3-google-re2 python bindings shipped, providing the fb-re2 
package.

- python2-fb-re2 retired

Currently, the google-re2 python bindings do not compile against
the older google-re2 we ship (but that might be a fairly trivial
fix, that would need to be done for the branches anyway)


Added package maintainers to the CC: for additional input.


Again, happy to help if time/effort is the only thing holding
this back. If there are other reasons for this, I'd very much
like to know more. I know there were soname issues in the past.

Packages that would be affected by the soname bump:

loaty
dnsdist
frr
grpc
libarrow
mtxclient
onnxruntime
perl-re-engine-RE2
python3-fb-re2
python3-grpcio
python3-onnxruntime
qt5-qtwebengine
syslog-ng
syslog-ng-opentelemetry

Thanks,

Paul
--
___
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: Heads-up: abseil-cpp 20240116.0 coming to F40/Rawhide

[Ben Beasley]

The rebuild is complete, and the side tag is merged via [1]. As of this 
writing, it is waiting on test gating.


Including parlaylib was an error on my part, since it is header-only and 
none of its binary packages depend on abseil-cpp. Nevertheless, 
parlaylib started to FTBFS in Rawhide after the initial announcement and 
before the rebuild, so I filed a bug[2].


The syslog-ng package already failed in the mass rebuild[3] because it 
FTBFS on i686[4], which is related to the Change PortingToModernC[5]. 
Since I knew rebuilding this package would fail (and a scratch build 
confirmed this[6] and showed that it actually fails on *all* 
architectures now), I did not bother to push a rebuild commit. Note that 
dropping i686 support from syslog-ng would require dropping it in 
perl-Unix-Syslog and therefore in a number of other packages. This is 
still probably feasible. I expect that syslog-ng-opentelemetry will now 
FTI until the package can be rebuilt in Rawhide and (post-branching) 
F40[7]. I am in contact with the syslog-ng maintainers via Bugzilla and 
have offered my assistance if they run into any trouble.


All other packages were successfully rebuilt.

If you think I missed something, let me know and I’ll help clean it up!

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce6bbab91a

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2262661

[3] https://bugzilla.redhat.com/show_bug.cgi?id=2261744

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2258853

[5] 
https://fedoraproject.org/wiki/Changes/PortingToModernC#Use_of_incompatible_pointer_types_without_a_cast


[6] https://koji.fedoraproject.org/koji/taskinfo?taskID=112924642

[7] https://bugzilla.redhat.com/show_bug.cgi?id=2261744#c8

On 1/28/24 13:43, Ben Beasley wrote:
In one week, 2024-02-04, or slightly later, I plan to update 
abseil-cpp from 20230802.1 to 20230116.0 (Abseil LTS branch, Jan 
2024)[1] in side tags for F40/Rawhide. If I miss getting the update 
into Rawhide before F40 branching, I plan to do the update in both 
F41/Rawhide and F40/Branched.


Like all new calendar versions of abseil-cpp, this breaks ABI 
compatibility and bumps the SONAME version. There are also some small 
intentional breaking API changes[2].


Testing in COPR[3] indicates all directly-dependent packages are 
compatible, except mozc, which can be fixed by a PR[4].


Besides abseil-cpp, I plan to rebuild all dependent packages using 
maintainer/co-maintainer or provenpackager privileges. I also plan to 
merge the mozc PR if it is still open. These packages are:


    - bear
    - bloaty
    - credentials-fetcher
    - CuraEngine_grpc_definitions
    - fastnetmon
    - fcitx5-mozc
    - frr
    - grpc
    - ilbc
    - libarrow
    - libphonenumber
    - mozc
    - onnxruntime
    - parlaylib
    - plasma-dialer
    - qmlkonsole
    - qt6-qtgrpc
    - spacebar
    - syslog-ng

Of these, I expect plasma-dialer and syslog-ng to FTBFS in the side 
tag since they already FTBFS in Rawhide.


Maintainers of all affected packages should have received this email 
directly (by BCC rather than CC, to keep the message from being held 
for moderation due to a long CC list).


If you want to handle the rebuild of the package yourself, or you have 
other questions or concerns, please just let me know before 2024-02-04.


– Ben Beasley (FAS: music)


[1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/16

[2] https://github.com/abseil/abseil-cpp/releases/tag/20240116.0

[3] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/

[4] https://src.fedoraproject.org/rpms/mozc/pull-request/6



--
___
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! What's up with OpenVDB?

[Ben Beasley]

I opened a PR on calligra[1] at the leaf of the remaining i686 
dependency chain to start the process of dropping i686, because even if 
we get openvdb working now, there’s no good reason to keep i686 versions 
of these packages in the future. The EncourageI686LeafRemoval Change was 
specifically designed to help avoid this kind of extra work to support 
building packages nobody is using on a multilib-only architecture.


Now that I’ve done this, I see that the deed is already done in openvdb, 
OpenImageIO, and OpenColorIO. So once the calligra PR is merged, this 
should be cleanly resolved.


[1] https://src.fedoraproject.org/rpms/calligra/pull-request/1

On 1/29/24 08:20, Richard Shaw wrote:

On Mon, Jan 29, 2024 at 7:13 AM Sérgio Basto  wrote:

>
> Well I just re-tried openvdb with _smp_build_ncpus 1 and it still
> failed so I don't think we have a choice at this point. Perhaps it
> was hitting the 4GB max per process due to being 32bit?
>

Have you try set in build the ulimit [1] .
On copr, copr already set the max number of files already by default
[2] have you check if you can build it on copr ?


No, and I don't have the time, it's not even my package, I just need 
it "fixed" so I can build OpenImageIO and its dependencies in my 
side-tag that should have been merged already.


Also, I'm not sure there's any compelling reason to "save" OpenVDB or 
its dependencies on i686 but if someone wants to go to the trouble 
I'll throw away my side tag and start over, again...


Thanks,
Richard

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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: Mass change of LicenseRef-KDE-Accepted-* licenses

[Ben Beasley]

Miroslav,

Could you please double-check this change? I noticed that in spacebar, 
LicenseRef-KDE-Accepted-GPL was the actual name of a license file in the 
%files section; this was replaced with (GPL-2.0-only OR GPL-3.0-only), 
which causes the package to FTBFS.


Looking at the grep output you originally posted, it seems like 
plasma-phonebook has a similar problem, and kf6-kglobalaccel, 
kf6-kjobwidgets, and kf6-kservice had filenames in comments replaced, 
which won’t break their builds but isn’t correct either.


I still appreciate that you are cleaning this up!

Thanks,
Ben Beasley (FAS: music)

On 1/23/24 04:52, Miroslav Suchý wrote:


Lots of packages in Fedora use license LicenseRef-KDE-Accepted-GPL and 
LicenseRef-KDE-Accepted-LGPL. These licenses were never approved. It 
took lots of time to discuss it and document it. We finally come with:


https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_licenseref_kde_accepted

(copy for your convience)

> KDE project uses LicenseRef-KDE-Accepted-* licenses. This was 
discussed here and here. The consensus is that upstream license 
LicenseRef-KDE-Accepted-GPL should be replaced in Fedora by 
GPL-2.0-only OR GPL-3.0-only. And upstream license 
LicenseRef-KDE-Accepted-LGPL should be replaced by LGPL-2.1-only OR 
LGPL-3.0-only.


It is used 123 times in our spec files (full list at the bottom of 
this email). I am willing to do the mass change (with my proven 
package hat on). I welcome your feedback. If no one stops me with a 
reason by end of this month, I will do the change early next month.


$ grepLicenseRef-KDE-Accepted *
akonadiconsole.spec:License: BSD-3-Clause AND CC0-1.0 AND GPL-2.0-only 
AND GPL-2.0-or-later AND GPL-3.0-only AND LGPL-2.0-or-later AND 
LGPL-2.1-or-later AND LicenseRef-KDE-Accepted-GPL
akonadi-mime.spec:License: BSD-3-Clause AND CC0-1.0 AND GPL-2.0-only 
AND LGPL-2.0-only AND LGPL-2.0-or-later AND LGPL-2.1-or-later AND 
LGPL-3.0-only AND LicenseRef-KDE-Accepted-LGPL
akonadi-search.spec:License: BSD-3-Clause AND CC0-1.0 AND GPL-2.0-only 
AND GPL-2.0-or-later AND GPL-3.0-only AND LGPL-2.0-or-later AND 
LGPL-2.1-only AND LGPL-2.1-or-later AND LGPL-3.0-only
AND LicenseRef-KDE-Accepted-GPL AND LicenseRef-KDE-Accepted-LGPL AND 
(MIT OR Apache-2.0) AND MIT
calendarsupport.spec:License: BSD-3-Clause AND CC0-1.0 AND 
GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND 
LGPL-2.0-or-later AND LicenseRef-KDE-Accepted-GPL
incidenceeditor.spec:License: BSD-3-Clause AND CC0-1.0 AND 
GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND 
LGPL-2.0-or-later AND LicenseRef-KDE-Accepted-GPL
kactivitymanagerd.spec:License: CC0-1.0 AND GPL-2.0-only AND 
GPL-2.0-or-later AND GPL-3.0-only AND LGPL-2.1-only AND LGPL-3.0-only 
AND LicenseRef-KDE-Accepted-GPL AND LicenseRef-KDE-Accepte

d-LGPL
kalendar.spec:License:    BSD-2-Clause AND BSD-3-Clause AND 
CC0-1.0 AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND 
GPL-3.0-or-later AND LGPL-2.0-or-later AND LGPL-2.1-only A
ND LGPL-2.1-or-later AND LGPL-3.0-only AND LGPL-3.0-or-later AND 
LicenseRef-KDE-Accepted-GPL AND LicenseRef-KDE-Accepted-LGPL
kdepim-addons.spec:License: BSD-3-Clause AND CC0-1.0 AND GPL-2.0-only 
AND GPL-2.0-or-later AND GPL-3.0-only AND LGPL-2.0-only AND 
LGPL-2.0-or-later AND LGPL-3.0-only AND LicenseRef-KDE-Acce

pted-GPL AND LicenseRef-KDE-Accepted-LGPL
kdepim-runtime.spec:License: AGPL-3.0-or-later AND BSD-2-Clause AND 
BSD-3-Clause AND CC0-1.0 AND GPL-2.0-only AND GPL-2.0-or-later AND 
GPL-3.0-only AND GPL-3.0-or-later AND LGPL-2.0-only AN
D LGPL-2.0-or-later AND LGPL-2.1-or-later AND LGPL-3.0-only AND 
LGPL-3.0-or-later AND LicenseRef-KDE-Accepted-GPL AND 
LicenseRef-KDE-Accepted-LGPL
kdeplasma-addons.spec:License: BSD-3-Clause AND CC0-1.0 AND 
GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND 
GPL-3.0-or-later AND LGPL-2.0-only AND LGPL-2.0-or-later AND LGPL-2.1-only
AND LGPL-2.1-or-later AND LGPL-3.0-only AND LGPL-3.0-or-later AND 
LicenseRef-KDE-Accepted-GPL AND LicenseRef-KDE-Accepted-LGPL AND MIT
kf5-akonadi-mime.spec:License: BSD-3-Clause AND CC0-1.0 AND 
GPL-2.0-only AND LGPL-2.0-only AND LGPL-2.0-or-later AND 
LGPL-2.1-or-later AND LGPL-3.0-only AND LicenseRef-KDE-Accepted-LGPL
kf5-akonadi-search.spec:License: BSD-3-Clause AND CC0-1.0 AND 
GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND 
LGPL-2.0-or-later AND LGPL-2.1-only AND LGPL-2.1-or-later AND LGPL-3.0-o

nly AND LicenseRef-KDE-Accepted-GPL AND LicenseRef-KDE-Accepted-LGPL
kf5-akonadi-server.spec:License: BSD-3-Clause AND CC0-1.0 AND 
GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-only AND LGPL-2.0-only 
AND LGPL-2.0-or-later AND LGPL-2.1-or-later AND LicenseRef

-KDE-Accepted-GPL AND MIT
kf5-attica.spec:License: CC0-1.0 AND LGPL-2.0-or-later AND 
LGPL-2.1-only AND LGPL-3.0-only AND LicenseRef-KDE-Accepted-LGPL
kf5-bluez-qt.spec:License:    CC0-1.0, LGPL-2.1-only AND 
LGPL-2.1-or-later AND LGPL-3.0-only AND LicenseRef-KDE-Accepted-LGPL
kf5-calendarsupport.spec:Lice

Heads-up: abseil-cpp 20240116.0 coming to F40/Rawhide

[Ben Beasley]

In one week, 2024-02-04, or slightly later, I plan to update abseil-cpp 
from 20230802.1 to 20230116.0 (Abseil LTS branch, Jan 2024)[1] in side 
tags for F40/Rawhide. If I miss getting the update into Rawhide before 
F40 branching, I plan to do the update in both F41/Rawhide and F40/Branched.


Like all new calendar versions of abseil-cpp, this breaks ABI 
compatibility and bumps the SONAME version. There are also some small 
intentional breaking API changes[2].


Testing in COPR[3] indicates all directly-dependent packages are 
compatible, except mozc, which can be fixed by a PR[4].


Besides abseil-cpp, I plan to rebuild all dependent packages using 
maintainer/co-maintainer or provenpackager privileges. I also plan to 
merge the mozc PR if it is still open. These packages are:


    - bear
    - bloaty
    - credentials-fetcher
    - CuraEngine_grpc_definitions
    - fastnetmon
    - fcitx5-mozc
    - frr
    - grpc
    - ilbc
    - libarrow
    - libphonenumber
    - mozc
    - onnxruntime
    - parlaylib
    - plasma-dialer
    - qmlkonsole
    - qt6-qtgrpc
    - spacebar
    - syslog-ng

Of these, I expect plasma-dialer and syslog-ng to FTBFS in the side tag 
since they already FTBFS in Rawhide.


Maintainers of all affected packages should have received this email 
directly (by BCC rather than CC, to keep the message from being held for 
moderation due to a long CC list).


If you want to handle the rebuild of the package yourself, or you have 
other questions or concerns, please just let me know before 2024-02-04.


– Ben Beasley (FAS: music)


[1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/16

[2] https://github.com/abseil/abseil-cpp/releases/tag/20240116.0

[3] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/

[4] https://src.fedoraproject.org/rpms/mozc/pull-request/6

--
___
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! What's up with OpenVDB?

[Ben Beasley]

Blender already excludes i686:

https://src.fedoraproject.org/rpms/blender/blob/8088da10c20e53ab0e1dd5de6fd3a2344bd288aa/f/blender.spec#_207

So does prusa-slicer:

https://src.fedoraproject.org/rpms/prusa-slicer/blob/44359e4b53c503cb61a60842abf991a01d1cb9db/f/prusa-slicer.spec#_68

Packages depending directly on openvdb are:

$ fedrq wrsrc -s openvdb
OpenImageIO-2.4.17.0-1.fc40.src
blender-1:4.0.2-1.fc40.src
luxcorerender-2.7-0.10.beta1.fc40.src
openvkl-2.0.0-5.fc40.src
prusa-slicer-2.4.2-13.fc40.src
usd-23.11-2.fc40.src

Of these, it looks like only OpenImageIO builds on i686. Packages 
depending on it are:


$ fedrq wrsrc -s OpenImageIO
OpenColorIO-2.2.1-6.fc40.src
blender-1:4.0.2-1.fc40.src
embree-4.3.0-2.fc40.src
luxcorerender-2.7-0.10.beta1.fc40.src
oidn-2.1.0-1.fc40.src
openshadinglanguage-1.12.14.0-9.fc40.src
usd-23.11-2.fc40.src

Of those, only OpenColorIO builds on i686. Packages depending on it are:

$ fedrq wrsrc -s OpenColorIO
OpenImageIO-2.4.17.0-1.fc40.src
blender-1:4.0.2-1.fc40.src
calligra-3.2.1-25.fc39.src
krita-5.2.2-1.fc40.src
luxcorerender-2.7-0.10.beta1.fc40.src
usd-23.11-2.fc40.src

Of those, only calligra builds on i686, and it’s a leaf package. So, if 
I haven’t missed anything, as long as i686 support is dropped from all 
of calligra, OpenColorIO, OpenImageIO, and openvdb, then it should be OK.


On 1/28/24 10:18, Richard Shaw wrote:
Well I upped the memory to 10GB and got it to build but the issue on 
i686 with the wrong tbb package being pulled in has not been corrected 
by any of the 4 maintainers of the package. So I did a minimal update 
and changed the tbb BR's from pkgconf to cmake and a scratch build 
completed pulling in the correct tbb-devel on i686, but now two 
attempts at real builds fail...


I think it's time to retire openvdb on i686 but blender and 
prusa-slicer would need to stop building for i686 first as first level 
BRs, I didn't dig any deeper into the dependency chain.


Thanks,
Richard

--
___
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: Orphaning python-flit

[Ben Beasley]

I patched python-signature-dispatch[1] and python-vecrec[2] so that they 
now use flit-core. I’m glad you pointed out that they were using flit.


[1] https://github.com/kalekundert/signature_dispatch/pull/6

[2] https://github.com/kxgames/vecrec/pull/3

On 1/25/24 15:58, Maxwell G wrote:

On Thu Jan 25, 2024 at 20:34 +0100, Miro Hrončok wrote:

Hello.

Hi Miro,

Thanks for the announcement!


Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.

For context, flit-core is the PEP 517 build backend that we need for use
with %pyproject_* in RPM builds. python3-flit provides the flit CLI that
can be used for basic Python project management (publishing to PyPI and
such). python3-flit and python3-flit-core used to be built from the same
SRPM, but we recently split it into two separate packages to simply the
specfile and help with RHEL builds.

While Python developers can always install the flit CLI with pipx or in
a virtual environment, it is nice to have a global version managed by
the system package manager.

I'll probably end up taking the package.


$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3.fc39.src
python-signature-dispatch-0:1.0.1-4.fc39.src
python-vecrec-0:0.3.1-11.fc40.src
weasyprint-0:60.2-1.fc40.src

The packages would probably build fine with flit-core (happy to help with that
if you are interested).

Regardless, those packages should switch to using flit-core to build.
Pulling in all of flit is not necessary for RPM builds.


--
___
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

Planning to unretire rust-zopfli and rust-oxipng

[Ben Beasley]

As required by the Package Retirement Process[1], this email announces 
that I plan to unretire the rust-zopfli and rust-oxipng packages. Both 
were retired because they were “no longer needed,” but I would like to 
package the oxipng command-line tool, which is similar to the existing 
optipng tool.


I have already prepared PR’s that revert the unretirement commits and 
update each package to the latest version[2][3], and the packages are 
ready for re-review[4][5].


[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming


[2] https://src.fedoraproject.org/rpms/rust-zopfli/pull-request/1

[3] https://src.fedoraproject.org/rpms/rust-oxipng/pull-request/1

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2259758

[5] https://bugzilla.redhat.com/show_bug.cgi?id=2259760

--
___
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

Orphaning python-sure (test dependency for python-httpretty)

[Ben Beasley]

I’ve decided to orphan python-sure. I have taken care of it for some 
time, after picking it up the last time it was orphaned, and the package 
is in good shape. Nevertheless, there are a couple of reasons I don’t 
want to own it any more:


    - Although I have a downstream patch that removes the dependency on 
the deprecated PyPI mock package[1] in the current release, upstream is 
working on a new major version, 3.0, that still has a hard dependency on 
mock. While they seem open to at least downgrading this to a test 
dependency that can be more easily removed[2], this remains a bit of a 
headache.


    - The new 3.0 release will add a runtime dependency on 
python-couleur, which would have to be packaged and which currently uses 
both nose[3] and mock for its own tests.


All of this can be worked around, but there is also only one remaining 
dependent package benefiting from all that effort, python-httpretty. I 
have CC’d its maintainers on this email in case someone wants to take 
over python-sure rather than dropping python-httpretty’s tests when it 
goes away.


[1] https://fedoraproject.org/wiki/Changes/DeprecatePythonMock

[2] https://github.com/gabrielfalcao/sure/pull/188#issuecomment-1893093994

[3] https://fedoraproject.org/wiki/Changes/DeprecateNose
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Ben Beasley]

It looks like openvdb-devel manages to accidentally depend on the tbb 
compat package on i686 only, which breaks OpenImageIO because 
OpenImageIO depends on the updated tbb, and that conflicts with the 
compat package:


Problem: package tbb2020.3-devel-2020.3-3.fc40.i686 conflicts with tbb-devel 
provided by tbb-devel-2021.11.0-2.fc40.i686
  - package openvdb-devel-11.0.0-2.fc40.i686 requires pkgconfig(tbb) >= 3.0, 
but none of the providers can be installed
  - conflicting requests

This is because openvdb-devel Requires pkgconfig(tbb), but on i686 the 
current tbb-devel provides only pkgconfig(tbb32), not pkgconfig(tbb).


The best and simplest fix is probably to adjust openvdb-devel so it 
Requires cmake(TBB) instead, which works on all architectures and is 
more technically accurate anyway. However, I haven’t attempted to 
actually implement this fix.


This issue breaks the dependency chain openvdb → OpenImageIO → 
openshadinglanguage → usd → blender, which is the reason (or at least 
the initial/primary reason?) Blender failed in the mass rebuild[1].


I’m posting about this in part just to explain the problem in case 
anyone else is encountering something similar.


– Ben Beasley (FAS music)

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111976337


On 1/19/24 07:45, Jonathan Wakely wrote:

On Fri, 19 Jan 2024 at 01:27, Sérgio Basto  wrote:

On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:

On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely
wrote:

On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely
wrote:

I'll be building boost, tbb, and the packages that depend on them
in
the f40-build-side-81691
side tag over the next few hours (in advance of the mass rebuild
tomorrow).

If your package gets a "Rebuilt for Boost 1.83.0" comment, please
don't rebuild it in rawhide, we're building it in the side tag
and
will merge it back to rawhide. If you need to update your package
before the mass rebuild, please let me and Patrick (CC'd) know
and
your changes can be built in the side tag too.

Please DO NOT build your package in rawhide if we're rebuilding it
in
the boost side tag. It will require another rebuild in the side tag
and another bodhi update and delay the mass rebuild by several more
hours while the gating tests run.

OK, the side tag has been merged. Builds can be done in rawhide again
now.


not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
needs pass in all "Test Gating" or is running again "Test Gating" for
new build(s)

(The new build that I think you caused btw!)

I'm not sure what's going on with the waiting status, but it's in
stable, and the new packages are in the buildroot and being used by
the mass rebuild.
--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Ben Beasley]

I attempted a quick check:

    $ repoquery -q --repo=rawhide -l -a | tee >(

        grep -E '^/usr/bin/[^/]+$' | sort -u | xargs -n 1 basename > 
bin.txt


        ) | grep -E '^/usr/sbin/[^/]+$' | sort -u | xargs -n 1 basename 
> sbin.txt


    $ wc -l bin.txt sbin.txt

     31229 bin.txt
      2998 sbin.txt
     34227 total

    $ comm -1 -2 bin.txt sbin.txt

    arping
    backintime-qt-root
    bat
    beesu
    chkrootkit
    etherape
    exabgp-healthcheck
    faxq
    gearmand
    hcidump
    hddtemp
    hunt
    ifstat
    iscsistart
    lshw-gui
    lspci
    makemap
    mate-system-log
    msktutil
    named-checkconf
    named-checkzone
    named-compilezone
    pidof
    ping
    ptdump
    rdistd
    rhino
    rpcbind
    rpcinfo
    sendfax
    sestatus
    setup
    sievec
    subscription-manager
    system-switch-java
    tmpwatch
    tracepath
    udevadm
    updatedb
    v4l-conf
    vpnc
    vpnc-disconnect

That should be a reasonably accurate list of the executables that need 
investigation, and for which the packages that provide them probably 
need some kind of modification.


On 1/7/24 10:47, Gary Buhrmaster wrote:

On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney  wrote:

Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin


I do not see as part of the plan a process to
go through all Fedora packages and identifying
binaries in /usr/bin that have the same name
as a binary in /usr/sbin (from the same, or
different packages) such that the packager
(or the multiple packages) will need to
coordinate the changes (perhaps by engaging
upstream).

I agree that there should be few, but
identifying impacts in advance provides
for a better decision process, and minimizes
the last minute work that packagers need
to do (they will have a longer warning and
preparation time).
--
___
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: updating python-pynamodb to 6.0.0 in Rawhide

[Ben Beasley]

In one week, 2024-01-21, or slightly later, I will update 
python-pynamodb to 6.0.0 in Rawhide[1]. This is a major version update 
with breaking changes[2]; however, there should be no impact to other 
Fedora packagers since python-pynamodb is currently a leaf package.


[1] https://src.fedoraproject.org/rpms/python-pynamodb/pull-request/1

[2] https://pynamodb.readthedocs.io/en/latest/release_notes.html#v6-0-0
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Planning to unretire rust-libdeflater and rust-libdeflate-sys

[Ben Beasley]

As required by the Package Retirement Process[1], this email announces 
that I plan to unretire the rust-libdeflater and rust-libdeflate-sys 
packages. Both were retired because they were “no longer needed,” but 
they will be in the dependency tree of a new python-cramjam package 
needed for the latest versions of python-fastavro.


I have already prepared PR’s that revert the unretirement commits and 
update each package to the latest version[2][3], and the packages are 
ready for re-review[4][5].


[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming


[2] https://src.fedoraproject.org/rpms/rust-libdeflater/pull-request/1

[3] https://src.fedoraproject.org/rpms/rust-libdeflate-sys/pull-request/1

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2256974

[5] https://bugzilla.redhat.com/show_bug.cgi?id=2256975
--
___
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

License for python-grabbit updated from “MIT” to “MIT AND Unlicense”

[Ben Beasley]

The License field for python-grabbit has been updated from “MIT” to “MIT 
AND Unlicense” to reflect the _version.py file generated by Versioneer 0.29.


As described in 
https://github.com/python-versioneer/python-versioneer#license, the 
_version.py file generated by Versioneer is under the same license as 
Versioneer itself. Since Versioneer 0.24, this is Unlicense; before 
that, it was CC0-1.0, or in much older versions, a public-domain 
declaration represented as LicenseRef-Fedora-Public-Domain.

--
___
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: Broken %pyproject_buildrequires parser

[Ben Beasley]

I think I would just do something like this in %prep:

sed -r -i 's/^file:/# &/' tests/requirements.in

On Thu, Dec 28, 2023, at 11:41 AM, Mattia Verga wrote:
> While trying to update python-rpds-py I came across this commit:
> https://github.com/crate-py/rpds/commit/27d6caf11aac8170e2e9fd56042f05ab27cdb580
>
> The 'file:.#egg=rpds-py' breaks %pyproject_buildrequires parser... 
> what's the best way to fix/patch it?
> --
> ___
> 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
--
___
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

[EPEL-devel] Re: EPEL-ANNOUNCE Incompatible update of llhttp in EPEL9

[Ben Beasley]

I have pushed this update to stable.

This is the final announcement prescribed by the EPEL Incompatible 
Upgrades Policy, 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ 



On 12/13/23 08:43, Ben Beasley wrote:
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.

--
___
epel-announce mailing list -- epel-annou...@lists.fedoraproject.org
To unsubscribe send an email to 
epel-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/epel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
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

[EPEL-devel] Incompatible update of llhttp in EPEL9

[Ben Beasley]

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.

--
___
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

Orphaning python-markdown-include

[Ben Beasley]

I’m orphaning the package python-markdown-include[1]. It is a leaf 
package in Fedora and EPEL9, and has been for several releases, although 
it is still used by a number of packages in the wider Python ecosystem[2].


The package is up to date, upstream remains active, and the spec file is 
clean, trivial, and follows modern practices. I’m not going to keep 
maintaining it “just in case” any longer, but feel free to pick it up if 
you think you will need it for something.


[1] https://src.fedoraproject.org/rpms/python-markdown-include

[2] https://www.wheelodex.org/projects/markdown-include/rdepends/
--
___
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: updating python-ujson to 5.9.0 in Rawhide

[Ben Beasley]

In one week, 2023-12-20, or slightly later, I plan to update 
python-ujson to 5.9.0 in Fedora Rawhide[1]. A COPR impact check shows no 
regressions[2] (the buildstream FTBFS is pre-existing), but the upstream 
release notes[3] indicate two breaking changes,


    - Raise `TypeError` if `toDict()` returns a non-`dict` instead of 
silently converting it to `null`

    - Use lowercase strings for `bool` `dict` keys

and I am therefore treating this as an incompatible update.

If you maintain a package that depends on python-ujson and there are 
extra manual QA checks that you do periodically, or if you know the code 
so well that you can easily audit for potential issues not covered by 
the tests in %check, you might want to have a look at it sometime in the 
F40 release cycle.


- Ben Beasley (FAS music)

[1] https://src.fedoraproject.org/rpms/python-ujson/pull-request/13

[2] https://copr.fedorainfracloud.org/coprs/music/ujson/packages/

[3] https://github.com/ultrajson/ultrajson/releases/tag/5.9.0
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Proposed incompatible security update (again) for llhttp in EPEL9

[Ben Beasley]

Since I sent the original email, I learned that aiohttp 3.9.0, a 
compatible feature release, also fixes two additional CVE’s, 
CVE-2023-49081[1] and CVE-2023-49082[2]. A COPR impact check[3] shows 
that the proposed llhttp update will allow python-aiohttp to be safely 
updated all the way from 3.8.5 to 3.9.1 in EPEL9, fixing these CVE’s as 
well. (As explained in the Bugzilla issues, I don’t have any plans to 
work on the EPEL8 branch.)


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2252239

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2252250

[3] https://copr.fedorainfracloud.org/coprs/music/aiohttp-el9/packages/

On 11/28/23 11:36, Ben Beasley wrote:
This email proposes upgrading the llhttp package in EPEL9 from 8.1.1 
to 9.1.3, which would break the ABI and bump the SONAME version, under 
the EPEL Incompatible Upgrades Policy[1].


The llhttp package is a C library (transpiled from TypeScript) that 
provides the low-level HTTP support for NodeJS and for python-aiohttp. 
Currently, only python-aiohttp depends on the llhttp package in EPEL9.


Versions of python-aiohttp prior to 3.8.6[2] are affected by 
CVE-2023-47627[3][4], an HTTP request/response smuggling vulnerability 
rated 5.3 in CVSS v3 and rated Moderate by Red Hat. This was reported 
as RHBZ#2249825[5]. Since the flaw is only in the pure-Python parser, 
and we compile the llhttp-based parser, this affects only code using 
the AIOHTTP_NO_EXTENSIONS environment variable. Updating aiohttp from 
3.8.5 to 3.8.6 to fix that still requires updating llhttp from 8.x to 
9.x. Additionally, according to the release notes this includes an 
llhttp-related security fix[6] with no assigned CVE, which provides 
added motivation to update.


The ABI break in llhttp would only affect python-aiohttp. The 
python-aiohttp update itself is compatible (by upstream intent, and as 
already demonstrated in Rawhide and F39/F38); and a large list of 
packages that depend on python-aiohttp would benefit from the fix. The 
necessary rebuild would be conducted in a side tag.


The same incompatible update was approved by FESCo for Fedora 38 and 
39[7]. Furthermore, it appears that FESCo will approve a permanent 
exception for llhttp[8].


The purpose of this email is to document and explain the proposed 
update, to begin the minimum one-week discussion period mandated by 
the EPEL Incompatible Upgrades Policy, and to request that the update 
be added to the agenda for an upcoming EPEL meeting.


[1] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades


[2] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6

[3] https://access.redhat.com/security/cve/CVE-2023-47627

[4] 
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-gfw2-4jvh-wgfg


[5] https://bugzilla.redhat.com/show_bug.cgi?id=2249825

[6] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6

[7] https://pagure.io/fesco/issue/3106

[8] https://pagure.io/fesco/issue/3115


--
___
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

[EPEL-devel] Proposed incompatible security update (again) for llhttp in EPEL9

[Ben Beasley]

This email proposes upgrading the llhttp package in EPEL9 from 8.1.1 to 
9.1.3, which would break the ABI and bump the SONAME version, under the 
EPEL Incompatible Upgrades Policy[1].


The llhttp package is a C library (transpiled from TypeScript) that 
provides the low-level HTTP support for NodeJS and for python-aiohttp. 
Currently, only python-aiohttp depends on the llhttp package in EPEL9.


Versions of python-aiohttp prior to 3.8.6[2] are affected by 
CVE-2023-47627[3][4], an HTTP request/response smuggling vulnerability 
rated 5.3 in CVSS v3 and rated Moderate by Red Hat. This was reported as 
RHBZ#2249825[5]. Since the flaw is only in the pure-Python parser, and 
we compile the llhttp-based parser, this affects only code using the 
AIOHTTP_NO_EXTENSIONS environment variable. Updating aiohttp from 3.8.5 
to 3.8.6 to fix that still requires updating llhttp from 8.x to 9.x. 
Additionally, according to the release notes this includes an 
llhttp-related security fix[6] with no assigned CVE, which provides 
added motivation to update.


The ABI break in llhttp would only affect python-aiohttp. The 
python-aiohttp update itself is compatible (by upstream intent, and as 
already demonstrated in Rawhide and F39/F38); and a large list of 
packages that depend on python-aiohttp would benefit from the fix. The 
necessary rebuild would be conducted in a side tag.


The same incompatible update was approved by FESCo for Fedora 38 and 
39[7]. Furthermore, it appears that FESCo will approve a permanent 
exception for llhttp[8].


The purpose of this email is to document and explain the proposed 
update, to begin the minimum one-week discussion period mandated by the 
EPEL Incompatible Upgrades Policy, and to request that the update be 
added to the agenda for an upcoming EPEL meeting.


[1] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades


[2] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6

[3] https://access.redhat.com/security/cve/CVE-2023-47627

[4] 
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-gfw2-4jvh-wgfg


[5] https://bugzilla.redhat.com/show_bug.cgi?id=2249825

[6] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6

[7] https://pagure.io/fesco/issue/3106

[8] https://pagure.io/fesco/issue/3115
--
___
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

Heads-up: python-param 2.0.0 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-10, or slightly later, I plan to update 
python-param to 2.0.0 in Rawhide[1]. This is a major release with 
massive changes, including a number of breaking ones[2]. Nevertheless, 
all of the dependent packages in Fedora are already compatible[3].


[1] https://src.fedoraproject.org/rpms/python-param/pull-request/3

[2] https://github.com/holoviz/param/releases/tag/v2.0.0

[3] https://copr.fedorainfracloud.org/coprs/music/param2/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

Heads-up: python-probeinterface 0.2.18 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-07, or slightly later, I plan to update 
python-probeinterface to 0.2.18 in Rawhide[1]. This release contains 
some small breaking API changes[2]; in particular, the 
with_channel_index argument is removed from plot_probe. Since 
python-probeinterface is currently a leaf package, this will have no 
impact on other packages.


[1] https://src.fedoraproject.org/rpms/python-probeinterface/pull-request/3

[2] 
https://github.com/SpikeInterface/probeinterface/blob/0.2.18/doc/releases/0.2.18.rst


___
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: python-socketio 5.10.0 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-05, or slightly later, I plan to update 
python-socketio to 5.10.0 in Rawhide[1]. This release contains one 
documented breaking API change (“async versions of enter_room and 
leave_room should be coroutines”), but all dependent packages still 
build from source, and I don’t expect that any changes to dependent 
packages will be required.


[1] https://src.fedoraproject.org/rpms/python-socketio/pull-request/3
___
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: usd 23.11 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-05, or slightly later, I plan to update usd to 
23.11 in Rawhide[1]. This includes ABI changes and a SONAME version 
bump. There are no documented breaking API changes[2].


The sole dependent package is blender. I verified compatibility in a 
local mock build, and I will rebuild it in a side tag as a co-maintainer.


[1] https://src.fedoraproject.org/rpms/usd/pull-request/13

[2] 
https://github.com/PixarAnimationStudios/OpenUSD/blob/v23.11/CHANGELOG.md

___
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: python-pytest-bdd 7.0.0 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-03, or slightly later, I plan to update 
python-pytest-bdd to 7.0.0 in Rawhide[1].


There is one incompatible change:

    - ⚠️ Backwards incompatible: - ``parsers.re`` now does a `fullmatch 
`_ instead of a 
partial match. This is to make it work just like the other parsers, 
since they don't ignore non-matching characters at the end of the 
string. `#539 `_


However, the only package that depends on python-pytest-bdd is jrnl, and 
I confirmed that it is compatible with version 7.0.0.


While I’m talking about python-pytest-bdd, I will mention that I retired 
the python-pytest-bdd5 compat package in Rawhide/F40 since jrnl no 
longer requires it, and nothing else depended on it.


[1] https://src.fedoraproject.org/rpms/python-pytest-bdd/pull-request/5

___
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: python-pyrsistent 0.20.0 coming to Rawhide

[Ben Beasley]

In one week, 2023-11-02, or slightly later, I plan to build 
python-pyrsistent 0.20.0[1] in Rawhide/F40. The list of changes is at 
[2]. Notably, pyrsistent now freezes defaultdicts, which is considered a 
backwards-incompatible change.


The only dependent package in Rawhide is python-sentry-sdk; it does not 
upper-bound the version of python-pyrsistent, and I checked 
compatibility in COPR[3].


[1] https://src.fedoraproject.org/rpms/python-pyrsistent/pull-request/7

[2] https://github.com/tobgu/pyrsistent/blob/v0.20.0/CHANGES.txt

[3] https://copr.fedorainfracloud.org/coprs/music/pyrsistent/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

Heads-up: updating python-trimesh to 4.0.0 in Rawhide

[Ben Beasley]

In one week, 2023-10-31, or slightly later, I plan to update the 
python-trimesh package in Rawhide to version 4.0.0[1]. No dependent 
package upper-bounds its version, and a COPR impact check[2] did not 
reveal any incompatibilities.


[1] https://src.fedoraproject.org/rpms/python-trimesh/pull-request/10

[2] https://copr.fedorainfracloud.org/coprs/music/trimesh4/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

Re: Upgrades of Sundials and PETSc

[Ben Beasley]

Just a heads-up that whichever process you have been using to determine 
the list of affected dependent packages has been missing getdp; see 
https://bugzilla.redhat.com/show_bug.cgi?id=2245240 and 
https://bugzilla.redhat.com/show_bug.cgi?id=2189695. I just rebuilt 
getdp in Rawhide, so there’s nothing to do right now.


For next time, this seems to work for me:

for p in petsc{,64,-openmpi,-mpich} libpetsc.so; do repoquery -q 
--repo=rawhide{,-source} --whatrequires "$p"; done | sort -u


Well, it doesn’t work in Rawhide right now, because the 
rebuilt getdp-3.5.0-10.fc40.x86_64 hasn’t been part of a compose yet, 
and getdp-3.5.0-9.fc40.x86_64 still requires libpetsc.so.3.19()(64bit), 
which petsc-0:3.20.0-1.fc40.x86_64 doesn’t provide. But at any other 
time, that command would reveal getdp as a package that needs rebuilding.


Thanks,

Ben Beasley (FAS music)

On 10/7/23 06:50, Antonio T. sagitter wrote:

Hi all.

In 1 week, i will upgrade Sundials and PETSc to their related newer 
versions:


PETSc-3.20.0
https://petsc.org/release/changes/320/

sundials-6.6.1
https://github.com/LLNL/sundials/releases

Following packages will be rebuilt:

bout++
freefem++
octave
cantera
dolfin

Regards.

___
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: Python enable dependency generator problem

[Ben Beasley]

It looks like you are using “%pyproject_buildrequires -t”, and upstream’s 
tox.ini gets its dependencies from the file test-requirements.txt, which pins 
exact versions of everything (==). Obviously, it’s very rare that this will 
line up with the versions packaged in Fedora. If you’re going to use that file, 
you’ll need to patch it in %prep to remove the version pins, or at least 
convert them to lower bounds (s/==/>=) if that seems appropriate. You should 
also patch out the dependency on pytest-cov 
(https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters).

If that all gets too messy, a less satisfying but more straightforward 
alternative would be to eschew tox, maintain the list of BR’s for the tests 
manually in the spec file the old-fashioned way, and run the tests with %pytest 
instead of %tox.

On Tue, Oct 10, 2023, at 4:30 PM, Priscila Gutierres wrote:
> Hello, 
>
> I'm trying to add python enable dependency generator on 
> python-pymemcache, but when adding it to the specfile, it asks for some 
> old version of some needed packages:
> https://paste.centos.org/view/33623ed7 
>
> Fedora repos have a more updated version, but this dependency generator 
> is asking for an older version of those packages:
>
> https://src.fedoraproject.org/rpms/python-faker
> https://src.fedoraproject.org/rpms/python-gevent
> https://src.fedoraproject.org/rpms/python-pylibmc
>
>
> How to fix this?
>
>
> Priscila.
> ___
> 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: python-absl-py 2.0.0 coming to Rawhide

[Ben Beasley]

In one week, 2023-10-07, or slightly later, I plan to update 
python-absl-py to 2.0.0 in Rawhide[1].


This release has some potentially breaking changes, described in [2], 
but it is a leaf package, so there is no impact to other packages in Fedora.


[1] https://src.fedoraproject.org/rpms/python-absl-py/pull-request/3

[2] https://github.com/abseil/abseil-py/releases/tag/v2.0.0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Claiming and unretiring python-pybv

[Ben Beasley]

I (FAS: music) plan to adopt the python-pybv package and unretire it in 
F39 and F40/Rawhide. This email provides the required[1] notice. This 
package was retired while orphaned today due to FTI/FTBFS.


I already have a PR that fixes the FTI/FTBFS[2], so I will be able to 
deal with that promptly.


I will add the neuro-sig packager group to the package, as it clearly 
falls within the scope of the NeuroFedora SIG.


[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming


[2] https://src.fedoraproject.org/rpms/python-pybv/pull-request/2
___
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: Orphaned packages looking for new maintainers

[Ben Beasley]

Since the python-qdarkstyle package is needed for the Spyder IDE, I 
ended up claiming it and fixing it. The main change is that I dropped 
the dependency on PySide2, since PySide2 is still broken on Python 3.12.


Now that python-qdarkstyle is installable on F39/F40 again, I was able 
to build electrum without any modifications; I added the builds  to my 
latest updates involving python-qdarkstyle:


F40: https://bodhi.fedoraproject.org/updates/FEDORA-2023-3a1e52015a

F39: https://bodhi.fedoraproject.org/updates/FEDORA-2023-527f01eddb

I’ve never used Electrum, and I didn’t attempt to test the package 
interactively, but at least it is buildable and installable now.



On 9/7/23 7:58 AM, Ben Beasley wrote:
It looks like the Electrum build is currently blocked not by protobuf, 
but by the failure of python-qdarkstyle to rebuild for Python 
3.12[1][2]. That dependency is also currently orphaned.


Grepping through the Electrum source, I see:

    Electrum-4.3.4/contrib/requirements/requirements.txt
    2:protobuf>=3.12,<4

    Electrum-4.3.4/contrib/requirements/requirements-hw.txt
    32:protobuf>=3.12,<4

    Electrum-4.3.4/contrib/deterministic-build/requirements-hw.txt
    175:protobuf==3.20.3 \

    Electrum-4.3.4/contrib/deterministic-build/requirements.txt
    31:protobuf==3.20.3 \

Based on that, it looks like the minimum protobuf version should 
actually be 3.12 (we have 3.19), not 3.20; the latter should only be 
the preferred version for deterministic builds. So I suspect 
everything will be fine if you can get python-qdarkstyle fixed.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2225768#c6

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2220472

On 9/7/23 05:52, Jonathan Schleifer wrote:
Unfortunately, it is worse than this: Electrum FTI in F39. A newer 
Electrum version would fix that, but F39 still has no new enough 
protobuf.


Is there any other solution here than saying packaging Electrum for 
Fedora 39 is just not possible and remove the package in F39, then 
reintroduce it in F40 (that is, if F40 finally gets a newer protobuf)?



___
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: Blender 3.6.2 failure to build

[Ben Beasley]

Thanks for working on this.

Are you certain that Blender failed to build in F39? As I reported in 
[1], the build failure in question is due to openxr 1.0.29, which only 
happened in F40.


Koschei remains green for F39[2], and there is a pending update rebuilt 
against USD 23.08[3] (so please don’t rebuild Blender again in F39 until 
that update goes stable at the end of the Beta Freeze).


For F40, we agreed to go ahead and merge the USD 23.08 side tag and fix 
the Blender build afterward[4]. At the time, there was no upstream patch 
available. I’m glad to see that one is available now. After you apply 
the patch, please do rebuild Blender in Rawhide to fix the current FTI 
bug[5]. Or I can commit the patch and do the rebuild, if you’d prefer.


Let me know if there’s anything I can do to help!


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2236801

[2] https://koschei.fedoraproject.org/package/blender?collection=f39

[3] https://bodhi.fedoraproject.org/updates/FEDORA-2023-62bee27bd1

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2236801#c2

[5] https://bugzilla.redhat.com/show_bug.cgi?id=2237533

On 9/15/23 3:40 AM, Luya Tshimbalanga wrote:

Hi,

On Thu, Sep 14, 2023 at 11:12 PM Luya Tshimbalanga
https://projects.blender.org/blender/blender/issues/111820 Try
applying the linked patch in
https://projects.blender.org/blender/blender/commit/8159bd90e527552ccfe27...

Thanks, Elliot. The patch fixed the issue.

Luya
___
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: python-ezdxf 1.1.0 coming to Rawhide/F40 with incompatible font support

[Ben Beasley]

In one week, 2023-09-16, I plan to update the python-ezdxf package in 
Rawhide/F40 from 1.0.3 to 1.1.0[1]. Upstream warns[2]:


    - WARNING: The font support changed drastically in this version, if 
you use the
      `ezdxf.tools.fonts` module your code will break, sorry! Pin the 
`ezdxf` version to

      v1.0.3 in your `requirements.txt` file to use the previous version!

The sole dependent package, python-trimesh, is not affected by these 
changes.


[1] https://src.fedoraproject.org/rpms/python-ezdxf/pull-request/3

[2] https://ezdxf.mozman.at/release-v1-1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Ben Beasley]

It looks like the Electrum build is currently blocked not by protobuf, 
but by the failure of python-qdarkstyle to rebuild for Python 
3.12[1][2]. That dependency is also currently orphaned.


Grepping through the Electrum source, I see:

    Electrum-4.3.4/contrib/requirements/requirements.txt
    2:protobuf>=3.12,<4

    Electrum-4.3.4/contrib/requirements/requirements-hw.txt
    32:protobuf>=3.12,<4

    Electrum-4.3.4/contrib/deterministic-build/requirements-hw.txt
    175:protobuf==3.20.3 \

    Electrum-4.3.4/contrib/deterministic-build/requirements.txt
    31:protobuf==3.20.3 \

Based on that, it looks like the minimum protobuf version should 
actually be 3.12 (we have 3.19), not 3.20; the latter should only be the 
preferred version for deterministic builds. So I suspect everything will 
be fine if you can get python-qdarkstyle fixed.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2225768#c6

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2220472

On 9/7/23 05:52, Jonathan Schleifer wrote:
Unfortunately, it is worse than this: Electrum FTI in F39. A newer 
Electrum version would fix that, but F39 still has no new enough 
protobuf.


Is there any other solution here than saying packaging Electrum for 
Fedora 39 is just not possible and remove the package in F39, then 
reintroduce it in F40 (that is, if F40 finally gets a newer protobuf)?



___
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: Orphaned packages looking for new maintainers

[Ben Beasley]

Interested parties have been grappling with the problem of getting protobuf 
updated to v4 (22.x, 23.x, etc.), but the number of impacted packages is 
tremendous and there are not enough people with time to work on it, so progress 
has been slow. The following PR represents the state of that work[1]. Note that 
I’m not a co-maintainer of protobuf, but I’ve been collaborating on it because 
it is an important dependency for grpc, and I can’t update grpc any more 
(including for security fixes) until we have protobuf v4.

There was some sentiment that we should focus on working toward the protobuf v4 
transition rather than on updating to newer 3.x branches during the F39 
development cycle. However, I’m not sure if everyone really understood the full 
scope of that transition.

At this point, and given the amount of work remaining to make protobuf v4 
possible, it’s probably a good idea for protobuf to be updated to a current v3 
release, ideally 3.24.2. Given the number of potentially impacted packages, and 
the huge list of packages that need to be rebuilt (minor version updates break 
ABI), it’s probably too late to land that in F39, but it should be possible for 
F40, and it would be a good hedge against the possibility that the v4 work 
drags on for another release cycle (or more?!).

Input is welcome. Even more welcome is assistance working through unresolved 
protobuf v4 incompatibilities in dependent packages.

[1] https://src.fedoraproject.org/rpms/protobuf/pull-request/25

On Mon, Sep 4, 2023, at 2:39 PM, Jonathan Schleifer wrote:
> Am 04.09.23 um 17:10 schrieb Miro Hrončok:
>
>> electrum  js, orphan   0 
>> weeks ago
>
> Electrum isn't orphaned, but cannot be updated because protobuf is not 
> being updated. Newer versions require at least protobuf 3.20. I 
> contacted the protobuf maintainer on 2023-06-04 and never got a reply.
>
> -- 
> Jonathan
> ___
> 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

[EPEL-devel] Re: Incompatible security update for llhttp in EPEL9

[Ben Beasley]

I just pushed this update to stable.

On 8/17/23 9:08 AM, Ben Beasley wrote:
This email announces that the llhttp package in EPEL9 will be upgraded 
from 6.0.10 to 8.1.1[1], which breaks the ABI and bumps the SONAME 
version, as discussed[2] and approved[3] under the EPEL Incompatible 
Upgrades Policy[4]. At the same time, python-aiohttp will be upgraded 
from 3.8.4 to 3.8.5. Currently, only python-aiohttp depends on the 
llhttp package in EPEL9. This update fixes CVE-2023-30589[5].


Users of the python-aiohttp package, or of the various packages that 
depend on it, will benefit from this security fix but should not 
expect any incompatibilities or performance regressions.


In the unlikely case that you are maintaining software that depends 
directly on the llhttp package, you will need to rebuild it due to the 
SONAME version bump. Breaking changes from 6.0.10 to 8.1.1 include a 
couple of HTTP parsing changes (“do not allow whitespaces after start 
line,” “require semicolon to start chunk parameters”) and one API 
change (“rename status code 509”). Most programs will not require 
source code changes.


[1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e2fcc4af81

[2] 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/DLJ4ILU6QHXN2YYHTHNTAF2ED6YRP23H/


[3] https://pagure.io/epel/issue/241

[4] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades


[5] https://access.redhat.com/security/cve/CVE-2023-30589

[4] https://github.com/advisories/GHSA-cggh-pq45-6h9x

[5] 
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w



___
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

Heads-up: updating python-databases to 0.8.0 in Rawhide/F40 and in F39

[Ben Beasley]

In one week, 2023-09-05, I plan to update[1] python-databases to 0.8.0 
in Rawhide/F40 and in F39.


This release includes some potentially-breaking changes[2]: “In most 
cases, these changes should not be breaking. However, if using an open 
transaction across tasks, the active connection (db.connection()) now 
needs to be explicitly passed to each task.” I have verified 
compatibility with both dependent packages, python-fastapi and 
python-slackclient: they build from source and there are no regressions 
in their extensive test suites.


Regarding updating F39 during the Beta Freeze, I think that the likely 
benefit of bugfixes to connection and translation isolation outweighs 
the small chance of a regression slipping through the dependent 
packages’ test suites.


[1] https://src.fedoraproject.org/rpms/python-databases/pull-request/1

[2] https://github.com/encode/databases/releases/tag/0.8.0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Heads-up: updating usd (OpenUSD) from 23.05 to 23.08 in Rawhide and F39

[Ben Beasley]

In one week, 2023-09-01, I plan to update the usd package (OpenUSD) from 
23.05 to 23.08 [1][2] in Rawhide/F40 and in F39. There are only very 
minor API changes, but the ABI is incompatible and the SONAME version is 
bumped.


I will rebuild the sole dependent package, blender, in a side tag for 
each release. Anyone further updating Blender in F39 during the Beta 
Freeze should re-use the same side tag, or at least tag in the USD 23.08 
build to a new side tag. Let me know if you are planning such an update, 
and I’ll be happy to answer questions or take care of the builds myself.


[1] https://src.fedoraproject.org/rpms/usd/pull-request/12

[2] 
https://github.com/PixarAnimationStudios/OpenUSD/blob/v23.08/CHANGELOG.md#2308---2023-07-21

___
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] Incompatible security update for llhttp in EPEL9

[Ben Beasley]

This email announces that the llhttp package in EPEL9 will be upgraded 
from 6.0.10 to 8.1.1[1], which breaks the ABI and bumps the SONAME 
version, as discussed[2] and approved[3] under the EPEL Incompatible 
Upgrades Policy[4]. At the same time, python-aiohttp will be upgraded 
from 3.8.4 to 3.8.5. Currently, only python-aiohttp depends on the 
llhttp package in EPEL9. This update fixes CVE-2023-30589[5].


Users of the python-aiohttp package, or of the various packages that 
depend on it, will benefit from this security fix but should not expect 
any incompatibilities or performance regressions.


In the unlikely case that you are maintaining software that depends 
directly on the llhttp package, you will need to rebuild it due to the 
SONAME version bump. Breaking changes from 6.0.10 to 8.1.1 include a 
couple of HTTP parsing changes (“do not allow whitespaces after start 
line,” “require semicolon to start chunk parameters”) and one API change 
(“rename status code 509”). Most programs will not require source code 
changes.


[1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e2fcc4af81

[2] 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/DLJ4ILU6QHXN2YYHTHNTAF2ED6YRP23H/


[3] https://pagure.io/epel/issue/241

[4] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades


[5] https://access.redhat.com/security/cve/CVE-2023-30589

[4] https://github.com/advisories/GHSA-cggh-pq45-6h9x

[5] 
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w

___
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

Heads-up: llhttp 9.0.1 coming to Rawhide

[Ben Beasley]

In one week, 2023-08-29, I plan to update llhttp from 8.1.1 to 9.0.1 in 
F40/Rawhide[1]. This update contains some breaking API changes and 
breaks the ABI, bumping the SONAME version[2][3]. Most significantly, 
the compile-time LLHTTP_STRICT_MODE option is replaced with three new 
runtime flags.


The sole dependent package is python-aiohttp; I will rebuild it myself 
in a side tag, using a patch for llhttp 9.x support backported from an 
unreleased upstream commit[4].


I don’t plan to apply the python-aiohttp patch and the llhttp 9.0.1 
update to F39 at this time, with the understanding that this will 
constrain future python-aiohttp updates in F39: I would prefer to avoid 
getting ahead of upstream. I might reconsider this if an upstream 
release of python-aiohttp using llhttp 9.x happens by the end of the 
beta freeze, or if someone convinces me that keeping llhttp at 8.1.1 is 
the wrong approach. Input is welcome.


[1] https://src.fedoraproject.org/rpms/llhttp/pull-request/15

[2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.0.0

[3] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.0.1

[4] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/27
___
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: abseil-cpp 20230802.0 coming to F40/Rawhide and F39/Branched

[Ben Beasley]

In one week, 2023-08-28, I plan to update abseil-cpp from 20230125.3 to 
20230802.0 (Abseil LTS branch, Aug 2023)[1] in side tags for F40/Rawhide 
and F39/Branched.


Like all new calendar versions of abseil-cpp, this breaks ABI 
compatibility and bumps the SONAME version. There are no intentional 
breaking API changes[2].


Testing in COPR[3] indicates all directly-dependent packages are 
compatible. (A change was required in mozc and fcitx5-mozc, which were 
using internal/non-API symbols[4]; the necessary change has already been 
discussed with upstream and committed to dist-git.)


Besides abseil-cpp, I will rebuild the following dependent packages as 
maintainer or co-maintainer:


    bear, fastnetmon, grpc, libarrow (Rawhide only, using collaborator 
privileges)


I should be able to build existing commits of the following packages 
even though I do not have privileges on the dist-git projects:


    fcitx5-mozc, mozc

The following were tested in COPR but do not need to be rebuilt, because 
they are header-only and do not link dynamically against abseil-cpp:


    parlaylib

I will ask the maintainers of the following to rebuild into the side 
tags, asking a provenpackager to help if the maintainers are not able to 
follow up within a few days:


    bloaty, credentials-fetcher, frr, ilbc, libarrow (F39 only), 
libphonenumber, plasma-dialer, qmlkonsole, syslog-ng


If you maintain a package on this final list, please expect another 
direct email once the side tags are ready and I have built at least 
abseil-cpp and grpc. If you want me to handle rebuilds like this in the 
future, you can add me as a co-maintainer (FAS music) with commit 
privileges, or at minimum collaborator privileges on the rawhide branch 
since these updates will usually happen before branching.


Maintainers of all affected packages should have received this email 
directly (by BCC rather than CC, to keep the message from being held for 
moderation due to a long CC list).


Finally, those working on the eventual upgrade of protobuf from 3.x to 
v4 (22.x/23.x/24.x) should be aware that it looks like we will need to 
package a 24.x release for compatibility with this abseil-cpp 
release[5][6]. This shouldn’t be a problem; we are nowhere close to 
working out all the issues in dependent packages for protobuf v4, which 
will certainly not happen in F39, and another rebase of the working 
PR[7] will be a trivial effort compared to the other necessary work.


[1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/14

[2] https://github.com/abseil/abseil-cpp/releases/tag/20230802.0

[3] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2231905

[5] https://github.com/google/mozc/issues/790#issuecomment-1679915315

[6] https://github.com/protocolbuffers/protobuf/pull/13534/files

[7] https://src.fedoraproject.org/rpms/protobuf/pull-request/25
___
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] Proposed incompatible security update for llhttp in EPEL9

[Ben Beasley]

This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to 
8.1.1, which would break the ABI and bump the SONAME version, under the 
EPEL Incompatible Upgrades Policy[1].


The llhttp package is a C library (transpiled from TypeScript) that 
provides the low-level HTTP support for NodeJS and for python-aiohttp. 
Currently, only python-aiohttp depends on the llhttp package in EPEL9.


Versions of llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an 
HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated 
Moderate by Red Hat. The GitHub advisory for llhttp is 
GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is 
GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by 
updating llhttp (which they bundle, but we unbundle) in release 3.8.5.


I am not comfortable attempting to backport the fix to an older release 
of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] 
and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI 
break in llhttp would only affect python-aiohttp; the python-aiohttp 
update itself is compatible (by upstream intent, and verified in 
COPR[7]); and a number of packages that depend on python-aiohttp would 
benefit from the fix.


If this exception request is not approved, my fallback plan is to 
propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, 
which would convert it to a pure-Python package. This is a documented 
mitigation, but comes with potentially serious performance regressions, 
again affecting a number of dependent packages. The llhttp package would 
become a leaf package and would remain unpatched.


The same incompatible update was approved by FESCo for Fedora 37[8].

The purpose of this email is to document and explain the proposed 
update, to begin the minimum one-week discussion period mandated by the 
EPEL Incompatible Upgrades Policy, and to request that the update be 
added to the agenda for an upcoming EPEL meeting.


[1] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades


[2] https://access.redhat.com/security/cve/CVE-2023-30589

[3] https://github.com/advisories/GHSA-cggh-pq45-6h9x

[4] 
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w


[5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14

[6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26

[7] https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/

[8] https://pagure.io/fesco/issue/3049
___
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: Orphaned python-testing.postgresql

[Ben Beasley]

I realized I have a package pending review[1] that uses 
python-testing.postgresql for its tests, so I have picked it back up 
(along with python-testing.common.database), and I will fix the 
FTI/FTBFS in F39/Rawhide.


It’s unfortunate that upstream seems to have moved on from these 
packages, but I do want to run the tests that require them, and they are 
simple enough that I expect I can keep them working for as long as 
necessary without much effort.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2189323

On 7/18/23 11:02, Ben Beasley wrote:

In response, I have also orphaned python-testing.common.database:

    - since python-testing.postgresql was the only package that 
depended on it (python-testing.mysqld was never packaged)


    - since nothing depends on python-testing.postgresql anymore, and

    - since upstream for these packages has been inactive for 4-5 years

I think it’s probably best to let these packages go, but anyone 
considering picking them up should know that both packages have spec 
files that use modern practices and are in a good “state of repair.”


- Ben Beasley (FAS: music)

On 7/18/23 2:47 AM, Miroslav Suchý wrote:

I orphaned

  https://src.fedoraproject.org/rpms/python-testing.postgresql

I do not use it any more. Feel free to grab it.


___
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

License change: python-h5io is now simply BSD-3-Clause

[Ben Beasley]

Prior to release 0.1.8, python-h5io used a bundled, amalgamated 
versioneer.py under CC0-1.0 to generate a _version.py file under the 
same license, so the package was licensed (BSD-3-Clause AND CC0-1.0). 
With release 0.1.8, upstream no longer uses Versioneer, so the package 
license is now simply BSD-3-Clause[1].


[1] https://src.fedoraproject.org/rpms/python-h5io/pull-request/3
___
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: Orphaned python-testing.postgresql

[Ben Beasley]

In response, I have also orphaned python-testing.common.database:

    - since python-testing.postgresql was the only package that 
depended on it (python-testing.mysqld was never packaged)


    - since nothing depends on python-testing.postgresql anymore, and

    - since upstream for these packages has been inactive for 4-5 years

I think it’s probably best to let these packages go, but anyone 
considering picking them up should know that both packages have spec 
files that use modern practices and are in a good “state of repair.”


- Ben Beasley (FAS: music)

On 7/18/23 2:47 AM, Miroslav Suchý wrote:

I orphaned

  https://src.fedoraproject.org/rpms/python-testing.postgresql

I do not use it any more. Feel free to grab it.


___
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: Non-responsive maintainer check for Athos Ribeiro,(athoscr)

[Ben Beasley]

Thanks for your response! Of course, I understand that free time is a scarce 
and unpredictable commodity.

Please do let me know if you need someone to co-maintain, or just make a few 
PR’s for, any of the font-related Python packages.

Best wishes,
Ben Beasley (FAS music)

On Mon, Jul 17, 2023, at 3:51 PM, Athos Ribeiro wrote:
> On Mon, Jul 17, 2023 at 03:13:31PM -0400, Ben Beasley wrote:
>>Does anyone know how to contact Athos Ribeiro (FAS: athoscr)? This 
>>email is part of the non-responsive maintainer process 
>>(https://bugzilla.redhat.com/show_bug.cgi?id=2223422).
>
> Hi Ben,
>
> Thanks for the contact :)
>
> I haven't been able to give those some love due to ENOTIME different job
> in a while.
>
> I am setting up my fedora dev env once again this week and will start
> either giving some love to each of those or start passing the one I am
> no longer interested in maintaining forward!
>
>>The following PR and bug/NEEDINFO have received no response in 7-9 months:
>>
>>https://src.fedoraproject.org/rpms/python-defcon/pull-request/1
>>
>>    https://bugzilla.redhat.com/show_bug.cgi?id=1936574
>>
>>The activity report at https://src.fedoraproject.org/user/athoscr/ 
>>shows no activity in the past year, and fedora-active-user reports:
>>
>>    $ python3 fedora_active_user.py --user athoscr --nofas
>>    Last action on koji:
>>       Wed, 31 May 2023 tag_package_owners entry created by bodhi 
>>[still active]
>>
>>    Last package update on bodhi:
>>       2021-02-19 23:00:32 on package hugo-0-1
>>    Last actions performed according to fedmsg:
>>      - io.pagure.prod.pagure.issue.comment.added on 2023-02-15 07:07:42
>>
>>A list of some other apparently-neglected bugs follows.
>>
>>Updates available for a long time with the release-monitoring.org bugs 
>>still in the NEW state:
>>
>>    flawfinder: https://bugzilla.redhat.com/show_bug.cgi?id=1914559
>>
>>    python-fontMath: https://bugzilla.redhat.com/show_bug.cgi?id=1974954
>>
>>    python-glyphsLib: https://bugzilla.redhat.com/show_bug.cgi?id=1881116
>>
>>    python-pyclipper: https://bugzilla.redhat.com/show_bug.cgi?id=194
>>
>>    rubygem-chake: https://bugzilla.redhat.com/show_bug.cgi?id=1907051
>>
>>    rubygem-fakefs: https://bugzilla.redhat.com/show_bug.cgi?id=2209178
>>
>>    rubygem-pathspec: https://bugzilla.redhat.com/show_bug.cgi?id=1912644
>>
>>A Python 3.12 compatibility bug has also received no response since 
>>late last year:
>>
>>    python-firehose: https://bugzilla.redhat.com/show_bug.cgi?id=2154946
>>
>>Additionally, a request to consider fixing or retiring a package:
>>
>>    rubygem-sinatra-rabbit: 
>>https://bugzilla.redhat.com/show_bug.cgi?id=1880144
>>
>
> -- 
> Athos Ribeiro
___
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

Non-responsive maintainer check for Athos Ribeiro,(athoscr)

[Ben Beasley]

Does anyone know how to contact Athos Ribeiro (FAS: athoscr)? This email 
is part of the non-responsive maintainer process 
(https://bugzilla.redhat.com/show_bug.cgi?id=2223422).


The following PR and bug/NEEDINFO have received no response in 7-9 months:

https://src.fedoraproject.org/rpms/python-defcon/pull-request/1

    https://bugzilla.redhat.com/show_bug.cgi?id=1936574

The activity report at https://src.fedoraproject.org/user/athoscr/ shows 
no activity in the past year, and fedora-active-user reports:


    $ python3 fedora_active_user.py --user athoscr --nofas
    Last action on koji:
       Wed, 31 May 2023 tag_package_owners entry created by bodhi 
[still active]


    Last package update on bodhi:
       2021-02-19 23:00:32 on package hugo-0-1
    Last actions performed according to fedmsg:
      - io.pagure.prod.pagure.issue.comment.added on 2023-02-15 07:07:42

A list of some other apparently-neglected bugs follows.

Updates available for a long time with the release-monitoring.org bugs 
still in the NEW state:


    flawfinder: https://bugzilla.redhat.com/show_bug.cgi?id=1914559

    python-fontMath: https://bugzilla.redhat.com/show_bug.cgi?id=1974954

    python-glyphsLib: https://bugzilla.redhat.com/show_bug.cgi?id=1881116

    python-pyclipper: https://bugzilla.redhat.com/show_bug.cgi?id=194

    rubygem-chake: https://bugzilla.redhat.com/show_bug.cgi?id=1907051

    rubygem-fakefs: https://bugzilla.redhat.com/show_bug.cgi?id=2209178

    rubygem-pathspec: https://bugzilla.redhat.com/show_bug.cgi?id=1912644

A Python 3.12 compatibility bug has also received no response since late 
last year:


    python-firehose: https://bugzilla.redhat.com/show_bug.cgi?id=2154946

Additionally, a request to consider fixing or retiring a package:

    rubygem-sinatra-rabbit: 
https://bugzilla.redhat.com/show_bug.cgi?id=1880144

___
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: getattr default value evaluation

[Ben Beasley]

The assertRaisesRegexp alias was removed in Python 3.12, along with a number of 
other previously-deprecated TestCase method aliases. You can search for it in 
https://docs.python.org/3.12/whatsnew/3.12.html. Upstream should just use 
assertRaisesRegex unconditionally unless they are trying to support Python 2.7.

On Sun, Jul 9, 2023, at 1:27 PM, Mattia Verga wrote:
> This code:
> ```
> from unittest import TestCase
> _testcase = TestCase('setUp')
> getattr(_testcase, 'assertRaisesRegex', _testcase.assertRaisesRegexp)
> ```
> was working in Python 3.11, but doesn't work anymore in 3.12:
> AttributeError: 'TestCase' object has no attribute 
> 'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?
>
> The default value was previously ignored, while now it is evaluated 
> even if it is not required. Is this an expected change behavior in 
> Python 3.12?
> ___
> 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
___
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

Re: Package deprecation policy

[Ben Beasley]

On 6/30/23 04:34, Benson Muite wrote:

There is at present no policy on when and why packages should be
deprecated.  Have made a proposal to allow deprecation of packages only
when they fail to build or are a security concern.  In other cases,
orphaning and retirement should be done. Comments and suggestions for
improvement are welcome.


There are other valid reasons to deprecate packages. Upstream 
deprecation is one of them.


For example, three of the subpackages in python-opentelemetry are 
currently deprecated because upstream has deprecated them, and I expect 
them to disappear in the future. Deprecating the subpackages keeps 
anyone from packaging something that depends on them and then being 
impacted a few months later by their removal in Rawhide.


In my experience, deprecation is used extremely sparingly (there are 
only 42 spec files in the entire distribution with the string 
“deprecated()”), and I am not aware of any issues with it being used 
carelessly. Furthermore, the current policy already requires a 
FESCo-approved change to deprecate anything that has dependent packages.


I am not convinced that the proposed Change clearly or accurately 
reflects all of the valid uses for deprecation, nor am I convinced that 
attempting to codify these uses is useful to packagers or solves an 
actual problem in the distribution or community.



This would also likely impact package review guidelines, since there are
packages that people may want in Fedora, which build but do not have
much upstream activity.


There certainly is no extant policy on how much upstream activity a 
package needs to have to enter or remain in Fedora, nor do I think it is 
reasonable to regulate this on anything other than a case-by-case basis. 
There are decades-old scientific tools with deceased authors that are 
still perfectly useful, there are tools that are “done” but have 
upstreams that spring into action after ten years of quiescence if a new 
bug is found, there are network libraries with large attack surfaces 
that might cause concern if an upstream PR or issue languishes untriaged 
for a few months, and there is everything in between.


The document 
https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/ 
already warns about the added maintenance burden of packaging projects 
with inactive or absent upstreams, and it is reasonable for a package 
reviewer to warn the submitter about an inactive upstream. It still 
makes sense to package these projects when they are sufficiently useful 
or when good alternatives are not yet available.

___
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: python-typeguard 4.0.0 coming to Rawhide

[Ben Beasley]

I plan to update python-typeguard from 2.12.3 to 4.0.0[1] in Rawhide.

Version 3 of typeguard included a number of breaking changes[2], and 
4.0.0 included a few as well[3].


Directly-dependent package compatibility with version 4.0.0 is as follows:

    - python-nptyping is compatible

    - python-signature-dispatch will be compatible with a concurrent 
update from 1.0.0 to 1.0.1[4]


    - python-stack-data has dropped the dependency in Rawhide

    - python-TestSlide is incompatible, but (1) the package already 
FTBFS in F38 and Rawhide, and (2) I opened PR’s to fix the existing 
FTBFS[5] and typeguard 4 compatibility[6] about a month ago. The 
maintainers can easily fix the incompatibility whenever they want to 
address the existing FTBFS.


While the Updates Policy prescribes one week’s notice for 
API-incompatible updates like this[7], the intent of that rule is to 
avoid breaking packages without notice. In this case, python-typeguard 
already FTBFS in Rawhide since python-typing-extensions was updated from 
4.5.0 to 4.6.2, and this incompatible update is required to fix that. If 
the package is not updated, python-typeguard and everything that 
directly or indirectly depends on it will fail in the Python 3.12 mass 
rebuild.


I have therefore asked FESCo for permission to update immediately rather 
than waiting out the usual one-week notice period.[8]


[1] https://src.fedoraproject.org/rpms/python-typeguard/pull-request/3

[2] 
https://github.com/agronholm/typeguard/blob/3.0.0/docs/versionhistory.rst#version-history


[3] 
https://github.com/agronholm/typeguard/blob/4.0.0/docs/versionhistory.rst#version-history


[4] 
https://src.fedoraproject.org/rpms/python-signature-dispatch/pull-request/1


[5] https://src.fedoraproject.org/rpms/python-TestSlide/pull-request/1

[6] https://src.fedoraproject.org/rpms/python-TestSlide/pull-request/2

[7] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide

[8] https://pagure.io/fesco/issue/3014
___
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: flatbuffers 23.5.26 coming to Rawhide

[Ben Beasley]

In one week (2023-06-06), or slightly later, I plan to build flatbuffers 
23.5.26 in Rawhide[1]. Because flatbuffers offers no ABI stability, it 
will be necessary to rebuild the sole dependent package, hyperhdr. Since 
I don’t currently have access to that project, there are three 
possibilities:


- I can let the maintainer know when the side tag is available for the 
flatbuffers update, and they can rebuild hyperhdr into it.


- If the maintainer wants me to handle this and future rebuilds for 
flatbuffers, they can add me to the hyperhdr project with at least 
collaborator privileges on the rawhide branch.


- If I don’t hear from the maintainer, I can ask a provenpackager to 
rebuild hyperhdr.


[1] https://src.fedoraproject.org/rpms/flatbuffers/pull-request/7
___
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: Bypassing setuptools_scm

[Ben Beasley]

On Sun, May 28, 2023, at 8:03 PM, Orion Poplawski wrote:
> Is there a canonical way to bypass setuptools_scm?  Sometimes one would 
> like to build from a github tarball (e.g. for test data) but then 
> setuptool_scm fails to detect a version.

Setting the environment variable SETUPTOOLS_SCM_PRETEND_VERSION should do what 
you want. This also works for packages that use hatch-vcs.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi
___
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

Re: Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a license change

[Ben Beasley]

On 5/27/23 08:33, Fabio Valentini wrote:
This doesn't explicitly mention statically linked binaries / 
header-only libraries, but it's clear that this rule applies to these 
situations as well (after all, binaries *are* built from project 
sources that have distinct licenses). I don't see how C/C++ 
header-only libraries (or Go packages, fwiw) should be treated 
differently than Rust crates.


I agree that C/C++ header-only libraries are effectively the same case 
as Rust crates. I do think it is fair to point out that the distinction 
between "header” and “source” files in C and C++ is mostly cultural 
rather than technical, and that header-only libraries represent a 
somewhat arbitrary line in the sand when it comes to considering the 
licenses of headers. I’m not complaining about that arbitrariness; it’s 
probably necessary.


I doubt that anyone expects it would be practical, or useful to 
end-users, to consider every header used in the build in the license 
expression, yet header-only libraries are not technically a special 
case. The headers of C++ and even C shared-library packages may contain 
just as much template or inline code as header-only libraries. Just look 
at the standard library implementations of both languages for an 
example. This code is compiled into the caller just as a header-only 
library would be, but it’s my understanding that we don’t consider it in 
the license expression as long as the dependency also has a 
dynamically-linked portion.


Asking packagers to manually track licenses of all included headers 
(which may change without any change to the package’s spec file or 
sources) seems like it would be ridiculously burdensome; so does asking 
them to assess some kind of measure of “triviality.” We are left with 
considering only header-only libraries (and static libraries, which are 
discouraged but occasionally necessary), not because this exactly 
reflects the objective truth, but because it seems to be the last 
plausibly reasonable step before a descent into madness.


I am not sure that it is possible for Fedora’s policy in this area to be 
both practically usable and perfectly logically consistent. It would 
certainly be useful to document it a little more clearly.

___
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

Updating fast_float from 4.0.0 to 5.0.0 in Rawhide, with a license change

[Ben Beasley]

This is a “heads-up” email about a (non-breaking) major version update 
with a (non-disruptive) license change in the fast_float package in Rawhide.


Once I have a successful scratch build in the PR[1], I plan to update 
fast_float from 4.0.0 to 5.0.0.


ABI changes are impossible because this is a header-only library; the 
upstream release notes[2] do not describe any breaking API changes; and 
I have verified compatibility of all dependent packages via local mock 
builds. Given all of that, I am not treating this as a breaking update 
even though the major version number is incremented.


A significant change in this release is the addition of Boost (BSL-1.0) 
as an additional disjunctive license option. The package license 
therefore changes from


Apache-2.0 OR MIT

to

Apache-2.0 OR MIT OR BSL-1.0

Since fast_float is a header-only library, and our guidelines treat 
these as a kind of static library, directly-dependent packages 
should—strictly speaking—include fast_float’s SPDX license expression in 
their own. I will take care of the necessary change for c4core[3].


[1] https://src.fedoraproject.org/rpms/fast_float/pull-request/5

[2] https://github.com/fastfloat/fast_float/releases/tag/v5.0.0

[3] https://src.fedoraproject.org/rpms/c4core/pull-request/8
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Status of the forge macros?

[Ben Beasley]

On 5/25/23 03:02, Panu Matilainen wrote:

On 5/24/23 18:26, Zbigniew Jędrzejewski-Szmek wrote:

Minor comment:
   %(c=%{commit}; echo ${c:0:7})
is a bit nicer because it doesn't require 'cut', it just uses 'echo',
which is a shell builtin.


Or in rpm >= 4.19 (just landed in rawhide), you can just do

%{sub %{commit} 1 8}


Both of these suggestions are really nice small improvements. Thanks!

Since this use case is in the Version field, and therefore the expansion 
is needed in the source RPMs, I will have to wait to use the RPM macro 
until my machine and the Koji builders are on rpm >=4.19. It’s still 
good to know about.


The shell-parameter-expansion suggestion takes a zero-based index and 
length[1], while the Lua routine exposed in the RPM macro takes the 
first and last one-based indices of the substring[2], so the exact 
equivalent would be:


    %{sub %{commit} 1 7}

[1] 
https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html


[2] https://www.lua.org/pil/20.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Status of the forge macros?

[Ben Beasley]

In your example, the forge macros simplify the spec file only because a 
snapshot is involved; but the forge macros put the snapshot info in the Release 
field, which is still permissible but deprecated[1].

Without the forge macros, the spec file would admittedly be a little more 
complex. I would probably do something like the following:

%global commit   791953030836d39687688a8e7f1a3e708892cfa1
%global snapdate 20230420

Version: 1.2^%{snapdate}git%(echo '%{commit}' | cut -b -7)
Release: 1%{?dist}

URL: https://github.com/riscv/opensbi
Source: %{url}/archive/%{commit}/opensbi-%{commit}.tar.gz

%prep
%autosetup -n opensbi-%{commit}

If the need to package a snapshot goes away, then the utility of the forge 
macros does too, as the packaging without them is perhaps even simpler than 
wirh them:

Version: 1.2.12345
Release: 1%{?dist}

URL: https://github.com/riscv/opensbi
Source: %{url}/archive/v%{version}/opensbi-%{version}.tar.gz

%prep
%autosetup

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#traditional-versioning

On Wed, May 24, 2023, at 9:32 AM, Richard W.M. Jones wrote:
> On Wed, May 24, 2023 at 09:56:30AM +0200, Vitaly Zaitsev via devel wrote:
>> On 23/05/2023 19:27, Richard W.M. Jones wrote:
>> >... so today I was taking part in a package review which uses these
>> >macros and was surprised to be told that they are deprecated.
>> 
>> Their author left Fedora a few years ago. They're now unmaintained
>> and may be removed soon (see FPC ticket[1]).
>> 
>> [1]: https://pagure.io/packaging-committee/pull-request/1270
>
> So the issue for me is I'm considering a new package (opensbi).  It is
> greatly(?) simplified by using the forge macros.  Nothing in official
> documentation says that new packages shouldn't use the forge macros,
> although the link above would add such a statement.  There seems to be
> disagreement in this thread about the best way forwards.
>
> Proposed spec:
> http://git.annexia.org/?p=fedora-reviews.git;a=blob;f=opensbi/opensbi.spec
>
> Rich.
>
> -- 
> Richard Jones, Virtualization Group, Red Hat 
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> 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: more distinct default bash prompt?

[Ben Beasley]

In my experience, “colorblindness” is generally understood to include a range 
of color vision “anomalies.” I have the most common form, deuteranomaly. Green 
does not look as bright as other colors to me, and I have a hard time 
distinguishing greenish colors from reddish colors when they are desaturated 
(like greenish-brown versus reddish-brown), or when looking at fine points or 
lines rather than large areas of color. I can still easily distinguish bright 
green from bright red, even in a small area, but it’s very difficult to 
distinguish a small amber LED from a green one.

It’s best to avoid using color to communicate essential information with no 
backup mechanism; to use something like the contrast ratio formulas from WCAG 
2.2 to ensure adjacent colors contrast sufficiently in luminance and not only 
in hue; and to particularly avoid contrasting colors that are both reddish or 
greenish when possible, since these are the most troublesome for the largest 
number of people.

On Tue, May 23, 2023, at 1:08 AM, Jens-Ulrik Petersen wrote:
> On Tue, May 23, 2023 at 12:47 PM Neal Gompa  wrote:
>> I actually would prefer that we color both, and make it obvious that
>> "root" is special. We should account for common color-blindness
>> issues, though.
>
> Sure, I think I agree: perhaps purple for root?
>
> I am all for "color blind testing" (though I am not completely sure 
> that "color-blind" is the right term here
> though I am not an a11y expert - I thought color blind is more about 
> differentiating different colors like green and red,
> but if you mean visual impairment/contrast/readability then I 
> completely agree).
> I think in the end it will come down also to wider user testing since 
> there are so many different terminals
> and color palettes around.
>
> Anyway that's why I proposed green since it seems to have reasonable 
> contrast for both light and dark terminals (unlike blue/cyan/yellow 
> often).
> I assume that may also be why Ubuntu and Nixos went with green.
>
> Jens
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: changing the name of a package

[Ben Beasley]

On Sat, May 6, 2023, at 10:58 AM, Sandro wrote:
> Moreover, pdf-stapler package itself should probably be renamed to 
> python-stapler to comply with the PyPI parity requirements [2] of the 
> packaging guidelines. The package is published on PyPI as 'stapler'.
>
> [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
> [2] 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_pypi_parity

I don’t think the PyPI parity rule needs to apply to the base package name, 
since this is primarily an application package and thus falls under the general 
naming guidelines[1]. You could make a case for renaming the python3-staplelib 
subpackage to python3-staple, adding the appropriate Obsoletes[2], and adding 
%py_provides python3-staplelib[3].

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_application_naming
[2] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
[3] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules
___
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: Numpy version pinned despite numpy>=1.22.3

[Ben Beasley]

You’re right that project.dependencies has numpy>=1.22.3[1], but 
upstream is also pinning numpy versions in the build-system.requires 
section[2] in the same manner as oldest-supported-numpy[3]. This is for 
PyPI distribution purposes; we don’t need to build wheels that support 
numpy versions older than the one in Fedora, so you can un-pin these 
downstream. I would do something like this in %prep:


    # Do not attempt to build with an old version of numpy; this makes 
sense for

    # PyPI distribution (oldest-supported-numpy) but not here.
    sed -r -i 's/(numpy)==/\1>=/' pyproject.toml

– Ben

[1] https://github.com/has2k1/scikit-misc/blob/main/pyproject.toml#L13

[2] https://github.com/has2k1/scikit-misc/blob/main/pyproject.toml#L86

[3] https://github.com/scipy/oldest-supported-numpy/

On 4/30/23 10:47, Sandro wrote:

Hi,

I'm trying to build/update a package using mesonpy [1].

While going through the build process, exploring how the existing 
macros behave together with mesonpy, I came across a weird build 
error, for which I have not yet found a cause or explanation.


The build fails with [2]:

No matching package to install: 'python3dist(numpy) = 1.23.2'

The version in rawhide is 1.24.3, yet the requirement in 
pyproject.toml [3] is:


"numpy>=1.22.3"

So, why is it insisting on using 1.23.2 while the existing 1.24.3 
satisfies the requirement?


There's one thing I noticed [4], which I believe is unrelated. But I 
asked upstream for clarification anyway.


The spec file is currently work in progress. I simply triggered a Copr 
build, so I could provide links here and verify that this is not a 
local issue in my build environment.


[1] So fresh it's still warm: 
https://src.fedoraproject.org/rpms/python-meson-python
[2] 
https://download.copr.fedorainfracloud.org/results/gui1ty/neuro-sig/fedora-rawhide-x86_64/05862367-python-scikit-misc/root.log.gz
[3] 
https://github.com/has2k1/scikit-misc/blob/8f829888ecf0fa96eb18aeb3f723fc985de5abcd/pyproject.toml#L13

[4] https://github.com/has2k1/scikit-misc/issues/24

Cheers,
___
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

Heads-up: edflib 1.24 coming to Rawhide

[Ben Beasley]

In one week (2023-04-30), or slightly later, I plan to update edflib to 
1.24, which includes a .so version bump. The shared library versioning 
was previously added downstream; now upstream is handling it. The 
package is currently a leaf, so there should be no impact.

___
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: USD 23.02 coming to Rawhide

[Ben Beasley]

Since I announced the update to USD 23.02, USD 23.05 was released, so I 
will update to that version instead. The schedule and the other details 
remain the same.


On 4/17/23 10:58, Ben Beasley wrote:
Now that Blender 3.5 has landed, I can update the usd package in 
Rawhide to version 23.02[1]. I plan to build it in one week, 
2023-04-24, or slightly later.


The .so version is bumped (as with every release) and the monolithic 
library is renamed from libusd_usd_ms.so to libusd_ms.so. I am also 
enabling the Draco plugin now that draco is packaged in Fedora; this 
adds the usdcompress command-line tool.


The sole dependent package is blender; I will rebuild it in a side tag 
myself.


[1] https://src.fedoraproject.org/rpms/usd/pull-request/4


___
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] Retiring flintqs in EPEL7/8/9

[Ben Beasley]

As previously proposed on the epel-devel mailing list, and in accordance 
with the EPEL Retirement Policy: Process: Security Reasons[1], I will be 
retiring the flintqs package in EPEL7, EPEL8, and EPEL9 today.


When I took over maintenance of the flintqs package[2]—which contains 
William Hart’s quadratic sieve implementation, as modified for 
sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why 
not? Someone might find it useful.”


It was recently pointed out[3][4] that the flintqs command-line tool 
uses temporary files in unsafe ways[5], which could potentially 
represent an exploitable security vulnerability; this has been assigned 
CVE-2023-29465[6].


There is no immediate patch available; while one could surely be 
constructed, the sagemath project plans to incorporate the factorization 
algorithm directly in sagemath and discontinue support of the vulnerable 
command-line tool rather than fixing it[7].


Since sagemath is not packaged in any of the EPEL releases, and flintqs 
is therefore a leaf package, I am handling this security report by 
retiring flintqs in all three EPELs.


Anyone who does need FlintQS on EL will need to consider their security 
threat model, then build it from source—either by cloning the upstream 
GitHub repository, or, for the time being, by rebuilding the Fedora 
source RPM. Note, however, that the Fedora package will also be retired 
as soon as it is no longer needed by sagemath.


[1] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons


[2] https://src.fedoraproject.org/rpms/flintqs

[3] https://bugzilla.redhat.com/show_bug.cgi?id=2185301

[4] https://github.com/sagemath/FlintQS/issues/3

[5] https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File

[6] https://nvd.nist.gov/vuln/detail/CVE-2023-29465

[7] https://github.com/sagemath/sage/pull/35419
___
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

Heads-up: USD 23.02 coming to Rawhide

[Ben Beasley]

Now that Blender 3.5 has landed, I can update the usd package in Rawhide 
to version 23.02[1]. I plan to build it in one week, 2023-04-24, or 
slightly later.


The .so version is bumped (as with every release) and the monolithic 
library is renamed from libusd_usd_ms.so to libusd_ms.so. I am also 
enabling the Draco plugin now that draco is packaged in Fedora; this 
adds the usdcompress command-line tool.


The sole dependent package is blender; I will rebuild it in a side tag 
myself.


[1] https://src.fedoraproject.org/rpms/usd/pull-request/4
___
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] Intent to retire flintqs in EPEL7, EPEL8, and EPEL9 for security reasons

[Ben Beasley]

When I took over maintenance of the flintqs package[1]—which contains 
William Hart’s quadratic sieve implementation, as modified for 
sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why 
not? Someone might find it useful.”


It was recently pointed out[2][3] that the flintqs command-line tool 
uses temporary files in unsafe ways[4], which could potentially 
represent an exploitable security vulnerability; this has been assigned 
CVE-2023-29465[5].


There is no immediate patch available; while one could surely be 
constructed, the sagemath project plans to incorporate the factorization 
algorithm directly in sagemath and discontinue support of the vulnerable 
command-line tool rather than fixing it[6].


Since sagemath is not packaged in any of the EPEL releases, and flintqs 
is therefore a leaf package, I plan to handle this security report by 
retiring flintqs in all three EPELs. This email is the beginning of that 
process as prescribed in the EPEL Retirement Policy: Process: Security 
Reasons[7]. I doubt there will be any objections, but the process 
requires a one-week discussion period, so I will follow up on the 
epel-announce list and do the retirements no earlier than 2023-03-17.


[1] https://src.fedoraproject.org/rpms/flintqs

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2185301

[3] https://github.com/sagemath/FlintQS/issues/3

[4] https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File

[5] https://nvd.nist.gov/vuln/detail/CVE-2023-29465

[6] https://github.com/sagemath/sage/pull/35419

[7] 
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons

___
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: Heads-up: fast_float 4.0.0 coming to Rawhide

[Ben Beasley]

Thanks; you’re correct. At least I got the year right!

On Sat, Apr 1, 2023, at 8:47 AM, Luna Jernberg wrote:
> Should this be 2023-04-07? 2023-03-07 has been weeks ago ?
>
> On 3/31/23, Ben Beasley  wrote:
>> In one week (2023-03-07), or slightly later, I plant to update
>> fast_float to 4.0.0[1] in Rawhide. This new major release contains one
>> small but technically incompatible change: errc::result_out_of_range is
>> now set on over/underflow. A PR[2] is ready, and I have already verified
>> (by local mock builds) that dependent packages c4core and libscn remain
>> compatible.
>>
>> [1] https://github.com/fastfloat/fast_float/releases/tag/v4.0.0
>>
>> [2] https://src.fedoraproject.org/rpms/fast_float/pull-request/4
>> ___
>> 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
___
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: fast_float 4.0.0 coming to Rawhide

[Ben Beasley]

In one week (2023-03-07), or slightly later, I plant to update 
fast_float to 4.0.0[1] in Rawhide. This new major release contains one 
small but technically incompatible change: errc::result_out_of_range is 
now set on over/underflow. A PR[2] is ready, and I have already verified 
(by local mock builds) that dependent packages c4core and libscn remain 
compatible.


[1] https://github.com/fastfloat/fast_float/releases/tag/v4.0.0

[2] https://src.fedoraproject.org/rpms/fast_float/pull-request/4
___
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: Anyone interested in packaging nim-lang?

[Ben Beasley]

This is just a note that nim was packaged in Fedora at one point[1], but was 
orphaned and eventually retired. There is a process[2] for reviving such a 
package; it will be similar to the process for adding a new package.

[1] https://src.fedoraproject.org/rpms/nim

[2] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

On Tue, Mar 28, 2023, at 7:53 AM, Ankur Sinha wrote:
> On Tue, Mar 28, 2023 17:11:06 +0530, Riya Bisht wrote:
>> Hello,
>
> Hi Riya,
>
>> I'm interested to package and maintain nim-lang. I've never used nim before 
>> but
>> i would like to start packaging for fedora. I can learn nim in the process.
>> Could you please help me to get started with this?
>
> That's great to hear!
>
> The starting point for package maintainers is here:
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
>
> Language stacks can be complex to build and package, and can also be
> quite a bit of work to maintain. So, if you don't have any packaging
> experience, I'd perhaps work on a few other packages to gain a good
> understanding of the packaging pipeline before taking this on.
>
> -- 
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
>
> ___
> 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
>
> Attachments:
> * signature.asc
___
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: abseil-cpp 20230125.1 coming to Rawhide/F39

[Ben Beasley]

Thank you for helping dig into the details. What you’ve written makes 
sense, and is consistent with the comments in absl/base/options.h 
regarding ABSL_OPTION_USE_STD_STRING_VIEW:


    A value of 2 means to detect the C++ version being used to compile 
Abseil,

    and use an alias only if a working std::string_view is available.  This
    option is useful when you are building your program from source.  
It should
    not be used otherwise -- for example, if you are distributing 
Abseil in a
    binary package manager -- since in mode 2, absl::string_view will 
name a
    different type, with a different mangled name and binary layout, 
depending on

    the compiler flags passed by the end user.  For more info, see
https://abseil.io/about/design/dropin-types.

https://github.com/abseil/abseil-cpp/blob/c8a2f92586fe9b4e1aff049108f5db8064924d8e/absl/base/options.h#L138

For completeness, the reason the value of 
ABSL_OPTION_USE_STD_STRING_VIEW changed from 2 to 1 since the previous 
release is an intentional upstream change described as follows:


    Change `absl/base/options.h` at install time to reflect the ABI used
    to compile the libraries, i.e., if Abseil was compiled with
    C++ >= 17 then the `ABSL_OPTION_USE_STD_*` macros are set to `1`,
    because then the C++ 17 types are embedded in the ABI of the installed
    artifacts.

    Likewise, set the `target_compile_features()` of Abseil libraries
    to reflect the C++ version used to compile them. If they the Abseil
    libraries are compiled with C++ >= 17, then all downstream
    dependencies must also be compiled with C++ >= 17.

https://github.com/abseil/abseil-cpp/commit/308bbf300fe9332130f4784c7a91fa2ad707d6e4

So the only way that dependent packages can use C++14 is if we 
intentionally and explicitly downgrade the C++ standard used to compile 
abseil-cpp from C++17 (the default) to C++14.


Given all this, it appears to me that the best course is still to keep 
abseil-cpp on the default C++17 standard and accept that dependent 
packages cannot use C++14. However, I’m pleased to have a much better 
understanding of what is happening, how, and why, and I’m still happy to 
consider any proposals to proceed differently.


On 3/15/23 6:29 PM, Jonathan Wakely wrote:



On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely  wrote:



On Wed, 15 Mar 2023 at 22:14, Ben Beasley
 wrote:

Thank you for prompting me to look at this more closely. A
quick investigation reveals:

“Abseil libraries require C++14 as the current minimum
standard. When compiled with C++17 (either because it is the
compiler's default or explicitly requested), then Abseil
requires C++17.”


https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291

The abseil-cpp package in Fedora has been compiled as C++17
for some time—at first explicitly, but this would also now be
the default if the spec file did not configure a particular
standard—so it seems dependent packages already technically
needed C++17, and it is mere happenstance that this particular
release is revealing incompatibilities.


I'm not sure if that's true, see my other email which crossed with
yours. In the previous release absl::string_view would work for
both C++14 and C++17, because USE_STD_STRING_VIEW was defined to
2, so adapted to the headers that included it.

In the new release it is hardcoded to only work for C++17. That
seems like a new change in the new version, not something that was
already present.


Digging deeper, maybe it was true, and ilbc was just getting away with 
it by chance.


Several member functions of absl::string_view are defined out-of-line 
in abseil-cpp-20220623.1/absl/strings/string_view.cc but if the 
library is built as C++17 then those won't be defined (because 
absl::string_view is just an alias for std::string_view, so all the 
members come from libstdc++). So all clients of abseil-cpp shared libs 
do need to be compiled as C++17 or later. It looks like 
libilbc.so.3.0.4 doesn't actually use any libasbl_*.so libs, so only 
uses libabsl headers, and that's why it "worked" when the header was 
adaptive w.r.t. the string-view definition. It doesn't care that there 
are no definitions for those string_view member functions, because it 
happens to not use those specific member 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

Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Ben Beasley]

Thank you for prompting me to look at this more closely. A quick investigation 
reveals:

“Abseil libraries require C++14 as the current minimum standard. When compiled 
with C++17 (either because it is the compiler's default or explicitly 
requested), then Abseil requires C++17.”
 
https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291

The abseil-cpp package in Fedora has been compiled as C++17 for some time—at 
first explicitly, but this would also now be the default if the spec file did 
not configure a particular standard—so it seems dependent packages already 
technically needed C++17, and it is mere happenstance that this particular 
release is revealing incompatibilities.

On Wed, Mar 15, 2023, at 10:01 AM, Jonathan Wakely wrote:
> On Wednesday, March 15, 2023, Ben Beasley  wrote:
>> In one week (2023-03-22), or slightly later, I plan to update abseil-cpp[1] 
>> in Rawhide/F39 to the latest LTS release, which is currently 20230125.1. 
>> Release notes are available[2].
>>
>> The most significant breaking change is that dependent packages are required 
>> to compile with C++14 or later, and I have found that users of 
>> absl::string_view need C++17 or later.
>
> Hmm, that seems odd. The release notes say C++14 is required but don't 
> mention that C++17 is needed for some components.
>
> C++17 provides std::string_view so what's the point in using 
> absl::string_view at all if it only works when std::string_view is 
> already available?
>
>> This has already been adjusted in a couple of packages (thanks!) and I have 
>> one PR still open[3].
>
>
> The error you showed there says the problem is using std::string_view, 
> which does indeed require C++17. That doesn't seem related to 
> absl::string_view, unless there's a bug in abseil which causes 
> absl::string_view to incorrectly use std::string_view in C++14 mode.
>
> I think something doesn't make sense here, and would be worth understanding.
>
>
>>
>> All dependent packages build successfully in COPR[4] (with any necessary 
>> C++17 PR’s applied).
>>
>> I will rebuild the following packages in the side tag myself as primary 
>> maintainer or as co-maintainer:
>>
>> - abseil-cpp (of course)
>>
>> - bear
>>
>> - fastnetmon
>>
>> - grpc
>>
>> - libarrow
>>
>> For the remaining packages that need to be rebuilt, when the new version of 
>> abseil-cpp and the rebuilt grpc are ready in the side tag, I will send an 
>> email to their maintainers asking them to rebuild into the side tag. After a 
>> few days, I will ask Rich Mattes, the primary abseil-cpp package maintainer, 
>> to use his provenpackager privileges to rebuild any remaining dependent 
>> packages (and merge the C++17 PR for ilbc if it is still open). He has 
>> already agreed to do so.
>>
>> If you maintain one of the affected packages and you want me to handle 
>> rebuilds in the future, you can grant me privileges on the project; 
>> collaborator on the rawhide branch should be sufficient.
>>
>> - bloaty
>>
>> - credentials-fetcher
>>
>> - fcitx5-mozc
>>
>> - frr
>>
>> - ilbc
>>
>> - libphonenumber
>>
>> - mozc
>>
>> - plasma-dialer
>>
>> - qmlkonsole
>>
>> - spacebar
>>
>> If you maintain one of the affected packages, you should find that you 
>> received this message directly (by BCC due to limitations on the number of 
>> CC recipients imposed by the devel mailing list).
>>
>> [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10
>>
>> [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1
>>
>> [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1
>>
>> [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/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: abseil-cpp 20230125.1 coming to Rawhide/F39

[Ben Beasley]

In one week (2023-03-22), or slightly later, I plan to update 
abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is 
currently 20230125.1. Release notes are available[2].


The most significant breaking change is that dependent packages are 
required to compile with C++14 or later, and I have found that users of 
absl::string_view need C++17 or later. This has already been adjusted in 
a couple of packages (thanks!) and I have one PR still open[3].


All dependent packages build successfully in COPR[4] (with any necessary 
C++17 PR’s applied).


I will rebuild the following packages in the side tag myself as primary 
maintainer or as co-maintainer:


    - abseil-cpp (of course)

    - bear

    - fastnetmon

    - grpc

    - libarrow

For the remaining packages that need to be rebuilt, when the new version 
of abseil-cpp and the rebuilt grpc are ready in the side tag, I will 
send an email to their maintainers asking them to rebuild into the side 
tag. After a few days, I will ask Rich Mattes, the primary abseil-cpp 
package maintainer, to use his provenpackager privileges to rebuild any 
remaining dependent packages (and merge the C++17 PR for ilbc if it is 
still open). He has already agreed to do so.


If you maintain one of the affected packages and you want me to handle 
rebuilds in the future, you can grant me privileges on the project; 
collaborator on the rawhide branch should be sufficient.


    - bloaty

    - credentials-fetcher

    - fcitx5-mozc

    - frr

    - ilbc

    - libphonenumber

    - mozc

    - plasma-dialer

    - qmlkonsole

    - spacebar

If you maintain one of the affected packages, you should find that you 
received this message directly (by BCC due to limitations on the number 
of CC recipients imposed by the devel mailing list).


[1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10

[2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1

[3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1

[4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/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

Re: Let's deprecate the %{pyproject_build_lib} macro... ?

[Ben Beasley]

Considering the rationale you’ve laid out, I don’t have any complaints 
about deprecating %{pyproject_build_lib}. I’m indifferent to the 
possible addition of a setuptools-specific macro, assuming the 
setuptools build directory is expected to stop changing frequently.


I tested the proposed replacements in a handful of packages that used 
%{pyproject_build_lib} (python-asyncpg, python-cmake-build-extension, 
python-cyipopt, and python-ezdxf). In python-cmake-build-extension, I 
need to run test executables from the build directory (admittedly an 
unusual situation), and removing %{pyproject_build_lib} actually 
simplified the spec file, since I no longer needed to consider a 
colon-separated list of *possible* build directories. The adjusted spec 
files for these packages worked as expected on F37–F39.


On 3/8/23 06:09, Miro Hrončok wrote:

Hello.

The %{pyproject_build_lib} macro is a *provisional* macro from 
pyproject-rpm-macros.


It was added to solve the problem of out-of-tree pip builds. From the 
pyproject-rpm-macros README:


"""
Sometimes, it is desired to be able to import the just-built extension 
modules in the %build section, e.g. to build the documentation with 
Sphinx.


  %build
  %pyproject_wheel
  ... build the docs here ...

With pure Python packages, it might be possible to set 
PYTHONPATH=${PWD} or PYTHONPATH=${PWD}/src. However, it is a bit more 
complicated with extension modules.


The location of just-built modules might differ depending on Python 
version, architecture, pip version, etc. Hence, the macro 
%{pyproject_build_lib} exists to be used like this:


  %build
  %pyproject_wheel
  PYTHONPATH=%{pyproject_build_lib} ... build the docs here ...
"""

When this macro was introduced, the built extension module lived in a 
folder like 
/builddir/build/BUILD/%{name}-%{version}/.pyproject-builddir/pip-req-build-/build/lib.linux-x86_64-3.10, 
hence it made sense to include in the pyproject-rpm-macros and call it 
%pyproject_something.




Today, on Rawhide, pip default to in-tree-builds and the value for 
extension modules will most likely be:


$PWD/build/lib.%{python3_platform}-cpython-%{python3_version_nodots}

And for pure Python:

  $PWD/build/lib

And it turns out, the value is setuptools-specific, see 
https://bugzilla.redhat.com/show_bug.cgi?id=2176393


Other build backends might store the built extension modules elsewhere 
or simply pack the pure Python files into wheel directly from the 
source tree.




In Rawhide, 41 packages use PYTHONPATH="%{pyproject_build_lib}" and 2 
packages have a comment with %%{pyproject_build_lib} in them.


Considering the macro

 - is not build-backend-agnostic, and
 - is not so much needed as it once was

I propose we deprecate it with no further fixes going in, but no 
scheduled removal.


The 41 packages can be fixed once Fedora 36 goes EOL by expanding the 
macro to the values above, or if desired, we could macronize this in 
pythohn3-setuptools as %{setuptools_build_lib}.



One problem is that the macro is unfortunately still needed on EL 9.


Thoughts?


___
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

License change: python-versioneer, python-ncclient

[Ben Beasley]

Since python-versioneer was updated to 0.28 in Rawhide, its license changed 
from Public Domain (which really should have been CC0-1.0) to Unlicense. This 
reflects an upstream relicensing decision in version 0.24.

While the comments in versioneer-generated _version.py files mention only that 
they are public-domain, the README.md file in versioneer makes it clear that 
these files should be considered to fall under the same license as the 
versioneer package.

Thus, for those few packages that use the *packaged* python-versioneer to 
generate a _version.py file, that file will change from CC0-1.0 to Unlicense, 
which could affect the package license. For this reason, the license of the 
python-ncclient package changes from Apache-2.0 AND CC0-1.0 to Apache-2.0 AND 
Unlicense.

There are still many packages that contain a _version.py generated by a bundled 
older version of versioneer.py, either during the RPM build process or when 
their upstream produced the source distribution archive to upload to PyPI. 
These may still be technically CC0-1.0 for many years, until their upstreams 
eventually update versioneer and issue new releases. I note this only for 
completeness and clarity; it is, as far as I can tell, not a problem.
___
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: flatbuffers 23.3.3 coming to F39/Rawhide and F38/Branched

[Ben Beasley]

In one week (2023-03-11), or slightly later, I plan to update 
flatbuffers to 23.3.3 in F39/Rawhide and F38/Branched[1]. This is an 
incompatible update because the libraries offer no ABI stability—the .so 
version is bumped to 23.3.3—and because the --proto option was removed 
from the flatc compiler.


This is now a “semi-leaf” package; hyperhdr BuildRequires 
flatbuffers-compiler for code generation, but does not link any 
flatbuffers library at runtime. I have verified that hyperhdr *can* be 
rebuilt with flatbuffers 23.3.3, but actually rebuilding it is optional.


[1] https://src.fedoraproject.org/rpms/flatbuffers/pull-request/6
___
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

Updating libbraiding from 1.1 to 1.2 in F39/Rawhide

[Ben Beasley]

In one week (2023-03-09), or slightly later, I plan to update libbraiding from 
1.1 to 1.2 in F39/Rawhide. Upstream says, “Minor changes for compatibility with 
newer C++.”
https://github.com/miguelmarco/libbraiding/compare/1.1...1.2

This is not supposed to be an incompatible update, and the .so version is 
unchanged, but there are changes to inline template functions that are used 
both inside and (potentially) outside the compiled library, and the compiled 
library loses several symbols as a result:

Comparing the ABI of binaries between libbraiding-1.1-14.fc38.x86_64.rpm and 
libbraiding-1.2-1.fc39.x86_64.rpm:

 changes of 'libbraiding.so.0.0.0'===
  Functions changes summary: 5 Removed, 0 Changed, 0 Added functions
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

  5 Removed functions:

[D] 'method bool 
CBraid::Factor::CompareWithDelta(CBraid::sint32) 
const'{_ZNK6CBraid6FactorINS_17ArtinPresentationEE16CompareWithDeltaEi}
[D] 'method bool 
CBraid::Factor::CompareWithIdentity() const'
{_ZNK6CBraid6FactorINS_17ArtinPresentationEE19CompareWithIdentityEv}
[D] 'method CBraid::Factor 
CBraid::Factor::Flip(CBraid::sint32) const'
{_ZNK6CBraid6FactorINS_17ArtinPresentationEE4FlipEi}
[D] 'function bool 
CBraid::MakeLeftWeighted(CBraid::Factor&,
 CBraid::Factor&)'
{_ZN6CBraid16MakeLeftWeightedINS_17ArtinPresentationEEEbRNS_6FactorIT_EES5_}
[D] 'function bool 
CBraid::MakeRightWeighted(CBraid::Factor&,
 CBraid::Factor&)'
{_ZN6CBraid17MakeRightWeightedINS_17ArtinPresentationEEEbRNS_6FactorIT_EES5_}

 end of changes of 'libbraiding.so.0.0.0'===
Therefore, for safety, I plan to build this for F39/Rawhide only, and I plan to 
coordinate a rebuild of sagemath (the sole dependent package) in a side tag.___
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: python-shapely 2.0.1 coming to Fedora Rawhide/39 (with updated License)

[Ben Beasley]

In one week (2023-03-02), or slightly later, I plan to update the 
python-shapely package from 1.8.5.post1 to 2.0.1 in Rawhide/F39 by 
merging the linked PR[1].


There are incompatible changes[2], but after some patching and some 
waiting for upstream releases, all dependent packages now build 
successfully in COPR[3], and I believe all upper-bounds on the Shapely 
version have been removed or loosened. No action by dependent package 
maintainers should be required; however, I am happy to help if you do 
encounter any problems.


The License field changes from BSD-3-Clause to (BSD-3-Clause AND 
Unlicense AND MIT). The Unlicense term comes from more careful 
consideration of the versioneer-generated file shapely/_version.py, and 
the MIT term comes from a new bundled source file that is a “copylib” 
from https://github.com/attractivechaos/klib.


I have no plans to build Shapely 2 for Fedora 38/Branched.

[1] https://src.fedoraproject.org/rpms/python-shapely/pull-request/9

[2] https://shapely.readthedocs.io/en/stable/migration.html

[3] https://copr.fedorainfracloud.org/coprs/music/shapely/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

Minor license changes in python-graph-tool 2.46

[Ben Beasley]

In python-graph-tool 2.46, the Python package contains a new module 
(src/graph_tool/collection/small.py) that contains code derived from the 
NetworkX library under the BSD-3-Clause license, but with modifications 
under LGPL-3.0-or-later. I have therefore assigned the SPDX expression 
LGPL-3.0-or-later AND BSD-3-Clause to this module, and the overall 
package License is updated from:


    LGPL-3.0-or-later AND BSL-1.0 AND GPL-3.0-or-later AND MIT AND (MIT 
OR Apache-2.0)


to:

    LGPL-3.0-or-later AND BSL-1.0 AND BSD-3-Clause AND GPL-3.0-or-later 
AND MIT AND (MIT OR Apache-2.0)


Additionally, as an improvement to the packaging, the 
python3-graph-tool-devel subpackage now has its own License tag. Because 
the base package’s License includes licenses of header-only (“static”) 
dependencies, but the -devel subpackage does not contain compiled 
binaries, its license does not need to contain terms for header-only 
dependencies (or for src/graph_tool/collection/small.py). Instead, it is 
simply:


    LGPL-3.0-or-later AND BSL-1.0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: providing gpg verification for a package without signature

[Ben Beasley]

“Where the upstream project publishes OpenPGP signatures of their releases, 
Fedora packages SHOULD verify that signature as part of the RPM build process.”

Most upstreams don’t sign their releases this way, so most Fedora packages 
don’t need to worry about it. If upstream did provide signatures, they would be 
published alongside the source archives.

> On Feb 26, 2023, at 11:02 AM, Globe Trotter via devel 
>  wrote:
> 
> Hello,
> 
> I have been trying to package slim again. The package does not come with a 
> signature or a gpg key. 
> 
> From 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification
>  I don't see an option of what to do if there is no signature provided. 
> 
> Any suggestions or pointers to where I can get guidance on this?
> 
> Thanks!
> ___
> 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