Re: [Kicad-developers] MSYS2 Dropping 32-bit support

[Seth Hillbrand]

On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh  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.

Obviously, if we successfully move to MSVC, this question is moot.

-Seth

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

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

[Wayne Stambaugh]

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

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

[Ian McInerney]

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

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

[Wayne Stambaugh]

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

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

[Steven A. Falco]

On 8/3/20 2:47 PM, Wayne Stambaugh wrote:

On 8/3/20 2:42 PM, Steven A. Falco wrote:

On 8/3/20 2:37 PM, Wayne Stambaugh wrote:

On 8/3/20 2:01 PM, Carsten Schoenert wrote:

Hello Ian,

Am 03.08.20 um 19:39 schrieb Ian McInerney:

I have now updated this so that we bundle the lemon parser code inside
thirdparty and build it for ourselves (it is only 1 main c file that
was released into the public domain). CMake then takes care of all the
pathing for the template and executable file for the targets. This
should work on all platforms now with no extra steps. It also means
that there is no need to install lemon on dev computers anymore.


unfortunately that is a typical thing how problems are getting "solved",
simply embed the required third party code. From a security perspective
this is mostly a nightmare as also typically nobody ever touches such
code again as it "works" for all times.
Please try to avoid this when *ever* possible and look for alternatives.
For package maintainers a good alternative is to make the use of the
third party code optional. Means that a configure switch should be
available to so on the Linux side we can use the package versions.

Embedded code is quite in no way traceable and make the work of package
maintainers and of the security teams within Linux distribution even
more harder [1].

So if not already the use of the lemon parser is configured in a way I
can chose to use a packaged version please consider to do so. Thank you.

[1] https://wiki.debian.org/EmbeddedCopies



I could not have said it better myself.  We now have programmed
ourselves into a third party library maintenance issue.  In the future,
all new dependencies should be run by the lead development team for
discussion so we can plan how we want to handle them.


What is the resolution?  Do I undo the dependency on the lemon parser
generator?  Or will there be a flag to select whether to generate or use
the canned one?

I really don't like having this potentially work two different ways.
Then there could be bugs that only show up when using a newer lemon, or
that show up when using the pregenerated code.  It is best to have
exactly one way that this works.

 Steve



Would the solution proposed in my last post be sufficient?


It would avoid adding a flag, but you'd still have the potential problem that 
different platforms could end up behaving differently, because some are using 
an older (canned) parser, and some are using a newer (generated) parser.  The 
risk in this instance is probably small, but as a general principle, it is not 
good to have avoidable differences between platforms.

That said, I'll be happy to adapt to whatever the lead devs decide.

Steve

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

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

[Carsten Schoenert]

Am 03.08.20 um 20:42 schrieb Steven A. Falco:

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?


In my eyes there is only one solution. Always prefer a dependency as 
external required dependency and set a minimum version. This isn't a 
problem on Linux based platforms as the whole ecosystem is build as this.


But for the Windows OS this will mostly not work, that's why this whole 
discussion is happen. ;)


If have a lot of time read about the DLL symbol solving problem and how 
M$ tried to get this managed.


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

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

[Wayne Stambaugh]

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?

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

[Carsten Schoenert]

Mark,

Am 03.08.20 um 20:19 schrieb Mark Roszko:

But this is also a nightmare.


I don't know what you mean here.

1. The main issue is the tool is not a real independent tool, it is only 
maintained within sqlite and everyone using it outside of that are 
"welcome to" by sqlite but the global library that's available is quite 
out of scope of the sqlite maintainers.


The situation for lemon isn't that bad.
It's not an dedicated special thing within SQlite, it's included in the 
main source. So up-streaming any issues could be more worse I guess. 
Security isn't the main problem here. This would be more an out of date 
for functionality.


2. Which now leads to the scenario like Arch Linux has. There is no 
official repo with lemon. Only a 5-years out of date user repo that is 
not exactly helping with that security goal ;)


That's a problem of Arch distro then I'd say. Arch is for sure having 
SQlite as package, how about convincing the package maintainer to also 
ship the lemon part? Technically this can't be that difficult.


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

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

[Steven A. Falco]

On 8/3/20 2:37 PM, Wayne Stambaugh wrote:

On 8/3/20 2:01 PM, Carsten Schoenert wrote:

Hello Ian,

Am 03.08.20 um 19:39 schrieb Ian McInerney:

I have now updated this so that we bundle the lemon parser code inside
thirdparty and build it for ourselves (it is only 1 main c file that
was released into the public domain). CMake then takes care of all the
pathing for the template and executable file for the targets. This
should work on all platforms now with no extra steps. It also means
that there is no need to install lemon on dev computers anymore.


unfortunately that is a typical thing how problems are getting "solved",
simply embed the required third party code. From a security perspective
this is mostly a nightmare as also typically nobody ever touches such
code again as it "works" for all times.
Please try to avoid this when *ever* possible and look for alternatives.
For package maintainers a good alternative is to make the use of the
third party code optional. Means that a configure switch should be
available to so on the Linux side we can use the package versions.

Embedded code is quite in no way traceable and make the work of package
maintainers and of the security teams within Linux distribution even
more harder [1].

So if not already the use of the lemon parser is configured in a way I
can chose to use a packaged version please consider to do so. Thank you.

[1] https://wiki.debian.org/EmbeddedCopies



I could not have said it better myself.  We now have programmed
ourselves into a third party library maintenance issue.  In the future,
all new dependencies should be run by the lead development team for
discussion so we can plan how we want to handle them.


What is the resolution?  Do I undo the dependency on the lemon parser 
generator?  Or will there be a flag to select whether to generate or use the 
canned one?

I really don't like having this potentially work two different ways.  Then 
there could be bugs that only show up when using a newer lemon, or that show up 
when using the pregenerated code.  It is best to have exactly one way that this 
works.

Steve


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

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

[Wayne Stambaugh]

On 8/3/20 2:19 PM, Mark Roszko wrote:
>> 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.
>>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].
> 
> But this is also a nightmare.
> 1. The main issue is the tool is not a real independent tool, it is only
> maintained within sqlite and everyone using it outside of that are
> "welcome to" by sqlite but the global library that's available is quite
> out of scope of the sqlite maintainers.
> 2. Which now leads to the scenario like Arch Linux has. There is no
> official repo with lemon. Only a 5-years out of date user repo that is
> not exactly helping with that security goal ;)
> 
> But yea, perhaps a configure switch will make this all happy?

Why not use CMake to check to see if lemon is installed on the system
and only build for source when necessary?

> 
> 
> On Mon, Aug 3, 2020 at 2:01 PM Carsten Schoenert
> mailto:c.schoen...@t-online.de>> 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
> 
> -- 
> 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
> 
> 
> 
> -- 
> 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] New Build Dependencies: Lemon + GTK3

[Wayne Stambaugh]

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.

Wayne

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

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

[Wayne Stambaugh]

Just a reminder for developers, this should have happened before any new
dependency was even pulled into KiCad and not resolved after the fact.
If we ran into a situation where we had to spend a lot of time fixing
lemon or could not build it on a given platform, we would be force to
revert all the code that depended on it or write our own solution.

On 8/3/20 1:54 PM, Roberto Fernández Bautista wrote:
> Thanks for that Ian - that sounds great! Definitely a much cleaner
> solution. Did you create a separate branch for this change or is it in
> master?
> 
> Thanks.
> 
> 
> 
> On Mon, 3 Aug 2020 at 18:40, Ian McInerney  > wrote:
> 
> 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.
> 
> -Ian
> 
> On Sun, Aug 2, 2020 at 11:46 PM Mark Roszko  > wrote:
> 
> LOL, "lemon" in VCPKG is not Lemon the grammar generator, it's
> Lemon the boost graph library.
> 
> And lemon grammar itself, isn't a real library. It's a single C
> file. It's very unlikely to be accepted into vcpkg.
> 
> We may as well just build it on the fly in kicad
> https://www.sqlite.org/src/file/tool/lemon.c 
>  
> 
> On Sun, Aug 2, 2020 at 6:37 PM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> 
> MSVC support is a work in progress so it's not that its not
> supported, it's just someone needs to fix it ;)
> 
> On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista
>  > wrote:
> 
> Just tried your branch and unfortunately couldn't get it
> to compile on Visual Studio (even after a "vcpkg install
> lemon:x64-windows" and "vcpkg integrate install")... I
> got the cmake error "lemon not found"
> 
> I know Visual Studio isn't officially supported but any
> ideas what I could do to install lemon correctly so
> visual studio/ cmake can recognise it?
> 
> Thanks
> 
> Roberto
> 
> On Sun, 2 Aug 2020 at 22:06, Ian McInerney
>  > wrote:
> 
> Yes, I have a branch on my fork [1] called
> "im/lemon" that can be used. It can be found
> here: https://gitlab.com/imcinerney/kicad/-/tree/im/lemon.
> If the build passes with that, it means lemon
> integration is working. CMake should error during
> configuration if the lemon executable can't be found
> 
> -Ian
> 
> [1] https://gitlab.com/imcinerney/kicad
> 
> On Sun, Aug 2, 2020 at 10:01 PM Adam Wolf
>  > wrote:
> 
> Is there a branch packages can use to make sure
> their lemon integration is working?
> 
> On Sun, Aug 2, 2020, 4:00 PM Ian McInerney
>  > wrote:
> 
> Two new build-time dependencies are being
> added to the master branch for v6:
> * lemon - The lemon parser generator
> * GTK3 (linux only) - the GTK3 libraries
> (only GTK3, not GTK2 - that is not supported
> anymore). This is technically also a runtime
> dependency, but we also need GTK3 for
> wxWidgets, so it shouldn't be a new runtime
> dep (only needing the build headers are new).
> 
> The lemon parser is needed to
> fix 
> https://gitlab.com/kicad/code/kicad/-/issues/5013 by
> changing how the files are generated (in
> MR 
> https://gitlab.com/kicad/code/kicad/-/merge_requests/318).
> GTK3 is needed to enable new functionality
> inside the platform-specific
> KIPLATFORM library for Linux (such as
> overriding menu settings, moving files to
> trash, etc.)
> 
> All 

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

[Kevin Lannen]

On Mon, Aug 3, 2020 at 12:19 PM Mark Roszko  wrote:

> > 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.
> >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].
>
> But this is also a nightmare.
> 1. The main issue is the tool is not a real independent tool, it is only
> maintained within sqlite and everyone using it outside of that are "welcome
> to" by sqlite but the global library that's available is quite out of scope
> of the sqlite maintainers.
> 2. Which now leads to the scenario like Arch Linux has. There is no
> official repo with lemon. Only a 5-years out of date user repo that is not
> exactly helping with that security goal ;)
>
> But yea, perhaps a configure switch will make this all happy?
>
>
I know there has been quite a bit of focus on using VCPKG as a package
manager on Windows but this sort of problem seems to me like it would be
better solved with a tool like Conan. https://conan.io/

Conan would allow us to publish a package that can be built and consumed on
any platform since it is cross platform. This would allow any platform to
use it easily and would not require putting the source into KiCad.

I have used Conan on several previous projects and it gives a very nice
experience since building on all platforms is the same process to build and
install dependencies.

Regards,

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

[Mark Roszko]

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

But this is also a nightmare.
1. The main issue is the tool is not a real independent tool, it is only
maintained within sqlite and everyone using it outside of that are "welcome
to" by sqlite but the global library that's available is quite out of scope
of the sqlite maintainers.
2. Which now leads to the scenario like Arch Linux has. There is no
official repo with lemon. Only a 5-years out of date user repo that is not
exactly helping with that security goal ;)

But yea, perhaps a configure switch will make this all happy?


On Mon, Aug 3, 2020 at 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
>
> --
> 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
>


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

[Carsten Schoenert]

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

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

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

[Roberto Fernández Bautista]

Thanks for that Ian - that sounds great! Definitely a much cleaner
solution. Did you create a separate branch for this change or is it in
master?

Thanks.



On Mon, 3 Aug 2020 at 18:40, Ian McInerney  wrote:

> 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.
>
> -Ian
>
> On Sun, Aug 2, 2020 at 11:46 PM Mark Roszko  wrote:
>
>> LOL, "lemon" in VCPKG is not Lemon the grammar generator, it's Lemon the
>> boost graph library.
>>
>> And lemon grammar itself, isn't a real library. It's a single C file.
>> It's very unlikely to be accepted into vcpkg.
>>
>> We may as well just build it on the fly in kicad
>> https://www.sqlite.org/src/file/tool/lemon.c
>>
>>
>> On Sun, Aug 2, 2020 at 6:37 PM Mark Roszko  wrote:
>>
>>> MSVC support is a work in progress so it's not that its not supported,
>>> it's just someone needs to fix it ;)
>>>
>>> On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista <
>>> roberto.fer@gmail.com> wrote:
>>>
 Just tried your branch and unfortunately couldn't get it to compile on
 Visual Studio (even after a "vcpkg install lemon:x64-windows" and "vcpkg
 integrate install")... I got the cmake error "lemon not found"

 I know Visual Studio isn't officially supported but any ideas what I
 could do to install lemon correctly so visual studio/ cmake can recognise
 it?

 Thanks

 Roberto

 On Sun, 2 Aug 2020 at 22:06, Ian McInerney 
 wrote:

> Yes, I have a branch on my fork [1] called "im/lemon" that can be
> used. It can be found here:
> https://gitlab.com/imcinerney/kicad/-/tree/im/lemon. If the build
> passes with that, it means lemon integration is working. CMake should 
> error
> during configuration if the lemon executable can't be found
>
> -Ian
>
> [1] https://gitlab.com/imcinerney/kicad
>
> On Sun, Aug 2, 2020 at 10:01 PM Adam Wolf <
> adamw...@feelslikeburning.com> wrote:
>
>> Is there a branch packages can use to make sure their lemon
>> integration is working?
>>
>> On Sun, Aug 2, 2020, 4:00 PM Ian McInerney 
>> wrote:
>>
>>> Two new build-time dependencies are being added to the master branch
>>> for v6:
>>> * lemon - The lemon parser generator
>>> * GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that
>>> is not supported anymore). This is technically also a runtime 
>>> dependency,
>>> but we also need GTK3 for wxWidgets, so it shouldn't be a new runtime 
>>> dep
>>> (only needing the build headers are new).
>>>
>>> The lemon parser is needed to fix
>>> https://gitlab.com/kicad/code/kicad/-/issues/5013 by changing how
>>> the files are generated (in MR
>>> https://gitlab.com/kicad/code/kicad/-/merge_requests/318). GTK3 is
>>> needed to enable new functionality inside the platform-specific
>>> KIPLATFORM library for Linux (such as overriding menu settings, moving
>>> files to trash, etc.)
>>>
>>> All developers should make sure they have these new dependencies
>>> installed, and nightly builds should add them to their build script 
>>> (Steve,
>>> thanks for updating Fedora's so quick!) I have opened issue on GitLab 
>>> for
>>> the builders on there:
>>> https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/101
>>> https://gitlab.com/kicad/packaging/kicad-mac-builder/-/issues/332
>>>
>>> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/issues/2
>>>
>>> I haven't merged any code into master that needs them yet, but I
>>> would like to merge the lemon fix as soon as possible (the problem it is
>>> solving has attracted increased attention it seems).
>>>
>>> -Ian
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : 

Re: [Kicad-developers] MSYS2 Dropping 32-bit support

[Wayne Stambaugh]

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.

On 8/1/20 10:20 PM, Mark Roszko wrote:
> Only just noticed this
> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported
>  
> 
> As a whole to KiCad, only 6% of Windows users will be affected.
> 
> I did change the website awhile back to more prominently push people
> onto 64-bit builds. 
> 
> Just the world finally moving forward with technology :D
> 
> -- 
> 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] New Build Dependencies: Lemon + GTK3

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

-Ian

On Sun, Aug 2, 2020 at 11:46 PM Mark Roszko  wrote:

> LOL, "lemon" in VCPKG is not Lemon the grammar generator, it's Lemon the
> boost graph library.
>
> And lemon grammar itself, isn't a real library. It's a single C file. It's
> very unlikely to be accepted into vcpkg.
>
> We may as well just build it on the fly in kicad
> https://www.sqlite.org/src/file/tool/lemon.c
>
>
> On Sun, Aug 2, 2020 at 6:37 PM Mark Roszko  wrote:
>
>> MSVC support is a work in progress so it's not that its not supported,
>> it's just someone needs to fix it ;)
>>
>> On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista <
>> roberto.fer@gmail.com> wrote:
>>
>>> Just tried your branch and unfortunately couldn't get it to compile on
>>> Visual Studio (even after a "vcpkg install lemon:x64-windows" and "vcpkg
>>> integrate install")... I got the cmake error "lemon not found"
>>>
>>> I know Visual Studio isn't officially supported but any ideas what I
>>> could do to install lemon correctly so visual studio/ cmake can recognise
>>> it?
>>>
>>> Thanks
>>>
>>> Roberto
>>>
>>> On Sun, 2 Aug 2020 at 22:06, Ian McInerney 
>>> wrote:
>>>
 Yes, I have a branch on my fork [1] called "im/lemon" that can be used.
 It can be found here:
 https://gitlab.com/imcinerney/kicad/-/tree/im/lemon. If the build
 passes with that, it means lemon integration is working. CMake should error
 during configuration if the lemon executable can't be found

 -Ian

 [1] https://gitlab.com/imcinerney/kicad

 On Sun, Aug 2, 2020 at 10:01 PM Adam Wolf <
 adamw...@feelslikeburning.com> wrote:

> Is there a branch packages can use to make sure their lemon
> integration is working?
>
> On Sun, Aug 2, 2020, 4:00 PM Ian McInerney 
> wrote:
>
>> Two new build-time dependencies are being added to the master branch
>> for v6:
>> * lemon - The lemon parser generator
>> * GTK3 (linux only) - the GTK3 libraries (only GTK3, not GTK2 - that
>> is not supported anymore). This is technically also a runtime dependency,
>> but we also need GTK3 for wxWidgets, so it shouldn't be a new runtime dep
>> (only needing the build headers are new).
>>
>> The lemon parser is needed to fix
>> https://gitlab.com/kicad/code/kicad/-/issues/5013 by changing how
>> the files are generated (in MR
>> https://gitlab.com/kicad/code/kicad/-/merge_requests/318). GTK3 is
>> needed to enable new functionality inside the platform-specific
>> KIPLATFORM library for Linux (such as overriding menu settings, moving
>> files to trash, etc.)
>>
>> All developers should make sure they have these new dependencies
>> installed, and nightly builds should add them to their build script 
>> (Steve,
>> thanks for updating Fedora's so quick!) I have opened issue on GitLab for
>> the builders on there:
>> https://gitlab.com/kicad/packaging/kicad-win-builder/-/issues/101
>> https://gitlab.com/kicad/packaging/kicad-mac-builder/-/issues/332
>>
>> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/issues/2
>>
>> I haven't merged any code into master that needs them yet, but I
>> would like to merge the lemon fix as soon as possible (the problem it is
>> solving has attracted increased attention it seems).
>>
>> -Ian
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Users grid - x, y

[Brian Piccioni]

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