Re: [Kicad-developers] Should I start a new bug or is the reopened one suitable?

[Steven A. Falco]

Thanks - next time I'll open a new report and ref the old one.  But I won't 
bother for this one, since Wayne has already commented about it on gitlab.

Steve

On 5/27/22 01:53 PM, Seth Hillbrand wrote:

You commented in that bug report with the details.  Usually, commenting in open 
reports with examples that show the issue is sufficient.

If the issue were already closed, then opening a new report and referencing the 
old one is preferred.

Seth

On Fri, May 27, 2022 at 10:48 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

I recently reopened an issue [1] because I found an old schematic that could be 
opened properly by 5.1, but which gave "missing symbol" boxes when opened with 
6.0 and 6.99.

However, while the effect is the same, the root cause may be different, so 
maybe reopening the bug was the wrong approach.  Should I instead start a new 
bug for this?

Looking at the .sch files, the original has entries like:

$Comp
L RES-10M-5%-1/4W-CF R5
...
$EndComp

But after opening and saving the schematic with 5.1, this component has 
changed to:

$Comp
L e202var-vlf-radio-receiver-rescue:RES-10M-5%-1_4W-CF R5
...
$EndComp

At that point, 6.0 and 6.99 can correctly open the newly saved schematic.

Thus, it looks like 6.0 and 6.99 have lost the ability to deal with a "/" 
in a component name.  I don't know if any other special characters also fall into this 
category.

         Steve

[1] https://gitlab.com/kicad/code/kicad/-/issues/11563 
<https://gitlab.com/kicad/code/kicad/-/issues/11563>

___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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 <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto: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

[Kicad-developers] Should I start a new bug or is the reopened one suitable?

[Steven A. Falco]

I recently reopened an issue [1] because I found an old schematic that could be opened 
properly by 5.1, but which gave "missing symbol" boxes when opened with 6.0 and 
6.99.

However, while the effect is the same, the root cause may be different, so 
maybe reopening the bug was the wrong approach.  Should I instead start a new 
bug for this?

Looking at the .sch files, the original has entries like:

$Comp
L RES-10M-5%-1/4W-CF R5
...
$EndComp

But after opening and saving the schematic with 5.1, this component has changed 
to:

$Comp
L e202var-vlf-radio-receiver-rescue:RES-10M-5%-1_4W-CF R5
...
$EndComp

At that point, 6.0 and 6.99 can correctly open the newly saved schematic.

Thus, it looks like 6.0 and 6.99 have lost the ability to deal with a "/" in a 
component name.  I don't know if any other special characters also fall into this 
category.

Steve

[1] https://gitlab.com/kicad/code/kicad/-/issues/11563

___
Mailing list: https://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] Two bugs reported on the Fedora bugzilla

[Steven A. Falco]

Sorry about the bug being private.  I've changed it to be public.

Regarding the cherry pick - I see commit 485e89f7a5, and I'll try to apply it 
as a patch on top of 6.0.5.

Steve

On 5/6/22 02:54 PM, Seth Hillbrand wrote:

Ah, thanks!

Looks like that was fixed in master but didn't get cherry-picked.  The fix is 
in the v6 branch now.

Seth

On Fri, May 6, 2022 at 11:08 AM Ian McInerney mailto:ian.s.mciner...@ieee.org>> wrote:

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 mailto:s...@kipro-pcb.com>> 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 mailto:stevenfa...@gmail.com>> 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=2079984>

https://bugzilla.redhat.com/show_bug.cgi?id=2082394 
<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 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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 <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto:i...@kipro-pcb.com>

___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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 <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto: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

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

[Steven A. Falco]

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

Re: [Kicad-developers] 6.0.5 stable release

[Steven A. Falco]

I'm guessing this has been delayed for bug fixes.  I'll keep monitoring this list and the 
Zulip "Stable Releases" stream for updates.

Steve

On 4/15/22 06:30 PM, Wayne Stambaugh wrote:

The 6.0 source branch repo has been frozen for the upcoming 6.0.5 stable 
release.  I plan on tagging the source branch on April 22nd and release on the 
24th.  If you have any last minute library or documentation changes that you 
would like to make before we have to tag those repos, now is the time.

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] [abrt] kicad: wxDataViewCtrlInternal::BuildBranch(wxGtkTreeModelNode*)(): kicad killed by SIGSEGV

[Steven A. Falco]

Thanks, Seth.  I added that info to the Fedora bug, and if there turns out to 
be a way to reproduce it, I'll open a KiCad issue.

Steve


On 3/25/22 11:35 AM, Seth Hillbrand wrote:

Hi Steve-

I think that this is related to https://gitlab.com/kicad/code/kicad/-/issues/7422 
 (and the other bugs near 
it).  This is a particularly problematic section of wx/gtk interaction.  I believe 
that the way this widget works has been improved in wx3.1, so once the new wxWidgets 
is available for Fedora, the issue should be resolved.

If there are steps to reproduce, we can maybe work around it as we have with 
the similar issues.

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

[Kicad-developers] [abrt] kicad: wxDataViewCtrlInternal::BuildBranch(wxGtkTreeModelNode*)(): kicad killed by SIGSEGV

[Steven A. Falco]

A segfault has been reported in Fedora, but the reporter says it is not 
reproducible.  Below is a link to the bug.

https://bugzilla.redhat.com/show_bug.cgi?id=2068449

Please let me know if this is a known issue, or if there is anything further 
that we can do about it, given that it is not reproducible.

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] 6.0.4 released

[Steven A. Falco]

On 3/18/22 04:59 PM, Wayne Stambaugh wrote:

The stable version 6.0.4 of KiCad has been released.  The packages for most 
major platforms should be available.  The reason there was no 6.0.3 release is 
that we found an issue with 6.0.3 before the official release announcement was 
made and had to fix it.  The KiCad development team would like to apologize for 
any inconvenience this may have caused. Thank you to everyone who made this 
stable release possible.


I never got that announcement - I built 6.0.3, as originally discussed.

I'll restart the builds for 6.0.4, but naturally there will be a delay...

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] Fedora build failure with cmake 3.23.0

[Steven A. Falco]

On 3/4/22 08:11 AM, Steven A. Falco wrote:

I received a new bug [1] stating that there is a KiCad "failure to build" in 
Fedora Rawhide.  The bug reporter thinks it is due to a new version of cmake: 3.23.0.

I'm trying to get more information, and I'll try to reproduce the problem.  
When I do, I'll provide a link to the log containing the error messages.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781


I have reproduced the error, and opened an issue [1].  It includes a copy of 
the log, showing the failure.

[1] https://gitlab.com/kicad/code/kicad/-/issues/11043

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

[Kicad-developers] Fedora build failure with cmake 3.23.0

[Steven A. Falco]

I received a new bug [1] stating that there is a KiCad "failure to build" in 
Fedora Rawhide.  The bug reporter thinks it is due to a new version of cmake: 3.23.0.

I'm trying to get more information, and I'll try to reproduce the problem.  
When I do, I'll provide a link to the log containing the error messages.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2060781

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

[Kicad-developers] Fedora and major version changes

[Steven A. Falco]

I'm not sure how many folks on this list care about what follows, but for those 
who do...

KiCad has been granted an exception to the Fedora "major update policy".  The 
exception will only be used in the case of critical bugs / security issues.

Consequently, I'm currently building 6.0.2 for F34 and F35, to address the 
recent CVE's.  The builds should complete tonight, but won't go live for a 
week, given the Fedora testing policy.

The most up-to-date KiCad releases will continue to be available via Copr for 
those who want them.

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] CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947

[Steven A. Falco]

On 2/16/22 01:52 PM, jp charras wrote:


Le 16/02/2022 à 19:38, Steven A. Falco a écrit :

I found "Fix overflow vulnerability in Gerbview" and possibly "Fix relative return 
with nullptr condition".  Are there other patches in the series, or are those two the only 
ones that are needed?

I tried grepping the log for CVE, but didn't find much...

Steve



3 fixes are needed. This one is needed:

"Fix float scaling to use single fn"


I tried applying the patches to 5.1.12 but ran into rejects that I didn't feel 
comfortable to rework.

I'm asking on the Fedora list, and there is a way to request exceptions to the 
"Fedora major update policy".  I'll see where that leads.  Given that KiCad is 
planning to do annual major updates, I suspect this problem will keep coming up, so if I 
can get an exception to the policy, that would be best.

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] CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947

[Steven A. Falco]

I found "Fix overflow vulnerability in Gerbview" and possibly "Fix relative return 
with nullptr condition".  Are there other patches in the series, or are those two the only 
ones that are needed?

I tried grepping the log for CVE, but didn't find much...

Steve

On 2/16/22 01:17 PM, Seth Hillbrand wrote:

Distributions that would like to release a patched version of 5.1, 5.0 or 4.0 
can cherry-pick the patch series.  They should apply cleanly.

Seth

On Wed, Feb 16, 2022 at 9:16 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

One additional question - I know that 5.1.12 was the last planned release 
in the 5.x series, and that 5.1.12 has the vulnerability.  Currently, because 
of Fedora policy, both F34 and F35 still ship 5.1.12.

I'll ask on the Fedora list if this event qualifies as an exception to the 
policy, but if not, how involved would it be to patch 5.1.12, or perhaps to 
spin a 5.1.13 just to fix this issue?

         Steve

On 2/16/22 11:49 AM, Steven A. Falco wrote:
 > Excellent!  I'll note that on the Fedora bugs.
 >
 >  Thanks,
 >  Steve
 >
 > On 2/16/22 09:44 AM, Ian McInerney wrote:
 >> 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 mailto:stevenfa...@gmail.com> <mailto:stevenfa...@gmail.com 
<mailto:stevenfa...@gmail.com>>> 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 
<https://bugs.gentoo.org/833426> <https://bugs.gentoo.org/833426 
<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=2054956> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054956 
<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=2054957> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054957 
<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=2054959> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054959 
<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=2054960> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054960 
<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=2054955> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054955 
<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=2054973> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054973 
<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=2054974> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054974 
<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=2054979> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054979 
<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=2054980> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054980 
<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=2054958> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054958 
<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=2054972> 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054972 
<https://bu

Re: [Kicad-developers] CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947

[Steven A. Falco]

One additional question - I know that 5.1.12 was the last planned release in 
the 5.x series, and that 5.1.12 has the vulnerability.  Currently, because of 
Fedora policy, both F34 and F35 still ship 5.1.12.

I'll ask on the Fedora list if this event qualifies as an exception to the 
policy, but if not, how involved would it be to patch 5.1.12, or perhaps to 
spin a 5.1.13 just to fix this issue?

Steve

On 2/16/22 11:49 AM, Steven A. Falco wrote:

Excellent!  I'll note that on the Fedora bugs.

 Thanks,
 Steve

On 2/16/22 09:44 AM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 <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=2054956>
    https://bugzilla.redhat.com/show_bug.cgi?id=2054957 
<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=2054959>
    https://bugzilla.redhat.com/show_bug.cgi?id=2054960 
<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=2054955>
    https://bugzilla.redhat.com/show_bug.cgi?id=2054973 
<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=2054974>
    https://bugzilla.redhat.com/show_bug.cgi?id=2054979 
<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=2054980>
    https://bugzilla.redhat.com/show_bug.cgi?id=2054958 
<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=2054972>
    https://bugzilla.redhat.com/show_bug.cgi?id=2054978 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054978>

    ___
    Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
    Post to     : kicad-developers@lists.launchpad.net 
<mailto: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>






___
Mailing list: https://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

[Steven A. Falco]

Excellent!  I'll note that on the Fedora bugs.

Thanks,
Steve

On 2/16/22 09:44 AM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 <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=2054956>
https://bugzilla.redhat.com/show_bug.cgi?id=2054957 
<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=2054959>
https://bugzilla.redhat.com/show_bug.cgi?id=2054960 
<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=2054955>
https://bugzilla.redhat.com/show_bug.cgi?id=2054973 
<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=2054974>
https://bugzilla.redhat.com/show_bug.cgi?id=2054979 
<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=2054980>
https://bugzilla.redhat.com/show_bug.cgi?id=2054958 
<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=2054972>
https://bugzilla.redhat.com/show_bug.cgi?id=2054978 
<https://bugzilla.redhat.com/show_bug.cgi?id=2054978>

___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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>




___
Mailing list: https://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] CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947

[Steven A. Falco]

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

Re: [Kicad-developers] 6.0.2 stable release

[Steven A. Falco]

On 2/7/22 04:46 PM, Wayne Stambaugh wrote:

On 2/7/2022 4:39 PM, Steven A. Falco wrote:

On 2/7/22 03:39 PM, Wayne Stambaugh wrote:

The goal is to release 6.0.2 on Friday, February 11th. If this is an issue for 
anyone please let me know.  I apologize that it's this late due to the Launch 
mailing list issue.


To confirm, do you mean that all the repos will be tagged with 6.0.2 on the 
11th?


Tagged on the 9th and release announcement on the 11th.


I'm guessing this has been held up.  Is there a new date for the tagging?

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] 6.0.2 stable release

[Steven A. Falco]

On 2/7/22 03:39 PM, Wayne Stambaugh wrote:

The goal is to release 6.0.2 on Friday, February 11th. If this is an issue for 
anyone please let me know.  I apologize that it's this late due to the Launch 
mailing list issue.


To confirm, do you mean that all the repos will be tagged with 6.0.2 on the 
11th?

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] Deprecation warnings with GCC 12

[Steven A. Falco]

Thanks, Ian.  I'll ignore the warnings then.

Steve

On 1/26/22 09:04 AM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 
<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 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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>




___
Mailing list: https://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] Deprecation warnings with GCC 12

[Steven A. Falco]

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

[Kicad-developers] Please merge

[Steven A. Falco]

I had created a merge request 
https://gitlab.com/kicad/code/kicad/-/merge_requests/1108 for a missing include 
file, but I seem to have messed the MR up.

Thus, I closed that one and opened a new MR: 
https://gitlab.com/kicad/code/kicad/-/merge_requests/1110

I'd appreciate it if this can be merged into master and cherry picked into 6.0 
as it is necessary for compilation with GCC 12.

Thanks,
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] V6 documentation

[Steven A. Falco]

On 1/19/22 05:18 PM, Eeli Kaikkonen wrote:

On Wed, Jan 19, 2022 at 9:13 PM Steven A. Falco  wrote:


It would still be helpful if the doc repo could be tagged at the same point that 
everything else is tagged, because every single Fedora package needs a correct version in 
its name.  For example, it would be very strange (perhaps "illegal") to package 
something called the 6.0.1 doc that came from some random SHA in an untagged tree.


I don't understand why this discussion is so difficult to understand.
I agree with Jon and don't see any problem for distros. As far as I
can see the point is that the documentation package version shouldn't
be logically dependent on the KiCad packages or vice versa. You can
have package kicad-v6.0-documentation version, say, 20222001 [date],
can't you? You don't have to give it the version number 6.0.x. If a
git tag is needed for technical reasons, let's have automatic tagging
which adds a tag each day.


I don't think the discussion is difficult to understand.  But Fedora's process 
doesn't map into what you have just proposed.

Currently, there is one single script (a "spec" file) that controls the build 
of all the components of KiCad on Fedora.  This includes the executable programs, 
libraries, and docs.

There is nothing automatic about the process.  When a new build is needed, I download the 
tar files based on a tag, upload them to a lookaside cache called "dist-git", 
and then I queue a build on Fedora's koji system.  Once that completes, I download the 
resulting artifacts, test them, and then submit the artifacts for further testing by the 
larger community.  Eventually, those artifacts get blessed and go into the distribution 
system as new packages.

It is all a very manual process, and I only do it when some significant event 
occurs, like when a new tag is placed.  Also, it takes time - the review 
process generally takes a full week, so daily package updates to the docs are 
out of the question.

So, there is no point to tagging the docs on a daily basis.  And since that tag 
wouldn't agree with the one on the KiCad program, it would have to be a 
separately maintained thing, which would double my work.  And it would still 
only be built occasionally - not every day, because like I said, it is a very 
manual process, and takes a lot longer than a day to complete.

Personally I'd like to see things stay the way they are as far as the tagging 
goes.  The docs would be tagged at the same time and with the same tag as 
everything else.  Yes, they might soon be out of date, which is why I suggested 
that the code default to using the on-line copy, whenever it is available, and 
only use the off-line copy when there was no connection.  That would cover most 
users who have an internet connection.

But that is not essential.  As Jon said, if someone chooses not to install the 
doc package, then they'd get the on-line version.

Perhaps the best thing would be to completely eliminate building the docs on 
Fedora.  That way, nobody could install them, and they'd always get the on-line 
version.

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] V6 documentation

[Steven A. Falco]

On 1/19/22 02:16 PM, Jon Evans wrote:


On Wed, Jan 19, 2022 at 2:12 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:


Not to put words in your mouth, but it sounds like the code will be changed 
so that when someone clicks on the Help menu, they will get the on-line 
version, if possible.
And only if the on-line version cannot be accessed, the code would then 
automatically fall back to the off-line (local) version.  Do I have the 
proposal correct?  If so, I like it.


Yes, something like that.  But, instead it could be to use the offline version 
if present, and fall back to the online version if absent.  Then it would be up 
to the packager to decide whether or not to include the offline docs (I'd 
propose to drop them from the Windows and Mac packages that we provide).


It might also be good to have a warning somewhere, perhaps in the off-line 
version itself, that it is not necessarily current, along with a suggestion to 
go retrieve the on-line version manually.


Yes, I think this is important, just have to figure out how to add it to the 
generated documentation but not the website.


It would still be helpful if the doc repo could be tagged at the same point that 
everything else is tagged, because every single Fedora package needs a correct version in 
its name.  For example, it would be very strange (perhaps "illegal") to package 
something called the 6.0.1 doc that came from some random SHA in an untagged tree.


I am not trying to break any distro's packaging requirements for the sake of 
making people's lives hard, I am just trying to make it so the average KiCad 
user who has access to the online docs finds them first.

Maybe one option would be to not install the documentation package by default 
when the user selects the main kicad package.  That way, a user who just 
installs kicad will get the online docs redirect, and one who cares about 
offline docs can manually install the extra package?


That is how things are packaged right now, both for Fedora nightlies and for 
Fedora downstream (official) packages.  We build three packages:

1) main program + all libraries except 3d (because it is huge)

2) docs

3) 3d library

So nobody has to install the docs.  As long as the off-line docs indicate that 
there may be more current on-line docs, that should be fine.

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] V6 documentation

[Steven A. Falco]

On 1/19/22 12:45 PM, Jon Evans wrote:

... snip ...


The point I was making is that someone who installs 6.0.1 today should get the 
latest V6 branch docs (not the latest master branch) ideally.
Anyone with internet access should be able to get the latest docs, not the docs 
at the 6.0.1 tag.


Not to put words in your mouth, but it sounds like the code will be changed so 
that when someone clicks on the Help menu, they will get the on-line version, 
if possible.

And only if the on-line version cannot be accessed, the code would then 
automatically fall back to the off-line (local) version.  Do I have the 
proposal correct?  If so, I like it.

It might also be good to have a warning somewhere, perhaps in the off-line 
version itself, that it is not necessarily current, along with a suggestion to 
go retrieve the on-line version manually.

It would still be helpful if the doc repo could be tagged at the same point that 
everything else is tagged, because every single Fedora package needs a correct version in 
its name.  For example, it would be very strange (perhaps "illegal") to package 
something called the 6.0.1 doc that came from some random SHA in an untagged tree.

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] V6 documentation

[Steven A. Falco]

On 1/19/22 12:00 PM, Jon Evans wrote:

That just doesn't seem that useful to me.  The fact that Fedora forces this 
process means that Fedora offline docs will always be outdated.


I don't disagree, but really, we could say that everything is always outdated - 
the code, the libs etc.  I have to pick a point in time, and create packages as 
of that point - currently that point is when a new release is tagged.  I.e., it 
is a manual process - I have to consciously create the packages, and it then 
takes a week or so for the packages to sit in the testing repositories before 
being released to general users.  I have no control over that process.


If there is no way to work around it for Fedora, I suggest we develop an 
out-of-band way of delivering offline docs to people (not using the Fedora 
packaging system).


People can always download the nightly docs packages via Copr, which will 
correspond to whatever is in the master branch.  There is no process at the 
moment for nightlies to build from any other branch, although I suppose one 
could be added.

Steve




On Wed, Jan 19, 2022 at 11:52 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

Right now, the downstream (official) Fedora builds depend on a single tag 
for all the components - source code, libraries, and docs.

I could substitute a SHA for the docs, but I'd have to hard-code the SHA in the 
"spec file" that controls the build, the same way the tag is hard-coded in the 
spec file.

Since all the components are built at the same time from the same script, it would not be 
possible to "update every time something is pushed to the V6 branch".  I.e., Fedora 
builds are not a "rolling release" - they are tied to tags.

         Steve

On 1/19/22 11:38 AM, Jon Evans wrote:
 > Carsten,
 >
 > There is no reason to remove the ability to package docs offline, I just 
don't think it should be a focus of the project.
 > The majority of users will be served better by keeping a "rolling release" online at 
docs.kicad.org <http://docs.kicad.org> <http://docs.kicad.org <http://docs.kicad.org>> (with 
a download button, ideally).
 >
 >  > It absolutely doesn't hurt to build completely offline usable 
documentation.
 >
 > It does hurt the way we do it today, for the following reasons:
 >
 > 1) We currently support multiple formats, which makes the build system 
and formatting changes complicated
 >
 > 2) We currently tie the documentation version together with the application 
version, and don't have good workflows for "rolling release" of documentation for 
Linux distros that use separate packages.
 >
 > 3) The application itself doesn't handle the situation where offline 
docs are missing very gracefully, or note to users that when offline docs are 
present that they are probably outdated.
 >
 > What I would propose to improve the situation is:
 >
 > 1) Drop all formats except HTML.  HTML is perfectly fine as an offline 
format, and this allows us to make improvements to the build workflow and the 
layout/style of the docs without worrying about doing so in a way that also works 
for PDF.  If you really want a PDF, you can render it from HTML pages anyway.
 >
 > 2) Change the application to gracefully redirect to the online docs if 
offline docs are missing
 >
 > 3) Make a better "offline docs" build that adds the warning about docs 
being out-of-date.  Have packagers use this if they want to generate docs packages, and 
maybe make it easy for anyone to download these from the website.
 >
 > 4) Stop tagging the kicad-docs repo with every KiCad code release.  
Instead, continue the new practice we have started of maintaining major release 
branches for the docs (V5, V6, etc) and have packagers start packaging the tip of 
these branches.  I.e. the Ubuntu package for kicad-docs will update every time 
something is pushed to the V6 branch as long as V6 is the stable release, and so 
on.
 >
 > -Jon
 >
 > On Wed, Jan 19, 2022 at 11:29 AM Carsten Schoenert mailto:c.schoen...@t-online.de> <mailto:c.schoen...@t-online.de 
<mailto:c.schoen...@t-online.de>>> wrote:
 >
 >     Hello,
 >
 >     Am 19.01.22 um 17:21 schrieb Gabriel Staples, 
ElectricRCAircraftGuy.com:
 >     ...
 >      > In other words, please do make "online documentation" only, as it 
allows
 >      > faster updates to it and better consistency,
 >
 >     please don't!
 >     It absolutely doesn't hurt to build completely offline usable
 >     documentation. It works for years without special requirements.
 >
 >     I work often in environ

Re: [Kicad-developers] Possible build failure using gcc 12

[Steven A. Falco]

Ok - I learned something new - thanks!

Here is the issue:

https://gitlab.com/kicad/code/kicad/-/issues/10508

Steve

On 1/19/22 11:51 AM, Seth Hillbrand wrote:

Hi Steven,

You can report this on the tracker, just add the term "build-error" to the 
description.  I think we list this in the template as an option but it might be in the 
middle of the text instructions.

Seth

On Wed, Jan 19, 2022 at 7:20 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

The Fedora nightly builds succeeded on F34 and F35 last night, but failed 
on Rawhide.  Rawhide recently switched to gcc 12, so that might be the cause of 
the build failures.

I would write this up as an issue on gitlab, but the template requires 
version information, which is not applicable in this situation.

The build log showing the failure is available here: 
https://download.copr.fedorainfracloud.org/results/@kicad/kicad/fedora-rawhide-x86_64/03196619-kicad-nightly/build.log.gz
 
<https://download.copr.fedorainfracloud.org/results/@kicad/kicad/fedora-rawhide-x86_64/03196619-kicad-nightly/build.log.gz>

Here is the error from that log:

[  2%] Building CXX object 
thirdparty/json_schema_validator/CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o
cd 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/redhat-linux-build/thirdparty/json_schema_validator
 && /usr/bin/g++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad 
-DKICAD_SCRIPTING_WXPYTHON -DKICAD_SPICE -DKICAD_USE_OCC -DWXUSINGDLL 
-DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator
 
-I/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/nlohmann_json
 -isystem 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/pybind11/include
 -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem 
/usr/include/freetype2 -isystem /usr/include/harfbuzz -isystem /usr/include/opencascade 
-isystem /usr/lib64/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -O2 
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -pthread 
-O2 -g -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden 
-std=c++17 -MD -MT 
thirdparty/json_schema_validator/CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o
 -MF CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o.d -o 
CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o -c 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp

/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp:
 In constructor '{anonymous}::string::string(nlohmann::json&, 
nlohmann::json_schema::root_schema*)':

/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp:762:53:
 error: ambiguous overload for 'operator=' (operand types are 'std::string' {aka 
'std::__cxx11::basic_string'} and 'nlohmann::basic_json<>')
    762 |                         patternString_ = attr.value();
        |                                                     ^
In file included from /usr/include/c++/12/string:53,
                   from /usr/include/c++/12/bits/locale_classes.h:40,
                   from /usr/include/c++/12/bits/ios_base.h:41,
                   from /usr/include/c++/12/streambuf:41,
                   from /usr/include/c++/12/bits/streambuf_iterator.h:35,
                   from /usr/include/c++/12/iterator:66,
                   from 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/nlohmann_json/nlohmann/json.hpp:42,
                   from 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/nlohmann/json-schema.hpp:24,
                   from 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp:9:
/usr/include/c++/12/bits/basic_string.h:733:21: note: candidate: 'std::__cxx11::basic_string<_CharT, 
_Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::nullptr_t) [with _CharT = char; _Traits = std::char_traits; _Alloc = 
std::allocator; std::nullptr_t = std::nullptr_t]' (deleted)
    733 |       basic_string& operator=(nullptr_t) = delete;
        |                     ^~~~

Re: [Kicad-developers] V6 documentation

[Steven A. Falco]

Right now, the downstream (official) Fedora builds depend on a single tag for 
all the components - source code, libraries, and docs.

I could substitute a SHA for the docs, but I'd have to hard-code the SHA in the 
"spec file" that controls the build, the same way the tag is hard-coded in the 
spec file.

Since all the components are built at the same time from the same script, it would not be possible 
to "update every time something is pushed to the V6 branch".  I.e., Fedora builds are not 
a "rolling release" - they are tied to tags.

Steve

On 1/19/22 11:38 AM, Jon Evans wrote:

Carsten,

There is no reason to remove the ability to package docs offline, I just don't 
think it should be a focus of the project.
The majority of users will be served better by keeping a "rolling release" online at 
docs.kicad.org  (with a download button, ideally).

 > It absolutely doesn't hurt to build completely offline usable documentation.

It does hurt the way we do it today, for the following reasons:

1) We currently support multiple formats, which makes the build system and 
formatting changes complicated

2) We currently tie the documentation version together with the application version, and 
don't have good workflows for "rolling release" of documentation for Linux 
distros that use separate packages.

3) The application itself doesn't handle the situation where offline docs are 
missing very gracefully, or note to users that when offline docs are present 
that they are probably outdated.

What I would propose to improve the situation is:

1) Drop all formats except HTML.  HTML is perfectly fine as an offline format, 
and this allows us to make improvements to the build workflow and the 
layout/style of the docs without worrying about doing so in a way that also 
works for PDF.  If you really want a PDF, you can render it from HTML pages 
anyway.

2) Change the application to gracefully redirect to the online docs if offline 
docs are missing

3) Make a better "offline docs" build that adds the warning about docs being 
out-of-date.  Have packagers use this if they want to generate docs packages, and maybe 
make it easy for anyone to download these from the website.

4) Stop tagging the kicad-docs repo with every KiCad code release.  Instead, 
continue the new practice we have started of maintaining major release branches 
for the docs (V5, V6, etc) and have packagers start packaging the tip of these 
branches.  I.e. the Ubuntu package for kicad-docs will update every time 
something is pushed to the V6 branch as long as V6 is the stable release, and 
so on.

-Jon

On Wed, Jan 19, 2022 at 11:29 AM Carsten Schoenert mailto:c.schoen...@t-online.de>> wrote:

Hello,

Am 19.01.22 um 17:21 schrieb Gabriel Staples, ElectricRCAircraftGuy.com:
...
 > In other words, please do make "online documentation" only, as it allows
 > faster updates to it and better consistency,

please don't!
It absolutely doesn't hurt to build completely offline usable
documentation. It works for years without special requirements.

I work often in environments where I have absolutely no access to the
internet, but can use packaged software, so I heavily need offline
documentation to do some sort of productive work.

-- 
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] Possible build failure using gcc 12

[Steven A. Falco]

The Fedora nightly builds succeeded on F34 and F35 last night, but failed on 
Rawhide.  Rawhide recently switched to gcc 12, so that might be the cause of 
the build failures.

I would write this up as an issue on gitlab, but the template requires version 
information, which is not applicable in this situation.

The build log showing the failure is available here: 
https://download.copr.fedorainfracloud.org/results/@kicad/kicad/fedora-rawhide-x86_64/03196619-kicad-nightly/build.log.gz

Here is the error from that log:

[  2%] Building CXX object 
thirdparty/json_schema_validator/CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o
cd 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/redhat-linux-build/thirdparty/json_schema_validator
 && /usr/bin/g++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad 
-DKICAD_SCRIPTING_WXPYTHON -DKICAD_SPICE -DKICAD_USE_OCC -DWXUSINGDLL 
-DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-I/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator
 
-I/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/nlohmann_json
 -isystem 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/pybind11/include
 -isystem /usr/include/cairo -isystem /usr/include/pixman-1 -isystem 
/usr/include/freetype2 -isystem /usr/include/harfbuzz -isystem /usr/include/opencascade 
-isystem /usr/lib64/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -O2 
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -pthread -O2 -g 
-DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++17 -MD -MT 
thirdparty/json_schema_validator/CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o
 -MF CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o.d -o 
CMakeFiles/nlohmann_json_schema_validator.dir/json-validator.cpp.o -c 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp:
 In constructor '{anonymous}::string::string(nlohmann::json&, 
nlohmann::json_schema::root_schema*)':
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp:762:53:
 error: ambiguous overload for 'operator=' (operand types are 'std::string' {aka 
'std::__cxx11::basic_string'} and 'nlohmann::basic_json<>')
  762 | patternString_ = attr.value();
  | ^
In file included from /usr/include/c++/12/string:53,
 from /usr/include/c++/12/bits/locale_classes.h:40,
 from /usr/include/c++/12/bits/ios_base.h:41,
 from /usr/include/c++/12/streambuf:41,
 from /usr/include/c++/12/bits/streambuf_iterator.h:35,
 from /usr/include/c++/12/iterator:66,
 from 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/nlohmann_json/nlohmann/json.hpp:42,
 from 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/nlohmann/json-schema.hpp:24,
 from 
/builddir/build/BUILD/kicad-826154d666cf192a7123005bf565168fd447fd86/thirdparty/json_schema_validator/json-validator.cpp:9:
/usr/include/c++/12/bits/basic_string.h:733:21: note: candidate: 'std::__cxx11::basic_string<_CharT, 
_Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::nullptr_t) [with _CharT = char; _Traits = std::char_traits; _Alloc = 
std::allocator; std::nullptr_t = std::nullptr_t]' (deleted)
  733 |   basic_string& operator=(nullptr_t) = delete;
  | ^~~~
/usr/include/c++/12/bits/basic_string.h:801:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator]'
  801 |   operator=(const basic_string& __str)
  |   ^~~~
/usr/include/c++/12/bits/basic_string.h:842:7: note: candidate: 'std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator]'
  842 |   operator=(basic_string&& __str)
  |   ^~~~

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 04:02 PM, Seth Hillbrand wrote:



On Tue, Jan 11, 2022 at 12:48 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

On 1/11/22 03:24 PM, Seth Hillbrand wrote:
 > We will not directly disable running in a VM.
 >
 > Our stance is that if there are issues running KiCad in a VM, they 
should be reported to the maker of the VM, not KiCad.

I'm going to have to disagree with that stance a little, Seth.  The initial bug 
report https://gitlab.com/kicad/code/kicad/-/issues/8944 
<https://gitlab.com/kicad/code/kicad/-/issues/8944> was from a Virtualbox user. 
 Then I saw the problem using the native Linux KVM.  Two different VM 
implementations.  And I think the root cause was a KiCad bug where the code didn't 
properly test for GLX_EXT_swap_control_tear.  So reporting to either of those VM 
makers would not have been effective, in this case.


Root cause was Mesa/X11 reporting that it was able to handle a call to 
GLX_EXT_swap_control_tear.  And then crashing when that call was made.

The "fix" was to test for a Mesa driver and then prevent it from calling the 
adaptive sync.

I stand by the statement that this is a bug in other programs (in this case, 
the Mesa driver used by the VM softwares.

KiCad can work around this issue (and all of the other fallback issues as 
well).  But then, that is where developer time goes instead of into developing 
new schematic and layout features that will be of use to our whole userbase.

This is why we will not be focussing on supporting VMs or fallback graphics in 
the future.


I stand corrected.

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] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 03:24 PM, Seth Hillbrand wrote:

We will not directly disable running in a VM.

Our stance is that if there are issues running KiCad in a VM, they should be 
reported to the maker of the VM, not KiCad.


I'm going to have to disagree with that stance a little, Seth.  The initial bug 
report https://gitlab.com/kicad/code/kicad/-/issues/8944 was from a Virtualbox 
user.  Then I saw the problem using the native Linux KVM.  Two different VM 
implementations.  And I think the root cause was a KiCad bug where the code 
didn't properly test for GLX_EXT_swap_control_tear.  So reporting to either of 
those VM makers would not have been effective, in this case.

Regardless, I'm glad you won't be disabling VM support because I need KiCad to 
work in a VM.  That is the only way I can test the official Fedora releases 
that I build.  Specifically, I'll first try my builds out in an F34 VM, a 
Rawhide VM, etc. before unleashing them on the community.

I don't have multiple physical machines running all those different Fedora 
editions, let alone Ubuntu and some others that I occasionally test with, so if 
I lose VM capability, I'll lose the ability to test what I build.

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] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 02:33 PM, pmx wrote:



Le 11/01/2022 à 19:25, Steven A. Falco a écrit :

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.


I'm describing two situations.  One is the artifacts on my desktop, and one is 
the segfault on VMs.  As long as the window opens and is somewhat usable, then 
one can select fallback graphics easily from preferences, as you said.  The 
bigger problem is on the VMs where it crashes before the window gets a chance 
to even open.  I'll look at the issue you linked and see if that helps.  I'll 
also try a test build from the tip of the 6.0 branch and see how that behaves.

I'm more concerned that fallback graphics might be removed entirely at some 
point.  Hopefully accelerated mode will be bullet-proof before that decision is 
made.

Steve 


Unless there is much work involved to keep both backends working in the future, 
I strongly feel that a fallback graphics engine is a must and should be kept 
alive, even if this requires some (moderate...) effort.

IMHO, we shouldn't remove anything that helps to deal gracefully with the 
diversity of situations (like a virtual machine), graphics hardware and video 
drivers... and their possible bugs ! (as stated about X11/Mesa).


@ Steven :
About the possibility to choose a graphics backend, in any situation, and 
indeed before a segfault  happens  :

What about a command line option (when launching Kicad), to force a specific graphics 
backend, including a "safe" fallback ?
Should be quite straightforward.


The segfault is fixed in the latest 6.0 code, so I guess there is no longer a 
need for either the dialog or a command.

However, some of the visual artifacts are still happening even with the latest 
6.0 code, therefore the fallback graphics mode is still essential.

I've added another video showing what it looks like when I resize the pcbnew 
screen.  Please see comment 
https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and 
https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
 for details.

I'm a little concerned that new users seeing these artifacts won't know what to 
do about them, and may give up.

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] Was the initial graphics mode screen removed?

[Steven A. Falco]

On 1/11/22 12:31 PM, Ian McInerney wrote:

Hi Steve,

On Tue, Jan 11, 2022 at 3:47 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

I've opened https://gitlab.com/kicad/code/kicad/-/issues/10375 
<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 
<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).


I'll do that - thanks for the pointer.


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.


I'm describing two situations.  One is the artifacts on my desktop, and one is 
the segfault on VMs.  As long as the window opens and is somewhat usable, then 
one can select fallback graphics easily from preferences, as you said.  The 
bigger problem is on the VMs where it crashes before the window gets a chance 
to even open.  I'll look at the issue you linked and see if that helps.  I'll 
also try a test build from the tip of the 6.0 branch and see how that behaves.

I'm more concerned that fallback graphics might be removed entirely at some 
point.  Hopefully accelerated mode will be bullet-proof before that decision is 
made.

Steve



-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 mailto:stevenfa...@gmail.com> <mailto:stevenfa...@gmail.com 
<mailto:stevenfa...@gmail.com>>> 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 

Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

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 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.

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 mailto:stevenfa...@gmail.com>> 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 
<mailto: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 <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto: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

[Kicad-developers] Was the initial graphics mode screen removed?

[Steven A. Falco]

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
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] 6.0.0 build flags

[Steven A. Falco]

I looked at CMakeLists.txt, and it appears that some of the old 5.x build flags 
have been removed, and some new flags have been added.

In particular, the following scripting flags are gone (only 
KICAD_SCRIPTING_WXPYTHON remains):

KICAD_SCRIPTING
KICAD_SCRIPTING_ACTION_MENU
KICAD_SCRIPTING_MODULES
KICAD_SCRIPTING_PYTHON3
KICAD_SCRIPTING_WXPYTHON_PHOENIX

These flags still appear in files like .gitlab/Windows-CI.yml and should be 
removed.  They should also be removed from the Fedora nightly builds, and 
probably from other builds, as well.

I can remove the above flags from the Fedora nightly builds, and I can create 
an MR for the .gitlab files, if desired.  Please let me know if you want that 
MR.

There are a few new flags that I think should be added to the Fedora builds for 
clarity, even though we don't change the defaults.  In particular, I propose to 
add:

KICAD_PCM=ON
KICAD_USE_EGL=OFF

Are there any other new flags that I should add?  (I could add every single 
flag from CMakeLists.txt, but most seem related to debug, and would just 
clutter the cmake command.)

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

[Kicad-developers] Disabled Copr builds for Fedora 33

[Steven A. Falco]

I don't expect this will affect anyone here, but just to prevent a possible 
blind-side, I wanted to announce that I've disabled building KiCad nightlies 
for Fedora 33, as that release has hit end-of-life, and I expect that the 
build-roots for F33 will disappear from Copr soon.

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] Version 6 release candidate 1

[Steven A. Falco]

Thanks for the clarification, Jon.  I had not been aware of that.

Steve

On 11/18/21 03:18 PM, Jon Evans wrote:

Just to be clear, I think it's fine to do this if you are testing your build/packaging 
process, but the docs at the rc1 tag are not going to be that useful to users, as they 
are in an incomplete and partially-untranslated state.  We are in the middle of a project 
to update the docs for V6, and we are doing this out of sync with the code (so we did not 
wait for the rc1 tag until the docs were at a "release candidate" state, in 
other words).

On Thu, Nov 18, 2021 at 3:13 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

On 11/18/21 03:04 PM, Johannes Maibaum wrote:
 > Am Donnerstag, dem 18.11.2021 um 14:58 -0500 schrieb Jon Evans:
 >> When do you need it by?  The docs are nowhere near ready for the
 >> final release, so if this isn't a hard requirement, I would suggest
 >> not bothering to package the docs for now.
 >
 > I hope to get 6.0.0-rc1 added to the flathub-beta channel over the
 > weekend and this was an item still missing on my list.
 >
 > But there is no immediate need at all before the final release. I had
 > included the docs into the flatpak, because this allowed to add a "has
 > (translated) user docs" flag which is one further green box checked in
 > software centers like GNOME Software.
 >
 > It's fine if they don't become ready in time. I will then just remove
 > that box again until they become ready at some later point.

You can download the doc as a tar from the following URL:


https://gitlab.com/kicad/services/kicad-doc/-/archive/6.0.0-rc1/kicad-doc-6.0.0-rc1.tar.bz2
 
<https://gitlab.com/kicad/services/kicad-doc/-/archive/6.0.0-rc1/kicad-doc-6.0.0-rc1.tar.bz2>

You can also change the "bz2" to "gz" if you prefer that format.

BTW, I've made the 6.0.0-rc1 builds for Fedora Rawhide, but they haven't 
been picked up by the mirrors yet.

I will not make 6.0.0 builds for Fedora 34 / 35 etc, because it is against 
policy to have a major version change on those.  Thus Fedora 36 (in about 6 
months) will be the first one that ships a 6.0.0 build.

         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] Version 6 release candidate 1

[Steven A. Falco]

On 11/18/21 03:04 PM, Johannes Maibaum wrote:

Am Donnerstag, dem 18.11.2021 um 14:58 -0500 schrieb Jon Evans:

When do you need it by?  The docs are nowhere near ready for the
final release, so if this isn't a hard requirement, I would suggest
not bothering to package the docs for now.


I hope to get 6.0.0-rc1 added to the flathub-beta channel over the
weekend and this was an item still missing on my list.

But there is no immediate need at all before the final release. I had
included the docs into the flatpak, because this allowed to add a "has
(translated) user docs" flag which is one further green box checked in
software centers like GNOME Software.

It's fine if they don't become ready in time. I will then just remove
that box again until they become ready at some later point.


You can download the doc as a tar from the following URL:

https://gitlab.com/kicad/services/kicad-doc/-/archive/6.0.0-rc1/kicad-doc-6.0.0-rc1.tar.bz2

You can also change the "bz2" to "gz" if you prefer that format.

BTW, I've made the 6.0.0-rc1 builds for Fedora Rawhide, but they haven't been 
picked up by the mirrors yet.

I will not make 6.0.0 builds for Fedora 34 / 35 etc, because it is against 
policy to have a major version change on those.  Thus Fedora 36 (in about 6 
months) will be the first one that ships a 6.0.0 build.

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] Version 6 release candidate 1

[Steven A. Falco]

Thanks for the update.  I'm preparing a test build for Fedora Rawhide as we 
speak. :-)

Steve

On 11/16/21 03:52 PM, Seth Hillbrand wrote:

Hi Steven-

The other 5 repos (docs, symbols, footprints, templates and packages3d) are 
tagged.  i18n is integrated into the v6 source repository and won't be tagged 
separately.

Seth

On Tue, Nov 16, 2021 at 7:14 AM Seth Hillbrand mailto:s...@kipro-pcb.com>> wrote:

They'll be tagged today

-Seth

On Tue, Nov 16, 2021, 6:27 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

So far, only the code/kicad repo has been tagged for 6.0.0-rc1.  In 
order to build trial Fedora packages, as you describe below, I'll need the 
other 6 repos tagged to match.

I realize that we are very early in this process, but is there a feel 
for when the remaining repos will be tagged?

         Steve

On 11/15/21 10:00 PM, Wayne Stambaugh wrote:
 > Release candidate 1 of version 6 has been tagged and pushed.  
Package builds should be available in the next few days for most systems.  There 
are still a few minor issues which should get fixed by stable release 6.0.0.  If 
all goes well, the stable release should be ready by the end of the year.  Thank 
you to the entire KiCad development team for there effort in getting RC1 out.
 >
 > Enjoy,
 >
 > Wayne
 >
 > ___
 > Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
 > Post to : kicad-developers@lists.launchpad.net 
<mailto: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>


___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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 <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto: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

Re: [Kicad-developers] License question

[Steven A. Falco]

Ok - just to confirm, I will use the settings I showed below for the nightlies 
for the upcoming 6.x packages.

I will leave the 5.x series as AGPLv3+ etc., since that matches the 
LICENSE.README file in the 5.1 sources.

Thanks for confirming.

Steve

On 11/16/21 02:37 PM, Wayne Stambaugh wrote:

Hi Steven,

I don't remember the 3D model or documentation licensing changing.  The source 
license did change from AGPLv3+ to GPLv3+.

Cheers,

Wayne

On 11/16/21 11:17 AM, Steven A. Falco wrote:

As we get close to releasing 6.x builds, I'd like to make sure our packages 
specify the correct license terms.

As of now, for Fedora, here is what we have.

Version 5.1.12:
===
Main package = AGPLv3+
3D Models = CC-BY-SA 4.0 with exception
documentation = GPLv3+ or CC-BY-3.0+


Nightly builds (5.99) and 6.x:
==
Main package = GPLv3+
3D Models = CC-BY-SA
documentation = GPLv3+ or CC-BY


Are the above specified correctly, or should something be changed?

Also, I assume 6.x and the 5.99 nightlies should use the same license terms, 
but if they should be different, please let me know.


Note: Fedora supports rather nuanced license terms, as described in [1].  In particular we can 
specify dual licenses via "or" terms, and we can specify different licenses for separate 
parts of a project using "and" terms.  Nested combinations of the above are also allowed. 
Consequently, the license specifier can get very complex, but I'd like to keep it as simple as is 
practical.

 Thanks,
 Steve

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/


___
Mailing list: https://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] License question

[Steven A. Falco]

As we get close to releasing 6.x builds, I'd like to make sure our packages 
specify the correct license terms.

As of now, for Fedora, here is what we have.

Version 5.1.12:
===
Main package = AGPLv3+
3D Models = CC-BY-SA 4.0 with exception
documentation = GPLv3+ or CC-BY-3.0+


Nightly builds (5.99) and 6.x:
==
Main package = GPLv3+
3D Models = CC-BY-SA
documentation = GPLv3+ or CC-BY


Are the above specified correctly, or should something be changed?

Also, I assume 6.x and the 5.99 nightlies should use the same license terms, 
but if they should be different, please let me know.


Note: Fedora supports rather nuanced license terms, as described in [1].  In particular we can 
specify dual licenses via "or" terms, and we can specify different licenses for separate 
parts of a project using "and" terms.  Nested combinations of the above are also allowed. 
 Consequently, the license specifier can get very complex, but I'd like to keep it as simple as is 
practical.

Thanks,
Steve

[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/


___
Mailing list: https://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] Version 6 release candidate 1

[Steven A. Falco]

So far, only the code/kicad repo has been tagged for 6.0.0-rc1.  In order to 
build trial Fedora packages, as you describe below, I'll need the other 6 repos 
tagged to match.

I realize that we are very early in this process, but is there a feel for when 
the remaining repos will be tagged?

Steve

On 11/15/21 10:00 PM, Wayne Stambaugh wrote:

Release candidate 1 of version 6 has been tagged and pushed.  Package builds 
should be available in the next few days for most systems.  There are still a 
few minor issues which should get fixed by stable release 6.0.0.  If all goes 
well, the stable release should be ready by the end of the year.  Thank you to 
the entire KiCad development team for there effort in getting RC1 out.

Enjoy,

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

[Kicad-developers] Test email - For some reason I'm no longer getting launchpad emails

[Steven A. Falco]

This is a test email - please ignore.

For some reason, the last email I received from launchpad was on 2021-10-08 at the time 
the "Launchpad bug tracker closure" email went out.

Thus, I missed the emails about domain name changes, the 5.1.11 release, etc.

I've tried to reset my email address in launchpad.  Let's see if that helped.  
Hopefully, launchpad will send me a copy of this email.

Sorry for the test.

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] Problem compiling 5.1, maybe from commit 2975e859500

[Steven A. Falco]

Thanks, Wayne - that is a clear improvement.

Steve

On 9/14/21 11:13, Wayne Stambaugh wrote:

On 9/14/21 10:05 AM, Steven A. Falco wrote:

Thanks, Jeff.  It looks like "make clean" does the right thing - it
removes "include/page_layout_reader_lexer.h", among others.

I was used to just blowing away the build directory to clean up, but now
I know that that is not sufficient for KiCAD, because it writes
generated files into its source area.


In master, the generated files are written to the build directory.  This
only applies to the 5.1 branch.



And of course there is always "git clean -fdx" when you really want a
pristine tree. :-)

 Steve

On 9/14/21 09:52, Jeff Young wrote:

This normally happens when you’re building both 5.1 and 5.99 in a
single tree.  I have to delete them a lot as I do that.

But I haven’t a clue how it’s /supposed/ to be.  When I have a working
build (even if it’s clunky), I tend to be very hesitant to change
/anything/. ;)


On 14 Sep 2021, at 14:27, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

It looks like the problem is that the definition of T_kicad_wks
appears in a generated file: include/page_layout_reader_lexer.h

However, while I do "out of tree" builds, page_layout_reader_lexer.h
is not created in the build directory, but rather it is created in
the source directory.

So when I deleted my build directory to force a clean build,
page_layout_reader_lexer.h was not deleted / re-created, hence the
new definition was not found.

Is the intention to have page_layout_reader_lexer.h be created in the
source directory or in the build directory?

Steve

On 9/13/21 17:17, Steven A. Falco wrote:

I'm getting the following error compiling the 5.1 branch:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
In member function ‘void
PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:22:
error: ‘T_kicad_wks’ was not declared in this scope
   131 | if( token == T_kicad_wks || token == T_drawing_sheet )
   |  ^~~
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:46:
error: ‘T_drawing_sheet’ was not declared in this scope
   131 | if( token == T_kicad_wks || token == T_drawing_sheet )
   |  ^~~
This appears to be due to commit 2975e859500, which added this code:
+    if( token == T_kicad_wks || token == T_drawing_sheet )
+    {
+    THROW_PARSE_ERROR( _( "KiCad was unable to open this
file because it was created with "
+  "a more recent version than the
one you are running.\n\n"
+  "To open it you will need to
upgrade KiCad to 5.99 or later." ),
+   CurSource(), CurLine(),
CurLineNumber(), CurOffset() );
+    }
+
 Steve



___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto: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>





___
Mailing list: https://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] Problem compiling 5.1, maybe from commit 2975e859500

[Steven A. Falco]

Thanks, Jeff.  It looks like "make clean" does the right thing - it removes 
"include/page_layout_reader_lexer.h", among others.

I was used to just blowing away the build directory to clean up, but now I know 
that that is not sufficient for KiCAD, because it writes generated files into 
its source area.

And of course there is always "git clean -fdx" when you really want a pristine 
tree. :-)

Steve

On 9/14/21 09:52, Jeff Young wrote:

This normally happens when you’re building both 5.1 and 5.99 in a single tree.  
I have to delete them a lot as I do that.

But I haven’t a clue how it’s /supposed/ to be.  When I have a working build 
(even if it’s clunky), I tend to be very hesitant to change /anything/. ;)


On 14 Sep 2021, at 14:27, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

It looks like the problem is that the definition of T_kicad_wks appears in a 
generated file: include/page_layout_reader_lexer.h

However, while I do "out of tree" builds, page_layout_reader_lexer.h is not 
created in the build directory, but rather it is created in the source directory.

So when I deleted my build directory to force a clean build, 
page_layout_reader_lexer.h was not deleted / re-created, hence the new 
definition was not found.

Is the intention to have page_layout_reader_lexer.h be created in the source 
directory or in the build directory?

Steve

On 9/13/21 17:17, Steven A. Falco wrote:

I'm getting the following error compiling the 5.1 branch:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
 In member function ‘void PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:22:
 error: ‘T_kicad_wks’ was not declared in this scope
  131 | if( token == T_kicad_wks || token == T_drawing_sheet )
  |  ^~~
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:46:
 error: ‘T_drawing_sheet’ was not declared in this scope
  131 | if( token == T_kicad_wks || token == T_drawing_sheet )
  |  ^~~
This appears to be due to commit 2975e859500, which added this code:
+    if( token == T_kicad_wks || token == T_drawing_sheet )
+    {
+    THROW_PARSE_ERROR( _( "KiCad was unable to open this file because it 
was created with "
+  "a more recent version than the one you are 
running.\n\n"
+  "To open it you will need to upgrade KiCad to 
5.99 or later." ),
+   CurSource(), CurLine(), CurLineNumber(), 
CurOffset() );
+    }
+
Steve



___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to : kicad-developers@lists.launchpad.net 
<mailto: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>





___
Mailing list: https://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] Problem compiling 5.1, maybe from commit 2975e859500

[Steven A. Falco]

It looks like the problem is that the definition of T_kicad_wks appears in a 
generated file: include/page_layout_reader_lexer.h

However, while I do "out of tree" builds, page_layout_reader_lexer.h is not 
created in the build directory, but rather it is created in the source directory.

So when I deleted my build directory to force a clean build, 
page_layout_reader_lexer.h was not deleted / re-created, hence the new 
definition was not found.

Is the intention to have page_layout_reader_lexer.h be created in the source 
directory or in the build directory?

Steve

On 9/13/21 17:17, Steven A. Falco wrote:

I'm getting the following error compiling the 5.1 branch:

/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
 In member function ‘void PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:22:
 error: ‘T_kicad_wks’ was not declared in this scope
   131 | if( token == T_kicad_wks || token == T_drawing_sheet )
   |  ^~~
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:46:
 error: ‘T_drawing_sheet’ was not declared in this scope
   131 | if( token == T_kicad_wks || token == T_drawing_sheet )
   |  ^~~

This appears to be due to commit 2975e859500, which added this code:

+    if( token == T_kicad_wks || token == T_drawing_sheet )
+    {
+    THROW_PARSE_ERROR( _( "KiCad was unable to open this file because it 
was created with "
+  "a more recent version than the one you are 
running.\n\n"
+  "To open it you will need to upgrade KiCad to 
5.99 or later." ),
+   CurSource(), CurLine(), CurLineNumber(), 
CurOffset() );
+    }
+

 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

[Kicad-developers] Problem compiling 5.1, maybe from commit 2975e859500

[Steven A. Falco]

I'm getting the following error compiling the 5.1 branch:

/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
 In member function ‘void PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:22:
 error: ‘T_kicad_wks’ was not declared in this scope
  131 | if( token == T_kicad_wks || token == T_drawing_sheet )
  |  ^~~
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:46:
 error: ‘T_drawing_sheet’ was not declared in this scope
  131 | if( token == T_kicad_wks || token == T_drawing_sheet )
  |  ^~~

This appears to be due to commit 2975e859500, which added this code:

+if( token == T_kicad_wks || token == T_drawing_sheet )
+{
+THROW_PARSE_ERROR( _( "KiCad was unable to open this file because it 
was created with "
+  "a more recent version than the one you are 
running.\n\n"
+  "To open it you will need to upgrade KiCad to 
5.99 or later." ),
+   CurSource(), CurLine(), CurLineNumber(), 
CurOffset() );
+}
+

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] ngspice library version

[Steven A. Falco]

Thanks for the pointer to the issue, Holger.

I've added a comment describing the root cause in detail, along with a proposed 
patch for discussion.  The patch would have to be cleaned up a bit, and tested 
with Windows and Mac by devs who have access to those build environments.  Or a 
different approach could be suggested by a CMake expert.

But it would be really good to resolve this, because the failure causes a hard 
crash of KiCAD, which could result in lost work.

Steve

On 8/24/21 5:24 AM, Holger Vogt wrote:

No new contribution, but just for completeness:

https://gitlab.com/kicad/code/kicad/-/issues/8878

https://lists.launchpad.net/kicad-developers/msg45289.html

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] ngspice library version

[Steven A. Falco]

Attached is an ugly patch that would correct the problem I reported, at least 
on Linux.  Hopefully, someone better versed in CMake than I can come up with 
something less hacky.  Also, I don't know if my ugly patch would break other OS 
builds.  Thus, this patch is just to stimulate discussion - I don't propose 
adopting it as is.

Basically, I just keep chopping numeric suffixes until I get down to the MAJOR 
ABI version, which I leave intact.  So, for typical Linux systems, the patch 
removes the last two numbers from the file name, changing something like 
libngspice.so.0.0.1 into libngspice.so.0

Btw, I tried using ABSOLUTE rather than REALPATH, but that is too aggressive.  
It removed _all_ numbers from the file name, including the MAJOR ABI version.

Steve

On 8/23/21 2:36 PM, Steven A. Falco wrote:

Please look at eeschema/CMakeLists.txt around line 9.  We have:

if( KICAD_SPICE )
     set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )

     # Find out the exact libngspice file name
     get_filename_component( NGSPICE_DLL_REALPATH "${NGSPICE_DLL}" REALPATH )
     get_filename_component( NGSPICE_DLL_FILE "${NGSPICE_DLL_REALPATH}" NAME )

     set_property( SOURCE sim/ngspice.cpp
     APPEND PROPERTY COMPILE_DEFINITIONS
     NGSPICE_DLL_FILE="${NGSPICE_DLL_FILE}"
     )
endif()

Note that "REALPATH" is being used, which according to the CMake documentation resolves 
symlinks.  I.e.: "REALPATH  = Full path to existing file with symlinks resolved"

So, it would seem that the root cause here is that CMake finds 
/usr/lib64/libngspice.so and then resolves it by following the links and winds 
up with a name like libngspice.so.0.0.0 or libngspice.so.0.0.1, which is too 
specific for a hard-coded variable.

Why are we using REALPATH?  Should that be changed to ABSOLUTE or something 
else?  I'm not a CMake expert btw, but it seems that REALPATH is not what we 
want here.

 Steve

On 8/23/21 1:42 PM, Steven A. Falco wrote:

Comments below.

On 8/23/21 11:45 AM, Reece R. Pollack wrote:

It doesn't matter what file name is used for the .so when linking an 
application. The SONAME of the library is embedded in the library file itself, 
and is extracted from the library when the application is linked.

Does the Fedora package that provides libngspice create the appropriate symlink 
"libngspice.so.0" to the actual image file "libngspice.so.0.0.1"?


Here are the links on a failing machine.  They look fine.

$ ls -l /lib64 | grep libngspice*
lrwxrwxrwx    1 root root    19 Aug  9 00:32 libngspice.so.0 -> 
libngspice.so.0.0.1*
lrwxrwxrwx    1 root root    19 Aug  9 00:32 libngspice.so -> 
libngspice.so.0.0.1*
-rwxr-xr-x    1 root root  10442176 Aug  9 00:51 libngspice.so.0.0.1*


What does ldd show on the failing systems (not your system)? The string to the right of the 
"=>" is the name of the file that satisfies the requirement /on that system/ and is 
determined by ldd at the time ldd is run. If this shows "not found", then there is a 
libngspice configuration problem on that system.


ldd reports that /lib64/libngspice.so.0 will satisfy the dependency and is 
present on the system.  However, that is not how KiCAD actually loads the 
library, as I'll discuss below.

$ ldd _eeschema.kiface | grep spice
 libngspice.so.0 => /lib64/libngspice.so.0 (0x7f075e3f7000)


My guess is that the symlinks are installed as part of the development package 
for libngspice and not as part of the base package that provides the library 
itself. This is a common packaging error.

The problem is that KiCAD manually tries to load the library, using a call to 
m_dll.Load((), based on the NGSPICE_DLL_FILE variable, rather than using the 
normal linking mechanism.

Please see NGSPICE::init_dll() around line 278 in eeschema/sim/ngspice.cpp.  
Specifically, the #else clause at line 324 has  m_dll.Load( NGSPICE_DLL_FILE 
);.  Unfortunately, at the time the build was made, the build system set 
NGSPICE_DLL_FILE to libngspice.so.0.0.0, because that was the current version 
at the time of the build.  But that version is no longer present on the failing 
system; now it has libngspice.so.0.0.1 instead.

The libngspice.so.0.0.0 version is therefore hard compiled into the program, 
and no links can fix that.

Thus, for KiCAD to be able to manually load the library, we need to change the 
way the NGSPICE_DLL_FILE variable is computed.  It needs to be set to the more 
generic libngspice.so.0 rather than libngspice.so.0.0.0 or libngspice.so.0.0.1, 
because the latter are too specific, and won't necessarily survive a system 
upgrade.

 Steve


-Reece

On 8/23/21 11:06 AM, Steven A. Falco wrote:

I've done a bit of digging.  According to ldd, the desired version is 
appropriate, just specifying the first digit of the version info:

libngspice.so.0 => /lib64/libngspice.so.0 (0x7f70913de000

Re: [Kicad-developers] ngspice library version

[Steven A. Falco]

Please look at eeschema/CMakeLists.txt around line 9.  We have:

if( KICAD_SPICE )
set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )

# Find out the exact libngspice file name
get_filename_component( NGSPICE_DLL_REALPATH "${NGSPICE_DLL}" REALPATH )
get_filename_component( NGSPICE_DLL_FILE "${NGSPICE_DLL_REALPATH}" NAME )

set_property( SOURCE sim/ngspice.cpp
APPEND PROPERTY COMPILE_DEFINITIONS
NGSPICE_DLL_FILE="${NGSPICE_DLL_FILE}"
)
endif()

Note that "REALPATH" is being used, which according to the CMake documentation resolves 
symlinks.  I.e.: "REALPATH  = Full path to existing file with symlinks resolved"

So, it would seem that the root cause here is that CMake finds 
/usr/lib64/libngspice.so and then resolves it by following the links and winds 
up with a name like libngspice.so.0.0.0 or libngspice.so.0.0.1, which is too 
specific for a hard-coded variable.

Why are we using REALPATH?  Should that be changed to ABSOLUTE or something 
else?  I'm not a CMake expert btw, but it seems that REALPATH is not what we 
want here.

Steve

On 8/23/21 1:42 PM, Steven A. Falco wrote:

Comments below.

On 8/23/21 11:45 AM, Reece R. Pollack wrote:

It doesn't matter what file name is used for the .so when linking an 
application. The SONAME of the library is embedded in the library file itself, 
and is extracted from the library when the application is linked.

Does the Fedora package that provides libngspice create the appropriate symlink 
"libngspice.so.0" to the actual image file "libngspice.so.0.0.1"?


Here are the links on a failing machine.  They look fine.

$ ls -l /lib64 | grep libngspice*
lrwxrwxrwx    1 root root    19 Aug  9 00:32 libngspice.so.0 -> 
libngspice.so.0.0.1*
lrwxrwxrwx    1 root root    19 Aug  9 00:32 libngspice.so -> 
libngspice.so.0.0.1*
-rwxr-xr-x    1 root root  10442176 Aug  9 00:51 libngspice.so.0.0.1*


What does ldd show on the failing systems (not your system)? The string to the right of the 
"=>" is the name of the file that satisfies the requirement /on that system/ and is 
determined by ldd at the time ldd is run. If this shows "not found", then there is a 
libngspice configuration problem on that system.


ldd reports that /lib64/libngspice.so.0 will satisfy the dependency and is 
present on the system.  However, that is not how KiCAD actually loads the 
library, as I'll discuss below.

$ ldd _eeschema.kiface | grep spice
     libngspice.so.0 => /lib64/libngspice.so.0 (0x7f075e3f7000)


My guess is that the symlinks are installed as part of the development package 
for libngspice and not as part of the base package that provides the library 
itself. This is a common packaging error.

The problem is that KiCAD manually tries to load the library, using a call to 
m_dll.Load((), based on the NGSPICE_DLL_FILE variable, rather than using the 
normal linking mechanism.

Please see NGSPICE::init_dll() around line 278 in eeschema/sim/ngspice.cpp.  
Specifically, the #else clause at line 324 has  m_dll.Load( NGSPICE_DLL_FILE 
);.  Unfortunately, at the time the build was made, the build system set 
NGSPICE_DLL_FILE to libngspice.so.0.0.0, because that was the current version 
at the time of the build.  But that version is no longer present on the failing 
system; now it has libngspice.so.0.0.1 instead.

The libngspice.so.0.0.0 version is therefore hard compiled into the program, 
and no links can fix that.

Thus, for KiCAD to be able to manually load the library, we need to change the 
way the NGSPICE_DLL_FILE variable is computed.  It needs to be set to the more 
generic libngspice.so.0 rather than libngspice.so.0.0.0 or libngspice.so.0.0.1, 
because the latter are too specific, and won't necessarily survive a system 
upgrade.

 Steve


-Reece

On 8/23/21 11:06 AM, Steven A. Falco wrote:

I've done a bit of digging.  According to ldd, the desired version is 
appropriate, just specifying the first digit of the version info:

libngspice.so.0 => /lib64/libngspice.so.0 (0x7f70913de000)

However, according to eeschema_kiface.dir/build.make we have 
-DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" as shown in this excerpt:

cd /builddir/build/BUILD/kicad-5.1.10/x86_64-redhat-linux-gnu/eeschema && /usr/bin/g++ 
$(CXX_DEFINES) -DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" $(CXX_INCLUDES) $(CXX_FLAGS) 
-MD -MT eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -MF 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o.d -o 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -c 
/builddir/build/BUILD/kicad-5.1.10/eeschema/sim/ngspice.cpp

Since eeschema/sim/ngspice.cpp explicitly uses the NGSPICE_DLL_FILE variable to 
load the DLL, that is apparently why the more general ldd version is not used.

eeschema/sim/ngspice.cpp:    m_dll.Load( NGSPICE_DLL_FILE );

So it seems the fix would be to tr

Re: [Kicad-developers] ngspice library version

[Steven A. Falco]

Comments below.

On 8/23/21 11:45 AM, Reece R. Pollack wrote:

It doesn't matter what file name is used for the .so when linking an 
application. The SONAME of the library is embedded in the library file itself, 
and is extracted from the library when the application is linked.

Does the Fedora package that provides libngspice create the appropriate symlink 
"libngspice.so.0" to the actual image file "libngspice.so.0.0.1"?


Here are the links on a failing machine.  They look fine.

$ ls -l /lib64 | grep libngspice*
lrwxrwxrwx1 root root19 Aug  9 00:32 libngspice.so.0 -> 
libngspice.so.0.0.1*
lrwxrwxrwx1 root root19 Aug  9 00:32 libngspice.so -> 
libngspice.so.0.0.1*
-rwxr-xr-x1 root root  10442176 Aug  9 00:51 libngspice.so.0.0.1*


What does ldd show on the failing systems (not your system)? The string to the right of the 
"=>" is the name of the file that satisfies the requirement /on that system/ and is 
determined by ldd at the time ldd is run. If this shows "not found", then there is a 
libngspice configuration problem on that system.


ldd reports that /lib64/libngspice.so.0 will satisfy the dependency and is 
present on the system.  However, that is not how KiCAD actually loads the 
library, as I'll discuss below.

$ ldd _eeschema.kiface | grep spice
libngspice.so.0 => /lib64/libngspice.so.0 (0x7f075e3f7000)


My guess is that the symlinks are installed as part of the development package 
for libngspice and not as part of the base package that provides the library 
itself. This is a common packaging error.

The problem is that KiCAD manually tries to load the library, using a call to 
m_dll.Load((), based on the NGSPICE_DLL_FILE variable, rather than using the 
normal linking mechanism.

Please see NGSPICE::init_dll() around line 278 in eeschema/sim/ngspice.cpp.  
Specifically, the #else clause at line 324 has  m_dll.Load( NGSPICE_DLL_FILE 
);.  Unfortunately, at the time the build was made, the build system set 
NGSPICE_DLL_FILE to libngspice.so.0.0.0, because that was the current version 
at the time of the build.  But that version is no longer present on the failing 
system; now it has libngspice.so.0.0.1 instead.

The libngspice.so.0.0.0 version is therefore hard compiled into the program, 
and no links can fix that.

Thus, for KiCAD to be able to manually load the library, we need to change the 
way the NGSPICE_DLL_FILE variable is computed.  It needs to be set to the more 
generic libngspice.so.0 rather than libngspice.so.0.0.0 or libngspice.so.0.0.1, 
because the latter are too specific, and won't necessarily survive a system 
upgrade.

    Steve


-Reece

On 8/23/21 11:06 AM, Steven A. Falco wrote:

I've done a bit of digging.  According to ldd, the desired version is 
appropriate, just specifying the first digit of the version info:

libngspice.so.0 => /lib64/libngspice.so.0 (0x7f70913de000)

However, according to eeschema_kiface.dir/build.make we have 
-DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" as shown in this excerpt:

cd /builddir/build/BUILD/kicad-5.1.10/x86_64-redhat-linux-gnu/eeschema && /usr/bin/g++ 
$(CXX_DEFINES) -DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" $(CXX_INCLUDES) $(CXX_FLAGS) 
-MD -MT eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -MF 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o.d -o 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -c 
/builddir/build/BUILD/kicad-5.1.10/eeschema/sim/ngspice.cpp

Since eeschema/sim/ngspice.cpp explicitly uses the NGSPICE_DLL_FILE variable to 
load the DLL, that is apparently why the more general ldd version is not used.

eeschema/sim/ngspice.cpp:    m_dll.Load( NGSPICE_DLL_FILE );

So it seems the fix would be to truncate NGSPICE_DLL_FILE to remove the MAJOR.MINOR 
component and just have -DNGSPICE_DLL_FILE=\"libngspice.so.0\"

Steve

On 8/23/21 10:29 AM, Steven A. Falco wrote:

I just got a bug report for the official Fedora version of KiCAD stating that 
ngspice was not found.  An attempt to perform a simulation results in KiCAD 
crashing.

The Fedora KiCAD package specifies libngspice.so.0.0.0, but the library has now 
bumped to libngspice.so.0.0.1.  I would have expected that to be fine, because 
the new library should be compatible.  But apparently, the loader is looking 
for an exact match, and refuses to use the newer library.

For now, I'm rebuilding the official package to match the new ngspice library, 
but I'm wondering if there is a way to improve this situation, such that KiCAD 
links with libngspice.0 rather than insisting on an exact match of the minor 
number.

 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] ngspice library version

[Steven A. Falco]

Thanks for the info.  The SONAME is correct:

$ objdump -p /lib64/libngspice.so.0.0.1 | grep SONAME
  SONAME   libngspice.so.0

As I discovered and mentioned in my second email, the problem seems to be in 
the explicit loading of $NGSPICE_DLL_FILE, which is set to the more constrained 
name.

I'll check out the link you provided.

Thanks,
Steve


On 8/23/21 11:28 AM, Reece R. Pollack wrote:

Typically the way this is handled is that the application is linked against a 
symlink to the library that references the library's SONAME rather than the 
full name of the library. In the runtime system, a symlink with this name 
points at the correct file.

To check the SONAME in the library, use this incantation:

objdump -p //path/to/library/ |grep SONAME

I run Kubuntu rather than Fedora, so I don't know the SONAME of Fedora's 
libngspice. On Kubuntu 20.04, I get this:

$ objdump -p /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 |grep SONAME
   SONAME   libngspice.so.0

On the build system, I have these files:

libngspice.so -> libngspice.so.0.0.0
libngspice.so.0 -> libngspice.so.0.0.0
libngspice.so.0.0.0

The application developer typically links against libngspice.so rather than 
libngspice.so.0.0.0 to avoid having to know which library version is installed. 
At build time the linker will pick up the SONAME embedded in this .so file.

At runtime the loader will use the SONAME to find the library. You can use "ldd" to see what 
libraries the built application is linked against. The part to the left of the "=>" is 
the SONAME, and the part to the right is the name of the file that will be used on /this/ system.

Here's a link to the Debian policy on shared libraries for a detailed 
explanation of how this works:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html


On 8/23/21 10:29 AM, Steven A. Falco wrote:

I just got a bug report for the official Fedora version of KiCAD stating that 
ngspice was not found.  An attempt to perform a simulation results in KiCAD 
crashing.

The Fedora KiCAD package specifies libngspice.so.0.0.0, but the library has now 
bumped to libngspice.so.0.0.1.  I would have expected that to be fine, because 
the new library should be compatible.  But apparently, the loader is looking 
for an exact match, and refuses to use the newer library.

For now, I'm rebuilding the official package to match the new ngspice library, 
but I'm wondering if there is a way to improve this situation, such that KiCAD 
links with libngspice.0 rather than insisting on an exact match of the minor 
number.

Steve

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] ngspice library version

[Steven A. Falco]

I've done a bit of digging.  According to ldd, the desired version is 
appropriate, just specifying the first digit of the version info:

libngspice.so.0 => /lib64/libngspice.so.0 (0x7f70913de000)

However, according to eeschema_kiface.dir/build.make we have 
-DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" as shown in this excerpt:

cd /builddir/build/BUILD/kicad-5.1.10/x86_64-redhat-linux-gnu/eeschema && /usr/bin/g++ 
$(CXX_DEFINES) -DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" $(CXX_INCLUDES) $(CXX_FLAGS) 
-MD -MT eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -MF 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o.d -o 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -c 
/builddir/build/BUILD/kicad-5.1.10/eeschema/sim/ngspice.cpp

Since eeschema/sim/ngspice.cpp explicitly uses the NGSPICE_DLL_FILE variable to 
load the DLL, that is apparently why the more general ldd version is not used.

eeschema/sim/ngspice.cpp:m_dll.Load( NGSPICE_DLL_FILE );

So it seems the fix would be to truncate NGSPICE_DLL_FILE to remove the MAJOR.MINOR 
component and just have -DNGSPICE_DLL_FILE=\"libngspice.so.0\"

    Steve

On 8/23/21 10:29 AM, Steven A. Falco wrote:

I just got a bug report for the official Fedora version of KiCAD stating that 
ngspice was not found.  An attempt to perform a simulation results in KiCAD 
crashing.

The Fedora KiCAD package specifies libngspice.so.0.0.0, but the library has now 
bumped to libngspice.so.0.0.1.  I would have expected that to be fine, because 
the new library should be compatible.  But apparently, the loader is looking 
for an exact match, and refuses to use the newer library.

For now, I'm rebuilding the official package to match the new ngspice library, 
but I'm wondering if there is a way to improve this situation, such that KiCAD 
links with libngspice.0 rather than insisting on an exact match of the minor 
number.

 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

[Kicad-developers] ngspice library version

[Steven A. Falco]

I just got a bug report for the official Fedora version of KiCAD stating that 
ngspice was not found.  An attempt to perform a simulation results in KiCAD 
crashing.

The Fedora KiCAD package specifies libngspice.so.0.0.0, but the library has now 
bumped to libngspice.so.0.0.1.  I would have expected that to be fine, because 
the new library should be compatible.  But apparently, the loader is looking 
for an exact match, and refuses to use the newer library.

For now, I'm rebuilding the official package to match the new ngspice library, 
but I'm wondering if there is a way to improve this situation, such that KiCAD 
links with libngspice.0 rather than insisting on an exact match of the minor 
number.

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] Problem building on Fedora Rawhide

[Steven A. Falco]

This has now been corrected in Fedora rawhide as described in [1], which let me 
close the associated KiCAD FTBFS in [2].

I don't know if this issue is unique to Fedora or if others will see the same 
problem.  I guess that depends on whether/when the upstream python3-wxpython4 
project corrects the problem.  I've attached the patch to python3-wxpython4 in 
case it is useful to anyone.

Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1990001

On 7/30/21 11:39 AM, Steven A. Falco wrote:

I decided to file a bug on Fedora [1].

I also saw a similar issue on the wxWidgets site and added a comment [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
[2] https://github.com/wxWidgets/Phoenix/issues/1963

     Steve

On 7/30/21 10:58 AM, Steven A. Falco wrote:

I just updated my rawhide VM, and you are quite correct:

rawhide$ python -c "import wx;print(wx.version())"
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
Aborted (core dumped)

I'll post on the Fedora mailing list and see where they want the bug filed.

 Steve


On 7/30/21 10:48 AM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 <http://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 <http://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("C

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

[Steven A. Falco]

I decided to file a bug on Fedora [1].

I also saw a similar issue on the wxWidgets site and added a comment [2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
[2] https://github.com/wxWidgets/Phoenix/issues/1963

Steve

On 7/30/21 10:58 AM, Steven A. Falco wrote:

I just updated my rawhide VM, and you are quite correct:

rawhide$ python -c "import wx;print(wx.version())"
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
Aborted (core dumped)

I'll post on the Fedora mailing list and see where they want the bug filed.

 Steve


On 7/30/21 10:48 AM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 <http://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 <http://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/lo

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

[Steven A. Falco]

I just updated my rawhide VM, and you are quite correct:

rawhide$ python -c "import wx;print(wx.version())"
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
Aborted (core dumped)

I'll post on the Fedora mailing list and see where they want the bug filed.

Steve


On 7/30/21 10:48 AM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 <http://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 <http://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\$  --seten

[Kicad-developers] Problem building on Fedora Rawhide

[Steven A. Falco]

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

Re: [Kicad-developers] Problem opening a PCB file

[Steven A. Falco]

On 7/6/21 12:04 PM, jp charras wrote:


Le 06/07/2021 à 17:55, Steven A. Falco a écrit :

On 7/6/21 11:30 AM, jp charras wrote:


Le 06/07/2021 à 17:17, Steven A. Falco a écrit :

I've found a project on github [1] that I am interested in, but I have not been 
able to open the PCB file correctly.  It seems that 5.1 is too old to handle 
this file, but 5.99 has several issues, as described in [2].

It looks like the ground plane is not being processed properly.  I also noted that the 
three "zone" buttons on the left pane of pcb_new are grayed out, which seems 
very strange.

I'm not sure if the original project authors did something wrong. I see both a 
.pro and a .kicad_pro file in the directory, so they must have switched major 
releases at some point.  But I'd still expect pcb_new to be able to deal with 
the board file.

Steve

[1] https://github.com/phl0/MMDVM_HS_Dual_Hat/tree/master/hardware/r2.0-mini
[2] https://gitlab.com/kicad/code/kicad/-/issues/8739



Just delete the .kicag_prl file, or reenable the visibility of objects.

Jean-Pierre CHARRAS


Thanks - that helps.  But something is still wrong.  When I toggle the pads and 
zones visibility to turn them on, I see the zones filled in, as expected.

But then, when I type ^B, I get 88 unrouted nets, and if I had "Show filled areas of 
zones" selected, the filled zone in the center of the board disappears although the 
zone outline remains.

So it seems that something is still wrong.

Steve - 


^B removes the zone fill. B rebuilds the zone fill.


Jean-Pierre CHARRAS


Ooops.  I feel stupid.  Thanks for the help. :-)

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] Problem opening a PCB file

[Steven A. Falco]

On 7/6/21 11:30 AM, jp charras wrote:


Le 06/07/2021 à 17:17, Steven A. Falco a écrit :

I've found a project on github [1] that I am interested in, but I have not been 
able to open the PCB file correctly.  It seems that 5.1 is too old to handle 
this file, but 5.99 has several issues, as described in [2].

It looks like the ground plane is not being processed properly.  I also noted that the 
three "zone" buttons on the left pane of pcb_new are grayed out, which seems 
very strange.

I'm not sure if the original project authors did something wrong. I see both a 
.pro and a .kicad_pro file in the directory, so they must have switched major 
releases at some point.  But I'd still expect pcb_new to be able to deal with 
the board file.

Steve

[1] https://github.com/phl0/MMDVM_HS_Dual_Hat/tree/master/hardware/r2.0-mini
[2] https://gitlab.com/kicad/code/kicad/-/issues/8739



Just delete the .kicag_prl file, or reenable the visibility of objects.

Jean-Pierre CHARRAS


Thanks - that helps.  But something is still wrong.  When I toggle the pads and 
zones visibility to turn them on, I see the zones filled in, as expected.

But then, when I type ^B, I get 88 unrouted nets, and if I had "Show filled areas of 
zones" selected, the filled zone in the center of the board disappears although the 
zone outline remains.

So it seems that something is still wrong.

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

[Kicad-developers] Problem opening a PCB file

[Steven A. Falco]

I've found a project on github [1] that I am interested in, but I have not been 
able to open the PCB file correctly.  It seems that 5.1 is too old to handle 
this file, but 5.99 has several issues, as described in [2].

It looks like the ground plane is not being processed properly.  I also noted that the 
three "zone" buttons on the left pane of pcb_new are grayed out, which seems 
very strange.

I'm not sure if the original project authors did something wrong.  I see both a 
.pro and a .kicad_pro file in the directory, so they must have switched major 
releases at some point.  But I'd still expect pcb_new to be able to deal with 
the board file.

Steve

[1] https://github.com/phl0/MMDVM_HS_Dual_Hat/tree/master/hardware/r2.0-mini
[2] https://gitlab.com/kicad/code/kicad/-/issues/8739


___
Mailing list: https://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

[Steven A. Falco]

Congrats Roberto!  Glad to have you in a most prominent position!

Steve

On 7/6/21 8:03 AM, 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] Experience compiling latest HEAD

[Steven A. Falco]

For fun, I tried running through the README.md file.  I hit a slight snag in that the 
"flatpak install" prerequisite step failed with:

error: No remote refs found similar to ‘flathub’

It is simple to correct; just run this command prior to the "flatpak install" 
step:

flatpak remote-add --user --if-not-exists flathub 
https://flathub.org/repo/flathub.flatpakrepo

I created an MR [1] for that.

Steve

[1] 
https://gitlab.com/kicad/packaging/kicad-flatpak/kicad-nightly-flatpaks/kicad-nightly-flatpak/-/merge_requests/1


On 6/29/21 9:43 AM, Jon Evans wrote:

Hi Ruth,

You can build the nightly flatpak (with wx 3.1) by grabbing this repository and 
following the instructions in the readme:

https://gitlab.com/kicad/packaging/kicad-flatpak/kicad-nightly-flatpaks/kicad-nightly-flatpak
 


Johannes can probably answer any detailed questions better than I, but I did 
test this a while ago and it worked.

The problem of dependency management on Linux would not be solved by switching 
to Qt.  It's why things like flatpak have been created.
Personally I think to get the best experience with KiCad, one should use 
Flatpak on Linux (if not building everything from source) because KiCad can't 
solve the issues with the way Linux packaging works that mean that many distros 
will not make wxWidgets 3.1 available, but we can at least provide 3.1 on any 
systems where the dependencies are under our control (Windows, Mac, Flatpak)

Best,
Jon

On Tue, Jun 29, 2021 at 9:15 AM Ruth Ivimey-Cook mailto:r...@ivimey.org>> wrote:


On 29/06/2021 12:39, Jeff Young wrote:
 > Windows and Mac are single platforms, so the KiCad team builds those.  
We also build the Linux flatpak, which is statically linked (to 3.1).

Except that the flatpak I installed yesterday is of version 5.1.10 and
that one at least is linked to wx 3.0. If there is another version of
kicad available as a flatpak I am unaware of it.

I need (because of the new lib formats) a 5.99 linked to wx 3.1.

I did try to self-compile, but the DRI linkage stuff broke. I still
don't know why.

Could the team consider making a flatpak of kicad-nightly available,
linked to wx 3.1.x (not necessarily latest), and document on the
relevant page how to install and use it for those like me who are unused
to the flatpak?


 > It’s all the Linux distros that we can’t do much about.
 >
 >> I'm not saying it's ideal to use the possibly broken -dev version of wx, but IMO 
it is worse to use the actually broken "stable" version of it
 > He he… yeah, that about sums up the state of wxWidgets. ;)

I presume KiCad 6 will be released after wx 3.2 is released (stated by
their releases page as 'hopefully in September 2021').

I personally feel the project would be much better off using Qt because
it's a far better supported and designed framework, but I guess that's a
question for another era!

Ruth


 >
 > Cheers,
 > Jeff.
 >
 >
 >> On 29 Jun 2021, at 11:44, Ruth Ivimey-Cook mailto:r...@ivimey.org>> wrote:
 >>
 >>
 >>> wxwidget 3.1 is the development version for the upcoming stable version
 >>> 3.2 which possible breaks the API/ABI with every new version that is
 >>> getting released. That makes this software breaking other software too
 >>> often and by this unfit to get introduced into Debian unstable, it
 >>> simply make to less sense.
 >> Despite this, both the Windows and MacOS builds are using wx 3.1, 
somehow or other
 >>
 >> I'm not saying it's ideal to use the possibly broken -dev version of wx, but IMO 
it is worse to use the actually broken "stable" version of it.
 >>
 >> If needed, select a good-enough build of wx3.1 from the repo I 
referenced and link kicad statically to it, so there can be no pollution of other 
apps.
 >>
 >> Ruth
 >>
 >> --
 >>
 >> Tel: 01223 414180
 >> Blog: http://www.ivimey.org/blog 
 >> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/ 

 >>
 >>
 >> ___
 >> Mailing list: https://launchpad.net/~kicad-developers 

 >> Post to     : kicad-developers@lists.launchpad.net 

 >> Unsubscribe : https://launchpad.net/~kicad-developers 

 >> More help   : https://help.launchpad.net/ListHelp 


-- 
Software Manager & Engineer

Tel: 01223 414180
Blog: http://www.ivimey.org/blog 
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/ 

Re: [Kicad-developers] Python 3 now required

[Steven A. Falco]

I have a related qestion regarding "shebangs" in python code.  In a few files 
we have #!/usr/bin/env python3, which is great, because it fully specifies which 
interpreter to use.  For example tools/create_dark_theme.py has this.

In other files, the python version is not specified, and we just have 
!/usr/bin/env python.  This is ambiguous - you might get python2 or python3 
depending on the OS.  For example, translation/plot_i18n_status.py has this.

Lastly, there are a number of python files that have no shebangs at all.  Fedora's RPM 
builder warns about this on 15 files, and disables the scripts by clearing the 
"executable" bit.  Here is an example:

*** WARNING: ./usr/share/kicad/scripting/plugins/zip_wizard.py is executable 
but has no shebang, removing executable bit

Now that python3 is the only allowed version, can all python files be modified to have 
the "#!/usr/bin/env python3" shebang, or would that negatively impact some 
target OS's?

Steve


On 6/4/21 1:34 PM, Seth Hillbrand wrote:

Hi Folks-

KiCad now officially only supports Python 3.  Note that this comes a full year and 6 months 
after Python 2 was deprecated (https://pythonclock.org/ ) 
and most, if not all, of our supporting packages have pledged to stop supporting Python 2 
(https://python3statement.org/ )

We are now making the same transition.

As part of this transition, we are also binding the Python interpreter more 
closely with KiCad.  This means that we have removed the following build 
settings and set them all to '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

For the moment, `KICAD_SCRIPTING_WXPYTHON` does remain an advanced build 
setting but we'll be moving that to the advanced_config file shortly as it does 
not control a build setting (only a run-time operation).

The current minimum Python version is 3.7 (due to a module test call we use) 
but we are looking at potentially supporting Python 3.6 if we can handle 
dynamic reloads.

A large thank you in this effort goes to Mark Roszko and Adam Wolf who wrangled 
the build requirements for Windows and Mac respectively.  The transition was 
non-trivial and largely invisible.  KiCad has come out better for the work that 
they contributed.  Thank you!

-Seth
--
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] asciidoc

[Steven A. Falco]

Yes - I had to refresh my token too.  By the way, below is a link to the copr 
test build I made (in my private copr) - it passed :-)

https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/build/2215757/

Steve

On 6/3/21 4:32 PM, Nick Østergaard wrote:

Ah,ok, I misread the pipeline logs..

Error: Login invalid/expired. Please visit https://copr.fedorainfracloud.org/api 
<https://copr.fedorainfracloud.org/api> to get or renew your API token.

I gotta update that.

On Thu, 3 Jun 2021 at 22:29, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

The build you are looking at happened before I put in the fix.  In other 
words, I saw that same build failure (on May 30), and put in the fix a few 
hours later.

The next doc build should use rubygem-asciidoctor in place of asciidoc, and 
it should pass.

Can you kick off a manual build of the docs to test that?

         Steve

On 6/3/21 3:26 PM, Nick Østergaard wrote:
     > @Steven A. Falco <mailto:stevenfa...@gmail.com 
<mailto:stevenfa...@gmail.com>>
 >
 > Did you have a look at building the docs for fedora with the other 
package?
 >
 > It appears to still BuildRequires: asciidoc when I look in the spec file in 
https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ 
<https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/> 
<https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ 
<https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/>>
 >
 > On Sun, 30 May 2021 at 22:51, Jon Evans mailto:j...@craftyjon.com> 
<mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>> wrote:
 >
 >     If you use Docker, there is also a container for the docs build 
based on Debian:
 >
 > 
https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
 
<https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base>
 
<https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
 
<https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base>>
 >
 >     Maybe this is also helpful for setting up a Fedora VM or Docker 
container
 >
 >     On Sun, May 30, 2021 at 3:00 PM Steven A. Falco mailto:stevenfa...@gmail.com> <mailto:stevenfa...@gmail.com 
<mailto:stevenfa...@gmail.com>>> wrote:
 >      >
 >      > I'll have to spin up a VM to play with that.  I'll get back to 
you... :-)
 >      >
 >      >         Steve
 >      >
 >      > On 5/30/21 2:34 PM, Jon Evans wrote:
 >      > > You want this one: https://github.com/Mogztter/asciidoctor-web-pdf 
<https://github.com/Mogztter/asciidoctor-web-pdf> 
<https://github.com/Mogztter/asciidoctor-web-pdf 
<https://github.com/Mogztter/asciidoctor-web-pdf>>
 >      > >
 >      > > On Ubuntu I install it with "sudo npm i -g @asciidoctor/core 
asciidoctor-pdf"
 >      > >
 >      > > On Sun, May 30, 2021 at 2:33 PM Steven A. Falco mailto:stevenfa...@gmail.com> <mailto:stevenfa...@gmail.com 
<mailto:stevenfa...@gmail.com>>> wrote:
 >      > >>
 >      > >> I'm able to build the html pages, which is all we need for the 
nightlies, but I am not able to build the pdf files.  I get an error:
 >      > >>
 >      > >>           Could NOT find ASCIIDOCTORPDF (missing: 
ASCIIDOCTORPDF_COMMAND)
 >      > >>
 >      > >> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a program 
called "asciidoctor-web-pdf".
 >      > >>
 >      > >> Fedora has a package "rubygem-asciidoctor-pdf" which provides a program 
called "asciidoctor-pdf".
 >      > >>
 >      > >> I don't know if "asciidoctor-pdf" is equivalent to 
"asciidoctor-web-pdf".  If it is, then perhaps the cmake file should accept either one.
 >      > >>
 >      > >>          Steve
 >      > >>
 >      > >> On 5/30/21 1:58 PM, Steven A. Falco wrote:
 >      > >>> Thanks Jon.
 >      > >>>
 >      > >>> I'm running a test build now.  If it passes, I'll propose a 
patch for the README.  I'll also push the change to the nightly Fedora builds.
 >      > >>>
 >      > >>>       Steve
 >      > >>>
 >      > >>> On 5/30/21 1:51 PM, Jon Evans wrot

Re: [Kicad-developers] asciidoc

[Steven A. Falco]

The build you are looking at happened before I put in the fix.  In other words, 
I saw that same build failure (on May 30), and put in the fix a few hours later.

The next doc build should use rubygem-asciidoctor in place of asciidoc, and it 
should pass.

Can you kick off a manual build of the docs to test that?

Steve

On 6/3/21 3:26 PM, Nick Østergaard wrote:

@Steven A. Falco <mailto:stevenfa...@gmail.com>

Did you have a look at building the docs for fedora with the other package?

It appears to still BuildRequires: asciidoc when I look in the spec file in 
https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ 
<https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/>

On Sun, 30 May 2021 at 22:51, Jon Evans mailto:j...@craftyjon.com>> wrote:

If you use Docker, there is also a container for the docs build based on 
Debian:


https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
 
<https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base>

Maybe this is also helpful for setting up a Fedora VM or Docker container

On Sun, May 30, 2021 at 3:00 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
 >
 > I'll have to spin up a VM to play with that.  I'll get back to you... :-)
 >
 >         Steve
 >
 > On 5/30/21 2:34 PM, Jon Evans wrote:
 > > You want this one: https://github.com/Mogztter/asciidoctor-web-pdf 
<https://github.com/Mogztter/asciidoctor-web-pdf>
 > >
 > > On Ubuntu I install it with "sudo npm i -g @asciidoctor/core 
asciidoctor-pdf"
 > >
 > > On Sun, May 30, 2021 at 2:33 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
 > >>
 > >> I'm able to build the html pages, which is all we need for the 
nightlies, but I am not able to build the pdf files.  I get an error:
 > >>
 > >>           Could NOT find ASCIIDOCTORPDF (missing: 
ASCIIDOCTORPDF_COMMAND)
 > >>
 > >> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a program called 
"asciidoctor-web-pdf".
 > >>
 > >> Fedora has a package "rubygem-asciidoctor-pdf" which provides a program called 
"asciidoctor-pdf".
 > >>
 > >> I don't know if "asciidoctor-pdf" is equivalent to 
"asciidoctor-web-pdf".  If it is, then perhaps the cmake file should accept either one.
 > >>
 > >>          Steve
 > >>
 > >> On 5/30/21 1:58 PM, Steven A. Falco wrote:
 > >>> Thanks Jon.
 > >>>
 > >>> I'm running a test build now.  If it passes, I'll propose a patch 
for the README.  I'll also push the change to the nightly Fedora builds.
 > >>>
 > >>>       Steve
 > >>>
 > >>> On 5/30/21 1:51 PM, Jon Evans wrote:
 > >>>> Hi Steve,
 > >>>>
 > >>>> As the readme notes, I have not yet updated the docs for Fedora or
 > >>>> Manjaro/Arch as I don't use those distros and am not sure of the 
right
 > >>>> incantations.
 > >>>>
 > >>>> If you can advise what should go into the README I'm happy to 
update it.
 > >>>>
 > >>>> Also, please let me know if you run into any snags building the docs
 > >>>> with the new toolchain.
 > >>>>
 > >>>> Best,
 > >>>> Jon
 > >>>>
 > >>>> On Sun, May 30, 2021 at 1:49 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
 > >>>>>
 > >>>>> The Fedora nightly build for doc failed because it wanted 
asciidoctor, but all it had was asciidoc.
 > >>>>>
 > >>>>> I believe I just need to change the "buildrequires" from:
 > >>>>>
 > >>>>> BuildRequires:  asciidoc
 > >>>>>
 > >>>>> to:
 > >>>>>
 > >>>>> BuildRequires:  rubygem-asciidoctor
 > >>>>>
 > >>>>> in the kicad-nightly-doc.spec file.
 > >>>>>
 > >>>>> However, I also noticed that the page 
https://gitlab.com/kicad/services/kicad-doc <https://gitlab.com/kicad/services/kicad-doc> still 
calls for asciidoc, so that README.adoc should probably be updated too.
 > >>>>>
 > >>>>>           Steve
 > 

Re: [Kicad-developers] asciidoc

[Steven A. Falco]

I'll have to spin up a VM to play with that.  I'll get back to you... :-)

Steve

On 5/30/21 2:34 PM, Jon Evans wrote:

You want this one: https://github.com/Mogztter/asciidoctor-web-pdf

On Ubuntu I install it with "sudo npm i -g @asciidoctor/core asciidoctor-pdf"

On Sun, May 30, 2021 at 2:33 PM Steven A. Falco  wrote:


I'm able to build the html pages, which is all we need for the nightlies, but I 
am not able to build the pdf files.  I get an error:

  Could NOT find ASCIIDOCTORPDF (missing: ASCIIDOCTORPDF_COMMAND)

It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a program called 
"asciidoctor-web-pdf".

Fedora has a package "rubygem-asciidoctor-pdf" which provides a program called 
"asciidoctor-pdf".

I don't know if "asciidoctor-pdf" is equivalent to "asciidoctor-web-pdf".  If 
it is, then perhaps the cmake file should accept either one.

 Steve

On 5/30/21 1:58 PM, Steven A. Falco wrote:

Thanks Jon.

I'm running a test build now.  If it passes, I'll propose a patch for the 
README.  I'll also push the change to the nightly Fedora builds.

  Steve

On 5/30/21 1:51 PM, Jon Evans wrote:

Hi Steve,

As the readme notes, I have not yet updated the docs for Fedora or
Manjaro/Arch as I don't use those distros and am not sure of the right
incantations.

If you can advise what should go into the README I'm happy to update it.

Also, please let me know if you run into any snags building the docs
with the new toolchain.

Best,
Jon

On Sun, May 30, 2021 at 1:49 PM Steven A. Falco  wrote:


The Fedora nightly build for doc failed because it wanted asciidoctor, but all 
it had was asciidoc.

I believe I just need to change the "buildrequires" from:

BuildRequires:  asciidoc

to:

BuildRequires:  rubygem-asciidoctor

in the kicad-nightly-doc.spec file.

However, I also noticed that the page 
https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, so that 
README.adoc should probably be updated too.

  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] asciidoc

[Steven A. Falco]

I'm able to build the html pages, which is all we need for the nightlies, but I 
am not able to build the pdf files.  I get an error:

Could NOT find ASCIIDOCTORPDF (missing: ASCIIDOCTORPDF_COMMAND)

It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a program called 
"asciidoctor-web-pdf".

Fedora has a package "rubygem-asciidoctor-pdf" which provides a program called 
"asciidoctor-pdf".

I don't know if "asciidoctor-pdf" is equivalent to "asciidoctor-web-pdf".  If 
it is, then perhaps the cmake file should accept either one.

Steve

On 5/30/21 1:58 PM, Steven A. Falco wrote:

Thanks Jon.

I'm running a test build now.  If it passes, I'll propose a patch for the 
README.  I'll also push the change to the nightly Fedora builds.

 Steve

On 5/30/21 1:51 PM, Jon Evans wrote:

Hi Steve,

As the readme notes, I have not yet updated the docs for Fedora or
Manjaro/Arch as I don't use those distros and am not sure of the right
incantations.

If you can advise what should go into the README I'm happy to update it.

Also, please let me know if you run into any snags building the docs
with the new toolchain.

Best,
Jon

On Sun, May 30, 2021 at 1:49 PM Steven A. Falco  wrote:


The Fedora nightly build for doc failed because it wanted asciidoctor, but all 
it had was asciidoc.

I believe I just need to change the "buildrequires" from:

BuildRequires:  asciidoc

to:

BuildRequires:  rubygem-asciidoctor

in the kicad-nightly-doc.spec file.

However, I also noticed that the page 
https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, so that 
README.adoc should probably be updated too.

 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] asciidoc

[Steven A. Falco]

Thanks Jon.

I'm running a test build now.  If it passes, I'll propose a patch for the 
README.  I'll also push the change to the nightly Fedora builds.

Steve

On 5/30/21 1:51 PM, Jon Evans wrote:

Hi Steve,

As the readme notes, I have not yet updated the docs for Fedora or
Manjaro/Arch as I don't use those distros and am not sure of the right
incantations.

If you can advise what should go into the README I'm happy to update it.

Also, please let me know if you run into any snags building the docs
with the new toolchain.

Best,
Jon

On Sun, May 30, 2021 at 1:49 PM Steven A. Falco  wrote:


The Fedora nightly build for doc failed because it wanted asciidoctor, but all 
it had was asciidoc.

I believe I just need to change the "buildrequires" from:

BuildRequires:  asciidoc

to:

BuildRequires:  rubygem-asciidoctor

in the kicad-nightly-doc.spec file.

However, I also noticed that the page 
https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, so that 
README.adoc should probably be updated too.

 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] asciidoc

[Steven A. Falco]

The Fedora nightly build for doc failed because it wanted asciidoctor, but all 
it had was asciidoc.

I believe I just need to change the "buildrequires" from:

BuildRequires:  asciidoc

to:

BuildRequires:  rubygem-asciidoctor

in the kicad-nightly-doc.spec file.

However, I also noticed that the page 
https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, so that 
README.adoc should probably be updated too.

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] OCE vs. OCC default build flag

[Steven A. Falco]

I confirm that Fedora already selects OCC in its build scripts, both for the 
official 5.1 builds, and for the 5.99 nightlies.  The default can change 
without affecting Fedora.

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] 5.1.10 stable release tagged

[Steven A. Falco]

The Fedora builds are complete.  The one for Rawhide is available today, and 
the ones for F32, F33, and F34 are in testing.  Those will become generally 
available in 3 days, since I don't expect to receive enough positive karma to 
shortcut the testing interval.

Steve


On 5/3/21 5:12 AM, Jean-Samuel Reynaud wrote:

On my side PPA (ubuntu) is ready with 5.1.10.

Le 27/04/2021 à 22:14, Christoph Moench-Tegeder a écrit :

## Seth Hillbrand (s...@kipro-pcb.com):


Docs and i18n have been tagged.


And there they are, thanks.
I'll give it a spin (testing, so important) and push later this week.

Regards,
Christoph




___
Mailing list: https://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.10 stable release tagged

[Steven A. Falco]

Thanks Seth - Fedora builds are underway.

Steve

On 4/27/21 11:25 AM, Seth Hillbrand wrote:

Docs and i18n have been tagged.

-Seth

On Tue, Apr 27, 2021 at 7:05 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

+1

I will need doc and i18n to start the Fedora build.

         Steve

On 4/27/21 8:59 AM, Jean-Samuel Reynaud wrote:
 > Hi,
 >
 > Same with kicad-i18n...
 >
 >
 > Le 27/04/2021 à 14:35, Christoph Moench-Tegeder a écrit :
 >> Hi,
 >>
 >> ## Wayne Stambaugh (stambau...@gmail.com <mailto:stambau...@gmail.com>):
 >>
 >>> I just pushed the stable release tag to GitLab.  Please update any repo
 >>> tags as required so we can get the packages build.
 >>
 >> Any chance to get kicad-doc tagged before the release? I'd rather
 >> push kicad, all the libraries and docs at once instead of piecemeal.
 >>
 >> Regards,
 >> Christoph
 >>
 >
 >
 > ___
 > Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
 > Post to     : kicad-developers@lists.launchpad.net 
<mailto: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>
 >


___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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 <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto: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

Re: [Kicad-developers] 5.1.10 stable release tagged

[Steven A. Falco]

+1

I will need doc and i18n to start the Fedora build.

Steve

On 4/27/21 8:59 AM, Jean-Samuel Reynaud wrote:

Hi,

Same with kicad-i18n...


Le 27/04/2021 à 14:35, Christoph Moench-Tegeder a écrit :

Hi,

## Wayne Stambaugh (stambau...@gmail.com):


I just pushed the stable release tag to GitLab.  Please update any repo
tags as required so we can get the packages build.


Any chance to get kicad-doc tagged before the release? I'd rather
push kicad, all the libraries and docs at once instead of piecemeal.

Regards,
Christoph




___
Mailing list: https://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] Packaging note: new data file

[Steven A. Falco]

On 3/11/21 8:43 AM, Jon Evans wrote:

Hi all,

As of 18037e2f, a new data file is generated during build that contains image 
resources for KiCad.

This file should be installed to ${KICAD_DATA}/resources/images.tar.gz (So, 
something like /usr/share/kicad/resources/images.tar.gz on Linux).

There is an install target for this in the cmake file now, so this *should* be 
done automatically, but I wanted to give a heads-up in case any of the nightly 
packages require manual modification when the build artifacts change.


I tried a Fedora nightly build and the file is created in the correct place, so 
no changes are needed there.

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] Fedora rawhide build failure related to ngspice

[Steven A. Falco]

On 2/12/21 8:01 AM, Holger Vogt wrote:

Steven,

the info from Mamuro:

Hello:

I've pushed ngspice-34-2.fc35 / .fc34 with relevant changes.
Regards,
Mamoru

So please try again.


The fix is good, and I've closed the Fedora bug.

Thanks,
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] Fedora rawhide build failure related to ngspice

[Steven A. Falco]

On 2/12/21 8:01 AM, Holger Vogt wrote:

Steven,

the info from Mamuro:

Hello:

I've pushed ngspice-34-2.fc35 / .fc34 with relevant changes.
Regards,
Mamoru

So please try again.


Thanks!  I'll do that 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

[Kicad-developers] Fedora rawhide build failure related to ngspice

[Steven A. Falco]

There is a new bug [1] that mentions that KiCAD fails to build in Fedora 
rawhide.

The failure message is in the eeschema link step:

/usr/bin/g++ -Wall -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wsuggest-override -Werror=vla -pthread -DNDEBUG -Wl,-z,relro -Wl,--as-needed  
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -rdynamic 
CMakeFiles/qa_eeschema.dir/__/__/common/base_units.cpp.o 
CMakeFiles/qa_eeschema.dir/__/__/common/eda_text.cpp.o 
CMakeFiles/qa_eeschema.dir/__/__/common/colors.cpp.o 
CMakeFiles/qa_eeschema.dir/__/__/common/observable.cpp.o 
CMakeFiles/qa_eeschema.dir/eeschema_test_utils.cpp.o 
CMakeFiles/qa_eeschema.dir/test_module.cpp.o 
CMakeFiles/qa_eeschema.dir/test_eagle_plugin.cpp.o -o qa_eeschema  
-Wl,-rpath,/builddir/build/BUILD/kicad-5.1.9/x86_64-redhat-linux-gnu/eeschema 
../../eeschema/_eeschema.kiface ../../common/libcommon.a ../../common/libgal.a 
../qa_utils/libqa_utils.a ../unit_test_utils/libunit_test_utils.a 
../../common/liblegacy_gal.a -lngspice ../../common/libcommon.a 
../../common/libgal.a -lGLEW -lcairo -lpixman-1 -lGL -lGLU 
../../bitmaps_png/libbitmaps.a ../../polygon/libpolygon.a -lcurl -lssl -lcrypto 
-pthread -lwx_gtk3u_gl-3.0 -lwx_gtk3u_aui-3.0 -lwx_gtk3u_adv-3.0 
-lwx_gtk3u_html-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 
-lwx_baseu_xml-3.0 -lwx_gtk3u_stc-3.0 -lboost_unit_test_framework 
-lboost_filesystem -lboost_system
/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../lib64/libngspice.so: undefined 
reference to `history_file'
collect2: error: ld returned 1 exit status

I looked at the symbols in libngspice.so.0.0.0.  In Fedora 33 we had:

008ad320 B history_file

but in Fedora 34 (a.k.a. rawhide) we have:

 U history_file

I don't see where this is a KiCAD problem, because I don't find any references 
to history_file in the KiCAD code.  Does anyone have any suggestions about this?

Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1927628
___
Mailing list: https://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] Question about symbol library updates

[Steven A. Falco]

That's fine, Wayne.  I wrote in the bug that the user could keep using the 
github files (which have the extra symbols), or if they're willing to use 6.x, 
they can try the nightlies.

Steve

On 2/7/21 2:04 PM, Wayne Stambaugh wrote:

Up until the conversion to the new library file format, I'm pretty sure
the 5.1.x tags are the same between GitHub and GitLab.  Apparently the
PCIe symbol library was added after the 5.1.9 tag and wont be available
until V6 unless users check out the last commit before the libraries
were converted to the V6 file format.  Maybe one of the library devs can
give you a better answer if this is not satisfactory.

Cheers,

Wayne

On 2/7/21 10:50 AM, Steven A. Falco wrote:

I received a bug report [1] that points out that the libraries on github
contain symbols that are not present in the official gitlab
repositories.  The example cited is that [2] has PCIexpress symbols, but
[3], in the 5.1.9 tag, does not.  ([3] does have PCIe on master, but
that doesn't help the 5.x series.)

I'm not sure how to respond to the bug report.  We do our builds from
the gitlab repos; the files on github are not versioned in a way that
would let us use them for building.  Please let me know how to proceed.

 Thanks,
 Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1925836
[2] https://kicad.github.io/symbols/Connector
[3] https://gitlab.com/kicad/libraries/kicad-symbols

___
Mailing list: https://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] Question about symbol library updates

[Steven A. Falco]

Thanks.  I'll note that in the bug report and close it.

Steve


On 2/7/21 12:30 PM, Mark Roszko wrote:

That github page while still functioning is abandoned. It's pointed at master 
and at the master just before it was converted to the 6.0 library format.


On Sun, Feb 7, 2021 at 10:50 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

I received a bug report [1] that points out that the libraries on github 
contain symbols that are not present in the official gitlab repositories.  The 
example cited is that [2] has PCIexpress symbols, but [3], in the 5.1.9 tag, 
does not.  ([3] does have PCIe on master, but that doesn't help the 5.x series.)

I'm not sure how to respond to the bug report.  We do our builds from the 
gitlab repos; the files on github are not versioned in a way that would let us 
use them for building.  Please let me know how to proceed.

         Thanks,
         Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1925836 
<https://bugzilla.redhat.com/show_bug.cgi?id=1925836>
[2] https://kicad.github.io/symbols/Connector 
<https://kicad.github.io/symbols/Connector>
[3] https://gitlab.com/kicad/libraries/kicad-symbols 
<https://gitlab.com/kicad/libraries/kicad-symbols>

___
Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net 
<mailto: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>



--
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

[Kicad-developers] Question about symbol library updates

[Steven A. Falco]

I received a bug report [1] that points out that the libraries on github 
contain symbols that are not present in the official gitlab repositories.  The 
example cited is that [2] has PCIexpress symbols, but [3], in the 5.1.9 tag, 
does not.  ([3] does have PCIe on master, but that doesn't help the 5.x series.)

I'm not sure how to respond to the bug report.  We do our builds from the 
gitlab repos; the files on github are not versioned in a way that would let us 
use them for building.  Please let me know how to proceed.

Thanks,
Steve

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1925836
[2] https://kicad.github.io/symbols/Connector
[3] https://gitlab.com/kicad/libraries/kicad-symbols

___
Mailing list: https://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

[Steven A. Falco]

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

Re: [Kicad-developers] Linux Packaging heads up

[Steven A. Falco]

You are correct, Nick.  No changes are needed.  The "make install" step copies 
the files from linux/launchers into share/applications and the spec file picks them up 
from there.

Steve

On 1/20/21 3:22 PM, Steven A. Falco wrote:

The kicad.spec file for Fedora runs desktop-file-install on the desktop files.  
It will likely have to change.  I'm running a test build now.  Here is the 
relevant code from the spec file:

# Desktop integration
for desktopfile in %{buildroot}%{_datadir}/applications/*.desktop ; do
     desktop-file-install \
     --dir %{buildroot}%{_datadir}/applications \
     --remove-category Development \
     --delete-original \
     ${desktopfile}
done

 Steve


On 1/20/21 3:15 PM, Nick Østergaard wrote:

Mmm, I guess they are also part of the install target in cmake and no real 
packaging changes are needed a such, right?

On Wed, 20 Jan 2021 at 18:34, Seth Hillbrand mailto:s...@kipro-pcb.com>> wrote:

    This is a heads up for our Linux packagers that the launcher locations have 
changed in the master branch.

    You will now find the .desktop launcher files in the build directory, under 
`resources/linux/launchers/`

    -Seth

    --     KiCad Services Corporation Logo
    Seth Hillbrand
    *Lead Developer*
    +1-530-302-5483‬
    Long Beach, CA
    www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com 
<mailto:i...@kipro-pcb.com>

    ___
    Mailing list: https://launchpad.net/~kicad-developers 
<https://launchpad.net/~kicad-developers>
    Post to     : kicad-developers@lists.launchpad.net 
<mailto: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>


___
Mailing list: https://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] Linux Packaging heads up

[Steven A. Falco]

The kicad.spec file for Fedora runs desktop-file-install on the desktop files.  
It will likely have to change.  I'm running a test build now.  Here is the 
relevant code from the spec file:

# Desktop integration
for desktopfile in %{buildroot}%{_datadir}/applications/*.desktop ; do
desktop-file-install \
--dir %{buildroot}%{_datadir}/applications \
--remove-category Development \
--delete-original \
${desktopfile}
done

Steve


On 1/20/21 3:15 PM, Nick Østergaard wrote:

Mmm, I guess they are also part of the install target in cmake and no real 
packaging changes are needed a such, right?

On Wed, 20 Jan 2021 at 18:34, Seth Hillbrand mailto:s...@kipro-pcb.com>> wrote:

This is a heads up for our Linux packagers that the launcher locations have 
changed in the master branch.

You will now find the .desktop launcher files in the build directory, under 
`resources/linux/launchers/`

-Seth

-- 
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




___
Mailing list: https://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.9 tagged for release

[Steven A. Falco]

On 12/23/20 9:36 AM, Wayne Stambaugh wrote:

On 12/23/20 5:20 AM, Carsten Schoenert wrote:

Hell Nick,

Am 23.12.20 um 10:07 schrieb Nick Østergaard:

Hi Carsten

This is a balancing act. Quite some time ago we decided that we should
make the release _announcement_ (on the website) when we have build
available for some major platforms, these specifically being windows,
ubuntu ppa and macos, mostly because that gives us some good
"coverage" and we control those builds "ourselves".


that's of course up to the KiCad team to do such decisions. But I see no
reason why KiCad should be that exclusive. So far I've seen in the past
all the big distributions and the maintainer of the packages for KiCad
have acted quick as possible. But you need to give them some time. And
again, we have x-mas, why rushing things more than needed?


I am not trying to exclude you as a kicad maintainer.


But this is it it looks like.
As at least one other contributor has stated, please give us the needed
time. No planned release announcement was done again on any of the ML. :-(


By having the release announcement, it is easier to use that as a
reference when users are flagging packages in various distros.
Essentially we don't expect other distros to have builds ready by the
release announcement.

Why not doing this? It has worked in the past years. It would look much
better if things would be done more coordinated.



This is why I asked if everyone is OK with my original time line.  I
don't want to speak on behalf of all of the other devs because I don't
know what their schedules look like.  We should not be tagging all the
other repos until folks have had a chance to reply in case there is any
outstanding issues.  I'm perfectly fine with proceeding with my original
time line.  It sounds like we just had a few translations that needed
merged so I fine waiting until that is complete before we start building
packages.


Everything was already tagged as of yesterday.  I think it is already too late 
to make any further changes to 5.1.9.

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] 5.1.9 tagged for release

[Steven A. Falco]

On 12/22/20 3:14 PM, Wayne Stambaugh wrote:

5.1.9 has been tagged for release. Please tag the library, doc, and
translation repos for release. I don't think we have much in the way of
changes there so is a week to get these repos tagged and another week to
get packages built for a January 5th release work for everyone?  Please
let me know an I will adjust the release schedule accordingly.  As
always, thank you to everyone who made this possible.


I've made the official Fedora builds.  They should appear in the F32 and F33 
testing repositories in a day or so, and they will then transition to the 
stable repositories a week after that.  The rawhide build should appear in the 
stable repo sooner.

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] 5.1.7 tagged.

[Steven A. Falco]

The Fedora builds have completed:

Rawhide - in production repo now
F33 - in testing repo now - will move to production repo in 3 days
F32 - in testing repo now - will move to production repo in 7 days
F31 - in testing repo now - will move to production repo in 7 days

Steve

On 9/28/20 9:51 AM, Jean-Samuel Reynaud wrote:

FYI Ubuntu builds (PPA) are ready.

Le 25/09/2020 à 22:10, Wayne Stambaugh a écrit :

I just pushed the 5.1.7 tagged commit to GitLab.  How are we doing on
tagging the libraries, docs, and translations.  I would like to make the
release announcement either 9/30 or 10/1 if possible.  Thank you to all
of our developers who made this possible.

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




___
Mailing list: https://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] Fedora Rawhide build broken due to systemd-nspawn bug

[Steven A. Falco]

I've been chasing a build failure on the nightlies for Fedora Rawhide whereby 
wxGTK3-devel is claimed to be missing, even though it is clearly installed.

This bug explains what is going on: 
https://bugzilla.redhat.com/show_bug.cgi?id=1869030

Fixes for the bug are in progress, but there is still some discussion as to 
where and when the fixes will appear.

Unfortunately, I don't know of any workaround for the nightlies, because they 
are built on COPR.  Local mock builds can be done by passing --isolation=simple 
to mock.

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] New Build Dependencies: Lemon + GTK3

[Steven A. Falco]

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

___
Mailing list: https://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

[Steven A. Falco]

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


___
Mailing list: https://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)?

[Steven A. Falco]

For Fedora, it should just be a one-liner to add lemon to the spec file:

BuildRequires:  lemon

I'm running a test now, and I'll add it to the nightlies if it passes.

Steve

On 8/1/20 6:21 PM, Ian McInerney wrote:

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 mailto: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, mailto:eeli.kaikko...@gmail.com>> wrote:

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




___
Mailing list: https://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.

[Steven A. Falco]

Thanks Ian.  Will do.

Steve

On 7/30/20 4:13 PM, Ian McInerney wrote:

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 mailto:stevenfa...@gmail.com>> 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 
<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] Build failure in Fedora Rawhide

[Steven A. Falco]

On 7/20/20 8:28 PM, Steven A. Falco wrote:

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install


It does look like it is that easy.  I should have a build in another hour or 
so.  Then I'll load it into a VM and test.  If that works out, I'll change the 
packaging scripts.


Ok, I've updated the packaging script and merged that into gitlab.  The next 
nightly should build correctly for rawhide.

I'll tackle the downstream script tomorrow.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Steven A. Falco]

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install


It does look like it is that easy.  I should have a build in another hour or 
so.  Then I'll load it into a VM and test.  If that works out, I'll change the 
packaging scripts.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Steven A. Falco]

On 7/20/20 6:01 PM, Ian McInerney wrote:

You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install

Then the builds and install will automatically use the proper out of tree 
directory. See the change proposal page for more details: 
https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration.


Thanks, Ian.  I'll give that a try later.  But if I have to iterate a few times 
to get everything right, it could take some time.

Steve


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Steven A. Falco]

On 7/20/20 5:37 PM, Seth Hillbrand wrote:

Hi Steve-

This looks like a build setup issue, not in our CMake code.  We can build out 
of tree (in fact, we really prefer it) right now.  From the log, the broken 
command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
-DKICAD_SCRIPTING_PYTHON3=ON -DKICAD_SCRIPTING_WXPYTHON=ON 
-DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON -DKICAD_SCRIPTING_ACTION_MENU=ON 
-DKICAD_USE_OCC=ON -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF 
-DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON -DKICAD_VERSION_EXTRA=r19086-6d8fb94d 
-DCMAKE_BUILD_TYPE=Debug .

You can modify this in your .spec.template file.


I understand that, and I use out-of-tree builds for most of my local KiCAD 
builds.  But that is not how the nightlies work.  They are built on the Copr 
website, and they use the normal RPM build mechanism.

You are correct that there is nothing wrong with our CMake code, and we can fix 
our build setup.  But it is more than just compiling the source.  There are 
lots of other components that get built, and the location of the files that get 
rolled into the package will also change a bit.  So the changes will take some 
time to sort out, especially given how long it takes to test a build.  Hence 
the proposal of the workaround.

Steve
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Steven A. Falco]

On 7/20/20 5:34 PM, Nick Østergaard wrote:

What does this mean if I want to test this locally?

Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...


To test locally, I use our kicad-fedora-builder/builder.sh script with the -m 
(mock) option:

./builder.sh -m fedora-rawhide-x86_64

For that to work, you have to have set up for mock, by installing it and adding 
your uid to the mock group.

Steve



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Build failure in Fedora Rawhide

[Steven A. Falco]

Fedora recently made a change to their cmake macros, to force packages to build "out 
of tree".  The developers responsible for this change plan to go through and fix up 
the thousand or so packages that may break as a result, so they should eventually fix the 
official downstream KiCAD package.

However, they will not be able to fix up third-party packages, one of which is 
our nightly builds.

The attached email shows that KiCAD does indeed fail to build for Fedora 
rawhide now.  The right thing to do is to modify the kicad.spec.template file 
to accommodate the new cmake macros, but as a temporary workaround, we can add 
a line to force the old behavior:

%global __cmake_in_source_build 1

I've tried that, and it does let KiCAD build as before.

I don't know exactly how the developers plan to fix up the broken packages, so 
we can either add the workaround, wait to see what they do, then change the 
nightlies to match (and remove the workaround), OR we can make our own changes, 
which may result in the spec files diverging.

If the lead KiCAD devs wish, I can add the workaround - I can do that quickly.  
Attempting to sort out a proper fix would naturally take longer.

Steve


--- Begin Message ---
Notification time stamped 2020-07-20 17:31:25 UTC

Package:  kicad-100:r19086-6d8fb94d.fc33
COPR: @kicad/kicad
Built by: nickoe
Status:   failed
ID:   01565774

Logs:
  Build: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/build.log.gz
  Root:  
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/root.log.gz
  Copr:  
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/build-01565774.log
  Mockchain: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/mockchain.log.gz
Results: 
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/01565774-kicad/
Repodata:
https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-x86_64/repodata/

https://copr.fedoraproject.org/coprs/g/kicad/kicad/build/1565774/

--
You received this message due to your preference settings at 
https://apps.fedoraproject.org/notifications/stevenfalco.id.fedoraproject.org/email/60697--- End Message ---
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Request to merge support of python 3.9

[Steven A. Falco]

On 5/29/20 11:36 AM, Ian McInerney wrote:

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.


Thanks Ian.  I appreciate your help.  I'm glad we don't need two merge requests 
for the two branches.

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.


I wonder that too, but I don't know enough about cmake to judge.

Steve



-Ian

On Fri, May 29, 2020 at 4:22 PM Steven A. Falco mailto:stevenfa...@gmail.com>> 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 
<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

[Kicad-developers] Request to merge support of python 3.9

[Steven A. Falco]

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