Re: gloox soname bump
> On Tuesday, 19 March 2024 at 09:41, David Bold wrote: > > Builds completed. I think you can submit the updates yourself now. > Next time, I'd suggest opening a pull request against > each of the packages you want to rebuild. That saves time for PPs. > > Regards, > Dominik Submitting updates did indeed work without PP powers. I didn't know that submitting PRs works for rebuilds as well, I will do it in the future. Thanks a lot, David -- ___ 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: gloox soname bump
> Hi Fedorians, > > I intend to update gloox to 1.0.28 which comes with a soname bump. > 0ad and uwsgi depend on gloox [0]. > > I have successfully rebuild both in copr [1]. > > I will rebuild gloox in the following side tags: > fedpkg build --target=f41-build-side-85385 > fedpkg build --target=f40-build-side-85387 > > Help with the rebuilds would be greatly appreciated, as I do not have > permission for those > two packages. > > Best, David It has been a bit over a week. Could I please get some help from a provenpackager to rebuild the two dependencies and submit the update? -- ___ 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
gloox soname bump
Hi Fedorians, I intend to update gloox to 1.0.28 which comes with a soname bump. 0ad and uwsgi depend on gloox [0]. I have successfully rebuild both in copr [1]. I will rebuild gloox in the following side tags: fedpkg build --target=f41-build-side-85385 fedpkg build --target=f40-build-side-85387 Help with the rebuilds would be greatly appreciated, as I do not have permission for those two packages. Best, David [0] fedrq wrsrc gloox -X -F source [1] https://copr.fedorainfracloud.org/coprs/davidsch/testing/builds/ -- ___ 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: Feedback wanted - pruning old rawhide chroots in Copr
> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber wrote: > I like this idea. Move things that were built for "rawhide" into the > "fedora-40" chroot, and start Rawhide empty, requiring fresh builds of > things. > Since there is no equivalent to the mass rebuild in COPR, that would > also solve the problem of "stale" packages in Rawhide chroots. > > Fabio Could you clarify what that would mean to a copr (e.g. [1]) that has only a rawhide branch. Would that switch to fedora-41 on the next branching, and I have to manually recreate the rawhide branch every half year? Or will there be in addition an fedora-41 created, where all the builds will go and the rawhide branch will be empty? What I would really like if there would be an option to say that builds get automatically deleted after a few months, but I could not find such an option, only to delete the whole copr after a given time, but that is not what I want. Would such an option avoid the problem? If the user could specify when builds should get pruned? And if the selected time is more then a year, they have to confirm every half year? Looking at the storage statistics it is not quite clear to me to what extend "small" projects matter at all. It seems there are around 30 TB of storage, of which the two biggest user produce 5 TB each. Maybe an opt-in into deletion plus some communication with the biggest storage users could be a solution? David [1] https://copr.fedorainfracloud.org/coprs/davidsch/testing/ -- ___ 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
Cancel build from mass rebuild?
I noticed a while ago that bout++ is currently FTBFS, and one of the tests with mpich on s390x seems to get stuck in a dead lock, openmpi and other arches are having no issues. I haven't managed to find a fix, and forgot to push a workaround that disables the tests. It seems I cannot cancel the build from the mass rebuild [1]. Can some one cancel the build for me? I think the timeout is quite late, and I do not want a stuck build waste all the compute time ... Any hints on how to debug mpich related issues on s390x would of course also be appreciated :-) Best, David [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2348630 -- ___ 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: openmpi 5.0.0 update coming - drops i686 and C++ API
Thanks Dan, I will have a go at your machine + mock to reproduce and debug. ___ 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: openmpi 5.0.0 update coming - drops i686 and C++ API
> On Tue, 07 Nov 2023 10:17:06 - > David Schwörer > > if you mean strange as ppc64le, then it's in the output just because I > was updating a rawhide/ppc64le system, but the problem exists on all > arches. The libmpi_cxx.so.40 doesn't exist at all in openmpi 5.0, so > people on x86_64 or aarch64 are affected as well. > > > Dan Sorry, I should have been more specific. I was taking about s390x, and only remembered it is one of those once where I do no easy access to. Thus it is hard for me to resolve it [0]. I assume the MUSIC maintainer are in a similar position that they did not manage to resolve the FTBFS, but I think obsoleting FTBFS packages is not the way to go. There is an issue for MUSIC to switch to the C API [1], thus I would assume they would be happy to get some help, I know I would be happy if someone could figure out why bout++ has issues with openmpi 5 on s390x. I am aware that until I can rebuild bout++, and until MUSIC can be rebuild, the packages are FTI, blocking upgrade of openmpi. I am stuck on the old openmpi as well. Best, David [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=107756851 [1] https://github.com/INCF/MUSIC/issues/27 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: A way to prepare custom source tarballs from .spec file to improve CI experience
On 4/25/22 13:42, Fabio Valentini wrote: On Mon, Apr 25, 2022 at 10:51 AM Vít Ondruch wrote: 2) Standalone script does not solve the main issue and that is a way CI could obtain the tarball. Of course you mentioned "with support for extraction in spectool", but that is also part of the issue, because that would need the "spectool" changes as well as CI changes. My proposal does not need that. Of course, this is proof of concept, while the part of the script you point out could be possibly improved and abstracted by some macro. This has come up before, but given that the current maintainer of spectool (which is me) has offered to implement support for this, I don't see this as a problem. I also assume that the CI you're talking about already calls spectool to download package sources for new versions, so doing this would actually make any changes to the CI environment entirely unnecessary. We'd just need to agree on a way to specify the path to the script that needs to be run for generating source X. For example, we could use something like: # SourceScript: gen_clean_tarball.sh That would make it easy for spectool to parse this information from the .spec file, and then execute the program with that name. I think it does require some changes to CI, otherwise, this will execute untrusted code when all it was supposed to do is download. I do currently assume that I can run `spectool -g` on an untrusted spec to look at the source code, without running untrusted code. I think the user should make an active decision to execute such scripts, thus a API change for CI would be needed. David We could possibly also supply some variables as command line arguments to that script, for example, the current "Version" from the .spec file, so it doesn't have to be modified in two places. Fabio ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: RetireARMv7 (System-Wide Change proposal)
On 11/15/21 20:15, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/RetireARMv7 > ... > == Scope == > > * Proposal owners: Work with rel-eng to disable the architecture in > koji, remove all the various pungi pieces and clean up any other > release detritus. > > * Other developers: No action required. > > * Release engineering: [https://pagure.io/releng/issue/10387 Releng > issue #10387] Disable a bunch of stuff, it's really just one koji > admin command and a PR for pungi config changes > > * Policies and guidelines: No initial updates to policies and > guidelines as ARMv7 won't completely disappear until F-36 EOL. > > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > > Any current users of Fedora on ARMv7 devices won't be able to upgrade > to Fedora 37, they will have to stay on Fedora 36 until it's EOL. > ... > == User Experience == > Any current users of Fedora on ARMv7 devices won't be able to upgrade > to Fedora 37, they will have to stay on Fedora 36 until it's EOL. ... I just tried to install Fedora on RPi, and I ended up on [1] where I downloaded an image. That was unfortunately armv7 - and I needed to go to [2] - which was not linked in the descriptions [3,4]. Also the wiki lists first the armv7 [5] As such I think there will be very many people being stuck on F36, without a way to update to F37. I was not happy that my old RPi will not work any more, but that we still push people towards a to be retired version is very bad. I think at least this needs to be taken into account, and the websites should be fixed as soon as possible. Further, if this is possible, there should be instructions to update from armv7 to aarch64, to make a direct upgrade, rather than reinstall, possible. tl;dr 1) mention that also aarch64 users are affect, if they run armv7 software, which seems quite likely 2) Change the websites, add deprecation info, and point to aarch64 pages 3) discuss impact on armv7 on aarch64 users Cheers, David [1] https://arm.fedoraproject.org/ [2] https://alt.fedoraproject.org/alt/ [3] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/ [4] https://docs.fedoraproject.org/en-US/quick-docs/raspberry-pi/#installing-fedora-on-a-raspberry-pi-using-the-fedora-arm-installer_rpi [5] https://www.fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35 ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: rpm requires/provides not run for library
I noticed the permissions on the library are wrong. I will try again with the executable bit set. Sorry for the confusion, David On 9/8/21 09:38, David Bold wrote: I did notice that bout++ in Fedora 35 is not installable: Problem 1: problem with installed package python3-bout++-mpich-4.3.2-6.fc34.x86_64 - package python3-bout++-mpich-4.3.2-11.fc35.x86_64 requires libnetcdf.so.15()(64bit), but none of the providers can be installed - python3-bout++-mpich-4.3.2-6.fc34.x86_64 does not belong to a distupgrade repository - netcdf-4.7.3-6.fc34.x86_64 does not belong to a distupgrade repository - nothing provides libbout++.so.4.4.0()(64bit)(mpich-x86_64) needed by python3-bout++-mpich-4.4.0-1.fc35.x86_64 It seems the MPI provides are missing: dnf --releasever=35 --enablerepo=updates-testing repoquery --provides bout++-mpich-4.4.0 Last metadata expiration check: 0:31:15 ago on Wed 08 Sep 2021 08:45:11 AM CEST. bout++-mpich = 4.4.0-1.fc35 bout++-mpich(x86-64) = 4.4.0-1.fc35 bundled(libpvode) But the library itself is included: rpm -q -l ./bout++-mpich-4.4.0-1.fc35.x86_64.rpm [...] /usr/lib64/mpich/lib/libbout++.so.4.4.0 [...] Looking at the build[1,2], it seems the shared object are not processed, and no provides/requires are generated for the shared object. https://koji.fedoraproject.org/koji/buildinfo?buildID=1822939 The rawhide builds have the same issue, same is true for different arches. Any ideas what might have gone wrong? Dependencies on this library are generated, but provides are missing. Thank you, David ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
rpm requires/provides not run for library
I did notice that bout++ in Fedora 35 is not installable: Problem 1: problem with installed package python3-bout++-mpich-4.3.2-6.fc34.x86_64 - package python3-bout++-mpich-4.3.2-11.fc35.x86_64 requires libnetcdf.so.15()(64bit), but none of the providers can be installed - python3-bout++-mpich-4.3.2-6.fc34.x86_64 does not belong to a distupgrade repository - netcdf-4.7.3-6.fc34.x86_64 does not belong to a distupgrade repository - nothing provides libbout++.so.4.4.0()(64bit)(mpich-x86_64) needed by python3-bout++-mpich-4.4.0-1.fc35.x86_64 It seems the MPI provides are missing: dnf --releasever=35 --enablerepo=updates-testing repoquery --provides bout++-mpich-4.4.0 Last metadata expiration check: 0:31:15 ago on Wed 08 Sep 2021 08:45:11 AM CEST. bout++-mpich = 4.4.0-1.fc35 bout++-mpich(x86-64) = 4.4.0-1.fc35 bundled(libpvode) But the library itself is included: rpm -q -l ./bout++-mpich-4.4.0-1.fc35.x86_64.rpm [...] /usr/lib64/mpich/lib/libbout++.so.4.4.0 [...] Looking at the build[1,2], it seems the shared object are not processed, and no provides/requires are generated for the shared object. https://koji.fedoraproject.org/koji/buildinfo?buildID=1822939 The rawhide builds have the same issue, same is true for different arches. Any ideas what might have gone wrong? Dependencies on this library are generated, but provides are missing. Thank you, David ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
