[Kicad-developers] Stable version 6.0.6 released.

[Wayne Stambaugh]

The latest stable version six branch of KiCad has been released[1].
Thank you to everyone who contributed there time and talent to make this
stable release of KiCad possible.

Cheers,

Wayne

[1]: https://www.kicad.org/blog/2022/06/KiCad-6.0.6-Release/

___
Mailing list: https://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] Stable release 6.0.6

[Wayne Stambaugh]

One other thing that I forgot, it would be nice if we could get some
extra eyes on the recent router changes to make sure there are no
regressions.  Please download the latest testing build and help with the
testing if possible.

On 6/11/22 11:32, Wayne Stambaugh wrote:
> We now have a sufficient number of bug fixes in the 6.0 branch to start
> thinking about a 6.0.6 stable release.  The goal is to tag 6.0.6 Friday,
> June 17th and make the release announcement on the 19th.  If anyone has
> any last minute commits to make to the documentation and/or libraries,
> 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

[Kicad-developers] Stable release 6.0.6

[Wayne Stambaugh]

We now have a sufficient number of bug fixes in the 6.0 branch to start
thinking about a 6.0.6 stable release.  The goal is to tag 6.0.6 Friday,
June 17th and make the release announcement on the 19th.  If anyone has
any last minute commits to make to the documentation and/or libraries,
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

Re: [Kicad-developers] Unable to build on Ubuntu 18.04 for 6.0 branch

[Wayne Stambaugh]

Hi Seth,

Yes, but the build is failing at compile time for code that is not in
boost 1.59 or earlier.  The boost version should have been bumped to the
version of boost that includes the missing code (I don't know which
version that is).  This way the failure will occur during configuration
so it will be obvious to developers that they need to upgrade to a newer
version of boost.

- Wayne

On 5/9/22 11:52 AM, Seth Hillbrand wrote:
> Hi Wayne,
> 
> From the page you linked, 18.04 is not a supported system and has never
> been supported for v6.  We had decided some time ago that we would
> support Ubuntu LTS versions for 1 year after the release of the next LTS
> [1].
> 
> Jean-Samuel, you may be able to use the mhier PPA[2] as the source for
> newer Boost versions that will allow KiCad on older Ubuntus.
> 
> -Seth
> 
> [1] https://lists.launchpad.net/kicad-developers/msg43255.html
> <https://lists.launchpad.net/kicad-developers/msg43255.html>
> [2]
> https://launchpad.net/~mhier/+archive/ubuntu/libboost-latest/+packages
> <https://launchpad.net/~mhier/+archive/ubuntu/libboost-latest/+packages>
> 
> On Mon, May 9, 2022 at 6:06 AM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> It looks like someone back ported some random number generator fixes
> from master that are not available in boost 1.56 which is the minimum
> version in the 6.0 branch.  We should address this since 18.04 LTS is a
> supported system[1].
> 
> 
> [1]:https://www.kicad.org/help/system-requirements/
> <https://www.kicad.org/help/system-requirements/>
> 
> On 5/9/22 4:05 AM, Jean-Samuel Reynaud wrote:
> > Hi,
> >
> > As I see, since one of those commits:
> > 891c919c239223ef601284a8f166d0f229f6b030
> > 0ea7dabc1271dbc77b8d5764e4eecbeba85903d6
> > e1cd74dd78031b002737a79ddffcf3489d74105c
> > 4d8297a1f6f18d59cb38361b88a959d7af062480
> >
> > KiCad is unable to build on Ubuntu 18.04. I guess it's a boost version
> > issue (Boost is 1.65.1 on Ubuntu 18.04).
> > The build error:
> > kicad/common/kiid.cpp:50:73:   required from here
> > /usr/include/boost/random/detail/seed_impl.hpp:269:9: error: ‘class
> > boost::uuids::detail::seed_rng’ has no member named ‘generate’
> >      seq.generate([0], [0] + ((w+31)/32) * n);
> >      ^~~~
> >
> >
> > You can take a look as the build output at
> >
> 
> https://launchpadlibrarian.net/600354670/buildlog_ubuntu-bionic-amd64.kicad_6.0.0+nightly-202205081117+43b8adad1a~116~ubuntu18.04.1_BUILDING.txt.gz
> 
> <https://launchpadlibrarian.net/600354670/buildlog_ubuntu-bionic-amd64.kicad_6.0.0+nightly-202205081117+43b8adad1a~116~ubuntu18.04.1_BUILDING.txt.gz>
> > (large log, error message near the end ;)
> >
> >
> > Is this version of Ubuntu is still supported for 6.0 branch ? (for me
> > yes since the Ubuntu support is up to April 2023)...
> > Note that it affect version 6.0.5 (6.0.4 was built correctly)
> >
> > Regards,
> >
> > ___
> > 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] Unable to build on Ubuntu 18.04 for 6.0 branch

[Wayne Stambaugh]

It looks like someone back ported some random number generator fixes
from master that are not available in boost 1.56 which is the minimum
version in the 6.0 branch.  We should address this since 18.04 LTS is a
supported system[1].


[1]:https://www.kicad.org/help/system-requirements/

On 5/9/22 4:05 AM, Jean-Samuel Reynaud wrote:
> Hi,
> 
> As I see, since one of those commits:
> 891c919c239223ef601284a8f166d0f229f6b030
> 0ea7dabc1271dbc77b8d5764e4eecbeba85903d6
> e1cd74dd78031b002737a79ddffcf3489d74105c
> 4d8297a1f6f18d59cb38361b88a959d7af062480
> 
> KiCad is unable to build on Ubuntu 18.04. I guess it's a boost version
> issue (Boost is 1.65.1 on Ubuntu 18.04).
> The build error:
> kicad/common/kiid.cpp:50:73:   required from here
> /usr/include/boost/random/detail/seed_impl.hpp:269:9: error: ‘class
> boost::uuids::detail::seed_rng’ has no member named ‘generate’
>  seq.generate([0], [0] + ((w+31)/32) * n);
>  ^~~~
> 
> 
> You can take a look as the build output at
> https://launchpadlibrarian.net/600354670/buildlog_ubuntu-bionic-amd64.kicad_6.0.0+nightly-202205081117+43b8adad1a~116~ubuntu18.04.1_BUILDING.txt.gz
> (large log, error message near the end ;)
> 
> 
> Is this version of Ubuntu is still supported for 6.0 branch ? (for me
> yes since the Ubuntu support is up to April 2023)...
> Note that it affect version 6.0.5 (6.0.4 was built correctly)
> 
> Regards,
> 
> ___
> Mailing list: https://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] 6.0.5 release announcement

[Wayne Stambaugh]

Stable version 6.0.5 has officially been release.  See the release
announcement[1] for more information.  Thanks to everyone who made this
release possible.

Cheers,

Wayne

[1]:https://www.kicad.org/blog/2022/05/KiCad-6.0.5-Release/

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

[Wayne Stambaugh]

Yet another last minute critical issue was fixed yesterday so I'm
pushing tagging back another week.  I will tag 6.0.5 on Monday, May 2nd.

Wayne

On 4/25/22 12:02 PM, Wayne Stambaugh wrote:
> Sending this again because apparently some folks on the mailing list
> didn't get it.  Sorry for the noise.
> 
> Wayne
> 
> On 4/22/22 7:39 AM, Wayne Stambaugh wrote:
>> Due to another crash bug being fixed, the new freeze date started on
>> April 19th.  To allow a full week of testing, I will be tagging 6.0.5 on
>> Wednesday, April 27th.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/15/22 6: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

Re: [Kicad-developers] 6.0.5 stable release

[Wayne Stambaugh]

Sending this again because apparently some folks on the mailing list
didn't get it.  Sorry for the noise.

Wayne

On 4/22/22 7:39 AM, Wayne Stambaugh wrote:
> Due to another crash bug being fixed, the new freeze date started on
> April 19th.  To allow a full week of testing, I will be tagging 6.0.5 on
> Wednesday, April 27th.
> 
> Cheers,
> 
> Wayne
> 
> On 4/15/22 6: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

Re: [Kicad-developers] 6.0.5 stable release

[Wayne Stambaugh]

Due to another crash bug being fixed, the new freeze date started on
April 19th.  To allow a full week of testing, I will be tagging 6.0.5 on
Wednesday, April 27th.

Cheers,

Wayne

On 4/15/22 6: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

[Kicad-developers] 6.0.5 stable release

[Wayne Stambaugh]

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

Re: [Kicad-developers] Introduction of sentry application monitoring and error tracking

[Wayne Stambaugh]

Thanks Mark!

On 3/31/22 11:37 AM, Jon Evans wrote:

Thanks for putting in the work to get this integrated, Mark!  Having
automated crash dumps will be invaluable to improving KiCad stability.

On Wed, Mar 30, 2022 at 8:32 PM Mark Roszko  wrote:


Hey folks,

We are planning to introduce the use of the Sentry platform into KiCad.
Sentry https://sentry.io/ is open source platform to capture application 
events, crash dumps, and other random analytics.
Both their hosted platform (https://github.com/getsentry/sentry) is open source 
and the integrated SDK to handle crash handling in C++ is also open source on 
github under MIT license (https://github.com/getsentry/sentry-native)
Sentry has given KiCad a sponsored account to use their SaaS platform as the 
KiCad team does not have the manpower to maintain a self-hosted instance.

The plan going forward is:
- The primary use in KiCad will be to capture crash reports, but in the future 
it could also let us gather things like performance metrics of algorithms 
across the wider user base.
- The implementation will be and will remain entirely opt-in with a one time 
prompt on startup, and the ability to turn it off in preferences. This is to 
maintain privacy regulation compliance and just good manners.
- No PII is captured, we have no need or desire for it. Only a random GUID 
generated for your install is used to connect crash reports. This GUID can be 
reset at any time by the user.
- To aid in avoiding PII capture, all sentry reports go to a "sentry-relay" 
server run on KiCad owned infrastructure,
this relay serves as a proxy to communicate to the main sentry.io platform, 
this aids in hiding originating IP addresses but we have also turned off the 
storage of IP addresses in sentry
- Additionally, the cmake variable KICAD_USE_SENTRY is being added where a 
value of false will disable the inclusion of the sentry sdk entirely. The 
current default will be off as only Windows support is tested.
- Sentry will only store at most 1 raw crash dump (though we can turn it off 
entirely) for analysis. Sentry will parse out only the relevant crash details 
such as call stack, and stack frame and discard the rest of the crash dump.
- This will be deployed for Windows nightly builds first
- Data in sentry is retained for at max 90 days before it is deleted 
automatically.


This solves a many years long desire of the KiCad team to capture crash dumps 
without user involvement and sentry offers us a very easy solution to do it and 
help make KiCad better for everyone.

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


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



___
Mailing list: https://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] SpaceMouse support for the schmetics viewer

[Wayne Stambaugh]

Hi Markus,

The KiCad version 7 feature freeze date is September 30th so your MR 
would have to be merged by that date to make it in V7.  Given that the 
Pcbnew and 3D viewer SpaceMouse code was a rather large change set, you 
should probably submit the MR by the end of August to allow time for the 
dev team to review and test.


Cheers,

Wayne

On 3/22/22 2:06 AM, Markus Bonk wrote:


Hi,

What is the window of opportunity to implement SpaceMouse support in 
Eeshema, KiCad's schematics viewer for version 7.0.


I think the KiCad folks will enter a feature-freeze at some point and 
we would like to know when this will be.


Markus



*Markus Bonk*
Senior Software Engineer

Clarita-Bernhard-Str. 18
81249 München
Germany



markus_b...@3dconnexion.com
www.3dconnexion.com 

Geschäftsführer: Antonio Pascucci
Sitz der Gesellschaft: München
Registergericht: München HRB 99232

This email and any files transmitted with are from 3Dconnexion GmbH. 
The contents of this email and any attachments are confidential to the 
intended recipient. They may not be disclosed to or used by or copied 
in any way by anyone other than the intended recipient. If this email 
is received in error, please contact 3Dconnexion GmbH by calling +49 
89 8974542-0 and then delete it. Please note that neither 3Dconnexion 
GmbH nor the sender accepts any responsibility for viruses and it is 
your responsibility to scan or otherwise check this email and any 
attachments. Any opinion expressed in this email are those of the 
individual and not necessarily those of 3Dconnexion GmbH.
3Dconnexion GmbH processes and stores for commercial purposes your 
personal data, collected upon your consent, in accordance with its 
privacy policy available at https://www.3dconnexion.eu/privacy.html, 
which has been drafted in accordance with Regulation (EU) no. 679/2016 
and all applicable local data protection laws and regulations of the 
countries where the company operates. To revoke your consent or 
exercise all your rights with regards to personal data, please contact 
us at priv...@3dconnexion.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

[Kicad-developers] 6.0.4 released

[Wayne Stambaugh]

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.


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

Re: [Kicad-developers] 6.0.3 stable release

[Wayne Stambaugh]

The source repo has been tagged so we need to get the remaining repos 
tagged so we can get the package builders fired up.


Cheers,

Wayne

On 3/15/22 9:41 AM, Wayne Stambaugh wrote:
I am planning on tagging 6.0.3 this evening around 8PM EDT.  Please let 
me know if you need more time.  All of the other repos will need tagged 
as well so we can packages built and uploaded.  The goal is release on 
Thursday, March 17th.


Cheers,

Wayne

On 3/8/22 7:32 AM, Wayne Stambaugh wrote:
We are planning on releasing 6.0.3 on March 15th which means that we 
will have to have all of the repos tagged by March 13th.  Please let 
me know if you have any issues with this time line.  Thanks in advance 
for the help.


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

Re: [Kicad-developers] 6.0.3 stable release

[Wayne Stambaugh]

I am planning on tagging 6.0.3 this evening around 8PM EDT.  Please let 
me know if you need more time.  All of the other repos will need tagged 
as well so we can packages built and uploaded.  The goal is release on 
Thursday, March 17th.


Cheers,

Wayne

On 3/8/22 7:32 AM, Wayne Stambaugh wrote:
We are planning on releasing 6.0.3 on March 15th which means that we 
will have to have all of the repos tagged by March 13th.  Please let me 
know if you have any issues with this time line.  Thanks in advance for 
the help.


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

[Kicad-developers] 6.0.3 stable release

[Wayne Stambaugh]

We are planning on releasing 6.0.3 on March 15th which means that we 
will have to have all of the repos tagged by March 13th.  Please let me 
know if you have any issues with this time line.  Thanks in advance for 
the help.


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

[Kicad-developers] 6.0.2 tagged.

[Wayne Stambaugh]

All of the repos have been tagged for 6.0.2 and the documentation
archive can be download from
https://kicad-downloads.s3.cern.ch/docs/kicad-doc-6.0.2.tar.gz.  Let's
get those package builders fired up for the 6.0.2 release.

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

Re: [Kicad-developers] 6.0.2 stable release

[Wayne Stambaugh]

On 2/10/22 10:06 AM, Steven A. Falco wrote:

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?


I'm hoping later today.  I'm waiting for one last bug fix confirmation.



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

[Wayne Stambaugh]

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.



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

[Wayne Stambaugh]

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.



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

[Kicad-developers] Mailing list issue

[Wayne Stambaugh]

In case you didn't know, the KiCad developer's mailing list was down for 
a few days so no one was getting the messages.  If you sent anything 
over the last few days and didn't get a response, your going to have to 
resend it.  I don't think anyone should be expected to go through the 
mailing list archives to response to messages.  Sorry about the 
inconvenience.


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

[Kicad-developers] It's 2022

[Wayne Stambaugh]

Just a friendly reminder to developers to please update the copyright 
date to 2022 as you make changes to the KiCad source files.


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

Re: [Kicad-developers] 6.0.1

[Wayne Stambaugh]

Hi Franck,

We already have a "ki_keywords" property which does the same thing as 
your proposed "CompactedFamily" property.  This property already exists 
so search tags should added to the existing property.


As for regular expression search, that is a new feature and would not be 
back ported to the 6.0 branch.


Cheers,

Wayne

On 1/7/22 5:17 AM, Franck Bourdonnec wrote:

Hello,
I have a simple one.

Choosing some symbol is sometimes very difficult because it is long list 
, very long list of the same thing with just pin count varying for example.


In a future version, KiCad may address that by only displaying a single 
line for the symbol, same as a regular expression.


Example:

Pinheader[01,02]_[02..64]_[H,V]_2.00
Pinheader[01,02]_[02..64]_[H,V]_2.54
and expand that on demand.



These are all generated by scripts.

It is easy for each script to insert a field saying simply how it was 
developped and thus how KiCad can factorise all the serie


Just reserve a keyword in the parsers so that any v6 can read without 
complaining.


(property "CompactedFamily" )    <= not happy
(property "CompactedFamily" none)
(property "CompactedFamily" [01,02]_[02..64]_[H,V]_2.54mm )

Same for footprints

Franck

Le 06/01/2022 à 23:43, Wayne Stambaugh a écrit :
Just a quick heads up to all library, package, documentation, and 
translation developers, barring any unexpected critical bugs I will be 
tagging stable release version 6.0.1 late on Tuesday, January 11 (EST) 
for official release on January 15th.  If you have anything you want 
to push before 6.0.1, now would be a good 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


!DSPAM:61d7717c7328861912533!





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

[Wayne Stambaugh]

Just a quick heads up to all library, package, documentation, and 
translation developers, barring any unexpected critical bugs I will be 
tagging stable release version 6.0.1 late on Tuesday, January 11 (EST) 
for official release on January 15th.  If you have anything you want to 
push before 6.0.1, now would be a good 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

Re: [Kicad-developers] QA build failure

[Wayne Stambaugh]

The build error is fixed.  Thanks.

On 12/26/21 11:55 AM, jeff wrote:

More bits committed...


On 26 Dec 2021, at 15:48, Wayne Stambaugh  wrote:

Now I'm seeing this:

/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp: In constructor 
‘PNS_LOG_VIEWER_FRAME::PNS_LOG_VIEWER_FRAME(wxFrame*)’:
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp:294:14: error: request for 
member ‘m_ZoneDisplayMode’ in ‘settings’, which is of pointer type 
‘KIGFX::PCB_RENDER_SETTINGS*’ (maybe you meant to use ‘->’ ?)
  294 | settings.m_ZoneDisplayMode = ZONE_DISPLAY_MODE::SHOW_FILLED;
  |  ^
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:398: 
qa/pns/CMakeFiles/test_pns.dir/pns_log_viewer.cpp.o] Error 1


On 12/26/21 10:13 AM, jeff wrote:

I’ve attempted to fix these, although they don’t appear to be part of the build 
target on my machine so I can’t confirm.

On 26 Dec 2021, at 14:26, foo Stambaugh  wrote:

I'm seeing the following build failure this morning:

/home/foo/src/kicad-trunk/qa/qa_utils/mocks.cpp:622:28: error: no declaration 
matches ‘const PCB_DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const’
  622 | const PCB_DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const
  |^
In file included from 
/home/foo/src/kicad-trunk/pcbnew/router/pns_tool_base.h:30,
 from /home/foo/src/kicad-trunk/pcbnew/router/router_tool.h:26,
 from /home/foo/src/kicad-trunk/qa/qa_utils/mocks.cpp:38:
/home/foo/src/kicad-trunk/pcbnew/tools/pcb_tool_base.h:172:39: note: candidate is: 
‘PCBNEW_SETTINGS::DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const’
  172 | PCBNEW_SETTINGS::DISPLAY_OPTIONS& displayOptions() const;
  |   ^~
/home/foo/src/kicad-trunk/pcbnew/tools/pcb_tool_base.h:70:7: note: ‘class 
PCB_TOOL_BASE’ defined here
   70 | class PCB_TOOL_BASE : public TOOL_INTERACTIVE
  |   ^
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp: In constructor 
‘PNS_LOG_VIEWER_FRAME::PNS_LOG_VIEWER_FRAME(wxFrame*)’:
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp:294:15: error: ‘class 
KIGFX::PCB_RENDER_SETTINGS’ has no member named ‘SetZoneDisplayMode’; did you 
mean ‘m_ZoneDisplayMode’?
  294 | settings->SetZoneDisplayMode( ZONE_DISPLAY_MODE::SHOW_FILLED );
  |   ^~
  |   m_ZoneDisplayMode
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:468: 
qa/pns/CMakeFiles/test_pns.dir/__/qa_utils/mocks.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:398: 
qa/pns/CMakeFiles/test_pns.dir/pns_log_viewer.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4556: qa/pns/CMakeFiles/test_pns.dir/all] 
Error 2
make: *** [Makefile:166: all] Error 2

___
Mailing list: https://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] QA build failure

[Wayne Stambaugh]

Now I'm seeing this:

/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp: In constructor 
‘PNS_LOG_VIEWER_FRAME::PNS_LOG_VIEWER_FRAME(wxFrame*)’:
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp:294:14: error: 
request for member ‘m_ZoneDisplayMode’ in ‘settings’, which is of 
pointer type ‘KIGFX::PCB_RENDER_SETTINGS*’ (maybe you meant to use ‘->’ ?)

  294 | settings.m_ZoneDisplayMode = ZONE_DISPLAY_MODE::SHOW_FILLED;
  |  ^
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:398: 
qa/pns/CMakeFiles/test_pns.dir/pns_log_viewer.cpp.o] Error 1



On 12/26/21 10:13 AM, jeff wrote:

I’ve attempted to fix these, although they don’t appear to be part of the build 
target on my machine so I can’t confirm.


On 26 Dec 2021, at 14:26, foo Stambaugh  wrote:

I'm seeing the following build failure this morning:

/home/foo/src/kicad-trunk/qa/qa_utils/mocks.cpp:622:28: error: no declaration 
matches ‘const PCB_DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const’
  622 | const PCB_DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const
  |^
In file included from 
/home/foo/src/kicad-trunk/pcbnew/router/pns_tool_base.h:30,
 from /home/foo/src/kicad-trunk/pcbnew/router/router_tool.h:26,
 from /home/foo/src/kicad-trunk/qa/qa_utils/mocks.cpp:38:
/home/foo/src/kicad-trunk/pcbnew/tools/pcb_tool_base.h:172:39: note: candidate is: 
‘PCBNEW_SETTINGS::DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const’
  172 | PCBNEW_SETTINGS::DISPLAY_OPTIONS& displayOptions() const;
  |   ^~
/home/foo/src/kicad-trunk/pcbnew/tools/pcb_tool_base.h:70:7: note: ‘class 
PCB_TOOL_BASE’ defined here
   70 | class PCB_TOOL_BASE : public TOOL_INTERACTIVE
  |   ^
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp: In constructor 
‘PNS_LOG_VIEWER_FRAME::PNS_LOG_VIEWER_FRAME(wxFrame*)’:
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp:294:15: error: ‘class 
KIGFX::PCB_RENDER_SETTINGS’ has no member named ‘SetZoneDisplayMode’; did you 
mean ‘m_ZoneDisplayMode’?
  294 | settings->SetZoneDisplayMode( ZONE_DISPLAY_MODE::SHOW_FILLED );
  |   ^~
  |   m_ZoneDisplayMode
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:468: 
qa/pns/CMakeFiles/test_pns.dir/__/qa_utils/mocks.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:398: 
qa/pns/CMakeFiles/test_pns.dir/pns_log_viewer.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4556: qa/pns/CMakeFiles/test_pns.dir/all] 
Error 2
make: *** [Makefile:166: all] Error 2

___
Mailing list: https://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] QA build failure

[Wayne Stambaugh]

I'm seeing the following build failure this morning:

/home/foo/src/kicad-trunk/qa/qa_utils/mocks.cpp:622:28: error: no 
declaration matches ‘const PCB_DISPLAY_OPTIONS& 
PCB_TOOL_BASE::displayOptions() const’

  622 | const PCB_DISPLAY_OPTIONS& PCB_TOOL_BASE::displayOptions() const
  |^
In file included from 
/home/foo/src/kicad-trunk/pcbnew/router/pns_tool_base.h:30,
 from 
/home/foo/src/kicad-trunk/pcbnew/router/router_tool.h:26,

 from /home/foo/src/kicad-trunk/qa/qa_utils/mocks.cpp:38:
/home/foo/src/kicad-trunk/pcbnew/tools/pcb_tool_base.h:172:39: note: 
candidate is: ‘PCBNEW_SETTINGS::DISPLAY_OPTIONS& 
PCB_TOOL_BASE::displayOptions() const’

  172 | PCBNEW_SETTINGS::DISPLAY_OPTIONS& displayOptions() const;
  |   ^~
/home/foo/src/kicad-trunk/pcbnew/tools/pcb_tool_base.h:70:7: note: 
‘class PCB_TOOL_BASE’ defined here

   70 | class PCB_TOOL_BASE : public TOOL_INTERACTIVE
  |   ^
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp: In constructor 
‘PNS_LOG_VIEWER_FRAME::PNS_LOG_VIEWER_FRAME(wxFrame*)’:
/home/foo/src/kicad-trunk/qa/pns/pns_log_viewer.cpp:294:15: error: 
‘class KIGFX::PCB_RENDER_SETTINGS’ has no member named 
‘SetZoneDisplayMode’; did you mean ‘m_ZoneDisplayMode’?

  294 | settings->SetZoneDisplayMode( ZONE_DISPLAY_MODE::SHOW_FILLED );
  |   ^~
  |   m_ZoneDisplayMode
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:468: 
qa/pns/CMakeFiles/test_pns.dir/__/qa_utils/mocks.cpp.o] Error 1

make[2]: *** Waiting for unfinished jobs
make[2]: *** [qa/pns/CMakeFiles/test_pns.dir/build.make:398: 
qa/pns/CMakeFiles/test_pns.dir/pns_log_viewer.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:4556: 
qa/pns/CMakeFiles/test_pns.dir/all] Error 2

make: *** [Makefile:166: all] Error 2

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

[Wayne Stambaugh]

Due to the recent churn, the KiCad lead development team has decide to 
tag a release candidate 2 for version 6.  If testing goes well over the 
weekend, the goal is to tag 6.0.0 on Monday.


Until version 6 is tagged, no new commits can be pushed directly to the 
master branch.  All commits until 6.0.0 is tagged and v6 is branched are 
limited to critical and high priority bug fixes and must be submitted 
through the merge request system.  All MRs must be approved by two 
members of the lead development team who are not the MR author.  All low 
and medium priority bug fixes should be tagged and deferred to milestone 
6.0.1.


Thank you for your cooperation and thanks for the last minute effort to 
get the major issue resolved.

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

Re: [Kicad-developers] installation of translations

[Wayne Stambaugh]

Check to make sure the KICAD_BUILD_I18N and KICAD_I18N_UNIX_STRICT_PATH 
build options are set properly.  They default to OFF.


On 11/19/21 8:47 AM, Marco Ciampa wrote:

Hi devs!
In order to check the coherence of the translation I often compile and install 
KiCad from source (from git).
Using the usual commands like:

cd build
cmake ..
make
sudo make install

I just noted that the translations are not or not completely installed.

Do I miss something?

My system is Ubuntu 20.04-64 and installing KiCad from git master.

TIA for any hint!




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

[Kicad-developers] New lead developer announcement

[Wayne Stambaugh]

I am happy to announce that Mikolaj Wielgus has accepted an invitation 
to become a member of the KiCad lead development team.  Mikolaj has made 
some significant contributions to the KiCad project and I look forward 
to his contributions as lead developer.  Please join me in 
congratulating Mikolaj 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

Re: [Kicad-developers] Question about attributes and complex hierarchies

[Wayne Stambaugh]

Hi Lorenzo,

Welcome back.

It sounds to me like you are describing a variant system to allow for 
different populations of the same board layout from a single schematic 
design.  This is already planned for version 7 so you wont have to use 
any hacks like you are suggesting below to create a variant.  I'm not 
sure when in the V7 development cycle this will get implemented but it's 
definitely on the list.


Cheers,

Wayne

On 11/17/21 3:39 AM, Lorenzo Marcantonio wrote:

…I'm back from the grave after something like 10 years because I'm busy
*using* kicad rather than doing developement work.

Today I incurred in a (rather big) eeschema nuisance and I'd like to ask
if already there are plan for that.

Since there is no population variation for schematics (hint hint :D) I'm
using custom attributes to tag the modifications. For this concrete
example the board has a 12V and a 230V variations so I'm tagging with a
'#' (or something) in the relevant field if the component has to be
omitted and then postprocess the BOMs to filter out the unneeded parts,
and everyone's happy.

The requirements of the day is that while there are three exact
subcircuits in the design, the 12V board only has populated two of these
three instances so the idea would be to set the DNP12 attribute on the
parts of the third instance.

This board uses a complex hierarchy (the same sheet instanced three
times in the root, to be exact) and after looking at the new format I've
seen that this use case can't be supported:

- The complex instances are now held in the root (for some reason)
   in the (symbol_instances …) section

- Each (path …) element contains only some stock fields: reference,
   unit, value, footprint;

- The editor actually enforces the change on value and footprint to all
   the instances so why they are saved in the instance data eludes me;

- The only things that can be actually altered for each instance is the
   designator (reference + part);

Now it wouldn't probably be *too* difficult to extend the file to handle
the extra attribute (just add the custom attributes in the (path …)
entity) but the UI would need some serious tought to avoid the symbol
editor mess (the magic 'present in all instances' checkbox). In fact the
design issue is substantially the same (multiple subparts vs multiple
subcircuits)

Is there already some plan or idea to handle this?


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




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

Re: [Kicad-developers] License question

[Wayne Stambaugh]

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

[Kicad-developers] Version 6 release candidate 1

[Wayne Stambaugh]

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

[Kicad-developers] Stable release update

[Wayne Stambaugh]

Unfortunately we found a locale issue with 5.1.11.  Some of the packages 
were ready and uploaded to website which resulted in a few users 
downloading them which exposed the issue.  We have fixed the issue but 
given that users have already downloaded 5.1.11 packages, we will not be 
officially releasing 5.1.11.  Instead, we will officially be releasing 
5.1.12 which include the fix.  I just pushed the 5.1.12 tag to the 5.1 
repo so packages and the official release announcement should be 
available soon.  The KiCad project apologizes for any inconvenience.


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

Re: [Kicad-developers] 5.1.11 Release Notes?

[Wayne Stambaugh]

Hi Stefan,

There is not a formal release notes per se but you can see the list of 
closed issues at https://gitlab.com/groups/kicad/-/milestones/6.


Cheers,

Wayne

On 10/30/2021 11:03 AM, Stefan Brüns wrote:

Hi,

I am currently preparing packages for openSUSE, and was wondering if the
release notes are already available?

As I want to reference it in the package changelog, is it safe to assume it
will appear as:

https://kicad.org/blog/2021/11/KiCad-5.1.11-Release/

(i.e. not during the next 32 hours ...)

Kind regards,

Stefan


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

[Wayne Stambaugh]

The lead development team has agreed on a version 6 release schedule as 
follows:



- String freeze November 1.
- Tag RC1 on November 15.
- All repos frozen on December 14.
- Tag all repos with 6.0.0 on December 15.
- 6.0.0 release announcement December 31 (maybe the day before Christmas
  just for fun).
- Branch V6 and open master for new feature development on January 1.

Our goal is to stick to that as closely as possible so if you have any 
outstanding work, please use this schedule as a reference to get it done.


Going forward, we will be following the new stable release policy[1] 
which will move us to an annual release schedule.


Thank you everyone for your continued support of the KiCad project. 
Hopefully the version 6 release will go reasonably smoothly and we can 
get started on version 7 in 2022.


Cheers,

Wayne

[1]: https://dev-docs.kicad.org/en/rules-guidelines/release-policy/

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

[Kicad-developers] 5.1.11 release update

[Wayne Stambaugh]

I had to re-tag the 5.1 branch due to removal of the old domain name and 
a last minute bug fix.  Please update any previous package builds to the 
latest commit.  I apologize for any inconvenience.


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

Re: [Kicad-developers] 5.1.11 release tagged

[Wayne Stambaugh]

On 10/26/21 4:31 PM, Carsten Schoenert wrote:

Hello Wayne,

Am 26.10.21 um 20:38 schrieb Wayne Stambaugh:

Hi Carsten,

Do we still we still build and deploy the old 5.1 developer docs
anywhere?  I guess I should remove them just in case someone else does.
   I should be able to get to this shortly.


stuff from that folder isn't going into (Debian) packages, I'm not sure
about other places there this was or is deployed to.

I came along this while looking into the references to kicad-pcb.org
within the debian/ folder and found a lot matches also outside the
debian/ folder. So I pulled the 5.1 branch to compare that against the
5.1.11 tag and still found references.


If there is anything else in the 5.1 source tree, please let me know and 
I will fix it.


- Wayne



The packaging is including more additional folders like localization and
the documentation. I haven't looked into this yet.




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

Re: [Kicad-developers] 5.1.11 release tagged

[Wayne Stambaugh]

I purged the old domain from the 5.1 branch developer docs and pushed 
everything to the 5.1 branch so we should be good to go.


- Wayne

On 10/26/21 2:40 PM, Wayne Stambaugh wrote:
Please hold off building the 5.1.11 packages until I get this fixed even 
though the resulting code wont be any different, the commit hash will 
be.  Sorry for the headaches.


Cheers,

Wayne

On 10/26/21 2:38 PM, Wayne Stambaugh wrote:

Hi Carsten,

Do we still we still build and deploy the old 5.1 developer docs 
anywhere?  I guess I should remove them just in case someone else 
does.   I should be able to get to this shortly.


Thanks,

Wayne

On 10/26/21 2:18 PM, Carsten Schoenert wrote:

Hello Wayne,

Am 26.10.21 um 13:32 schrieb Wayne Stambaugh:

I just pushed the 5.1.11 tag to the 5.1 branch so please tag all of the
other repos so we can start the packaging process.  Please let me know
if there are any issues that would delay the tagging.


I guess the loss of kicad-pcb.org isn't incorporated yet into this tag.

carsten@i5:~/gitprojects/kicad-upstream/kicad [(5.1.11)] $ git grep 
"kicad-pcb\.org"
Documentation/development/compiling.md:[download]: 
http://kicad-pcb.org/download/
Documentation/development/compiling.md:[KiCad website]: 
http://kicad-pcb.org/
Documentation/development/pcbnew-plugins.md:documentation](http://docs.kicad-pcb.org/stable/en/pcbnew.html#_kicad_scripting_reference). 

Documentation/development/pcbnew-plugins.md:[here](http://docs.kicad-pcb.org/doxygen-python/namespacepcbnew.html). 

Documentation/development/road-map.md:[kicad-website]:http://kicad-pcb.org/ 

Documentation/development/road-map.md:[kicad-docs]:http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html 

Documentation/development/stable-release-policy.md:added to either 
the KiCad developer's site on Launchpad or the main website at 
www.kicad-pcb.org.
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[advanced config 
documentation]: 
http://docs.kicad-pcb.org/doxygen/namespaceAC__KEYS.html


I think you will agree that it would be good to fix this also within 
the devel information resources before releasing a new version.









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

[Wayne Stambaugh]

Please hold off building the 5.1.11 packages until I get this fixed even 
though the resulting code wont be any different, the commit hash will 
be.  Sorry for the headaches.


Cheers,

Wayne

On 10/26/21 2:38 PM, Wayne Stambaugh wrote:

Hi Carsten,

Do we still we still build and deploy the old 5.1 developer docs 
anywhere?  I guess I should remove them just in case someone else does. 
  I should be able to get to this shortly.


Thanks,

Wayne

On 10/26/21 2:18 PM, Carsten Schoenert wrote:

Hello Wayne,

Am 26.10.21 um 13:32 schrieb Wayne Stambaugh:

I just pushed the 5.1.11 tag to the 5.1 branch so please tag all of the
other repos so we can start the packaging process.  Please let me know
if there are any issues that would delay the tagging.


I guess the loss of kicad-pcb.org isn't incorporated yet into this tag.

carsten@i5:~/gitprojects/kicad-upstream/kicad [(5.1.11)] $ git grep 
"kicad-pcb\.org"
Documentation/development/compiling.md:[download]: 
http://kicad-pcb.org/download/
Documentation/development/compiling.md:[KiCad website]: 
http://kicad-pcb.org/
Documentation/development/pcbnew-plugins.md:documentation](http://docs.kicad-pcb.org/stable/en/pcbnew.html#_kicad_scripting_reference). 

Documentation/development/pcbnew-plugins.md:[here](http://docs.kicad-pcb.org/doxygen-python/namespacepcbnew.html). 

Documentation/development/road-map.md:[kicad-website]:http://kicad-pcb.org/ 

Documentation/development/road-map.md:[kicad-docs]:http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html 

Documentation/development/stable-release-policy.md:added to either 
the KiCad developer's site on Launchpad or the main website at 
www.kicad-pcb.org.
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[advanced config documentation]: 
http://docs.kicad-pcb.org/doxygen/namespaceAC__KEYS.html


I think you will agree that it would be good to fix this also within 
the devel information resources before releasing a new version.







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

[Wayne Stambaugh]

Hi Carsten,

Do we still we still build and deploy the old 5.1 developer docs 
anywhere?  I guess I should remove them just in case someone else does. 
 I should be able to get to this shortly.


Thanks,

Wayne

On 10/26/21 2:18 PM, Carsten Schoenert wrote:

Hello Wayne,

Am 26.10.21 um 13:32 schrieb Wayne Stambaugh:

I just pushed the 5.1.11 tag to the 5.1 branch so please tag all of the
other repos so we can start the packaging process.  Please let me know
if there are any issues that would delay the tagging.


I guess the loss of kicad-pcb.org isn't incorporated yet into this tag.

carsten@i5:~/gitprojects/kicad-upstream/kicad [(5.1.11)] $ git grep 
"kicad-pcb\.org"
Documentation/development/compiling.md:[download]: 
http://kicad-pcb.org/download/
Documentation/development/compiling.md:[KiCad website]: 
http://kicad-pcb.org/
Documentation/development/pcbnew-plugins.md:documentation](http://docs.kicad-pcb.org/stable/en/pcbnew.html#_kicad_scripting_reference). 

Documentation/development/pcbnew-plugins.md:[here](http://docs.kicad-pcb.org/doxygen-python/namespacepcbnew.html). 

Documentation/development/road-map.md:[kicad-website]:http://kicad-pcb.org/ 

Documentation/development/road-map.md:[kicad-docs]:http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html 

Documentation/development/stable-release-policy.md:added to either the 
KiCad developer's site on Launchpad or the main website at 
www.kicad-pcb.org.
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[advanced config documentation]: 
http://docs.kicad-pcb.org/doxygen/namespaceAC__KEYS.html


I think you will agree that it would be good to fix this also within the 
devel information resources before releasing a new version.





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

[Kicad-developers] 5.1.11 release tagged

[Wayne Stambaugh]

I just pushed the 5.1.11 tag to the 5.1 branch so please tag all of the 
other repos so we can start the packaging process.  Please let me know 
if there are any issues that would delay the tagging.


Thank you everyone for continued contributions to KiCad.

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

Re: [Kicad-developers] Warning about potentially malicious software

[Wayne Stambaugh]

On 10/21/21 9:03 AM, Dick Hollenbeck wrote:

On 10/19/21 3:29 PM, Seth Hillbrand wrote:

we attempted to secure the rights to the original domain name from Dick without 
success.


This is untrue.  *No* offer was ever made, neither to re-imburse nor any offer 
to purchase was ever made.

"we attempted" is actually rediculous.   "we" is funny.  "attempted" is funny,

When Wayne lets this mis-characterization happen without stepping up to 
clarify, that is far less than what I would
expect from an old friend.


Dick is correct.  I dropped the ball on this after our last email as it 
just fell off of my radar with everything that is going on.  Mea culpa.


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

[Wayne Stambaugh]

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

[Wayne Stambaugh]

Hi Johannes,

I'm curious where you got wxWidgets 3.1.6 from.  The last tag I see in 
the wxWidgets repo is 3.1.5 and I'm pretty sure KiCad builds fine with 
wxWidgets 3.1.5.  AFAIK, the version of wxWidgets packaged for Ubuntu 
20.04 is 3.0.4.


Cheers,

Wayne

On 9/8/21 12:55 AM, j...@vfedtec.com wrote:

Howdy,

latest (today, yesterday) kicad 5.99 master source compile on 20.04

Successful compilation was possible only after the
addition of below statement in below four files.

#include 

.../kicad/common/dialogs/dialog_migrate_settings_base.h
.../kicad/eeschema/dialogs/dialog_schematic_find_base.h
.../kicad/gerbview/toolbars_gerber.cpp
.../kicad/pcbnew/dialogs/dialog_find_base.cpp

Without the '#includes', no go! Any clues?

Cheers

Johannes

---

Application: KiCad

Version: (5.99.0-12259-g7b4b7fe1ca), release build

Libraries:
     wxWidgets 3.1.6
     libcurl/7.68.0 GnuTLS/3.6.13 zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0
libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0
librtmp/2.3

Platform: Linux 5.4.0-77-generic x86_64, 64 bit, Little endian, wxGTK,
xubuntu, x11

Build Info:
     Date: Sep 8 2021 11:04:42
     wxWidgets: 3.1.6 (wchar_t,wx containers) GTK+ 3.24
     Boost: 1.71.0
     OCC: 7.5.2
     Curl: 7.68.0
     ngspice: 31
     Compiler: GCC 10.3.0 with C++ ABI 1014

Build settings:
     KICAD_USE_OCC=ON
     KICAD_USE_EGL=ON
     KICAD_SPICE=ON



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




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

[Kicad-developers] New lead developer announcement

[Wayne Stambaugh]

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

Re: [Kicad-developers] Get wxWidgets 3.1.5 package for MSYS2

[Wayne Stambaugh]

Add -DPYTHON_INCLUDE_DIR=/mingw64/include/python3.8 to the CMake command 
line.  You have msys2 python installed which for some reason, 
FindPythonLibs.cmake detects instead of the mingw64 path.


On 7/2/2021 11:55 PM, pradeepa.kck wrote:

I am using MINGW64.



Sent on the go with Vodafone


 Original message 
From: Brian Piccioni 
Date: 3/7/21 1:43 pm (GMT+10:00)
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Get wxWidgets 3.1.5 package for MSYS2

Are you doing this from an MSYS2 window or MinGW64 window? Because I was 
doing the former and had all sorts of problems like this.


On 2021-07-02 11:39 p.m., Pradeepa Senanayake wrote:
One more issue in the build related to the crypt.h file in python. Are 
there any other package changes from the doc?



[  6%] Building CXX object 
common/CMakeFiles/gal.dir/view/wx_view_controls.cpp.obj
In file included from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/detail/common.h:119,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/pytypes.h:12,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/cast.h:13,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/attr.h:13,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/pybind11.h:45,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/embed.h:12,

                 from I:/my_projects/kicad/include/pgm_base.h:41,
                 from 
I:/my_projects/kicad/common/view/wx_view_controls.cpp:29:
C:/msys64/usr/include/python3.9/Python.h:44:10: fatal error: crypt.h: 
No such file or directory

   44 | #include 
      |          ^
compilation terminated.
make[2]: *** [common/CMakeFiles/gal.dir/build.make:272: 
common/CMakeFiles/gal.dir/view/wx_view_controls.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:2688: 
common/CMakeFiles/gal.dir/all] Error 2

make: *** [Makefile:146: all] Error 2


Following are the python packages I have for python:

Pradeepa@DESKTOP-OA7GTE5 MINGW64 /i/my_projects/kicad/build/release
$ pacman -Qs python
local/mingw-w64-x86_64-python 3.8.9-2
    A high-level scripting language (mingw-w64)
local/mingw-w64-x86_64-python-numpy 1.21.0-1
    Scientific tools for Python (mingw-w64)
local/mingw-w64-x86_64-python-pillow 8.3.0-1
    Python Imaging Library (PIL) fork Python3 version (mingw-w64)
local/mingw-w64-x86_64-python-six 1.16.0-1
    Python 2 and 3 compatibility utilities (mingw-w64)
local/mingw-w64-x86_64-python2 2.7.18-1
    A high-level scripting language (mingw-w64)
local/mingw-w64-x86_64-wxPython 4.1.1-1
    A wxWidgets GUI toolkit for Python (mingw-w64)
local/python 3.9.5-1
    Next generation of the python high-level scripting language
local/scons 3.1.2-6 (base-devel)
    Extensible Python-based build utility

Best Regards,
Pradeepa Senanayake.


On Sat, Jul 3, 2021 at 1:10 PM Pradeepa Senanayake 
mailto:pradeepa@gmail.com>> wrote:


Thanks! You are right.

I had to remove the outdated wxWidgets package and clean up my
build folder.

Best Regards,
Pradeepa Senanayake.


On Sat, Jul 3, 2021 at 1:03 PM Brian Piccioni
mailto:br...@documenteddesigns.com>>
wrote:

Yes, I checked

mingw-w64-x86_64-wxmsw3.1 gets you 3.1.5


mingw64/mingw-w64-x86_64-wxmsw3.1 3.1.5-1 [installed]
    A C++ library that lets developers create applications for
Windows, Linux and UNIX (mingw-w64)

On 2021-07-02 10:51 p.m., Pradeepa Senanayake wrote:

Hello,

I'm trying to build the KiCad in MSYS2.

I get the following error,

  Could NOT find wxWidgets: Found unsuitable version "3.0.5",
but required is
  at least "3.1.5"

I cannot download the required version through the suggested
pacman -S mingw-w64-x86_64-wxWidgets command.
(https://packages.msys2.org/package/mingw-w64-x86_64-wxWidgets 
)

Do I need to build wxWidgets from the source?

Best Regards,
Pradeepa Senanayake.

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

Re: [Kicad-developers] Experience compiling latest HEAD

[Wayne Stambaugh]

On 6/28/21 12:34 PM, Ruth Ivimey-Cook wrote:

I have v5.1 from http://ppa.launchpad.net/kicad/kicad-5.1-releases/ubuntu/


In the short term, we will probably continue to package 5.1 with wx 3.0. 
 This is primarily to ensure that our python scripts aren't broken by 
Python 3 which is require when building with wxWidgets 3.1.




And the kicad built nightly v5.99 from 
http://ppa.launchpad.net/kicad/kicad-dev-nightly/ubuntu/


And it's v5.99 I was asking to include wx 3.1.


I though we had changed our nightly Ubuntu builds over to 3.1 but 
apparently not.  Maybe our PPA package dev can comment about what it 
would take to do that.  I've been using 3.1 on Debian testing for quite 
a long time now and it seems to be stable and it also fixes a lot of issues.




Ruth


On 28/06/2021 16:53, Wayne Stambaugh wrote:

Which version of KiCad are you talking about, 5.1 or master?  Where are
you getting your Kubuntu KiCad package, Kubuntu or the KiCad PPA?  The
decision to build against wxWidgets 3.1 is up to the disto package
developer if you are using the disto's package.

On 6/28/21 11:38 AM, Ruth Ivimey-Cook wrote:

Folks,

I'm using Kicad on Kubuntu 21.04 with a 4K screen, and experience the
'tiny fonts' problem on it. I got fed up with that a few days ago and
noticed the recommendations that wxWin 3.1 fixes many issues. I first
tried to install the 'flatpak' build, but couldn't do so, so then I
compiled it from scratch. It took a little while but I did get to a
build (re: the recent GLEW posts, that was a problem for me also).

The project screen loaded fine and displays the fonts very nicely...
however, pcbnew fails (either directly or via project window) with a DRI
failed to authenticate message. Having looked around, I think this could
be because I'm using the nVidia driver for my GTX1060 GPU which doesn't
play nice with DRI. However, the officially-compiled kicad versions
(including nightly) work fine in that regard, so I'm not sure what is
happening there.

So, this is a long post to say:

 Please incorporate wx 3.1 into the Linux build, as you have for the
Win and Mac builds, because wx 3.0 is broken.

Also, it would be good to know (if it is known) what happened with 
DRI 2.


Ruth


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

[Wayne Stambaugh]

Which version of KiCad are you talking about, 5.1 or master?  Where are
you getting your Kubuntu KiCad package, Kubuntu or the KiCad PPA?  The
decision to build against wxWidgets 3.1 is up to the disto package
developer if you are using the disto's package.

On 6/28/21 11:38 AM, Ruth Ivimey-Cook wrote:
> Folks,
> 
> I'm using Kicad on Kubuntu 21.04 with a 4K screen, and experience the
> 'tiny fonts' problem on it. I got fed up with that a few days ago and
> noticed the recommendations that wxWin 3.1 fixes many issues. I first
> tried to install the 'flatpak' build, but couldn't do so, so then I
> compiled it from scratch. It took a little while but I did get to a
> build (re: the recent GLEW posts, that was a problem for me also).
> 
> The project screen loaded fine and displays the fonts very nicely...
> however, pcbnew fails (either directly or via project window) with a DRI
> failed to authenticate message. Having looked around, I think this could
> be because I'm using the nVidia driver for my GTX1060 GPU which doesn't
> play nice with DRI. However, the officially-compiled kicad versions
> (including nightly) work fine in that regard, so I'm not sure what is
> happening there.
> 
> So, this is a long post to say:
> 
>     Please incorporate wx 3.1 into the Linux build, as you have for the
> Win and Mac builds, because wx 3.0 is broken.
> 
> Also, it would be good to know (if it is known) what happened with DRI 2.
> 
> Ruth
> 

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

Re: [Kicad-developers] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[Wayne Stambaugh]

Good catch.  I missed that when I made the change.  I will fix the
message when I get a chance.  I would prefer not to use a dialog.  Maybe
adding a warning to update the schematic to the message panel would be a
less intrusive.  The other option would be an info bar.

On 6/28/21 11:32 AM, Brian Piccioni wrote:
> Ah.
> 
> Perhaps it would be useful to throw up a dialog to the effect that that
> the schematic should be updated?
> 
> It still says
> 
> PCB and schematic successfully reannotated
> 
> In the dialog.
> 
> 
> On 2021-06-28 11:29 a.m., Wayne Stambaugh wrote:
>> The reannotation dialog update schematic option because it was removed
>> because it could leave schematics in an undefined state under certain
>> conditions.  See commit 54e18f6b1f4c2199f8748fff82198f86522bef83 and the
>> related issue for details.
>>
>> Wayne
>>
>> On 6/28/21 9:51 AM, Brian Piccioni wrote:
>>> Hello
>>>
>>> I have observed that Geographical Reannotation (my contribution) no
>>> longer seems to update the schematic. Manual "Update Schematic from PCB"
>>> seems to work so I assume there has been a modification to the Kiway
>>> commands. In order to track this down I need to set up build on msys2.
>>>
>>> I have followed the instructions at
>>> https://dev-docs.kicad.org/en/build/windows-msys2/. In addition I had to
>>>
>>> pacman -S cmake
>>> pacman -S gcc.
>>>
>>> cmake fails with Could NOT find GLEW (missing: GLEW_LIBRARY)
>>>
>>> Glew is installed as per the instructions.
>>>
>>> Any suggestions?
>>>
>>> Brian
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[Wayne Stambaugh]

The reannotation dialog update schematic option because it was removed
because it could leave schematics in an undefined state under certain
conditions.  See commit 54e18f6b1f4c2199f8748fff82198f86522bef83 and the
related issue for details.

Wayne

On 6/28/21 9:51 AM, Brian Piccioni wrote:
> Hello
> 
> I have observed that Geographical Reannotation (my contribution) no
> longer seems to update the schematic. Manual "Update Schematic from PCB"
> seems to work so I assume there has been a modification to the Kiway
> commands. In order to track this down I need to set up build on msys2.
> 
> I have followed the instructions at
> https://dev-docs.kicad.org/en/build/windows-msys2/. In addition I had to
> 
> pacman -S cmake
> pacman -S gcc.
> 
> cmake fails with Could NOT find GLEW (missing: GLEW_LIBRARY)
> 
> Glew is installed as per the instructions.
> 
> Any suggestions?
> 
> Brian
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] OCC now default build configuration

[Wayne Stambaugh]

OpenCascade is now the default when building KiCad.  This includes the 
5.1 branch.  This was done because OCC fixes a few bugs in OCE and OCE 
support will eventually be removed.


Package developers should adjust the platform build and install 
dependencies to OCC as required.  If a platform doesn't support OCC, 
configure builds with -DKICAD_USE_OCE=ON -DKICAD_USE_OCC=OFF in order to 
build against OCE.  Also, make sure OCE is uninstalled from your system 
before installing OCC as library conflicts can cause issues on some 
platforms.


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

Re: [Kicad-developers] Python 3 now required

[Wayne Stambaugh]

On 6/14/21 4:59 PM, Kevin Cozens wrote:

On 2021-06-14 4:34 p.m., Marco Ciampa wrote:

On Mon, Jun 14, 2021 at 03:43:54PM -0400, Jon Evans wrote:

You should be able to override what is found by CMake by defining the
PYTHON_EXECUTABLE variable in your cmake command line


Gosh, shame on me, it was so simple!


Not that simple. I tried passing -DPYTHON_EXECUTABLE=python3 and it 
still only finds 2.7. I tried it without the -D part. I have also tried 
it with and without a full path to python3. I even tried putting 
PYTHON_EXECUTABLE before 'cmake' on the line.


How do you tell cmake which version of python you want to use?




According to FindPythonInterp.cmake, the PYTHON_ROOT_DIR variable is 
used to control the Python interpreter rather than use the normal find 
method.  I set it to the Python3 executable on my MinGW builds and it 
works as expected.  I'm guessing Linux builds would also work using this 
config method.


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

Re: [Kicad-developers] Odp: Re: SPICE_VALUE behavior

[Wayne Stambaugh]

Hi Sylwester,

Got it. I would avoid rejecting all extra characters after the 
multiplier suffix and parse SI units (if they are defined).  If the SI 
units are not valid, then the value should be rejected as invalid.


Wayne

On 5/19/21 12:45 PM, Sylwester Kocjan wrote:

Hi Wayne,

Dnia 19 maja 2021 00:32 Wayne Stambaugh <mailto:stambau...@gmail.com>> napisał(a):


The test cases look correct so I don't see any issues here.


Could you please check again with better formatting below? Hertz is a 
valid SI unit, so strings: "10m" and "10mHz" are valid, but

values ending with "Hzz" are invalid:





*Scenario:*
*Input:*
*Actual behavior:*
*Expected behavior:*
*Result:*
Positive
10m
Value parsed correctly
Value parsed correctly
PASS
Positive
10mHz
Value parsed correctly
Value parsed correctly
PASS
Negative
10mHzz
Value parsed correctly
Exception thrown
FAIL
Positive
10Hz
Exception thrown
Value parsed correctly
FAIL
Negative
10Hzz
Exception thrown
Exception thrown
PASS

Parsing strings in V7 wouldn't hurt, that's no problem, but the 
easiest solution is to reject all extra characters:





*Input:*
*Actual behavior:*
10m
Value parsed correctly
10mHz
Exception thrown
10mHzz
Exception thrown
10Hz
Exception thrown
10Hzz
Exception thrown


Best regards,
Sylwester

Dnia 19 maja 2021 00:32 Wayne Stambaugh <mailto:stambau...@gmail.com>> napisał(a):


Hi Sylwester,

I don't know that we need to support SI units in spice strings but I
suppose it wouldn't hurt.  That would have to wait until V7 as 

it is a

new feature.  The test cases look correct so I don't see any
issues here.

- Wayne

On 5/18/21 2:06 PM, Sylwester Kocjan wrote:

Hello!

I've noticed a minor bug in SPICE_VALUE class. Could you
please let me
know if we should parse SI units in SPICE strings or ignore
them, so I
can fix it? I think ngspice accepts units like, V, I, Ohm, but
this may
be an overkill. The easiest solution is to ignore everything after
number and prefix.

See below the testcases I made on AC tab of Simulation
Settings dialog:

Input:  Actual behavior:    Expected behavior:
10m Value parsed correctly  Value parsed correctly
10mHz   Value parsed correctly  Value parsed correctly
10mHzz  Value parsed correctly  

Exception thrown

10Hz    Exception thrown    Value parsed correctly
10Hzz   Exception thrown    Exception thrown

Best regards,
Sylwester

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



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

[Wayne Stambaugh]

Hi Sylwester,

I don't know that we need to support SI units in spice strings but I 
suppose it wouldn't hurt.  That would have to wait until V7 as it is a 
new feature.  The test cases look correct so I don't see any issues here.


- Wayne

On 5/18/21 2:06 PM, Sylwester Kocjan wrote:

Hello!

I've noticed a minor bug in SPICE_VALUE class. Could you please let me 
know if we should parse SI units in SPICE strings or ignore them, so I 
can fix it? I think ngspice accepts units like, V, I, Ohm, but this may 
be an overkill. The easiest solution is to ignore everything after 
number and prefix.


See below the testcases I made on AC tab of Simulation Settings dialog:

Input:  Actual behavior:    Expected behavior:
10m Value parsed correctly  Value parsed correctly
10mHz   Value parsed correctly  Value parsed correctly
10mHzz  Value parsed correctly  Exception thrown
10Hz    Exception thrown    Value parsed correctly
10Hzz   Exception thrown    Exception thrown

Best regards,
Sylwester

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



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

Re: [Kicad-developers] OCE vs. OCC default build flag

[Wayne Stambaugh]

Make sure that OCE is not installed along side OCC.  I also had to add 
"-DOCC_INCLUDE_DIR=/${MINGW_PREFIX}/include/opencascade" so that 
FindOpenCASCADE.cmake could find the header files.  Everything else 
should build as normal.


On 5/18/2021 9:12 AM, Nick Østergaard wrote:

It did not work last time I tried it.

On Tue, 18 May 2021 at 14:43, Wayne Stambaugh <mailto:stambau...@gmail.com>> wrote:


I just looked and the 5.1.10 windows build is using OCE.  I thought we
switched over to OCC for msys2 builds but apparently not.  I have
switched to OCC on my windows msys2 builds.  I think we should switch
the msys2 5.1 builds to OCC because it resolves some issues.

Wayne

On 5/17/2021 3:21 PM, Seth Hillbrand wrote:
 > After reviewing the thread that Nick linked
 > (https://gitlab.com/kicad/code/kicad/-/issues/6198
<https://gitlab.com/kicad/code/kicad/-/issues/6198>
 > <https://gitlab.com/kicad/code/kicad/-/issues/6198
<https://gitlab.com/kicad/code/kicad/-/issues/6198>>) I recall this
 > discussion more.
 >
 > I think that we should remove OCE altogether.  The existing versions
 > have bugs that we cannot fix and it is fully deprecated at the
source
 > repository (https://github.com/tpaviot/oce/releases
<https://github.com/tpaviot/oce/releases>
 > <https://github.com/tpaviot/oce/releases
<https://github.com/tpaviot/oce/releases>>) in that it only tags
upstream
 > releases and hasn't released any updates since 2018.
 >
 > Keeping OCE in the build tree as an option is just asking for
headaches
 > that we can avoid in v6.
 >
 > -Seth
 >
 > On Mon, May 17, 2021 at 12:07 PM Steven A. Falco
mailto:stevenfa...@gmail.com>
 > <mailto:stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>>> wrote:
 >
 >     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
<https://launchpad.net/~kicad-developers>
 >     <https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>>
 >     Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
 >     <mailto:kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>>
 >     Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
 >     <https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>>
 >     More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>
 >     <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 <http://www.kipro-pcb.com>
<https://www.kipro-pcb.com/ <https://www.kipro-pcb.com/>>
i...@kipro-pcb.com <mailto:i...@kipro-pcb.com>
 > <mailto: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
<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] OCE vs. OCC default build flag

[Wayne Stambaugh]

I just looked and the 5.1.10 windows build is using OCE.  I thought we 
switched over to OCC for msys2 builds but apparently not.  I have 
switched to OCC on my windows msys2 builds.  I think we should switch 
the msys2 5.1 builds to OCC because it resolves some issues.


Wayne

On 5/17/2021 3:21 PM, Seth Hillbrand wrote:
After reviewing the thread that Nick linked 
(https://gitlab.com/kicad/code/kicad/-/issues/6198 
) I recall this 
discussion more.


I think that we should remove OCE altogether.  The existing versions 
have bugs that we cannot fix and it is fully deprecated at the source 
repository (https://github.com/tpaviot/oce/releases 
) in that it only tags upstream 
releases and hasn't released any updates since 2018.


Keeping OCE in the build tree as an option is just asking for headaches 
that we can avoid in v6.


-Seth

On Mon, May 17, 2021 at 12:07 PM Steven A. Falco > wrote:


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




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

[Wayne Stambaugh]

How does this change affect our package devs?  I'm guessing they would 
have to make some package dependencies changes if OCC is going to be the 
default.  I would like to hear from them before we make OCC the default.


We will also have to update the developer docs to reflect this change.

Wayne

On 5/16/21 7:24 PM, Seth Hillbrand wrote:
Yes, our plan has been to switch the default (if it is not already).  We 
were waiting until both MSVC and Mac builds had OCC well tested, which I 
think has happened now.


Seth

On Sun, May 16, 2021, 2:10 PM Eeli Kaikkonen > wrote:


While I was writing Linux and several distro specific build
instructions (

https://gitlab.com/eelik-kicad/kicad/-/wikis/How-to-build-KiCad-on-Linux-(the-easy-way)


, discussion in

https://forum.kicad.info/t/build-from-source-simple-instructions-to-compile-kicad-for-some-linux-distributions/28982


) I noticed that all distros I tried have OCC instead of OCE.

Should the default build flag be changed to be OCC instead of OCE?

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

[Kicad-developers] 5.1.10 stable released

[Wayne Stambaugh]

KiCad 5.1.10 has officially been released[1].  Downloads are available 
now for most operating systems[2].  Thanks to everyone who contributed 
their time and talent to make this release of KiCad possible.


Cheers,

Wayne

[1]: https://www.kicad.org/blog/2021/05/KiCad-5.1.10-Release/
[2]: https://www.kicad.org/download/

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

[Kicad-developers] 5.1.10 stable release tagged

[Wayne Stambaugh]

I just pushed the stable release tag to GitLab.  Please update any repo 
tags as required so we can get the packages build.  I will get the 
release announcement ready over the weekend.  Once we have packages 
ready for download and the website updated, I will make the release 
announcement.  Thank you everyone for you continued support of the KiCad 
project.


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

[Kicad-developers] Stable release 5.1.10 tag

[Wayne Stambaugh]

I would like to tag the 5.1.10 release on Friday, April 23rd.  That 
would give us a week to get packages built, the website download pages 
updated, and make release announcements on all of the usual channels. 
Is there anything outstanding that would prevent us from tagging on 
Friday?  Please let me know.


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

Re: [Kicad-developers] Can we merge a change to STEP export despite code freeze?

[Wayne Stambaugh]

Hi Cirilo,

I would prefer that we hold off until the master branch is open for new 
features.  We have far more outstanding issues than I would like to see 
with less than 3 months to V6 release.  Adding yet another new feature 
during the freeze only increases the potential bug surface.  Feel free 
to get the merge request ready to go so it can be merged as soon as 
master is open for new features.


Cheers,

Wayne

On 4/10/21 11:35 PM, Cirilo Bernardo wrote:

I made a small change to the STEP exporter:
https://gitlab.com/cbernardo/kicad

The change implements the creation of STEP models based on IDF outlines.
This makes it possible for users to specify simple extruded models for some
parts and more complex STEP models where the size and form matter.

Although in code freeze, this only affects the (standalone) STEP exporter
and should have no impact on the main KiCad suite so I think it's safe to put
it in.

Let me know if a merge for this change would be OK and I can create
the merge request.

Regards,
Cirilo

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

[Wayne Stambaugh]

On 4/2/2021 2:08 PM, Marco Ciampa wrote:

On Fri, Apr 02, 2021 at 01:21:11PM -0400, Wayne Stambaugh wrote:

I would like to tag 5.1.10 for release by the end of April for release in
early May.  This is a heads up to the rest of the development teams to
please get everything ready to go by then.  Please let me know if you
anticipate any issues with that date so I can push back the schedule. Thanks
in advance for the help.


In kicad/tree_project_frame.cpp line 1086

else
 {
 m_Parent->SetStatusText( _( "" ), 0 );
 }

rises this warning:

./update-po-files.sh it
Using default SOURCEDIR=../kicad
kicad/tree_project_frame.cpp:1086: warning: Empty msgid.  It is reserved by GNU 
gettext:
 gettext("") returns the header 
entry with
 meta information, not the empty 
string.

please add a space or something or just delete it (why did someone make it?) ...


Either wxEmptyString or the wxT() macro is probably the way to go here.



--

Saluton,
Marco Ciampa

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



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

[Kicad-developers] 5.1.10 stable release

[Wayne Stambaugh]

I would like to tag 5.1.10 for release by the end of April for release 
in early May.  This is a heads up to the rest of the development teams 
to please get everything ready to go by then.  Please let me know if you 
anticipate any issues with that date so I can push back the schedule. 
Thanks in advance for the help.


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

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

I guess that's not going to work.  We may just have to punt on a
sensible solution. :(

On 3/23/21 6:03 PM, Mark Roszko wrote:
> pkgconfig is only available for builds within vcpkg for builds of libraries.
> 
> kicad does not build within vcpkg, it builds outside vcpkg using vcpkg.
> This is the intended mode of use for applications.
> 
> On Tue, Mar 23, 2021 at 12:09 PM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> Did I misunderstand Marks's comments about MSVC?  I though he said that
> pkg-config would not be available to KiCad at runtime and that it would
> be available (I'm assuming via vcpkg) at build time.  I really want to
> avoid a separate solution for MSVC if possible.
> 
> On 3/23/21 11:32 AM, Jon Evans wrote:
> > As Wayne points out, compatibility with older ngspice versions
> needs to
> > be considered, as well as Windows/vcpkg.
> >
> > Since pkg-config apparently can't be used in the MSVC/vcpkg
> environment
> > during the kicad build, the only option I can think of is to
> generate a
> > version header as part of the ngspice vcpkg port itself.
> >
> > So, there would be two different paths, one for Windows/MSVC and
> one for
> > other platforms.
> >
> > -Jon
> >
> > On Tue, Mar 23, 2021 at 11:28 AM Jonatan Liljedahl
> mailto:li...@kymatica.com>
> > <mailto:li...@kymatica.com <mailto:li...@kymatica.com>>> wrote:
> >
> >     Ah, yes that sounds reasonable. I guess
> >     /CMakeModules/Findngspice.cmake could be modified to use
> pkg-config to
> >     get the version and paths needed?
> >
> >     On Tue, Mar 23, 2021 at 4:20 PM Jon Evans  <mailto:j...@craftyjon.com>
> >     <mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>> wrote:
> >     >
> >     > It sounds like the preference is to move away from using a
> >     config.h at all, which means all the KiCad packaging systems would
> >     need to update to use pkg-config to generate a header which
> can then
> >     be included in kicad's build process.  Is that correct?
> >     >
> >     > On Tue, Mar 23, 2021 at 11:15 AM Jonatan Liljedahl
> >     mailto:li...@kymatica.com>
> <mailto:li...@kymatica.com <mailto:li...@kymatica.com>>> wrote:
> >     >>
> >     >> If ngspice-35 is not ready to be tagged soon, perhaps
> Holger could
> >     >> make a branch called "ngspice-34-config-fix" or something,
> based on
> >     >> the ngspice-34 tag but only adding the simple fix of installing
> >     >> config.h into /include/ngspice/ instead? Then KiCad
> packagers could
> >     >> build from this branch? Unless some packages are not using
> locally
> >     >> built ngspice? Just some ideas of possible solutions...
> >     >>
> >     >> Cheers
> >     >>
> >     >> On Tue, Mar 23, 2021 at 3:22 PM Holger Vogt
> >     mailto:holger.v...@uni-due.de>
> <mailto:holger.v...@uni-due.de <mailto:holger.v...@uni-due.de>>> wrote:
> >     >> >
> >     >> > The intention is to not at all install config.h.
> >     >> >
> >     >> > Installing it into ./include was a bug in ngspice-34
> which has
> >     already
> >     >> > been removed in the current ngspice master branch.
> >     >> >
> >     >> > Perhaps you may make use of this bug by automatically moving
> >     config.h
> >     >> > from <...>/include/ to <...>/include/ngspice/ when
> building KiCad,
> >     >> > before we will have a solution without config.h in
> ngspice-35?
> >     >> >
> >     >> >
> >     >> > ___
> >     >> > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     >> > Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>&

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

I guess that's not going to work.  We may just have to punt on a
sensible solution. :(

On 3/23/21 6:03 PM, Mark Roszko wrote:
> pkgconfig is only available for builds within vcpkg for builds of libraries.
> 
> kicad does not build within vcpkg, it builds outside vcpkg using vcpkg.
> This is the intended mode of use for applications.
> 
> On Tue, Mar 23, 2021 at 12:09 PM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> Did I misunderstand Marks's comments about MSVC?  I though he said that
> pkg-config would not be available to KiCad at runtime and that it would
> be available (I'm assuming via vcpkg) at build time.  I really want to
> avoid a separate solution for MSVC if possible.
> 
> On 3/23/21 11:32 AM, Jon Evans wrote:
> > As Wayne points out, compatibility with older ngspice versions
> needs to
> > be considered, as well as Windows/vcpkg.
> >
> > Since pkg-config apparently can't be used in the MSVC/vcpkg
> environment
> > during the kicad build, the only option I can think of is to
> generate a
> > version header as part of the ngspice vcpkg port itself.
> >
> > So, there would be two different paths, one for Windows/MSVC and
> one for
> > other platforms.
> >
> > -Jon
> >
> > On Tue, Mar 23, 2021 at 11:28 AM Jonatan Liljedahl
> mailto:li...@kymatica.com>
> > <mailto:li...@kymatica.com <mailto:li...@kymatica.com>>> wrote:
> >
> >     Ah, yes that sounds reasonable. I guess
> >     /CMakeModules/Findngspice.cmake could be modified to use
> pkg-config to
> >     get the version and paths needed?
> >
> >     On Tue, Mar 23, 2021 at 4:20 PM Jon Evans  <mailto:j...@craftyjon.com>
> >     <mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>> wrote:
> >     >
> >     > It sounds like the preference is to move away from using a
> >     config.h at all, which means all the KiCad packaging systems would
> >     need to update to use pkg-config to generate a header which
> can then
> >     be included in kicad's build process.  Is that correct?
> >     >
> >     > On Tue, Mar 23, 2021 at 11:15 AM Jonatan Liljedahl
> >     mailto:li...@kymatica.com>
> <mailto:li...@kymatica.com <mailto:li...@kymatica.com>>> wrote:
> >     >>
> >     >> If ngspice-35 is not ready to be tagged soon, perhaps
> Holger could
> >     >> make a branch called "ngspice-34-config-fix" or something,
> based on
> >     >> the ngspice-34 tag but only adding the simple fix of installing
> >     >> config.h into /include/ngspice/ instead? Then KiCad
> packagers could
> >     >> build from this branch? Unless some packages are not using
> locally
> >     >> built ngspice? Just some ideas of possible solutions...
> >     >>
> >     >> Cheers
> >     >>
> >     >> On Tue, Mar 23, 2021 at 3:22 PM Holger Vogt
> >     mailto:holger.v...@uni-due.de>
> <mailto:holger.v...@uni-due.de <mailto:holger.v...@uni-due.de>>> wrote:
> >     >> >
> >     >> > The intention is to not at all install config.h.
> >     >> >
> >     >> > Installing it into ./include was a bug in ngspice-34
> which has
> >     already
> >     >> > been removed in the current ngspice master branch.
> >     >> >
> >     >> > Perhaps you may make use of this bug by automatically moving
> >     config.h
> >     >> > from <...>/include/ to <...>/include/ngspice/ when
> building KiCad,
> >     >> > before we will have a solution without config.h in
> ngspice-35?
> >     >> >
> >     >> >
> >     >> > ___
> >     >> > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     >> > Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>&

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

Did I misunderstand Marks's comments about MSVC?  I though he said that
pkg-config would not be available to KiCad at runtime and that it would
be available (I'm assuming via vcpkg) at build time.  I really want to
avoid a separate solution for MSVC if possible.

On 3/23/21 11:32 AM, Jon Evans wrote:
> As Wayne points out, compatibility with older ngspice versions needs to
> be considered, as well as Windows/vcpkg.
> 
> Since pkg-config apparently can't be used in the MSVC/vcpkg environment
> during the kicad build, the only option I can think of is to generate a
> version header as part of the ngspice vcpkg port itself.
> 
> So, there would be two different paths, one for Windows/MSVC and one for
> other platforms.
> 
> -Jon
> 
> On Tue, Mar 23, 2021 at 11:28 AM Jonatan Liljedahl  > wrote:
> 
> Ah, yes that sounds reasonable. I guess
> /CMakeModules/Findngspice.cmake could be modified to use pkg-config to
> get the version and paths needed?
> 
> On Tue, Mar 23, 2021 at 4:20 PM Jon Evans  > wrote:
> >
> > It sounds like the preference is to move away from using a
> config.h at all, which means all the KiCad packaging systems would
> need to update to use pkg-config to generate a header which can then
> be included in kicad's build process.  Is that correct?
> >
> > On Tue, Mar 23, 2021 at 11:15 AM Jonatan Liljedahl
> mailto:li...@kymatica.com>> wrote:
> >>
> >> If ngspice-35 is not ready to be tagged soon, perhaps Holger could
> >> make a branch called "ngspice-34-config-fix" or something, based on
> >> the ngspice-34 tag but only adding the simple fix of installing
> >> config.h into /include/ngspice/ instead? Then KiCad packagers could
> >> build from this branch? Unless some packages are not using locally
> >> built ngspice? Just some ideas of possible solutions...
> >>
> >> Cheers
> >>
> >> On Tue, Mar 23, 2021 at 3:22 PM Holger Vogt
> mailto:holger.v...@uni-due.de>> wrote:
> >> >
> >> > The intention is to not at all install config.h.
> >> >
> >> > Installing it into ./include was a bug in ngspice-34 which has
> already
> >> > been removed in the current ngspice master branch.
> >> >
> >> > Perhaps you may make use of this bug by automatically moving
> config.h
> >> > from <...>/include/ to <...>/include/ngspice/ when building KiCad,
> >> > before we will have a solution without config.h in ngspice-35?
> >> >
> >> >
> >> > ___
> >> > Mailing list: https://launchpad.net/~kicad-developers
> 
> >> > Post to     : kicad-developers@lists.launchpad.net
> 
> >> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> >> > More help   : https://help.launchpad.net/ListHelp
> 
> >>
> >>
> >>
> >> --
> >> /Jonatan
> >> http://kymatica.com 
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> 
> >> Post to     : kicad-developers@lists.launchpad.net
> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> >> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> -- 
> /Jonatan
> http://kymatica.com 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

On 3/23/21 11:20 AM, Jon Evans wrote:
> It sounds like the preference is to move away from using a config.h at
> all, which means all the KiCad packaging systems would need to update to
> use pkg-config to generate a header which can then be included in
> kicad's build process.  Is that correct?

I would say yes assuming ngspice supports pkg-config back to a least
version 32.  This would be a reliable way to address this for most if
not all existing platforms now and going forward assuming ngspice will
continue to support pkg-config.

> 
> On Tue, Mar 23, 2021 at 11:15 AM Jonatan Liljedahl  > wrote:
> 
> If ngspice-35 is not ready to be tagged soon, perhaps Holger could
> make a branch called "ngspice-34-config-fix" or something, based on
> the ngspice-34 tag but only adding the simple fix of installing
> config.h into /include/ngspice/ instead? Then KiCad packagers could
> build from this branch? Unless some packages are not using locally
> built ngspice? Just some ideas of possible solutions...
> 
> Cheers
> 
> On Tue, Mar 23, 2021 at 3:22 PM Holger Vogt  > wrote:
> >
> > The intention is to not at all install config.h.
> >
> > Installing it into ./include was a bug in ngspice-34 which has already
> > been removed in the current ngspice master branch.
> >
> > Perhaps you may make use of this bug by automatically moving config.h
> > from <...>/include/ to <...>/include/ngspice/ when building KiCad,
> > before we will have a solution without config.h in ngspice-35?
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> > More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> -- 
> /Jonatan
> http://kymatica.com 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

On 3/22/21 7:02 PM, Mark Roszko wrote:
>> Does vcpkg support pkg-config?
> 
> vcpkg can use pkg-config for building its own libraries.
> However vcpkg will not share it outside of itself, meaning kicad has no
> ability to use it easily

I wasn't thinking about calling it from KiCad at runtime.  I was
thinking running it from CMake at build time to fetch the ngspice build
version.

> 
> On Mon, Mar 22, 2021 at 3:18 PM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> Would pkg-config work on all platforms?  I know it works on Linux and
> msys2.  I would rather not have a separate hack for every platform if we
> can avoid it.  Does vcpkg support pkg-config?  If so, then it should be
> possible to use it on msvc builds as well.
> 
> On 3/22/21 2:57 PM, Jon Evans wrote:
> > Bumping this thread as we don't seem to have a resolution yet.
> >
> > The Windows vcpkg package works as there is still a config.h with the
> > version in the "visualc" directory.
> >
> > But, MacOS doesn't build and I guess some Linux distros don't either.
> >
> > Can we make pkg-config work for MacOS?
> >
> > On Wed, Feb 3, 2021 at 1:45 PM Carsten Schoenert
> > mailto:c.schoen...@t-online.de>
> <mailto:c.schoen...@t-online.de <mailto:c.schoen...@t-online.de>>>
> wrote:
> >
> >     Am 03.02.21 um 13:03 schrieb jp charras:
> >     > OTOH, a version.h file is not a bad idea (read: for me a
> very good
> >     idea):
> >     >
> >     > at least the name is already a useful comment and it request
> only
> >     a very
> >     > few amount of work.
> >     >
> >     > Many tools use this trick (for instance opencascade, and most of
> >     other
> >     > tools we are using in Kicad), and one **big** advantage it works
> >     outside
> >     > the libtool stuff.
> >
> >     For simple things like version detection pkg-config is already
> enough,
> >     no need for mostly incompatible hacks. Even different shells
> on the same
> >     host can behavior really unexpected.
> >
> >     If you need to detect the version of ngspice you will need to
> do this
> >     this already before any build is started.
> >
> >     > $ pkg-config --modversion ngspice
> >     > 33
> >     --
> >     Regards
> >     Carsten
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     More help   : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> >     <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>
> >
> 
> ___
> 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

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

Would pkg-config work on all platforms?  I know it works on Linux and
msys2.  I would rather not have a separate hack for every platform if we
can avoid it.  Does vcpkg support pkg-config?  If so, then it should be
possible to use it on msvc builds as well.

On 3/22/21 2:57 PM, Jon Evans wrote:
> Bumping this thread as we don't seem to have a resolution yet.
> 
> The Windows vcpkg package works as there is still a config.h with the
> version in the "visualc" directory.
> 
> But, MacOS doesn't build and I guess some Linux distros don't either.
> 
> Can we make pkg-config work for MacOS?
> 
> On Wed, Feb 3, 2021 at 1:45 PM Carsten Schoenert
> mailto:c.schoen...@t-online.de>> wrote:
> 
> Am 03.02.21 um 13:03 schrieb jp charras:
> > OTOH, a version.h file is not a bad idea (read: for me a very good
> idea):
> >
> > at least the name is already a useful comment and it request only
> a very
> > few amount of work.
> >
> > Many tools use this trick (for instance opencascade, and most of
> other
> > tools we are using in Kicad), and one **big** advantage it works
> outside
> > the libtool stuff.
> 
> For simple things like version detection pkg-config is already enough,
> no need for mostly incompatible hacks. Even different shells on the same
> host can behavior really unexpected.
> 
> If you need to detect the version of ngspice you will need to do this
> this already before any build is started.
> 
> > $ pkg-config --modversion ngspice
> > 33
> -- 
> 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

Re: [Kicad-developers] Current development status?

[Wayne Stambaugh]

On 3/20/21 11:02 AM, RigoLigo RLC wrote:
> I have a few questions about the current KiCad development.
> 
> 1. new features after feature freeze?
> 
> Most significantly, the separate icon set. While everyone is looking
> forward to having this small feature, it's still kinda offending the
> term feature "freeze". Though we weren't at string freeze, new features
> are already annoying enough to translators. Are we getting other
> features before V6 launch?

Yes. There is one major (the new Python API) and a few minor exceptions
still outstanding.  The new icon set code was on the feature freeze
exception list maintained by the lead development team.  I believe I
mentioned that there were a few exceptions that were outstanding when I
made the feature freeze announcement.  If I didn't, my bad.

The string freeze will be announced as soon as all of the exceptions
have been committed and the code base has stabilized.

> 
> 2. unresolved mysterious crashes
> 
> Many (or most) critical/high priority issues are unresolved crashes,
> usually hard to reproduce, without need-info tag. Are they slowing down
> the version iteration? I mean, KiCad crashes are not new, not to mention
> those that are hard to tackle. Reducing data loss with autosave and such
> would be enough for current status of KiCad IMO. Of course crashes that
> have known reasons must be fixed. But what are we going to do with these
> mysterious crash issues? Wait till they're resolved before we launch RC1?

All known reproducible crash bugs must be fixed before RC1 can happen
but yes hard to reproduce bugs are always going to slow things down.

> 
> 3. Development iteration...
> 
> Currently KiCad will push big version leaps for all the features
> developers add into it. I know it's got reasons (difficulty of
> maintaining two branches, plugin API consistency) but a big leap
> requires a LONG wait. For OSS users this might not be a big problem but
> in Chinese community there are companies that use KiCad as alternatives.
> They dare not to use nightlies(even it's stable, it's not a stable
> release, and files are incompatible), but are still eager to have nice
> new features. Will we get more frequent updates like 6.1 6.2 adding
> small features step by step instead of doing all the things in one
> milestone?

There most likely will not be point version releases but the lead
development team has discussed smaller change sets and possibly an
annual release schedule to lower the time between releases so that is a
likely possibility.

- Wayne

> 
> I'd like to know from you guys.
> 
> Rigo
> 
> ___
> Mailing list: https://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] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Wayne Stambaugh]

It seems as though we are heading towards a consensus that making the
simulator build mandatory unless there is some strenuous objection to
doing so by one of our package developers.  I still want to give
everyone a chance to reply before I make the change.  In the mean time,
I think I'm  going to split out the ngspice settings because it will be
a bit cleaner and it will fix the immediate build issues.

Wayne

On 3/19/21 4:06 AM, Nick Østergaard wrote:
> I would be fine with permanently enabling the ngspice integration. It
> has historically not been that complicated to support, I mean build
> wise, and I don't think it makes a lot of difference for rebuilds, which
> is where it could be nice to disable some things, like scripting sometimes.
> 
> Speaking from experience on windows, linux and mac. At least I don't
> remember any issues with it on newer releases of ngspice, and if a
> problem crops of for some reason I am sure we can workaround it and
> Holger is very responsive on requests from us.
> 
> On Fri, 19 Mar 2021 at 04:14, Jon Evans  <mailto:j...@craftyjon.com>> wrote:
> 
> I agree with Seth.  The longer a feature is part of KiCad, the more
> people will refer to it in forum posts, tutorials, etc.   This
> feature has now existed for plenty long enough for people to expect
> it.  If there are no packaging reasons to do otherwise, I support it
> being included in all builds.
> 
> -Jon
> 
> On Thu, Mar 18, 2021 at 10:49 PM Seth Hillbrand  <mailto:s...@kipro-pcb.com>> wrote:
> 
> I agree that this is one area where we can improve the user
> experience.
> 
> By first-class, I mean only that it is an integral part of KiCad
> that we develop and support.  We are no longer in the testing
> phase where it would make sense to have a conditional compilation.
> 
> -Seth
> 
> On Thu, Mar 18, 2021 at 4:51 PM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> 
> You say it's first class but the spice gui needs alot of
> loving. The tool framework is also ducktaped poorly into it.
> 
> On Thu, Mar 18, 2021 at 7:14 PM Seth Hillbrand
> mailto:s...@kipro-pcb.com>> wrote:
> 
> Do we still need spice as a build option?  It would be
> nice to bring down the number of permutations out there
> and the SPICE simulator is really a first-class KiCad
> citizen nowadays.
> 
> -S
> 
> On Thu, Mar 18, 2021 at 4:04 PM Jon Evans
> mailto:j...@craftyjon.com>> wrote:
> 
> Saving in the project file is fine, I just mean if
> you split out NGSPICE_SIMULATOR_SETTINGS to a
> different file (not sim/ngspice.h) with no
> dependencies on ngspice itself, the settings class
> can be built without ngspice.
> 
> On Thu, Mar 18, 2021 at 6:57 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>>
> wrote:
> 
> I thought about that but in what context does a
> simulation make sense
> out side of a schematic or a netlist generated
> from a schematic?  I
> saved the ngspice simulator settings in the
> project file because that is
> the proper scope of the setting.  I really don't
> see a more logical
> place to save the setting.   I suppose I could
> split out the simulator
> settings code but it would be awkward at best.
> 
> On 3/18/21 6:42 PM, Jon Evans wrote:
> > Wayne, I haven't checked this code carefully
> but I'd recommend building
> > the settings always, and moving the #ifdef to
> a different level (i.e.
> > make the settings not depend on ngspice)
> >
> > That way if the same settings files are shared
> between a build with
> > ngspice and a build without, they won't get
> thrown away.
> >
> > On Thu, Mar 18, 2021 at 6:37 PM Wayne
> Stambaugh  <mailto:stambau...@gmail.com>
> 

Re: [Kicad-developers] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Wayne Stambaugh]

That's an equally valid solution.  Any of our package devs object to
this on the grounds that some platform doesn't support ngspice?

On 3/18/21 7:13 PM, Seth Hillbrand wrote:
> Do we still need spice as a build option?  It would be nice to bring
> down the number of permutations out there and the SPICE simulator is
> really a first-class KiCad citizen nowadays.
> 
> -S
> 
> On Thu, Mar 18, 2021 at 4:04 PM Jon Evans  <mailto:j...@craftyjon.com>> wrote:
> 
> Saving in the project file is fine, I just mean if you split out
> NGSPICE_SIMULATOR_SETTINGS to a different file (not sim/ngspice.h)
> with no dependencies on ngspice itself, the settings class can be
> built without ngspice.
> 
> On Thu, Mar 18, 2021 at 6:57 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> 
> I thought about that but in what context does a simulation make
> sense
> out side of a schematic or a netlist generated from a schematic?  I
> saved the ngspice simulator settings in the project file because
> that is
> the proper scope of the setting.  I really don't see a more logical
> place to save the setting.   I suppose I could split out the
> simulator
> settings code but it would be awkward at best.
> 
> On 3/18/21 6:42 PM, Jon Evans wrote:
> > Wayne, I haven't checked this code carefully but I'd recommend
> building
> > the settings always, and moving the #ifdef to a different
> level (i.e.
> > make the settings not depend on ngspice)
> >
> > That way if the same settings files are shared between a build
> with
> > ngspice and a build without, they won't get thrown away.
> >
> > On Thu, Mar 18, 2021 at 6:37 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
> wrote:
> >
> >     My bad.  I forgot the simulator was a build option so I
> will have to
> >     #ifdef the offending settings code.
> >
> >     - Wayne
> >
> >     On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> >     > I have disabled ngspice in cmake settings but in a
> recent commit by
> >     > Wayne #include , which in turn includes
> >     > ngspice/sharedspice.h, was added to schematic.cpp which
> makes
> >     > compilation fail apparently because I don't have ngspice
> at all.
> >     >
> >     > Eeli Kaikkonen
> >     >
> >     > ___
> >     > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     > Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>>
> >     > Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     > More help   : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> >     <https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>>
> >     >
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad

Re: [Kicad-developers] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Wayne Stambaugh]

That was the option I meant but it would mean orphaned project file
settings when the spice simulator isn't built.

On 3/18/21 7:03 PM, Jon Evans wrote:
> Saving in the project file is fine, I just mean if you split out
> NGSPICE_SIMULATOR_SETTINGS to a different file (not sim/ngspice.h) with
> no dependencies on ngspice itself, the settings class can be built
> without ngspice.
> 
> On Thu, Mar 18, 2021 at 6:57 PM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> I thought about that but in what context does a simulation make sense
> out side of a schematic or a netlist generated from a schematic?  I
> saved the ngspice simulator settings in the project file because that is
> the proper scope of the setting.  I really don't see a more logical
> place to save the setting.   I suppose I could split out the simulator
> settings code but it would be awkward at best.
> 
> On 3/18/21 6:42 PM, Jon Evans wrote:
> > Wayne, I haven't checked this code carefully but I'd recommend
> building
> > the settings always, and moving the #ifdef to a different level (i.e.
> > make the settings not depend on ngspice)
> >
> > That way if the same settings files are shared between a build with
> > ngspice and a build without, they won't get thrown away.
> >
> > On Thu, Mar 18, 2021 at 6:37 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
> >
> >     My bad.  I forgot the simulator was a build option so I will
> have to
> >     #ifdef the offending settings code.
> >
> >     - Wayne
> >
> >     On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> >     > I have disabled ngspice in cmake settings but in a recent
> commit by
> >     > Wayne #include , which in turn includes
> >     > ngspice/sharedspice.h, was added to schematic.cpp which makes
> >     > compilation fail apparently because I don't have ngspice at all.
> >     >
> >     > Eeli Kaikkonen
> >     >
> >     > ___
> >     > Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     > Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>>
> >     > Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     > More help   : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> >     <https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>>
> >     >
> >
> >     ___
> >     Mailing list: https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> >     <mailto:kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>
> >     <https://launchpad.net/~kicad-developers
> <https://launchpad.net/~kicad-developers>>
> >     More help   : https://help.launchpad.net/ListHelp
> <https://help.launchpad.net/ListHelp>
> >     <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] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Wayne Stambaugh]

I thought about that but in what context does a simulation make sense
out side of a schematic or a netlist generated from a schematic?  I
saved the ngspice simulator settings in the project file because that is
the proper scope of the setting.  I really don't see a more logical
place to save the setting.   I suppose I could split out the simulator
settings code but it would be awkward at best.

On 3/18/21 6:42 PM, Jon Evans wrote:
> Wayne, I haven't checked this code carefully but I'd recommend building
> the settings always, and moving the #ifdef to a different level (i.e.
> make the settings not depend on ngspice)
> 
> That way if the same settings files are shared between a build with
> ngspice and a build without, they won't get thrown away.
> 
> On Thu, Mar 18, 2021 at 6:37 PM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> My bad.  I forgot the simulator was a build option so I will have to
> #ifdef the offending settings code.
> 
> - Wayne
> 
> On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> > I have disabled ngspice in cmake settings but in a recent commit by
> > Wayne #include , which in turn includes
> > ngspice/sharedspice.h, was added to schematic.cpp which makes
> > compilation fail apparently because I don't have ngspice at all.
> >
> > Eeli Kaikkonen
> >
> > ___
> > 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>
> 

___
Mailing list: https://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] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Wayne Stambaugh]

My bad.  I forgot the simulator was a build option so I will have to
#ifdef the offending settings code.

- Wayne

On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> I have disabled ngspice in cmake settings but in a recent commit by
> Wayne #include , which in turn includes
> ngspice/sharedspice.h, was added to schematic.cpp which makes
> compilation fail apparently because I don't have ngspice at all.
> 
> Eeli Kaikkonen
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Packaging note: new data file

[Wayne Stambaugh]

Awesome work Jon.  Thanks.

 - Wayne

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

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

Re: [Kicad-developers] Launch Pad ???

[Wayne Stambaugh]

I already paired down the information on Launchpad to the minimum that
makes sense and turned off the bug tracker.  There is not much more I
can pair down that I'm aware of that would make a significant difference
but I'm open to suggestion.

Cheers,

Wayne

On 3/4/21 8:13 AM, Clemens Koller wrote:
> Is ist possible to remove the remaining information from launchpad and make 
> it clear that we moved?
> 
> Clemens
> 
> On 04/03/2021 13.44, Wayne Stambaugh wrote:
>> All KiCad development and bug tracking has been moved to GitLab.  Only
>> the mailing list hosting remains on Launchpad.
>>
>> - Wayne
>>
>> On 2/19/21 2:23 PM, Christopher Buckley wrote:
>>> Are you guys still using launchpad for bug reporting / tracking?
>>>
>>> Latest bug I've found there is for June 2020...
>>>
>>> Am searching through the inventory...
>>>
>>> C
>>>
>>> ___
>>> Mailing list: https://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] Launch Pad ???

[Wayne Stambaugh]

All KiCad development and bug tracking has been moved to GitLab.  Only
the mailing list hosting remains on Launchpad.

- Wayne

On 2/19/21 2:23 PM, Christopher Buckley wrote:
> Are you guys still using launchpad for bug reporting / tracking?
> 
> Latest bug I've found there is for June 2020...
> 
> Am searching through the inventory...
> 
> C
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Build error.

[Wayne Stambaugh]

Thanks!

On 2/27/21 8:54 AM, Jon Evans wrote:
> Should be fixed now.
> 
> On Sat, Feb 27, 2021 at 7:48 AM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> Looks like a commit in the last 24 hours broke KiCad builds with Python
> enabled.  Here is the build error on Linux using gcc 9.3.0.
> 
> In file included from
> /usr/include/x86_64-linux-gnu/c++/9/bits/c++allocator.h:33,
>                  from /usr/include/c++/9/bits/allocator.h:46,
>                  from /usr/include/c++/9/string:41,
>                  from /usr/include/c++/9/stdexcept:39,
>                  from
> 
> /home/wayne/build/kicad/trunk-debug-gtk3-phoenix-occt/pcbnew/pcbnew_wrap.cxx:3006:
> /usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void
> __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
> std::pair >; _Args = {const
> std::pair std::default_delete > >&}; _Tp =
> std::_Rb_tree_node
> > >]’:
> /usr/include/c++/9/bits/alloc_traits.h:482:2:   required from ‘static
> void std::allocator_traits
> >::construct(std::allocator_traits
> >::allocator_type&, _Up*, _Args&& ...) [with _Up = std::pair const, std::unique_ptr >; _Args = {const std::pair const, std::unique_ptr > >&};
> _Tp = std::_Rb_tree_node std::unique_ptr > >;
> std::allocator_traits >::allocator_type =
> std::allocator std::unique_ptr > > >]’
> /usr/include/c++/9/bits/stl_tree.h:614:32:   required from ‘void
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::_M_construct_node(std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Link_type, _Args&& ...) [with _Args = {const
> std::pair std::default_delete > >&}; _Key = ZONE*; _Val =
> std::pair >; _KeyOfValue =
> std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node
> > >*]’
> /usr/include/c++/9/bits/stl_tree.h:487:3:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Reuse_or_alloc_node::operator()(_Arg&&) [with _Arg =
> const std::pair >&; _Key =
> ZONE*; _Val = std::pair >;
> _KeyOfValue = std::_Select1st std::unique_ptr > >; _Compare = std::less; _Alloc =
> std::allocator > >;
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node
> > >*]’
> /usr/include/c++/9/bits/stl_tree.h:658:33:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_M_clone_node(std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Const_Link_type, _NodeGen&) [with _NodeGen =
> std::_Rb_tree
> >, std::_Select1st >
> >, std::less, std::allocator std::unique_ptr > > >::_Reuse_or_alloc_node; _Key = ZONE*;
> _Val = std::pair >; _KeyOfValue
> = std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node >
> >*; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::_Const_Link_type = const std::_Rb_tree_node const, std::unique_ptr > >*]’
> /usr/include/c++/9/bits/stl_tree.h:1875:13:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_M_copy(std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Const_Link_type, std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Base_ptr, _NodeGen&) [with _NodeGen =
> std::_Rb_tree
> >, std::_Select1st >
> >, std::less, std::allocator std::unique_ptr > > >::_Reuse_or_alloc_node; _Key = ZONE*;
> _Val = std::pair >; _KeyOfValue
> = std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node >
> >*; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::_Const_Link_type = const std::_Rb_tree_node const, std::unique_ptr > >*; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Base_ptr = std::_Rb_

[Kicad-developers] Build error.

[Wayne Stambaugh]

Looks like a commit in the last 24 hours broke KiCad builds with Python
enabled.  Here is the build error on Linux using gcc 9.3.0.

In file included from
/usr/include/x86_64-linux-gnu/c++/9/bits/c++allocator.h:33,
 from /usr/include/c++/9/bits/allocator.h:46,
 from /usr/include/c++/9/string:41,
 from /usr/include/c++/9/stdexcept:39,
 from
/home/wayne/build/kicad/trunk-debug-gtk3-phoenix-occt/pcbnew/pcbnew_wrap.cxx:3006:
/usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
std::pair >; _Args = {const
std::pair > >&}; _Tp =
std::_Rb_tree_node > >]’:
/usr/include/c++/9/bits/alloc_traits.h:482:2:   required from ‘static
void std::allocator_traits
>::construct(std::allocator_traits
>::allocator_type&, _Up*, _Args&& ...) [with _Up = std::pair >; _Args = {const std::pair > >&};
_Tp = std::_Rb_tree_node > >;
std::allocator_traits >::allocator_type =
std::allocator > > >]’
/usr/include/c++/9/bits/stl_tree.h:614:32:   required from ‘void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_construct_node(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_Link_type, _Args&& ...) [with _Args = {const
std::pair > >&}; _Key = ZONE*; _Val =
std::pair >; _KeyOfValue =
std::_Select1st > >;
_Compare = std::less; _Alloc = std::allocator > >; std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node > >*]’
/usr/include/c++/9/bits/stl_tree.h:487:3:   required from
‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_Reuse_or_alloc_node::operator()(_Arg&&) [with _Arg =
const std::pair >&; _Key =
ZONE*; _Val = std::pair >;
_KeyOfValue = std::_Select1st > >; _Compare = std::less; _Alloc =
std::allocator > >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node > >*]’
/usr/include/c++/9/bits/stl_tree.h:658:33:   required from
‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_M_clone_node(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_Const_Link_type, _NodeGen&) [with _NodeGen =
std::_Rb_tree
>, std::_Select1st >
>, std::less, std::allocator > > >::_Reuse_or_alloc_node; _Key = ZONE*;
_Val = std::pair >; _KeyOfValue
= std::_Select1st > >;
_Compare = std::less; _Alloc = std::allocator > >; std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node >
>*; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Const_Link_type = const std::_Rb_tree_node > >*]’
/usr/include/c++/9/bits/stl_tree.h:1875:13:   required from
‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_M_copy(std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_Const_Link_type, std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Base_ptr, _NodeGen&) [with _NodeGen =
std::_Rb_tree
>, std::_Select1st >
>, std::less, std::allocator > > >::_Reuse_or_alloc_node; _Key = ZONE*;
_Val = std::pair >; _KeyOfValue
= std::_Select1st > >;
_Compare = std::less; _Alloc = std::allocator > >; std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node >
>*; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Const_Link_type = const std::_Rb_tree_node > >*; std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Base_ptr = std::_Rb_tree_node_base*]’
/usr/include/c++/9/bits/stl_tree.h:901:15:   required from
‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>::_M_copy(const std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>&, _NodeGen&) [with _NodeGen = std::_Rb_tree >,
std::_Select1st > >,
std::less, std::allocator > > >::_Reuse_or_alloc_node; _Key = ZONE*;
_Val = std::pair >; _KeyOfValue
= std::_Select1st > >;
_Compare = std::less; _Alloc = std::allocator > >; std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node > >*]’
/usr/include/c++/9/bits/stl_tree.h:1783:16:   required from
‘std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::operator=(const std::_Rb_tree<_Key, _Val, _KeyOfValue,
_Compare, _Alloc>&) [with _Key = ZONE*; _Val = std::pair >; _KeyOfValue =
std::_Select1st > >;
_Compare = std::less; _Alloc = std::allocator > >]’
/usr/include/c++/9/bits/stl_map.h:100:11:   required from here
/usr/include/c++/9/ext/new_allocator.h:145:20: error: use of deleted
function ‘constexpr std::pair<_T1, _T2>::pair(const std::pair<_T1,
_T2>&) [with _T1 = ZONE* const; _T2 = std::unique_ptr]’
  145 |  noexcept(noexcept(::new((void *)__p)
  |^~
  146 |_Up(std::forward<_Args>(__args)...)))
  |~~~
In file included from /usr/include/c++/9/bits/stl_algobase.h:64,
 from /usr/include/c++/9/bits/char_traits.h:39,
 from 

Re: [Kicad-developers] Code execution context

[Wayne Stambaugh]

Any code contributed to KiCad would have to be release under the GPL3+
or compatible license to be accepted.  Linking to proprietary drivers is
not an issue since we already link to Windows and MacOS proprietrary
libraries in order to provide KiCad on those platforms.  We just cannot
ship those libraries.  Given that KiCad supports Linux, Windows, and
macOS, we would prefer to provide a comparable experience on all
supported platforms.

Cheers,

Wayne

On 2/25/21 9:45 AM, Jon Evans wrote:
> As long as the experience is the same on all platforms (Win, Mac, Linux)
> and KiCad does not require any proprietary libraries to compile, I think
> it is up to Wayne whether or not an optional dependency on a proprietary
> library on Windows is acceptable.
> 
> But, I would like to hear from Markus on the topic first -- if other
> software is successfully using websockets to provide a good interface to
> 3dconnexion hardware on Windows, maybe it is not as bad as you fear?
> 
> -Jon
> 
> On Thu, Feb 25, 2021 at 9:38 AM Mark Roszko  > wrote:
> 
> On another note, I personally am not a fan of websockets usage
> locally on Windows. In corporate environments there's going to be
> hell with security software interfering and in general it's fragile.
> 
> I personally would rather just link against the 3dconnexion library
> directly. We have the MSVC builds now, we can compile against MSVC
> built libraries no problem. MSYS2 builds would just remain without it.
> 
> But just my opinion on this.
> 
> On Thu, Feb 25, 2021 at 9:32 AM Jon Evans  > wrote:
> 
> That is a good point Mark, we could either have this behind a
> flag so that it only gets enabled/compiled with new-enough Boost
> versions, or investigate a different websockets library.
> 
> I'm not sure the overlap of 3dconnexion users and 18.04 users is
> large enough to rule that approach out, at least if there are no
> other issues with Beast.
> 
> -Jon
> 
> On Thu, Feb 25, 2021 at 9:23 AM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> 
> * Boost 1.65 being the version Ubuntu 18.04 LTS currently
> has and are committed to support until EOL.
> 
> On Thu, Feb 25, 2021 at 9:19 AM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> 
> Markus,
> 
> We currently require support for a minimum of boost 1.59
> due to Linux distros lagging behind. boost/beast is not
> a viable option as beast did not appear in boost until 1.66.
> 
> From some offhand sounding out we may be able to bump
> the minimum to 1.65 but that doesn't help :/
> 
> 
> Regards,
> Mark
> 
> On Thu, Feb 25, 2021 at 9:00 AM Jon Evans
> mailto:j...@craftyjon.com>> wrote:
> 
> Hello Markus,
> 
> This is exciting news, as some of our users are also
> big fans of 3dconnexion products[1]
> 
> Others have looked in to what it would take in the
> past, but there were some questions about the need
> for proprietary drivers on some platforms[2]
> 
> It sounds like this websocket interface is a new
> approach that doesn't require any additional
> libraries for KiCad to link against?
> Does the hardware use some other daemon process to
> bridge between the device driver and websockets?
> 
> As you may know, KiCad uses wxWidgets as a
> framework, so you probably want to plug in to the wx
> event loop on the main thread.
> There are some guidelines on this in their docs[3].
> 
> You probably want to check out
> ./common/view/wx_view_controls.cpp to see how
> existing input events are handled by the 2D canvases.
> I guess your new code would hook in here somewhere,
> and provide additional event handlers to manage the
> data from the 3D device.
> Your communication thread should be able to post
> wxWidgets events to the main thread and then we can
> consume them here.
> 
> By the way: although the wx docs use wxThread, I
> think this general concept should work with C++
> standard libraries threads just fine.
> The documentation for wxEvtHandler::QueueEvent may
> also be useful[4]
> 
> Hope this helps!
> 
> Best,
> Jon
> 

Re: [Kicad-developers] Question about symbol library updates

[Wayne Stambaugh]

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

Re: [Kicad-developers] Icon freeze

[Wayne Stambaugh]

String and icon freeze will happen at RC1.  We still have several
outstanding feature freeze exceptions that need to be merged so RC1 is
looking like the end of Q1 (March) at the earliest.

Cheers,

Wayne

On 2/6/21 8:07 AM, Константин Барановский wrote:
> Could we have an icon freeze for the 6.0 version along with the string
> freeze (or even the GUI freeze)?
> It would give a good chance to update the screenshots of the documentation.
> We could start a tradition to update doc's screenshots for every major
> version.
> What do you think?
> 
> ___
> Mailing list: https://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] *** SPAM *** Re: ngspice-34

[Wayne Stambaugh]

Holger,

You should use something like NGSPICE_PACKAGE_VERSION to avoid namespace
clashes with other header version definitions.  PACKAGE_VERSION seems
like it could be an issue.

Cheers,

Wayne


On 2/4/21 3:38 PM, Holger Vogt wrote:
> I prefer adding
> #define PACKAGE_VERSION "34+"
> to sharedspice.h.
> 
> sharespice.h has been and will always be there.
> In old ngspice releases PACKAGE_VERSION is not defined. But config.h is
> there, containing its PACKAGE_VERSION. In ngspice-34 unfortunately
> PACKAGE_VERSION will not be available. But the code snipped below
> starting at line 161 in  common/build_version.cpp (not tested) should
> just return "unknown". No user interaction is required. In ngspice-35
> PACKAGE_VERSION will be available in sharedspice.h.
> 
> #else
>     #include 
>     #ifdef PACKAGE_VERSION
>     aMsg << indent4 << "ngspice: " << PACKAGE_VERSION << eol;
>     #else
>     aMsg << indent4 << "ngspice: " << "unknown" << eol;
>     #endif
> #endif
> 
> The disadvantage of the compile time approach of course is that it would
> not follow a user who just upgrades (or downgrades?) ngspice.
> 
> 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] [kicad-eeschema] Vertical pins with horizontal texts

[Wayne Stambaugh]

Hi Johannes,

I should have made it clear that the feature freeze implies that the
file formats are frozen as well.  I'm not saying there would never be a
case where we wouldn't change it but the chances are extremely low.

Cheers,

Wayne

On 2/1/21 2:03 AM, Johannes Sprigode wrote:
> Hi Wayne,
> 
> appreciate your heads up.
> 
> Will restart with current file format.
> 
> Cheers
> 
> Johannes
> 
> On 1/02/21 1:52 am, Wayne Stambaugh wrote:
>> Hi Johannes,
>>
>> The new schematic and symbol file formats are frozen unless we find a
>> bug that needs fixed so you should be able to start working on this
>> again.  Please note that we are in feature freeze so this feature will
>> not be merged until V6 is branched and released and we open up V7
>> development.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/30/21 8:14 PM, Johannes Sprigode wrote:
>>> Hi Wayne et al,
>>>
>>> the new file format appears to be stable as of now.
>>>
>>> The format contains all required information to implement rotated texts.
>>>
>>> I am considering an implementation restart of my previous efforts.
>>>
>>> Are there any activities already underway?
>>>
>>> Cheers
>>>
>>> Johannes
>>>
>>>
>>> On 13/08/19 11:46 pm, Wayne Stambaugh wrote:
>>>> Hi Johannes,
>>>>
>>>> The the new file format work is in progress and should be done in a few
>>>> months.  The UI support for moving pin name and number text will happen
>>>> some time after that.  I cannot say when for sure as the new file
>>>> formats add a lot of new features which will require a significant
>>>> amount of UI work so it could be while.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 8/12/19 11:26 PM, Johannes Sprigode wrote:
>>>>> Howdy Wayne,
>>>>>
>>>>> no worries. Thanks for the heads up. I'm not surprised at all since this
>>>>> only makes sense to have.
>>>>>
>>>>> In the meantime I'll keep it up if viable as a local patch just for
>>>>> fun-kickers.
>>>>>
>>>>> Is that feature already progressing? If so, which tag?
>>>>>
>>>>> Cheers
>>>>>
>>>>> Johannes
>>>>>
>>>>> On 13/08/19 7:27 AM, Wayne Stambaugh wrote:
>>>>>> Johannes,
>>>>>>
>>>>>> Once the new schematic and symbol library file formats are complete, you
>>>>>> will be able orient pin number and name positions freely.  This is
>>>>>> planned for version 6 which is currently under development so no changes
>>>>>> will be made to the existing file format to support this.  Thank you for
>>>>>> offering to help but this already is planned.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>> On 7/15/19 7:18 AM, Johannes Sprigode wrote:
>>>>>>> Hello there,
>>>>>>>
>>>>>>> been using Kicad for a while and have not looked back at eagle except
>>>>>>> for project imports.
>>>>>>>
>>>>>>> However, I found all those vertical texts  in eeschema quite disruptive.
>>>>>>> So I've done something like in attached screen shot over the last couple
>>>>>>> of days working off of master under Linux.
>>>>>>>
>>>>>>> Would you guys be interest to implement this sort of feature? If so, I
>>>>>>> would follow through with the nitty gritties since the actual
>>>>>>> implications are ‘slightly’ more complex then just that.
>>>>>>>
>>>>>>> Who would be the best contact to discuss this?
>>>>>>>
>>>>>>> I’m quite happy to lay out an implementation scenario.
>>>>>>>
>>>>>>> As it stands this ‘add-in’ will not impact on already existing
>>>>>>> libraries. Going by what is in master there is no such feature except
>>>>>>> some decent groundwork to build upon.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Johannes
>>>>>>>
>>>>>>>
>>>>>>> ___

Re: [Kicad-developers] [kicad-eeschema] Vertical pins with horizontal texts

[Wayne Stambaugh]

Hi Johannes,

The new schematic and symbol file formats are frozen unless we find a
bug that needs fixed so you should be able to start working on this
again.  Please note that we are in feature freeze so this feature will
not be merged until V6 is branched and released and we open up V7
development.

Cheers,

Wayne

On 1/30/21 8:14 PM, Johannes Sprigode wrote:
> Hi Wayne et al,
> 
> the new file format appears to be stable as of now.
> 
> The format contains all required information to implement rotated texts.
> 
> I am considering an implementation restart of my previous efforts.
> 
> Are there any activities already underway?
> 
> Cheers
> 
> Johannes
> 
> 
> On 13/08/19 11:46 pm, Wayne Stambaugh wrote:
>> Hi Johannes,
>>
>> The the new file format work is in progress and should be done in a few
>> months.  The UI support for moving pin name and number text will happen
>> some time after that.  I cannot say when for sure as the new file
>> formats add a lot of new features which will require a significant
>> amount of UI work so it could be while.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 8/12/19 11:26 PM, Johannes Sprigode wrote:
>>> Howdy Wayne,
>>>
>>> no worries. Thanks for the heads up. I'm not surprised at all since this
>>> only makes sense to have.
>>>
>>> In the meantime I'll keep it up if viable as a local patch just for
>>> fun-kickers.
>>>
>>> Is that feature already progressing? If so, which tag?
>>>
>>> Cheers
>>>
>>> Johannes
>>>
>>> On 13/08/19 7:27 AM, Wayne Stambaugh wrote:
>>>> Johannes,
>>>>
>>>> Once the new schematic and symbol library file formats are complete, you
>>>> will be able orient pin number and name positions freely.  This is
>>>> planned for version 6 which is currently under development so no changes
>>>> will be made to the existing file format to support this.  Thank you for
>>>> offering to help but this already is planned.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 7/15/19 7:18 AM, Johannes Sprigode wrote:
>>>>> Hello there,
>>>>>
>>>>> been using Kicad for a while and have not looked back at eagle except
>>>>> for project imports.
>>>>>
>>>>> However, I found all those vertical texts  in eeschema quite disruptive.
>>>>> So I've done something like in attached screen shot over the last couple
>>>>> of days working off of master under Linux.
>>>>>
>>>>> Would you guys be interest to implement this sort of feature? If so, I
>>>>> would follow through with the nitty gritties since the actual
>>>>> implications are ‘slightly’ more complex then just that.
>>>>>
>>>>> Who would be the best contact to discuss this?
>>>>>
>>>>> I’m quite happy to lay out an implementation scenario.
>>>>>
>>>>> As it stands this ‘add-in’ will not impact on already existing
>>>>> libraries. Going by what is in master there is no such feature except
>>>>> some decent groundwork to build upon.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Johannes
>>>>>
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>> ___
>>>> Mailing list: https://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
> 



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

Re: [Kicad-developers] ngspice-34

[Wayne Stambaugh]

Holger,

Thanks for the fixes.  Hopefully our packagers can get this into as many
of our nightly builds as feasible.  I know there will likely be some
distro related packaging issues but we should be able to support a large
number of builds.

Cheers,

Wayne

On 1/30/21 10:10 AM, Holger Vogt wrote:
> ngspice-34 is available.
> 
> 
> Some of the recent issues (such as
> https://gitlab.com/kicad/code/kicad/-/issues/7180) have been fixed.
> 
> 
> 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] Questions to the QA code

[Wayne Stambaugh]

Hi Sywester,

Turtle mocks looks like a better fit than gMock/gTest since it's based
on Boost which is already a dependency.  At least it looks like the
project is still maintained.  I don't know how it compares feature wise
to gMock so there may some things missing but are they significant
enough to warrant using it is unknown.

Cheers,

Wayne

On 1/26/21 5:38 PM, Sylwester Kocjan wrote:
> Hello,
> 
> Here's a follow-up about mocks in the qa tests. I prepared example use
> of Turtle library. My observations below:
> - integrates easily with Boost.Test (HippoMocks didn't require any
> integration, gmock will be harder,
> https://gitlab.com/kicad/code/kicad/-/merge_requests/652/diffs?commit_id=5fa5d228204506de71b265594fdcba5740b43f3e)
> - looks similar in use to google mocks
> - it's maintained on GitHub: https://github.com/mat007/turtle
> - it forced me to create more mocks than HippoMocks and rework the code
> a bit
> (https://gitlab.com/kicad/code/kicad/-/merge_requests/652/diffs?commit_id=c5df86c208156facc66a95ef60bdeabb6e66efb5),
> so:
>   - may require more work to create/maintain tests
>   - but I believe that in exchange it will result in better quality (I
> found missing 'virtual' keyword before destructor of SCHEMATIC!)
> 
> Best regards,
> Sylwester
> 
> Dnia 21 stycznia 2021 16:38 Jeff Young  napisał(a):
> 
> Good point.  I have only used the Java one (which I guess is the
> original?).
> 
> Cheers,
> Jeff.
> 
> 
>> On 20 Jan 2021, at 21:18, Sylwester Kocjan
>> <s.koc...@o2.pl > wrote:
>>
>> Hi Jeff,
>>
>> Did you use https://github.com/tpounds/mockitopp or that one for
>> Java https://github.com/mockito/mockito ?
>> Mockitopp has it's last code update about ~1,5 year ago, so it
>> looks it has the same downside as HippoMocks.
>> There is also Mockpp, also not actively developed:
>> https://sourceforge.net/projects/mockpp/
>>
>> BR,
>> SK
>>
>> Dnia 17 stycznia 2021 16:45 Jeff Young
>> <j...@rokeby.ie >
>> napisał(a):
>>
>> I’ve used Mockito.  Can’t say I remember a thing about it,
>> though (which could be good?).
>>
>> Cheers,
>> Jeff.
>>
>>> On 17 Jan 2021, at 14:49, Sylwester Kocjan
>>> <s.koc...@o2.pl
>>> > wrote:
>>>
>>> Hello,
>>>
>>> On 17/01/2021 09:47, Alex wrote:
>>> > ...GTest, Doctest and Catch2, (...) they'll all get the job
>>> done
>>>
>>> They are all testing frameworks without mocking capability.
>>> We have already Boost.Test based tests and I find it
>>> unnecessary effort to migrate them, and alone
>>> they don't solve the problem.
>>>
>>>
>>> On 17/01/2021 09:47, Alex wrote:
>>> > I wasn't aware that GMock could operate separately from
>>> GTest, but if it can, that's pretty neat.
>>>
>>> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko
>>>   wrote:
>>> > You can also use gmock separately from gtest.
>>>
>>> Since some time gmock is a part of gtest. Any search results
>>> in the topic of gmock with another testing frameworks are
>>> quite old. I think there is a risk that it will not work.
>>>
>>>
>>> On 17/01/2021 09:47, Alex wrote:
>>> > Catch is a single header
>>>
>>> I was instructed to avoid introducing new dependencies, hence
>>> my initial choice of single-header HippoMocks:
>>>
>>> https://gitlab.com/kicad/code/kicad/-/issues/4446#note_445185505
>>>
>>> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand
>>>   wrote:
>>> > The downside of HippoMocks from what I can gather is that
>>> the project appears abandoned.
>>>
>>> Sadly, this is true. There are also other choices, but I
>>> don't have any hands-on experience with them and I don't know
>>> which one to choose:
>>> - http://turtle.sourceforge.net/
>>> - https://github.com/tpounds/mockitopp
>>> - https://github.com/rollbear/trompeloeil
>>>
>>> Best regards,
>>> Sylwester
>>>
>>>
>>> On 17/01/2021 09:47, Alex wrote:
 I've used GTest, Doctest and Catch2, and they'll all get the
 job done; Doctest is definitely the fastest to compile, but
 also has the least of features; Catch and GTest have the
 most features.

 I wasn't aware that GMock could operate separately from
 GTest, but if it can, that's pretty neat.

 I believe Doctest and Catch both are single header - I know
 at least Catch is a single header; but I think it makes
 sense to use a git submodule in this case.


 

Re: [Kicad-developers] Origin Transforms for the Footprint Editor

[Wayne Stambaugh]

Hi Reece,

We are officially in feature freeze so this is going to have to wait
until V7.  I would rather not add another exception to the freeze list
as we are deeper into the freeze than I would like to be and still have
outstanding features to commit.

Cheers,

Wayne

On 12/30/20 11:53 PM, Reece R. Pollack wrote:
> I finally have some time to work on adding origin transforms to the
> footprint editor. I have a couple of questions:
> 
> 1) Is the Developers mailing list still working? I haven't gotten
> anything since Dec 26th.
> 
> 2) Is the v6.0 release past string freeze, or should I push to get this
> done quickly? It looks like all that's lacking is the preference settings.
> 
> 3) I'm thinking the preference settings dialog panel will give the
> choice of measuring from the "Anchor" or the "Grid" origins, as the
> concept of an "Aux" origin doesn't make sense here. Does it even make
> sense to offer a choice of display origins here?
> 
> -Reece
> 
> ___
> Mailing list: https://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

[Wayne Stambaugh]

On 12/23/20 9:38 AM, Steven A. Falco wrote:
> 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.

Well this is unfortunate.  Next time we need to do a better job of
allowing everyone to respond before we tag all of the other repos to
make sure there are no outstanding issues.  I think this is the first
time this has happened so I'm not going to over react a propose new
policies.

Wayne

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

[Wayne Stambaugh]

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.

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

Re: [Kicad-developers] 5.1.9 tagged for release

[Wayne Stambaugh]

I'm not opposed to a Christmas special if we can get most the packages
uploaded to the website by Thursday.  I have the announcement ready to
go so it's a simple commit from my end.  If that's not possible, a New
Year special should be doable.

On 12/22/20 5:04 PM, Jon Evans wrote:
> The KiCad Christmas special?
> 
> On Tue, Dec 22, 2020 at 5:02 PM Nick Østergaard  <mailto:oe.n...@gmail.com>> wrote:
> 
> I don't think we need that long. Everything seems to be tagged. I have
> triggered the windows build and it should just be a simple pkgver bump
> for macos and ubuntu ppa as well.
> 
> 
>     On Tue, 22 Dec 2020 at 21:14, Wayne Stambaugh  <mailto:stambau...@gmail.com>> 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.
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> <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] 5.1.9 tagged for release

[Wayne Stambaugh]

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.

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

[Kicad-developers] Stable release 5.1.8 tagged.

[Wayne Stambaugh]

I just tagged the 5.1 branch for the 5.1.8 stable release.  Please tag
any remaining repos as required so we can get the packages build and
uploaded.  I would like to make the release announcement next Wednesday.
 Is that enough time for everyone?  Thanks again to everyone who made
this release 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

Re: [Kicad-developers] New lead developer announcement.

[Wayne Stambaugh]

I can add a forum post when I get a chance.  I'm assuming they both are
on the forum.  We haven't really used the blog for new lead developer
announcements in the past but I'm not opposed to it.

On 10/7/20 9:28 AM, Chris Gammell wrote:
> Congrats, that's awesome! Wayne, can you post on the main site (blog) or
> the forum as well so we can spread the word?
> 
> On Wed, Oct 7, 2020 at 8:23 AM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
> I am happy to announce that Mark Roszko and Thomas Pointhuber have
> accepted invitations to the KiCad lead development team.  Mark and
> Thomas have be long time contributors to the KiCad project and I look
> forward to their contributions as lead developers.  Please join me in
> congratulating them in their new roles.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Kicad-developers] New lead developer announcement.

[Wayne Stambaugh]

I am happy to announce that Mark Roszko and Thomas Pointhuber have
accepted invitations to the KiCad lead development team.  Mark and
Thomas have be long time contributors to the KiCad project and I look
forward to their contributions as lead developers.  Please join me in
congratulating them in their new roles.

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

Re: [Kicad-developers] Version 6 feature freeze.

[Wayne Stambaugh]

Hi Pedro,

Thank you for attending the meeting.

The file format will not be officially frozen until V6 is released.
There is always the possibility there is a bug we haven't found yet that
could change the file format.  There is also one feature on the
exception list (sheet page numbering) that will change the schematic
file format.  Unless there are any bugs, the symbol library file format
should not change.

Cheers,

Wayne

On 10/3/20 1:31 PM, Pedro Martin wrote:
> Hi Wayne,
> 
> Thank you and all the team for the Kicon meeting today.
> 
> My question,
> Is the file format for V6 frozen too?
> 
> I want to start working with V5.99 for real work. I know the risks, but
> the risks are higher if the file format may be changed in a near future.
> I mean, I want ot be sure that the files will be opened with any V6 update.
> 
> Thanks.
> Pedro.
> 
> El 3/10/20 a las 18:32, Wayne Stambaugh escribió:
>> Hi Marco,
>>
>> On 10/3/20 11:55 AM, Marco Ciampa wrote:
>>> On Fri, Oct 02, 2020 at 06:46:05PM -0400, Wayne Stambaugh wrote:
>>>> As of now, the development branch of KiCad is closed for new feature
>>>> merges except for the items on the exception list.  A new feature freeze
>>>> exception tag has been created to tag existing merge requests that fall
>>>> into the exception category.  All new feature merge requests will be
>>>> pushed back until the main repo is opened for version 7 development.
>>>> The focus will now be on getting ready to release version 6 early in
>>>> 2021.  Thank you to everyone who made this possible.
>>> Hi Wayne,
>>> when do you think will occur the creation of a 6.0 branch?
>> Not until -rc1 is released which hopefully will be early in January
>> 2021.  I want the dev team to stay focused on getting V6 out before we
>> open the repo for V7 features.
>>
>> Cheers,
>>
>> Wayne
>>
>>> --
>>>
>>> Saluton,
>>> Marco Ciampa
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Wayne Stambaugh]

Hi Marco,

On 10/3/20 11:55 AM, Marco Ciampa wrote:
> On Fri, Oct 02, 2020 at 06:46:05PM -0400, Wayne Stambaugh wrote:
>> As of now, the development branch of KiCad is closed for new feature
>> merges except for the items on the exception list.  A new feature freeze
>> exception tag has been created to tag existing merge requests that fall
>> into the exception category.  All new feature merge requests will be
>> pushed back until the main repo is opened for version 7 development.
>> The focus will now be on getting ready to release version 6 early in
>> 2021.  Thank you to everyone who made this possible.
> 
> Hi Wayne,
> when do you think will occur the creation of a 6.0 branch?

Not until -rc1 is released which hopefully will be early in January
2021.  I want the dev team to stay focused on getting V6 out before we
open the repo for V7 features.

Cheers,

Wayne

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

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

[Kicad-developers] Version 6 feature freeze.

[Wayne Stambaugh]

As of now, the development branch of KiCad is closed for new feature
merges except for the items on the exception list.  A new feature freeze
exception tag has been created to tag existing merge requests that fall
into the exception category.  All new feature merge requests will be
pushed back until the main repo is opened for version 7 development.
The focus will now be on getting ready to release version 6 early in
2021.  Thank you to everyone 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