Re: [Kicad-developers] Critical path item / request for help
1. cmake scripts already work with wxwidgets, that was already done awhile back. I've been building with MSVC for awhile One dependency that'll need "porting" is ngspice. But let me put this out there, does it make sense to leave ngspice to a higher level distro and not built as part of kicad? We've already had cases of repackaging Windows and macOS just to bump ngspice versions up. Why not make it standard baseline as part of kicad instead of allowing versions to be mixed? On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard wrote: > Just a FYI, we have not really solved wxpython phoenix for macos yet, > though some progress were made recently. > > For MSVC there are a number of issues yet to be addressed, this is > with the intention of using vcpkg. > 1. Fix cmake scripts for wxwidgets > 2. Add opencascade to vcpkg > 3. Add swig to vcpkg (or sip if that is what we want to use in the future) > 4. Probably a small handful of other things need to be done > > On Mon, 6 Jul 2020 at 20:35, Jeff Young wrote: > > > > I love this part: > > > > wxPython4.0 (needed for Python3) > > > > > > And I thought our versioning was challenged. ;) > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- Mark ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Critical path item / request for help
Just a FYI, we have not really solved wxpython phoenix for macos yet, though some progress were made recently. For MSVC there are a number of issues yet to be addressed, this is with the intention of using vcpkg. 1. Fix cmake scripts for wxwidgets 2. Add opencascade to vcpkg 3. Add swig to vcpkg (or sip if that is what we want to use in the future) 4. Probably a small handful of other things need to be done On Mon, 6 Jul 2020 at 20:35, Jeff Young wrote: > > I love this part: > > wxPython4.0 (needed for Python3) > > > And I thought our versioning was challenged. ;) > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Critical path item / request for help
I love this part: > wxPython4.0 (needed for Python3) And I thought our versioning was challenged. ;)___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Critical path item / request for help
Hi Folks- One aspect of KiCad v6 that is critical for us is the ability to move to Python3 on all platforms. So far, we've been able to port Linux and MacOS but Windows remains the laggard. There are a couple ways to proceed here for the interested developer. Our standard chain uses mingw32. This build system does not yet support wxPython4.0 (needed for Python3). The package in mingw32 could be updated to support wxPython4.0. Alternatively, wxPython4 for Windows compiles using Microsoft Visual Studio. We do not have a full build of KiCad and dependencies that works using MS Visual Studio and their packaging repository vcpkg. That said, we've been moving in that direction with the main system, so adding the needed items to vcpkg for a full KiCad build may be easier. Is there anyone on this list who'd be willing to take this project on? Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Assumptions about EDA_DRAW_FRAME in pcbnew
There is some general documentation here: https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html There are KiCad-specific instructions that show up as a template in the merge request description box when you are creating the MR. Basically you have to change some default settings in order for the CI build to work and for people to be able to rebase your changes on master. Best, Jon On Mon, Jul 6, 2020 at 1:05 PM Reece R. Pollack wrote: > > Jon, > > I'm very familiar with Git, but a total novice with GitLab. Is there a > cheat-sheet somewhere that describes the process for requesting merges > and such to KiCad's code base? > > -Reece > > On 7/6/20 12:24 PM, Jon Evans wrote: > > Hi Reece, > > > > Could you open a merge request for this branch? You can mark it as > > WIP by putting "WIP: " in the beginning of the title. > > > > Doing so will allow people to review it more easily (even if it's not done) > > > > Thanks, > > Jon > > > > On Mon, Jul 6, 2020 at 12:21 PM Reece R. Pollack wrote: > >> On 7/3/20 9:22 PM, Seth Hillbrand wrote: > >>> Hi Reece- > >>> > >>> I think I mentioned back then that I'm happy to help with the > >>> implementation. The offer remains if you are interested. > >>> > >>> It is easy enough to overload with a pure virtual function in the base > >>> class. The derived classes can override (not overload) the virtual > >>> functions that apply to each. So pcbnew gets one viable function > >>> signature and eeschema gets the other. Misusing this gets an error in > >>> compiling, which keeps errors from creeping down to the user. > >>> > >>> One aspect of dynamic_cast that is sometimes overlooked is that casts > >>> to the base class are optimized out by the compiler. I think that > >>> might save your implementation (if I understand your intention correctly) > >>> > >>> Best- > >>> Seth > >>> > >> Hi Seth, > >> > >> I think it'd be great if you'd participate in the discussions of this > >> feature. As far as I'm concerned, the more input I get the better. > >> > >> Last year I tried posting patches periodically for people to comment on > >> as my development progressed but I didn't get a lot of response. This > >> time I've created a GitLab repo which might make it easier for folk to > >> see what I'm doing in context: > >> > >> https://gitlab.com/RRPollack/kicad/-/tree/rrp-5.99-origin-transform > >> > >> Note that this is a rewrite -- not a port -- of last year's work, though > >> the user interface is intended to be the same. I've pushed the first > >> phase of changes, which implement the Pcbnew status line and the dialogs > >> that use the UNIT_BINDER class. It all compiles cleanly. The parts I've > >> tested work fine but I have to remember how to get to some of the > >> dialogs. The code needs some clean-up, especially in the Doxygen > >> support, and there's some development spew to the console so I can > >> verify the conversions taking place are appropriate. > >> > >> Conspicuously missing is the settings panel that allows easy > >> configuration; I just haven't gotten to it yet. To change to use the Aux > >> origin and flip the Y axis (my normal configuration) add these lines to > >> the pcbnew.json "pcb_display" section: > >> > >> "origin_invert_x_axis": false, > >> "origin_invert_y_axis": true, > >> "origin_mode": 1, > >> > >> Also missing is support for GetMsgPanelInfo, GetSelectMenuText, and DRC > >> markers. All in good time! > >> > >> It'd be nice to get some feedback before I get too far down the road. > >> > >> -Reece > >> > >> ___ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : kicad-developers@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew
Jon, I'm very familiar with Git, but a total novice with GitLab. Is there a cheat-sheet somewhere that describes the process for requesting merges and such to KiCad's code base? -Reece On 7/6/20 12:24 PM, Jon Evans wrote: Hi Reece, Could you open a merge request for this branch? You can mark it as WIP by putting "WIP: " in the beginning of the title. Doing so will allow people to review it more easily (even if it's not done) Thanks, Jon On Mon, Jul 6, 2020 at 12:21 PM Reece R. Pollack wrote: On 7/3/20 9:22 PM, Seth Hillbrand wrote: Hi Reece- I think I mentioned back then that I'm happy to help with the implementation. The offer remains if you are interested. It is easy enough to overload with a pure virtual function in the base class. The derived classes can override (not overload) the virtual functions that apply to each. So pcbnew gets one viable function signature and eeschema gets the other. Misusing this gets an error in compiling, which keeps errors from creeping down to the user. One aspect of dynamic_cast that is sometimes overlooked is that casts to the base class are optimized out by the compiler. I think that might save your implementation (if I understand your intention correctly) Best- Seth Hi Seth, I think it'd be great if you'd participate in the discussions of this feature. As far as I'm concerned, the more input I get the better. Last year I tried posting patches periodically for people to comment on as my development progressed but I didn't get a lot of response. This time I've created a GitLab repo which might make it easier for folk to see what I'm doing in context: https://gitlab.com/RRPollack/kicad/-/tree/rrp-5.99-origin-transform Note that this is a rewrite -- not a port -- of last year's work, though the user interface is intended to be the same. I've pushed the first phase of changes, which implement the Pcbnew status line and the dialogs that use the UNIT_BINDER class. It all compiles cleanly. The parts I've tested work fine but I have to remember how to get to some of the dialogs. The code needs some clean-up, especially in the Doxygen support, and there's some development spew to the console so I can verify the conversions taking place are appropriate. Conspicuously missing is the settings panel that allows easy configuration; I just haven't gotten to it yet. To change to use the Aux origin and flip the Y axis (my normal configuration) add these lines to the pcbnew.json "pcb_display" section: "origin_invert_x_axis": false, "origin_invert_y_axis": true, "origin_mode": 1, Also missing is support for GetMsgPanelInfo, GetSelectMenuText, and DRC markers. All in good time! It'd be nice to get some feedback before I get too far down the road. -Reece ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew
Hi Reece, Could you open a merge request for this branch? You can mark it as WIP by putting "WIP: " in the beginning of the title. Doing so will allow people to review it more easily (even if it's not done) Thanks, Jon On Mon, Jul 6, 2020 at 12:21 PM Reece R. Pollack wrote: > > On 7/3/20 9:22 PM, Seth Hillbrand wrote: > > Hi Reece- > > > > I think I mentioned back then that I'm happy to help with the > > implementation. The offer remains if you are interested. > > > > It is easy enough to overload with a pure virtual function in the base > > class. The derived classes can override (not overload) the virtual > > functions that apply to each. So pcbnew gets one viable function > > signature and eeschema gets the other. Misusing this gets an error in > > compiling, which keeps errors from creeping down to the user. > > > > One aspect of dynamic_cast that is sometimes overlooked is that casts > > to the base class are optimized out by the compiler. I think that > > might save your implementation (if I understand your intention correctly) > > > > Best- > > Seth > > > > Hi Seth, > > I think it'd be great if you'd participate in the discussions of this > feature. As far as I'm concerned, the more input I get the better. > > Last year I tried posting patches periodically for people to comment on > as my development progressed but I didn't get a lot of response. This > time I've created a GitLab repo which might make it easier for folk to > see what I'm doing in context: > > https://gitlab.com/RRPollack/kicad/-/tree/rrp-5.99-origin-transform > > Note that this is a rewrite -- not a port -- of last year's work, though > the user interface is intended to be the same. I've pushed the first > phase of changes, which implement the Pcbnew status line and the dialogs > that use the UNIT_BINDER class. It all compiles cleanly. The parts I've > tested work fine but I have to remember how to get to some of the > dialogs. The code needs some clean-up, especially in the Doxygen > support, and there's some development spew to the console so I can > verify the conversions taking place are appropriate. > > Conspicuously missing is the settings panel that allows easy > configuration; I just haven't gotten to it yet. To change to use the Aux > origin and flip the Y axis (my normal configuration) add these lines to > the pcbnew.json "pcb_display" section: > > "origin_invert_x_axis": false, > "origin_invert_y_axis": true, > "origin_mode": 1, > > Also missing is support for GetMsgPanelInfo, GetSelectMenuText, and DRC > markers. All in good time! > > It'd be nice to get some feedback before I get too far down the road. > > -Reece > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew
On 7/3/20 9:22 PM, Seth Hillbrand wrote: Hi Reece- I think I mentioned back then that I'm happy to help with the implementation. The offer remains if you are interested. It is easy enough to overload with a pure virtual function in the base class. The derived classes can override (not overload) the virtual functions that apply to each. So pcbnew gets one viable function signature and eeschema gets the other. Misusing this gets an error in compiling, which keeps errors from creeping down to the user. One aspect of dynamic_cast that is sometimes overlooked is that casts to the base class are optimized out by the compiler. I think that might save your implementation (if I understand your intention correctly) Best- Seth Hi Seth, I think it'd be great if you'd participate in the discussions of this feature. As far as I'm concerned, the more input I get the better. Last year I tried posting patches periodically for people to comment on as my development progressed but I didn't get a lot of response. This time I've created a GitLab repo which might make it easier for folk to see what I'm doing in context: https://gitlab.com/RRPollack/kicad/-/tree/rrp-5.99-origin-transform Note that this is a rewrite -- not a port -- of last year's work, though the user interface is intended to be the same. I've pushed the first phase of changes, which implement the Pcbnew status line and the dialogs that use the UNIT_BINDER class. It all compiles cleanly. The parts I've tested work fine but I have to remember how to get to some of the dialogs. The code needs some clean-up, especially in the Doxygen support, and there's some development spew to the console so I can verify the conversions taking place are appropriate. Conspicuously missing is the settings panel that allows easy configuration; I just haven't gotten to it yet. To change to use the Aux origin and flip the Y axis (my normal configuration) add these lines to the pcbnew.json "pcb_display" section: "origin_invert_x_axis": false, "origin_invert_y_axis": true, "origin_mode": 1, Also missing is support for GetMsgPanelInfo, GetSelectMenuText, and DRC markers. All in good time! It'd be nice to get some feedback before I get too far down the road. -Reece ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Invalid certificate on kicad.info
Hi All Yep, sorry about that, the holiday had me a bit behind the game on updating the server. I am updating and migrating the forum over to a new server (Ubuntu 20.04), which will have a renewed certificat. There will be a new method for securing the frontpage site. Please feel free to let me know if you need anything else. Chris On Mon, Jul 6, 2020 at 5:10 AM Christoph Moench-Tegeder wrote: > ## Kliment (Future Bits) (klim...@0xfb.com): > > > kicad.info itself (without forum.) does not present a certificate at > all. > > Worse: https://www.kicad.info only has the certificate for > forum.kicad.info - there's no SubjectAltName for www.kicad.info or > kicad.info. > But then, according to that very site: "This site is run by Contextual > Electronics" (http://kicad.info/about/), so perhaps someone should tell > them? > > Regards, > Christoph > > -- > Spare Space > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Invalid certificate on kicad.info
The owner of both sites, Chris Gammell, is a member of this kicad-developers list. Regads, Pedro. El 6/7/20 a las 12:10, Christoph Moench-Tegeder escribió: ## Kliment (Future Bits) (klim...@0xfb.com): kicad.info itself (without forum.) does not present a certificate at all. Worse: https://www.kicad.info only has the certificate for forum.kicad.info - there's no SubjectAltName for www.kicad.info or kicad.info. But then, according to that very site: "This site is run by Contextual Electronics" (http://kicad.info/about/), so perhaps someone should tell them? Regards, Christoph ___ 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] Windows msys2 build error
Thanks! - Wayne On 7/6/20 9:19 AM, Seth Hillbrand wrote: > I fixed the includes but we should probably push the definitions out of > that file at some point. > > Best- > Seth > > Seth Hillbrand > KiCad Services Corporation > https://www.kipro-pcb.com > +1 530 302 5483 | +1 212 603 9372 > > On 2020-07-06 05:18, Wayne Stambaugh wrote: >> I'm seeing the following build error this morning on windows using msys2: >> >> C:/msys64/home/Wayne/src/kicad-trunk/include/ws_draw_item.h:463:55: >> error: cannot convert 'std::vector::iterator' to >> 'const char*' >> 463 | auto newEnd = std::remove( m_graphicList.begin(), >> m_graphicList.end(), aItem ); >> | ~~~^~ >> | | >> | >> std::vector::iterator >> In file included from C:/msys64/mingw64/include/wx-3.0/wx/string.h:39, >> from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15, >> from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19, >> from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15, >> from >> C:/msys64/home/Wayne/src/kicad-trunk/include/fctsys.h:28, >> from >> C:/msys64/home/Wayne/src/kicad-trunk/common/page_layout/ws_data_model.cpp:47: >> >> C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:752:34: note: >> initializing argument 1 of 'int remove(const char*)' >> 752 | int __cdecl remove(const char *_Filename); >> | ^ >> make[2]: *** [common/CMakeFiles/common.dir/build.make:957: >> common/CMakeFiles/common.dir/page_layout/ws_data_model.cpp.obj] Error 1 >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ 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] Windows msys2 build error
I fixed the includes but we should probably push the definitions out of that file at some point. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 On 2020-07-06 05:18, Wayne Stambaugh wrote: I'm seeing the following build error this morning on windows using msys2: C:/msys64/home/Wayne/src/kicad-trunk/include/ws_draw_item.h:463:55: error: cannot convert 'std::vector::iterator' to 'const char*' 463 | auto newEnd = std::remove( m_graphicList.begin(), m_graphicList.end(), aItem ); |~~~^~ | | | std::vector::iterator In file included from C:/msys64/mingw64/include/wx-3.0/wx/string.h:39, from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15, from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19, from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15, from C:/msys64/home/Wayne/src/kicad-trunk/include/fctsys.h:28, from C:/msys64/home/Wayne/src/kicad-trunk/common/page_layout/ws_data_model.cpp:47: C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:752:34: note: initializing argument 1 of 'int remove(const char*)' 752 | int __cdecl remove(const char *_Filename); | ^ make[2]: *** [common/CMakeFiles/common.dir/build.make:957: common/CMakeFiles/common.dir/page_layout/ws_data_model.cpp.obj] Error 1 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ 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] Windows msys2 build error
I'm seeing the following build error this morning on windows using msys2: C:/msys64/home/Wayne/src/kicad-trunk/include/ws_draw_item.h:463:55: error: cannot convert 'std::vector::iterator' to 'const char*' 463 | auto newEnd = std::remove( m_graphicList.begin(), m_graphicList.end(), aItem ); |~~~^~ | | | std::vector::iterator In file included from C:/msys64/mingw64/include/wx-3.0/wx/string.h:39, from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15, from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19, from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15, from C:/msys64/home/Wayne/src/kicad-trunk/include/fctsys.h:28, from C:/msys64/home/Wayne/src/kicad-trunk/common/page_layout/ws_data_model.cpp:47: C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:752:34: note: initializing argument 1 of 'int remove(const char*)' 752 | int __cdecl remove(const char *_Filename); | ^ make[2]: *** [common/CMakeFiles/common.dir/build.make:957: common/CMakeFiles/common.dir/page_layout/ws_data_model.cpp.obj] Error 1 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Invalid certificate on kicad.info
## Kliment (Future Bits) (klim...@0xfb.com): > kicad.info itself (without forum.) does not present a certificate at all. Worse: https://www.kicad.info only has the certificate for forum.kicad.info - there's no SubjectAltName for www.kicad.info or kicad.info. But then, according to that very site: "This site is run by Contextual Electronics" (http://kicad.info/about/), so perhaps someone should tell them? Regards, Christoph -- Spare Space ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Invalid certificate on kicad.info
Hey, Not sure who runs forum.kicad.info but the COMODO cert that was used for it expired today. Most browsers will refuse to load it. Just wanted to make sure whoever runs that server is aware. kicad.info itself (without forum.) does not present a certificate at all. Kliment ___ 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
