> 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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
+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
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
17 matches
Mail list logo
