Re: [Kicad-developers] Minimum Boost version

[Mark Roszko]

>  I was not aware that this attitude has changed.

Well it's just the way I see it, heck I may be wrong but it isn't really an
attitude as much as upstreams wanting to continuously deliver the latest
versions without distro repo politics. In some cases, there are both distro
and official upstream releases.

On Wed, Oct 23, 2019 at 12:43 PM Wayne Stambaugh 
wrote:

> On 10/23/2019 10:52 AM, Mark Roszko wrote:
> > Can there ever be a statement written somewhere that says "KiCad strives
> > to support Ubuntu LTS Latest and Previous, Debian Latest, etc"?
> > Basically defining what is considered "older Linux distros" vs
> "supported".
>
> This is always going to be an issue but I think we can do a better job
> of defining which distros we support.  AFAIK, the stable version
> currently builds on all of the Linux distros listed.  We just need to be
> clear that this only applies to the current stable release and that
> development branch may not build.
>
> >
> > KiCad is unique in not building linux packages directly compared to most
> > other major pieces of software so that line has never been defined
> clearly.
>
> I thought most Linux distros packaged software in accordance with the
> preferred packaging requirements for each distro.  It used to be the
> case that distros frowned upon externally build packages because there
> was always the distinct possibly that they would break something in ways
> that were difficult to resolve.  I was not aware that this attitude has
> changed.  Too be honest, I would rather the distros build KiCad
> according to their requirements.  I would think the manpower for us to
> provide packages for every linux distro would be overwhelming.
>
> >
> > On Wed, Oct 23, 2019 at 9:28 AM Wayne Stambaugh  > > wrote:
> >
> > One thing we don't specify on the system requirements page on the
> KiCad
> > website is whether or not this applies to the current stable release
> or
> > the nightly builds.  Since we don't specify this, I can see how users
> > would assume that it's all versions of KiCad.  Perhaps we should note
> > that this is only applicable to the current stable version and that
> > nightly builds may not support older Linux distributions due to the
> > availability of dependency library versions.  I don't think it's
> > reasonable to expect the latest development version of KiCad to
> continue
> > to support legacy Linux distros.  The current LTS release of Ubuntu
> is
> > 18.04 which supports boost version 1.65.  I think attempting to
> support
> > nightly builds on Ubuntu 16.04 is going to continue cause headaches
> as
> > time goes on.  If no one objects, I will update the system
> requirements
> > page accordingly.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 10/23/2019 1:39 AM, Eeli Kaikkonen wrote:
> > > It should also be noted that 20.04 will be the next LTS release of
> > > Ubuntu. This means that there will be two post-16.04 LTS releases
> out
> > > there before KiCad 6 will be released (I'm not *that* optimistic
> :) ).
> > > Is it really worth it to actively support 3 different LTS
> releases? It
> > > doesn't sound very realistic. How many users would actually be
> > affected
> > > if KiCad 6 wouldn't be available for 16.04? 1000s? 100s? 10? And
> > if they
> > > continue with 16.04 until 2021, why would they need to switch to
> > KiCad 6
> > > before that?
> > >
> > > Eeli Kaikkonen
> > >
> > > ke 23. lokak. 2019 klo 3.05 Seth Hillbrand (s...@kipro-pcb.com
> > 
> > > >)
> kirjoitti:
> > >
> > > On 2019-10-22 16:06, Ian McInerney wrote:
> > >
> > >> I dug into the website history and apparently the original
> intent
> > >> should have been to support 16.04 LTS until its standard
> support
> > >> ends in 2021
> > >>
> >  (
> https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782
> ).
> > >> Since we haven't actually used any code from the newer Boost
> > >> version (that we weren't already using), we should probably
> back
> > >> out the change and also update the website with the correct
> > Ubuntu
> > >> LTS support date. It looks like that will make it so we can't
> > >> update to 1.59 until 2021 then.
> > >>
> > >
> > > Hi Ian-
> > >
> > > I did write that.  In retrospect, I'm not sure that the
> > sentiment is
> > > correct.  One of the things we are attempting to do is focus
> our
> > > primary efforts where they will have the largest impact for our
> > > users.  Toward that end, we were attempting (in the post KiCon
> > > meeting) to define where that cut off should be.  We kind of
> > > arbitrary picked "vendor 

Re: [Kicad-developers] [PATCH] Three new source types added to DIALOG_SPICE_MODEL

[Evan Shultz]

Hi,

Apologies for the slight tangent...

When I submitted symbols for all V and I sources supported by ngspice at
https://github.com/KiCad/kicad-symbols/pull/1473, I created a
simulation schematic to show off their output waveforms. Some of them can
use the source control features here. I thought this might be helpful when
testing this patch

It may also be useful to include the SPICE source simulation as a demo. If
so, should I make a bug on launchpad?

On Sun, Oct 20, 2019 at 2:00 PM Sylwester Kocjan  wrote:

> On 20/10/2019 20:53, Seth Hillbrand wrote:
> > On 2019-10-20 08:36, Sylwester Kocjan wrote:
> >> Hi,
> >>
> >> Here is a patch with three additional source models implemented: SFFM,
> >> AM and Random.
> >>
> >> I hope this looks ok, cause I had troubles with configuring
> >> clang-format on Windows. If no, I can correct.
> >>
> >> 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
> >
> > Hi Sylwester-
> >
> > There is something odd with your patch.  See the attached screenshot.  I
> > cannot apply this to test as there are a number of unknown characters at
> > the end of lines and the end of the file.
> >
> > -Seth
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
>
> Hi Seth,
>
> You are right, this patch is quite big and was truncated by mail
> servers, something gone wrong during sending mail. I've put it to google
> drive:
>
>
> https://drive.google.com/file/d/1x_YDsIw6FhgJFEsDgteEl5L5PGwSsCiz/view?usp=sharing
>
>
> 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] [PATCH] SPICE .option confused with .op simulation

[Sylwester Kocjan]

Hi,

Thanks for pointing that. Maybe I'll try to prepare some tests in boost 
for symulation to test my changes better.


However, I'd like to share my opinion during this occasion. I think that 
parsing SPICE commands in KiCad is too much effort. Holger Vogt said 
once that this is very difficult because SPICE language was designed 
before lex become popular. I believe optimal way for simulation 
would be following:

- strive to handle all types of simulations on DIALOG_SIM_SETTINGS tabs
- get rid of user command in schematic sheet
- two additional text fields on simulation options: pre- and post-sim 
user directives

- passing these user directives directly to output netlist
- pre-sim can be for example specific .options, post-sim could be .meas
either of them can be .control ... .endc
- ideally if all these settings could be saved in file and loaded from menu

Sure, that's a lot of work but hopefully I can help with some of this.

Best regards,
Sylwester

On 23/10/2019 15:39, Seth Hillbrand wrote:

On 2019-10-22 23:35, Maciej Suminski wrote:

Hi Sylwester,

I admit I have not checked your patch in action, but it seems that it
will not accept ".op" command, unless it is followed by a space. Since
".op" does not take any parameters, I presume it is a rare case when one
adds an extra space after the command.

Regards,
Orson


Thanks Orson!  You are right, it was skipping the unpadded .op.  I 
missed this as the .tran command does print the DC operating point and I 
was checking in a multi-command circuit.  Good catch.  I've fixed up the 
command parsing to ensure we pad the command lines.


This does bring up, however, that our simulator does not handle .op 
well.  It won't probe the values or print them easily.  LTSpice prints 
the DC Operating Point table for all nets after running in this mode. 
Not that LTSpice is the model of usability but there may be something to 
this.


-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



___
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.5 release status

[Ian McInerney]

This looks to be Debian specific. The build logs for the most recent Fedora
build [1] show -DNDEBUG in the flags but the Debian build log [2] does not.
It looks like the release type is not being specified properly in the
Debian packaging since they are forcing the release type to None (they use
custom flags and do not want CMake to actually set any flags itself
apparently [3, 4]). Therefore, we will need to add the flag in manually.

Carsten, I just made a merge request on the Debian packaging repo to do
this. Can you take a look at it and comment? After this change, I see the
-DNDEBUG appearing in the compile command when I do a local build on my
machine.

-Ian

[1]
https://kojipkgs.fedoraproject.org//packages/kicad/5.1.4/5.fc32/data/logs/x86_64/build.log
[2]
https://buildd.debian.org/status/fetch.php?pkg=kicad=amd64=5.1.4%2Bdfsg1-2=1570912510=0
[3]
https://github.com/Debian/debhelper/blob/master/lib/Debian/Debhelper/Buildsystem/cmake.pm
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701233

On Wed, Oct 23, 2019 at 4:42 PM Wayne Stambaugh 
wrote:

> I see -DNDEBUG defined in windows release builds where CMake is
> configured with -DCMAKE_BUILD_TYPE=Release.  Is this not the case with
> Linux and/or macos?  Did we make the mistake of doing something like:
>
> set( CMAKE_COMPILER_FLAGS "-foo" )
>
> instead of:
>
> set( CMAKE_COMPILER_FLAGS "${CMAKE_COMPILER_FLAGS} -foo" )
>
> in one of the none windows build code paths?  Doing this will wipe out
> any compiler flags set by CMake.
>
> On 10/23/2019 11:16 AM, Ian McInerney wrote:
> > It looks like the build flags for KiCad are not getting NDEBUG defined
> > to remove the assertions. We should add -DNDEBUG to the flags passed
> > into CMake alongside the Debian flags.
> >
> > -Ian
> >
> > On Wed, Oct 23, 2019 at 6:38 AM Carsten Schoenert
> > mailto:c.schoen...@t-online.de>> wrote:
> >
> > Hello Seth,
> >
> > Am 22.10.19 um 18:10 schrieb Seth Hillbrand:
> > > Why do you have "hardening=+all" enabled?
> >
> > mostly because this is the default for building binary packages with
> > enabled hardening.
> >
> > https://wiki.debian.org/Hardening#Using_Hardening_Options
> >
> > > This is likely where the assertions are happening.  We might
> consider
> > >  "hardening=-all,+format,+fortify"
> > I'm not that deep into the details here or at least would need to
> keep
> > reading some stuff. But as far I've understand the hardening flags
> > should have no effect on this.
> >
> > Maybe Simon can give some enlightenment on this?
> >
> > --
> > Regards
> > Carsten Schoenert
> >
> > ___
> > 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] [Patch] Fix "unit_test_utils" Build When Using Boost 1.59

[Wayne Stambaugh]

Hi Michael,

Is this patch for master, 5.1, or both?

Cheers,

Wayne

On 10/23/2019 12:26 PM, Michael Smith wrote:
> Hi,
> 
> Below is a patch which fixes "unit_test_utils" build when using Boost 1.59 .
> 
> Best regards,
> Michael
> 
> From d4764f49bd756f2b0cfa6bf529bc4179229f8f2d Mon Sep 17 00:00:00 2001
> From: Michael Smith  >
> Date: Wed, 23 Oct 2019 16:50:54 +0200
> Subject: [PATCH] Fixed an issue which prevented unit_test_utils from being
> buildable with Boost 1.59
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="2.7.4"
> 
> This is a multi-part message in MIME format.
> --2.7.4
> Content-Type: text/plain; charset=UTF-8; format=fixed
> Content-Transfer-Encoding: 8bit
> 
> ---
> qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h | 1 +
> 1 file changed, 1 insertion(+)
> 
> 
> --2.7.4
> Content-Type: text/x-patch;
> name="0001-Fixed-an-issue-which-prevented-unit_test_utils-from-.patch"
> Content-Transfer-Encoding: 8bit
> Content-Disposition: attachment;
> filename="0001-Fixed-an-issue-which-prevented-unit_test_utils-from-.patch"
> 
> diff --git
> a/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
> b/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
> index 08ae0b9..6f99dcb 100644
> --- a/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
> +++ b/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
> @@ -26,6 +26,7 @@
> 
> #include 
> #include 
> +#include 
> 
> #include 
> 
> 
> --2.7.4--
> 
> 
> 
> 
> ___
> 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] Minimum Boost version

[Wayne Stambaugh]

On 10/23/2019 10:52 AM, Mark Roszko wrote:
> Can there ever be a statement written somewhere that says "KiCad strives
> to support Ubuntu LTS Latest and Previous, Debian Latest, etc"?
> Basically defining what is considered "older Linux distros" vs "supported".

This is always going to be an issue but I think we can do a better job
of defining which distros we support.  AFAIK, the stable version
currently builds on all of the Linux distros listed.  We just need to be
clear that this only applies to the current stable release and that
development branch may not build.

> 
> KiCad is unique in not building linux packages directly compared to most
> other major pieces of software so that line has never been defined clearly.

I thought most Linux distros packaged software in accordance with the
preferred packaging requirements for each distro.  It used to be the
case that distros frowned upon externally build packages because there
was always the distinct possibly that they would break something in ways
that were difficult to resolve.  I was not aware that this attitude has
changed.  Too be honest, I would rather the distros build KiCad
according to their requirements.  I would think the manpower for us to
provide packages for every linux distro would be overwhelming.

> 
> On Wed, Oct 23, 2019 at 9:28 AM Wayne Stambaugh  > wrote:
> 
> One thing we don't specify on the system requirements page on the KiCad
> website is whether or not this applies to the current stable release or
> the nightly builds.  Since we don't specify this, I can see how users
> would assume that it's all versions of KiCad.  Perhaps we should note
> that this is only applicable to the current stable version and that
> nightly builds may not support older Linux distributions due to the
> availability of dependency library versions.  I don't think it's
> reasonable to expect the latest development version of KiCad to continue
> to support legacy Linux distros.  The current LTS release of Ubuntu is
> 18.04 which supports boost version 1.65.  I think attempting to support
> nightly builds on Ubuntu 16.04 is going to continue cause headaches as
> time goes on.  If no one objects, I will update the system requirements
> page accordingly.
> 
> Cheers,
> 
> Wayne
> 
> On 10/23/2019 1:39 AM, Eeli Kaikkonen wrote:
> > It should also be noted that 20.04 will be the next LTS release of
> > Ubuntu. This means that there will be two post-16.04 LTS releases out
> > there before KiCad 6 will be released (I'm not *that* optimistic :) ).
> > Is it really worth it to actively support 3 different LTS releases? It
> > doesn't sound very realistic. How many users would actually be
> affected
> > if KiCad 6 wouldn't be available for 16.04? 1000s? 100s? 10? And
> if they
> > continue with 16.04 until 2021, why would they need to switch to
> KiCad 6
> > before that?
> >
> > Eeli Kaikkonen
> >
> > ke 23. lokak. 2019 klo 3.05 Seth Hillbrand (s...@kipro-pcb.com
> 
> > >) kirjoitti:
> >
> >     On 2019-10-22 16:06, Ian McInerney wrote:
> >
> >>     I dug into the website history and apparently the original intent
> >>     should have been to support 16.04 LTS until its standard support
> >>     ends in 2021
> >>   
>  
> (https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782).
> >>     Since we haven't actually used any code from the newer Boost
> >>     version (that we weren't already using), we should probably back
> >>     out the change and also update the website with the correct
> Ubuntu
> >>     LTS support date. It looks like that will make it so we can't
> >>     update to 1.59 until 2021 then.
> >>      
> >      
> >     Hi Ian-
> >      
> >     I did write that.  In retrospect, I'm not sure that the
> sentiment is
> >     correct.  One of the things we are attempting to do is focus our
> >     primary efforts where they will have the largest impact for our
> >     users.  Toward that end, we were attempting (in the post KiCon
> >     meeting) to define where that cut off should be.  We kind of
> >     arbitrary picked "vendor supported" as it seemed reasonable.
> >      
> >     I now think we should tighten that a bit more for the Linux
> >     distributions.  Under MSW/Mac, we compile or have rolling updates
> >     for most of our own dependencies.  This allows us to ensure system
> >     compatibility but not worry about library compatibility.  The
> Linux
> >     library system is different and holds back updates.
> >      
> >     So, why would we want to update the boost libraries and what
> does it
> >     gain us?  The 

Re: [Kicad-developers] 5.1.5 release status

[Wayne Stambaugh]

No problem.  Unless something critical happens between now and then, I
will tag the 5.1 branch Friday around 12PM EDT.  If anyone has any last
minute bug fixes to commit to the 5.1 branch, now would be a good time.

Cheers,

Wayne

On 10/23/2019 10:31 AM, Adam Wolf wrote:
> It may take me another few days to get the wx-built-without-debug on
> releases setup in kicad-macos-builder, but that won't be source
> changes.  I can get it ready and then use the rc code for it, and get
> folks to test.
> 
> Adam
> 
> On Wed, Oct 23, 2019 at 8:50 AM Wayne Stambaugh  wrote:
>>
>> Now that JP fixed lp:1849289[1], is there anything else that needs to be
>> fixed before I tag rc1?  If not, I will tag it Friday.  That means that
>> we will be in a string freeze until the 5.1.5 release and that no new
>> bug fixes other than bugs that already affect rc1 (including bugs moved
>> to 5.1.6) cannot be committed without first discussing it on the dev
>> mailing list.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]: https://bugs.launchpad.net/kicad/+bug/1849289
>>
>> On 10/21/2019 3:11 PM, Ian McInerney wrote:
>>> There were two bugs still on the 5.1.5 milestone [1], [2] that related
>>> to the editing of H/V/45 constrained polygons. I have bumped those to
>>> 6.0 now. Should we reopen and move [3] and [4] to 6.0 so that we
>>> actually fix the issues there?
>>>
>>> -Ian
>>>
>>> [1] https://bugs.launchpad.net/kicad/+bug/1842055
>>> [2] https://bugs.launchpad.net/kicad/+bug/1842195
>>> [3] https://bugs.launchpad.net/kicad/+bug/1847722
>>> [4] https://bugs.launchpad.net/kicad/+bug/1846029
>>>
>>> On Mon, Oct 21, 2019 at 7:02 PM Seth Hillbrand >> > wrote:
>>>
>>> On 2019-10-21 10:52, Ian McInerney wrote:
>>>
>>> > Seth,
>>> >
>>> > Just to clarify, for 5.1.5 (and future 5.1 releases), the H/V/45 is
>>> > only available during initial zone creation and is not going to be
>>> > active for editing the lines after creation? If this is the case, I
>>> > will push the bugs for this into the 6.0 milestone, so they can be
>>> > addressed there.
>>> >
>>> > -Ian
>>>
>>> That is correct.  I've already reset that bug[1].  But if you see
>>> others
>>> that relate to it, feel free to mark the dupes.
>>>
>>> -Seth
>>>
>>> Seth Hillbrand
>>> KiCad Services Corporation
>>> https://www.kipro-pcb.com
>>> +1 530 302 5483 | +1 212 603 9372
>>>
>>> [1] https://bugs.launchpad.net/kicad/+bug/1833673
>>>
>>>
>>> ___
>>> 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] [Patch] Fix "unit_test_utils" Build When Using Boost 1.59

[Michael Smith]

Hi,

Below is a patch which fixes "unit_test_utils" build when using Boost 1.59 .

Best regards,
Michael

From d4764f49bd756f2b0cfa6bf529bc4179229f8f2d Mon Sep 17 00:00:00 2001
From: Michael Smith 
Date: Wed, 23 Oct 2019 16:50:54 +0200
Subject: [PATCH] Fixed an issue which prevented unit_test_utils from being
buildable with Boost 1.59
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"

This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h | 1 +
1 file changed, 1 insertion(+)

--2.7.4
Content-Type: text/x-patch; 
name="0001-Fixed-an-issue-which-prevented-unit_test_utils-from-.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; 
filename="0001-Fixed-an-issue-which-prevented-unit_test_utils-from-.patch"

diff --git a/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h 
b/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
index 08ae0b9..6f99dcb 100644
--- a/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
+++ b/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h
@@ -26,6 +26,7 @@

#include 
#include 
+#include 

#include 

--2.7.4--___
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.5 release status

[Wayne Stambaugh]

I see -DNDEBUG defined in windows release builds where CMake is
configured with -DCMAKE_BUILD_TYPE=Release.  Is this not the case with
Linux and/or macos?  Did we make the mistake of doing something like:

set( CMAKE_COMPILER_FLAGS "-foo" )

instead of:

set( CMAKE_COMPILER_FLAGS "${CMAKE_COMPILER_FLAGS} -foo" )

in one of the none windows build code paths?  Doing this will wipe out
any compiler flags set by CMake.

On 10/23/2019 11:16 AM, Ian McInerney wrote:
> It looks like the build flags for KiCad are not getting NDEBUG defined
> to remove the assertions. We should add -DNDEBUG to the flags passed
> into CMake alongside the Debian flags.
> 
> -Ian
> 
> On Wed, Oct 23, 2019 at 6:38 AM Carsten Schoenert
> mailto:c.schoen...@t-online.de>> wrote:
> 
> Hello Seth,
> 
> Am 22.10.19 um 18:10 schrieb Seth Hillbrand:
> > Why do you have "hardening=+all" enabled?
> 
> mostly because this is the default for building binary packages with
> enabled hardening.
> 
> https://wiki.debian.org/Hardening#Using_Hardening_Options
> 
> > This is likely where the assertions are happening.  We might consider
> >  "hardening=-all,+format,+fortify"
> I'm not that deep into the details here or at least would need to keep
> reading some stuff. But as far I've understand the hardening flags
> should have no effect on this.
> 
> Maybe Simon can give some enlightenment on this?
> 
> -- 
> Regards
> Carsten Schoenert
> 
> ___
> 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] 5.1.5 release status

[Ian McInerney]

It looks like the build flags for KiCad are not getting NDEBUG defined to
remove the assertions. We should add -DNDEBUG to the flags passed into
CMake alongside the Debian flags.

-Ian

On Wed, Oct 23, 2019 at 6:38 AM Carsten Schoenert 
wrote:

> Hello Seth,
>
> Am 22.10.19 um 18:10 schrieb Seth Hillbrand:
> > Why do you have "hardening=+all" enabled?
>
> mostly because this is the default for building binary packages with
> enabled hardening.
>
> https://wiki.debian.org/Hardening#Using_Hardening_Options
>
> > This is likely where the assertions are happening.  We might consider
> >  "hardening=-all,+format,+fortify"
> I'm not that deep into the details here or at least would need to keep
> reading some stuff. But as far I've understand the hardening flags
> should have no effect on this.
>
> Maybe Simon can give some enlightenment on this?
>
> --
> Regards
> Carsten Schoenert
>
> ___
> 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] Minimum Boost version

[Mark Roszko]

Can there ever be a statement written somewhere that says "KiCad strives to
support Ubuntu LTS Latest and Previous, Debian Latest, etc"?
Basically defining what is considered "older Linux distros" vs "supported".

KiCad is unique in not building linux packages directly compared to most
other major pieces of software so that line has never been defined clearly.

On Wed, Oct 23, 2019 at 9:28 AM Wayne Stambaugh 
wrote:

> One thing we don't specify on the system requirements page on the KiCad
> website is whether or not this applies to the current stable release or
> the nightly builds.  Since we don't specify this, I can see how users
> would assume that it's all versions of KiCad.  Perhaps we should note
> that this is only applicable to the current stable version and that
> nightly builds may not support older Linux distributions due to the
> availability of dependency library versions.  I don't think it's
> reasonable to expect the latest development version of KiCad to continue
> to support legacy Linux distros.  The current LTS release of Ubuntu is
> 18.04 which supports boost version 1.65.  I think attempting to support
> nightly builds on Ubuntu 16.04 is going to continue cause headaches as
> time goes on.  If no one objects, I will update the system requirements
> page accordingly.
>
> Cheers,
>
> Wayne
>
> On 10/23/2019 1:39 AM, Eeli Kaikkonen wrote:
> > It should also be noted that 20.04 will be the next LTS release of
> > Ubuntu. This means that there will be two post-16.04 LTS releases out
> > there before KiCad 6 will be released (I'm not *that* optimistic :) ).
> > Is it really worth it to actively support 3 different LTS releases? It
> > doesn't sound very realistic. How many users would actually be affected
> > if KiCad 6 wouldn't be available for 16.04? 1000s? 100s? 10? And if they
> > continue with 16.04 until 2021, why would they need to switch to KiCad 6
> > before that?
> >
> > Eeli Kaikkonen
> >
> > ke 23. lokak. 2019 klo 3.05 Seth Hillbrand (s...@kipro-pcb.com
> > ) kirjoitti:
> >
> > On 2019-10-22 16:06, Ian McInerney wrote:
> >
> >> I dug into the website history and apparently the original intent
> >> should have been to support 16.04 LTS until its standard support
> >> ends in 2021
> >> (
> https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782
> ).
> >> Since we haven't actually used any code from the newer Boost
> >> version (that we weren't already using), we should probably back
> >> out the change and also update the website with the correct Ubuntu
> >> LTS support date. It looks like that will make it so we can't
> >> update to 1.59 until 2021 then.
> >>
> >
> > Hi Ian-
> >
> > I did write that.  In retrospect, I'm not sure that the sentiment is
> > correct.  One of the things we are attempting to do is focus our
> > primary efforts where they will have the largest impact for our
> > users.  Toward that end, we were attempting (in the post KiCon
> > meeting) to define where that cut off should be.  We kind of
> > arbitrary picked "vendor supported" as it seemed reasonable.
> >
> > I now think we should tighten that a bit more for the Linux
> > distributions.  Under MSW/Mac, we compile or have rolling updates
> > for most of our own dependencies.  This allows us to ensure system
> > compatibility but not worry about library compatibility.  The Linux
> > library system is different and holds back updates.
> >
> > So, why would we want to update the boost libraries and what does it
> > gain us?  The original bump was to allow unit tests.  During v6, I
> > would also like to utilize the UUID library from 1.60 as many of the
> > feature we plan will require GUID at least.
> >
> > This doesn't preclude using KiCad on 16.04.  It just requires
> > someone to package a boost ppa.  There are a few out there that
> > could be used as baselines for this.
> >
> > -Seth
> >
> >
> > KiCad Services Corporation KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬ 
> > Davis, CA
> > www.kipro-pcb.com i...@kipro-pcb.com
> > 
> > https://twitter.com/KiProEDA 
> > https://www.linkedin.com/company/kicad
> > 
> >
> > ___
> > 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 : 

Re: [Kicad-developers] 5.1.5 release status

[Adam Wolf]

It may take me another few days to get the wx-built-without-debug on
releases setup in kicad-macos-builder, but that won't be source
changes.  I can get it ready and then use the rc code for it, and get
folks to test.

Adam

On Wed, Oct 23, 2019 at 8:50 AM Wayne Stambaugh  wrote:
>
> Now that JP fixed lp:1849289[1], is there anything else that needs to be
> fixed before I tag rc1?  If not, I will tag it Friday.  That means that
> we will be in a string freeze until the 5.1.5 release and that no new
> bug fixes other than bugs that already affect rc1 (including bugs moved
> to 5.1.6) cannot be committed without first discussing it on the dev
> mailing list.
>
> Cheers,
>
> Wayne
>
> [1]: https://bugs.launchpad.net/kicad/+bug/1849289
>
> On 10/21/2019 3:11 PM, Ian McInerney wrote:
> > There were two bugs still on the 5.1.5 milestone [1], [2] that related
> > to the editing of H/V/45 constrained polygons. I have bumped those to
> > 6.0 now. Should we reopen and move [3] and [4] to 6.0 so that we
> > actually fix the issues there?
> >
> > -Ian
> >
> > [1] https://bugs.launchpad.net/kicad/+bug/1842055
> > [2] https://bugs.launchpad.net/kicad/+bug/1842195
> > [3] https://bugs.launchpad.net/kicad/+bug/1847722
> > [4] https://bugs.launchpad.net/kicad/+bug/1846029
> >
> > On Mon, Oct 21, 2019 at 7:02 PM Seth Hillbrand  > > wrote:
> >
> > On 2019-10-21 10:52, Ian McInerney wrote:
> >
> > > Seth,
> > >
> > > Just to clarify, for 5.1.5 (and future 5.1 releases), the H/V/45 is
> > > only available during initial zone creation and is not going to be
> > > active for editing the lines after creation? If this is the case, I
> > > will push the bugs for this into the 6.0 milestone, so they can be
> > > addressed there.
> > >
> > > -Ian
> >
> > That is correct.  I've already reset that bug[1].  But if you see
> > others
> > that relate to it, feel free to mark the dupes.
> >
> > -Seth
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > [1] https://bugs.launchpad.net/kicad/+bug/1833673
> >
> >
> > ___
> > 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] 5.1.5 release status

[Ian McInerney]

Can we slip [1] into 5.1.5, or would you rather hold it until we open for
5.1.6 work?

-Ian

[1] https://bugs.launchpad.net/kicad/+bug/1847580

On Wed, Oct 23, 2019 at 2:50 PM Wayne Stambaugh 
wrote:

> Now that JP fixed lp:1849289[1], is there anything else that needs to be
> fixed before I tag rc1?  If not, I will tag it Friday.  That means that
> we will be in a string freeze until the 5.1.5 release and that no new
> bug fixes other than bugs that already affect rc1 (including bugs moved
> to 5.1.6) cannot be committed without first discussing it on the dev
> mailing list.
>
> Cheers,
>
> Wayne
>
> [1]: https://bugs.launchpad.net/kicad/+bug/1849289
>
> On 10/21/2019 3:11 PM, Ian McInerney wrote:
> > There were two bugs still on the 5.1.5 milestone [1], [2] that related
> > to the editing of H/V/45 constrained polygons. I have bumped those to
> > 6.0 now. Should we reopen and move [3] and [4] to 6.0 so that we
> > actually fix the issues there?
> >
> > -Ian
> >
> > [1] https://bugs.launchpad.net/kicad/+bug/1842055
> > [2] https://bugs.launchpad.net/kicad/+bug/1842195
> > [3] https://bugs.launchpad.net/kicad/+bug/1847722
> > [4] https://bugs.launchpad.net/kicad/+bug/1846029
> >
> > On Mon, Oct 21, 2019 at 7:02 PM Seth Hillbrand  > > wrote:
> >
> > On 2019-10-21 10:52, Ian McInerney wrote:
> >
> > > Seth,
> > >
> > > Just to clarify, for 5.1.5 (and future 5.1 releases), the H/V/45 is
> > > only available during initial zone creation and is not going to be
> > > active for editing the lines after creation? If this is the case, I
> > > will push the bugs for this into the 6.0 milestone, so they can be
> > > addressed there.
> > >
> > > -Ian
> >
> > That is correct.  I've already reset that bug[1].  But if you see
> > others
> > that relate to it, feel free to mark the dupes.
> >
> > -Seth
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > [1] https://bugs.launchpad.net/kicad/+bug/1833673
> >
> >
> > ___
> > 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] 5.1.5 release status

[Wayne Stambaugh]

Now that JP fixed lp:1849289[1], is there anything else that needs to be
fixed before I tag rc1?  If not, I will tag it Friday.  That means that
we will be in a string freeze until the 5.1.5 release and that no new
bug fixes other than bugs that already affect rc1 (including bugs moved
to 5.1.6) cannot be committed without first discussing it on the dev
mailing list.

Cheers,

Wayne

[1]: https://bugs.launchpad.net/kicad/+bug/1849289

On 10/21/2019 3:11 PM, Ian McInerney wrote:
> There were two bugs still on the 5.1.5 milestone [1], [2] that related
> to the editing of H/V/45 constrained polygons. I have bumped those to
> 6.0 now. Should we reopen and move [3] and [4] to 6.0 so that we
> actually fix the issues there?
> 
> -Ian
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1842055
> [2] https://bugs.launchpad.net/kicad/+bug/1842195
> [3] https://bugs.launchpad.net/kicad/+bug/1847722
> [4] https://bugs.launchpad.net/kicad/+bug/1846029
> 
> On Mon, Oct 21, 2019 at 7:02 PM Seth Hillbrand  > wrote:
> 
> On 2019-10-21 10:52, Ian McInerney wrote:
> 
> > Seth,
> >
> > Just to clarify, for 5.1.5 (and future 5.1 releases), the H/V/45 is
> > only available during initial zone creation and is not going to be
> > active for editing the lines after creation? If this is the case, I
> > will push the bugs for this into the 6.0 milestone, so they can be
> > addressed there.
> >
> > -Ian
> 
> That is correct.  I've already reset that bug[1].  But if you see
> others
> that relate to it, feel free to mark the dupes.
> 
> -Seth
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1833673
> 
> 
> ___
> 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] [PATCH] SPICE .option confused with .op simulation

[Seth Hillbrand]

On 2019-10-22 23:35, Maciej Suminski wrote:

Hi Sylwester,

I admit I have not checked your patch in action, but it seems that it
will not accept ".op" command, unless it is followed by a space. Since
".op" does not take any parameters, I presume it is a rare case when 
one

adds an extra space after the command.

Regards,
Orson


Thanks Orson!  You are right, it was skipping the unpadded .op.  I 
missed this as the .tran command does print the DC operating point and I 
was checking in a multi-command circuit.  Good catch.  I've fixed up the 
command parsing to ensure we pad the command lines.


This does bring up, however, that our simulator does not handle .op 
well.  It won't probe the values or print them easily.  LTSpice prints 
the DC Operating Point table for all nets after running in this mode.  
Not that LTSpice is the model of usability but there may be something to 
this.


-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

Re: [Kicad-developers] Minimum Boost version

[Nick Østergaard]

+1

ons. 23. okt. 2019 15.28 skrev Wayne Stambaugh :

> One thing we don't specify on the system requirements page on the KiCad
> website is whether or not this applies to the current stable release or
> the nightly builds.  Since we don't specify this, I can see how users
> would assume that it's all versions of KiCad.  Perhaps we should note
> that this is only applicable to the current stable version and that
> nightly builds may not support older Linux distributions due to the
> availability of dependency library versions.  I don't think it's
> reasonable to expect the latest development version of KiCad to continue
> to support legacy Linux distros.  The current LTS release of Ubuntu is
> 18.04 which supports boost version 1.65.  I think attempting to support
> nightly builds on Ubuntu 16.04 is going to continue cause headaches as
> time goes on.  If no one objects, I will update the system requirements
> page accordingly.
>
> Cheers,
>
> Wayne
>
> On 10/23/2019 1:39 AM, Eeli Kaikkonen wrote:
> > It should also be noted that 20.04 will be the next LTS release of
> > Ubuntu. This means that there will be two post-16.04 LTS releases out
> > there before KiCad 6 will be released (I'm not *that* optimistic :) ).
> > Is it really worth it to actively support 3 different LTS releases? It
> > doesn't sound very realistic. How many users would actually be affected
> > if KiCad 6 wouldn't be available for 16.04? 1000s? 100s? 10? And if they
> > continue with 16.04 until 2021, why would they need to switch to KiCad 6
> > before that?
> >
> > Eeli Kaikkonen
> >
> > ke 23. lokak. 2019 klo 3.05 Seth Hillbrand (s...@kipro-pcb.com
> > ) kirjoitti:
> >
> > On 2019-10-22 16:06, Ian McInerney wrote:
> >
> >> I dug into the website history and apparently the original intent
> >> should have been to support 16.04 LTS until its standard support
> >> ends in 2021
> >> (
> https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782
> ).
> >> Since we haven't actually used any code from the newer Boost
> >> version (that we weren't already using), we should probably back
> >> out the change and also update the website with the correct Ubuntu
> >> LTS support date. It looks like that will make it so we can't
> >> update to 1.59 until 2021 then.
> >>
> >
> > Hi Ian-
> >
> > I did write that.  In retrospect, I'm not sure that the sentiment is
> > correct.  One of the things we are attempting to do is focus our
> > primary efforts where they will have the largest impact for our
> > users.  Toward that end, we were attempting (in the post KiCon
> > meeting) to define where that cut off should be.  We kind of
> > arbitrary picked "vendor supported" as it seemed reasonable.
> >
> > I now think we should tighten that a bit more for the Linux
> > distributions.  Under MSW/Mac, we compile or have rolling updates
> > for most of our own dependencies.  This allows us to ensure system
> > compatibility but not worry about library compatibility.  The Linux
> > library system is different and holds back updates.
> >
> > So, why would we want to update the boost libraries and what does it
> > gain us?  The original bump was to allow unit tests.  During v6, I
> > would also like to utilize the UUID library from 1.60 as many of the
> > feature we plan will require GUID at least.
> >
> > This doesn't preclude using KiCad on 16.04.  It just requires
> > someone to package a boost ppa.  There are a few out there that
> > could be used as baselines for this.
> >
> > -Seth
> >
> >
> > KiCad Services Corporation KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬ 
> > Davis, CA
> > www.kipro-pcb.com i...@kipro-pcb.com
> > 
> > https://twitter.com/KiProEDA 
> > https://www.linkedin.com/company/kicad
> > 
> >
> > ___
> > 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] [PATCH] SPICE .option confused with .op simulation

[Maciej Suminski]

Hi Sylwester,

I admit I have not checked your patch in action, but it seems that it
will not accept ".op" command, unless it is followed by a space. Since
".op" does not take any parameters, I presume it is a rare case when one
adds an extra space after the command.

Regards,
Orson

On 10/19/19 9:54 PM, Sylwester Kocjan wrote:
> Hi all,
> 
> If user wants to add custom SPICE options on schematic, for example
> 
> .option TEMP=60
> .option TNOM=27
> 
> It will get confused with .op simulation and will be included on
> DIALOG_SIM_SETTINGS in custom simulation directive text field.
> Eventually simulation will fail.
> 
> Please find the patch attached, where this issue is prevented.
> 
> 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