Re: [Kicad-developers] Finally!
On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, 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
Re: [Kicad-developers] Finally!
On 10/15/2014 4:27 PM, Brian Sidebotham wrote: On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, Brian. It was worth a try. The problem with the stock FindPythonLibs.cmake is that it doesn't have a default variable (either environment or CMake definition) that allows you to add to the PATH statement in the find_library() command. This way you could just define the path during the build config because in your case you already know the path. I guess I'll have to put the custom version back and fix it so it works on MSYS2. Before I do that, what is the python-a-mingw-us link library path and file name? Maybe I can figure out a way to use the stock one with kicad-winbuilder without breaking the msys2 builds. 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] Finally!
On 15 October 2014 21:44, Wayne Stambaugh stambau...@verizon.net wrote: On 10/15/2014 4:27 PM, Brian Sidebotham wrote: On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, Brian. It was worth a try. The problem with the stock FindPythonLibs.cmake is that it doesn't have a default variable (either environment or CMake definition) that allows you to add to the PATH statement in the find_library() command. This way you could just define the path during the build config because in your case you already know the path. I guess I'll have to put the custom version back and fix it so it works on MSYS2. Before I do that, what is the python-a-mingw-us link library path and file name? Maybe I can figure out a way to use the stock one with kicad-winbuilder without breaking the msys2 builds. Wayne I think the better way is for me to generate a new findpythonamingwus.cmake module which can exclusively find a python-a-mingw-us install. This can go in our custom cmakemodules directory and then we can either: if( PYTHON_NOFOUND ) FindPythonAMinGWUs() or if( MINGW AND NOT MSYS ) FindPythonAMinGWUs() to use findpythonamingwus instead of the stock findpython module. I agree using the standard install versions where we can is the best way. The reason you see if( MINGW ) clauses in the custom findpython module is because it was at the time the only sane option for building python modules with MinGW because otherwise you'd end up with multiple c runtimes linked which would cause havoc. Now that there is a pure MinGW version of python available under msys2 the if( MINGW ) clauses are not correct because you don't want to search for python-a-mingw-us when you're using msys2. Returning to the custom one until I introduce the new one would be the best solution for me. Our baby is currently cutting teeth so time is scarce for KiCad development at the moment, but I promise to get it sorted as soon as possible. It should just be a case of stripping down the custom version to stop it detecting a standard python install and to just look for the python-a-mingw-us install. Best Regards, 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
Re: [Kicad-developers] Finally!
On 15 October 2014 22:44, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 15 October 2014 21:44, Wayne Stambaugh stambau...@verizon.net wrote: On 10/15/2014 4:27 PM, Brian Sidebotham wrote: On 5 October 2014 00:12, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. Unfortunately we've done it the other way around in rev 5174: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 This breaks KiCad-Winbuilder, but only for new downloads because it can't configure due to not being able to find the python libs. Old installs still work because pythonlibs were already found by the modified findpythonlibs module. I think the main problem is that Python-a-mingw-us which is used by KiCad-Winbuilder uses a different name for the python dll. Best Regards, Brian. It was worth a try. The problem with the stock FindPythonLibs.cmake is that it doesn't have a default variable (either environment or CMake definition) that allows you to add to the PATH statement in the find_library() command. This way you could just define the path during the build config because in your case you already know the path. I guess I'll have to put the custom version back and fix it so it works on MSYS2. Before I do that, what is the python-a-mingw-us link library path and file name? Maybe I can figure out a way to use the stock one with kicad-winbuilder without breaking the msys2 builds. Wayne I think the better way is for me to generate a new findpythonamingwus.cmake module which can exclusively find a python-a-mingw-us install. This can go in our custom cmakemodules directory and then we can either: if( PYTHON_NOFOUND ) FindPythonAMinGWUs() or if( MINGW AND NOT MSYS ) FindPythonAMinGWUs() to use findpythonamingwus instead of the stock findpython module. I agree using the standard install versions where we can is the best way. The reason you see if( MINGW ) clauses in the custom findpython module is because it was at the time the only sane option for building python modules with MinGW because otherwise you'd end up with multiple c runtimes linked which would cause havoc. Now that there is a pure MinGW version of python available under msys2 the if( MINGW ) clauses are not correct because you don't want to search for python-a-mingw-us when you're using msys2. Returning to the custom one until I introduce the new one would be the best solution for me. Our baby is currently cutting teeth so time is scarce for KiCad development at the moment, but I promise to get it sorted as soon as possible. It should just be a case of stripping down the custom version to stop it detecting a standard python install and to just look for the python-a-mingw-us install. Best Regards, Brian. Also, SelectLibraryConfigurations.cmake is there purely for our old FindPythonLibs.cmake, so if that's gone, then SelectLibraryConfigurations.cmake can go too. Best Regards, 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
Re: [Kicad-developers] Finally!
On 5 October 2014 00:18, Wayne Stambaugh stambau...@verizon.net wrote: Here is a another teaser of the mingw64 version of kicad showing the wxPython shell so it appears to be working. Hi Wayne, There's no reason it shouldn't work really, KiCad-Winbuilder uses mingw-w64 and builds fine with wxPython (Well, the wxwidgets-cmake project I did for it: https://launchpad.net/wxwidgets-cmake ). By the way, is the MSYS python okay when not being run in a POSIX environment? I'm sure it is and in which case it removes the need for Python-a-mingw-us, but Python-a-mingw-us is still the only MinGW compiled python distribution outside of MSYS as far as I'm aware. This is obviously essential for us when packaging KiCad for windows. What we do need to think about when generating a stable release for Windows is the packaging of dependencies. Python brings with it a lot of dependency requirements. I don't think cpack will be able to handle our installer very well if we choose to include python (which I am assuming we will have to). I'm very glad to see you've got the python console up and running! :D Best Regards, 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
Re: [Kicad-developers] Finally!
On 10/6/2014 11:37 AM, Brian Sidebotham wrote: On 5 October 2014 00:18, Wayne Stambaugh stambau...@verizon.net wrote: Here is a another teaser of the mingw64 version of kicad showing the wxPython shell so it appears to be working. Hi Wayne, There's no reason it shouldn't work really, KiCad-Winbuilder uses mingw-w64 and builds fine with wxPython (Well, the wxwidgets-cmake project I did for it: https://launchpad.net/wxwidgets-cmake ). Did you try removing our custom FindPythonLibs.cmake file and run a build? If so I will either remove our custom version or copy the latest version from CMake 3.0.2. By the way, is the MSYS python okay when not being run in a POSIX environment? I'm sure it is and in which case it removes the need for Python-a-mingw-us, but Python-a-mingw-us is still the only MinGW compiled python distribution outside of MSYS as far as I'm aware. This is obviously essential for us when packaging KiCad for windows. Yes! It is a mingw64 or mingw32 build of Python depending on what you install and build against. It is not an msys build. Msys2 really is leaving the original msys/mingw32 project in the dust. I don't see the original project ever catching up. The msys2 project uses the pacman package manager from Arch linux. It's almost like using a linux distro inside of windows. There is already a package file created for kicad. The version the msys2 project started doesn't build yet but I already have it building on my system. I have to submit Tom's context patch to them because the packaged version of boost 1.56 doesn't work and then I have a few minor CMake fixes to verify. Once I send the patches the msys2 project, there will be a fully packaged version of kicad for windows that can be install by typing `pacman -S mingw-w64-x86_64-kicad`. I just saw this morning that wxWidgets 3.0.2 was already packaged and it was just released today! If you haven't tried msys2 yet, give it try. What we do need to think about when generating a stable release for Windows is the packaging of dependencies. Python brings with it a lot of dependency requirements. I don't think cpack will be able to handle our installer very well if we choose to include python (which I am assuming we will have to). I'm hoping we can tweak our nsis installer script to pull in all of the dependencies required to run a local version of python. I realize that it is a lot of work but I really think providing a local version of Python will be a better way to go than any attempt to get the natively installed Python (built with msvc) to play nice will applications compiled with mingw. I really would like to include python scripting on Windows rather than making windows a second class citizen. Wayne I'm very glad to see you've got the python console up and running! :D Best Regards, 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
[Kicad-developers] Finally!
After years of struggling to get KiCad to build with the wxPython scripting enabled with mingw on Windows, I've finally managed to pull it off. Take a look at the attached screenshot. You'll notice that all of the major KiCad features are enabled. This is due in large part to the excellent work of the msys2 project. I still have to send them a patch for their package of Boost 1.56 (thanks Tom) and then all of the dependencies are already packaged. No more building dependencies from source on mingw, yeah!!! They all ready have a skeleton package set up for kicad so it shouldn't take long to a have a packaged version of a fully functional build of KiCad for windows. Once this is in place, it should be fairly easy for someone to create an autobuilder to provide up to date mingw64 and mingw32 packages for testing. It should be possible to roll up all of the dependencies and create a windows installer as well. This would greatly aid in testing. On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. 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] Finally!
On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ Mailing list: https://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] Finally!
The MSYS2 file layout is configured very much like Linux so that is probably why the stock version worked. The if(MINGW) code in our custom version broke finding the include file path. The MSYS2 version of cmake is 3.0.2 so they are keeping things up to date. On 10/4/2014 5:23 PM, Adam Wolf wrote: With regards to Linux, my FindPythonLibs changes have been accepted into Cmake proper for a while, and the official bug was marked resolved last week, so I don't think there's any necessity for a custom module for Linux anymore. Adam Wolf On Oct 4, 2014 4:10 PM, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: After years of struggling to get KiCad to build with the wxPython scripting enabled with mingw on Windows, I've finally managed to pull it off. Take a look at the attached screenshot. You'll notice that all of the major KiCad features are enabled. This is due in large part to the excellent work of the msys2 project. I still have to send them a patch for their package of Boost 1.56 (thanks Tom) and then all of the dependencies are already packaged. No more building dependencies from source on mingw, yeah!!! They all ready have a skeleton package set up for kicad so it shouldn't take long to a have a packaged version of a fully functional build of KiCad for windows. Once this is in place, it should be fairly easy for someone to create an autobuilder to provide up to date mingw64 and mingw32 packages for testing. It should be possible to roll up all of the dependencies and create a windows installer as well. This would greatly aid in testing. On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Finally!
Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ Mailing list: https://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] Finally!
Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. I'm away from my keyboard at the moment so I'll have a look at this tomorrow when I'm back at the keyboard. Best Regards, Brian. On 4 Oct 2014 23:32, Wayne Stambaugh stambau...@verizon.net wrote: Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ Mailing list: https://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] Finally!
Here is a another teaser of the mingw64 version of kicad showing the wxPython shell so it appears to be working. On 10/4/2014 5:09 PM, Wayne Stambaugh wrote: After years of struggling to get KiCad to build with the wxPython scripting enabled with mingw on Windows, I've finally managed to pull it off. Take a look at the attached screenshot. You'll notice that all of the major KiCad features are enabled. This is due in large part to the excellent work of the msys2 project. I still have to send them a patch for their package of Boost 1.56 (thanks Tom) and then all of the dependencies are already packaged. No more building dependencies from source on mingw, yeah!!! They all ready have a skeleton package set up for kicad so it shouldn't take long to a have a packaged version of a fully functional build of KiCad for windows. Once this is in place, it should be fairly easy for someone to create an autobuilder to provide up to date mingw64 and mingw32 packages for testing. It should be possible to roll up all of the dependencies and create a windows installer as well. This would greatly aid in testing. On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Finally!
No hurry. Let me know when you have it sorted out. Please send me a patch so I can verify it on msys2. Thanks, Wayne On 10/4/2014 7:12 PM, Brian Sidebotham wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. I'm away from my keyboard at the moment so I'll have a look at this tomorrow when I'm back at the keyboard. Best Regards, Brian. On 4 Oct 2014 23:32, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net mailto:stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
