search

KiCad / fedora-packaging

Fedora packaging for KiCad used for the nightlies and distributed via copr [moved to https://gitlab.com/kicad]
2 stars 7 forks source link

Future packaging of KiCad libraries #7

Closed aimylios closed 6 years ago

aimylios commented 6 years ago

The KiCad suite consists of multiple building blocks:

Fedora currently puts all of this into just two RPMs (e.g., see 4.0.7-3.fc28):

The nightly builds at the @kicad/kicad Copr even provide only a single package for everything (except documentation, which is not included at all).

Considering the enormous size of the libraries (especially the 3D models) a better packaging strategy needs to be found. There is already a proposal on how Debian (and Ubuntu, I think) want to handle this. As some refactoring of this repo is currently going on, I decided to open this issue as a platform to discuss the pros and cons of the different approaches for the nightlies.

Personally, I would like to see the nightly builds not to deviate too much from upstream. This will make it easier for users to switch back and forth. As a first step, I suggest to reintegrate the documentation and thereby close the gap to the stable packages (see PR #6). After that, the quality of the nightlies should be improved (clean up SPEC even more, add OCE, add python scripting). A new packaging scheme would only be the last step for me.

In my personal release builds (source, Copr) I have separated the libraries from the main application and ended up with a collection of six RPMs: kicad, kicad-doc, kicad-footprints, kicad-packages3D, kicad-symbols, kicad-templates But one could go even further and put the demos into a separate package. Or add a meta-package kicad-libraries that just pulls in templates, symbols, footprints and 3D models as a dependency.

The next question would then be whether this shall be handled with a single SPEC file or not. Separate SPECs would make it possible to do selective updates, e.g. ship new footprints without touching applications and other libraries. Admittedly, for the nightlies this is probably not really relevant, as they will provide an up-to-date version of everything every day.

@lkundrak: What are your plans for the stable builds of KiCad 5?

@nickoe, @stevefalco: What do you think?

stevefalco commented 6 years ago

I've already submitted a pull request (PR https://github.com/KiCad/fedora-packaging/pull/5) to create separate packages for the nightlies. This will separate out the symbols, docs, etc.

It will include the documentation, so your PR#6 is not needed. My PR#5 already includes that.

I've also started a conversation with @lkundrak via private email, but that discussion could move here instead. Right now I'm working on getting set up to clone the Fedora kicad project, so I can propose a spec file for the official Fedora kicad 5 builds.

nickoe commented 6 years ago

What are the rules about camelcasing package names? Personally I think it should be all small letters, but maybe this policy is different for rpm based distros? I am thinking about kicad-packages3D vs kicad-packages3d.

I personally think it would be best to get the new packaging scheme with more packages as soon as possible. The task with enabling all the python scripting requires a wxpython compat package (built against gtk2) which should be able to coexist on the system with the normal one. The issue here is the wxversion python module which is not versioned on wxpython classic. You probably know the story.

Are there any issues with OCE at the moment? I think we can just add the depend and enable it?

aimylios commented 6 years ago

@stevefalco: Thanks! I have added a comment to your PR #5, because I think it is not ready for merge yet. It seems to include some changes from my branches that are unrelated to the packaging itself, and I also think there should be some consensus on the strategy before merging anything like this. Do I understand you correctly that you vote for adopting the packaging scheme I am currently using in my personal Copr builds (see above)? What do you think about the demos or an additional meta-package for the libraries?

@nickoe: Good point. The Fedora Package Naming Guidelines strongly recommend to keep package names lower case only (although uppercase letters are not strictly forbidden). It should indeed be kicad-packages3d instead of kicad-packages3D.

Some of the other compile time options can be safely enabled on Fedora:

nickoe commented 6 years ago

@aimylios But does the pcbnew gui look good both when started from kicad and standalone? Usually the GUI elements in the toolbar are not placed correctly when started from kicad. https://bugzilla.redhat.com/show_bug.cgi?id=1519989

Aabout ngspice, why a workaround? I assume you just made your own package. I think you need to push for upstream to also build it as a lib.

aimylios commented 6 years ago

Yes, looks good, I have never observed such problems. But I did leave KICAD_SCRIPTING_WXPYTHON set to OFF, whereas your bug report explicitly mentions building against wxPython (which I do not even have installed). If you want, I can submit a PR this evening to enable this in the nightlies and then we will see if any users start complaining.

The following screenshots have been taken with my personal release build:

Application: kicad
Version: 5.0.0-rc1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.55.1 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.18.0 (+libidn2/2.0.3) libssh2/1.8.0 nghttp2/1.25.0
Platform: Linux 4.15.4-300.fc27.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.64.0
    Curl: 7.55.1
    Compiler: GCC 7.3.1 with C++ ABI 1011
Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=OFF

Pcbnew in standalone mode: pcbnew_standalone

Pcbnew started from KiCad: pcbnew_kicad

About ngspice: The maintainer is currently not willing to include the ngspice shared libraries. See the README.md in my woraround repository for details. My package only ships the shared libraries and pulls in ngspice from the main Fedora repo as a dependency. This is much less invasive than completely substituting the upstream package.

stevefalco commented 6 years ago

Regarding camel-case, I don't know what the standard might be, but it seems to follow upstream. At least I see examples like:

NetworkManager-wifi.x86_64 R-tkWidgets.noarch libXScrnSaver-devel.x86_64

and so on. But if you want it all lower-case, that is easy to do.

nickoe commented 6 years ago

I would just really like to use the same package names as used by the fedora maintainer to cause less confusion for everyone. I am ok with merging the changes to split the package as is, but I would prefer not to rush that before getting a response from the upstream maintainer. I do consider the nightlies unstable and the users of those should be ready to accept disruptions.

stevefalco commented 6 years ago

That is fine. I sent an email to @lkundrak and hopefully we can get him involved as the Fedora maintainer. He said he is travelling, so it might be a little while until he replies.

aimylios commented 6 years ago

The Packaging Guidelines just recommend to use lower case. But as we are introducing a completely new package I would suggest to follow this recommendation and call it kicad-packages3d. All other packages are already lower case only. "Package names should be in lower case and use dashes in preference to underscores. You can take some cues from the name of the upstream tarball, the project name from which this software came, and the name which has been used for this package by other distributions/packagers in the past. You can also request guidance from the upstream developers. Do not just blindly follow those examples, however, as package names should strive to be consistent within Fedora more than consistent between distributions."

I remember having problems to find some packages because the old application installer (I think it was PackageKit) was case-sensitive. I then had to use Koji web search to find out the "correct" name. dnfdragora, in contrast, doesn't care at all about upper/lower case. So this might be less of a problem nowadays.

@stevefalco, you could clone the Fedora KiCad repository and put it on GitHub. We could then have a look at your proposal for the stable SPEC together. Maybe that helps to accelerate the process, and as soon as the stable maintainer approves it it can be implemented in the nightlies. It will most probably take several weeks if not months until stable 5.0.0 is released, and we shouldn't wait that long.

stevefalco commented 6 years ago

On 03/01/2018 05:36 PM, aimylios wrote:

The Packaging Guidelines https://fedoraproject.org/wiki/Packaging:Naming#General_Naming just recommend to use lower case. But as we are introducing a completely new package I would suggest to follow this recommendation and call it kicad-packages3d. All other packages are already lower case only. /"Package names should be in lower case and use dashes in preference to underscores. You can take some cues from the name of the upstream tarball, the project name from which this software came, and the name which has been used for this package by other distributions/packagers in the past. You can also request guidance from the upstream developers. Do not just blindly follow those examples, however, as package names should strive to be consistent within Fedora more than consistent between distributions."/

I remember having problems to find some packages because the old application installer (I think it was PackageKit) was case-sensitive. I then had to use Koji web search to find out the "correct" name. dnfdragora, in contrast, doesn't care at all about upper/lower case. So this might be less of a problem nowadays.

@stevefalco https://github.com/stevefalco, you could clone the Fedora KiCad repository and put it on GitHub. We could then have a look at your proposal for the stable SPEC together. Maybe that helps to accelerate the process, and as soon as the stable maintainer approves it it can be implemented in the nightlies. It will most probably take several weeks if not months until stable 5.0.0 is released, and we shouldn't wait that long.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KiCad/fedora-packaging/issues/7#issuecomment-369755334, or mute the thread https://github.com/notifications/unsubscribe-auth/ACBafIlB457frXXccIOZO7ZISU1FqF9Kks5taHfmgaJpZM4SXfuK.

I created a clone of the official Fedora KiCad repo locally, then tied it into github here: https://github.com/stevefalco/kicad-from-fedoraproject

I pushed three of the branches from my local machine to github: f26, f27, and f28, where f28 is the master, a/k/a rawhide branch. I think that should be sufficient, but if you want other branches pushed, please let me know.

While the spec file and patches are there, none of the actual tar-balls are present, because they are in the Fedora look-aside cache rather than in git. But then again, I don't think we need them.

Steve
aimylios commented 6 years ago

All of the changes I wanted to suggest for the nightly builds have been submitted as part of PR #13.

I've now gone ahead and put together a proposal for a "stable" SPEC file based on the KiCad 4.0.7 upstream package. You can find it here: https://github.com/aimylios/fedora-kicad-packaging-upstream/blob/aimylios/proposal-v5/kicad.spec

I've tried to keep as much of the old file as possible to minimise the diff. I did run a build test to make sure it contains no stupid mistakes, but didn't bother to install or actually use it. Its only purpose is to support this discussion. Anyone who wants to use parts of it should review it very carefully.

The packages are separated in a similar way to what has been announced for Debian with two differences:

Personally, I don't really see the need to have a meta-package for the libraries. Users should be able to decide what to install by themselves or (if in doubt) install everything.

I tend to prefer a separate package for the demos (just because I don't use them). The only reason for me not to implement this is that too many packages might cause more confusion to new users than it helps me to save ~9 MB of disk space. :-)

Please let me know what you think!

stevefalco commented 6 years ago

It sounds fine but I won't be able to review it for a while. We had a major snow storm and power and internet is out.

I'll look at it when we get those services back. Might be a few days...

Steve

On Thu, Mar 8, 2018, 5:51 PM aimylios notifications@github.com wrote:

All of the changes I wanted to suggest for the nightly builds have been submitted as part of PR #13 https://github.com/KiCad/fedora-packaging/pull/13.

I've now gone ahead and put together a proposal for a "stable" SPEC file based on the KiCad 4.0.7 upstream package. You can find it here:

https://github.com/aimylios/fedora-kicad-packaging-upstream/blob/aimylios/proposal-v5/kicad.spec

I've tried to keep as much of the old file as possible to minimise the diff. I did run a build test to make sure it contains no stupid mistakes, but didn't bother to install or actually use it. Its only purpose is to support this discussion. Anyone who wants to use parts of it should review it very carefully.

The packages are separated in a similar way to what has been announced for Debian https://lists.launchpad.net/kicad-developers/msg34000.html with two differences:

  • no meta-package kicad-libraries
  • no package kicad-demos (the demos are shipped as part of the kicad package)

Personally, I don't really see the need to have a meta-package for the libraries. Users should be able to decide what to install by themselves or (if in doubt) install everything.

I tend to prefer a separate package for the demos (just because I don't use them). The only reason for me not to implement this is that too many packages might cause more confusion to new users than it helps me to save ~9 MB of disk space. :-)

Please let me know what you think!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KiCad/fedora-packaging/issues/7#issuecomment-371652493, or mute the thread https://github.com/notifications/unsubscribe-auth/ACBafP6vBOJAZi1oddsTNf3BtH-utEcEks5tcbYAgaJpZM4SXfuK .

nickoe commented 6 years ago

I think it is better to also install the demos, they are useful when people bugreport.

nickoe commented 6 years ago

By the way, the cvpcb part of the package description. Remove it. Cvpcb is not considered a standalone app anymore. It can only be opened from within Eeschema.

aimylios commented 6 years ago

@nickoe If I understand you correctly, you want the demos to be available on all installations? This is how it is currently implemented in my proposal, they are part of the main kicad package and will always be installed to /usr/share/kicad/demos/.

I tried to restrict the changes to the upstream SPEC file to a minimum, so that it is easier to look at the diff and understand what is required to go from 4.0.7 to 5.0.0. But I've now added a comment to remind me of the outdated description and submitted a new description as part of PR #13 for the nightly builds.

nickoe commented 6 years ago

@aimylios Yes, I was replying to your comment in https://github.com/KiCad/fedora-packaging/issues/7#issuecomment-371652493 where I think it is better to keep the demos in the normal kicad package unconditionally.

stevefalco commented 6 years ago

I received an email from @lkundrak (the Fedora maintainer). He cannot connect to github right now. I don't want to put words in his mouth, but my sense is that he would support the idea of having the various distros all use similar packaging layouts, and to have upstream kicad help make sensible packaging recommendations.

I think he would also like kicad to produce official tarballs rather than getting them by distro-specific scripts. Right now Fedora uses the github "archive URL" feature to extract libraries, but official tarballs would be preferred.

I also think he's interested in the idea that the libraries might be broken out into separate source RPMs - basically similar to the separate spec files that @aimylios is already using for private dev builds.

That would let different versions be mixed and matched, but some checks would have to be in place to prevent using new libraries with old binaries that don't support all the features the new libraries might need, like shaped pads.

Again, I hope I'm representing his position correctly, and I further hope that he will be able to join this conversation soon.

stevefalco commented 6 years ago

I have been in contact with @lkundrak, who has added me to the Fedora "packager group" so I can better participate in the Fedora KiCad packaging effort.

I have a fork here:

https://src.fedoraproject.org/fork/stevenfalco/rpms/kicad/tree/master

I have outlined three options, depending on how finely-grained we want the Fedora packaging to be.

Option 1 (two RPMs):

RPM for kicad - all the executables, i18n, libraries, models, templates (4.8 GB) RPM for kicad-doc - all of the documentation (116 MB)

Option 2 (four RPMs, separate out the 3D models because of size):

RPM for kicad-core - all the executables, i18n, libraries, templates (342 MB) RPM for kicad-doc - all of the documentation (116 MB) RPM for 3D models - all of the 3D models (4.5 GB) Meta RPM to pull in all of the above (4.9 GB)

Option 3 (seven RPMs, separate out symbols, footprints, templates, 3D models):

RPM for kicad-core - all the executables, i18n (105 MB) RPM for kicad-doc - all of the documentation (116 MB) RPM for symbols - all of the schematic symbols (21 MB) RPM for footprints - all of the PCB footprints (84 MB) RPM for templates - all of the basic examples and templates (16 MB) RPM for 3D models - all of the 3D models (4.5 GB) Meta RPM to pull in all of the above (4.9 GB)

For my first pull request, I have implemented option 1 (in my "for_pull_1" branch), and I have also implemented option 2 (in my "try_option_2" branch). I haven't implemented option 3 yet.

So far, there has been no decision on which option to implement. My personal preference is for option 1, because it is simpler for new users. There is a scratch koji build of option 1 here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=27357968

Option 2 would be my next choice, because some people may not want to install the large 3D models. There is a scratch koji build of option 2 here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=27446558

Option 3 would be my last choice, because it runs the risk of new users not having any libraries installed, which might frustrate them before they can even get started.

aimylios commented 6 years ago

@stevefalco, thanks for your efforts to bring KiCad 5 to the official Fedora repositories! The 3D models definitely need to be moved to a separate package, so your "option 2" should be considered the minimum solution (although I don't see the need for a meta-package, kicad + kicad-doc + kicad-packages3d is self-explanatory and should not confuse anyone).

Personally, I still prefer a solution similar to what was done in Debian (see here) with separate packages for symbols and footprints as well (similar to your "option 3"). Moving the libraries to a separate SPEC would even be better, as the binaries are rebuilt quite often (e.g. with every boost update), and it does not make any sense to redownload several GB of libraries every couple of weeks when only the binaries have changed.

I looked at the commits in your fork of the packaging repository and would like to see some changes before this gets merged upstream:

stevefalco commented 6 years ago

I'd like to get my current commits merged before queuing up more changes. With 20 or so commits waiting, it has taken us a while to get to this point. @lkundrak has reviewed the changes and I've addressed the individual comments he made. I agree that there is more that could be done, and I am sure we will continue to fine-tune the package.

To your individual points:

I don't feel that it is appropriate for me to get in the middle of some of your recommendations - after all, they are your work, not mine, and I think you are more experienced with some of this stuff than I am. So, I'd like to suggest that you get an account in FAS so you can create your own fork and propose patches directly. That way you can get credit for your work, and there will be no risk that I misunderstand your position on things. Would that be ok with you?

aimylios commented 6 years ago

No worries. Please take everything I say with a grain of salt and feel free to ignore it. To be honest, I do not intend to use the upstream package, as I am very happy with my personal release and nightly builds. There is still some time left until the final release of 5.0, which can be used to make further changes after your version of RC2 has been uploaded.

The main purpose of this bug report is to find a better way to package the KiCad libraries. I would like to see this resolved before the release, as it might not be a good idea to change the packaging scheme in between releases. The nightly builds should then adopt this scheme to make it easier for users to switch back and forth.

stevefalco commented 6 years ago

I agree. People who use the official Fedora packages won't want to do frequent updates - they just want to get their schematic and PCB work done. KiCad developers have different needs. :-)

As you can see from the %build, %install, etc, I've been trying to make the Fedora official packages align as closely as possible with the nightlies, since that minimizes the work for everyone.

I'll keep doing that. Thanks for your comments!

mangelajo commented 6 years ago

Can we leave KICAD_SCRIPTING_WXPYTHON enabled? , that was the reason why I created this packaging in the first place :D

mangelajo commented 6 years ago

By the way, amazing to see activity here related to fedora packaging, good work :D

stevefalco commented 6 years ago

There is a problem with KICAD_SCRIPTING_WXPYTHON - as Fedora has switched from python 2 to python 3, one of the libraries needed for KICAD_SCRIPTING_WXPYTHON is not currently available. You can read more about this issue here:

https://copr.fedorainfracloud.org/coprs/aimylios/kicad-nightly/

As you will see, @aimylios has made a private build of the missing library, and he has included KICAD_SCRIPTING_WXPYTHON in his build at the link shown above.

Therefore, you might want to use his Copr builds. Note that he has also added support for ngspice there - again a needed library is missing from official Fedora.

Hopefully, KiCad will eventually move everything to python 3, at which point we can support KICAD_SCRIPTING_WXPYTHON in the official Fedora builds.

nickoe commented 6 years ago

What is the issue with ngspice? I would like to see it enabled in the kicad copr nightlies.

stevefalco commented 6 years ago

Fedora doesn't provide libngspice. As @aimylios said on his copr page, he built his own library so he could enable ngspice. KiCad could certainly build nightlies with ngspice, either by using the lib he created, or KiCad could fork the lib to avoid depending on the one @aimylios provides.

Again, please look at:

https://copr.fedorainfracloud.org/coprs/aimylios/kicad-nightly/

where he spells out the reasons in more detail.

Note that ngspice would be easy for the nightlies to support, but wxpython would not be easy. That is because of conflicts with the official Fedora. I.e., to use wxpython in KiCad, one has to remove some other things from Fedora, which most people would not find acceptable.

aimylios commented 6 years ago

@mangelajo

Can we leave KICAD_SCRIPTING_WXPYTHON enabled? , that was the reason why I created this packaging in the first place :D

Unfortunately, we can't enable KICAD_SCRIPTING_WXPYTHON because the official wxPython package is built against GTK3. KiCad needs to be built against GTK2, and for some obscure reason the combination of KiCad with GTK2 and wxPython with GTK3 makes the KiCad GUI unusable. Other distributions (e.g., Arch) suffer from the same problem. As @stevefalco already mentioned, I have prepared a custom package of wxPython built against GTK2 that I ship as part of my personal kicad-nightly copr. This is a dirty workaround and not suitable for upstream. In the meantime, I have found a less intrusive way to achieve the same thing, but this would require to change the way how KiCad calls wxPython, which will probably cause issues on other platforms. The only real solution is to port KiCad to GTK3.

@nickoe

What is the issue with ngspice? I would like to see it enabled in the kicad copr nightlies.

Me too, but the maintainer of the Fedora ngspice package refuses to include the shared library (e.g., see RHB 1440904 and 1492481). Version 28 of ngspice has recently been released. I'll try to find out whether it resolves his concerns, maybe we can fix this problem before the KiCad 5.0 release.

mangelajo commented 6 years ago

@aimylios oh, right, I'm remembering that. It'd be great if we can publish your copr in the website (if it's not already published) :) thanks for working on it.

aimylios commented 6 years ago

@mangelajo Until now, it was not "officially" published anywhere. To change this, I just advertised it on the kicad.info forum: https://forum.kicad.info/t/kicad-5-and-nightly-builds-for-fedora-linux/11144 It might be a bit too "advanced" for the average KiCad user. Also, I won't promise to maintain it until the end of days. The KiCad website may thus not be the best place to publish it. @nickoe, any thoughts?

By the way, I noticed that the description of the official KiCad nightly copr still says: This is a nightly built repository for KiCad with wxPython and wxGTK3(gtk2 based) and python scripting enabled. This should be corrected to not confuse new users.

nickoe commented 6 years ago

@aimylios I have updated the description on the copr package.

I don't understand your postualate in your forum post about:

There is currently no easy way to install the KiCad 5 release candidates on Fedora. I therefore decided to set up my own KiCad 5 Copr repository. If you want to give it a try, you can find it here: https://copr.fedorainfracloud.org/coprs/aimylios/kicad-release/

Users can use the KiCad copr. If you think something is missing, please make some proposals for changes via pull requests. Did we miss something from pull request https://github.com/KiCad/fedora-packaging/pull/5 . @stevefalco marked it as closed, so I assumed that you got all the changes you wanted at that time merged.

As I mentioned earlier, I would like to see the same package names used as we discussed earlier that aligns with the debian package, but where the demos are included with the core. And also a libraries meta pacakge. I hope the upstream fedora package will be the same such that it is easy for users to migrate to the stable packges when we finally release.

aimylios commented 6 years ago

@nickoe I don't agree. Nightlies are not release candidates. The whole idea of an RC is to have a specific codebase that is used and tested by many users on various platforms. This makes it easier to identify and reproduce bugs and fix them before the final release. E.g., in the Fedora world, RCs are often packaged for Rawhide (whereas nightly builds are not). It is true, though, that the KiCad developers seem to have a different interpretation. Neither RC1 nor RC2 have been announced on the website, and there is no place where you can download pre-built binaries. In my opinion, this is a shame. There are many users out there who are afraid to install something called "nightly build", but would be happy to try out a "release candidate". I try to fill this gap with my kicad-release copr (which is different to the nightlies in that it is not a debug build, is modular and only gets updated with a new tag RC1/RC2/etc.).

I am happy to propose further changes to the nightlies, but I'd prefer to wait until upstream has decided on a new packaging scheme and then adopt it. As far as I understand, @stevefalco is currently working on that and we will see which of his ideas get accepted by the maintainer. As pointed out before, a solution similar to Debian would be my preference as well.

Maybe this forum post was not a good idea at all. So far it has only caused confusion and attracted people asking about the official nightlies...

stevefalco commented 6 years ago

Indeed I am working with the official Fedora packaging. I've received a second set of comments, and I'm reworking my patch set to comply.

As @aimylios says, RC builds are different from nightlies, and what Fedora publishes is yet again different. For example, one comment I received relates to python2-devel. That may not fly as a build requirement, since it is soon to become obsolete. So, I may have to remove all that stuff to get the package accepted.

nickoe commented 6 years ago

@aimylios and @stevefalco Any updates to this?

  1. After the ngspice release 28 will fedora upstream be able to priovide the lib package?
  2. Is there anything new in the upstream package that needs backporting to these scripts?
  3. Any other outstanding issues that we can put under its own issue?
stevefalco commented 6 years ago

1) I don't think anything is changing regarding ngspice. I downloaded the ngspice-28-2 rpm, and there are no libs in it. Also, I didn't see a separate libngspice rpm.

2) I am in the process of separating out the 3D models as per the request in https://bugzilla.redhat.com/show_bug.cgi?id=1548851. It would be great to converge the spec files. They are fairly close, but I did have to turn off all scripting, because @lkundrak was not comfortable with the python 2 libs. I hope KiCad can move to python 3, so we can add the scripting back in.

3) I'm not aware of any other spec issues. My Fedora builds are crashing when I try to open the 3D view in pcbnew. I need to try with the nightlies to see if it is something unique to my builds or something more generic.

aimylios commented 6 years ago

  1. ngspice has already been updated to version 28 in Fedora 28, but the issue that code model files are different when building the shared library remains. The underlying problem has been resolved upstream (see commit fe8126) and this fix will be part of ngspice 29. @nickoe, I see you have commented bug 1440904 today. I will add a proposal to cherrypick the bugfix and add it to version 28.

  2. The only thing I would like to backport from upstream is to remove the dblatex dependency. I have already prepared a patch to do that and will submit a PR later today. As soon as upstream moves the 3D models into a separate package, the nightly builds should follow. I will prepare a PR for this as well, so that @nickoe can merge it as soon as @stevefalco has made his changes. After that, we can close this issue. A more fine grained package structure will have to wait until upstream is open to accept it. The nightlies should not deviate too much.

  3. I'm not aware of anything else that would merit its own issue. @stevefalco: I did not check your Rawhide build, but the 3D viewer does not cause any problems with the packages from my kicad-release copr.

aimylios commented 6 years ago

Now that the 3D models have their own RPM kicad-packages3d (see PR #18), I consider this issue to be resolved.