[Bug 2124136] New: Please branch and build perl-ExtUtils-XSBuilder in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2124136 Bug ID: 2124136 Summary: Please branch and build perl-ExtUtils-XSBuilder in epel9 Product: Fedora EPEL Version: epel9 Hardware: All OS: Linux Status: NEW Component: perl-ExtUtils-XSBuilder Severity: low Assignee: spo...@gmail.com Reporter: bo...@rexursive.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com Target Milestone: --- Classification: Fedora Description of problem: Please create/build epel9 branch perl-ExtUtils-XSBuilder. This is required for building libapreq2. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2124136 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Adding Package to side-tag
On Sat, Sep 03, 2022 at 08:32:47PM +1000, Frank Crawford wrote: > > The document I used > was > https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages > > It was the only place I could find that really talked about side-tags, > and wait-repo looks only mentioned in passing. Once you know it is > needed it is more obvious, but not if you haven't used them much > before. Well, it does say: "The latter is important if any builds depend on previous ones in the side tag. Use koji wait-repo --build to ensure that the respective build is available in the build root for subsequent builds. " But if you can see a way to be more clear there, perhaps you could put in a PR? kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123426] perl-Locale-Codes-3.72 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123426 --- Comment #7 from Fedora Update System --- FEDORA-2022-66cf5d4e88 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-66cf5d4e88` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-66cf5d4e88 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123426 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123426] perl-Locale-Codes-3.72 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123426 --- Comment #6 from Fedora Update System --- FEDORA-2022-5213abf65a has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-5213abf65a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5213abf65a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123426 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Build failure on f37-x86_64, stdlib.h: No such file or directory
Bruno Postle wrote on 2022/09/04 17:44: Can someone give me hint as to what I'm doing wrong here, I have a C++ package that builds fine for f35 & f36 with x86_64 & aarch64, but which fails on f37-x86_64 (the build is ok on f37-aarch64): https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/build/4771106/ [ 0%] Building CXX object CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o /usr/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DHAS_SCHEMA_2x3 -DHAS_SCHEMA_4 -DHAS_SCHEMA_4x1 -DHAS_SCHEMA_4x2 -DHAS_SCHEMA_4x3 -DHAS_SCHEMA_4x3_rc1 -DHAS_SCHEMA_4x3_rc2 -DHAS_SCHEMA_4x3_rc3 -DHAS_SCHEMA_4x3_rc4 -DIFC_SHARED_BUILD -DIfcParse_EXPORTS -DSCHEMA_SEQ="(2x3)(4)(4x1)(4x2)(4x3_rc1)(4x3_rc2)(4x3_rc3)(4x3_rc4)(4x3)" -DUSE_MMAP -DWITH_GLTF -DWITH_HDF5 -DWITH_IFCXML -DWITH_OPENCOLLADA -I/usr/include/opencascade -I/usr/include/COLLADABaseUtils -I/usr/include/COLLADAStreamWriter -I/usr/include/libxml2 -isystem /usr/include -lxml2 -DNDEBUG -O3 -fPIC -Wall -Wextra -Wno-maybe-uninitialized -Wno-deprecated-copy -fPIC -DIFC_PARSE_EXPORTS -std=gnu++14 -MD -MT CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -MF CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o.d -o CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -c /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp In file included from /usr/include/c++/12/ext/string_conversions.h:41, from /usr/include/c++/12/bits/basic_string.h:3960, from /usr/include/c++/12/string:53, from /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp:27: /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ This command line contains "-isystem /usr/include", on other architectures this is not included, this is the difference. But currently I cannot figure out where this "-isystem /usr/include" came from. Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1934532] EPEL8 Request: perl-Astro-FITS-CFITSIO
https://bugzilla.redhat.com/show_bug.cgi?id=1934532 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Astro-FITS-CFITSIO-1.1 |perl-Astro-FITS-CFITSIO-1.1 |5-1.el8 |5-1.el8 ||perl-Astro-FITS-CFITSIO-1.1 ||5-1.el9 --- Comment #8 from Fedora Update System --- FEDORA-EPEL-2022-d6bb4559c9 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1934532 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1934532] EPEL8 Request: perl-Astro-FITS-CFITSIO
https://bugzilla.redhat.com/show_bug.cgi?id=1934532 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Fixed In Version||perl-Astro-FITS-CFITSIO-1.1 ||5-1.el8 Last Closed||2022-09-04 22:13:08 --- Comment #7 from Fedora Update System --- FEDORA-EPEL-2022-d4d0379152 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1934532 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 side tag after branching point
Here we go: - F37: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8414514ae6 - rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c2d48988e After the mass rebuild in the F37 side tag, we tagged all builds also in a rawhide side tag, rebuilt everything in one go, untagged the F37 builds, and created the update for rawhide. Quick and easy. Thanks all for your help. Iñaki On Wed, 24 Aug 2022 at 19:04, Kevin Fenzi wrote: > > Just to chime in from a releng perspective here... > > IMHO you should do builds for f38 now also (either by making a side tag > and bootstrapping them just like was done for f37, or tagging f37 builds > you need into the f38 sidetag). > > While it's technically possible to push the f37 builds into rawhide > also, it would take releng manually tagging them in, bypassing bodhi, > gating and CI completely. It's much better to build again for > f38/rawhide and let those builds get checked by gating and CI, etc. > > If you run into any problems, let me know... > > kevin > ___ > 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 -- Iñaki Úcar ___ 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: Questions regarding %pyproject_buildrequires
On 04-09-2022 22:52, Miro Hrončok wrote: On 04. 09. 22 22:08, Sandro wrote: On 04-09-2022 20:42, Miro Hrončok wrote: On 04. 09. 22 14:15, Sandro wrote: Hi, Hi. I'm tinkering with a package in review, trying to understand the Python RPM build process. The package is hatch-fancy-pypi-readme [1]. The package uses hatch for build, but it includes a non-license file, AUTHORS.md, which I thought would be trivial to patch around, so it's not included in the RPM. I don't understand why do you want to do this in the first place. What is the issue with the file? Well, fedora-review complains about the file not being included in the package as %license. There's more details in the package review: https://bugzilla.redhat.com/show_bug.cgi?id=2123618 An automated tool complains about that file not being marked as %license. I don't understand why is that a reason to remove it entirely. I've commented on the bugzilla for other options. Thank you for your input. Removing the file is just one option, of course, and possibly not the best. Adding it to %doc is what I suggested in the review when fedora-review complaint. I was in tinkering mood and I actually learned quite a bit along the way. What I didn't expect was tests failing once AUTHORS.md is removed. I patched the pyproject.toml and added: [tool.hatch.build] exclude = ["AUTHORS.md"] I don't know hatch, so I cannot tell whether this does something useful. Note that upstream has committed https://github.com/hynek/hatch-fancy-pypi-readme/commit/3b17e39c which might solve this (or not, not sure). I don't know much about Hatch myself, but that's the Hatch way of excluding files according to their documentation. But since Hatch does not appear to be used in the RPM build process, this has no effect. I am pretty sure hatch *is* used during the build. It creates the licenses directory in /usr/lib/python3.11/site-packages/hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/ It is indeed as can be seen in the output of 'python3 -m build': * Installing packages in isolated environment... (hatchling) Then I realized %pyproject_buildrequires has the option -w enabled, producing a wheel for metadata extraction. So, I added a patch, putting a MANIFEST.in in the root dir of the project with one line: exclude AUTHORS.md The MANIFEST.in file does not say which files will be installed. It is used by distutils and/or setuptools to determine which files will be in the source tarball. I am not entirely sure if hatch reads that file at all. Clear. Yet, strangely enough with the described MANIFEST.in in place and running 'python3 -m build --sdist', the resulting tar.gz archive still has the AUTHORS.md file in it. That only confirms what I thought: hatch does not even read this file. It is distutils/setuptools specific. Understood. Beginners mistake on my part. Yet the whl archive still contains the file: hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/AUTHORS.md and so does the final RPM. Do I have to resort to manually removing the file in %prep? If you insist on removing that file, deleting it in %prep sounds like much easier option than patching pyproject.toml. However, I'd keep it. Here is where it gets interesting. I can not do without the file or the tests will fail. See the review bug mentioned above. Just add a 'rm -f AUTHORS.md' to %prep in the spec file. But keeping it around, fedora-review (rpmlint) will keep complaining about its presence as a not included license file since it is installed in the license dir together with the LICENSE.txt file. fedora-review is not always right. Please don't try to do ugly things to make it happier. Anyway, see https://bugzilla.redhat.com/show_bug.cgi?id=2123618#c6 I encountered another issue with %pyproject_buildrequires when passing the -t option for automatic test requirements. I wanted to see if I can get rid of the extra BuildRequires in the submitters spec file [2], so I commented out all but python3-dev and python3-test BuildRequires and added -t to %pyproject_buildrequires. That made the build fail with: No matching package to install: 'python3dist(pytest-icdiff)' Yet, I don't see any test or other python module importing icdiff. Building with the original spec file, tests are run and succeed. Is that a known issue with the -t option? Or am I missing something? The pytest-icdiff dependency is listed by upstream as their test dependency for tox (-t stands for tox): https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/tox.ini#L49 -> https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/pyproject.toml#L50 Thank you for the pointer. I missed looking in the pyproject.toml file. I searched in the tests dir. The -t option reads that and generates the BuildRequires. If it is not needed, I suggest talking to upstream about why is this listed. In the meantime, you have 2 options to avoid the unwanted dependency: - don't use -t and list test
Re: Questions regarding %pyproject_buildrequires
On 04. 09. 22 22:08, Sandro wrote: On 04-09-2022 20:42, Miro Hrončok wrote: On 04. 09. 22 14:15, Sandro wrote: Hi, Hi. I'm tinkering with a package in review, trying to understand the Python RPM build process. The package is hatch-fancy-pypi-readme [1]. The package uses hatch for build, but it includes a non-license file, AUTHORS.md, which I thought would be trivial to patch around, so it's not included in the RPM. I don't understand why do you want to do this in the first place. What is the issue with the file? Well, fedora-review complains about the file not being included in the package as %license. There's more details in the package review: https://bugzilla.redhat.com/show_bug.cgi?id=2123618 An automated tool complains about that file not being marked as %license. I don't understand why is that a reason to remove it entirely. I've commented on the bugzilla for other options. I patched the pyproject.toml and added: [tool.hatch.build] exclude = ["AUTHORS.md"] I don't know hatch, so I cannot tell whether this does something useful. Note that upstream has committed https://github.com/hynek/hatch-fancy-pypi-readme/commit/3b17e39c which might solve this (or not, not sure). I don't know much about Hatch myself, but that's the Hatch way of excluding files according to their documentation. But since Hatch does not appear to be used in the RPM build process, this has no effect. I am pretty sure hatch *is* used during the build. It creates the licenses directory in /usr/lib/python3.11/site-packages/hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/ Then I realized %pyproject_buildrequires has the option -w enabled, producing a wheel for metadata extraction. So, I added a patch, putting a MANIFEST.in in the root dir of the project with one line: exclude AUTHORS.md The MANIFEST.in file does not say which files will be installed. It is used by distutils and/or setuptools to determine which files will be in the source tarball. I am not entirely sure if hatch reads that file at all. Clear. Yet, strangely enough with the described MANIFEST.in in place and running 'python3 -m build --sdist', the resulting tar.gz archive still has the AUTHORS.md file in it. That only confirms what I thought: hatch does not even read this file. It is distutils/setuptools specific. Yet the whl archive still contains the file: hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/AUTHORS.md and so does the final RPM. Do I have to resort to manually removing the file in %prep? If you insist on removing that file, deleting it in %prep sounds like much easier option than patching pyproject.toml. However, I'd keep it. Here is where it gets interesting. I can not do without the file or the tests will fail. See the review bug mentioned above. Just add a 'rm -f AUTHORS.md' to %prep in the spec file. But keeping it around, fedora-review (rpmlint) will keep complaining about its presence as a not included license file since it is installed in the license dir together with the LICENSE.txt file. fedora-review is not always right. Please don't try to do ugly things to make it happier. Anyway, see https://bugzilla.redhat.com/show_bug.cgi?id=2123618#c6 I encountered another issue with %pyproject_buildrequires when passing the -t option for automatic test requirements. I wanted to see if I can get rid of the extra BuildRequires in the submitters spec file [2], so I commented out all but python3-dev and python3-test BuildRequires and added -t to %pyproject_buildrequires. That made the build fail with: No matching package to install: 'python3dist(pytest-icdiff)' Yet, I don't see any test or other python module importing icdiff. Building with the original spec file, tests are run and succeed. Is that a known issue with the -t option? Or am I missing something? The pytest-icdiff dependency is listed by upstream as their test dependency for tox (-t stands for tox): https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/tox.ini#L49 -> https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/pyproject.toml#L50 Thank you for the pointer. I missed looking in the pyproject.toml file. I searched in the tests dir. The -t option reads that and generates the BuildRequires. If it is not needed, I suggest talking to upstream about why is this listed. In the meantime, you have 2 options to avoid the unwanted dependency: - don't use -t and list test dependencies manually instead - patch/sed it out from pyproject.toml It looks like it's not being used (any more). Building the package without -t and without listing python3dist(pytest-icdiff), which is not even available in Fedora, succeeds. The package is for fancier diffs when tests fail. It seems to be what upstream prefers when they run tests but I agree that it is not important in the RPM package. Similarly, upstream lists coverage as their test dependency and we should not depend on that downstream, see
Re: Questions regarding %pyproject_buildrequires
On 04-09-2022 20:42, Miro Hrončok wrote: On 04. 09. 22 14:15, Sandro wrote: Hi, Hi. I'm tinkering with a package in review, trying to understand the Python RPM build process. The package is hatch-fancy-pypi-readme [1]. The package uses hatch for build, but it includes a non-license file, AUTHORS.md, which I thought would be trivial to patch around, so it's not included in the RPM. I don't understand why do you want to do this in the first place. What is the issue with the file? Well, fedora-review complains about the file not being included in the package as %license. There's more details in the package review: https://bugzilla.redhat.com/show_bug.cgi?id=2123618 I patched the pyproject.toml and added: [tool.hatch.build] exclude = ["AUTHORS.md"] I don't know hatch, so I cannot tell whether this does something useful. Note that upstream has committed https://github.com/hynek/hatch-fancy-pypi-readme/commit/3b17e39c which might solve this (or not, not sure). I don't know much about Hatch myself, but that's the Hatch way of excluding files according to their documentation. But since Hatch does not appear to be used in the RPM build process, this has no effect. Then I realized %pyproject_buildrequires has the option -w enabled, producing a wheel for metadata extraction. So, I added a patch, putting a MANIFEST.in in the root dir of the project with one line: exclude AUTHORS.md The MANIFEST.in file does not say which files will be installed. It is used by distutils and/or setuptools to determine which files will be in the source tarball. I am not entirely sure if hatch reads that file at all. Clear. Yet, strangely enough with the described MANIFEST.in in place and running 'python3 -m build --sdist', the resulting tar.gz archive still has the AUTHORS.md file in it. Yet the whl archive still contains the file: hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/AUTHORS.md and so does the final RPM. Do I have to resort to manually removing the file in %prep? If you insist on removing that file, deleting it in %prep sounds like much easier option than patching pyproject.toml. However, I'd keep it. Here is where it gets interesting. I can not do without the file or the tests will fail. See the review bug mentioned above. Just add a 'rm -f AUTHORS.md' to %prep in the spec file. But keeping it around, fedora-review (rpmlint) will keep complaining about its presence as a not included license file since it is installed in the license dir together with the LICENSE.txt file. I encountered another issue with %pyproject_buildrequires when passing the -t option for automatic test requirements. I wanted to see if I can get rid of the extra BuildRequires in the submitters spec file [2], so I commented out all but python3-dev and python3-test BuildRequires and added -t to %pyproject_buildrequires. That made the build fail with: No matching package to install: 'python3dist(pytest-icdiff)' Yet, I don't see any test or other python module importing icdiff. Building with the original spec file, tests are run and succeed. Is that a known issue with the -t option? Or am I missing something? The pytest-icdiff dependency is listed by upstream as their test dependency for tox (-t stands for tox): https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/tox.ini#L49 -> https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/pyproject.toml#L50 Thank you for the pointer. I missed looking in the pyproject.toml file. I searched in the tests dir. The -t option reads that and generates the BuildRequires. If it is not needed, I suggest talking to upstream about why is this listed. In the meantime, you have 2 options to avoid the unwanted dependency: - don't use -t and list test dependencies manually instead - patch/sed it out from pyproject.toml It looks like it's not being used (any more). Building the package without -t and without listing python3dist(pytest-icdiff), which is not even available in Fedora, succeeds. [1] https://github.com/hynek/hatch-fancy-pypi-readme [2] https://pnemade.fedorapeople.org/python-hatch-fancy-pypi-readme.spec -- Sandro ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: [Messaging] RabbitMQ for EPEL 9
On Sat, 2022-09-03 at 13:39 -0500, Richard Shaw wrote: > Have you tried building the package yourself yet? When asking for > someone to support an EPEL branch it's not always straightforward. I > tried building the rawhide branch for EPEL 9 and ran into the > following: > > No matching package to install: 'elixir' > No matching package to install: 'erlang >= 23' I breifly looked into this a couple of months ago as someone asked me about it at work. From what I recall, erlang is mostly doable, but elixir is a problem because it pulls in a bunch of other stuff and seems to have a bit of a bootstrapping problem. I'm sure someone familiar with this ecosystem could get it sorted out, but that's not me so I ended up leaving it alone. Cheers Davide ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 6:29 PM Alexander Bokovoy wrote: > You might want to watch our Nest with Fedora 2022 talk. More features > are coming too, we are working on a direct FIDO2 integration in SSSD and > FreeIPA . Thanks for the update. Good news about the progress. I will watch the talks. ___ 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: Questions regarding %pyproject_buildrequires
On 04. 09. 22 14:15, Sandro wrote: Hi, Hi. I'm tinkering with a package in review, trying to understand the Python RPM build process. The package is hatch-fancy-pypi-readme [1]. The package uses hatch for build, but it includes a non-license file, AUTHORS.md, which I thought would be trivial to patch around, so it's not included in the RPM. I don't understand why do you want to do this in the first place. What is the issue with the file? I patched the pyproject.toml and added: [tool.hatch.build] exclude = ["AUTHORS.md"] I don't know hatch, so I cannot tell whether this does something useful. Note that upstream has committed https://github.com/hynek/hatch-fancy-pypi-readme/commit/3b17e39c which might solve this (or not, not sure). Then I realized %pyproject_buildrequires has the option -w enabled, producing a wheel for metadata extraction. So, I added a patch, putting a MANIFEST.in in the root dir of the project with one line: exclude AUTHORS.md The MANIFEST.in file does not say which files will be installed. It is used by distutils and/or setuptools to determine which files will be in the source tarball. I am not entirely sure if hatch reads that file at all. Yet the whl archive still contains the file: hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/AUTHORS.md and so does the final RPM. Do I have to resort to manually removing the file in %prep? If you insist on removing that file, deleting it in %prep sounds like much easier option than patching pyproject.toml. However, I'd keep it. I encountered another issue with %pyproject_buildrequires when passing the -t option for automatic test requirements. I wanted to see if I can get rid of the extra BuildRequires in the submitters spec file [2], so I commented out all but python3-dev and python3-test BuildRequires and added -t to %pyproject_buildrequires. That made the build fail with: No matching package to install: 'python3dist(pytest-icdiff)' Yet, I don't see any test or other python module importing icdiff. Building with the original spec file, tests are run and succeed. Is that a known issue with the -t option? Or am I missing something? The pytest-icdiff dependency is listed by upstream as their test dependency for tox (-t stands for tox): https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/tox.ini#L49 -> https://github.com/hynek/hatch-fancy-pypi-readme/blob/22.3.0/pyproject.toml#L50 The -t option reads that and generates the BuildRequires. If it is not needed, I suggest talking to upstream about why is this listed. In the meantime, you have 2 options to avoid the unwanted dependency: - don't use -t and list test dependencies manually instead - patch/sed it out from pyproject.toml [1] https://github.com/hynek/hatch-fancy-pypi-readme [2] https://pnemade.fedorapeople.org/python-hatch-fancy-pypi-readme.spec -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123969] perl-Sereal-Decoder-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123969 --- Comment #1 from Fedora Update System --- FEDORA-2022-820d29ea37 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-820d29ea37 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123969 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123968] perl-Sereal-Encoder-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123968 --- Comment #1 from Fedora Update System --- FEDORA-2022-820d29ea37 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-820d29ea37 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123968 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123967] perl-Sereal-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123967 --- Comment #1 from Fedora Update System --- FEDORA-2022-820d29ea37 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-820d29ea37 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123967 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On su, 04 syys 2022, Gary Buhrmaster wrote: On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson wrote: Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely. Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)). However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*). FreeIPA 4.9.10+ supports integration with an external OAuth2 identity provider (IdP). It needs OAuth2 device authorization grant flow support from IdP which Ipsilon does not support but Keycloak or any of major public IdPs aside from Gitlab do support. Keycloak does support FIDO2/WebAuthn too, so FreeIPA in Fedora 36 or later can be set up to operate with WebAuthn and no passwords in your own deployments. Fedora AAA uses RHEL IdM as a backend and there this feature is coming in next minor RHEL releases. It is not fully functional yet but for Fedora AAA use-case things are there with FreeIPA side. For Fedora users it would look like similar to the current Kerberos flow: (1) obtain an anonymous PKINIT ticket to use as a FAST channel, and (2) attempt to authenticate to Fedora KDC. If sssd-idp subpackage is installed and your Fedora AAA account is configured to use external IdP for your access authorization, then you'd be asked to visit a URL where you'd authenticate and then grant that authorization to Fedora AAA system. This IdP can be something that Ipsilon could federate to purely for the user authentication purposes. This is not implemented in Fedora AAA yet. You might want to watch our Nest with Fedora 2022 talk. More features are coming too, we are working on a direct FIDO2 integration in SSSD and FreeIPA, but a lot of help is needed from desktop folks as well to make it usable for login to graphical environments. GDM login is ugly right now as a message we push through PAM prompts is simply not fitting into GDM input boxes and you don't know where to go for your IdP access. See https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html for practical workshop details on how to set and use this in FreeIPA. Nest With Fedora's talk replay is available here: https://app.hopin.com/events/nest-with-fedora-2022/replay/Um91bmR0YWJsZVJlY29yZGluZ0FyY2hpdmU6MTM2OTQ3 (skip to 8:55 or so to the talk's start). Slides can be found here but the talk also has several demos: https://vda.li/talks/2022/2022-Nest-With-Fedora-FreeIPA-and-OAuth2.pdf (*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point. Ipsilon is orphaned in Fedora. If not picked up, it will disappear. It would be sad but a practical issue is that upstream seem to be less active too. Not sure how it goes but given that Fedora AAA is deployed or going to be eventually deployed in a containerized way, then probably focusing on another feature rich open source IdP could be a better option. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123967] perl-Sereal-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123967 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Fixed In Version||perl-Sereal-5.001-1.fc38 Status|NEW |MODIFIED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123967 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, Sep 4 2022 at 04:48:10 PM +, Gary Buhrmaster wrote: However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*). You don't have to be a provenpackager to be able to do serious damage; you just need to maintain one package that's installed by a sufficiently-interesting quantity of Fedora users. In the long run, we should be moving to require WebAuthn for all Fedora authentication-related purposes, since it's unphishable. Last year I entered my GitHub password into a phishing page that was proxying the real GitHub... if the evil page had gone to just slightly more effort, it could have easily intercepted a simple TOTP/HOTP challenge. This is not possible with WebAuthn, which I would say actually is pretty much equivalent to a security magic bullet. That said, I say this keenly aware that WebKitGTK doesn't support WebAuthn yet, and I would be interacting with Fedora packaging a lot less if I couldn't use my normal web browser. And anybody who isn't willing to buy a security key wouldn't be able to contribute to Fedora at all. Michael ___ 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: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 3:48 PM Adam Williamson wrote: > Personally, once a year wouldn't be anywhere near frequent enough to > trigger me to Do Something About It - it took me years to turn off > Bugzilla's "hey look you have needinfo bugs!" thing and I was getting > that every *day*. :P But I dunno about others. At least you did not have to actively respond once a day in order to keep your packaging status. If you did, I suspect you would have figured out a different solution (and being required to respond is what we are talking about here). I am not sure how often a required response should be (and as you rightly say, it can vary by person). While (putting my security hat on) I would prefer security awareness training happen continuously and constantly(*), a yearly refresher/revalidation seems to be the industry norm, where one agrees, yet again, that they are aware of, and agree to, their roles and responsibilities. (*) And not due to repeated "You opened *what* email attachment?" ___ 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: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 3:52 PM Adam Williamson wrote: > Well, not really. 2FA isn't a magic bullet. I would be in favor of > doing this, but you can't treat any security measure as solving all > your problems completely. Nothing is a magic bullet (and most security can be bypassed with the $10 (it was $5 before inflationary increase) wrench) but passkeys (which can eliminate passwords entirely) do tend to raise the bar substantially, and those services doing authorization can require additional levels of real time identity assurance for additional levels of access (so inserting a usb token, or having your phone nearby, might let you login, but you need to provide additional something (pin, biometrics, whatever) to access things at a higher level at the time you require that (say, for this case, using PP powers)). However, last this was discussed, the Fedora AAA system(s) did not (yet?) support the full fido2/webauthn/passkey functionality, so at this time such full integration is just a dream(*). (*) Given that all the major tech companies are moving towards allowing (and will be encouraging) customers to use passkeys I hope we will see better integrations with FreeIPA and Ipsilon at some point. ___ 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: [Test-Announce] Proposal to CANCEL: 2022-09-05 Fedora QA Meeting
Hey! Can't join on Tuesday next week as i will be at the Red Hat Open Tour Stockholm event then On 9/4/22, Adam Williamson wrote: > Hi folks! I'm proposing we cancel the QA meeting tomrrow. It's a holiday > in North America and I don't have anything much for the agenda again. > There will be a blocker review meeting on Tuesday, due to the holiday. > > If you're aware of anything it would be useful to discuss this week, > please do reply to this mail and we can run the meeting on Tuesday. > > Thanks folks! > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ 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
[Test-Announce] Proposal to CANCEL: 2022-09-05 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting tomrrow. It's a holiday in North America and I don't have anything much for the agenda again. There will be a blocker review meeting on Tuesday, due to the holiday. If you're aware of anything it would be useful to discuss this week, please do reply to this mail and we can run the meeting on Tuesday. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, 2022-09-04 at 10:18 +0200, Vitaly Zaitsev via devel wrote: > On 04/09/2022 02:40, Adam Williamson wrote: > > Maybe if there are > > folks like that they'd be happy to drop the privileges so if they do > > lose their laptop or something, the consequences are more limited. > > We just need to force all proven packagers to use 2FA. Problem solved. Well, not really. 2FA isn't a magic bullet. I would be in favor of doing this, but you can't treat any security measure as solving all your problems completely. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, 2022-09-04 at 03:02 +, Gary Buhrmaster wrote:
> On Sun, Sep 4, 2022 at 1:06 AM Kevin Fenzi wrote:
>
> > Perhaps it would be better (although more noisy) to just mail all
> > provenpackagers every cycle and ask if anyone would like to leave the
> > group?
>
> One should ask a PP (I am not so honored), but getting
> an email every cycle (and requiring an affirmative response)
> would be one of those reasons that I would consider a
> loophole closure loophole bypass ("stop annoying me!").
Personally, once a year wouldn't be anywhere near frequent enough to
trigger me to Do Something About It - it took me years to turn off
Bugzilla's "hey look you have needinfo bugs!" thing and I was getting
that every *day*. :P But I dunno about others.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Sun, Sep 4, 2022 at 1:38 PM Mattia Verga via devel wrote: > If anyone wants to have a look to what packages **may** be orphaned when > those users are removed from the packager group, I've set up a script > and uploaded the results here [1]. Thanks for doing this. The list does not look unduly long or scary(*), especially if a fair number of the packagers reengage (as I expect many will). And if, in the end, I need to pick up a few (mostly leaf) packages that I strongly care about that will work out too. (*) There are some of what I consider core/fundamental packages in the list that I have little doubt either the current packager, or someone else, will pick up as needed (php would seem to be a poster child, but I did see a few others that are fundamental). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123968] perl-Sereal-Encoder-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123968 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |MODIFIED Fixed In Version||perl-Sereal-Encoder-5.001-1 ||.fc38 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123968 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123969] perl-Sereal-Decoder-5.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123969 Paul Howarth changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |MODIFIED Fixed In Version||perl-Sereal-Decoder-5.001-1 ||.fc38 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123969 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123186] perl-HTTP-BrowserDetect-3.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123186 Emmanuel Seyman changed: What|Removed |Added Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Fixed In Version||perl-HTTP-BrowserDetect-3.3 ||6-1.fc38 Last Closed||2022-09-04 13:44:30 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2057434 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123186 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2123185] perl-HTML-Tiny-1.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2123185 Emmanuel Seyman changed: What|Removed |Added Fixed In Version||perl-HTML-Tiny-1.07-1.fc38 Status|NEW |CLOSED Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2022-09-04 13:41:53 --- Comment #2 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2057437 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2123185 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2122868] perl-JSON-Path-1.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2122868 Emmanuel Seyman changed: What|Removed |Added Resolution|--- |RAWHIDE Fixed In Version||perl-JSON-Path-1.0.1-1.fc38 Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Last Closed||2022-09-04 13:41:11 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2057438 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2122868 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Il 19/08/22 18:53, Gary Buhrmaster ha scritto: > On Fri, Aug 19, 2022 at 10:47 AM P J P wrote: > >> * Interesting numbers there. > (see below on another number) > >> * While I get that such pruning from time to time is generally good. >>What happens to the packages orphaned by removing inactive packagers? >> >> * Removing orphaned packages may not be easy, as other packages may depend >> on them. > Obviously, if the packages are still desired or needed, an > active packager will need to pick them up. For a number of > those packages I suspect that they have been running more > or less on successful auto-pilot (mass rebuild) for some > time, so picking them up should not result in substantially > increased workload going forward after the initial take, but > I admit I, myself, do not look forward to having to add to > the list of packages I might need to feel (at least notionally) > responsible for if I end up having to take some of them on > due to dependencies in things I do care about. > > I would also say, that while it is probably not entirely easy > to do so, a *very* interesting additional number would > have been how many packages would be orphaned if > all of the identified packagers are removed, just so we > have an order of magnitude of what we are looking at > moving forward. But that list is probably best produced > at a later time, as, for all we know, many of the people > may indeed still be active (and because their packagers > do run on auto-pilot, do not regularly engage). > > These are, of course, probably mostly first run issues. > Once the process is in place and ongoing, the order of > magnitude of the people and packages is likely to be > the usual background noise levels. If anyone wants to have a look to what packages **may** be orphaned when those users are removed from the packager group, I've set up a script and uploaded the results here [1]. Do not be too scared by those results: there's still plenty of time for those users to show up and declare their willingness to maintain their status. If you, however, see a package you care listed with an asterisk (look at the bottom of the list), take notice that these are the packages that will surely be orphaned, because the current maintainer has asked to be removed from the packager group. Maybe you can start asking them to transfer the package to you. I plan to post an updated list before the end of the month and at mid October (or maybe Ben will do, if he prefer). Mattia [1] https://mattia.fedorapeople.org/inactive-packagers/affected_packages.txt ___ 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
Manually queue Koschei build?
I noticed on the packager dashboard that I have a package that was failing for EPEL 7[1] and I have since fixed it, but I don't need to build a new package and Koschei hasn't attempted a rebuild since 6/29. While I could just ignore it, I was wondering if there was a way to force a rebuild? I see the priority field but I don't have any reference for what a good value would be, it's not particularly intuitive. Thanks, Richard [1] https://koschei.fedoraproject.org/package/OpenColorIO?collection=epel7 ___ 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
Fedora 37 compose report: 20220904.n.0 changes
OLD: Fedora-37-20220903.n.0 NEW: Fedora-37-20220904.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.33 MiB Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-37-20220904.n.0.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-37-20220904.n.0.aarch64.raw.xz = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: R-Rcompression-0.93.2-34.fc37 Summary: R Package for in-memory compression RPMs:R-Rcompression Size:1.33 MiB = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Questions regarding %pyproject_buildrequires
Hi, I'm tinkering with a package in review, trying to understand the Python RPM build process. The package is hatch-fancy-pypi-readme [1]. The package uses hatch for build, but it includes a non-license file, AUTHORS.md, which I thought would be trivial to patch around, so it's not included in the RPM. I patched the pyproject.toml and added: [tool.hatch.build] exclude = ["AUTHORS.md"] Then I realized %pyproject_buildrequires has the option -w enabled, producing a wheel for metadata extraction. So, I added a patch, putting a MANIFEST.in in the root dir of the project with one line: exclude AUTHORS.md Yet the whl archive still contains the file: hatch_fancy_pypi_readme-22.3.0.dist-info/licenses/AUTHORS.md and so does the final RPM. Do I have to resort to manually removing the file in %prep? I encountered another issue with %pyproject_buildrequires when passing the -t option for automatic test requirements. I wanted to see if I can get rid of the extra BuildRequires in the submitters spec file [2], so I commented out all but python3-dev and python3-test BuildRequires and added -t to %pyproject_buildrequires. That made the build fail with: No matching package to install: 'python3dist(pytest-icdiff)' Yet, I don't see any test or other python module importing icdiff. Building with the original spec file, tests are run and succeed. Is that a known issue with the -t option? Or am I missing something? [1] https://github.com/hynek/hatch-fancy-pypi-readme [2] https://pnemade.fedorapeople.org/python-hatch-fancy-pypi-readme.spec -- Sandro ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20220904.n.0 changes
OLD: Fedora-Rawhide-20220903.n.0 NEW: Fedora-Rawhide-20220904.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:1 Upgraded packages: 32 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.33 MiB Size of upgraded packages: 567.60 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 20.13 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20220904.n.0.iso = DROPPED IMAGES = Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20220903.n.0.x86_64.tar.gz = ADDED PACKAGES = = DROPPED PACKAGES = Package: R-Rcompression-0.93.2-34.fc37 Summary: R Package for in-memory compression RPMs:R-Rcompression Size:1.33 MiB = UPGRADED PACKAGES = Package: AusweisApp2-1.24.1-1.fc38 Old package: AusweisApp2-1.22.3-2.fc37 Summary: Online identification with German ID card (Personalausweis) RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc Size: 20.73 MiB Size change: 2.89 MiB Changelog: * Fri Sep 02 2022 Bj??rn Esser - 1.24.1-1 - New upstream release Package: asio-1.24.0-2.fc38 Old package: asio-1.16.1-6.fc37 Summary: A cross-platform C++ library for network programming RPMs: asio-devel Size: 19.98 MiB Size change: 9.34 MiB Changelog: * Sun Jul 31 2022 Julian Sikorski - 1.22.2-1 - Update to 1.22.2 * Sat Aug 13 2022 Julian Sikorski - 1.24.0-1 - Update to 1.24.0 * Sat Sep 03 2022 Julian Sikorski - 1.24.0-2 - Rebuild due to disappearing side tag Package: cinnamon-session-5.4.0-3.fc38 Old package: cinnamon-session-5.4.0-2.fc37 Summary: Cinnamon session manager RPMs: cinnamon-session Size: 582.94 KiB Size change: -252 B Changelog: * Sat Sep 03 2022 Leigh Scott - 5.4.0-3 - Accept Desktop Entry Specification v1.5 Package: ddnet-16.3.1-1.fc38 Old package: ddnet-16.2.2-2.fc37 Summary: DDraceNetwork, a cooperative racing mod of Teeworlds RPMs: ddnet ddnet-data ddnet-server Size: 32.77 MiB Size change: 103.03 KiB Changelog: * Sat Sep 03 2022 S??rgio Basto - 16.3.1-1 - Update ddnet to 16.3.1 (#2118277) Package: gamemode-1.7-1.fc38 Old package: gamemode-1.6-4.fc36 Summary: Optimize system performance for games on demand RPMs: gamemode gamemode-devel Size: 566.25 KiB Size change: 36.82 KiB Changelog: * Thu Jul 21 2022 Fedora Release Engineering - 1.6-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild * Sat Sep 03 2022 Peter Robinson - 1.7-1 - Update to 1.7 Package: gimp-2:2.10.32-3.fc38 Old package: gimp-2:2.10.30-1.fc37.3 Summary: GNU Image Manipulation Program RPMs: gimp gimp-devel gimp-devel-tools gimp-libs Size: 92.46 MiB Size change: 624.52 KiB Changelog: * Sat Sep 03 2022 Nils Philippsen 2:2.10.32-1 - Version 2.10.32 * Sat Sep 03 2022 Nils Philippsen 2:2.10.32-2 - Remove more cruft for unstable version packaging * Sat Sep 03 2022 Nils Philippsen 2:2.10.32-3 - Add and update (build-)dependencies Package: gnome-subtitles-1.8-1.fc38 Old package: gnome-subtitles-1.7.2-3.fc37 Summary: Subtitle editor for Gnome RPMs: gnome-subtitles Size: 6.28 MiB Size change: 4.57 MiB Changelog: * Thu Aug 25 2022 Julian Sikorski 1.7.2-4 - Rebuild for gtk-sharp3-3.22 * Sat Sep 03 2022 Julian Sikorski 1.8-1 - Update to 1.8 - switch to meson - bundle gst-sharp and gtk-sharp until system versions can be used - drop outdated user guide - update the URL - switch to .xz sources - move COPYING from %%doc to %%license Package: goaccess-1.6.3-1.fc38 Old package: goaccess-1.6.2-1.fc38 Summary: Real-time web log analyzer and interactive viewer RPMs: goaccess Size: 1.36 MiB Size change: 5.54 KiB Changelog: * Sat Sep 03 2022 Eduardo Echeverria - 1.6.3-1 - Update to 1.6.3 Package: golang-github-gobuffalo-flect-0.3.0-1.fc38 Old package: golang-github-gobuffalo-flect-0.2.5-2.fc37 Summary: Inflection engine for Golang RPMs: golang-github-gobuffalo-flect-devel Size: 44.17 KiB Size change: 223 B Changelog: * Sat Sep 03 2022 Elliott Sales de Andrade 0.3.0-1 - Update to latest version (#2123970) Package: golang-github-subosito-gotenv-1.4.1-1.fc38 Old package: golang-github-subosito-gotenv-1.4.0-1.fc37 Summary: Load environment variables from `.env` or `io.Reader` in Go RPMs: golang-github-subosito-gotenv-devel Size: 17.27 KiB Size change: 110 B Changelog: * Sat Sep 03 2022 Elliott Sales de Andrade 1.4.1-1 - Update to latest version (#2120894) Package: golang-github-tdewolff-minify-2.12.1-1.fc38 Old package: golang-github-tdewolff-minify-2.11.10-5.fc37
Build failure on f37-x86_64, stdlib.h: No such file or directory
Can someone give me hint as to what I'm doing wrong here, I have a C++ package that builds fine for f35 & f36 with x86_64 & aarch64, but which fails on f37-x86_64 (the build is ok on f37-aarch64): https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/build/4771106/ [ 0%] Building CXX object CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o /usr/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DHAS_SCHEMA_2x3 -DHAS_SCHEMA_4 -DHAS_SCHEMA_4x1 -DHAS_SCHEMA_4x2 -DHAS_SCHEMA_4x3 -DHAS_SCHEMA_4x3_rc1 -DHAS_SCHEMA_4x3_rc2 -DHAS_SCHEMA_4x3_rc3 -DHAS_SCHEMA_4x3_rc4 -DIFC_SHARED_BUILD -DIfcParse_EXPORTS -DSCHEMA_SEQ="(2x3)(4)(4x1)(4x2)(4x3_rc1)(4x3_rc2)(4x3_rc3)(4x3_rc4)(4x3)" -DUSE_MMAP -DWITH_GLTF -DWITH_HDF5 -DWITH_IFCXML -DWITH_OPENCOLLADA -I/usr/include/opencascade -I/usr/include/COLLADABaseUtils -I/usr/include/COLLADAStreamWriter -I/usr/include/libxml2 -isystem /usr/include -lxml2 -DNDEBUG -O3 -fPIC -Wall -Wextra -Wno-maybe-uninitialized -Wno-deprecated-copy -fPIC -DIFC_PARSE_EXPORTS -std=gnu++14 -MD -MT CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -MF CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o.d -o CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o -c /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp In file included from /usr/include/c++/12/ext/string_conversions.h:41, from /usr/include/c++/12/bits/basic_string.h:3960, from /usr/include/c++/12/string:53, from /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp:27: /usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ -- Bruno ___ 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: Inactive packagers to be removed after the F37 release
On 04/09/2022 02:40, Adam Williamson wrote: Maybe if there are folks like that they'd be happy to drop the privileges so if they do lose their laptop or something, the consequences are more limited. We just need to force all proven packagers to use 2FA. Problem solved. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On 04/09/2022 00:01, Adam Williamson wrote: But yeah, looking at that, one 'loophole' is it doesn't check if they're actually needing*proven* packager powers - just packager powers. If a proven packager is only building packages they have explicit commit rights to, they may not need proven packager powers any more? According to Fedora Provenpackager policy, proven packagers should only use their powers during approved bulk changes, rebuilding dependent packages, etc. It's fine that they didn't change other packages during the reporting period. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
Il 04/09/22 00:01, Adam Williamson ha scritto: > On Sat, 2022-09-03 at 13:04 -0700, Kevin Fenzi wrote: >> On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote: >>> So, I have a probably-controversial idea for a follow-up on this. >>> >>> Even after this sweep, we have 141 proven packagers. That's a lot of >>> people who can build almost anything in Fedora. >>> >>> It should be possible to check whether a provenpackager has built any >>> package they don't have direct commit rights to in the last X months. >>> >>> Should we construct that search, run it, and propose removing >>> provenpackager status from folks who aren't using it, to cut down that >>> set? >> That policy was setup before this one for packagers. ;) >> >> https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ > Look, I'm getting old, okay? ;) > > But yeah, looking at that, one 'loophole' is it doesn't check if > they're actually needing *proven* packager powers - just packager > powers. If a proven packager is only building packages they have > explicit commit rights to, they may not need proven packager powers any > more? I sometimes use my PP powers to fix build tagging issues / updates flows caused by Bodhi glitches, but I (very) rarely use them to build someone else package. What I mean is whatever test is done to check if someone needs to be PP doesn't assume the power is just used to build packages. Mattia ___ 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
