[Kicad-developers] Torrent downloads

[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

Re: [Kicad-developers] 5.1.7 tagged.

[Adam Wolf]

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  
>>> 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 
>>> >> > > 
>>> >> > > 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 ready.
>>> >> > > > > > >
>>> >> > > > > > > I think the macos build may be a bit 

Re: [Kicad-developers] Thanks for all the new work on the 3D rendering.

[Bevan Weiss]

Do we currently have a line that says:
glEnable(GL_CULL_FACE)

That turns on face culling, so removing that should:
a. Render the back of triangles
b. Decrease the performance a little where back faces are indeed internal / 
non-visible (although z-cull should help with these also)



Regards,
Bevan


On 1 Oct. 2020, 07:48, at 07:48, "Mário Luzeiro"  wrote:
>> Normally culling of polygons with non-camera facing normals is an
>optimisation and can be turned off.
>
>It is but I'm not sure / dont remember then how it will work with the
>lighting.
>
>I'm not sure if the "facing normals" are the only issue. It could be
>also related with triangle orientation?
>
>
>> Is this not possible in the 3d render libraries we're using?
>
>The libraries are OpenGL and KiCad source code :)
>
>Mario
>
>
>From: Bevan Weiss 
>Sent: 30 September 2020 22:32
>To: Cirilo Bernardo
>Cc: Mário Luzeiro; kicad-developers@lists.launchpad.net
>Subject: Re: [Kicad-developers] Thanks for all the new work on the 3D
>rendering.
>
>Normally culling of polygons with non-camera facing normals is an
>optimisation and can be turned off.
>Is this not possible in the 3d render libraries we're using?
>
>
>Regards,
>Bevan
>On 1 Oct. 2020, at 06:23, Cirilo Bernardo
>mailto:cirilo.berna...@gmail.com>> wrote:
>
>Hi Mario,
>
> I never thought of a good way to manage the doubling of the vertices /
>viewing from both sides. Since this is a problem of IGES as well as
>VRML models (especially models not produced via MCAD) and it
>makes no sense to me to complicate KiCad or the 3D viewer, maybe
>one way to fix this would be to mark a bad model file by putting a
>'_' at the end of the name, for example 'broken-model_.igs". Files
>with that tag will be assumed to have bad normals and the vertices
>will be doubled, otherwise normals are assumed to be good.
>
>Cirilo
>
>
>On Thu, Oct 1, 2020 at 12:36 AM Mário Luzeiro  wrote:
>
> Thanks Cirilo!
> It has been small additions but resulted in good improvements...
>
> results in a doubling of the triangular surfaces
>
> Could an option be added to this? ( both exporter and 3D-Viewer )
>
>I didn't know / don't remember this condition, but I have an idea of
>some inverted models cases too...
>
> Mario
>
>
>
>From: Kicad-developers
>http://ua.pt>@lists.launchpad.net>
>on behalf of Cirilo Bernardo 
> Sent: 29 September 2020 04:51
> To: KiCad Developers
>Subject: [Kicad-developers] Thanks for all the new work on the 3D
>rendering.
>
> I see the latest changes from Mario Luzeiro and Oleg Endo.  Wow .. the
> 3D viewer has improved so much since Mario and I rewrote the code 6+
> years ago.  I'm very glad to see people continuing to make
> improvements.  If anyone has time and wants a challenge there are 2
> items I'm not very happy with in the 3D system. One is due to our
> early support for VRML only models as well as IGES models, and the
> second issue is due to mistakes I made in interpreting the VRML
> specification.
>
> 1. Legacy issue: the import of a VRML model (including those exported
> by kicad) or an IGES model results in a doubling of the triangular
> surfaces. So if you import a box described by 12 triangles that is
> double to 24 and if you export the model and import it again you get
> 48 triangles, and so on. The reason is that every facet is rendered
> from *both* sides and there is no algorithm for decimating the
> triangle data.  The reason triangles were rendered from both sides is
> that many (well, *most*) VRML models which we used before the 3D
> overhaul were defective and the viewing normals were not guaranteed to
> be correct (a facet described as viewable from the wrong side).  IGES
> models also suffer this problem because the specification does not
> provide a requirement of a 'right-hand rule' to determine the Inner
> side vs Outer side of a surface and various CAD packages seemed to
> either use a right-hand rule, left-hand rule, or no rule.  The
> triangle bloating problem will obviously have disastrous consequences
> for rendering time.  As an alternative to decimating the triangles,
> any VRML model exported by KiCad could be specially tagged (similar to
> how PDF uses some special comments) so that the importer does not
> double the triangles. The advantage of this would be that the VRML
> models generated from solid models via scripts could also be tagged
> and the doubleg could be avoided altogether where appropriate.
>
> 2. Incorrect interpretation of VRML spec.  This is really a fairly
> minor issue and I don't believe there is any evidence that it has an
> impact on VRML models generated from solid models via
> OpenCascade/FreeCAD.  Unfortunately I can't remember the exact problem
> now, but at least one of the VRML groups are not correctly implemented
> and as a result cannot be correctly referenced by more than 1 other
> group. Fixing the implementation could produce a more efficient
> exported model in some use 

Re: [Kicad-developers] Thanks for all the new work on the 3D rendering.

[Mário Luzeiro]

> Normally culling of polygons with non-camera facing normals is an 
> optimisation and can be turned off.

It is but I'm not sure / dont remember then how it will work with the lighting.

I'm not sure if the "facing normals" are the only issue. It could be also 
related with triangle orientation?


> Is this not possible in the 3d render libraries we're using?

The libraries are OpenGL and KiCad source code :)

Mario


From: Bevan Weiss 
Sent: 30 September 2020 22:32
To: Cirilo Bernardo
Cc: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Thanks for all the new work on the 3D rendering.

Normally culling of polygons with non-camera facing normals is an optimisation 
and can be turned off.
Is this not possible in the 3d render libraries we're using?


Regards,
Bevan
On 1 Oct. 2020, at 06:23, Cirilo Bernardo 
mailto:cirilo.berna...@gmail.com>> wrote:

Hi Mario,

 I never thought of a good way to manage the doubling of the vertices /
viewing from both sides. Since this is a problem of IGES as well as
VRML models (especially models not produced via MCAD) and it
makes no sense to me to complicate KiCad or the 3D viewer, maybe
one way to fix this would be to mark a bad model file by putting a
'_' at the end of the name, for example 'broken-model_.igs". Files
with that tag will be assumed to have bad normals and the vertices
will be doubled, otherwise normals are assumed to be good.

Cirilo


On Thu, Oct 1, 2020 at 12:36 AM Mário Luzeiro  wrote:

 Thanks Cirilo!
 It has been small additions but resulted in good improvements...

 results in a doubling of the triangular surfaces

 Could an option be added to this? ( both exporter and 3D-Viewer )

 I didn't know / don't remember this condition, but I have an idea of some 
inverted models cases too...

 Mario



 From: Kicad-developers 
http://ua.pt>@lists.launchpad.net> on 
behalf of Cirilo Bernardo 
 Sent: 29 September 2020 04:51
 To: KiCad Developers
 Subject: [Kicad-developers] Thanks for all the new work on the 3D rendering.

 I see the latest changes from Mario Luzeiro and Oleg Endo.  Wow .. the
 3D viewer has improved so much since Mario and I rewrote the code 6+
 years ago.  I'm very glad to see people continuing to make
 improvements.  If anyone has time and wants a challenge there are 2
 items I'm not very happy with in the 3D system. One is due to our
 early support for VRML only models as well as IGES models, and the
 second issue is due to mistakes I made in interpreting the VRML
 specification.

 1. Legacy issue: the import of a VRML model (including those exported
 by kicad) or an IGES model results in a doubling of the triangular
 surfaces. So if you import a box described by 12 triangles that is
 double to 24 and if you export the model and import it again you get
 48 triangles, and so on. The reason is that every facet is rendered
 from *both* sides and there is no algorithm for decimating the
 triangle data.  The reason triangles were rendered from both sides is
 that many (well, *most*) VRML models which we used before the 3D
 overhaul were defective and the viewing normals were not guaranteed to
 be correct (a facet described as viewable from the wrong side).  IGES
 models also suffer this problem because the specification does not
 provide a requirement of a 'right-hand rule' to determine the Inner
 side vs Outer side of a surface and various CAD packages seemed to
 either use a right-hand rule, left-hand rule, or no rule.  The
 triangle bloating problem will obviously have disastrous consequences
 for rendering time.  As an alternative to decimating the triangles,
 any VRML model exported by KiCad could be specially tagged (similar to
 how PDF uses some special comments) so that the importer does not
 double the triangles. The advantage of this would be that the VRML
 models generated from solid models via scripts could also be tagged
 and the doubleg could be avoided altogether where appropriate.

 2. Incorrect interpretation of VRML spec.  This is really a fairly
 minor issue and I don't believe there is any evidence that it has an
 impact on VRML models generated from solid models via
 OpenCascade/FreeCAD.  Unfortunately I can't remember the exact problem
 now, but at least one of the VRML groups are not correctly implemented
 and as a result cannot be correctly referenced by more than 1 other
 group. Fixing the implementation could produce a more efficient
 exported model in some use cases.

 Cirilo



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



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

Re: [Kicad-developers] Thanks for all the new work on the 3D rendering.

[Bevan Weiss]

Normally culling of polygons with non-camera facing normals is an optimisation 
and can be turned off.
Is this not possible in the 3d render libraries we're using?


Regards,
Bevan


On 1 Oct. 2020, 06:23, at 06:23, Cirilo Bernardo  
wrote:
>Hi Mario,
>
> I never thought of a good way to manage the doubling of the vertices /
>viewing from both sides. Since this is a problem of IGES as well as
>VRML models (especially models not produced via MCAD) and it
>makes no sense to me to complicate KiCad or the 3D viewer, maybe
>one way to fix this would be to mark a bad model file by putting a
>'_' at the end of the name, for example 'broken-model_.igs". Files
>with that tag will be assumed to have bad normals and the vertices
>will be doubled, otherwise normals are assumed to be good.
>
>Cirilo
>
>
>On Thu, Oct 1, 2020 at 12:36 AM Mário Luzeiro  wrote:
>>
>> Thanks Cirilo!
>> It has been small additions but resulted in good improvements...
>>
>> > results in a doubling of the triangular surfaces
>>
>> Could an option be added to this? ( both exporter and 3D-Viewer )
>>
>> I didn't know / don't remember this condition, but I have an idea of
>some inverted models cases too...
>>
>> Mario
>>
>> 
>> From: Kicad-developers
> on
>behalf of Cirilo Bernardo 
>> Sent: 29 September 2020 04:51
>> To: KiCad Developers
>> Subject: [Kicad-developers] Thanks for all the new work on the 3D
>rendering.
>>
>> I see the latest changes from Mario Luzeiro and Oleg Endo.  Wow ..
>the
>> 3D viewer has improved so much since Mario and I rewrote the code 6+
>> years ago.  I'm very glad to see people continuing to make
>> improvements.  If anyone has time and wants a challenge there are 2
>> items I'm not very happy with in the 3D system. One is due to our
>> early support for VRML only models as well as IGES models, and the
>> second issue is due to mistakes I made in interpreting the VRML
>> specification.
>>
>> 1. Legacy issue: the import of a VRML model (including those exported
>> by kicad) or an IGES model results in a doubling of the triangular
>> surfaces. So if you import a box described by 12 triangles that is
>> double to 24 and if you export the model and import it again you get
>> 48 triangles, and so on. The reason is that every facet is rendered
>> from *both* sides and there is no algorithm for decimating the
>> triangle data.  The reason triangles were rendered from both sides is
>> that many (well, *most*) VRML models which we used before the 3D
>> overhaul were defective and the viewing normals were not guaranteed
>to
>> be correct (a facet described as viewable from the wrong side).  IGES
>> models also suffer this problem because the specification does not
>> provide a requirement of a 'right-hand rule' to determine the Inner
>> side vs Outer side of a surface and various CAD packages seemed to
>> either use a right-hand rule, left-hand rule, or no rule.  The
>> triangle bloating problem will obviously have disastrous consequences
>> for rendering time.  As an alternative to decimating the triangles,
>> any VRML model exported by KiCad could be specially tagged (similar
>to
>> how PDF uses some special comments) so that the importer does not
>> double the triangles. The advantage of this would be that the VRML
>> models generated from solid models via scripts could also be tagged
>> and the doubleg could be avoided altogether where appropriate.
>>
>> 2. Incorrect interpretation of VRML spec.  This is really a fairly
>> minor issue and I don't believe there is any evidence that it has an
>> impact on VRML models generated from solid models via
>> OpenCascade/FreeCAD.  Unfortunately I can't remember the exact
>problem
>> now, but at least one of the VRML groups are not correctly
>implemented
>> and as a result cannot be correctly referenced by more than 1 other
>> group. Fixing the implementation could produce a more efficient
>> exported model in some use cases.
>>
>> Cirilo
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>___
>Mailing list: https://launchpad.net/~kicad-developers
>Post to : kicad-developers@lists.launchpad.net
>Unsubscribe : https://launchpad.net/~kicad-developers
>More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://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] Thanks for all the new work on the 3D rendering.

[Cirilo Bernardo]

Hi Mario,

 I never thought of a good way to manage the doubling of the vertices /
viewing from both sides. Since this is a problem of IGES as well as
VRML models (especially models not produced via MCAD) and it
makes no sense to me to complicate KiCad or the 3D viewer, maybe
one way to fix this would be to mark a bad model file by putting a
'_' at the end of the name, for example 'broken-model_.igs". Files
with that tag will be assumed to have bad normals and the vertices
will be doubled, otherwise normals are assumed to be good.

Cirilo


On Thu, Oct 1, 2020 at 12:36 AM Mário Luzeiro  wrote:
>
> Thanks Cirilo!
> It has been small additions but resulted in good improvements...
>
> > results in a doubling of the triangular surfaces
>
> Could an option be added to this? ( both exporter and 3D-Viewer )
>
> I didn't know / don't remember this condition, but I have an idea of some 
> inverted models cases too...
>
> Mario
>
> 
> From: Kicad-developers 
>  on behalf of 
> Cirilo Bernardo 
> Sent: 29 September 2020 04:51
> To: KiCad Developers
> Subject: [Kicad-developers] Thanks for all the new work on the 3D rendering.
>
> I see the latest changes from Mario Luzeiro and Oleg Endo.  Wow .. the
> 3D viewer has improved so much since Mario and I rewrote the code 6+
> years ago.  I'm very glad to see people continuing to make
> improvements.  If anyone has time and wants a challenge there are 2
> items I'm not very happy with in the 3D system. One is due to our
> early support for VRML only models as well as IGES models, and the
> second issue is due to mistakes I made in interpreting the VRML
> specification.
>
> 1. Legacy issue: the import of a VRML model (including those exported
> by kicad) or an IGES model results in a doubling of the triangular
> surfaces. So if you import a box described by 12 triangles that is
> double to 24 and if you export the model and import it again you get
> 48 triangles, and so on. The reason is that every facet is rendered
> from *both* sides and there is no algorithm for decimating the
> triangle data.  The reason triangles were rendered from both sides is
> that many (well, *most*) VRML models which we used before the 3D
> overhaul were defective and the viewing normals were not guaranteed to
> be correct (a facet described as viewable from the wrong side).  IGES
> models also suffer this problem because the specification does not
> provide a requirement of a 'right-hand rule' to determine the Inner
> side vs Outer side of a surface and various CAD packages seemed to
> either use a right-hand rule, left-hand rule, or no rule.  The
> triangle bloating problem will obviously have disastrous consequences
> for rendering time.  As an alternative to decimating the triangles,
> any VRML model exported by KiCad could be specially tagged (similar to
> how PDF uses some special comments) so that the importer does not
> double the triangles. The advantage of this would be that the VRML
> models generated from solid models via scripts could also be tagged
> and the doubleg could be avoided altogether where appropriate.
>
> 2. Incorrect interpretation of VRML spec.  This is really a fairly
> minor issue and I don't believe there is any evidence that it has an
> impact on VRML models generated from solid models via
> OpenCascade/FreeCAD.  Unfortunately I can't remember the exact problem
> now, but at least one of the VRML groups are not correctly implemented
> and as a result cannot be correctly referenced by more than 1 other
> group. Fixing the implementation could produce a more efficient
> exported model in some use cases.
>
> Cirilo
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] 5.1.7 tagged.

[Mark Roszko]

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 
>> 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 
>> 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 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 <
>> >> > > > > > > chsch...@gmail.com
>> >> > > > > > > > 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
>> >> > > > > > >
>> >> > > > > > >
>> 

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

Re: [Kicad-developers] 5.1.7 tagged.

[Adam Wolf]

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 
>> > > 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 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 <
>> > > > > > > chsch...@gmail.com
>> > > > > > > > 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
>>
>> ___
>> Mailing list: https://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] Thanks for all the new work on the 3D rendering.

[Mário Luzeiro]

Thanks Cirilo!
It has been small additions but resulted in good improvements...

> results in a doubling of the triangular surfaces

Could an option be added to this? ( both exporter and 3D-Viewer )

I didn't know / don't remember this condition, but I have an idea of some 
inverted models cases too...

Mario


From: Kicad-developers 
 on behalf of 
Cirilo Bernardo 
Sent: 29 September 2020 04:51
To: KiCad Developers
Subject: [Kicad-developers] Thanks for all the new work on the 3D rendering.

I see the latest changes from Mario Luzeiro and Oleg Endo.  Wow .. the
3D viewer has improved so much since Mario and I rewrote the code 6+
years ago.  I'm very glad to see people continuing to make
improvements.  If anyone has time and wants a challenge there are 2
items I'm not very happy with in the 3D system. One is due to our
early support for VRML only models as well as IGES models, and the
second issue is due to mistakes I made in interpreting the VRML
specification.

1. Legacy issue: the import of a VRML model (including those exported
by kicad) or an IGES model results in a doubling of the triangular
surfaces. So if you import a box described by 12 triangles that is
double to 24 and if you export the model and import it again you get
48 triangles, and so on. The reason is that every facet is rendered
from *both* sides and there is no algorithm for decimating the
triangle data.  The reason triangles were rendered from both sides is
that many (well, *most*) VRML models which we used before the 3D
overhaul were defective and the viewing normals were not guaranteed to
be correct (a facet described as viewable from the wrong side).  IGES
models also suffer this problem because the specification does not
provide a requirement of a 'right-hand rule' to determine the Inner
side vs Outer side of a surface and various CAD packages seemed to
either use a right-hand rule, left-hand rule, or no rule.  The
triangle bloating problem will obviously have disastrous consequences
for rendering time.  As an alternative to decimating the triangles,
any VRML model exported by KiCad could be specially tagged (similar to
how PDF uses some special comments) so that the importer does not
double the triangles. The advantage of this would be that the VRML
models generated from solid models via scripts could also be tagged
and the doubleg could be avoided altogether where appropriate.

2. Incorrect interpretation of VRML spec.  This is really a fairly
minor issue and I don't believe there is any evidence that it has an
impact on VRML models generated from solid models via
OpenCascade/FreeCAD.  Unfortunately I can't remember the exact problem
now, but at least one of the VRML groups are not correctly implemented
and as a result cannot be correctly referenced by more than 1 other
group. Fixing the implementation could produce a more efficient
exported model in some use cases.

Cirilo

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

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

Re: [Kicad-developers] 5.1.7 tagged.

[Ian McInerney]

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 
> > > 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 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 <
> > > > > > > chsch...@gmail.com
> > > > > > > > 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
>
> ___
> Mailing list: https://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] ***UNCHECKED*** Re: Linux support for wxGLCanvas and Wayland/EGL

[Ian McInerney]

On Wed, Sep 30, 2020 at 2:53 PM Simon Richter 
wrote:

> Hi,
>
> On Wed, Sep 30, 2020 at 08:46:46AM -0400, Wayne Stambaugh wrote:
>
> > I'm fine with adding glew to the third party directory.  I'm assuming
> > that the plan would be to use cmake to determine if EGL support was
> > required and build glew accordingly.
>
> With the Debian Developer hat on: this needs an easily reachable OFF
> switch, because it makes packaging harder if projects ship outdated
> components as part of their source tree.
>

It is going behind *2* CMake flags - the first one is `KICAD_USE_EGL` which
will default to OFF and require the flag to be passed into CMake directly
to enable it. This flag will only have effect on Linux. Without this flag
set to ON, it will always use the system GLEW and there is no way around
that. The second is `KICAD_USE_BUNDLED_GLEW`. This will be dependent upon
the `KICAD_USE_EGL` flag, and will have absolutely no effect when
`KICAD_USE_EGL` is OFF (it will always use the system GLEW). When
`KICAD_USE_EGL` is ON this will default to ON and use the bundled GLEW, but
it can be switched off if the system can provide a proper GLEW compiled for
use with EGL (which no systems seem to be packaging).

There will be no auto-detection of EGL inside CMake because implementing
that detection is non-trivial and I don't have the time or motivation
to make it work - so it will always require developer interaction. I will
be adding `#error` macros into the code to flag-up the incompatibility if
we aren't compiled with `KICAD_USE_EGL` and wx is compiled with EGL.

-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

Re: [Kicad-developers] 5.1.7 tagged.

[Wayne Stambaugh]

Adam,

I have no idea how many users this will impact.  Any of our other macOS
devs have any thoughts on this?  Does the typical macOS user keep their
system up to date?  If so, then I expect this to not be an issue.  If
not, then we may have to rethink.  For the time being, at least we have
a package for the latest version of macOS.

Cheers,

Wayne

On 9/30/20 9:46 AM, 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 
>>> 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 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 <
>>> chsch...@gmail.com
>>> > 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
> 
> ___
> Mailing list: https://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] ***UNCHECKED*** Re: Linux support for wxGLCanvas and Wayland/EGL

[Simon Richter]

Hi,

On Wed, Sep 30, 2020 at 08:46:46AM -0400, Wayne Stambaugh wrote:

> I'm fine with adding glew to the third party directory.  I'm assuming
> that the plan would be to use cmake to determine if EGL support was
> required and build glew accordingly.

With the Debian Developer hat on: this needs an easily reachable OFF
switch, because it makes packaging harder if projects ship outdated
components as part of their source tree.

   Simon

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

[Adam Wolf]

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 
> > 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 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 <
> > > > > > chsch...@gmail.com
> > > > > > > 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

___
Mailing list: https://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 support for wxGLCanvas and Wayland/EGL

[Wayne Stambaugh]

Hi Ian,

I'm fine with adding glew to the third party directory.  I'm assuming
that the plan would be to use cmake to determine if EGL support was
required and build glew accordingly.

Cheers,

Wayne

On 9/28/20 6:42 PM, Ian McInerney wrote:
> The upcoming wxWidgets 3.1.5 release has added a new backend supporting
> Wayland/EGL to the wxGLCanvas that we use for displaying the OpenGL
> drawing canvas. This backend appears to be the new default backend for
> wxGTK unless it is explicitly disabled on the wxWidgets configure step
> (you pass --disable-glcanvasegl to the configure script). It is also not
> currently possible to change this backend at runtime. This means that we
> will be forced to use whatever the distro-defaults are for the canvas
> backend once wx 3.1/3.2 is being used in the wild.
> 
> I was just working with it some, and our main bottleneck for supporting
> it natively is currently the GLEW dependency we have in our rendering
> code. GLEW requires a compile-time selection of either X11 or EGL
> backends, and all distributions seem to only ship a library built for
> the X11 backend.
> 
> I have done some experimenting, and building a version of GLEW that is
> meant for EGL is fairly simple and uses a single C file and the public
> headers. It can be compiled into a static library that we then link into
> our code, so we don't actually need to bundle a shared library. My
> thinking currently is that we provide these GLEW files in the
> thirdparty directory, and only use them if a specific compile-time
> option to use EGL is provided. That will mean that linux packaging will
> still use distro-provided GLEW libraries when using the X11 backend, and
> if the distro can supply an EGL-capable GLEW version we can try to use
> that (I am not sure how the distros will manage this though).
> 
> -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