Hi Ian,
Am 23.10.19 um 18:59 schrieb Ian McInerney:
> 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.
thanks, I
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
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
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
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)
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
On 2019-10-21 22:08, Carsten Schoenert wrote:
Hi,
Am 21.10.19 um 23:16 schrieb Ian McInerney:
We also seem to have assertions enabled in the Debian build (there
have
been two reports from users [1], [2]). Is this something we control as
well, or is the the distribution packaging forcing them
I would prefer that stable release builds have assertions disabled in
KiCad and all of it's library dependencies. If we want to provide debug
builds for users who want to help with debugging, I'm fine with that.
Wayne
On 10/22/19 7:43 AM, Adam Wolf wrote:
> I can look into doing this for
On 10/22/19 1:08 AM, Carsten Schoenert wrote:
> Hi,
>
> Am 21.10.19 um 23:16 schrieb Ian McInerney:
>> We also seem to have assertions enabled in the Debian build (there have
>> been two reports from users [1], [2]). Is this something we control as
>> well, or is the the distribution packaging
I can look into doing this for release builds on macOS If I do this, I
will need to make a pre-release build for folks to test since by definition
this wouldn't be tested on nightlies, right?
Are there other dependencies that we want to build differently for release
vs nightly?
Adam
On Tue,
Hi,
Am 21.10.19 um 23:16 schrieb Ian McInerney:
> We also seem to have assertions enabled in the Debian build (there have
> been two reports from users [1], [2]). Is this something we control as
> well, or is the the distribution packaging forcing them on?
the Debian build configuration is
We also seem to have assertions enabled in the Debian build (there have
been two reports from users [1], [2]). Is this something we control as
well, or is the the distribution packaging forcing them on?
-Ian
[1] https://bugs.launchpad.net/kicad/+bug/1847554
[2]
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]
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
I thought this might be the case. If you click cancel, the assertion
dialog will not be displayed again until you restart KiCad.
Would one of our macos devs please take a look at the config settings
use to build wxWidgets and see if we can turn the assertions off on
release builds? This might
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.
It may be a false alarm--I am reviewing everything and it looks like
it is working for everyone so far. There may be some documentation we
have to add to the macOS specific things about allowing permissions
when a popup pops up on first run, but if I am understanding correctly
none of the issues
Hi Jonaton,
This is an assertion in wxWidgets being raised. This really shouldn't
happen on release builds. While assertions like this are annoying they
are not show stoppers unless clicking either the "No" or "Cancel"
buttons cause KiCad to crash. I'm guessing this is not the case but one
of
On 10/20/19 12:02 PM, Seth Hillbrand wrote:
> On 2019-10-20 08:40, Ian McInerney wrote:
>
>> There is also this H/V/45 issue [1]. It is more of a gray area though,
>> since it will probably involve touching the file format due to what is
>> happening (the H/V/45 is being saved as a global board
Do we know if this is a KiCad source bug issue or a macos packaging
issue? I was getting the distinct impression that it was the latter. I
agree that we do not want to release 5.1.5 without a functioning macos
package. I'm willing to hold off on the rc1 tag until we resolve this
issue. It may
Hi Seth,
On 10/20/19 1:48 PM, Seth Hillbrand wrote:
> Hi Wayne-
>
> These should be fixed. I've pushed the reload issue off to v6 as the
> setting isn't available in the current file format as Ian mentioned, so
> I've reset the associated bug with a new milestone.
Thanks. I appreciate the
Hi folks.
I was under the impression that although the macOS 10.15 betas had
weird issues with KiCad, that the release Catalina was fine. This may
not be the case. I am mobile today and only using my phone, so it's
difficult for me to dig into it right now. If folks are still
reporting that
Hi Wayne-
These should be fixed. I've pushed the reload issue off to v6 as the
setting isn't available in the current file format as Ian mentioned, so
I've reset the associated bug with a new milestone.
We should be clear for these reports now. It's safe to tag 5.1.5RC1
from my
On 2019-10-20 08:40, Ian McInerney wrote:
There is also this H/V/45 issue [1]. It is more of a gray area though,
since it will probably involve touching the file format due to what is
happening (the H/V/45 is being saved as a global board setting rather
than a per-zone setting as the GUI
There is also this H/V/45 issue [1]. It is more of a gray area though,
since it will probably involve touching the file format due to what is
happening (the H/V/45 is being saved as a global board setting rather than
a per-zone setting as the GUI would seem to make it).
-Ian
[1]
Thanks Seth,
There is also this[1] bug and this[2] bug and this[3] bug related to the
zone constraint changes. I probably wont hold up the 5.1.5 release for
them but they are behavioral changes which users will not expect. The
most annoying one is lp:1846028.
Cheers,
Wayne
[1]:
On 2019-10-20 06:41, Wayne Stambaugh wrote:
Where are we on the 5.1.5 release? I took a look at the bug tacker and
the only serious bug I saw was the glib assertion bug[1]. How close
are
we to getting this fixed? There is still some unexpected behavior with
the constrained zone drawing and
30 matches
Mail list logo
