Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 8:28 PM, Steven A. Falco wrote:

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install


It does look like it is that easy.  I should have a build in another hour or 
so.  Then I'll load it into a VM and test.  If that works out, I'll change the 
packaging scripts.


Ok, I've updated the packaging script and merged that into gitlab.  The next 
nightly should build correctly for rawhide.

I'll tackle the downstream script tomorrow.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install


It does look like it is that easy.  I should have a build in another hour or 
so.  Then I'll load it into a VM and test.  If that works out, I'll change the 
packaging scripts.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Ian McInerney
Good luck.

I've been putting off updating the Audacity spec file that I am maintainer
on because of the cmake macro changes. But in my case I have to rewrite the
entire spec to use cmake since they removed their autotools-based build
system and instead introduced a broken cmake build system now - and they
did this in a patch release... that is not going to be fun to switch to.

-Ian

On Mon, Jul 20, 2020 at 11:08 PM Steven A. Falco 
wrote:

> On 7/20/20 6:01 PM, Ian McInerney wrote:
> > You should be able to switch the macros:
> > %cmake -> %cmake
> > %make_build -> %cmake_build
> > %make_install -> %cmake_install
> >
> > Then the builds and install will automatically use the proper out of
> tree directory. See the change proposal page for more details:
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration
> .
>
> Thanks, Ian.  I'll give that a try later.  But if I have to iterate a few
> times to get everything right, it could take some time.
>
> Steve
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Ian McInerney
There should be no differences with where things get installed to - and if
there are then our "install" targets are incorrect and should be fixed
upstream. The changes to the cmake macros are simply for the build system.

-Ian

On Mon, Jul 20, 2020 at 11:04 PM Steven A. Falco 
wrote:

> On 7/20/20 5:37 PM, Seth Hillbrand wrote:
> > Hi Steve-
> >
> > This looks like a build setup issue, not in our CMake code.  We can
> build out of tree (in fact, we really prefer it) right now.  From the log,
> the broken command is
> > /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64
> -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share
> -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
> >
> > You can modify this in your .spec.template file.
>
> I understand that, and I use out-of-tree builds for most of my local KiCAD
> builds.  But that is not how the nightlies work.  They are built on the
> Copr website, and they use the normal RPM build mechanism.
>
> You are correct that there is nothing wrong with our CMake code, and we
> can fix our build setup.  But it is more than just compiling the source.
> There are lots of other components that get built, and the location of the
> files that get rolled into the package will also change a bit.  So the
> changes will take some time to sort out, especially given how long it takes
> to test a build.  Hence the proposal of the workaround.
>
> Steve
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install

Then the builds and install will automatically use the proper out of tree 
directory. See the change proposal page for more details: 
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration.


Thanks, Ian.  I'll give that a try later.  But if I have to iterate a few times 
to get everything right, it could take some time.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 5:37 PM, Seth Hillbrand wrote:

Hi Steve-

This looks like a build setup issue, not in our CMake code.  We can build out 
of tree (in fact, we really prefer it) right now.  From the log, the broken 
command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
-DKICAD_SCRIPTING_PYTHON3=ON -DKICAD_SCRIPTING_WXPYTHON=ON 
-DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON -DKICAD_SCRIPTING_ACTION_MENU=ON 
-DKICAD_USE_OCC=ON -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF 
-DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON -DKICAD_VERSION_EXTRA=r19086-6d8fb94d 
-DCMAKE_BUILD_TYPE=Debug .

You can modify this in your .spec.template file.


I understand that, and I use out-of-tree builds for most of my local KiCAD 
builds.  But that is not how the nightlies work.  They are built on the Copr 
website, and they use the normal RPM build mechanism.

You are correct that there is nothing wrong with our CMake code, and we can fix 
our build setup.  But it is more than just compiling the source.  There are 
lots of other components that get built, and the location of the files that get 
rolled into the package will also change a bit.  So the changes will take some 
time to sort out, especially given how long it takes to test a build.  Hence 
the proposal of the workaround.

Steve
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Ian McInerney
You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install

Then the builds and install will automatically use the proper out of tree
directory. See the change proposal page for more details:
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration
.

-Ian

On Mon, Jul 20, 2020 at 10:29 PM Steven A. Falco 
wrote:

> Fedora recently made a change to their cmake macros, to force packages to
> build "out of tree".  The developers responsible for this change plan to go
> through and fix up the thousand or so packages that may break as a result,
> so they should eventually fix the official downstream KiCAD package.
>
> However, they will not be able to fix up third-party packages, one of
> which is our nightly builds.
>
> The attached email shows that KiCAD does indeed fail to build for Fedora
> rawhide now.  The right thing to do is to modify the kicad.spec.template
> file to accommodate the new cmake macros, but as a temporary workaround, we
> can add a line to force the old behavior:
>
> %global __cmake_in_source_build 1
>
> I've tried that, and it does let KiCAD build as before.
>
> I don't know exactly how the developers plan to fix up the broken
> packages, so we can either add the workaround, wait to see what they do,
> then change the nightlies to match (and remove the workaround), OR we can
> make our own changes, which may result in the spec files diverging.
>
> If the lead KiCAD devs wish, I can add the workaround - I can do that
> quickly.  Attempting to sort out a proper fix would naturally take longer.
>
> Steve
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

On 7/20/20 5:34 PM, Nick Østergaard wrote:

What does this mean if I want to test this locally?

Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...


To test locally, I use our kicad-fedora-builder/builder.sh script with the -m 
(mock) option:

./builder.sh -m fedora-rawhide-x86_64

For that to work, you have to have set up for mock, by installing it and adding 
your uid to the mock group.

Steve



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Nick Østergaard
Re: that.. https://www.spinics.net/lists/fedora-devel/msg274669.html

Quote from an Igor:

I'm confused by the proposal, it is named "CMake to do out-of-source builds"

but the macros seems to do the opposite?

On Rawhide (local repo):

%__cmake \
-S "%{_vpath_srcdir}" \
-B "%{__cmake_builddir}" \

__cmake_builddir
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
__cmake_in_source_build1

Looks like __cmake_builddir is defined as "." so the build will happen
in source?


On Mon, 20 Jul 2020 at 23:45, Nick Østergaard  wrote:
>
> I am not sure I misunderstand the terminology here, but "cmake -S . -B
> foo -Dnickersej" looks "in tree" to me.
>
> On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand  wrote:
> >
> > Hi Steve-
> >
> > This looks like a build setup issue, not in our CMake code.  We can
> > build out of tree (in fact, we really prefer it) right now.  From the
> > log, the broken command is
> > /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> > -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> > -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> > -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> > -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> > -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> > -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> > -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> > -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
> >
> > You can modify this in your .spec.template file.
> >
> > Best-
> > Seth
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > On 2020-07-20 14:28, Steven A. Falco wrote:
> > > Fedora recently made a change to their cmake macros, to force packages
> > > to build "out of tree".  The developers responsible for this change
> > > plan to go through and fix up the thousand or so packages that may
> > > break as a result, so they should eventually fix the official
> > > downstream KiCAD package.
> > >
> > > However, they will not be able to fix up third-party packages, one of
> > > which is our nightly builds.
> > >
> > > The attached email shows that KiCAD does indeed fail to build for
> > > Fedora rawhide now.  The right thing to do is to modify the
> > > kicad.spec.template file to accommodate the new cmake macros, but as a
> > > temporary workaround, we can add a line to force the old behavior:
> > >
> > > %global __cmake_in_source_build 1
> > >
> > > I've tried that, and it does let KiCAD build as before.
> > >
> > > I don't know exactly how the developers plan to fix up the broken
> > > packages, so we can either add the workaround, wait to see what they
> > > do, then change the nightlies to match (and remove the workaround), OR
> > > we can make our own changes, which may result in the spec files
> > > diverging.
> > >
> > > If the lead KiCAD devs wish, I can add the workaround - I can do that
> > > quickly.  Attempting to sort out a proper fix would naturally take
> > > longer.
> > >
> > >   Steve
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Nick Østergaard
I am not sure I misunderstand the terminology here, but "cmake -S . -B
foo -Dnickersej" looks "in tree" to me.

On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand  wrote:
>
> Hi Steve-
>
> This looks like a build setup issue, not in our CMake code.  We can
> build out of tree (in fact, we really prefer it) right now.  From the
> log, the broken command is
> /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
>
> You can modify this in your .spec.template file.
>
> Best-
> Seth
>
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
>
> On 2020-07-20 14:28, Steven A. Falco wrote:
> > Fedora recently made a change to their cmake macros, to force packages
> > to build "out of tree".  The developers responsible for this change
> > plan to go through and fix up the thousand or so packages that may
> > break as a result, so they should eventually fix the official
> > downstream KiCAD package.
> >
> > However, they will not be able to fix up third-party packages, one of
> > which is our nightly builds.
> >
> > The attached email shows that KiCAD does indeed fail to build for
> > Fedora rawhide now.  The right thing to do is to modify the
> > kicad.spec.template file to accommodate the new cmake macros, but as a
> > temporary workaround, we can add a line to force the old behavior:
> >
> > %global __cmake_in_source_build 1
> >
> > I've tried that, and it does let KiCAD build as before.
> >
> > I don't know exactly how the developers plan to fix up the broken
> > packages, so we can either add the workaround, wait to see what they
> > do, then change the nightlies to match (and remove the workaround), OR
> > we can make our own changes, which may result in the spec files
> > diverging.
> >
> > If the lead KiCAD devs wish, I can add the workaround - I can do that
> > quickly.  Attempting to sort out a proper fix would naturally take
> > longer.
> >
> >   Steve
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Seth Hillbrand

Hi Steve-

This looks like a build setup issue, not in our CMake code.  We can 
build out of tree (in fact, we really prefer it) right now.  From the 
log, the broken command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr 
-DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON 
-DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON 
-DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON 
-DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF 
-DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON 
-DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .


You can modify this in your .spec.template file.

Best-
Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

On 2020-07-20 14:28, Steven A. Falco wrote:

Fedora recently made a change to their cmake macros, to force packages
to build "out of tree".  The developers responsible for this change
plan to go through and fix up the thousand or so packages that may
break as a result, so they should eventually fix the official
downstream KiCAD package.

However, they will not be able to fix up third-party packages, one of
which is our nightly builds.

The attached email shows that KiCAD does indeed fail to build for
Fedora rawhide now.  The right thing to do is to modify the
kicad.spec.template file to accommodate the new cmake macros, but as a
temporary workaround, we can add a line to force the old behavior:

%global __cmake_in_source_build 1

I've tried that, and it does let KiCAD build as before.

I don't know exactly how the developers plan to fix up the broken
packages, so we can either add the workaround, wait to see what they
do, then change the nightlies to match (and remove the workaround), OR
we can make our own changes, which may result in the spec files
diverging.

If the lead KiCAD devs wish, I can add the workaround - I can do that
quickly.  Attempting to sort out a proper fix would naturally take
longer.

Steve



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Nick Østergaard
What does this mean if I want to test this locally?

Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...


On Mon, 20 Jul 2020 at 23:28, Steven A. Falco  wrote:
>
> Fedora recently made a change to their cmake macros, to force packages to 
> build "out of tree".  The developers responsible for this change plan to go 
> through and fix up the thousand or so packages that may break as a result, so 
> they should eventually fix the official downstream KiCAD package.
>
> However, they will not be able to fix up third-party packages, one of which 
> is our nightly builds.
>
> The attached email shows that KiCAD does indeed fail to build for Fedora 
> rawhide now.  The right thing to do is to modify the kicad.spec.template file 
> to accommodate the new cmake macros, but as a temporary workaround, we can 
> add a line to force the old behavior:
>
> %global __cmake_in_source_build 1
>
> I've tried that, and it does let KiCAD build as before.
>
> I don't know exactly how the developers plan to fix up the broken packages, 
> so we can either add the workaround, wait to see what they do, then change 
> the nightlies to match (and remove the workaround), OR we can make our own 
> changes, which may result in the spec files diverging.
>
> If the lead KiCAD devs wish, I can add the workaround - I can do that 
> quickly.  Attempting to sort out a proper fix would naturally take longer.
>
> Steve
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


[Kicad-developers] Build failure in Fedora Rawhide

2020-07-20 Thread Steven A. Falco

Fedora recently made a change to their cmake macros, to force packages to build "out 
of tree".  The developers responsible for this change plan to go through and fix up 
the thousand or so packages that may break as a result, so they should eventually fix the 
official downstream KiCAD package.

However, they will not be able to fix up third-party packages, one of which is 
our nightly builds.

The attached email shows that KiCAD does indeed fail to build for Fedora 
rawhide now.  The right thing to do is to modify the kicad.spec.template file 
to accommodate the new cmake macros, but as a temporary workaround, we can add 
a line to force the old behavior:

%global __cmake_in_source_build 1

I've tried that, and it does let KiCAD build as before.

I don't know exactly how the developers plan to fix up the broken packages, so 
we can either add the workaround, wait to see what they do, then change the 
nightlies to match (and remove the workaround), OR we can make our own changes, 
which may result in the spec files diverging.

If the lead KiCAD devs wish, I can add the workaround - I can do that quickly.  
Attempting to sort out a proper fix would naturally take longer.

Steve


--- Begin Message ---
Notification time stamped 2020-07-20 17:31:25 UTC

Package:  kicad-100:r19086-6d8fb94d.fc33
COPR: @kicad/kicad
Built by: nickoe
Status:   failed
ID:   01565774

Logs:
  Build: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/build.log.gz
  Root:  
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/root.log.gz
  Copr:  
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/build-01565774.log
  Mockchain: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/mockchain.log.gz
Results: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/
Repodata:
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/repodata/

https://copr.fedoraproject.org/coprs/g/kicad/kicad/build/1565774/

--
You received this message due to your preference settings at 
https://apps.fedoraproject.org/notifications/stevenfalco.id.fedoraproject.org/email/60697--- End Message ---
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp