Re: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

[Vitaly Zaitsev via devel]

On 13/01/2025 10:11, Zbigniew Jędrzejewski-Szmek wrote:

First, this would require setting up the infrastructure to build and
store and distribute multiple builds of a single version of a
package. This is something that Fedora currently doesn't do, so it'd
require changes to operations in mock, koji, bodhi, the CI, mirrors.


Yes, but that would be better than storing 2x (or maybe 3x in the future 
for the v3 subarchitecture) binaries on each Fedora user's machine.


This will be very important especially for Server Edition, since disk 
space on host machines is very limited and the user *pays* for it.



Second, dnf would need to learn about this and install the appropriate
variant.


RPM and Zypper already support this feature:

https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847

https://github.com/openSUSE/libzypp/commit/fc151d82689c14635fd099f7b2f5a6e3ae698633

We need to port this functionality to dnf5.


Third, this choice would be "permanent", i.e. it would be done once at
package installation time. If the user tries to boot the same image
on different hardware, it might fail. This is inferior to the proposed
approach where the choice is made at runtime.


Yes. But user can do a simple chroot and use `dnf swap` for all 
unsupported packages. This is a trivial task.


Of course, the dnf5 package should not be optimized.


Fourth, this would actualy use more space. Most packages have only a
little bit of code and a lot of other files, so duplicating whole
packages to provide different variants of a few binaries would not
be space efficient.


Only on mirrors. I think it's ok since the number of these packages will 
be small.


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

Re: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

[Vitaly Zaitsev via devel]

On 13/01/2025 09:25, David Bold wrote:

No, 0.1 to 1 ms or 0.0001 to 0.001 seconds


Yeah, there's a font problem. I thought it was milli, not micro. After 
changing the default font it now looks better. Thanks.


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

Re: Need assistance to build Blender

[Michael J Gruber]

Got it to build (see dist-git/PR), but please make sure the result works ;)

Cheers
Michael

Luya Tshimbalanga venit, vidit, dixit 2025-01-13 18:19:07:
> Whoops,
> 
> 
> here is, https://koji.fedoraproject.org/koji/taskinfo?taskID=127824831
> 
> On 2025-01-13 00:17, Michael J Gruber wrote:
> > Luya Tshimbalanga venit, vidit, dixit 2025-01-12 22:30:03:
> >> On 2025-01-12 10:58, Sérgio Basto wrote:
> >>> On Sun, 2025-01-12 at 10:15 -0800, Luya Tshimbalanga wrote:
> 
>  Hello team,
> 
>  Blender failed to build due to an issue related to Python rules
>  changes and an additional
>     failure from this line:
> 
>  /builddir/build/BUILD/blender-4.3.2-build/blender-
>  4.3.2/source/blender/python/gpu/gpu_py_batch.cc:341:7: error: cannot
>  convert ‘const char*’ to ‘const char* const*’ in initialization
> 
> >>> is the gcc safety type warnings that now are error ?
> >>>
> >>> please try %global build_type_safety_c 0
> >>>
> >>> As wrote in "Controlling Type Safety" of
> >>> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md
> >>> the default now is 3 , you also mey try %global build_type_safety_c 1
> >>> and %global build_type_safety_c 2 .
> >>>
> >>> Best regards,
> >>>
> >> The error still happens. It seemed triggered after changing
> >>
> >> # Change from Python 3.13
> >> sed -i "s/_PyLong_AsInt/PyLong_AsInt/" \
> >>       source/blender/python/generic/py_capi_utils.hh
> >>
> >> the issues occurred on
> >>
> >> /builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/source/blender/python/generic/imbuf_py_api.cc:
> >> In function ‘PyObject* py_imbuf_resize(Py_ImBuf*, PyObject*, PyObject*)’:
> >> /builddir/build/BUILD/blender-4.3.2-build/blender-4.3.2/source/blender/python/generic/imbuf_py_api.cc:102:7:
> >> error: cannot convert ‘const char*’ to ‘const char* const*’ in
> >> initialization
> > So, you didn't just bump to 4.3.2 but applied other spec changes
> > already? In this case a link to your koji scratch build or putting your
> > changes on your dist-git fork would help us help you ;-)
> >
> > Cheers
> > \Michael
> >
> -- 
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 15 for Fedora 42 in a side-tag

[Björn Persson]

Björn Persson wrote:
> There seems to be a regression on S390x:
> 
> gprconfig --batch -o /dev/null --validate
> raised SYSTEM.OBJECT_READER.FORMAT_ERROR : 
> System.Object_Reader.ELF64_Ops.Initialize: unrecognized architecture
> Load address: 0x2aa1b38

This fresh commit is supposed to fix the problem:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=744a59f3f55bfc890f755c57c72919566e1bcad5

Any chance we can get that in before the mass rebuild?

Björn Persson


pgpef9B8o2fHz.pgp
Description: OpenPGP digital signatur
-- 
___
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: GCC 15 for Fedora 42 in a side-tag

[Jakub Jelinek]

On Tue, Jan 14, 2025 at 12:43:51PM +0100, Björn Persson wrote:
> Björn Persson wrote:
> > There seems to be a regression on S390x:
> > 
> > gprconfig --batch -o /dev/null --validate
> > raised SYSTEM.OBJECT_READER.FORMAT_ERROR : 
> > System.Object_Reader.ELF64_Ops.Initialize: unrecognized architecture
> > Load address: 0x2aa1b38
> 
> This fresh commit is supposed to fix the problem:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=744a59f3f55bfc890f755c57c72919566e1bcad5
> 
> Any chance we can get that in before the mass rebuild?

It is in https://koji.fedoraproject.org/koji/taskinfo?taskID=127856626
But when exactly it will finish depends on the build boxes, could be say 17
hours, could be 30.

Jakub

-- 
___
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: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

[Neal Gompa]

On Mon, Jan 13, 2025 at 6:06 AM Petr Pisar  wrote:
>
> V Sun, Jan 12, 2025 at 07:08:05PM -0500, Neal Gompa napsal(a):
> > On Sun, Jan 12, 2025 at 4:36 PM Chris Adams  wrote:
> > >
> > > Once upon a time, Neal Gompa  said:
> > > > For stuff installed into /usr, we
> > > > should just allow packages to be optionally built with the higher
> > > > microarchitecture level in addition to the base one and allow DNF to
> > > > sort and prefer packages accordingly.
> > >
> > > Is this not just resurrecting the old i386/i586/i686 RPM handling?  Is
> > > there a reason not to do it the same way again?
> >
> > Not that I know of. The logic is also already kind of there. The
> > x86_64 arch levels are supported as distinct architectures in RPM with
> > compatibility detection. openSUSE is already using this facility.
> >
> Could you point me to a documentation or an example of the SuSE
> implementation. So far I only found
>  and
>  which
> do not reveal how RPM and Zypper work with the architecture levels.
>

This was implemented in libzypp 17.31.9 in the following commits:

* 
https://github.com/openSUSE/libzypp/commit/6b1f606343554bdcd01f290c887b286122c0a2d2
* 
https://github.com/openSUSE/libzypp/commit/929743a8e5a3bcaf08e8a747c7a3b3fdcbcb

It seems to be relatively straightforward to support.



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 15 for Fedora 42 in a side-tag

[Sérgio Basto]

On Mon, 2025-01-13 at 11:45 +0100, Jakub Jelinek wrote:
> Hi!
> 
> With the Fedora 42 mass rebuild approaching, I've built gcc 15
> snapshot
> (and annobin/libtool) in the
> 
> f42-build-side-103300
> 
> side-tag.
> 
> Feel free to do scratch builds against this side-tag 


https://koji.fedoraproject.org/koji/taskinfo?taskID=127845969 again it
fails withh gcc15 but not with 14 on arch: ppc64le with VSX_
any idea ? 


[  1%] Building CXX object CMakeFiles/ade.dir/3rdparty/ade/ade-
0.1.2e/sources/ade/source/graph.cpp.o
/usr/bin/g++ -DVK_NO_PROTOTYPES -I/builddir/build/BUILD/opencv-4.11.0-
build/opencv-4.11.0/redhat-linux-build -I/usr/include/vulkan -
I/builddir/build/BUILD/opencv-4.11.0-build/opencv-4.11.0/redhat-linux-
build/3rdparty/ade/ade-0.1.2e/sources/ade/include -isystem
/usr/include/gdal -isystem /usr/include/coin -isystem
/usr/include/openblas -O2  -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-
cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-
cc1  -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -
fstack-clash-protection   -fsigned-char -W -Wall -Wreturn-type -Wnon-
virtual-dtor -Waddress -Wsequence-point -Wformat -Wformat-security -
Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -
Wsign-promo -Wuninitialized -Wsuggest-override -Wno-delete-non-virtual-
dtor -Wno-comment -Wimplicit-fallthrough=3 -Wno-strict-overflow -
fdiagnostics-show-option -pthread -fomit-frame-pointer -ffunction-
sections -fdata-sections  -fvisibility=hidden -fvisibility-inlines-
hidden -fopenmp -DNDEBUG  -DNDEBUG -std=c++17 -fPIC -MD -MT
CMakeFiles/ade.dir/3rdparty/ade/ade-
0.1.2e/sources/ade/source/graph.cpp.o -MF
CMakeFiles/ade.dir/3rdparty/ade/ade-
0.1.2e/sources/ade/source/graph.cpp.o.d -o
CMakeFiles/ade.dir/3rdparty/ade/ade-
0.1.2e/sources/ade/source/graph.cpp.o -c /builddir/build/BUILD/opencv-
4.11.0-build/opencv-4.11.0/redhat-linux-build/3rdparty/ade/ade-
0.1.2e/sources/ade/source/graph.cpp
duplicated: CLASS cv::.Algorithm : 
In file included from /builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/base.hpp:679,
 from /builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core.hpp:53,
 from /builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/utility.hpp:56,
 from /builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/src/precomp.hpp:53,
 from /builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/src/algorithm.cpp:43:
/builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/vsx_utils.hpp: In function
‘vec_float4 vec_cvfo(const vec_double2&)’:
/builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/vsx_utils.hpp:260:54: error:
‘__builtin_vsx_xvcvdpsp’ was not declared in this scope; did you mean
‘__builtin_vsx_xscvdpsp’?
  260 | VSX_REDIRECT_1RG(vec_float4,  vec_double2, vec_cvfo,
__builtin_vsx_xvcvdpsp)
  | 
^~
/builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/vsx_utils.hpp:102:43: note: in
definition of macro ‘VSX_REDIRECT_1RG’
  102 | VSX_FINLINE(rt) fnm(const rg& a) { return fn2(a); }
  |   ^~~
/builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/vsx_utils.hpp: In function
‘vec_double2 vec_cvfo(const vec_float4&)’:
/builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/vsx_utils.hpp:261:54: error:
‘__builtin_vsx_xvcvspdp’ was not declared in this scope; did you mean
‘__builtin_vsx_xscvspdp’?
  261 | VSX_REDIRECT_1RG(vec_double2, vec_float4,  vec_cvfo,
__builtin_vsx_xvcvspdp)
  | 
^~
/builddir/build/BUILD/opencv-4.11.0-build/opencv-
4.11.0/modules/core/include/opencv2/core/vsx_utils.hpp:102:43: note: in
definition of macro ‘VSX_REDIRECT_1RG’
  102 | VSX_FINLINE(rt) fnm(const rg& a) { return fn2(a); }



> if you want
> to test whether something builds fine with GCC 15 (David Malcolm has
> performed a mass prebuild with earlier version of GCC 15, filed
> various
> bugs and will post a summary).  And, if there are packages which need
> to be
> rebuilt against GCC 15 before the mass rebuild (like packages using
> Ada),
> feel free to build them into the side-tag.
> 
>   Jakub
> 

-- 
Sérgio M. B.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List G

Convention for naming patches

[Vít Ondruch]

Hi,

Is there any convention for naming patches? I mildly remember that there 
used to be some guideline suggesting form such as 
`pagkage-name-version-description-of-patch.patch`. But I was not able to 
find this codified in guidelines.



Vít



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

Re: F42 Change Proposal: RPM Support For Systemd Sysusers.d (system-wide)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 13, 2025 at 02:02:33PM +0100, Iker Pedrosa wrote:
> Which shadow-utils upstream ticket?

https://github.com/shadow-maint/shadow/issues/940

> I've long wanted to get rid of the patch we have in Fedora for shadow
> audit, either by including it upstream or removing it altogether, but I'm
> afraid it may affect our user's systems. Maybe this FSWC will be the
> trigger for such a change.

This is separate topic. Anyway, based on what Steve wrote, the patch
cannot be removed.

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

Re: Unresponsive packager: pvoborni

[Fraser Tweedale]

I removed Petr as a maintainer of rpms/ipa-hcc.

Thanks,
Fraser
-- 
___
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: SDL2_sound

[Dominik 'Rathann' Mierzejewski]

Hello!
As part of updating SDL2_sound to 2.0.4, I reviewed the licensing of the
code and the full license is now:
Zlib AND LGPL-2.1-or-later AND ( MIT OR Unlicense ) AND 
LicenseRef-Fedora-Public-Domain

Before, it was:
Zlib AND LicenseRef-Callaway-LGPLv2+

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan
-- 
___
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: F42 Change Proposal: RPM Support For Systemd Sysusers.d (system-wide)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 10, 2025 at 04:21:56PM -0500, Steve Grubb wrote:
> On Friday, January 10, 2025 10:20:07 AM EST Zbigniew Jędrzejewski-Szmek 
> wrote:
> > https://github.com/systemd/systemd/pull/35957

> Thanks. It just occurred to me that upstream shadow-utils has kinda broken 
> auditing. The way that audit events get parsed is looking for name=value 
> keyword pairs. Anything else gets thrown away. So, in cases of "op=adding 
> group", only "adding" is kept. The fix for this is to replace the space with 
> either a dash or underscore. Then the audit tools will see adding-group as 
> one word and keep it.
> 
> This little detail is important when testing with
> 
> ausearch --start recent -m ADD_USER --format text
> ausearch --start recent -m ADD_USER --format csv
> 
> I see that f41 and rawhide are OK because of a patch fedora is carrying. But 
> upstream shadow-utils has a problem.
> 
> Would you mind adding a small patch on top of your patch that adds a dash 
> between words for the operation? Check it with the format text option above. 
> It should make sense as an English sentence. I'll have to figure out what to 
> do with upstream shadow-utils. Unless other distros applies fedora's patch, 
> they have a somewhat broken audit trail around the user account lifecycle.

I reworked the PR significantly based on the comments.
PTAL again.

The log now is:
type=ADD_GROUP msg=audit(01/14/2025 11:40:36.144:6837) : pid=1206846 uid=root 
auid=zbyszek ses=2 msg='op=adding-group acct=foo6 exe=systemd-sysusers 
hostname=x1c addr=? terminal=pts/10 res=success' 
type=ADD_USER msg=audit(01/14/2025 11:40:36.145:6838) : pid=1206846 uid=root 
auid=zbyszek ses=2 msg='op=adding-user acct=foo6 exe=systemd-sysusers 
hostname=x1c addr=? terminal=pts/10 res=success' 

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

Re: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

[Panu Matilainen]

On 1/13/25 11:07 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Jan 13, 2025 at 12:10:44PM +0100, Jakub Jelinek wrote:

On Mon, Jan 13, 2025 at 09:11:35AM +, Zbigniew Jędrzejewski-Szmek wrote:

First, this would require setting up the infrastructure to build and
store and distribute multiple builds of a single version of a
package. This is something that Fedora currently doesn't do, so it'd
require changes to operations in mock, koji, bodhi, the CI, mirrors.


We've been building packages like that for years, so I don't understand
how it would require changes.  E.g. we had glibc.i386 and glibc.i686, when
glibc was built, it was built for both of those architectures and rpm/yum
chose the right one.


I think this functionality stopped being used ages ago. At least a
decade, but I think more. So it seems unlikely that it'd work out of the
box.


Second, dnf would need to learn about this and install the appropriate
variant.


I think it should have that support like it had for i686 vs. i386.


That probably was yum. Then we had dnf4, and now we have dnf5.
The folks who work on dnf and rpm should comment, but I expect that
this functionality either has been removed or is completely bitrotted.


I don't know about dnf5 but at least the rpm-side functionality very 
much still exists and is used by some distros. We just recently 
introduced the x86_64 subarchitecture support in rpm.


- Panu -

--
___
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: Unresponsive packager: pvoborni

[Pierre-Yves Chibon]

On Mon, Jan 13, 2025 at 02:19:25PM +0200, Alexander Bokovoy wrote:
> On Пан, 13 сту 2025, Pierre-Yves Chibon wrote:
> > On Mon, Jan 13, 2025 at 11:41:07AM +0200, Alexander Bokovoy wrote:
> > > On Пан, 13 сту 2025, Pierre-Yves Chibon wrote:
> > > > Good Morning Everyone,
> > > >
> > > > We have been emailing daily the following user to notify that the email 
> > > > they
> > > > have set in FAS does not correspond to a valid bugzilla account.
> > > > This is a requirement for Fedora packagers.
> > > >
> > > > Does someone know how to contact them?
> > > 
> > > Petr has left Red Hat at the end of November 2024.
> > > 
> > > It looks like he is not going to continue working on the packages below.
> > > 
> > > > pvoborni - emailed since November 19th
> > > >
> > > > pvoborni is maintainer of rpms/bind-dyndb-ldap
> > > > pvoborni is maintainer of rpms/freeipa
> > > > pvoborni is maintainer of rpms/freeipa-healthcheck
> > > > pvoborni is maintainer of rpms/ipa-hcc
> > > > pvoborni is maintainer of rpms/mrack
> > > > pvoborni is maintainer of rpms/open-sans-fonts
> > > > pvoborni is maintainer of rpms/ttembed
> > > 
> > > I own or maintain at least half of the packages above. For all the
> > > packages there are other people who are designated as 'main admins', so
> > > we aren't going to lose those packages.
> > 
> > The issue is that the mismatch in email addresses prevents syncing default
> > assignee and CC list from src.fp.o to bugzilla, for the all the packages 
> > where
> > Petr is.
> > 
> > Should I just ask Fesco to remove his access (or can you/your team do it?)?
> 
> I'll ask the team today, thank you for the note.

Thanks, it looks like there are only 2 lefts:
pvoborni is maintainer of rpms/ipa-hcc
pvoborni is maintainer of rpms/mrack

Thanks again! :)

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

[Cristian Le via devel]

If anyone knows how to contact  sham1, please let me know. I've sent an email 
to his/her personal email but haven't got a response. The pull request has been 
unreviewed for more than 3 
weeks:https://src.fedoraproject.org/rpms/maildir-utils/pull-request/9


I don't know sham1, but I presume you have tried to contact via email 
and mastodon as found in the Fas page [1] and Github profile [2]? I 
remember that mastodon can be finicky with displaying federated content 
(if you are in a different server you do not see the same reply feed as 
the user), but I don't know if it extends to DMs as well.


Anyway, I wanted to primarily correct you on the CC address where you 
tried to use @fedoraproject.org. Afaiu that is not/no longer a 
thing. Instead you should use -maintain...@fedoraproject.org, 
e.g. in your case it is maildir-utils-maintain...@fedoraproject.org.


[1]: https://accounts.fedoraproject.org/user/sham1/
[2]: https://github.com/sham1
-- 
___
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: Convention for naming patches

[Daniel P . Berrangé]

On Tue, Jan 14, 2025 at 11:36:59AM +0100, Vít Ondruch wrote:
> Hi,
> 
> Is there any convention for naming patches? I mildly remember that there
> used to be some guideline suggesting form such as
> `pagkage-name-version-description-of-patch.patch`. But I was not able to
> find this codified in guidelines.

IMHO if there are enough patches that maintainers are starting to think
about naming conventions, then the patches are best maintained as a
branch in source-git. At that point the naming convention question is
solved by delegating the problem to 'git format-patch', which derives
a filename from the commit first line.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

-- 
___
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: GCC 15 for Fedora 42 in a side-tag

[Jakub Jelinek]

On Tue, Jan 14, 2025 at 12:33:55PM +, Sérgio Basto wrote:
> On Mon, 2025-01-13 at 11:45 +0100, Jakub Jelinek wrote:
> > Hi!
> > 
> > With the Fedora 42 mass rebuild approaching, I've built gcc 15
> > snapshot
> > (and annobin/libtool) in the
> > 
> > f42-build-side-103300
> > 
> > side-tag.
> > 
> > Feel free to do scratch builds against this side-tag 
> 
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=127845969 again it
> fails withh gcc15 but not with 14 on arch: ppc64le with VSX_
> any idea ? 

See https://gcc.gnu.org/r15-1919 and
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649747.html
In short, for intrinsics on the various architectures, the supported API
are the intrinsics declared in the header, not the underlying builtin
functions, which can be added/removed as needed, those are just
implementation details how to implement those intrinsics.
opencv is clearly using a builtin directly, don't.

That said, I don't know much about the VSX intrinsics, for vector
conversions there is also __builtin_convertvector (both in GCC and LLVM)
which allows to say convert a vector of floats to vector of doubles or vice
versa.

In any case, I think raise this upstream and if they don't know what to do,
get them talk to the author of those changes.

Jakub

-- 
___
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: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

[Stephen Smoogen]

On Mon, 13 Jan 2025 at 16:08, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Mon, Jan 13, 2025 at 12:10:44PM +0100, Jakub Jelinek wrote:
> > On Mon, Jan 13, 2025 at 09:11:35AM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > First, this would require setting up the infrastructure to build and
> > > store and distribute multiple builds of a single version of a
> > > package. This is something that Fedora currently doesn't do, so it'd
> > > require changes to operations in mock, koji, bodhi, the CI, mirrors.
> >
> > We've been building packages like that for years, so I don't understand
> > how it would require changes.  E.g. we had glibc.i386 and glibc.i686,
> when
> > glibc was built, it was built for both of those architectures and rpm/yum
> > chose the right one.
>
> I think this functionality stopped being used ages ago. At least a
> decade, but I think more. So it seems unlikely that it'd work out of the
> box.
>


I think there is a gap in communication in this paragraph which may lead to
a lot more confusion. You say that you think the functionality stopped
being used a decade ago, but people have been pointing out that 'it' is
being used in SuSE and other distros. Are we talking about two different
functionalities which have been lost in the pronouns?
-- 
___
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

Looking for maintainer of bc and SFML

[Sérgio Basto]

Hi, 

I adopt bc and SFML [3] to avoid one mass removing of packages some
time ago , these two packages have some dependencies , but I'm not very
familiar with them 

Recently an user , ask me to consider "Consider switching gnub-bc to
howard-bc"[1] and [2] and change from gcc to clang .

Anyone can me advice what to do ? I don't have much time and I'd like
focus on other packages 

Best regards,


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

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

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

Re: Convention for naming patches

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 14, 2025 at 11:36:59AM +0100, Vít Ondruch wrote:
> Hi,
> 
> Is there any convention for naming patches? I mildly remember that there
> used to be some guideline suggesting form such as
> `pagkage-name-version-description-of-patch.patch`. But I was not able to
> find this codified in guidelines.

Coordinated naming of patches (and sources, and other files) used to
matter when people dumped them in a shared directory like
~/rpmbuild/SOURCES/. I really really hope nobody does that anymore.

When files are stored in individual directories, in the usual dist-git
layout, then the naming is up to the maintainers. In particular,
-description-with-dashes.patch is often used, since this is
what 'git format-patch' generates. But there is no need for guidlines
to prescribe any naming.

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

Re: Fedora eln compose report: 20250112.n.0 changes

[Miro Hrončok]

On 12. 01. 25 4:59, Fedora ELN Report wrote:

Added packages:  267


Hi. What happened here? I cannot find the newly added packages in the content 
resolver.


Are those packages from ELN Extras?

--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok

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

Re: Schedule for Tuesday's FESCo Meeting (2025-01-14)

[Stephen Gallagher]

Quick summary:

We discussed the mass-update of packages to use `git-core` instead of
`git` for dependencies. We agreed that merge requests may be
mass-submitted and that a provenpackager (zbyszek) will merge them
after four weeks of inactivity. MRs can be merged by the maintainer
before then or rejected if appropriate.

We also discussed the report to be sent to the Fedora Council
regarding the recent provenpackager issue and have approved our
internal report. It will be delivered to the Council by the FESCo
Liaison, David Cantrell in the near future.

Lastly, we briefly discussed performance of Fedora Infrastructure,
praising the improvement in s390x builder availability and noting that
performance issues in ppc64le systems are being investigated.



=
# #meeting:fedoraproject.org: fesco
=

Meeting started by @fale:fale.io at 2025-01-14 17:01:26



Meeting summary
---
* TOPIC: Init Process (@sgallagh:fedora.im, 17:01:43)
* TOPIC: #3320 Change: Switch to git-core (@sgallagh:fedora.im, 17:06:50)
* AGREED: Change is approved with the clarification that a proven
packager will merge all the pull requests which remain unanswered
after 4 weeks. (+6, 0, -0) (@sgallagh:fedora.im, 17:19:44)
* INFO: I'm volunteering be the provenpackager in question.
(@zbyszek:fedora.im, 17:20:14)
* INFO: Change proposal needs updating to include information
about the pull request deadline (@sgallagh:fedora.im, 17:20:33)
* ACTION: zbyszek to handle merging MRs after four weeks
(@sgallagh:fedora.im, 17:20:58)
* TOPIC: Next Week's Chair (@sgallagh:fedora.im, 17:21:36)
* ACTION: nirik to chair 2025-01-21 meeting (@sgallagh:fedora.im, 17:24:56)
* TOPIC: Open Floor (@sgallagh:fedora.im, 17:25:01)
* AGREED: we ask dcantrell as the FESCO liaison to convey the
report about provenpackager work to Council (+7, 0, -0)
(@sgallagh:fedora.im, 17:41:13)

Meeting ended at 2025-01-14 17:58:54

Action items

* zbyszek to handle merging MRs after four weeks
* nirik to chair 2025-01-21 meeting

People Present (lines said)
---
* @sgallagh:fedora.im (57)
* @zbyszek:fedora.im (25)
* @conan_kudo:matrix.org (23)
* @nirik:matrix.scrye.com (20)
* @decathorpe:fedora.im (9)
* @zodbot:fedora.im (9)
* @humaton:fedora.im (7)
* @fale:fale.io (5)
* @blc:fedora.im (3)
* @meetbot:fedora.im (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: Convention for naming patches

[Vít Ondruch]

Dne 14. 01. 25 v 16:21 Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, Jan 14, 2025 at 11:36:59AM +0100, Vít Ondruch wrote:

Hi,

Is there any convention for naming patches? I mildly remember that there
used to be some guideline suggesting form such as
`pagkage-name-version-description-of-patch.patch`. But I was not able to
find this codified in guidelines.

Coordinated naming of patches (and sources, and other files) used to
matter when people dumped them in a shared directory like
~/rpmbuild/SOURCES/.



Yes, I remember something like this was the reason. But not sure if this 
was just verbally shared knowledge or if there was any official guideline.




I really really hope nobody does that anymore.



I have no hopes ;)




When files are stored in individual directories, in the usual dist-git
layout, then the naming is up to the maintainers. In particular,
-description-with-dashes.patch is often used, since this is
what 'git format-patch' generates. But there is no need for guidlines
to prescribe any naming.



But the opposite guideline, such as "there is no official patch naming 
convention, feel free to use whatever works for you" would also help 😇



Vít




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

tree-sitter build broke Emacs

[Jerry James]

Emacs is uninstallable in Rawhide due to a tree-sitter soname bump.
Are the tree-sitter maintainers planning to rebuild (quickly!) the
broken dependencies soon?  The mass rebuild is about to start...
-- 
Jerry James
http://www.jamezone.org/
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora eln compose report: 20250112.n.0 changes

[Yaakov Selkowitz]

On 1/14/25 08:41, Miro Hrončok wrote:

On 12. 01. 25 4:59, Fedora ELN Report wrote:

Added packages:  267


Hi. What happened here? I cannot find the newly added packages in the 
content resolver.


Are those packages from ELN Extras?


Yes, ELN and ELN Extras are composed together.  In this case, this was 
the result of fixing a couple workloads that were broken before everyone 
went on break, and just got fixed now that people are back.  Due to the 
way Content Resolver works, when workloads are broken with Errors, then 
that workload is skipped and its packages may fall off of CR's results 
(unless they are dependencies of other workloads).  Consequently, when 
the workload is fixed, the packages are "re-added" from CR's perspective 
(and hence the Extras repo).


--
Yaakov Selkowitz
Principal Software Engineer, Emerging RHEL
Red Hat, Inc.

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

rawhide metadata change

[Kevin Fenzi via devel-announce]

Greetings.

Last year, as part of 
https://fedoraproject.org/wiki/Changes/ChangeComposeSettings
we were going to change rawhide (and then f41) repo metadata to use the
new upstream createrepo_c default (zstd). 

We unfortunately had to partially back this change out because at the
time there were still consumers using older OSes (in particular rhel7)
that were unable to handle the repodata.

We are going to switch rawhide back on the next compose.

RHEL8/9 dnf can handle this repodata fine, however, if you use
mergerepo_c or the like you may need to use 
https://copr.fedorainfracloud.org/coprs/amatej/createrepo_c/
until createrepo_c is updated.

kevin


signature.asc
Description: PGP signature
-- 
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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: Looking for maintainer of bc and SFML

[Stephen Smoogen]

On Tue, 14 Jan 2025 at 09:38, Sérgio Basto  wrote:

> Hi,
>
> I adopt bc and SFML [3] to avoid one mass removing of packages some
> time ago , these two packages have some dependencies , but I'm not very
> familiar with them
>
> Recently an user , ask me to consider "Consider switching gnub-bc to
> howard-bc"[1] and [2] and change from gcc to clang .
>
> Anyone can me advice what to do ? I don't have much time and I'd like
> focus on other packages
>
>
Moving from one bc to another isn't as easy as the requester may think.
There are a lot of sysadmin scripts which use bc in all kinds of places and
if they are using the math additions, it can break anything from a school
computer accounting system (*cough*) to other things. I would say that the
person should look at packaging up the other bc as an alternative but stay
with what is there for basic installs. [And I can be added as a
comaintainer if that would help you.]



> Best regards,
>
>
> [1]
> https://src.fedoraproject.org/rpms/bc/pull-request/6
>
> [2]
> https://bugzilla.redhat.com/show_bug.cgi?id=2308672
>
> [3]
> https://src.fedoraproject.org/rpms/SFML
> --
> Sérgio M. B.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Carlos Rodriguez-Fernandez]

I took the golang cgroup ones, since I'm familiarized with it, as well 
as with golang. Also trying to start getting into golang packages.


On 1/14/25 5:00 PM, maxwell--- via devel-announce wrote:

olang(github.com/containerd/containerd/cio) = 1.6.23-1.fc41, 
golang(github.com/containerd/containerd/containers) = 1.6.23-1.fc41, 
golang(github.com/containerd/containerd/content) = 1.6.23-1.fc41, 
golang(github.com/containerd/containerd/content/local) = 1.6.23-1.fc41, golang(


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

Re: F42 Change Proposal: RPM Support For Systemd Sysusers.d (system-wide)

[Steve Grubb]

Hello,

Zbigniew, thanks for updating the audit events.

On Tuesday, January 14, 2025 5:56:01 AM EST Zbigniew Jędrzejewski-Szmek 
wrote:
> On Mon, Jan 13, 2025 at 02:02:33PM +0100, Iker Pedrosa wrote:
> 
> > Which shadow-utils upstream ticket?
> 
> https://github.com/shadow-maint/shadow/issues/940
> 
> > I've long wanted to get rid of the patch we have in Fedora for shadow
> > audit, either by including it upstream or removing it altogether, but
> > I'm afraid it may affect our user's systems. Maybe this FSWC will be the
> > trigger for such a change.
> 
> This is separate topic. Anyway, based on what Steve wrote, the patch
> cannot be removed.

Right. But I see a possible minimal patch to  fix it.

https://github.com/shadow-maint/shadow/blob/master/lib/audit_help.c#L59

This ^^^ function logs all audit events, In all cases what needs to be fixed 
is the op field. There could be a patch for that function that looks for white 
spaces in the op field and replaces it with a hyphen. Then all that's left is 
reviewing that their op fields throughout the code haven't diverged from our 
patch.

I'll look into sending them a patch to fix the first issue. Reviewing all 
events will take longer to get to.

-Steve


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

Re: Looking for maintainer of bc and SFML

[Benjamin Calderon]

So... I've been lurking for a bit and haven't even introduced myself to the dev 
mailing list, but I'm certainly interested in SFML. I just looked at the spec 
file for the library and looks understandable enough, so if you don't mind a 
little hand holding I'd love to look into that!

I'm also aware that sfml released version 3 so Idk if that would be a better 
package or part of maintaining sfml would include updating sfml to v3.

At any rate, I'm gonna test my rpm and fedora knowledge attempting to build the 
spec file locally and... well, TBH, Idk what's next or if my offering to help 
might actually be more work for you! :-D 

Either way, I do have interest in sfml and I'm available to help in any way I 
can :-)
-- 
___
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: Convention for naming patches

[Neal Gompa]

On Tue, Jan 14, 2025 at 1:29 PM Vít Ondruch  wrote:
>
>
> Dne 14. 01. 25 v 16:21 Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Tue, Jan 14, 2025 at 11:36:59AM +0100, Vít Ondruch wrote:
> >> Hi,
> >>
> >> Is there any convention for naming patches? I mildly remember that there
> >> used to be some guideline suggesting form such as
> >> `pagkage-name-version-description-of-patch.patch`. But I was not able to
> >> find this codified in guidelines.
> > Coordinated naming of patches (and sources, and other files) used to
> > matter when people dumped them in a shared directory like
> > ~/rpmbuild/SOURCES/.
>
>
> Yes, I remember something like this was the reason. But not sure if this
> was just verbally shared knowledge or if there was any official guideline.
>
>
> > I really really hope nobody does that anymore.
>
>
> I have no hopes ;)
>
>
> >
> > When files are stored in individual directories, in the usual dist-git
> > layout, then the naming is up to the maintainers. In particular,
> > -description-with-dashes.patch is often used, since this is
> > what 'git format-patch' generates. But there is no need for guidlines
> > to prescribe any naming.
>
>
> But the opposite guideline, such as "there is no official patch naming
> convention, feel free to use whatever works for you" would also help 😇
>

I personally use a numbering scheme to split up backports, proposed
upstream changes, and downstream only changes.

Usually, 0001~0500 are upstream backports, 0501~1000 are proposed
changes, and 1001+ are downstream only.

Occasionally, I explicitly do not use git-am formatted filenames for
downstream patches because they are never intended for upstreaming and
I like tracking the package name+version they were written/updated to.

I refuse to use source-git, as I find it problematic, but I use "-S
git_am" to apply patches since I get bisectable trees when I need to
debug things.



-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Convention for naming patches

[Tomasz Torcz]

On Tue, Jan 14, 2025 at 11:36:59AM +0100, Vít Ondruch wrote:
> Hi,
> 
> Is there any convention for naming patches? I mildly remember that there
> used to be some guideline suggesting form such as
> `pagkage-name-version-description-of-patch.patch`. But I was not able to
> find this codified in guidelines.

  I recollect such naming rule, too. But I cannot find it in guidelines
now. Maybe that was a rule in `rpmlint`?

  Anyway, even if there is such rule, it is not easily googlable or
written in naming guidelines in Fedora docs. So we can assume it does
not exist.

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen

-- 
___
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: Fedora 42 Mass Rebuild Notification - Scheduled for 2025-01-15

[Alexander Ploumistos]

On Tue, Jan 14, 2025 at 8:38 AM Jednorozec  wrote:
>
> Yes, that is the list. Sometimes, maintainers or change owners required 
> packages to be omitted from the current mass rebuild.
> The noautobuild file is used for packages that should never be mass rebuilt.

Great, thank you for the information.
-- 
___
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