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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

Re: [Kicad-developers] DRC - detecting acute angles

[Joshua Redstone]

Someone commented that teardrops are important for flexible PCBs. Maybe
sharp angles also affect flex pcbs?
And may be useful for people etching at home?
As a hobbyist sending boards to be made at the cheapest fab I can find,
it'd be nice not to have sharp angles just so
I don't have to think about the issue, but my expertise re angles and
corners is low.
That last article you link to mentions "you can effectively ignore this
problem unless you are working with a typical Chinese manufacturer".
Josh

On Mon, Jul 20, 2020 at 11:38 AM Andrew Zonenberg <
azonenb...@drawersteak.com> wrote:

> Hi,
>
> I guess the other question is, do we even *want* to be doing this check?
> It's not the 1980s anymore.
>
> At the very least it should be able to be disabled for those of us who
> aren't working with a PCB shop stuck in last century.
>
>
> https://resources.ema-eda.com/blog/are-acid-traps-still-a-problem-for-pcbs-in-2019
>
>
> https://electronics.stackexchange.com/questions/115653/are-acid-traps-real-2014
>
> https://resources.altium.com/p/7-common-misconceptions-about-pcb-design
>
>
> https://www.nwengineeringllc.com/article/right-angle-pcb-traces-its-time-to-kill-the-myths.php
>
> Andrew
>
> On 7/20/20 8:29 AM, Tomasz Wlostowski wrote:
> > On 18/07/2020 23:47, Joshua Redstone wrote:
> >> Thanks, that link's a helpful starting point.
> >> Josh
> >
> > Hi Joshua,
> >
> > If you could figure out the algorithm for robust acute angle detection
> > (your input is a set of BOARD_ITEMs), I can integrate it with the new
> > KiCad DRC engine.
> >
> > Tom
> >
> >
> >>
> >> On Fri, Jul 17, 2020 at 7:40 PM Seth Hillbrand  >> > wrote:
> >>
> >> Please have a look over the open issues on GitLab.  Until the new
> >> DRC code has been merged into master, it's not a good candidate for
> >> a new developer.
> >>
> >> Here's a link with open issues for the feature-freeze that have not
> >> yet been assigned.  Please do note that any feature-development work
> >> should have a documented implementation plan that the lead
> >> developers sign off on before you begin coding.  This can help to
> >> avoid problems where you do a lot of work that doesn't get accepted
> >> because it doesn't fit in the larger plan.
> >>
> >>
> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0%20Feature%20Freeze_id=None
> >>
> >> I would also strongly encourage you (as we do for all developers
> >> starting to work on KiCad) to look at fixing small issues first.
> >> They are not nearly as appealing as a feature implementation but
> >> they are more manageable and will help you learn the general layout
> >> and workings of the system.
> >>
> >> Best-
> >> Seth
> >>
> >> KiCad Services Corporation KiCad Services Corporation Logo
> >> Seth Hillbrand
> >> *Lead Developer*
> >> +1-530-302-5483‬ 
> >> Davis, CA
> >> www.kipro-pcb.com 
> i...@kipro-pcb.com
> >> 
> >> https://twitter.com/KiProEDA 
> >> https://www.linkedin.com/company/kicad
> >> 
> >>
> >>
> >> On 2020-07-17 16:13, Joshua Redstone wrote:
> >>
> >>> Hi all,
> >>> I was wondering what's the state of the pcbnew DRC work and what
> >>> are the todos left to be done?
> >>> I have a bit of time while waiting for a board to be assembled. I
> >>> was thinking of exploring DRC changes to either detect acute
> >>> angles in copper or detect silkscreen text that intersects vias /
> >>> pads, but I'm also curious to know what else needs doing.
> >>> Cheers,
> >>> Josh
> >>>
> >>>
> >>> ___
> >>> 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
> >>
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : 

Re: [Kicad-developers] DRC - detecting acute angles

[Andrew Zonenberg]

Hi,

I guess the other question is, do we even *want* to be doing this check?
It's not the 1980s anymore.

At the very least it should be able to be disabled for those of us who
aren't working with a PCB shop stuck in last century.

https://resources.ema-eda.com/blog/are-acid-traps-still-a-problem-for-pcbs-in-2019

https://electronics.stackexchange.com/questions/115653/are-acid-traps-real-2014

https://resources.altium.com/p/7-common-misconceptions-about-pcb-design

https://www.nwengineeringllc.com/article/right-angle-pcb-traces-its-time-to-kill-the-myths.php

Andrew

On 7/20/20 8:29 AM, Tomasz Wlostowski wrote:
> On 18/07/2020 23:47, Joshua Redstone wrote:
>> Thanks, that link's a helpful starting point.
>> Josh
> 
> Hi Joshua,
> 
> If you could figure out the algorithm for robust acute angle detection
> (your input is a set of BOARD_ITEMs), I can integrate it with the new
> KiCad DRC engine.
> 
> Tom
> 
> 
>>
>> On Fri, Jul 17, 2020 at 7:40 PM Seth Hillbrand > > wrote:
>>
>> Please have a look over the open issues on GitLab.  Until the new
>> DRC code has been merged into master, it's not a good candidate for
>> a new developer.
>>
>> Here's a link with open issues for the feature-freeze that have not
>> yet been assigned.  Please do note that any feature-development work
>> should have a documented implementation plan that the lead
>> developers sign off on before you begin coding.  This can help to
>> avoid problems where you do a lot of work that doesn't get accepted
>> because it doesn't fit in the larger plan.
>>
>> 
>> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0%20Feature%20Freeze_id=None
>>
>> I would also strongly encourage you (as we do for all developers
>> starting to work on KiCad) to look at fixing small issues first. 
>> They are not nearly as appealing as a feature implementation but
>> they are more manageable and will help you learn the general layout
>> and workings of the system.
>>
>> Best-
>> Seth
>>
>> KiCad Services Corporation KiCad Services Corporation Logo
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ 
>> Davis, CA
>> www.kipro-pcb.com     i...@kipro-pcb.com
>> 
>> https://twitter.com/KiProEDA 
>> https://www.linkedin.com/company/kicad
>> 
>>
>>
>> On 2020-07-17 16:13, Joshua Redstone wrote:
>>
>>> Hi all,
>>> I was wondering what's the state of the pcbnew DRC work and what
>>> are the todos left to be done?
>>> I have a bit of time while waiting for a board to be assembled. I
>>> was thinking of exploring DRC changes to either detect acute
>>> angles in copper or detect silkscreen text that intersects vias /
>>> pads, but I'm also curious to know what else needs doing.
>>> Cheers,
>>> Josh
>>>  
>>>
>>> ___
>>> 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
>>
> 
> 
> ___
> 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] DRC - detecting acute angles

[Joshua Redstone]

Hi Tom,
Thanks for the suggestion - that sounds like a fun problem. But I just
started working on named groups (after an email exchange with Seth).
Cheers,
Josh


On Mon, Jul 20, 2020 at 11:29 AM Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:

> On 18/07/2020 23:47, Joshua Redstone wrote:
> > Thanks, that link's a helpful starting point.
> > Josh
>
> Hi Joshua,
>
> If you could figure out the algorithm for robust acute angle detection
> (your input is a set of BOARD_ITEMs), I can integrate it with the new
> KiCad DRC engine.
>
> Tom
>
>
> >
> > On Fri, Jul 17, 2020 at 7:40 PM Seth Hillbrand  > > wrote:
> >
> > Please have a look over the open issues on GitLab.  Until the new
> > DRC code has been merged into master, it's not a good candidate for
> > a new developer.
> >
> > Here's a link with open issues for the feature-freeze that have not
> > yet been assigned.  Please do note that any feature-development work
> > should have a documented implementation plan that the lead
> > developers sign off on before you begin coding.  This can help to
> > avoid problems where you do a lot of work that doesn't get accepted
> > because it doesn't fit in the larger plan.
> >
> >
> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0%20Feature%20Freeze_id=None
> >
> > I would also strongly encourage you (as we do for all developers
> > starting to work on KiCad) to look at fixing small issues first.
> > They are not nearly as appealing as a feature implementation but
> > they are more manageable and will help you learn the general layout
> > and workings of the system.
> >
> > Best-
> > Seth
> >
> > KiCad Services Corporation KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬ 
> > Davis, CA
> > www.kipro-pcb.com i...@kipro-pcb.com
> > 
> > https://twitter.com/KiProEDA 
> > https://www.linkedin.com/company/kicad
> > 
> >
> >
> > On 2020-07-17 16:13, Joshua Redstone wrote:
> >
> >> Hi all,
> >> I was wondering what's the state of the pcbnew DRC work and what
> >> are the todos left to be done?
> >> I have a bit of time while waiting for a board to be assembled. I
> >> was thinking of exploring DRC changes to either detect acute
> >> angles in copper or detect silkscreen text that intersects vias /
> >> pads, but I'm also curious to know what else needs doing.
> >> Cheers,
> >> Josh
> >>
> >>
> >> ___
> >> 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
> >
>
>
___
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] DRC - detecting acute angles

[Tomasz Wlostowski]

On 18/07/2020 23:47, Joshua Redstone wrote:
> Thanks, that link's a helpful starting point.
> Josh

Hi Joshua,

If you could figure out the algorithm for robust acute angle detection
(your input is a set of BOARD_ITEMs), I can integrate it with the new
KiCad DRC engine.

Tom


> 
> On Fri, Jul 17, 2020 at 7:40 PM Seth Hillbrand  > wrote:
> 
> Please have a look over the open issues on GitLab.  Until the new
> DRC code has been merged into master, it's not a good candidate for
> a new developer.
> 
> Here's a link with open issues for the feature-freeze that have not
> yet been assigned.  Please do note that any feature-development work
> should have a documented implementation plan that the lead
> developers sign off on before you begin coding.  This can help to
> avoid problems where you do a lot of work that doesn't get accepted
> because it doesn't fit in the larger plan.
> 
> 
> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0%20Feature%20Freeze_id=None
> 
> I would also strongly encourage you (as we do for all developers
> starting to work on KiCad) to look at fixing small issues first. 
> They are not nearly as appealing as a feature implementation but
> they are more manageable and will help you learn the general layout
> and workings of the system.
> 
> Best-
> Seth
> 
> KiCad Services Corporation KiCad Services Corporation Logo
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com     i...@kipro-pcb.com
> 
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> 
> 
> On 2020-07-17 16:13, Joshua Redstone wrote:
> 
>> Hi all,
>> I was wondering what's the state of the pcbnew DRC work and what
>> are the todos left to be done?
>> I have a bit of time while waiting for a board to be assembled. I
>> was thinking of exploring DRC changes to either detect acute
>> angles in copper or detect silkscreen text that intersects vias /
>> pads, but I'm also curious to know what else needs doing.
>> Cheers,
>> Josh
>>  
>>
>> ___
>> 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
> 


___
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] DRC rules panel

[Ben Ellis]

Neat, that'll be super useful

On Mon, Jul 20, 2020, 9:56 AM Jeff Young  wrote:

> To do syntax highlighting and code completion.
>
> > On 20 Jul 2020, at 14:41, Ben Ellis  wrote:
> >
> > Why are the DRC rules parsed w/ s-exprs as they're being typed instead
> of after? I just fixed a bug where typing ) without ( crashed the entire
> program
> > ___
> > 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] DRC rules panel

[Jeff Young]

To do syntax highlighting and code completion.

> On 20 Jul 2020, at 14:41, Ben Ellis  wrote:
> 
> Why are the DRC rules parsed w/ s-exprs as they're being typed instead of 
> after? I just fixed a bug where typing ) without ( crashed the entire program
> ___
> 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] DRC rules panel

[Ben Ellis]

Why are the DRC rules parsed w/ s-exprs as they're being typed instead of
after? I just fixed a bug where typing ) without ( crashed the entire
program
___
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