Package Details: kicad-git 9.0.0.rc1.r499.gf665760a8e-1

Git Clone URL: https://aur.archlinux.org/kicad-git.git (read-only, click to copy)
Package Base: kicad-git
Description: Electronic schematic and printed circuit board (PCB) design tools
Upstream URL: https://kicad.org/
Licenses: GPL-3.0-or-later
Conflicts: kicad, kicad-bzr
Provides: kicad
Submitter: Chocobo
Maintainer: nickoe
Last Packager: nickoe
Votes: 67
Popularity: 0.000000
First Submitted: 2015-10-08 16:39 (UTC)
Last Updated: 2025-01-07 22:16 (UTC)

Required by (26)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

ILF commented on 2018-05-15 15:45 (UTC)

Was someone successful in building kicad with opencascade (OCC), instead of oce. I, too, would prefer to use opencascade because of freecad. When I try to use OCC, compile fails with a dependency on PTKernel, and it seems the PTKernel module is not part of opencascade since version 6.9.1.

doragasu commented on 2018-05-14 09:06 (UTC)

I do not know why, but several cross compilers fail if you define LD_LIBRARY_PATH.

You can test this e.g. by downloading crosstool-ng and trying to build any toolchain. Unless you unset LD_LIBRARY_PATH, build will fail.

nickoe commented on 2018-05-14 08:04 (UTC)

Yes, you should be able to use OCC instead of OCE, but it is not yet well tested.

I don't understand what you mean with OCE breaking build systems. The prefix location and adding a new location does not break build systems.

doragasu commented on 2018-05-14 08:00 (UTC)

Would it be possible to build this package using opencascade (https://aur.archlinux.org/packages/opencascade/) instead of oce? I do not really know which is the difference between these two packages, but they mostly look like the same thing, and opencascade installs a lot more cleanly.

I have both installed: oce for kicad-git, and opencascade for freecad. If they are the same thing, it would be good getting rid of one.

oce package installs under /opt and messes with LD_LIBRARY_PATH, breaking some build systems (opencascade installs under /usr). So if this can be done with opencascade instead oce, for me it would be a gain.

palmitoxico commented on 2018-04-10 11:18 (UTC)

It works fine after the efa2a13eaa4e8b7090ef978ab5e203ae3c32668c commit. Thanks!

palmitoxico commented on 2018-04-04 14:04 (UTC)

@nickoe I've read them. I just added that I can run without problems if I invoke kicad from build/kicad directly.

nickoe commented on 2018-04-04 12:56 (UTC)

@palmitoxico, this is expected, read the comments.

palmitoxico commented on 2018-04-04 12:47 (UTC)

There is something wrong with the packaging. I can run eeschema and pcbnew with no problems invoking kicad from the build/kicad directory (provided that you create symlinks to _eeschema.kiface and _pcbnew.kiface inside the build/kicad directory), but when running the installed package the pcbnew window doesn't show buttons / widgets and don't resize properly and it prints:

/usr/lib/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py:16629: UserWarning: wxPython/wxWidgets release number mismatch warnings.warn("wxPython/wxWidgets release number mismatch")

After closing pcbnew, a segmentation fault occurs in Kicad.

Also, when running eeschema, trying to insert any component causes it to stop responding.

mbl commented on 2018-04-03 18:25 (UTC)

@orson

I will do that, thanks for your reply.

Sorry for the wrong post.

orson commented on 2018-04-02 15:50 (UTC)

@mbl

I would rather move the discussion to the official bug tracker [1], this place is dedicated to package related discussions.

Can you try removing symbol libraries to see if it helps? Also, do you have wxpython or wxpython-gtk2 installed? If possible, please report it on the bug tracker with the questions answered.

  1. https://bugs.launchpad.net/kicad

mbl commented on 2018-04-02 15:44 (UTC)

Hi,

I have build kicad-git today. Eeschma freezes (for me) if I try to place a new component. Anyone an idea how to debug/fix this?

k3a commented on 2018-03-30 20:01 (UTC) (edited on 2018-04-05 13:36 (UTC) by k3a)

The problem was that even with KICAD_SCRIPTING_WXPYTHON = OFF, src/kicad-git/pcbnew/python/kicad_pyshell/init.py would be loaded and it imports "wx" which is wxWidgets causing the version mismatch problem.

I reported it upstream under https://bugs.launchpad.net/kicad/+bug/1760200 and will be fixed soon. As a hotfix, you can temporarily delete /usr/share/kicad/scripting/kicad_pyshell/init.py. Of course completely disabling scripting also solves it, but it would be disabling too much unnecessarily.

nickoe commented on 2018-03-30 15:52 (UTC)

@k3a, I am not ure where you are going with this. Wxpython scripting is already disabled.

k3a commented on 2018-03-30 12:13 (UTC)

I can confirm that Pcbnew freezes when opened from Kicad. It won't fully initialize UI and attempt to close the window would crash the app.

The core reason seems to be mismatched versions of the wxWidgets (wxgtk) and wxPython. The problem can be resolved by disabling WxPython scripting or ensuring versions match (which may be difficult to achieve long-term):

-DKICAD_SCRIPTING_WXPYTHON=OFF

Not sure how many people are using this part of scripting. KiCad 5 is a very nice improvement over version 4 and I recommend it to everyone! :)

nickoe commented on 2018-03-13 09:03 (UTC)

You write OFF in every line that says SCRIPTING instead of ON.

Llama commented on 2018-03-12 14:31 (UTC)

What does it mean, "Disable scripting completely?"

nickoe commented on 2018-02-23 12:40 (UTC)

Disable scripting completely.

dexterlb commented on 2018-02-23 12:21 (UTC)

Does anyone have an idea how to make kicad start pcbnew correctly, so that we don't need to start it standalone?

nickoe commented on 2018-02-17 15:33 (UTC)

Although pcbnew seems like it is still broken when started from kicad, but it looks ok when started standalone.

nickoe commented on 2018-02-17 15:22 (UTC)

It seems to work fine afterall with only wxpython disabled

greyltc commented on 2018-02-17 13:42 (UTC)

Cool. I think we all hope the gtk2 vs 3 stuff here gets ironed out.

https://aur.archlinux.org/packages/kicad-scripting-git/

nickoe commented on 2018-02-17 13:08 (UTC)

You can just modify the pkgbuild and enable it. But it is beacuse it depends on wxpython built with gtk2. And wxpython-gtk2 can not coexist with the normal wxpython package. So I disabled it to be safe. I am ok with your makeing a specific package which enables scripting, but that is hopefully just temporary.

greyltc commented on 2018-02-17 12:32 (UTC)

I'm sad that scripting is now turned off in this package since this feature is important to me. Shall I fork to a new package kicad-scripting-git?

fredericva commented on 2018-02-02 12:45 (UTC)

@nickoe not by default, and I'm not sure how much effort it would be to split them for concurrent installation.

On my local systems kicad is the only package requiring wxpython, so I can safely use the GTK2 version.

I've also tried kicad-git with -DKICAD_SCRIPTING_WXPYTHON=OFF and the wxpython dependency removed, which works fine (at the expense of wxpython scripting of course, but I don't need it).

nickoe commented on 2018-02-02 12:41 (UTC)

Does the wxpython with gtk3 amd wxpython-gtk2 coexist?

fredericva commented on 2018-02-02 10:51 (UTC)

The latest wxpython version 3.0.2.0-7 breaks the kicad UI since it's now compiled using GTK3 instead of GTK2.

I've added a package wxpython-gtk2 to the AUR which goes back to the previous behaviour. Maybe it's best to list it as dependency instead of wxpython?

The alternative is to disable wxpython scripting suppport for now, similar to how it's done in the stable kicad Arch package.

nickoe commented on 2018-01-31 17:14 (UTC)

The ngspice dependency should be fixed now.

fclad commented on 2018-01-31 16:03 (UTC)

ngspice is needed as a dependency!

greyltc commented on 2018-01-19 08:20 (UTC)

please add ngspice to the dependencies list

nickoe commented on 2018-01-18 20:15 (UTC)

@sirus20x6, done.

sirus20x6 commented on 2018-01-18 19:33 (UTC)

can we get -DKICAD_SCRIPTING_ACTION_MENU option on as well? it adds the external plugin menu entry on pcbnew->tools.

Thanks

doragasu commented on 2017-08-22 15:32 (UTC)

I thing @greyltc suggestion is great, ngspice support is a very important feature.

greyltc commented on 2017-08-22 14:37 (UTC) (edited on 2017-08-22 14:39 (UTC) by greyltc)

Could you please build with the following cmake flags: cmake ../.. -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_INSTALL_LIBDIR=/usr/lib \ -DBUILD_GITHUB_PLUGIN=ON \ -DKICAD_SCRIPTING=ON \ -DKICAD_SPICE=TRUE \ -DKICAD_USE_OCE=TRUE \ -DOCE_DIR="/opt/oce/lib/oce-0.18" \ -DKICAD_SCRIPTING_MODULES=ON \ -DKICAD_SCRIPTING_WXPYTHON=ON \ -DCMAKE_SKIP_RPATH=TRUE \ -DCMAKE_SKIP_INSTALL_RPATH=TRUE and add ngspice to the deps?

argen14 commented on 2017-07-12 21:56 (UTC)

@nickoe I've just tested it, after removing the workaround by @Andy2 I can still see the 3d models. Thanks.

nickoe commented on 2017-07-12 19:22 (UTC)

I have made a fix, please test it.

nickoe commented on 2017-07-11 22:15 (UTC)

It seems that you can debug the plugin by setting the environment variable; WXTRACE=3D_PLUGIN_MANAGER.

argen14 commented on 2017-07-10 22:23 (UTC)

Thanks @Andy2 ! It works with your workaround on my setup. For reference, I am using 'kicad-git' package.

Andy2 commented on 2017-07-10 22:00 (UTC)

I found a workaround for the missing 3D shapes: mkdir -p ~/.kicad/plugins ln -s /usr/lib/kicad/plugins/3d ~/.kicad/plugins/3d The reason this works is, that in /usr/lib/kicad/plugins/3d are three shared objects responsible for rendering the shapes depending on their formats. I straced kicad and had a look what it does and I saw this: stat("/usr/usr/lib/kicad/plugins/3d", 0x7ffdeed2bf70) = -1 ENOENT (No such file or directory) stat("/home/andy/.kicad/plugins/3d", 0x7ffdeed2bf70) = -1 ENOENT (No such file or directory) There is a /usr too much in the search path it tries initially. I don't know why and how it got there. The symlink in your user-directory makes it work temporarily, that's at least a workaround until we figure out why the search path is wrong. Note: I'm using kicad-step-git instead of kicad-git, but that shouldn't play a role.

nickoe commented on 2017-07-09 22:47 (UTC)

You may try to do a clean build and remove the CMAKE_INSTALL_LIBDIR line.

nickoe commented on 2017-07-04 21:29 (UTC)

I can confirm that the 3d models are not rendered with a default build. It works for my normal builds that I install without this pkgbuild. I am not sure what the difference is yet.

argen14 commented on 2017-07-03 16:46 (UTC)

@nickoe Can you give some direction where to look where to fix the 3D viewer problem? It seems to work for you.

doragasu commented on 2017-07-01 15:47 (UTC)

I have also the same problem with 3D models. I cannot get a single one to render, even though KISYSMOD is OK and module paths are OK. I get modules neither in the 3D viewer nor in the pcbnew 3D preview of the footprints. If it works for @nickoe, maybe there is an optional dependency that is missing, or there is some needed configuration steps.

argen14 commented on 2017-06-29 15:24 (UTC) (edited on 2017-06-29 20:57 (UTC) by argen14)

@nickoe I have the same problem of 3D models not rendering. I've upgraded to latest AUR oce 0.18.1-1. (You mentioned you use oce 0.18-2?) Then installed kicad-git. I don't get any errors compiling but when I open the pcb 3d viewer no models come up, either WRL or STEP. Same when I try to select a model, no preview. The paths are correct and libraries installed.

nickoe commented on 2017-06-03 12:36 (UTC)

It works fine for me with aur/oce 0.18-2, also, since you could not see wrl models with a build without OCE... it can't be a problem of OCE. Please reverify that the paths for the model you are testing are correct.

nickoe commented on 2017-06-02 17:46 (UTC)

This discusstion really belongs to the kicad bug tracker. Could you try 1a75d9979f14588f5688e60eb4818599da9e686a in the meantime.

Shino commented on 2017-05-30 18:35 (UTC)

I have the same problem as "liubenyuan". The 3d view does not render any components. Just the PCB. I've double checked the paths to the 3D models. They're correct. Also tried compiling without OCE. Didn't work either. Don't know why it is needed anyways. The AUR version just screws up the LD_LIBRARY_PATH and installs into /opt...