Re: [Kicad-developers] Two bugs reported on the Fedora bugzilla

[Ian McInerney]

The second bug appears to be an assertion due to an invalid vector access.

The stack trace is below.

Truncated backtrace:
Thread no. 1 (10 frames)
 #2 std::__replacement_assert at
/usr/include/c++/11/x86_64-redhat-linux/bits/c++config.h:2660
 #3 std::vector, std::allocator > >::operator[]
at /usr/include/c++/11/bits/stl_vector.h:1043
 #5 ZONE::HatchBorder at
/usr/src/debug/kicad-6.0.4-1.fc34.x86_64/pcbnew/zone.cpp:1031
 #6 ZONE::SetBorderDisplayStyle at
/usr/src/debug/kicad-6.0.4-1.fc34.x86_64/pcbnew/zone.cpp:882
 #7 PCB_PARSER::parseZONE at
/usr/src/debug/kicad-6.0.4-1.fc34.x86_64/pcbnew/plugins/kicad/pcb_parser.cpp:5437
 #8 PCB_PARSER::parseFOOTPRINT_unchecked at
/usr/include/c++/11/bits/unique_ptr.h:173
 #9 PCB_PARSER::parseFOOTPRINT at
/usr/src/debug/kicad-6.0.4-1.fc34.x86_64/pcbnew/plugins/kicad/pcb_parser.cpp:3211
 #10 PCB_PARSER::Parse at /usr/include/c++/11/bits/unique_ptr.h:185
 #11 FP_CACHE::Load at
/usr/src/debug/kicad-6.0.4-1.fc34.x86_64/pcbnew/plugins/kicad/pcb_plugin.cpp:274
 #12 PCB_PLUGIN::FootprintEnumerate at
/usr/src/debug/kicad-6.0.4-1.fc34.x86_64/pcbnew/plugins/kicad/pcb_plugin.cpp:2390


This is trying to read the
`/usr/share/kicad/footprints//RF_Module.pretty/MOD-nRF8001.kicad_mod` file
provided in the standard footprint library (and apparently there is an
extra slash entering the path somewhere, but that is extraneous to this).
What seems to be happening is that during the parsing, it is finding a
hatched zone, but the hatch border has an empty pointbuffer, which then
causes the stdlib assert to fire when it is accessed at any index.

-Ian

On Fri, May 6, 2022 at 7:00 PM Seth Hillbrand  wrote:

> Hi Steven-
>
> The second bug is locked down.  We can't see it without proper access
> credentials.
>
> Seth
>
> On Fri, May 6, 2022 at 6:45 AM Steven A. Falco 
> wrote:
>
>> There are two SIGABRT bugs reported on Fedora:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2079984
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2082394
>>
>> The first bug was closed because it was not able to be reproduced.  The
>> second one has apparently happened to the reporter several times, but again
>> I don't know if it is reproducible on demand.
>>
>> Do either of these ring a bell with anyone?
>>
>> 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
>>
>
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> ___
> 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] CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947

[Ian McInerney]

All 4 CVEs were fixed in the 6.0.2 release and the release announcement was
updated last night to say this (to coincide with the public disclosure that
happened today). There will be another email on the developer list later
today with more details.

-Ian

On Wed, Feb 16, 2022 at 2:18 PM Steven A. Falco 
wrote:

> I've just received a large number of bugs against KiCad, supposedly due to
> CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947.
>
> I don't have time to look into them, but I wanted to make them known.
> There are apparently also bugs for this on the gentoo site - here is one:
> https://bugs.gentoo.org/833426
>
> Here are the Fedora bugs:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2054956
> https://bugzilla.redhat.com/show_bug.cgi?id=2054957
> https://bugzilla.redhat.com/show_bug.cgi?id=2054959
> https://bugzilla.redhat.com/show_bug.cgi?id=2054960
> https://bugzilla.redhat.com/show_bug.cgi?id=2054955
> https://bugzilla.redhat.com/show_bug.cgi?id=2054973
> https://bugzilla.redhat.com/show_bug.cgi?id=2054974
> https://bugzilla.redhat.com/show_bug.cgi?id=2054979
> https://bugzilla.redhat.com/show_bug.cgi?id=2054980
> https://bugzilla.redhat.com/show_bug.cgi?id=2054958
> https://bugzilla.redhat.com/show_bug.cgi?id=2054972
> https://bugzilla.redhat.com/show_bug.cgi?id=2054978
>
> ___
> 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] Deprecation warnings with GCC 12

[Ian McInerney]

Hi Steve,

These warnings have already been addressed in the master branch because we
switched to C++17 (so those deprecated functions were removed and no longer
available). We didn't cherry-pick the change to v6 though, because it was
more of a cleanup than a bug fix (and v6 is staying with C++14, so it will
always have those functions). I think you could safely ignore the warnings
in the build with the understanding they will be fixed in v7.

-Ian

On Tue, Jan 25, 2022 at 10:46 PM Steven A. Falco 
wrote:

> I don't know if anyone is currently interested in deprecation warnings
> with GCC 12, but I'm seeing messages like:
>
> /builddir/build/BUILD/kicad-6.0.1/include/hashtables.h:36:25: warning:
> 'template struct
> std::binary_function' is deprecated [-Wdeprecated-declarations]
>
> and
>
> /builddir/build/BUILD/kicad-6.0.1/include/hashtables.h:80:29: warning:
> 'template struct std::unary_function' is
> deprecated [-Wdeprecated-declarations]
>
> when building with GCC 12.  I'm not a C++ developer so I don't know how
> significant these are.
>
> A full log is available here:
> https://kojipkgs.fedoraproject.org//work/tasks/7031/81867031/build.log
>
> Should I write this up as an issue, or should it be ignored for now?
>
> 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] Was the initial graphics mode screen removed?

[Ian McInerney]

Hi Steve,

On Tue, Jan 11, 2022 at 3:47 PM Steven A. Falco 
wrote:

> I've opened https://gitlab.com/kicad/code/kicad/-/issues/10375
>
> I'll be adding more info to the issue as I do more testing.  Right now,
> the issue just reports on visual artifacts that make accelerated graphics
> unusable on my desktop machine.
>
> I'll add info on the segfaults that I see in VMs asap.
>

This might already have been reported in
https://gitlab.com/kicad/code/kicad/-/issues/8944 and fixed in the master
and 6.0 branches. There is a workaround in there for v6 that you could try
(it is setting an environment variable before launching KiCad).


> This stuff will no doubt take time to resolve.  The artifacts may be even
> harder to address than the segfaults, because I don't see how to gather
> data on what is causing the flickering and pad color errors as described in
> the issue.  I therefore respectfully recommend putting the dialog back in
> until the issues are resolved.
>
>
I don't think the dialog would help any in the situation you are describing
with the artifacts on the screen. It was only shown on first start, so it
wouldn't give the choice in future runs (which would be after you notice
all the artifacts). You can change the rendering backend in the preferences
pane though, so you can switch back to the fallback graphics that way.

-Ian


> Steve
>
> On 1/11/22 09:03 AM, Seth Hillbrand wrote:
> > Hi Steve-
> >
> > Please open an issue with the details of your machines that crash when
> trying to use accelerated graphics.  We thought that we had addressed all
> or almost all of these cases.
> >
> > Our current plan is to shift our backend graphics away from the
> OpenGL/Cairo engines and use a third-party library like libbgfx.  This may
> remove any option for Cairo rendering in the future, so it'll be good to
> work out the kinks.
> >
> > And for the peanut gallery: of course we check libraries and query
> features before using them.  The segfaults happen when libraries return
> values that they don't actually support.  Mesa/X11 is a big culprit here on
> Linux and older bulit-in intel drivers on Windows do the same.  The way we
> do better is to get detailed system reports when segfaults happen.  If
> folks just sit on these issues because fallback works for them, then we'll
> never fix them.
> >
> > Seth
> >
> > On Mon, Jan 10, 2022 at 8:55 PM Steven A. Falco  > wrote:
> >
> > In the past, when running eeschema or pcbnew for the first time, it
> would ask if I wanted to try accelerated graphics.  That no longer seems to
> be the case - I don't get that dialog.
> >
> > I don't know if the dialog was intentionally removed or if it is a
> bug, but I think it is an issue either way, because the default is now
> accelerated graphics, which results in segfaults on some machines that I
> have here.
> >
> > Today I was trying some experiments in a new VM, and I couldn't
> launch eeschema, either from the main app or standalone.  It would segfault
> before putting up its window.  Then I remembered that I had had that
> problem in the past when I was trying out accelerated graphics.  But in the
> past, I was able to select fallback graphics from that initial dialog.
> >
> > In this case, my only way to fix the situation was to copy the json
> config files from another machine that was already configured for fallback
> graphics.  That worked.  KiCad was now usable in the VM.
> >
> > Most people won't have a set of suitable json files laying around to
> get past the segfault, or even know to try that.  Thus, I think the initial
> dialog needs to be there, or perhaps the default should be changed to
> fallback graphics.
> >
> >  Steve
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>
> >
> >
> >
> > --
> > KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬
> > Long Beach, CA
> > www.kipro-pcb.com  i...@kipro-pcb.com
> 
> >
>
>
> ___
> 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] strange, probably trivial, message formatting error

[Ian McInerney]

Did you include the newlines in the translated text?

-Ian

On Mon, Nov 29, 2021 at 9:22 AM Marco Ciampa  wrote:

> Hi devs,
> the message here:
>
> #: common/dialogs/dialog_global_lib_table_config.cpp:42
> #, c-format
> msgid ""
> "KiCad has been run for the first time using the new %s library table
> for\n"
> "accessing libraries.  In order for KiCad to access %s libraries,\n"
> "you must configure your global %s library table.  Please select from
> one\n"
> "of the options below.  If you are not sure which option to select,
> please\n"
> "use the default selection."
>
>  seems to be rendered without new lines (see image attached). It is
> obviously very difficoult to read.
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> 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] [OT-ish] Rotate while moving?

[Ian McInerney]

Please update your build. That version string is showing that your current
build is over 4 months old (it is from early June), and a loy of bugs have
been fixed since then.

-Ian

On Mon, 15 Nov 2021, 5:49 pm Brian,  wrote:

> Sorry, I always forget to include that.
>
> Application: Pcbnew
> Version: (5.99.0-1130-ge92acbb7f-dirty), release build
> Libraries:
>  wxWidgets 3.0.5
>  libcurl/7.74.0 GnuTLS/3.7.2 zlib/1.2.11 brotli/1.0.9 libidn2/2.3.2
> libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
> Platform: Linux 4.19.0-9-amd64 x86_64, 64 bit, Little endian, wxGTK
> Build Info:
>  Build date: Jun  5 2020 19:11:31
>  wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
>  Boost: 1.67.0
>  OpenCASCADE Community Edition: 6.9.1
>  Curl: 7.64.0
>  Compiler: GCC 8.3.0 with C++ ABI 1013
>
> Build settings:
>  KICAD_SCRIPTING=ON
>  KICAD_SCRIPTING_MODULES=ON
>  KICAD_SCRIPTING_PYTHON3=OFF
>  KICAD_SCRIPTING_WXPYTHON=ON
>  KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
>  KICAD_SCRIPTING_ACTION_MENU=ON
>  BUILD_GITHUB_PLUGIN=ON
>  KICAD_USE_OCE=ON
>  KICAD_USE_OCC=OFF
>  KICAD_SPICE=ON
>
>
> On 11/15/21 12:22 PM, Jeff Young wrote:
> > It works on my build (5.99).  What version are you running?
> >
> >> On 15 Nov 2021, at 16:58, Brian  wrote:
> >>
> >> Hi,
> >>
> >> I would swear that at one time in the past, while moving / grabbing a
> symbol or footprint (M or G), I could rotate it in the midst of the
> move/grab operation by pressing R.  Somewhere along the way, that stopped
> working; now I can only move, grab, OR rotate.
> >>
> >> Is there some option that controls this?  Being able to rotate while
> moving saves a lot of clicks when I'm trying to determine the best fit,
> turning a part this way and that while moving it around...
> >>
> >> I know this is more of a usage question than a development question, so
> please excuse the noise if this is the complete wrong place to ask.
> >>
> >> Thanks,
> >> -Brian
> >>
> >> ___
> >> 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] Fwd: Crash invoking pcbnew Board settings

[Ian McInerney]

So, for some reason GMail thinks this email is empty when I open it but
shows text in the inbox view, so I am going off of what I can see in the
"show original message" option.

For running with ASAN, you simply need to pass the CMake flag
KICAD_SANITIZE_ADDRESS and then I would suggest setting the environment
variable
"ASAN_OPTIONS=detect_leaks=0:halt_on_error=0:check_initialization_order=1:detect_stack_use_after_return=1:detect_invalid_pointer_pairs=2"
in whatever you run the KiCad process in (that helps configure ASAN).

-Ian

FYI, the content I can see:

Devs,

Can someone run this on the flatpak and see if it reproduces for them?  (It=
 does not for me on OSX.  Speaking of which, can someone refresh my memory =
on the cmake instruction to turn on something like ASAN on OSX?)

Cheers,
Jeff.


On Sat, Nov 6, 2021 at 5:56 PM Jeff Young  wrote:

> ___
> 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] missing? #include

[Ian McInerney]

Is it on a recent clone of the wxWidgets master branch? I thought this was
fixed upstream in July in https://github.com/wxWidgets/wxWidgets/pull/2436.

-Ian

On Thu, Sep 9, 2021 at 12:35 AM  wrote:

> Hi Wayne,
>
> just did a git clone on the wxWdigets master.
>
> There does not seem to be an explicit 3.1.6 tag though. 'master' apears
> to do the trick. Yes, 20.04 comes with wxWidgets 3.0.4
>
> Cheers
>
> Johannes
>
> On 8/09/21 11:22 pm, Wayne Stambaugh wrote:
> > Hi Johannes,
> >
> > I'm curious where you got wxWidgets 3.1.6 from.  The last tag I see in
> > the wxWidgets repo is 3.1.5 and I'm pretty sure KiCad builds fine with
> > wxWidgets 3.1.5.  AFAIK, the version of wxWidgets packaged for Ubuntu
> > 20.04 is 3.0.4.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 9/8/21 12:55 AM, j...@vfedtec.com wrote:
> >> Howdy,
> >>
> >> latest (today, yesterday) kicad 5.99 master source compile on 20.04
> >>
> >> Successful compilation was possible only after the
> >> addition of below statement in below four files.
> >>
> >> #include 
> >>
> >> .../kicad/common/dialogs/dialog_migrate_settings_base.h
> >> .../kicad/eeschema/dialogs/dialog_schematic_find_base.h
> >> .../kicad/gerbview/toolbars_gerber.cpp
> >> .../kicad/pcbnew/dialogs/dialog_find_base.cpp
> >>
> >> Without the '#includes', no go! Any clues?
> >>
> >> Cheers
> >>
> >> Johannes
> >>
> >> ---
> >>
> >> Application: KiCad
> >>
> >> Version: (5.99.0-12259-g7b4b7fe1ca), release build
> >>
> >> Libraries:
> >>  wxWidgets 3.1.6
> >>  libcurl/7.68.0 GnuTLS/3.6.13 zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0
> >> libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0
> >> librtmp/2.3
> >>
> >> Platform: Linux 5.4.0-77-generic x86_64, 64 bit, Little endian, wxGTK,
> >> xubuntu, x11
> >>
> >> Build Info:
> >>  Date: Sep 8 2021 11:04:42
> >>  wxWidgets: 3.1.6 (wchar_t,wx containers) GTK+ 3.24
> >>  Boost: 1.71.0
> >>  OCC: 7.5.2
> >>  Curl: 7.68.0
> >>  ngspice: 31
> >>  Compiler: GCC 10.3.0 with C++ ABI 1014
> >>
> >> Build settings:
> >>  KICAD_USE_OCC=ON
> >>  KICAD_USE_EGL=ON
> >>  KICAD_SPICE=ON
> >>
> >>
> >>
> >> ___
> >> 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] libngspice versioning by libtool

[Ian McInerney]

On Mon, Aug 2, 2021 at 11:32 AM Carsten Schoenert 
wrote:

> Hi Holger,
>
> Am 31.07.21 um 15:52 schrieb Holger Vogt:
> > Hello Carsten,
> >
> > there are two thing now open:
> >
> > I have made an update to ngspice in branch pre-master:
> > Now all boolean symbols transferred over the ABI are of true boolean
> > type. So the interfacing from any caller does not need to be changed,
> > your compile should then (hopefully) finish successfully.
>
> today I was able to have a look again. Thanks for patience.
>
> I've rebuilt a new snapshot of Debian packages for ngspice and installed
> the libngspice specific packages for further testing.
>
> The build of the current master of kicad is still failing with the same
> error message as previously. This isn't ngspice related I guess.
>
> > [ 42%] Building CXX object
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o
> > [ 42%] Building CXX object
> bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2component.cpp.o
> > [ 42%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_netlist_base.cpp.o
> >
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:241:22:
> error: use of undeclared identifier 'T_pinfunction'
> > case T_pinfunction:
> >  ^
> >
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:247:22:
> error: use of undeclared identifier 'T_pintype'
> > case T_pintype:
> >  ^
> >
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:371:14:
> error: use of undeclared identifier 'T_property'
> > case T_property:
> >  ^
> > 3 errors generated.
> > make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:689:
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o]
> Fehler 1
> > make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet...
>
>
> The build of the current HEAD in the branch 5.1 (configured the same way
> as the master branch) successes now again with ngspice c4470db.
> And so far KiCad is also usable.
>
> This error has been discussed on the list before, but basically it is
caused by using the same source tree and trying to build both 5.1 and
master by switching back and forth between them using git checkout. There
were several changes to where auto-generated header files are located
between the two, so if you switch between the two it can get the wrong
header files - specifically this error is it using the 5.1 header file
which was created in the source tree in the master branch build instead of
the new one for the master branch that was created in the build directory.
One way to fix this is to use different trees for the two, or remove the
ignored generated files.

-Ian


>
> > Concerning loading the ngspice shared library:
> > With the help of reading the commit
> >
> https://gitlab.com/kicad/code/kicad/-/commit/b445b0fab28f7dd41273801d06d7705215c57c0f
> > the procedure seems to be:
> > With cmake function get_filename_component() at compile time KiCad
> > detects a path to ngspice and hard-codes it in NGSPICE_DLL_FILE.
> > This variable then is used to load ngspice dynamically at runtime. So
> > everything depends what string one finds in NGSPICE_DLL_FILE
> (ngspice.cpp).
> >
> > Unfortunately I have not been able to compile KiCad so far
> > (wxPython/Phoenix seems to be not yet available in openSUSE Leap 15.3).
> > So, Carsten, if you can compile, could you have a look at the contents
> > of NGSPICE_DLL_FILE?
>
> I'm not that familiar with CMake and there are probably some differences
> need to be done between the three operating systems in the end as they
> behave differently. So I think I can't say really helpful things in that
> matter. I'd use at least different names for the variable that is
> pointing to the ngspice specific library, we usually talk about "shared
> objects" (SO) within Linux/GNU and dynamic linked libraries (DLL) on the
> Windows side. I've no idea how MacOS is calling these files, maybe also
> shared objects.
>
> For the Linux world it would be needed to link against the name
> libngspice.so.0 currently as this is the API version that is required,
> but before the CMake checking needs to prove that the current minimal
> required version is available on the system. That's currently c:a:r
> 0.0.x if the set of available symbols is enough.
>
> This can be done by using pkg-config (pkg-config --modversion ngspice).
>
> The build configuration of ngspice is currently using the package
> version that is abstracted by autoconf and configure.ac (currently this
> is 35) for adding a version number into ngspice.pc.
> There is no specific requirement which version number has to be used
> here, some packages (probably most of it) simply use a semver based
> package version, some packages using here the 

Re: [Kicad-developers] Problem building on Fedora Rawhide

[Ian McInerney]

Steve,

I saw that failure last night also, and I think it may be a wxPython
problem with Python 3.10. I don't hav ea Rawhide VM available at the
moment, but what we should do is try the following:

1) Install Python 3.10 and python-wxpython4 in a Rawhide install
2) Run python -c "import wx;print(wx.version())"
3) See if it errors

My guess is there will be an error in step 2, in which case we need to push
it upstream to wxPython and the Fedora Python maintainers.

-Ian

On Fri, Jul 30, 2021 at 3:26 PM Steven A. Falco 
wrote:

> The nightly build failed with an error when building KiCAD for Fedora
> Rawhide, when discovering the python interpreter.  I haven't tracked down
> the root cause yet, but below are the error messages in case anyone has an
> idea on what can cause this.  Fedora has recently upgraded the python
> version, so perhaps that is the cause.
>
> Steve
>
> -- Found PythonInterp: /usr/bin/python3 (found version "3.10")
> -- Found PythonLibs: /usr/lib64/libpython3.10.so
> -- Performing Test HAS_FLTO
> -- Performing Test HAS_FLTO - Success
> -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.10",
> minimum required is "3.6")
> -- Check for installed Python Interpreter -- found
> :1: DeprecationWarning: The distutils package is deprecated and
> slated for removal in Python 3.12. Use setuptools or check PEP 632 for
> potential alternatives
> :1: DeprecationWarning: The distutils.sysconfig module is
> deprecated, use sysconfig instead
> -- Python module install path: lib/python3.10/site-packages
> -- Found PythonLibs: /usr/lib64/libpython3.10.so (found suitable version
> "3.10.0b4", minimum required is "3.6")
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.10/site-packages/wx/__init__.py", line 17, in
> 
>  from wx.core import *
>File "/usr/lib64/python3.10/site-packages/wx/core.py", line 12, in
> 
>  from ._core import *
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 261:
> invalid continuation byte
> free(): invalid size
> CMake Error at CMakeModules/FindwxPython.cmake:66 (message):
>Unknown wxPython/Phoenix version string:
> Call Stack (most recent call first):
>CMakeLists.txt:835 (find_package)
> -- Configuring incomplete, errors occurred!
> See also
> "/builddir/build/BUILD/kicad-baf67986957afc3b4c47ed6f3def0ba3af76d2e9/redhat-linux-build/CMakeFiles/CMakeOutput.log".
> See also
> "/builddir/build/BUILD/kicad-baf67986957afc3b4c47ed6f3def0ba3af76d2e9/redhat-linux-build/CMakeFiles/CMakeError.log".
> error: Bad exit status from /var/tmp/rpm-tmp.R634pK (%build)
> RPM build errors:
>  line 57: It's not recommended to use '>' in Obsoletes: Obsoletes:
>   kicad >= 100:r1-1
>  Bad exit status from /var/tmp/rpm-tmp.R634pK (%build)
> Child return code was: 1
> EXCEPTION: [Error()]
> Traceback (most recent call last):
>File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py",
> line 93, in trace
>  result = func(*args, **kw)
>File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in
> do_with_status
>  raise exception.Error("Command failed: \n # %s\n%s" % (command,
> output), child.returncode)
> mockbuild.exception.Error: Command failed:
>   # /usr/bin/systemd-nspawn -q -M c4a5491b70ab476abdc4b76cbef74bac -D
> /var/lib/mock/fedora-rawhide-x86_64/root -a -u mockbuild
> --capability=cap_ipc_lock --bind=/tmp/mock-resolv.3h0kphr8:/etc/resolv.conf
> --bind=/dev/btrfs-control --bind=/dev/loop-control --bind=/dev/loop0
> --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
> --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8
> --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe
> --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> --setenv=PROMPT_COMMAND=printf "\033]0;\007"
> --setenv=PS1= \s-\v\$  --setenv=LANG=C.UTF-8 --resolv-conf=off
> bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps
> /builddir/build/SPECS/kicad-nightly.spec
>
> ___
> 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] libngspice versioning by libtool

[Ian McInerney]

Depending on how the OpenSUSE build system si setup, a prebuilt version
from their repository might not work with a library with a different
version. Many build systems for Linux packages will encode a dependency on
a specific version of the shared library, which is included in the
filename. When that changes (called an SONAME bump), the dependent packages
must be rebuilt to pickup the new SONAME.

Try building KiCad with the new ngspice library and see what happens. I
think that should pick up your new version and work properly.

-Ian

On Wed, Jul 28, 2021 at 8:23 AM Holger Vogt  wrote:

> Pre-built 5.1.10, installed from openSUSE Leap 15.3 Electronics
> repository, delivered with ngspice-34.
>
> I have opened an issue at
> https://gitlab.com/kicad/code/kicad/-/issues/8878
>
> If this is a non-issue (hopefully) and future 5.1.11 and 5.99 will not
> have any problems, I would be happy to add versioning to ngspice shared
> library.
>
> ___
> 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] libngspice versioning by libtool

[Ian McInerney]

At this point, KiCad isn't defining a version requirement on ngspice, so
any way you choose to do it would work for us.

As for the issue compiling earlier, did you try to use your new ngspice
build with a pre-built KiCad version or did you build that KiCad version
yourself?

-Ian

On Tue, Jul 27, 2021 at 7:13 PM Holger Vogt  wrote:

> Carsten,
>
> it is not about what I should do, but what the KiCad devs should do to
> allow me adding versioning to shared ngspice.  I will add versioning if
> it is aknowledged by KiCad/Eeschema.
>
> Holger
>
>
> ___
> 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] New lead developer announcement

[Ian McInerney]

Congrats Roberto!

On Tue, Jul 6, 2021 at 1:04 PM Wayne Stambaugh  wrote:

> I am happy to announce that Roberto Fernandez Bautista has accepted an
> invitation to the KiCad lead development team.  Roberto has made some
> significant contributions to the KiCad project and I look forward to his
> contributions as lead developer.  Please join me in congratulating
> Roberto in his new role.
>
> Cheers,
>
> Wayne
>
> ___
> 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] OCE vs. OCC default build flag

[Ian McInerney]

I would prefer we keep this change to 5.99/6.0 only and not force a default
change in 5.1 builds. There are enough other dependency changes going on
for future v6 that packagers/users have to handle I think it is more
reasonable to force it there.

-Ian

On Tue, May 18, 2021 at 5:35 PM Eeli Kaikkonen 
wrote:

> See
> https://gitlab.com/eelik-kicad/kicad/-/wikis/How-to-build-KiCad-on-Ubuntu-(the-easy-way)
>
> The reason I started this thread was that I saw that practically all
> packages were using OCC already, so it's available.
>
> On Tue, May 18, 2021 at 6:04 PM Kevin Cozens  wrote:
> >
> > How will this affect those of us who build KiCad from source? I have
> liboce
> > packages installed which provide OCE. If you change to OCC what
> package(s)
> > will I need then? The distro I use (Linux Mint) has libocct (Open CASCADE
> > Technology) packages. Is that what I will need or will I have to find
> > another source (ie. a PPA) for the support libraries?
> >
>
> Eeli Kaikkonen
>
> ___
> 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] Feature request: Gerbview - Print - Pagination option

[Ian McInerney]

Hi Clifford,

Welcome to the list! That sounds like a good suggestion, but we keep track
of feature requests in the issue database on GitLab
https://gitlab.com/kicad/code/kicad. Are you able to make a new issue
describing the feature you want added (the direct link to make a new issue
is https://gitlab.com/kicad/code/kicad/-/issues/new?issue?

Thanks,
-Ian

On Wed, May 5, 2021 at 10:15 PM Clifford Neal Simon  wrote:

> Hi devs,
>
> New mailing-list member here.
>
> When I print multiple layers from Gerbview, the layers appear one per
> page. Would like a radio button for pagination, to choose all layers on one
> page or one layer on each page. Pcbnew has this but not Gerbview.
>
> In my engineering workflow I print out a paper PCB "model" showing (only)
> the edges, drills, and silkscreen. With office tools I cut the edges and
> accurately punch out the drill holes for all mounting hardware, then I
> "install" the piece of paper in the mounting to show board shape and
> silkscreen in the actual housing and mounting. This is also a test of
> gerber integrity since the "model" is produced from preliminary gerbers. In
> my current workflow I have to print from Gerbview (to PDF) then postprocess
> the PDF to flatten it to one page.
>
> Note, I think pcbnew can print "real" drill if you include a copper layer
> but my "model" must not show any copper or soldermask. Silkscreen only.
> Also, a print from pcbnew is useless for gerber integrity. Whence, I am
> inquiring about the pagination feature for Gerbview, to be sure
> verification of gerber is included in the workflow.
>
>
>
> Clifford Simon
> I'm using (5.1.9)-1. I just saw the 5.1.10 release but I haven't
> downloaded it yet.
>
> ___
> 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] Building with sanitizers on master branch

[Ian McInerney]

I have added support to build with the thread sanitizer on the master
branch (including annotating our coroutine implementation to track the
context switching). The thread sanitizer can be enabled using the flag
CMake KICAD_SANITIZE_THREADS.

As part of this change, I have changed the address sanitizer flag to be
KICAD_SANITIZE_ADDRESS instead of just KICAD_SANITIZE - so if you have been
using that option you will need to update your build scripts and do a clean
rebuild. The address sanitizer can still report false positives due to our
coroutine switching though - so beware about using it. I hope to spend a
bit of time soon adding the proper annotations to the coroutine
implementation to let ASAN track the stack (and hopefully reduce false
positives).

-Ian
___
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] Nightly Linux Packaging Changes

[Ian McInerney]

A point of clarification: this is only master branch (5.99) builds. None of
these changes will be in stable releases until v6 (so they aren't in 5.1).

-Ian

On Thu, Apr 15, 2021 at 5:38 PM Ian McInerney 
wrote:

> FYI to all the packagers who work with the nightly packages on Linux, I
> have just merged in a set of changes overhauling the metadata naming and
> contents (https://gitlab.com/kicad/code/kicad/-/merge_requests/742).
> These changes make our files follow the standard file-naming system now
> (org.kicad.*), and also renames from an appdata file to a metainfo file
> (which is the new file we should be providing - since the appdata name is
> being phased out).
>
> You will probably need to update the packaging scripts accordingly (with
> the new metainfo directory, filenames, changed sed commands, etc). Let me
> know if you see any problems with this batch of changes.
>
> -Ian
>
___
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] Nightly Linux Packaging Changes

[Ian McInerney]

FYI to all the packagers who work with the nightly packages on Linux, I
have just merged in a set of changes overhauling the metadata naming and
contents (https://gitlab.com/kicad/code/kicad/-/merge_requests/742). These
changes make our files follow the standard file-naming system now
(org.kicad.*), and also renames from an appdata file to a metainfo file
(which is the new file we should be providing - since the appdata name is
being phased out).

You will probably need to update the packaging scripts accordingly (with
the new metainfo directory, filenames, changed sed commands, etc). Let me
know if you see any problems with this batch of changes.

-Ian
___
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] Can't show 3D models (was: build failure)

[Ian McInerney]

That is unrelated to the 3D models issue and is instead the software
rendering not working on macOS - so it can be fixed by simply switching to
the accelerated (OpenGL) canvas. We have an open ticket to remove the
software rendering from Pcbnew in 5.1 here
https://gitlab.com/kicad/code/kicad/-/issues/7052, and we have already
removed it from 5.99.

-Ian

On Mon, Mar 8, 2021 at 12:16 PM Marco Ciampa  wrote:

> On Sat, Mar 06, 2021 at 06:09:22PM +0100, Jonatan Liljedahl wrote:
> > If I manually copy libTKVCAF.7.dylib into
> > /kicad/KiCad.app/Contents/PlugIns/3d/ then "make install"
> > succeeds.
> >
> > Also, libTKVCAF and all its friends was copied into
> > $(CMAKE_INSTALL_PREFIX)/KiCad.app/Contents/Frameworks/
> > so they all exist there.
> >
> > But still, no 3D models at all are shown.
> >
> > I tried moving them to KiCad.app/Contents/PlugIns/3d/ but that didn't
> > help either.
> >
> > Ideas?
>
> Somebody reported to me that he cannot see anything than a grey layer in
> pcbnew with kicad 5.1.9 and 5.1.8 in both Big Sur and Mojave and instead
> with the oldest 5.1 is all ok. Sorry I haven't more precise information
> about this issue. Is it possible that this can be related to that?
>
> Hope this incomplete report can help somehow...
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> 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] Can't show 3D models (was: build failure)

[Ian McInerney]

Hmm, I wonder if this is another instance of a pathing issue. We had a
similar bug on Linux that was caused by the 3d viewer looking for the
plugin to load OCE files in the wrong location, so it just wouldn't load
any files. That was https://gitlab.com/kicad/code/kicad/-/issues/7750,
which I have reopened so we can take a look at it again on macOS.

-Ian

On Sat, Mar 6, 2021 at 10:31 PM Jonatan Liljedahl 
wrote:

> Hi,
>
> I tried the nightly 20210306, and actually no, it shows no models
> either! See attached screenshots.
> As you see, I have KICAD6_3DMODEL_DIR =
> /Users/lijon/Coding/kicad-packages3D, which is where I've cloned the
> kicad-packages3D gitlab repo. The model is there:
>
> % ls -l
> /Users/lijon/Coding/kicad-packages3D/LED_THT.3dshapes/LED_D3.0mm.wrl
> -rw-r--r--  1 lijon  staff  36129 Aug 16  2020
> /Users/lijon/Coding/kicad-packages3D/LED_THT.3dshapes/LED_D3.0mm.wrl
>
> On Sat, Mar 6, 2021 at 6:56 PM Adam Wolf 
> wrote:
> >
> > Do the release versions work for you?
> >
> > Assuming it does, this is almost certainly an issue with dyld and
> fixup_bundle.
> >
> > Let me know if the release/nighties work on your system, and I can walk
> folks through how to solve it.
> >
> >
> > Adam
> >
> > On Sat, Mar 6, 2021, 11:09 AM Jonatan Liljedahl 
> wrote:
> >>
> >> If I manually copy libTKVCAF.7.dylib into
> >> /kicad/KiCad.app/Contents/PlugIns/3d/ then "make install"
> >> succeeds.
> >>
> >> Also, libTKVCAF and all its friends was copied into
> >> $(CMAKE_INSTALL_PREFIX)/KiCad.app/Contents/Frameworks/
> >> so they all exist there.
> >>
> >> But still, no 3D models at all are shown.
> >>
> >> I tried moving them to KiCad.app/Contents/PlugIns/3d/ but that didn't
> >> help either.
> >>
> >> Ideas?
> >>
> >> On Sat, Mar 6, 2021 at 9:47 AM Jonatan Liljedahl 
> wrote:
> >> >
> >> > On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf <
> adamw...@feelslikeburning.com> wrote:
> >> > >
> >> > > It is certainly possible that Homebrew is distributing bottles that
> >> > > are linked a little weird, and you'd be getting the MacOS 10.14
> >> > > reference from that.  We've had this happen before.
> >> >
> >> > Yes, I think this was the case with my OCE install, OCEConfig.cmake
> >> > referenced 10.14. After unbrewing OCE, I tried to brew install it
> >> > again but only got a 404. However, after that I reinstalled OCC and it
> >> > built fine so maybe OCE and OCC was in conflict or something.
> >> >
> >> > > Regarding the libTKVCAF error, it looks like something's not quite
> >> > > right between the library and the fixup_bundle call.
> >> > >
> >> > > Does libTKVCAF.7.dylib exist on your system?
> >> >
> >> > Yes, that and all other OCC libs exist in
> >> > /usr/local/Cellar/opencascade/7.5.0_1/lib as well as symlinked into
> >> > /usr/local/lib (by homebrew).
> >> >
> >> > So I assume the problem here is that it's not finding all these libs
> >> > at runtime? How can I check if this is actually the issue here?
> >> >
> >> > During "make install" I get all these warnings:
> >> >
> >> > -- warning: embedded item does not exist
> >> >
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCAF.7.dylib'
> >> > --
> >> > warning: cannot resolve item '@loader_path/libTKCAF.7.dylib'
> >> >
> >> >   possible problems:
> >> > need more directories?
> >> > need to use InstallRequiredSystemLibraries?
> >> > run in install tree instead of build tree?
> >> >
> >> > -- warning: embedded item does not exist
> >> >
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKV3d.7.dylib'
> >> > --
> >> > warning: cannot resolve item '@loader_path/libTKV3d.7.dylib'
> >> >
> >> >   possible problems:
> >> > need more directories?
> >> > need to use InstallRequiredSystemLibraries?
> >> > run in install tree instead of build tree?
> >> >
> >> > -- warning: embedded item does not exist
> >> >
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKLCAF.7.dylib'
> >> > --
> >> > warning: cannot resolve item '@loader_path/libTKLCAF.7.dylib'
> >> >
> >> >   possible problems:
> >> > need more directories?
> >> > need to use InstallRequiredSystemLibraries?
> >> > run in install tree instead of build tree?
> >> >
> >> > -- warning: embedded item does not exist
> >> >
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCDF.7.dylib'
> >> > --
> >> > warning: cannot resolve item '@loader_path/libTKCDF.7.dylib'
> >> >
> >> >   possible problems:
> >> > need more directories?
> >> > need to use InstallRequiredSystemLibraries?
> >> > run in install tree instead of build tree?
> >> >
> >> > -- warning: embedded item does not exist
> >> >
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKBO.7.dylib'
> >> > --
> >> > warning: cannot resolve item '@loader_path/libTKBO.7.dylib'
> >> >
> >> >   possible problems:
> >> > need more directories?
> >> > need to use 

Re: [Kicad-developers] error compiling kicad branch 5.1

[Ian McInerney]

The main reason we don't have CI on 5.1 is that I was being lazy and didn't
setup any and just focused on getting the master branch CI working since
that is what sees the most development.

-Ian

On Wed, Feb 17, 2021 at 3:49 PM Jon Evans  wrote:

> We don't have CI on the 5.1 branch right now.  I'm not sure if there is
> any reason other than needing to set up additional runner machines, I agree
> it would be a good idea.
>
> On Wed, Feb 17, 2021 at 10:46 AM Marco Ciampa  wrote:
>
>> On Wed, Feb 17, 2021 at 08:12:14AM -0500, Jon Evans wrote:
>> > Hi Marco,
>>
>> Hi Jon,
>>
>> > I am not part of kicad-us...@groups.io but I am part of this list and
>> I can
>> > fix the issue you mention, sorry about that...
>>
>> You see, first I try to fix it myself, then ask others, then ask devs as
>> a last resort...
>>
>> Glad I helped spot a glitch... only thought that bugs me... that should
>> be the kind of problem that CI should help detect... I wonder why it
>> didn't work?
>>
>> --
>>
>> Saluton,
>> Marco Ciampa
>>
>> ___
>> 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] ngspice-34

[Ian McInerney]

On Wed, Feb 3, 2021 at 7:34 AM Holger Vogt  wrote:

> To obtain version information of the currently available libngspice-0.so
> version, you might do the following:
>
> load libngspice-0 dynamically
> initialze libngspice
> send the command 'version -s'
> retrieve some text response similar to the following:
>
> **
> ** ngspice-34
> ** Please get your ngspice manual from
> http://ngspice.sourceforge.net/docs.html
> ** Please file your bug-reports at
> http://ngspice.sourceforge.net/bugrep.html
> ** Creation Date: Fri Jan 29 14:27:27 UTC 2021
> **
>
> check for ngspice, get the version number
> unload libngspice
>
>
There was a discussion about retrieving the version information here:
https://gitlab.com/kicad/code/kicad/-/issues/4833, and it looks like Holger
even mentioned that config.h includes the version information so that is
why Wayne used it. The main thing is, having to load the simulator just to
get the version information is a very complicated thing for our system to
handle. The ngspice code in KiCad is only in one specific window, and the
help windows are available from all programs. The reason the build-time
info (from config.h) was chosen is because that information can be exposed
to all the help windows and included in the version string the entire time.

-Ian
___
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] Translation building changes in master

[Ian McInerney]

Ok, I have updated the linux translation framework so that it will now
gracefully handle errors in the file translation. If it detects an error
when translating the metadata it will instead copy the raw metadata file
over and throw a warning into the build log but let the build continue.

-Ian

On Thu, Jan 21, 2021 at 5:25 PM Ian McInerney 
wrote:

> Yes, Steve made me aware of the lack of that file on older distros - and I
> am working on a solution. I am currently building out the CMake files so
> that they try to do the translation and then check the return code and
> fallback to a simple file copy if the translation fails (and display the
> failure as a warning, so it is visible but doesn't stop the build process).
>
> -Ian
>
> On Thu, Jan 21, 2021 at 5:12 PM Steven A. Falco 
> wrote:
>
>> We have the same problem with Fedora 32 because it also doesn't have the
>> needed ITS file.
>>
>> I believe Ian is looking into a solution.
>>
>> Steve
>>
>> On 1/21/21 11:40 AM, Jean-Samuel Reynaud wrote:
>> > Dear Ian,
>> >
>> > Since this update some build fail on ubuntu. In fact there is
>> > translation of some XML files (for example mime types
>> > resources/linux/mime/kicad-gerbers.xml.in) but gettext is unable to
>> find
>> > rules to translate that kind of file without the appropriate ITS file.
>> > On Ubuntu 18.04, shared-mime-info is too old and don't ship
>> > shared-mime-info.loc and shared-mime-info.its. So building is failing.
>> >
>> > So what is your proposal for that ? Perhaps there is already an answer
>> > about this point ? I think I can fix that by coping missing ITS files on
>> > the appropriate directory but it's a dirty solution...
>> >
>> >
>> >
>> >
>> > Le 18/01/2021 à 18:54, Ian McInerney a écrit :
>> >> The changes to the i18n build system have now been merged into the
>> >> master branch - with the change that KICAD_BUILD_I18N will default to
>> >> OFF now, so it must be enabled when you want to build the translations
>> >> libraries.
>> >>
>> >> At this point, all nightly builds of the master branch that include
>> >> translations need to be updated to use the KICAD_BUILD_I18N=ON flag and
>> >> no longer reference the i18n repository.
>> >>
>> >> -Ian
>> >>
>> >> On Sat, Jan 16, 2021 at 7:41 PM Ian McInerney <
>> ian.s.mciner...@ieee.org
>> >> <mailto:ian.s.mciner...@ieee.org>> wrote:
>> >>
>> >>  Since we now host the v6 translations inside the main code
>> >>  repository, I have consolidated the CMake scripts for building the
>> >>  translation files into the main build process inside this MR
>> >>  (https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That
>> >>  exposes a new CMake option `KICAD_BUILD_I18N`, which defaults to
>> on,
>> >>  that controls if the translations are built. When that option is
>> ON,
>> >>  gettext is a required dependency and when it is off it is not
>> >>  needed. This change will require some people to modify their
>> current
>> >>  build setup to disable the translations if they do not wish to
>> build
>> >>  with gettext.
>> >>
>> >>  In that MR I have also added the linux metadata files to the
>> >>  translation framework to allow for the strings contained inside
>> them
>> >>  to be internationalized (so that the user sees translated strings
>> on
>> >>  desktop icons/tooltips in their display manager). That should be a
>> >>  transparent change to the packagers of nightly builds, but a
>> welcome
>> >>  change for users.
>> >>
>> >>  -Ian
>> >>
>> >>
>> >> ___
>> >> 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] Translation building changes in master

[Ian McInerney]

Yes, Steve made me aware of the lack of that file on older distros - and I
am working on a solution. I am currently building out the CMake files so
that they try to do the translation and then check the return code and
fallback to a simple file copy if the translation fails (and display the
failure as a warning, so it is visible but doesn't stop the build process).

-Ian

On Thu, Jan 21, 2021 at 5:12 PM Steven A. Falco 
wrote:

> We have the same problem with Fedora 32 because it also doesn't have the
> needed ITS file.
>
> I believe Ian is looking into a solution.
>
> Steve
>
> On 1/21/21 11:40 AM, Jean-Samuel Reynaud wrote:
> > Dear Ian,
> >
> > Since this update some build fail on ubuntu. In fact there is
> > translation of some XML files (for example mime types
> > resources/linux/mime/kicad-gerbers.xml.in) but gettext is unable to find
> > rules to translate that kind of file without the appropriate ITS file.
> > On Ubuntu 18.04, shared-mime-info is too old and don't ship
> > shared-mime-info.loc and shared-mime-info.its. So building is failing.
> >
> > So what is your proposal for that ? Perhaps there is already an answer
> > about this point ? I think I can fix that by coping missing ITS files on
> > the appropriate directory but it's a dirty solution...
> >
> >
> >
> >
> > Le 18/01/2021 à 18:54, Ian McInerney a écrit :
> >> The changes to the i18n build system have now been merged into the
> >> master branch - with the change that KICAD_BUILD_I18N will default to
> >> OFF now, so it must be enabled when you want to build the translations
> >> libraries.
> >>
> >> At this point, all nightly builds of the master branch that include
> >> translations need to be updated to use the KICAD_BUILD_I18N=ON flag and
> >> no longer reference the i18n repository.
> >>
> >> -Ian
> >>
> >> On Sat, Jan 16, 2021 at 7:41 PM Ian McInerney  >> <mailto:ian.s.mciner...@ieee.org>> wrote:
> >>
> >>  Since we now host the v6 translations inside the main code
> >>  repository, I have consolidated the CMake scripts for building the
> >>  translation files into the main build process inside this MR
> >>  (https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That
> >>  exposes a new CMake option `KICAD_BUILD_I18N`, which defaults to
> on,
> >>  that controls if the translations are built. When that option is
> ON,
> >>  gettext is a required dependency and when it is off it is not
> >>  needed. This change will require some people to modify their
> current
> >>  build setup to disable the translations if they do not wish to
> build
> >>  with gettext.
> >>
> >>  In that MR I have also added the linux metadata files to the
> >>  translation framework to allow for the strings contained inside
> them
> >>  to be internationalized (so that the user sees translated strings
> on
> >>  desktop icons/tooltips in their display manager). That should be a
> >>  transparent change to the packagers of nightly builds, but a
> welcome
> >>  change for users.
> >>
> >>  -Ian
> >>
> >>
> >> ___
> >> 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] Translation building changes in master

[Ian McInerney]

The changes to the i18n build system have now been merged into the master
branch - with the change that KICAD_BUILD_I18N will default to OFF now, so
it must be enabled when you want to build the translations libraries.

At this point, all nightly builds of the master branch that include
translations need to be updated to use the KICAD_BUILD_I18N=ON flag and no
longer reference the i18n repository.

-Ian

On Sat, Jan 16, 2021 at 7:41 PM Ian McInerney 
wrote:

> Since we now host the v6 translations inside the main code repository, I
> have consolidated the CMake scripts for building the translation files into
> the main build process inside this MR (
> https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That exposes a
> new CMake option `KICAD_BUILD_I18N`, which defaults to on, that controls if
> the translations are built. When that option is ON, gettext is a required
> dependency and when it is off it is not needed. This change will require
> some people to modify their current build setup to disable the translations
> if they do not wish to build with gettext.
>
> In that MR I have also added the linux metadata files to the translation
> framework to allow for the strings contained inside them to be
> internationalized (so that the user sees translated strings on desktop
> icons/tooltips in their display manager). That should be a transparent
> change to the packagers of nightly builds, but a welcome change for users.
>
> -Ian
>
___
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] Translation building changes in master

[Ian McInerney]

Since we now host the v6 translations inside the main code repository, I
have consolidated the CMake scripts for building the translation files into
the main build process inside this MR (
https://gitlab.com/kicad/code/kicad/-/merge_requests/628). That exposes a
new CMake option `KICAD_BUILD_I18N`, which defaults to on, that controls if
the translations are built. When that option is ON, gettext is a required
dependency and when it is off it is not needed. This change will require
some people to modify their current build setup to disable the translations
if they do not wish to build with gettext.

In that MR I have also added the linux metadata files to the translation
framework to allow for the strings contained inside them to be
internationalized (so that the user sees translated strings on desktop
icons/tooltips in their display manager). That should be a transparent
change to the packagers of nightly builds, but a welcome change for users.

-Ian
___
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] MSVC build, incomplete version info

[Ian McInerney]

In order for the version string to contain the git version information, the
build must be done inside a git repository.

-Ian

On Sun, Nov 15, 2020 at 6:36 PM  wrote:

> Thanks to Mark Roszko’s help I can build now with MSVC and KiCad runs ok.
>
> But then, the version info looks strange (see below). I’m not pulling or
> branching,
>
> simply copying the source over. What am I missing?
>
>
>
> Application: KiCad
>
>
>
> Version: 5.99.0-unknown, debug build
>
>
>
> Libraries:
>
> wxWidgets 3.1.4
>
> libcurl/7.73.0-DEV Schannel zlib/1.2.11
>
>
>
> Platform: Windows 10 (build 19041), 64-bit edition, 64 bit, Little endian,
> wxMSW
>
>
>
> Build Info:
>
> Date: Nov 15 2020 19:13:58
>
> wxWidgets: 3.1.4 (wchar_t,STL containers)
>
> Boost: 1.73.0
>
> OCC: 7.4.0
>
> Curl: 7.73.0-DEV
>
> ngspice: 32
>
> Compiler: Visual C++ 1928 without C++ ABI
>
>
>
> Build settings:
>
> KICAD_SCRIPTING=OFF
>
> KICAD_SCRIPTING_MODULES=OFF
>
> KICAD_SCRIPTING_PYTHON3=OFF
>
> KICAD_SCRIPTING_WXPYTHON=OFF
>
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
>
> KICAD_SCRIPTING_ACTION_MENU=OFF
>
> KICAD_USE_OCC=ON
>
> KICAD_SPICE=ON
>
> KICAD_STDLIB_DEBUG=OFF
>
> KICAD_STDLIB_LIGHT_DEBUG=OFF
>
> KICAD_SANITIZE=OFF
> ___
> 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] eeSchema sporadically switches to "User Grid"

[Ian McInerney]

On Wed, Oct 28, 2020 at 4:07 PM Brian Piccioni 
wrote:

> I found it in Common and reassigned it to ctl-F12 so I won't use it by
> accident. I can't see how to clear or disable a hotkey.
>

If you right-click on the action in the hotkey list there should be an
option to clear the assigned hotkey so that none are assigned to it.

-Ian


> I think this should be a separate function under eeSchema: changing grids,
> especially to a wonky user grid just causes problems.
>
>
> On 2020-10-28 11:54 a.m., Brian Piccioni wrote:
>
> Perhaps it is, however, entering "Grid" in the hotkey search box does not
> yield Next Grid so there is no way for a user to know that 'N' means next
> grid, let alone to disable it.
>
> I would want to disable that function as switching grids in eeSchema is
> just a way of creating problems.
>
>
> On 2020-10-28 11:48 a.m., Laurence DV wrote:
>
> Hello (and all),
>
> I tend to do that by missing the "M" key on my keyboard and hitting "N"
> (select next grid) (fyi Shift-N for previous grid).
>
> User-grid being the last in the list it happen a lot when routing (I tend
> to route on finest grid).
>
> Maybe it is just that?
>
> On 2020-10-28 11:41 a.m., Brian Piccioni wrote:
>
> Hello
>
> I have been having a weird problem for some time now. Every once in a
> while, eeSchema would place things off grid. I am unable to replicate this,
> it just happens.
>
> I noticed just now that eeSchema had switched to "User Grid" of 0.013 in
> (0.32 mm), which I suspect is the root of the "off grid" issues. I thought
> perhaps there was a "Set to user grid" hotkey I was hitting accidentally,
> but I cannot find one.
>
> I have switched my User Grid to 0.05 x 0.05 and I'll see if that at least
> stops the "off grid" problem.
>
> However, I suspect that either there is an undisclosed "Set to user grid"
> hotkey or something is overwriting the grid setting. If there was some way
> of alerting that the grid was set I might be able to provide replication
> instructions.
>
>
> Brian
>
>
> ___
> 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] Odp: broken pipe and a simple commit

[Ian McInerney]

If all you are doing is touching the translations, we will be skipping the
CI checks. Just make the merge request with the update files and it will be
merged. I will look into changing the CI so that it doesn't run if only the
translation files are updated.

On Thu, Oct 22, 2020 at 10:43 AM Marco Ciampa  wrote:

> On Thu, Oct 22, 2020 at 10:52:08AM +0200, Sylwester Kocjan wrote:
> > Hi Marco,   Did you try to push your commit directly on master branch?
>
> No, I did this (as I am used to in github...):
>
> > General Guidelines:
> >
> >1)Always create a new branch for merge requests instead of using your
> fork's master branch.
>
> I created a personal fork. First commit (super small change that does not
> affect compilation at all) error message:
>
> Your pipeline has failed.
>
> Project: kicad ( https://gitlab.com/ciampix/kicad )
> Branch: master ( https://gitlab.com/ciampix/kicad/-/commits/master )
>
> Commit: d8da1615 (
> https://gitlab.com/ciampix/kicad/-/commit/d8da161599065e519cc1a33b8bef01d3be3f8204
> )
> Commit Message: Fixed single language translation update that w...
> Commit Author: Marco Ciampa ( https://gitlab.com/ciampix )
>
> Pipeline #206121055 (
> https://gitlab.com/ciampix/kicad/-/pipelines/206121055 ) triggered by
> Marco Ciampa ( https://gitlab.com/ciampix )
> had 3 failed builds.
>
> Job #805521551 ( https://gitlab.com/ciampix/kicad/-/jobs/805521551/raw )
>
> Stage: report
> Name: report_build_warn
> Job #805521552 ( https://gitlab.com/ciampix/kicad/-/jobs/805521552/raw )
>
> Stage: report
> Name: report_metrics
> Job #805521539 ( https://gitlab.com/ciampix/kicad/-/jobs/805521539/raw )
>
> Stage: build
> Name: build_linux
>
> TIA
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> 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] Can't see references - V5.99 what am I doing wrong?

[Ian McInerney]

On Wed, Oct 14, 2020 at 3:52 PM Jon Evans  wrote:

> "Footprint Text" off turns off all footprint text, including references
> and values.  This isn't new behavior but I worry that the simplified
> objects panel has made it more confusing than it was in 5.1
>
>
This only turns it off when viewing the board, correct? It will still be
included in the plot output if the actual text is marked "Show" in the
dialog.


> We could have the Footprint Text control act as a visual override for the
> Values and References controls to make this more clear...
>

Can we link these controls so that changing the "Footprint Text" visibility
changes the "references" and "values" visibility, but those two can still
be changed separately? (e.g. to allow showing only the references text from
footprints).

-Ian


>
> On Wed, Oct 14, 2020 at 10:49 AM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
>
>> I am working on a PCB with PCBNew from a couple days ago.
>>
>> I can't see the references. Silkscreen is on and the little eye is open
>> but the references don't show up.
>>
>> If I edit a reference it is on the right layer and show is clicked.
>>
>>
>> What am I doing wrong?
>> ___
>> 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] Attempting to build kicad-git source on Slackware-current Linux

[Ian McInerney]

Oh, the Phoenix version of wxWidgets was updated between when they added
the EGL canvas and when they added the option to disable the EGL canvas
apparently. I have opened an issue with Pheonix to see if they will bump
their bundled wx version to a more recent version (that will include the
option of disabling EGL). I am also in the process of making our code work
with EGL, but I have been sidetracked by some other items, so I haven't
gotten it wrapped up yet.

-Ian

On Mon, Oct 12, 2020 at 3:51 PM Tom Crane 
wrote:

> Thanks but I don't appear to have a --disable-glcanvasegl switch,
>
> /tmp/SBo/Phoenix/ext/wxWidgets# ./configure --disable-glcanvasegl
> configure: error: unrecognized options: --disable-glcanvasegl
>
>
> /tmp/SBo/Phoenix/ext/wxWidgets# wx-config --version-full
> 3.1.5.0
> root@mklab:/tmp/SBo/Phoenix/ext/wxWidgets# ./configure --help | grep
> glcanvasegl
>
> I have done a 'git pull' at the top level.
>
> Am I missing something?
>
> Thanks
> Tom
>
> On Mon, 12 Oct 2020, Ian McInerney wrote:
>
> > The OpenGL failing is because wxWidgets has defaulted to an EGL backend
> instead of GLX and I haven't pushed the needed changes in our code to work
> around it yet. For now, you need to add the --disable-glcanvasegl option to
> the wxWidgets configure line.
> > -Ian
> >
> > On Mon, Oct 12, 2020 at 3:20 AM Tom Crane 
> wrote:
> >   Thanks for the clarification -- and to all who follow-ed up.  That
> was the
> >   information I needed.  Now using Phoenix 4.1.1a1/gtk3 (wxWidgets
> 3.1.5)
> >   from git to build both wxPython4 and wxWidgets (wxGTK3+ Slackware
> package)
> >   I was able to build KiCad from git.
> >
> >   Thankfully I don't get the segfaults I had with the previous build
> (using
> >   GTK2+ and Python2).
> >
> >   The one new problem I have is that the accelerated graphics no
> longer
> >   work.  Eeschema gives the 'Info' pop-up -- "Could not use OpenGL,
> falling
> >   back to software rendering".  The 'see details' twisty just gives
> "Unknown
> >   Error".
> >
> >   I built wxWidgets (wxGTK3+ Slackware package) with configure's
> >   '--with-opengl' switch.  My hardware has not changed -- a very
> ordinary
> >   graphics adapter (Intel Desktop board on-board graphics).
> >
> >   I built KiCad with 'cmake -DCMAKE_BUILD_TYPE=Debug' so can
> investigate
> >   with gdb if needed.
> >
> >   Could you give me any tips on what might be wrong and where to
> look?
> >
> >   Thanks again
> >
> >   Tom Crane
> >
> >   On Thu, 8 Oct 2020, Ian McInerney wrote:
> >
> >   > The build has failed because it appears that your version of
> wxPython/Phoenix is using wxWidgets 3.1.5 and you are trying to use
> wxWidgets 3.1.4 in the main KiCad build. Those two versions must be the
> same in order for KiCad to build properly
> >   (otherwise there
> >   > will be issues with linking).
> >   > The compiler flag tests have no impact on this, they are in the
> log just because your GCC version doesn't support them so we aren't
> enabling them.
> >   >
> >   > -Ian
> >   >
> >   > On Thu, Oct 8, 2020 at 4:38 PM Tom Crane <
> tpcki...@mklab.ph.rhul.ac.uk> wrote:
> >   >   I am having no success despite having been able to do this
> in the past.
> >   >
> >   >   Previously I was able to build for gtk2+ with Python2.
> Now trying this fails at runtime with eg. "(eeschema:6730): Gtk-ERROR **:
> 15:29:43.689: GTK+ 2.x symbols detected.  Using GTK+ 2.x and GTK+ 3 in the
> same process is not supported".
> >   According
> >   >   to https://forum.kicad.info/t/gtk-2-to-3-issues/24856/2
> GTK2 isn't able to be used any more.
> >   >
> >   >   Instead (my preference anyway) I am now trying to build
> against gtk3+ and
> >   >   Python3.
> >   >
> >   >   I get this error,
> >   >
> >   >   # cmake -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
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON ../
> >   >   -- KiCad install dir: 
> >   >   -- Enabling warning -Wsuggest-override
> >   >   -- Enabling warning -Wduplicated-branches
> >   >   -- Enabling warning -Wduplicated-cond
> >   >

Re: [Kicad-developers] Attempting to build kicad-git source on Slackware-current Linux

[Ian McInerney]

The OpenGL failing is because wxWidgets has defaulted to an EGL backend
instead of GLX and I haven't pushed the needed changes in our code to work
around it yet. For now, you need to add the --disable-glcanvasegl option to
the wxWidgets configure line.

-Ian

On Mon, Oct 12, 2020 at 3:20 AM Tom Crane 
wrote:

> Thanks for the clarification -- and to all who follow-ed up.  That was the
> information I needed.  Now using Phoenix 4.1.1a1/gtk3 (wxWidgets 3.1.5)
> from git to build both wxPython4 and wxWidgets (wxGTK3+ Slackware package)
> I was able to build KiCad from git.
>
> Thankfully I don't get the segfaults I had with the previous build (using
> GTK2+ and Python2).
>
> The one new problem I have is that the accelerated graphics no longer
> work.  Eeschema gives the 'Info' pop-up -- "Could not use OpenGL, falling
> back to software rendering".  The 'see details' twisty just gives "Unknown
> Error".
>
> I built wxWidgets (wxGTK3+ Slackware package) with configure's
> '--with-opengl' switch.  My hardware has not changed -- a very ordinary
> graphics adapter (Intel Desktop board on-board graphics).
>
> I built KiCad with 'cmake -DCMAKE_BUILD_TYPE=Debug' so can investigate
> with gdb if needed.
>
> Could you give me any tips on what might be wrong and where to look?
>
> Thanks again
>
> Tom Crane
>
> On Thu, 8 Oct 2020, Ian McInerney wrote:
>
> > The build has failed because it appears that your version of
> wxPython/Phoenix is using wxWidgets 3.1.5 and you are trying to use
> wxWidgets 3.1.4 in the main KiCad build. Those two versions must be the
> same in order for KiCad to build properly (otherwise there
> > will be issues with linking).
> > The compiler flag tests have no impact on this, they are in the log just
> because your GCC version doesn't support them so we aren't enabling them.
> >
> > -Ian
> >
> > On Thu, Oct 8, 2020 at 4:38 PM Tom Crane 
> wrote:
> >   I am having no success despite having been able to do this in the
> past.
> >
> >   Previously I was able to build for gtk2+ with Python2.  Now trying
> this fails at runtime with eg. "(eeschema:6730): Gtk-ERROR **:
> 15:29:43.689: GTK+ 2.x symbols detected.  Using GTK+ 2.x and GTK+ 3 in the
> same process is not supported".  According
> >   to https://forum.kicad.info/t/gtk-2-to-3-issues/24856/2 GTK2
> isn't able to be used any more.
> >
> >   Instead (my preference anyway) I am now trying to build against
> gtk3+ and
> >   Python3.
> >
> >   I get this error,
> >
> >   # cmake -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
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON ../
> >   -- KiCad install dir: 
> >   -- Enabling warning -Wsuggest-override
> >   -- Enabling warning -Wduplicated-branches
> >   -- Enabling warning -Wduplicated-cond
> >   -- Enabling error for -Wvla
> >   -- Enabling warning -Wimplicit-fallthrough
> >   -- Enabling error for -Wreturn-type
> >   -- Enabling warning -Wshadow
> >   -- Enabling warning -Wsign-compare
> >   -- Enabling warning -Wmissing-field-initializers
> >   -- Enabling warning -Wempty-body
> >   -- Enabling warning -Wreorder
> >   -- Check for installed GLEW -- found
> >   -- Check for installed ZLIB -- found
> >   -- Check for installed Python Interpreter -- found
> >   -- Python module install path: lib64/python3.8/site-packages
> >   -- Found Phoenix 4.1.1a1/gtk3 (wxWidgets 3.1.5)
> >   CMake Error at
> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165
> (message):
> >  Could NOT find wxWidgets: Found unsuitable version "3.1.4", but
> required is  at least "3.1.5" (found
> >
> >
>  
> -L/usr/lib64/gtk3;-pthread;;;-lwx_gtk3u_gl-3.1;-lwx_gtk3u_aui-3.1;-lwx_gtk3u_html-3.1;-lwx_gtk3u_core-3.1;-lwx_baseu_net-3.1;-lwx_baseu-3.1;-lwx_gtk3u_propgrid-3.1;-lwx_baseu_xml-3.1;-lwx_gtk3u_stc-3.1)
> >   Call Stack (most recent call first):
> >
>  /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:456
> >   (_FPHSA_FAILURE_MESSAGE)
> >  CMakeModules/FindwxWidgets.cmake:1014
> >   (find_package_handle_standard_args)
> >  CMakeLists.txt:808 (find_package)
> >
> >
> >   -- Configuring incomplete, errors occurred!
> >   See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeOutput.log".
> >   See also "/tmp/SBo/kic

Re: [Kicad-developers] Attempting to build kicad-git source on Slackware-current Linux

[Ian McInerney]

The build has failed because it appears that your version of
wxPython/Phoenix is using wxWidgets 3.1.5 and you are trying to use
wxWidgets 3.1.4 in the main KiCad build. Those two versions must be the
same in order for KiCad to build properly (otherwise there will be issues
with linking).

The compiler flag tests have no impact on this, they are in the log just
because your GCC version doesn't support them so we aren't enabling them.

-Ian

On Thu, Oct 8, 2020 at 4:38 PM Tom Crane 
wrote:

> I am having no success despite having been able to do this in the past.
>
> Previously I was able to build for gtk2+ with Python2.  Now trying this
> fails at runtime with eg. "(eeschema:6730): Gtk-ERROR **: 15:29:43.689:
> GTK+ 2.x symbols detected.  Using GTK+ 2.x and GTK+ 3 in the same process
> is not supported".  According to
> https://forum.kicad.info/t/gtk-2-to-3-issues/24856/2 GTK2 isn't able to
> be used any more.
>
> Instead (my preference anyway) I am now trying to build against gtk3+ and
> Python3.
>
> I get this error,
>
> # cmake -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
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON ../
> -- KiCad install dir: 
> -- Enabling warning -Wsuggest-override
> -- Enabling warning -Wduplicated-branches
> -- Enabling warning -Wduplicated-cond
> -- Enabling error for -Wvla
> -- Enabling warning -Wimplicit-fallthrough
> -- Enabling error for -Wreturn-type
> -- Enabling warning -Wshadow
> -- Enabling warning -Wsign-compare
> -- Enabling warning -Wmissing-field-initializers
> -- Enabling warning -Wempty-body
> -- Enabling warning -Wreorder
> -- Check for installed GLEW -- found
> -- Check for installed ZLIB -- found
> -- Check for installed Python Interpreter -- found
> -- Python module install path: lib64/python3.8/site-packages
> -- Found Phoenix 4.1.1a1/gtk3 (wxWidgets 3.1.5)
> CMake Error at
> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165
> (message):
>Could NOT find wxWidgets: Found unsuitable version "3.1.4", but
> required is  at least "3.1.5" (found
>
>
> -L/usr/lib64/gtk3;-pthread;;;-lwx_gtk3u_gl-3.1;-lwx_gtk3u_aui-3.1;-lwx_gtk3u_html-3.1;-lwx_gtk3u_core-3.1;-lwx_baseu_net-3.1;-lwx_baseu-3.1;-lwx_gtk3u_propgrid-3.1;-lwx_baseu_xml-3.1;-lwx_gtk3u_stc-3.1)
> Call Stack (most recent call first):
>/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:456
> (_FPHSA_FAILURE_MESSAGE)
>CMakeModules/FindwxWidgets.cmake:1014
> (find_package_handle_standard_args)
>CMakeLists.txt:808 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
> See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeOutput.log".
> See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeError.log".
>
>
> CMakeError.log shows the test compilations failing with these three errors,
> c++: error: unrecognized command line option
> '-Winconsistent-missing-override'
> c++: error: unrecognized command line option '-Wmismatched-tags'
> c++: error: unrecognized command line option
> '-Wimplicit-int-float-conversion'
>
> BTW I am using GCC 9.3.0.
>
> I built wxWidgets-3.1.4 using a slightly modified third party SlackBuilds
> script for the wxGTK3 package, which includes the following configure,
>
> ./configure \
>--prefix=/usr \
>--libdir=/usr/lib${LIBDIRSUFFIX}/gtk3 \
>--mandir=/usr/man \
>--docdir=/usr/doc/$PRGNAM-$VERSION \
>--localstatedir=/var \
>--sysconfdir=/etc \
>--disable-precomp-headers \
>--disable-stl \
>--enable-graphics_ctx \
>--enable-mediactrl \
>--enable-plugins \
>--enable-unicode \
>--with-gtk=3 \
>--with-opengl \
>--program-prefix= \
>--program-suffix= \
>--build=$TARGET
>
> It includes the '--with-opengl' option as required by Kicad at
>
> https://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html
> .
>
>
> Initially I built the SlackBuilds wxPython4 package which uses wxPython /
> Phoenix version 4.0.7.post2 and tried building Kicad with that.
>
> Then I tried the wxWidgets/Phoenix git source (reports as Merge branch
> 'sip-4.19.24').  The Kicad build log above was built against that.
>
>
> I am confused as to whether my Kicad build log failed due to compiler flag
> or package dependency problems...
>
>
> I also tried building the kicad-5.1.7 stable/release (with gtk2+,
> Python2).  That was successful but my current project's new format files
> (eg. .kicad_sch rather than .sch) means I cannot use kicad-5.1.7.
>
> My last successful build of kicad-git (i.e. from
> https://github.com/KiCad/kicad-source-mirror.git), used gtk2+ & Python2,
> has nasty bugs -- eg. segfaults when trying to switch between sheets in
> eeschema and is barely usable which is why I need to rebuild.
>
> I am stuck.  Please help!
>
> Thanks
> Tom Crane.
>
> --
> Tom Crane, Digital Electronics Engineer, Dept. Physics, Royal Holloway,
> University of 

Re: [Kicad-developers] 5.1.7 tagged.

[Ian McInerney]

Out of curiosity, which issues are preventing the 10.12-10.13 builds? Is it
the disappearance of OCE from homebrew?

-Ian

On Wed, Sep 30, 2020 at 2:47 PM Adam Wolf 
wrote:

> macOS is uploaded:
>
> https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.7-0-10_14.dmg
>
> I was unable to make a 10.12-10.13 build.  These were a little old at
> the start of the 5.1 series, and "are older than they've ever been and
> now they're even older." :) It is not necessarily impossible to create
> these builds, but it's not straightforward at all anymore.  I do not
> like having a different set of support at the end of the series than
> at the beginning, so if Wayne or someone says "Please go try some
> more!" I will, but at the same point, not spending more time than I
> already have on the 10.12 builds gives me more time for KiCad 6.
>
> We may need to adjust the wording on the download page because of this.
>
> Adam
>
> On Mon, Sep 28, 2020 at 3:47 PM Johannes Maibaum 
> wrote:
> >
> > Hi,
> >
> > flatpak on flathub will be ready a few hours after I press the button to
> > build them for the stable flathub branch, which will happen on the day I
> > see the announcement posted. Everything's set to go here.
> >
> >
> > Best,
> > Johannes
> >
> > Am Montag, den 28.09.2020, 08:53 -0500 schrieb Adam Wolf:
> > > Thanks!
> > >
> > > On Mon, Sep 28, 2020 at 8:47 AM Wayne Stambaugh 
> > > wrote:
> > > > Adam,
> > > >
> > > > No problem, I can hold off posting the announcement to the 30th
> > > > which
> > > > was the original plan.
> > > >
> > > > Cheers,
> > > >
> > > > Wayne
> > > >
> > > > On 9/28/2020 8:55 AM, Adam Wolf wrote:
> > > > > MacOS is going to be at least a day or two, but I should have it
> > > > > ready
> > > > > by the 30th.
> > > > >
> > > > > If it's alright with folks, could we hold off on the announcement
> > > > > until tomorrow at least?
> > > > >
> > > > > Adam
> > > > >
> > > > > On Mon, Sep 28, 2020 at 7:05 AM Wayne Stambaugh <
> > > > > stambau...@gmail.com> wrote:
> > > > > > Has the website download page been updated? If that's done, I
> > > > > > will
> > > > > > remove the draft tag from the release announcement today.
> > > > > >
> > > > > > On 9/26/2020 1:42 PM, Nick Østergaard wrote:
> > > > > > > Everything has been tagged, the windows build is ready.
> > > > > > >
> > > > > > > I think the macos build may be a bit delayed, but I think we
> > > > > > > can undraft
> > > > > > > the release announcement now anyways.
> > > > > > >
> > > > > > > On Sat, 26 Sep 2020 at 03:33, Christian Schlüter <
> > > > > > > chsch...@gmail.com
> > > > > > > > wrote:
> > > > > > >
> > > > > > > Libraries are
> > > > > > >
> > > > > > >
> > > > > > > https://github.com/KiCad/kicad-footprints/releases/tag/5.1.7
> > > > > > > https://github.com/KiCad/kicad-symbols/releases/tag/5.1.7
> > > > > > >
> > > > > > > https://github.com/KiCad/kicad-packages3D/releases/tag/5.1.7
> > > > > > >
> > > > > > > https://github.com/KiCad/kicad-templates/releases/tag/5.1.7
> > > > > > >
> > > > > > > Cheers,
> > > > > > > CS
> > > ___
> > > 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] ***UNCHECKED*** Re: Linux support for wxGLCanvas and Wayland/EGL

[Ian McInerney]

On Wed, Sep 30, 2020 at 2:53 PM Simon Richter 
wrote:

> Hi,
>
> On Wed, Sep 30, 2020 at 08:46:46AM -0400, Wayne Stambaugh wrote:
>
> > I'm fine with adding glew to the third party directory.  I'm assuming
> > that the plan would be to use cmake to determine if EGL support was
> > required and build glew accordingly.
>
> With the Debian Developer hat on: this needs an easily reachable OFF
> switch, because it makes packaging harder if projects ship outdated
> components as part of their source tree.
>

It is going behind *2* CMake flags - the first one is `KICAD_USE_EGL` which
will default to OFF and require the flag to be passed into CMake directly
to enable it. This flag will only have effect on Linux. Without this flag
set to ON, it will always use the system GLEW and there is no way around
that. The second is `KICAD_USE_BUNDLED_GLEW`. This will be dependent upon
the `KICAD_USE_EGL` flag, and will have absolutely no effect when
`KICAD_USE_EGL` is OFF (it will always use the system GLEW). When
`KICAD_USE_EGL` is ON this will default to ON and use the bundled GLEW, but
it can be switched off if the system can provide a proper GLEW compiled for
use with EGL (which no systems seem to be packaging).

There will be no auto-detection of EGL inside CMake because implementing
that detection is non-trivial and I don't have the time or motivation
to make it work - so it will always require developer interaction. I will
be adding `#error` macros into the code to flag-up the incompatibility if
we aren't compiled with `KICAD_USE_EGL` and wx is compiled with EGL.

-Ian
___
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] 3D-Viewer: limit scale to positive values?

[Ian McInerney]

The question then becomes, how do we want to do this. Should we remove the
(scale ) s-expr from newly saved footprints and replace it with a units
one? Or do we make this a UI-only change and have the UI compute the
scaling factors that are saved in the file.

-Ian

On Tue, Sep 29, 2020 at 7:02 PM Seth Hillbrand  wrote:

> I've never seen another package use VRML.  Everyone uses STEP.  I suspect
> if we were implementing this today, we would look at the tradeoff on
> support/benefit for VRML and limit ourselves to STEP as well.
>
> I like Ian's suggestion for unit options.
>
> -Seth
>
> On Tue, Sep 29, 2020 at 10:22 AM Jon Evans  wrote:
>
>> Do other EDA tools allow model scaling?  Altium doesn't even allow VRML
>> import in the first place.
>>
>> On Tue, Sep 29, 2020 at 1:10 PM Seth Hillbrand 
>> wrote:
>>
>>> Well, we've backed ourselves into a bit of a corner.  VRML is specified
>>> in meters, so if we're assuming inches, we're a bit off in left field.  But
>>> do we need three separate scale parameters?  We could reduce to 1, correct?
>>>
>>> In the official footprint library, we have 7 footprints that specify
>>> non-unity scaling. (Banana_Jack_[1-3], NS-Tech_Grove_1x04, Fuse_Blade_ATO,
>>> Fuse_Blad_Mini, Oscillator_SMD_TXC0_G158).
>>>
>>> -Seth
>>>
>>>
>>>
>>>
>>> On Tue, Sep 29, 2020 at 9:30 AM Ian McInerney 
>>> wrote:
>>>
>>>> We can't remove the scaling option until we make the VRML importer
>>>> handle proper unit selection. I have routinely run into the case where I go
>>>> OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
>>>> because it makes for easier computations (all the datasheet values are
>>>> nicely given in mm) and then have to apply a scaling factor of 0.3937 to
>>>> all the axes in KiCad to make it the proper size because we seem to have a
>>>> hardcoded assumption about what unit system the VRML file is in.
>>>>
>>>> In fact, the KLC says: WRL files do not specify absolute dimensions.
>>>> KiCad normalizes model parameters to units of inches and the internal units
>>>> (dimensionless) of the WRL model must be scaled accordingly.
>>>>
>>>> -Ian
>>>>
>>>> On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand 
>>>> wrote:
>>>>
>>>>> There has been some discussion to removing the scale option here
>>>>> altogether.  The logic being that if you need the model scaled, you should
>>>>> be doing this in your solid CAD not in your electronic CAD.  I have come
>>>>> around to this idea and it might be worth implementing rather than doing
>>>>> the scale limiting.
>>>>>
>>>>> -Seth
>>>>>
>>>>> On Tue, Sep 29, 2020 at 4:52 AM Mário Luzeiro  wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm wondering if it is safe to limit the scale of shapes to be
>>>>>> positive values?
>>>>>>
>>>>>> Applying negative scales will cause inverted shapes and render issues
>>>>>> on the models.
>>>>>>
>>>>>> Could be that anyone in the world is using negative scale values?
>>>>>> or should be safe to limit it?
>>>>>>
>>>>>> This is related with this issues:
>>>>>> https://gitlab.com/kicad/code/kicad/-/issues/5817
>>>>>>
>>>>>> Mario
>>>>>> ___
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: KiCad Services Corporation Logo]
>>>>> Seth Hillbrand
>>>>> *Lead Developer*
>>>>> +1-530-302-5483‬ <+12126039372>
>>>>> Davis, CA
>>>>> www.kipro-pcb.comi...@kipro-pcb.com
>>>>> ___
>>>>> 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
>>>>>
>>>>
>>>
>>> --
>>> [image: KiCad Services Corporation Logo]
>>> Seth Hillbrand
>>> *Lead Developer*
>>> +1-530-302-5483‬ <+12126039372>
>>> Davis, CA
>>> www.kipro-pcb.comi...@kipro-pcb.com
>>> ___
>>> 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
>>>
>>
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
>
___
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] 3D-Viewer: limit scale to positive values?

[Ian McInerney]

I am all for removing scaling completely on STEP models - those should be
properly defined. I'm not sure the history of why VRML was chosen as the
first model type that was supported, but we shouldn't remove it since it is
used primarily in the 3D viewer to get better renders.

We can probably go down to 1 scaling input for VRML models, but why not
just turn it into a "VRML Units" selection and provide a list of the common
units and compute the scaling factor from that? That should be the only use
case when scaling VRML is needed.

-Ian

On Tue, Sep 29, 2020 at 6:22 PM Jon Evans  wrote:

> Do other EDA tools allow model scaling?  Altium doesn't even allow VRML
> import in the first place.
>
> On Tue, Sep 29, 2020 at 1:10 PM Seth Hillbrand  wrote:
>
>> Well, we've backed ourselves into a bit of a corner.  VRML is specified
>> in meters, so if we're assuming inches, we're a bit off in left field.  But
>> do we need three separate scale parameters?  We could reduce to 1, correct?
>>
>> In the official footprint library, we have 7 footprints that specify
>> non-unity scaling. (Banana_Jack_[1-3], NS-Tech_Grove_1x04, Fuse_Blade_ATO,
>> Fuse_Blad_Mini, Oscillator_SMD_TXC0_G158).
>>
>> -Seth
>>
>>
>>
>>
>> On Tue, Sep 29, 2020 at 9:30 AM Ian McInerney 
>> wrote:
>>
>>> We can't remove the scaling option until we make the VRML importer
>>> handle proper unit selection. I have routinely run into the case where I go
>>> OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
>>> because it makes for easier computations (all the datasheet values are
>>> nicely given in mm) and then have to apply a scaling factor of 0.3937 to
>>> all the axes in KiCad to make it the proper size because we seem to have a
>>> hardcoded assumption about what unit system the VRML file is in.
>>>
>>> In fact, the KLC says: WRL files do not specify absolute dimensions.
>>> KiCad normalizes model parameters to units of inches and the internal units
>>> (dimensionless) of the WRL model must be scaled accordingly.
>>>
>>> -Ian
>>>
>>> On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand 
>>> wrote:
>>>
>>>> There has been some discussion to removing the scale option here
>>>> altogether.  The logic being that if you need the model scaled, you should
>>>> be doing this in your solid CAD not in your electronic CAD.  I have come
>>>> around to this idea and it might be worth implementing rather than doing
>>>> the scale limiting.
>>>>
>>>> -Seth
>>>>
>>>> On Tue, Sep 29, 2020 at 4:52 AM Mário Luzeiro  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm wondering if it is safe to limit the scale of shapes to be
>>>>> positive values?
>>>>>
>>>>> Applying negative scales will cause inverted shapes and render issues
>>>>> on the models.
>>>>>
>>>>> Could be that anyone in the world is using negative scale values?
>>>>> or should be safe to limit it?
>>>>>
>>>>> This is related with this issues:
>>>>> https://gitlab.com/kicad/code/kicad/-/issues/5817
>>>>>
>>>>> Mario
>>>>> ___
>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: KiCad Services Corporation Logo]
>>>> Seth Hillbrand
>>>> *Lead Developer*
>>>> +1-530-302-5483‬ <+12126039372>
>>>> Davis, CA
>>>> www.kipro-pcb.comi...@kipro-pcb.com
>>>> ___
>>>> 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
>>>>
>>>
>>
>> --
>> [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ <+12126039372>
>> Davis, CA
>> www.kipro-pcb.comi...@kipro-pcb.com
>> ___
>> 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] 3D-Viewer: limit scale to positive values?

[Ian McInerney]

We can't remove the scaling option until we make the VRML importer handle
proper unit selection. I have routinely run into the case where I go
OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
because it makes for easier computations (all the datasheet values are
nicely given in mm) and then have to apply a scaling factor of 0.3937 to
all the axes in KiCad to make it the proper size because we seem to have a
hardcoded assumption about what unit system the VRML file is in.

In fact, the KLC says: WRL files do not specify absolute dimensions. KiCad
normalizes model parameters to units of inches and the internal units
(dimensionless) of the WRL model must be scaled accordingly.

-Ian

On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand  wrote:

> There has been some discussion to removing the scale option here
> altogether.  The logic being that if you need the model scaled, you should
> be doing this in your solid CAD not in your electronic CAD.  I have come
> around to this idea and it might be worth implementing rather than doing
> the scale limiting.
>
> -Seth
>
> On Tue, Sep 29, 2020 at 4:52 AM Mário Luzeiro  wrote:
>
>> Hi all,
>>
>> I'm wondering if it is safe to limit the scale of shapes to be positive
>> values?
>>
>> Applying negative scales will cause inverted shapes and render issues on
>> the models.
>>
>> Could be that anyone in the world is using negative scale values?
>> or should be safe to limit it?
>>
>> This is related with this issues:
>> https://gitlab.com/kicad/code/kicad/-/issues/5817
>>
>> Mario
>> ___
>> 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
>>
>
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> ___
> 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] Back Annotate - Ignore Other Projects

[Ian McInerney]

Thanks for checking. I will remove that option from the UI tonight then.

-Ian

On Tue, Sep 29, 2020 at 12:35 PM Alexander Shuklin 
wrote:

> Hi,
> I just checked the sheet shared across 2 projects. Thanks to the new
> schematic format, it works fine. It looks like you don't need this
> checkbox. The reason why this option was created doesn't exist anymore.
>
> On Tue, 29 Sep 2020 at 00:00, Jeff Young  wrote:
>
>> I think this is no longer used.  If memory serves, it was used in
>> multi-part warnings.  (Now that we can independently back-annotate parts it
>> no longer applies.)
>>
>> But someone should probably do a cursory poke around to see if that
>> memory matches reality….
>>
>> On 28 Sep 2020, at 19:58, jasura...@gmail.com wrote:
>>
>> Hi Ian,
>> Sorry I write from phone. I can tell you what logic was from very
>> beginning. In old schematic version it was possible to re-use schematic
>> from the other projects(for example you have 2 projects in one folder and
>> each of them use same schematic sheet).
>> I'm not sure what happens next, I haven't look into the code after my old
>> commits. May be something changed with new schematic format and now it
>> really does nothing. I'm away from pc and cannot check it now.
>> I hope it helps.
>>
>> 28 сентября 2020 г. 20:04:27 GMT+03:00, Ian McInerney <
>> ian.s.mciner...@ieee.org> пишет:
>>>
>>> What is the option to "Ignore other projects" supposed to be used for in
>>> the back annotation system? Right now it appears that it isn't connected to
>>> anything outside the UI because I am getting an unused variable warning on
>>> it:
>>>
>>> [1257/1983] Building CXX object
>>> eeschema/CMakeFiles/eeschema_kiface_objects.dir/tools/backannotate.cpp.o
>>> In file included from ../../eeschema/tools/backannotate.cpp:26:
>>> ../../eeschema/./tools/backannotate.h:112:34: warning: private field
>>> 'm_ignoreOtherProjects' is not used [-Wunused-private-field]
>>> bool m_ignoreOtherProjects;
>>>  ^
>>> 1 warning generated.
>>>
>>> -Ian
>>>
>>
>> --
>> Простите за краткость, создано в K-9 Mail.
>> ___
>> 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] Linux support for wxGLCanvas and Wayland/EGL

[Ian McInerney]

The upcoming wxWidgets 3.1.5 release has added a new backend supporting
Wayland/EGL to the wxGLCanvas that we use for displaying the OpenGL drawing
canvas. This backend appears to be the new default backend for wxGTK unless
it is explicitly disabled on the wxWidgets configure step (you
pass --disable-glcanvasegl to the configure script). It is also not
currently possible to change this backend at runtime. This means that we
will be forced to use whatever the distro-defaults are for the canvas
backend once wx 3.1/3.2 is being used in the wild.

I was just working with it some, and our main bottleneck for supporting it
natively is currently the GLEW dependency we have in our rendering code.
GLEW requires a compile-time selection of either X11 or EGL backends, and
all distributions seem to only ship a library built for the X11 backend.

I have done some experimenting, and building a version of GLEW that is
meant for EGL is fairly simple and uses a single C file and the public
headers. It can be compiled into a static library that we then link into
our code, so we don't actually need to bundle a shared library. My thinking
currently is that we provide these GLEW files in the thirdparty directory,
and only use them if a specific compile-time option to use EGL is provided.
That will mean that linux packaging will still use distro-provided GLEW
libraries when using the X11 backend, and if the distro can supply an
EGL-capable GLEW version we can try to use that (I am not sure how the
distros will manage this though).

-Ian
___
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] Back Annotate - Ignore Other Projects

[Ian McInerney]

What is the option to "Ignore other projects" supposed to be used for in
the back annotation system? Right now it appears that it isn't connected to
anything outside the UI because I am getting an unused variable warning on
it:

[1257/1983] Building CXX object
eeschema/CMakeFiles/eeschema_kiface_objects.dir/tools/backannotate.cpp.o
In file included from ../../eeschema/tools/backannotate.cpp:26:
../../eeschema/./tools/backannotate.h:112:34: warning: private field
'm_ignoreOtherProjects' is not used [-Wunused-private-field]
bool m_ignoreOtherProjects;
 ^
1 warning generated.

-Ian
___
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] eeschema unusable for two or three days

[Ian McInerney]

It is better to post these types of issue to the issue tracer rather than
the developer list so that they can be properly tracked and addressed.

-Ian

On Sat, Sep 12, 2020 at 12:00 PM BERTRAND Joël 
wrote:

> Hello,
>
> I'm using kicad 5.99 (built from sources on a Linux workstation) :
>
> Version: (5.99.0-3320-g30a428677), release build
> Libraries:
> wxWidgets 3.0.5
> libcurl/7.72.0 GnuTLS/3.6.14 zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0
> libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.8.0 nghttp2/1.41.0 librtmp/2.3
> Platform: Linux 5.7.0-2-amd64 x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> Date: Sep 12 2020 09:39:20
> wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
> Boost: 1.71.0
> OCC: 7.4.0
> Curl: 7.72.0
> ngspice: 29
> Compiler: GCC 10.2.0 with C++ ABI 1014
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCC=ON
> KICAD_SPICE=ON
>
> Recently, I have seen that wire tool in eeschema is unusable.
> Start and
> end point of wires are automatically connected to objects (other lines,
> other wires...). I haven't found any option in configuration to adjust
> this new functionnality. The only way around the problem is to have a
> very high zoom level. Is it possible to return to the previous state?
>
> Best regards,
>
> JKB
>
>
>
> ___
> 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] Evaluating cross-selection between the 3D-Viewer and Pcbnew

[Ian McInerney]

The 3d viewer does have access to the kiway, but I really think we need to
think about how this is done before we just go adding a cross-probing
interface between pcbnew and the 3d viewer. As our kiway is written
currently, adding the cross-probing will basically be adding a brand-new
messaging protocol between those two frames - and I would like for us to
avoid adding a new cross-probing specification when we already have two in
existence (the pcbnew <-> eeschema one and eeschema <-> simulator) that
both are different.

Jon, Seth and I had been discussing the future of the kiway off and on for
the last few months, and I think we are going to propose upgrading the
kiway to be a more structured interface (possibly using something like
JSON-RPC, but that hasn't been spec'd yet and I don't want to start the
discussion at this moment) with every frame listening on a local port for
the messages (instead of the current wx-event system relying on passing
strings/objects in memory) for v7. The thinking is then we define a
"cross-probe" command in the new RPC system that will be sent over the
kiway and all frames receive it and act on it if they want (so then you can
select a module in pcbnew and it will send a single cross-probe request
that can be ingested by both eeschema and the 3d-viewer instead of having
to send two different requests in possibly two different formats).

I don't think Seth, Jon or I will have much time in the next month to write
up a spec on this new interface yet since we all have work to do before
feature freeze. But I think this can definitely be something we ensure is
inside the kiway spec so it will be implementable in v7.

The part I have never been sure of is how the actual 3d-viewer parts would
be implemented, because it is not obvious to me if there is a nice way to
show the selection in the rendering, or if we can get user-input to select
models in the 3d viewer and then cross-probe them back to the board in our
system. This is something that is possible in the OpenCascade viewer system
though, so we might be able to add similar functionality to ours.

-Ian

On Wed, Sep 2, 2020 at 2:04 PM Wayne Stambaugh  wrote:

> It's part of the kiway mail messaging system.  Take a look at the
> kiway*.{h/cpp} files.  I'm not sure if the 3D viewer is derived from
> KIWAY_PLAYER.  If it is, this should be fairly straight forward assuming
> you can figure out the component position from the model geometry and
> translate that back to the board position.  If not, you will have a lot
> more work to do.  I do no want to add another messaging protocol to the
> board editor.
>
> On 9/1/20 6:15 PM, Mário Luzeiro wrote:
> > Hello all,
> >
> > I'm evaluating how/ if it will be possible to implement some kind of
> cross footprint selection between the 3D-Viewer and Pcbnew.
> > I know that it works with Schematic and Board so I believe there are
> already some existent mechanisms.. but I don't know what exists in KiCad
> source-code for that.
> >
> > Could someone point me where can I find relevant code that is already
> used or implemented for this purpose?
> >
> > I have the following questions do clarify:
> > - Can I notify 3D-Viewer to update the render from pcbnew/eeschema?
> > - How can I flag/or select a footprint and notify pcbnew/eeschema?
> > - Does a footprint has a flag that says it is selected? or there is some
> other list of selected footprints?
> >
> > Any other concerns or things that I should have a look?
> >
> > Regards,
> > Mario Luzeiro
> >
> > ___
> > 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] New dependency in docker image - tigervnc - xvfb

[Ian McInerney]

I have added xvfb to the docker images used for CI (both the Fedora 31
image and Ubuntu 18.04 image).

-Ian

On Fri, Aug 28, 2020 at 8:36 PM Sylwester Kocjan  wrote:

> Hi again,
>
>
> On 23/08/2020 02:12, Ian McInerney wrote:
>
> Are you wanting to add new QA tests that need a window to the main unit
> test suite?
>
> Yes, that's correct.
>
> On 23/08/2020 01:28, Seth Hillbrand wrote:
>
> Could you explain further why you would need this in the official docker?
> Can you not specify your own docker for your tests?
>
> 1. Based on this great tutorial I made changes in qa tests which allow to
> use wxFrames in test suite.
>
> http://www.remy.org.uk/tech.php?tech=1407951209
>
> 2. I used these kind of tests with my development in following merge
> request (commit 3542e2da9b9 and later):
>
> https://gitlab.com/kicad/code/kicad/-/merge_requests/215
>
> 3. I want to add more of these tests, namely: I want to cover
> DIALOG_SIM_SETTINGS with tests and add new types of simulation in the
> future.
> 4. Sure I can install what I need on my own docker image, but I want to
> make it working with CI as well. Otherwise it makes no sense.
> 5. I was hoping that other developers can benefit from this change as
> well.
>
> On 23/08/2020 02:12, Ian McInerney wrote:
>
> If so, we should not use a VNC server to run them we should use xvfb to
> emulate an X server interface.
>
> Good point, this can be used as well, but xvfb is not available in
> official KiCad image. Can we consider adding it?
>
> I hope it's not a big deal. Are there any obstacles (maybe I'm not aware
> of something)?
>
> Best regards,
> Sylwester
>
>
> On 23/08/2020 02:12, Ian McInerney wrote:
>
> Are you wanting to add new QA tests that need a window to the main unit
> test suite? If so, we should not use a VNC server to run them we should use
> xvfb to emulate an X server interface.
>
> -Ian
>
> On Sat, Aug 22, 2020 at 11:31 PM Sylwester Kocjan  wrote:
>
>> Hello,
>>
>> Can I ask for updating docker images with additional dependency,
>> according to attached patch?
>>
>> I was trying with running wx frames in qa test application and this
>> change will be helpful for me.
>>
>> Best regards,
>> Sylwester
>>
>> ___
>> 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] New dependency in docker image - tigervnc

[Ian McInerney]

Are you wanting to add new QA tests that need a window to the main unit
test suite? If so, we should not use a VNC server to run them we should use
xvfb to emulate an X server interface.

-Ian

On Sat, Aug 22, 2020 at 11:31 PM Sylwester Kocjan  wrote:

> Hello,
>
> Can I ask for updating docker images with additional dependency,
> according to attached patch?
>
> I was trying with running wx frames in qa test application and this
> change will be helpful for me.
>
> Best regards,
> Sylwester
>
> ___
> 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] running gerbview from local build on macOS

[Ian McInerney]

My solution was not to use anything other than the main kicad launcher ;).
So I never used standalone pcbnew/eeschema/gerbview/... on OSX. I did
figure out what it would take to fix the kiface detection issue, and
started https://gitlab.com/kicad/code/kicad/-/merge_requests/82 to try to
make it so everything will work from the build directory, but I haven't
gotten around to figuring out the Python pathing yet (that is the one that
is most troublesome for me now that I switched back to a Linux daily driver
machine - the kifaces just work for me now :) ).

-Ian

On Wed, Aug 19, 2020 at 10:39 AM Jeff Young  wrote:

> It’s a “thing” on OSX.  I run the attached script which fixes things up.
> Sadly it has to be run after each build.
>
> I know Jon has the same issue, but I haven’t heard about it from Ian.
> Perhaps he has a better solution….
>
> Cheers,
> Jeff.
>
>
>
> On 19 Aug 2020, at 10:32, Jonatan Liljedahl  wrote:
>
> I now tried deleting the old system-wide /Applications/KiCad, and now
> when clicking the gerbview button in project manager it gives the same
> error about not finding _gerbview.kiface
>
> On Wed, Aug 19, 2020 at 11:25 AM Jonatan Liljedahl 
> wrote:
>
>
> Hi! I'm having difficulties launching gerbview from my local build.
>
> I'm opening kicad.app like this, while standing in the build directory
> (/Users/lijon/Coding/kicad/build/master)
>
>open kicad/kicad.app
>
> ...which works fine. However, clicking the gerbview button in the
> project manager launches an old gerbview installed in systemwide
> /Applications/KiCad/
>
> Trying to open it manually by
>
>open gerbview/gerbview.app
>
> fails with "Failed to load kiface library
> “/Users/lijon/Coding/kicad/build/Contents/PlugIns/_gerbview.kiface”
> and then crashes.
>
> Same with:
>
>./gerbview/gerbview.app/Contents/MacOS/gerbview
>
> except now it tries to look in
> /Users/lijon/Coding/kicad/build/master/Contents/PlugIns/
>
> I've also tried to stand in the kicad.app directory and open it from
> there, but with similar results.
>
> Any ideas how to run a locally built gerbview on macOS?
>
> Cheers
> --
> /Jonatan
> http://kymatica.com
>
>
>
>
> --
> /Jonatan
> http://kymatica.com
>
> ___
> 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] Pcbnew - wxWidgets Debug Alerts on startup

[Ian McInerney]

Found the problem, it was an unintialized enum in the property system
(PCB_LAYER_T). I have just pushed a fix to master for it.

-Ian

On Tue, Aug 18, 2020 at 8:20 PM Ian McInerney 
wrote:

> I saw those when I opened up a windows build yesterday, but I haven't had
> time to dig into it (they appear to be windows only).
>
> -Ian
>
> On Tue, Aug 18, 2020 at 8:02 PM Jeff Young  wrote:
>
>> I don’t see them.
>>
>> Can you drop into a debugger and give us the stack trace for each one of
>> them?
>>
>> Thanks,
>> Jeff.
>>
>> On 18 Aug 2020, at 19:56, pjmo...@csi.com wrote:
>>
>> Is it just me or does anyone else get these "wxWidgets Debug Alert"
>> messages when starting up Pcbnew:
>>
>> -
>> C:/msys64/home/kicad-master/kicad/include/property.h(418): assert
>> "m_choices.GetCount() > 0" failed in PROPERTY_ENUM(): No enum choices
>> defined
>> Do you want to stop the program?
>> You can also choose [Cancel] to suppress further warnings.
>> -
>>
>> If you click "No" to continue, you get two more of them before Pcbnew
>> finally starts.  Clicking cancel on the first skips the other two.
>>
>> I've been seeing these for probably 3-4 weeks and assumed it would be
>> found and fixed long ago.  However, since the glitch still shows up even
>> in the 96f4e8f6f877a4a13ac7 commit from 8/17/2020, I'd like to know if
>> anyone else is seeing this?
>> ___
>> 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] Pcbnew - wxWidgets Debug Alerts on startup

[Ian McInerney]

I saw those when I opened up a windows build yesterday, but I haven't had
time to dig into it (they appear to be windows only).

-Ian

On Tue, Aug 18, 2020 at 8:02 PM Jeff Young  wrote:

> I don’t see them.
>
> Can you drop into a debugger and give us the stack trace for each one of
> them?
>
> Thanks,
> Jeff.
>
> On 18 Aug 2020, at 19:56, pjmo...@csi.com wrote:
>
> Is it just me or does anyone else get these "wxWidgets Debug Alert"
> messages when starting up Pcbnew:
>
> -
> C:/msys64/home/kicad-master/kicad/include/property.h(418): assert
> "m_choices.GetCount() > 0" failed in PROPERTY_ENUM(): No enum choices
> defined
> Do you want to stop the program?
> You can also choose [Cancel] to suppress further warnings.
> -
>
> If you click "No" to continue, you get two more of them before Pcbnew
> finally starts.  Clicking cancel on the first skips the other two.
>
> I've been seeing these for probably 3-4 weeks and assumed it would be
> found and fixed long ago.  However, since the glitch still shows up even
> in the 96f4e8f6f877a4a13ac7 commit from 8/17/2020, I'd like to know if
> anyone else is seeing this?
> ___
> 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] New Build Dependency

[Ian McInerney]

It will be `zlib`.

-Ian

On Mon, Aug 17, 2020 at 8:20 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:

> Hi Seth,
>
> Thanks for heads up. Any ideas what the new dependency might be called in
> VCPKG? Or if not available, could you let me know which CMAKE variable
> should I set to "OFF" in order to compile without the dependency?
>
> Thanks
>
> Roberto.
>
> On Mon, 17 Aug 2020 at 17:44, Seth Hillbrand  wrote:
>
>> I should have the MR ready today and I'll send along the branch info.
>>
>> Best-
>> Seth
>>
>> On Mon, Aug 17, 2020 at 9:38 AM Adam Wolf 
>> wrote:
>>
>>> I love the heads up! Thanks!
>>>
>>> Is there a sample branch I can try before it's merged into master?
>>>
>>> Adam
>>>
>>> On Mon, Aug 17, 2020 at 10:23 AM Seth Hillbrand 
>>> wrote:
>>>
 Hi Folks (Packagers especially)-

 We are adding a new build dependency to KiCad in the next few days.
 zlib1g-dev (on debian) will be required to support stream
 compression/decompression of model files.

 Please update your build environment to include this (if it doesn't
 already).  The critical file for KiCad is "zlib.h" in one of the standard
 include locations.  Let me know if you have any questions.

 Best-
 Seth

 --
 [image: KiCad Services Corporation Logo]
 Seth Hillbrand
 *Lead Developer*
 +1-530-302-5483‬ <+12126039372>
 Davis, CA
 www.kipro-pcb.comi...@kipro-pcb.com

>>>
>>
>> --
>> [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ <+12126039372>
>> Davis, CA
>> www.kipro-pcb.comi...@kipro-pcb.com
>> ___
>> 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] MSYS2 Dropping 32-bit support

[Ian McInerney]

On Tue, Aug 4, 2020 at 1:44 PM Mark Roszko  wrote:

> Been working on Phoenix, I basically have something working to build,
> though it'll be awhile before I have anything to share.
>
>
> However, here's the fun part:
> wxPhoenix 4.1.0 only works with wxWidgets 3.1.4 and above
> wxPhoenix 4.0.7 only works with wxWidgets 3.0.x series
>
> There's a fun gap with 3.1.0-3.1.3 :D Basically even with their fancy
> pancy dynamic generation system for most of their code. They hardcoded
> things specific references with no version checking fallback. Even the
> 4.0.x series may have some compatibility issues with wx 3.0.x depending on
> mix.
>
> wx is to blame too because wxWidgets 3.1.4 has API changes that
> really should have made it 3.2.  Hell, 3.1.4 appears to have enabled a
> newer C++ standard and the build is broken for MSVC until you patch it with
> master because Microsoft under some newer standard flags clamped down on
> STL export violations.
>
>
wxWidgets follows a "development series" version system - only the even
numbers are stable releases (e.g. 2.9, 3.0, 3.2, etc.), so anything in 3.1
is going to have API/ABI changes happening as they change the API and
stabilize it before the next stable release (the full list of changes from
3.0 to the current 3.1/future 3.2 is here
https://github.com/wxWidgets/wxWidgets/blob/master/docs/changes.txt). This
on its own isn't a problem, the real problem is that 3.1 has been in
development for a long time and hasn't been released as a stable release
yet.


> I have a PR update to vcpkg to go to 3.1.4 and patch it for MSVC.
> https://github.com/microsoft/vcpkg/pull/12733
>
>
>
> On Tue, Aug 4, 2020 at 7:41 AM Wayne Stambaugh 
> wrote:
>
>> On 8/3/20 9:19 PM, Seth Hillbrand wrote:
>> >
>> >
>> > On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh > > > wrote:
>> >
>> > I'm not ready to drop 32 bit builds for V6.  I still think there are
>> > enough 32-bit users to warrant supporting it for one more release.
>> It's
>> > something we can discuss for V7.
>> >
>> >
>> > If we keep 32 bit builds on mingw2, does that mean that we freeze all
>> > packages at their current versions?  It might be problematic to keep
>> > different package versions for different architectures.
>>
>> I'm assuming you mean dependency packages so yes we would continue to
>> build 32 bit windows versions using the current package versions.  If
>> someone figures out how to get wxPhoenix to build, then we could bump to
>> wxWidgets 3.1.x and Python 3.x.
>>
>> >
>> > Obviously, if we successfully move to MSVC, this question is moot.
>> >
>> > -Seth
>> >
>>
>> ___
>> 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
>>
>
>
> --
> Mark
> ___
> 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] New Build Dependencies: Lemon + GTK3

[Ian McInerney]

*sigh*... do it one way and people don't like it and then do it another way
and get more responses. I should just put it behind a
`KICAD_REGENERATE_LEMON_PARSER` flag that defaults to off to be done with
the damn thing. Then only people who actually want to regenerate the parser
grammars will need it.

The first lemon code was added in 2017, so the ship has sailed on this one.

-Ian

On Mon, Aug 3, 2020 at 8:01 PM Wayne Stambaugh  wrote:

> On 8/3/20 2:55 PM, Steven A. Falco wrote:
> > On 8/3/20 2:47 PM, Wayne Stambaugh wrote:
> >> On 8/3/20 2:42 PM, Steven A. Falco wrote:
> >>> On 8/3/20 2:37 PM, Wayne Stambaugh wrote:
> >>>> On 8/3/20 2:01 PM, Carsten Schoenert wrote:
> >>>>> Hello Ian,
> >>>>>
> >>>>> Am 03.08.20 um 19:39 schrieb Ian McInerney:
> >>>>>> I have now updated this so that we bundle the lemon parser code
> >>>>>> inside
> >>>>>> thirdparty and build it for ourselves (it is only 1 main c file that
> >>>>>> was released into the public domain). CMake then takes care of all
> >>>>>> the
> >>>>>> pathing for the template and executable file for the targets. This
> >>>>>> should work on all platforms now with no extra steps. It also means
> >>>>>> that there is no need to install lemon on dev computers anymore.
> >>>>>
> >>>>> unfortunately that is a typical thing how problems are getting
> >>>>> "solved",
> >>>>> simply embed the required third party code. From a security
> >>>>> perspective
> >>>>> this is mostly a nightmare as also typically nobody ever touches such
> >>>>> code again as it "works" for all times.
> >>>>> Please try to avoid this when *ever* possible and look for
> >>>>> alternatives.
> >>>>> For package maintainers a good alternative is to make the use of the
> >>>>> third party code optional. Means that a configure switch should be
> >>>>> available to so on the Linux side we can use the package versions.
> >>>>>
> >>>>> Embedded code is quite in no way traceable and make the work of
> >>>>> package
> >>>>> maintainers and of the security teams within Linux distribution even
> >>>>> more harder [1].
> >>>>>
> >>>>> So if not already the use of the lemon parser is configured in a way
> I
> >>>>> can chose to use a packaged version please consider to do so. Thank
> >>>>> you.
> >>>>>
> >>>>> [1] https://wiki.debian.org/EmbeddedCopies
> >>>>>
> >>>>
> >>>> I could not have said it better myself.  We now have programmed
> >>>> ourselves into a third party library maintenance issue.  In the
> future,
> >>>> all new dependencies should be run by the lead development team for
> >>>> discussion so we can plan how we want to handle them.
> >>>
> >>> What is the resolution?  Do I undo the dependency on the lemon parser
> >>> generator?  Or will there be a flag to select whether to generate or
> use
> >>> the canned one?
> >>>
> >>> I really don't like having this potentially work two different ways.
> >>> Then there could be bugs that only show up when using a newer lemon, or
> >>> that show up when using the pregenerated code.  It is best to have
> >>> exactly one way that this works.
> >>>
> >>>  Steve
> >>>
> >>
> >> Would the solution proposed in my last post be sufficient?
> >
> > It would avoid adding a flag, but you'd still have the potential problem
> > that different platforms could end up behaving differently, because some
> > are using an older (canned) parser, and some are using a newer
> > (generated) parser.  The risk in this instance is probably small, but as
> > a general principle, it is not good to have avoidable differences
> > between platforms.
> >
> > That said, I'll be happy to adapt to whatever the lead devs decide.
> >
> > Steve
> >
>
> I wasn't suggesting a flag.  I was suggesting that if CMake cannot find
> an acceptable version of lemon on the system during configuration, fall
> back to building lemon from source.
>
> ___
> 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] New Build Dependencies: Lemon + GTK3

[Ian McInerney]

I have now updated this so that we bundle the lemon parser code inside
thirdparty and build it for ourselves (it is only 1 main c file that was
released into the public domain). CMake then takes care of all the pathing
for the template and executable file for the targets. This should work on
all platforms now with no extra steps. It also means that there is no need
to install lemon on dev computers anymore.

-Ian

On Sun, Aug 2, 2020 at 11:46 PM Mark Roszko  wrote:

> LOL, "lemon" in VCPKG is not Lemon the grammar generator, it's Lemon the
> boost graph library.
>
> And lemon grammar itself, isn't a real library. It's a single C file. It's
> very unlikely to be accepted into vcpkg.
>
> We may as well just build it on the fly in kicad
> https://www.sqlite.org/src/file/tool/lemon.c
>
>
> On Sun, Aug 2, 2020 at 6:37 PM Mark Roszko  wrote:
>
>> MSVC support is a work in progress so it's not that its not supported,
>> it's just someone needs to fix it ;)
>>
>> On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista <
>> roberto.fer@gmail.com> wrote:
>>
>>> Just tried your branch and unfortunately couldn't get it to compile on
>>> Visual Studio (even after a "vcpkg install lemon:x64-windows" and "vcpkg
>>> integrate install")... I got the cmake error "lemon not found"
>>>
>>> I know Visual Studio isn't officially supported but any ideas what I
>>> could do to install lemon correctly so visual studio/ cmake can recognise
>>> it?
>>>
>>> Thanks
>>>
>>> Roberto
>>>
>>> On Sun, 2 Aug 2020 at 22:06, Ian McInerney 
>>> wrote:
>>>
>>>> Yes, I have a branch on my fork [1] called "im/lemon" that can be used.
>>>> It can be found here:
>>>> https://gitlab.com/imcinerney/kicad/-/tree/im/lemon. If the build
>>>> passes with that, it means lemon integration is working. CMake should error
>>>> during configuration if the lemon executable can't be found
>>>>
>>>> -Ian
>>>>
>>>> [1] https://gitlab.com/imcinerney/kicad
>>>>
>>>> On Sun, Aug 2, 2020 at 10:01 PM Adam Wolf <
>>>> adamw...@feelslikeburning.com> wrote:
>>>>
>>>>> Is there a branch packages can use to make sure their lemon
>>>>> integration is working?
>>>>>
>>>>> On Sun, Aug 2, 2020, 4:00 PM Ian McInerney 
>>>>> wrote:
>>>>>
>>>>>> Two new build-time dependencies are being added to the master branch
>>>>>> for v6:
>>>>>> * lemon - The lemon parser generator
>>>>>> * GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that
>>>>>> is not supported anymore). This is technically also a runtime dependency,
>>>>>> but we also need GTK3 for wxWidgets, so it shouldn't be a new runtime dep
>>>>>> (only needing the build headers are new).
>>>>>>
>>>>>> The lemon parser is needed to fix
>>>>>> https://gitlab.com/kicad/code/kicad/-/issues/5013 by changing how
>>>>>> the files are generated (in MR
>>>>>> https://gitlab.com/kicad/code/kicad/-/merge_requests/318). GTK3 is
>>>>>> needed to enable new functionality inside the platform-specific
>>>>>> KIPLATFORM library for Linux (such as overriding menu settings, moving
>>>>>> files to trash, etc.)
>>>>>>
>>>>>> All developers should make sure they have these new dependencies
>>>>>> installed, and nightly builds should add them to their build script 
>>>>>> (Steve,
>>>>>> thanks for updating Fedora's so quick!) I have opened issue on GitLab for
>>>>>> the builders on there:
>>>>>> https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/101
>>>>>> https://gitlab.com/kicad/packaging/kicad-mac-builder/-/issues/332
>>>>>>
>>>>>> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/issues/2
>>>>>>
>>>>>> I haven't merged any code into master that needs them yet, but I
>>>>>> would like to merge the lemon fix as soon as possible (the problem it is
>>>>>> solving has attracted increased attention it seems).
>>>>>>
>>>>>> -Ian
>>>>>> ___
>>>>>> 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
>>>
>>
>>
>> --
>> Mark
>>
>
>
> --
> Mark
>
___
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] New Build Dependencies: Lemon + GTK3

[Ian McInerney]

Do you know if is called "lemon.exe" and is on the path by default? If it
isn't on the path, then CMake might have difficulty finding it. You can try
passing "-DLEMON=" in the CMake command line and I believe it will
use that path instead of searching for it. Other than that, I might need
Jon to take a look at it since he has a MSVC setup currently I believe (but
we are relying on the built-in CMake FindLemon script, not our own).

-Ian

On Sun, Aug 2, 2020 at 11:06 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:

> Just tried your branch and unfortunately couldn't get it to compile on
> Visual Studio (even after a "vcpkg install lemon:x64-windows" and "vcpkg
> integrate install")... I got the cmake error "lemon not found"
>
> I know Visual Studio isn't officially supported but any ideas what I could
> do to install lemon correctly so visual studio/ cmake can recognise it?
>
> Thanks
>
> Roberto
>
> On Sun, 2 Aug 2020 at 22:06, Ian McInerney 
> wrote:
>
>> Yes, I have a branch on my fork [1] called "im/lemon" that can be used.
>> It can be found here: https://gitlab.com/imcinerney/kicad/-/tree/im/lemon.
>> If the build passes with that, it means lemon integration is working. CMake
>> should error during configuration if the lemon executable can't be found
>>
>> -Ian
>>
>> [1] https://gitlab.com/imcinerney/kicad
>>
>> On Sun, Aug 2, 2020 at 10:01 PM Adam Wolf 
>> wrote:
>>
>>> Is there a branch packages can use to make sure their lemon integration
>>> is working?
>>>
>>> On Sun, Aug 2, 2020, 4:00 PM Ian McInerney 
>>> wrote:
>>>
>>>> Two new build-time dependencies are being added to the master branch
>>>> for v6:
>>>> * lemon - The lemon parser generator
>>>> * GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that is
>>>> not supported anymore). This is technically also a runtime dependency, but
>>>> we also need GTK3 for wxWidgets, so it shouldn't be a new runtime dep (only
>>>> needing the build headers are new).
>>>>
>>>> The lemon parser is needed to fix
>>>> https://gitlab.com/kicad/code/kicad/-/issues/5013 by changing how the
>>>> files are generated (in MR
>>>> https://gitlab.com/kicad/code/kicad/-/merge_requests/318). GTK3 is
>>>> needed to enable new functionality inside the platform-specific
>>>> KIPLATFORM library for Linux (such as overriding menu settings, moving
>>>> files to trash, etc.)
>>>>
>>>> All developers should make sure they have these new dependencies
>>>> installed, and nightly builds should add them to their build script (Steve,
>>>> thanks for updating Fedora's so quick!) I have opened issue on GitLab for
>>>> the builders on there:
>>>> https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/101
>>>> https://gitlab.com/kicad/packaging/kicad-mac-builder/-/issues/332
>>>>
>>>> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/issues/2
>>>>
>>>> I haven't merged any code into master that needs them yet, but I would
>>>> like to merge the lemon fix as soon as possible (the problem it is solving
>>>> has attracted increased attention it seems).
>>>>
>>>> -Ian
>>>> ___
>>>> 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] New Build Dependencies: Lemon + GTK3

[Ian McInerney]

Yes, I have a branch on my fork [1] called "im/lemon" that can be used. It
can be found here: https://gitlab.com/imcinerney/kicad/-/tree/im/lemon. If
the build passes with that, it means lemon integration is working. CMake
should error during configuration if the lemon executable can't be found

-Ian

[1] https://gitlab.com/imcinerney/kicad

On Sun, Aug 2, 2020 at 10:01 PM Adam Wolf 
wrote:

> Is there a branch packages can use to make sure their lemon integration is
> working?
>
> On Sun, Aug 2, 2020, 4:00 PM Ian McInerney 
> wrote:
>
>> Two new build-time dependencies are being added to the master branch for
>> v6:
>> * lemon - The lemon parser generator
>> * GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that is
>> not supported anymore). This is technically also a runtime dependency, but
>> we also need GTK3 for wxWidgets, so it shouldn't be a new runtime dep (only
>> needing the build headers are new).
>>
>> The lemon parser is needed to fix
>> https://gitlab.com/kicad/code/kicad/-/issues/5013 by changing how the
>> files are generated (in MR
>> https://gitlab.com/kicad/code/kicad/-/merge_requests/318). GTK3 is
>> needed to enable new functionality inside the platform-specific
>> KIPLATFORM library for Linux (such as overriding menu settings, moving
>> files to trash, etc.)
>>
>> All developers should make sure they have these new dependencies
>> installed, and nightly builds should add them to their build script (Steve,
>> thanks for updating Fedora's so quick!) I have opened issue on GitLab for
>> the builders on there:
>> https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/101
>> https://gitlab.com/kicad/packaging/kicad-mac-builder/-/issues/332
>>
>> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/issues/2
>>
>> I haven't merged any code into master that needs them yet, but I would
>> like to merge the lemon fix as soon as possible (the problem it is solving
>> has attracted increased attention it seems).
>>
>> -Ian
>> ___
>> 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] New Build Dependencies: Lemon + GTK3

[Ian McInerney]

Two new build-time dependencies are being added to the master branch for v6:
* lemon - The lemon parser generator
* GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that is not
supported anymore). This is technically also a runtime dependency, but we
also need GTK3 for wxWidgets, so it shouldn't be a new runtime dep (only
needing the build headers are new).

The lemon parser is needed to fix
https://gitlab.com/kicad/code/kicad/-/issues/5013 by changing how the files
are generated (in MR
https://gitlab.com/kicad/code/kicad/-/merge_requests/318). GTK3 is needed
to enable new functionality inside the platform-specific KIPLATFORM library
for Linux (such as overriding menu settings, moving files to trash, etc.)

All developers should make sure they have these new dependencies installed,
and nightly builds should add them to their build script (Steve, thanks for
updating Fedora's so quick!) I have opened issue on GitLab for the builders
on there:
https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/101
https://gitlab.com/kicad/packaging/kicad-mac-builder/-/issues/332
https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/issues/2

I haven't merged any code into master that needs them yet, but I would like
to merge the lemon fix as soon as possible (the problem it is solving has
attracted increased attention it seems).

-Ian
___
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] Something wrong with Windows nightly builds (1 Aug)?

[Ian McInerney]

The builds will be flagged with dirty until I am able to merge the Lemon MR
that changes the build process to fix it.

-Ian

On Sun, 2 Aug 2020, 6:28 p.m. Mark Roszko,  wrote:

>   Nick has fixed the Windows nightlies, rejoice
>
> The builds are flagged dirty for what its worth.
>
> On Sat, Aug 1, 2020 at 9:04 AM Eeli Kaikkonen 
> wrote:
>
>> [image: image.png]
>>
>> Something wrong with the Windows nightly builds?
>>
>> The commit 0c77 is from 30 July, I remember seeing that same commit dated
>> to 30 and I downloaded it then (the link has different color) and I have it
>> installed, but now the date is 1 Aug. There seems to be no newer nightly
>> build available, I think there should be one or two of them.
>>
>> Eeli Kaikkonen
>> ___
>> 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
>>
>
>
> --
> Mark
> ___
> 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] MSYS2 Dropping 32-bit support

[Ian McInerney]

We'll have to figure out how to phrase the support requirements for this,
because we have committed to supporting Windows 8.1 until January 10, 2023
apparently - and 8.1 would have 32-bit versions.

-Ian

On Sun, Aug 2, 2020 at 4:58 AM Mark Roszko  wrote:

> I am working on a MSVC build chain slowly amongst my ADHD heh.
> Though I'm focusing on Win64 builds, Win32 would be trivial. It's just a
> measure of how much is it worth it. Microsoft has instituted a complete ban
> on 32-bit sales of new PCs a few months ago on their end so wiin32 is
> slowly moving towards life support status.
>
> On Sat, Aug 1, 2020 at 11:31 PM Seth Hillbrand  wrote:
>
>>
>> On Sat, Aug 1, 2020 at 7:31 PM Mark Roszko  wrote:
>>
>>> Ah right, as it stands, the only way to use a new install of msys2
>>> 32-bit now is to patch it on startup because the repo keys changed but they
>>> no longer update the 32-bit base package
>>>
>>> See: https://www.msys2.org/news/#2020-06-29-new-packagers
>>>
>>> But the package versions available on 32-bit are going to begin to
>>> diverge from the 64-bit builds
>>>
>>>
>>> There may need to be a decision made about continued 32-bit support for
>>> KiCad Windows.
>>>
>>>
>> Unless we push the Windows builds over to Visual Studio, this
>> announcement makes our decision for us.  V6 makes a natural transition
>> point for us, support-wise as well.
>>
>> -Seth
>>
>> --
>> [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ <+12126039372>
>> Davis, CA
>> www.kipro-pcb.comi...@kipro-pcb.com
>>
>
>
> --
> Mark
> ___
> 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] Something wrong with Windows nightly builds (1 Aug)?

[Ian McInerney]

No, it isn't a build error that is causing it. If you look at the status
page showing the pipeline results (
https://jenkins.simonrichter.eu/view/KiCad%20Status/job/windows-kicad-msys2-pipeline/),
you'll see the builds finish successfully.

Eeli, can you try downloading the most recent lite build and see which
version string is being reported by the program itself? I downloaded the
log from one of the runs on July 31, and it seems to have downloaded the
most recent commit as of that time and was supposed to have built a package
with "r16610.61c817377". Perhaps that is just contained in the most
recently uploaded package for some reason?

My guess is the packaging script can't handle the "-dirty" being appended
to the KiCad build string. It is being marked as dirty right now due to
https://gitlab.com/kicad/code/kicad/-/issues/5013, and the fix for it is in
https://gitlab.com/kicad/code/kicad/-/merge_requests/318, but I can't apply
the fix until all packaging setups are updated to contain lemon (so I now
know that Windows has it, but OSX and many Linux ones don't).

-Ian

On Sat, Aug 1, 2020 at 9:40 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:

> Hi Eeli,
>
> I assume this was due to what I highlighted in my previous email (
> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg38706.html).
> The build was broken for Windows.
>
> I submitted a merge request (
> https://gitlab.com/kicad/code/kicad/-/merge_requests/322) which was
> merged last night, hence you are only seeing it today.
>
> Thanks.
>
> Roberto.
>
>
> On Sat, 1 Aug 2020, 14:04 Eeli Kaikkonen, 
> wrote:
>
>> [image: image.png]
>>
>> Something wrong with the Windows nightly builds?
>>
>> The commit 0c77 is from 30 July, I remember seeing that same commit dated
>> to 30 and I downloaded it then (the link has different color) and I have it
>> installed, but now the date is 1 Aug. There seems to be no newer nightly
>> build available, I think there should be one or two of them.
>>
>> Eeli Kaikkonen
>> ___
>> 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] Lots of "note" messages regarding std::error_code, std::error_condition, std::ctype_base, etc.

[Ian McInerney]

You need to upgrade to GCC 10.2 to get rid of them - it was a bug with GCC.
I think 10.2 has landed in the Fedora stable repos now.

-Ian

On Thu, Jul 30, 2020 at 9:10 PM Steven A. Falco 
wrote:

> I'm running a build of the master branch on Fedora 32, and I'm seeing a
> lot of "note" messages mentioning std::error_code, std::error_condition,
> and a few others:
>
> /usr/include/c++/10/bits/locale_facets_nonio.h:1770:10: note:
> ‘std::messages_base’ defined as ‘struct’ here
> /usr/include/c++/10/bits/regex.h:80:12: note: ‘std::__cxx11::regex_traits<
>  >’ defined as ‘struct’ here
> /usr/include/c++/10/bits/valarray_array.h:396:12: note: ‘std::_Array<_Tp>’
> defined as ‘struct’ here
> /usr/include/c++/10/complex:1082:12: note: ‘std::complex’ defined
> as ‘struct’ here
> /usr/include/c++/10/complex:1227:12: note: ‘std::complex’ defined
> as ‘struct’ here
> /usr/include/c++/10/complex:127:12: note: ‘std::complex<_Tp>’ defined as
> ‘struct’ here
> /usr/include/c++/10/complex:1372:12: note: ‘std::complex’
> defined as ‘struct’ here
> /usr/include/c++/10/system_error:180:10: note: ‘std::error_code’ defined
> as ‘struct’ here
> /usr/include/c++/10/system_error:278:10: note: ‘std::error_condition’
> defined as ‘struct’ here
> /usr/include/c++/10/thread:338:12: note: ‘std::hash’
> defined as ‘struct’ here
> /usr/include/c++/10/x86_64-redhat-linux/bits/ctype_base.h:41:10: note:
> ‘std::ctype_base’ defined as ‘struct’ here
>
> The messages don't appear to hurt anything, but I thought folks might want
> to know about them, as they might be unique to Fedora.
>
> Here is the version info:
>
> Application: KiCad
>
> Version: (5.99.0-2487-g310613a94), debug build
>
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.69.1 OpenSSL/1.1.1g-fips zlib/1.2.11 brotli/1.0.7
> libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh/0.9.4/openssl/zlib
> nghttp2/1.41.0
>
> Platform: Linux 5.7.10-201.fc32.x86_64 x86_64, 64 bit, Little endian, wxGTK
>
> Build Info:
> Date: Jul 30 2020 15:23:56
> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+
> 3.24
> Boost: 1.69.0
> OCC: 7.4.0
> Curl: 7.69.1
> ngspice: 32
> Compiler: GCC 10.1.1 with C++ ABI 1014
>
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCC=ON
> KICAD_SPICE=ON
> KICAD_STDLIB_DEBUG=OFF
> KICAD_STDLIB_LIGHT_DEBUG=OFF
> KICAD_SANITIZE=OFF
>
> I've attached the full build log (gzipped since it is about 4 MB of text).
>
> 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] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Ian McInerney]

It was committed on July 3rd. I am not sure which commit is 100 behind the
current head though, and I really don't want to kill my build directory by
switching that far back to find out.

-Ian

On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh 
wrote:

> I'm running `git bisect` now from HEAD~100.  Is it further back that
> that?  Given that mingw debug builds are painfully slow, it's going to
> take a while.
>
> On 7/22/2020 6:17 PM, Ian McInerney wrote:
> > Try going right before c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
> > The errors that Brian showed at the beginning of the thread mention
> > NETCLASS* and shared_ptr stuff, and it looks like the last commit that
> > touched those Swig parts was from Jon on June 30th which moved that from
> > pcbnew to the common Swig directory. I am not sure how that could have
> > broken things, but I think it would be a good commit to start with and
> > see if it is the issue.
> >
> > -Ian
> >
> > On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
> > mailto:br...@documenteddesigns.com>>
> wrote:
> >
> > Perhaps what I can try and do is a binary search for the last
> "working"
> > master.
> >
> > I think that is within my abilities.
> >
> > On 2020-07-22 6:00 p.m., Jon Evans wrote:
> > > If you know a version that builds (you said late June worked) you
> can
> > > do a git bisect against a commit from back then and eventually this
> > > will tell you which commit changed the behavior
> > >
> > > On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
> > > mailto:br...@documenteddesigns.com>>
> > wrote:
> > >> You can't imagine how happy it makes me feel to know it isn't some
> > >> stupid little thing I did.
> > >>
> > >> I don't know how I can help though. I can try building a release
> > version
> > >> to confirm.
> > >>
> > >> On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:
> > >>> I've been playing around with this and there is definetly
> something
> > >>> amiss.  I don't get the build errors on release builds but I do
> > see them
> > >>> with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig
> from
> > >>> 4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch
> builds
> > >>> just fine so I suspect a recent change in the one of the CMake
> > config
> > >>> files is to blame.  I don't remember seeing any swig changes
> > recently.
> > >>>
> > >>> On 7/22/2020 9:30 AM, Brian Piccioni wrote:
> > >>>> Using this script
> > >>>>
> > >>>> cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
> > >>>> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
> > >>>> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
> > >>>> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad
> > >>>>
> > >>>> I get the same results
> > >>>>
> > >>>> [ 98%] Built target qa_eeschema
> > >>>>
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > >>>>
> >
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> > >>>> undefined reference to `.refptr.PyObject_GenericGetAttr'
> > >>>>
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > >>>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> > function
> > >>>> `std::invalid_argument::invalid_argument(std::invalid_argument
> > const&)':
> > >>>> C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> > reference
> > >>>> to `.refptr._ZTVSt16invalid_argument'
> > >>>>
> >
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> > >>>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> > function
> > >>>> `std::_Sp_counted_deleter > >>>> std::allocator,
> > >>>> (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info
> 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Ian McInerney]

w/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> >>>> make: *** [Makefile:161: all] Error 2
> >>>>
> >>>> bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> >>>>
> >>>> On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
> >>>>> Did you try to use the normal makefile generator rather than the
> >>>>> eclipse one?
> >>>>>
> >>>>> ons. 22. jul. 2020 01.37 skrev Brian Piccioni
> >>>>> mailto:br...@documenteddesigns.com>>:
> >>>>>
> >>>>>   FWIW, I re-cloned Kicad master into an empty directory,
> created a
> >>>>>   new build directory, ran the standard build script
> >>>>>
> >>>>>   cmake -DCMAKE_BUILD_TYPE=Debug \
> >>>>>   -G "Eclipse CDT4 - Unix Makefiles" \
> >>>>>   -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> >>>>>   -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> >>>>>   -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> >>>>>   -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
> >>>>>   -DMSYS=TRUE \
> >>>>>   ../kicad
> >>>>>
> >>>>>   and got the same errors
> >>>>>
> >>>>>Built target qa_eeschema
> >>>>>
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>>>
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> >>>>>   undefined reference to `.refptr.PyObject_GenericGetAttr'
> >>>>>
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>>>   CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> >>>>>   function
> >>>>>   `std::invalid_argument::invalid_argument(std::invalid_argument
> >>>>>   const&)':
> >>>>>   C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
> >>>>>   reference to `.refptr._ZTVSt16invalid_argument'
> >>>>>
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>>>   CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> >>>>>       function `std::_Sp_counted_deleter SWIG_null_deleter,
> >>>>>   std::allocator,
> >>>>>   (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info
> const&)':
> >>>>>
>  C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
> >>>>>   undefined reference to `typeinfo for SWIG_null_deleter'
> >>>>>
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>>>   CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
> >>>>>   function `swig::traits_from::from(KIID const&)':
> >>>>>
>  
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
> >>>>>   undefined reference to
> `swig::traits_from_ptr::from(KIID*, int)'
> >>>>>
>  
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> >>>>>
>  
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
> >>>>>   undefined reference to `typeinfo name for SWIG_null_deleter'
> >>>>>   collect2.exe: error: ld returned 1 exit status
> >>>>>   make[2]: ***
> [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
> >>>>>   pcbnew/_pcbnew.kiface] Error 1
> >>>>>   make[1]: *** [CMakeFiles/Makefile2:3284:
> >>>>>   pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> >>>>>   make: *** [Makefile:161: all] Error 2
> >>>>>
> >>>>>   bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> >>>>>   $
> >>>>>
> >>>>>
> >>>>>
> >>>>>   On 2020-07-21 2:54 p.m., Ian McInerney wrote:
> >>>>>>   Ignore all of those notes being printed by the compiler about
> >>>>>>

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Ian McInerney]

Ignore all of those notes being printed by the compiler about mismatched
struct/class definition. There is a bug in GCC 10.1 that isn't silencing
those properly, but that is fixed in GCC 10.2/GCC 11 (I think they are
hoping to release 10.2 this week).

The linker errors appear to be Python related. Did you update your Python
installation that KiCad uses recently? Can you confirm that SWIG and Python
are being detected correctly bby CMake?

-Ian

On Tue, Jul 21, 2020 at 6:58 PM Brian Piccioni 
wrote:

> Before updating master I had successfuIly build a c late June version.
>
> After failing to build yesterday's master I deleted my build directory,
> pulled master, same problem. I then updated msys in order to make sure it
> wasn't a tool issue. Same problem. I deleted the build directory and same
> result.
>
> When I get home I'll try a new download of master and try that but I
> expect the same result
>
> Note the earlier reply claiming to have had a similar problem.
>
> On Tue, Jul 21, 2020, 13:47 Nick Østergaard  wrote:
>
>> That looks quite strange. Did you try a clean build directort? Maybe
>> there is some caching that is broken after a toolchain update?  Pure
>> speculation.
>>
>>
>> On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
>>  wrote:
>> >
>> > It is a non-release tag, but as a developer I sort of need it to
>> compile ...
>> >
>> > On 2020-07-21 10:45 a.m., Alex wrote:
>> >
>> > I too, also had the same errors, but assumed that 5.99 was some weird
>> non-release tag, and switched to a different branch, as this is my first
>> day building the application.
>> >
>> > On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni <
>> br...@documenteddesigns.com> wrote:
>> >>
>> >> When building I get a slew of errors or information messages of the
>> type
>> >> (see below). During linking I then get a pile of "undefined" errors.
>> >> There are so many I can't reproduce them all.
>> >>
>> >> When I link I get a fatal error.
>> >>
>> >> This is the Master branch downloaded a few minutes before compiling. I
>> >> tried updating Msys and get the same result.
>> >>
>> >>
>> >> 42 |   struct ctype_base
>> >>|  ^~
>> >> In file included from C:/msys64/mingw64/include/c++/10.1.0/string:43,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
>> >>   from
>> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> >> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
>> >> replace the class-key with 'struct'
>> >>125 |   class ctype_base;
>> >>| ^~
>> >> In file included from
>> >> C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
>> >>   from
>> >> C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
>> >>   from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
>> >>   from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
>> >>   from
>> C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
>> >>   from
>> C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
>> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
>> >>   from
>> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> >>
>> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
>> >> note: 'std::ctype_base' defined as 'struct' here
>> >> 42 |   struct ctype_base
>> >>|  ^~
>> >> [ 93%] Building CXX object
>> >> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
>> >> In file included from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
>> >>   from
>> >>
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
>> >>   from
>> >>
>> 

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

[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

[Kicad-developers] GTK2 Support Dropped for Linux

[Ian McInerney]

I have just merged the PR that drops GTK2 support for Linux. This means
that the GTK3 version of wxWidgets must be used on all Linux platforms
building and using master (e.g. future v6). This change does not affect
5.1. If you don't use Linux, then this change shouldn't affect you.

-Ian
___
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] Kicad 6 API

[Ian McInerney]

The core features of KiCad do not rely on GTK, or any specific toolkit
other than wxWidgets currently. GTK is only required if you want to use
KiCad on Linux machines, and it will use the native (Win32 and Appkit)
frameworks on the other operating systems [1]. The core code does have a
dependency on the core wxWidgets libraries for things like file IO though,
but that dependency is not concerning for this work.

KiCad is a complicated application, with a long history. Design changes
that are fundamental to the core code take time to implement and cannot be
done overnight. Couple that with the fact that the current set of active
developers is small (I believe we have ~10 lead developers, and around 5-10
other regular contributors), large changes like that will take a developer
away from other features that users want. Pausing KiCad releases for a very
long time to do the refactor of the backend code will not be helpful to
users who want features added during that release cycle and to use those
features in the near future. As such, we incrementally do it as we work in
areas, as it is needed for other new features, and as developers have time.
The current developer viewpoint is that we don't add new features or code
that will make this separation more difficult to achieve in the future, but
try to either introduce more separation or keep it at the same level with
new features. During each development cycle, small projects are done in the
beginning to introduce more separation, and we are trying to work towards
the point where that final separation can be achieved during a release
cycle, but it isn't going to be in version 6.

I will echo what has been said before: to get an understanding of the
current state of the KiCad codebase and what it will take to do a refactor
that accomplishes what you are suggesting, please look through the code and
experiment with it (fixing issues and implementing small new features is a
good way to do that). I have been in the codebase for around a year at this
point, and even I still don't understand some aspects of it.

-Ian

[1] Technically you could use any of the ports of wx on the platforms they
support (e.g. wxGTK on windows), but we only will provide support for the
native port running on the machine.



On Wed, Jul 15, 2020 at 5:26 PM Conrad Wood 
wrote:

> I looked at the SWIG stuff some months ago (because I'm keen on Golang
> APIs). My SWIG-fu was nowhere near as good to figure out to compile
> anything but the python bindings (and even that was non-trivial IMHO)
>
> I think it would be much easier (as in trivial) if there be a clean
> split between UI (and dependencies) and non UI.
>
> If there were a library (kicad.so) with the relevant functions, then it
> would be quite trivial to create (and maintain) Bindings. The GUI ought
> to use the library as well, but ideally the library should not depend
> on any GTK of any sort.
>
> If that split were as clean as I imagine it, it would even be easy to
> create additional functionality, such as (kicad-diff.so) or (kicad-
> tools.so) which the GUI could choose to use or not. Maybe splitting out
> kicad-eeschema.so and kicad-pcbnew etc makes sense too.
>
> This would make it much easier to allow maintainers to focus on one
> area and become the "domain expert" there. Hopefully, this would also
> release some pressure on the current (lead) developers, I imagine.
>
> I also think it would enable independent software developers to build
> software on top of, or around kicad, further enhancing its value.
>
> That's another reason why I think it might be useful to think and
> document a little about the architecture and the components of future
> Kicad releases and the long-term evolution.
>
>
>
>
> On Wed, 2020-07-15 at 08:00 -0700, Seth Hillbrand wrote:
> > Our main focus is stabilizing the Python API.  If there is a
> > motivated developer who steps up to contribute and maintain (fix
> > bugs) an alternate language binding, we could consider additional
> > support in the main tree.  For right now, that is not on our list of
> > features for v6.
> > Best-
> > Seth
> >
> > Seth Hillbrand
> > Lead Developer
> > +1-530-302-5483‬
> > Davis, CA
> > www.kipro-pcb.comi...@kipro-pcb.com
> >
> >
> > On 2020-07-13 21:00, Tim Hawkins wrote:
> > > Would it be possible to consider using swig to create the Python
> > > Bindings, so that it will be easy to create bindings for other
> > > languages than just Python, Java, Kotlin or Rust would be of
> > > interest to me.
> > >
> > > On Tue, Jul 14, 2020 at 1:06 AM Jon Evans 
> > > wrote:
> > > > Hi Conrad,
> > > >
> > > > We are working towards removing all the UI dependencies (already
> > > > the
> > > > latest state-of-the-art is way better than the 5.1 branch in this
> > > > regard).  We are also working towards a more stable Python API.
> > > >
> > > > One of the goals of this work is to enable some of the features
> > > > you
> > > > mentioned (automated generation of outputs, etc).

Re: [Kicad-developers] Display origin transforms for DRC reports?

[Ian McInerney]

I view the package of information need as the arguments to the function. If
information isn't needed, then it shouldn't be passed in. Creating a new
wrapper type that just holds the EDA_UNITS and the ORIGIN_TRANSFORMS object
seems like an extra level of abstraction that is not needed. The point of
my original question about the IU is that if the transform operates on the
IU, then these two items are probably not needed together anywhere else.
Adding a struct solely to hold these two datatypes will add
code/understanding overhead to the functions and its callsite, specifically:
* Having to create the actual struct and populate it's fields before
calling the function
* In the function the struct has to be unpacked/continually referenced (so
the variable names become longer)
* It hides the fact that we are passing these two items (one of which is
already an opaque type) inside another opaque type when someone just views
the prototype for the function

To me, it seems like there is not enough here to justify the creation of a
new layer of abstraction to pass these two items into this function. If
these two datatypes are needed in other places at the same time, then I
could see the justification.

-Ian

On Fri, Jul 10, 2020 at 9:30 PM Jon Evans  wrote:

> The way I see it, there is one package of information that we should
> be delivering: how to turn internal units into real text for display.
> That information includes both a units selection and whatever
> transform to apply in case there are coordinates involved.
>
> I see no benefit into splitting that into two arguments.
>
> On Fri, Jul 10, 2020 at 4:27 PM Ian McInerney 
> wrote:
> >
> > Doesn't the origin transform operate on the IU and not use the units
> directly (so the units are only needed by the actual menu text generation
> function)? If they are separate, then we should pass them as two individual
> arguments to the GetSelectMenuText function.
> >
> > -Ian
> >
> > On Fri, Jul 10, 2020 at 8:40 PM Jon Evans  wrote:
> >>
> >> It would be preferable to make it possible to call GetSelectMenuText
> >> (or really, any facility that needs access to the current units and
> >> coordinate transform) without a frame.
> >>
> >> We have recently been putting a lot of effort into separating the
> >> logic code from the UI / frame code in KiCad, and it would be a shame
> >> to introduce something that ties them together.
> >>
> >> What about bundling together the units selection and the origin
> >> transforms into a single object that can be passed into
> >> GetSelectMenuText instead of the EDA_DRAW_FRAME?
> >>
> >> That would make it easier to write testcases and other standalone
> >> chunks of code that can pass in arbitrary units and transforms without
> >> having to construct a frame.
> >>
> >> -Jon
> >>
> >> On Fri, Jul 10, 2020 at 3:33 PM Reece R. Pollack  wrote:
> >> >
> >> > The units selection and the origin transforms are both available
> through
> >> > the EDA_DRAW_FRAME. I haven't looked at every call in detail (there
> are
> >> > a combined 118 calls and function declarations), but it appears that
> >> > when the caller has access to an EDA_DRAW_FRAME then the call is some
> >> > variant of:
> >> >
> >> >   GetSelectMenuText( m_editFrame->GetUserUnits() );
> >> >
> >> > Where there isn't access to an EDA_DRAW_FRAME, it's coded as:
> >> >
> >> >   GetSelectMenuText( EDA_UNITS::MILLIMETRES );
> >> >
> >> > It seems to me that if we're going to change the parameters to this
> >> > function, we should pass a pointer to an EDA_DRAW_FRAME as a single
> >> > parameter. If this parameter is nullptr, then we assume
> >> > EDA_UNITS::MILLIMETRES and null transforms, otherwise we use the
> getter
> >> > functions in EDA_DRAW_FRAME to get the correct object or data.
> >> >
> >> > I'd need to see more than a few nodding heads before I made either of
> >> > these changes.
> >> >
> >> > -Reece
> >> >
> >> > On 7/10/20 3:00 PM, Jeff Young wrote:
> >> > > I agree on both points: units and transform should be saved in the
> project file, and they should be passed to GetSelectMenuText as parameters.
> >> > >
> >> > > Cheers,
> >> > > Jeff.
> >> > >
> >> > >
> >> > >> On 10 Jul 2020, at 19:35, Jon Evans  wrote:
> >> > >>
> >> > >> OK, I see.
> 

Re: [Kicad-developers] Display origin transforms for DRC reports?

[Ian McInerney]

Doesn't the origin transform operate on the IU and not use the units
directly (so the units are only needed by the actual menu text generation
function)? If they are separate, then we should pass them as two
individual arguments to the GetSelectMenuText function.

-Ian

On Fri, Jul 10, 2020 at 8:40 PM Jon Evans  wrote:

> It would be preferable to make it possible to call GetSelectMenuText
> (or really, any facility that needs access to the current units and
> coordinate transform) without a frame.
>
> We have recently been putting a lot of effort into separating the
> logic code from the UI / frame code in KiCad, and it would be a shame
> to introduce something that ties them together.
>
> What about bundling together the units selection and the origin
> transforms into a single object that can be passed into
> GetSelectMenuText instead of the EDA_DRAW_FRAME?
>
> That would make it easier to write testcases and other standalone
> chunks of code that can pass in arbitrary units and transforms without
> having to construct a frame.
>
> -Jon
>
> On Fri, Jul 10, 2020 at 3:33 PM Reece R. Pollack  wrote:
> >
> > The units selection and the origin transforms are both available through
> > the EDA_DRAW_FRAME. I haven't looked at every call in detail (there are
> > a combined 118 calls and function declarations), but it appears that
> > when the caller has access to an EDA_DRAW_FRAME then the call is some
> > variant of:
> >
> >   GetSelectMenuText( m_editFrame->GetUserUnits() );
> >
> > Where there isn't access to an EDA_DRAW_FRAME, it's coded as:
> >
> >   GetSelectMenuText( EDA_UNITS::MILLIMETRES );
> >
> > It seems to me that if we're going to change the parameters to this
> > function, we should pass a pointer to an EDA_DRAW_FRAME as a single
> > parameter. If this parameter is nullptr, then we assume
> > EDA_UNITS::MILLIMETRES and null transforms, otherwise we use the getter
> > functions in EDA_DRAW_FRAME to get the correct object or data.
> >
> > I'd need to see more than a few nodding heads before I made either of
> > these changes.
> >
> > -Reece
> >
> > On 7/10/20 3:00 PM, Jeff Young wrote:
> > > I agree on both points: units and transform should be saved in the
> project file, and they should be passed to GetSelectMenuText as parameters.
> > >
> > > Cheers,
> > > Jeff.
> > >
> > >
> > >> On 10 Jul 2020, at 19:35, Jon Evans  wrote:
> > >>
> > >> OK, I see.
> > >>
> > >> I have mostly stayed out of this conversation before so I will
> > >> probably step back, but I would suggest that I think that display
> > >> units and origin choice should be a project-level setting, not
> > >> system-level.
> > >>
> > >> Probably it makes sense to change GetSelectMenuText so that it has
> > >> this context available somehow (whether by passing in an
> > >> EDA_DRAW_FRAME or by just passing in the ORIGIN_TRANSFORMS or
> > >> whatever)
> > >>
> > >> -Jon
> > >>
> > >> On Fri, Jul 10, 2020 at 2:29 PM Reece R. Pollack 
> wrote:
> > >>> Jon,
> > >>>
> > >>> The alternate origins themselves (Place & Drill / Aux origin, and
> Grid
> > >>> origin) in Pcbnew are stored in the BOARD_DESIGN_SETTINGS class and
> > >>> saved in the board file. Of course, the Page origin location doesn't
> > >>> need to be stored; it's always (0,0).
> > >>>
> > >>> My initial thought last year was to store the user's choice of
> display
> > >>> origin in the board file, but after some discussion we reached
> consensus
> > >>> that the choice of display origin was more like millimeters/inches
> and
> > >>> thus should be a user option rather than a board property. In the
> > >>> proposed implementation, the user's preference for which origin is
> used
> > >>> for display is stored in the PCB_DISPLAY_OPTIONS class and saved in
> the
> > >>> pcbnew.json file. I think a case could be made that this should be
> saved
> > >>> per-project, but no one has made a good argument for that.
> > >>>
> > >>>
> > >>> The primary user of the display origin transforms is the UNIT_BINDER
> > >>> class. This class has a pointer to the EDA_DRAW_FRAME object.  Since
> > >>> UNIT_BINDER is common, I added a virtual function
> > >>> "GetOriginTransforms()" to the EDA_DRAW_FRAME class. This function
> > >>> returns a reference to an ORIGIN_TRANSFORMS class. The base
> > >>> implementation of the ORIGIN_TRANSFORMS class contains functions that
> > >>> return their coordinate arguments unchanged. This way none of the
> KiCad
> > >>> applications see a change in behavior unless they override the
> > >>> GetOriginTransforms() function.
> > >>>
> > >>> In the case of Pcbnew, the EDA_DRAW_FRAME parameter is actually a
> > >>> pointer to a PCB_BASE_FRAME object. In this class, the
> > >>> GetOriginTransforms() function is overridden and returns a reference
> to
> > >>> a PCB_ORIGIN_TRANSFORMS object. This object's functions know how to
> > >>> access the BOARD_DESIGN_SETTINGS and PCB_DISPLAY_OPTIONS objects
> through
> > >>> the PCB_BASE_FRAME object and perform the 

[Kicad-developers] Proposal: Drop GTK2 support

[Ian McInerney]

Currently, we support both GTK2 and GTK3 versions of wxWidgets. What I am
proposing here is that we drop the support of GTK2 from our codebase and
only officially support the GTK3 version of wxWidgets on Linux. This would
only apply for master (v6 and beyond), 5.1 would continue to have its same
support status.

The reasons I have for wanting this are:
* GTK2 has some issues in rendering our UI that we can't overcome (
https://gitlab.com/kicad/code/kicad/-/issues/4842).
* New features in the KIPLATFORM library will make direct use of the GTK
calls and headers, and having to support mixed GTK versions makes the build
system and code for these features very complex
* All of our supported platforms for v6 use the GTK3 version of wxWidgets
by default

Any objections/comments?

-Ian
___
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] Lots of compile errors after recent source pull

[Ian McInerney]

Thanks, that is the line I was interested in and it confirms what I was
thinking - we aren't turning them on.

I reported this to upstream GCC on Sunday, and they have confirmed there is
a bug in the compiler where it is printing out the note statements when it
shouldn't (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063). They have
fixed that for GCC 11, and I am hoping they pull the fix into GCC 10.2. I
will have to guard this warning against the GCC version I guess, but I am
waiting to see their reply about backporting it to 10.2 first.

-Ian

On Wed, Jul 8, 2020 at 1:05 AM  wrote:

> Ian,
>
> Sorry for the delay in getting this information.  I believe this is the
> info you wanted from the "compile_commands.json" file.  If not, I can
> always send you the entire 1.5 MB file.
>
> {
>   "directory": "C:/msys64/home/codelite-kicad-compile-test2/eeschema",
>   "command": "C:/msys64/mingw64/bin/c++.exe  -DDEBUG -DEESCHEMA
> -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad
> -DKICAD_SPICE -DKICAD_USE_OCE -DUNICODE -DWXUSINGDLL -DWX_COMPATIBILITY
> -D_FILE_OFFSET_BITS=64 -D_UNICODE -D_USE_MATH_DEFINES
> -D__USE_MINGW_ANSI_STDIO=1 -D__WXMSW__
> @CMakeFiles/eeschema_kiface_objects.dir/includes_CXX.rsp  -fpermissive
> -Wall -Wsuggest-override -Wduplicated-branches -Wduplicated-cond
> -Werror=vla -Wimplicit-fallthrough=5 -Werror=return-type -Wshadow
> -Wsign-compare -Wmissing-field-initializers -Wempty-body -Wreorder
> -Wmismatched-tags -g3 -ggdb3 -fvisibility=hidden
> -fno-keep-inline-dllexport   -std=gnu++14 -o
> CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_annotate.cpp.obj -c
> C:/msys64/home/kicad-compile-test2/kicad/eeschema/dialogs/dialog_annotate.cpp",
>   "file":
> "C:/msys64/home/kicad-compile-test2/kicad/eeschema/dialogs/dialog_annotate.cpp"
> }
>
>
>
>
> -Original Message-
> From: Ian McInerney 
> To: pjmo...@csi.com
> Cc: ian.s.mciner...@ieee.org ;
> kicad-developers@lists.launchpad.net  >
> Sent: Sun, Jul 5, 2020 4:52 am
> Subject: Re: [Kicad-developers] Lots of compile errors after recent source
> pull
>
> Yea, unfortunately the Windows headers love to have unscoped defines that
> are very common words, meaning anytime we try to use those we get conflicts
> (it is really annoying). JP fixed it yesterday in
> https://gitlab.com/kicad/code/kicad/-/commit/9e669db5b4bdeff7f057614a6c93067f7a8c7024.
>
>
> As for the warnings, can you please provide the command that is being used
> to compile one of the files that has the mismatched-tag warnings? You can
> find them by setting `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` in your CMake
> config, then looking inside compile_commands.json in the build directory
> for the filename. I would like to track down why your mingw build is
> warning in system headers when it shouldn't. In the meantime, I have
> reported the mismatched tags to libstdc++ upstream, so hopefully they can
> clean them up.
>
> -Ian
>
> On Sun, Jul 5, 2020 at 6:12 AM  wrote:
>
> Very hard to find the errors among the epic amount of long warning
> messages.  The full make would go a long time, then fail.  I'd start it
> again, it would go for some time, then fail again. Lather. Rinse.
> Repeat.
>
> Finally saw these error messages:
>
> C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note:
> 'std::error_condition' defined as 'struct' here
>   278 |   struct error_condition
>   |  ^~~
> In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
>  from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
>  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
>  from
> C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected identifier before numeric constant
>70 | ERROR,
>   | ^
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected '}' before numeric constant
> In file included from
> C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:67:1: note: to
> match this '{'
>67 | {
>   | ^
> In file includ

Re: [Kicad-developers] Lots of compile errors after recent source pull

[Ian McInerney]

Yea, unfortunately the Windows headers love to have unscoped defines that
are very common words, meaning anytime we try to use those we get conflicts
(it is really annoying). JP fixed it yesterday in
https://gitlab.com/kicad/code/kicad/-/commit/9e669db5b4bdeff7f057614a6c93067f7a8c7024
.

As for the warnings, can you please provide the command that is being used
to compile one of the files that has the mismatched-tag warnings? You can
find them by setting `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` in your CMake
config, then looking inside compile_commands.json in the build directory
for the filename. I would like to track down why your mingw build is
warning in system headers when it shouldn't. In the meantime, I have
reported the mismatched tags to libstdc++ upstream, so hopefully they can
clean them up.

-Ian

On Sun, Jul 5, 2020 at 6:12 AM  wrote:

> Very hard to find the errors among the epic amount of long warning
> messages.  The full make would go a long time, then fail.  I'd start it
> again, it would go for some time, then fail again. Lather. Rinse.
> Repeat.
>
> Finally saw these error messages:
>
> C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note:
> 'std::error_condition' defined as 'struct' here
>   278 |   struct error_condition
>   |  ^~~
> In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
>  from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
>  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
>  from
> C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected identifier before numeric constant
>70 | ERROR,
>   | ^
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected '}' before numeric constant
> In file included from
> C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:67:1: note: to
> match this '{'
>67 | {
>   | ^
> In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
>  from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
>  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
>  from
> C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected unqualified-id before numeric constant
>70 | ERROR,
>   | ^
> In file included from
> C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:72:1: error:
> expected declaration before '}' token
>72 | };
>   | ^
>
>
>
> -Original Message-
> To: ian.s.mciner...@ieee.org 
> Cc: kicad-developers@lists.launchpad.net <
> kicad-developers@lists.launchpad.net>
> Sent: Sat, Jul 4, 2020 6:45 pm
> Subject: Re: [Kicad-developers] Lots of compile errors after recent source
> pull
>
> Other headers as well.
>
> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note: replace
> the class-key with 'struct'
>   125 |   class ctype_base;
>
> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
> note: 'std::ctype_base' defined as 'struct' here
>42 |   struct ctype_base
>   |  ^~
>
> C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note:
> 'std::_Array<_Tp>' defined as 'struct' here
>   396 | struct _Array
>
> ...as well as the one I originally showed...
>
> C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace the
> class-key with 'struct'
>54 |   class error_code;
>
> There may be more, but these are the ones I see repeating over and over.
> I tried to do a full b

Re: [Kicad-developers] Lots of compile errors after recent source pull

[Ian McInerney]

That would probably be because I enabled the warning for
"-Wmismatched-tags" on clang/GCC. This shouldn't be an error though, only a
warning. It warns about declaring things class/struct inconsistently (on
MSVC builds this can cause problems, so I enabled this warning to ensure we
don't have issues with this since we are starting to have more people
use MSVC). It appears that the system headers in GCC don't follow that
standard unfortunately, but usually warnings from inside system headers are
ignored (apparently on the C++ headers on my machine it is also mismatched
but I don't see all the warnings when building with Clang). These are
supposed to be hidden when the include directories are system include
directories though.

Do you see this for other headers, or is it just this one header? I
wouldn't mind forwarding this upstream to cleanup their headers.

-Ian

On Sat, Jul 4, 2020 at 11:00 PM  wrote:

> I did a pull yesterday and suddenly I'm getting just a ton of errors
> during compiling.  I'm on Windows 10 under minGW.  My setup was working
> great up until this recent pull, and then everything fell apart.
>
> The problems seem to begin when compiling the "common" directory,
> specifically when it hits "gal".  This is a sample of gcc's output when the
> problem first starts:
>
> Scanning dependencies of target gal
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/basic_gal.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/gl_context_mgr.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/newstroke_font.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/painter.cpp.obj
> In file included from
> C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
>  from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
>  from
> C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
>  from C:/msys64/mingw64/include/c++/10.1.0/iterator:66,
>  from C:/msys64/mingw64/include/wx-3.0/wx/arrstr.h:116,
>  from C:/msys64/mingw64/include/wx-3.0/wx/filefn.h:15,
>  from C:/msys64/mingw64/include/wx-3.0/wx/utils.h:20,
>  from C:/msys64/mingw64/include/wx-3.0/wx/cursor.h:69,
>  from C:/msys64/mingw64/include/wx-3.0/wx/event.h:21,
>  from C:/msys64/mingw64/include/wx-3.0/wx/app.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/glcanvas.h:18,
>  from
> C:/msys64/home/kicad-master/kicad/include/gl_context_mgr.h:28,
>  from
> C:/msys64/home/kicad-master/kicad/common/gl_context_mgr.cpp:26:
> C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace the
> class-key with 'struct'
>54 |   class error_code;
>   | ^~
> C:/msys64/mingw64/include/c++/10.1.0/system_error:180:10: note:
> 'std::error_code' defined as 'struct' here
>   180 |   struct error_code
>   |  ^~
> C:/msys64/mingw64/include/c++/10.1.0/system_error:55:9: note: replace the
> class-key with 'struct'
>55 |   class error_condition;
>   | ^~~
> C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note:
> 'std::error_condition' defined as 'struct' here
>   278 |   struct error_condition
>
> It goes on and on and on like this with all these errors about "struct
> error code" and "class error code" and the like.
>
> I have a local branch that is only up to date with
> 2cfd6ba978caee591a6ae2a1f920d96c31717f2f from July 2, and I was able just
> now to compile it again without any errors.
>
> I created a brand new clone repo of the latest commit  (
> 9e669db5b4bdeff7f057614a6c93067f7a8c7024 ) and I still get the same compile
> errors.
>
> Has anyone else noticed this?  Is this a problem on my end or is there a
> bad push that started this problem somewhere between July 2 and today?
> ___
> 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] macOS on Arm

[Ian McInerney]

Hi Adam,

Thanks for your work trying to test this on the new hardware! I have made a
tracker epic for all the fixes we need to make to our code/infrastructure
here: https://gitlab.com/groups/kicad/-/epics/5, so we can more easily keep
track of everything. Currently, it is just tracking a few small commits I
have been seeing in upstream wxWidgets that we will probably need to
cherry-pick into our fork (but they will eventually be included inside
3.1/3.2). As you find things, please open issues where appropriate (main
code repo, packaging repos, etc.) and we can add them to this tracker. You
can also leave comments on the Epic about things as well.

-Ian

On Thu, Jun 25, 2020 at 3:40 PM Adam Wolf 
wrote:

> Hi folks!
>
> I have applied to the Apple ARM transition program so I can be ready
> for Apple's next macOS release.  As part of that, I have signed an NDA
> (harrumph), which means I may not be able to keep folks in-the-loop as
> much as I'd like.
>
> Thanks for your understanding!
>
> Adam Wolf
>
> ___
> 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] Auto-generated backup files: are they useful?

[Ian McInerney]

Yes, it will use the system file rename command to rename the temp saved
file. If that system command fails, then wx will automatically attempt to
copy the temp saved file instead, and that will preserve the temp saved
file if it fails (so basically, the temp saved file will only be removed if
the operation succeeds).

-Ian

On Tue, Jun 30, 2020 at 5:07 PM Andrew Lutsenko 
wrote:

> Ah, I reread now what the change to save logic was and I agree, the main
> reason for the current backup system is now irrelevant, assuming the last
> step of copying over the file is done using system functions and not by
> opening and writing the file.
>
> On Tue, Jun 30, 2020 at 8:15 AM Jon Evans  wrote:
>
>> What is the scenario that they guard against today?  I claim that they
>> don't do this anymore.
>>
>> Scenario 1:
>>
>> 1) Save, which succeeds
>> 2) Do some work, but don't hit save
>> 3) KiCad crashes
>>
>> Result: data after last save is lost
>>
>> Scenario 2:
>>
>> 1) Save, which succeeds
>> 2) Do some work, hit save
>> 3) KiCad crashes while saving file
>>
>> Result: The same as Scenario 1, since my recent change to save behavior.
>>
>> -Jon
>>
>> On Tue, Jun 30, 2020 at 11:09 AM Andrew Lutsenko 
>> wrote:
>> >
>> > I don't think removing the current backup system before implementing a
>> new one is the right thing to do.
>> > As limited and simple as it is, the current system provides valuable
>> safeguard against data loss on crashes that may corrupt the main save file.
>> And no, VCS is not a replacement, most people hit ctrl-s a lot more often
>> than they do "git commit".
>> >
>> >
>> > On Tue, Jun 30, 2020 at 7:13 AM Jon Evans  wrote:
>> >>
>> >> JP, I agree that true backups are useful.
>> >>
>> >> Maybe even it is a good idea for KiCad to have a built-in backup
>> function.
>> >>
>> >> I just don't think the current backup function is actually useful
>> >> because of my first point (backups are overwritten on each save).
>> >>
>> >> I would propose:
>> >>
>> >> 1) Remove the current backup file generation
>> >>
>> >> 2) Create a spec (in GitLab issue) for a better backup system that:
>> >>
>> >> - Can be turned on or off
>> >> - Backs up the whole project in a zip file
>> >> - Can keep the last N backups
>> >> - Runs on a schedule, not necessarily every time you click Save.
>> >>
>> >> Anyone opposed to this?
>> >>
>> >> -Jon
>> >>
>> >> On Tue, Jun 30, 2020 at 3:32 AM jp charras 
>> wrote:
>> >> >
>> >> > Le 30/06/2020 à 00:13, hauptmech a écrit :
>> >> > >
>> >> > > While I agree that it is not KiCad's job to do archival backups or
>> version control, I do think that KiCad should preserve the integrity of
>> users data through a crash. Even better if the work between the last save
>> and the crash is also preserved and recovered on restart.
>> >> > >
>> >> > > I have had to use the backup files to recover data in the past. I
>> have no idea if that recovery was related to something that is now no
>> longer a possible issue.
>> >> > >
>> >> > >
>> >> > > -Hauptmech
>> >> > >
>> >> > >
>> >> >
>> >> > I am also thinking a backup can be useful when something unexpected
>> happens.
>> >> >
>> >> > Backups, like any security system, bothers you as long as you do not
>> need to use them.
>> >> > But you are happy to find them in case of trouble.
>> >> >
>> >> > I like the way some CAD tools manage backup:
>> >> > only one zip archive is created (for instance
>> projectname_backup.zip) and contains all saved files
>> >> > (in our case: *.kicad_sch (and sub paths) and .kicad_pcb)
>> >> > This is not a full project backup, just main files are saved.
>> >> >
>> >> > This is not invasive (only one file, or a few .zip if one want to
>> keep last n saved versions)
>> >> > and is a security against  unexpected cases.
>> >> >
>> >> > For me, backups are like a accident insurance: you need them and you
>> hope never use them.
>> >> >
>> >> > And about VCS use:
>> >> >
>> >> > Many good electronics guys do not even know what is it, and have
>> never compiled any source code.
>> >> > Electronics world and Software world are not exactly the same world.
>> >> >
>> >> > --
>> >> > Jean-Pierre CHARRAS
>> >> >
>> >> > ___
>> >> > 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   : 

Re: [Kicad-developers] Auto-generated backup files: are they useful?

[Ian McInerney]

I'm +1 on removing the backup files completely. I can see how they might
have been useful in the past given the save behavior, but I think the
recent changes to that have made them obsolete. I am also someone who puts
all my projects into a git repo, so I have always found them annoying and
never even used them.

Also, did we ever even have anything like an auto-recover mechanism for
them (where if the main file failed loading it would fallback to the
backup)? I can't recall... (which probably means I never used it if we have
one).

-Ian

On Mon, Jun 29, 2020 at 8:24 PM Jon Evans  wrote:

> Currently, KiCad automatically creates backups of schematic and PCB
> files when you save a file.
>
> The logic for these backups is basically: if a file already exists
> with the same name as what we are saving, copy that file to a new file
> and give it the "-bak" suffix on the file extension.
>
> These backups are stored next to the original file in the current
> KiCad codebase.  This understandably creates clutter that some people
> don't like (myself included) so in the project-settings branch that is
> about ready to be merged, I changed this behavior to place all these
> backups in a special backups folder for the project.
>
> This proved to have some complications around the handling of files
> outside the project path (which it's possible to have with
> hierarchical schematic sheets) so I need to do something else.
>
> After some thought, I am pretty convinced that the right thing to do
> is just *remove this backup feature entirely*.  Here's why:
>
> 1) It's not a very good backup:  It just stores the state from the
> last time you hit "save".  If you hit save again, your backup is blown
> up.  So, it's really like a "undo" function, but on disk, and with
> only one level of undo.
>
> 2) Recently I changed how we save schematic and board files to fix
> some unrelated issues people were seeing with cloud backup services.
> Before this change, if KiCad crashed or had some other serious error
> while saving a file, the file would be lost (because we used to delete
> the old file and then write a new one in its place).  After this
> change, we write the new file to a temporary location, and only if
> that write succeeds do we copy it on top of the old file.  I think
> this vulnerability to generating corrupt files if we crash was one of
> the reasons for this backup file system, and that reason is now gone.
>
> 3) Because it's not a very good backup, I worry that the fact that
> "bak" files exist might cause some users to have a false sense of
> security and not use a true backup system (like a version control
> system, or some other mechanism that actually backs up files
> periodically).  I want to remove this false sense of security so that
> it is more clear that users should back up their files in some way if
> they care about the work.
>
> In other words, I don't think this feature actually gives enough value
> to make it worth the clutter in the project folder and/or the
> development effort to make it work well with less clutter.
>
> So, I'd like to hear from others on this: anyone disagree?
>
> Thanks,
> Jon
>
> ___
> 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] GitLab milestone cleanup

[Ian McInerney]

In general, wishlist items should only be given a milestone if they are
either:
1) Actively being worked on by a developer
2) Currently on the plan for the release they are milestoned against (this
one doesn't need a developer assigned/working on them yet)

Other wishlist items don't get a milestone attached to them. I don't think
there is a need to have a "future" milestone though, since the GitLab
interface makes it easy to look through issues with no milestone and the
wishlist label (it is far easier than Launchpad was).

-Ian

On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen 
wrote:

>
>
> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  wrote:
>
>> What about feature requests / wishes from users that are very unlikely to
>> realise quickly? Should they still be assigned the new milestone?
>>
>> I just worry they may clutter the overview too much, but I guess when we
>> will see how it goes. :) My concern may not be a real problem afterall.
>>
>> Nick
>>
>>
> Could there be a milestone "Future" for features which are wanted but not
> planned for the next release? For example, some things were in the v6
> roadmap but were moved to the future roadmap, and even more can(?) be moved
> later. It would be better to have them in Future milestone than keep them
> in v6 milestone or remove the milestone completely.
>
> Eeli Kaikkonen
> ___
> 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] Compile issue

[Ian McInerney]

The pcb calculator is a kiface (the bitmap 2 component is not though). The
Kiface() symbol is defined in `pcb_calculator.cpp`, and that hasn't changed.

-Ian

On Tue, Jun 23, 2020 at 3:19 PM Jeff Young  wrote:

> Did something change regarding how much of common is getting pulled into
> pcb_calculator?
>
> I’m getting the following link errors:
>
> Undefined symbols for architecture x86_64:
>   "Kiface()", referenced from:
>   EDA_BASE_FRAME::config() const in libcommon.a(eda_base_frame.cpp.o)
>   EDA_BASE_FRAME::sys_search() in libcommon.a(eda_base_frame.cpp.o)
>   EDA_BASE_FRAME::help_name() in libcommon.a(eda_base_frame.cpp.o)
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> gmake[2]: ***
> [pcb_calculator/CMakeFiles/pcb_calculator.dir/build.make:113:
> pcb_calculator/pcb_calculator.app/Contents/MacOS/pcb_calculator] Error 1
> gmake[1]: *** [CMakeFiles/Makefile2:2954:
> pcb_calculator/CMakeFiles/pcb_calculator.dir/all] Error 2
>
>
> I don’t think pcb_calculator is supposed to have a Kiface()?
>
> Thanks,
> Jeff.
> ___
> 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] Propose feature I plan to implement here or elsewhere?

[Ian McInerney]

Welcome.

Yes, if you have some ideas for features to implement, this list is the
best place to start the discussion.

-Ian

On Sat, 20 Jun 2020, 00:20 ,  wrote:

> Hi,
>
> I just joined this developer's mailing list.  I have a feature I'd like to
> add and wanted to know if I should post my proposal to this list, or if
> there's some other mechanism I should use?
>
> Thanks
> ___
> 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] Granularity of DRC error code

[Ian McInerney]

I might have missed something, but how are the basic rules being specified?
Are we going to ship them as pre-built selectors that run through the same
DRC engine as the custom rules (so we only have one engine to worry about),
or are they being done differently? It would seem better to ship them as
pre-built selectors and use the same mechanisms for specifying the severity
of them as custom rules would. I think that is also nicer, because it
essentially provides an example rules file.

-Ian

On Thu, Jun 11, 2020 at 6:40 PM Jon Evans  wrote:

> Yeah I like this.
>
> For the basic rules, we could still make it so that each basic rule had
> independent severity while generating common error codes, although that
> increases complexity. It might be better to keep one error code per "basic"
> rule, except for the ones we are already in agreement can be consolidated.
>
> Then for net class and custom rules, we can just have the severity be a
> rule property, not an error code property.
>
> -Jon
>
> On Thu, Jun 11, 2020, 13:36 Ian McInerney 
> wrote:
>
>> Another example I just thought of (not involving costs): differential
>> pair rules. We could have a category "Trace length mismatch" (or some other
>> name...), and then someone could define rules such that:
>> Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
>> Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
>>
>> When x > y and rule 1 is a higher priority, this can then basically allow
>> for a zone for the DRC to flag the length mismatch where the design will
>> still work, but is not ideal as a warning, and any larger values where the
>> design would fail as an error.
>>
>> -Ian
>>
>> On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney 
>> wrote:
>>
>>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>>>> >
>>>> > Imagine that violating the micro-via min bumps me up a classification
>>>> but violating the through-via min drops me out of pooling.  There’s a big
>>>> cost difference between those two.
>>>> >
>>>>
>>>
>>> This is why I think switching to the severities coming from the rules
>>> would be a better way than defining them by the category of the violation.
>>> By doing that we can limit the need for a lot of categories of violations.
>>> We can for instance have a single code for "Minimum drill violated", and
>>> then have two different rules for the minimum u-via drill and the minimum
>>> through-via drill. Then those rules can treat the code "Minimum drill
>>> violated" as either a warning or an error as they see fit.
>>>
>>> -Ian
>>>
>>>
___
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] Granularity of DRC error code

[Ian McInerney]

Another example I just thought of (not involving costs): differential pair
rules. We could have a category "Trace length mismatch" (or some other
name...), and then someone could define rules such that:
Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning

When x > y and rule 1 is a higher priority, this can then basically allow
for a zone for the DRC to flag the length mismatch where the design will
still work, but is not ideal as a warning, and any larger values where the
design would fail as an error.

-Ian

On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney 
wrote:

> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>> >
>> > Imagine that violating the micro-via min bumps me up a classification
>> but violating the through-via min drops me out of pooling.  There’s a big
>> cost difference between those two.
>> >
>>
>
> This is why I think switching to the severities coming from the rules
> would be a better way than defining them by the category of the violation.
> By doing that we can limit the need for a lot of categories of violations.
> We can for instance have a single code for "Minimum drill violated", and
> then have two different rules for the minimum u-via drill and the minimum
> through-via drill. Then those rules can treat the code "Minimum drill
> violated" as either a warning or an error as they see fit.
>
> -Ian
>
>
___
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] Granularity of DRC error code

[Ian McInerney]

> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
> >
> > Imagine that violating the micro-via min bumps me up a classification
> but violating the through-via min drops me out of pooling.  There’s a big
> cost difference between those two.
> >
>

This is why I think switching to the severities coming from the rules would
be a better way than defining them by the category of the violation. By
doing that we can limit the need for a lot of categories of violations. We
can for instance have a single code for "Minimum drill violated", and then
have two different rules for the minimum u-via drill and the minimum
through-via drill. Then those rules can treat the code "Minimum drill
violated" as either a warning or an error as they see fit.

-Ian
___
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] Granularity of DRC error code

[Ian McInerney]

Why not make the severity attached to the rule being used instead of the
error code type. I think being able to say "this rule is very important and
should be treated as an error" and "this rule is just a guideline and can
be treated as a warning" while they are both the same error code would make
more sense.

-Ian

On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:

> The only reasons to have multiple violation error codes is to be able
> to set a different severity for them, or to be able to filter/sort
> them.
>
> I can't think of a situation in which I would want to do either of
> those things for different via types.
>
> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh 
> wrote:
> >
> > I was thinking along the same lines.  Wouldn't it make more sense to
> > define the objects that violate a DRC rule and generate the error
> > message on the fly rather than adding violation error codes for every
> > possible error?
> >
> > On 6/11/20 9:26 AM, Jon Evans wrote:
> > > I think microvias and vias using different technologies means they
> > > need different *rules*, not different error codes.
> > >
> > > Whether a hole is laser or mechanically drilled, it will have some
> > > rules, and those rules could generate an error "hole size is outside
> > > allowed range".
> > >
> > > You can tell from the affected items whether the hole in question is a
> > > via, microvia, blind via, buried via.
> > > You can tell from the rule source whether this came from a microvia
> > > rule, normal via rule, custom rule, etc.
> > >
> > > Why should we have separate violations per via type?  (not separate
> > > *rules* but separate violations)  I still don't get the use case.
> > >
> > > As mentioned in the last taxonomy discussion, I still think we could
> > > get rid of the tons of different "X close to Y" errors and just call
> > > it a "clearance error", but I understand that might be more
> > > contentious so I'd like to focus for now on just the keepouts and
> > > vias.
> > >
> > > -Jon
> > >
> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
> > >>
> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be
> in favour of folding all of those into a single violation because a keepout
> already specifies which types of things are excluded.
> > >>
> > >> But other things I’d be less in favour of.  I want a warning about
> NPTHs in courtyards; I don’t want one for PTHs (the former likely has a
> mechanical fixing, the later likely doesn't).
> > >>
> > >> While I don’t personally use uVias, I’d certainly think we’d want
> separate violations for their holes (as they’re made with different
> technologies).  On the flip side, I’m not sure there’s any value in
> distinguishing between throughVia holes and pad holes.
> > >>
> > >> But that gives us a different taxonomy for size vs. hole, as the
> difference between uVia and throughVia size may not be important.  (We
> already have this to some extent as I didn’t bother with separate annulus
> violations for via types, although there’s a TODO in the code).
> > >>
> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it
> just an ivory-tower kind of thing, or will it actually cause confusion?
> > >>
> > >> Back to specific instances, I like being able to treat
> track-too-close-to-connected-item separately from
> track-to-close-to-unconnected-item, but I’m less fussed about the
> differences between the type of connected item (track-to-close-to-via vs
> track-to-close-to-track).  (For what it’s worth, unconnected items are
> already grouped as we don’t have separate errors for
> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit of
> unevenness in the existing taxonomy.)
> > >>
> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I
> have no idea why.  I guess it just gives me a better idea of what I’m
> looking for on the board?
> > >>
> > >> One last note: Greg’s request for specific exclusions is already in
> the nightlies.
> > >>
> > >> Cheers,
> > >> Jeff
> > >>
> > >>
> > >>
> > >>> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
> > >>>
> > >>> I think more grouping in general categories is good. I also think
> that it would be nice to exclude *specific* DRCs that once a designer
> checks the error, they can flag it to ignore in the future. The specific
> check could be identified by a unique id: a hash of specific information,
> like unique error and objects involved (identified by geometries and
> properties involved). If anything changes, then the rule violation
> reappears under a different unique id. I think this would help greatly on
> near-tapeout activities where sifting over the same DRC errors becomes
> tedious and prone to missing valid DRC violations in the midst of “designer
> checked and allowed” ones.
> > >>>
> > >>> Greg S.
> > >>>
> >  On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
> > 
> >  Hi all,
> > 
> >  A DRC error code is something like "Via inside keepout 

Re: [Kicad-developers] Sizes for bitmaps in cpp-other

[Ian McInerney]

Ok, I was able to extract the sizing information for these bitmaps from the
existing cpp representations, however it appears that we do not have source
SVGs for the tune_diff_pair_skew_legend and tune_single_track_length_legend
bitmaps, we only have PNGs. Does anyone know where those two came from?

-Ian

On Wed, Jun 10, 2020 at 1:03 PM Ian McInerney 
wrote:

> Does anyone know what the sizes for the bitmaps in the cpp-other folder
> are? The bitmaps are:
> stroke_dash
> stroke_dashdot
> stroke_dot
> stroke_solid
> tune_diff_pair_length_legend
> tune_diff_pair_skew_legend
> tune_single_track_length_legend
>
> I noticed that they are not being regenerated with the rest of the
> bitmaps, we don't appear to have sizes for them defined in the bitmap cmake
> file, and they are not a standard size (hence why they are in other).
>
> -Ian
>
___
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] Sizes for bitmaps in cpp-other

[Ian McInerney]

Does anyone know what the sizes for the bitmaps in the cpp-other folder
are? The bitmaps are:
stroke_dash
stroke_dashdot
stroke_dot
stroke_solid
tune_diff_pair_length_legend
tune_diff_pair_skew_legend
tune_single_track_length_legend

I noticed that they are not being regenerated with the rest of the bitmaps,
we don't appear to have sizes for them defined in the bitmap cmake file,
and they are not a standard size (hence why they are in other).

-Ian
___
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] No hotkey for "Set Bus Entry Shape"

[Ian McInerney]

There are currently 2 actions on the Eeschema tool framework for changing
the bus entry shape, but they don't have a hotkey assigned by default.
Additionally, bus entries are able to be mirrored and rotated as normal
(using the hotkeys for those actions). So I guess the question is, do we
need to have explicit actions for changing the shape of the bus entry when
all that is really doing is a mirror/rotate and we allow that anyway?

-Ian

On Sun, May 31, 2020 at 8:05 PM Andy Peters  wrote:

>
>
> On May 31, 2020, at 6:12 AM, Wayne Stambaugh  wrote:
>
> Maybe it got dropped when Eeschema was ported to the new tool framework
> or broken somewhere along the way.  I'm not seeing a way to change the
> bus entry orientation on master in Linux either so I suspect it got
> dropped.  I don't see a issue report for this on GitLab so please file
> an issue so it doesn't get lost in developers mailing list.
>
>
>
> It’s good to know I’m not crazy.
>
> Issue here: https://gitlab.com/kicad/code/kicad/-/issues/4588
>
> On 5/29/20 7:40 PM, Andy Peters wrote:
>
> In 5.1.6 schematics on macOS Catalina, which is what I’m using, and this
> may be older …
>
> When you choose “place wire to bus entry” (or the ‘z’ key) or “place bus
> to bus entry” (or ‘/‘), you don’t see the entry until you click the mouse
> on the schematic. And there’s no way to change the angle of the entry at
> placement time. There is no hotkey entry for that option, and the only way
> I can see to change it is to place the entry, get out of the place mode,
> right-click select then entry and then choose “set bus entry shape” from
> the context menu, and them move the entry to where you actually want it.
>
> Yeah, that’s not good.
>
> Am I missing something?
>
> -a
>
> ___
> 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] Poll: how does autocomplete filter?

[Ian McInerney]

I am used to autocomplete tools only showing those that match the current
search query. That would also be consistent with the way our hotkey search
control matches when typed as well.

-Ian

On Sat, May 30, 2020 at 4:04 PM Eeli Kaikkonen 
wrote:

> Definitely leaving only matching items and removing others.
>
> Eeli Kaikkonen
>
>
> On Sat, May 30, 2020 at 5:50 PM Jeff Young  wrote:
>
>> One strategy is to highlight the first match as you type, but leave the
>> menu entries unchanged.
>>
>> Another strategy is to remove the un-matched entries (so the selected on
>> is always at the top).
>>
>> I’m used to CLion, which removes, but the Scintilla Editor’s default is
>> to just highlight.
>>
>> Which is more common?  Which are you used to?  Which do you like better?
>>
>> Cheers,
>> Jeff.
>> ___
>> 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] Request to merge support of python 3.9

[Ian McInerney]

Steve,

Thanks for the update to it, and it looks good, so I have set it to merge
to master when the CI build completes. I will then manually cherry-pick
this to the 5.1 branch.

I do wonder if there is a better way for us to structure this search so
that we don't have to touch the file every time a new Python version is
released.

-Ian

On Fri, May 29, 2020 at 4:22 PM Steven A. Falco 
wrote:

> I pushed a change to my KiCad code repo to add python 3.9 as a supported
> version, because Fedora is actively rebuilding everything for python 3.9.
>
> As this is my first contribution via gitlab, please let me know if I
> created the merge request properly.
>
> In particular, this should go into both master and 5.1 - do I need to make
> a separate merge request for 5.1, or can/will it be cherry-picked by
> whomever does the merge?
>
> 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] How much do we care about small memory leaks?

[Ian McInerney]

There are quite a few leaks in the code at present, and every now and then
I go through and try to plug some of them (but I don't find all of them,
that is for sure). My suggestion is that you can either propose a patch in
a merge request if you think you know where the memory should be freed and
who owns it, or file some issues with the details of the memory leaks if
you aren't sure about the memory management. I usually find these when I
run under ASAN, and there are several open already (and some more I am
needing to open issues for):

https://gitlab.com/kicad/code/kicad/-/issues/4070
https://gitlab.com/kicad/code/kicad/-/issues/3882

-Ian


On Fri, May 29, 2020 at 3:23 PM Johannes Pfister <
johannes.pfis...@josttech.ch> wrote:

> As an example, if opening and closing the plot window would leak 3 kB
> each time, would we care about that? And is it justified to increase
> code complexity to avoid this leak?
> If yes, what about "leaks" that alloc memory only once, use the same
> memory till the application is closed and don't free it. Should we
> increase code complexity to avoid this "leaks" too?
>
> The reason for this question: There are some of this kind of leaks in the
> code.
>
> ___
> 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] Merge request: add "Select All" in schematic & layout disambiguation popup menu

[Ian McInerney]

Mikolaj,

Sorry for the delay in revisiting the merge request (it seems to have
slipped past me). I just took a look and it seems fine to me, so I just
merged it. Thanks for the contribution, and thanks for the ping to make
sure this got done.

-Ian

On Sun, May 24, 2020 at 3:46 PM Mikołaj Wielgus 
wrote:

> Hi,
>
> Could anyone please take a look on my merge request below?
> https://gitlab.com/kicad/code/kicad/-/merge_requests/155
>
> There hasn't been any response for 3 weeks since I submitted a revised
> version. I think this is ready to be merged.
>
> Best regards,
> Mikołaj Wielgus
> ___
> 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] How to redefine default system footprint/symbols/packages3d/templates search paths at build time?

[Ian McInerney]

(see comments inline).

On Sun, May 24, 2020 at 1:34 PM Johannes Maibaum  wrote:

> Hi Ian and Nick,
>
> Am Sonntag, den 24.05.2020, 10:59 +0200 schrieb Nick Østergaard:
> > Maybe some of thar stuff depends on CMAKE_INSTALL_PREFIX in some
> > unexpected way?
>
> It seems indeed that on Linux, setting DEFAULT_INSTALL_PATH doesn't have
> the effect you would be expecting from reading the comment in
> CMakeLists.txt:
>
> > The value of DEFAULT_INSTALL_PATH is expanded in config.h and used in
> > the source code to define the base path for kicad search paths and
> > environment variables.
> (from:
> https://gitlab.com/kicad/code/kicad/-/blob/5.1/CMakeLists.txt#L179)
>
> Should I open a ticket for this?
>
> > lør. 23. maj 2020 22.38 skrev Ian McInerney 
> > :
> > > Have you tried redefining the environment variables to point to the
> > > correct system libraries? Specifically I believe the 4 you need are:
> > > KICAD_TEMPLATE_DIR (the templates)
> > > KICAD_SYMBOL_DIR (the eeschema symbols)
> > > KISYSMOD (the modules)
> > > KISYS3DMOD (the 3d models)
>
> I have tried that just now. It seems to work on the KiCad side, i.e.
> setting those environment variables makes the paths show up as defined
> in Preferences -> Configure paths.
>
> OTOH, flatpak doesn't seem to like the fact that the packages3d
> directory by default resides inside the modules directory. This doesn't
> seem to work, but it's not primarily KiCad's fault and I think I can
> work around this limitation by simply putting those two libraries to two
> completely separate paths.
>

Yes, you should be able to put the 3d models in a directory alongside the
footprints, not inside them, and as long as you set the environment
variable correctly I believe it will work (this is how I have my copy of
the git libraries setup).


> Yet, there seems to be another issue with the templates path at the
> moment, which does not only get stuff installed from the kicad-templates
> package, but there is also a "kicad.pro" (default?) project file coming
> from the main application.
>
> The templates get a bit difficult. The symbols, footprints and main
application all install things into the templates folder - specifically the
template project, the default symbol library table, and the default
footprint library table. The easiest packaging split would be to just keep
the 3d models separate and leave the templates/symbols/main application all
in one package (that is how Fedora does it). If you want to get more
complicated, you can look at how Debian has structured their packages,
since they split everything into separate packages.


>
> So far, thanks for the hints, guys! I will keep experimenting with the
> different variables and see if I can come up with a solution that works
> for now.
>
> For the not-too-distant future (a.k.a. KiCad 6): Are there plans to
> revamp the default library search paths? In general it seems to be a
> quite thought through system, but then there are some rough edges here
> and there, like the packages3d being inside the modules directory, plus
> the templates coming from two different source packages.
>

The 3d model search system is a known limitation, and it is on the future
roadmap to switch over to using library tables like the footprint/symbol
libraries instead of the current hard-coded paths - but that won't be for
v6.


>
> And it would be great to know if the comment regarding
> DEFAULT_INSTALL_PATH is simply not up to date on Linux, or if it is
> indeed a bug that should be fixed?
>
>
> Johannes
>
>
___
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] How to redefine default system footprint/symbols/packages3d/templates search paths at build time?

[Ian McInerney]

Have you tried redefining the environment variables to point to the correct
system libraries? Specifically I believe the 4 you need are:
KICAD_TEMPLATE_DIR (the templates)
KICAD_SYMBOL_DIR (the eeschema symbols)
KISYSMOD (the modules)
KISYS3DMOD (the 3d models)

-Ian



On Sat, May 23, 2020 at 8:50 PM Johannes Maibaum  wrote:

> Hello KiCad developers,
>
> TL;DR:
> How can I redefine the default system
> footprint/symbols/packages3d/templates base search paths at build time
> using CMake options, so that KISYSMOD, KISYS3DMOD, KICAD_SYMBOL_DIR, and
> KICAD_TEMPLATE_DIR all point to the directories:
>
> $PREFIX/data/share/kicad/{modules,modules/packages3d,symbols,templates}
>
> instead of:
>
> $PREFIX/share/kicad/{modules,modules/packages3d,symbols,templates}?
>
>
> Longer version:
>
> First a quick update from flatpak land:
>
> This week I merged the update to KiCad 5.1.6, fixed the ngspice
> simulator in Eeschema, activated Python scripting, and added user
> documentation to the KiCad flatpak. This means that flatpak users by now
> get a KiCad experience that should support close to all features that
> the software package offers.
>
> But what I would like to do in order to make the installed size
> (currently 6.2GB, mostly due to the 3D packages) a little bit more
> controllable from the user perspective [1] is to move the footprint,
> symbols, 3D models, and templates into separate "flatpak app extensions"
> which can then be installed or removed independently of the main
> application.
>
> The way flatpak extensions work is that you basically define an
> "extension mount point" inside your main flatpak (I chose /app/data) for
> whatever files and directories an installed extension wants to add into
> the bundle.
>
> I have set up those library extensions already, and they are being
> mounted correctly inside the flatpak at runtime, but so far I wasn't
> able to configure KiCad correctly to use this mount point as base dir
> for the data files.
>
> So far, I have tried either -DDEFAULT_INSTALL_PATH=/app/data or
> -DCMAKE_INSTALL_DATADIR=/app/data during CMake configuration in two
> different test builds (as those two options were appearing in
> CMakeLists.txt and the surrounding lines seemed to indicate that they
> were doing what I was trying to achieve).
>
> Yet, none of the two did change anything (though I didn't try using both
> together yet) regarding to the KiCad system paths. This is what I see in
> "Preferences->Configure Paths" with or without redefining the CMake
> options:
>
> KICAD_SYMBOL_DIR=/app/share/kicad/library
> KICAD_TEMPLATE_DIR=/app/share/kicad/template
> KISY3DSMOD=/app/share/kicad/modules/packages3d
> KISYSMOD=/app/share/kicad/modules
>
> I saw further CMake options which are all marked as advanced, thus I did
> not try them yet.
>
> Is there a way to achieve what I want to do with the current set of
> CMake switches or would this need deeper plumbing?
>
>
> Here's my current CMake setup:
>
> "config-opts": [
> "-DBOOST_ROOT=/app",
> "-DDEFAULT_INSTALL_PATH=/app/data",
> "-DGLEW_INCLUDE_DIR=/app/include/GL",
> "-DOPENGL_glu_LIBRARY=/app/lib/libGLU.so",
> "-DKICAD_BUILD_QA_TESTS=OFF",
> "-DKICAD_SCRIPTING_PYTHON3=ON",
> "-DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON"
> ]
>
> (--prefix=/app is the default in flatpak land).
>
>
> And version info:
>
> Application: KiCad
> Version: 5.1.6, release build
> Libraries:
> wxWidgets 3.0.5
> libcurl/7.65.3-DEV GnuTLS/3.6.13 (NSS/3.46.1) (OpenSSL/1.1.1d)
> zlib/1.2.11 libidn2/2.2.0
> Platform: Linux 5.6.14-arch1-1 x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+
> 3.24
> Boost: 1.66.0
> OpenCASCADE Community Edition: 6.9.1
> Curl: 7.65.3-DEV
> Compiler: GCC 9.2.0 with C++ ABI 1013
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=ON
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_USE_OCC=OFF
> KICAD_SPICE=ON
>
>
>
> Cheers,
> Johannes
>
>
> [1] To quote a user: "KiCad is AFAIK the biggest flatpak on Flathub" (
>
> https://github.com/flathub/org.kicad_pcb.KiCad/issues/19#issuecomment-632761066
> )
>
>
> ___
> 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] KiCad website

[Ian McInerney]

We should make sure that both are working though. It is common for people
to put the www in front of the URL.

-Ian

On Sat, May 23, 2020 at 3:31 PM jp charras  wrote:

> Le 23/05/2020 à 15:26, Wayne Stambaugh a écrit :
> > I don't know if it was intentional (I'm guessing not) but the KiCad
> > website looks completely different today on Firefox and Chrome (see
> > attached screen shot).  Clicking on the topic links doesn't even take me
> > to the correct page.
> >
> > Thanks,
> >
> > Wayne
> >
>
> Be sure you are using:
> https://kicad-pcb.org
> and not the old link https://www.kicad-pcb.org
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] no broken default fp-lib-table, removed footprint library

[Ian McInerney]

I think the question is, do the other repos actually need to do "release
candidates." We switched to the release candidate paradigm for the main
code repo because for the initial releases in the 5.1 series it seemed like
as soon as a new version was released a critical regression was found that
resulted in crashes for users, so a new release was spun very quickly. The
release candidate is a time when the commits to the 5.1 branch are limited
in scope to critical fixes only, and we call it a rc to get more user
feedback.

This also provides a good time for the translators to update parts, since
there shouldn't be any changes to the strings (so it essentially becomes a
string freeze as well). Is there really a benefit for doing a release
candidate for the docs and translations? I don't think there is, but if
people do want it then we need to introduce a new milestone in the main
code repo for doing a string freeze before we do a release candidate so
that the translations have time to catch up before the release candidate.

-Ian

On Sun, May 17, 2020 at 5:45 PM Nick Østergaard  wrote:

> On Sun, 17 May 2020 at 11:24, Carsten Schoenert 
> wrote:
> >
> > Hello Wayne,
> >
> > Am 14.05.20 um 18:43 schrieb Wayne Stambaugh:
> > > Carsten,
> > >
> > > What information do you need from KiCad.  Does Debian (or any other
> > > disto) have recommendations for upstream projects to help packagers?
> >
> > Debian has some dedicated information for upstream projects and coders
> > of course.
> >
> > https://wiki.debian.org/UpstreamGuide
> >
> > But these are all plain technically points written down. You will not
> > find any issues for the main KiCad application based on the list from
> > the Debian wiki and that's good.
> >
> > > Packaging is import to the project so if we can package devs lives a
> bit
> > > easier, I'm willing to consider ways to do so.
> >
> > We are going in loops so I currently don't want to put more energy into
> > a for me pointless discussion. And it's also disappointing and not
> > encouraging if people saying they haven't read my complete message(s) ...
> >
> > The main point is that projects simply should provide as much
> > information and communication as possible about the new versions they
> > provide. Distributions need always to think about how intrusive
> > modifications are, that's mainly a simple risk analysis.
> >
> > What do you think if a contributor is providing a 1000 line patch for
> > KiCad and you have no further information than that pure diff?
> > That's mainly the situation for me regarding to symbols and footprints.
> >
> > The release of a new KiCad version can be improved in my eyes by doing a
> > better job of release managing. For example some parts do create release
> > candidates some don't. Makes it difficult for me to do packaging
> > preparations as the final version of the kicad package says then nothing
> > about the real combined l10n and documentation parts as I need to pick
> > up some random versions. Also not helpful if users bring up issues as
> > you need to figure out against what commits these are for real.
> >
>
> There were probably no -rc tag for i18n and the doc, but I didn't see
> you pointing it out in time either.
>
> > --
> > Regards
> > Carsten
> >
> > ___
> > 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

[Kicad-developers] Fix for Boost 1.73 Compilation Error

[Ian McInerney]

If you are going to be compiling the 5.1.6 release against Boost 1.73, you
will probably need to backport the patch given in
https://gitlab.com/kicad/code/kicad/-/merge_requests/207 to the branch. I
have already cherry-picked it to the 5.1 branch, so the head of both 5.1
and master should compile on it with no patching - only the
released version may have issues.

   - There are a few Linux distributions currently packaging up Boost 1.73,
   so please be aware this may be an issue (Steve, you will probably need to
   add this to Fedora's Rawhide build soon).
   - Homebrew doesn't have it yet, but there is a PR in progress to bump
   the version: https://github.com/Homebrew/homebrew-core/pull/53874.


-Ian
___
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] 5.1 CMake Version Bump to 3.2

[Ian McInerney]

FYI: I have just merged
https://gitlab.com/kicad/code/kicad/-/merge_requests/198 into 5.1 which
bumps the minimum CMake version required from 3.0 to 3.2 so that we can fix
https://gitlab.com/kicad/code/kicad/-/issues/4209. We discussed the version
bump at length inside
https://gitlab.com/kicad/code/kicad/-/merge_requests/167, and decided to
only bump the minimum needed to fix the issue (which is to 3.2), and all
our supported platforms have CMake versions larger than this (and we
maintain compatibility with Ubuntu 16.04 for those users still using it).

A similar bump happened on Master a week or so ago, and no problems have
been reported because of it.

-Ian
___
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] 5.1.6 Release Update

[Ian McInerney]

Considering that there are also changes to the library in the releases,
does it make sense to package the light releases for the versioned
(non-testing/nightly) releases. I would think that in this case users would
want the updated libraries.

-Ian

On Fri, May 15, 2020 at 12:33 PM Andrew Lutsenko 
wrote:

> Windows 5.1.6 builds seem to be uploaded as well but no lite release?
> https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/stable/
>
> On Fri, May 15, 2020 at 2:59 AM Jean-Samuel Reynaud 
> wrote:
>
>> KiCad 5.1.6 is now available on Ubuntu PPA since 2 days.
>>
>> And some statistics on May 2020:
>>
>> By Ubuntu version (only for 5.1 download):
>> Focal (20.04)  499.00 ( 8%)
>> Eoan (19.10)   389.00 ( 6%)
>> Bionic (18.04)4753.00 (76%)
>> Xenial (16.04) 582.00 ( 9%)
>> Totals6223.00
>>
>>
>>
>>
>>
>> Le 15/05/2020 à 04:56, Adam Wolf a écrit :
>> > Mac builds have been uploaded, just the same as all the other 5.1
>> > releases.  Have a good weekend, everyone!
>> >
>> > On Wed, May 13, 2020 at 3:48 PM Kevin Cozens  wrote:
>> >>
>> >> On 2020-05-13 4:11 p.m., Rene Pöschl wrote:
>> >>> You must pull the tagged commit otherwise you get whatever got merged
>> last.
>> >>
>> >> Ok, thank you. With the v6 libraries no longer compatible with v5 I was
>> >> expecting to see a branch, not just a tag. Does this mean the v5
>> libraries
>> >> are no longer being maintained or will they be branched later if a
>> change is
>> >> required to a v5 library?
>> >>
>> >> --
>> >> Cheers!
>> >>
>> >> Kevin.
>> >>
>> >> http://www.ve3syb.ca/   | "Nerds make the shiny things
>> that
>> >> https://www.patreon.com/KevinCozens | distract the mouth-breathers,
>> and
>> >>  | that's why we're powerful"
>> >> Owner of Elecraft K2 #2172  |
>> >> #include  | --Chris Hardwick
>> >>
>> >> ___
>> >> 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] Compile problem with Fedora 32

[Ian McInerney]

If you are using Fedora 32, then you shouldn't be using Python 2 (they
deprecated it in this release with limited exceptions...), and it
definitely doesn't have a Python2 version of wxPython.

-Ian

On Fri, May 15, 2020 at 11:27 AM Simon Richter 
wrote:

> Hi,
>
> On 14.05.20 07:28, victor tejada wrote:
>
> > Hello, guys, I tried to compile kicad source code on fedora 32 but the
> > error is
> > "ImportError: No module named wx
> > CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
> >  wxPython/Phoenix does not appear to be installed on the system
> > Call Stack (most recent call first):
> >  CMakeLists.txt:740 (find_package)"
> > so wxPython 4.0.1 is installed on my pc.
>
> Check that it's using the Python version that wxPython was compiled
> against. IIRC KiCad still selects Python 2 unless told to use Python 3,
> so if you have wxPython for Python 3, it will not be usable.
>
> On any modern distro, you probably need to configure with
>
> -DKICAD_SCRIPTING_PYTHON3:BOOL=ON
> -DKICAD_SCRIPTING_WXPYTHON:BOOL=ON
> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX:BOOL=ON
>
>Simon
>
> ___
> 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] 5.1.6 Release Update

[Ian McInerney]

The stable packages might not have been touched since we made this switch
after releasing 5.1.5 (at least the Fedora package still has launchpad in
it). But I don't think that is a good reason to still use it, the scripts
should be updated with this release.

-Ian

On Mon, May 11, 2020 at 8:00 PM Wayne Stambaugh 
wrote:

> It would make my life easier so I am all for that.  I don't know if any
> of our package build scripts still pull from launchpad.  That's why I
> asked.
>
> On 5/11/20 2:55 PM, Ian McInerney wrote:
> > I would suggest we switch to GitLab as the single source of truth for
> > the code tarballs for this release.
> >
> > On Mon, May 11, 2020 at 7:25 PM Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > Is there any reason that I need to continue uploading stable source
> > archives to launchpad now that you can do this directly from gitlab?
> >
> > On 5/10/20 12:07 PM, Wayne Stambaugh wrote:
> > > Since we are only a week away (Friday) from the proposed 5.1.6
> release
> > > date and none of the critical bugs seem to be reproducible,  I
> would
> > > like to tag the 5.1 branch tomorrow along with the other repos so
> we
> > > have time to allow the package builders to complete and website
> > download
> > > page to be updated by Friday so I can make the official
> announcement.
> > > Is there anything else holding us back from this before I tag
> 5.1.6 in
> > > the repo?
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto: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] 5.1.6 Release Update

[Ian McInerney]

I would suggest we switch to GitLab as the single source of truth for the
code tarballs for this release.

On Mon, May 11, 2020 at 7:25 PM Wayne Stambaugh 
wrote:

> Is there any reason that I need to continue uploading stable source
> archives to launchpad now that you can do this directly from gitlab?
>
> On 5/10/20 12:07 PM, Wayne Stambaugh wrote:
> > Since we are only a week away (Friday) from the proposed 5.1.6 release
> > date and none of the critical bugs seem to be reproducible,  I would
> > like to tag the 5.1 branch tomorrow along with the other repos so we
> > have time to allow the package builders to complete and website download
> > page to be updated by Friday so I can make the official announcement.
> > Is there anything else holding us back from this before I tag 5.1.6 in
> > the repo?
> >
> > Cheers,
> >
> > Wayne
> >
>
> ___
> 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