Re: mpich always injects lto flags

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: > > > > >

Re: Orphaning openbabel

On Thursday, 30 July 2020 at 19:18, Alexander Ploumistos wrote: [...] > Given the time of the year in the Northern Hemisphere, do you think > you could hold on to the package a little longer (e.g. until the > beginning of September), so that people who are interested might get > the chance to get

Re: Test machines for s390x?

On Thursday, 06 August 2020 at 18:45, Dan Horák wrote: [...] > Kevin, shall I try to get a guest from Marist we could use as the stable > test/devel machine? Like we do with the ppc64le machine from the > OpenPOWER hub. By the way, do you have a reliable support contact at the OpenPOWER hub? I've

Re: What do to about massive # of FTBFS bugs?

On Thu, 2020-08-06 at 17:54 +0200, Fabio Valentini wrote: > On Thu, Aug 6, 2020 at 4:51 PM Jeff Law wrote: > > On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote: > > > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini > > > wrote: > > > > I'd say it's pretty safe to submit things to rawhide

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

Re: Test machines for s390x?

On Thu, 2020-08-06 at 18:43 -0400, Robbie Harwood wrote: > Adam Williamson writes: > > > Neal Gompa wrote: > > > Adam Williamson wrote: > > > > Robbie Harwood wrote: > > > > > Elliott Sales de Andrade writes: > > > > > > > > > > > Now that ppc64 is gone, s390x is the only big-endian

Re: Orphaning openbabel

On Friday, 31 July 2020 at 11:04, Kevin Kofler wrote: [...] > We will likely also need an openbabel2 compatibility package then, because I > doubt that everything will build against OpenBabel 3 without non-trivial > porting. This is the porting guide:

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:

Re: What to do about FTBFS because auf cmake change?

Neal Gompa wrote: > Not only is that terrible advice, it's actually *wrong*. If you're > going to do bad things like that, at least make sure to test it. I did: https://src.fedoraproject.org/rpms/blogilo/c/ee482f1b33b50d79190951180d209e749b545dcd?branch=master

Re: Orphaning openbabel

Dominik 'Rathann' Mierzejewski wrote: > This is the porting guide: > https://open-babel.readthedocs.io/en/latest/UseTheLibrary/migration.html#migrating-to-3-0 > > It doesn't look too bad from a cursory look. To me, this list looks like a classic incompatible major version of a library that is

Re: Test machines for s390x?

Adam Williamson writes: > Neal Gompa wrote: >> Adam Williamson wrote: >>> Robbie Harwood wrote: Elliott Sales de Andrade writes: > Now that ppc64 is gone, s390x is the only big-endian architecture > left. Bugs around endianness are not usually difficult to fix, > _if_ I

Coin4 build failure

While trying to update the spec for the CMake change I ran into this for the first time: cd /builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/src/base && /usr/bin/g++ -I/builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/data -I/builddir/build/BUILD/coin-6enkw/include/Inventor/annex

Re: Respinning rawhide images every filesystem update?

- Original Message - > From: "Stephen John Smoogen" > To: "Development discussions related to Fedora" > > Sent: Thursday, August 6, 2020 10:55:51 AM > Subject: Re: Respinning rawhide images every filesystem update? > > On Thu, 6 Aug 2020 at 10:05, Alex Scheel wrote: > > > > -

Re: What do to about massive # of FTBFS bugs?

On Thu, Aug 6, 2020 at 4:51 PM Jeff Law wrote: > > On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote: > > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini wrote: > > > I'd say it's pretty safe to submit things to rawhide again. I haven't > > > seen any lingering buildroot issues for the past

Re: Test machines for s390x?

On Wed, Aug 5, 2020 at 9:27 PM Elliott Sales de Andrade wrote: > > Hi, > > Now that ppc64 is gone, s390x is the only big-endian architecture > left. Bugs around endianness are not usually difficult to fix, _if_ I > can debug it and see where exactly the problem is. However, this > requires a

Mock configs for the future-branched F33 (on 2020-08-11)

Hey all, we just wrapped a new update for mock-core-configs + distribution-gpg-keys that include configuration (configs + gpg keys) for F34: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f1032de02 https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ec390d120

CPE Feedback Survey

CPE need your help :) Over the last several months we've been trying to improve how we interact and share information with you all. From the blog posts, to mails and how we work on the tickets you send us. Here is a link to a very short survey we've

neuro-sig COPR group clean up

Hello, We've got quite a few unmaintained repos on COPR under the neuro-sig group. I intend to do a bit of housekeeping to remove projects there that aren't in use any more. Please take a look and let me know if you do not want me to delete a project:

Re: Test machines for s390x?

On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote: > Elliott Sales de Andrade writes: > > > Hi, > > > > Now that ppc64 is gone, s390x is the only big-endian architecture > > left. Bugs around endianness are not usually difficult to fix, _if_ I > > can debug it and see where exactly the

Re: Test machines for s390x?

On Thu, Aug 6, 2020 at 2:00 PM Adam Williamson wrote: > > On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote: > > Elliott Sales de Andrade writes: > > > > > Hi, > > > > > > Now that ppc64 is gone, s390x is the only big-endian architecture > > > left. Bugs around endianness are not usually

Re: neuro-sig COPR group clean up

On Thu, 6 Aug 2020 at 19:30, Ankur Sinha wrote: > Hello, > > We've got quite a few unmaintained repos on COPR under the neuro-sig > group. I intend to do a bit of housekeeping to remove projects there > that aren't in use any more. Please take a look and let me know if you > do not want me to

Re: Test machines for s390x?

Elliott Sales de Andrade writes: > Hi, > > Now that ppc64 is gone, s390x is the only big-endian architecture > left. Bugs around endianness are not usually difficult to fix, _if_ I > can debug it and see where exactly the problem is. However, this > requires a tedious guess-a-patch, try a

Re: Test machines for s390x?

On Thu, 2020-08-06 at 14:01 -0400, Neal Gompa wrote: > On Thu, Aug 6, 2020 at 2:00 PM Adam Williamson > wrote: > > > > On Thu, 2020-08-06 at 13:42 -0400, Robbie Harwood wrote: > > > Elliott Sales de Andrade writes: > > > > > > > Hi, > > > > > > > > Now that ppc64 is gone, s390x is the only

Re: Test machines for s390x?

On Wed, 5 Aug 2020 21:21:02 -0700 Kevin Fenzi wrote: > On Wed, Aug 05, 2020 at 11:26:34PM -0400, Elliott Sales de Andrade wrote: > > Hi, > > > > Now that ppc64 is gone, s390x is the only big-endian architecture > > left. Bugs around endianness are not usually difficult to fix, _if_ I > > can

Re: Lost ELF library auto-provides since mass rebuild

On Thu, Aug 06, 2020 at 05:04:20PM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > This is in relation to this bug > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1862745 > > > > The last but one build of libgphoto have auto-provides for the ELF > > libraries: > > > > libgphoto2 =

Re: Lost ELF library auto-provides since mass rebuild

* Daniel P. Berrangé: > This AC_LANG_PROGRAM call puts the code snippet inside a main() { ...} > so what configure was actually attempting to compile is: > > int > main () > { > >int f1() { } >int f2() { } >asm(".symver f1, f@VER1"); >

Re: Coin4 build failure

On 07.08.20 02:58, Richard Shaw wrote: > While trying to update the spec for the CMake change I ran into this > for the first time: > > cd /builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/src/base > && /usr/bin/g++ >  -I/builddir/build/BUILD/coin-6enkw/x86_64-redhat-linux-gnu/data >

Re: InsightToolkit LTO build failure

On 8/6/20 9:01 AM, Jeff Law wrote: On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote: InsightToolkit fails to build with LTO: /usr/bin/ld.gold: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status gmake[2]: ***

mame fails to build with LTO enabled

Hi list, mame has failed to build with lto enabled due to violation of C++ one definition rule apparently: https://koji.fedoraproject.org/koji/taskinfo?taskID=48829086 I don't really know how to fix it. I am going to disable lto for now as, according to upstream comment from 2017, mame is likely

Re: Test machines for s390x?

On Thu, Aug 06, 2020 at 06:45:22PM +0200, Dan Horák wrote: > On Wed, 5 Aug 2020 21:21:02 -0700 > Kevin Fenzi wrote: > > > On Wed, Aug 05, 2020 at 11:26:34PM -0400, Elliott Sales de Andrade wrote: > > > Hi, > > > > > > Now that ppc64 is gone, s390x is the only big-endian architecture > > > left.

Re: Coin4 build failure

You can bypass this by using CXXFLGS="-DXML_POOR_ENTROPY=1" export CXXFLAGS="-DXML_POOR_ENTROPY=1" in bash before compiling sorry... so long MUFTO ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Driverless scanning for WSD and ESCL supported scanners is coming

On 8/6/20 4:37 PM, Robert Marcano via devel wrote: > On 8/6/20 3:48 AM, Zdenek Dohnal wrote: >> On 8/5/20 2:30 PM, Jiří Eischmann wrote: >>> >>>   Will it be possible to use a Fedora machine as a server, so that I >>> can >>> have an old scanner connected to it via USB and then shared with other

Re: Driverless scanning for WSD and ESCL supported scanners is coming

On 8/5/20 2:30 PM, Jiří Eischmann wrote: > > Will it be possible to use a Fedora machine as a server, so that I can > have an old scanner connected to it via USB and then shared with other > devices on the local network via those protocols? > That would be neat. > > Jiri Hi Jirka, IIRC it is

Re: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote: > InsightToolkit fails to build with LTO: > > /usr/bin/ld.gold: fatal error: lto-wrapper failed > collect2: error: ld returned 1 exit status > gmake[2]: *** >

Re: InsightToolkit LTO build failure

On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote: > No need to file a bug right now. Once we're past the mass rebuild we'll > review > everything that's opted out and see what upstream actions need to be taken. > > Note that it appears this package is using the "gold" linker. That's

Re: Lost ELF library auto-provides since mass rebuild

* Daniel P. Berrangé: > This is in relation to this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1862745 > > The last but one build of libgphoto have auto-provides for the ELF > libraries: > > libgphoto2 = 2.5.24-2.fc33 > libgphoto2(x86-64) = 2.5.24-2.fc33 > libgphoto2.so.6()(64bit) >

Re: Lost ELF library auto-provides since mass rebuild

On Thu, 2020-08-06 at 17:04 +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > This is in relation to this bug > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1862745 > > > > The last but one build of libgphoto have auto-provides for the ELF > > libraries: > > > > libgphoto2 =

Re: [regression]Blender gets broken python detection with cmake

Hello, Any news on this? Regards, Lailah On Fri, 24 Jul 2020 at 08:04, Luya Tshimbalanga wrote: > Hello team, > > It looks like something broke inside cmake when attempting to detect > python: > > CMake Error at > /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:164 (message):

Re: InsightToolkit LTO build failure

On Thu, 2020-08-06 at 17:04 +0200, Jakub Jelinek wrote: > On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote: > > No need to file a bug right now. Once we're past the mass rebuild we'll > > review > > everything that's opted out and see what upstream actions need to be taken. > > > > Note

Re: InsightToolkit LTO build failure

On Thu, Aug 06, 2020 at 09:13:02AM -0600, Jeff Law wrote: > On Thu, 2020-08-06 at 17:04 +0200, Jakub Jelinek wrote: > > On Thu, Aug 06, 2020 at 09:01:16AM -0600, Jeff Law wrote: > > > No need to file a bug right now. Once we're past the mass rebuild we'll > > > review > > > everything that's

Re: InsightToolkit LTO build failure

On Thu, Aug 6, 2020 at 10:05 AM Orion Poplawski wrote: > > InsightToolkit fails to build with LTO: > > /usr/bin/ld.gold: fatal error: lto-wrapper failed > collect2: error: ld returned 1 exit status > gmake[2]: *** >

Re: vim has lost it's damn mind

On 2020-07-28 17:09, John Florian wrote: > > I also have seen some weirdness of late, but I'm still on F31.  I had > yaml files indented with sw=4 and my foldmethod=indent.  Now I have to > open the fold twice, once for the invisible fold that seems to be > implied as if sw=2 and one more to get

Re: What to do about FTBFS because auf cmake change?

what do I have to do if I want to keep the timestamp? %install %make_install INSTALL="install -p" %cmake_install INSTALL="install -p" did not work. Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Driverless scanning for WSD and ESCL supported scanners is coming

On 8/5/20 10:04 PM, Robert Marcano via devel wrote: > On 8/5/20 8:30 AM, Jiří Eischmann wrote: >> Zdenek Dohnal píše v St 05. 08. 2020 v 07:44 +0200: >>> Hi all, >>> >>> I would like to announce sane-airscan project [1] will be shipped in >>> the >>> official Fedora repositories from Fedora 32

Re: Test machines for s390x?

On 06. 08. 20 5:26, Elliott Sales de Andrade wrote: Hi, Now that ppc64 is gone, s390x is the only big-endian architecture left. Bugs around endianness are not usually difficult to fix, _if_ I can debug it and see where exactly the problem is. However, this requires a tedious guess-a-patch, try

Re: Test machines for s390x?

* Elliott Sales de Andrade: > Just like we have test machines for other less used architectures [1], > I am wondering if there is some way we can spin up a test machine for > s390x? Marist offers machine access for open-source development:

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: > > > You are not supposed to use %__cmake_builddir. > > It is not documented, and eventually will be removed. So don't rely on > it. If you want to change the build directory, set

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 12:35 PM Neal Gompa wrote: > > On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote: > > > > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: > > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: > > > > > You are not supposed to use %__cmake_builddir. > > > > > > It is

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa wrote: > On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote: > > > > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: > > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa > wrote: > > > > > You are not supposed to use %__cmake_builddir. > > > > > > It is

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote: > > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: > > > > You are not supposed to use %__cmake_builddir. > > > > It is not documented, and eventually will be removed. So don't rely on >

Re: What to do about FTBFS because auf cmake change?

On Thu, Aug 6, 2020 at 5:45 AM Kevin Kofler wrote: > > FYI, the easiest and most portable fix is to add: > -B. > (followed by a space or some other whitespace) before the . or .. (source > directory) argument. (That basically undoes the effects of this pointless > incompatible macro change.) >

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 6:43 AM Michal Schorm wrote: > > On Thu, Aug 6, 2020 at 12:35 PM Neal Gompa wrote: > > > > On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote: > > > > > > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: > > > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: > > > >

Re: What do to about massive # of FTBFS bugs?

On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini wrote: > > I'd say it's pretty safe to submit things to rawhide again. I haven't > seen any lingering buildroot issues for the past 2-3 days, except for > some longer wait/build times in koji due to batched ELN build > submissions (but those are

Re: What to do about FTBFS because auf cmake change?

On Wed, 2020-08-05 at 07:59 -0400, Neal Gompa wrote: > On Wed, Aug 5, 2020 at 7:53 AM Lukáš Hrázký wrote: > > Hi Neal, all, > > > > On Tue, 2020-08-04 at 07:42 -0400, Neal Gompa wrote: > > > ... > > > > What if I build for multiple platforms at the same time? E.g. in dnf we > > have: > > > >

Re: What to do about FTBFS because auf cmake change?

FYI, the easiest and most portable fix is to add: -B. (followed by a space or some other whitespace) before the . or .. (source directory) argument. (That basically undoes the effects of this pointless incompatible macro change.) Kevin Kofler

Re: /usr/bin/node: No such file or directory

not really right now, but I thought it would be easy. Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: /usr/bin/node: No such file or directory

On 06. 08. 20 14:57, Martin Gansser wrote: Hi, when I try to compile nodejs-indexof under rawhide I get the following error message [2] /usr/bin/node: No such file or directory [1] https://src.fedoraproject.org/rpms/nodejs-indexof/blob/master/f/nodejs-indexof.spec [2]

Re: Proposal to Add: Log In/Out Blocker Criteria

On Thu, Aug 6, 2020 at 5:47 AM Stephen J. Turnbull wrote: > I'm really uncomfortable about the amount of crossp-posting, so I'm > limiting this to devel@ (I receive it) and test@ (obvious to me why > relevant). > > Kamil Paral writes: > > Adam writes: > > > > Arguably the environment from

Re: Making `ls` colours follow terminal configuration

On Thu, Aug 6, 2020 at 3:25 PM Allan Day wrote: > Hi all, > > coreutils currently configures `ls` to use 256 colours rather than 16. > This is a downstream Fedora change which means that `ls` doesn't > follow the colour palette that's configured in the terminal. > It makes sense to synchronize

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

On Thu, Aug 6, 2020 at 7:12 AM Richard Shaw wrote: > > On Thu, Aug 6, 2020 at 5:35 AM Neal Gompa wrote: >> >> On Thu, Aug 6, 2020 at 6:20 AM Michal Schorm wrote: >> > >> > On Tue, Aug 4, 2020 at 5:54 PM Neal Gompa wrote: >> > > > On Tue, Aug 4, 2020 at 3:12 PM Neal Gompa wrote: >> > > > > You

Re: %{_vpath_builddir} needs to be in the Cmake packaging guidelines

I further discussed it with Neil. We came to a compromise. We will document this macro and its potential usage, as well as the warning why and when it shouldn't be used; and an information that it will be removed in some future Fedora release. I've made a PR to the Docs [1], we should discuss

http response to fedpkg build failure?

This is a new one for me: $ fedpkg build Could not execute build: The following error occurred while trying to get the active release branches in PDC: http://www.w3.org/TR/html4/strict.dtd;> Fedora Project Fedora

Making `ls` colours follow terminal configuration

Hi all, coreutils currently configures `ls` to use 256 colours rather than 16. This is a downstream Fedora change which means that `ls` doesn't follow the colour palette that's configured in the terminal. We are therefore planning on removing the downstream customisation, so that `ls` uses the

Summary/Minutes from yesterday's FESCo Meeting (2020-08-05)

= #fedora-meeting-2: FESCO (2020-08-05) = Meeting started by King_InuYasha at 14:03:44 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-08-05/fesco.2020-08-05-14.03.log.html .

Re: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

Dne 06. 08. 20 v 11:26 Aleksandra Fedorova napsal(a): > Hi, > > On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski wrote: >> So, I'm getting one of these messages every couple of hours and I'd >> really rather not. Who do I need to talk to about it? > You can talk about it with the ELN SIG [1] or

Re: Proposed Modular Policy for Fedora ELN

On Wed, Aug 05, 2020 at 10:50:59PM -0400, Stephen Gallagher wrote: > On Wed, Aug 5, 2020 at 6:17 PM James Cassell > wrote: > > > > On Wed, Aug 5, 2020, at 3:36 PM, Stephen Gallagher wrote: > > > * If a stream of a module has build-time-only components, all such > > > components *MUST* be marked

Lost ELF library auto-provides since mass rebuild

This is in relation to this bug https://bugzilla.redhat.com/show_bug.cgi?id=1862745 The last but one build of libgphoto have auto-provides for the ELF libraries: libgphoto2 = 2.5.24-2.fc33 libgphoto2(x86-64) = 2.5.24-2.fc33 libgphoto2.so.6()(64bit) libgphoto2_port.so.12()(64bit)

/usr/bin/node: No such file or directory

Hi, when I try to compile nodejs-indexof under rawhide I get the following error message [2] /usr/bin/node: No such file or directory [1] https://src.fedoraproject.org/rpms/nodejs-indexof/blob/master/f/nodejs-indexof.spec [2]

Re: /usr/bin/node: No such file or directory

On 06/08/2020 13:57, Martin Gansser wrote: when I try to compile nodejs-indexof under rawhide I get the following error message [2] /usr/bin/node: No such file or directory [1] https://src.fedoraproject.org/rpms/nodejs-indexof/blob/master/f/nodejs-indexof.spec [2]

Re: arm/neon LTO-related FTBS

Dominique Martinet wrote on Tue, Aug 04, 2020: > So I'd really need a way to have only that file compiled with the > optimisations, and other files without it -- Jeff or someone else, could > you please advise? I could still use help with that, please. To recap, waypipe: - compiles a single

Re: Respinning rawhide images every filesystem update?

I'm bumping this thread. This is still broken. - Original Message - > From: "Alex Scheel" > To: "Development discussions related to Fedora" > > Sent: Monday, August 3, 2020 2:36:40 PM > Subject: Respinning rawhide images every filesystem update? > > Hey list, > > > How do Fedora

Re: http response to fedpkg build failure?

On Thu, Aug 06, 2020 at 06:46:12AM -0500, Richard Shaw wrote: >This is a new one for me: >$ fedpkg build The key line is this one:         Sorry!  This service is currently unavailable. Looks like you've hit koji at a time of an outage. We had a vpn issue earlier today where

Re: What to do about FTBFS because auf cmake change?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2020-08-06 at 07:48 +, Martin Gansser wrote: > what do I have to do if I want to keep the timestamp? > > %install > %make_install INSTALL="install -p" > > > %cmake_install INSTALL="install -p" did not work. Just use %cmake_install.

Re: Can we use emulation of other architectures to run integration tests?

On 30. 07. 20 14:14, Miro Hrončok wrote: On 30. 07. 20 12:24, Aleksandra Fedorova wrote: As COPR has recently got support for s390 builds, the question is: if emulation is good enough for building packages, can we use it for testing? What are the limitations there? Is it worth it? I don't

Re: Test machines for s390x?

> I am wondering if there is some way we can spin up a test machine for s390x? I do not know the way for s390x. I wish that the test machine resources for s390x are supported by an organization not only for Fedora but also for the upstream open source projects for free, as the resources for Arm

Re: What do to about massive # of FTBFS bugs?

On Thu, Aug 6, 2020 at 11:50 AM Kevin Kofler wrote: > > Richard Shaw wrote: > > I'm confused if I should even fix these right now due to the various > > issues I've seen on the list. > > Just set them to ASSIGNED, you have 6 months to actually fix them. > > Kevin Kofler While that might

Re: mpich always injects lto flags

* Christoph Junghans: > 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

Re: bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

Hi, On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski wrote: > > So, I'm getting one of these messages every couple of hours and I'd > really rather not. Who do I need to talk to about it? You can talk about it with the ELN SIG [1] or Fedora CI SIG [2]. Mail thread on devel works, we recommend to

Re: What do to about massive # of FTBFS bugs?

Richard Shaw wrote: > I'm confused if I should even fix these right now due to the various > issues I've seen on the list. Just set them to ASSIGNED, you have 6 months to actually fix them. Kevin Kofler ___ devel mailing list --

Re: /usr/bin/node: No such file or directory

Many thanks, that solves it. Regards Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: Respinning rawhide images every filesystem update?

On Thu, 6 Aug 2020 at 09:36, Alex Scheel wrote: > > I'm bumping this thread. This is still broken. > Please open a ticket at https://pagure.io/fedora-infrastructure/new_issue and open new issue with an explanation of what is broken and where you are pulling from. If it is a fedora registry then

Segmentation fault (core dumped) doxygen docs/doxygen.cfg when compiling sayonara

Hi, when compiling sayonara on rawhide, the compilation fails with a problem with doxygen: [100%] Built target sayonara gmake[1]: Leaving directory '/home/martin/rpmbuild/BUILD/sayonara-player-1.6.0-beta6' /usr/bin/cmake -E cmake_progress_start

Re: Proposed Modular Policy for Fedora ELN

On 05. 08. 20 21:36, Stephen Gallagher wrote: FESCo has requested that I submit the module policy once more to the Fedora development list for discussion. Feedback is welcome. == Requirements for Default Streams * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN permits

InsightToolkit LTO build failure

InsightToolkit fails to build with LTO: /usr/bin/ld.gold: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status gmake[2]: *** [Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307: bin/ITKImageIntensityTestDriver] Error 1

Re: Respinning rawhide images every filesystem update?

- Original Message - > From: "Stephen John Smoogen" > To: "Development discussions related to Fedora" > , asch...@redhat.com > Sent: Thursday, August 6, 2020 9:55:17 AM > Subject: Re: Respinning rawhide images every filesystem update? > > On Thu, 6 Aug 2020 at 09:36, Alex Scheel wrote:

Re: Driverless scanning for WSD and ESCL supported scanners is coming

On 8/6/20 3:48 AM, Zdenek Dohnal wrote: On 8/5/20 2:30 PM, Jiří Eischmann wrote: Will it be possible to use a Fedora machine as a server, so that I can have an old scanner connected to it via USB and then shared with other devices on the local network via those protocols? That would be neat.

Re: What do to about massive # of FTBFS bugs?

On Thu, 2020-08-06 at 06:17 -0500, Richard Shaw wrote: > On Thu, Aug 6, 2020 at 5:08 AM Fabio Valentini wrote: > > I'd say it's pretty safe to submit things to rawhide again. I haven't > > seen any lingering buildroot issues for the past 2-3 days, except for > > some longer wait/build times in

Re: Respinning rawhide images every filesystem update?

On Thu, 6 Aug 2020 at 10:05, Alex Scheel wrote: > > - Original Message - > > From: "Stephen John Smoogen" > > To: "Development discussions related to Fedora" > > , asch...@redhat.com > > Sent: Thursday, August 6, 2020 9:55:17 AM > > Subject: Re: Respinning rawhide images every

Proposing a new Perl Module Versioning Scheme

Hi, I'm working at SUSE, and for about a year I have been in charge of updating the CPAN modules in SUSE Open Build Service: https://build.opensuse.org/project/show/devel:languages:perl This is half automated. The spec file is generated with the cpanspec script, and we manually look over the

[Bug 1859415] perl-Log-Log4perl-1.50 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1859415 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc

[Bug 1842274] perl-Excel-Writer-XLSX-1.07 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1842274 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Excel-Writer-XLSX-1.06

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2020-08-07 from 21:00:00 to 22:00:00 UTC At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic

[Bug 1866972] New: perl-Test2-Suite-0.000132 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1866972 Bug ID: 1866972 Summary: perl-Test2-Suite-0.000132 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test2-Suite Keywords: FutureFeature, Triaged

[Bug 1842274] perl-Excel-Writer-XLSX-1.07 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1842274 --- Comment #10 from Upstream Release Monitoring --- Created attachment 1710703 --> https://bugzilla.redhat.com/attachment.cgi?id=1710703=edit [patch] Update to 1.07 (#1842274) -- You are receiving this mail because: You are on the CC

Re: Proposing a new Perl Module Versioning Scheme

I wrote a blog post thoroughly explaining Perl module versions and agree with the assessment and suggested method presented (though I have no comment on the remedy). http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html -Dan On Thu, Aug 6, 2020, 1:09 PM Tina Müller

distro perl's ldflags='... -Wl,-z,relro ...' causing module build errors. bug in distro perl flags? or module code?

i'm attempting to build a MaxMind GeopIP2 DB reader perl module MaxMind::DB::Reader::XS ( https://metacpan.org/pod/MaxMind::DB::Reader::XS ) on Fedora 32. the build fails on F32 with Errors: "/usr/bin/ld: unrecognized option '-Wl,-z,relro'" & "Unsupported

[Bug 1802607] perl-Net-DNS-1.26 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1802607 --- Comment #12 from Upstream Release Monitoring --- An unexpected error occurred while creating the scratch build and has been automatically reported. Sorry! -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 1802607] perl-Net-DNS-1.26 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1802607 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Net-DNS-1.25 is|perl-Net-DNS-1.26 is

[389-devel] please review: PR 51234 - ds-replcheck crashes in offline mode

https://pagure.io/389-ds-base/pull-request/51234 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

[389-devel] 389 DS nightly 2020-08-07 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/07/report-389-ds-base-1.4.4.4-20200806git066a7b4.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

  1   2   >