bodhi push error
Hi, Has anybody seen this error before: FEDORA-2024-310c0537ac ejected from the push because "Cannot find relevant tag for gromacs-2023.4-1.fc39. None of ['f39-updates', 'f39-updates-pending'] are in ['epel9-next-testing', 'epel7-testing', 'eln-updates-testing', 'epel8-testing', 'epel9-testing', 'epel8-next-testing', 'f40-container-updates-testing', 'f38-modular-updates-testing', 'f38-flatpak-updates-testing', 'f40-updates-testing', 'f38-updates-testing', 'f38-container-updates-testing', 'f39-updates-testing', 'f39-container-updates-testing', 'f39-flatpak-updates-testing']." Cheers, Christoph -- Christoph Junghans Web: http://www.compphys.de -- ___ 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 tests blocked
On Thu, Nov 10, 2022 at 10:27 PM Orion Poplawski wrote: > > On 11/6/22 07:31, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 05 November 2022 at 21:27, Antonio T. sagitter wrote: > >> Hi all. > >> > >> Many OpenMPI tests in RPM packaging are blocked for unknown reason, no > >> output or error, just hanged until test timeout. > >> For example, PETSc test is blocked with this message: > >> > >> > >> Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca > >> btl_base_warn_component_unused 0 -n 1 > >> /tmp/petsc-p7fo3olx/config.packages.MPI/conftest > >> Running Executable with threads to time it out at 120 > >> Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca > >> btl_base_warn_component_unused 0 -n 1 > >> /tmp/petsc-p7fo3olx/config.packages.MPI/conftest > >> Runaway process exceeded time limit of 120 > >> ERROR while running executable: Could not execute > >> "['/usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused > >> 0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest']": > >> Runaway process exceeded time limit of 120 > >> > >> Something like this happened with Sundials and Ipopt, when OpenMPI is used, > >> not with MPICH. > >> > >> At this time, these tests in Rawhide (and ELN) cannot be executed. > > > > I've got the same issue with elpa. OpenMPI hangs, MPICH works fine. > > Let's open a bug against OpenMPI and compare notes. ;) > > > > Regards, > > Dominik > > We have: > > https://bugzilla.redhat.com/show_bug.cgi?id=2141137 > > I've reported it upstream as well. Hopefully they can help. openSUSE had a similar bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1205139 Maybe that is related. Christoph > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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: Unannounced .so version bump in libcerf
On Mon, Apr 11, 2022 at 9:50 AM Ben Beasley wrote: > > The libcerf package was updated to version 2.1 in Rawhide yesterday[1], > which included an unannounced .so version bump from “1” to “2”. My mistake, I thought I did a "dnf repoquery --whatrequires libcerf.so.1", but it only showed libecpint. > > The following packages will need to be rebuilt: > > - LabPlot https://src.fedoraproject.org/rpms/LabPlot/pull-request/3 > > - gnuplot https://src.fedoraproject.org/rpms/gnuplot/pull-request/12 > > - libecpint That is mine, so already done. Sorry for the inconvenience, Christoph > > > [1] > https://src.fedoraproject.org/rpms/libcerf/c/27320a591bcafad2f31429d6ba8bd1ca0fadd940?branch=rawhide > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Review swap
Hi,
can someone please review:
https://bugzilla.redhat.com/show_bug.cgi?id=2032487
This is basically a merge of votca-{tools,csg,xtp} to make building it
easier (no more chain builds) and to allow for more testing. Plus it
will package the tutorials as well.
I am happy to review a package in exchange.
Cheers,
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
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: Mass spec file change: Adding BuildRequires: make
On Mon, Nov 30, 2020 at 4:05 PM Tom Hughes via devel wrote: > > On 30/11/2020 22:06, Tom Stellard wrote: > > > As part of the f34 change request[1] for removing make from the > > buildroot, I will be doing a mass update of packages[2] to add > > BuildRequires: make where it is needed. > > What happened to excluding packages which use cmake? The packages would still need to depend on make or ninja. Christoph > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: can't find the format file `latex.fmt' on Rawhide
On Fri, Nov 13, 2020 at 8:19 AM Christoph Junghans wrote:
>
> Hi,
>
> Using latex in Docker on Rawhide gives an "I can't find the format
> file `latex.fmt'!" error.
> I have seen this before but I don't recall how to fix it.
>
> Mini reproducer using the following Dockerfile:
> FROM registry.fedoraproject.org/fedora:rawhide
> RUN dnf -y update
> RUN dnf -y install texlive
> RUN printf
> '\\documentclass{article}\n\\begin{document}\ntest\n\\end{document}'
> > test.tex
> RUN latex test.tex
>
> Any ideas?
I did some follow up research - summary here:
https://bugzilla.redhat.com/show_bug.cgi?id=1897839
In short, same texlive version works fine in a F33 container, so it
must be something else in Rawhide that triggers this.
>
> Thanks,
>
> Christoph
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
--
Christoph Junghans
Web: http://www.compphys.de
___
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
can't find the format file `latex.fmt' on Rawhide
Hi,
Using latex in Docker on Rawhide gives an "I can't find the format
file `latex.fmt'!" error.
I have seen this before but I don't recall how to fix it.
Mini reproducer using the following Dockerfile:
FROM registry.fedoraproject.org/fedora:rawhide
RUN dnf -y update
RUN dnf -y install texlive
RUN printf '\\documentclass{article}\n\\begin{document}\ntest\n\\end{document}'
> test.tex
RUN latex test.tex
Any ideas?
Thanks,
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: ld segfaults on rawhide
On Tue, Nov 3, 2020 at 10:42 AM Justin Forbes wrote: > > On Tue, Nov 3, 2020 at 11:17 AM Miro Hrončok wrote: > > > > On 11/3/20 6:08 PM, Jeff Law wrote: > > > > > > On 11/3/20 9:56 AM, Kevin Fenzi wrote: > > >> On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: > > >>> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes > > >>> wrote: > > >>>> On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: > > >>>>> > > >>>>> On 10/31/20 9:13 AM, Christoph Junghans wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I am getting the following error on all archs on rawhide: > > >>>>>> collect2: fatal error: ld terminated with signal 11 [Segmentation > > >>>>>> fault], core dumped > > >>>>>> in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 > > >>>>>> > > >>>>>> any ideas? > > >>>>> Given it's happening on multiple architectures, I'd guess its a linker > > >>>>> bug of some kind. > > >>>>> > > >>>> Definitely seems to be. Killed every arch for the kernel builds today > > >>>> as well. > > >>>> > > >>> Would it be possible/wise to untag the bad binutils build from rawhide > > >>> until an answer is found here? > > >> Well, it may already be out in yesterdays rawhide? > > >> > > >> I see: > > >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1637660 > > >> landed today... > > >> > > >> Does that one work any better? > > > > > > I ping'd Nick on this issue about an hour ago and he indicated it was > > > now fixed in rawhide. > > > > > > > It appears to be fixed in binutils 2.35.1-12.fc34 > > > > At least rpm builds again. > > > > kernel as well. @Kevin Still segfaults, now inside using clang++-11: Program received signal SIGSEGV, Segmentation fault. 0x7fb81e40aa88 in bfd_elf_link_add_symbols () from /usr/lib64/libbfd-2.35.1-11.fc34.so (gdb) bt #0 0x7fb81e40aa88 in bfd_elf_link_add_symbols () from /usr/lib64/libbfd-2.35.1-11.fc34.so #1 0x55745267e16c in load_symbols.part () #2 0x55745267304c in open_input_bfds.lto_priv () #3 0x557452673116 in open_input_bfds.lto_priv () #4 0x55745267b538 in lang_process () #5 0x55745266bf97 in main () (from building votca-xtp with clang-11 on rawhide) To reproduce, run: $ docker run -it fedora:rawhide /bin/bash in the container $ dnf install git cmake eigen3-devel libint2-devel hdf5-devel libxc-devel expat-devel boost-devel $ git clone --recursive https://github.com/votca/votca $ cmake -B build -DBUILD_XTP=ON votca $ cmake --build build wait and see the segfault. Christoph > > Justin > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: ld segfaults on rawhide
On Sat, Oct 31, 2020 at 9:32 AM Jeff Law wrote: > > > On 10/31/20 9:13 AM, Christoph Junghans wrote: > > Hi, > > > > I am getting the following error on all archs on rawhide: > > collect2: fatal error: ld terminated with signal 11 [Segmentation > > fault], core dumped > > in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 > > > > any ideas? > > Given it's happening on multiple architectures, I'd guess its a linker > bug of some kind. > > > Nick (on-cc)? Thoughts here? Good point, I did a scratch build (https://koji.fedoraproject.org/koji/taskinfo?taskID=54554103) before that passed: binutils changed from DEBUG util.py:636: binutilsx86_64 2.35.1-10.fc34 build 5.4 M DEBUG util.py:636: binutils-gold x86_64 2.35.1-10.fc34 build 777 k to DEBUG util.py:636: binutilsx86_64 2.35.1-11.fc34 build 5.4 M DEBUG util.py:636: binutils-gold x86_64 2.35.1-11.fc34 build 779 k That change seems to be due to https://bugzilla.redhat.com/show_bug.cgi?id=1889763 Christoph > > > Jeff > -- Christoph Junghans Web: http://www.compphys.de ___ 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
ld segfaults on rawhide
Hi, I am getting the following error on all archs on rawhide: collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 any ideas? Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
non-verbose %ctest
Hi, The new %ctest macro generates so much output, it sometimes makes it hard to find the actual failure. Especially with gtest, where you have many tests in one executable and multiple executables run at the same time.. Is there a way to drop the "--verbose" option? "%ctest --quiet" works but suppresses all outputs. "%ctest --no-verbose" does nothing. I would just like the normal "ctest --output-on-failure" behavior back. Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: mpich always injects lto flags
On Thu, Aug 6, 2020 at 5:24 PM Jeff Law wrote:
>
> On Thu, 2020-08-06 at 15:59 -0600, Christoph Junghans wrote:
> > On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans
> > wrote:
> > > On Wed, Aug 5, 2020 at 2:21 PM Jeff Law wrote:
> > > > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > > > > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I am trying to rebuild espresso to adapt to the recent cmake
> > > > > > changes,
> > > > > > when doing this I hit
> > > > > > https://github.com/espressomd/espresso/issues/3396, which prevents
> > > > > > us
> > > > > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > > > > which works for the build with openmpi, but gets ignored for the
> > > > > > mpich
> > > > > > build.
> > > > > >
> > > > > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > > > > and then puts them in
> > > > > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > > > > >
> > > > > > So I think the fix would be to strip these flags from mpicc. Sounds
> > > > > > reasonable?
> > > > > >
> > > > > > The flags also contain
> > > > > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > > > > makes it depend on redhat-rpm-config. We had a similar issue in
> > > > > > hdf5 a
> > > > > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > > > > >
> > > > > > Christoph
> > > > > >
> > > > > Another related bug is:
> > > > >
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> > > > Note that the BZ complains about -fstack-clash-protection in LLVM which
> > > > has had
> > > > various bits landing over the last few months. So that specific issue
> > > > I'd expect
> > > > to resolve itself over time. The more general issue remains though.
> > > https://src.fedoraproject.org/rpms/mpich/pull-request/4
> >
> > Can any proven package retrigger
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48824350, the
> > tests seem flaky and passed for me here:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48825280
> Done. ppc64le seems to have tested fine this time. Of course, there's quite
> a
> back-up on s390x, so it'll be a while before it's done and tagged.
Great, thanks!
>
> jeff
>
>
>
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: mpich always injects lto flags
On Wed, Aug 5, 2020 at 7:01 PM Christoph Junghans wrote:
>
> On Wed, Aug 5, 2020 at 2:21 PM Jeff Law wrote:
> >
> > On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > > Hi,
> > > >
> > > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > > when doing this I hit
> > > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > > which works for the build with openmpi, but gets ignored for the mpich
> > > > build.
> > > >
> > > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > > and then puts them in
> > > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > > >
> > > > So I think the fix would be to strip these flags from mpicc. Sounds
> > > > reasonable?
> > > >
> > > > The flags also contain
> > > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > > >
> > > > Christoph
> > > >
> > > Another related bug is:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> > Note that the BZ complains about -fstack-clash-protection in LLVM which has
> > had
> > various bits landing over the last few months. So that specific issue I'd
> > expect
> > to resolve itself over time. The more general issue remains though.
> https://src.fedoraproject.org/rpms/mpich/pull-request/4
Can any proven package retrigger
https://koji.fedoraproject.org/koji/taskinfo?taskID=48824350, the
tests seem flaky and passed for me here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48825280
Thanks,
Christoph
>
> Christoph
> >
> > jeff
> > >
> > ___
> > 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
>
>
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: mpich always injects lto flags
On Wed, Aug 5, 2020 at 2:21 PM Jeff Law wrote:
>
> On Wed, 2020-08-05 at 21:56 +0200, David Schwörer wrote:
> > On 8/5/20 8:45 PM, Christoph Junghans wrote:
> > > Hi,
> > >
> > > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > > when doing this I hit
> > > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > > which works for the build with openmpi, but gets ignored for the mpich
> > > build.
> > >
> > > I think the problem is that CMake picks up the lto flags from mpicxx
> > > and then puts them in
> > > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> > >
> > > So I think the fix would be to strip these flags from mpicc. Sounds
> > > reasonable?
> > >
> > > The flags also contain
> > > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> > >
> > > Christoph
> > >
> > Another related bug is:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1821728
> Note that the BZ complains about -fstack-clash-protection in LLVM which has
> had
> various bits landing over the last few months. So that specific issue I'd
> expect
> to resolve itself over time. The more general issue remains though.
https://src.fedoraproject.org/rpms/mpich/pull-request/4
Christoph
>
> jeff
> >
> ___
> 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
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: mpich always injects lto flags
On Wed, Aug 5, 2020 at 12:54 PM Jeff Law wrote:
>
> On Wed, 2020-08-05 at 12:45 -0600, Christoph Junghans wrote:
> > Hi,
> >
> > I am trying to rebuild espresso to adapt to the recent cmake changes,
> > when doing this I hit
> > https://github.com/espressomd/espresso/issues/3396, which prevents us
> > from compiling espresso with -lto, so I set _lto_cflags to %{nil},
> > which works for the build with openmpi, but gets ignored for the mpich
> > build.
> >
> > I think the problem is that CMake picks up the lto flags from mpicxx
> > and then puts them in
> > MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
> >
> > So I think the fix would be to strip these flags from mpicc. Sounds
> > reasonable?
> >
> > The flags also contain
> > '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
> > makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
> > while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
> You might try %global (which has global scope) rather than %define (which has
> a
> local scope). Or just strip it away like you've proposed.
%global doesn't help either.
Christoph
>
> jeff
> >
> ___
> 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
--
Christoph Junghans
Web: http://www.compphys.de
___
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
mpich always injects lto flags
Hi,
I am trying to rebuild espresso to adapt to the recent cmake changes,
when doing this I hit
https://github.com/espressomd/espresso/issues/3396, which prevents us
from compiling espresso with -lto, so I set _lto_cflags to %{nil},
which works for the build with openmpi, but gets ignored for the mpich
build.
I think the problem is that CMake picks up the lto flags from mpicxx
and then puts them in
MPI_CXX_COMPILE_OPTIONS. (Also compare mpicc -show).
So I think the fix would be to strip these flags from mpicc. Sounds reasonable?
The flags also contain
'-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1', which effectively
makes it depend on redhat-rpm-config. We had a similar issue in hdf5 a
while back: https://bugzilla.redhat.com/show_bug.cgi?id=1794625
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines
On Tue, Aug 4, 2020 at 7:22 AM Tom Hughes via devel
wrote:
>
> On 04/08/2020 14:11, Neal Gompa wrote:
> > On Tue, Aug 4, 2020 at 9:10 AM Richard Shaw wrote:
> >>
> >> On Tue, Aug 4, 2020 at 6:17 AM Michal Schorm wrote:
> >>>
> >>> Since this change, all (subsequent) CMake commands (after "%cmake")
> >>> MUST be used with the builddir argument ( "-B %{__cmake_builddir}" ).
> >>
> >>
> >> Ok, I'll use that in the future, but it still needs a mention in the
> >> guidelines :)
> >>
> >
> > You are not supposed to use %__cmake_builddir. That macro only exists
> > so we don't have to mutate %_vpath_builddir when switching behaviors
> > through %__cmake_in_source_build.
>
> Surely that's exactly the advantage of using %__cmake_builddir, that it
> points at the place that was actually used for the build regardless of
> whether in source builds are enabled or disabled...
I had to do some similar hackery to make the legion package build
again after the cmake changes:
https://src.fedoraproject.org/rpms/legion/c/bebc0d947b45caa64941507f0f21306b11d87f73?branch=master
certainly not the most elegant way.
My question is if one can set __cmake_builddir to shell variable,
which expands later, something like:
%build
%global __cmake_builddir ${mpi:-serial}
. /etc/profile.d/modules.sh
for mpi in '' mpich openmpi ; do
test -n "${mpi}" && module load mpi/${mpi}-%{_arch}
%cmake
%cmake_build
test -n "${mpi}" && module unload mpi/${mpi}-%{_arch}
done
But I am not 100% sure about the expansion order.
Christoph
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
> ___
> 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
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Latest fedora on docker hub
Hi, it seems fedora:latest on docker hub is still F31. $ docker run -it fedora:latest cat /etc/redhat-release Unable to find image 'fedora:latest' locally latest: Pulling from library/fedora 4c69497db035: Pull complete Digest: sha256:ee55117b3058f2f12961184fae4b9c392586e400487626c6bd0d15b4eae94ecc Status: Downloaded newer image for fedora:latest Fedora release 31 (Thirty One) The README on docker hub (https://hub.docker.com/_/fedora) suggests it should be F32. Cheers, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
module 'posix' not found when module load mpi/mpich-x86_64
Hi, when building some of my mpi packages, I got the following error message: + module load mpi/mpich-x86_64 ++ /usr/share/lmod/lmod/libexec/lmod sh load mpi/mpich-x86_64 /usr/bin/lua: /usr/share/lmod/lmod/libexec/lmod:61: module 'posix' not found: no field package.preload['posix'] no file '/usr/share/lua/5.3/posix.lua' no file '/usr/share/lua/5.3/posix/init.lua' no file '/usr/lib64/lua/5.3/posix.lua' no file '/usr/lib64/lua/5.3/posix/init.lua' no file '/usr/lib64/lua/5.3/posix.so' no file '/usr/lib64/lua/5.3/loadall.so' no file '' stack traceback: [C]: in function 'require' /usr/share/lmod/lmod/libexec/lmod:61: in main chunk [C]: in ? Adding BuildRequires: lua-posix doesn't help. Any ideas? Does lmod need a rebuild for lua-5.3? Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
tingency Plan == > * Contingency mechanism: Proposal owners will adjust macros to not do > out-of-source builds by default, but will preserve newly created macro > (essentially to bring them to the targeted state of older supported > Fedora releases). > * Contingency deadline: Beta freeze. > * Blocks release? No > > == Documentation == > The only place that needs to be adjusted is packaging guidelines. +1 This is very similar to what I suggested in https://src.fedoraproject.org/rpms/cmake/pull-request/4 a couple of months ago. Nice work! Christoph > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Unannounced SONAME bump: libxc.so.5 → libxc.so.9
I will take care of votca-xtp shortly. Christoph On Sat, Apr 18, 2020 at 7:24 AM Fabio Valentini wrote: > > On Sat, Apr 18, 2020 at 3:22 PM Fabio Valentini wrote: > > > > Hi everybody, > > > > The latest rawhide update of libxc (5.0.0) bumped the SONAME as > > mentioned in $SUBJECT. > > > > None of the depending packages have been rebuilt against this version: > > > > - cp2k > > - elk > > - gpaw > > - psi4 > > - python-pyscf > > - votca-xtp > > > > Affected maintainers added to CC. > > > > Fabio > > Oh, sorry - it turns out, this *was* announced two weeks ago, but the > necessary rebuilds have just not happened at all. > > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: mock inside docker
On Thu, Mar 5, 2020 at 9:23 AM Frantisek Zatloukal wrote:
>
> Hi,
>
> adding "--no-bootstrap-chroot" wouldn't help?
Nope, still getting:
ERROR: Command failed:
# /bin/mount -n --bind
/var/cache/mock/fedora-rawhide-x86_64/yum_cache
/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/yum
Christoph
>
> On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans wrote:
>>
>> Hi,
>>
>> if I am trying to run mock inside docker, I am getting the following error:
>> INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
>> ERROR: Command failed:
>> # /bin/mount -n --bind
>> /var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
>>
>> In the past I usually added --old-chroot to workaround that, but now
>> this yields:
>> ERROR: Command failed:
>> # /bin/mount -n -t tmpfs -o rprivate tmpfs
>> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
>>
>> This mock 2.0 inside the f31 ("fedora:latest") container from this morning.
>>
>> Any idea how get mock working again?
>>
>> Christoph
>>
>> --
>> Christoph Junghans
>> Web: http://www.compphys.de
>> ___
>> 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
>
>
>
> --
>
> Best regards / S pozdravem,
>
> František Zatloukal
> Quality Engineer
> Red Hat
> ___
> 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
--
Christoph Junghans
Web: http://www.compphys.de
___
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
mock inside docker
Hi,
if I am trying to run mock inside docker, I am getting the following error:
INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result
ERROR: Command failed:
# /bin/mount -n --bind
/var/cache/mock/fedora-rawhide-x86_64-bootstrap/yum_cache
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/yum
In the past I usually added --old-chroot to workaround that, but now
this yields:
ERROR: Command failed:
# /bin/mount -n -t tmpfs -o rprivate tmpfs
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/proc
This mock 2.0 inside the f31 ("fedora:latest") container from this morning.
Any idea how get mock working again?
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: internal error in mpich on rawhide
On Sat, Feb 22, 2020 at 5:11 PM Christoph Junghans wrote: > > On Sat, Feb 22, 2020 at 1:46 PM Kevin Fenzi wrote: > > > > On Fri, Feb 21, 2020 at 04:21:04PM -0700, Christoph Junghans wrote: > > > Hi, > > > > > > could a proven maintainer have a look at > > > https://src.fedoraproject.org/rpms/mpich/pull-request/2? > > > It causes a FTBFS in espressomd, gromacs and now coin-or-Ipopt on rawhide > > > (see https://bugzilla.redhat.com/show_bug.cgi?id=1803964 for details) > > > > > > The above PR is open for a week and I have pinged the maintainers a > > > while back, too. > > > > Merged and building. Should I cherry pick for f32 also? Or you want to > > do a PR there? Or does this not affect f32? > F32 seems to be fine, I just scratch built gromacs on aarch64 there > successfully. Sorry, I stand corrected, could you please backport it to F32 as well? Thanks, Christoph > > Christoph > > > > 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 > > > > -- > Christoph Junghans > Web: http://www.compphys.de -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: internal error in mpich on rawhide
On Sat, Feb 22, 2020 at 1:46 PM Kevin Fenzi wrote: > > On Fri, Feb 21, 2020 at 04:21:04PM -0700, Christoph Junghans wrote: > > Hi, > > > > could a proven maintainer have a look at > > https://src.fedoraproject.org/rpms/mpich/pull-request/2? > > It causes a FTBFS in espressomd, gromacs and now coin-or-Ipopt on rawhide > > (see https://bugzilla.redhat.com/show_bug.cgi?id=1803964 for details) > > > > The above PR is open for a week and I have pinged the maintainers a > > while back, too. > > Merged and building. Should I cherry pick for f32 also? Or you want to > do a PR there? Or does this not affect f32? F32 seems to be fine, I just scratch built gromacs on aarch64 there successfully. Christoph > > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
internal error in mpich on rawhide
Hi, could a proven maintainer have a look at https://src.fedoraproject.org/rpms/mpich/pull-request/2? It causes a FTBFS in espressomd, gromacs and now coin-or-Ipopt on rawhide (see https://bugzilla.redhat.com/show_bug.cgi?id=1803964 for details) The above PR is open for a week and I have pinged the maintainers a while back, too. Cheers, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Signal 4 (ILL) caught by ps in mock
On Mon, Feb 17, 2020 at 3:45 AM Dan Horák wrote: > > On Mon, 17 Feb 2020 11:26:30 +0100 > Petr Pisar wrote: > > > On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote: > > > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák wrote: > > > > > > > > On Fri, 14 Feb 2020 10:28:10 -0700 > > > > Christoph Junghans wrote: > > > > > > > > > >> > > > > > >> In your case procps-ng package seems to be miscompiled (or > > > > > >> run on an incopatible hardware). I recommend getting a shell > > > > > >> in the mock enviroment (mock --shell) and investigeting > > > > > >> whether the ps program works there). > > > > > > > > > > > > Ok, I will try that and report back. > > > > > It is indeed broken in shell as well: > > > > > sh-5.0# ps > > > > > > > > > > Signal 4 (ILL) caught by ps (3.3.15). > > > > > /usr/bin/ps:ps/display.c:66: please report this bug > > > > > Segmentation fault (core dumped) > > > > > > > > works (no crash) on my Power9 system, but it could be a P9 > > > > instruction sneaked into the binary and crashing on Power8 > > > > systems. I'll take a look, but if you could file a bug (with me > > > > in CC), it would be helpful. > > > just to make sure, I am running this in mock on the following > > > system: $ cat /proc/cpuinfo > > > processor : 0 > > > vendor_id : GenuineIntel > > > cpu family : 6 > > > model : 142 > > > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz > > > > Then you actually run the PowerPC ps binary in QEMU emulator. Could > > you show the /proc/cpuinfo from inside of the mock environment? > > first I suggest to use the latest qemu from the virt-preview repo [1] > and if it still SIGILLs, then report a bugu against qemu. I don't see > any problem with "ps" on (real) Power8 or Power9 hw, so most likely it's > an emulation bug. Updating qemu-common to 2:4.2.0-4 fixed the issue. Christoph > > [1] > https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/ > > > > Dan > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Signal 4 (ILL) caught by ps in mock
On Mon, Feb 17, 2020 at 3:27 AM Petr Pisar wrote: > > On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote: > > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák wrote: > > > > > > On Fri, 14 Feb 2020 10:28:10 -0700 > > > Christoph Junghans wrote: > > > > > > > >> > > > > >> In your case procps-ng package seems to be miscompiled (or run on > > > > >> an incopatible hardware). I recommend getting a shell in the mock > > > > >> enviroment (mock --shell) and investigeting whether the ps program > > > > >> works there). > > > > > > > > > > Ok, I will try that and report back. > > > > It is indeed broken in shell as well: > > > > sh-5.0# ps > > > > > > > > Signal 4 (ILL) caught by ps (3.3.15). > > > > /usr/bin/ps:ps/display.c:66: please report this bug > > > > Segmentation fault (core dumped) > > > > > > works (no crash) on my Power9 system, but it could be a P9 instruction > > > sneaked into the binary and crashing on Power8 systems. I'll take a > > > look, but if you could file a bug (with me in CC), it would be helpful. > > just to make sure, I am running this in mock on the following system: > > $ cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 142 > > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz > > Then you actually run the PowerPC ps binary in QEMU emulator. Could you show > the /proc/cpuinfo from inside of the mock environment? It is the same inside mock! > > -- Petr > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Signal 4 (ILL) caught by ps in mock
On Fri, Feb 14, 2020 at 10:37 AM Dan Horák wrote: > > On Fri, 14 Feb 2020 10:28:10 -0700 > Christoph Junghans wrote: > > > >> > > >> In your case procps-ng package seems to be miscompiled (or run on > > >> an incopatible hardware). I recommend getting a shell in the mock > > >> enviroment (mock --shell) and investigeting whether the ps program > > >> works there). > > > > > > Ok, I will try that and report back. > > It is indeed broken in shell as well: > > sh-5.0# ps > > > > Signal 4 (ILL) caught by ps (3.3.15). > > /usr/bin/ps:ps/display.c:66: please report this bug > > Segmentation fault (core dumped) > > works (no crash) on my Power9 system, but it could be a P9 instruction > sneaked into the binary and crashing on Power8 systems. I'll take a > look, but if you could file a bug (with me in CC), it would be helpful. just to make sure, I am running this in mock on the following system: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 142 model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz stepping : 9 cpu MHz : 3504.000 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor ssse3 cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase avx2 invpcid rdseed clflushopt md_clear flush_l1d bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 7008.00 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: Christoph > > > Dan > ___ > 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 -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Signal 4 (ILL) caught by ps in mock
On Fri, Feb 14, 2020 at 6:38 AM Christoph Junghans wrote: > > > > On Fri, Feb 14, 2020, 00:16 Petr Pisar wrote: >> >> On Thu, Feb 13, 2020 at 07:48:22PM -0700, Christoph Junghans wrote: >> > when running "mock -r fedora-rawhide-ppc64le --no-clean >> > gromacs-2019.5-2.fc32.1.src.rpm" >> > I am getting the following error: >> > Signal 4 (ILL) caught by ps (3.3.15). >> > /usr/bin/ps:ps/display.c:66: please report this bug >> > >> > I tried a couple of different src.rpm with the same result. >> > This is mock 1.4.21 on f31. >> > >> > Has anybody else seen this? >> > >> Not exactly, but if you check Koji build history for gromacs package >> <https://koji.fedoraproject.org/koji/packageinfo?packageID=6961>. You will >> find out that the build failed during F32 mass rebuild >> <https://koji.fedoraproject.org/koji/taskinfo?taskID=41318028> on ppc64le and >> aarch64. The ppc64le failure is: > > That was exactly the reason why I was looking into building this ppc64le ;-) But unfortunately the Signal 4 shows up before it even gets to the CMake part. > >> >> -- Performing Test CXX_mvsx_COMPILE_WORKS - Failed >> -- Flag was accepted, but it did not build test source (this could be due to either the compiler or binutils) >> -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED >> -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED - Success >> -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS >> -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS - Failed >> -- Flag was accepted, but it did not build test source (this could be due to either the compiler or binutils) >> -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED >> -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED - Failed >> -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS >> -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS - Failed >> -- Could not find any flag to build test source (this could be due to either the compiler or binutils) >> CMake Error at cmake/gmxManageSimd.cmake:51 (message): >> Cannot find IBM VSX compiler flag. Use a newer compiler, or disable SIMD >> support (slower). >> Call Stack (most recent call first): >> cmake/gmxManageSimd.cmake:265 (gmx_give_fatal_error_when_simd_support_not_found) >> CMakeLists.txt:719 (gmx_manage_simd) >> -- Configuring incomplete, errors occurred! >> See also "/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeOutput.log". >> See also "/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeError.log". >> >> Koschei history <https://koschei.fedoraproject.org/package/gromacs> claims the >> build started to fail with these changes >> <https://koschei.fedoraproject.org/build/7747640>. It's probably a triggered by >> an upgrade of GCC to 10 version. >> >> SIGILL means the processor met an instruction it does not understand. >> >> In your case procps-ng package seems to be miscompiled (or run on an >> incopatible hardware). I recommend getting a shell in the mock enviroment >> (mock --shell) and investigeting whether the ps program works there). > > Ok, I will try that and report back. It is indeed broken in shell as well: sh-5.0# ps Signal 4 (ILL) caught by ps (3.3.15). /usr/bin/ps:ps/display.c:66: please report this bug Segmentation fault (core dumped) > >> >> My gut feeling is that GCC 10 started to omit new instructions and your >> hardware is not compatible with them. Can you reproduce it on one of these >> machines >> < https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers >? > > Using these machines might be the easiest way the track down the gromacs issue, thanks for the reminder that we have these resources. > > Christoph > >> >> -- Petr >> ___ >> 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 -- Christoph Junghans Web: http://www.compphys.de -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Signal 4 (ILL) caught by ps in mock
On Fri, Feb 14, 2020, 00:16 Petr Pisar wrote: > On Thu, Feb 13, 2020 at 07:48:22PM -0700, Christoph Junghans wrote: > > when running "mock -r fedora-rawhide-ppc64le --no-clean > > gromacs-2019.5-2.fc32.1.src.rpm" > > I am getting the following error: > > Signal 4 (ILL) caught by ps (3.3.15). > > /usr/bin/ps:ps/display.c:66: please report this bug > > > > I tried a couple of different src.rpm with the same result. > > This is mock 1.4.21 on f31. > > > > Has anybody else seen this? > > > Not exactly, but if you check Koji build history for gromacs package > <https://koji.fedoraproject.org/koji/packageinfo?packageID=6961>. You will > find out that the build failed during F32 mass rebuild > <https://koji.fedoraproject.org/koji/taskinfo?taskID=41318028> on ppc64le > and > aarch64. The ppc64le failure is: > That was exactly the reason why I was looking into building this ppc64le ;-) But unfortunately the Signal 4 shows up before it even gets to the CMake part. > -- Performing Test CXX_mvsx_COMPILE_WORKS - Failed > -- Flag was accepted, but it did not build test source (this could be due > to either the compiler or binutils) > -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED > -- Performing Test CXX_maltivec_mabi_altivec_FLAG_ACCEPTED - Success > -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS > -- Performing Test CXX_maltivec_mabi_altivec_COMPILE_WORKS - Failed > -- Flag was accepted, but it did not build test source (this could be due > to either the compiler or binutils) > -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED > -- Performing Test CXX_qarch_auto_qaltivec_FLAG_ACCEPTED - Failed > -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS > -- Performing Test CXX_COMPILE_WORKS_WITHOUT_SPECIAL_FLAGS - Failed > -- Could not find any flag to build test source (this could be due to > either the compiler or binutils) > CMake Error at cmake/gmxManageSimd.cmake:51 (message): > Cannot find IBM VSX compiler flag. Use a newer compiler, or disable SIMD > support (slower). > Call Stack (most recent call first): > cmake/gmxManageSimd.cmake:265 > (gmx_give_fatal_error_when_simd_support_not_found) > CMakeLists.txt:719 (gmx_manage_simd) > -- Configuring incomplete, errors occurred! > See also > "/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeOutput.log". > See also > "/builddir/build/BUILD/gromacs-2019.5/serial/CMakeFiles/CMakeError.log". > > Koschei history <https://koschei.fedoraproject.org/package/gromacs> > claims the > build started to fail with these changes > <https://koschei.fedoraproject.org/build/7747640>. It's probably a > triggered by > an upgrade of GCC to 10 version. > > SIGILL means the processor met an instruction it does not understand. > > In your case procps-ng package seems to be miscompiled (or run on an > incopatible hardware). I recommend getting a shell in the mock enviroment > (mock --shell) and investigeting whether the ps program works there). > Ok, I will try that and report back. > My gut feeling is that GCC 10 started to omit new instructions and your > hardware is not compatible with them. Can you reproduce it on one of these > machines > < > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > >? Using these machines might be the easiest way the track down the gromacs issue, thanks for the reminder that we have these resources. Christoph > -- Petr > ___ > 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 > ___ 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
Signal 4 (ILL) caught by ps in mock
Hi, when running "mock -r fedora-rawhide-ppc64le --no-clean gromacs-2019.5-2.fc32.1.src.rpm" I am getting the following error: Signal 4 (ILL) caught by ps (3.3.15). /usr/bin/ps:ps/display.c:66: please report this bug I tried a couple of different src.rpm with the same result. This is mock 1.4.21 on f31. Has anybody else seen this? Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
dnf exit code
Hi, I am getting an exit code 143 when running dnf in docker, example: $ cat Dockerfile FROM fedora:rawhide RUN dnf install -y openmpi-devel $ docker build . ... Running scriptlet: systemd-245~rc1-2.fc32.x86_64 121/121 Running scriptlet: systemd-udev-245~rc1-2.fc32.x86_64 121/121The command '/bin/sh -c dnf install -y openmpi-devel' returned a non-zero code: 143 Only on rawhide, f31 works fine, i.e. $ cat Dockerfile FROM fedora:31 RUN dnf install -y openmpi-devel $ docker build . Complete! Removing intermediate container 85bb626aff58 ---> e9a30f6992d7 Successfully built e9a30f6992d7 Any ideas? Thanks, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 1:31 PM Stephen John Smoogen wrote: > On Wed, 22 Jan 2020 at 14:54, Christoph Junghans > wrote: > > > > On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok > wrote: > >> > > >> jtaylornetsniff-ng ocaml-lablgtk suricata > >> junghans gasnet > > > > Sorry, how do I install gcc10 on Rawhide? > > "dnf upgrade --advisory=FEDORA-2020-a165791b6f" doesn't seem to do it. > > > > Christoph > > > >> > > Going from a similar discussion in #fedora-devel. There has been no > current compose of rawhide so it can not be synced out of the mirror. > In order to upgrade/install gcc10 you will need to enable the local > repo in mock or replicate it on your system. > I see and how do I do that? > > 2020-01-21 18:33:05 fedora-32 is still at gcc-9.2.1, but I got > an em > ail saying cjdns no longer builds with gcc-10. How do I rebuild with > gcc-10 to > get this fixed? I assume the goal is to get most packages ready for > gcc-10 befo > re upgrading rawhide. > 2020-01-21 18:58:03 sdgathman: rawhide/f32 already has > gcc-10... the > re just hasn't been a successfull rawhide compose syncing it out to > mirrors. You > can do scratch builds or you could enable the 'local' repo in mock to use > the k > oji buildroot... > > > -- > Stephen J Smoogen. > ___ > 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 > -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: gcc 10: Default to -fno-common, multiple definitions of ...
ix iproute strongswan > pbrobinson csound dtc hippo-canvas speech-dispatcher uboot-tools > vboot-utils > pcahynacdrkit > pcmoorelibsepol policycoreutils > pcpa megaglest planarity sympow > pemensik dhcp > peter coreboot-utils erlang flashrom nagios opensips sipsak > pfrields foremost pioneers > pghmcfcgtkwave > pgordonglabels > pidgornyy bspwm sxhkd > pjones device-mapper-multipath > pkfed slurm > pkratoch libcomps > pkubat pax > plautrba checkpolicy libsepol opencryptoki policycoreutils > plindner memcached > pmachata libunwind > pmuldoon frysk > ppisar libisds nas ramond sharutils shigofumi wmfrog > praiskup libunicap pax postgresql-pgpool-II > prajnoha device-mapper-multipath > praveenp ipmitool sblim-sfcb > psabatatinyfugue > pspacekbird > psutteriproute > pvrabecfwknop openscap > pwalterggz-gtk-client gnome-control-center roxterm warsow > pwouters alpine hping3 libreswan strongswan > pwuibus-rime > qulogicR-Rmpfr R-curl > raphgrognurobbo xvkbd > rathannapbs chemtool crm114 gabedit hnb libgadu libxsmm ming ocl-icd > pseudo > raveit65 caja engrampa mate-applets mate-utils python-caja > ravindrakumar open-vm-tools > rclark mesa ocl-icd > rcritten mod_nss > rdieterBitchX Macaulay2 alpine mate-applets mate-utils nas sbcl xforms > rebus hydra medusa ncrack packETH skipfish > remi libmemcached > renich gtick > rhughesNetworkManager argyllcms file-roller mesa xorg-x11-drv-ati > xorg-x11-server > richardfearn ncdu > rishi vinagre > rjones erlang mingw-nsis ocaml ocaml-lablgtk open-vm-tools > rluzynski gnome-abrt > rmattesmosquitto > rmeggins 389-ds-base > robert bird flashrom iftop libunicap partclone tcpick xforms > robyduck xfce4-sensors-plugin > romal nagios > roshansingh artha opendchub > rrankindenemo > rsroka rsyslog > rstrodeNetworkManager file-roller mesa xorg-x11-drv-ati xorg-x11-server > runcom i3 > rvokal adns iproute > s4504krinadyn-mt > sadmac libnih > salimmagamazons gauche gnugo neovim nickle roxterm typespeed > sandeene2fsprogs fio ncid ndctl xfsprogs > saprasad libreswan > sbueno x3270 > scottt urjtag > sdzcsound sugar-toolkit > sergiomb gpm webalizer > sergiopr psfex sextractor swarp > sgrubb audit suricata > sham1 wmCalClock wmacpi > sharkczopencryptoki ski uboot-tools x3270 xa > sinnykumari opencryptoki > skottler erlang > slaanesh ocl-icd open-vm-tools > slankesgimp-lqr-plugin libacpi > slavazanko mc > smani gmsh mingw-nsis mingw-qt5-qtbase openambit > smilnerncrack > smooge nagios > snirkelgnomad2 > splinuxfbpanel > spot SDL2 alienarena enlightenment libunwind logjam > nacl-arm-binutils > qstat rocksndiamonds tkimg xmbdfed xorg-x11-drv-ati > spstarrnagios > sspNetworkManager file-roller mesa xorg-x11-server > stahnmacdpr > stefanok mate-utils > steved libtirpc nfs-utils > stevetraylen qstat > stingray flow-tools > stransky seamonkey > suchakra lttng-tools lttng-ust > sundaram chocolate-doom > svashisht logrotate > swilkerson nagios > tachoknight nethack > tagoh imsettings libgcroots > tartaregeomorph > tartinajamin phasex > terjeros ganglia gq mtpaint scsi-target-utils wf > teuf mingw-nsis vinagre > thallerNetworkManager > than efax menu-cache > thias memcached ncftp > thmawesome > thofmann sway > thozza adns dhcp wget > tibbs amanda > till bindfs fatsort > timfennapbs > timn clips coriander > tingping transmission-remote-gtk > tkanteck intel-cmt-cat > tkorbarlibmemcached memcached > tmraz galculator gnupg2 > tnorth alliance > tohojo bird > tomeu sugar-toolkit > tosykora rsyslog > tredaell dpdk > trembleMacaulay2 arc halibut > tross qpid-dispatch > tstellar mesa > ttorcz owfs > twaugh cups-filters pnm2ppa > twoerner iproute > uraeus gstreamer1-plugins-bad-free > vascom gimp-wavelet-denoise-plugin mcabber > vcrhonek bogl epic kbd sblim-gather sblim-sfcb sblim-smis-hba > vdamc > vdolezal amanda dump ipmitool > verdurin bwa > vicodanenlightenment > vishalvndctl > vmojzischeckpolicy libsepol policycoreutils > volter mbrowse > whot xorg-x11-drv-ati xorg-x11-server > wolfy pam_ssh > wsato openscap > wtaymans gstreamer1-plugins-bad-free pipewire > wzzrd glabels ykpers > xgl-maint xorg-x11-drv-ati xorg-x11-server > zbyszekgeeqie gpm > zdohnalc2esp cups-filters pnm2ppa > zsun gcin kabi-dw menu-cache trace-cmd > zultronspacenavd > zvetliksway > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Christoph Junghans Web: http://www.compphys.de ___ 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
OpenMPI is flaky
Hi, I was trying to bump the espresso package to v4.1.1 and came across multiple issues in the %check phase of the builds on Rawhide, F31 and EPEL8. On Rawhide and F31, some tests seem to receive an error in the MPI_INIT phase. Error: *** An error occurred in MPI_Init *** on a NULL communicator This happened with OpenMPI, but not MPICH. I was able to workaround these failures by retriggering the builds a couple of times, which isn't a great solution. Upstream issues on that topic: Rawhide: https://github.com/espressomd/espresso/issues/3306 F31: https://github.com/espressomd/espresso/issues/3305 On EPEL8 however, things are much worse - multiple tests fail on each arch in MPI_INIT incl. a couple of segfaults: https://github.com/espressomd/espresso/issues/3307 I wasn't able to reproduce these issues in a CentOs8 container in docker. Any ideas and help would be appreciated. Unrelated, but still annoying I saw a Fatal Python error: init_sys_streams: can't initialize sys standard streams on s390x (F31), which got triggered by setting the somewhat unrelated CMAKE_SKIP_RPATH=ON option. Any suggestions on that would be more than welcome. Upstream issue: https://github.com/espressomd/espresso/issues/3316 Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: Unretire txt2tags package?
On Wed, Aug 14, 2019 at 12:20 PM Miro Hrončok wrote:
>
> On 14. 08. 19 20:03, Christoph Junghans wrote:
> > Hi,
> >
> > txt2tags was recently retired due to FTBFS
> > (https://bugzilla.redhat.com/show_bug.cgi?id=1676168) as it requires
> > python2.
>
> Just a note: We haven't retired any package just because it requires python2
> (not yet anyway).
You are correct, I see it now.
The FTBFS fix is actually trivial:
diff --git a/txt2tags.spec b/txt2tags.spec
index ebb78e3..38ea2e4 100644
--- a/txt2tags.spec
+++ b/txt2tags.spec
@@ -54,6 +54,7 @@ rm -rf %{buildroot}
#Install the executable
install -Dp -m0755 txt2tags %{buildroot}%{_bindir}/txt2tags
+sed -i '1s/python/&2/' %{buildroot}%{_bindir}/txt2tags
#Install manpages
install -Dp -m0644 doc/manpage.man %{buildroot}%{_mandir}/man1/txt2tags.1
Do I need a review to unretire this package?
Christoph
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Unretire txt2tags package?
Hi, txt2tags was recently retired due to FTBFS (https://bugzilla.redhat.com/show_bug.cgi?id=1676168) as it requires python2. txt2tags is still needed for some of my packages, e.g. votca-csg to build manpages. There is an python3 port of the last release by rednotebook (see https://github.com/txt2tags/txt2tags/issues/207#issuecomment-461846655), which we could package. Any objections? Alternatively, we could disable the manpages in votca-csg. Christoph -- Christoph Junghans Web: http://www.compphys.de ___ 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
Re: error: More than one file on a line
On Sat, Aug 3, 2019 at 3:27 PM Elliott Sales de Andrade
wrote:
>
>
>
> On Sat, Aug 3, 2019, 3:49 PM Christoph Junghans, wrote:
>>
>> Hi,
>>
>> related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
>> I am getting a strange error:
>>
>> RPM build errors:
>> BUILDSTDERR: More than one file on a line:
>> /_kim-api-collections-management
>> BUILDSTDERR: More than one file on a line:
>> /kim-api-collections-management.bash
>> (see https://koji.fedoraproject.org/koji/taskinfo?taskID=36767148)
>> I remember I have seen this before for bash-completion files, but I
>> can unfortunately not remember what the solution was.
>>
>> the lines in the spec triggering this install are:
>> %files
>> ...
>> %{z_compdir}/_kim-api-collections-management
>> %{z_compdir}/kim-api-collections-management.bash
>> with:
>> %global z_compdir "%{_datadir}/zsh/site-functions"
>> which is given to CMake
>> %{cmake3} -DZSH_COMPLETION_COMPLETIONSDIR=%{z_compdir} ..
>> and picked up correctly:
>> -- Installing:
>> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/_kim-api-collections-management
>> -- Installing:
>> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/kim-api-collections-management.bash
>> nagement
>>
>> Any ideas?
>
>
> Remove the quotes on the %global and only use them for the shell invocations
> (or not at all because there won't be any spaces in the path anyway.)
Thanks, that did the trick!
Christoph
>
>> Christoph
>>
>>
>>
>> --
>> Christoph Junghans
>> Web: http://www.compphys.de
>> ___
>> 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
>
> ___
> 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
--
Christoph Junghans
Web: http://www.compphys.de
___
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
error: More than one file on a line
Hi,
related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
I am getting a strange error:
RPM build errors:
BUILDSTDERR: More than one file on a line: /_kim-api-collections-management
BUILDSTDERR: More than one file on a line:
/kim-api-collections-management.bash
(see https://koji.fedoraproject.org/koji/taskinfo?taskID=36767148)
I remember I have seen this before for bash-completion files, but I
can unfortunately not remember what the solution was.
the lines in the spec triggering this install are:
%files
...
%{z_compdir}/_kim-api-collections-management
%{z_compdir}/kim-api-collections-management.bash
with:
%global z_compdir "%{_datadir}/zsh/site-functions"
which is given to CMake
%{cmake3} -DZSH_COMPLETION_COMPLETIONSDIR=%{z_compdir} ..
and picked up correctly:
-- Installing:
/builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/_kim-api-collections-management
-- Installing:
/builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/kim-api-collections-management.bash
nagement
Any ideas?
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
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
Re: module load inside rpmbuild inside docker
On Sat, May 4, 2019 at 5:30 AM Neal Gompa wrote:
>
> On Sat, May 4, 2019 at 7:26 AM Daniel Walsh wrote:
> >
> > On 5/3/19 6:00 PM, Christoph Junghans wrote:
> > > Hi,
> > >
> > > I wanted to bump the legion package to 19.04.0
> > > (https://bugzilla.redhat.com/show_bug.cgi?id=1705033), however for
> > > some reason all tests segfault with openmpi
> > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=34577005), so I
> > > reported this upstream
> > > (https://github.com/StanfordLegion/legion/issues/533) and included a
> > > minimal dockerfile to reproduce this issue:
> > >
> > > FROM fedora:rawhide
> > > RUN dnf install -y spectool wget rpm-build dnf-plugins-core
> > > RUN wget
> > > https://src.fedoraproject.org/fork/junghans/rpms/legion/raw/master/f/legion.spec
> > > RUN spectool -g legion.spec
> > > RUN dnf builddep -y legion.spec
> > > RUN dnf install -y make
> > > RUN rpmbuild -D"_sourcedir ${PWD}" -D"_srcrpmdir ${PWD}" -ba legion.spec
> > >
> > > This worked fine on Thursday(?) to reproduce the failing tests in
> > > %check, but now rpmbuild fails at an earlier stage with:
> > > + module load mpi/mpich-x86_64
> > > ++ /usr/share/lmod/lmod/libexec/lmod sh load mpi/mpich-x86_64
> > > Lmod has detected the following error: The following module(s) are
> > > unknown:
> > > "mpi/mpich-x86_64"
> > >
> > > If I jump into the container interactively (docker run -it ..
> > > /bin/bash), "module load" as well as rpmbuild (and "module load"
> > > inside) works.
> > >
> > > If know this is a convoluted case, but any ideas how fix this?
> > >
> > > Christoph
> > >
> > >
> > Are you running a privileged container in one case and not in the
> > other. Normal running of containers should not allow you to load a
> > kernel module.
> >
> >
> > BTW Have you tried this with Podman?
>
> I'm pretty sure these aren't kernel modules, but environment modules
> for OpenMPI and such...
Correct.
I am thinking there is something missing in the default environment in
the container, that gets loaded in the interactive mode.
Christoph
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
module load inside rpmbuild inside docker
Hi,
I wanted to bump the legion package to 19.04.0
(https://bugzilla.redhat.com/show_bug.cgi?id=1705033), however for
some reason all tests segfault with openmpi
(https://koji.fedoraproject.org/koji/taskinfo?taskID=34577005), so I
reported this upstream
(https://github.com/StanfordLegion/legion/issues/533) and included a
minimal dockerfile to reproduce this issue:
FROM fedora:rawhide
RUN dnf install -y spectool wget rpm-build dnf-plugins-core
RUN wget
https://src.fedoraproject.org/fork/junghans/rpms/legion/raw/master/f/legion.spec
RUN spectool -g legion.spec
RUN dnf builddep -y legion.spec
RUN dnf install -y make
RUN rpmbuild -D"_sourcedir ${PWD}" -D"_srcrpmdir ${PWD}" -ba legion.spec
This worked fine on Thursday(?) to reproduce the failing tests in
%check, but now rpmbuild fails at an earlier stage with:
+ module load mpi/mpich-x86_64
++ /usr/share/lmod/lmod/libexec/lmod sh load mpi/mpich-x86_64
Lmod has detected the following error: The following module(s) are unknown:
"mpi/mpich-x86_64"
If I jump into the container interactively (docker run -it ..
/bin/bash), "module load" as well as rpmbuild (and "module load"
inside) works.
If know this is a convoluted case, but any ideas how fix this?
Christoph
--
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: openmpi breakage on Rawhide
I think a rebuild will fix the problem: https://src.fedoraproject.org/rpms/openmpi/pull-request/5 On Wed, Apr 17, 2019 at 9:53 AM Christoph Junghans wrote: > > Hi all, > > Some of my packages failed to build due to a openmpi breakage > > DEBUG util.py:554: BUILDSTDERR: Error: > DEBUG util.py:554: BUILDSTDERR: Problem: package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers can > be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the > providers can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none of > the providers can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires > liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the providers > can be installed > DEBUG util.py:554: BUILDSTDERR: - package > openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, but > none of the providers can be installed > DEBUG util.py:554: BUILDSTDERR: - conflicting requests > DEBUG util.py:554: BUILDSTDERR: - nothing provides > libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 > > Christoph > > -- > Christoph Junghans > Web: http://www.compphys.de -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
openmpi breakage on Rawhide
Hi all, Some of my packages failed to build due to a openmpi breakage DEBUG util.py:554: BUILDSTDERR: Error: DEBUG util.py:554: BUILDSTDERR: Problem: package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_cxx.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_mpifh.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_usempif08.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires libmpi_java.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires liboshmem.so.40()(64bit)(openmpi-x86_64), but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - package openmpi-devel-3.1.3-3.fc31.x86_64 requires openmpi = 3.1.3-3.fc31, but none of the providers can be installed DEBUG util.py:554: BUILDSTDERR: - conflicting requests DEBUG util.py:554: BUILDSTDERR: - nothing provides libosmcomp.so.4()(64bit) needed by openmpi-3.1.3-3.fc31.x86_64 Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What is a PDC branch?
On Tue, Apr 16, 2019 at 7:21 AM Robert-André Mauchin wrote: > > On Tuesday, 16 April 2019 04:40:22 CEST Jerry James wrote: > > I had two packages pass review a couple of weeks ago. However, my > > requests for repos were closed as invalid because "The PDC branch > > already exists". I reopened the tickets with a request for more > > information, but they just got closed again with the same message, > > which tells me that humans are not reading these, so there's no point > > in opening them again. Here are the relevant tickets: > > > > https://pagure.io/releng/fedora-scm-requests/issue/10798 > > https://pagure.io/releng/fedora-scm-requests/issue/10799 > > https://pagure.io/releng/fedora-scm-requests/issue/10800 > > https://pagure.io/releng/fedora-scm-requests/issue/10801 > > > > Could somebody please (a) tell me what on earth that means, and (b) > > fix whatever generates that error message so that it says something > > intelligible to us mere mortals? > > > > Thank you, > > -- > > Jerry James > > http://www.jamezone.org/ > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > It means your packages already exist in the Product Definition Center, > For example: > https://pdc.fedoraproject.org/rest_api/v1/component-branches/? > active=true&global_component=gap-pkg-francy > > Most likely the script which creates them went wrong. Ask infra to solve the > issues. I had the same problem for the newly added kim-api package: https://pagure.io/releng/fedora-scm-requests/issue/11076 https://pagure.io/releng/fedora-scm-requests/issue/11077 https://pagure.io/releng/fedora-scm-requests/issue/11078 https://pagure.io/releng/fedora-scm-requests/issue/11079 However I was able to create branches myself, by disabling the "Prevent creating new branches by git push" hook and doing: $ git push origin master:f30 $ git push origin master:f29 $ git push origin master:f28 $ git push origin master:epel7 Christoph > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Translating spec to dockerfile for upstream ispc
On Fri, Feb 22, 2019 at 10:31 PM Luya Tshimbalanga
wrote:
>
> Upstream ISPC [0] will need a dockerfile to reproduce the failure to
> build ispc package in Fedora[1][2]. Unfortunately, I know very little
> about the Docker functionality so I will need assistance to do so.
You can do an rpm build from a spec file within docker with a
dockerfile like this:
FROM fedora:rawhide
RUN dnf install -y spectool git rpm-build dnf-plugins-core
RUN git clone https://src.fedoraproject.org/rpms/ispc.git
WORKDIR ispc
RUN spectool -g ispc.spec
RUN dnf builddep -y ispc.spec
RUN rpmbuild -D"_sourcedir ${PWD}" -D"_srcrpmdir ${PWD}" -ba ispc.spec
(you might need to point git to clone the right spec file.)
Christoph
>
> The docker file for Fedora is inside the upstream tarball .
>
> Thanks in advance.
>
> Luya
>
> References
>
> ---
>
> [0] https://github.com/ispc/ispc
>
> [1] https://github.com/ispc/ispc/issues/1413
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1675162
>
> [3] https://src.fedoraproject.org/rpms/ispc
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Assertion in stl_vector.h
On Wed, Feb 13, 2019 at 1:35 PM Christoph Junghans wrote: > > Hi, > > I am trying to debug https://bugzilla.redhat.com/show_bug.cgi?id=1674863 > however I cannot reproduce the issue locally using mock: > https://github.com/espressomd/espresso/issues/2507#issuecomment-463262689 > nor can upstream, however it still fails in a recent scratch build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=32789573 > > Any ideas on how to attack this? Upstream found it, it is a bug in Boost.MPI: https://github.com/espressomd/espresso/issues/2507#issuecomment-463652108 and it got reported upstream: https://github.com/boostorg/mpi/pull/81 Christoph > > Christoph > > -- > Christoph Junghans > Web: http://www.compphys.de -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: GCC 9 OpenMP issues
On Tue, Feb 12, 2019 at 5:39 PM Orion Poplawski wrote:
>
> On 2/12/19 1:02 AM, Jakub Jelinek wrote:
> > On Mon, Feb 11, 2019 at 07:17:25PM -0700, Orion Poplawski wrote:
> >> Looks like GCC 9 is finally enforcing an OpenMP change:
> >>
> >> From https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html
> >
> > Please see https://gcc.gnu.org/gcc-9/porting_to.html#ompdatasharing
> > which documents what you can do and what works with both compilers and what
> > doesn't.
>
> Thanks for the reference.
>
> >> GCC 8 complains about just adding fp_stderr to shared():
> >>
> >> nco_omp.c: In function 'nco_openmp_ini':
> >> nco_omp.c:205:43: error: 'fp_stderr' is predetermined 'shared' for 'shared'
> >> # pragma omp parallel default(none) shared(fp_stderr,thr_nbr_act)
> >
> > Yes, either you want firstprivate(fp_stderr), or drop default(none) if you
> > want to make it work with both compilers.
>
> Okay. In this case we'll probably drop default(none). Many people have
> gotten into the habit of using default(none) though in order to force
> declaring the form of all variables.
>
> >> And apparently complains if you drop default(none) as well (from another
> >> project with the same problem):
> >>
> >> [ 9%] Building CXX object CMakeFiles/_CuraEngine.dir/src/layerPart.cpp.o
> >> /home/ruben/Projects/CuraEngine/src/layerPart.cpp: In function ‘void
> >> cura::createLayerParts(cura::SliceMeshStorage&, cura::Slicer*)’:
> >> /home/ruben/Projects/CuraEngine/src/layerPart.cpp:52:78: error:
> >> ‘total_layers’ is predetermined ‘shared’ for ‘shared’
> >> #pragma omp parallel for shared(mesh, slicer, total_layers)
> >> schedule(dynamic)
> >
> > That is with GCC 8 or earlier, right? Just leave total_layers out
> > of the shared clause.
>
> Right, because the default is to be shared. Thanks.
For the lammps package I chatted with upstream:
https://github.com/lammps/lammps/issues/1326
and they already had a hack_openmp script in their source for the PGI
compiler, which basically boils down to something like:
find . -type f \( -name "*.cpp" -or -name "*.h" \) -exec sed -e
'/#pragma omp/s/default(none)/default(shared)/' -e '/#pragma
omp/s/shared([^)]\+)//' -i {} +
and that did the trick for now, while upstream is fixing it for good:
https://github.com/lammps/lammps/pull/1330
Cheers,
Christoph
>
> --
> Orion Poplawski
> Manager of NWRA Technical Systems 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Assertion in stl_vector.h
Hi, I am trying to debug https://bugzilla.redhat.com/show_bug.cgi?id=1674863 however I cannot reproduce the issue locally using mock: https://github.com/espressomd/espresso/issues/2507#issuecomment-463262689 nor can upstream, however it still fails in a recent scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=32789573 Any ideas on how to attack this? Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Debugging ppc64le
On Wed, Feb 6, 2019 at 5:11 AM Miroslav Suchý wrote: > > Dne 06. 02. 19 v 1:47 Christoph Junghans napsal(a): > > Is there a good way (qemu or something) to debug this interactively? > > https://github.com/rpm-software-management/mock/wiki/Feature-forcearch Thanks, "mock -r epel-7-ppc64le --forcearch ppc64le --dnf shell" did it for me! Christoph > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Debugging ppc64le
Hi, While packaging up votca-csg-1.5, I ran into some tests failing: https://github.com/votca/csg/issues/326 but this only happens on ppc64le under epel7. (So I expect boost-1.53 being the culprit!) Is there a good way (qemu or something) to debug this interactively? Cheers, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, Feb 18, 2018 at 10:09 AM, Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Over this weekend I've performed scratch-mass-rebuild without having gcc and > gcc-c++ in buildroot of all Fedora packages, many of which failed due to > random > reasons and I grepped all logs for some common errors found by analyzing > hundreds of build logs. > > Guidelines: > https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire > s_and_Requies > > The grep output is located here: > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt > > Some packages might be missed due to short koji outage, broken dependencies > and > so on, but majority of real failures is below. > > If you fixed package(s), found false positive, found missing packages in list > or anything else -- please let me know. > > Note to packages which use CMake buildsystem. When you have project(xxx) in > CMakeLists.txt it checks both for C and CXX compilers. So you might encounter > packages where you have BuildRequires: gcc and it fails on CXX compiler (even > you think you don't need it). Solution for this is to send patch to upstream > switching to something like project(xxx C), or if problem is opposite to > project(xxx CXX). > > List of packages and respective maintainers: > https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt I just fixed espresso exodusii gasnet libaec tng votca-csg votca-tools! gromacs and votca-xtp have the fix, but they fail to build for a different reason. > > - -- > - -Igor Gnatenko > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJs1QACgkQaVcUvRu8 > X0xxkRAAj56QZYSxzDXiMyvM9eLdVS0Qrt9jiNa66rasIbDVciTym7WQoV2CXxM+ > ZxaOCYU8eyxOhE1rx36KITJ7SgU6ugLu2dVZlG/QR8vH3RTqJPV/GWhM/WUAgaon > f/SPwTIMk31qvEuKwlqLgNH1rwpRH2NfWVelZChwi1zXOglMvIHakV7sSedYy2i9 > bmVvf/1ylj/NbaI6FaLUqg81UQhUulD8RYeZi1cyxSpit/4aysP7ixCb4MLizmwH > uNUO0y//xxL0hMSShmfTlsPXowU+NpkzV+lFQ/k2X4KcCZWMabfCt69TdyTbYlj5 > ai8oFGNI94Tv6rrzR/Rirfl/eODtdaaeNqyg/MBze6hYpS2w2oezOEmdYvlpJ7Xo > z0fN/vIus1SeeyIKWo4KYHZYRX6g2nTCUeGYJqvCIRVxS9UJsy45C/HlnIWTtedn > Dyp9O/0aSDhY+ErPQi64+HloZrY7p+KsCzPNc9HdzLbhnfM5IUn2TmO+qHngBSlY > zGNfpOsBmmllSuBftWDfiayh8C9sBUpGT9693iyQYXPIwjZkQSHAclDZa7naN3Oy > NKQaqVOsDmgDDP9xVOyr/Aue3jQk/8QHraM5DgO05L6lXHwdm+rjIdbb7CU2rFF7 > Gl14+kSFP7yufRQiS6Gt96eN4ePxSuD7XjiT/9GicztDXypNeX8= > =KRiO > -END PGP SIGNATURE- > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenImageIO GCC 8 build problem?
On Mon, Feb 12, 2018 at 6:29 AM, Jonathan Wakely wrote: > On 10/02/18 12:32 -0600, Richard Shaw wrote: >> >> On Sat, Feb 10, 2018 at 12:24 PM, Jakub Jelinek wrote: >> >>> On Sat, Feb 10, 2018 at 06:42:00AM -0600, Richard Shaw wrote: >>> > A scratch build works fine on Fedora 27... >>> >>> Likely http://gcc.gnu.org/PR83204 . >> >> >> >> Looks like it, rebuilding with C++11 let it complete. Would rebuilding >> with >> 11 cause an ABI change? > > > I already read the other replies suggesting waiting for the new GCC, > but for the record: no, it wouldn't. I found another strange, what seems to be a compiler bug in gcc-8, when building legion-18.02 on f28, which works fine on f27: https://github.com/StanfordLegion/legion/issues/350 Christoph > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libiscsi "missing" on s390x?
On Tue, Feb 6, 2018 at 5:00 PM, Richard W.M. Jones wrote: > On Tue, Feb 06, 2018 at 04:56:14PM -0700, Christoph Junghans wrote: >> On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans >> wrote: >> > On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones >> > wrote: >> >> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1542728 >> >> >> >> This build fails, but only on s390x: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023 >> >> >> >> The strange this is that libiscsi is not installed into the build root >> >> on s390x (but it is on other architectures) and that apparently causes >> >> the missing dependency which causes the build to fail. >> > It seems the s390x environment needs some work, e.g. >> > nothing provides rdma-core-devel(s390-64) needed by hwloc-devel >> > in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515 >> And I just found: >> nothing provides libibverbs.so.1()(64bit) needed by >> openmpi--2.1.1-7.fc28.s390x >> in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507 > > I don't understand. > > libiscsi was built on s390x, see: > https://koji.fedoraproject.org/koji/buildinfo?buildID=979268 > > Somehow it's not available for further builds, which appears to > be a Koji problem. Hmm, I tried to rebuild libiscsi in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761879 but got: DEBUG util.py:439: No matching package to install: 'libibverbs-devel' DEBUG util.py:439: No matching package to install: 'librdmacm-devel' Christoph > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-df lists disk usage of guests without needing to install any > software inside the virtual machine. Supports Linux and Windows. > http://people.redhat.com/~rjones/virt-df/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libiscsi "missing" on s390x?
On Tue, Feb 6, 2018 at 4:50 PM, Christoph Junghans wrote: > On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones wrote: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1542728 >> >> This build fails, but only on s390x: >> https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023 >> >> The strange this is that libiscsi is not installed into the build root >> on s390x (but it is on other architectures) and that apparently causes >> the missing dependency which causes the build to fail. > It seems the s390x environment needs some work, e.g. > nothing provides rdma-core-devel(s390-64) needed by hwloc-devel > in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515 And I just found: nothing provides libibverbs.so.1()(64bit) needed by openmpi--2.1.1-7.fc28.s390x in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761507 > > Christoph >> >> Rich. >> >> -- >> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones >> Read my programming and virtualization blog: http://rwmj.wordpress.com >> virt-top is 'top' for virtual machines. Tiny program with many >> powerful monitoring features, net stats, disk stats, logging, etc. >> http://people.redhat.com/~rjones/virt-top >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > -- > Christoph Junghans > Web: http://www.compphys.de -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libiscsi "missing" on s390x?
On Tue, Feb 6, 2018 at 3:53 PM, Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1542728 > > This build fails, but only on s390x: > https://koji.fedoraproject.org/koji/taskinfo?taskID=24760023 > > The strange this is that libiscsi is not installed into the build root > on s390x (but it is on other architectures) and that apparently causes > the missing dependency which causes the build to fail. It seems the s390x environment needs some work, e.g. nothing provides rdma-core-devel(s390-64) needed by hwloc-devel in https://koji.fedoraproject.org/koji/taskinfo?taskID=24761515 Christoph > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swap
Hi, could someone with MPI experience do these reviews: 1.) mpibash - Parallel scripting right from the Bourne-Again Shell <https://bugzilla.redhat.com/show_bug.cgi?id=1513582> 2.) libcircle - A library used to distribute workloads <https://bugzilla.redhat.com/show_bug.cgi?id=1513733> Except for the mpi parts both packages are standard autotools. I will take reviews in exchange. Thanks, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: git push fails for new packages
2017-08-13 11:16 GMT-06:00 Pierre-Yves Chibon : > On Fri, Aug 11, 2017 at 03:52:59PM -0500, Wart wrote: >> On 08/11/2017 09:57 AM, Pierre-Yves Chibon wrote: >> > On Fri, Aug 11, 2017 at 10:17:59AM -, Martin Gansser wrote: >> >> for f27: This is a known problem see: >> >> https://pagure.io/fedora-infrastructure/issue/6236 >> >> They working on it right now. >> >> >> >> f26 works for me now with: >> >> $ git checkout -b f26; git push --set-upstream origin f26; fedpkg build >> >> --nowait >> >> >> >> on f25 branch: I don't know what happens. >> >> >> >> $ git push --set-upstream origin f25 >> >> Total 0 (delta 0), reused 0 (delta 0) >> >> remote: FATAL: C refs/heads/f25 rpms/nuvola-app-mixcloud martinkg DENIED >> >> by refs/heads/f[0-9][0-9] >> >> remote: error: hook declined to update refs/heads/f25 >> >> To ssh://pkgs.fedoraproject.org/rpms/nuvola-app-mixcloud >> >> ! [remote rejected] f25 -> f25 (hook declined) >> >> error: failed to push some refs to >> >> 'ssh://marti...@pkgs.fedoraproject.org/rpms/nuvola-app-mixcloud' >> > >> > Basically, in order to prevent people from creating an epel8 branches we >> > only >> > apply the same restrictions as before (no fXX or elXX or epelXX or olpcXX >> > branches that are not whitelisted. >> > But the script that whitelist these branches but putting them into PDC >> > doesn't >> > ask pagure to refresh its config, so PDC is up to date but not pagure, >> > until >> > that project's config gets updated. >> > >> > We're working on allowing the script run by the admin to trigger a refresh >> > of >> > the config of a certain project so that right after creating the branch in >> > pdc >> > it can ask pagure to refresh the corresponding config. >> > In the mean time admins have a way to manually ask that a projet be >> > refreshed so >> > feel free to reach out if needed. >> >> I'm getting a similar error when trying to create the epel7 branch for >> tcl-tclnagios: > > Refresh in progress, sorry for the delay. Worked! Thank for working on the weekend. Christoph > > > Pierre > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review swap
Hi all, could somebody please review the package of this small library: <https://bugzilla.redhat.com/show_bug.cgi?id=1462443> ? I will take another review in exchange. Thanks, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swap
Hi all, As Besser82 is still missing in action, could somebody with MPI experience finish this review: <https://bugzilla.redhat.com/show_bug.cgi?id=1382755> I will take another review in exchange. Thanks, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
review swap
Hi all, I have a small parallelization library for review [1]. Any volunteers? Cheers, Christoph [1] https://bugzilla.redhat.com/show_bug.cgi?id=1382755 -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swaps
Hi, I have a package which is in need of a review, anyone interested in a swap? gasnet - A Portable High-Performance Communication Layer for GAS Languages * https://bugzilla.redhat.com/show_bug.cgi?id=1375744 Cheers, Christoph -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
