Re: FailsToInstall bugs, can we have it enable on EPEL branches ?
On 21. 09. 24 20:00, Sérgio Basto wrote: Hello, On Sat, 2024-09-21 at 10:03 +, bugzi...@redhat.com wrote: Hello, Please note that this comment was generated automatically by https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py Have this scripts running on EPEL branches would help me detect FTI more quickly , instead be users reporting it Best regards, We probably could. It runs against the koji repos, so as long as it does not want to report bugzillas for RHEL content, it should work. -- 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
abrt to be retired from F41 one week before the final freeze
Hello, according to the policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs The abrt package will be retired one week before the Fedora 41 final freeze, due to https://bugzilla.redhat.com/show_bug.cgi?id=2295150 Are we ready to ditch abrt, or is somebody planning to solve this (e.,g. by dropping the python3-abrt-container-addon subpackage only)? -- 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: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"
On 06. 09. 24 10:49, Miroslav Suchý wrote: churchyard pypy pypy3.10 pypy3.9 python3.13 Huh? pypy uses a license that is valid old license identifier not listed in Fedora-license-data. But python3.13? Is it because the license is macronized? -- 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: pyliblo3 - build on rawhide fails
On 04. 09. 24 16:35, Martin Gansser wrote: this patch solves the problem:: --- a/pyliblo3/_liblo.pyx +++ b/pyliblo3/_liblo.pyx @@ -271,7 +271,7 @@ cdef int _msg_callback(const_char *path, const_char *types, lo_arg **argv, elif t == 'm': v = (argv[i].m[0], argv[i].m[1], argv[i].m[2], argv[i].m[3]) elif t == 't': v = _timetag_to_double(argv[i].t) elif t == 'b': -v = bytes(lo_blob_dataptr(argv[i])) +v = bytes(lo_blob_dataptr(argv[i])) else: v = None # unhandled data type Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=2248131#c5 -- 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: pyliblo3 - %python3 setup.py test fails
On 29. 08. 24 15:45, Martin Gansser wrote:
i attached spec file and log messages, hope it helps.
[1] https://martinkg.fedorapeople.org/ErrorReports/pyliblo3.spec
[2] https://martinkg.fedorapeople.org/ErrorReports/pyliblo3-build-mess.txt
[3] https://martinkg.fedorapeople.org/ErrorReports/rpm-tmp.894bVx
If you move the pyliblo3 directory out of the way whenr unning tests lie this,
does it help?
%check
mv pyliblo3 pyliblo3_dont
%{py3_test_envvars} %{python3} -m unittest discover
Or if you invoke Python with -P?
%check
%{py3_test_envvars} %{python3} -P -m unittest discover
--
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: pyliblo3 - %python3 setup.py test fails
On 29. 08. 24 15:07, Martin Gansser wrote: I get the same error message with both commands: + PATH=/home/martin/rpmbuild/BUILDROOT/pyliblo3-0.16.2-0.3.git91d1781.fc40.x86_64/usr/bin:/usr/local/cuda/bin:/usr/local/cuda/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/martin/.local/bin:/home/martin/bin + PYTHONPATH=/home/martin/rpmbuild/BUILDROOT/pyliblo3-0.16.2-0.3.git91d1781.fc40.x86_64/usr/lib64/python3.12/site-packages:/home/martin/rpmbuild/BUILDROOT/pyliblo3-0.16.2-0.3.git91d1781.fc40.x86_64/usr/lib/python3.12/site-packages + PYTHONDONTWRITEBYTECODE=1 + PYTEST_ADDOPTS=' --ignore=/home/martin/rpmbuild/BUILD/pyliblo3-91d17815b911ccc2c1d1408412e7885c32f2d460/.pyproject-builddir' + PYTEST_XDIST_AUTO_NUM_WORKERS=2 + /usr/bin/python3 -m unittest discover E == ERROR: pyliblo3 (unittest.loader._FailedTest.pyliblo3) -- ImportError: Failed to import test module: pyliblo3 Traceback (most recent call last): File "/usr/lib64/python3.12/unittest/loader.py", line 429, in _find_test_path package = self._get_module_from_name(name) File "/usr/lib64/python3.12/unittest/loader.py", line 339, in _get_module_from_name __import__(name) File "/home/martin/rpmbuild/BUILD/pyliblo3-91d17815b911ccc2c1d1408412e7885c32f2d460/pyliblo3/__init__.py", line 18, in from ._liblo import * ModuleNotFoundError: No module named 'pyliblo3._liblo' If you need help, please share the full spec file and full build log. -- 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: pyliblo3 - %python3 setup.py test fails
On 29. 08. 24 14:16, Martin Gansser wrote:
%{py3_test_envvars}
%{python3} -m unittest discover
Put that on a single line like this:
%{py3_test_envvars} %{python3} -m unittest discover
Or export it, like this:
export %{py3_test_envvars}
%{python3} -m unittest discover
--
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: pyliblo3 - %python3 setup.py test fails
On 29. 08. 24 10:53, Martin Gansser wrote:
Hi,
i want to use %python3 setup.py test [1] with pyliblo3, but this fails.
Running setup.py test is deprecated and even if it worked, please don't use it.
For this package, I think this should work:
%check
%{py3_test_envvars} %{python3} -m unittest discover
--
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: [SPDX] Mass license change - batch #3 of all remaining packages
On 28. 08. 24 11:53, Miroslav Suchý wrote: Here is the third and last batch of changes for 972 packages (perl-JSON-Create to 0ad-data) https://miroslav.suchy.cz/fedora/rest-of-callaway-batch3.diff Shorten version without the context is here: https://miroslav.suchy.cz/fedora/rest-of-callaway-batch3-short-diff.txt I will appreciate a review. If there will be no issue I will commit and push this to dist-git in a week. Please exclude pythran: https://src.fedoraproject.org/rpms/pythran/pull-request/31 Also, could you please send a plain list of packages you plan to change, so I can run it trough find-package-maintainers and see the list of packages that I co-maintain? (Or just share the output of find-package-maintainers yourself.) Thanks, -- 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: Pyliblo3 fails to build on Fedora 41 with python 3.13.0
On 27. 08. 24 11:57, Martin Gansser wrote: This is about the pyliblo3 package. I have found that the pyliblo3/_liblo.c file needs to be deleted before the actual build and therefore no patch is required. I will post a new rpm package in the review. That would be https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_using_cython """ Tightening the general Fedora policy, packages MUST NOT use files pre-generated by Cython. These MUST be deleted in %prep and regenerated during the build. """ -- 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: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On 12. 04. 24 23:52, Aoife Moloney wrote: Wiki - https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 Discussion.fpo - https://discussion.fedoraproject.org/t/f41-change-proposal-python-built-with-gcc-03-self-contained/112743 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Instead of [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags Fedora's default `-O2` compiler flag], we will use `-O3` to build CPython. This only impacts the interpreter and Python standard library, not any 3rd party extension modules built as RPM or on developer machines. This aligns with the way Python is built upstream. According to our performance measurements, it makes Python significantly faster (pyperformance geometric mean: 1.04x faster). ...snip... # Amendment: Flag for user-built extension modules When this change was originally proposed, the expectation was that the C flags for building Python extension modules other than modules from the Python standard library would not be changed. * Python extension modules built in Fedora RPM packages were built with `-O2` before this change and would continue to be built that way (for packages other than Python itself). * Python extension modules built outside of Fedora RPM packages were built with no `-O` flag before this change and would continue to be built that way. However, after implementing the change proposal, it was accidentally changed so the **Python extension modules built outside of Fedora RPM packages are built with the `-O3` flag**. This was not originally intended, yet the change owners believe we should keep it that way because it makes Fedora's Python closer to upstream Python and because it makes Fedora more competitive with other platforms on CIs and similar systems. For more details, see https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/2IXTGNASAVR3NNHKFCOIC27CMFA6RJRH/ --- I am asking FESCo to approve this amendment in https://pagure.io/fesco/issue/3260 -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ 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: Disabling extra subpackages wallpaper for Fedora 41
On 13. 08. 24 1:31, Luya Tshimbalanga wrote:
Hello spin maintainers,
As the subpackage wallpaper i.e. fxx-extras-{gnome,kde,mate,budgie} series,
are stale for a while since at least Fedora 30, I would like to disable it for
Fedora 41 so the default
wallpaper is the only active package. If there is an objection for the change,
let it know.
What's the motivation for disabling it?
If they are stale, maybe we can move them to a package that is not
Fedora-versioned?
--
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: file '/usr/lib64/carla/libcarla_frontend.so' contains an invalid runpath
On 07. 08. 24 9:35, Martin Gansser wrote: HI, when I compile Carla [1] in Fedora 40, I get the following error messages at the end. + /usr/lib/rpm/check-rpaths *** * * WARNING: 'check-rpaths' detected a broken RPATH OR RUNPATH and will cause * 'rpmbuild' to fail. To ignore these errors, you can set the * '$QA_RPATHS' environment variable which is a bitmask allowing the * values below. The current value of QA_RPATHS is 0x. * *0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor * issue but are introducing redundant searchpaths without * providing a benefit. They can also cause errors in multilib * environments. *0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute * nor relative filenames and can therefore be a SECURITY risk *0x0004 ... insecure RPATHs; these are relative RPATHs which are a * SECURITY risk *0x0008 ... the special '$ORIGIN' RPATHs are appearing after other * RPATHs; this is just a minor issue but usually unwanted *0x0010 ... the RPATH is empty; there is no reason for such RPATHs * and they cause unneeded work while loading libraries *0x0020 ... an RPATH references '..' of an absolute path; this will break * the functionality when the path before '..' is a symlink * * * Examples: * - to ignore standard and empty RPATHs, execute 'rpmbuild' like * $ QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild my-package.src.rpm * - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like * $ RPM_BUILD_ROOT= /usr/lib/rpm/check-rpaths * *** ERROR 0002: file '/usr/lib64/carla/libcarla_frontend.so' contains an invalid runpath '\$ORIGIN' in [\$ORIGIN:/usr/lib] ERROR 0001: file '/usr/lib64/carla/libcarla_frontend.so' contains a standard runpath '/usr/lib' in [\$ORIGIN:/usr/lib] How can I solve this ? See some tips in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath -- 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: Epel8 build with python > 3.6?
On 02. 08. 24 14:30, Nico Kadel-Garcia wrote:
On Tue, Jul 16, 2024 at 12:19 PM Miro Hrončok wrote:
On 16. 07. 24 17:08, Mark E. Fuller via devel wrote:
But the magic switch I need appears to be:
%global __python3 /usr/bin/python3.12
And:
%global python3_pkgversion 3.12
Some packages successfully build without this one, but the idea is:
BuildRequires: python%{python3_pkgversion}-devel
BuildRequires: python%{python3_pkgversion}-pytest
etc.
There are also sometimes binaries mentioned with a "-3" suffix whose
references will need to be revised, especially for "pytest" commands.
Also, don't forget to set "python3_version" along with
"python3_pkgverson".
Don't set %python3_version. It is queried from %__python3.
--
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: Packages with problematic license tag (for SPDX conversion)
On 30. 07. 24 16:07, Miroslav Suchý wrote: churchyard pypy pypy3.10 pypy3.9 IMHO this uses a valid Callaway expression. It has UCD in it, which is not part of fedora-license-data, but it was listed in the old wiki: There is https://fedoraproject.org/wiki/Licensing:UCD And it is listed in https://fedoraproject.org/w/index.php?title=Licensing:Main&oldid=651191#Good_Licenses --- https://gitlab.com/fedora/legal/fedora-license-data/-/issues/30 --- I attempted to convert PyPy to SPDX license in https://src.fedoraproject.org/fork/churchyard/rpms/pypy3.9/commits/7.3.12-spdx But there was some negative feedback to my conversion: https://src.fedoraproject.org/rpms/pypy3.9/pull-request/38#comment-152929 Help is appreciated. PyPy has a lot of code taken here and there in it. -- 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: 2FA policy for provenpackagers is now active
On 24. 06. 24 19:38, Stephen Gallagher wrote: On Mon, Jun 24, 2024 at 1:30 PM Miro Hrončok wrote: On 24. 06. 24 19:13, Kevin Fenzi wrote: tickets are valid for 24hours and can be renewed for 1 week. (Either via gnome online accounts or just 'kinit -R') How do I do that? $ fkinit ... all good ... later: $ klist Ticket cache: KCM:1000:. Default principal: churchy...@fedoraproject.org Valid starting Expires Service principal 24.6.2024 15:42:35 25.6.2024 15:42:21 krbtgt/fedoraproject@fedoraproject.org 24.6.2024 15:42:41 25.6.2024 15:42:21 HTTP/koji.fedoraproject@fedoraproject.org $ kinit -R kinit: KDC can't fulfill requested option while renewing credentials $ kinit -R churchy...@fedoraproject.org kinit: KDC can't fulfill requested option while renewing credentials Seems like a bug on your end; I just tested it on my end and it worked just fine. Maybe your kerberos configuration is out of date? It's changed a few times over the years and if you ever made any manual edits, they may be overriding newer RPM content. I had some custom configuration in /etc/krb5.conf [libdefaults] to make (IPA.)REDHAT.COM work for centos stream builds. I moved everything related to that to /etc/krb5.conf.d/ipa_redhat_com and out of [libdefaults]. Now I can run kinit -R churchy...@fedoraproject.org. Hopefully I can still login to internal stuff. Thanks. -- 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: collect2: fatal error: cannot find ‘ld’
On 30. 07. 24 1:57, Sérgio Basto wrote:
On Tue, 2024-07-30 at 01:31 +0200, Miro Hrončok wrote:
On 30. 07. 24 1:20, Miro Hrončok wrote:
Hello,
I got build failure of pypy3.9 and pypy3.10 on x86_64 only, with:
collect2: fatal error: cannot find ‘ld’
compilation terminated.
See the CI results of (the rawhide results):
https://src.fedoraproject.org/rpms/pypy3.9/pull-request/55
https://src.fedoraproject.org/rpms/pypy3.10/pull-request/20
This is with binutils 2.42.90-1.fc41
It takes 40+ minutes to failure. Any ideas what might be causing
this are
appreciated.
There is:
%ifarch %{ix86} x86_64 %{arm}
sed -i -r 's/\$\(LDFLAGSEXTRA\)/& -fuse-ld=gold/'
./rpython/translator/platform/posix.py
%endif
In the spec. Which might explain why this only happens on x86_64
(%{ix86} is
ExcludeArched, %{arm} is EOL).
Actually, I see binutils-gold installed in the f40 root.log, but not
in the
rawhide root.log.
So this is likely the reason it fails, binutils-gold not installed. I
will
BuildRequire it.
https://src.fedoraproject.org/rpms/binutils/c/2175d42ba13c8999c2cc61813978f66ad8089980
Remove "Requires: binutils-gold" from binutils sub-package.
This was done, but not communicated :(
Hi,
On 21 Jun 2023 4:07 p.m. in devel mailing list was announce the drop of
binutils-gold [1].
Yes, but that never happened.
BTW and regarding this topic, should we start avoid build with golden
linker ? i.e for example, qt5-qtwebengine [2] should we add
BuildRequires: binutils-gold or should we try built with other linker
(ldd IIRC) ?
I'll try to figure out why pypy builds with gold. The original commit is 7+
years old and provides no context:
https://src.fedoraproject.org/rpms/pypy3.9/c/ad0d37c683891eaf084a84e4a9f2205ce3c5585b
--
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: collect2: fatal error: cannot find ‘ld’
On 30. 07. 24 1:20, Miro Hrončok wrote:
Hello,
I got build failure of pypy3.9 and pypy3.10 on x86_64 only, with:
collect2: fatal error: cannot find ‘ld’
compilation terminated.
See the CI results of (the rawhide results):
https://src.fedoraproject.org/rpms/pypy3.9/pull-request/55
https://src.fedoraproject.org/rpms/pypy3.10/pull-request/20
This is with binutils 2.42.90-1.fc41
It takes 40+ minutes to failure. Any ideas what might be causing this are
appreciated.
There is:
%ifarch %{ix86} x86_64 %{arm}
sed -i -r 's/\$\(LDFLAGSEXTRA\)/& -fuse-ld=gold/'
./rpython/translator/platform/posix.py
%endif
In the spec. Which might explain why this only happens on x86_64 (%{ix86} is
ExcludeArched, %{arm} is EOL).
Actually, I see binutils-gold installed in the f40 root.log, but not in the
rawhide root.log.
So this is likely the reason it fails, binutils-gold not installed. I will
BuildRequire it.
https://src.fedoraproject.org/rpms/binutils/c/2175d42ba13c8999c2cc61813978f66ad8089980
Remove "Requires: binutils-gold" from binutils sub-package.
This was done, but not communicated :(
--
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
collect2: fatal error: cannot find ‘ld’
Hello, I got build failure of pypy3.9 and pypy3.10 on x86_64 only, with: collect2: fatal error: cannot find ‘ld’ compilation terminated. See the CI results of (the rawhide results): https://src.fedoraproject.org/rpms/pypy3.9/pull-request/55 https://src.fedoraproject.org/rpms/pypy3.10/pull-request/20 This is with binutils 2.42.90-1.fc41 It takes 40+ minutes to failure. Any ideas what might be causing this are appreciated. -- 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: List of long term FTBFS packages to be retired in 1 week
On 26. 07. 24 16:32, David Abdurachmanov wrote: On Fri, Jul 26, 2024 at 3:52 PM Miro Hrončok wrote: On 26. 07. 24 14:23, Andrea Bolognani wrote: On Fri, Jul 26, 2024 at 03:13:27PM GMT, David Abdurachmanov wrote: On Tue, Jul 23, 2024 at 5:30 PM Miro Hrončok wrote: Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. Hi Miro, I suggest including the following two packages: - InsightToolkit - gimp-separate+ These packages failed in mass rebuilds (F40 and F41). These continue to depend on old libtiff (with CVEs). Looking at gimp-separate+ the domain in URL: field is no longer valid. We are using source code from 2010 (final release). There was an attempt for a minor (patch level) release in 2016. They did some alpha tarballs, but I don't see any release. It seems to be dead for a decade or so. InsightToolkit seems to fail compiling VTK bits. We could probably disable the VTK sub-package for now. Then finally stop libtiff incl. old libtiff binaries with CVEs. For completeness' sake, this is the bug that has been filed a while ago against libtiff to highlight the problematic situation David is referring to: https://bugzilla.redhat.com/show_bug.cgi?id=2292047 If the packages that still need libtiff.so.5 were to be retired, addressing it would become trivial. Hey folks. I cannot retire them while handling the policy, because they were built in Fedora 39 which is not yet EOL. You can follow steps 1-5 from https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs instead. I am a bit surprised here. gimp-separate+ got FTBFS ticket [0] on 2024-01-29 and there has been no response from the maintainer. The rules allow you to nuke the package in 14 (or less) weeks in a specific situation instead of waiting for 13 months. I assume there is no "concerned party" to follow up on FTBFS tickets to get these packages orphaned, and removed more promptly? [0] https://bugzilla.redhat.com/show_bug.cgi?id=2261154 Yeah, if you are a concerned party, you need to follow up at step 3. I tried to make this automated but it still requires maintenance, see https://pagure.io/fedora-infra/ansible/pull-request/1632 I'll switch this to f40. -- 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: List of long term FTBFS packages to be retired in 1 week
On 26. 07. 24 14:23, Andrea Bolognani wrote: On Fri, Jul 26, 2024 at 03:13:27PM GMT, David Abdurachmanov wrote: On Tue, Jul 23, 2024 at 5:30 PM Miro Hrončok wrote: Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. Hi Miro, I suggest including the following two packages: - InsightToolkit - gimp-separate+ These packages failed in mass rebuilds (F40 and F41). These continue to depend on old libtiff (with CVEs). Looking at gimp-separate+ the domain in URL: field is no longer valid. We are using source code from 2010 (final release). There was an attempt for a minor (patch level) release in 2016. They did some alpha tarballs, but I don't see any release. It seems to be dead for a decade or so. InsightToolkit seems to fail compiling VTK bits. We could probably disable the VTK sub-package for now. Then finally stop libtiff incl. old libtiff binaries with CVEs. For completeness' sake, this is the bug that has been filed a while ago against libtiff to highlight the problematic situation David is referring to: https://bugzilla.redhat.com/show_bug.cgi?id=2292047 If the packages that still need libtiff.so.5 were to be retired, addressing it would become trivial. Hey folks. I cannot retire them while handling the policy, because they were built in Fedora 39 which is not yet EOL. You can follow steps 1-5 from https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_package_removal_for_long_standing_ftbfs_and_fti_bugs instead. -- 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 (2024-07-23)
On 24. 07. 24 0:27, Kevin Kofler via devel wrote: Zbigniew Jędrzejewski-Szmek wrote: #3244 Change: Retire Python 2.7 https://pagure.io/fesco/issue/3244 APPROVED (+8, 0, 0) This is going to break the build of a whole bunch of compatibility packages, which will in turn break a lot of software in Fedora. Do you expect packages to do what Qt5WebEngine did for EPEL and bundle their own copy of Python 2 to be used at build time? This just does not make any sense whatsoever. For Qt5WebEngine, there is now a patch from Arch Linux to make it build with Python 3 that we could apply, but both the Qt 4 and 5 QtWebKit require Python 2 to build. As do several other packages, I am pretty sure. We have needinfo'ed all the maintainers of the remaining dependent packages except Qt5WebEngine which does not have a bugzilla. Glad that it has a patch for Qt5WebEngine available. Please use it. We got no replies for months (years even). I am not going to block the removal of Python 2 on a handful of packages who's maintainers don't bother communicating. See the list at https://fedoraproject.org/wiki/Changes/RetirePython2.7#Dependent_packages Also, you had the opportunity to discuss this change before it was approved by FESCo, so I am going to interpret this as rant rather than constructive feedback. As explained in https://fedoraproject.org/wiki/Changes/RetirePython2.7#Benefit_to_Fedora if you wish to maintain Python 2 beyond Fedora 41, you can talk to us and demonstrate the ability and will to take care of Python 2 by joining the maintenance early. -- 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
List of long term FTBFS packages to be retired in 1 week
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 1 week, i.e. around 2024-07-30. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 38. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers === adwaita-blue-gtk-theme abompard, ryanlerch apmdaekoroglu, jskarvad aspell-no jchaloup, ljavorsk, nforro biboumi misc efitoolsvladius fonts-KOI8-Rthan golang-github-acme-lego @go-sig, eclipseo golang-github-ajstarks-deck @go-sig, eclipseo golang-github-prometheus@go-sig, fuller, mikelo2 golang-storj-drpc @go-sig, mikelo2 grpcurl @go-sig, mikelo2 gtk+extra rrankin jack_captureverdurin jowldaxelrod ksensorskkofler libgsystem walters libtpcmisc ankursinha netbox ignatenkobrain, ngompa new-session-manager eeickmeyer octave-odepkg cbm, orphan open-policy-agent @go-sig, olem openstack-java-sdk fsimonce pesign-test-app javierm, nfrayer, pjones, rharwood php-doctrine-doctrine-bundleorphan php-phpdocumentor-reflection1 siwinski php-symfony siwinski php-symfony-psr-http-message-bridge siwinski php-symfony3remi, siwinski postsrsdduck unicornscan robert wiki2beamer sdyroff The following packages require above mentioned packages: Depending on: adwaita-blue-gtk-theme (1) gnofract4d (maintained by: orphan) gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme Depending on: golang-github-ajstarks-deck (4) golang-github-ajstarks-svgo (maintained by: @go-sig, eclipseo, jchaloup) golang-github-ajstarks-svgo-0-23.20210108git7a3c8b5.fc41.src requires golang(github.com/ajstarks/deck/generate) golang-github-ajstarks-svgo-personal-devel-0-23.20210108git7a3c8b5.fc41.noarch requires golang(github.com/ajstarks/deck/generate) golang-github-aclements-gg (maintained by: @go-sig, alexsaezm, jchaloup) golang-github-aclements-gg-0-20.20180422gitabd1f79.fc41.src requires golang(github.com/ajstarks/svgo) golang-github-aclements-gg-devel-0-20.20180422gitabd1f79.fc41.noarch requires golang(github.com/ajstarks/svgo) golang-github-ajstarks-deck (maintained by: @go-sig, eclipseo) golang-github-ajstarks-deck-0-0.15.20210114git30c9fc6.fc38.src requires golang(github.com/ajstarks/svgo), golang(github.com/ajstarks/svgo/float) golang-x-perf (maintained by: @go-sig, alexsaezm, jchaloup) golang-x-perf-0-0.23.20210123gitbdcc622.fc40.src requires golang(github.com/aclements/go-gg/generic/slice), golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table) golang-x-perf-devel-0-0.23.20210123gitbdcc622.fc40.noarch requires golang(github.com/aclements/go-gg/generic/slice), golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table) Depending on: golang-github-prometheus (31) golang-contrib-opencensus-exporter-stackdriver (maintained by: @go-sig, alexsaezm) golang-contrib-opencensus-exporter-stackdriver-0.13.14-1.fc41.src requires golang(github.com/prometheus/prometheus/model/value) golang-contrib-opencensus-exporter-stackdriver-devel-0.13.14-1.fc41.noarch requires golang(github.com/prometheus/prometheus/model/value) golang-github-oklog (maintained by: @go-sig, eclipseo) golang-github-oklog-0.3.2-19.20190701gitca7cdf5.fc40.src requires golang(github.com/prometheus/prometheus/util/testutil) golang-opentelemetry-contrib-0.20 (maintained by: @go-sig, alexsaezm) golang-opentelemetry-contrib-0.20-0.20.0-12.fc41.src requires golang(
Re: Fedora Mass Rebuild 41 has completed
On 23. 07. 24 1:07, Zbigniew Jędrzejewski-Szmek wrote:
I noticed the following when comparing packages after the rebuild:
│ │ │
-{"type":"rpm","name":"guile22","version":"2.2.7-12.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
│ │ │
+{"type":"rpm","name":"guile22","version":"2.2.7-14.fc41","architecture":"x86_64","osCpe":"cpe:/o:fedoraproject:fedora:40"}
It seems the info in os-release hasn't been updated so the
package notes embedded in the binaries are off.
package-notes has:
%build
sed "s|@OSCPE@|$(cat /usr/lib/system-release-cpe)|" %{SOURCE0}
>redhat-package-notes
But the last build before the mass rebuild happened on Fedora 40.
To prevent this situation in the future, package-notes needs to be rebuilt
right after branching.
--
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: Fedora Mass Rebuild 41 has completed
On 22. 07. 24 22:26, Miro Hrončok wrote: Many of them are due to: nothing provides libguile-2.2.so.1()(64bit) or nothing provides libguile-3.0.so.1()(64bit) See https://bugzilla.redhat.com/show_bug.cgi?id=2299414 for the cause. -- 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: Fedora Mass Rebuild 41 has completed
On 22. 07. 24 21:43, Kevin Fenzi wrote: Hi all, Per the Fedora Linux f41 schedule [1] we started a mass rebuild for Fedora Linux f41 on 2024-07-17. We did a mass rebuild for Fedora Linux f41 for: https://pagure.io/releng/issues?status=Open&tags=mass+rebuild The mass rebuild was done in a side tag (f41-rebuild) and moved over to f41. Failures can be seen https://kojipkgs.fedoraproject.org/mass-rebuild/f41-failures.html Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f41-need-rebuild.html 22899 builds have been tagged into f41, there is currently 1008 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on libera.chat, by dropping an email to our list [2], joining #releng:fedoraproject.org on Matrix, or filing an issue in pagure [3]. Regards, Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ Hi. Installation bugs likely related to the rebuild: https://bugzilla.redhat.com/buglist.cgi?bug_id=2299350,2299351,2299352,2299353,2299354,2299355,2299356,2299357,2299358,2299359,2299360,2299361,2299362,2299363,2299364,2299365,2299366,2299367,2299368,2299369,2299370,2299371,2299372,2299373,2299374,2299375,2299376,2299377,2299378,2299379,2299381,2299382,2299383,2299384,2299385,2299386 Many of them are due to: nothing provides libguile-2.2.so.1()(64bit) or nothing provides libguile-3.0.so.1()(64bit) -- 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: Incorrect code or Python regression?
On 21. 07. 24 22:48, Barry wrote: On 21 Jul 2024, at 10:22, Paul Howarth wrote: Hence the check is: except UnsupportedAlgorithm as e: return e._reason is _Reasons.UNSUPPORTED_HASH This may be a case of the e._reason being the correct int value of _ Reasons.UNSUPPORTED_HASH by not the singleton. So “is” fails but when == coerces to int it is True. You would need to print out both values to see if this is the case. They have the same repr, type, int value. They have different IDs. ... except UnsupportedAlgorithm as e: ... ex = e >>> ex._reason _Reasons.UNSUPPORTED_HASH >>> _Reasons.UNSUPPORTED_HASH _Reasons.UNSUPPORTED_HASH >>> type(_Reasons.UNSUPPORTED_HASH) == type(ex._reason) True >>> type(_Reasons.UNSUPPORTED_HASH) is type(ex._reason) True >>> int(ex._reason) 1 >>> int(_Reasons.UNSUPPORTED_HASH) 1 >>> ex._reason == _Reasons.UNSUPPORTED_HASH True >>> ex._reason is _Reasons.UNSUPPORTED_HASH False >>> id(ex._reason) 140685770732432 >>> id(_Reasons.UNSUPPORTED_HASH) 140685770728432 -- 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: Incorrect code or Python regression?
On 21. 07. 24 19:10, Paul Howarth wrote:
Hi Miro,
On Sun, 21 Jul 2024 17:46:24 +0200
Miro Hrončok wrote:
Hey Paul.
I just tried this with pip-installed cryptography in Python 3.13 venv:
>>> from cryptography.exceptions import _Reasons
>>> from cryptography.hazmat.primitives.kdf.kbkdf import KBKDFHMAC
>>> try:
... KBKDFHMAC(None, None, None, None, None, None, None, None,
None) ... except Exception as e:
... ex = e
...
>>> ex
UnsupportedAlgorithm('Algorithm supplied is not a supported hash
algorithm.')
>>> ex._reason
_Reasons.UNSUPPORTED_HASH
>>> ex._reason is _Reasons.UNSUPPORTED_HASH
True
dnf-installed cryptography behaves the same in Rawhide mock.
How can I raise the exception that has a _reason that equals but is
not identical to _Reasons.UNSUPPORTED_HASH?
Sure way is to try rebuilding python-paramiko. The code that exhibits
this behavior is in tests/_util.py:
from cryptography.exceptions import UnsupportedAlgorithm, _Reasons
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding, rsa
...
def sha1_signing_unsupported():
"""
This is used to skip tests in environments where SHA-1 signing is
not supported by the backend.
"""
private_key = rsa.generate_private_key(
public_exponent=65537, key_size=2048, backend=default_backend()
)
message = b"Some dummy text"
try:
private_key.sign(
message,
padding.PSS(
mgf=padding.MGF1(hashes.SHA1()),
salt_length=padding.PSS.MAX_LENGTH,
),
hashes.SHA1(),
)
return False
except UnsupportedAlgorithm as e:
return e._reason is _Reasons.UNSUPPORTED_HASH
I can reproduce that. But I unable to say whether it's a bug in cpython,
cryptography or pyo3. The code in cryptography is written in Rust and I don't
have much experience with hat.
I suggest reporting this behavior at
https://github.com/pyca/cryptography/issues as a starting point.
--
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: Incorrect code or Python regression?
On 21. 07. 24 11:21, Paul Howarth wrote:
Hi all,
python-paramiko failed to build in the mass rebuild and I'm wondering
if there's incorrect code in paramiko (or its dependency cryptography),
or whether it's a regression in the current Python beta.
The failures are in the test suite and the failing tests all involve
this error:
cryptography.exceptions.UnsupportedAlgorithm: sha1 is not supported by
this backend for RSA signing.
Now I know that sha1 signing has recently been disabled in Rawhide: the
upstream test suite is supposed to skip the tests that require sha1
signing, which is implemented using a decorator @requires_sha1_signing.
This was done following a PR I made upstream in 2022
(https://github.com/paramiko/paramiko/pull/2011) in order to get the test
suite to pass in EPEL-9, where the same crypto policy has been in
effect for a long time.
The @requires_sha1_signing decorator is implemented using a function
that attempts sha1 signing, catches the UnsupportedAlgorithm exception
from cryptography and checks that the reason code is
_Reasons.UNSUPPORTED_HASH.
_Reasons is an enum class in cryptography. The pythonic way of checking
enum identities is to use "is", since enums are singletons in Python.
Hence the check is:
except UnsupportedAlgorithm as e:
return e._reason is _Reasons.UNSUPPORTED_HASH
Except that doesn't work in Rawhide. The exception is being raised
exactly as expected but the identity test fails. However, it passes if
I change it to this:
except UnsupportedAlgorithm as e:
return e._reason == _Reasons.UNSUPPORTED_HASH
With that change, the test suite passes.
So my question is: is the python code wrong (test check, enum
implementation in cryptography?) or is this a regression in the latest
Python beta? The latter seems unlikely to me given how this affects
something quite fundamental.
Hey Paul.
I just tried this with pip-installed cryptography in Python 3.13 venv:
>>> from cryptography.exceptions import _Reasons
>>> from cryptography.hazmat.primitives.kdf.kbkdf import KBKDFHMAC
>>> try:
... KBKDFHMAC(None, None, None, None, None, None, None, None, None)
... except Exception as e:
... ex = e
...
>>> ex
UnsupportedAlgorithm('Algorithm supplied is not a supported hash algorithm.')
>>> ex._reason
_Reasons.UNSUPPORTED_HASH
>>> ex._reason is _Reasons.UNSUPPORTED_HASH
True
dnf-installed cryptography behaves the same in Rawhide mock.
How can I raise the exception that has a _reason that equals but is not
identical to _Reasons.UNSUPPORTED_HASH?
--
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: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On 18. 07. 24 22:46, Neal Gompa wrote: On Thu, Jul 18, 2024 at 3:39 AM Miro Hrončok wrote: On 18. 07. 24 1:30, Neal Gompa wrote: You are conflating license tag conversion with a license audit. Tag conversion is explicitly*not* an audit exercise. No, I state the old GPL tags and the new GPL identifiers have different meanings. This is not the case. Even going back to the beginning when the case was first made and all the identifiers were being categorized, all the GNU license tags we had for the Fedora system were matched 1:1 to the SPDX ones. They do not have different meanings. That the form of how GNU license identifiers differ from how we did it before is why I *explicitly* asked and got confirmation about when it happened. Everyone was forced to deal with it when SPDX deprecated the "+" modifier and the associated GNU license tags that used it. The *only* actual difference between "time of Fedora identifiers" and "time of now" is that we have this quest to use SPDX identifiers everywhere and our ability to simplify *informational* license tags has been removed. As said, I know I won't change your mind. And that's OK. You don't need to keep repeating your argument. All I say is that FESCo did not approve this. -- 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: sha1 policy not updated in rawhide
On 18. 07. 24 19:52, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jul 18, 2024 at 03:49:11PM +0200, Alexander Sosedkin wrote: On Thu, Jul 18, 2024 at 3:26 PM Zbigniew Jędrzejewski-Szmek wrote: We recently noticed in systemd upstream that sha1 signing is _not_ failing in rawhide. And indeed, the default crypto policy has not been updated to disallow sha1 signatures in rawhide yet. If this is supposed to happen for F41, it should have happened before the mass rebuild so that we don't get unexpected build failures later on. As for why I've only landed it now --- unlucky timing. First (from Jun 25) I was waiting for the ticket to be assigned, in accordance to the changes policy, I think this is a misunderstanding. Once something is approved by FESCo, it's fine to push the changes. The FESCo ticket says: """ Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. """ See https://pagure.io/fesco/issue/3229 (or any other change ticket) It took 2 weeks form approval to tracking bug creating, and there is no Fedora Program Manager any more. If we want to avoid such delays, the template needs to be updated to mention a different "indication to proceed". -- 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: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On 18. 07. 24 1:30, Neal Gompa wrote: You are conflating license tag conversion with a license audit. Tag conversion is explicitly*not* an audit exercise. No, I state the old GPL tags and the new GPL identifiers have different meanings. This is not an audit, and we have never offered a guarantee of accuracy. If you want the tags to be accurate, you need to evaluate the package every time it is updated. And I know you do it for your stuff, but we know not everyone does. And we do not have tooling to help people audit their packages properly. We also do not have tooling to validate audits in place either. The change to SPDX identifiers is *not* coupled to the "no effective licensing" thing. Those were separate updates that happened at roughly the same time, but are *still* not coupled to each other. I don't want to have this conversation here again. I won't change your mind. However, I say that what FESCo approved is not what you are acting as-if FESCo approved. Do you at least see that? -- 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: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On 17. 07. 24 22:15, Neal Gompa wrote: On Wed, Jul 17, 2024 at 3:41 PM Miroslav Suchý wrote: Dne 17. 07. 24 v 6:41 odp. Miro Hrončok napsal(a): Done. Hi Mirek, I am a bit confused. I thought there was a clear nonconsensus about the *GPL conversion [1] which resulted to the FESCo ticket [2]. It is kinda surprising to see the "Done." comment here and in the LGPL thread as well. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5VAL3I26A4ACWCXWWFHTKV6OXO2GISZ/ [2] https://pagure.io/fesco/issue/3230 Ouch, now I am confused too. You are right that the final wording is: !agreed FESCo is in favor of standardizing on the SPDX format and understands that not all licenses are ready for direct conversion. Those licenses that are unreviewed or otherwise not yet fully compliant should be converted to SPDX licenses of the format LicenseRef--* where * is the old Fedora identifier. (+8, 1, -0) which means that I should stop doing that 1:1 (aka trivial) conversion and convert *everything* to LicenseRef-Callaway-*. But I was on that meeting - and if you read the log: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-16/fesco.2024-07-16-17.00.log.html There was: <@sgallagh:fedora.im> 17:52:01 Proposal: FESCo is in favor of standardizing on the SPDX format and understands that not all licenses are ready for this. Those that are not should be converted to SPDX licenses to a format `LicenseRef--*` where "*" is the old format. ... <@msuchy:matrix.org> 17:52:24 Can I have a clear statement what to do with GPL* ? <@zbyszek:fedora.im> 17:54:04 The whole point is to convert everything. <@conan_kudo:matrix.org> 17:54:08 nirik: it'd be GPLv2 -> GPL-2.0-only, GPLv2+ -> GPL-2.0-or-later <@conan_kudo:matrix.org> 17:54:20 and so on <@zbyszek:fedora.im> 17:54:22 Otherwise, it's not syntactically valid. <@salimma:fedora.im> 17:54:26 sorry, I mixed up msuchy's question with Neal's original response <@nirik:matrix.scrye.com> 17:54:32 but then we have 0 way to tell what was converted? I guess we could look at commits <@conan_kudo:matrix.org> 17:54:56 after everything is said and done, audits still need to be done separately <@conan_kudo:matrix.org> 17:55:00 don't mistake conversions for audits <@salimma:fedora.im> 17:55:05 we might need a second vote to clarify what to do with ambiguous licenses <@salimma:fedora.im> 17:58:24 so Stephen's new proposal is quite clear that every legacy license we can't convert to SPDX would be marked as LicenseRef--* ... I think that addresses the ambiguity So I'd say that Neal statement in 17:54:08 put me in mistake that I should continue with 1:1 but it is not in the final decision/statement. What you're doing is what we expected in FESCo. GNU license identifiers *are* trivial conversions. The main ones that aren't are the older "BSD" and "MIT" ones, which have no meaningful analogue in SPDX. That is your opinion. My opinion differs: The *GPL conversions *are not* trivial because they may hide several other "weaker" licenses in them following the old rules, which is no longer allowed by the new rules that were created when we approved the entire SPDX thing. --- The disagreement on this is what spawned the discussion and the FESCo ticket in the first place. If FESCo wanted to autoconvert all the old "*GPL" licenses to the new SPDX GPL identifiers, it should have been proposed and voted upon. That did not happen. FESCo approved what to do with the ones that are not trivial, but it did not say which are trivial. -- 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: [SPDX] Mass license change AGPLv3 to AGPL-3.0-only
On 17. 07. 24 13:56, Miroslav Suchý wrote: Dne 18. 06. 24 v 8:19 dop. Miroslav Suchý napsal(a): I am going to do the mass change of the license from AGPLv3 to AGPL-3.0-only Done. Hi Mirek, I am a bit confused. I thought there was a clear nonconsensus about the *GPL conversion [1] which resulted to the FESCo ticket [2]. It is kinda surprising to see the "Done." comment here and in the LGPL thread as well. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q5VAL3I26A4ACWCXWWFHTKV6OXO2GISZ/ [2] https://pagure.io/fesco/issue/3230 -- 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
List of long term FTBFS packages to be retired in 2 weeks
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 2 weeks, i.e. around 2024-07-30. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 38. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers === adwaita-blue-gtk-theme abompard, ryanlerch apmdaekoroglu, jskarvad aspell-no jchaloup, ljavorsk, nforro biboumi misc efitoolsvladius fonts-KOI8-Rthan golang-github-acme-lego @go-sig, eclipseo golang-github-ajstarks-deck @go-sig, eclipseo golang-github-prometheus@go-sig, fuller, mikelo2 golang-storj-drpc @go-sig, mikelo2 grpcurl @go-sig, mikelo2 gtk+extra rrankin jack_captureverdurin jowldaxelrod kcm_systemd kkofler, tdawson ksensorskkofler libgsystem walters libtpcmisc ankursinha mingw-libgovirt elmarco, etrunko, teuf netbox ignatenkobrain, ngompa new-session-manager eeickmeyer non-ntk tartina octave-odepkg cbm, orphan open-policy-agent @go-sig, olem openstack-java-sdk fsimonce pesign-test-app javierm, nfrayer, pjones, rharwood php-doctrine-doctrine-bundleorphan php-phpdocumentor-reflection1 siwinski php-symfony siwinski php-symfony-psr-http-message-bridge siwinski php-symfony3remi, siwinski postsrsdduck unicornscan robert wiki2beamer sdyroff The following packages require above mentioned packages: Depending on: adwaita-blue-gtk-theme (1) gnofract4d (maintained by: orphan) gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme Depending on: golang-github-ajstarks-deck (4) golang-github-ajstarks-svgo (maintained by: @go-sig, eclipseo, jchaloup) golang-github-ajstarks-svgo-0-23.20210108git7a3c8b5.fc41.src requires golang(github.com/ajstarks/deck/generate) golang-github-ajstarks-svgo-personal-devel-0-23.20210108git7a3c8b5.fc41.noarch requires golang(github.com/ajstarks/deck/generate) golang-github-aclements-gg (maintained by: @go-sig, alexsaezm, jchaloup) golang-github-aclements-gg-0-20.20180422gitabd1f79.fc41.src requires golang(github.com/ajstarks/svgo) golang-github-aclements-gg-devel-0-20.20180422gitabd1f79.fc41.noarch requires golang(github.com/ajstarks/svgo) golang-github-ajstarks-deck (maintained by: @go-sig, eclipseo) golang-github-ajstarks-deck-0-0.15.20210114git30c9fc6.fc38.src requires golang(github.com/ajstarks/svgo), golang(github.com/ajstarks/svgo/float) golang-x-perf (maintained by: @go-sig, alexsaezm, jchaloup) golang-x-perf-0-0.23.20210123gitbdcc622.fc40.src requires golang(github.com/aclements/go-gg/generic/slice), golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table) golang-x-perf-devel-0-0.23.20210123gitbdcc622.fc40.noarch requires golang(github.com/aclements/go-gg/generic/slice), golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table) Depending on: golang-github-prometheus (31) golang-contrib-opencensus-exporter-stackdriver (maintained by: @go-sig, alexsaezm) golang-contrib-opencensus-exporter-stackdriver-0.13.14-1.fc41.src requires golang(github.com/prometheus/prometheus/model/value) golang-contrib-opencensus-exporter-stackdriver-devel-0.13.14-1.fc41.noarch requires golang(github.com/prometheus/prometheus/model/value) golang-github-oklog (maintained by: @go-sig, eclipseo) golang-github-oklog-0.3.2-19.20190701gitca7cdf5.fc40.src requires golang(github.com/prometheus/prometheu
Re: Epel8 build with python > 3.6?
On 16. 07. 24 17:08, Mark E. Fuller via devel wrote:
But the magic switch I need appears to be:
%global __python3 /usr/bin/python3.12
And:
%global python3_pkgversion 3.12
Some packages successfully build without this one, but the idea is:
BuildRequires: python%{python3_pkgversion}-devel
BuildRequires: python%{python3_pkgversion}-pytest
etc.
--
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: Epel8 build with python > 3.6?
On 16. 07. 24 13:28, Petr Pisar wrote: V Tue, Jul 16, 2024 at 05:24:55AM -0400, Stephen Smoogen napsal(a): So you are running into modularity issue there and I am guessing it is from mock versus koji because koji gets around modularity with a hack. In mock you have to tell it to enable the module there are in. I don’t know the syntax off hand but it is probably a command line flag. It's not a modularity issue. The issue is the python38-pytest is only built as a modular package. In contrast to python38 or python312 packages which are built a nonmodular packages. That is not entirely correct. python38 is a modular package, python38-pytest is a modular package as well. python3.12 is not a modular package, python3.12-pytest is also not a modular package. -- Anyway, the RHEL 8 Python 3.8 module is out of support, don't build any EPEL packages with Python 3.8 please. -- 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
List of long term FTBFS packages to be retired in July
(Message resent due to https://pagure.io/fedora-infrastructure/issue/12046 -- this time only yo devel-announce.) Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 3 weeks, i.e. around 2024-07-30. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 38. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers === NetworkManager-iodine danfruehauf adwaita-blue-gtk-theme abompard, ryanlerch apmdaekoroglu, jskarvad aspell-no jchaloup, ljavorsk, nforro biboumi misc efitoolsvladius fonts-KOI8-Rthan golang-github-acme-lego @go-sig, eclipseo golang-github-ajstarks-deck @go-sig, eclipseo golang-github-prometheus@go-sig, fuller, mikelo2 golang-storj-drpc @go-sig, mikelo2 gopass @go-sig, fale, laiot grpcurl @go-sig, mikelo2 gtk+extra rrankin jack_captureverdurin jowldaxelrod kcm_systemd kkofler, tdawson ksensorskkofler libgsystem walters libtpcmisc ankursinha mingw-libgovirt elmarco, etrunko, teuf netbox ignatenkobrain, ngompa new-session-manager eeickmeyer non-ntk tartina octave-odepkg ankursinha, cbm open-policy-agent @go-sig, olem openstack-java-sdk fsimonce pesign-test-app javierm, nfrayer, pjones, rharwood php-doctrine-doctrine-bundlesiwinski php-phpdocumentor-reflection1 siwinski php-symfony siwinski php-symfony-psr-http-message-bridge siwinski php-symfony3remi, siwinski postsrsdduck rEFInd dcavalca, ngompa unicornscan robert wiki2beamer sdyroff xedit pcpa xorg-x11-drv-armada lkundrak zynaddsubfx tartina The following packages require above mentioned packages: Depending on: NetworkManager-iodine (2) plasma-nm (maintained by: @kde-sig, rdieter) plasma-nm-iodine-6.1.2-1.fc41.i686 requires NetworkManager-iodine plasma-nm-iodine-6.1.2-1.fc41.x86_64 requires NetworkManager-iodine plasma-mobile (maintained by: @kde-sig, farchord) plasma-mobile-6.1.2-1.fc41.i686 requires plasma-nm plasma-mobile-6.1.2-1.fc41.x86_64 requires plasma-nm Depending on: adwaita-blue-gtk-theme (1) gnofract4d (maintained by: orphan) gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme Depending on: golang-github-ajstarks-deck (4) golang-github-ajstarks-svgo (maintained by: @go-sig, eclipseo, jchaloup) golang-github-ajstarks-svgo-0-23.20210108git7a3c8b5.fc41.src requires golang(github.com/ajstarks/deck/generate) golang-github-ajstarks-svgo-personal-devel-0-23.20210108git7a3c8b5.fc41.noarch requires golang(github.com/ajstarks/deck/generate) golang-github-aclements-gg (maintained by: @go-sig, alexsaezm, jchaloup) golang-github-aclements-gg-0-20.20180422gitabd1f79.fc41.src requires golang(github.com/ajstarks/svgo) golang-github-aclements-gg-devel-0-20.20180422gitabd1f79.fc41.noarch requires golang(github.com/ajstarks/svgo) golang-github-ajstarks-deck (maintained by: @go-sig, eclipseo) golang-github-ajstarks-deck-0-0.15.20210114git30c9fc6.fc38.src requires golang(github.com/ajstarks/svgo), golang(github.com/ajstarks/svgo/float) golang-x-perf (maintained by: @go-sig, alexsaezm, jchaloup) golang-x-perf-0-0.23.20210123gitbdcc622.fc40.src requires golang(github.com/aclements/go-
Re: PR for rebuild and autochangelog
On 09. 07. 24 17:01, David Bold wrote: Gi, I tried to open a PR to get petsc rebuild for a recent update of openmpi. However, I cannot open a PR, which I think might be related that I only have an empty commit [0]. I have been told I should open PRs for rebuilds [1]. Is it possible to have a PR without any code changes? Is there an alternative, recommended way to ask for rebuilds? Best, David [0] https://src.fedoraproject.org/fork/davidsch/rpms/petsc/diff/rawhide..rawhide [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QIOG5NGHKIABSU2M2QQCZ67PHZSVVV5H/ I reported this as a problem to Pagure 2.5 years ago: https://pagure.io/pagure/issue/5270 No meaningful response since. -- 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
List of long term FTBFS packages to be retired in July
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 3 weeks, i.e. around 2024-07-30. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 38. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers === NetworkManager-iodine danfruehauf adwaita-blue-gtk-theme abompard, ryanlerch apmdaekoroglu, jskarvad aspell-no jchaloup, ljavorsk, nforro biboumi misc efitoolsvladius fonts-KOI8-Rthan golang-github-acme-lego @go-sig, eclipseo golang-github-ajstarks-deck @go-sig, eclipseo golang-github-prometheus@go-sig, fuller, mikelo2 golang-storj-drpc @go-sig, mikelo2 gopass @go-sig, fale, laiot grpcurl @go-sig, mikelo2 gtk+extra rrankin jack_captureverdurin jowldaxelrod kcm_systemd kkofler, tdawson ksensorskkofler libgsystem walters libtpcmisc ankursinha mingw-libgovirt elmarco, etrunko, teuf netbox ignatenkobrain, ngompa new-session-manager eeickmeyer non-ntk tartina octave-odepkg ankursinha, cbm open-policy-agent @go-sig, olem openstack-java-sdk fsimonce pesign-test-app javierm, nfrayer, pjones, rharwood php-doctrine-doctrine-bundlesiwinski php-phpdocumentor-reflection1 siwinski php-symfony siwinski php-symfony-psr-http-message-bridge siwinski php-symfony3remi, siwinski postsrsdduck rEFInd dcavalca, ngompa unicornscan robert wiki2beamer sdyroff xedit pcpa xorg-x11-drv-armada lkundrak zynaddsubfx tartina The following packages require above mentioned packages: Depending on: NetworkManager-iodine (2) plasma-nm (maintained by: @kde-sig, rdieter) plasma-nm-iodine-6.1.2-1.fc41.i686 requires NetworkManager-iodine plasma-nm-iodine-6.1.2-1.fc41.x86_64 requires NetworkManager-iodine plasma-mobile (maintained by: @kde-sig, farchord) plasma-mobile-6.1.2-1.fc41.i686 requires plasma-nm plasma-mobile-6.1.2-1.fc41.x86_64 requires plasma-nm Depending on: adwaita-blue-gtk-theme (1) gnofract4d (maintained by: orphan) gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme Depending on: golang-github-ajstarks-deck (4) golang-github-ajstarks-svgo (maintained by: @go-sig, eclipseo, jchaloup) golang-github-ajstarks-svgo-0-23.20210108git7a3c8b5.fc41.src requires golang(github.com/ajstarks/deck/generate) golang-github-ajstarks-svgo-personal-devel-0-23.20210108git7a3c8b5.fc41.noarch requires golang(github.com/ajstarks/deck/generate) golang-github-aclements-gg (maintained by: @go-sig, alexsaezm, jchaloup) golang-github-aclements-gg-0-20.20180422gitabd1f79.fc41.src requires golang(github.com/ajstarks/svgo) golang-github-aclements-gg-devel-0-20.20180422gitabd1f79.fc41.noarch requires golang(github.com/ajstarks/svgo) golang-github-ajstarks-deck (maintained by: @go-sig, eclipseo) golang-github-ajstarks-deck-0-0.15.20210114git30c9fc6.fc38.src requires golang(github.com/ajstarks/svgo), golang(github.com/ajstarks/svgo/float) golang-x-perf (maintained by: @go-sig, alexsaezm, jchaloup) golang-x-perf-0-0.23.20210123gitbdcc622.fc40.src requires golang(github.com/aclements/go-gg/generic/slice), golang(github.com/aclements/go-gg/ggstat), golang(github.com/aclements/go-gg/table) golang-x-
Re: Automatic detection of unused BuildRequires
On 03. 07. 24 18:02, Marián Konček wrote: As many of you know, as packages change, so do their BuildRequires. In the current state, maintaining them requires some manual work from the maintainer. 1. So I got around the idea of a simple tool that checks file accesses during the build and using RPM queries, detects whether some package's files are not accessed at all therefore the package is not needed for the build. To my knowledge there is no such project. The project is here: https://github.com/mkoncek/unbreq It may not be completely reliable, but it also may be good enough to catch simple mistakes. 2. At least in the case of maven build system, this tool does not help with `mvn(foo:bar)` dependencies, as maven unconditionally reads all the files present in /usr/share/maven-metadata, from which it deduces the associations between jars and artifact coordinates. I imagine other build systems employ a similar strategy. 3. In the case of maven, we have a manual tool: xmvn-builddep, which reads the build.log and constructs the actual BuildRequires from it, using knowledge about the build procedure. This could be used as an additional step of this tool, having similar tools for other languages. Ultimately, I am interested in the possibility of having automated unused BuildRequires detection as part of rpmbuild / mockbuild. Amongst others, I get: warning: BuildRequires make is not needed While I call /usr/bin/make which is owned by make. Any idea what could cause this? -- 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: Automatic detection of unused BuildRequires
On 03. 07. 24 18:02, Marián Konček wrote: As many of you know, as packages change, so do their BuildRequires. In the current state, maintaining them requires some manual work from the maintainer. Thanks! (As a side note, I encourage everybody to use %genearte_buildrequires from upstream metadata/code as much as possible, it helps remove stale BuildRequires quite a lot. I can help you design a macro for this for your ecosystem (e.g. Perl, Maven)). 1. So I got around the idea of a simple tool that checks file accesses during the build and using RPM queries, detects whether some package's files are not accessed at all therefore the package is not needed for the build. To my knowledge there is no such project. The project is here: https://github.com/mkoncek/unbreq It may not be completely reliable, but it also may be good enough to catch simple mistakes. I read the documentation. Should this be executed after %check rather than after %install? 2. At least in the case of maven build system, this tool does not help with `mvn(foo:bar)` dependencies, as maven unconditionally reads all the files present in /usr/share/maven-metadata, from which it deduces the associations between jars and artifact coordinates. I imagine other build systems employ a similar strategy. I imagine that for Python packages, this will be similar, as Python tools would likely read all the installed .dist-info, .egg-info metadata regardless of whether they actually need those packages. Perhaps there could be a regex/glob based ignore-list of files that should not count? 3. In the case of maven, we have a manual tool: xmvn-builddep, which reads the build.log and constructs the actual BuildRequires from it, using knowledge about the build procedure. This could be used as an additional step of this tool, having similar tools for other languages. Ultimately, I am interested in the possibility of having automated unused BuildRequires detection as part of rpmbuild / mockbuild. I +1 Mirek's opinion to make this a mock plugin. That way, we can run it in bulk without modifying the specs. -- 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: [EPEL-devel] RFC: Adding the ability to specify what side tag should be used for scratch builds of a PR
On 02. 07. 24 23:25, Michel Lind wrote: Hi all, I'm currently shepherding getting catch v3 into EPEL 9 (bringing along the catch2 compatibility package, so the impact is minimal) - and to make sure no dependent package is left in a state where they can't be rebuilt, I'm coordinating the work in a side tag. See for example https://src.fedoraproject.org/rpms/cli11/pull-request/1 The problem is - the scratch build still happens against EPEL 9, and there's currently no way to direct it to use a side tag, so of course it fails and the package maintainers sometimes assumed something is wrong with the PR. I see that Depends-On is already supported, so I figure we can also add something like Side-Tag as an option. https://zuul-ci.org/docs/zuul/latest/gating.html#cross-project-dependencies Does this sound like a useful idea, and if so, where should I file it? Zuul itself uses Storyboard, but IDK if that's too general and this request is too Fedora-specific -- I notice Storyboard uses Ubuntu One for login, for instance. Zuul already supports this in CentOS Stream, but not in Fedora/EPEL. I opened https://pagure.io/fedora-ci/general/issue/240 3 years ago ¯\_(ツ)_/¯ -- 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
List of long term FTBFS packages to be retired in July
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 4 weeks, i.e. around 2024-07-30. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 38. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers === NetworkManager-iodine danfruehauf adwaita-blue-gtk-theme abompard, ryanlerch apmdaekoroglu, jskarvad aspell-no jchaloup, ljavorsk, nforro biboumi misc efitoolsvladius fonts-KOI8-Rthan golang-github-acme-lego @go-sig, eclipseo golang-github-ajstarks-deck @go-sig, eclipseo golang-github-prometheus@go-sig, fuller, mikelo2 golang-storj-drpc @go-sig, mikelo2 gopass @go-sig, fale, laiot grpcurl @go-sig, mikelo2 gtk+extra rrankin jack_captureverdurin jowldaxelrod kcm_systemd kkofler, tdawson ksensorskkofler libgsystem walters libtpcmisc ankursinha mingw-libgovirt elmarco, etrunko, teuf netbox ignatenkobrain, ngompa new-session-manager eeickmeyer non-ntk tartina octave-odepkg ankursinha, cbm open-policy-agent @go-sig, olem openstack-java-sdk fsimonce pesign-test-app javierm, nfrayer, pjones, rharwood php-doctrine-doctrine-bundlesiwinski php-phpdocumentor-reflection1 siwinski php-symfony siwinski php-symfony-psr-http-message-bridge siwinski php-symfony3remi, siwinski postsrsdduck rEFInd dcavalca, ngompa unicornscan robert wiki2beamer sdyroff xedit pcpa xorg-x11-drv-armada lkundrak zynaddsubfx tartina The following packages require above mentioned packages: Depending on: NetworkManager-iodine (2) plasma-nm (maintained by: @kde-sig, rdieter) plasma-nm-iodine-6.1.1-1.fc41.i686 requires NetworkManager-iodine plasma-nm-iodine-6.1.1-1.fc41.x86_64 requires NetworkManager-iodine plasma-mobile (maintained by: @kde-sig, farchord) plasma-mobile-6.1.1-1.fc41.i686 requires plasma-nm plasma-mobile-6.1.1-1.fc41.x86_64 requires plasma-nm Depending on: adwaita-blue-gtk-theme (1) gnofract4d (maintained by: orphan) gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme Depending on: golang-github-acme-lego (1) incus (maintained by: @go-sig, ganto, ngompa) golang-github-lxc-incus-devel-6.2-1.fc41.noarch requires golang(github.com/go-acme/lego/v4/acme), golang(github.com/go-acme/lego/v4/certcrypto), golang(github.com/go-acme/lego/v4/certificate), golang(github.com/go-acme/lego/v4/challenge), golang(github.com/go-acme/lego/v4/lego), golang(github.com/go-acme/lego/v4/registration) Depending on: golang-github-ajstarks-deck (4) golang-github-ajstarks-svgo (maintained by: @go-sig, eclipseo, jchaloup) golang-github-ajstarks-svgo-0-23.20210108git7a3c8b5.fc41.src requires golang(github.com/ajstarks/deck/generate) golang-github-ajstarks-svgo-personal-devel-0-23.20210108git7a3c8b5.fc41.noarch requires golang(github.com/ajstarks/deck/generate) golang-github-aclements-gg (maintained by: @go-sig, alexsaezm, jchaloup) golang-github-aclements-gg-0-20.20180422gitabd1f79.fc41.src requires golang(github.com/ajstarks/svgo) golang-github-aclements-gg-devel-0-20.20180422gitabd1f79.fc41.noarch requires golang(github.com/ajstarks/svgo) golang-github-ajstarks-deck (maintained by: @go-sig, e
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 26. 06. 24 14:17, Miroslav Suchý wrote: Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a): Clearly, I must miss something. What do we gain by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? We will get valid SPDX formula. And all tools generating SBOMs from RPMs can use it and it will produce valid SBOM document. If we keep the old value, it will not be valid SPDX formula and all tools build on top of that have to put if/else into their workflow. And what good is a valid SPDX formula if it contains custom identifiers? If we converted all the Licenses of all our packages to LicenseRef-Fedora-Unknown, it would still be a valid formula, but clearly, we would not want that. Or would we? -- 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: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 26. 06. 24 5:59, Richard Fontana wrote: On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok wrote: On 25. 06. 24 22:50, Miroslav Suchý wrote: Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only We (the Change owners) discussed this on a meeting today. And we agreed on output: # Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2 This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license. What do you think? I don't understand what is the benefit of doing this at all. Sorry. The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.) What is the benefit of that outcome? I understand the benefit of SPDX in general. I don't understand the benefit of converting everything to custom LicenseRef identifiers. We are already making it clear that the expressions are legacy by... being legacy. Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate? I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion? -- 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: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 25. 06. 24 22:50, Miroslav Suchý wrote: Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only We (the Change owners) discussed this on a meeting today. And we agreed on output: # Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2 This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license. What do you think? I don't understand what is the benefit of doing this at all. Sorry. -- 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
List of long term FTBFS packages to be retired in July
Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 41 approximately one week before branching. 5 weekly reminders are required, hence the retirement will happen approximately in 5 weeks, i.e. around 2024-07-30. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ The packages in rawhide were not successfully built at least since Fedora 38. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers === NetworkManager-iodine danfruehauf adwaita-blue-gtk-theme abompard, ryanlerch apmdaekoroglu, jskarvad aspell-no jchaloup, ljavorsk, nforro biboumi misc efitoolsvladius erlang-hex_core @erlang-maint-sig, peter fonts-KOI8-Rthan golang-github-acme-lego @go-sig, eclipseo golang-github-ajstarks-deck @go-sig, eclipseo golang-github-cryptix-wav @deepinde-sig, @go-sig, zsun golang-github-prometheus@go-sig, fuller, mikelo2 golang-github-viant-toolbox @go-sig, mikelo2 golang-modernc-mathutil @go-sig, eclipseo golang-storj-drpc @go-sig, mikelo2 gopass @go-sig, fale, laiot grpcurl @go-sig, mikelo2 gtk+extra rrankin jack_captureverdurin jowldaxelrod kcm_systemd kkofler, tdawson ksensorskkofler libgsystem walters libratbag bentiss, skitt, whot libtpcmisc ankursinha mingw-drmingw sailer mingw-libftdi sailer mingw-libgovirt elmarco, etrunko, teuf netbox ignatenkobrain, ngompa new-session-manager eeickmeyer non-ntk tartina octave-odepkg ankursinha, cbm open-policy-agent @go-sig, olem openstack-java-sdk fsimonce pesign-test-app javierm, nfrayer, pjones, rharwood php-doctrine-doctrine-bundlesiwinski php-phpdocumentor-reflection1 siwinski php-symfony siwinski php-symfony-psr-http-message-bridge siwinski php-symfony3remi, siwinski postsrsdduck rEFInd dcavalca, ngompa serdisplib jwrdegoede tkabber-plugins krege unicornscan robert wiki2beamer sdyroff x2goclient orion xedit pcpa xorg-x11-drv-armada lkundrak zynaddsubfx tartina The following packages require above mentioned packages: Depending on: NetworkManager-iodine (2) plasma-nm (maintained by: @kde-sig, rdieter) plasma-nm-iodine-6.1.0-1.fc41.i686 requires NetworkManager-iodine plasma-nm-iodine-6.1.0-1.fc41.x86_64 requires NetworkManager-iodine plasma-mobile (maintained by: @kde-sig, farchord) plasma-mobile-6.1.0-1.fc41.i686 requires plasma-nm plasma-mobile-6.1.0-1.fc41.x86_64 requires plasma-nm Depending on: adwaita-blue-gtk-theme (1) gnofract4d (maintained by: jjames) gnofract4d-4.3-17.fc41.src requires adwaita-blue-gtk-theme Depending on: erlang-hex_core (85) erlang-rebar3 (maintained by: @erlang-maint-sig, peter) erlang-rebar3-3.22.0-4.fc40.noarch requires erlang-hex_core erlang-rebar3-3.22.0-4.fc40.src requires erlang-hex_core elixir (maintained by: codeblock, fnux) elixir-1.16.2-1.fc41.src requires erlang-rebar3 erlang-amf (maintained by: peter) erlang-amf-0-0.34.20110224git8fea004.fc41.src requires erlang-rebar3 erlang-base64url (maintained by: @erlang-maint-sig, bowlofeggs, peter) erlang-base64url-1.0.1-15.fc41.src requires
Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 21. 06. 24 8:30, Miroslav Suchý wrote: What I can do is to put a comment above the license: # Automatically converted from old format: GPLv2 License: GPL-2.0-only Could you make the comment something like this? # Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only I would support such automatic conversion. Thanks. -- 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: Reverse dependency query
On 24. 06. 24 23:27, Jerry James wrote:
On Mon, Jun 24, 2024 at 3:19 PM Miro Hrončok wrote:
This seems like the traditional "the SRPM was built on i686" problem.
If I click through to the buildSRPMFromSCM task, I arrive here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=118928877
which says that task was executed on
buildvm-a64-24.iad2.fedoraproject.org, which is aarch64. Are we using
that SRPM for the build only, then picking some random SRPM from the
build to promote?
Yes. Except I don't know if it's truly random.
Anyway, the SRPMs from buildSRPMFromSCM tasks do not have
%generate_buildrequires results in them. Only the final SRPMs have them. To
know which architecture the SRPM was built on, you can go to:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2469158
Locate the task:
https://koji.fedoraproject.org/koji/taskinfo?taskID=118928836
Click the individual buildArch tasks and see only the i686 one has src.rpm in
the Output section.
Alternatively, you can start at the same place:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2469158
Locate the SRPM and click (info):
https://koji.fedoraproject.org/koji/rpminfo?rpmID=38863151
Go to Buildroot:
https://koji.fedoraproject.org/koji/buildrootinfo?buildrootID=51527189
Go to Component RPMs:
https://koji.fedoraproject.org/koji/rpmlist?buildrootID=51527189&type=component
See i686+noarch NVRs.
So ...`%ifarch %{java_arches}` evaluated to false when the source RPM
was generated? Does that mean that other BuildRequires inside of
%ifarch might be hidden from such queries? That would make the
queries less useful than I would like.
Correct.
So I can't rely
on fedrq or repoquery to give me a full list of reverse dependencies
when I check for impact of a version upgrade. That's really, really
unfortunate.
You cannot. It is.
--
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: Reverse dependency query
On 24. 06. 24 23:00, Fabio Valentini wrote:
On Mon, Jun 24, 2024 at 10:48 PM Jerry James wrote:
I want to see what packages depend on antlr4.
$ fedrq wr antlr4
antlr4-maven-plugin-4.10.1-15.fc41.noarch
azure-cli-2.61.0-2.fc41.src
coq-8.18.0-7.fc41.src
golang-github-google-cel-0.12.4-7.fc40.src
And repoquery agrees:
$ dnf --repo=rawhide --repo=rawhide-source repoquery --whatrequires
antlr4 --alldeps
antlr4-maven-plugin-0:4.10.1-15.fc41.noarch
azure-cli-0:2.61.0-2.fc41.src
coq-0:8.18.0-7.fc41.src
golang-github-google-cel-0:0.12.4-7.fc40.src
Except that's incomplete. The sympy package was omitted. From sympy.spec:
%ifarch %{java_arches}
BuildRequires: antlr4
%endif
The most recent build was on 12 June 2024:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2469158. Look
at the x86_64 root.log, for example, and antlr4 is there:
DEBUG util.py:463: antlr4 noarch
4.10.1-15.fc41 build2.6 MiB
Is there a query that shows sympy in the result?
It looks like the problem is actually on the sympy side, not with your query.
The latest "sympy.src" package does not have a dependency on antlr4:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=38863151
This seems like the traditional "the SRPM was built on i686" problem.
Koji only exposes one of the built SRPMs. It's often (but not always?) the one
built on i686.
There is no way to query this built dependency, as it is not in the repository.
3-year-old RFE for Koji: https://pagure.io/koji/issue/2726
--
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: 2FA policy for provenpackagers is now active
On 24. 06. 24 19:13, Kevin Fenzi wrote: tickets are valid for 24hours and can be renewed for 1 week. (Either via gnome online accounts or just 'kinit -R') How do I do that? $ fkinit ... all good ... later: $ klist Ticket cache: KCM:1000:. Default principal: churchy...@fedoraproject.org Valid starting Expires Service principal 24.6.2024 15:42:35 25.6.2024 15:42:21 krbtgt/fedoraproject@fedoraproject.org 24.6.2024 15:42:41 25.6.2024 15:42:21 HTTP/koji.fedoraproject@fedoraproject.org $ kinit -R kinit: KDC can't fulfill requested option while renewing credentials $ kinit -R churchy...@fedoraproject.org kinit: KDC can't fulfill requested option while renewing credentials -- 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: java-*-openjdk-portable and the FTBFS policy
On 24. 06. 24 19:16, Jiri Vanek wrote: hi! Yes, there is upcoming release in 17july, and in this release will be all built on f39. If there would be any intermittent release it would be already on f39 anyway. I do not have strong preference on exclude/rebuild. I was going by moreover middle path - to keep building on oldest supported os, considering jdk is built no later then every 3 months, I was not hurrying with rebuild once f38 went eol. Actually during every build I'm ensuring buildability of all jdks on all fedoras, which is ok, except jdk8 on f40+ (but that should go better soon). If you want me to rebuild on each EOL, I'm ok to do it, only do not be to angry if I forget from time to time. I will always respond to ping. Does it make sense? Absolutely. If you rebuild every 3 months anyway, I don't think an explicit rebuild after EOL is necessary. I will exclude the packages from the report to avoid noise. Thanks! -- 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
java-*-openjdk-portable and the FTBFS policy
Hello, I am about to send a reminder about Rawhide packages that were not successfully built on a supported Fedora release / fail top build for 2+ releases. Amongst the list of the packages, I see: java-1.8.0-openjdk-portable-1:1.8.0.412.b06-1.fc38.src java-11-openjdk-portable-1:11.0.23.0.9-1.fc38.src java-17-openjdk-portable-1:17.0.11.0.9-1.fc38.src java-21-openjdk-portable-1:21.0.3.0.9-1.fc38.src java-latest-openjdk-portable-1:22.0.1.0.8-1.rolling.fc38.src Technically, those packages do not fail to build, but they were built on Fedora 38 on purpose. However, Fedora 38 is now EOL so the package do violate the "built on supported release" principle of the policy. Should those packages be exempted from the policy, or should we rebuild them on Fedora 39 now? I don't know if this poses some additional expenses wrt certification. -- 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: [Node.js] Stepping down as Node.js Maintainer in Fedora
On 24. 06. 24 10:45, Emmanuel Seyman wrote: * Jan Staněk [24/06/2024 03:06] : Right now I see no way on Pagure to request ownership/co-maintenance (maybe I'm just blind). Anyway, feel free to add me to maintainers and/or transfer the ownership. Unless things have changed, Pagure does not allow transfer of ownership. It does. The current maintainer can "give" the package to another one. Go to Settings -> Give Project: https://src.fedoraproject.org/rpms/nodejs22/settings#giveproject-tab -- 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: 2FA policy for provenpackagers is now active
On 23. 06. 24 20:33, Leigh Scott wrote: Once set you can't disable it. If this persists I will ditch provenpackager group Leaving the group won't disable 2FA. I recommend opening a fedora-infrastructure ticket and asking for help. -- 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: bin-sbin merge planned for next week
On 20. 06. 24 22:44, Zbigniew Jędrzejewski-Szmek wrote: In the particular case of alternatives.rpm, the pull request was https://src.fedoraproject.org/rpms/chkconfig/pull-request/13, which then becamehttps://github.com/fedora-sysv/chkconfig/pull/131. The Fedora PR was closed. The non-Fedora PR seems merged but this has not landed in Fedora. That is why I have not found it, because it is not there, not because it is guarded by an %if. This needs to land before the merge. Insert a general rant about upstream specfiles and not following https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity -- 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: bin-sbin merge planned for next week
On 19. 06. 24 12:34, Zbigniew Jędrzejewski-Szmek wrote:
4. We have packages which use filepath Requires on paths in %_sbindir.
Such packages will FTI when the_providing_ package is rebuilt with
the new value of %_sbindir. To keep those packages working, I made
a list of all such filepath dependencies in Fedora and prepared
patches for the provider packages to add a virtual Provides for the
old name, e.g. [5]. This means that the provider package has
Provides:/usr/sbin/foo before the merge and
Provides:/usr/bin/foo,/usr/sbin/foo when rebuilt after the merge.
I'll rebuild all packages that need to add the virtual Provides in
the side tag too.
So, recently I saw this:
Requires(post): %{_sbindir}/alternatives
Requires(postun): %{_sbindir}/alternatives
And I checked the alternatives package (chkconfig component). It does not
manually provide /usr/sbin/alternatives. There is no open pull request.
Your email made it sound like this is all ready, but I don't see it.
$ repoquery -q --repo=rawhide --whatrequires /usr/sbin/alternatives | wc -l
128
So, what is the list of the packages and the prepared patches?
--
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: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 19. 06. 24 23:32, Miroslav Suchý wrote: Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a): How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar? Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically. I don't know. But it seems like the best option. Not to me. When we decided to do the SPDX thing, we also decided to do the "no effective license analysis" and "list all the licenses". I don't have an opinion whether that decision is good or bad, but it is that way. We cannot automatically convert GPLv2 to GPL-2.0-only (or similarly with other variants and versions). If we do this, we are effectively saying "OK, we agreed on a set of rules, but we decided to ignore them for a sake of..." what exactly? Completeness? Closure? That does not make sense to me. More below. What are the options: 1) Wait for all the maintainers to do the conversion themselves. Based on the data I send every two weeks, we can do it in a year. But that target date is 20 days away every two weeks. Even if this "never" happens (i.e. we will still have packages using the old License notation in 10 years), it is the right thing to do. We decided that new packages MUST follow the new rules (and use the SPDX notation), and the old thing will eventually die out, very very slowly. And that's OK. It's better to have 25 % packages notconverted than having 25 % packages converted incorrectly. Moreover, when we see "GPLv2" we know what it means -- it has not been converted yet and might hide additional licenses. If you convert everything to "GPL-2.0-only" we can no longer distinguish between "effective GPL" and "GPL and no other license". (Note that I do not live in a fantasy world and I am well aware many packages were already converted from GPLv2 to GPL-2.0-only or similar by their maintainers without checking all the licenses. But that is their choise. We should, not encourage it and do it in bulk.) 2) Do nothing at all. That's the same as 1). 3) Automatically convert where there's a good chance it's correct. Good chance of correct is not good enough correct. If it is, let's change the rules to explicitly allow this kind of "effective license analysis" again and bulk convert everything. (If we do that, a lot of work was wasted, but let's not sue that as an argument not to do that, if it turns out to be the best solution.) In our group we made a list of what can be automatically converted. For RH folks this link https://docs.google.com/spreadsheets/d/1thDTCawJTewqMCgC1dDuKu4Hq9DCA57q0VDstFXTHvg/edit?usp=sharing for others this copy https://k00.fr/tnbu0zrs What I posted is what made sense to us. But there are licenses where it doesn't make sense to us. For example. wxWindows which will probably be rewritten to LGPL-2.0-or-later WITH WxWindows-exception-3.1 but the exception may be slightly different and needs to be checked. I disagree with the conclusions from that list wrt the GPL license family. I would be very happy if the migration was done manually. Every time I did a manual analysis, I discovered some files under other licenses. That is exactly the reason we cannot do it automatically. But manually checking everything under the current state of the tools is not realistic. That is the reality we need to accept. But it does not mean we can dodge the bullet by doing the proposed conversion. But there are a lot of people working in the background to have better tools. For example, I would like to publicly thank Robert-André Mauchin, who has spent a lot of time wrapping scancode=toolkit and its dependencies. This is an excellent tool for file analysis. We are just a small step away from completing all the reviews. When this is done, I'd like to create a tool to alert maintainers to new licenses that are used in a file but not in tarball. +1 For me, migrating these particular licenses is not a perfectly executed step. But it is a step forward. And any imperfections can be fixed in the future. The conversion can be done in the future as well. -- 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: [SPDX] Mass license change GPLv2 to GPL-2.0-only
On 18. 06. 24 18:46, Miroslav Suchý wrote: Hi. I am going to do the mass change of the license from GPLv2 to GPL-2.0-only Hi. How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar? Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically. Same for the other thread about LGPLv3 to LGPL-3.0-only conversion. -- 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
Orphaned python-astunparse
Hello. I orphaned python-astunparse. It used to be a dependency of python-gast (a dependency of pythran), but it is no longer so since at least Fedora 36. python-astor is the only dependent package in Rawhide, seems to be a leaf. python-astunparse is currently broken on Python 3.13 and I have not investigated why. The latest upstream commit is 5 years old. https://bugzilla.redhat.com/2279984 -- 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: Fedora 41 Python 3.13 mass rebuild status
On 10. 06. 24 17:34, Karolina Surma wrote: Hello, The Python 3.13 rebuild is in progress. We plan to merge the side tag soon. So far, we've successfully built 3528 out of 4109 source packages, with 581 remaining to be built. See the list of packages sorted by maintainers at the end of this mail. If your package fails because there is a non-dependency problem, you might have already received a bugzilla from us in the past. If the build failure is related to changes in Python 3.13, it should contain some hints about the problem. If you haven't received a bugzilla from us yet, feel free to open a new one and block the PYTHON3.13 tracking bug. You can verify your package builds with Python 3.13 via a scratch build: $ koji build --scratch f41-python or $ fedpkg build --scratch --target f41-python If successful, you can submit a build to the side tag from the rawhide branch in dist-git repository via: $ fedpkg build --target f41-python Please, don't build Python packages in regular rawhide now. After the side tag is merged, we'll let you know when it's safe to build in regular rawhide again. The remaining failures can be fixed afterwards. I requested the side tag to be merged. https://pagure.io/releng/issue/12155 If you build for f41-python now, there is a risk that the build will fail at tagging time if the side tag is merged during the build. I don't recommend building long builds. Please, still don't build Python packages in rawhide until the side tag is fully merged. Thank you for your patience. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 10. 06. 24 15:07, Tom Stellard wrote: On 5/31/24 01:55, Karolina Surma wrote: Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there? It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 06. 06. 24 16:03, Michael J Gruber wrote: Karolina Surma venit, vidit, dixit 2024-06-06 14:17:10: Hi, On 6/6/24 12:41, Michael J Gruber wrote: Hi there, I'm somewhat confused by the two different coprs @python/python3.13-b1 @python/python3.13 What is the role of which? @python/python3.13 is the main copr used for the continuous Python rebuild since alpha1 and a testing bed for the package maintainers. As its environment rapidly changes, sometimes the obsolete package versions are pulled into the buildroot. In order to simulate the current Fedora environment as close as possible, last week we created a python3.13-b1 copr - a testing repository to bootstrap Python (again) from scratch and make sure we haven't omitted something by accident. I have a package (notmuch) which succeeds locally in mock (against python 3.13) and in @python/python3.13 but fails in @python/python3.13-b1. The failure is probably related to gdb (the python module) usage in a test. My guess is the "main" copr was still using some older package builds, while the python3.13-b1 only contains the newest versions and that exposed the issue in notmuch. We're currently rebuilding everything with Python 3.13.0~beta2 in the main copr and will know in a few hours whether notmuch is still affected. @python/python3.13-b1 was used as a basis for bugzilla, it appears. (The bz entry points to instructions which are not filled in, btw.) Apologies for the inconsistent instructions, that's an oversight. Thanks for the clarification, and no need to apologize :) BTW: With current @python/python3.13-b1, the problem seems to be scripting gdb: ``` /etc/gdbinit:9: Error in sourced command file: Scripting in the "Python" language is not supported in this copy of GDB. /builddir/build/BUILD/notmuch-0.38.3-build/notmuch-0.38.3/test/atomicity.py:11: Error in sourced command file: Undefined command: "import". Try "help". ``` This is from mock --shell. (notmuch's test suite makes it hard to spot these things the easy way.) So, let's hope gdb with py 3.13.0~beta2 will fix scripting. gdb is built twice in the rebuild. The first build is without_python. notmuch probably needs the second build, but there is no way to express that via RPM BuildRequires (unless gdb starts providing something like gdb(python)). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On 29. 05. 24 13:59, Richard W.M. Jones wrote: On Wed, May 29, 2024 at 01:46:43PM +0200, Miro Hrončok wrote: On 29. 05. 24 13:38, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=118234666 It failed right at the end with this mysterious error: GenericError: srpm mismatch for /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: (none) (expected ocaml-5.2.0-1.fc41.src.rpm) I have just now kicked off another build in case this was a one-off, but anyone got ideas about this? RPM 4.20 regression. Fix is being cooked at https://src.fedoraproject.org/rpms/rpm/c/9042b409567e8479d6ddafc26e33badbe3bb3457?branch=rawhide I see the rpm package build containing this one failed, with the same failure in debuginfo generation :-( (https://koji.fedoraproject.org/koji/taskinfo?taskID=118237702) Is the bad rpm package going to be untagged? We'll use side tags to build it with old rpm. I was planning to do the OCaml 5.2 rebuild today, but if RPM is full of regressions maybe that's not such a good idea. What do you think? I suggest waiting a day. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GenericError: srpm mismatch for [debuginfo file]
On 29. 05. 24 13:38, Richard W.M. Jones wrote: https://koji.fedoraproject.org/koji/taskinfo?taskID=118234666 It failed right at the end with this mysterious error: GenericError: srpm mismatch for /mnt/koji/work/tasks/4737/118234737/ocaml-ocamldoc-debuginfo-5.2.0-1.fc41.x86_64.rpm: (none) (expected ocaml-5.2.0-1.fc41.src.rpm) I have just now kicked off another build in case this was a one-off, but anyone got ideas about this? RPM 4.20 regression. Fix is being cooked at https://src.fedoraproject.org/rpms/rpm/c/9042b409567e8479d6ddafc26e33badbe3bb3457?branch=rawhide -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-05-20)
On 20. 05. 24 22:59, Stephen Gallagher wrote: * AGREED: FESCo will permit the inclusion of binaries provided by upstream Python and FFI exclusively for the purposes of loading the installer on MacOS since we have no reasonable way to cross-compile for that platform at this time. (+5, 0, -4) (@sgallagh:fedora.im, 20:01:08) I am a tad sad that this was approved by FESCo without being first discussed with the wider community. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to retire mlocate
On 21. 05. 24 12:29, Fabio Valentini wrote: On Mon, May 20, 2024 at 2:42 PM Michal Sekletar wrote: On Fri, May 17, 2024 at 6:14 PM Michal Sekletar wrote: Hi everyone, We have had a plocate as a drop-in replacement for mlocate for quite a while now. My intention is to retire the mlocate package next week in order to prevent duplication and so that we can focus only on plocate going forward. mlocate is now retired in Rawhide. https://src.fedoraproject.org/rpms/mlocate/c/7277dd5f59db126d1046a6aa5c4077a597dc?branch=rawhide Thanks for the heads-up! Should the package also be added to fedora-obsolete-packages so that it is - if installed - removed on upgrade to Fedora 41? If a specific replacement exists (plocate), I think it should Obsolete it explicitly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
On 20. 05. 24 16:37, Aoife Moloney wrote: Hi Folks, After _much_ troubleshooting and some wonderful folks working with me to help resolve the issues that littered the elections today, I am pleased to say all issues have been resolved, or at least I live in hope that they are! :crosses fingers: ... If you have voted in Council and/or Mindshare, and did not have a claim link for your badge, please revisit your vote as the link has been updated and you should be able to access it. If you can't, email me directly and I will manually award this to you (I cant see who voted so I can't do this without knowing who to send it to). I'm afraid the badge claim link is expired now: """ 410 Gone This resource is no longer available. No forwarding address is given. That invitation is expired. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Elections - Voting is now open!
On 20. 05. 24 1:04, Aoife Moloney wrote: Hi all, The F40 elections have now officially opened after a little delay. You can find all of the candidate details in the Elections blog post[1]. We have open positions in Fedora Council, EPEL Steering Committee, Mindshare and Fedora Engineering Steering Committee (FESCo) and the voting period will close on Thursday 30th May @ 23:59:59 UTC sharp so please do take some time to read the wonderful candidate interviews we have received for the various open positions, cast your vote and dont forget to claim your Fedora badge too! [1] https://communityblog.fedoraproject.org/elections-voting-is-now-open/ <https://communityblog.fedoraproject.org/elections-voting-is-now-open/> Hello, there is a "None None" candidate to the EPEL Steering Committee. The link leads to Troy Dawson (tdawson) interview. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 15. 05. 24 13:31, Vít Ondruch wrote: I am saying that Python is bad example and nobody should follow it. I respectfully disagree. The LLVM maintainers think it is a good example worth following. So did the NodeJS maintainers. Name-versioning all the components makes things so much easier for the maintainers. The component name does not matter to the "normal" users. It only matters to experienced packagers, but those should be capable of dealing with that. (The Python 3 vs Python thing obviously is horrible, and nobody should ever do anything like that again.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 15. 05. 24 10:08, Vít Ondruch wrote: Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a): On 14. 05. 24 16:02, Vít Ondruch wrote: Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a): On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. ~~~ $ rpm -q python package python is not installed ~~~ Why? Because it is called python3. $ rpm -q python3 python3-3.12.3-2.fc39.x86_64 I thought this discussion is about python3.12 vs python3.13, not about python vs python3. I supposed the reason it is called python3 and not python is well know at this point (but if it is not, let me know and I'll try to explain). We are in 2024, so I suppose we could rename everything python3 to python now, I just worry that it would be a lot of effort for not much benefit. Even if `# dnf install python` does something, it still won't install `python` package. Well, it installs the python-unverisoned-command package. Which requires python3. So it install python. Why does it matter? What are you trying to demonstrate here? (Don't take me wrong, I always appreciate good criticism, I juts don't understand what are you suggesting we should do.) Do you suggest to rename python-unversioned-command to python? Do you suggest to rename python3 to python? Do you suggest to rename the python3.12 component to python? (As names of the components started this discussion.) Or is it something else? Every time I bring up such discussion, I am told "the reason it is called python3 and not python is well know" and yes, it is know to some, including me. But advocating for less experienced users. I advocating for users which are not experts on Python ecosystem. I am advocating for conventions. I am trying to demonstrate that things should be obvious. There is "Python" language. Not "Python 3" language. There is e.g. https://www.python.org/ not https://www.python3.org/ etc. Therefore, I'd rather hear "you are right, that does not make too much sense (these days). It is confusing and it is about the time to make the things right (finally)". In your words "We are in 2024, so I suppose we could rename everything python3 to python now" is what I would appreciate. So you say "python3" should be renamed to "python". But this entire discussion started about component names (e.g. "python3.12") and your inability to tell which Python version is the default just by looking at the sources. I am not disagreeing with you. I just don't see how we suddenly discuss a completely different thing. Anyway, let me tell you: You are right, calling the package(s) "python3" does not make too much sense any more. It might be confusing and it might be about the time to make things right by renaming ~4200 packages back to "python". Feel free to propose a detailed plan of execution. Note that I won't do it, because I don't think the benefits outweighs the necessary work. However, if there is a volunteer to drive this, I am happy to review the proposal and share my feedback. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 14. 05. 24 16:02, Vít Ondruch wrote: Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a): On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. ~~~ $ rpm -q python package python is not installed ~~~ Why? Because it is called python3. $ rpm -q python3 python3-3.12.3-2.fc39.x86_64 I thought this discussion is about python3.12 vs python3.13, not about python vs python3. I supposed the reason it is called python3 and not python is well know at this point (but if it is not, let me know and I'll try to explain). We are in 2024, so I suppose we could rename everything python3 to python now, I just worry that it would be a lot of effort for not much benefit. Even if `# dnf install python` does something, it still won't install `python` package. Well, it installs the python-unverisoned-command package. Which requires python3. So it install python. Why does it matter? What are you trying to demonstrate here? (Don't take me wrong, I always appreciate good criticism, I juts don't understand what are you suggesting we should do.) Do you suggest to rename python-unversioned-command to python? Do you suggest to rename python3 to python? Do you suggest to rename the python3.12 component to python? (As names of the components started this discussion.) Or is it something else? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
When is Fedora 38 going EOL?
Hi, When is Fedora 38 going EOL? https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html says today https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say next week Which one is correct? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Hulk edition
On 10. 05. 24 22:45, Miroslav Suchý wrote: Dne 10. 05. 24 v 11:29 dop. Miro Hrončok napsal(a): So we can now have packages with uppercase AND/ORs and packages with lowercase and/ors and we can no longer quickly recognize SPDX expression by observing uppercase AND/ORs? That does not sound like improvement to me :/ This is very very frequent mistake. Mistake for people that does not have time to study the specification and thinks that the case variant does not matter. Recognizing if something is SPDX expression using uppercase operators is IMHO bad idea. What is wrong with `license-validate`? license-validate does not fit into my head. Seeing uppercase AND/OR does not mean the SPDX expression is correct, it only means it is an attempt of an SPDX expression. Which is often enough for me, when I read a specfile. I won't run license-validate on it when I am there to bump a vertsion, but I will notice the License uses and/or and hence I can do the SPDX conversion shile touching it (that is, up until SPDX 3). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Smaller buildroot for Perl packages
On 13. 05. 24 17:11, Frank Ch. Eigler wrote: Hi - I also did a test rebuild of all packages directly build-requiring systemtap-sdt-devel and identified these packages that really need the dtrace script: [...] (The logistic challenge there will be side-tag rebuilding all those after a systemtap subrpm split.) I don't understand why that would be necessary. Could you please explain why do you believe it would? OK, build-time dependency changes may not need the side tag but do need a spec update to prevent a FTBFS at next build. Only those packages that actually need dtrace would require changes. Such changes could land gradually as needed. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 13. 05. 24 20:04, Tulio Magno Quites Machado Filho wrote: Miro Hrončok writes: It first showed up in https://src.fedoraproject.org/rpms/python3.13/pull-request/58 The Ci has all the logs, e.g. https://kojipkgs.fedoraproject.org//work/tasks/8452/117468452/build.log Thanks for these links. It looks like this is happening because the tests are still using annocheck 12.40. I can't reproduce this issue locally with the current annocheck version available in rawhide (v12.53). annocheck 12.53 reports the following message: skip: fortify test because LTO compilation discards preprocessor options I suspect the Zuul rpminspect test runs on Fedora 38 which still has annocheck 12.40. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 13. 05. 24 15:38, Vít Ondruch wrote: And TBH, for me as a Fedora used with no special interest in Python, the current Python versioning sucks hard. How am I supposed to tell what is the current version just looking at e.g. the repository? Is it `python3.12` or is it already `python3.13`? Despite I have spent with Fedora more then a decade, answering such simple question is not trivial for me. I guess that for the user, the easiest way is to look at the RPMs. Users barely look into our repositories. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GIMP 3.0 in F41?
On 13. 05. 24 12:34, Daniel P. Berrangé wrote: On Mon, May 13, 2024 at 12:14:14PM +0200, Fabio Valentini wrote: On Mon, May 13, 2024, 11:50 Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: On Monday, 13 May 2024 at 01:00, Neal Gompa wrote: On Sun, May 12, 2024 at 4:59 PM Sérgio Basto wrote: https://src.fedoraproject.org/rpms/gimp3 What the heck? This should have been gimp2 for the old version, not gimp3 for the new version... Also, how did this pass review? License:LGPLv3+ And I'll answer myself: it hasn't or at least I can't find any review ticket. Nils, could you explain how this package ended up in Fedora? Standard procedure, everything seems to be in order: https://pagure.io/releng/fedora-scm-requests/issue/62152 The review exception is valid because it's an alternative version of an existing package, and Nils is also the maintainer of the existing package. It that exception automatic ? I thought it had to be explicitly requested from FPC ? eg in https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure It says: "The FPC can grant exceptions to the normal package review process. This may happen, for instance, if a large number of similar packages are being submitted at once or if a package is being updated to a new major version while the old version is being kept in the distribution with a different name. .. Just file a ticket here, set the component to "Review Process Exception" and explain (with detail) why you're requesting the exemption and the committee will consider it in the next meeting. " So gimp3 falls under the 2nd example documented there, but still sounds like an FPC ticket was needed ? This is documented here: https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process The section of the wiki page you linked should probably be updated/retired. Anyway, if packagers are abusing this exception to import packages which don't even build, perhaps we should revisit if this exception is needed. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LLVM Packaging Ideas for Fedora 41
On 27. 04. 24 6:34, Tom Stellard wrote: ... * Switch to python-style compat/main packages. In order to make the packaging more consistent between the main package (e.g. llvm) and the compat package (e.g. llvm18), we would retire the un-versioned dist-git for llvm, and create a new versioned dist-git for each new release (e.g. llvm19, llvm20, llvm21 etc.). We would then designate one of these as the 'main version', and that version would produce binary rpms that look like the current main package (i.e. llvm-libs instead of llvm19-libs). In Python, we did it this way because it was hard to keep one "python3" component that was different version in different Fedoras + multiple "python3.X" components that did (not) exist on certain Fedoras. Git cherry-pciks between branches were... hard. Merges were impossible. Having the component names release-agnostic simplified things us a lot. * Invert the order of compat/main packages. Instead of having the compat package be the old version, and the main package be the new version, we would have the compat package be newer and the main package be older. This would allow us to introduce a new version of llvm without impacting other packages that depend on the main version of LLVM. This allowed us to package new pre-releases of Python as soon as alpha 1 was out (we could even do pre-alphas, but so far there was not enough motivation). That makes it easier for users to test things early. It also allows *us* to test the RPM build early. It also allowed users of e.g. Fedora 38 to use Python 3.12 if they needed to (however, without the entire RPM-Python packages stack on top), despite Python 3.12 being the main Python in F39+ only. Overall, it works quite nicely. If anyone has any feedback on these ideas we'd like to hear it and are happy to discuss these more. +100 Any chance this gets partially implemented in older Fedoras? I'd appreciate llvm18 and clang18 in Fedora 39 (for Python 3.13 experimental JIT). https://github.com/python/cpython/blob/3.13/Tools/jit/README.md Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Smaller buildroot for Perl packages
On 10. 05. 24 17:16, Frank Ch. Eigler wrote: [...] I also did a test rebuild of all packages directly build-requiring systemtap-sdt-devel and identified these packages that really need the dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16, perl, php, mariadb10.11, and libvirt. Those would newly depend on a new package where we move the script to. (The logistic challenge there will be side-tag rebuilding all those after a systemtap subrpm split.) I don't understand why that would be necessary. Could you please explain why do you believe it would? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 10. 05. 24 18:59, Tulio Magno Quites Machado Filho wrote: Siddhesh Poyarekar writes: _FORTIFY_SOURCE (any level) should work perfectly with -O (any level). Is this new? Or do you mean any level where optimization is enabled? i.e. -On, where n >= 1 Anyway, a warning should be printed when using -O0 unless -Wno-cpp is also used. The debug build is -O0 -Wno-cpp. The optimized build is -O3. annocheck's source code even mention that -O2 might be needed. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 10. 05. 24 15:58, Siddhesh Poyarekar wrote: On 2024-05-10 06:41, Miro Hrončok wrote: Hello, when we build Python 3.13 with -O3 https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 I see the following annocheck problem: Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3 (lto) Looks like an annobin issue; do you you have build logs someone can look at? It first showed up in https://src.fedoraproject.org/rpms/python3.13/pull-request/58 The Ci has all the logs, e.g. https://kojipkgs.fedoraproject.org//work/tasks/8452/117468452/build.log The C flags have: -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -O3 Is -D_FORTIFY_SOURCE=3 not comaptible with -O3? Do I need to do somethign about this? _FORTIFY_SOURCE (any level) should work perfectly with -O (any level). That's what I thought as well. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
Hello, when we build Python 3.13 with -O3 https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 I see the following annocheck problem: Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3 (lto) The C flags have: -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -O3 Is -D_FORTIFY_SOURCE=3 not comaptible with -O3? Do I need to do somethign about this? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Hulk edition
On 10. 05. 24 10:55, Miroslav Suchý wrote: Hot news: SPDX v3 has been published. The biggest change for us is that license expression allows lowercase operators (and, or, with). This got into the specification because of your (Fedora maintainers) feedback! So we can now have packages with uppercase AND/ORs and packages with lowercase and/ors and we can no longer quickly recognize SPDX expression by observing uppercase AND/ORs? That does not sound like improvement to me :/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Testing package version is spec file
On 08. 05. 24 19:38, Brad Smith wrote:
I help maintain a package where upstream changed the process to
generate installed documentation. In version 1.30 and newer, the spec
file needs to use process A; in versions older than 1.30 (e.g. 1.29.x,
etc) the spec file needs to use process B. I am struggling to find a
workable solution to testing the version like this.
Can someone please point me in the right direction? Or useful example?
Something like this?
%if v"%{version}" >= v"1.30"
do this
%else
do that
%endif
That said, please don't do that. Do the necessary changes for 1.30+ only in the
specfile for 1.30+ in new Fedora(s), keep the specfile as it was with 1.29 in
the older Fedoras you still need to support.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: pipenv removal in F40
On 30. 04. 24 8:13, Mattia Verga via devel wrote: I vaguely remember that pipenv retirement was briefly discussed here on the ML, yet I was surprised that F40 doesn't have pipenv anymore. IMO, this would have been announced more prominently as a self contained change, as I expect more python developers to find out this too late. Well, the package was orphaned and later retired because nobody stepped up to take it. We don't usually file change proposals for package orphaning and neither we should -- packagers who do no longer have the resources to maintain a package rarely have resources to write documents about it. If you wish to help, I guess you can send a pull request to the release notes... Also, the official guide on https://developer.fedoraproject.org/tech/languages/python/pipenv.html should have been updated as well. ...or to this guide. (I agree it needs to be updated and/or removed.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On 13. 04. 24 10:04, Miro Hrončok wrote: On 13. 04. 24 2:33, Kevin Kofler via devel wrote: How much larger is Python at -O3 compared to -O2? And other packages? That is a good question, will measure. -O2 RPM size: python3-3.12.2-3.fc41.x86_6432638 python3-libs-3.12.2-3.fc41.x86_644246 -O3 RPM size: python3-3.12.2-3.O3.fc41.x86_64 32638 python3-libs-3.12.2-3.O3.fc41.x86_64 43389702 Difference of python3-libs: 500856 == 489 kB = 1.1678 % increase in size of pytohn3-libs itself or 1.1669 % of python3-libs+python3 combined size. (I added this to the change proposal.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
On 13. 04. 24 2:33, Kevin Kofler via devel wrote: How much larger is Python at -O3 compared to -O2? And other packages? That is a good question, will measure. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 07. 04. 24 17:47, Miro Hrončok wrote: Note that it produces incorrect results if the Release value is not numerical (or if it is a greater number than count of the commits since last bump). It will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 to 30 or even release 500 to 10. I converted all of my packages with it and in some cases I had to manually fix the results. E.g.: https://src.fedoraproject.org/rpms/printrun/pull-request/8 https://src.fedoraproject.org/rpms/pypy3.10/pull-request/15#comment-179619 https://src.fedoraproject.org/rpms/poly2tri/pull-request/2 + fixup commit on top https://src.fedoraproject.org/rpms/poly2tri/c/053f90 I had to push https://src.fedoraproject.org/rpms/simarrange/c/4ec0880c after a broked automated conversion. It's very hard to notice this when converting ~100 packages at the same time. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [SPDX] Mass license change AGPLv3+ to AGPL-3.0-or-later
On 12. 04. 24 11:22, Miroslav Suchý wrote: Hi. I am going to do the mass change of the license from AGPLv3+ to AGPL-3.0-or-later The proposed diff is in attachment. Affected packages: simarrange I had a look at this package of mine and realized I borked the rpmautospec conversion, so I opened https://src.fedoraproject.org/rpms/simarrange/pull-request/3 -- it includes the SPDX conversion. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 08. 04. 24 6:08, Carlos Rodriguez-Fernandez wrote: Not all commits correspond with a new release downstream, and not all commit messages are relevant to the end user to be part of the change log. For example, commits related with increasing gating test coverage efforts, or setting up gating.yaml itself. Another example is linting setting and/or configurations. How is that handled with autochangelog? Can we tell it to skip certain commits? Or should we include it all? Put [skip changelog] in the commit message. https://fedora-infra.github.io/rpmautospec-docs/autochangelog.html#skipping-changelog-entries -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
On 07. 04. 24 17:15, Zbigniew Jędrzejewski-Szmek wrote: Hi everyone, I'm revisting the topic of rpmautospec because I was doing some work on various packages, and it's annoying that some packages are using rpmautospec and others are not. All my packages have been converted, so in day-to-day work, I don't even think about %changelog. When working with other packages, I'll forget to update the Relase and/or %changelog. Today I was rebasing some pull requests in pagure, and the _only_ conflicts that I had were about Release and %changelog. I think it's time to switch to rpmautospec completely. Thus, the proposal: - new packages MUST use rpmautospec - packagers SHOULD convert their packages - provenpackagers MAY convert existing packages (e.g. when they want to push some fix or separately from other work) - people submitting pull requests against src.fp.o MAY also include a conversion in the pull request and packagers SHOULD merge it. I have some packages where the tooling isn't ready yet for %autorelease, so I put them on hold. I also have some packages with pre-release info still in the Release filed and moving it to Version with ~ (to use %autorelease) would make the package downgrade, so I am waiting for a next upstream release to do that. I think it's to early to force this. (FTR, 'rpmautospec convert' does the conversion, incl. the commit to dist-git. Manual conversion should not be used.) Note that it produces incorrect results if the Release value is not numerical (or if it is a greater number than count of the commits since last bump). It will happily convert release 0.1 to 3, 29.20130501hg26242d0aa7b8 to 30 or even release 500 to 10. I converted all of my packages with it and in some cases I had to manually fix the results. E.g.: https://src.fedoraproject.org/rpms/printrun/pull-request/8 https://src.fedoraproject.org/rpms/pypy3.10/pull-request/15#comment-179619 https://src.fedoraproject.org/rpms/poly2tri/pull-request/2 + fixup commit on top https://src.fedoraproject.org/rpms/poly2tri/c/053f90 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 27. 03. 24 16:03, Jens-Ulrik Petersen wrote: On Wed, Mar 27, 2024 at 9:46 PM Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: > Also botan got orphaned despite the FTI going away > <https://bugzilla.redhat.com/show_bug.cgi?id=2259559 <https://bugzilla.redhat.com/show_bug.cgi?id=2259559>> [1] ;-( > Could it be un-orphaned back? > [1] Seems FTI failed to close the bug fixed on 2024-03-07 It was closed after it was fixed. The update was stuck at beta freeze and nobody associated the FTI bugzilla with it. No, it was reported <https://bugzilla.redhat.com/show_bug.cgi?id=2259559#c5> installable (comment 5) on 7th March by fti-bugs but was not closed as it should have been then. On Fedora 41 only. Then it was orphaned <https://bugzilla.redhat.com/show_bug.cgi?id=2259559#c6> (comment 6) on 21st March. Yes, because it was still NEW and not acted upon by the maintainer. Then again reported <https://bugzilla.redhat.com/show_bug.cgi?id=2259559#c7> installable (comment 7) on 25th which actually closed the bug. On Fedora 40. Which is why I am asking if the orphaned can be reverted, please. Yes, if the previous maintainer is still interested in maintaining it, they can take the package back by clicking on the *Take* button. It makes no sense to me to assign it back to them if they are not interested. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 25. 03. 24 7:48, Jens-Ulrik Petersen wrote: Also botan got orphaned despite the FTI going away <https://bugzilla.redhat.com/show_bug.cgi?id=2259559> [1] ;-( Could it be un-orphaned back? Yes, by clicking the *Take* button. [1] Seems FTI failed to close the bug fixed on 2024-03-07 It was closed after it was fixed. The update was stuck at beta freeze and nobody associated the FTI bugzilla with it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Default NodeJS stream packages with versioned names are not available
On 20. 03. 24 17:35, Jan Staněk wrote:
Hello all,
recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
slight problem: when a NodeJS stream is the default one, versioned
packages (i.e. nodejs20) are not generated and are not installable.
For example, on current rawhide, I cannot install `nodejs20` package,
only `nodejs`; this will give me the version 20.x as expected.
The problem is that this complicates the CI setup,
and requires me to take into account which Fedora I'm currently on.
As an example, when adding tests for nodejs20 dist-git[1],
I would like to simply specify `requires: nodejs20` into the test
metadata. However, with the current setup, I would need something akin
to the following (pseudocode, I did not really test if that would work):
requires:
- {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}
In addition to being more complicated, this will also break if the
default stream for a given Fedora version ever change
(which is not unlikely to happen, as the upstream release schedule
is not really synchronized with the Fedore one).
---
I recall that the current status is the result of already existing
long discussion, with associated debugging, so I would like to have this
solved with as minimal disruption as possible. That being said,
what is the reason for having the non-versioned packages (`nodejs`) *in
stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
to them?
The non-versioned packages could then require the appropriate versioned
ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
/usr/lib/node_modules → /usr/lib/node_modules_20, etc.).
Python does this similarly to nodejs (we have python3.11, pytohn3, python3.13
in rawhide today), with one difference. The python3 package provides
python3.12. So when you do:
requires:
- python3.12
It just works.
I believe nodejs should provide nodejs20, the same way.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Follow up for bash-completion pkgconfig file packaging change
On 18. 03. 24 17:07, Fabio Valentini wrote:
I wonder why these packages rely in pkg-config and don't just install
to `%{bash_completions_dir}`?
Because they either predate the macro or the thing was copied from another
package that predates it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Follow up for bash-completion pkgconfig file packaging change
On 18. 03. 24 16:33, Mamoru TASAKA wrote: Hello, all: After investigating the recent Fedora-Security-Live livespin compose failure on F-41, it is found that this is caused because: - Recently on F-41, bash-completion packaging changed so that pkgconfig file is moved into -devel subpackage: (bash-completion-2.11-15.fc41) https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide - A package (lynis) installing bash-completion file into the directory $(pkg-config --variable=completionsdir bash-completion), had "BuildRequires: bash-completion", but did not have "BuildRequires: pkgconfig(bash-completion)". - So after the above bash-completion side packaging change, the above command line was expanded to the empty string, so the completion file was installed into the wrong directory, which caused conflict with filesystem rpm. I've commented about his at https://bugzilla.redhat.com/show_bug.cgi?id=1457164#c8 a month ago but so far no response. So on F-41(rawhide), the packages * trying to install bash-completion file using $(pkg-config --variable=completionsdir bash-completion) * which have "BuildRequires: bash-completion", but do NOT have "BuildRequires: pkgconfig(bash-completion)" may be installing completion file into wrong directories after rebuild. (At least, I tried rebuilding cowsay and actually it installs completion file into the wrong directory). The possible packages which may need fixing are: ... 13 python-django/rawhide/python-django.spec bashcompdir=$(pkg-config --variable=completionsdir bash-completion) I opened https://src.fedoraproject.org/rpms/python-django/pull-request/37 5 days ago. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guiding co-dependent RPM packages to swap nicely
On 08. 03. 24 11:43, Florian Weimer wrote: * Miro Hrončok: On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*. Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20 However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin. Is there something I can do as a package maintainer to "guide" the co-dependent swap case? Have you tried using “dnf shell” and entering both swap commands there/ I am actually looking for a metadata solution that would guide the package manager to do it for me, not for a way to swap them manually. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
