> 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,
> Dom
> 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
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
> 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
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
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:
> 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
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
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
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
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
-
11 matches
Mail list logo
