Last stable seems to be from a year ago, though
https://code.launchpad.net/~registry/kicad/stable

Anyway, assigning to maintainer.

Severity: enhancement => normal
CC: (none) => marja11
Component: New RPM package request => RPM Packages
Assignee: bugsquad => mageia

They are freezing right now and will release a new stable soon.
Maybe we should wait and skip the 4029 (2014) release.

BTW : change to the update.sh script is needed :

-PARENT_library=lp:~kicad-lib-committers/kicad/library
+PARENT_library=lp:~kicad-product-committers/kicad/library/

CC: (none) => yann.cantin

For the record :

Build against the latest sources (6035) after updating with the supplied update.sh and tweaking the spec (diff attached).

Only problem : It requires a custom version of boost, retrieved and patched with bzr during kicad compilation, and bzr have to be configured with a name (bzr whoami "bla bla@bla.org").

Kicad 4.0.0 just land in cauldron, please test !

Mageia5 and Kicad (from Caldron sources). Kicad leaves traces in the form of a cross in eeschema. Problems with gtk3.
See:
https://bugs.launchpad.net/kicad/+bug/1461698

I confirm what Milan writes: kicad-4.0.1-4.mga6 from cauldron does have that crosshair cursor trace bug. (In fact i found this bug report page after experiencing the crosshair bug myself, while searching if someone had reported that crosshair bug already).

Anyways, the page linked by Milan explains that this is a WXGTK3 bug that happens when wxWidgets is built against GTK3, as opposed to a wxGTK3 built against GTK2 which (according to that page) is the default. They go on explaining that WXGTK doesn't work correctly with GTK3 and shouldn't be built with GTK3 but with (the default) GTK2.
So it would seem that the place to solve that is the wxgtk package.

=> i filed a bug report for wxgtk:
https://bugs.mageia.org/show_bug.cgi?id=17956

CC: (none) => c934w-xavm493b

i'm having other display/refresh problems as well: the kicad window content isn't properly refreshed when resizing the window and sometimes also fails when moving/zooming the schematic.
probably all due to above mentioned problem with wxgtk3 / lib64wxgtkugl3

in order to check the strong "build wxgtk against gtk2, not gtk3" conveyed by the page linked by Milan, I just built wxgtk3 (using gtk2) and kicad 4.0.2 from source tarballs (and into a prefix dir to keep it separated), and as expected, the above mentioned display problems are all gone, kicad works perfectly.

Sounds great :)
Any chance of getting it into mageia 6 release?

CC: (none) => fri

Oh, need to clean my glasses, 4.0.1 *is* in cauldron :)  

 THANK YOU :)

(just a minor release back, 4.0.2 released in feb)

So we can close this bug fixed or you are working on 4.0.2 first?
Is backport to mga5 planned?

OK i got cofee now and calmed down.
I see the crosshair bug now in packaged 4.0.1.
The drawing window is very slow to rezise.  In KDE plasma, 64 bit.

If there is a package of 4.0.2 to try, just tell me.

update kicad-4.0.1-5.mga6 : i see no crosshair bug in schema :)

kicad-4.0.4 will come in a few hours for Cauldron.

CC: (none) => geiger.david68210

I just installed kicad (intending to migrate from geda to kicad):

Launching pcbnew, I get an error popup: pcbnewInitPythonScripting() failed

Hitting "Details" gives:
    Python error -1 occurred running string `import wxversion: wxversion.select('3.0')`

Console output after a command-line launch of pcbnew is:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/usr/lib64/python2.7/site-packages/wxversion.py", line 152, in select
       raise VersionError("Requested version of wxPython not found")
    wxversion.VersionError: Requested version of wxPython not found

The error goes away if I manually install wxPython - looks like a simple packaging problem - a require for wxPython missing in kicad

Do you want me to file a separate bug for this issue?

CC: (none) => juergen.harms

A separate bug report would be better, but since this bug report had not been marked as RESOLVED FIXED yet, I guess we can continue using it for this issue. It should be easy to fix.

It is like the trains at French railway crossings: once the missing package is loaded, whenever kicad is launched and the pcb editor is started the first time (only the first time after kicad launch), the pcb editor pops up on "findpcbnewInitPythonScripting failed (no problem launching the schema editor); but this has no apparent consequences and kicad can be used.

I have now painfully completed my exercise to get a test project completed (a clone of an old project implemented in geda). Conclusion: as promising the specifications of kicad are, using kicad is still extremely messy and painful. This is not a countradiction to the satisfactory use of kicad at CERN - I imagine that kicad may run well if the usage is precisely along the lines foreseen by the authors and maintainers (elas not well documented) - that does not cover a majority of different use cases. 

Kicad 4.0.7 has been released in March 2017: there is not much sense to invest time to understand and fix the many problems of its 2-year old predecessor. It might nevertheless be a good idea to fix this missing package problem with the purpose to immediately have a usable kicad package pending the upgrade to 4.0.7.

Sorry for the typo at the very end of comment 16 - 4.0.7 should read 4.0.6.

I have now created and intensively tested a local package with 4.0.6. That went very smoothly, installs and runs without problem - but no real progress re solidity of the software. The principal advantage for the user is the availability of new footprints.

Footprints is also an issue for packaging 4.0.6: it contains some new module directories (no problem), but some directories that existed in 4.0.4 have been dropped. That is no problem for an initial install of 4.0.6, but if you do an upgrade from 4.0.4 the dropped packages probably will be referenced in the users .config/kicad/fp-lib-table and trigger error messages when the user launches kicad. Mageia might consider to carry over some of the now dropped packages into 4.0.6 even if they have disappeared from the upstream sources.

It would be nice if 4.0.6 makes it into mga6 release, because of the new/renamed footprints - to avoid that problem in later updates; better it comes in mga5->6 update.

This can and need to be explained rather easily in mga6 errata (link to upstream http://kicad-pcb.org/post/release-4.0.6/).

This is much better than if it suddenly hits user in a later update in mga6!

The Gerber X2 in ver >= 4.0.5 is also a strong point, easing sending the design to production with less pitfalls.

I can do some basic testing if someone packages this. (I have not CADded a board for a couple years...)

> It would be nice if 4.0.6 makes it into mga6 release

I have done most of the necessary work - but since (due to "old-age engineering") I have given up active packaging, somebody has to effectively do the build on the Mageia build system and submit the new package.

My local build uses the spec-file of 4.0.4 with only the evident modifications to cope with the changed names of sources, locally it builds and runs smoothly. What remains to be done is

1. see if building on the Mageia build system works without hickups
2. decide which kicad libraries to include into the Mageia kicad packages:
- the kicad executable is code without library packages
- a large set of library packages comes in a separate source package, specific library packages need to be cherry-picked and individually "sourced" in the spec-file and included in the SOURCE directory.
- my choice in that local build is, essentially, based on what Fedora has done for its package; but since I am perfectly new to kicad, this is arbitrary and requires a careful review by somebody who has has an idea on the need of libraries by the  "average user"
3. I doubt whether more usage testing is needed - I ported 4 pcb quite complex schemas and pcbs from geda to kicad (making probably all the usage errors a newby user is likely to commit).

The SRPM is too big for shipping it around (240 MB). I therefore include as attachments
- my spec-file - the choice of selected library files is directly visible from the list of "Sources" (Source4 and on). I included info on what I have done into the list of comments at the end of the spec file.
- a text file with an ls of the SOURCE directory

Suggestion: Morgan, can you have a look at the list of liberary packages  (Source4 to Source93) and comment on the choice? The work that is left to be done by an active packager should than be no problem.

Created attachment 9332 [details]
Sped file used for my local build

Created attachment 9333 [details]
ls of the SOURCES directory

Thank you for your work Juergen!

As I am a bit rusty on CAD now, only tried KiCad earlier in this thread, and never tried packaging, you cannot count on me, sorry, but I will install, start and play with the packaged version a little bit.

I did a quick look though:

__Spec file:

 § If everything is to be similar, i think Source 5 miss ".pretty" before "/archive/"

 § I suggest we add note in %description section like
"Note: library changes in 4.0.6! see http://kicad-pcb.org/post/release-4.0.6/"

__Sources list:

 § It contain a line:

source_list

sorted into it alphabetically. I believe it should not be there, or maybe at top?


§ I note the four first sources (kicad*) is sorted into it alpabetically but i think that is as is should be?


__Selection of libraries...  scattered notes...


We should have 74xx and 4000Cmos logic gates, PIC, AVR, and other common microcontrollers, EEPROMS,...  DC/DC converters...

I have not grasped where all available are listed, and relation schema symbol-footprint alternatives-3D model...?
Here are some footprint libraries:
https://github.com/KiCad/kicad-library/wiki/Footprint-Libraries
§ Do we have all?
§ I think we should follow upstream and remove deprecated libraries (i.e Air_Coils)


https://github.com/KiCad/kicad-library/wiki/Status-of-the-libraries


I read at https://github.com/KiCad/kicad-library "If you want to download them locally, the library-repos-install.bat and library-repos-install.sh scripts in the KiCad source can do this automatically."
So one idea is to skip libraries and let user download and update manually  anytime to latest versions?


Data for 3D viewer included? https://github.com/KiCad/packages3D

Sorry that it took so much time to reply.

I am afraid that I let myself get carried away with the suggestion to use my local build as the base for submitting an official kicad-4.0.6 package. When I adapted the 4.0.4 package for 4.0.6, I just intuitively did the modifications that were evidently needed, built the new package and ended up with a package that worked to full satifaction - OK for the kind of evaluation I wanted to do, but not enough for producing a coherently conceived upgrade package intended for use by the community.

The principle problem for me was to understand how kicad manages the inclusion of library packages while it is being configured, and how this reflects into the contents of the spec-file - not quite evident to a newby user.

After a lot of digging (thanks to the decent wifi service on German fast trains and a long trip), I start to have a better understanding:

- the original packaging (way back, probably not even done in the framework of Mageia) is rather unfortunate: it introduces the code of kicad libraries twice, once from source2, and once from the individual tar files provided as source4 to source<nn>;

- that is not only redundant and tremendously blows up the the size of the srpm, but is also the origin for incoherencies between (a) the list of packages that upstream set up to compile into kicad, determining the view kicad has of the library packages, and (b) the list of libraries the spec-file explicitely specifies and that are provided in the SOURCES directory;

- furthermore, it invites typos in the enumeration of package files - some of them pointed out in comment #22.

A proper job of packaging kicad would be to drop the long list of packages included as source4 and on and, instead, make the spec-file extract the library files from what is already provided as source2.

Here is what I presently suggest to do (even started doing)

- probably refrain from such a major modification of the kicad spec-file and stick to the clumsy - but working - approach used for past spec-files,

- rather, look at the fp-lib-table.for-pretty file (part of source2) as a master list for the library files to be included as source4 and on, and manually verify and, where necessary, complete the files provided in the SOURCES directory,

- go through the spelling of the specifications of the Source<nn>: declaration in the spec file and eliminate typos - painful and requiring package-by package verification,

This approach deals with what is pointed out in comment #22, gets rid of the need to cherry-pick individual library files; it is simple and straightforward and minimizes the risk of introducing new problems do to complicated extensions to the spec-file.

Some specific replies to comment #22

> I think we should follow upstream and remove deprecated libraries (i.e Air_Coils):
The approach outlined above deals with that, the list of libraries is determined by upstream in the fp-lib-table.for-pretty file (and presently keeps files lik Air_Coils but flags them as candidates for future elimination)

> Data for 3D viewer included? https://github.com/KiCad/packages3D:
Yes, kicad sources take care of that and get the image from the included kicad-libraries.

Comments? (and sorry for all these words - they should help whoever picks this up later)

CC: (none) => juergen.harms

Great you took the time to dissect this :)

Would it be possible to package just the programs and let end user download libraries, if that is not too complicated for end user.  I think i read there is a script for that...?

The idea is to make packaging easier - both now and later, and leave user fully in control of libs.

This is an update of a comment that went in mid-air collision with comment #24

Sorry - the remark on library redundancy was wrong: kicad-library does not contain the xxx.pretty directories - so: the libraries really need to be manually added. The rest of comment #23 remains OK.

Building the kicad-4.0.6 along these lines went more quickly than I had anticipated - I have now an upgrade package where I understand what I did, which locally works without any flaw and where I have confidence that it is solid and ready for uploading. Problem: the 4 rpms total to a size of 200 MB and the source rpm has a size of 240MB; my machines sit behind NAT with limited upload speed.

The best approach is probably if I carry (bicycle online) the RPM to my old lab at Unige - their infrastructure allows to make the SRPM and the RPMs accessible with high bandwidth. That could initially serve for downloading the packages (4 of them) for testing, and later do the transfer for an official build and upload.

I would like to make the rpms and the srpm downloadable as plain files (without keys), avoiding the work to make the stuff look like a repository.

Hooray :) Well done.

You could just upload the spec file here and I'll sync it in the Mageia repo (provided the tarballs in Source# can be retrieved from the Internet easily).

> You could just upload the spec file here and I'll sync it in the Mageia repo (provided the tarballs in Source# can be retrieved from the Internet easily).

Thanks - easier for me, work for you. Note that a build of kicad takes an amazing amount of time to run. And, btw, a nice occasion to say thank you for your calm efficiency role as a deus ex machina.

New attachments:

- the new spec-file (keeping "1" as the release number - not counting my initial local build) - since my builds are local, I did not prepend a revision number to my comment

- a file with the list of urls for downloading the 4 kicad tarballs and 93 libra
ry tars. I did not anticipate that these downloads would be so rapidly needed to be done again and did not make a script - sorry.

Created attachment 9353 [details]
spec-file for kicad-4.6.0.1 (comment #28)

Attachment 9332 is obsolete: 0 => 1

Created attachment 9354 [details]
List of urls to download into kicad-4.0.6.1 SOURCES

Attachment 9333 is obsolete: 0 => 1

> The idea is to make packaging easier - both now and later, and leave user fully in control of libs. (Comment #24)

That is an important issue - manually composing a long list of sources and explicitly downloading the corresponding library packages should not be required, should not be difficult to automate - not only for economy of packager time, but also to reduce the risk of errors (typos, table - package mismatches).

I saw that "Leaving users in control of libs" is foreseen in kicad by creating templates. But I think that this is too hard for the average user, is probably meant for largish projects, to be done by a project manager who has the skills (out of scope in Mageia with the handfull of potential users)

Thanks for the detailed list of URLs :)
Actually the spec should be enough, as we have a handy tool for packaging: `mgarepo sync -d` will download all the necessary sources after substitution of the RPM macros in their URLs, and upload them to Mageia's tarball repo.

kicad-4.0.6-1.mga6 built successfully, thanks a lot Juergen!

BTW, if you want to become a Mageia packager and help maintain this package, I could mentor you.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Quick test OK :)
Many thanks guys!

> BTW, if you want to become a Mageia packager and help maintain this package, I could mentor you.

Thanks for the offer - I had got trained as a maintainer way back by Olivier Faurax. I am now over 80 and have, some time ago, relinquished formal maintainership for the packages I had maintained (efficiency going down, tendency to blunder going up) and stopped using my authorization to upload.

But I still try to occasionally help out. Fundamentally, this is a good decision, but I start to wonder: probably a poorly and un-timely maintained package is still way better than an unmaintained package.

Yes!  This update was a good contribution :)
I hope i too will contribute in 32 years from now, and beyond.