Re: [PRQ#46166] Deletion Request for gnuradio-maint38-git

[Nick Østergaard]

Hi

I am not sure that is fair as such, people could be using it for legacy oot
modules, and there is someone trying it out at least two weeks ago, see
https://github.com/gnuradio/gnuradio/issues/6762

I must admit, that I have not touched it in a while.

Nick

On Sun, 13 Aug 2023 at 01:35,  wrote:

> MarsSeed [1] filed a deletion request for gnuradio-maint38-git [2]:
>
> gnuradio 3.8 is not maintained since
> 2022-03 (last release 2022-01). [a]
>
> Nothing depends on this VCS package.
>
> I recommend deletion.
>
> [a]: https://github.com/gnuradio/gnuradio/commits/maint-3.8
>
> [1] https://aur.archlinux.org/account/MarsSeed/
> [2] https://aur.archlinux.org/pkgbase/gnuradio-maint38-git/

Re: [PRQ#46166] Deletion Request for gnuradio-maint38-git

[Nick Østergaard]

Yeah, I agree.

On Mon, 4 Sept 2023, 15:16 Marcell Meszaros, 
wrote:

> Upstream stated they have no intention or capacity to maintain the legacy
> gnuradio 3.8 branch.
>
> This git package does not provide 'gnuradio38' [a], so it has no
> dependents, only the latter does.
>
> But both this and that package fails to build.
>
> The few dependents of 'gnuradio38' are all dead and fail to build as well,
> or some of them actually have upstream updates or third-party forks that
> work with gnuradio 3.10.
>
> So keeping this package is completely superfluous in my view.
>
> [a]: https://aur.archlinux.org/packages/gnuradio38?all_reqs=1#pkgreqs
>
>
> On 13 August 2023 06:46:05 GMT+02:00, "Nick Østergaard" 
> wrote:
>
>> Hi
>>
>> I am not sure that is fair as such, people could be using it for legacy
>> oot modules, and there is someone trying it out at least two weeks ago, see
>> https://github.com/gnuradio/gnuradio/issues/6762
>>
>> I must admit, that I have not touched it in a while.
>>
>> Nick
>>
>> On Sun, 13 Aug 2023 at 01:35,  wrote:
>>
>>> MarsSeed [1] filed a deletion request for gnuradio-maint38-git [2]:
>>>
>>> gnuradio 3.8 is not maintained since
>>> 2022-03 (last release 2022-01). [a]
>>>
>>> Nothing depends on this VCS package.
>>>
>>> I recommend deletion.
>>>
>>> [a]: https://github.com/gnuradio/gnuradio/commits/maint-3.8
>>>
>>> [1] https://aur.archlinux.org/account/MarsSeed/
>>> [2] https://aur.archlinux.org/pkgbase/gnuradio-maint38-git/
>>
>>

Re: [kicad] Any thoughts on Fedora bug 2169876?

[Nick Østergaard]

Maybe try to move the configs in the home dir?

On Wed, 15 Feb 2023, 18:00 Jon Evans,  wrote:

> We can start by asking the user to type "bt" in the gdb prompt after they
> get the crash, which will give us a clue (assuming the Fedora packages are
> compiled with debug symbols)
>
> Your other suggestions are good ones.
>
> -Jon
>
> On Wed, Feb 15, 2023 at 11:52 AM Steven A. Falco 
> wrote:
>
>> A user has reported a bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2169876
>>
>> I'm at a bit of a loss, because there are no error messages yet.  I've
>> made some suggestions of things to try, but if any devs have other
>> thoughts, I'll relay them to the user.
>>
>> Steve
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "KiCad Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to devlist+unsubscr...@kicad.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/kicad.org/d/msgid/devlist/390352ec-e5e1-c0a6-f65f-9fcddaf586d4%40gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "KiCad Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to devlist+unsubscr...@kicad.org.
> To view this discussion on the web visit
> https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCCcdfLgeN-a2Lt8kEK_gLz6j%3DNk7t7PgA2DPBQZPOTWAQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to devlist+unsubscr...@kicad.org.
To view this discussion on the web visit 
https://groups.google.com/a/kicad.org/d/msgid/devlist/CAOuK9LjS4Q1rb%2BmhYBbLnPU-NrB0KbAYDc_7ZW%3Dc6jZ-Q3xnSQ%40mail.gmail.com.

Re: [aur-requests] [PRQ#35805] Deletion Request for tio-git

[Nick Østergaard via aur-requests]

I don't think this needs to be deleted. Yes, you started to make
many releases with is good, but I still think there is a place for
this package as a convenience.

1.40 released this 7 days ago · 13 commits to master since this release

local/tio-git 1.40.r13.g941e8d5-1

On Fri, 24 Jun 2022 at 01:39,  wrote:
>
> lundmar [1] filed a deletion request for tio-git [2]:
>
> I don't think a git version is needed as tio is quite often updated
> with official releases.
>
> [1] https://aur.archlinux.org/account/lundmar/
> [2] https://aur.archlinux.org/pkgbase/tio-git/

Re: [Kicad-developers] Symbol Server for Windows devs

[Nick Østergaard]

Cool. Great work Mark :)

On Thu, 31 Mar 2022, 04.53 Mark Roszko,  wrote:

> Three symbol stores are now available at https://symbols.kicad.org for
> Windows developers/users to troubleshoot crashes.
>
> These stores are automatically updated on nightly builds and stable
> releases.
> The nightly and testing symbols are only kept for 30 days however to
> conserve disk space.
>
> --
> 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

Re: [Kicad-developers] 6.0.2 tagged.

[Nick Østergaard]

You need to use the package target when buildign the doc tar

On Fri, 11 Feb 2022, 16.15 Jon Evans,  wrote:

> @seth - I think the docs need to be re-packed in the manner Christoph
> says, IIRC that is a requirement for the Mac packaging.
>
> On Fri, Feb 11, 2022 at 10:09 AM Christoph Moench-Tegeder <
> c...@burggraben.net> wrote:
>
>> Hi,
>>
>> ## Wayne Stambaugh (stambau...@gmail.com):
>>
>> > 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.
>>
>> That docs archive... Previously (until and including 6.0.1), that
>> archive had been breated with kicad-doc-$version as the top level
>> directory, but with 6.0.2 the top level directory is "share".
>> In practical terms:
>>
>> cmt@elch:Sources$ tar tzf kicad-doc-6.0.1.tar.gz | sort | head -5
>> kicad-doc-6.0.1/share/
>> kicad-doc-6.0.1/share/doc/
>> kicad-doc-6.0.1/share/doc/kicad/
>> kicad-doc-6.0.1/share/doc/kicad/help/
>> kicad-doc-6.0.1/share/doc/kicad/help/ca/
>>
>> cmt@elch:Sources$ tar tzf kicad-doc-6.0.2.tar.gz | sort | head -5
>> share/
>> share/doc/
>> share/doc/kicad/
>> share/doc/kicad/help/
>> share/doc/kicad/help/ca/
>>
>> Is that meant to stay this way in 6.0.2? It's easy to handle in packaging
>> either way round, but if you plan to reroll the tarball, I'll wait for
>> the new package (and the new checksums) before pushing.
>>
>> Regards,
>> Christoph
>>
>> --
>> Spare Space
>>
>> ___
>> Mailing list: https://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] V6 documentation

[Nick Østergaard]

Hi Franck,

This should be  superceeded by:
https://dev-docs.kicad.org/en/file-formats/

Nick

On Wed, 19 Jan 2022 at 19:41, Franck Bourdonnec  wrote:
>
>
> About doc, this one seems good but bazaar, no revision, no datestamp ?
>
> Is it maintained ?
>
>
> bazaar.launchpad.net/~stambaughw/kicad/doc-read-only/download/head:/1115%4016bec504-3128-0410-b3e8-8e38c2123bca:trunk%252Fkicad-doc%252Fdoc%252Fhelp%252Ffile_formats%252Ffile_formats.pdf/file_formats.pdf
>
>
> ___
> Mailing list: https://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] sch.py

[Nick Østergaard]

Hi Levente,

Is this the file you are looking for?

https://gitlab.com/kicad/libraries/kicad-library-utils/-/blob/master/.v5_schlib/schlib.py

Nick

On Mon, 17 Jan 2022 at 00:51, Levente  wrote:
>
> Hello devs,
>
>
>
> I miss the sch.py from kicad-library-utils for v6, and I thought I write
> it myself. Do I miss something and someone already working on the
> library? Are there any alternative way to parse a v6 schematic in python?
>
>
>
> Thanks,
> Lev
>
>
> --
> Levente Kovacs
> Senior Electronic Engineer
>
> W: http://levente.logonex.eu
>
> ___
> Mailing list: https://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.0 build flags

[Nick Østergaard]

Having the unused parameters is no harm, it will only generate a
warning at configure time.

The KICAD_PCM flag already defaults to ON, but I guess it should just
be removed as an option?  Are there any reason to keep it as a toggle
for v6+?

I am not aware of anything new flags for features in v7.

On Fri, 24 Dec 2021 at 18:21, Steven A. Falco  wrote:
>
> I looked at CMakeLists.txt, and it appears that some of the old 5.x build 
> flags have been removed, and some new flags have been added.
>
> In particular, the following scripting flags are gone (only 
> KICAD_SCRIPTING_WXPYTHON remains):
>
> KICAD_SCRIPTING
> KICAD_SCRIPTING_ACTION_MENU
> KICAD_SCRIPTING_MODULES
> KICAD_SCRIPTING_PYTHON3
> KICAD_SCRIPTING_WXPYTHON_PHOENIX
>
> These flags still appear in files like .gitlab/Windows-CI.yml and should be 
> removed.  They should also be removed from the Fedora nightly builds, and 
> probably from other builds, as well.
>
> I can remove the above flags from the Fedora nightly builds, and I can create 
> an MR for the .gitlab files, if desired.  Please let me know if you want that 
> MR.
>
> There are a few new flags that I think should be added to the Fedora builds 
> for clarity, even though we don't change the defaults.  In particular, I 
> propose to add:
>
> KICAD_PCM=ON
> KICAD_USE_EGL=OFF
>
> Are there any other new flags that I should add?  (I could add every single 
> flag from CMakeLists.txt, but most seem related to debug, and would just 
> clutter the cmake command.)
>
> Steve
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] Test email - For some reason I'm no longer getting launchpad emails

[Nick Østergaard]

The list received it at least ..

On Thu, 4 Nov 2021, 20.26 Steven A. Falco,  wrote:

> This is a test email - please ignore.
>
> For some reason, the last email I received from launchpad was on
> 2021-10-08 at the time the "Launchpad bug tracker closure" email went out.
>
> Thus, I missed the emails about domain name changes, the 5.1.11 release,
> etc.
>
> I've tried to reset my email address in launchpad.  Let's see if that
> helped.  Hopefully, launchpad will send me a copy of this email.
>
> Sorry for the test.
>
> Steve
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] Update to Footprint/Symbol paths

[Nick Østergaard]

What about versioning these folders? Or is that handled by the packager on
a given platform with a build arg?

On Mon, 18 Oct 2021 at 01:32, Seth Hillbrand  wrote:

> Hi Folks-
>
> There's a small change brewing to where the default symbol/footprint
> libraries are installed.
>
> Previously, KiCad had default paths for schematic symbols in
> `/usr/share/kicad/library` and for footprints in
> `/usr/share/kicad/modules/` (Windows users found these at
> %{KICAD_PROGRAM}\share\kicad\library and
> %{KICAD_PROGRAM}\share\kicad\modules)
>
> Starting with tomorrow's nightly build, we will be installing these to
> `/usr/share/kicad/symbols` for schematic symbols and
> `/usr/share/kicad/footprints` for layout footprints.
>
> I know what you are thinking.  "Why would you guys decide to name the
> directories for what is actually in them?  Won't that make it easier for
> new users to find things?"  Well, maybe...  The original directory names
> have a lot of history and were descriptive for the original intent.  We've
> standardized our nomenclature throughout KiCad in advance of v6 and the
> directory structure was one of the last holdouts.
>
> Hopefully the transition will be smooth.  If you compile locally, you will
> need to update your locally installed libraries or set the PATHs variable
> to point to the libraries (footprints and symbols) you currently have
> installed.  Users who run from one of the packages should find their
> changes to be transparent.
>
> Seth
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@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] Warning about potentially malicious software

[Nick Østergaard]

Wouldn't be appropriate to add the post as this to the blog on kicad.org as
well?

On Tue, 19 Oct 2021 at 22:30, Seth Hillbrand  wrote:

> Hi Folks-
>
> As you know, the original KiCad domain name (kicad-pcb.org) was recently
> sold.  This happened without notification to the KiCad Project or members
> of the KiCad Development Team. This sale was unexpected and may pose a risk
> to KiCad users. The new owners may simply post advertisements or
> (worst-case scenario) they may host malicious versions of the KiCad
> software for download.
>
> # How did this happen?
>
> The domain name was originally registered in 2012 by the then project lead
> Dick Hollenbeck. As KiCad did not have a formal entity at the time, he
> registered it in his own name through his company SoftPLC. When the KiCad
> Project formally became registered under the Linux Foundation, we attempted
> to secure the rights to the original domain name from Dick without success.
>
> In the meantime, Digikey Corporation purchased the kicad.org domain name
> from squatters and donated it to the KiCad Project.  This is now our
> current domain name.
>
> # What is the KiCad Project doing now to protect its users?
>
> We are removing all links to the old domain name in the software for
> version 5.1.11 as well as 6.0. We are also contacting various sites that
> host content related to KiCad to update their links.
>
> # What can I do?
>
> Please do not contact Dick about this. He cannot undo the damage at this
> point.
>
> If you host KiCad videos on YouTube or content on a blog that has links to
> kicad-pcb.org, please update them to kicad.org as soon as possible. This
> will decrease the visibility of the old domain-name and limit the damage.
> You can also contact tech sites that post reviews of KiCad or otherwise
> have links to the old site and ask them to update their links.
>
> When installing KiCad, please always verify the installation signature.
> Starting with KiCad version 5.99, all installs are signed by KiCad Services
> Corporation.
>
> # What is KiCad doing to prevent this in the future?
>
> The current kicad.org domain name is not under control of a single
> person. We have built in safeguards to our transfer process. Additionally,
> all KiCad trademarks are registered to the Linux Foundation for the sole
> purpose of advancing open-source EDA software.
>
> We regret that this was done to the KiCad project and its users.
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@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] Issue with autoplacing of designator and name in schematic

[Nick Østergaard]

Hi Bastian,

You should probably report it as an issue on
https://gitlab.com/kicad/code/kicad/-/issues

There you can also add a screenshot to help explain what you are
seeing. Remember to add the version information.

Nick

On Fri, 8 Oct 2021 at 22:08, Bastian  wrote:
>
> Hi
>
> Placing a new IC component on the schematic moves the designator and 
> component name ontop in the center. Always colliding with VCC pins.
> Running autoplace puts the values below the component colliding with GND pins.
>
> The components come with a point where the designator and name can be placed 
> without interfering with pins. But it is never put there.
>
> Is this something I can have a look at or is somebody already working on that?
>
> Basti
> ___
> Mailing list: https://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

[Nick Østergaard]

This is the same we saw on the windows build earlier. FWIW.

On Tue, 14 Sept 2021 at 17:18, Steven A. Falco  wrote:
>
> Thanks, Wayne - that is a clear improvement.
>
> Steve
>
> On 9/14/21 11:13, Wayne Stambaugh wrote:
> > On 9/14/21 10:05 AM, Steven A. Falco wrote:
> >> Thanks, Jeff.  It looks like "make clean" does the right thing - it
> >> removes "include/page_layout_reader_lexer.h", among others.
> >>
> >> I was used to just blowing away the build directory to clean up, but now
> >> I know that that is not sufficient for KiCAD, because it writes
> >> generated files into its source area.
> >
> > In master, the generated files are written to the build directory.  This
> > only applies to the 5.1 branch.
> >
> >>
> >> And of course there is always "git clean -fdx" when you really want a
> >> pristine tree. :-)
> >>
> >>  Steve
> >>
> >> On 9/14/21 09:52, Jeff Young wrote:
> >>> This normally happens when you’re building both 5.1 and 5.99 in a
> >>> single tree.  I have to delete them a lot as I do that.
> >>>
> >>> But I haven’t a clue how it’s /supposed/ to be.  When I have a working
> >>> build (even if it’s clunky), I tend to be very hesitant to change
> >>> /anything/. ;)
> >>>
>  On 14 Sep 2021, at 14:27, Steven A. Falco   > 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
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Nick Østergaard]

Maybe you should post that to the github issue?

On Wed, 4 Aug 2021 at 17:41, Steven A. Falco  wrote:
>
> This has now been corrected in Fedora rawhide as described in [1], which let 
> me close the associated KiCAD FTBFS in [2].
>
> I don't know if this issue is unique to Fedora or if others will see the same 
> problem.  I guess that depends on whether/when the upstream python3-wxpython4 
> project corrects the problem.  I've attached the patch to python3-wxpython4 
> in case it is useful to anyone.
>
> Steve
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1990001
>
> On 7/30/21 11:39 AM, Steven A. Falco wrote:
> > I decided to file a bug on Fedora [1].
> >
> > I also saw a similar issue on the wxWidgets site and added a comment [2].
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
> > [2] https://github.com/wxWidgets/Phoenix/issues/1963
> >
> >  Steve
> >
> > On 7/30/21 10:58 AM, Steven A. Falco wrote:
> >> I just updated my rawhide VM, and you are quite correct:
> >>
> >> rawhide$ python -c "import wx;print(wx.version())"
> >> Traceback (most recent call last):
> >>File "", line 1, in 
> >>File "/usr/lib64/python3.10/site-packages/wx/__init__.py", line 17, in 
> >> 
> >>  from wx.core import *
> >>File "/usr/lib64/python3.10/site-packages/wx/core.py", line 12, in 
> >> 
> >>  from ._core import *
> >> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 261: 
> >> invalid continuation byte
> >> free(): invalid size
> >> Aborted (core dumped)
> >>
> >> I'll post on the Fedora mailing list and see where they want the bug filed.
> >>
> >>  Steve
> >>
> >>
> >> On 7/30/21 10:48 AM, Ian McInerney wrote:
> >>> Steve,
> >>>
> >>> I saw that failure last night also, and I think it may be a wxPython 
> >>> problem with Python 3.10. I don't hav ea Rawhide VM available at the 
> >>> moment, but what we should do is try the following:
> >>>
> >>> 1) Install Python 3.10 and python-wxpython4 in a Rawhide install
> >>> 2) Run python -c "import wx;print(wx.version())"
> >>> 3) See if it errors
> >>>
> >>> My guess is there will be an error in step 2, in which case we need to 
> >>> push it upstream to wxPython and the Fedora Python maintainers.
> >>>
> >>> -Ian
> >>>
> >>> On Fri, Jul 30, 2021 at 3:26 PM Steven A. Falco  >>> > wrote:
> >>>
> >>> The nightly build failed with an error when building KiCAD for Fedora 
> >>> Rawhide, when discovering the python interpreter.  I haven't tracked down 
> >>> the root cause yet, but below are the error messages in case anyone has 
> >>> an idea on what can cause this.  Fedora has recently upgraded the python 
> >>> version, so perhaps that is the cause.
> >>>
> >>>  Steve
> >>>
> >>> -- Found PythonInterp: /usr/bin/python3 (found version "3.10")
> >>> -- Found PythonLibs: /usr/lib64/libpython3.10.so 
> >>> 
> >>> -- Performing Test HAS_FLTO
> >>> -- Performing Test HAS_FLTO - Success
> >>> -- Found PythonInterp: /usr/bin/python3 (found suitable version 
> >>> "3.10", minimum required is "3.6")
> >>> -- Check for installed Python Interpreter -- found
> >>> :1: DeprecationWarning: The distutils package is deprecated 
> >>> and slated for removal in Python 3.12. Use setuptools or check PEP 632 
> >>> for potential alternatives
> >>> :1: DeprecationWarning: The distutils.sysconfig module is 
> >>> deprecated, use sysconfig instead
> >>> -- Python module install path: lib/python3.10/site-packages
> >>> -- Found PythonLibs: /usr/lib64/libpython3.10.so 
> >>>  (found suitable version "3.10.0b4", minimum 
> >>> required is "3.6")
> >>> Traceback (most recent call last):
> >>> File "", line 1, in 
> >>> File "/usr/lib64/python3.10/site-packages/wx/__init__.py", line 
> >>> 17, in 
> >>>   from wx.core import *
> >>> File "/usr/lib64/python3.10/site-packages/wx/core.py", line 12, 
> >>> in 
> >>>   from ._core import *
> >>> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 
> >>> 261: invalid continuation byte
> >>> free(): invalid size
> >>> CMake Error at CMakeModules/FindwxPython.cmake:66 (message):
> >>> Unknown wxPython/Phoenix version string:
> >>> Call Stack (most recent call first):
> >>> CMakeLists.txt:835 (find_package)
> >>> -- Configuring incomplete, errors occurred!
> >>> See also 
> >>> "/builddir/build/BUILD/kicad-baf67986957afc3b4c47ed6f3def0ba3af76d2e9/redhat-linux-build/CMakeFiles/CMakeOutput.log".
> >>> See also 
> >>> "/builddir/build/BUILD/kicad-baf67986957afc3b4c47ed6f3def0ba3af76d2e9/redhat-linux-build/CMakeFiles/CMakeError.log".
> >>> error: Bad exit status from /var/tmp/rpm-tmp.R634pK (%build)
> >>> RPM build errors:
> >>>   line 57: It's not recommended to use '>' in Obsoletes: 

Re: [Kicad-developers] Can't compile latest kicad

[Nick Østergaard]

What commit are you on?

On Fri, 16 Jul 2021 at 10:39, Alex Vidrasan  wrote:
>
> Hi,
>
> I tried to submit a bug report the usual way but gitlab killed my account and 
> won't let me register a new one for some reason.
>
> The issue is I can't compile the latest kicad from a freshly cloned 
> repository. Error below:
>
> Scanning dependencies of target kimath
> [  1%] Building CXX object 
> thirdparty/potrace/CMakeFiles/potrace.dir/src/decompose.cpp.o
> [  1%] Building CXX object 
> libs/kimath/CMakeFiles/kimath.dir/src/bezier_curves.cpp.o
> [  2%] Building CXX object 
> thirdparty/potrace/CMakeFiles/potrace.dir/src/greymap.cpp.o
> [  2%] Building CXX object 
> thirdparty/potrace/CMakeFiles/potrace.dir/src/potracelib.cpp.o
> [  2%] Building CXX object 
> thirdparty/potrace/CMakeFiles/potrace.dir/src/render.cpp.o
> [  2%] Building CXX object 
> thirdparty/potrace/CMakeFiles/potrace.dir/src/trace.cpp.o
> [  2%] Building CXX object 
> libs/kimath/CMakeFiles/kimath.dir/src/convert_basic_shapes_to_polygon.cpp.o
> [  2%] Linking CXX static library libpotrace.a
> [  2%] Built target potrace
> Scanning dependencies of target kiplatform
> [  2%] Building CXX object 
> libs/kiplatform/CMakeFiles/kiplatform.dir/gtk/app.cpp.o
> /home/alex/kicad_sources/kicad/libs/kimath/src/convert_basic_shapes_to_polygon.cpp:
>  In function ‘void CornerListToPolygon(SHAPE_POLY_SET&, 
> std::vector&, int, int, ERROR_LOC)’:
> /home/alex/kicad_sources/kicad/libs/kimath/src/convert_basic_shapes_to_polygon.cpp:314:43:
>  error: ‘OPT >’ {aka ‘class boost::optional >’} has 
> no member named ‘has_value’; did you mean ‘value’?
>  outline.Append( intersect.has_value() ? intersect.get() : 
> arcStart );
>^
>value
> /home/alex/kicad_sources/kicad/libs/kimath/src/convert_basic_shapes_to_polygon.cpp:327:43:
>  error: ‘OPT >’ {aka ‘class boost::optional >’} has 
> no member named ‘has_value’; did you mean ‘value’?
>  outline.Append( intersect.has_value() ? intersect.get() : 
> arcEnd );
>^
>value
> make[2]: *** [libs/kimath/CMakeFiles/kimath.dir/build.make:76: 
> libs/kimath/CMakeFiles/kimath.dir/src/convert_basic_shapes_to_polygon.cpp.o] 
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:1920: 
> libs/kimath/CMakeFiles/kimath.dir/all] Error 2
>
> I can't for the life of me figure out what the issue is. I'm running devuan 
> and the cmake process finished without any warnings or errors.
>
> Best regards,
> Alex
> ___
> Mailing list: https://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 functionality explanation help

[Nick Østergaard]

 @Amir, Currently, any help at getting this list sorted out is progress.

https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0.0-rc1

But that list contains both big and small items, but items that do require
some real work.

On Tue, 29 Jun 2021 at 16:11, Mark Roszko  wrote:

> >The number of issues is about 1170 on any day since a few months. My
> goal is to reduce the number of open issues to a bare minimum or eliminate
> them
>
>
> You realize we only have <100 real issues right? You cannot look at the
> silly total displayed and assume. You have to drill down by tags.
> A vast majority are wishlist items (849), not actual bugs.
>
> Some bugs also cannot be fixed by wishful thinking, they are platform
> issues or user specific with no reproduction cases but we leave open for
> documentation. Some bugs are also slated for later fixes in newer versions
> downstream.
>
> You came barging in assuming we are just randomly  committing code without
> plans. We absolutely do and have a workflow. Of course we are volunteers
> and work on what we want and when we want which is why we don't take kindly
> to someone coming in and accosting us that we need someone to manage us and
> spend months writing fizz buzz to work on KiCad which is already going slow.
>
>
> On Tue, Jun 29, 2021, 8:12 AM Amit M  wrote:
>
>> Hello all,
>>
>>
>>
>> I’m a beginner to Kicad source code. I’m looking to test some modules and
>> components. Is there a way to learn which module does what in the repo? I
>> have the source code with me.  The whole project seems a bit complex so I’m
>> trying to figure out one part , test it and then increase tests to other
>> parts to cover most or all of it.  I am sort of familiar with understanding
>> large code bases but am finding a starting point. I have been told to look
>> at the directory below and write tests there.
>>
>> https://gitlab.com/kicad/code/kicad/-/tree/master/qa
>>
>>
>>
>> The entire code is below:
>>
>> https://gitlab.com/kicad/code/kicad/-/tree/master
>>
>>
>>
>> If you can, can you please suggest any documentation or emails or
>> anything which can explain which module does what and how does each module
>> work ? Examples of some modules I’m wanting to learn to test are eeschema
>> , pcbnew,
>> qa_utils, gerber and geometry just to name a few. I  also looked at UI and
>> other things such as 3d viewer modules. I figure there may be UI related
>> bugs because there were crashes as listed in the mailing list or in the
>> issue list here:
>>
>> https://gitlab.com/kicad/code/kicad/-/issues
>>
>>
>>
>> The number of issues is about 1170 on any day since a few months. My goal
>> is to reduce the number of open issues to a bare minimum or eliminate them.
>>
>> I had some discussions with the developers and they didn’t accept
>> suggestions that writing detailed software requirements and design
>> specifications to reduce bugs would work as most developers are volunteers.
>>
>>
>>
>> Thanks,
>>
>> Amit
>> ___
>> Mailing list: https://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)

[Nick Østergaard]

Yeah, it appears they ship wxwidgets as 3.0 and wxmsw as 3.1. The guide
should probably be updsted for that dependency.

And I think the wxpython matches wxmsw 3.1, which should be compatible with
python3. I have not tested that.

man. 28. jun. 2021 17.18 skrev Brian Piccioni :

> That was probably it!
>
> I get much farther now. It stopped at
>
> CMake Error at
> C:/msys64/mingw64/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230
> (message):
>   Could NOT find wxWidgets: Found unsuitable version "3.0.5", but required
> is
>   at least "3.1.5" (found
>
> -LC:/msys64/mingw64/lib;;;-pipe;-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high;-Wl,--subsystem,windows;-mwindows;-lwx_mswu_gl-3.0;-lwx_mswu_aui-3.0;-lwx_mswu_adv-3.0;-lwx_mswu_html-3.0;-lwx_mswu_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_mswu_propgrid-3.0;-lwx_baseu_xml-3.0;-lwx_mswu_stc-3.0)
>
> Because it found 3.0.5 (even though 3.1.5 was installed) so I ran
>
>  pacman -R mingw-w64-x86_64-wxWidgets
>
> and it went through.
>
>
> Thanks everybody!
>
>
>
> On 2021-06-28 11:00 a.m., Nick Østergaard wrote:
>
> Brian,  think that is because you started the msys shell instead of one of
> the mingw64 one.
>
> On Mon, 28 Jun 2021 at 16:46, jp charras  wrote:
>
>>
>> Le 28/06/2021 à 16:14, Brian Piccioni a écrit :
>> > JP
>> >
>> > Thanks for the quick reply
>> >
>> > bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
>> > $ find /mingw64/ -name *glew*
>> > /mingw64/bin/glew32.dll
>> > /mingw64/bin/glewinfo.exe
>> > /mingw64/bin/libvtkglew-8.2.dll
>> > /mingw64/include/GL/glew.h
>> > /mingw64/include/GL/wglew.h
>> > /mingw64/include/OGRE/RenderSystems/GL/GL/glew.h
>> > /mingw64/include/OGRE/RenderSystems/GL/GL/wglew.h
>> > /mingw64/include/vtk-8.2/vtkglew
>> > /mingw64/include/vtk-8.2/vtkglew/include/GL/glew.h
>> > /mingw64/include/vtk-8.2/vtkglew/include/GL/vtk_glew_mangle.h
>> > /mingw64/include/vtk-8.2/vtkglew/include/GL/wglew.h
>> > /mingw64/include/vtk-8.2/vtk_glew.h
>> > /mingw64/lib/cmake/glew
>> > /mingw64/lib/cmake/glew/glew-config.cmake
>> > /mingw64/lib/cmake/glew/glew-targets-release.cmake
>> > /mingw64/lib/cmake/glew/glew-targets.cmake
>> > /mingw64/lib/cmake/vtk-8.2/Modules/vtkglew.cmake
>> > /mingw64/lib/libglew32.a
>> > /mingw64/lib/libglew32.dll.a
>> > /mingw64/lib/libvtkglew-8.2.dll.a
>> > /mingw64/lib/pkgconfig/glew.pc
>> > /mingw64/share/licenses/glew
>> >
>> > bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
>> > $ pacman -Ss glew
>> > mingw32/mingw-w64-i686-glew 2.2.0-2
>> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
>> > mingw64/mingw-w64-x86_64-glew 2.2.0-2 [installed]
>> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
>> > ucrt64/mingw-w64-ucrt-x86_64-glew 2.2.0-2
>> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
>> > clang64/mingw-w64-clang-x86_64-glew 2.2.0-2
>> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
>> >
>> > bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
>> >
>> >
>>
>> This is similar to what I see on my computer (but I have less files).
>>
>> GLEW_LIBRARY should be found by cmake.
>>
>> You can try the brute force (that helped me in some cases):
>>
>> invoke cmake with the option:
>>
>> -DGLEW_LIBRARY=/d/mingw/mingw64/lib
>>
>> (expecting your mingw path is /d/mingw) to force the GLEW_LIBRARY path.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>>
>> ___
>> Mailing list: https://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)

[Nick Østergaard]

Brian,  think that is because you started the msys shell instead of one of
the mingw64 one.

On Mon, 28 Jun 2021 at 16:46, jp charras  wrote:

>
> Le 28/06/2021 à 16:14, Brian Piccioni a écrit :
> > JP
> >
> > Thanks for the quick reply
> >
> > bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
> > $ find /mingw64/ -name *glew*
> > /mingw64/bin/glew32.dll
> > /mingw64/bin/glewinfo.exe
> > /mingw64/bin/libvtkglew-8.2.dll
> > /mingw64/include/GL/glew.h
> > /mingw64/include/GL/wglew.h
> > /mingw64/include/OGRE/RenderSystems/GL/GL/glew.h
> > /mingw64/include/OGRE/RenderSystems/GL/GL/wglew.h
> > /mingw64/include/vtk-8.2/vtkglew
> > /mingw64/include/vtk-8.2/vtkglew/include/GL/glew.h
> > /mingw64/include/vtk-8.2/vtkglew/include/GL/vtk_glew_mangle.h
> > /mingw64/include/vtk-8.2/vtkglew/include/GL/wglew.h
> > /mingw64/include/vtk-8.2/vtk_glew.h
> > /mingw64/lib/cmake/glew
> > /mingw64/lib/cmake/glew/glew-config.cmake
> > /mingw64/lib/cmake/glew/glew-targets-release.cmake
> > /mingw64/lib/cmake/glew/glew-targets.cmake
> > /mingw64/lib/cmake/vtk-8.2/Modules/vtkglew.cmake
> > /mingw64/lib/libglew32.a
> > /mingw64/lib/libglew32.dll.a
> > /mingw64/lib/libvtkglew-8.2.dll.a
> > /mingw64/lib/pkgconfig/glew.pc
> > /mingw64/share/licenses/glew
> >
> > bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
> > $ pacman -Ss glew
> > mingw32/mingw-w64-i686-glew 2.2.0-2
> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> > mingw64/mingw-w64-x86_64-glew 2.2.0-2 [installed]
> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> > ucrt64/mingw-w64-ucrt-x86_64-glew 2.2.0-2
> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> > clang64/mingw-w64-clang-x86_64-glew 2.2.0-2
> > GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> >
> > bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
> >
> >
>
> This is similar to what I see on my computer (but I have less files).
>
> GLEW_LIBRARY should be found by cmake.
>
> You can try the brute force (that helped me in some cases):
>
> invoke cmake with the option:
>
> -DGLEW_LIBRARY=/d/mingw/mingw64/lib
>
> (expecting your mingw path is /d/mingw) to force the GLEW_LIBRARY path.
>
>
> --
> Jean-Pierre CHARRAS
>
>
> ___
> Mailing list: https://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] Python 3 now required

[Nick Østergaard]

You don't need to specify the type, but cmake will accept it as well and
that is how it is written by cmake in the CMakeCache.txt.

On Wed, 16 Jun 2021 at 20:51, Kevin Cozens  wrote:

> On 2021-06-15 6:32 a.m., Marco Ciampa wrote:
> > On Tue, Jun 15, 2021 at 12:22:42AM +0300, Eeli Kaikkonen wrote:
> [snip]
> >> That's where cmake UIs come handy. Try ccmake or cmake-gui (they are
> [snip]
> >
> > Exactly, Kevin is right but using the cmake-gui command it was very easy
> > to figure out how to change the variables to make it compile for me.
>
> I changed a symlink on my machine to make 'python' point to 'python3'. I
> also rm'ed the build directory. I seem to be over the problem with it
> finding the right version of Python when both 2.7 and 3.6 are installed.
>
> Now it complains that it can't find wxPython/Phoenix. AFAICT, that means I
> need version 4 of wx. I only have 3 and the distro I'm using doesn't have
> version 4 available so I can no longer build KiCAD v6. At least I solved
> the
> previous problem. :)
>
> > //Build for Python 3 instead of 2 (default OFF).
> > KICAD_SCRIPTING_PYTHON3:BOOL=ON
>
> Is this the new way of specifying whether a setting is enabled or not? You
> need to specify the setting type and not just whether it is on or off? In
> the past I just have just used =.
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
>  | that's why we're powerful"
> Owner of Elecraft K2 #2172  |
> #include  | --Chris Hardwick
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] asciidoc

[Nick Østergaard]

It was also happy here
https://gitlab.com/kicad/packaging/kicad-fedora-builder/-/jobs/1316881996

tor. 3. jun. 2021 22.38 skrev Steven A. Falco :

> Yes - I had to refresh my token too.  By the way, below is a link to the
> copr test build I made (in my private copr) - it passed :-)
>
> https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/build/2215757/
>
> Steve
>
> On 6/3/21 4:32 PM, Nick Østergaard wrote:
> > Ah,ok, I misread the pipeline logs..
> >
> > Error: Login invalid/expired. Please visit
> https://copr.fedorainfracloud.org/api <
> https://copr.fedorainfracloud.org/api> to get or renew your API token.
> >
> > I gotta update that.
> >
> > On Thu, 3 Jun 2021 at 22:29, Steven A. Falco  <mailto:stevenfa...@gmail.com>> wrote:
> >
> > The build you are looking at happened before I put in the fix.  In
> other words, I saw that same build failure (on May 30), and put in the fix
> a few hours later.
> >
> > The next doc build should use rubygem-asciidoctor in place of
> asciidoc, and it should pass.
> >
> > Can you kick off a manual build of the docs to test that?
> >
> >  Steve
> >
> > On 6/3/21 3:26 PM, Nick Østergaard wrote:
> >  > @Steven A. Falco <mailto:stevenfa...@gmail.com  stevenfa...@gmail.com>>
> >  >
> >  > Did you have a look at building the docs for fedora with the
> other package?
> >  >
> >  > It appears to still BuildRequires: asciidoc when I look in the
> spec file in
> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ <
> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/> <
> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ <
> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/>>
> >  >
> >  > On Sun, 30 May 2021 at 22:51, Jon Evans  <mailto:j...@craftyjon.com> <mailto:j...@craftyjon.com  j...@craftyjon.com>>> wrote:
> >  >
> >  > If you use Docker, there is also a container for the docs
> build based on Debian:
> >  >
> >  >
> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
> <
> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base>
> <
> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
> <
> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
> >>
> >  >
> >  > Maybe this is also helpful for setting up a Fedora VM or
> Docker container
> >  >
> >  > On Sun, May 30, 2021 at 3:00 PM Steven A. Falco <
> stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>  stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>>> wrote:
> >  >  >
> >  >  > I'll have to spin up a VM to play with that.  I'll get
> back to you... :-)
> >  >  >
> >  >  > Steve
> >  >  >
> >  >  > On 5/30/21 2:34 PM, Jon Evans wrote:
> >  >  > > You want this one:
> https://github.com/Mogztter/asciidoctor-web-pdf <
> https://github.com/Mogztter/asciidoctor-web-pdf> <
> https://github.com/Mogztter/asciidoctor-web-pdf <
> https://github.com/Mogztter/asciidoctor-web-pdf>>
> >  >  > >
> >  >  > > On Ubuntu I install it with "sudo npm i -g
> @asciidoctor/core asciidoctor-pdf"
> >  >  > >
> >  >  > > On Sun, May 30, 2021 at 2:33 PM Steven A. Falco <
> stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>  stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>>> wrote:
> >  >  > >>
> >  >  > >> I'm able to build the html pages, which is all we need
> for the nightlies, but I am not able to build the pdf files.  I get an
> error:
> >  >  > >>
> >  >  > >>   Could NOT find ASCIIDOCTORPDF (missing:
> ASCIIDOCTORPDF_COMMAND)
> >  >  > >>
> >  >  > >> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake
> wants a program called "asciidoctor-web-pdf".
> >  >  > >>
> >  >  > >> Fedora has a package "rubygem-asciidoctor-pdf" which
> provides a program called "asciido

Re: [Kicad-developers] asciidoc

[Nick Østergaard]

Hopefully it should be running ok in
https://gitlab.com/kicad/packaging/kicad-fedora-builder/-/jobs/1316881996

On Thu, 3 Jun 2021 at 22:32, Nick Østergaard  wrote:

> Ah,ok, I misread the pipeline logs..
>
> Error: Login invalid/expired. Please visit
> https://copr.fedorainfracloud.org/api to get or renew your API token.
>
> I gotta update that.
>
> On Thu, 3 Jun 2021 at 22:29, Steven A. Falco 
> wrote:
>
>> The build you are looking at happened before I put in the fix.  In other
>> words, I saw that same build failure (on May 30), and put in the fix a few
>> hours later.
>>
>> The next doc build should use rubygem-asciidoctor in place of asciidoc,
>> and it should pass.
>>
>> Can you kick off a manual build of the docs to test that?
>>
>> Steve
>>
>> On 6/3/21 3:26 PM, Nick Østergaard wrote:
>> > @Steven A. Falco <mailto:stevenfa...@gmail.com>
>> >
>> > Did you have a look at building the docs for fedora with the other
>> package?
>> >
>> > It appears to still BuildRequires: asciidoc when I look in the spec
>> file in
>> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ <
>> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/>
>> >
>> > On Sun, 30 May 2021 at 22:51, Jon Evans > j...@craftyjon.com>> wrote:
>> >
>> > If you use Docker, there is also a container for the docs build
>> based on Debian:
>> >
>> >
>> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
>> <
>> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
>> >
>> >
>> > Maybe this is also helpful for setting up a Fedora VM or Docker
>> container
>> >
>> > On Sun, May 30, 2021 at 3:00 PM Steven A. Falco <
>> stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>> wrote:
>> >  >
>> >  > I'll have to spin up a VM to play with that.  I'll get back to
>> you... :-)
>> >  >
>> >  > Steve
>> >  >
>> >  > On 5/30/21 2:34 PM, Jon Evans wrote:
>> >  > > You want this one:
>> https://github.com/Mogztter/asciidoctor-web-pdf <
>> https://github.com/Mogztter/asciidoctor-web-pdf>
>> >  > >
>> >  > > On Ubuntu I install it with "sudo npm i -g @asciidoctor/core
>> asciidoctor-pdf"
>> >  > >
>> >  > > On Sun, May 30, 2021 at 2:33 PM Steven A. Falco <
>> stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>> wrote:
>> >  > >>
>> >  > >> I'm able to build the html pages, which is all we need for
>> the nightlies, but I am not able to build the pdf files.  I get an error:
>> >  > >>
>> >  > >>   Could NOT find ASCIIDOCTORPDF (missing:
>> ASCIIDOCTORPDF_COMMAND)
>> >  > >>
>> >  > >> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a
>> program called "asciidoctor-web-pdf".
>> >  > >>
>> >  > >> Fedora has a package "rubygem-asciidoctor-pdf" which provides
>> a program called "asciidoctor-pdf".
>> >  > >>
>> >  > >> I don't know if "asciidoctor-pdf" is equivalent to
>> "asciidoctor-web-pdf".  If it is, then perhaps the cmake file should accept
>> either one.
>> >  > >>
>> >  > >>  Steve
>> >  > >>
>> >  > >> On 5/30/21 1:58 PM, Steven A. Falco wrote:
>> >  > >>> Thanks Jon.
>> >  > >>>
>> >  > >>> I'm running a test build now.  If it passes, I'll propose a
>> patch for the README.  I'll also push the change to the nightly Fedora
>> builds.
>> >  > >>>
>> >  > >>>   Steve
>> >  > >>>
>> >  > >>> On 5/30/21 1:51 PM, Jon Evans wrote:
>> >  > >>>> Hi Steve,
>> >  > >>>>
>> >  > >>>> As the readme notes, I have not yet updated the docs for
>> Fedora or
>> >  > >>>> Manjaro/Arch as I don't use those distros and am not sure
>> of the right
>> >  > >>>> incantations.
>

Re: [Kicad-developers] asciidoc

[Nick Østergaard]

Ah,ok, I misread the pipeline logs..

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

I gotta update that.

On Thu, 3 Jun 2021 at 22:29, Steven A. Falco  wrote:

> The build you are looking at happened before I put in the fix.  In other
> words, I saw that same build failure (on May 30), and put in the fix a few
> hours later.
>
> The next doc build should use rubygem-asciidoctor in place of asciidoc,
> and it should pass.
>
> Can you kick off a manual build of the docs to test that?
>
> Steve
>
> On 6/3/21 3:26 PM, Nick Østergaard wrote:
> > @Steven A. Falco <mailto:stevenfa...@gmail.com>
> >
> > Did you have a look at building the docs for fedora with the other
> package?
> >
> > It appears to still BuildRequires: asciidoc when I look in the spec file
> in https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/ <
> https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/2215751/>
> >
> > On Sun, 30 May 2021 at 22:51, Jon Evans  j...@craftyjon.com>> wrote:
> >
> > If you use Docker, there is also a container for the docs build
> based on Debian:
> >
> >
> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
> <
> https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base
> >
> >
> > Maybe this is also helpful for setting up a Fedora VM or Docker
> container
> >
> > On Sun, May 30, 2021 at 3:00 PM Steven A. Falco <
> stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>> wrote:
> >  >
> >  > I'll have to spin up a VM to play with that.  I'll get back to
> you... :-)
> >  >
> >  > Steve
> >  >
> >  > On 5/30/21 2:34 PM, Jon Evans wrote:
> >  > > You want this one:
> https://github.com/Mogztter/asciidoctor-web-pdf <
> https://github.com/Mogztter/asciidoctor-web-pdf>
> >  > >
> >  > > On Ubuntu I install it with "sudo npm i -g @asciidoctor/core
> asciidoctor-pdf"
> >  > >
> >  > > On Sun, May 30, 2021 at 2:33 PM Steven A. Falco <
> stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>> wrote:
> >  > >>
> >  > >> I'm able to build the html pages, which is all we need for the
> nightlies, but I am not able to build the pdf files.  I get an error:
> >  > >>
> >  > >>   Could NOT find ASCIIDOCTORPDF (missing:
> ASCIIDOCTORPDF_COMMAND)
> >  > >>
> >  > >> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a
> program called "asciidoctor-web-pdf".
> >  > >>
> >  > >> Fedora has a package "rubygem-asciidoctor-pdf" which provides
> a program called "asciidoctor-pdf".
> >  > >>
> >  > >> I don't know if "asciidoctor-pdf" is equivalent to
> "asciidoctor-web-pdf".  If it is, then perhaps the cmake file should accept
> either one.
> >  > >>
> >  > >>  Steve
> >  > >>
> >  > >> On 5/30/21 1:58 PM, Steven A. Falco wrote:
> >  > >>> Thanks Jon.
> >  > >>>
> >  > >>> I'm running a test build now.  If it passes, I'll propose a
> patch for the README.  I'll also push the change to the nightly Fedora
> builds.
> >  > >>>
> >  > >>>   Steve
> >  > >>>
> >  > >>> On 5/30/21 1:51 PM, Jon Evans wrote:
> >  > >>>> Hi Steve,
> >  > >>>>
> >  > >>>> As the readme notes, I have not yet updated the docs for
> Fedora or
> >  > >>>> Manjaro/Arch as I don't use those distros and am not sure of
> the right
> >  > >>>> incantations.
> >  > >>>>
> >  > >>>> If you can advise what should go into the README I'm happy
> to update it.
> >  > >>>>
> >  > >>>> Also, please let me know if you run into any snags building
> the docs
> >  > >>>> with the new toolchain.
> >  > >>>>
> >  > >>>> Best,
> >  > >>>> Jon
> >  > >>>>
> >  > >>>> On Sun, May 30, 202

Re: [Kicad-developers] asciidoc

[Nick Østergaard]

@Steven A. Falco 

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

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

On Sun, 30 May 2021 at 22:51, Jon Evans  wrote:

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

[Nick Østergaard]

Mm, normally you should use the mingw env in msys2, from your prompt it
appears you use the msys env.

Normally I would expect all psths it uses for binsries to be unic like,
that is /c instead of c:/

ons. 19. maj 2021 02.55 skrev Clifford Neal Simon :

> Hi devs,
>
> I'm doing my first build from source, using msys2 on windows.
> I (shallow) cloned the main repository.
> I downloaded the tools and dependencies using pacman, according to here:
> https://dev-docs.kicad.org/en/build/windows-msys2/
> Now I should be able to run cmake, but cmake fails.
>
> User@Programming MSYS ~/kicad/build/release
> $ /mingw64/bin/cmake -DCMAKE_BUILD_TYPE=Release \
>   -G "MSYS Makefiles" \
>   -DCMAKE_PREFIX_PATH=/mingw64 \
> -DCMAKE_INSTALL_PREFIX=/mingw64 \
> -DDEFAULT_INSTALL_PATH=/mingw64 \
> ../../
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - failed
> -- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe
> -- Check for working C compiler: C:/msys64/mingw64/bin/gcc.exe - broken
> CMake Error at
> C:/msys64/mingw64/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66
> (message):
>   The C compiler
>
> "C:/msys64/mingw64/bin/gcc.exe"
>
>   is not able to compile a simple test program.
>
> I looked at CMakeError.log. From what I can tell from there, it seems to
> be trying to compile "CMakeCCompilerId.c" with gcc but it passed the flags
> --target=arm-arm-none-eabi;-mcpu=cortex-m3 to gcc and gcc does not
> understand those flags. Those flags are very strange. I did not ask to
> cross-compile, and of course I would not expect for a cross-compilation to
> work. Have I missed a step?
>
> -Clifford
>
> ___
> Mailing list: https://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

[Nick Østergaard]

It did not work last time I tried it.

On Tue, 18 May 2021 at 14:43, Wayne Stambaugh  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
> > ) 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
>
___
Mailing list: https://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

[Nick Østergaard]

IMHO we should be fine with defaulting to OCC by now. Previously there were
issues with the occ build in msys2 where kicad would not link to it
properly, but we have since started to support msvc instead and we are
using occ for those builds for master.

Also, I think we are using occ on macos now, according to a comment on
zulip:
> Michael Kavanagh: @Wayne Stambaugh macOS has been packaged with OCC for a
while now (hence my build comment on the issue)

> Michael Kavanagh:
https://gitlab.com/kicad/packaging/kicad-mac-builder/-/commit/e9d69381b957670f4447e21c07228243ca4ee3db

There was a bit back and forth going on there for macos...

Nick

On Mon, 17 May 2021 at 16:57, Eeli Kaikkonen 
wrote:

> On Mon, May 17, 2021 at 5:14 PM Carsten Schoenert
>  wrote:
>
> > I'm using mostly the explicit set up of build options and do not rely on
> > used default values, so the Debian packages using OCC for more than a
> > year. And this also for backported versions.
>
> I was unsure about Debian because I didn't document my failure to
> build KiCad (with phoenix) on it. For other distros, I'm 100% sure
> about Ubuntu (and Kubuntu), Mint, Fedora, Arch and Manjaro, the latest
> release versions of those distros. Also openSUSE Tumbleweed (the
> rolling release). None of them drew OCE as a dependency for the
> available KiCad 5.99 (or 5.1 if 5.99 wasn't available) package, they
> all use OCC.
>
> This covers all of the supported distros. Also all of the distros in
> the Download page except gentoo. Flatpak seems to use explicit cmake
> flags and also dowloads and compiles the used OCC/OCE version
> explicitly, so it's not affected.
>
> > I've configured the build of the current 5.99 version for experimental
> > since a few weeks, and wxpython 4.0 is used here also like done for the
> > current stable version since a long time. Or I miss your point.
>
> I already forgot the details, but it was Buster for which I couldn't
> install the build dependencies which would make it possible to compile
> 5.99 with wxPhoenix. There was something strange about it. But that's
> offtopic.
>
> 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] Compiling KiCAD 5.99 on Raspberry Pi (400)

[Nick Østergaard]

I am not aware of any patches needed for buster.

Just try to build and see if it succeeds.

On Wed, 28 Apr 2021 at 18:14, Knochi.de  wrote:

> I’m using the standard Raspberry OS which is “raspian buster”
> libcurl4-gnutls-dev was the correct pick. So continuing with resolving
> dependencies for now.
>
> Next is how to apply patches. From my understanding I need to apply
> patches to certain files, plus the documentation says “platform dependent
> patches” so e.g. for boost I don’t need the “mingw” stuff.
> Do I need to apply them at all? They are very old.
>
> Cu
> David
>
> Am 28. Apr. 2021, 17:47 +0200 schrieb Nick Østergaard :
>
> Mm, you didn't state what OS you have on that pi, but I assume something
> debian based, you probably need a "-dev" og some of the libcurl stuff.
> Something like libcurl4-gnutls-dev
>
> On Wed, 28 Apr 2021 at 17:26, David Knochenhauer  wrote:
>
>> Hi,
>>
>> I'm new to this topic, but I want to learn how this stuff works and I
>> want my favorite eCAD software to be the subject of this journey.
>>
>> So what I have managed so far:
>>
>>- getting the sources from GIT
>>- executing cmake (ha!)
>>- identifying missing dependencies
>>- turning OFF SCRIPTING and OCE
>>- installed GLEW and GLM libraries
>>
>> Now I'm struggling with CURL.. I'm not sure which library to install.
>> Libcurl4 and libcurl3-gnutls are preinstalled but obviously neither of them
>> is the needed.
>>
>> So if someone have a hint on this.. thanks in advance
>>
>> Cu
>> David
>>
>> ___
>> Mailing list: https://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

[Nick Østergaard]

Ok, thank you. I will follow-up with archlinux packager for ngspice.

On Wed, 28 Apr 2021 at 10:02, Holger Vogt  wrote:

> config.h for ngspice should not be distributed, because it is a local,
> OS dependent autogenerated file, and might interfere with other packages.
>
> So I did remove it in ngspice-34.
>
> Nevertheless KiCad uses it (from its position in
> /usr/include/ngspice/config.h) to extract compile time version info for
> ngspice.
>
> Due to a bug from my side config.h was still distributed with
> ngspice-34, now located in /usr/include/config.h.
>
> ngspice-35 will contain version info in sharedspice.h (which is always
> distributed), and there are some suggestion by Carsten how to handle the
> version info issue "the correct way" (unfortunately barely Windows
> compatible).
>
> So indeed an intermediate sultion for ngspice-34 might be to shift
> config.h to /usr/include/ngspice/config.h before compilation.
>
>
___
Mailing list: https://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

[Nick Østergaard]

Hi

What is the solution to this issue. I just hit issues with ngspice-34 in
archlinux. [1]

There is a /usr/include/config.h

Should this be put in /usr/include/ngspice/config.h?

I lost track of this discussion, so I am not really sure what happened and
why. Just slightly surprised that it appears broken somehow.

Regards
Nick

[1] https://aur.archlinux.org/packages/kicad-git/#comment-804217

On Tue, 23 Mar 2021 at 15:22, 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
>
___
Mailing list: https://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

[Nick Østergaard]

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

Re: [Kicad-developers] kicad-msvc.r21621.b71ab01d-x86_64.exe AND kicad-msvc.r21619.2c3f9d30-x86_64.exe installs but does not start up-Windows reports as already running.

[Nick Østergaard]

If  
https://gitlab.com/kicad/code/kicad/-/commit/e38fe842e225271b2c971cc5d8d4035d57c837c1
fixes it, there should be a new lite build i half an hour.

On Sat, 13 Mar 2021 at 16:30, Jon Evans  wrote:
>
> If this is the first time you are running KiCad 5.99, or you erased your 
> settings directory, you may be hitting 
> https://gitlab.com/kicad/code/kicad/-/issues/7900 with that version.
>
> If this is the case, try installing an older nightly (like go back a week or 
> so, just using the lite installer is fine) and try starting it up.  If that 
> works, you should be able to install the latest version again and have it 
> work.
>
> -Jon
>
> On Sat, Mar 13, 2021 at 10:26 AM Nick Østergaard  wrote:
>>
>> Please try to see if you can start it directly from the kicad.exe in the 
>> install location insread of the shortcuts.
>>
>> lør. 13. mar. 2021 16.22 skrev David :
>>>
>>> I'm reporting this here as I am unable to provide any version information 
>>> as nothing starts up. This is reported as an incomplete report by the Kicad 
>>> bot on Gitlab.
>>>
>>> Description
>>>
>>> kicad-msvc.r21621.b71ab01d-x86_64.exe AND 
>>> kicad-msvc.r21619.2c3f9d30-x86_64.exe installs but does not start 
>>> up-Windows reports as already running when double-clicking on Kicad, 
>>> eeschema or pcbnew. None of these applications are listed in task manager. 
>>> They have NOT been blocked by Comodo internet security premium on my PC 
>>> (any kicad application is normally sandboxed, and I manually have to add to 
>>> trusted applications).
>>>
>>> Steps to reproduce
>>>
>>> 1.Install. 2.Double click on EESchema, PCBnew icons
>>>
>>> KiCad Version
>>>
>>> Can not copy version info as applications will NOT start up. My Windows 
>>> version is Windows 10 2004 (OS Build 19041.867)
>>>
>>> ___
>>> Mailing list: https://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] kicad-msvc.r21621.b71ab01d-x86_64.exe AND kicad-msvc.r21619.2c3f9d30-x86_64.exe installs but does not start up-Windows reports as already running.

[Nick Østergaard]

Please try to see if you can start it directly from the kicad.exe in the
install location insread of the shortcuts.

lør. 13. mar. 2021 16.22 skrev David :

> I'm reporting this here as I am unable to provide any version information
> as nothing starts up. This is reported as an incomplete report by the Kicad
> bot on Gitlab.
> Description
>
> kicad-msvc.r21621.b71ab01d
> -x86_64.exe
> AND kicad-msvc.r21619.2c3f9d30
> -x86_64.exe
> installs but does not start up-Windows reports as already running when
> double-clicking on Kicad, eeschema or pcbnew. None of these applications
> are listed in task manager. They have NOT been blocked by Comodo internet
> security premium on my PC (any kicad application is normally sandboxed, and
> I manually have to add to trusted applications).
> Steps to reproduce
>
> 1.Install. 2.Double click on EESchema, PCBnew icons
> KiCad Version
>
> Can not copy version info as applications will NOT start up. My Windows
> version is Windows 10 2004 (OS Build 19041.867)
> ___
> Mailing list: https://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 failure

[Nick Østergaard]

Maybe try the kicad-mac-buidler just to verify your environment works?
It should use the same brew stuff as you manually use.

https://gitlab.com/kicad/packaging/kicad-mac-builder/

On Fri, 5 Mar 2021 at 17:44, Jonatan Liljedahl  wrote:
>
> I tried "make install" in case something wasn't in the right place,
> but now that fails (which used to work fine):
>
> -- fixup_bundle
> --   
> app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
> --   
> libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
> --   dirs=' /usr/local/lib'
> --   ignoreItems=''
> -- fixup_bundle: preparing...
> -- warning: embedded item does not exist
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> CMake Error at 
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
> (message):
>   otool -l failed: 1
>
>
>   
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
>   error: '@loader_path/libTKVCAF.7.dylib': No such file or directory
>
> Call Stack (most recent call first):
>   
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
> (get_item_rpaths)
>   
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
> (set_bundle_key_values)
>   
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
> (get_bundle_keys)
>   kicad/cmake_install.cmake:101 (fixup_bundle)
>   cmake_install.cmake:67 (include)
>
>
> make: *** [install] Error 1

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

Re: [Kicad-developers] build failure

[Nick Østergaard]

td::__1::char_traits, std::__1::allocator > const&,
> TRIPLET, TDF_Label&) in libkicad2step_lib.a(oce_utils.cpp.o)
>  "APIHeaderSection_MakeHeader::SetAuthorValue(int,
> opencascade::handle const&)", referenced
> from:
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "APIHeaderSection_MakeHeader::SetDescriptionValue(int,
> opencascade::handle const&)", referenced
> from:
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "APIHeaderSection_MakeHeader::SetOrganizationValue(int,
> opencascade::handle const&)", referenced
> from:
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  
> "APIHeaderSection_MakeHeader::SetOriginatingSystem(opencascade::handle
> const&)", referenced from:
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  
> "APIHeaderSection_MakeHeader::SetName(opencascade::handle
> const&)", referenced from:
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  
> "APIHeaderSection_MakeHeader::APIHeaderSection_MakeHeader(opencascade::handle
> const&)", referenced from:
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "Standard_Failure::GetMessageString() const", referenced from:
>  vtable for Standard_ConstructionError in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  vtable for Standard_OutOfRange in libkicad2step_lib.a(oce_utils.cpp.o)
>  "XCAFDoc_ShapeTool::GetFreeShapes(NCollection_Sequence&)
> const", referenced from:
>  PCBMODEL::transferModel(opencascade::handle&,
> opencascade::handle&, TRIPLET) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  "Standard_Transient::DecrementRefCounter() const", referenced from:
>  PCBMODEL::PCBMODEL() in libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::handle::~handle() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::handle::~handle() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  opencascade::handle::~handle() in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  PCBMODEL::~PCBMODEL() in libkicad2step_lib.a(oce_utils.cpp.o)
>  PCBMODEL::AddPadHole(KICADPAD const*) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  std::__1::vector
>
> ::push_back(TopoDS_Shape const&) in
>
> libkicad2step_lib.a(oce_utils.cpp.o)
>  ...
>  "Standard_Transient::IncrementRefCounter() const", referenced from:
>  PCBMODEL::AddPadHole(KICADPAD const*) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  std::__1::vector
>
> ::push_back(TopoDS_Shape const&) in
>
> libkicad2step_lib.a(oce_utils.cpp.o)
>  PCBMODEL::CreatePCB() in libkicad2step_lib.a(oce_utils.cpp.o)
>  NCollection_List::Append(TopoDS_Shape const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  PCBMODEL::WriteSTEP(wxString const&) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  PCBMODEL::transferModel(opencascade::handle&,
> opencascade::handle&, TRIPLET) in
> libkicad2step_lib.a(oce_utils.cpp.o)
>  OUTLINE::addEdge(BRepBuilderAPI_MakeWire*, KICADCURVE&,
> DOUBLET&) in libkicad2step_lib.a(oce_utils.cpp.o)
>  ...
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[2]: *** [kicad/KiCad.app/Contents/MacOS/kicad2step] Error 1
> make[1]: *** [utils/kicad2step/CMakeFiles/kicad2step.dir/all] Error 2
>
> On Fri, Mar 5, 2021 at 11:57 AM Nick Østergaard  wrote:
>
>
> You need to make sure you have a clean buid dir and try yo explicitly disable 
> oce and enable occt on your cmake configure line.
>
> fre. 5. mar. 2021 11.48 skrev Jonatan Liljedahl :
>
>
> Ok, I'm now trying to build against OCE instead, as I'm sure that used
> to work before.
> I managed to have CMake find my homebrew installed OCE by setting
> OCE_DIR, however it fails here:
>
> make[2]: *** No rule to make target
> `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework',
> needed by `kicad/KiCad.app/Contents/MacOS/kicad2step'.  Stop.
>
> Because I don't have MacOSX10.14.sdk, but 10.15. The weird thing is
> that I have set CMake build variables to the correct path:
>
> CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.15
> CMAKE_OSX_SYSROOT:PATH=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
>
> But even then, kicad2step still has 10.14:
>
> utils/kicad2step/CMakeFiles/kicad2step.dir/build.make:kicad/KiCad.app/Contents/MacOS/kicad2step:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework
>
> Removing utils/kicad2step/CMakeFiles (and plugins/3d/oce/CMakeFiles),
> a recursive grep in my build directory tells me that there's NO
> mention of "MacOSX10.14" anywhere. But after I've run cmake, it shows
> up again in the above mentioned places!
>
> So where is this "MacOSX10.14" reference coming from?
>
> lijon@lijon-mbp kicad % grep -R --include CMakeLists.txt 10.14 .
>
> ...show nothing, so it must come outside the kicad source tree.
> Any ideas?
>
> Cheers
> /Jonatan
>
> ___
> Mailing list: https://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] build failure

[Nick Østergaard]

You need to make sure you have a clean buid dir and try yo explicitly
disable oce and enable occt on your cmake configure line.

fre. 5. mar. 2021 11.48 skrev Jonatan Liljedahl :

> Ok, I'm now trying to build against OCE instead, as I'm sure that used
> to work before.
> I managed to have CMake find my homebrew installed OCE by setting
> OCE_DIR, however it fails here:
>
> make[2]: *** No rule to make target
>
> `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework',
> needed by `kicad/KiCad.app/Contents/MacOS/kicad2step'.  Stop.
>
> Because I don't have MacOSX10.14.sdk, but 10.15. The weird thing is
> that I have set CMake build variables to the correct path:
>
> CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.15
>
> CMAKE_OSX_SYSROOT:PATH=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
>
> But even then, kicad2step still has 10.14:
>
>
> utils/kicad2step/CMakeFiles/kicad2step.dir/build.make:kicad/KiCad.app/Contents/MacOS/kicad2step:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework
>
> Removing utils/kicad2step/CMakeFiles (and plugins/3d/oce/CMakeFiles),
> a recursive grep in my build directory tells me that there's NO
> mention of "MacOSX10.14" anywhere. But after I've run cmake, it shows
> up again in the above mentioned places!
>
> So where is this "MacOSX10.14" reference coming from?
>
> lijon@lijon-mbp kicad % grep -R --include CMakeLists.txt 10.14 .
>
> ...show nothing, so it must come outside the kicad source tree.
> Any ideas?
>
> Cheers
> /Jonatan
>
> ___
> Mailing list: https://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] [ciam...@posteo.net: [kicad-users] error compiling kicad branch 5.1]

[Nick Østergaard]

https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/lastSuccessfulBuild/artifact/pkglist_with_s.txt

lør. 20. feb. 2021 07.18 skrev Thomas Lei :

> Hi Nick,
>
> Can you give me pacman -Q output of your build environment for
> reference? I've failed to compile kicad debug build on my environment
> either. Thanks.
>
> Regards,
>
> Thomas
>
> On 2/20/21 3:04 AM, Nick Østergaard wrote:
> > It works for me now, at least,
> >
> > https://jenkins.simonrichter.eu/job/windows-kicad-msys2-5.1/237/console
> >
> > On Wed, 17 Feb 2021 at 14:12, Jon Evans  wrote:
> >> Hi Marco,
> >>
> >> I am not part of kicad-us...@groups.io but I am part of this list and
> I can fix the issue you mention, sorry about that...
> >>
> >> Best,
> >> Jon
> >>
> >> On Wed, Feb 17, 2021 at 7:34 AM Marco Ciampa 
> wrote:
> >>> Forwarded because nobody answered me...
> >>>
> >>> - Forwarded message from Marco Ciampa  -
> >>>
> >>> Date: Sun, 14 Feb 2021 15:38:24 +0100
> >>> From: Marco Ciampa 
> >>> To: kicad-us...@groups.io
> >>> Subject: [kicad-users] error compiling kicad branch 5.1
> >>>
> >>> Sorry to bother you but I do not understand what it's going on here
> >>> (on my computer) and I do not know who I can ask for a hint...
> >>>
> >>> All of a sudden my computer started to say this:
> >>>
> >>>
> ~/git/gitlab/kicad/branch-5.1/code/kicad/eeschema/bom_plugins.cpp:130:10:
> error: ‘BOM_GENERATOR_HANDLER’ has not been declared
> >>> wxString BOM_GENERATOR_HANDLER::getOutputExtension( const wxString&
> aHeader )
> >>> make[2]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/build.make:1191:
> eeschema/CMakeFiles/eeschema_kiface.dir/bom_plugins.cpp.o] Error 1
> >>>
> >>> KiCad master branch compiles just fine...
> >>>
> >>> My sysstem is Linux Unbuntu 20.04 64bit...
> >>>
> >>> Any hint?
> >>>
> >>> --
> >>>
> >>> Saluton,
> >>> Marco Ciampa
> >>>
> >>>
> >>> -=-=-=-=-=-=-=-=-=-=-=-
> >>> Groups.io Links: You receive all messages sent to this group.
> >>> View/Reply Online (#22982):
> https://groups.io/g/kicad-users/message/22982
> >>> Mute This Topic: https://groups.io/mt/80631239/2365677
> >>> Group Owner: kicad-users+ow...@groups.io
> >>> Unsubscribe:
> https://groups.io/g/kicad-users/leave/4830707/910801564/xyzzy [
> ciam...@posteo.net]
> >>> -=-=-=-=-=-=-=-=-=-=-=-
> >>>
> >>>
> >>> - End forwarded message -
> >>>
> >>> --
> >>>
> >>> 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] [ciam...@posteo.net: [kicad-users] error compiling kicad branch 5.1]

[Nick Østergaard]

It works for me now, at least,

https://jenkins.simonrichter.eu/job/windows-kicad-msys2-5.1/237/console

On Wed, 17 Feb 2021 at 14:12, Jon Evans  wrote:
>
> Hi Marco,
>
> I am not part of kicad-us...@groups.io but I am part of this list and I can 
> fix the issue you mention, sorry about that...
>
> Best,
> Jon
>
> On Wed, Feb 17, 2021 at 7:34 AM Marco Ciampa  wrote:
>>
>> Forwarded because nobody answered me...
>>
>> - Forwarded message from Marco Ciampa  -
>>
>> Date: Sun, 14 Feb 2021 15:38:24 +0100
>> From: Marco Ciampa 
>> To: kicad-us...@groups.io
>> Subject: [kicad-users] error compiling kicad branch 5.1
>>
>> Sorry to bother you but I do not understand what it's going on here
>> (on my computer) and I do not know who I can ask for a hint...
>>
>> All of a sudden my computer started to say this:
>>
>> ~/git/gitlab/kicad/branch-5.1/code/kicad/eeschema/bom_plugins.cpp:130:10: 
>> error: ‘BOM_GENERATOR_HANDLER’ has not been declared
>> wxString BOM_GENERATOR_HANDLER::getOutputExtension( const wxString& aHeader )
>> make[2]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/build.make:1191: 
>> eeschema/CMakeFiles/eeschema_kiface.dir/bom_plugins.cpp.o] Error 1
>>
>> KiCad master branch compiles just fine...
>>
>> My sysstem is Linux Unbuntu 20.04 64bit...
>>
>> Any hint?
>>
>> --
>>
>> Saluton,
>> Marco Ciampa
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Groups.io Links: You receive all messages sent to this group.
>> View/Reply Online (#22982): https://groups.io/g/kicad-users/message/22982
>> Mute This Topic: https://groups.io/mt/80631239/2365677
>> Group Owner: kicad-users+ow...@groups.io
>> Unsubscribe: https://groups.io/g/kicad-users/leave/4830707/910801564/xyzzy 
>> [ciam...@posteo.net]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>> - End forwarded message -
>>
>> --
>>
>> 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

Re: [Kicad-doc-devs] Problem building docs on Windows

[Nick Østergaard]

I don't think anyone really tested it on windows before. There are
probably some subtle issues.

Sort of related is the wish to ditch asciidoc in favor of asciidoctor only.

https://gitlab.com/kicad/services/kicad-doc/-/issues/638

On Sun, 14 Feb 2021 at 15:52, Jon Evans  wrote:
>
> Anyone have tips for building the documentation on Windows?
>
> I have tried the following in msys2 (from a ./build directory)
>
> cmake -G "MinGW Makefiles" -DLANGUAGES=en -DBUILD_FORMATS=html
> make
>
> Both cmake and make run with no errors, but no output is present in the build 
> folder.
> Make exits very quickly with little output:
>
> $ make
> Microsoft Windows [Version 10.0.19041.804]
> (c) 2020 Microsoft Corporation. All rights reserved.
>
> The above workflow is working fine for me on Linux (using -GNinja instead of 
> makefiles)
> Has anyone seen this before?
>
> Thanks,
> Jon
> --
> Mailing list: https://launchpad.net/~kicad-doc-devs
> Post to : kicad-doc-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-doc-devs
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] ngspice-34

[Nick Østergaard]

Hi Holger,

Whats up with this big diff from 33 to 34?

https://github.com/msys2/MINGW-packages/pull/7867#issuecomment-770786574

Nick

On Sat, 30 Jan 2021 at 17:57, Wayne Stambaugh  wrote:
>
> 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

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

Re: [Kicad-developers] Linux Packaging heads up

[Nick Østergaard]

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

On Wed, 20 Jan 2021 at 18:34, Seth Hillbrand  wrote:

> This is a heads up for our Linux packagers that the launcher locations
> have changed in the master branch.
>
> You will now find the .desktop launcher files in the build directory,
> under `resources/linux/launchers/`
>
> -Seth
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@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] Build problem of current master tree

[Nick Østergaard]

FYI, there are still generated files in the source which are also checked
in to the source tree:

After a make clean:
deleted:../eeschema/dialogs/dialog_bom_help_md.h
deleted:../pcb_calculator/attenuators/bridget_tee_formula.h
deleted:../pcb_calculator/attenuators/pi_formula.h
deleted:../pcb_calculator/attenuators/splitter_formula.h
deleted:../pcb_calculator/attenuators/tee_formula.h
deleted:../pcb_calculator/eserie_help.h
deleted:../pcb_calculator/tracks_width_versus_current_formula.h


On Sat, 2 Jan 2021 at 17:03, Seth Hillbrand  wrote:

> Hello Carsten-
>
> We agree with you.  This is why we moved the generated files to the build
> tree and out of the source tree.  But legacy files in the source tree are
> still considered first, so older build directories need the fix-up that
> Jeff mentioned.  We might be able to get around this by changing the
> .gitignore but we haven't tested that.
>
> Regards-
> Seth
>
> On Sat, Jan 2, 2021 at 7:07 AM Carsten Schoenert 
> wrote:
>
>> Hello Jeff,
>>
>> Am 02.01.21 um 15:45 schrieb Jeff Young:
>> > Hi Carsten,
>> >
>> > Known problem when building 5.99 in a tree that used to hold 5.1.
>> >
>> > Try:
>> >
>> > cd include
>> > rm *_lexer.h
>> ahh, yes that fixed the build.
>>
>> But I see the build of additional required files within the source tree
>> rather as issue if I build out of tree. Is this behavior a problem of
>> cmake or more a miss configuration of the build controlling?
>>
>> --
>> Mit freundlichen Grüßen
>> Carsten Schönert
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.comi...@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] Origin Transforms for the Footprint Editor

[Nick Østergaard]

The list is not dead.

On Thu, 31 Dec 2020 at 05:53, 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

[Nick Østergaard]

The emails on this mailing list is the "heads up". Anyhow, I don't
think we need to change anything other than maybe set an _rc1 tag when
announcing an imminent stable tag, for every stable tag -- big or
small. And make sure to have a strict string freeze. That will allow
translations to flow in since that _rc1.

On Wed, 23 Dec 2020 at 13:34, Christoph Moench-Tegeder
 wrote:
>
> ## Nick Østergaard (oe.n...@gmail.com):
>
> > By having the release announcement, it is easier to use that as a
> > reference when users are flagging packages in various distros.
>
> Even more: some distros - I'm writing as the maintainer of FreeBSD's
> KiCAD packages - are waiting for the release announcement before
> shipping the update. In the past, there were some unfortunate cases
> where distfiles had to be re-rolled, causing much hassle and version
> bumps; and I understood this was a situation to avoid.
>
> Perhaps it would be nice to have a seperate "heads up, you can start
> packaging now" announcement to have releases ready from day one on
> more platforms.
> Or we just don't lose any sweat over a few days delay. Hey, there's
> a lot of volunteer work going on here, and at any given time someone
> will be on vacation, busy or otherwise unavailable for whatever reason.
> And then we don't really need coordinated security releases - yes,
> complex file format and file exchange across organisations, but then
> KiCAD is not running internet-facing on half of the world's infrastructure.
>
> Also, these bugfix releases are mostly low-effort for packagers:
> with 5.1.9, I only had to bump the versions - no additional
> patching required.
>
> Regards,
> Christoph
>
> --
> Spare Space

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

[Nick Østergaard]

This is a distributed effort. We can't wait to announce it untill all habe
bumped the pkgver, this could mean that we have builds released months
before we even announced it and it will confuse users. Having "major"
platforms covered and then announce is a good comprimise. Two of those
don't are not released via a native package manager.

ons. 23. dec. 2020 11.20 skrev Carsten Schoenert :

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

Re: [Kicad-developers] 5.1.9 tagged for release

[Nick Østergaard]

Hi

Yes, of course. I was not aware that there were any string changes,
but I didn't really check it either.

Nick

On Wed, 23 Dec 2020 at 10:34, Константин Барановский
 wrote:
>
> Please next time provide the ability for the translators to update the 
> translations before tagging.
>
> вт, 22 дек. 2020 г. в 22:15, 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
>
> ___
> Mailing list: https://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

[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". I am not trying to
exclude you as a kicad maintainer. Your feedback is always valuable
concise :)

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.

Nick

On Wed, 23 Dec 2020 at 09:27, Carsten Schoenert  wrote:
>
> Hi,
>
> Am 22.12.20 um 23:01 schrieb Nick Østergaard:
> > 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.
>
> please do also remember that there is more out there than the builds
> done by KiCad team members. Especially right now one day before the
> X-mas days. I see no need to rush up things more than on other releases
> too. Providing new packages is one part, don't forget that in the
> western world the users of such releases will be too on X-mas holidays
> so the gain would be rather small.
>
> I personally have slightly different interests than going immediately
> over to do packaging work.
>
> For me the time span Wayne has given is the right approach and don't
> brings in some none useful pressure.
>
> --
> 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

Re: [Kicad-developers] 5.1.9 tagged for release

[Nick Østergaard]

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  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
> 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.99.0-7573-ge07848d887 Warning: Missing ngspice + problems seting up a working development environment

[Nick Østergaard]

Hi Stefan

(You did not use reply all, so I re-added the list on cc)

Ok. I was slightly confused because you mentioned msys2 and vcpkg at
the same time. They are not compatible.

Normally with cmake the procedure is to configure the project first,
often a makefile generator is used, which means you use the make
command. If you want to use msvc (visual studio) and vcpkg you use
follow the instructions, I have used cmake-gui before. I have not
really tried to run anything for a dev environment under msvc, but I
gues it is possible, but remember usually you need to run the install
target to make sure you got all the proper binaries whereever you run
it from.

But you should simply be able to follow the instructions you probably
already found on
https://docs.kicad.org/doxygen/md_Documentation_development_compiling.html#vs_build

I am not sure how to configure that properly for runtime, but I know
other people are doing it so it is possible, but there may be some
custom configuration needed.

Nick

On Sat, 19 Dec 2020 at 21:13, star7  wrote:
>
> My goal is to be able to understand parts of the code, modify, debug, search 
> errors and doing experiments. In the future testing and proposing new 
> features.
>
> So the nightly builds could help me in cases of real errors, they are 
> possibly removed in nightly builds.
>
> Off course I had a look on the source code before I compiled it. But I wanted 
> to have a complete development environment to get a chance to easier 
> understand parts of the code. I have a working compile environment now with 
> mingw64. The compiled Code runs very well within mingw64. It does not work 
> outside of mingw64. Some installation steps are missing.
>
> Looking on the source code with an editor only is to cumbersome. So I 
> installed Visual Studio. My next goal was to get the project inside of Visual 
> Studio as to have a much easier look on the code, much more as with a pure 
> editor. I am not stuck to Visual Studio. Something like Eclipse would be as 
> good. But my problem is in the moment to get the project under CMake in the 
> Visual Studio 2019 environment. Might be Visual Studio 2017 would do the job, 
> might be the problems come with Visual Studio 2019 or the vcpkg version. I 
> did not try. Also I could move the hole thing from Windows 10 to a Linux 
> environment. Up to now I only used KiCad (designed and produced successfully 
> some PCB designs now in working products; !!! Many thanks by the way to this 
> positive experience to all the contributors to KiCad!!!, Before I worked with 
> proprietary Software) and did this on Windows. But if development of the 
> KiCad Code is easier on Linux I could move to Linux for this target.
>
>
> best wishes
>
>
> Stefan
>
>
> On 12/18/20 4:28 PM, Nick Østergaard wrote:
>
> What is your goal?
>
> fre. 18. dec. 2020 12.00 skrev Stefan Auracher :
>>
>> I started KiCad from within msys like
>> /d/proj/msys_mingw/KiCad_git_repo/kicad/build/release/kicad/kicad.exe
>>
>> And within this build tree in
>> D:\proj\msys_mingw\KiCad_git_repo\kicad\build\release
>>
>> I don't have the directory structure as in an regular KiCad installation
>> like C:\auracher\pgr\eda\KiCad\kicad-5.1.6_1-x86_64\KiCad with
>>
>> the subdirectories bin lib share ssl. So there is no directory
>> kicad/lib/ngspice/
>>
>>
>> Sorry I am a beginner in this. I Think I am missing the installation
>> steps from the build tree to the real independant installation of KiCad
>> outside of msys/mingw
>>
>> I would expect that this should be collected to
>> D:\proj\msys_mingw\KiCad_git_repo\kicad\out. But also ther are no
>> subdirectorys bin lib share ssl. Do I need another
>>
>> make target?
>>
>>
>> How can I do that. Or what other possibilities do I have to work with
>> the KiCad Code ?
>>
>> Or is it a silly idea to work on windows. Is it easier on Linux?
>>
>>
>> Thanks for any help
>>
>>
>> Besides this I have a second problem.
>>
>> On Windows 10 I installed Microsoft Visual Studio C++ 2019 to get an IDE
>> for the kiCad Source
>>
>> Also I compiled the vcpg packages with
>>
>> .\vcpkg install boost
>> .\vcpkg install cairo
>> .\vcpkg install curl
>> .\vcpkg install glew
>> .\vcpkg install gettext
>> .\vcpkg install glm
>> .\vcpkg install icu
>> .\vcpkg install ngspice
>> .\vcpkg install opencascade
>> .\vcpkg install opengl
>> .\vcpkg install openssl
>> .\vcpkg install python3
>> .\vcpkg install wxwidgets
>> .\vcpkg install zlib
>>
>> as desribed in
>> https://docs.kicad.org/doxygen/md_Documentat

Re: [Kicad-developers] 5.99.0-7573-ge07848d887 Warning: Missing ngspice + problems seting up a working development environment

[Nick Østergaard]

What is your goal?

fre. 18. dec. 2020 12.00 skrev Stefan Auracher :

> I started KiCad from within msys like
> /d/proj/msys_mingw/KiCad_git_repo/kicad/build/release/kicad/kicad.exe
>
> And within this build tree in
> D:\proj\msys_mingw\KiCad_git_repo\kicad\build\release
>
> I don't have the directory structure as in an regular KiCad installation
> like C:\auracher\pgr\eda\KiCad\kicad-5.1.6_1-x86_64\KiCad with
>
> the subdirectories bin lib share ssl. So there is no directory
> kicad/lib/ngspice/
>
>
> Sorry I am a beginner in this. I Think I am missing the installation
> steps from the build tree to the real independant installation of KiCad
> outside of msys/mingw
>
> I would expect that this should be collected to
> D:\proj\msys_mingw\KiCad_git_repo\kicad\out. But also ther are no
> subdirectorys bin lib share ssl. Do I need another
>
> make target?
>
>
> How can I do that. Or what other possibilities do I have to work with
> the KiCad Code ?
>
> Or is it a silly idea to work on windows. Is it easier on Linux?
>
>
> Thanks for any help
>
>
> Besides this I have a second problem.
>
> On Windows 10 I installed Microsoft Visual Studio C++ 2019 to get an IDE
> for the kiCad Source
>
> Also I compiled the vcpg packages with
>
> .\vcpkg install boost
> .\vcpkg install cairo
> .\vcpkg install curl
> .\vcpkg install glew
> .\vcpkg install gettext
> .\vcpkg install glm
> .\vcpkg install icu
> .\vcpkg install ngspice
> .\vcpkg install opencascade
> .\vcpkg install opengl
> .\vcpkg install openssl
> .\vcpkg install python3
> .\vcpkg install wxwidgets
> .\vcpkg install zlib
>
> as desribed in
> https://docs.kicad.org/doxygen/md_Documentation_development_compiling.html
>
> and did the other steps documented there.
>
> This all worked very well as described in the above kiCad Docu.
>
>
> After starting Visual Studio 2019 I tried to build the project via
> CMake. I opened:
>
> D:\proj\msys_mingw\KiCad_git_repo\kicad\CmakeLists.txt
>
> I had to modify the file:
>
> D:\proj\msys_mingw\KiCad_git_repo\kicd\CMakeLists.txt
>
> I inserted at the top
>
>
> set( GLEW_INCLUDE_DIR
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/glew_x86-windows/include/" )
> set( GLEW_LIBRARY
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/glew_x86-windows/lib" )
>
> set ( GLM_INCLUDE_DIR
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/glm_x86-windows/include" )
> set ( GLM_VERSION "0.9.9.8" )
>
> set ( ZLIB_LIBRARY
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/zlib_x86-windows/lib" )
> set ( ZLIB_INCLUDE_DIR
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/zlib_x86-windows/include")
>
> set ( CURL_LIBRARY
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/curl_x86-windows/lib" )
> set ( CURL_INCLUDE_DIR
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/curl_x86-windows/include")
>
> set ( CAIRO_LIBRARIES
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/cairo_x86-windows/lib")
> set ( CAIRO_INCLUDE_DIR
> "/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/cairo_x86-windows/include")
> set ( CAIRO_RELEASE "1.16.0" )
>
> set( PKG_CONFIG_EXECUTABLE "/c/msys64/mingw64/bin/pkgconf.exe" )
>
>
> This eliminated some errors
>
>
> But I still have the following problem
>
> 1> [CMake] -- KiCad install dir:
> 
> 1> [CMake] -- Check for installed GLEW -- found
> 1> [CMake] -- Check for installed ZLIB -- found
> 1> [CMake] -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
> 1> [CMake] CMake Error at CMakeModules/FindCairo.cmake:145 (file):
> 1> [CMake]   file failed to open for reading (No such file or directory):
> 1> [CMake]
> 1> [CMake]
>
> /d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/cairo_x86-windows/include/cairo-version.h
> 1> [CMake] Call Stack (most recent call first):
>
> ...
>
>
> many thanks for teh patience
>
>
> Stefan
>
>
> On 12/16/20 12:14 PM, Holger Vogt wrote:
> > Correction:
> >
> > analog.com and 5 other *.cm files should reside in kicad/lib/ngspice/
> >
> >
> > ___
> > Mailing list: https://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 Dropping 32-bit support

[Nick Østergaard]

Correct, but that is not the case right now. It just means that we should
be able to update MSYS2 packages just fine without trouble on the builder
server.

On Wed, 11 Nov 2020 at 13:30, Mark Roszko  wrote:

> >It does mention that it is just the environment that is 64 bit only, but
> not the mingw toolchains, so I don't really think this affects us.
>
> It does,* just not right now. *The writing is on the wall for 32-bit x86.
> Microsoft officially has marked 32-bit Windows 10 EOL and I believe it's
> being dropped by Microsoft towards the end of next year (no more security
> updates).
> It would be crazy for MSYS2 not to eventually drop the packages themselves
> as well.
>
> On Tue, Nov 10, 2020 at 6:13 PM Nick Østergaard  wrote:
>
>> On further review of the msys2 news page that states:
>>
>> /quote
>> 2020-05-17 - 32-bit MSYS2 no longer actively supported
>> 32-bit mingw-w64 packages are still supported, this is about the POSIX
>> emulation layer, i.e. the runtime, Bash, MinTTY...
>>
>> After this date, we don't plan on building updated msys-i686 packages nor
>> releasing i686 installers anymore. This is due to increasingly frustrating
>> difficulties with limited 32-bit address space, high penetration of 64-bit
>> systems and Cygwin (our upstream) starting their way to drop 32-bit support
>> as well.
>> /quote
>>
>> It does mention that it is just the environment that is 64 bit only, but
>> not the mingw toolchains, so I don't really think this affects us.
>>
>> Nick
>>
>> On Wed, 5 Aug 2020 at 01:10, Wayne Stambaugh 
>> wrote:
>>
>>> On 8/4/20 4:43 PM, Seth Hillbrand wrote:
>>> >
>>> >
>>> > On Tue, Aug 4, 2020 at 4:41 AM Wayne Stambaugh >> > <mailto:stambau...@gmail.com>> wrote:
>>> >
>>> > On 8/3/20 9:19 PM, Seth Hillbrand wrote:
>>> > >
>>> > >
>>> > > On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh
>>> > mailto:stambau...@gmail.com>
>>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
>>> wrote:
>>> > >
>>> > > I'm not ready to drop 32 bit builds for V6.  I still think
>>> > there are
>>> > > enough 32-bit users to warrant supporting it for one more
>>> > release.  It's
>>> > > something we can discuss for V7.
>>> > >
>>> > >
>>> > > If we keep 32 bit builds on mingw2, does that mean that we
>>> freeze all
>>> > > packages at their current versions?  It might be problematic to
>>> keep
>>> > > different package versions for different architectures.
>>> >
>>> > I'm assuming you mean dependency packages so yes we would continue
>>> to
>>> > build 32 bit windows versions using the current package versions.
>>> If
>>> > someone figures out how to get wxPhoenix to build, then we could
>>> bump to
>>> > wxWidgets 3.1.x and Python 3.x.
>>> >
>>> >
>>> > Do you envision building 32-bit and 64-bit with different package
>>> versions?
>>>
>>> I hope not but we may have to bite the bullet if we can't get all of the
>>> packaging up to snuff be it msys2 or msvc builds.
>>>
>>> >
>>> > -Seth
>>> >
>>> >
>>> > --
>>> > KiCad Services Corporation Logo
>>> > Seth Hillbrand
>>> > *Lead Developer*
>>> > +1-530-302-5483‬ 
>>> > Davis, 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
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : 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] MSYS2 Dropping 32-bit support

[Nick Østergaard]

On further review of the msys2 news page that states:

/quote
2020-05-17 - 32-bit MSYS2 no longer actively supported
32-bit mingw-w64 packages are still supported, this is about the POSIX
emulation layer, i.e. the runtime, Bash, MinTTY...

After this date, we don't plan on building updated msys-i686 packages nor
releasing i686 installers anymore. This is due to increasingly frustrating
difficulties with limited 32-bit address space, high penetration of 64-bit
systems and Cygwin (our upstream) starting their way to drop 32-bit support
as well.
/quote

It does mention that it is just the environment that is 64 bit only, but
not the mingw toolchains, so I don't really think this affects us.

Nick

On Wed, 5 Aug 2020 at 01:10, Wayne Stambaugh  wrote:

> On 8/4/20 4:43 PM, Seth Hillbrand wrote:
> >
> >
> > On Tue, Aug 4, 2020 at 4:41 AM Wayne Stambaugh  > > wrote:
> >
> > On 8/3/20 9:19 PM, Seth Hillbrand wrote:
> > >
> > >
> > > On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >>
> wrote:
> > >
> > > I'm not ready to drop 32 bit builds for V6.  I still think
> > there are
> > > enough 32-bit users to warrant supporting it for one more
> > release.  It's
> > > something we can discuss for V7.
> > >
> > >
> > > If we keep 32 bit builds on mingw2, does that mean that we freeze
> all
> > > packages at their current versions?  It might be problematic to
> keep
> > > different package versions for different architectures.
> >
> > I'm assuming you mean dependency packages so yes we would continue to
> > build 32 bit windows versions using the current package versions.  If
> > someone figures out how to get wxPhoenix to build, then we could
> bump to
> > wxWidgets 3.1.x and Python 3.x.
> >
> >
> > Do you envision building 32-bit and 64-bit with different package
> versions?
>
> I hope not but we may have to bite the bullet if we can't get all of the
> packaging up to snuff be it msys2 or msvc builds.
>
> >
> > -Seth
> >
> >
> > --
> > KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬ 
> > Davis, 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] New Build Dependency

[Nick Østergaard]

For archlinux that is...

On Mon, 9 Nov 2020 at 20:08, Nick Østergaard  wrote:

> Mm, I am not sure exactly why, but I have had zlib as a build dependency
> for a looong time.
>
> On Tue, 18 Aug 2020 at 00:56, Seth Hillbrand  wrote:
>
>> As promised, the MR is:
>>
>> https://gitlab.com/kicad/code/kicad/-/merge_requests/359
>>
>> You can click the "Check out branch" to get the branch to test
>>
>> Best-
>> Seth
>>
>> On Mon, Aug 17, 2020 at 9:44 AM Seth Hillbrand 
>> wrote:
>>
>>> I should have the MR ready today and I'll send along the branch info.
>>>
>>> Best-
>>> Seth
>>>
>>> On Mon, Aug 17, 2020 at 9:38 AM Adam Wolf 
>>> wrote:
>>>
>>>> I love the heads up! Thanks!
>>>>
>>>> Is there a sample branch I can try before it's merged into master?
>>>>
>>>> Adam
>>>>
>>>> On Mon, Aug 17, 2020 at 10:23 AM Seth Hillbrand 
>>>> wrote:
>>>>
>>>>> Hi Folks (Packagers especially)-
>>>>>
>>>>> We are adding a new build dependency to KiCad in the next few days.
>>>>> zlib1g-dev (on debian) will be required to support stream
>>>>> compression/decompression of model files.
>>>>>
>>>>> Please update your build environment to include this (if it doesn't
>>>>> already).  The critical file for KiCad is "zlib.h" in one of the standard
>>>>> include locations.  Let me know if you have any questions.
>>>>>
>>>>> Best-
>>>>> Seth
>>>>>
>>>>> --
>>>>> [image: KiCad Services Corporation Logo]
>>>>> Seth Hillbrand
>>>>> *Lead Developer*
>>>>> +1-530-302-5483‬ <+12126039372>
>>>>> Davis, CA
>>>>> www.kipro-pcb.comi...@kipro-pcb.com
>>>>>
>>>>
>>>
>>> --
>>> [image: KiCad Services Corporation Logo]
>>> Seth Hillbrand
>>> *Lead Developer*
>>> +1-530-302-5483‬ <+12126039372>
>>> Davis, CA
>>> www.kipro-pcb.comi...@kipro-pcb.com
>>>
>>
>>
>> --
>> [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ <+12126039372>
>> Davis, CA
>> www.kipro-pcb.comi...@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] New Build Dependency

[Nick Østergaard]

Mm, I am not sure exactly why, but I have had zlib as a build dependency
for a looong time.

On Tue, 18 Aug 2020 at 00:56, Seth Hillbrand  wrote:

> As promised, the MR is:
>
> https://gitlab.com/kicad/code/kicad/-/merge_requests/359
>
> You can click the "Check out branch" to get the branch to test
>
> Best-
> Seth
>
> On Mon, Aug 17, 2020 at 9:44 AM Seth Hillbrand  wrote:
>
>> I should have the MR ready today and I'll send along the branch info.
>>
>> Best-
>> Seth
>>
>> On Mon, Aug 17, 2020 at 9:38 AM Adam Wolf 
>> wrote:
>>
>>> I love the heads up! Thanks!
>>>
>>> Is there a sample branch I can try before it's merged into master?
>>>
>>> Adam
>>>
>>> On Mon, Aug 17, 2020 at 10:23 AM Seth Hillbrand 
>>> wrote:
>>>
 Hi Folks (Packagers especially)-

 We are adding a new build dependency to KiCad in the next few days.
 zlib1g-dev (on debian) will be required to support stream
 compression/decompression of model files.

 Please update your build environment to include this (if it doesn't
 already).  The critical file for KiCad is "zlib.h" in one of the standard
 include locations.  Let me know if you have any questions.

 Best-
 Seth

 --
 [image: KiCad Services Corporation Logo]
 Seth Hillbrand
 *Lead Developer*
 +1-530-302-5483‬ <+12126039372>
 Davis, CA
 www.kipro-pcb.comi...@kipro-pcb.com

>>>
>>
>> --
>> [image: KiCad Services Corporation Logo]
>> Seth Hillbrand
>> *Lead Developer*
>> +1-530-302-5483‬ <+12126039372>
>> Davis, CA
>> www.kipro-pcb.comi...@kipro-pcb.com
>>
>
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@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] A few run-time problems on kicad-git build on Slackware64-current Linux

[Nick Østergaard]

Tom, did you create a new build dir when switching from gtk2 to gtk3?

On Sat, 7 Nov 2020 at 16:32, Mark Roszko  wrote:

> The change wouldn't be in KiCad. It's the behavior of your window manager.
> Apparently some Linux WMs send mouse events to windows and controls without
> focus and others don't. KiCad traditionally assumed it wouldn't receive
> mouse events without being activated.
>
> On Fri, Nov 6, 2020 at 11:33 PM Tom Crane 
> wrote:
>
>> Thanks for the explanation.  I noticed these problems on moving from
>> gtk2 to gtk3 builds.  Is this where these changes were made?
>>
>> Are there likely to be any user selectable runtime options added to Kicad
>> to ameliorate these problems?
>>
>> Tom Crane.
>>
>> On Thu, 5 Nov 2020, Mark Roszko wrote:
>>
>> > Your issues in (1) are by design.
>> >
>> > Whether that design is correct or not is another story.
>> >
>> > I actually removed that behavior on Windows because Microsoft has a
>> stable api to determine top level window for focus.
>> > Linux does not and GDK used to be but with the fragmented x11/wayland
>> mess, they removed the api call support to determine top level window.
>> >
>> > And removing the focus calls instead are going to lead a rabbit hole of
>> things not working like hotkeys.
>> >
>> > On Thu, Nov 5, 2020 at 9:14 PM Tom Crane 
>> wrote:
>> >   On Thu, 5 Nov 2020, Nick Østergaard wrote:
>> >
>> >   Thanks again for the quick follow-up.
>> >
>> >   > Did you install wxpython (phoenix) with pip?
>> >   No.
>> >
>> >   > you have some python stuff in ~/.local.
>> >
>> >   I have uploaded the modified SlackBuild scripts I used to build
>> both the
>> >   Slackware wxGTK3 package (wxWidgets/Phoenix) and the wxPython4
>> package at
>> >   https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/ in case the
>> problem
>> >   lies with either.
>> >
>> >   >
>> >   > Maybe just try to clear that out completely, or explicitly
>> set PYTHONPATH to the site-packages path of your install location?
>> >
>> >   Just tried removing ~/.local and then,
>> >
>> >   export PYTHONPATH=/usr/lib64/python3.8/site-packages/
>> >
>> >   In both cases the scripting console error remains the same.
>> >
>> >   Thanks
>> >   Tom.
>> >
>> >
>> >   >
>> >   > On Thu, 5 Nov 2020 at 20:51, Tom Crane <
>> tpcki...@mklab.ph.rhul.ac.uk> wrote:
>> >   >   Thanks for the quick response.  In the past I have been
>> bitten by old
>> >   >   libraries in non-standard places derailing other
>> application builds but
>> >   >   can't see anything obviously amiss here.
>> >   >
>> >   >   My $LD_LIBRARY_PATH EV is empty.  I checked where
>> ldconfig looks and could
>> >   >   not see anything incriminating outside the standard
>> install locations for
>> >   >   Slackware distros (/usr/lib64 & /lib64).  See
>> >   >   https://www.mklab.rhul.ac.uk/~tom/kicad/ldconfig-p.txt
>> for the O/P of
>> >   >   'ldconfig -p'.
>> >   >
>> >   >   I also tried stracing open* calls in pcbnew.  See
>> >   >
>> https://www.mklab.rhul.ac.uk/~tom/kicad/strace-pcbnew2.lis.  Again
>> nothing
>> >   >   jumped out as problematic.  All calls to Python related
>> files seem to
>> >   >   reference python v.3.8 ones as expected.
>> >   >
>> >   >   The build scripts I am using are release version
>> 'SlackBuild' scripts I've
>> >   >   hacked to use the git development code.  See
>> >   >   https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/.
>> The tom_build.sh
>> >   >   script calls the main build script kicad-git.SlackBuild.
>> >   >
>> >   >   Thanks
>> >   >   Tom
>> >   >
>> >   >   On Thu, 5 Nov 2020, Nick Østergaard wrote:
>> >   >
>> >   >   > Are you using a build script? If so please link it.
>> >   >   > Also check if you partially installed in multiple
>> locations, sucha as where ldconfig looks and echo LD_LIBRARY_PATH from yo

Re: [Kicad-developers] Torrent downloads

[Nick Østergaard]

Hi

Can it have multiple webseed locations?

fre. 6. nov. 2020 02.40 skrev Andrew Lutsenko :

> Hi Nick,
>
> Is there anything else I can help with here?
> I see 5.1.8 update is released already.
>
> On Thu, Oct 1, 2020 at 3:48 AM Andrew Lutsenko 
> wrote:
>
>> Oh, I did verify that, sorry I wasn't clear. It definitely works.
>>
>> On Thu, Oct 1, 2020, 02:00 Nick Østergaard  wrote:
>>
>>> I was implicitly hoping you could explicitly verify for me that using
>>> the OSDN url would support range requests.  :)
>>>
>>> tor. 1. okt. 2020 09.09 skrev Andrew Lutsenko :
>>>
>>>> Yes, it does. I think it will work with any http server supporting
>>>> range requests.
>>>> You can have multiple webseed urls in the torrent as well, just pass
>>>> --urlList flag multiple times.
>>>>
>>>> On Wed, Sep 30, 2020 at 11:28 PM Nick Østergaard 
>>>> wrote:
>>>>
>>>>> Does it also work with the OSDN mirror?
>>>>>
>>>>> tor. 1. okt. 2020 02.42 skrev Andrew Lutsenko :
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I recall we had this discussion before about providing torrent files
>>>>>> for release downloads to reduce the slowdown related to rush traffic. it
>>>>>> didn't go far mainly because of resources needed to maintain separate
>>>>>> torrent seeding infrastructure.
>>>>>>
>>>>>> I recently discovered that p2p torrent protocol supports webseeding,
>>>>>> a feature that allows torrent clients to download chunks of files from
>>>>>> standard http/ftp servers. It's implemented by most major torrent client
>>>>>> software. This way the file is initially seeded by the http server but as
>>>>>> more and more peers get the data the swarm takes over most of the traffic
>>>>>> load.
>>>>>>
>>>>>> I tried it out and it works nicely with kicad's existing http
>>>>>> download resources so there is no need to have separate infra for 
>>>>>> torrents!
>>>>>>
>>>>>> Would you be open to adding this?
>>>>>> All that is needed is put .torrent files either on kicad website or
>>>>>> even better, on the https://kicad-downloads.s3.cern.ch/ server next
>>>>>> to the installers and add a link to them.
>>>>>>
>>>>>> I've generated torrents with webseed information for 5.1.7 here:
>>>>>> https://forum.kicad.info/t/torrents-for-kicad-stable-version-5-1-7-win-and-osx/16609/14?u=qu1ck
>>>>>>
>>>>>> To do it yourself in the future is trivial, here is the bash script I
>>>>>> used to create the files:
>>>>>>
>>>>>> for f in *.exe ; do
>>>>>> create-torrent "$f" -o $f.torrent --urlList
>>>>>> https://kicad-downloads.s3.cern.ch/windows/stable/
>>>>>> done
>>>>>> for f in *.dmg ; do
>>>>>> create-torrent "$f" -o $f.torrent --urlList
>>>>>> https://kicad-downloads.s3.cern.ch/osx/stable/
>>>>>> done
>>>>>>
>>>>>> It depends on create-torrent utility that you can get by running "npm
>>>>>> install -g create-torrent"
>>>>>>
>>>>>> I can also make a merge request on the kicad website if someone will
>>>>>> upload the torrent files to the s3 server.
>>>>>>
>>>>>> Regards,
>>>>>> Andrew
>>>>>> ___
>>>>>> Mailing list: https://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] A few run-time problems on kicad-git build on Slackware64-current Linux

[Nick Østergaard]

Did you install wxpython (phoenix) with pip? you have some python stuff in
~/.local.

Maybe just try to clear that out completely, or explicitly set PYTHONPATH
to the site-packages path of your install location?

On Thu, 5 Nov 2020 at 20:51, Tom Crane  wrote:

> Thanks for the quick response.  In the past I have been bitten by old
> libraries in non-standard places derailing other application builds but
> can't see anything obviously amiss here.
>
> My $LD_LIBRARY_PATH EV is empty.  I checked where ldconfig looks and could
> not see anything incriminating outside the standard install locations for
> Slackware distros (/usr/lib64 & /lib64).  See
> https://www.mklab.rhul.ac.uk/~tom/kicad/ldconfig-p.txt for the O/P of
> 'ldconfig -p'.
>
> I also tried stracing open* calls in pcbnew.  See
> https://www.mklab.rhul.ac.uk/~tom/kicad/strace-pcbnew2.lis.  Again
> nothing
> jumped out as problematic.  All calls to Python related files seem to
> reference python v.3.8 ones as expected.
>
> The build scripts I am using are release version 'SlackBuild' scripts I've
> hacked to use the git development code.  See
> https://www.mklab.rhul.ac.uk/~tom/kicad/SlackBuild/.  The tom_build.sh
> script calls the main build script kicad-git.SlackBuild.
>
> Thanks
> Tom
>
> On Thu, 5 Nov 2020, Nick Østergaard wrote:
>
> > Are you using a build script? If so please link it.
> > Also check if you partially installed in multiple locations, sucha as
> where ldconfig looks and echo LD_LIBRARY_PATH from your runtime env.
> >
> > Nicl
> >
> > tor. 5. nov. 2020 16.26 skrev Tom Crane :
> >   I have been using recent builds for the past few weeks.  They are
> usable
> >   but I have a couple of outstanding problems which I'm not sure how
> to
> >   diagnose/fix.
> >
> >   (1) I have strange behaviours with open Kicad application windows.
> For
> >   example I have a Kicad project, eeschema and pcbnew windows open
> on a
> >   single display. If I let the mouse pointer move from the project
> window to
> >   the eeschema or pcbnew window then input focus immediately
> transfers to
> >   the eeschema or pcbnew window.  This is without touching any mouse
> >   buttons.
> >
> >   Similarly moving the mouse pointer back to the project window has
> no
> >   effect (as it should) but moving it between the eeschema and pcbnew
> >   windows transfers input focus as soon as it enters the other
> window.
> >
> >   There is a similar effect when moving between unrelated (eg. an
> xterm)
> >   windows and either eeschema or pcbnew.  Here the eeschema or
> pcbnew window
> >   does not receive input focus (which remains with the xterm as it
> should)
> >   but the eeschema or pcbnew window does move up the window
> 'stack'.  eg. if
> >   I have an eeschema windows partially covered by a pcbnew window,
> partially
> >   covered by an xterm window which has input focus, then moving the
> mouse
> >   pointer from the xterm to an uncovered section of the eeschema
> window will
> >   cause it to move up the stack and fully cover the pcbnew window.
> >
> >   I get this behaviour with both accelerated and standard graphics
> set.
> >
> >   The above behaviours were observed with the KDE desktop.  I get
> similar
> >   behaviour with my usual window manager (fvwm95) except that the
> window
> >   focus never switches.
> >
> >   I also find that when invoking the DRC check that the DRC Control
> Window
> >   disappears immediately after popping-up and has to be
> 're-acquired' by
> >   clicking the pcbnew tab on the fvwm95 taskbar.  I suspect this is
> another
> >   facet of these window problems.
> >
> >   I don't get this behaviour with any other applications but Kicad
> is the
> >   only wxWidgets/wxPython based one I currently use and so the
> problem could
> >   there at the library level rather than within Kicad on my
> >   distro/Kicad+dependencies build.
> >
> >   None of this is a show-stopper but it is irritating.
> >
> >   Any ideas?
> >
> >
> >   (2) I am unable to use any Kicad scripts.  Clicking on pcbnew -->
> Tools
> >   --> scripting console I get the "Error: unable to create Python
> Console"
> >   pop-up and the following on the console,
> >
> > Traceback (most recent call last):
> >  File "", line 1, in 
> >  File "/usr/share/kicad/scripting/ki

Re: [Kicad-developers] A few run-time problems on kicad-git build on Slackware64-current Linux

[Nick Østergaard]

Are you using a build script? If so please link it.

Also check if you partially installed in multiple locations, sucha as where
ldconfig looks and echo LD_LIBRARY_PATH from your runtime env.

Nicl

tor. 5. nov. 2020 16.26 skrev Tom Crane :

> I have been using recent builds for the past few weeks.  They are usable
> but I have a couple of outstanding problems which I'm not sure how to
> diagnose/fix.
>
> (1) I have strange behaviours with open Kicad application windows. For
> example I have a Kicad project, eeschema and pcbnew windows open on a
> single display. If I let the mouse pointer move from the project window to
> the eeschema or pcbnew window then input focus immediately transfers to
> the eeschema or pcbnew window.  This is without touching any mouse
> buttons.
>
> Similarly moving the mouse pointer back to the project window has no
> effect (as it should) but moving it between the eeschema and pcbnew
> windows transfers input focus as soon as it enters the other window.
>
> There is a similar effect when moving between unrelated (eg. an xterm)
> windows and either eeschema or pcbnew.  Here the eeschema or pcbnew window
> does not receive input focus (which remains with the xterm as it should)
> but the eeschema or pcbnew window does move up the window 'stack'.  eg. if
> I have an eeschema windows partially covered by a pcbnew window, partially
> covered by an xterm window which has input focus, then moving the mouse
> pointer from the xterm to an uncovered section of the eeschema window will
> cause it to move up the stack and fully cover the pcbnew window.
>
> I get this behaviour with both accelerated and standard graphics set.
>
> The above behaviours were observed with the KDE desktop.  I get similar
> behaviour with my usual window manager (fvwm95) except that the window
> focus never switches.
>
> I also find that when invoking the DRC check that the DRC Control Window
> disappears immediately after popping-up and has to be 're-acquired' by
> clicking the pcbnew tab on the fvwm95 taskbar.  I suspect this is another
> facet of these window problems.
>
> I don't get this behaviour with any other applications but Kicad is the
> only wxWidgets/wxPython based one I currently use and so the problem could
> there at the library level rather than within Kicad on my
> distro/Kicad+dependencies build.
>
> None of this is a show-stopper but it is irritating.
>
> Any ideas?
>
>
> (2) I am unable to use any Kicad scripts.  Clicking on pcbnew --> Tools
> --> scripting console I get the "Error: unable to create Python Console"
> pop-up and the following on the console,
>
>   Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/share/kicad/scripting/kicad_pyshell/__init__.py", line 17,
> in
> 
>  import wx
>File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 12, in
> 
>  __version__ = wx.__version__.VERSION_STRING
> AttributeError: partially initialized module 'wx' has no attribute
> '__version__' (most likely due to a circular import)
>
>
> I built kicad with Python3 support (see below) so it should be using that
> and not Python2 (for which I don't have a wxWidgets build) but I suspect
> it might still be calling Python2.
>
> Any ideas?
>
> Many thanks
> Tom Crane
>
> Build details:
>
> Application: KiCad
> Version: (5.99.0-6755-g3b10d1583), release build
> Libraries:
>  wxWidgets 3.1.4
>  libcurl/7.70.0 OpenSSL/1.1.1h zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0
> libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
> Platform: Linux 5.4.6-mklab x86_64, 64 bit, Little endian, wxGTK, ,
> Build Info:
>  Date: Nov 2 2020 16:07:07
>  wxWidgets: 3.1.4 (wchar_t,wx containers) GTK+ 3.24
>  Boost: 1.74.0
>  OCE: 6.9.1
>  Curl: 7.72.0
>  ngspice: 30
>  Compiler: GCC 9.3.0 with C++ ABI 1013
> Build settings:
>  KICAD_SCRIPTING=ON
>  KICAD_SCRIPTING_MODULES=ON
>  KICAD_SCRIPTING_PYTHON3=ON
>  KICAD_SCRIPTING_WXPYTHON=ON
>  KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
>  KICAD_SCRIPTING_ACTION_MENU=ON
>  KICAD_USE_OCE=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

Re: [Kicad-developers] Fedevel openRex Module migrated to KiCad

[Nick Østergaard]

Hi Alexander

Maybe you want to add it to the "made with kicad" page on the website?
https://kicad-pcb.org/made-with-kicad/

Nick

On Thu, 10 Sep 2020 at 19:52,  wrote:

> Oh, that's right, I'll do it. Thanks)
>
> 10 сентября 2020 г. 18:42:23 GMT+03:00, "Roberto Fernández Bautista" <
> roberto.fer@gmail.com> пишет:
>>
>> Hi Alexander,
>>
>> I'd suggest that you post this in the forum instead as you will get a
>> wider audience of KiCad users: https://forum.kicad.info/
>>
>> Looks interesting though!
>>
>> Roberto
>>
>> On Thu, 10 Sep 2020 at 13:03, Alexander Shuklin 
>> wrote:
>>
>>> Hi All!
>>> I hope somebody will find it useful, I migrated openRex imx6 SOM (
>>> https://www.imx6rex.com/ ) to KiCad. That's an open source ARM SOM
>>> module from Fedevel courses. You can find it in my gitlab:
>>> https://gitlab.com/jasuramme/imx6-openrex-kicad-port
>>>
>>> The course I just finished is Advanced PCB Layout Course. (
>>> https://academy.fedevel.com/courses/online-advanced-pcb-layout-course )
>>> That's a really nice one and I would recommend it.
>>>
>>> I hope Robert Feranec, author, will create a course based on KiCad as
>>> well someday.
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
> --
> Простите за краткость, создано в K-9 Mail.
> ___
> Mailing list: https://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 nightly builds for Arch

[Nick Østergaard]

Hi Rachel

I wonder why you wouldn't just propose the changes to the maintainer of
kicad-git in AUR.

I didn't review your scripts, but that is where I woukd start.


fre. 23. okt. 2020 12.32 skrev :

> Hi folks,
>
> I recently got fed up enough of not having a parallel installable
> nightly for Arch that I could use at the same time as release KiCAD so
> I could toy with new features and yet still keep my main projects in
> 5.x format, so I put in the effort to create a set of PKGBUILD files
> for such a nightly.
>
> The result of this are the two sets of packages on the AUR known as
> kicad-nightly and kicad-library-nightly. However, updating these is
> presently a touch unwieldy and I wish to put together a meta-repo with
> my scripts for updating the packages.
>
> To this end, I'm seeking a packaging repo on GitLab such as
> `kicad-arch-builder`, and possibly a couple of mirroring repos for
> each of the two AUR packages, if that is possible please?
>
> Many thanks,
> Rachel.
>
>
> ___
> Mailing list: https://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-doc-devs] Translations Locations

[Nick Østergaard]

What happens for weblate if translations are updated via git?

On Sun, 18 Oct 2020 at 00:00, Seth Hillbrand  wrote:

> It is a requirement to use their "Libre" hosting plan.  If we host our own
> instance, we don't need to combine them.
>
> Is there any reason why we shouldn't?
>
> Seth
>
> On Sat, Oct 17, 2020, 11:02 AM Nick Østergaard  wrote:
>
>> I don't really see it as an advantage as such to move it into the kicad
>> source. Why do we technically need that to use weblate?
>>
>> On Sat, 17 Oct 2020 at 19:31, Steven A. Falco 
>> wrote:
>>
>>> I have no objections.  It makes sense to combine those repos.
>>>
>>> Steve
>>>
>>> On 10/17/20 11:08 AM, Seth Hillbrand wrote:
>>> > Hi All-
>>> >
>>> > Currently, and for some time, our translations of KiCad have lived in
>>> a separate repository from the codebase.  I'd like to merge the
>>> translations into the KiCad codebase in a subdirectory called "translation"
>>> >
>>> > This will allow our translators to only have to check out a single
>>> repository instead of two.  This will also allow us to begin using an
>>> online collaborative translation platform called Weblate[1] that is used by
>>> Fedora, openSUSE, LibreOffice, etc.  The online translation system is
>>> optional, translators are not required to use it, but it does add a number
>>> of useful features and quality checks.
>>> >
>>> > Does anyone have objections to moving the i18n repository into a
>>> subdirectory of the source code repository or know of a reason why we
>>> shouldn't?
>>> >
>>> > Best-
>>> > Seth
>>> >
>>> > --
>>> > KiCad Services Corporation Logo
>>> > Seth Hillbrand
>>> > *Lead Developer*
>>> > +1-530-302-5483‬ 
>>> > Davis, 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-doc-devs
>>> Post to : kicad-doc-devs@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-doc-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> --
>> Mailing list: https://launchpad.net/~kicad-doc-devs
>> Post to : kicad-doc-devs@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-doc-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
-- 
Mailing list: https://launchpad.net/~kicad-doc-devs
Post to : kicad-doc-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-doc-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-doc-devs] Translations Locations

[Nick Østergaard]

I don't really see it as an advantage as such to move it into the kicad
source. Why do we technically need that to use weblate?

On Sat, 17 Oct 2020 at 19:31, Steven A. Falco  wrote:

> I have no objections.  It makes sense to combine those repos.
>
> Steve
>
> On 10/17/20 11:08 AM, Seth Hillbrand wrote:
> > Hi All-
> >
> > Currently, and for some time, our translations of KiCad have lived in a
> separate repository from the codebase.  I'd like to merge the translations
> into the KiCad codebase in a subdirectory called "translation"
> >
> > This will allow our translators to only have to check out a single
> repository instead of two.  This will also allow us to begin using an
> online collaborative translation platform called Weblate[1] that is used by
> Fedora, openSUSE, LibreOffice, etc.  The online translation system is
> optional, translators are not required to use it, but it does add a number
> of useful features and quality checks.
> >
> > Does anyone have objections to moving the i18n repository into a
> subdirectory of the source code repository or know of a reason why we
> shouldn't?
> >
> > Best-
> > Seth
> >
> > --
> > KiCad Services Corporation Logo
> > Seth Hillbrand
> > *Lead Developer*
> > +1-530-302-5483‬ 
> > Davis, CA
> > www.kipro-pcb.com  i...@kipro-pcb.com
> 
> >
> >
>
>
> --
> Mailing list: https://launchpad.net/~kicad-doc-devs
> Post to : kicad-doc-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-doc-devs
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Mailing list: https://launchpad.net/~kicad-doc-devs
Post to : kicad-doc-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-doc-devs
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Problems with windows installers?

[Nick Østergaard]

I don't know what the problem may be, but as far as I am aware, there are
not changes in the build system.

On Mon, 12 Oct 2020 at 23:51, Brian Piccioni 
wrote:

> Windows 10 Home
> V1909
> OS Build 18363.1082
>
> As noted below My prior version kicad-r18012.7f1c376128-x86_64-lite.exe
> seems to work
>
>
> I have not tested all versions between
>
>
> On 2020-10-12 4:20 p.m., Nick Østergaard wrote:
>
> What system are you installing it on?
>
> Does any older nightly builds work?
>
> On Mon, 12 Oct 2020 at 18:42, Brian Piccioni 
> wrote:
>
>> Hello
>>
>> I downloaded kicad-r18079.88102bca46-x86_64.exe and
>> kicad-r18079.88102bca46-x86_64-lite.exe from
>> https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/
>>
>> On running both throw up the Microsoft warning warning but clicking
>> "Install Anyway" has no effect.
>>
>> My prior version kicad-r18012.7f1c376128-x86_64-lite.exe seems to work
>> as expected, suggesting this may not be a Windows issue
>>
>> 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

Re: [Kicad-developers] Problems with windows installers?

[Nick Østergaard]

What system are you installing it on?

Does any older nightly builds work?

On Mon, 12 Oct 2020 at 18:42, Brian Piccioni 
wrote:

> Hello
>
> I downloaded kicad-r18079.88102bca46-x86_64.exe and
> kicad-r18079.88102bca46-x86_64-lite.exe from
> https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/
>
> On running both throw up the Microsoft warning warning but clicking
> "Install Anyway" has no effect.
>
> My prior version kicad-r18012.7f1c376128-x86_64-lite.exe seems to work
> as expected, suggesting this may not be a Windows issue
>
> 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

Re: [Kicad-developers] Via isolation

[Nick Østergaard]

You may be interested in the DRC updates for v6, see
https://forum.kicad.info/t/need-some-guinea-pigs-for-a-rule-based-drc-prototype/22955

man. 12. okt. 2020 07.49 skrev BERTRAND Joël :

> Hello,
>
> Sometimes, on very compact boards, I need isolated vias (from
> planes)
> for example for power supplies, even if I have power planes. A power
> track can go from bottom side to top side while being isolated from the
> power plan.
>
> Is it possible to do this ? I haven't find any solution.
>
> Best regards,
>
> JKB
>
> ___
> Mailing list: https://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] Attempting to build kicad-git source on Slackware-current Linux

[Nick Østergaard]

Build with the same options as used on arch.

man. 12. okt. 2020 04.20 skrev Tom Crane :

> Thanks for the clarification -- and to all who follow-ed up.  That was the
> information I needed.  Now using Phoenix 4.1.1a1/gtk3 (wxWidgets 3.1.5)
> from git to build both wxPython4 and wxWidgets (wxGTK3+ Slackware package)
> I was able to build KiCad from git.
>
> Thankfully I don't get the segfaults I had with the previous build (using
> GTK2+ and Python2).
>
> The one new problem I have is that the accelerated graphics no longer
> work.  Eeschema gives the 'Info' pop-up -- "Could not use OpenGL, falling
> back to software rendering".  The 'see details' twisty just gives "Unknown
> Error".
>
> I built wxWidgets (wxGTK3+ Slackware package) with configure's
> '--with-opengl' switch.  My hardware has not changed -- a very ordinary
> graphics adapter (Intel Desktop board on-board graphics).
>
> I built KiCad with 'cmake -DCMAKE_BUILD_TYPE=Debug' so can investigate
> with gdb if needed.
>
> Could you give me any tips on what might be wrong and where to look?
>
> Thanks again
>
> Tom Crane
>
> On Thu, 8 Oct 2020, Ian McInerney wrote:
>
> > The build has failed because it appears that your version of
> wxPython/Phoenix is using wxWidgets 3.1.5 and you are trying to use
> wxWidgets 3.1.4 in the main KiCad build. Those two versions must be the
> same in order for KiCad to build properly (otherwise there
> > will be issues with linking).
> > The compiler flag tests have no impact on this, they are in the log just
> because your GCC version doesn't support them so we aren't enabling them.
> >
> > -Ian
> >
> > On Thu, Oct 8, 2020 at 4:38 PM Tom Crane 
> wrote:
> >   I am having no success despite having been able to do this in the
> past.
> >
> >   Previously I was able to build for gtk2+ with Python2.  Now trying
> this fails at runtime with eg. "(eeschema:6730): Gtk-ERROR **:
> 15:29:43.689: GTK+ 2.x symbols detected.  Using GTK+ 2.x and GTK+ 3 in the
> same process is not supported".  According
> >   to https://forum.kicad.info/t/gtk-2-to-3-issues/24856/2 GTK2
> isn't able to be used any more.
> >
> >   Instead (my preference anyway) I am now trying to build against
> gtk3+ and
> >   Python3.
> >
> >   I get this error,
> >
> >   # cmake -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON
> -DKICAD_SCRIPTING_PYTHON3=ON -DKICAD_SCRIPTING_WXPYTHON=ON
> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON -DKICAD_SCRIPTING_ACTION_MENU=ON
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON ../
> >   -- KiCad install dir: 
> >   -- Enabling warning -Wsuggest-override
> >   -- Enabling warning -Wduplicated-branches
> >   -- Enabling warning -Wduplicated-cond
> >   -- Enabling error for -Wvla
> >   -- Enabling warning -Wimplicit-fallthrough
> >   -- Enabling error for -Wreturn-type
> >   -- Enabling warning -Wshadow
> >   -- Enabling warning -Wsign-compare
> >   -- Enabling warning -Wmissing-field-initializers
> >   -- Enabling warning -Wempty-body
> >   -- Enabling warning -Wreorder
> >   -- Check for installed GLEW -- found
> >   -- Check for installed ZLIB -- found
> >   -- Check for installed Python Interpreter -- found
> >   -- Python module install path: lib64/python3.8/site-packages
> >   -- Found Phoenix 4.1.1a1/gtk3 (wxWidgets 3.1.5)
> >   CMake Error at
> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165
> (message):
> >  Could NOT find wxWidgets: Found unsuitable version "3.1.4", but
> required is  at least "3.1.5" (found
> >
> >
>  
> -L/usr/lib64/gtk3;-pthread;;;-lwx_gtk3u_gl-3.1;-lwx_gtk3u_aui-3.1;-lwx_gtk3u_html-3.1;-lwx_gtk3u_core-3.1;-lwx_baseu_net-3.1;-lwx_baseu-3.1;-lwx_gtk3u_propgrid-3.1;-lwx_baseu_xml-3.1;-lwx_gtk3u_stc-3.1)
> >   Call Stack (most recent call first):
> >
>  /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:456
> >   (_FPHSA_FAILURE_MESSAGE)
> >  CMakeModules/FindwxWidgets.cmake:1014
> >   (find_package_handle_standard_args)
> >  CMakeLists.txt:808 (find_package)
> >
> >
> >   -- Configuring incomplete, errors occurred!
> >   See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeOutput.log".
> >   See also "/tmp/SBo/kicad-git/build/CMakeFiles/CMakeError.log".
> >
> >
> >   CMakeError.log shows the test compilations failing with these
> three errors,
> >   c++: error: unrecognized command line option
> '-Winconsistent-missing-override'
> >   c++: error: unrecognized command line option '-Wmismatched-tags'
> >   c++: error: unrecognized command line option
> '-Wimplicit-int-float-conversion'
> >
> >   BTW I am using GCC 9.3.0.
> >
> >   I built wxWidgets-3.1.4 using a slightly modified third party
> SlackBuilds
> >   script for the wxGTK3 package, which includes the following
> configure,
> >
> >   ./configure \
> >  --prefix=/usr \
> >  --libdir=/usr/lib${LIBDIRSUFFIX}/gtk3 \
> >  

Re: [Kicad-developers] 5.1.7 tagged.

[Nick Østergaard]

Unless you really enjoy torturing yourself, please focus on py3k and apple
silicon in prep for v6. :)

We are trying to support as many systems as possible on a best effort
basis. We never promised anyone to provide new builds for abandoned OS'.

On Thu, 1 Oct 2020 at 02:29, Adam Wolf 
wrote:

> I got further today getting the 10.12 build to go, but it choked
> during the boost/icu4c installation.
>
> I am not of a strong opinion here--my default opinion is to keep
> supporting all the versions we supported at the start of 5.1, but we
> also have much fewer resources than Apple, who does not support these
> systems anymore.  I am willing to keep at it if folks want, or go back
> to Python 3 / Apple Silicon stuff in prep for 6.
>
> Adam Wolf
>
> On Wed, Sep 30, 2020 at 2:24 PM Mark Roszko  wrote:
> >
> > Yea I'm with Nick on this one. As it standards, 10.12 is past EOL now.
> 10.13 EOL is in 2 months. Supporting outdated (and as an extension
> insecure) OSes just encourages users to make the bad decision to keep using
> them.
> >
> > On Wed, Sep 30, 2020 at 11:26 AM Nick Østergaard 
> wrote:
> >>
> >> If people needs to get a build support for an OS that is not supported
> by the maker, then they can still build it themselves with some effort or
> pay someone to do it. :) There is no reason to handcuff ourselves when it
> is an impediment to doing what we like and do on a volunteer basis. Not
> supporting non-supported OS' when we have better things to do, like getting
> python3 to work, is just a reasonable decision considering the time we have
> at our disposal. We are only dropping "legacy" systems when it becomes a
> pain to maintain. As it is now, we are not just supporting the latest macos
> version.
> >>
> >> On Wed, 30 Sep 2020 at 16:52, Adam Wolf 
> wrote:
> >>>
> >>> I think it's actually an issue with installing openssl.
> >>>
> >>> I've had an OCE bottle I made that I stored in the repo for years,
> >>> since there were issues with the upstream 10.12 bottle for a while.
> >>>
> >>> Wayne, I suspect is it a relatively low amount of users.  10.12 hasn't
> >>> been getting security updates from Apple since October 2019.  10.13
> >>> just got a security update 3 days ago, and that was likely the last
> >>> security update it will ever get.  10.14 is ~2 years old, 10.15 is
> >>> about a year old, and 10.16 is in beta at the moment.
> >>>
> >>> I'll put a few more minutes into it this morning and see what I can do.
> >>>
> >>> Adam Wolf
> >>>
> >>> On Wed, Sep 30, 2020 at 9:20 AM Ian McInerney <
> ian.s.mciner...@ieee.org> wrote:
> >>> >
> >>> > Out of curiosity, which issues are preventing the 10.12-10.13
> builds? Is it the disappearance of OCE from homebrew?
> >>> >
> >>> > -Ian
> >>> >
> >>> > On Wed, Sep 30, 2020 at 2:47 PM Adam Wolf <
> adamw...@feelslikeburning.com> wrote:
> >>> >>
> >>> >> macOS is uploaded:
> >>> >>
> https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.7-0-10_14.dmg
> >>> >>
> >>> >> I was unable to make a 10.12-10.13 build.  These were a little old
> at
> >>> >> the start of the 5.1 series, and "are older than they've ever been
> and
> >>> >> now they're even older." :) It is not necessarily impossible to
> create
> >>> >> these builds, but it's not straightforward at all anymore.  I do not
> >>> >> like having a different set of support at the end of the series than
> >>> >> at the beginning, so if Wayne or someone says "Please go try some
> >>> >> more!" I will, but at the same point, not spending more time than I
> >>> >> already have on the 10.12 builds gives me more time for KiCad 6.
> >>> >>
> >>> >> We may need to adjust the wording on the download page because of
> this.
> >>> >>
> >>> >> Adam
> >>> >>
> >>> >> On Mon, Sep 28, 2020 at 3:47 PM Johannes Maibaum <
> jmaib...@gmail.com> wrote:
> >>> >> >
> >>> >> > Hi,
> >>> >> >
> >>> >> > flatpak on flathub will be ready a few hours after I press the
> button to
> >>> >> > build them for the stable flathub branch, which will happen on
> the day I
> >

Re: [Kicad-developers] Torrent downloads

[Nick Østergaard]

I was implicitly hoping you could explicitly verify for me that using the
OSDN url would support range requests.  :)

tor. 1. okt. 2020 09.09 skrev Andrew Lutsenko :

> Yes, it does. I think it will work with any http server supporting range
> requests.
> You can have multiple webseed urls in the torrent as well, just pass
> --urlList flag multiple times.
>
> On Wed, Sep 30, 2020 at 11:28 PM Nick Østergaard 
> wrote:
>
>> Does it also work with the OSDN mirror?
>>
>> tor. 1. okt. 2020 02.42 skrev Andrew Lutsenko :
>>
>>> Hi all,
>>>
>>> I recall we had this discussion before about providing torrent files for
>>> release downloads to reduce the slowdown related to rush traffic. it didn't
>>> go far mainly because of resources needed to maintain separate torrent
>>> seeding infrastructure.
>>>
>>> I recently discovered that p2p torrent protocol supports webseeding, a
>>> feature that allows torrent clients to download chunks of files from
>>> standard http/ftp servers. It's implemented by most major torrent client
>>> software. This way the file is initially seeded by the http server but as
>>> more and more peers get the data the swarm takes over most of the traffic
>>> load.
>>>
>>> I tried it out and it works nicely with kicad's existing http download
>>> resources so there is no need to have separate infra for torrents!
>>>
>>> Would you be open to adding this?
>>> All that is needed is put .torrent files either on kicad website or even
>>> better, on the https://kicad-downloads.s3.cern.ch/ server next to the
>>> installers and add a link to them.
>>>
>>> I've generated torrents with webseed information for 5.1.7 here:
>>> https://forum.kicad.info/t/torrents-for-kicad-stable-version-5-1-7-win-and-osx/16609/14?u=qu1ck
>>>
>>> To do it yourself in the future is trivial, here is the bash script I
>>> used to create the files:
>>>
>>> for f in *.exe ; do
>>> create-torrent "$f" -o $f.torrent --urlList
>>> https://kicad-downloads.s3.cern.ch/windows/stable/
>>> done
>>> for f in *.dmg ; do
>>> create-torrent "$f" -o $f.torrent --urlList
>>> https://kicad-downloads.s3.cern.ch/osx/stable/
>>> done
>>>
>>> It depends on create-torrent utility that you can get by running "npm
>>> install -g create-torrent"
>>>
>>> I can also make a merge request on the kicad website if someone will
>>> upload the torrent files to the s3 server.
>>>
>>> Regards,
>>> Andrew
>>> ___
>>> Mailing list: https://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] Torrent downloads

[Nick Østergaard]

Does it also work with the OSDN mirror?

tor. 1. okt. 2020 02.42 skrev Andrew Lutsenko :

> Hi all,
>
> I recall we had this discussion before about providing torrent files for
> release downloads to reduce the slowdown related to rush traffic. it didn't
> go far mainly because of resources needed to maintain separate torrent
> seeding infrastructure.
>
> I recently discovered that p2p torrent protocol supports webseeding, a
> feature that allows torrent clients to download chunks of files from
> standard http/ftp servers. It's implemented by most major torrent client
> software. This way the file is initially seeded by the http server but as
> more and more peers get the data the swarm takes over most of the traffic
> load.
>
> I tried it out and it works nicely with kicad's existing http download
> resources so there is no need to have separate infra for torrents!
>
> Would you be open to adding this?
> All that is needed is put .torrent files either on kicad website or even
> better, on the https://kicad-downloads.s3.cern.ch/ server next to the
> installers and add a link to them.
>
> I've generated torrents with webseed information for 5.1.7 here:
> https://forum.kicad.info/t/torrents-for-kicad-stable-version-5-1-7-win-and-osx/16609/14?u=qu1ck
>
> To do it yourself in the future is trivial, here is the bash script I used
> to create the files:
>
> for f in *.exe ; do
> create-torrent "$f" -o $f.torrent --urlList
> https://kicad-downloads.s3.cern.ch/windows/stable/
> done
> for f in *.dmg ; do
> create-torrent "$f" -o $f.torrent --urlList
> https://kicad-downloads.s3.cern.ch/osx/stable/
> done
>
> It depends on create-torrent utility that you can get by running "npm
> install -g create-torrent"
>
> I can also make a merge request on the kicad website if someone will
> upload the torrent files to the s3 server.
>
> Regards,
> Andrew
> ___
> Mailing list: https://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.7 tagged.

[Nick Østergaard]

If people needs to get a build support for an OS that is not supported by
the maker, then they can still build it themselves with some effort or pay
someone to do it. :) There is no reason to handcuff ourselves when it is an
impediment to doing what we like and do on a volunteer basis. Not
supporting non-supported OS' when we have better things to do, like getting
python3 to work, is just a reasonable decision considering the time we have
at our disposal. We are only dropping "legacy" systems when it becomes a
pain to maintain. As it is now, we are not just supporting the latest macos
version.

On Wed, 30 Sep 2020 at 16:52, Adam Wolf 
wrote:

> I think it's actually an issue with installing openssl.
>
> I've had an OCE bottle I made that I stored in the repo for years,
> since there were issues with the upstream 10.12 bottle for a while.
>
> Wayne, I suspect is it a relatively low amount of users.  10.12 hasn't
> been getting security updates from Apple since October 2019.  10.13
> just got a security update 3 days ago, and that was likely the last
> security update it will ever get.  10.14 is ~2 years old, 10.15 is
> about a year old, and 10.16 is in beta at the moment.
>
> I'll put a few more minutes into it this morning and see what I can do.
>
> Adam Wolf
>
> On Wed, Sep 30, 2020 at 9:20 AM Ian McInerney 
> wrote:
> >
> > Out of curiosity, which issues are preventing the 10.12-10.13 builds? Is
> it the disappearance of OCE from homebrew?
> >
> > -Ian
> >
> > On Wed, Sep 30, 2020 at 2:47 PM Adam Wolf 
> wrote:
> >>
> >> macOS is uploaded:
> >>
> https://kicad-downloads.s3.cern.ch/osx/stable/kicad-unified-5.1.7-0-10_14.dmg
> >>
> >> I was unable to make a 10.12-10.13 build.  These were a little old at
> >> the start of the 5.1 series, and "are older than they've ever been and
> >> now they're even older." :) It is not necessarily impossible to create
> >> these builds, but it's not straightforward at all anymore.  I do not
> >> like having a different set of support at the end of the series than
> >> at the beginning, so if Wayne or someone says "Please go try some
> >> more!" I will, but at the same point, not spending more time than I
> >> already have on the 10.12 builds gives me more time for KiCad 6.
> >>
> >> We may need to adjust the wording on the download page because of this.
> >>
> >> Adam
> >>
> >> On Mon, Sep 28, 2020 at 3:47 PM Johannes Maibaum 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > flatpak on flathub will be ready a few hours after I press the button
> to
> >> > build them for the stable flathub branch, which will happen on the
> day I
> >> > see the announcement posted. Everything's set to go here.
> >> >
> >> >
> >> > Best,
> >> > Johannes
> >> >
> >> > Am Montag, den 28.09.2020, 08:53 -0500 schrieb Adam Wolf:
> >> > > Thanks!
> >> > >
> >> > > On Mon, Sep 28, 2020 at 8:47 AM Wayne Stambaugh <
> stambau...@gmail.com>
> >> > > wrote:
> >> > > > Adam,
> >> > > >
> >> > > > No problem, I can hold off posting the announcement to the 30th
> >> > > > which
> >> > > > was the original plan.
> >> > > >
> >> > > > Cheers,
> >> > > >
> >> > > > Wayne
> >> > > >
> >> > > > On 9/28/2020 8:55 AM, Adam Wolf wrote:
> >> > > > > MacOS is going to be at least a day or two, but I should have it
> >> > > > > ready
> >> > > > > by the 30th.
> >> > > > >
> >> > > > > If it's alright with folks, could we hold off on the
> announcement
> >> > > > > until tomorrow at least?
> >> > > > >
> >> > > > > Adam
> >> > > > >
> >> > > > > On Mon, Sep 28, 2020 at 7:05 AM Wayne Stambaugh <
> >> > > > > stambau...@gmail.com> wrote:
> >> > > > > > Has the website download page been updated? If that's done, I
> >> > > > > > will
> >> > > > > > remove the draft tag from the release announcement today.
> >> > > > > >
> >> > > > > > On 9/26/2020 1:42 PM, Nick Østergaard wrote:
> >> > > > > > > Everything has been tagged, the windows build is 

Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?

[Nick Østergaard]

A solution to this could be go genrate idf models more interactively as
suggested Jon. We already have idfcyl and idfrect as references. I assume
there is no reason to use IDF over STEP as the physical representation.

On Tue, 29 Sep 2020 at 21:01, Mário Luzeiro  wrote:

> that would work for me too ;)
>
> Mario
>
> 
> From: Jon Evans 
> Sent: 29 September 2020 19:53
> To: Mário Luzeiro
> Cc: Seth Hillbrand; kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?
>
> Note Altium's solution to the use case of needing "easy basic models": it
> can actually generate the models built-in.
>
> You just specify some parameters and it will generate cylinders, spheres,
> or extruded shapes from a 2D contour.
>
> If we could add this kind of feature in the future, maybe we would not
> need to support "stretching" generic models, as we could just generate the
> right generic model parametrically (without "stretching" a source model)
>
> On Tue, Sep 29, 2020 at 2:50 PM Mário Luzeiro  mrluze...@ua.pt>> wrote:
> From my user experience: I use the 3 scale values on my projects.
> I created unit solids (eg: 1mm cube, 1mm cylinder radius / thickness, etc)
> and then I use it to quickly create shapes (by adjusting X,Y,Z scale) to
> populate the board if I don't have the proper STEP model.
> This is helpful to create round buttons, push buttons switch house
> packages, displays (attached is an example I made just using 1mm cubes)
> I'm using WRL but I believe it should work if I had used STEP scaled and
> then export it for CAD purposes.
>
> If you remove scale at all, I will need to learn and use a new CAD
> software :/ :)
>
> My suggestion is keep the scale but hide (or disable) it by default on the
> UI and it should only be enabled by clicking on some checkbox, at that
> time, displaying some message to the user "this is not a good idea for
> CAD.."
>
>
> > I'm not sure the history of why VRML was chosen as the first model type
> that was supported
>
> Maybe at that time it was created was a very time consuming thing to
> implement.
> For STEP we need a 3rd part library (as it is very complex format).
> On the current 3D-Viewer implementation, Cirilo worked alone on the model
> importer code alone and it took some months of work..
>
> Mario
>
> 
> From: Kicad-developers  ua...@lists.launchpad.net> on behalf of
> Seth Hillbrand mailto:s...@kipro-pcb.com>>
> Sent: 29 September 2020 19:01
> To: Jon Evans
> Cc: kicad-developers@lists.launchpad.net kicad-developers@lists.launchpad.net>
> Subject: Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?
>
> I've never seen another package use VRML.  Everyone uses STEP.  I suspect
> if we were implementing this today, we would look at the tradeoff on
> support/benefit for VRML and limit ourselves to STEP as well.
>
> I like Ian's suggestion for unit options.
>
> -Seth
>
> On Tue, Sep 29, 2020 at 10:22 AM Jon Evans  j...@craftyjon.com>>>
> wrote:
> Do other EDA tools allow model scaling?  Altium doesn't even allow VRML
> import in the first place.
>
> On Tue, Sep 29, 2020 at 1:10 PM Seth Hillbrand  s...@kipro-pcb.com>>>
> wrote:
> Well, we've backed ourselves into a bit of a corner.  VRML is specified in
> meters, so if we're assuming inches, we're a bit off in left field.  But do
> we need three separate scale parameters?  We could reduce to 1, correct?
>
> In the official footprint library, we have 7 footprints that specify
> non-unity scaling. (Banana_Jack_[1-3], NS-Tech_Grove_1x04, Fuse_Blade_ATO,
> Fuse_Blad_Mini, Oscillator_SMD_TXC0_G158).
>
> -Seth
>
>
>
>
> On Tue, Sep 29, 2020 at 9:30 AM Ian McInerney  >> wrote:
> We can't remove the scaling option until we make the VRML importer handle
> proper unit selection. I have routinely run into the case where I go
> OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
> because it makes for easier computations (all the datasheet values are
> nicely given in mm) and then have to apply a scaling factor of 0.3937 to
> all the axes in KiCad to make it the proper size because we seem to have a
> hardcoded assumption about what unit system the VRML file is in.
>
> In fact, the KLC says: WRL files do not specify absolute dimensions. KiCad
> normalizes model parameters to units of inches and the internal units
> (dimensionless) of the WRL model must be scaled accordingly.
>
> -Ian
>
> On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand  s...@kipro-pcb.com>>>
> wrote:
> There has been some discussion to removing the scale option here
> altogether.  The logic being that if you need the model scaled, you 

Re: [Kicad-developers] 5.1.7 tagged.

[Nick Østergaard]

Everything has been tagged, the windows build is ready.

I think the macos build may be a bit delayed, but I think we can undraft
the release announcement now anyways.

On Sat, 26 Sep 2020 at 03:33, Christian Schlüter  wrote:

> Libraries are
>
> https://github.com/KiCad/kicad-footprints/releases/tag/5.1.7
> https://github.com/KiCad/kicad-symbols/releases/tag/5.1.7
> https://github.com/KiCad/kicad-packages3D/releases/tag/5.1.7
> https://github.com/KiCad/kicad-templates/releases/tag/5.1.7
>
> Cheers,
> CS
> ___
> Mailing list: https://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] mingw64 build issue.

[Nick Østergaard]

Ni, they are only cached via the archive artifacts of jenkins, which I
can't reach right now.

fre. 25. sep. 2020 22.39 skrev Wayne Stambaugh :

> Is there a repo with with the build configuration so I can see what
> msys2/mingw64 packages are being used in our builds?
>
> On 9/25/20 4:09 PM, Nick Østergaard wrote:
> > I cant reach the build server right now, so I don't know the status, but
> > it is not autoupdated. Mainly updated once in a while after a release
> > has been made with "known good env".
> >
> > fre. 25. sep. 2020 22.02 skrev Wayne Stambaugh  > <mailto:stambau...@gmail.com>>:
> >
> > I take it we are not getting any nightly build errors for
> msys2/mingw54
> > builds.  Do we always use the latest msys2/mingw64 packages for
> nightly
> > builds or are they pinned to a specific version that we know works?
> If
> > it's the latter, where can I find the package list.  Maybe that will
> > give me a better idea of which package broke my builds.  I suspect JP
> > hasn't run `pacman -Syuu` recently so he may have older build tool
> > packages.
> >
> > On 9/25/20 3:29 PM, Mark Roszko wrote:
> > > I actually got that MSYS2 error awhile backas for why, I don't
> > know,
> > > I haven't been arsed to rebuild the msys2 install yet again.
> > >
> > >
> > > I'm waiting on vcpkg to merge opencascade which was blocked on
> 32-bit
> > > builds being broken, the MSVC team responded with a workaround to
> the
> > > compiler bug so now its blocked on somebody else having broke
> > vcpkg for
> > > windows (lul)
> > >
> > > There's also a python port upgrade required, someone else managed
> to
> > > beat me to submitting the exact changes I need but that port is
> > pending
> > > merge hopefully once the windows breakage is fixed.
> > >
> > > Then my wxPython port, I'll see if I can sneak it into vcpkg once
> that
> > > python port is merged but it is usable.
> > >
> > > On Fri, Sep 25, 2020 at 3:14 PM Jon Evans  > <mailto:j...@craftyjon.com>
> > > <mailto:j...@craftyjon.com <mailto:j...@craftyjon.com>>> wrote:
> > >
> > > MSVC works great, I really recommend giving it a try.  Much
> faster
> > > compile time than msys.
> > >
> > > Seems like Mark will have a solution for wxPython very soon
> too :)
> > >
> > > On Fri, Sep 25, 2020 at 3:10 PM Wayne Stambaugh
> > > mailto:stambau...@gmail.com>
> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
> > >
> > > On 9/25/2020 3:04 PM, jp charras wrote:
> > > >
> > > > Le 25/09/2020 à 19:11, Wayne Stambaugh a écrit :
> > > >> Is anyone else seeing the following error when building
> > with
> > > >> MinGW64/msys2?
> > > >>
> > > >>
> > >
> >
>   ../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
> > > >> relocation truncated to fit: R_X86_64_PC32 against
> `*ABS*'
> > > >>
> > > >> I did some digging around and it looks like it's a bug
> > in the
> > > context
> > > >> assembly code but I've never seen the error before.  I
> > tried
> > > downgrading
> > > >> gcc from 10.2 to 10.1 but no luck.  It also happens when
> > > building the
> > > >> 5.1 branch.  It doesn't happen when building with
> > MinGW32/msys2.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Wayne
> > > >
> > > > I am not seeing this issue.
> > > >
> > > > I have a recent (2 weeks) msys install, on a new
> computer,
> > > with W10 -
> > > > 64bits
> > >
> > > Thanks for the feedback.  Maybe something got broken
> during an
> > > update.
> > > My msys2 install is quite old so maybe it's time to do a
> clean
> > > reinstall
>

Re: [Kicad-developers] mingw64 build issue.

[Nick Østergaard]

I cant reach the build server right now, so I don't know the status, but it
is not autoupdated. Mainly updated once in a while after a release has been
made with "known good env".

fre. 25. sep. 2020 22.02 skrev Wayne Stambaugh :

> I take it we are not getting any nightly build errors for msys2/mingw54
> builds.  Do we always use the latest msys2/mingw64 packages for nightly
> builds or are they pinned to a specific version that we know works?  If
> it's the latter, where can I find the package list.  Maybe that will
> give me a better idea of which package broke my builds.  I suspect JP
> hasn't run `pacman -Syuu` recently so he may have older build tool
> packages.
>
> On 9/25/20 3:29 PM, Mark Roszko wrote:
> > I actually got that MSYS2 error awhile backas for why, I don't know,
> > I haven't been arsed to rebuild the msys2 install yet again.
> >
> >
> > I'm waiting on vcpkg to merge opencascade which was blocked on 32-bit
> > builds being broken, the MSVC team responded with a workaround to the
> > compiler bug so now its blocked on somebody else having broke vcpkg for
> > windows (lul)
> >
> > There's also a python port upgrade required, someone else managed to
> > beat me to submitting the exact changes I need but that port is pending
> > merge hopefully once the windows breakage is fixed.
> >
> > Then my wxPython port, I'll see if I can sneak it into vcpkg once that
> > python port is merged but it is usable.
> >
> > On Fri, Sep 25, 2020 at 3:14 PM Jon Evans  > > wrote:
> >
> > MSVC works great, I really recommend giving it a try.  Much faster
> > compile time than msys.
> >
> > Seems like Mark will have a solution for wxPython very soon too :)
> >
> > On Fri, Sep 25, 2020 at 3:10 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> >
> > On 9/25/2020 3:04 PM, jp charras wrote:
> > >
> > > Le 25/09/2020 à 19:11, Wayne Stambaugh a écrit :
> > >> Is anyone else seeing the following error when building with
> > >> MinGW64/msys2?
> > >>
> > >>
> >
>  ../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
> > >> relocation truncated to fit: R_X86_64_PC32 against `*ABS*'
> > >>
> > >> I did some digging around and it looks like it's a bug in the
> > context
> > >> assembly code but I've never seen the error before.  I tried
> > downgrading
> > >> gcc from 10.2 to 10.1 but no luck.  It also happens when
> > building the
> > >> 5.1 branch.  It doesn't happen when building with
> MinGW32/msys2.
> > >>
> > >> Thanks,
> > >>
> > >> Wayne
> > >
> > > I am not seeing this issue.
> > >
> > > I have a recent (2 weeks) msys install, on a new computer,
> > with W10 -
> > > 64bits
> >
> > Thanks for the feedback.  Maybe something got broken during an
> > update.
> > My msys2 install is quite old so maybe it's time to do a clean
> > reinstall
> > :(.  I guess all development for me will be on Linux until I can
> > free up
> > a decent block of time to upgrade msys2 or maybe try out the new
> > msvc
> > stuff Mark has been working on.
> >
> > Cheers,
> >
> > Wayne
> >
> > >
> > >
> > >> --
> > >> Jean-Pierre CHARRAS
> > >
> > > ___
> > > Mailing list: https://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
> >
> >
> >
> > --
> > 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

Re: [Kicad-developers] High speed tools

[Nick Østergaard]

Hi

Slightly related to this discussion and for inspiration:

https://twitter.com/azonenberg/status/1282188633118699520

Nick

On Wed, 23 Sep 2020 at 09:43, Alexander Shuklin  wrote:

> Hi Kliment,
> I think if these things you explained will be implemented, it will make
> high speed design very much easier.
> And the problem is much worse if you have a lot of differential pairs.
> When I see design and the only thing which I can do with differential pairs
> is to tune length or redraw, I feel stressed.
> Is it right that diffpairs are always treated as just single tracks now?
> If I want to write a script or piece of code to change diffpair width or
> gap, what idea should I use?
> I think about finding all coupled lengths of some differential pair and
> changing the gap on all of coupled lengths and don't touch it if it is
> uncoupled... Or maybe shift a bit (by gap/2 difference for each side)
>
> On Tue, 22 Sep 2020 at 22:23, Kliment (Future Bits) 
> wrote:
>
>> Having just routed a board with 56 diffpairs I have an idea about number
>> 4:
>>
>> I think we should treat diffpairs as single traces when routing and when
>> using the pns functionality to move them around. The trace should have
>> the thickness of 2x dpair trace width + 1x dpair trace gap, and have a
>> clearance of dpair clearance. It should behave as such a trace to the
>> pns and revert back to being a diffpair when shoving/pns manipulation is
>> done. This way dragging, rerouting, and shoving diffpairs works as
>> expected - it maintains the diffpairness of the pair. Length adjustment
>> works just as well on a single trace, and places where the pair splits
>> up or has a skew tune can remain locked while the trace is being
>> manipulated. This requires minimal change to the pns (we just feed it
>> different data) to work, and would dramatically improve the usability of
>> diffpairs because all the lovely stuff we can do to traces now will be
>> available to diffpairs without breakage. We still need the diffpair
>> routing logic for vias and for starting/ending pairs, but we have that
>> now.
>>
>> On 22.09.20 21:11, Tomasz Wlostowski wrote:
>> > My 5 quick cents:
>> >
>> >> 1) tool to visualize nets lengths (similar to
>> >> https://github.com/MitjaNemec/Kicad_action_plugins#length-stats
>> ). I
>> >> want to make a gui where you can define what nets you want to see
>> >> altogether. And it should show you length on each layer and
>> summary.
>> >> And vias as well.
>> >
>> >   2) Same stuff for length between 2 objects (for example via and
>> pad
>> >> for T-topology) similar to
>> >>
>> https://github.com/MitjaNemec/Kicad_action_plugins#pad2pad-track-distance
>> .
>> > New DRC will take care of that (checking length between arbitrary
>> > endpoints as well as reporting constrained length traces/diff pairs).
>> >
>> >
>> >> 3) some tool to define and automatically change tracks length on
>> >> different layers (to match target impedance)
>> > Did you mean per-layer width/gap constraints? abs(Impedance) is not
>> > related (at least not so simply) to trace lengths. We already have
>> > length tuner tool, with the V6 design rule system it will be able to
>> > pick length constraints from board design rules instead of hand-typed
>> > values.
>> >
>> >> 4) Tool to work with differential pairs.
>> > We didn't plan implementing such a tool. Beware that even if it happens,
>> > applying more than cosmetic changes to the routing globally will likely
>> > ruin your board so badly you'll spend rest of the day cleaning it up...
>> >
>> > Tom
>> >
>> >
>> > ___
>> > Mailing list: https://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] string translation error

[Nick Østergaard]

I think JP fixed this in
https://gitlab.com/kicad/code/kicad/-/commit/ff0a728753adf701a9d723b9f2b6484114e5dff1

On Mon, 14 Sep 2020 at 08:11, Marco Ciampa  wrote:

> See the message:
>
> pcbnew/drc/drc_engine.cpp:492: warning: Empty msgid.  It is reserved by
> GNU gettext:
> gettext("") returns the header
> entry with
> meta information, not the empty
> string.
>
> TIA
>
> --
>
> 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

Re: [Kicad-developers] Compilation doesn't find class_via.h

[Nick Østergaard]

It is the same for the windows nighlties.

On Tue, 8 Sep 2020 at 15:08, Eeli Kaikkonen  wrote:
>
> Compilation fails today:
>
> [4/14] Building CXX object 
> qa/drc_proto/CMakeFiles/drc_proto.dir/drc_test_provider_annulus.cpp.o
> FAILED: qa/drc_proto/CMakeFiles/drc_proto.dir/drc_test_provider_annulus.cpp.o
>
> /work/ohjelmointi/kicad/kicad-master/qa/drc_proto/drc_test_provider_annulus.cpp:26:10:
>  fatal error: class_via.h: No such file or directory
>26 | #include 
>   |  ^
>
>
> 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] running gerbview from local build on macOS

[Nick Østergaard]

Why don't you just install it?

On Wed, 19 Aug 2020 at 13:04, Jonatan Liljedahl  wrote:
>
> I see! But isn't gerbview always run standalone? Running pcbnew and
> eeschema from the main kicad project manager works fine from the build
> directory, as long as you don't open a pcb or schematic which are not
> named the same as the project - then it will launch a standalone
> instance.
>
> On Wed, Aug 19, 2020 at 12:14 PM Ian McInerney  
> wrote:
> >
> > My solution was not to use anything other than the main kicad launcher ;). 
> > So I never used standalone pcbnew/eeschema/gerbview/... on OSX. I did 
> > figure out what it would take to fix the kiface detection issue, and 
> > started https://gitlab.com/kicad/code/kicad/-/merge_requests/82 to try to 
> > make it so everything will work from the build directory, but I haven't 
> > gotten around to figuring out the Python pathing yet (that is the one that 
> > is most troublesome for me now that I switched back to a Linux daily driver 
> > machine - the kifaces just work for me now :) ).
> >
> > -Ian
> >
> > On Wed, Aug 19, 2020 at 10:39 AM Jeff Young  wrote:
> >>
> >> It’s a “thing” on OSX.  I run the attached script which fixes things up.  
> >> Sadly it has to be run after each build.
> >>
> >> I know Jon has the same issue, but I haven’t heard about it from Ian.  
> >> Perhaps he has a better solution….
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>
> >> On 19 Aug 2020, at 10:32, Jonatan Liljedahl  wrote:
> >>
> >> I now tried deleting the old system-wide /Applications/KiCad, and now
> >> when clicking the gerbview button in project manager it gives the same
> >> error about not finding _gerbview.kiface
> >>
> >> On Wed, Aug 19, 2020 at 11:25 AM Jonatan Liljedahl  
> >> wrote:
> >>
> >>
> >> Hi! I'm having difficulties launching gerbview from my local build.
> >>
> >> I'm opening kicad.app like this, while standing in the build directory
> >> (/Users/lijon/Coding/kicad/build/master)
> >>
> >>open kicad/kicad.app
> >>
> >> ...which works fine. However, clicking the gerbview button in the
> >> project manager launches an old gerbview installed in systemwide
> >> /Applications/KiCad/
> >>
> >> Trying to open it manually by
> >>
> >>open gerbview/gerbview.app
> >>
> >> fails with "Failed to load kiface library
> >> “/Users/lijon/Coding/kicad/build/Contents/PlugIns/_gerbview.kiface”
> >> and then crashes.
> >>
> >> Same with:
> >>
> >>./gerbview/gerbview.app/Contents/MacOS/gerbview
> >>
> >> except now it tries to look in
> >> /Users/lijon/Coding/kicad/build/master/Contents/PlugIns/
> >>
> >> I've also tried to stand in the kicad.app directory and open it from
> >> there, but with similar results.
> >>
> >> Any ideas how to run a locally built gerbview on macOS?
> >>
> >> Cheers
> >> --
> >> /Jonatan
> >> http://kymatica.com
> >>
> >>
> >>
> >>
> >> --
> >> /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
>
>
>
> --
> /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] Change in Library Team Leadership

[Nick Østergaard]

Hi Rene

Thank you for the heads up. You have contributed a lot, I am not
really in the loop with all the library maintenance effort, but the
libraries have certainly been kicked high up on the quality and
coverage lists while you have been around.

I don't even dare to mention other honorable librarians, in case I
forget someone :S  -- But -- Thank you all for moving the libs
forward. :)

Nick

On Wed, 26 Aug 2020 at 22:08, Adam Wolf  wrote:
>
> Thanks for everything, Rene!  Congrats on the job!
>
> On Wed, Aug 26, 2020 at 3:01 PM Rene Pöschl  wrote:
> >
> > Hi all,
> >
> >
> > the bad news up front, I no longer have the time to properly handle
> > leading the library team as i am now working full time and still have my
> > education to finish (Covid isn't much help either as it makes me lose a
> > bit of time as i try to avoid public transport at peak hours).
> >
> >
> > And now the good news. Christian Schlüter has volunteered to take over
> > as the team leader. I personally plan to be around and help as much as i
> > can with reviews but simply feel that i should give somebody a chance to
> > grow who has more time on their hand. To be honest i think he already
> > took on part of my roles as i had been absent for quite some time
> > (partly hoping i will find more time and partly just not wanting to
> > admit that i don't have it anymore).
> >
> >
> > Kind regards Rene
> >
> >
> > ___
> > Mailing list: https://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] Segmentation Fault when creating a copper zone

[Nick Østergaard]

Please submit it directly on gitlab as a merge request.

https://gitlab.com/kicad/code/kicad

fre. 21. aug. 2020 14.17 skrev Augusto Fraga Giachero :

> Hi,
>
> I've experienced crashes in pcbnew when creating a cooper fill zone when
> no board edges has been defined. Tuns out that BuildBoardPolygonOutlines
> is called with aErrorText set to nullptr an it tries to deference it to
> write an error message when no board edges has been found.
>
> The attached patch checks aErrorText and only deference it if it is not
> nullptr.
>
> Upon further investigation I discovered that the overloaded method
> BOARD::GetBoardPolygonOutlines is called from ZONE_FILLER::Fill with its
> default values of aErrorText and aErrorLocation (both nullptr). Wouldn't
> be better to supply a valid pointer to aErrorText to inform the user
> about the error / warning in this case?
>
> Thanks,
> Augusto.
> ___
> Mailing list: https://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] Fedora Rawhide build broken due to systemd-nspawn bug

[Nick Østergaard]

I assume rawhide maintainers will get this resolved when the dust settles.
At least the numbered fedoracore builds are building just fine on copr.

ons. 19. aug. 2020 23.25 skrev Steven A. Falco :

> I've been chasing a build failure on the nightlies for Fedora Rawhide
> whereby wxGTK3-devel is claimed to be missing, even though it is clearly
> installed.
>
> This bug explains what is going on:
> https://bugzilla.redhat.com/show_bug.cgi?id=1869030
>
> Fixes for the bug are in progress, but there is still some discussion as
> to where and when the fixes will appear.
>
> Unfortunately, I don't know of any workaround for the nightlies, because
> they are built on COPR.  Local mock builds can be done by passing
> --isolation=simple to mock.
>
> Steve
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] running gerbview from local build on macOS

[Nick Østergaard]

Isn't there a new cmakevariable to enable the binaries to be run from the
build dir?

ons. 19. aug. 2020 11.38 skrev Jeff Young :

> It’s a “thing” on OSX.  I run the attached script which fixes things up.
> Sadly it has to be run after each build.
>
> I know Jon has the same issue, but I haven’t heard about it from Ian.
> Perhaps he has a better solution….
>
> Cheers,
> Jeff.
>
>
>
> On 19 Aug 2020, at 10:32, Jonatan Liljedahl  wrote:
>
> I now tried deleting the old system-wide /Applications/KiCad, and now
> when clicking the gerbview button in project manager it gives the same
> error about not finding _gerbview.kiface
>
> On Wed, Aug 19, 2020 at 11:25 AM Jonatan Liljedahl 
> wrote:
>
>
> Hi! I'm having difficulties launching gerbview from my local build.
>
> I'm opening kicad.app like this, while standing in the build directory
> (/Users/lijon/Coding/kicad/build/master)
>
>open kicad/kicad.app
>
> ...which works fine. However, clicking the gerbview button in the
> project manager launches an old gerbview installed in systemwide
> /Applications/KiCad/
>
> Trying to open it manually by
>
>open gerbview/gerbview.app
>
> fails with "Failed to load kiface library
> “/Users/lijon/Coding/kicad/build/Contents/PlugIns/_gerbview.kiface”
> and then crashes.
>
> Same with:
>
>./gerbview/gerbview.app/Contents/MacOS/gerbview
>
> except now it tries to look in
> /Users/lijon/Coding/kicad/build/master/Contents/PlugIns/
>
> I've also tried to stand in the kicad.app directory and open it from
> there, but with similar results.
>
> Any ideas how to run a locally built gerbview on macOS?
>
> Cheers
> --
> /Jonatan
> http://kymatica.com
>
>
>
>
> --
> /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] Downloads storage maintenance

[Nick Østergaard]

Probably CEST, and 24h clock...

man. 17. aug. 2020 16.33 skrev Kevin Cozens :

> On 2020-08-17 3:58 a.m., Maciej Suminski wrote:
> > I have received a message saying that a virtual machine hosting the
> > downloads storage might be down on 7th September between 9:00 and 12:00.
>
> Is that AM or PM and in which time zone?
>
> --
> Cheers!
>
> Kevin.
>
> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
>  | that's why we're powerful"
> Owner of Elecraft K2 #2172  |
> #include  | --Chris Hardwick
>
> ___
> Mailing list: https://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] New Build Dependencies: Lemon + GTK3

[Nick Østergaard]

I think we should just get the updated solution merged that Ian made.
It does not use system lemon and there for not require it as an
external dependency, but addes the source file directly and fixes the
issue with the dirty flag. If someone want to make it be able to
switch to a system lemon if found, they should probably just base
their proposal on top of Ians merge request. Lets get it in and move
forward.

https://gitlab.com/kicad/code/kicad/-/merge_requests/318

On Mon, 3 Aug 2020 at 22:03, Wayne Stambaugh  wrote:
>
>
>
> On 8/3/20 3:31 PM, Ian McInerney wrote:
> > *sigh*... do it one way and people don't like it and then do it another
> > way and get more responses. I should just put it behind a
> > `KICAD_REGENERATE_LEMON_PARSER` flag that defaults to off to be done
> > with the damn thing. Then only people who actually want to regenerate
> > the parser grammars will need it.
>
> I'm fine with this option as well.  It fits with how we handle images
> where only developers need to use the grammar generator mode.
>
> >
> > The first lemon code was added in 2017, so the ship has sailed on this one.
> >
> > -Ian
> >
> > On Mon, Aug 3, 2020 at 8:01 PM Wayne Stambaugh  > > wrote:
> >
> > On 8/3/20 2:55 PM, Steven A. Falco wrote:
> > > On 8/3/20 2:47 PM, Wayne Stambaugh wrote:
> > >> On 8/3/20 2:42 PM, Steven A. Falco wrote:
> > >>> On 8/3/20 2:37 PM, Wayne Stambaugh wrote:
> >  On 8/3/20 2:01 PM, Carsten Schoenert wrote:
> > > Hello Ian,
> > >
> > > Am 03.08.20 um 19:39 schrieb Ian McInerney:
> > >> I have now updated this so that we bundle the lemon parser code
> > >> inside
> > >> thirdparty and build it for ourselves (it is only 1 main c
> > file that
> > >> was released into the public domain). CMake then takes care
> > of all
> > >> the
> > >> pathing for the template and executable file for the targets.
> > This
> > >> should work on all platforms now with no extra steps. It also
> > means
> > >> that there is no need to install lemon on dev computers anymore.
> > >
> > > unfortunately that is a typical thing how problems are getting
> > > "solved",
> > > simply embed the required third party code. From a security
> > > perspective
> > > this is mostly a nightmare as also typically nobody ever
> > touches such
> > > code again as it "works" for all times.
> > > Please try to avoid this when *ever* possible and look for
> > > alternatives.
> > > For package maintainers a good alternative is to make the use
> > of the
> > > third party code optional. Means that a configure switch should be
> > > available to so on the Linux side we can use the package versions.
> > >
> > > Embedded code is quite in no way traceable and make the work of
> > > package
> > > maintainers and of the security teams within Linux
> > distribution even
> > > more harder [1].
> > >
> > > So if not already the use of the lemon parser is configured in
> > a way I
> > > can chose to use a packaged version please consider to do so.
> > Thank
> > > you.
> > >
> > > [1] https://wiki.debian.org/EmbeddedCopies
> > >
> > 
> >  I could not have said it better myself.  We now have programmed
> >  ourselves into a third party library maintenance issue.  In the
> > future,
> >  all new dependencies should be run by the lead development team for
> >  discussion so we can plan how we want to handle them.
> > >>>
> > >>> What is the resolution?  Do I undo the dependency on the lemon
> > parser
> > >>> generator?  Or will there be a flag to select whether to
> > generate or use
> > >>> the canned one?
> > >>>
> > >>> I really don't like having this potentially work two different ways.
> > >>> Then there could be bugs that only show up when using a newer
> > lemon, or
> > >>> that show up when using the pregenerated code.  It is best to have
> > >>> exactly one way that this works.
> > >>>
> > >>>  Steve
> > >>>
> > >>
> > >> Would the solution proposed in my last post be sufficient?
> > >
> > > It would avoid adding a flag, but you'd still have the potential
> > problem
> > > that different platforms could end up behaving differently,
> > because some
> > > are using an older (canned) parser, and some are using a newer
> > > (generated) parser.  The risk in this instance is probably small,
> > but as
> > > a general principle, it is not good to have avoidable differences
> > > between platforms.
> > >
> > > That said, I'll be happy to adapt to whatever the lead devs decide.
> > >
> > > Steve
> > >
> >
> > 

Re: [Kicad-developers] Users grid - x, y

[Nick Østergaard]

I think it has always been like this. But there is only one user grid
selection, so I am not sure it is a real issue.

On Mon, 3 Aug 2020 at 17:02, Brian Piccioni  wrote:
>
> Hello
>
> While working on geographic annotation I note that it is possible to set
> different x and y for the user grid but the choice menu only shows one
> (I think the x).
>
> I also notice that in footprint_preview_panel.cpp it only takes one of
> the values.
>
> It seems the user grid setting menu is out of sync with the implementation.
>
> Am I missing something?
>
> 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

Re: [Kicad-developers] New Build Dependencies: Lemon + GTK3

[Nick Østergaard]

Not to throw a finger at anyone, but it has been quasi-optional for a while.

https://gitlab.com/kicad/code/kicad/-/blob/a146cd9e2e22c2b7100cb3c635f1e7733e346daf/common/CMakeLists.txt#L440-445

Although that just means that you won't see anything dirty if you
don't have lemon available on your system, but will unconditionally
use lemon if it is available and that will of course cause a diff for
the developer that may have it installed.

Also it looks like it has been commed in and out a couple of times before.

On Mon, 3 Aug 2020 at 21:00, Wayne Stambaugh  wrote:
>
> On 8/3/20 2:55 PM, Steven A. Falco wrote:
> > On 8/3/20 2:47 PM, Wayne Stambaugh wrote:
> >> On 8/3/20 2:42 PM, Steven A. Falco wrote:
> >>> On 8/3/20 2:37 PM, Wayne Stambaugh wrote:
>  On 8/3/20 2:01 PM, Carsten Schoenert wrote:
> > Hello Ian,
> >
> > Am 03.08.20 um 19:39 schrieb Ian McInerney:
> >> I have now updated this so that we bundle the lemon parser code
> >> inside
> >> thirdparty and build it for ourselves (it is only 1 main c file that
> >> was released into the public domain). CMake then takes care of all
> >> the
> >> pathing for the template and executable file for the targets. This
> >> should work on all platforms now with no extra steps. It also means
> >> that there is no need to install lemon on dev computers anymore.
> >
> > unfortunately that is a typical thing how problems are getting
> > "solved",
> > simply embed the required third party code. From a security
> > perspective
> > this is mostly a nightmare as also typically nobody ever touches such
> > code again as it "works" for all times.
> > Please try to avoid this when *ever* possible and look for
> > alternatives.
> > For package maintainers a good alternative is to make the use of the
> > third party code optional. Means that a configure switch should be
> > available to so on the Linux side we can use the package versions.
> >
> > Embedded code is quite in no way traceable and make the work of
> > package
> > maintainers and of the security teams within Linux distribution even
> > more harder [1].
> >
> > So if not already the use of the lemon parser is configured in a way I
> > can chose to use a packaged version please consider to do so. Thank
> > you.
> >
> > [1] https://wiki.debian.org/EmbeddedCopies
> >
> 
>  I could not have said it better myself.  We now have programmed
>  ourselves into a third party library maintenance issue.  In the future,
>  all new dependencies should be run by the lead development team for
>  discussion so we can plan how we want to handle them.
> >>>
> >>> What is the resolution?  Do I undo the dependency on the lemon parser
> >>> generator?  Or will there be a flag to select whether to generate or use
> >>> the canned one?
> >>>
> >>> I really don't like having this potentially work two different ways.
> >>> Then there could be bugs that only show up when using a newer lemon, or
> >>> that show up when using the pregenerated code.  It is best to have
> >>> exactly one way that this works.
> >>>
> >>>  Steve
> >>>
> >>
> >> Would the solution proposed in my last post be sufficient?
> >
> > It would avoid adding a flag, but you'd still have the potential problem
> > that different platforms could end up behaving differently, because some
> > are using an older (canned) parser, and some are using a newer
> > (generated) parser.  The risk in this instance is probably small, but as
> > a general principle, it is not good to have avoidable differences
> > between platforms.
> >
> > That said, I'll be happy to adapt to whatever the lead devs decide.
> >
> > Steve
> >
>
> I wasn't suggesting a flag.  I was suggesting that if CMake cannot find
> an acceptable version of lemon on the system during configuration, fall
> back to building lemon from source.
>
> ___
> Mailing list: https://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] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Nick Østergaard]

Did you try to use the normal makefile generator rather than the eclipse
one?

ons. 22. jul. 2020 01.37 skrev Brian Piccioni :

> FWIW, I re-cloned Kicad master into an empty directory, created a new
> build directory, ran the standard build script
>
> cmake -DCMAKE_BUILD_TYPE=Debug \
> -G "Eclipse CDT4 - Unix Makefiles" \
> -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
> -DMSYS=TRUE \
> ../kicad
>
> and got the same errors
>
>  Built target qa_eeschema
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
> undefined reference to `.refptr.PyObject_GenericGetAttr'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `std::invalid_argument::invalid_argument(std::invalid_argument const&)':
> C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference to
> `.refptr._ZTVSt16invalid_argument'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `std::_Sp_counted_deleter std::allocator,
> (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
> C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490: undefined
> reference to `typeinfo for SWIG_null_deleter'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
> `swig::traits_from::from(KIID const&)':
> C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
> undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
> C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
> undefined reference to `typeinfo name for SWIG_null_deleter'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
> pcbnew/_pcbnew.kiface] Error 1
> make[1]: *** [CMakeFiles/Makefile2:3284:
> pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
> make: *** [Makefile:161: all] Error 2
>
> bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
> $
>
>
>
> On 2020-07-21 2:54 p.m., Ian McInerney wrote:
>
> Ignore all of those notes being printed by the compiler about mismatched
> struct/class definition. There is a bug in GCC 10.1 that isn't silencing
> those properly, but that is fixed in GCC 10.2/GCC 11 (I think they are
> hoping to release 10.2 this week).
>
> The linker errors appear to be Python related. Did you update your Python
> installation that KiCad uses recently? Can you confirm that SWIG and Python
> are being detected correctly bby CMake?
>
> -Ian
>
> On Tue, Jul 21, 2020 at 6:58 PM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
>
>> Before updating master I had successfuIly build a c late June version.
>>
>> After failing to build yesterday's master I deleted my build directory,
>> pulled master, same problem. I then updated msys in order to make sure it
>> wasn't a tool issue. Same problem. I deleted the build directory and same
>> result.
>>
>> When I get home I'll try a new download of master and try that but I
>> expect the same result
>>
>> Note the earlier reply claiming to have had a similar problem.
>>
>> On Tue, Jul 21, 2020, 13:47 Nick Østergaard  wrote:
>>
>>> That looks quite strange. Did you try a clean build directort? Maybe
>>> there is some caching that is broken after a toolchain update?  Pure
>>> speculation.
>>>
>>>
>>> On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
>>>  wrote:
>>> >
>>> > It is a non-release tag, but as a developer I sort of need it to
>>> compile ...
>>> >
>>> > On 2020-07-21 10:45 a.m., Alex wrote:
>>> >
>>> > I too, also had the same errors, but assumed that 5.99 was some weird
>>> non-release tag, and switched to a different branch, as this is my first
>>> day building the application.
>>> >
>>> > On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni <
>>> br...@documenteddesigns.com> wrote:
>>&

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Nick Østergaard]

That looks quite strange. Did you try a clean build directort? Maybe
there is some caching that is broken after a toolchain update?  Pure
speculation.


On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
 wrote:
>
> It is a non-release tag, but as a developer I sort of need it to compile ...
>
> On 2020-07-21 10:45 a.m., Alex wrote:
>
> I too, also had the same errors, but assumed that 5.99 was some weird 
> non-release tag, and switched to a different branch, as this is my first day 
> building the application.
>
> On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni  
> wrote:
>>
>> When building I get a slew of errors or information messages of the type
>> (see below). During linking I then get a pile of "undefined" errors.
>> There are so many I can't reproduce them all.
>>
>> When I link I get a fatal error.
>>
>> This is the Master branch downloaded a few minutes before compiling. I
>> tried updating Msys and get the same result.
>>
>>
>> 42 |   struct ctype_base
>>|  ^~
>> In file included from C:/msys64/mingw64/include/c++/10.1.0/string:43,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
>> replace the class-key with 'struct'
>>125 |   class ctype_base;
>>| ^~
>> In file included from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
>>   from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
>>   from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
>>   from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
>>   from C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
>>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
>> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
>> note: 'std::ctype_base' defined as 'struct' here
>> 42 |   struct ctype_base
>>|  ^~
>> [ 93%] Building CXX object
>> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
>> In file included from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
>> C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note: replace the
>> class-key with 'struct'
>>574 |   friend class _Array<_Tp>;
>>|^~~
>> In file included from C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
>>   from
>> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
>> C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note:
>> 'std::_Array<_Tp>' defined as 'struct' here
>>396 | struct _Array
>>|^~
>> In file included from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
>>   from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
>>   from
>> C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
>>  

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

[Nick Østergaard]

Re: that.. https://www.spinics.net/lists/fedora-devel/msg274669.html

Quote from an Igor:

I'm confused by the proposal, it is named "CMake to do out-of-source builds"

but the macros seems to do the opposite?

On Rawhide (local repo):

%__cmake \
-S "%{_vpath_srcdir}" \
-B "%{__cmake_builddir}" \

__cmake_builddir
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
__cmake_in_source_build1

Looks like __cmake_builddir is defined as "." so the build will happen
in source?


On Mon, 20 Jul 2020 at 23:45, Nick Østergaard  wrote:
>
> I am not sure I misunderstand the terminology here, but "cmake -S . -B
> foo -Dnickersej" looks "in tree" to me.
>
> On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand  wrote:
> >
> > Hi Steve-
> >
> > This looks like a build setup issue, not in our CMake code.  We can
> > build out of tree (in fact, we really prefer it) right now.  From the
> > log, the broken command is
> > /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> > -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> > -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> > -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> > -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> > -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> > -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> > -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> > -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
> >
> > You can modify this in your .spec.template file.
> >
> > Best-
> > Seth
> >
> > Seth Hillbrand
> > KiCad Services Corporation
> > https://www.kipro-pcb.com
> > +1 530 302 5483 | +1 212 603 9372
> >
> > On 2020-07-20 14:28, Steven A. Falco wrote:
> > > Fedora recently made a change to their cmake macros, to force packages
> > > to build "out of tree".  The developers responsible for this change
> > > plan to go through and fix up the thousand or so packages that may
> > > break as a result, so they should eventually fix the official
> > > downstream KiCAD package.
> > >
> > > However, they will not be able to fix up third-party packages, one of
> > > which is our nightly builds.
> > >
> > > The attached email shows that KiCAD does indeed fail to build for
> > > Fedora rawhide now.  The right thing to do is to modify the
> > > kicad.spec.template file to accommodate the new cmake macros, but as a
> > > temporary workaround, we can add a line to force the old behavior:
> > >
> > > %global __cmake_in_source_build 1
> > >
> > > I've tried that, and it does let KiCAD build as before.
> > >
> > > I don't know exactly how the developers plan to fix up the broken
> > > packages, so we can either add the workaround, wait to see what they
> > > do, then change the nightlies to match (and remove the workaround), OR
> > > we can make our own changes, which may result in the spec files
> > > diverging.
> > >
> > > If the lead KiCAD devs wish, I can add the workaround - I can do that
> > > quickly.  Attempting to sort out a proper fix would naturally take
> > > longer.
> > >
> > >   Steve
> > >
> > >
> > >
> > > ___
> > > Mailing list: https://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] Build failure in Fedora Rawhide

[Nick Østergaard]

I am not sure I misunderstand the terminology here, but "cmake -S . -B
foo -Dnickersej" looks "in tree" to me.

On Mon, 20 Jul 2020 at 23:37, Seth Hillbrand  wrote:
>
> Hi Steve-
>
> This looks like a build setup issue, not in our CMake code.  We can
> build out of tree (in fact, we really prefer it) right now.  From the
> log, the broken command is
> /usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_PYTHON3=ON
> -DKICAD_SCRIPTING_WXPYTHON=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> -DKICAD_SCRIPTING_ACTION_MENU=ON -DKICAD_USE_OCC=ON
> -DKICAD_INSTALL_DEMOS=ON -DKICAD_BUILD_QA_TESTS=OFF
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SPICE=ON
> -DKICAD_VERSION_EXTRA=r19086-6d8fb94d -DCMAKE_BUILD_TYPE=Debug .
>
> You can modify this in your .spec.template file.
>
> Best-
> Seth
>
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
>
> On 2020-07-20 14:28, Steven A. Falco wrote:
> > Fedora recently made a change to their cmake macros, to force packages
> > to build "out of tree".  The developers responsible for this change
> > plan to go through and fix up the thousand or so packages that may
> > break as a result, so they should eventually fix the official
> > downstream KiCAD package.
> >
> > However, they will not be able to fix up third-party packages, one of
> > which is our nightly builds.
> >
> > The attached email shows that KiCAD does indeed fail to build for
> > Fedora rawhide now.  The right thing to do is to modify the
> > kicad.spec.template file to accommodate the new cmake macros, but as a
> > temporary workaround, we can add a line to force the old behavior:
> >
> > %global __cmake_in_source_build 1
> >
> > I've tried that, and it does let KiCAD build as before.
> >
> > I don't know exactly how the developers plan to fix up the broken
> > packages, so we can either add the workaround, wait to see what they
> > do, then change the nightlies to match (and remove the workaround), OR
> > we can make our own changes, which may result in the spec files
> > diverging.
> >
> > If the lead KiCAD devs wish, I can add the workaround - I can do that
> > quickly.  Attempting to sort out a proper fix would naturally take
> > longer.
> >
> >   Steve
> >
> >
> >
> > ___
> > Mailing list: https://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] Build failure in Fedora Rawhide

[Nick Østergaard]

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

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


On Mon, 20 Jul 2020 at 23:28, Steven A. Falco  wrote:
>
> Fedora recently made a change to their cmake macros, to force packages to 
> build "out of tree".  The developers responsible for this change plan to go 
> through and fix up the thousand or so packages that may break as a result, so 
> they should eventually fix the official downstream KiCAD package.
>
> However, they will not be able to fix up third-party packages, one of which 
> is our nightly builds.
>
> The attached email shows that KiCAD does indeed fail to build for Fedora 
> rawhide now.  The right thing to do is to modify the kicad.spec.template file 
> to accommodate the new cmake macros, but as a temporary workaround, we can 
> add a line to force the old behavior:
>
> %global __cmake_in_source_build 1
>
> I've tried that, and it does let KiCAD build as before.
>
> I don't know exactly how the developers plan to fix up the broken packages, 
> so we can either add the workaround, wait to see what they do, then change 
> the nightlies to match (and remove the workaround), OR we can make our own 
> changes, which may result in the spec files diverging.
>
> If the lead KiCAD devs wish, I can add the workaround - I can do that 
> quickly.  Attempting to sort out a proper fix would naturally take longer.
>
> Steve
>
>
> ___
> Mailing list: https://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] Critical path item / request for help

[Nick Østergaard]

If anyone is using vcpkg based dependencies for building kicad with
msvc, could you please test the build configurations that I have
enabled on jenkins?

See https://jenkins.simonrichter.eu/job/windows-kicad-msvc-vcpkg/

The debug build fails for 64 bit builds, and there is some issue with
curl for 32 bit builts for both debug and release.

Nick Østergaard

On Wed, 8 Jul 2020 at 02:08, Wayne Stambaugh  wrote:
>
> I wish I could say I was surprised.
>
> On 7/7/20 4:34 PM, Mark Roszko wrote:
> > vcpkg has a python3 build .. in fact, people actually complain vcpkg
> > wants to use its own python copy as a dependency for other libraries
> > like boost-python instead of system python (lol)
> >
> > On Tue, Jul 7, 2020 at 2:42 PM Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > This could be the straw that breaks the msvc camel's back.  If we are
> > tied to the installed Python on windows, the amount of effort required
> > to package KiCad on windows increases significantly.  Shipping KiCad
> > without Python on windows is not acceptable.
> >
> > On 7/7/20 2:36 PM, Jon Evans wrote:
> > > I am not sure there is much history of vcpkg and Python working
> > > together, so this might be breaking new ground.  It is nominally a
> > > package manager for C++ libraries, after all.
> > >
> > > On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> > >>
> > >> The wxPython Phoenix build system is ugly.  Before the Phoenix
> > work, it
> > >> used to respect the Python distutils configuration.  Now it just
> > steps
> > >> all over the Python distutils settings on windows and assumes
> > that the
> > >> only build platform used on windows is msvc.
> > >>
> > >> I have experience using Python distutils to build Python
> > libraries so I
> > >> can help with this although it's been a while so I'm a bit
> > rusty.  I've
> > >> never been a big fan of distutils.  It always seemed like a
> > solution in
> > >> search of a problem to me.  There are so many config/build tools
> > that do
> > >> the same thing far less painfully.
> > >>
> > >> One problem I see is that Python distutils is very much tied to the
> > >> current Python version installed.  I don't know how vcpkg handles
> > >> Python.  Do they use the installed Python or is it packaged as a
> > stand
> > >> alone port inside vcpkg?  If they use the installed Python, this
> > >> significantly complicates things as we will have to provide a
> > build for
> > >> every supported version of Python that could be installed on someones
> > >> system.  There is a big advantage with the current way we handle
> > Python
> > >> on windows.
> > >>
> > >> On 7/7/20 8:59 AM, Jon Evans wrote:
> > >>> Yes, wxWidgets I can now use straight from vcpkg.
> > >>>
> > >>> I took a look at wxPython phoenix and the build system
> > is...something else.
> > >>> Is anyone more experienced with Python build systems?
> > >>> It seems like the happy path for vcpkg is for projects that use
> > cmake.
> > >>> This hybrid of Python and C++ with custom build system in Python
> > looks
> > >>> like a headache to integrate.
> > >>>
> > >>> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> > >>> are less worried about that one)
> > >>>
> > >>> -Jon
> > >>>
> > >>> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko
> > mailto:mark.ros...@gmail.com>> wrote:
> > >>>>
> > >>>> Nope, I'm building straight out of vcpkg now.
> > >>>> Jon Evans posted the patches to kicad's findwxwidgets back in
> > November fyi.
> > >>>>
> > >>>> On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard
> > mailto:oe.n...@gmail.com>> wrote:
> > >>>>>
> > >>>>> Hi Mark
> > >>>>>
> > >>>>> I still need to patch FindwxWidgets.cmake, using this version:
> >   

Re: [Kicad-developers] Kicad 6 API

[Nick Østergaard]

Are you talking about the python scripting API,   or what is your intention?

tor. 9. jul. 2020 14.20 skrev Conrad Wood :

> Hi,
>
> I have a keen interest on APIs for Kicad6. I wonder if there are any
> documents describing the intented architecture and APIs of Kicad6 yet?
> If so could you give me a pointer where?
> If not, is there any interest in me starting a google doc and begin to
> propose something like it?
>
> Conrad
>
>
>
>
> ___
> Mailing list: https://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] Critical path item / request for help

[Nick Østergaard]

About the findwxWidgets, I see it has been updated in kicad, but
shouldn't such a fix be upstreamed in cmake as well?

I did a clean vcpkg environment and it does seem to compile again,
lets see if it works for x86 and x64 and debug and release in a couple
of hours.

I don't see any progress about OCC, I only saw a request to make it.

On Tue, 7 Jul 2020 at 14:59, Jon Evans  wrote:
>
> Yes, wxWidgets I can now use straight from vcpkg.
>
> I took a look at wxPython phoenix and the build system is...something else.
> Is anyone more experienced with Python build systems?
> It seems like the happy path for vcpkg is for projects that use cmake.
> This hybrid of Python and C++ with custom build system in Python looks
> like a headache to integrate.
>
> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> are less worried about that one)
>
> -Jon
>
> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
> >
> > Nope, I'm building straight out of vcpkg now.
> > Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.
> >
> > On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
> >>
> >> Hi Mark
> >>
> >> I still need to patch FindwxWidgets.cmake, using this version:
> >> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> >>
> >> See there two vcpkg issues:
> >> https://github.com/microsoft/vcpkg/issues/1843
> >> https://github.com/microsoft/vcpkg/issues/4756
> >>
> >> I thought you were using a selfbuilt version of wxwidgets. Have you
> >> started to use it directly from vcpkg?
> >>
> >> I use:
> >>
> >> cmake ^
> >> 
> >> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
> >> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> >> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> >> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> >> -DKICAD_SPICE=OFF ^
> >> -DKICAD_USE_OCE=OFF ^
> >> -DKICAD_SCRIPTING=OFF ^
> >> -DKICAD_SCRIPTING_MODULES=OFF ^
> >> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> >> ..\src
> >>
> >> cmake --build . --config %build% --target install -- /M
> >>
> >> Recently I started to get this error at install time:
> >>
> >> 23:48:21 -- Found OpenGL: opengl32
> >> 23:48:21 CMake Error at C:/Program
> >> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> >> (message):
> >> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> >> 23:48:21 Call Stack (most recent call first):
> >> 23:48:21   C:/Program
> >> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> >> (_FPHSA_FAILURE_MESSAGE)
> >> 23:48:21   CMakeModules/FindGLEW.cmake:38 
> >> (find_package_handle_standard_args)
> >> 23:48:21   
> >> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> >> (_find_package)
> >> 23:48:21   CMakeLists.txt:586 (find_package)
> >>
> >> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
> >> >
> >> > 1. cmake scripts already work with wxwidgets, that was already done 
> >> > awhile back. I've been building with MSVC for awhile
> >> >
> >> >
> >> >
> >> > One dependency that'll need "porting" is ngspice.
> >> > But let me put this out there, does it make sense to leave ngspice to a 
> >> > higher level distro and not built as part of kicad?
> >> > We've already had cases of repackaging Windows and macOS just to bump 
> >> > ngspice versions up.
> >> > Why not make it standard baseline as part of kicad instead of allowing 
> >> > versions to be mixed?
> >> >
> >> >
> >> > On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
> >> >>
> >> >> Just a FYI, we have not really solved wxpython phoenix for macos yet,
> >> >> though some progress were made recently.
> >> >>
> >> >> For MSVC there are a number of issues yet to be addressed, this is
> >> >> with the intention of using vcpkg.
> >> >>  1. Fix cmake scripts for wxwidgets
> >> >>  2. Add opencascade to vcpkg
> >> >>  3. Add swig to vcpkg (or sip if that is what we want to use in the 
> >> >> future)
> >> >>  4. Probably a small h

Re: [Kicad-developers] Critical path item / request for help

[Nick Østergaard]

Hi Mark

I still need to patch FindwxWidgets.cmake, using this version:
https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520

See there two vcpkg issues:
https://github.com/microsoft/vcpkg/issues/1843
https://github.com/microsoft/vcpkg/issues/4756

I thought you were using a selfbuilt version of wxwidgets. Have you
started to use it directly from vcpkg?

I use:

cmake ^
-DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
-DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
-DKICAD_SPICE=OFF ^
-DKICAD_USE_OCE=OFF ^
-DKICAD_SCRIPTING=OFF ^
-DKICAD_SCRIPTING_MODULES=OFF ^
-DKICAD_SCRIPTING_WXPYTHON=OFF ^
..\src

cmake --build . --config %build% --target install -- /M

Recently I started to get this error at install time:

23:48:21 -- Found OpenGL: opengl32
23:48:21 CMake Error at C:/Program
Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
(message):
23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
23:48:21 Call Stack (most recent call first):
23:48:21   C:/Program
Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
(_FPHSA_FAILURE_MESSAGE)
23:48:21   CMakeModules/FindGLEW.cmake:38 (find_package_handle_standard_args)
23:48:21   
C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
(_find_package)
23:48:21   CMakeLists.txt:586 (find_package)

On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
>
> 1. cmake scripts already work with wxwidgets, that was already done awhile 
> back. I've been building with MSVC for awhile
>
>
>
> One dependency that'll need "porting" is ngspice.
> But let me put this out there, does it make sense to leave ngspice to a 
> higher level distro and not built as part of kicad?
> We've already had cases of repackaging Windows and macOS just to bump ngspice 
> versions up.
> Why not make it standard baseline as part of kicad instead of allowing 
> versions to be mixed?
>
>
> On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
>>
>> Just a FYI, we have not really solved wxpython phoenix for macos yet,
>> though some progress were made recently.
>>
>> For MSVC there are a number of issues yet to be addressed, this is
>> with the intention of using vcpkg.
>>  1. Fix cmake scripts for wxwidgets
>>  2. Add opencascade to vcpkg
>>  3. Add swig to vcpkg (or sip if that is what we want to use in the future)
>>  4. Probably a small handful of other things need to be done
>>
>> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
>> >
>> > I love this part:
>> >
>> > wxPython4.0 (needed for Python3)
>> >
>> >
>> > And I thought our versioning was challenged. ;)
>> > ___
>> > Mailing list: https://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
>
>
>
> --
> 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] Critical path item / request for help

[Nick Østergaard]

Just a FYI, we have not really solved wxpython phoenix for macos yet,
though some progress were made recently.

For MSVC there are a number of issues yet to be addressed, this is
with the intention of using vcpkg.
 1. Fix cmake scripts for wxwidgets
 2. Add opencascade to vcpkg
 3. Add swig to vcpkg (or sip if that is what we want to use in the future)
 4. Probably a small handful of other things need to be done

On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
>
> I love this part:
>
> wxPython4.0 (needed for Python3)
>
>
> And I thought our versioning was challenged. ;)
> ___
> Mailing list: https://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] Scripting hooks

[Nick Østergaard]

I like the sound of this idea, it could definitely help the workflow
for a lot of people.

What may be related to this is some properly "plugin" manager such
that it is easier to bundle some script and have some script installed
external, similar to the freecad addon manager.

I don't remember if anyone is seriously working on that, I sorta
expect that to be on hold unstill eeschema gets scripting support.

On Tue, 30 Jun 2020 at 21:43, Eeli Kaikkonen  wrote:
>
> On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko  wrote:
>>
>> While more extensibility is great. I can only say expecting the user to use 
>> python exclusively for adding the new behavior like for issue #2339 is very 
>> crude.
>
>
> I'm not saying any possible feature which can be replaced with a script 
> should be replaced. It must be decided case by case. I don't even say that 
> these examples are something where an internal feature should be replaced 
> with a hook. They are just possible examples to show what could be possible. 
> Just think about it this way:
>
> 1. Which one is better, just let the users wait for the feature to be 
> implemented, or add a hook which makes it possible to implement it right away 
> in a simple way in a script and then let the users wait for it to be 
> implemented in KiCad proper later?
>
> 2. Each hook makes it possible to add any imaginable functionality, not just 
> one feature wish.
>
> 3. Adding a hook doesn't take anything away, it just adds possibilities.
>
> 4. Any developer is still free to implement anything  in C++. Like now they 
> are free to implement a functionality which has existed only in an action 
> script before.
>
> 5. Adding a hook doesn't change the UI or the behavior in any way. They 
> wouldn't cause any bugs if the backend for the hook system is good. Hooks 
> could be added even for bugfix releases. It may be much better than waiting 
> for one or two years for the next feature release.
>
>
>>
>> Not everyone is a programmer
>
>
> Sure. But big problems with scripting have been 1) the unstable API and 2) 
> the lack of asset infrastructure. Both are being worked on. When KiCad 
> scripting gets more traction and the scripts are easier to share and install, 
> not everyone needs to be a programmer and still can easily benefit from the 
> work from others. The potential number of python developers for simple 
> scripts like string  handling and generic file manipulation is certainly 
> larger than the amount of potential C++ developers.
>
> And if we take that #2339 as an example, it would require a real GUI in KiCad 
> proper (because it would need a way to manipulate the list of folders). A 
> python script would be one a couple of python functions and a list of text 
> strings. If  someone writes the script, anyone can change the list of 
> strings, there's no need to be a programmer to change the names of the 
> folders. So, which one would be the better option: 1) add a simple hook to 
> make it possible and implement the GUI later, or 2) not make it possible 
> until someone implements the GUI?
>
> 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] Auto-generated backup files: are they useful?

[Nick Østergaard]

Last time I looked, there was rescue feature in the file menu of pcbnew, I
think. I never used it, I don't really know what it does, but I guess it
just reads the bak file.

tir. 30. jun. 2020 09.32 skrev jp charras :

> Le 30/06/2020 à 00:13, hauptmech a écrit :
> >
> > While I agree that it is not KiCad's job to do archival backups or
> version control, I do think that KiCad should preserve the integrity of
> users data through a crash. Even better if the work between the last save
> and the crash is also preserved and recovered on restart.
> >
> > I have had to use the backup files to recover data in the past. I have
> no idea if that recovery was related to something that is now no longer a
> possible issue.
> >
> >
> > -Hauptmech
> >
> >
>
> I am also thinking a backup can be useful when something unexpected
> happens.
>
> Backups, like any security system, bothers you as long as you do not need
> to use them.
> But you are happy to find them in case of trouble.
>
> I like the way some CAD tools manage backup:
> only one zip archive is created (for instance projectname_backup.zip) and
> contains all saved files
> (in our case: *.kicad_sch (and sub paths) and .kicad_pcb)
> This is not a full project backup, just main files are saved.
>
> This is not invasive (only one file, or a few .zip if one want to keep
> last n saved versions)
> and is a security against  unexpected cases.
>
> For me, backups are like a accident insurance: you need them and you hope
> never use them.
>
> And about VCS use:
>
> Many good electronics guys do not even know what is it, and have never
> compiled any source code.
> Electronics world and Software world are not exactly the same world.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://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] GitLab milestone cleanup

[Nick Østergaard]

Ok, that sonds good to me.

fre. 26. jun. 2020 12.11 skrev Ian McInerney :

> In general, wishlist items should only be given a milestone if they are
> either:
> 1) Actively being worked on by a developer
> 2) Currently on the plan for the release they are milestoned against (this
> one doesn't need a developer assigned/working on them yet)
>
> Other wishlist items don't get a milestone attached to them. I don't think
> there is a need to have a "future" milestone though, since the GitLab
> interface makes it easy to look through issues with no milestone and the
> wishlist label (it is far easier than Launchpad was).
>
> -Ian
>
> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen 
> wrote:
>
>>
>>
>> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard 
>> wrote:
>>
>>> What about feature requests / wishes from users that are very unlikely
>>> to realise quickly? Should they still be assigned the new milestone?
>>>
>>> I just worry they may clutter the overview too much, but I guess when we
>>> will see how it goes. :) My concern may not be a real problem afterall.
>>>
>>> Nick
>>>
>>>
>> Could there be a milestone "Future" for features which are wanted but not
>> planned for the next release? For example, some things were in the v6
>> roadmap but were moved to the future roadmap, and even more can(?) be moved
>> later. It would be better to have them in Future milestone than keep them
>> in v6 milestone or remove the milestone completely.
>>
>> 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] GitLab milestone cleanup

[Nick Østergaard]

What about feature requests / wishes from users that are very unlikely to
realise quickly? Should they still be assigned the new milestone?

I just worry they may clutter the overview too much, but I guess when we
will see how it goes. :) My concern may not be a real problem afterall.

Nick


fre. 26. jun. 2020 00.49 skrev Jon Evans :

> Hi all,
>
> I wanted to make it more clear what the remaining work is for 6.0, so
> I created a new "6.0 Feature Freeze" milestone separate from the
> 6.0.0-rc1 milestone that already existed:
>
> Those with permissions to assign milestones on GitLab: please assign
> wishlist/feature-request items to the Feature Freeze milestone (if
> they will be worked on for 6.0) and bug reports to the 6.0.0-rc1
> milestone.  That way, we can keep track of the remaining work needed
> before feature freeze can happen separate from issues that could get
> fixed after feature freeze.
>
> Also, if anyone is planning on working on something for 6.0 and is not
> currently assigned to it in GitLab, please assign yourself the issue
> (and create the issue for it if it's not there yet!)
>
> Thanks,
> 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