kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

Please Bernhard avoid changing mac version destination for your sanity,
there was a list of issues mostly wxWidgets related about using the new
stdlib.
This is the reason why wxWidgets usually defaults to compatibility to 10.6:
you will miss no feature nor speed.

Libraries that will be build will be migrated for you to fix-bundles.sh
directly into the bundles, making it portable and portable between systems.

The only step you will need is to copy the .app in place, you could do it
manually or search some old posts.


--
Marco


On Tue, May 27, 2014 at 2:00 PM, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx
> wrote:

>  Hi Marco,
>
> I have to admit that I was stupid as it seems... I did read documentation
> while back (I think this was before you made all the changes with
> downloading dependencies), but I always assumed, that if I build with
> ..._STATIC=OFF it is the same as ..._DYNAMIC=ON.
> It was Jean-Pauls post about wxWidgets being automatically downloaded
> which made me wondering... with ..._STATIC=OFF  nothing was downloaded for
> me except boost.
>
> Meanwhile I found out that with ..._DYNAMIC=ON all dependencies are
> downloaded and built as dylib. And moreover, I also learned that there is a
> script that should make the app bundle portable.
> The script doesn't work for me just right now with an out-of-tree build...
> I will try to fix that today.
>
> That script is also not used when not using ..._DYNAMIC=ON - which was
> what I used all the time. Moreover, KiCadOSXBuilder also had it's own
> little script for making its build portable, so I assumed there isn't
> something (and that's why I tried dylibbundler and BundleUtilities).
>
> Furthermore I had some problems with building the dependencies on my 10.9
> machine.
> It seems as if different libs (especially wxWidgets) got compiled with
> different libc++/libstdc++ and/or mac-osx-version=... which caused problems
> when linking (I also don't understand why I didn't see those problems on my
> 10.8 machine with different XCode).
> To fix that I reworked all the download_* cmake scripts to include stdlib
> and version options. Now, it runs just perfect on 10.9 for me... will also
> try on 10.8 these days.
> If you don't mind, I would send the changes directly to you (I can also
> post them on the developers list, but Dick didn't know what to do with my
> last change about libc++ anyway and I guess you would have to submit them).
>
> I will also correct my statements on the ML as soon as everything is
> working... maybe it would be very good to have one consolidated page
> somewhere on launchpad (?) with the defintive instructions/options how to
> build and what to use.
> Nowadays, everyone seems to have his own script and process on how to
> build... that's bad, even more if I read the posts on the ML it is better
> to use it in a VM on OSX... :(
>
>
>
> Best regards
> Bernhard
>
>
>
>
> On 2014-05-27 10:24, Marco Serantoni wrote:
>
> Bernhard,
> Do you tried to follow the instruction in the repository ?
>
>
> --
> Marco
>
>
> On Sun, May 25, 2014 at 6:10 PM, Bernhard Stegmaier <
> stegmaier@xxxxxxxxxxxxx> wrote:
>
>> Hi all,
>>
>> played around with making the app bundle portable today, but
>> unfortunately I ended up just where I gave up some months ago and switched
>> to static linkage… :(
>> Back then I tried dylibbundler, now I gave BundleUtilities shipped with
>> cmake a chance.
>>
>> Problem is as follows:
>> This is what wxWidgets creates as libraries:
>>  -rwxr-xr-x   1 root        staff  5435032 20 Nov  2013
>> libwx_osx_cocoau_core-3.0.0.0.0.dylib
>> lrwxr-xr-x   1 root        staff       37 24 Mai 21:06
>> libwx_osx_cocoau_core-3.0.0.dylib -> libwx_osx_cocoau_core-3.0.0.0.0.dylib
>> lrwxr-xr-x   1 root        staff       33 24 Mai 21:06
>> libwx_osx_cocoau_core-3.0.dylib -> libwx_osx_cocoau_core-3.0.0.dy
>>  One “real” lib and a couple of symlinks with less detailed version
>> numbers pointing to it.
>> At least quite common in the Linux world...
>>
>> pcbnew now e.g. links against my MacPorts …-3.0.dylib wxWidgets library
>>  /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib
>> (compatibility version 1.0.0, current version 1.0.0)
>>  whereas my wxWidgets libwx_osx_cocoau_gl.3.0.dylib links against
>>  /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.0.0.dylib
>> (compatibility version 1.0.0, current version 1.0.0)
>>
>> Both the cmake tool as well as dylibbundler parse/collect (recursive)
>> dependencies and end up copying two identical instances to the app bundle -
>> one for …-3.0.dylib and one for …-3.0.0.0.0.dylib. It doesn’t care/check
>> that one of those is just a symlink.
>> That doesn’t work for similar reasons than linking wxWidgets statically
>> doesn’t work with kiface.
>> I tried to fix this back then in dylibbundler by copying a symlink… but
>> that also isn’t that easy, because it is not only one indirection, but
>> probably more of them. So, by just copying a single symlink you might end
>> up in the middle of nowhere.
>>
>> If I change the copies in the app bundle manually to one instance and the
>> other being a symlink pointing to it
>>  -rwxr-xr-x   1 bstegmaier  staff  5435032 25 Mai 16:19
>> libwx_osx_cocoau_core-3.0.0.0.0.dylib
>> lrwxr-xr-x   1 bstegmaier  staff       37 25 Mai 16:27
>> libwx_osx_cocoau_core-3.0.dylib -> libwx_osx_cocoau_core-3.0.0.0.
>>  everything is fine again...
>>
>> In my opinion this version symlinking is quite common, so I am wondering
>> a bit that both of these common tools obviously don’t handle it correctly.
>> So, at the moment the only options would be to link kicad apps so that
>> they reference the most detailed version as wxWidgest does itself, to fix
>> one of the scripts or to create an own script doing that stuff (that’s what
>> MacOSXKicadBuilder partly did).
>>
>> Maybe I’ll ask on the cmake mailing list if this is a known problem and
>> if there is a solution for that…
>>
>>
>> Regards,
>> Bernhard
>>
>> PS:
>> If someone is interested… that’s what I did for pcbnew Makefile:
>> === modified file 'pcbnew/CMakeLists.txt'
>> --- pcbnew/CMakeLists.txt 2014-05-12 15:17:51 +0000
>> +++ pcbnew/CMakeLists.txt 2014-05-25 14:17:55 +0000
>> @@ -599,6 +599,12 @@
>>          set_target_properties( pcbnew_kiface PROPERTIES
>>              LIBRARY_OUTPUT_DIRECTORY
>> ${CMAKE_CURRENT_BINARY_DIR}/pcbnew.app/Contents/MacOS/
>>              )
>> +
>> +        # create portable app bundle
>> + install( CODE "
>> +        include( BundleUtilities )
>> +        fixup_bundle( ${CMAKE_INSTALL_PREFIX}/bin/pcbnew.app
>> \"_pcbnew.kiface\" \"\" )
>> +    ")
>>      else()
>>          install( TARGETS pcbnew_kiface
>>              DESTINATION ${KICAD_BIN}
>> Additionally, you have to reformat Info.plist to have each element in a
>> new line, otherwise BundleUtilities won’t parse it correctly and bails out.
>>
>> But be careful.. doesn’t work with a MacPorts installed wxWidgets.
>> MacPorts installs the libs in a …/wxWidgets.framework/… path which makes
>> BundleUtilities think that this is a framework and not just a dylib.
>> Don’t know yet if the MacPorts installation violates the Framework
>> concept of OSX or BundleUtilities just don’t handle such a situation
>> correctly...
>>
>>
>>  On 24.05.2014, at 16:55, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
>> wrote:
>>
>>  Bernard,
>>
>> If you *don't* succeed, would you mind posting back here anyway?
>>
>> Thanks!
>>
>> Adam Wolf
>> W&L, LLC
>>
>>
>> On Sat, May 24, 2014 at 9:44 AM, Bernhard Stegmaier <
>> stegmaier@xxxxxxxxxxxxx> wrote:
>>
>>> Hi Dick (and others),
>>>
>>> thanks for the hint, I will try not to use static linking.
>>> I did that because in the past dynamic linking didn’t produce portable
>>> applications.
>>> That is, they contained a reference to the wxWidgets libs at the place
>>> when being built and haven’t been copied to the app bundle… and all the
>>> usual fix-scripts to copy those libs into the bundle failed for me
>>> (problems with the symlinks)… and I didn’t want to fix every path manually.
>>>
>>> I looked around a bit and found some cmake modules that should be able
>>> to produce portable application bundles… I’ll try to add/change that in the
>>> cmake files… if I succeed, I will of course propose a patch.
>>>
>>>
>>> Thanks,
>>> Bernhard
>>>
>>>  On 24.05.2014, at 04:16, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>>>
>>>  On 05/23/2014 12:31 PM, Jean-Paul Louis wrote:
>>>
>>> Hi Bernhard,
>>>
>>> I am attaching my script to this email.
>>> Some of the stuff in the script might not be needed anymore, but I will
>>> clean it up when I have time.
>>>
>>> After the “make” is finished, I skip the “make install” as it is not yet
>>> capable to work.
>>> So I just copy the bundles (*.app) to "/Applications/kicad” (see towards
>>> the end of the script).
>>>
>>> Thanks to the help of Marco, Adam and even more so from Dick of the
>>> development team, I simplified the script so it build to 100%, and Dick
>>> modified the Cmake files to create the bundles with the kiface files
>>> properly copied where they belongs.
>>> That might by why we have duplicate kiface files (seems to be the cause
>>> of the error at the end of the “make”.
>>>
>>> I will create the files for the ENV variables, and let you know how that
>>> works.
>>>
>>> Regards,
>>> Jean-Paul
>>>
>>>
>>> On May 23, 2014, at 10:59 AM, Bernhard Stegmaier stegmaier@xxxxxxxxxxxxx[kicad-users] <
>>> kicad-users@xxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi Jean-Paul,
>>>
>>>
>>> can you tell me what files have to be copied where?
>>> I remember some discussions about copying/linking/whatever .kiface files
>>> that on the dev-list, but I didn’t find anything on first glance.
>>> And yes, let’s try to fix this…
>>>
>>> With respect to setting the environment variables I did the following:
>>> Using Linux-like ~/.profile, etc. files will set the variables only when
>>> launching from command-line… not from the dock/launcher.
>>> To set a variable for the launcher I made in
>>> ~/Library/LaunchAgents
>>> files named like
>>> local.kicad.kisys3dmod.plist
>>> which looks like
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
>>>    "http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
>>> <plist version="1.0">
>>> <dict>
>>>    <key>Label</key>
>>>    <string>local.kicad.kisys3dmod</string>
>>>    <key>EnableGlobbing</key>
>>>    <true/>
>>>    <key>ProgramArguments</key>
>>>    <array>
>>>        <string>launchctl</string>
>>>        <string>setenv</string>
>>>        <string>KISYS3DMOD</string>
>>>        <string>~/10 - Projekte/KiCad/Modules</string>
>>>    </array>
>>>    <key>RunAtLoad</key>
>>>    <true/>
>>> </dict>
>>> </plist>
>>> and in the case sets KISYS3DMOD variable. I did the same for the other
>>> variables I need (I didn’t find any solution to set more than one variable
>>> in a single file). The files will be loaded automatically on login (as far
>>> as I remember) or you can test them with “launchctl load …”.
>>> But caution: those files will only set it for the launcher, not the
>>> shell… while searching for that I found some shell scripting that can be
>>> added to e.g., .profile reading the values from launched so that you don’t
>>> have to maintain it in two places if you need that, but I didn’t need it so
>>> I don’t have a link at hand.
>>>
>>> This solution works well for me both on 10.8 and 10.9.
>>>
>>> The KiCadOSXBuilder creates a wrapper-script for setting the variables,
>>> but I didn’t like that approach, because for me those variables are
>>> machine-specific (especially the library stuff).
>>> So, it shouldn’t be hardcoded somewhere in the application bundle, but
>>> defined by the machine/account itself.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 23.05.2014, at 16:27, Jean-Paul Louis louijp@xxxxxxxxx [kicad-users]
>>> <kicad-users@xxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi Bernhard,
>>>
>>> I use OS X 10.9.2 and I keep trying the most recents BZR. I came to the
>>> same conclusion about some failures due to duplicate work copying files
>>> into the OS X bundles.
>>>
>>> I use a bash script fairly raw to copy the files from the build to the
>>> /Applications/kicad directory.
>>> eeschema sort of work, but cannot find kicad.pro template.
>>> it does complain about a missing power lib twice, then load the project
>>> I am working on as a test case.
>>> When I go to the preferences, nothing is loaded there, except a power
>>> lib (the missing one) that I do not use, and a weird path like
>>> /usr/local/share.
>>>
>>> My next task is to figure out how to set the proper shell variables like
>>> KISYSMOD, KIGITHUB, etc..
>>> because they are not set at all in my build.
>>>
>>> If you are interested, we can work together to fix what we can, as I do
>>> not get any help from Marco Serantoni who is supposed to be the Mac OS X
>>> guru.
>>>
>>> Regards,
>>> Jean-Paul
>>> AC9GH
>>>
>>> On May 23, 2014, at 7:24 AM, Bernhard Stegmaier stegmaier@xxxxxxxxxxxxx[kicad-users] <
>>> kicad-users@xxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi Mac guys,
>>>
>>>
>>> did anyone succeed to build and run a recent version on OSX (most likely
>>> after the modular kicad changes)?
>>>
>>> I tried to build some versions on both 10.8 and 10.9 machines using
>>> different versions of XCode during the last 2 weeks, but I didn’t succeed…
>>> :(
>>> Compilation did work smoothly on all machines (configured with
>>> -DKICAD_BUILD_STATIC=ON and having disabled scripting and github plugin -
>>> just as I did with all the previous versions I have built) after a small
>>> patch of aMakefile (see end of the mail, I think this is just a leftover
>>> because the file that should be copied by that piece of code is already at
>>> the right spot…).
>>> But, all binaries (except kicad) don’t work on any of my machines.
>>>
>>> They start and immediately crash with a backtrace like this:
>>> <<<
>>> Exception Type:  EXC_CRASH (SIGABRT)
>>> Exception Codes: 0x0000000000000000, 0x0000000000000000
>>>
>>> Application Specific Information:
>>> abort() called
>>> *** error for object 0x108e2c0f0: pointer being freed was not allocated
>>>
>>>
>>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>>> 0   libsystem_kernel.dylib         0x00007fff8ae51866 __pthread_kill +
>>> 10
>>> 1   libsystem_pthread.dylib        0x00007fff8dbd435c pthread_kill + 92
>>> 2   libsystem_c.dylib              0x00007fff8e2c8b1a abort + 125
>>> 3   libsystem_malloc.dylib         0x00007fff91e2b07f free + 411
>>> 4   org.kicad-eda.pcbnew           0x0000000100008c3e
>>> wxScopedCharTypeBuffer<char>::DecRef() + 62
>>> 5   org.kicad-eda.pcbnew           0x00000001000bbff7
>>> wxScopedCharTypeBuffer<char>::MakeOwnedCopyOf(wxScopedCharTypeBuffer<char>
>>> const&) + 31
>>> 6   _pcbnew.kiface                 0x00000001082f2275
>>> wxMessageOutputStderr::Output(wxString const&) + 97
>>> 7   _pcbnew.kiface                 0x00000001081ef968
>>> ShowAssertDialog(wxString const&, int, wxString const&, wxString const&,
>>> wxString const&, wxAppTraits*) + 664
>>> 8   _pcbnew.kiface                 0x00000001081ee6cc
>>> wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString
>>> const&, wxString const&) + 188
>>> 9   _pcbnew.kiface                 0x00000001081eec5f wxOnAssert(char
>>> const*, int, char const*, char const*, wchar_t const*) + 127
>>> 10  _pcbnew.kiface                 0x0000000108278d60
>>> wxStandardPathsBase::Get() + 80
>>>
>>>
>>>
>>>
>>> Why is this stack trace point showing that function
>>> wxStandardPathBase::Get() is in the
>>> module _pcbnew.kiface?
>>>
>>> This might be because you are linking with static wx libraries.  With
>>> the advent of
>>> kiface, this can never work again.
>>>
>>> All platforms must link to a shared/dynamic wx library set.  No static
>>> wxWidgets library
>>> set ever again please.
>>>
>>> Start there.  Its possible that wxTheApp is not unique. You have a
>>> second copy because you
>>> are linking wx into every frickin module.
>>>
>>> As to the ::Get() call, here is the source from svn head of wx:
>>>
>>> line 59 or so of common/stdpbase.cpp:
>>>
>>> wxStandardPaths& wxStandardPathsBase::Get()
>>> {
>>>    wxAppTraits * const traits = wxTheApp ? wxTheApp->GetTraits() : NULL;
>>>    wxCHECK_MSG( traits, gs_stdPaths, wxT("create wxApp before calling
>>> this") );
>>>
>>>    return traits->GetStandardPaths();
>>> }
>>>
>>>
>>> But we only want this to reside in the wx SHARED/DYNAMIC library, not in
>>> our
>>> _pcbnew.kiface module.
>>>
>>>
>>>
>>>   11  _pcbnew.kiface                 0x0000000108242677
>>> wxFileConfig::GetLocalFile(wxString const&, int) + 27
>>> 12  _pcbnew.kiface                 0x00000001082429ad
>>> wxFileConfig::wxFileConfig(wxString const&, wxString const&, wxString
>>> const&, wxString const&, long, wxMBConv const&) + 497
>>> 13  _pcbnew.kiface                 0x0000000107e20845 BIN_MOD::Init() +
>>> 229
>>> 14  _pcbnew.kiface                 0x0000000107e686d7
>>> KIFACE_I::start_common(int) + 39
>>> 15  _pcbnew.kiface                 0x00000001079141c5
>>> PCB::IFACE::OnKifaceStart(PGM_BASE*, int) + 21
>>> 16  org.kicad-eda.pcbnew           0x0000000100022609
>>> KIWAY::KiFACE(KIWAY::FACE_T, bool) + 441
>>> 17  org.kicad-eda.pcbnew           0x0000000100022ca5
>>> KIWAY::Player(FRAME_T, bool) + 309
>>> 18  org.kicad-eda.pcbnew           0x0000000100006144
>>> PGM_SINGLE_TOP::OnPgmInit(wxApp*) + 1428
>>> 19  org.kicad-eda.pcbnew           0x0000000100009bed
>>> APP_SINGLE_TOP::OnInit() + 45
>>> 20  org.kicad-eda.pcbnew           0x000000010007912c
>>> wxApp::CallOnInit() + 78
>>> 21  org.kicad-eda.pcbnew           0x0000000100292f3c wxEntry(int&,
>>> wchar_t**) + 76
>>> 22  org.kicad-eda.pcbnew           0x0000000100005b20 main + 48
>>> 23  org.kicad-eda.pcbnew           0x0000000100005ab4 start + 52
>>>
>>>  and messages on console like
>>> <<<
>>> objc[17580]: Class wxNSAnimationDelegate is implemented in both
>>> /Volumes/MacStorage/Temp/KiCad/bin/bin/pcbnew.app/Contents/MacOS/pcbnew and
>>> /Volumes/MacStorage/Temp/KiCad/bin/bin/pcbnew.app/Contents/MacOS/_pcbnew.kiface.
>>> One of the two will be used. Which one is undefined.
>>> ./src/common/stdpbase.cpp(62): assert "traits" failed in Get(): create
>>> wxApp before calling this
>>>
>>>  After googling a bit at least the messages on console seem to indicate
>>> that some wxWidgets functions are used before the wxApp is instantiated.
>>>
>>> The problem might already be known, I found this comment in the code,
>>> but one line below where it crashes for me.
>>> <<<
>>>   m_bm.Init();
>>>
>>>   m_bm.m_config->Read( showPageLimitsKey, &g_ShowPageLimits );
>>>
>>>   // FIXME OSX Mountain Lion (10.8)
>>>   // Seems that Read doesn't found anything and ColorFromInt
>>>   // Asserts - I'm unable to reproduce on 10.7
>>>
>>>   int draw_bg_color = BLACK;      // Default for all apps but Eeschema
>>>
>>>
>>> Any hints/ideas?
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> === modified file 'pcb_calculator/CMakeLists.txt'
>>> --- pcb_calculator/CMakeLists.txt 2014-05-12 15:17:51 +0000
>>> +++ pcb_calculator/CMakeLists.txt 2014-05-16 09:00:42 +0000
>>> @@ -134,15 +134,6 @@
>>>           )
>>>   endif()
>>>
>>> -    if( APPLE )
>>> -        # copies kiface into the bundle
>>> -        add_custom_target( _pcb_calculator_kiface_copy ALL
>>> -            COMMAND ${CMAKE_COMMAND} -E copy
>>> ${CMAKE_BINARY_DIR}/pcb_calculator/_pcb_calculator.kiface
>>> "${CMAKE_BINARY_DIR}/pcb_calculator/pcb_calculator.app/Contents/MacOS/"
>>> -            DEPENDS pcb_calculator_kiface
>>> -            COMMENT "Copying kiface into pcb_calculator"
>>> -        )
>>> -    endif()
>>> -
>>> else()
>>>
>>>   add_executable( pcb_calculator WIN32 MACOSX_BUNDLE
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>> ------------------------------------
>>>
>>> Please read the Kicad FAQ in the group files section before posting your
>>> question.
>>> Please post your bug reports here. They will be picked up by the creator
>>> of Kicad.
>>> Please visit http://www.kicadlib.org for details of how to contribute
>>> your symbols/modules to the kicad library.
>>> For building Kicad from source and other development questions visit the
>>> kicad-devel group athttp://groups.yahoo.com/group/kicad-develYahooGroups Links
>>>
>>> <*> To visit your group on the web, go to:
>>>   http://groups.yahoo.com/group/kicad-users/
>>>
>>> <*> Your email settings:
>>>   Individual Email | Traditional
>>>
>>> <*> To change settings online go to:
>>>   http://groups.yahoo.com/group/kicad-users/join
>>>   (Yahoo! ID required)
>>>
>>> <*> To change settings via email:
>>>   kicad-users-digest@xxxxxxxxxxxxxxx
>>>   kicad-users-fullfeatured@xxxxxxxxxxxxxxx
>>>
>>> <*> To unsubscribe from this group, send an email to:
>>>   kicad-users-unsubscribe@xxxxxxxxxxxxxxx
>>>
>>> <*> Your use of Yahoo Groups is subject to:
>>>   https://info.yahoo.com/legal/us/yahoo/utos/terms/
>>>
>>>
>>>
>>> __._,_.___
>>> Posted by: Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>
>>> Reply via web post • Reply to sender • Reply to group • Start a New
>>> Topic • Messages in this topic (3)
>>> Please read the Kicad FAQ in the group files section before posting your
>>> question.
>>> Please post your bug reports here. They will be picked up by the creator
>>> of Kicad.
>>> Please visit http://www.kicadlib.org for details of how to contribute
>>> your symbols/modules to the kicad library.
>>> For building Kicad from source and other development questions visit the
>>> kicad-devel group athttp://groups.yahoo.com/group/kicad-devel
>>> VISIT YOUR GROUP
>>> • New Members 14
>>>  • New Photos 3
>>>
>>> • Privacy • Unsubscribe • Terms of Use
>>>
>>> .
>>>
>>>
>>> __,_._,___
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>