Re: [Kicad-developers] V6 documentation

[Carsten Schoenert]

Hi,

Am 19.01.22 um 23:18 schrieb Eeli Kaikkonen:


I don't understand why this discussion is so difficult to understand.


sorry but I don't understand what problem you are trying to solve!
There is no problem within the Linux world and their distros to provide 
packaged documentation, there is no need to develop another new way for 
distributing documentation.



I agree with Jon and don't see any problem for distros. As far as I
can see the point is that the documentation package version shouldn't
be logically dependent on the KiCad packages or vice versa. You can
have package kicad-v6.0-documentation version, say, 20222001 [date],
can't you? You don't have to give it the version number 6.0.x. If a
git tag is needed for technical reasons, let's have automatic tagging
which adds a tag each day.


To use the words from Marco...

"Are you serious?"

I'm getting a bit disappointed because I become the feeling that you are 
somehow ignorant about the arguments of at least two main packagers of 
KiCad within Linux. And I really think that you want to solve problems 
on the wrong corner.


THE MAIN PROBLEM ARE THE OUTDATED DOCUMENTS!
NOT THE WAY THEY ARE DISTRIBUTED.

So it's better to think about how the documentation can be updated and 
how a ongoing process can be introduced to make contributions easier 
with a low barrier for one time contributors.


And as Marco did explain, we need to fix the tools if there is something 
missed at the end. Be friendly to the distributions, please do not try 
to ignore them. They are part of the FOSS ecosystem KiCad is depending on.
Do not try to "solve" things were distributions already have a process 
for and established rules for that.


I stop now reading any new post on this topic.

--
Regards
Carsten

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

Re: [Kicad-developers] V6 documentation

[Carsten Schoenert]

[ I'm on this list, no need to address me dedicated. ]

Am 19.01.22 um 18:45 schrieb Jon Evans:

I think you misunderstand.  We currently have three rolling releases on 
docs.kicad.org : V5, V6, and master (nightly).
We will continue adding new "rolling release" builds for every major 
release version.


I think I have understand you. :)

But for me "rolling release" and "stable release" isn't something that 
is working well together as it simply doesn't fit together per definition.


[cut off]
I stand on my opinion, I'm not convinced that most of the things you 
suggested is the way to go.


The price is that the average Linux user will get 6.0.1 tagged docs 
instead of latest V6 docs (and so forth) and won't necessarily think to 
check for updated ones.


That's the idea behind packages that using a tagged version. I haven't 
seen any professional software is doing that you suggest.

And the typical experienced Linux user isn't behaving like Windows user.

You are confusing rolling release of binary packages/applications with 
rolling release of documentation -- they are entirely different in my mind.


No, I don't.
Doing constantly bug fixing for current stable releases of KiCad doesn't 
exclude doing the same for improving the (stable) documentation 
independently from the current development branch.


I'm not a native English speaker and I'm not really able to help on this 
part effectively, and also I have given up long time ago trying 
contributing to the KiCad documentation for various reasons.


The main devs are free to do and decide whatever they think is the right 
thing and way for KiCad. I simple don't see why it would be really 
helpful for the users what you are proposing. In my eyes is dropping 
existing formats a loss of well working and usable support.



--
Regards
Carsten

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

Re: [Kicad-developers] V6 documentation

[Carsten Schoenert]

Am 19.01.22 um 18:12 schrieb Steven A. Falco:


I don't disagree, but really, we could say that everything is always
outdated - the code, the libs etc.  I have to pick a point in time,
and create packages as of that point - currently that point is when a
new release is tagged.  I.e., it is a manual process - I have to
consciously create the packages, and it then takes a week or so for
the packages to sit in the testing repositories before being released
to general users.  I have no control over that process.


Exactly!

The main part of the Linux distributions are simply not intended to 
build as rolling release.
There is simply no way to "work around" this within the rule set of 
these distributions.


Users that want to follow some nightly and so called releases will need 
to use distribution/flavor A or B or C that can and will support this.


But I haven't seen a serious usage of what Linux DE ever that was build 
on distributions that are using a rolling release model.


--
Regards
Carsten

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

Re: [Kicad-developers] V6 documentation

[Carsten Schoenert]

Hello Jon,

Am 19.01.22 um 17:38 schrieb Jon Evans:

Carsten,

There is no reason to remove the ability to package docs offline, I just 
don't think it should be a focus of the project.


here start to disagree.
In my eyes the offline bundled and created documentation IS a strong 
service the project should always have a focus on.


The majority of users will be served better by keeping a "rolling 
release" online at docs.kicad.org  (with a 
download button, ideally).


I disagree again, I know several users of KiCad which don't follow a 
rolling release of KiCad valid reasons and even don't update to a new 
main version because the current one ore more big projects is critical.
Professional users typically don't have the time to follow rolling 
releases as this is lost and unpaid time for them. It's easier to live 
with the know problems and to work around them. And once a new version 
is out and the time has come projects can do and will do the version update.


A rolling release only of the online documentation is also counter 
productive in such a case, as it would be probably mostly wrong for the 
old used version potentially.


 > It absolutely doesn't hurt to build completely offline usable 
documentation.


It does hurt the way we do it today, for the following reasons:

1) We currently support multiple formats, which makes the build system 
and formatting changes complicated


So what?
Isn't it exact the purpose of the build system to solve all these 
problems for the users?
And currently there isn't something special format built, at least I 
don't see why HTML, PDF and ePUB diff that much between, except the way 
they are created.
If you see a problem within the supporting of the formats the tooling 
for creating needs improvements! But as long nowadays developers (not 
KiCad devs!) thinking that every problem needs to be solved by some 
Node.JS stuff the "solutions" going worse every day.


2) We currently tie the documentation version together with the 
application version, and don't have good workflows for "rolling release" 
of documentation for Linux distros that use separate packages.


There is no need to support some sort of rolling release for tagged 
versions, sorry, I don't get what goal is wanted to archive here. The 
problem isn't the rolling release if you want to name it that way. There 
is a toolchain that is building the various formats and this stays the 
same basically.


The current problem is simply the current outdated base which requires a 
lot of work to get this updated. Evolving the documentation for the 
current dev branch is something different from supporting the current 
stable released version.


3) The application itself doesn't handle the situation where offline 
docs are missing very gracefully, or note to users that when offline 
docs are present that they are probably outdated.


The KiCad application can't do anything about that circumstance. It 
simply just can start some external resource. So it's the responsibility 
of that resource to handle that. Is see no problem in adding some header 
or similar into the current documentation that is saying that the most 
recent version this document can be found there and there.



What I would propose to improve the situation is:

1) Drop all formats except HTML.  HTML is perfectly fine as an offline 
format, and this allows us to make improvements to the build workflow 
and the layout/style of the docs without worrying about doing so in a 
way that also works for PDF.  If you really want a PDF, you can render 
it from HTML pages anyway.


Why?
My father isn't able to handle this for the most of us simple task. I 
don't think such a step is really user friendly.
I was e.g. happy to have the documentation readable on my EBook reader 
as this was the most suitable device for me to read it.


I see no real costs to provide al these formats as these are really 
common formats.


2) Change the application to gracefully redirect to the online docs if 
offline docs are missing


Agreed.

3) Make a better "offline docs" build that adds the warning about docs 
being out-of-date.  Have packagers use this if they want to generate 
docs packages, and maybe make it easy for anyone to download these from 
the website.


Shouldn't be that difficult as this is mostly the current state.

4) Stop tagging the kicad-docs repo with every KiCad code release.  
Instead, continue the new practice we have started of maintaining major 
release branches for the docs (V5, V6, etc) and have packagers start 
packaging the tip of these branches.  I.e. the Ubuntu package for 
kicad-docs will update every time something is pushed to the V6 branch 
as long as V6 is the stable release, and so on.


Here I disagree again, most of the Linux distribution have some tooling 
created to collect all the required tarballs or tags as they need always 
some upstream tarball that is used for everything that is created later.


Tags 

Re: [Kicad-developers] V6 documentation

[Carsten Schoenert]

Hello,

Am 19.01.22 um 17:21 schrieb Gabriel Staples, ElectricRCAircraftGuy.com:
...
In other words, please do make "online documentation" only, as it allows 
faster updates to it and better consistency,


please don't!
It absolutely doesn't hurt to build completely offline usable 
documentation. It works for years without special requirements.


I work often in environments where I have absolutely no access to the 
internet, but can use packaged software, so I heavily need offline 
documentation to do some sort of productive work.


--
Regards
Carsten

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

Re: [Kicad-developers] Note to packagers: new data dependency for KiCad PCM

[Carsten Schoenert]

Hello Jon,

Am 08.11.21 um 03:30 schrieb Jon Evans:
> Hi all,
> 
> We just turned the plugin and content manager (PCM) feature on for all
> users.
> 
> To work properly, this feature needs an additional directory packaged:
> 
> $KICAD_DATA/schemas
> 
> If your packaging scripts already grab everything inside $KICAD_DATA,
> you should not need to do anything. If you manually package each
> subdirectory (resources, scripting, template, etc) then please add the
> schemas directory to the list.

which package should contain this new folder?
I guess the KiCad main application, am I right?

-- 
Regards
Carsten

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

Re: [Kicad-developers] 5.1.11 release tagged

[Carsten Schoenert]

Hello Wayne,

Am 26.10.21 um 20:38 schrieb Wayne Stambaugh:
> Hi Carsten,
> 
> Do we still we still build and deploy the old 5.1 developer docs 
> anywhere?  I guess I should remove them just in case someone else does. 
>   I should be able to get to this shortly.

stuff from that folder isn't going into (Debian) packages, I'm not sure
about other places there this was or is deployed to.

I came along this while looking into the references to kicad-pcb.org
within the debian/ folder and found a lot matches also outside the
debian/ folder. So I pulled the 5.1 branch to compare that against the
5.1.11 tag and still found references.

The packaging is including more additional folders like localization and
the documentation. I haven't looked into this yet.

-- 
Regards
Carsten Schönert

___
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.11 release tagged

[Carsten Schoenert]

Hello Wayne,

Am 26.10.21 um 13:32 schrieb Wayne Stambaugh:

I just pushed the 5.1.11 tag to the 5.1 branch so please tag all of the
other repos so we can start the packaging process.  Please let me know
if there are any issues that would delay the tagging.


I guess the loss of kicad-pcb.org isn't incorporated yet into this tag.


carsten@i5:~/gitprojects/kicad-upstream/kicad [(5.1.11)] $ git grep 
"kicad-pcb\.org"
Documentation/development/compiling.md:[download]: 
http://kicad-pcb.org/download/
Documentation/development/compiling.md:[KiCad website]: http://kicad-pcb.org/
Documentation/development/pcbnew-plugins.md:documentation](http://docs.kicad-pcb.org/stable/en/pcbnew.html#_kicad_scripting_reference).
Documentation/development/pcbnew-plugins.md:[here](http://docs.kicad-pcb.org/doxygen-python/namespacepcbnew.html).
Documentation/development/road-map.md:[kicad-website]:http://kicad-pcb.org/
Documentation/development/road-map.md:[kicad-docs]:http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/index.html
Documentation/development/stable-release-policy.md:added to either the KiCad 
developer's site on Launchpad or the main website at www.kicad-pcb.org.
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[trace mask documentation]: 
http://docs.kicad-pcb.org/doxygen/group__trace__env__vars.html
Documentation/development/testing.md:[advanced config documentation]: 
http://docs.kicad-pcb.org/doxygen/namespaceAC__KEYS.html


I think you will agree that it would be good to fix this also within the 
devel information resources before releasing a new version.


--
Regards
Carsten Schönert

___
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] libngspice versioning by libtool

[Carsten Schoenert]

Am 02.08.21 um 13:11 schrieb Ian McInerney:

> This error has been discussed on the list before, but basically it is
> caused by using the same source tree and trying to build both 5.1 and
> master by switching back and forth between them using git checkout.
> There were several changes to where auto-generated header files are
> located between the two, so if you switch between the two it can get the
> wrong header files - specifically this error is it using the 5.1 header
> file which was created in the source tree in the master branch build
> instead of the new one for the master branch that was created in the
> build directory. One way to fix this is to use different trees for the
> two, or remove the ignored generated files.


Hmm, yes I can vaguely remember...

> carsten@x260:~/gitprojects/kicad-upstream/kicad/build [5.1] $ LANG= git st
> On branch 5.1
> Your branch is up to date with 'origin/5.1'.
> 
> Untracked files:
>   (use "git add ..." to include in what will be committed)
>   ../eeschema/sch_text_help_md.h
>   ../pcbnew/dialogs/panel_setup_rules_help_md.h

Would be nice if these files can be removed out of the way while the
cmake run is done. The current behavior is a bit annoying.

I'm quite sure this will come up regularly. :)

-- 
Regards
Carsten

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

Re: [Kicad-developers] libngspice versioning by libtool

[Carsten Schoenert]

Hi Holger,

Am 31.07.21 um 15:52 schrieb Holger Vogt:
> Hello Carsten,
> 
> there are two thing now open:
> 
> I have made an update to ngspice in branch pre-master:
> Now all boolean symbols transferred over the ABI are of true boolean 
> type. So the interfacing from any caller does not need to be changed, 
> your compile should then (hopefully) finish successfully.

today I was able to have a look again. Thanks for patience.

I've rebuilt a new snapshot of Debian packages for ngspice and installed
the libngspice specific packages for further testing.

The build of the current master of kicad is still failing with the same
error message as previously. This isn't ngspice related I guess.

> [ 42%] Building CXX object 
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o
> [ 42%] Building CXX object 
> bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2component.cpp.o
> [ 42%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_netlist_base.cpp.o
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:241:22:
>  error: use of undeclared identifier 'T_pinfunction'
> case T_pinfunction:
>  ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:247:22:
>  error: use of undeclared identifier 'T_pintype'
> case T_pintype:
>  ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:371:14:
>  error: use of undeclared identifier 'T_property'
> case T_property:
>  ^
> 3 errors generated.
> make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:689: 
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o]
>  Fehler 1
> make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet...


The build of the current HEAD in the branch 5.1 (configured the same way
as the master branch) successes now again with ngspice c4470db.
And so far KiCad is also usable.


> Concerning loading the ngspice shared library:
> With the help of reading the commit
> https://gitlab.com/kicad/code/kicad/-/commit/b445b0fab28f7dd41273801d06d7705215c57c0f
> the procedure seems to be:
> With cmake function get_filename_component() at compile time KiCad 
> detects a path to ngspice and hard-codes it in NGSPICE_DLL_FILE.
> This variable then is used to load ngspice dynamically at runtime. So 
> everything depends what string one finds in NGSPICE_DLL_FILE (ngspice.cpp).
> 
> Unfortunately I have not been able to compile KiCad so far 
> (wxPython/Phoenix seems to be not yet available in openSUSE Leap 15.3). 
> So, Carsten, if you can compile, could you have a look at the contents 
> of NGSPICE_DLL_FILE?

I'm not that familiar with CMake and there are probably some differences
need to be done between the three operating systems in the end as they
behave differently. So I think I can't say really helpful things in that
matter. I'd use at least different names for the variable that is
pointing to the ngspice specific library, we usually talk about "shared
objects" (SO) within Linux/GNU and dynamic linked libraries (DLL) on the
Windows side. I've no idea how MacOS is calling these files, maybe also
shared objects.

For the Linux world it would be needed to link against the name
libngspice.so.0 currently as this is the API version that is required,
but before the CMake checking needs to prove that the current minimal
required version is available on the system. That's currently c:a:r
0.0.x if the set of available symbols is enough.

This can be done by using pkg-config (pkg-config --modversion ngspice).

The build configuration of ngspice is currently using the package
version that is abstracted by autoconf and configure.ac (currently this
is 35) for adding a version number into ngspice.pc.
There is no specific requirement which version number has to be used
here, some packages (probably most of it) simply use a semver based
package version, some packages using here the library SO version. Both
is usable.

Package maintainers need to ensure later that the required version is
defined correctly for the packaged KiCad application.

I think the most important thing on this is that the maintainers of
KiCad know what CMake needs to check at build time. If this is simply a
check that Ngspice >= 35 is required than this is all to be done I think.

Using dlopen should be the right things in Linux systems, but this is
used all the times yet so far I know.

-- 
Regards
Carsten

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

Re: [Kicad-developers] libngspice versioning by libtool

[Carsten Schoenert]

Am 30.07.21 um 14:53 schrieb Holger Vogt:
[snip]
> Ah, and what is the versioning now? The API has not changed, it was 
> however not described correctly in sharedspice.h, which now (ngspice-35) 
> will be fixed.

So you have changed the internal behavior of one or more symbols?

This is of course a modification of the API. From the commit message
that I wrote for ngspice:

>  Existing symbols behave now different or existing symbols were removed.
> 
>  --> Increase 'current' by 1, set 'revision' to 0, set 'age' to 0 
> (c+1,r=0,a=0)
>  !!!Note!!!
>  The ABI version is also affected by this (needs a bump too, the library
>  isn't backward compatible any more.

So libngspice normally would need to get a bump of the current version.
Existing source projects aren't able to get built against the new
library version without the modifications to the source and would fail
already at configure time because the API version of the new library
isn't matching.
Now the fun begins because also the header files would need to go into a
new different folder than the old ones in most of the cases.

You can try to avoid such hassle by introducing a wrapper function that
is basically the old symbol call that is internally redirecting to the
new symbol.
By this you "only" introduce a new symbol and from an outside view the
library is behaving the same as before.

That's what other libraries always try to do because introducing a new
API version has a lot of necessary required following steps, especially
outside the library. If ever possible this is to get avoided.

-- 
Regards
Carsten

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

Re: [Kicad-developers] libngspice versioning by libtool

[Carsten Schoenert]

Hi again,

Am 29.07.21 um 10:29 schrieb Carsten Schoenert:
> From a quick built of ngspice (branch pre-master with current HEAD) I
> can run a KiCad 5.99 without issues with a new version of
> libngspice0.so.0.0.1.
> 
> Will do further testing this.

to shorten the story, I can use any existing old version of KiCad 5.1.9
.10 and also .99 together with an updated package libngspice to
pre-master 35 of ngspice within a Debian testing. Al my testing did
happen on Debian testing.

I could also configure, built and use successful some old tree of KiCad
5.99 to together with a new library of libngspice.so.0.0.1.

The current HEAD (4633840) is able to get a target built configured, but
breaks later with some non libngspice related failure.

> [ 42%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_print_using_printer.cpp.o
> [ 42%] Building CXX object 
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/kicad_clipboard.cpp.o
> [ 42%] Building CXX object 
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o
> [ 42%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_print_using_printer_base.cpp.o
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:241:22:
>  error: use of undeclared identifier 'T_pinfunction'
> case T_pinfunction:
>  ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:247:22:
>  error: use of undeclared identifier 'T_pintype'
> case T_pintype:
>  ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:371:14:
>  error: use of undeclared identifier 'T_property'
> case T_property:
>  ^
> 3 errors generated.
> make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:689: 
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o]
>  Fehler 1
> make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet
> [ 42%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_rescue_each.cpp.o
> make[1]: *** [CMakeFiles/Makefile2:2983: common/CMakeFiles/pcbcommon.dir/all] 
> Fehler 2
> make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet



The current HEAD in branch 5.1. is getting configured successful but is
failing while compiling with this error message with then updated
packages of libngspice0 and libngspice0-dev:

> [ 87%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_pns_length_tuning_settings.cpp.o
> [ 87%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/sim/netlist_exporter_pspice_sim.cpp.o
> [ 87%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o
> [ 87%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_pns_length_tuning_settings_base.cpp.o
> /home/carsten/gitprojects/kicad-upstream/kicad/eeschema/sim/ngspice.cpp:341:47:
>  error: cannot initialize a parameter of type 'ControlledExit *' (aka 'int 
> (*)(int, int, int, int, void *)') with an rvalue of type 'int (*)(int, bool, 
> bool, int, void *)': type mismatch at 2nd parameter ('NG_BOOL' (aka 'int') vs 
> 'bool')
> m_ngSpice_Init( , , , NULL, NULL, 
> , this );
>   ^
> 1 error generated.
> make[2]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/build.make:2588: 
> eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o] Fehler 1
> make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet

Looks currently to me if something needs to get cherry picked from
master into 5.1. At least I can remembering that some fixing around this
was already happen in the past.

-- 
Regards
Carsten

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

Re: [Kicad-developers] libngspice versioning by libtool

[Carsten Schoenert]

Hi,

Am 28.07.21 um 14:14 schrieb Ian McInerney:
> Depending on how the OpenSUSE build system si setup, a prebuilt version
> from their repository might not work with a library with a different
> version. Many build systems for Linux packages will encode a dependency
> on a specific version of the shared library, which is included in the
> filename. When that changes (called an SONAME bump), the dependent
> packages must be rebuilt to pickup the new SONAME.

this is only true if the current version (aka API version) has changed.
As long the SO version is the same a rebuild package with a greater
version will get built.

>From a quick built of ngspice (branch pre-master with current HEAD) I
can run a KiCad 5.99 without issues with a new version of
libngspice0.so.0.0.1.

Will do further testing this.

-- 
Regards
Carsten

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

Re: [Kicad-developers] libngspice versioning by libtool

[Carsten Schoenert]

Am 27.07.21 um 20:12 schrieb Holger Vogt:
> Carsten,
> 
> it is not about what I should do, but what the KiCad devs should do to 
> allow me adding versioning to shared ngspice.  I will add versioning if 
> it is aknowledged by KiCad/Eeschema.

That's not the question in my eyes. It's not something that you need to
be allowed to do. In my eyes it the responsibility of every maintainer
to do it right. It's really hard to package some libraries because we
need to do a lot of extra work and tricks so the user can use the
library in the end.

Serving a proper versioned library is the only right way in the long
run. What non versioned work can produce is better than ever visible in
the Windows world. Every peace of software brings in it's own bundled
version of the same peace of software because it's just a hassle to use
system wide installed libraries even if they are from M$ itself.

I thought this topic was already clear. There is now an extra variable
in sharedspice.h that the Windows world can rely on.

-- 
Regards
Carsten

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

Re: [Kicad-developers] libngspice versioning by libtool

[Carsten Schoenert]

Hello Holger,

Am 27.07.21 um 14:03 schrieb Holger Vogt:
> So what would be the correct action?
> 
> When I compile ngspice, I get (besides libngspice.so.0.0.0 or 
> libngspice.so.0.0.1) two aliases libngspice.so.0 and libngspice.so. What 
> would be the correct version to link to?

there is nothing you need to do here (and you shouldn't do anything
here!), the correct linking of all relevant files is always done by
libtool as part of the intended versioning schema inside libtool based
on idea of ELF Symbol Versioning.

For those who are not really familiar with this I suggest to read some
old written stuff by Ulrich Drepper that explains some internals.

https://akkadia.org/drepper/symbol-versioning

libtool naming, something you need to remember every time if working
with the versioning for libraries.

libtool uses three elements to give a library a version.

1. Current  (== API version)
2. Revision (== iteration of the library)
3. Age  (== iteration on the availability of new symbols)

This built currently the following library for ngspice with it's full
name as all these elements using 0 for a version as nothing as a version
is given to the libtool call:

  libngspice.so.0.0.0



And this is the schema that libtool is using to create the full name.

current ---\ /--- revision
|   |
shared object file --\  |   |
  libngspice.so.0.0.0
   |  |
library name --/  |
age -/


Looking at the output of libtool we see currently this if ngspice is
built with --with-ngshared:

> $ ls -l /usr/lib/x86_64-linux-gnu/libngspice*
> lrwxrwxrwx 1 root root  19 31. Jan 12:43 
> /usr/lib/x86_64-linux-gnu/libngspice.so -> libngspice.so.0.0.0
> lrwxrwxrwx 1 root root  19 31. Jan 12:43 
> /usr/lib/x86_64-linux-gnu/libngspice.so.0 -> libngspice.so.0.0.0
> -rw-r--r-- 1 root root 7340384 31. Jan 12:43 
> /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0

We see two links, the first one is the basic library name that is
pointing to the full version.
The other link is using an additional number which is simply '0' which
is also pointing to the full name.
This means these two links can only exist one time, but we can have
multiple full named libraries installed, the trick is the symlinking
here to point to the the most recent version normally.

Going back to the second link (libngspice.so.0 -> libngspice.so.0.0.0).
You might already see what this '0' means here, it's the number of
'Current' or also known as the API version.

Greater means breaking (non backward compatible) changes as also the API
has changed by this. This is happen e.g. if the maintainer has removed
symbols from the library for hopefully good reasons.

Now we are already by the compatibility of a library.

A library is backwards compatible if in a newer version all existing
symbols are still available and the behavior of the symbols doesn't have
changed. By this all old and existing applications can also use a newer
library version. And this is visible by the link of libngspice.so.0, the
number '0' means here exactly this.

What's if the maintainer has just done bug fixing or improved the
performance of the library? No new symbols were added and no existing
symbols have been modified or removed!
For this the new version needs to increase the revision. We would move
on from

libngspice.so.0.0.0   tolibngspice.so.0.0.1 (and so on)

And now the new library has become some new symbols, all existing
symbols stays the same as before.

Now the age needs to get increased and the revision falls back to 0. For
libngspice this would look like this.

libngspice.so.0.0.1   will go tolibngspice.so.0.1.0

And now the most intrusive thing that can happen, the new library has at
least one of there symbols removed. Remember, the library isn't
backwards compatible any longer! The API version has changed!
Current will get increased and revison and also age will get reset to '0'.

libngspice.so.0.1.0   will go tolibngspice.so.1.0.0

And libtool will create a new link named libngspice.so.1 pointing to the
new full named file.

If you doing this for the first time it's all a bit confusing as you can
see this all has nothing  to do with semver. But once you have
understand the idea it's quite obvious what needs to be done.

PS: I'm far away from being an expert in such things! Forgive me if
somethings isn't fully correct explained.

-- 
Regards
Carsten

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

Re: [Kicad-developers] old ngspice in 599 macOS nightly

[Carsten Schoenert]

Hello Holger,

Am 24.07.21 um 14:51 schrieb Holger Vogt:
> Carsten,
> 
> library versioning: not yet.
> 
> Did some experiments with libtool library versioning.
> The input 0:1:0 (code change but no api change) created a 
> libngspice.so.0.0.1.

that's correct, just increase the revision (or age if new symbols were
added) for the library with every new release as long no backward
compatible breaking changes were made.

> My Linux Eeschema (5.1.10 from SUSE Leap 15.3 Electronics repository 
> with ngspice-14) failed immediately because it wants to load 
> libngspice.so.0.0.0.

Then KiCad is doing something wrong or is not smart enough. It's not
your responsibility as maintainer of ngspice to fix this.

KiCad is to strict if it will only built with library version 0.0.0,
that is just wrong as the main thing for using versioned library is to
ensure that at least a subset of the symbols is available.

> I do not have patience and enough know-how to figure out what is right 
> or wrong, so versioning has to be postponed.

You don't have to do much on your side, just do the increasing step for
the library revision or age if needed and you are ready. Thanks.

-- 
Regards
Carsten Schönert

___
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] old ngspice in 599 macOS nightly

[Carsten Schoenert]

Hello Holger,

Am 22.07.21 um 21:17 schrieb Holger Vogt:
> With ngspice-35, there will be to changes concerning the
> sharedspice.h API header.
> 
> There is now a preprocessor flag definition added
> #define NGSPICE_PACKAGE_VERSION "35"
this means too there is now a proper versioned library built?

-- 
Regards
Carsten

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

Re: [Kicad-developers] For those wondering about KiCad version 5.99.0 in Debian unstable...

[Carsten Schoenert]

Hello Jon,

Am 06.07.21 um 21:45 schrieb Jon Evans:
> Hi Carsten,
> 
> I was reminded of this thread because of this forum post:
> https://forum.kicad.info/t/how-install-kicad-6-x-on-debian/30034/4
> 
> Is the fact that there is a 6.0.0 tag on experimental also related to
> this issue with versioning?

yes.
But to be completely precise the tag isn't "6.0.0". It's
"6.0.0~20210702.eff75b6+dfsg1-1".

The important thing is the *tilde* sign that make this version less than
6.0.0.

My mistake has some side effects. The package manager is only looking at
versions, if a version of a package is greater than the installed
version than it can be installed.

To get current versions from the develop branch into experimental the
version needs to be higher than the version in unstable/testing.
Thus I decided to take the version schema 6.0.0~ to get the above
requirement fulfilled.

Debian Bulleseye is targeted to be released on 31th July.
Means after this date the current version in unstable (that is in fact
5.1.10) will go into testing and can afterwards get into backports.

-- 
Regards
Carsten

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

Re: [Kicad-developers] Experience compiling latest HEAD

[Carsten Schoenert]

Hello Ruth,

Am 28.06.21 um 21:34 schrieb Ruth Ivimey-Cook:

> I would *really* appreciate an ubuntu "official" nightly build of 5.99
> that uses wx3.1

there was never and probably will never be any official Ubuntu KiCad
packages.

The "official Ubuntu" packages are taken from Debian by the automatic
pick up from Debian unstable.

wxwidget 3.1 is the development version for the upcoming stable version
3.2 which possible breaks the API/ABI with every new version that is
getting released. That makes this software breaking other software too
often and by this unfit to get introduced into Debian unstable, it
simply make to less sense.

-- 
Regards
Carsten

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

Re: [Kicad-developers] asciidoc

[Carsten Schoenert]

Hi,

this topic more relevant for kicad-doc I think.

Am 30.05.21 um 20:34 schrieb Jon Evans:
> You want this one: https://github.com/Mogztter/asciidoctor-web-pdf
> 
> On Ubuntu I install it with "sudo npm i -g @asciidoctor/core asciidoctor-pdf"

For Debian (and also for Ubuntu) this isn't possible.
We need to build stuff from packages that are available within the
archive, there is no access to any external resources while binary
package build.

This NPM module isn't packed so we can't use this way.

Some similar Ruby based package is available, but I've no clue if this
is suitable.

> $ apt search asciidoctor
> Sorting... Done
> Full Text Search... Done
> asciidoctor/testing,testing,now 2.0.12-2 all [installed]
>   AsciiDoc to HTML rendering for Ruby
> 
> asciidoctor-doc/testing,testing 2.0.12-2 all
>   AsciiDoc to HTML rendering for Ruby (documentation)
> 
> ruby-asciidoctor/testing,testing,now 2.0.12-2 all [installed,automatic]
>   AsciiDoc to HTML rendering for Ruby (core libraries)
> 
> ruby-asciidoctor-include-ext/testing,testing 0.3.1-2 all
>   Asciidoctor's standard include::[] processor reimplemented as an extension
> 
> ruby-asciidoctor-kroki/testing,testing 0.2.2-3 all
>   Asciidoctor extension to convert diagrams to images using Kroki
> 
> ruby-asciidoctor-pdf/testing,testing,now 1.5.4-3 all [installed]
>   Converts AsciiDoc documents to PDF using Prawn
> 
> ruby-asciidoctor-plantuml/testing,testing 0.0.12-1 all
>   extension for Asciidoctor to enable support for PlantUML diagrams
> 
> $ apt show ruby-asciidoctor-pdf
> Package: ruby-asciidoctor-pdf
> Version: 1.5.4-3
> Priority: optional
> Section: ruby
> Maintainer: Keith Packard 
> Installed-Size: 3.754 kB
> Depends: ruby (>= 1:2.5.1), ruby-asciidoctor (>= 1.5.0), ruby-concurrent (>= 
> 1.1~), ruby-prawn (>= 2.2.0), ruby-prawn-icon (>= 1.4.0), ruby-prawn-svg (>= 
> 0.31.0), ruby-prawn-table (>= 0.2.2), ruby-safe-yaml (>= 1.0.4), 
> ruby-thread-safe (>= 0.3.6), ruby-treetop (>= 1.5.3)
> Suggests: ruby-rouge
> Homepage: https://github.com/asciidoctor/asciidoctor-pdf
> Ruby-Versions: all
> Download-Size: 1.393 kB
> APT-Manual-Installed: yes
> APT-Sources: http://ftp.de.debian.org/debian testing/main amd64 Packages
> Description: Converts AsciiDoc documents to PDF using Prawn
>  An extension for Asciidoctor that converts AsciiDoc documents to PDF
>  using the Prawn PDF library.

-- 
Regards
Carsten

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

Re: [Kicad-developers] OCE vs. OCC default build flag

[Carsten Schoenert]

Hi,

Am 18.05.21 um 17:01 schrieb Kevin Cozens:
> How will this affect those of us who build KiCad from source? I have liboce 
> packages installed which provide OCE. If you change to OCC what package(s) 
> will I need then? The distro I use (Linux Mint) has libocct (Open CASCADE 
> Technology) packages. Is that what I will need or will I have to find 
> another source (ie. a PPA) for the support libraries?

you will need to have installed libocct-data-exchange-dev which will
probably pull in other OCC related packages as an dependency.

-- 
Regards
Carsten

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

Re: [Kicad-developers] OCE vs. OCC default build flag

[Carsten Schoenert]

Hi,

I can just speak for Debian.

Am 17.05.21 um 14:53 schrieb Eeli Kaikkonen:
> As far as I can tell, Ubuntu and all derivatives, Fedora, openSUSE,
> Debian (if I remember correctly), Arch and Manjaro already use OCC so
> that the latest available KiCad 5.99 (and even 5.1) packages for the
> latest available distro versions use OCC. Only gentoo KiCad 5.1 seems
> to use OCE.

So far I remember correctly the KiCad project was switching to OCC
because the OCE variant was lagging behind some or more wanted features.
I'm using mostly the explicit set up of build options and do not rely on
used default values, so the Debian packages using OCC for more than a
year. And this also for backported versions.

> Changing the python flags (soon, I hope?) will have bigger
> consequences. I couldn't even find a way to compile 5.99 for Debian
> testing with phoenix.

I've configured the build of the current 5.99 version for experimental
since a few weeks, and wxpython 4.0 is used here also like done for the
current stable version since a long time. Or I miss your point.

> https://salsa.debian.org/electronics-team/KiCad/kicad/-/blob/debian/experimental/debian/rules#L39

-- 
Regrads
Carsten

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

[Kicad-developers] For those wondering about KiCad version 5.99.0 in Debian unstable...

[Carsten Schoenert]

it's not really a version 5.99.0.

I made a mistake last week while preparing a current snapshot of all
relevant KiCad parts and the kicad package was of course intended for
uploading to the distribution experimental but was pushed into
unstable/sid due stupidity of me.

To fix this error I needed to upload a greater version into the archive
than the previous upload as DAK (the Debian Archive Kit) is checking for
this condition and will reject the upload otherwise, the Debian system
is only supporting upgrades and no downgrades.
Another option would have been to use a epoch, that prefix with a colon
before the typical version number string. E.g. *1:*5.1.9 could I've been
used.

But introducing epochs need to go through consensus on the list
debian-devel as these are often avoidable and not really needed. And I
think this here is a case there no need for an epoch is required and I
have chosen to simply increase the version numbering from a POV of DAK
and created a version 5.99.0+really5.1.9.

The underlying source is still 5.1.9.

I need to stay with this schema until 6.x will get released (6.x is
greater than 5.99.x), even for the backported versions. I'm really not
proud about the mistake I've made but it's happen. :-(

This will also have effect for Ubuntu and their downstreams as the PPA
version will also became less than 5.99.0+really once the Debian
version(s) will hit the Ubuntu archive and users wouldn't be able to
install packages from PPA archives in case they have previously
installed kicad package from the Ubuntu archive.

There are two solution for this case people want to use the PPA versions
of kicad.

Option A:
 - The PPA versioning doesn't adopt the version schema from Debian

People can't have installed kicad packages from the Ubuntu archive
before, if they have installed the kicad package from Ubuntu they need
to be removed first!

Option B
 - The PPA archive is also using the versioning schema from Debian

In this case users doesn't have to do anything than to add the PPA
entries as it's already done yet right now.

My suggestion is to do the latter, so the names, versions and behaviour
will stay the same on all Debian based distributions.

This all is only relevant for the non nightly packages as this is using
a different package name!

-- 
Regards
Carsten

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

Re: [Kicad-developers] possible license mismatch in bitmaps_png/sources ?

[Carsten Schoenert]

Hell Seth,

Am 02.04.21 um 17:14 schrieb Seth Hillbrand:
> The correct license is CC-BY-SA.  We'll update the SVG to the correct
> license.
thanks, I'll use some more recent snapshot then as this makes my life
easier.

-- 
Regards
Carsten

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

[Kicad-developers] possible license mismatch in bitmaps_png/sources ?

[Carsten Schoenert]

Hi,

while working on a current snapshot (42c6af4) of the KiCad development
tree and adjusting the build environment for Debian unstable I'm facing
the output of the Lintian QS tool about the usage of the non-free
Creative Commons Non-Commercial Share-Alike (CC-NC-SA) license for some
source files. The used license is considered as non-free within Debian.

> $ grep -r by-nc-sa bitmaps_png/sources/
> bitmaps_png/sources/dark/gbr_select_mode2.svg:   
> rdf:resource="http://creativecommons.org/licenses/by-nc-sa/4.0/; />
> bitmaps_png/sources/dark/gbr_select_mode2.svg: 
> rdf:about="http://creativecommons.org/licenses/by-nc-sa/4.0/;>
> bitmaps_png/sources/dark/bug.svg:   
> rdf:resource="http://creativecommons.org/licenses/by-nc-sa/4.0/; />
> bitmaps_png/sources/dark/bug.svg: 
> rdf:about="http://creativecommons.org/licenses/by-nc-sa/4.0/;>
> bitmaps_png/sources/light/gbr_select_mode2.svg:   
> rdf:resource="http://creativecommons.org/licenses/by-nc-sa/4.0/; />
> bitmaps_png/sources/light/gbr_select_mode2.svg: 
> rdf:about="http://creativecommons.org/licenses/by-nc-sa/4.0/;>
> bitmaps_png/sources/light/bug.svg:   
> rdf:resource="http://creativecommons.org/licenses/by-nc-sa/4.0/; />
> bitmaps_png/sources/light/bug.svg: 
> rdf:about="http://creativecommons.org/licenses/by-nc-sa/4.0/;>

The CREDIT file in the same folder is saying something different.

> $ cat bitmaps_png/sources/CREDITS 
> ICONS:
> 
> Original KiCad Icon work by Inigo Zuluaga and Fabrizio Tappero among others
> 
> KiCad icons were redesigned in 2020 by Aleksandr Zyrianov
> 
> License: CC-BY-SA 4.0

No matter how the correct situation is, I see here a mismatch between
the source license and the later used license. I'm not sure if the
source license is by-nc-sa-4.0 (CC-NC-SA) then the derived work can be
licensed as CC-BY-SA.

If the source files with the critical license aren't used for building
the KiCad package I can drop them while importing the source into the
Debian working tree. The KiCad package is already using the 'dfsg'
suffix due other files we need to exclude.

So, how is the correct license situation for the SVG files in questions?
And, are these files critical for building the KiCad package?

-- 
Regards
Carsten

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

Re: [Kicad-developers] ngspice-34

[Carsten Schoenert]

Am 03.02.21 um 13:03 schrieb jp charras:
> OTOH, a version.h file is not a bad idea (read: for me a very good idea):
> 
> at least the name is already a useful comment and it request only a very 
> few amount of work.
> 
> Many tools use this trick (for instance opencascade, and most of other 
> tools we are using in Kicad), and one **big** advantage it works outside 
> the libtool stuff.

For simple things like version detection pkg-config is already enough,
no need for mostly incompatible hacks. Even different shells on the same
host can behavior really unexpected.

If you need to detect the version of ngspice you will need to do this
this already before any build is started.

> $ pkg-config --modversion ngspice
> 33
-- 
Regards
Carsten

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

Re: [Kicad-developers] ngspice-34

[Carsten Schoenert]

Hello Holger,

Am 03.02.21 um 11:20 schrieb Holger Vogt:
> 
> I remember some time ago I tried to address the libtool versioning, but 
> I did not understand it, so abandoned it again.

libtool isn't really easy, yes, but the more complicated thing is to
integrate the things correctly into configure.ac and potential
Makefile(s).am.

If I'm feeling boring enough I can try to have look this. But ngspice
did already cost a lot of my brain in the past. :P

> What about adding and distributing alongside of sharedspice.h a version 
> header file verngspice.h which contains only some version info?

That would for sure help for the problem Ian has written about, but it
doesn't solves the underlying real problem, a non versioned library.

To add such a version string you even don't need to add another header
file, there is already sharedspice.h available. It's easy to process
this as .h.in file while configure is running to add such a version
string. I can try to have a look at this as well.

-- 
Regards
Carsten

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

Re: [Kicad-developers] ngspice-34

[Carsten Schoenert]

Am 03.02.21 um 08:34 schrieb Holger Vogt:
> To obtain version information of the currently available libngspice-0.so 
> version, you might do the following:
> 
> load libngspice-0 dynamically
> initialze libngspice
> send the command 'version -s'
> retrieve some text response similar to the following:
> 
> **
> ** ngspice-34
> ** Please get your ngspice manual from 
> http://ngspice.sourceforge.net/docs.html
> ** Please file your bug-reports at 
> http://ngspice.sourceforge.net/bugrep.html
> ** Creation Date: Fri Jan 29 14:27:27 UTC 2021
> **
> 
> check for ngspice, get the version number
> unload libngspice

I'd say the only reliable long term way is to add a proper libtool
versioning with correct API/ABI integration in ngspice. All other things
will break on various ends again and again and will become PITA.
ngspice-34 comes with new symbols since at least version 28.

-- 
Regrads
Carsten

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

Re: [Kicad-developers] ngspice-34

[Carsten Schoenert]

Hello,

Am 02.02.21 um 22:07 schrieb Jean-Samuel Reynaud:
> FYI:
> As I see the PATH for the file ngspice/config.h is changed on
> ngspice-34. And on debian package this file is no more distributed on
> this version (as I see on last updated package).
> 
> So there is an impact on some KiCad code:
> 
> common/build_version.cpp:161:#include 

including a build specific header file from a depending component could
never be correct.

I dropped a note about that behavior of ngspice to ship the config.h
file some versions ago to Holger, but let the shipped header file within
the package. That's now gone.
Holger modified the configuration of ngspice so that the dist target of
ngspice isn't packaging config.h into the tarball that is correct, it's
(re-)created while the configure run.

I've no idea what functions did get included from ngspice/config.h
within kicad, but the only correct header file for including external
function is ngspice/sharedspice.h in case.

Starting a KiCad 5.1.9 together with libngspice0 34 works without
problems so far I could test it.

-- 
Regards
Carsten

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

Re: [Kicad-developers] Build problem of current master tree

[Carsten Schoenert]

Am 02.01.21 um 18:07 schrieb jp charras:
> What is the problem with these files?

They are build in tree in case you do a configure out of tree?

> They are already the final header files built from the corresponding .md 
> files.

In my eyes it's simply the wrong way to build files in another place
than I do configuring things, that's not expected by the user.

-- 
Regards
Carsten Schönert

___
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] Build problem of current master tree

[Carsten Schoenert]

Hi,

Am 02.01.21 um 17:17 schrieb jp charras:
> 
> Le 02/01/2021 à 17:09, Nick Østergaard a écrit :
>> FYI, there are still generated files in the source which are also 
>> checked in to the source tree:
>>
>> After a make clean:
>> deleted:    ../eeschema/dialogs/dialog_bom_help_md.h
>> deleted:    ../pcb_calculator/attenuators/bridget_tee_formula.h
>> deleted:    ../pcb_calculator/attenuators/pi_formula.h
>> deleted:    ../pcb_calculator/attenuators/splitter_formula.h
>> deleted:    ../pcb_calculator/attenuators/tee_formula.h
>> deleted:    ../pcb_calculator/eserie_help.h
>> deleted:  ../pcb_calculator/tracks_width_versus_current_formula.h
>>
> 
> They are automatically generated but they must be available in sources 
> because they are  needed for translations.

can't they turned into something like '*foo_header.h.in' that get than
processed into the final header file?
By this the files are still available, or better their content, for
localization.

-- 
Regards
Carsten Schönert

___
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] Build problem of current master tree

[Carsten Schoenert]

Hello Seth,

Am 02.01.21 um 17:02 schrieb Seth Hillbrand:
> Hello Carsten-
> 
> We agree with you.  This is why we moved the generated files to the
> build tree and out of the source tree.  But legacy files in the source
> tree are still considered first, so older build directories need the
> fix-up that Jeff mentioned.  We might be able to get around this by
> changing the .gitignore but we haven't tested that.

thanks, good to you you are aware about this problem.

I can remember we had in the past already some posts about this header
file thing.

-- 
Regards
Carsten Schönert

___
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] Build problem of current master tree

[Carsten Schoenert]

Hello Jeff,

Am 02.01.21 um 15:45 schrieb Jeff Young:
> Hi Carsten,
> 
> Known problem when building 5.99 in a tree that used to hold 5.1.
> 
> Try:
> 
> cd include
> rm *_lexer.h
ahh, yes that fixed the build.

But I see the build of additional required files within the source tree
rather as issue if I build out of tree. Is this behavior a problem of
cmake or more a miss configuration of the build controlling?

-- 
Mit freundlichen Grüßen
Carsten Schönert

___
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] Build problem of current master tree

[Carsten Schoenert]

Hi,

since a long time I'm trying to build a current version of 5.99 again.
But my attempt is failing with this error.

> [ 70%] Built target eeschema_kiface_objects
> Scanning dependencies of target eeschema_kiface
> [ 70%] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface.dir/eeschema.cpp.o
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:239:22:
>  error: use of undeclared identifier 'T_pinfunction'
> case T_pinfunction:
>  ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:362:14:
>  error: use of undeclared identifier 'T_property'
> case T_property:
>  ^
> 2 errors generated.
> make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:689: 
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o]
>  Error 1
> make[2]: *** Waiting for unfinished jobs
> [ 70%] Linking CXX shared module _eeschema.kiface
> make[1]: *** [CMakeFiles/Makefile2:2859: common/CMakeFiles/pcbcommon.dir/all] 
> Error 2
> make[1]: *** Waiting for unfinished jobs
> [ 70%] Built target eeschema_kiface
> make: *** [Makefile:182: all] Error 2

I'm running the required configuration within the classical subfolder
build/ which is empty before starting the cmake call.

Known problem or do I miss some thing on my site?

-- 
Regrads
Carsten

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

Re: [Kicad-developers] 5.1.9 tagged for release

[Carsten Schoenert]

Hell Nick,

Am 23.12.20 um 10:07 schrieb Nick Østergaard:
> Hi Carsten
> 
> This is a balancing act. Quite some time ago we decided that we should
> make the release _announcement_ (on the website) when we have build
> available for some major platforms, these specifically being windows,
> ubuntu ppa and macos, mostly because that gives us some good
> "coverage" and we control those builds "ourselves".

that's of course up to the KiCad team to do such decisions. But I see no
reason why KiCad should be that exclusive. So far I've seen in the past
all the big distributions and the maintainer of the packages for KiCad
have acted quick as possible. But you need to give them some time. And
again, we have x-mas, why rushing things more than needed?

> I am not trying to exclude you as a kicad maintainer.

But this is it it looks like.
As at least one other contributor has stated, please give us the needed
time. No planned release announcement was done again on any of the ML. :-(

> By having the release announcement, it is easier to use that as a
> reference when users are flagging packages in various distros.
> Essentially we don't expect other distros to have builds ready by the
> release announcement.
Why not doing this? It has worked in the past years. It would look much
better if things would be done more coordinated.

-- 
Regards
Carsten

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

Re: [Kicad-developers] 5.1.9 tagged for release

[Carsten Schoenert]

Hi,

Am 22.12.20 um 23:01 schrieb Nick Østergaard:
> I don't think we need that long. Everything seems to be tagged. I have
> triggered the windows build and it should just be a simple pkgver bump
> for macos and ubuntu ppa as well.

please do also remember that there is more out there than the builds
done by KiCad team members. Especially right now one day before the
X-mas days. I see no need to rush up things more than on other releases
too. Providing new packages is one part, don't forget that in the
western world the users of such releases will be too on X-mas holidays
so the gain would be rather small.

I personally have slightly different interests than going immediately
over to do packaging work.

For me the time span Wayne has given is the right approach and don't
brings in some none useful pressure.

-- 
Regards
Carsten

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

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

[Carsten Schoenert]

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

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


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


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


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


--
Regards
Carsten

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

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

[Carsten Schoenert]

Mark,

Am 03.08.20 um 20:19 schrieb Mark Roszko:

But this is also a nightmare.


I don't know what you mean here.

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


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


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


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


--
Regards
Carsten

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

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

[Carsten Schoenert]

Hello Ian,

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


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


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


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


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

--
Regards
Carsten

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

Re: [Kicad-developers] no broken default fp-lib-table, removed footprint library

[Carsten Schoenert]

Hello Wayne,

Am 14.05.20 um 18:43 schrieb Wayne Stambaugh:

Carsten,

What information do you need from KiCad.  Does Debian (or any other
disto) have recommendations for upstream projects to help packagers?


Debian has some dedicated information for upstream projects and coders 
of course.


https://wiki.debian.org/UpstreamGuide

But these are all plain technically points written down. You will not 
find any issues for the main KiCad application based on the list from 
the Debian wiki and that's good.



Packaging is import to the project so if we can package devs lives a bit
easier, I'm willing to consider ways to do so.


We are going in loops so I currently don't want to put more energy into 
a for me pointless discussion. And it's also disappointing and not 
encouraging if people saying they haven't read my complete message(s) ...


The main point is that projects simply should provide as much 
information and communication as possible about the new versions they 
provide. Distributions need always to think about how intrusive 
modifications are, that's mainly a simple risk analysis.


What do you think if a contributor is providing a 1000 line patch for 
KiCad and you have no further information than that pure diff?

That's mainly the situation for me regarding to symbols and footprints.

The release of a new KiCad version can be improved in my eyes by doing a 
better job of release managing. For example some parts do create release 
candidates some don't. Makes it difficult for me to do packaging 
preparations as the final version of the kicad package says then nothing 
about the real combined l10n and documentation parts as I need to pick 
up some random versions. Also not helpful if users bring up issues as 
you need to figure out against what commits these are for real.


--
Regards
Carsten

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

Re: [Kicad-developers] no broken default fp-lib-table, removed footprint library

[Carsten Schoenert]

 also also the GitLab sites to get an
full overview.

> All this is to say we will try not to repeat past issues but we are
> human and can't prevent making new ones. While it's great you're
> taking such an active interest in things and advocating for KiCad
> users, I expect you have a lot to do and would prefer that KiCad and
> other programs will take care of themselves. I believe we have done
> that here and will continue trying to do so in the future.

The KiCad project is one full of incredible people and developers. And
that's really great! And in my eyes KiCad is one of the best and in some
parts the only FOSS alternative to proprietary EDA tools. And as I
strongly believe on FOSS and enjoy to work with KiCad I'm happy to work
on packaging all this stuff to spread these tools.

But FOSS is nothing if we don't always also respect the users POV and
how they expected thing to behave. The gap between the software
developers and the users is filled by the packages user install and use.
But the packagers are completely depending on the information they have
and can get from the developers. And here for KiCad these people sitting
quite near to each other and we shouldn't make our free time work more
difficult and energy draining than really needed. That's mainly the core
point I wanted to show off by first email on this.

As always, it's about communication!

-- 
Regards
Carsten Schoenert

___
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] no broken default fp-lib-table, removed footprint library

[Carsten Schoenert]

Hello Rene,

Am 12.05.20 um 22:58 schrieb Rene Pöschl:
> What is broken here? The old library folder is still there to ensure 
> users do not get an error message. Footprints are embedded in the design 
> files so no negative impact on old designs. The new footprints are 
> vastly superior to the old ones so the tradeoff is simply worth it!

I'm glad that you can refute my concerns as this means in the end that
users don't get interruptions. And that's what I want and need to take
care on.

...
>> Keeping that entry makes no sense to me if the folder is now empty.
> Yes we could remove the entry but our CI script would complain -> so we 
> decided to just have the empty lib it does not hurt anyone.

So more a problem to get this reason publicity visible then?

...
> Well now you know why we keep the empty folder. (At least v5 does no 
> longer crash with a missing lib.)

No, I don't know this, otherwise I wouldn't ask, the experience of
releases from past was it was a problem. As written previously, I do not
and can't follow all the various developments in all places, to many
various places with different platforms for development.

...
> The two bug reports you list again clearly show why we now keep the 
> libraries as empty instead of removing them.

O.k. to summarize, the movement of footprints within libraries isn't a
problem (any more) as long the old now empty directory is still shipped?
Sounds like a issue to me.

I will try to do a bit of testing but this isn't possible to do this
manually for every release as the cases you want or need to test will
immediately growing. I haven't the time to do such things.

It would have been really helpful for me if things like above would get
communicated in a better way. The simplest thing is a text file within
the repository, mostly called README. :)
I haven't found any information in the git tree, in the mailing list, on
the KiCad website or on GitHub.

-- 
Regards
Carsten Schoenert

___
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] Broken default fp-lib-table, removed footprint library

[Carsten Schoenert]

Hi,

I started to package the updated packages due the tagged KiCad 5.1.6
release and started alphabetically with the footprints as this is the
first directory locally.

More by an accident I noticed that the directory
Connector_Multicomp.pretty is now empty. Digging into the reason behind
that I can see that the whole content of this folder has moved into
Connector_IDC.pretty.

I see there multiple issues here.

1. For me this is a breakage (again) of the rule no changes within the
stable release cycle on the user side that can break user projects and
workflows.
Compared to a classical C/C++ library would this be a removal of a
public symbol without an wrapper for backward compatibility, means an
API/ABI break which requires a increasing of the ABI version.

2. The default footprint table (fp-lib-table) within the tagged 5.1.6
tree is still referencing the old folder so user get this installed as
the default base for their footprint library table if they install a new
KiCad version or enforce a new default table.

> $ git grep -n Multicomp fp-lib-table
> fp-lib-table:28:  (lib (name Connector_Multicomp)(type KiCad)(uri 
> ${KISYSMOD}/Connector_Multicomp.pretty)(options "")(descr "Multicomp 
> connector foottprints"))

Keeping that entry makes no sense to me if the folder is now empty.

3. KiCad still has no internal mechanism to handle such removals within
the user space to adjust the local footptint table. Package
installations / removal doesn't touch or modify any user specific
configuration files so manual interaction from the user is needed to
adjust such cases.
Adding such an feature is not the responsibility of the library
maintainers of course, but makes such changes more difficult and
problematic within a stable release cycle. (And of course I don't want
to blame any one here!)

4. I haven't found a README or otherwise announcement about this change.
Also the commit message f764afb in kicad-footprints is rather short and
not explaining to me.

This all did already happen previously in 2017 in the releases of 4.0.5
and 4.0.7. At least two bug reports within Debian did happen due these
changes as this was leading to a breakage on the user side and also
leading to bad user experience.

https://bugs.debian.org/859409
https://bugs.debian.org/860093

In the past "we" solved the issues by adding symlinks from the old to
the new containing folder. Currently I'm undecided what to do here in
this new case.

Anyhow, please don't do such changes within a stable release cycle! It's
o.k. to do such things within major version bumps (as at some time it
must happen) but not within an increased *micro* version!
People do not expect such changes. And the majority of user isn't
following the development of KiCad itself or the libraries in deep! Keep
that in mind please. Thanks.

-- 
Regards
Carsten Schoenert

___
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] Is it really the case that installing KiCad on a Mac requires manually copying files around?

[Carsten Schoenert]

Hi Nick,

Am 25.04.20 um 12:58 schrieb Nick Østergaard:

I don't think we gain anything by adding more complexity to the
download page. It is after all just a download page.


I can't follow your reasoning here. Please pick up the users there they 
are and not there you think they are.
Writing some good explanations even for the MacOS users isn't that hard 
I'd say.



If we really need to do very step-by-step and verbose explanations for
those can't can't read the README in the installer,


Well, you've wrote "in the installer", so users might have some chicken 
/ egg problem here. You know you've done it wrong if you have broken it. 
It doesn't help users if you say them afterwards they did it wrong, this 
something they already know. Writing up same sharped sentences for MacOS 
users on the Download page what they need to do right before they start 
to download anything is better. Try to have a view from a users point of 
view who hasn't done any thing with KiCad before. We all here are quit 
deep in the software, project and so on and know how everything is 
working, but think back to the days once you started with KiCad.



I think that is better suited in a chapter of the documentation,
possible as a big section in the Getting Started in KiCad doc. Having
it in the documentation will also make it easier to translate.
For sure this is some useful thing, but do you really think *most* of 
the users do really read some bigger documentation first before they 
install some software? :-)
You only have about 20-30 seconds off attention if people land on the 
Download page (or any other web page). So better you remember this 
always and try to transfer the needed knowledge within that time span. 
But its' easy to point to the relevant part of documentation there you 
can explain things more in deep.



Also, don't forget that as it is now works for all other people, than
a small handful of people. We can't help everyone always.


The smaller part of people or users that aren't satisfied can make some 
bigger damage on a project than the broader "normal" audience. So try to 
keep this one group of people, that you will never serve completely, 
always small as possible.


--
Regards
Carsten Schoenert

___
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] Please be kind towards translators

[Carsten Schoenert]

And as we are on 'wxString errmsg', plugins/pluginldr.cpp is containing
a lot of strings like

> wxString errmsg = _( "missing function 'GetVersion'" );

Looks to me as these are also no strings for the normal user. Or am I
wrong here?

-- 
Regards
Carsten Schoenert

___
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] Please be kind towards translators

[Carsten Schoenert]

Am 05.04.20 um 11:25 schrieb jp charras:
> I just removed the I18N mark of strings used in debug messages.

Thanks, seems you have missed some of them?

> pcbnew/altium2kicadpcb_plugin/altium_parser.cpp:THROW_IO_ERROR( _( 
> "stream too large" ) );

> pcbnew/altium2kicadpcb_plugin/altium_pcb.cpp:
> wxString::Format( _( "No text position present for leader dimension object" ) 
> ) );

For the latter I'm not sure, but wxLogError looks not like it's some
string for the UI. Nitpick, it's not a sentence, the leading sentence
terminator is missing.

-- 
Regards
Carsten Schoenert

___
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] Inconsistency within l10n strings

[Carsten Schoenert]

Hello Marco

Am 04.04.20 um 20:05 schrieb Marco Ciampa:
> I do not know but perhaps rules are different in different countries?

that's for sure.

> For example single ' quote mark is never used in Italian so I always
> convert them into a double " quote.

I mostly do so too, but every time the original string is changed I need
to review this again. But the English source itself should be consistent
on this to lower down the work on currently 5.722! strings. :-)

-- 
Regards
Carsten Schoenert

___
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] Inconsistency within l10n strings

[Carsten Schoenert]

Hi,

I'm not sure if there are any written rules for creating l10n strings
within the source code. But one thing that I see quite often is changing
the escape sequence for variables like %s or %d.

So for example the string

Could not load footprint "%s" from library "%s".

is now changed to

Could not load footprint '%s' from library '%s'.

A few months back it was changed to the now again changed style. This
forward and backward makes translation work a bit tedious.

Both variants seen above are common in current generated .po files, but
most of the variables are inside double quotes.

Wouldn't it make sense to write up all these strings based on the same
rules?

-- 
Regards
Carsten Schoenert

___
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] FOSDEM 2020

[Carsten Schoenert]

Hi Seth,

Am 15.12.19 um 16:11 schrieb Seth Hillbrand:
> All pre-planned information has been shared on the mailing list, e.g. 
> KiCad Dinner, KiCad Coding Day, etc.

but they are fragmented and split of into various topics. :)
My day job is eating currently all of my time and also energy, that's
why it's a bit hard for me to follow all the news you give.

What about an Etherpad site (as KiCad currently has no Wiki) to keep all
the information and news on one place?

> Zulip is for small, on-the-ground coordination.  It is helpful to know 
> where people are meeting for lunch or an improptu debug session or who 
> is running late.

That's absolutely fine. I simply haven't knowing this software before.

> I hope that you'll be able to make the KiCad dinner.

There is also a planned MiniDebConf before the Fosdem itself, so there
are already some clash of dates. :(
I'd like to attend but this will mostly not work for me. But I will come
to the devroom.

> If you would like to be informed of the more minor communications,
> please send me your phone number and I'm happy to text you the
> information.
Thanks, but that's not needed. I'm mostly interested in the basic
headlines like where to find the devroom etc.

-- 
Regards
Carsten Schoenert

___
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] FOSDEM 2020

[Carsten Schoenert]

Hello Seth,

Am 10.12.19 um 23:19 schrieb Seth Hillbrand:
> We've set up a FOSDEM-specific room for event-related conversations and 
> coordination on site.  You can join the room at 
> https://kicad.zulipchat.com/join/iabkkf35trcq1mv2ygdpn6qo/

please not only use this channel for communications, spread news around
the Fosdem event and the presence of the KiCad project and contributors
alse here in the ML and/or also on the website.

I'm e.g. unable to register in Zulip (haven't heard about this before)
but I'm also not willing to install and use $some application for an on
time usage.

Usually I'm on Fosdem and also willing to meet other people from the
project or talk to other users. Time to keep up on all things I'm
somehow involved in my free time is really limited, can all the
important facts about KiCad@Fosdem2020 gathered on the website please so
all is visible easily?

-- 
Regards
Carsten Schoenert

___
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 Packagers: Resource File Updates

[Carsten Schoenert]

Hi Ian,

Am 29.11.19 um 12:16 schrieb Ian McInerney:
> Carsten, thanks for pointing those changes out. I will update the file
> with them as well. Redoing the screenshots is also on my todo list
> (since they still show a v4 release currently). Do you know what the
> guidelines are for sizing of them?

sorry no.

> I see that the current ones are 1024x576, and I can't seem to find
> any information on the suggested size (other than that Fedora
> recommends they are 16:9).
I've looked at some existing appdata files.

> https://code.videolan.org/jbk/vlc/blob/master/share/vlc.appdata.xml.in.in
> https://die-offenbachs.homelinux.org/hg/eric/file/tip/linux/eric6.appdata.xml.in
> https://github.com/gramps-project/gramps/blob/master/data/gramps.appdata.xml.in
> https://code.videolan.org/jbk/vlc/blob/master/share/vlc.appdata.xml.in.in

They mainly use a resolution with at least 1024px width. But the main
trick in AppStream is that the data is not shipped internally but
integrated as an external source so you can exchange them at any time
and also use them for other things like as an normal screenshot within
the website blog and so on.

I think a size of 1024x576 is fine, but a greater size would also be
o.k. The images should help users to get an overview of the application,
so a bigger screenshot would be better than a smaller one.

-- 
Regards
Carsten Schoenert

___
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 Packagers: Resource File Updates

[Carsten Schoenert]

Am 29.11.19 um 13:01 schrieb Nick Østergaard:
> I have not seen any packaging scripts depend on it, if it does I think it
> is fair for the package to be updated, but isn't it alreade handled by the
> make install step?

That's correct, so far I know all distros build the package and install
the data into a temporary folder from which the package(s) are created.
So the final appdata file needs to be installed into this temporary
folder, but that's already happen now.

-- 
Regards
Carsten Schoenert

___
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 Packagers: Resource File Updates

[Carsten Schoenert]

Hello Ian,

On 28.11.19 17:53, Ian McInerney wrote:
> I would like to change the way we generate the kicad.appdata.xml file to
> have it be generated by CMake and include the version string inside of
> it (that way the version will appear in the app stores and other places
> that reference this). I don't think this will cause any issues, but I
> just want to see if anyone sees any problems with this.

this can't be a problem as the AppStream specification is holding a key
for versioning information. Please see section 4.1.2,  ...


> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps

If you touch this all I'd suggest to update all URLs within the appdata
file as now the kicad-pcb.org domain is served by https.

> $ git diff
> diff --git a/resources/linux/appdata/kicad.appdata.xml 
> b/resources/linux/appdata/kicad.appdata.xml
> index 2fc29f0c1..550cb10c5 100644
> --- a/resources/linux/appdata/kicad.appdata.xml
> +++ b/resources/linux/appdata/kicad.appdata.xml
> @@ -46,27 +46,27 @@
>  
>
>  
> -   height="576">http://kicad-pcb.org/img/screenshots/appstream/kicad.png
> +   height="576">https://kicad-pcb.org/img/screenshots/appstream/kicad.png
>  
>  
>  
>Eeschema Schematic Editor
> -   height="576">http://kicad-pcb.org/img/screenshots/appstream/eeschema.png
> +   height="576">https://kicad-pcb.org/img/screenshots/appstream/eeschema.png
>  
>  
>  
>PcbNew PCB Layout
> -   height="576">http://kicad-pcb.org/img/screenshots/appstream/pcbnew.png
> +   height="576">https://kicad-pcb.org/img/screenshots/appstream/pcbnew.png
>  
>  
>  
>PcbNew 3D Viewer
> -   height="576">http://kicad-pcb.org/img/screenshots/appstream/3dviewer.png
> +   height="576">https://kicad-pcb.org/img/screenshots/appstream/3dviewer.png
>  
>
>  
> -  http://kicad-pcb.org/
> -  http://kicad-pcb.org/help/report-a-bug/
> +  https://kicad-pcb.org/
> +  https://kicad-pcb.org/help/report-a-bug/
>kicad-developers@lists.launchpad.net
>The KiCad Developers
>  

This reminds me that all the screenshots should be updated too. ;)

The validator for the AppData content within the Debian QA is mentioning
that the component ID is not a reverse domain-name. Should get fixed too
in case the file is getting changed.

> https://appstream.debian.org/sid/main/issues/kicad.html

-- 
Regards
Carsten Schoenert

___
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] Building Kicad on Windows 10/Eclipse/Msys2

[Carsten Schoenert]

Hello Eli,

Am 23.11.19 um 10:03 schrieb Eeli Kaikkonen:
> BTW, it's unnecessarily verbose to say "git pull origin master". Just
> "git pull" is enough when you are in the local master branch.

no it's not.
Your statement is only true if the user hasn't added one ore more
remotes. If you have only one remote configured git tries to be smart
and is substitute the rest for the command by the obviously logical value.

So, if you want to be safe than the full command line is correct.

-- 
Regards
Carsten Schoenert

___
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] [PATCH] Update python defaults

[Carsten Schoenert]

Am 26.10.19 um 23:03 schrieb Steven A. Falco:

I've been building for Fedora using both KICAD_SCRIPTING_PYTHON3=ON
and KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON for quite a while now, FWIW.
The same is true for Debian builds of KiCad in unstable/testing and 
buster/buster-backports for a while (since 5.0.2 at least).


Until now no reports about issues on this have reached the bug tracking 
system.


--
Regards
Carsten Schonert

___
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] Python files still depending on Python2 only due used shebang

[Carsten Schoenert]

Am 26.10.19 um 16:09 schrieb Seth Hillbrand:

I've added [1] so that we make sure to get to it before v6 is released.
What is the timeline for the new stable Debian/Fedora?  Do we need to
accelerate this for 5.1.6?


The next Debian stable release is planned for autumn 2021. So no rush 
needed.


--
Regards
Carsten Schoenert

___
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] Python files still depending on Python2 only due used shebang

[Carsten Schoenert]

Hello Wayne,

Am 26.10.19 um 15:53 schrieb Wayne Stambaugh:

I'm guessing that fixing the shebangs will not be enough because there
is python2 specific code in the script files.


I think so, I've haven't looked at the Python3 compatibility of the 
underlying code, just grep'd for potential shebang lines. Looking at the 
date within the copyright statement let me be quite sure the files wont 
be Python3 ready.


And this is for sure true for mostly all the existing files.

--
Regards
Carsten Schoenert

___
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] Python files still depending on Python2 only due used shebang

[Carsten Schoenert]

Hi,

as probably known Debian is planning to get Python2 removed within the
next planned stable release.

This requires no hard dependencies on Python2 of course in all related
packages.

The master branch (and of course also the branch 5.1) has still some
Python scripts which do have a shebang that is hard wired to the python2
binaries.

> $ for file in `find -type f -name "*.py"`; do if head -1 $file | grep -e 
> python2 -e /python; then echo found in $file; fi ;done
> #!/usr/bin/env python2.7
> found in ./pcbnew/python/examples/createFPC40.py
> #!/usr/bin/env python2
> found in ./scripts/ddr3_length_match.py
> #!/usr/bin/python
> found in ./scripts/test_plugin.py
> #!/usr/bin/python
> found in ./scripts/lib_convert.py
> #!/usr/bin/python
> found in ./scripts/test_kicad_plugin.py

Any plans to convert these files to at least a shebang of
'#!/usr/bin/env python' and a compatibility so the scripts can also be
used within a Python3 interpreter?

KiCad still has some other (indirect) dependencies on Python2 which will
also needed to get resolved, but that's another story.

-- 
Regards
Carsten Schoenert

___
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.5 release status

[Carsten Schoenert]

Hi Ian,

Am 23.10.19 um 18:59 schrieb Ian McInerney:
> Carsten, I just made a merge request on the Debian packaging repo to do
> this. Can you take a look at it and comment? After this change, I see
> the -DNDEBUG appearing in the compile command when I do a local build on
> my machine.

thanks, I merged your PR right now.

-- 
Regards
Carsten Schoenert

___
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] Minimum Boost version

[Carsten Schoenert]

Hello Wayne,

Am 23.10.19 um 18:43 schrieb Wayne Stambaugh:
> I thought most Linux distros packaged software in accordance with the
> preferred packaging requirements for each distro.  It used to be the
> case that distros frowned upon externally build packages because there
> was always the distinct possibly that they would break something in ways
> that were difficult to resolve.  I was not aware that this attitude has
> changed.  Too be honest, I would rather the distros build KiCad
> according to their requirements.  I would think the manpower for us to
> provide packages for every linux distro would be overwhelming.

at least my experience on this topic is that some upstream projects are
doing are really bad job on building their software for various Linux
distributions from a quality POV regarding the the packaging
requirements. And further more the feedback from the upstream projects
you will get if you point out problems is from "Thank you very much." to
"We don't care your comments".

I've seen packaged software that is breaking the distro they are
packaged for but also high quality packages which mostly could be easily
included in the distribution from the QA point.

Some upstream are scared if you asked them if they don't want put their
packages into the official distribution packaging process because they
think they are not good enough, other say they don't have the manpower
for doing this on a longer time base.

What always is helping is to get and stay in touch with the Linux
distributions because they know not only their (packaging) requirements
best. OTOH packaging is a technical thing mostly and the packagers don't
know every detail of the software they are packaging, here it is really
helpful if upstream maintainer can help. And members of the distro can
help regarding planned release time spans for their releases.

-- 
Regards
Carsten Schoenert

___
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.5 release status

[Carsten Schoenert]

Hello Seth,

Am 22.10.19 um 18:10 schrieb Seth Hillbrand:
> Why do you have "hardening=+all" enabled?

mostly because this is the default for building binary packages with
enabled hardening.

https://wiki.debian.org/Hardening#Using_Hardening_Options

> This is likely where the assertions are happening.  We might consider
>  "hardening=-all,+format,+fortify"
I'm not that deep into the details here or at least would need to keep
reading some stuff. But as far I've understand the hardening flags
should have no effect on this.

Maybe Simon can give some enlightenment on this?

-- 
Regards
Carsten Schoenert

___
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.5 release status

[Carsten Schoenert]

Hi,

Am 21.10.19 um 23:16 schrieb Ian McInerney:
> We also seem to have assertions enabled in the Debian build (there have
> been two reports from users [1], [2]). Is this something we control as
> well, or is the the distribution packaging forcing them on?

the Debian build configuration is visible in the GitLab repo for KiCad
on Salsa.

https://salsa.debian.org/electronics-team/KiCad/kicad
https://salsa.debian.org/electronics-team/KiCad/kicad/blob/debian/sid/debian/rules

I'm happily taken any patches if provided.

I personally haven't seen these asserts.

-- 
Regards
Carsten Schoenert

___
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] GitLab migration

[Carsten Schoenert]

Hi!

Am 09.10.19 um 20:45 schrieb Steven A. Falco:
> On 10/9/19 12:36 PM, Wayne Stambaugh wrote:
>> The lead development team has been discussing migrating the KiCad
>> project to GitLab[1].
> 
> For packagers, I'm curious as to how creating an archive from a tag
> would work.  Currently, to grab the source from launchpad, we use a
> URL like:>
> https://launchpad.net/kicad/5.0/%{version}/+download/kicad-%{version}.tar.xz
> 
> where %{version} is a Fedora macro that expands to the desired
> version.  This apparently works because Wayne explicitly uploads the
> tarball to launchpad.>
> For github, we use:
> 
> https://github.com/KiCad/kicad-doc/archive/%{version}.tar.gz
> 
> This works because github has an API that creates the tarball on-demand.
> 
> I found some references regarding how this works in GitLab.  For
> example, please see Issue 38830:>
> https://gitlab.com/gitlab-org/gitlab-foss/issues/38830
> 
> According to that issue, you can request a tarball from GitLab,
> similarly to what you would do with GitHub.  However, when you
> request a tarball of a tag, the SHA will be part of the filename.
> Worse, the top level directory will also contain the SHA.
Why do you think that such an important feature isn't available in GitLab?

> https://gitlab.com/inkscape/inkscape/-/tags

On the right side there is a download icon, have a look at the
referenced URLs.

> This will complicate packaging, because we'll need to know the
> expected SHAs for each of the 7 repos, and rename the directories as
> the tarballs are unpacked.  Or I suppose we could use wildcards to
> achieve the same thing.  It is certainly doable, but it is a bit
> ugly.

I usually prefer to create the tarball on my machine by the 'git
archive' command.
But you can also use the plain GitLab API to request a download URL. But
that's not really needed as the various download URLs are predictable.

-- 
Regards
Carsten Schoenert

___
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] GitLab migration

[Carsten Schoenert]

Hi,

Am 09.10.19 um 19:53 schrieb Wayne Stambaugh:
> On 10/9/19 1:06 PM, Rene Pöschl wrote:
>> Hi, this is welcome news.
>>
>> I would suggest we do the library transfer as soon as the new
>> file format is somewhat stable as we will need to make a hard
>> cut for transfering the symbol libs to the new file format
>> anyway.
>> (We would avoid needing to do doulbe work this way.)
>>
>> Would then of course mean that the v5 development will
>> stay at github and only v6 will be found at gitlab.
>> (The v5 development will be halted as soon as we start with
>> v6 as we simply do not have the resources to handle two
>> releases. And i assume the move will take us quite a while
>> so we need to start early with it anyways.)
> 
> This is a good idea that I hadn't considered.

I disagree at the point that releases will be on two different places.
Please don't do this. As there si no need to do this.

Think about a branch model and you will see there is no need to have two
different resources to keep the data.

-- 
Regards
Carsten Schoenert

___
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] Minimum Boost version

[Carsten Schoenert]

Hi,

Am 26.09.19 um 22:26 schrieb Ian McInerney:
> Ping. Is there any opposition to bumping the minimum Boost version to
> 1.59?
I still see no technical need to increase the minimal version for Boost.

-- 
Regards
Carsten Schoenert

___
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] Minimum Boost version

[Carsten Schoenert]

Hi,

Am 29.08.19 um 14:09 schrieb Wayne Stambaugh:
> What's wrong with setting the minimum boost version to 1.59?  If this is
> the version that has the testing features that you need and presumably
> all later versions, then this should suffice.  I would prefer that we
> maximize the number of supported distros whenever possible.

fully agreed!
Please don't bump versions only because you can do this. Check always if
you need some new shiny function that is resulting in a version bump.

-- 
Regards
Carsten Schoenert

___
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] Strange program version numbering in KiCad

[Carsten Schoenert]

Hello Wayne,

Am 10.07.19 um 21:12 schrieb Wayne Stambaugh:
> The problem with d & e is I do not think they address the user
> interpretation of our version string.  Using "master" as a prefix or
> suffix probably doesn't mean much to many users.  You may be expecting
> users to be more informed about versioning than they actually are.

that's the point. Developers know were and what to look at, don't expect
user to know your development model. But they know versions.

It doesn't matter for the user what branch is used for which development
cycle. And it's not a good idea to use a branch name in the version
because you may use different branches while development. So pleas get
rid of the branch name in the created version string.

And yes, the current solution isn't (still) working well. But nobody
needs to reinvent a wheel. The problem has probably hit every project in
the FOSS world at any time somehow. Please have a look at other project
and how they solved this problem.

-- 
Regards
Carsten Schoenert

___
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] Strange program version numbering in KiCad

[Carsten Schoenert]

Hello Nick,

Am 09.07.19 um 21:57 schrieb Nick Østergaard:
> I have a hard time to understand how  5.99 is better to describe a 
> development version. 6.00 was already a bad way to describe it.
> People also were confused. To me .99 seems very arbitrary. Why not
> .1234?
simply your mind is interpreting this different than .99. ;)

GTK+ is doing this scheme with .90 to .99 for quite a while and this is
*oneway* to do it.

https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/

KiCad is not the first project that needs to find it's own agreement on
the versioning. (And wont be the last.)

I'm personally not that happy with the usage of the 'git describe'
command and the reading of tags from the tree. It was never a good
approach in my eyes and it is currently really horrible for users to
interpret the numbering schema. Even the current HEAD on the stable
branch has a wrong number starting with.

Why not hard-code the prefix within the CMake scripting voodoo like done
in probably the majority of recent project that using autotools for
configuration and add the commit count and id as a suffix like done now
already?

And a prefix '6.0-dev' or 'master-dev' is always better than the current
solution.

-- 
Regards
Carsten Schoenert

___
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] [PATCH] Crash Reporter

[Carsten Schoenert]

Hi,

Am 05.07.19 um 23:28 schrieb Ian McInerney:
> 3.1.x is essentially only available on the lesser-known distros and as
> additional packages for OpenSUSE. Aside from that, most distros run
> anything between 3.0.2 and 3.0.4. (see
> here: https://repology.org/project/wxwidgets/versions).

well, and that's for a simple reason Wayne has already written.

wxwidgets 3.0.x is the current version series marked as stable with no
API changes between releases.

And 3.1.x is the current development version of wxwidgets *with*
possible internal and external API modifications that make it hard for
distros to keep all depending packages in sync, it nearly impossible. So
no version 3.1.x is packaged in Debian at least for that reason. Not
even in experimental.

Once the API is set to frozen a new stable series of wxwidgets 3.2.x
will get released. Given the progress the wxwidgets development is
taking nobody can say a targeted date for a new stable release of wxwidgets.

-- 
Regards
Carsten Schoenert

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

Re: [Kicad-developers] New package for macOS 5.1.2 stable including ngspice-30 ?

[Carsten Schoenert]

Hello Wayne,

Am 10.06.19 um 20:15 schrieb Wayne Stambaugh:
> We cannot make ngspice 30 the minimum version.  There are far too many
> linux distros where 30 is not available yet.  Please keep in mind,
> Debian stable and the latest Ubuntu LTS version are the benchmarks for
> dependency package versions.  I'm fine with packaging macos and windows
> with 30.

current Debian stable (Stretch) has KiCad version 4.0.5+dfsg1-4 in the
archive and no package libngspice0 at all (not even in non-free) so
there is nothing to take care on here.

The current Ubuntu LTS release 18.04 (Bionic Beaver) has KiCad version
4.0.7+dfsg1-1ubuntu2 and libngspice0 version 27-1.
At least the KiCad version is long long outdated. So also not really
relevant too.

But all relevant current Debian releases are providing a recent KiCad
version and also libngspice0 in version 30.2-1 (from unstable to
stretch-backports). This is also available in all Downstream of Debian
means also in Ubuntu >= 'Cosmic Cuttlefish' are providing KiCad
5.0.0+dfsg1-2, but also libngspice0 in version 27. Updates wont happen.

But Jean-Samuel Reynaud is providing actual versions of KiCad and also
the depending libngspice0 package and they even work in the always
outdated Linux Mint distro. So for me your requirements you like to set
are fulfilled.

And normally the application is defining the requirements. Simulations
seems to be for some users an critical option. So if the maintainers of
ngspice hardly suggesting to use the most recent version of ngspice in
recent KiCad version I would strongly consider to increase this build
dependency.

In the end it's up to the KiCad maintainers to define the requirements
for KiCad. It was a long road to get ngspice into Debian main but in the
end it happened, big thanks to Holger again btw! So Debian has no
problem to provide KiCad with a depending libngspice0 library >= 30.2.

-- 
Regards
Carsten Schoenert

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

Re: [Kicad-developers] New package for macOS 5.1.2 stable including ngspice-30 ?

[Carsten Schoenert]

Hi,

Am 10.06.19 um 01:46 schrieb Ian McInerney:
> Is there a reason that pushing a change like this can't wait until the
> 5.1.3 release?

that's up to the packagers in my eyes and the severity of the issue. As
far I read the reason behind the request from Holger it's an important
enough update to provide an updated version 5.1.2 for macOS.

> Wayne had mentioned wanting to try to get it out the door in
> early July, which wouldn't be that far off. That would also give more
> uniformity in its roll out across the various platforms, and allow for
> easier identification of if a user is using the ngsice-30 version when bug
> reports are filed (since apparently the version information doesn't seem to
> contain that).

There will be always differences between Windows, Linux and macOS that
can't be completely wiped out. And the required and uniformed versions
of the build dependencies are only solvable by the configure settings.

> On Sun, Jun 9, 2019 at 10:01 PM Adam Wolf 
> wrote:
> 
>> How about making 5.1.2-1 or -2 or whatever.  I don't like replacing
>> packages that have been released.

Yes of course, only increase the packaging version.

-- 
Regards
Carsten Schoenert

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

Re: [Kicad-developers] New package for macOS 5.1.2 stable including ngspice-30 ?

[Carsten Schoenert]

Hi

Am 09.06.19 um 09:03 schrieb Holger Vogt:
> Hi Adam,
> 
> would you mind creating a new package for macOS 5.1.2 stable replacing 
> the outdated libngspice 26 by the recent libngspice version 30?
> 
> And then use libngspice 30 also for the nightlies?
> 
> Nick has done this successfully for Windows. All tests have been o.k..
> 
> The users may benefit from the ngspice patches since version 26 (see 
> https://bugs.launchpad.net/kicad/+bug/1821520) towards better usage 
> during pcb design.

it should be possible to check the version of the ngspice library while
the cmake configure run and error out if the version is lower than 30.
I'm not an CMake expert but some version check should be possible here too.

-- 
Regards
Carsten Schoenert

___
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] Improving library editor checks

[Carsten Schoenert]

Hi,

Am 25.04.19 um 16:15 schrieb Wayne Stambaugh:
> Python scripting support is hopefully going to be implemented at some
> point during V6 development.  This should allow you to integrate the KLC
> scripts directly into the symbol library editor.  This will most likely
> happen late in V6 development because there are some major functional
> changes to the low level schematic and library objects.  It doesn't make
> sense to swig this until the low level object APIs stabilize.

what I'd like to see in KiCad regarding some automatic QA while creating
own symbols or footprints is a possibility to do an automatic checking
of symbols or footprints while I'm working on it depending on selected
rule set.

At least a possible checking directly within the editors in KiCad. It's
currently a bit uncomfortable and time consuming to check if a symbol is
fulfilling the KLC's rules (or any other rules).

Furthermore I'd appreciate if KiCad would pre ship such rule sets and I
could choose one. And also if I could copy such an existing rule set to
my own settings set and modify it afterwards.

Own rule sets should be addable from a own dedicated folder and also
selectable from and savable within a project.

-- 
Regards
Carsten Schoenert

___
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] [PATCH] Crash Reporter

[Carsten Schoenert]

Hello,

Am 16.04.19 um 23:25 schrieb Mark Roszko:
> Just to throw it out there
> 
> Did you consider at all at using something off the shelf such as
> Breakpad which both Mozilla and Chrome use?
> https://wiki.mozilla.org/Breakpad 
> https://github.com/google/breakpad

this has also some downsides.
The breakpad thing is nice for companies and projects that do provide
ready to use binary packages no matter for Windows, Linux or MacOS
platforms, just because they already know addresses from the used
symbols and functions from the generated binaries. The backtraces are
small and quite really anonymous and will mostly just hold signatures
and hashes.

But for all packages from the various Linux distributions you would need
to know some internals from the build of the binaries and the packages
later. You would also need a possibilities where the package creater
could upload all these data plus a framework as a helper for doing this all.

I've tried to get this all together for the Thunderbird package in
Debian but due the complexity and the amount of work I haven't finished
anything since almost two years.

Not that the breakpad package is bad thing, no it's not! And I haven't
looked into any implementation details from Tom. But for now I wouldn't
hardly focus on this. And there wont be the one and only solution in the
end I guess. But you need to start somewhere.

-- 
Regards
Carsten Schoenert

___
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] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Hello Aimylios,

Am 30.03.19 um 20:42 schrieb Aimylios:
> Hi Carsten,

(no need to address me directly, I'm subscribed to the list)

> your third patch breaks the Fedora nightly builds. This is the error we
> get (see [1] for a full build log):
> 
> FAILED:
> ? tag-missing   :  is not present
> Validation of files failed
> error: Bad exit status from /var/tmp/rpm-tmp.3E6TT2 (%check)
> 
> The reason is that the metadata_license tag is mandatory and must not be
> omitted. It indicates the license for the appdata.xml file itself.
> Please take a look at the AppStream specification for details [2].

agreed, I just wondering why this just happens now. The field of the
metadata_license was added by Wayne on Oct 24 2018, that is not that
long ago. And no one has raised their hands as I posted the patch that
was removing that field. ;-)

> I vote for reverting commit e5de787 [3]. In my opinion, CC-BY-SA-4.0 is
> a perfect choice for this kind of file. If the developers prefer a
> different license, that is fine for me as well.

I'm fine if Wayne wants to revert that patch. Depending on the required
or wanted license.

> But please add back the tag, so that we can continue distributing
> nightly builds for Fedora.
Until this happen I'd simply re-add that tag by a local patch.

-- 
Regards
Carsten Schoenert

___
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] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Am 27.03.19 um 18:09 schrieb Wayne Stambaugh:
> Carsten,
> 
> I'm still getting the following git error when applying patch 1:
> 
> Applying: Adding license information for demo files
> Using index info to reconstruct a base tree...
> error: patch failed: LICENSE.README:15
> error: LICENSE.README: patch does not apply
> error: Did you hand edit your patch?
> It does not apply to blobs recorded in its index.
> Patch failed at 0001 Adding license information for demo files
> hint: Use 'git am --show-current-patch' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> Any ideas?

I first assumed you are on the branch 5.1 and so I tried to apply the
patches and failed, so I tried to find any differences between the two
branches and ... found none.

Going a bit deeper that road I looked at the file LICENSE:README itself,
it has line endings as know from DOS/Windows.

> $ file LICENSE.README
> LICENSE.README: ASCII text, with CRLF line terminators

So I tried 'git am --keep-cr' but this isn't also not working.

If I convert the file into the unix format by dos2unix and commit the
modifications I can apply the the first patch without complains by git.

So I see two options, you ignore the first patch and modify the file by
yourself. The patch is just adding two lines. If you want to safe the
original author you can use the option '--author=' to do so. I do this
quite often.

Or you convert the whole file into the unix line ending format and apply
the patches then on top of that. The converting of the line endings will
mostly destroy the file history, OTOH it's a small file and history is
not really important here.

-- 
Regards
Carsten Schoenert

___
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] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Hello Wayne,

Am 27.03.19 um 16:34 schrieb Wayne Stambaugh:
> Hey Carsten,
> 
> I tried merging your patches and patch 1 does not merge cleanly.  Would
> you please rebase patch 1 so I can get it merged?

rebased and re-added.

-- 
Regards
Carsten Schoenert
From 34bd245a89c2aeecdb5db8814e77417003659762 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Fri, 8 Mar 2019 18:57:14 +0100
Subject: [PATCH 1/3] Adding license information for demo files

The demo files are covered by the CC-BY-SA-4.0 license.
Please note some discussion about this on the developers mailing list:

https://lists.launchpad.net/kicad-developers/msg39174.html
---
 LICENSE.README | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/LICENSE.README b/LICENSE.README
index 8f291c120..34793d27d 100644
--- a/LICENSE.README
+++ b/LICENSE.README
@@ -15,5 +15,7 @@ Licensed under BOOSTv1:
 - libcontext [https://github.com/boostorg/context], sources in common/system/libcontext.cpp
 Licensed under ISC:
 - portions of code in include/geometry/polygon_triangulation.h
+Licensed under CC-BY-SA-4.0:
+- All the demo files provided in demos/*
 Licensed under GPLv3 (or later):
-- All remaining code not listed above
\ No newline at end of file
+- All remaining code not listed above
-- 
2.20.1

>From a02fe585e6b6183e19238c8a6881b09e66856827 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Fri, 8 Mar 2019 19:02:45 +0100
Subject: [PATCH 2/3] Adding license text for CC-BY-SA-4.0 for completeness

As for the other used licenses adding also the license content for the
CC-BY-SA-4.0 license.
---
 LICENSE.CC-BY-SA-4.0 | 255 +++
 1 file changed, 255 insertions(+)
 create mode 100644 LICENSE.CC-BY-SA-4.0

diff --git a/LICENSE.CC-BY-SA-4.0 b/LICENSE.CC-BY-SA-4.0
new file mode 100644
index 0..39ffbb4b0
--- /dev/null
+++ b/LICENSE.CC-BY-SA-4.0
@@ -0,0 +1,255 @@
+Creative Commons Attribution-ShareAlike 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to
+be bound by the terms and conditions of this Creative Commons
+Attribution-ShareAlike 4.0 International Public License ("Public License").
+To the extent this Public License may be interpreted as a contract, You are
+granted the Licensed Rights in consideration of Your acceptance of these
+terms and conditions, and the Licensor grants You such rights in
+consideration of benefits the Licensor receives from making the Licensed
+Material available under these terms and conditions.
+
+Section 1 – Definitions.
+
+a.  Adapted Material means material subject to Copyright and Similar Rights
+that is derived from or based upon the Licensed Material and in which the
+Licensed Material is translated, altered, arranged, transformed, or
+otherwise modified in a manner requiring permission under the Copyright
+and Similar Rights held by the Licensor. For purposes of this Public
+License, where the Licensed Material is a musical work, performance, or
+sound recording, Adapted Material is always produced where the Licensed
+Material is synched in timed relation with a moving image.
+b.  Adapter's License means the license You apply to Your Copyright and
+Similar Rights in Your contributions to Adapted Material in accordance
+with the terms and conditions of this Public License.
+c.  BY-SA Compatible License means a license listed at
+creativecommons.org/compatiblelicenses, approved by Creative Commons as
+essentially the equivalent of this Public License.
+d.  Copyright and Similar Rights means copyright and/or similar rights closely
+related to copyright including, without limitation, performance,
+broadcast, sound recording, and Sui Generis Database Rights, without
+regard to how the rights are labeled or categorized. For purposes of this
+Public License, the rights specified in Section 2(b)(1)-(2) are not
+Copyright and Similar Rights.
+e.  Effective Technological Measures means those measures that, in the absence
+of proper authority, may not be circumvented under laws fulfilling
+obligations under Article 11 of the WIPO Copyright Treaty adopted on
+December 20, 1996, and/or similar international agreements.
+f.  Exceptions and Limitations means fair use, fair dealing, and/or any other
+exception or limitation to Copyright and Similar Rights that applies to
+Your use of the Licensed Material.
+g.  License Elements means the license attributes listed in the name of a
+Creative Commons Public License. The License Elements of this Public
+License are Attribution and ShareAlike.
+h.  Licensed Material means the artistic or literary work, database, or other
+material to which the Licensor applied this Public License.
+i.  Licensed Rights means the rights granted to You subject to the terms and
+conditions of this Public License, which are limited to all Copyright and
+

Re: [Kicad-developers] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Am 08.03.19 um 19:01 schrieb Wayne Stambaugh:
> This makes sense to me.

Great!

I created two patches about this solution so it's also documented.
And I made a third patch which removes the additional key
metadata_license from the appdata.xml file. Feel free to amend the
patches if required.

-- 
Regards
Carsten Schoenert
From 34bd245a89c2aeecdb5db8814e77417003659762 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Fri, 8 Mar 2019 18:57:14 +0100
Subject: [PATCH 1/3] Adding license information for demo files

The demo files are covered by the CC-BY-SA-4.0 license.
Please note some discussion about this on the developers mailing list:

https://lists.launchpad.net/kicad-developers/msg39174.html
---
 LICENSE.README | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/LICENSE.README b/LICENSE.README
index 8f291c120..34793d27d 100644
--- a/LICENSE.README
+++ b/LICENSE.README
@@ -15,5 +15,7 @@ Licensed under BOOSTv1:
 - libcontext [https://github.com/boostorg/context], sources in common/system/libcontext.cpp
 Licensed under ISC:
 - portions of code in include/geometry/polygon_triangulation.h
+Licensed under CC-BY-SA-4.0:
+- All the demo files provided in demos/*
 Licensed under GPLv3 (or later):
-- All remaining code not listed above
\ No newline at end of file
+- All remaining code not listed above
-- 
2.20.1

From a02fe585e6b6183e19238c8a6881b09e66856827 Mon Sep 17 00:00:00 2001
From: Carsten Schoenert 
Date: Fri, 8 Mar 2019 19:02:45 +0100
Subject: [PATCH 2/3] Adding license text for CC-BY-SA-4.0 for completeness

As for the other used licenses adding also the license content for the
CC-BY-SA-4.0 license.
---
 LICENSE.CC-BY-SA-4.0 | 255 +++
 1 file changed, 255 insertions(+)
 create mode 100644 LICENSE.CC-BY-SA-4.0

diff --git a/LICENSE.CC-BY-SA-4.0 b/LICENSE.CC-BY-SA-4.0
new file mode 100644
index 0..39ffbb4b0
--- /dev/null
+++ b/LICENSE.CC-BY-SA-4.0
@@ -0,0 +1,255 @@
+Creative Commons Attribution-ShareAlike 4.0 International Public License
+
+By exercising the Licensed Rights (defined below), You accept and agree to
+be bound by the terms and conditions of this Creative Commons
+Attribution-ShareAlike 4.0 International Public License ("Public License").
+To the extent this Public License may be interpreted as a contract, You are
+granted the Licensed Rights in consideration of Your acceptance of these
+terms and conditions, and the Licensor grants You such rights in
+consideration of benefits the Licensor receives from making the Licensed
+Material available under these terms and conditions.
+
+Section 1 – Definitions.
+
+a.  Adapted Material means material subject to Copyright and Similar Rights
+that is derived from or based upon the Licensed Material and in which the
+Licensed Material is translated, altered, arranged, transformed, or
+otherwise modified in a manner requiring permission under the Copyright
+and Similar Rights held by the Licensor. For purposes of this Public
+License, where the Licensed Material is a musical work, performance, or
+sound recording, Adapted Material is always produced where the Licensed
+Material is synched in timed relation with a moving image.
+b.  Adapter's License means the license You apply to Your Copyright and
+Similar Rights in Your contributions to Adapted Material in accordance
+with the terms and conditions of this Public License.
+c.  BY-SA Compatible License means a license listed at
+creativecommons.org/compatiblelicenses, approved by Creative Commons as
+essentially the equivalent of this Public License.
+d.  Copyright and Similar Rights means copyright and/or similar rights closely
+related to copyright including, without limitation, performance,
+broadcast, sound recording, and Sui Generis Database Rights, without
+regard to how the rights are labeled or categorized. For purposes of this
+Public License, the rights specified in Section 2(b)(1)-(2) are not
+Copyright and Similar Rights.
+e.  Effective Technological Measures means those measures that, in the absence
+of proper authority, may not be circumvented under laws fulfilling
+obligations under Article 11 of the WIPO Copyright Treaty adopted on
+December 20, 1996, and/or similar international agreements.
+f.  Exceptions and Limitations means fair use, fair dealing, and/or any other
+exception or limitation to Copyright and Similar Rights that applies to
+Your use of the Licensed Material.
+g.  License Elements means the license attributes listed in the name of a
+Creative Commons Public License. The License Elements of this Public
+License are Attribution and ShareAlike.
+h.  Licensed Material means the artistic or literary work, database, or other
+material to which the Licensor applied this Public License.
+i.  Licensed Rights means the rights granted to You subject to the terms and
+conditions of this Public L

Re: [Kicad-developers] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Hi *,

Am 27.01.19 um 19:55 schrieb Wayne Stambaugh:

> I suppose I could remove the CC-BY-SA-4.0 metadata license but I'm not
> sure it makes sense to put the demos under the gpl3+ license.  Maybe we
> should add the CC-BY-SA-4.0 license to the demo folder or the main
> folder with a note that the demos fall under the this license.  JP, you
> created most (all?) of the demos.  Do you have any opinion on this?

as nothing did really happen on this I want to poke this topic again.

How to proceed regrading the raised license question by Wayne?

-- 
Regards
Carsten Schoenert

___
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.0-rc2

[Carsten Schoenert]

Am 18.02.19 um 07:40 schrieb Carsten Schoenert:
...
> For me it wasn't and so far I see this also wasn't a problem for the
> other main languages that are well maintained. Chinese, France, Italian
> and German but also Russian are in a very good shape.

I've forgotten to also mention here Japanese! Sorry.

-- 
Regards
Carsten Schoenert

___
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.0-rc2

[Carsten Schoenert]

Am 17.02.19 um 22:27 schrieb Константин Барановский:
> Hi.
> 
> When the strings had been frozen?

Basically with the announcement of 5.1.0-rc1. And later with an
dedicated email from Wayne about asking to start with the string freeze
on 5th of January. Wayne has written he will push the freeze to the
release of 5.1.0-rc1.

https://lists.launchpad.net/kicad-developers/msg38841.html

> I'm one of Russian translators and never could determine the moment of a
> string freeze. I just update the translation in couple of days after a
> sources release.

So far I remember we had always a string freeze stating with the RC1. So
no big deal now.

> I think it would be great to create an issue on github (i18n repo), then
> all translators will be notified of necessery to update the translation.

No. This is maybe useful for the core of the *KiCad* *i18n* team. I'm
probably the only translator for kicad-i18n in German and never get an
info about new opened issues on kicad-i18n and don't want that.

There is a mailing list for translations of the documentation (but
assume the UI is also counting in) and in the past Marco and Nick have
written here an announcement about required action about string
translations. Here you will get more people reached I believe.

> Would our translators please reply if this is going to be an issue
> or should we revert the changes? 
> 
> 
> Yes, it is. Those strings will be maked as "fuzzy" and must be fixed,
> otherwise they will be left untranslated.

For me it wasn't and so far I see this also wasn't a problem for the
other main languages that are well maintained. Chinese, France, Italian
and German but also Russian are in a very good shape. And most of the
people behind these translation will do ongoing improvements right until
the final tagging will happen. For coordination of these sometimes the
mentioned mailing list is used so the tagging of kicad-i18n can be
scheduled. It wasn't a big problem in the past I'd say.

@Wayne
Like Marco has written too, no problem for me about the small additional
happen modifications to the KiCad strings. Keep on working and push RC2
out of the door. :)

-- 
Regards
Carsten Schoenert

___
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] off topic question [updated patch] GAL pixel alignment

[Carsten Schoenert]

Steve,

Am 16.02.19 um 17:50 schrieb Steven A. Falco:
> Will the libraries, translations, and documentation be tagged for the
> rc1, rc2, etc?>
> I'd like to use tagged material for the package builds, rather than
> just picking a random SHA.  Currently, only the source is tagged with
> rc1.

your question is completely off topic here. :-/

Could you please avoid "topic hijacking" in the future?

-- 
Regards
Carsten Schoenert

___
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] Date for 5.1.0-rc1?

[Carsten Schoenert]

Am 11.02.19 um 16:20 schrieb Steven A. Falco:
> I've tried downloading the tars for 5.1.0-rc1, but nothing is there
> yet.  Is there a tentative date for that?>
> The reason I ask is because Fedora 30 is scheduled to branch from
> rawhide on 2019-02-19, and it would be desirable to get 5.1.0-rc1 in
> before the branch.
KiCad 5.1.0-rc1 is already tagged.
You can create your own tarball from a local git tree or use the tagged
version on GitHub e.g.

https://github.com/KiCad/kicad-source-mirror/releases/tag/5.1.0-rc1

The trees for kicad-{doc,i18n} aren't tagged yet for 5.1.0-rc1 so you
need to decide which commit you will use if needed.

For the other parts like the libraries etc. there are also no tags
available.

-- 
Regards
Carsten Schoenert

___
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] environment checking in plugins (Re: 5.1.0-rc1)

[Carsten Schoenert]

Hello Mitja,

Am 10.02.19 um 08:13 schrieb Mitja Nemec:
> As a plugin developer I agree that KiCad is not responsible for third
> party plugins, but as a developer I don't have any sane option to
> detect the parameters of the system the plugin is running on.

and what exactly you are missing?
Sorry but I've seen the behavior of the plugins again and again that
there is no checking of a working condition at all. All plugins I've
seen are just don't do any checks if they can work meaningful.

> If build flags (especially KICAD_SCRIPTING_WX_PYTHON) would be 
> accessible to python, I (or any plugin developer) could read it 
> before trying to import wx module and could show a meaningful error 
> message using tkinter instead.
That's the way to go.
But KICAD_SCRIPTING_WX_PYTHON isn't enough. You will also need to know
which version of python-wxgtk3.0 is used if KICAD_SCRIPTING_WX_PYTHON is
set. Build time information for python-wxgtk3.0 can be found e.g. in
INSTPATH/wx-3.0-gtk{2,3}/wx/build/build_options.py.
On the most of recent Linux distribution versions it will look like
this. OTOH the current stable releases will show here "toolkit=gtk2".

> $ grep WX_CONFIG  
> /usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/build/build_options.py
> WX_CONFIG="/usr/bin/wx-config --toolkit=gtk3 --unicode=yes --version=3.0"

I expect that Kicad Python classes can be expanded easily to provide
some built time information of KiCad if they are missing. What kind of
information is needed is probably to discuss.

If plugins can provide some kind of callback function there KiCad can
detect if the plugin is compatible than the plugin can be displayed
grayed out for example in the UI if they are not compatible. And some
more information like version, author ... if the mouse is hovered over
such an entry.

> Should I raise a bug for this wish?

That would be the best as the noise on the list here is rather high.

-- 
Regards
Carsten Schoenert

___
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] still graphical issues in Eeschema also in GTK+3 builds (Re: 5.1.0-rc1)

[Carsten Schoenert]

This thread is getting offtopic ... better open up a new one.

Am 07.02.19 um 20:24 schrieb Steven A. Falco:> I'm concerned that people
will post bug reports (or just downgrade)
> if they see the display artifacts.  Would it make sense to put up a
> dialog the first time the new version is run, advising users to
> switch their settings if they don't like the appearance?  Or perhaps
> force the settings to "fallback+AA" one time on an upgrade?
I personally find such "suggesting windows" more annoying than helpful.
This whole topic is nothing more than the issues that can probably
happen because of the various know problem with graphic cards and
drivers, and mostly only hit people on Linux based systems. So why
bothering people that are affected by this like Windows users?

Better is a place where users can be pointed to in general. We have such
a place on the main website for KiCad. It might need a bit of update.

http://kicad-pcb.org/help/known-system-related-issues/

For more specific hints, especially in context to the used Linux
distribution this needs to be handled by their maintainers. If really
needed a dedicated information can go to the Help menu in KiCad which
I'd more prefer than pop up windows.

-- 
Regards
Carsten Schoenert

___
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] python3-wxpython4 in Fedore (Re: 5.1.0-rc1)

[Carsten Schoenert]

Am 06.02.19 um 22:59 schrieb Steven A. Falco:

> I tried running a Fedora build with wxGTK3 and that seemed to go ok.
> I then tried enabling KICAD_SCRIPTING_WXPYTHON_PHOENIX, but I'm not
> sure what library KiCad is looking for.  I get this:>
> ModuleNotFoundError: No module named 'wx'
> CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
>   wxPython/Phoenix does not appear to be installed on the system
> 
> I'll try to figure it out, but if anyone has a suggestion of what the
> library package might be called, that would help.

You probably looking for python3-wxpython4 in Fedora, in Debian the
package python3-wxgtk4.0 is required to get wxphoenix working in kicad
builds.

https://groups.google.com/forum/#!topic/wxpython-dev/EvjTb7BjXRI

-- 
Regards
Carsten Schoenert

___
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.0-rc1

[Carsten Schoenert]

Am 06.02.19 um 20:00 schrieb Wayne Stambaugh:
> Any idea the number of unique downloads?  I'm guessing not many users
> install from experimental.

Yes, people need to know that they want to use a version from
experimental, so the base is rather small. But I can't say anything
about the user base that is using the version from testing/unstable
and/or experimental.
Looking at the pocon chart for kicad and kiacd-libraries in detail there
are about 900 installations of the package kicad-libraries that is only
available since version 5.0.0. Given that there are about 3000 kicad
installations recorded than that means that over 60% are using older
versions.

https://qa.debian.org/popcon.php?package=kicad

But popcon only is a bad indicator as it's up to the user to contribute,
we wont see data from people that don't can submit data because of
firewalls etc.
The popcon chart has made some bump after the packages of version 5.0
hit the archive and are currently quite near the all time high.

You would need also to have a look into all the downstreams of Debian,
the biggest is of course Ubuntu. So it's difficult to say how big the
user base on Kicad 5.x on Debian and downstreams really is.

...
> I'm not sure what the issue is with glm and gcc but it has been rather
> annoying.  Hopefully clang wont make any changes that breaks the build.

I can build the current head with clang and also can use the output as
usual. So far I've understand the problem it's "just" because of the C++
standard. I've seen some more warnings (than build with gcc) while build
was running.

-- 
Regards
Carsten Schoenert

___
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.0-rc1

[Carsten Schoenert]

Hi Wayne,

Am 06.02.19 um 17:42 schrieb Wayne Stambaugh:
> Any idea where we stand with wxPhoenix/python3 builds?

the build of KiCad for Debian experimental [1] is build with wxPython4
(aka Phoenix) and Python3 scripting support.

I've got no bug reports about the snapshot versions of KiCad in
experimental about issues in KiCad itself so far, a few days ago GLM
0.9.9.3 was uploaded to unstable and currently kicad is failing to build
from source (FTBFS) and a bug was raised against kicad. I will need to
build now with clang, will adjust this on the next weekend I guess.

Locally I work only with the version from experimental and have also not
seen remarkable issues.

> I'm wondering if we have enough user testing with this configuration
> to feel comfortable enabling it for 5.1.  Do we even have any
> packaged builds with this configuration for users to test?  I haven't
> seen any bug reports directly attributed to this so either it works
> as well as wxPython/python2 or very few users are running it and it
> is not well tested.
Now that 5.1.0-rc1 is tagged the next upload can go to Debian unstable,
so a broader user base will get this version. I'm on the other hand
really excited and impressed that no new issues are opened up against
the kicad package in Debian in the recent past! So people maybe really
be tired about opening issues or there are no issues to open. ;)

[1] https://packages.debian.org/experimental/kicad

-- 
Regards
Carsten Schoenert

___
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.0-rc1

[Carsten Schoenert]

Hello Wayne,

Am 05.02.19 um 19:51 schrieb Wayne Stambaugh:
> Hopefully we wont need an -rc2.

would be really cool!

> Unfortunately, this will break all of the linux distro package manager
> version handling because of our previous policy of tagging ahead for the
> next version.  I apologize up front for the issues this is going to
> cause.  This decision falls squarely on my shoulders.

Experienced package maintainer should be able to handle this.

> The clock is ticking for the library, doc, and translation devs.  I
> would really like to get 5.1.0 released by the end of February.  This
> means the libraries, documentation, and translations would have to be
> tagged for 5.1.0 around 2/23 to give our package devs some time to get
> the packages built and uploaded to the website.

If this date is possible with some days of vary there there is a big
chance 5.1.0 will make it into the Debian Buster release! Something I'd
really appreciate to see because of the GTK+3 support. :-)
Otherwise people would directly need to wait for a backport.

-- 
Regards
Carsten Schoenert

___
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] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Hi Wayne,

Am 27.01.19 um 19:14 schrieb Wayne Stambaugh:
> Carsten,
> 
> The metadata (which I assumed to be defined as libraries, templates, and
> samples but maybe my thinking is incorrect here) license is
> CC-BY-SA-4.0.  What "required parts" are missing that would resolve the
> Debian copyright information?

well, Lintian is "just" a QS tool that tries to be smart. :)

In general Lintian is looking at the whole files, and this is the source
and also in the created packages.

As the libraries are not included in the src:kicad package it can't find
any references to CC-BY-SA-4.0 licensed files in the copyright file and
thus is prints out a warning. "Heh, I've found a mention of some general
CC-BY-SA-4.0 licensed files but I haven't found any it in the copyright
file!" Lintian doesn't know here of any other source packages that might
depend on KiCad.

I can override this warning with a small explaining and pointing what
this line in appdata.xml is intended for. I suggest you or someone else
simply write some lines that KiCad is relaying on other parts (like
libraries) which are licensed as CC-BY-SA-4.0 which I can point to.

I personally would drop that line in appdata.xml and just add this
information and relationship of KiCad to other parts in LICENSE.README.

The demos have no extra license statement so they are covered by the
licenses for KiCad. All other parts like libraries, documentation, l10n
are organized in dedicated trees with also own license information.

-- 
Regards
Carsten Schoenert

___
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] License CC-BY-SA-4.0 used in KiCad

[Carsten Schoenert]

Hi,

in commit 4db550353e the file resources/linux/appdata/kicad.appdata.xml
got modified and some reference to the license CC-BY-SA-4.0 was added.

https://github.com/KiCad/kicad-source-mirror/commit/4db550353e608ac363995cc65d7e9e2251c4ef48

I can't find out which files or parts of the KiCad source are now
affected by this license.

The file LICENSE.README is also not holding any useful information about
this license in relation to the files are published by this license.

The Lintain QS tool in Debian is detecting that appdata.xml is having a
reference to CC-BY-SA-4.0 but can't find the required parts inside the
Debian specific copyright file. And of course not because I will need to
add this information. But what do I need to add?

Wayne, as you have added 4db550353e, do you have some useful notes on this?

-- 
Regards
Carsten Schoenert

___
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] wrong formated string in kicad/common/dialog/dialog_global_lib_table_config.cpp

[Carsten Schoenert]

Am 26.01.19 um 09:30 schrieb jp charras:
> I just fixed this issue (missing l10n identifiers), and also fixed a few
> typos in i18n strings.

Yes, thanks for this quick fix, looks better now.

-- 
Regards
Carsten

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

Re: [Kicad-developers] wrong formated string in kicad/common/dialog/dialog_global_lib_table_config.cpp

[Carsten Schoenert]

Hi again,

one more thing that happen now around these l10n changes I can see is
the missing translation for the substituted strings in the modified
splash dialog window if KiCad is starting with an non existing file
'sym-lib-table' in the local configuration folder of KiCad.

I can see the intention behind these changes, to make the dialog more
consistent for the symbol and footprint library table, but this needs a
bit rework.

I append a screenshot from the GUI dialog windows about to setup the
symbol and footprint library table. The word 'symbol' would needed to be
displayed as the translated German string 'Bauteil'. The current state
is a bit unfortunate.

Or in short, there is some ability needed to make the substituted string
in theses dialogs also make translatable.

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

Re: [Kicad-developers] KiCad Snapshot version with enabled GTK+3 and wxPython4.0 scripting in Debian experimental

[Carsten Schoenert]

Hi Wayne,

Am 15.01.19 um 00:28 schrieb Wayne Stambaugh:
>> I'm a bit supersized that there is no plan to configure the current
>> KiCad development version at least with GTK+3 backend as default given
>> the original plan to eventually have a RC ready before or around Fosdem
>> and 5.1 should support GTK+3 fully.
> 
> Making Phoenix and python 3 the default option will cause problems on
> windows builds because there is no msys package for Phoenix.  The
> Phoenix project in it's infinite wisdom ignores forcing the compiler to
> gcc on windows so it will require a patch to make this work like it did
> in wxPython.

that's a valid point, unfortunately. Agreed. (I'm happy I only need to
work with that professional OS on my dayjob.:-) )

>  I suppose we make this the default on linux.

Yes, I really like to suggest this.

...
> Is it the policy of Debian to specify default options for documentation
> purposes?

No, there is no such rule in Debian about this, it's up to the
maintainers how they organize the package built. But documentation and
readability is a good point why the rules file looks like this.

>  You have a lot of defaults redefined.  I build KiCad on my
> Debian testing box using:
> 
> cmake -DCMAKE_BUILD_TYPE=Debug -DKICAD_SCRIPTING_PYTHON3=ON
> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON ~/src/kicad-trunk/
> 
> All of the other options are enabled by default.

[offtopic]
I have seen some sane projects in the past years that have chosen to
switch there defaults even within a stable release circle, I think it
was Samba that was given me a lot of joy because they not only switched
the behavior of an option but also did have make a difference if this
option was not explicitly written.
[/offtopic]

After some experiences in all the years I enjoy one of the zen [1]
principles of Python here, "Explicit is better than implicit."
A other positive effect is that not only me can see what I want to
archive here.

I'm aware that the KiCad developer know their build environment from
inside and also outside best, I'm not and I also work on some other
projects and do some packaging work. So that's the hopefully simple
reason why we do that kind of configuration of the kicad package.

[1] https://en.wikipedia.org/wiki/Zen_of_Python

-- 
Regards
Carsten Schoenert

___
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] KiCad Snapshot version with enabled GTK+3 and wxPython4.0 scripting in Debian experimental (was Re: 5.1 stable release)

[Carsten Schoenert]

Hello Wayne,

Am 11.01.19 um 21:08 schrieb Wayne Stambaugh:
> I doubt we will default to gtk3+/Phoenix anytime soon but I do think it
> would be a good idea to create a build using this configuration so we
> can get wider testing.  I'm guessing that for the most part, it's only
> devs using this configuration which severely limits the amount of
> testing we have.  Whether or not it would be a good idea to make this
> the default configuration for Debian Buster and later is a another
> thing.  I don't think we have enough good testing information at this
> point to make and educated decision.  I'm opposed to it but my fear is
> if things go sideways, we wont have the manpower to react in a manner
> that wont alienate users.

I'm a bit supersized that there is no plan to configure the current
KiCad development version at least with GTK+3 backend as default given
the original plan to eventually have a RC ready before or around Fosdem
and 5.1 should support GTK+3 fully.

I'm not sure this will scale well to find possible outstanding GTK+3
issues while about 95% of the users are pulling from
http://downloads.kicad-pcb.org or from an PPA. As no one has raised the
hand to your last email I must assume all these resources are currently
build with the default build options which is using GTK+2, but maybe I'm
wrong here.

So anyway, I've done some work based on my plannings and created some
branches for doing a Debian packaging of KiCad snapshots from the master
branch with GTK+3 and wxPython4.0 enabled scripting support for Debian
experimental.

As Debian has started his freeze for Debian 10 (Buster) right on the
last weekend I won't do any uploads of KiCad snapshot versions to Debian
unstable currently and will use experimental instead.

I uploaded a version 5.1~20190114.a0a4e5e+dfsg1-1 some time ago and the
build machine are working on this. Depending on available time slots I
will upload newer versions maybe about every 2-4 weeks.

The current build config can be seen in the git tree on Salsa within the
file debian/rules in the variable DEB_KICAD_CMAKE_OPTS.

https://salsa.debian.org/electronics-team/KiCad/kicad/blob/debian/experimental/debian/rules#L39

I appreciate any suggestions to improve this config!

I've installed kicad with this config and so far it looks really
promising, no problems or issues so far. But I'm not a heavy user and
I'm using no NVidia or Radeon graphic card.

So testers (which are using Debian testing or unstable) are welcome!
I've no plans to do backporting this to stable (Stretch) as this is
mostly impossible due missing GTK+3 related packages.

Note, you need to enable the experimental repo in your sources to be
able to pull the kicad packages. Or you install them manually if you
know what you are doing.

https://buildd.debian.org/status/package.php?p=kicad=experimental
https://packages.debian.org/source/experimental/kicad (It will take some
time to see anything on this link!)

-- 
Regards
Carsten Schoenert

___
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 stable release

[Carsten Schoenert]

Hello Wayne,

I've some further questions regarding the planned version 5.1 and
switching to GTK3+.

Am 17.12.18 um 16:18 schrieb Wayne Stambaugh:
> The other option assuming you have the gtk3 variant of wxwidgets
> installed (if not `sudo apt-get install libwxgtk3.0-gtk3-dev`) you can
> make that your default wxwidgets version by running `sudo
> update-alternatives --config wx-config` and select the appropriate
> version of wx-config.  You should be able to build kicad normally.
> 
> If you want to compile using phoenix and python 3 you need to install
> python-wxgtk4.0.  I seem to remember having to install another package
> to get the dev headers but I don't remember what that was off the top of
> my head.  Once you have the python packages installed you can build
> kicad with -DKICAD_SCRIPTING_PYTHON3=ON and
> -DKICAD_SCRIPTING_WXPYTHON_PHOENIX=ON.
> 
> I've successfully build kicad this way on both Debian testing and Ubuntu
> 18.10.

I was thinking (for some time) about building some random version of the
current master branch, aka devel branch for 5.1, with a later upload to
Debian experimental if things going well. But the main question for
doing this is the question of switching finally to GTK3+/WxPython4 also
by the preparations.

The background for doing a rather unusual upload of a random devel
snapshot of KiCad to experimental is the starting freeze period for the
next Debian release called Buster right on this weekend [1].

Doing a build with WxWidgets backend based on GTK3+ and WxPython4 isn't
a real technical problem I guess. But it makes not really since to do
this if this is contrary to the current plannings for 5.1.

So, what is the current status regarding to the default build options
for the KiCad applications?
I haven't looked really into the CMake files recently, is using GTK3+
WxWidgets already the standard or is this planned soon to do the
modification of the CMake files?
The same question belongs to WxPython4/Phoenix.

Or if switching the default build options hasn't happen yet how useful
would a build with GTK3+/WxPython4 than be?


Given the freeze plan for Buster KiCad 5.1 I see a chance to get this
version into Buster if KiCad 5.1 has entered Testing before 2019-03-12.
That's not to far away. So let's use the time to make things happen if
possible.


[1] https://release.debian.org/buster/freeze_policy.html

-- 
Regards
Carsten Schoenert

___
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] [RFC] Symbol library file format

[Carsten Schoenert]

Hello Thomas,

Am 02.01.19 um 10:39 schrieb Thomas Pointhuber:
> * I do not see anything related to SPICE in this document. I would vote
> to add it including the possibility to embedded spice models
> (BASE64-encoded) into the symbol itself.

I disagree on that.
Please do not mix two different main purposes and add more complexity.

Schematic simulation is a add-on, not a primary key feature of a symbol
format or within Eeeschema.

Including such stuff into a schematic symbol make it harder to maintain
the symbols in along term as you always need to touch the symbol no
matter what peace need a update. But the (new extended) symbol format
can get of course a new field of course for a referenced file to look
at. Like similar done for associated footprints. Add a new environment
variable like SPICE_MODEL_DIR to add a default folder.

Currently it's not clear how a open and free spice working model can
look like, I really suggest to not create a own world for spice models.
Make it modular so work needs to be done more than needed.

I also suggest to get in touch with Holger from the ngspice project
about his thoughts and possible suggestions on this topic.

-- 
Regards
Carsten Schoenert

___
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] MSYS2: downgrade to GLM version 0.9.9.2

[Carsten Schoenert]

Am 18.12.18 um 13:51 schrieb Wayne Stambaugh:
> Hi Cedric,
> 
> Please post a patch to the mailing list.  Create the patch using `git
> format-patch`.  Add [PATCH] to the beginning of the subject line.
> Someone will review your patch and merger it if no changes are required
> or request the appropriate changes required to get it merged.
> 
> I prefer in-line and bottom posting but generally I will following the
> posting style used by the thread.
> 
> Thank you for your interest in contributing to KiCad.

We are living in times where git exists for over decade now, just use
the possibilities. :)

$ git remote add cedric https://github.com/cdwijs/kicad-source-mirror
$ git fetch cedric
...
$ git show 019dec6edacd63237680b0662e720b8dab6f1664

cherry-pick, amend or do whatever is needed.

$ git remote remove cedric

The patch would introduce some whitespace issue and also some mixed
tab/space changes. But nothing that could not be solved by just quickly
amending this.

-- 
Regards
Carsten Schoenert

___
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] kicad-dev-nightly PPA builds for artful outdated?

[Carsten Schoenert]

Hi,

Am 11.12.18 um 20:14 schrieb Matthijs Kooijman:
> If only PPA's would just support building against Debian/stable, that
> would make a lot of stuff easier. Or perhaps I should just move to
> Ubuntu instead...

that would be better than to rely on usable packages from Ubuntu because
of Debian Stable isn't fresh enough and doesn't provide nightly builds
of KiCad. PPA's for Debian could be provided too, it's just a matter
time and resources.

BTW: It's rather simple to build a own KiCad version in Debian Stretch
with additional packages from Backports. That's how I sometimes test if
I need to tweek the build of KiCad for Backports.

-- 
Regards
Carsten Schoenert

___
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 stable release

[Carsten Schoenert]

Hello Wayne,

Am 10.12.18 um 14:04 schrieb Wayne Stambaugh:
> Hey John,
> 
> I can help with the test against gtk3.  I am currently using gtk3 on my
> home system although I have not yet tried to build with gtk3 and
> phoenix.  I'm not sure Debian supports this yet because I believe
> wxwidgets used to build phoenix is 3.1.1 or later where wxwidgets is
> 3.0.4 which would cause run time issues although I could be wrong about
> this.

Debian hasn't a more recent wxWidgets version other than 3.0.4 (source
package wxwidgets3.0 [1]). wxWidgets 3.2.0 would be the next stable
release, but no release date is planed nor announced. Today version
3.1.2 was released [2]. It's "just" a development release.

So any GTK3+ thingy need to be done on the current stable version of
3.0.4 in Debian.

Phoenix (aka wxpython4.0 [3]) is available in Unstable and Testing for
some months in Debian. The package python3-wxgtk4.0 is currently build
depending on libwxgtk3.0-gtk3-0v5 from src:wxWidgets3.0 version 3.0.4.
So no depending on some wxwidgets devel version.

[1] https://tracker.debian.org/pkg/wxwidgets3.0
[2] https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.2
[3] https://tracker.debian.org/pkg/wxpython4.0

-- 
Regards
Carsten Schoenert

___
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