Gi,
I tried to open a PR to get petsc rebuild for a recent update of openmpi.
However, I cannot open a PR, which I think might be related that I only have an
empty commit [0].
I have been told I should open PRs for rebuilds [1].
Is it possible to have a PR without any code changes?
Is there an a
Sandro wrote:
> On 09-07-2024 17:01, David Bold wrote:
> > Is it possible to have a PR without any code changes?
> > Is there an alternative, recommended way to ask for rebuilds?
> Specifically in the case of %autorelease, you can bump the release with
> an empty commit:
Cristian Le wrote:
> On 2024/07/09 17:09, Sandro via devel wrote:
> > On 09-07-2024 17:01, David Bold wrote:
> > Is it possible to have a PR without any code changes?
> > Is there an alternative, recommended way to ask for rebuilds?
> > Specifically in the case of %au
Adam Samalik wrote:
> On Wed, 17 Jul 2024 at 10:54, Pavel Raiskup prais...@redhat.com wrote:
> > On úterý 16. července 2024 15:22:56, SELČ Stephen Gallagher wrote:
> > On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup prais...@redhat.com
> > wrote:
> > [snip]
> > Do you suggest moving rawhide to branch
EPEL10 is currently in rawhide mode, thus updates get created automatically:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-bcaca74032
If you want to prevent this, you have to use a side-tag.
--
___
devel mailing list -- devel@lists.fedoraproj
> 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 aar
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
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
> 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 th
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
> 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=
> 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,
>
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
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
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++-mp
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
The policy is applied:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RROZC3KFCF6G4RRMKEM4NXJ4PTFFROTT/
The question is, why is rubygem-hashie not on the list ...
--
___
devel mailing list -- devel@lists.fedoraprojec
Vitaly Zaitsev wrote:
> > Benchmarks indicate 100–1000 μs.
> > 1 second? I think it's too much.
No, 0.1 to 1 ms or 0.0001 to 0.001 seconds
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedora
18 matches
Mail list logo
