Description of problem: Current kicad in caludron/8 RC is barely usable without hardware acceleration. Pcbnew program shows a warning "Could not use OpenGL, falling back to software rendering" right from the beginning as well as, when I try to switch to 'Modern Toolset' by pressing F11 key. That's half of the problem, the worst part is 3D viewer is not usable at all. When I open 3d viewer window with Alt+3 it shows a transparent window and spams me with "Unknown error" pop ups, so I have to kill pcbnew to regain control. Whilst trying to figure out the cause, I have narrowed down the suspects to a bundled wxWidgets 3.1.5 package. Either wxWidgets v3.1.5 are not playing nice with kicad at all or this is happening because it was compiled without --with-opengl option, which is important according to kicad documentation. Nevertheless, I ended up compiling kicad 5.1.9 and wxWidgets from source. I have used wxWidgets-3.0.5 sources and compiled them with --with-opengl option. Now everything works as it should. Version-Release number of selected component (if applicable): kicad-5.1.9-2.mga8.x86_64 wxgtk3.1-3.1.5-0.git20201230.1.mga8.x86_64 Steps to Reproduce: 1. Install kicad from repo 2. Run pcbnew 3. Press F11 key or Alt+3
Created attachment 12333 [details] inxi -bmG
Created attachment 12334 [details] OpenGL error
Created attachment 12335 [details] 3Dviewer error
Created attachment 12336 [details] Working kicad compiled from sources
Thanks for you report, I'm on it enabling the '--with-opengl' option in wxgtk3.0 and after that rebuilding kicad against it in mga8/Core/Updates_testing repo!
CC: (none) => geiger.david68210
Build in progress, please test when they landed in Core/Updates_testing repo in few hours.
Hmmm! kicad doesn't build with wxgtk 3.0.5 because of python3-wxpython4 which is built with wxgtk 3.1.5: -- Found Phoenix 4.1.1/gtk3 (wxWidgets 3.1.5) CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:218 (message): Could NOT find wxWidgets: Found unsuitable version "3.0.5", but required is at least "3.1.5" how did you succeed to build kicad against wxgtk 3.0.5?
Ah, I disabled python scripting support during configuration step with -DKICAD_SCRIPTING=0 option, since I don't need it. Of course, this shouldn't be disabled for distro package, so I suggest trying to build kicad with wxWidgets 3.1.5 and --with-opengl option for now.
Out of curiosity, I've rebuilt kicad locally against current wxWidgets 3.1.xx git master with --with-opengl option enabled. Well, the OpenGL error has returned. So, kicad doesn't play nicely with new wxWidgets after all.
Created attachment 12337 [details] kicad compiled against current wxWidgets git master with --with-opengl option enabled
Since DavidG is already well embarked on this, assigning it to you. BugSquad cannot do much to help here!
Severity: normal => enhancementAssignee: bugsquad => geiger.david68210
*** Bug 28602 has been marked as a duplicate of this bug. ***
CC: (none) => andrf
CC: (none) => fri
Is there any news on this issue? KiCAD is currently pretty much unusable in Mageia because a lot of things need the OpenGL canvas. And not having the 3D view is a major pain in the backside, making sanity checking things a lot harder.
CC: (none) => jan.ciger
In the mean time, Have you tried if it works better as flatpak? 1) Install flatpak system into Mageia https://wiki.mageia.org/en/Ways_to_install_programs#Flatpak 2) Install KiCAD as flatpak by issuing the command given at https://kicad.org/download/flatpak/ 3) Launch it with flatpak run org.kicad.KiCad I tried just now and do not see that error message. But i have no experience of using the program, so please try and report.
Yes I have tried this weekend and the current flatpak works OK. It used to be broken too (same error message) but it seems it has been updated recently.
Thank you for the confirmation. As I do not remember having seen this when i tried it in Mageia 7, I put it under upgrade issues, pointing to this workaround. https://wiki.mageia.org/en/Mageia_8_Errata#Various_upgrade_issues The impact of the problem is severe enough I regard this as a normal bug - rising it from enhancement request.
Keywords: (none) => IN_ERRATA8Severity: enhancement => normal
Is it possible to report this issue upstream at https://gitlab.com/kicad/code/kicad/-/issues ? To see what is going wrong with wxgtk 3.1.5
Here's one created upstream: https://gitlab.com/kicad/code/kicad/-/issues/8320 Feel free to add something else in there. As a side note, flatpack version that is suggested as workaround for now is built against old wxgtk-3.0.5 too. So yeah, something really went wrong in that kicad-5.1.9 + wxgtk-3.1.5 combo.
Ian McInerney replied: "You must build wxWidgets 3.1.5+ with the --disable-glcanvasegl to use KiCad 5.1.9 with hardware acceleration since we do not support the EGL canvas backend, which is the default in wxWidgets 3.1.5. Support for the EGl backend was added to 5.99 (the upcoming v6 release), and is non-trivial to backport to 5.1.9." Anyone willing to build a testing package?
Build in progress in Core/Updates_testing repo: wxgtk-3.1.5-0.git20201230.1.1.mga8
Hm, other packages depending on wxgtk needs to be tested if something breaks when glcanvasegl goes missing...
Created attachment 12684 [details] Kicad error Installed packages: (source «Core Release») kicad 5.1.9 2.mga8 x86_64 kicad-doc 5.1.9 2.mga8 noarch kicad-i18n 5.1.9 2.mga8 noarch kicad-library 5.1.9 2.mga8 noarch python3-wx-siplib 4.19.24 1.mga8 x86_64 python3-wxpython4 4.1.1 1.mga8 x86_64 (source «Core Updates Testing») lib64wx_gtk3u_aui3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_gl3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_propgrid3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_ribbon3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_richtext3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_stc3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_xrc3.1_5 3.1.5 0.git2020123> x86_64 Kicad shows an error: Failed to load shared library '/usr/bin/_pcbnew.kiface': /usr/bin-_pcbnew.kiface: undefined sybbol: xxxx, version WXU_3.1 See attached screenshot for error details. Looks like 'kicad' package needs a rebuild as well.
I've managed to rebuild kicad-5.1.9 source locally against wxgtk-3.1.5-0.git20201230.1.1.mga8 from testing repo and HW acceleration works now as expected. So, just rebuilding 'kicad' package against changed 'wxgtk' from testing repo should be enough to make it work. On another hand, as Thomas pointed out in comment 21, there's quite a bunch of packages that should be tested and perhaps rebuild against changed 'wxgtk-3.1.5' if these fixes are going to be pushed into Core Updates.
hmmmm! you are right Thomas. This is another wxgtk issue in our stable release that is complicated to manage :( So list of possibility packages that we should take care: codeblocks codelite erlang-wx flamerobin freedv freefilesync guayadeque kicad opencpn opencpn-ais-radar-plugin opencpn-climatology-plugin opencpn-polar-plugin opencpn-squiddio-plugin opencpn-watchdog-plugin opencpn-weather-routing-plugin python3-wxpython4 slade tintii urbanlightscape wxformbuilder wxhexeditor wxmaxima xchm
I think that only packages who use lib64wx_gtk3u_gl3.1_5 can be affected: $ urpmq --whatrequires lib64wx_gtk3u_gl3.1_5 0ad aegisub erlang-wx kicad opencpn opencpn-climatology-plugin opencpn-watchdog-plugin opencpn-weather-routing-plugin python3-wxpython4 slade vbam
kicad now rebuilded against wxgtk-3.1.5-0.git20201230.1.1.mga8 in Core/Updates_testing repo!
Created attachment 12688 [details] Working 3d viewer Installed packages: (source «Core Release») python3-wx-siplib 4.19.24 1.mga8 x86_64 python3-wxpython4 4.1.1 1.mga8 x86_64 (source «Core Updates Testing») kicad 5.1.9 2.1.mga8 x86_64 kicad-doc 5.1.9 2.1.mga8 noarch kicad-i18n 5.1.9 2.1.mga8 noarch kicad-library 5.1.9 2.1.mga8 noarch lib64wx_gtk3u_aui3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_gl3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_propgrid3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_ribbon3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_richtext3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_stc3.1_5 3.1.5 0.git2020123> x86_64 lib64wx_gtk3u_xrc3.1_5 3.1.5 0.git2020123> x86_64 Kicad works as expected, HW acceleration in place as well.
I confirm, the test version works a treat here as well. Thanks a lot for solving this.
Mageia KiCAD seem to be working fine here too now. Thank you guys :) So next step is to update and verify other stuff affected by the wxgtk update.
Assigning to QA, So now we have to be sure that the following packages still work as they should: 0ad aegisub erlang-wx kicad opencpn opencpn-climatology-plugin opencpn-watchdog-plugin opencpn-weather-routing-plugin python3-wxpython4 slade vbam And a list of possibility packages that we should also take care: codeblocks codelite flamerobin freedv freefilesync guayadeque opencpn opencpn-ais-radar-plugin opencpn-polar-plugin opencpn-squiddio-plugin tintii urbanlightscape wxformbuilder wxhexeditor wxmaxima xchm
Assignee: geiger.david68210 => qa-bugs
Advisory: ======================== Updated Kicad and wxgtk3.1 packages fix hardware acceleration missing The updated KiCad and wxgtk3.1 packages fix hardware acceleration missing. The wxWidgets 3.1.5 was build without the --disable-glcanvasegl to use KiCad 5.1.9 with hardware acceleration, since Kicad does not support the EGL canvas backend, which is the default in wxWidgets 3.1.5. Support for the EGl backend will be added the upcoming v6 release, and is non-trivial to backport to 5.1.9. References: https://bugs.mageia.org/show_bug.cgi?id=28352 ======================== Updated packages in 8/core/updates_testing: ======================== kicad-5.1.9-2.1.mga8 kicad-library-5.1.9-2.1.mga8 kicad-doc-5.1.9-2.1.mga8 kicad-i18n-5.1.9-2.1.mga8 lib(64)wx_gtk3u_html3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_xrc3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_baseu_net3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_aui3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_qa3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_core3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_gl3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_adv3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_propgrid3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wxgtku3.1-devel-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_stc3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_media3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_ribbon3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_richtext3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_baseu_xml3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_gtk3u_webview3.1_5-3.1.5-0.git20201230.1.1.mga8 lib(64)wx_baseu3.1_5-3.1.5-0.git20201230.1.1.mga8 wxgtk3.1-3.1.5-0.git20201230.1.1.mga8 from SRPMs: ======================== kicad-5.1.9-2.1.mga8 wxgtk3.1-3.1.5-0.git20201230.1.1.mga8 ======================== For QA: Important remark: see also comment 30.
CC: (none) => ouaurelien
Released May 3: "The 5.1.10 stable version contains critical bug fixes and other minor improvements since the previous release." ( from https://www.kicad.org/blog/2021/05/KiCad-5.1.10-Release/ ) As upstream say critical, i think it is a good idea to consider shipping that in this bug directly. List of fixed bugs: https://gitlab.com/groups/kicad/-/milestones/5 V6 is expected some time this year.
Assignee: qa-bugs => geiger.david68210
Updated wxgtk to 3.1.5 final. SRPM(S) wxgtk-3.1.5-1.mga8 RPM(S) lib(64)wx_baseu3.1_5-3.1.5-1.mga8 lib(64)wx_baseu_net3.1_5-3.1.5-1.mga8 lib(64)wx_baseu_xml3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_adv3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_aui3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_core3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_gl3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_html3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_media3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_propgrid3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_qa3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_ribbon3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_richtext3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_stc3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_webview3.1_5-3.1.5-1.mga8 lib(64)wx_gtk3u_xrc3.1_5-3.1.5-1.mga8 lib(64)wxgtku3.1-devel-3.1.5-1.mga8 wxgtk3.1-3.1.5-1.mga8
Thanks Jani I have pinged QA list for testing
$ urpmq -f kicad kicad-5.1.9-2.mga8.x86_64|kicad-5.1.9-2.1.mga8.x86_64 Was working prior to wxgtk update Now segmentation fault: $ kicad kicad: Symbol `_ZTV5wxPen' has different size in shared object, consider re-linking kicad: Symbol `_ZTV12wxHtmlWindow' has different size in shared object, consider re-linking kicad: Symbol `_ZTV15wxMessageDialog' has different size in shared object, consider re-linking kicad: Symbol `_ZTV14wxBitmapButton' has different size in shared object, consider re-linking kicad: Symbol `_ZTV12wxAuiToolBar' has different size in shared object, consider re-linking kicad: Symbol `_ZTV10wxCheckBox' has different size in shared object, consider re-linking kicad: Symbol `_ZTV9wxControl' has different size in shared object, consider re-linking kicad: Symbol `_ZTV17wxMDIClientWindow' has different size in shared object, consider re-linking kicad: Symbol `_ZTV26wxGenericRichMessageDialog' has different size in shared object, consider re-linking kicad: Symbol `_ZTV12wxButtonBase' has different size in shared object, consider re-linking kicad: Symbol `_ZTV17wxGenericTreeCtrl' has different size in shared object, consider re-linking kicad: Symbol `_ZTV16wxTopLevelWindow' has different size in shared object, consider re-linking kicad: Symbol `_ZTV16wxScrolledWindow' has different size in shared object, consider re-linking kicad: Symbol `_ZTV17wxTextEntryDialog' has different size in shared object, consider re-linking kicad: Symbol `_ZTV11wxDirDialog' has different size in shared object, consider re-linking kicad: Symbol `_ZTV8wxDialog' has different size in shared object, consider re-linking kicad: Symbol `_ZTV7wxPanel' has different size in shared object, consider re-linking kicad: Symbol `_ZTV18wxSashLayoutWindow' has different size in shared object, consider re-linking kicad: Symbol `_ZTV12wxSashWindow' has different size in shared object, consider re-linking kicad: Symbol `_ZTV11wxAnyButton' has different size in shared object, consider re-linking kicad: Symbol `_ZTV10wxTreeCtrl' has different size in shared object, consider re-linking kicad: Symbol `_ZTV8wxButton' has different size in shared object, consider re-linking Segmenteringsfel (minnesutskrift skapad) -------- BTW, KiCAD 6 seem to have some way to go to release, so packaging 5.1.10 would be nice. critical fixes, see comment 32
boincmgr also segfaults with similar errors.
For those testing this wxgtk3.1 upgrade and want to get back: urpmi --media release --downgrade wxgtk3.1 --------- I suggest to split this bug: * Release kicad-5.1.9-2 now And in new bugs: * kicad-5.1.10 update * wxgtk-3.1.5 final
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29291
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29309
* Ping to prepare release kicad-5.1.9-2 as is now - without wxgtk update. * This incompatible wxgtk-3.1.5-1.mga8 is still sitting in updates_testing. What to do? Dependent packages need recompile, how many? And first see if even newer wxgtk version exist and update to that instead? Or skip that? Really, i think wxgtk update should better have been a separate bug to start with. * Package kicad 5.1.10 - per above, in new bug; still currently latest, and have important fixes over 5.1.9
Either drop wxgtk-3.1.5-1.mga8 from core/updates_testing and rebuild all core/updates_testing pkgs using wxgtk: aom kicad python-wxpython4 Or keep wxgtk-3.1.5-1.mga8 and rebuild the following pkgs: 0ad aegisub aom ariamaestosa asc audacity boinc-client codeblocks codelite cwstudio diff-pdf dvdstyler erlang flamerobin freedink-dfarc freedv freefilesync fskbsetting gnudl gnuplot guayadeque kicad mediainfo openbabel opencpn opencpn-ais-radar-plugin opencpn-br24radar-plugin opencpn-celestial-navigation-plugin opencpn-chartdldr-plugin opencpn-climatology-plugin opencpn-iacfleet-plugin opencpn-logbookkonni-plugin opencpn-objsearch-plugin opencpn-polar-plugin opencpn-squiddio-plugin opencpn-statusbar-plugin opencpn-watchdog-plugin opencpn-weatherfax-plugin opencpn-weather-routing-plugin openmsx openyahtzee plplot python-wxpython4 radiotray-ng scorched3d slade spek tintii trustedqsl urbanlightscape vbam veracrypt woeusb wxformbuilder wxgtk wxhexeditor wxmaxima wxsqlite3 wxsvg xchm
CC: (none) => jani.valimaa
Regarding KiCad version update FWIW, Upstream bug https://gitlab.com/kicad/code/kicad/-/issues/8320 resolved with "Building wxWidgets 3.1.5 with the --disable-glcanvasegl and KiCad 5.1.9 afterwards, fixes the issue." But very importantly: Meanwhile, the long anticipated KiCad 6 have been released! https://www.kicad.org/blog/2021/12/KiCad-6.0.0-Release/ "There have been many important changes that make this release a substantial improvement over the 5.x series and a worthwhile upgrade for users on all platforms. There are hundreds of new features and improvements, as well as hundreds of bugs that have been fixed." As our current KiCad 5 package have been broken for quite some time and we have pointed users to fatpak, I see no reason not to go for 6.0.0 right now. ( Alternatively, 5.1.12 got released in november, but it feels just dumb to after long struggle ship an old style version... 6.x have much improvement and enhanced workflow, so it is counter productive to give 5.x to users to learn. (and if they want, we know 5.x works perfectly as flatpak already) ) PS Also make sure the spec/package/etc (regardless of version) info to not contain links to the old site, see https://www.kicad.org/blog/2021/10/Avoid-links-to-former-kicad-domain/ DS
This is a Catch22 situation: * The current kicad problem is fixed by Building wxWidgets 3.1.5 with the --disable-glcanvasegl option, and KiCad 5.1.9 afterwards * but if we do this, it has unknown consequences for a lot of other packages. From comment 19: "Support for the EGl backend was added to 5.99 (the upcoming v6 release)" This implies it should work with wxWidgets v3.1.5 without --disable-glcanvasegl > I see no reason not to go for 6.0.0 right now. @DavidG : what do you think? It looks as if this path would avoid us having to worry about changing wxWidgets 3.1.5 and unknown consequences for other packages.
Source RPM: (none) => kicad-5.1.9-1.mga8.src.rpmCC: (none) => lewyssmith
Using KiCad 6.0.0 with Wayland EGL support would also mean building GLEW with EGL support unless bundled copy of GLEW is used. See "Wayland EGL support" in https://dev-docs.kicad.org/en/build/getting-started/. ATM our GLEW is built without EGL support. SUSE reverted using EGL support in wxWidgets and GLEW because it was causing crashes. https://bugzilla.opensuse.org/show_bug.cgi?id=1189524 https://build.opensuse.org/request/show/913481 https://build.opensuse.org/request/show/913482 Best option would be to provide stable wxWidgets 3.1.5 in core/updates with --disable-glcanvasegl, update KiCad to 6.0.0 without Wayland EGL support and rebuild all other pkgs using wxWidgets. Although it's the hardest way.
Updated kicad 6.0.0 pkgs should be available in core/updates_testing any time soon after kicad-packages3d build is finsihed. SRPMS and RPMS: kicad-6.0.0-1.mga8 kicad-doc-6.0.0-1.mga8 kicad-footprints-6.0.0-1.mga8 kicad-packages3d-6.0.0-1.mga8 kicad-symbols-6.0.0-1.mga8 kicad-templates-6.0.0-1.mga8 Majority of other wxgtk 3.1.5 rebuilds are handled in bug 29848.
Summary: Bundled kicad 5.1.9 fails to enable HW acceleration => Kicad 5.1.9 fails to enable HW acceleration
(In reply to Jani Välimaa from comment #42) > Best option would be to provide stable wxWidgets 3.1.5 in core/updates with > --disable-glcanvasegl Version numbering of this is mind numbing. Current release is: wxgtk-3.1.5-0.git20201230.1.mga8.src.rpm But comment 31 has: wxgtk3.1-3.1.5-0.git20201230.1.1.mga8 and comment 33 wxgtk3.1-3.1.5-1.mga8 Is this last the update with --disable-glcanvasegl ? The one in updates/testing? > Using KiCad 6.0.0 with Wayland EGL support would also mean building GLEW > with EGL support unless bundled copy of GLEW is used. See "Wayland EGL > support" in https://dev-docs.kicad.org/en/build/getting-started/. ATM our > GLEW is built without EGL support. For those to whom it means something (not me), the link says: "Wayland EGL support The KICAD_USE_EGL option switches the OpenGL backend from using X11 bindings to Wayland EGL bindings. This option is only relevant on Linux when running wxWidgets 3.1.5+ with the EGL backend of the wxGLCanvas (which is the default option, but can be disabled in the wxWidgets build). By default, setting KICAD_USE_EGL will use a in-tree version of the GLEW library (that is compiled with the additional flags needed to run on an EGL canvas) staticly linked into KiCad. If the system version of GLEW supports EGL (it must be compiled with the GLEW_EGL flag), then it can be used instead by setting KICAD_USE_BUNDLED_GLEW to OFF." > then update KiCad to 6.0.0 without Wayland EGL support and > rebuild all other pkgs using wxWidgets. Although it's the hardest way. If we did this for kicad 6, why do we still need the frigged wxgtk3? In other words, what has this got to do with the current kicad-5.1.9-2 Comments 26-31 are about the updated & released kicad-5.1.9-2, but with what wxgtk3.1 ? --------------------------------------------------------------------------- For those followers of this bug who have a working kicad, please post the O/P of: $ rpm-q kicad wxgtk3.1 and please suggest whether new bug 29844 is another manifestation of the original incompatability between them ("kicad doesn't play nicely with new wxWidgets" comment 9).
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=29844
Depends on: (none) => 29848
As for newly built kicad 6.0. Installed packages from 8/core/updates_testing: - kicad-6.0.0-1.mga8.x86_64 - kicad-doc-6.0.0-1.mga8.noarch - kicad-footprints-6.0.0-1.mga8.noarch - kicad-symbols-6.0.0-1.mga8.noarch - kicad-templates-6.0.0-1.mga8.noarch - lib64wx_baseu3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_baseu_net3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_baseu_xml3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_aui3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_core3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_gl3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_html3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_propgrid3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_qa3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_ribbon3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_richtext3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_stc3.1_5-3.1.5-1.mga8.x86_64 - lib64wx_gtk3u_xrc3.1_5-3.1.5-1.mga8.x86_64 - python3-wxpython4-4.1.1-1.1.mga8.x86_64 - wxgtk3.1-3.1.5-1.mga8.x86_64 Kicad 6.0 works as expected. I was able to load projects created with previous versions without any problems, 3d viewer works normally as well.
Should this go in backports? Once a user uses KiCad 6.0 and saves their design in the new file format, they can't go back to using an older version. I can't use 6.0 myself, because I need to be able to import designs into Altium Designer, which only supports the old file format. But I've been using my own build of KiCad anyway, because of this bug, so I'll just keep doing so.
CC: (none) => mageia
Good catch Martin. But have our KiCad 5.x ever worked OK in mga8? Both KiCad 5 and 6 Flatpak works (quick test only by me), so that is the workaround.
kicad-5.1.9-1.mga8 worked fine for me for creating schematics, simulating with SPICE, and doing PCB component placement. I used it for 6 months before needing to generate a 3D model and finding this bug. P.S. Thanks to Jani for taking on the job of fixing this. I'm not complaining about having the new version - I only wish I could use it!
OK yes then probably KiCad 6 in backports is better. But new wxgtk (if we proceed that) need new need 5.1 Kicad package. Maybe update that to latest 5.1, 5.1.12, for updates repo? If not too hard.
I can revert to 5.1.x in mga8 if decided, but a help from sysadmins is needed to remove pkgs. Kicad 6.0.0 can be pushed to backports only after wxgtk update situation is settled as updated wxgtk with --disable-glcanvasegl is needed in any case.
Thanks, 6.0.0 to backports when possible would be great :) Preparing to test Kicad 5.1.9: I see a quirk in that it make urpmi and drakrpm pull the doc package version 6.0.0 instead of 5.1.9! $ LC_ALL=C sudo urpmi --test kicad-5.1.9 To satisfy dependencies, the following packages are going to be installed: (test only, installation will not be actually done) Package Version Release Arch (medium "Core Release") kicad 5.1.9 2.mga8 x86_64 kicad-i18n 5.1.9 2.mga8 noarch kicad-library 5.1.9 2.mga8 noarch (medium "Core Updates Testing") kicad-doc 6.0.0 1.mga8 noarch python3-wxpython4 4.1.1 1.1.mga8 x86_64 5.9GB of additional disk space will be used. 630MB of packages will be retrieved. Proceed with the installation of the 5 packages? (Y/n) y ... Installation is possible Same quirk using drakrpm: selecting kicad.5.1.9 selects cod 6.0.0, with the additional quirk there is no way to deselect kicad-doc 6.0.0 even after deselecting everyting else. So i guess there need to be a slight dependency adjustment in kicad 5.1.9 package, and additionally there is a quirk in drakrpm.
As told in wxgtk bug 29848, kicad 5.1.9-2 works with old wxgtk, but not with the new, segfaults. Another packaging quirk: selecting kicad 6.0.0 in drakrpm, do not unselect (uninstall) 5.1.9. Kicad 6.0.0 launches, and i started on a schema and a cirquit board.
Kicad 6.0.0 was removed from core/updates_testing and version reverted to 5.1.x. Latest upstream release 5.1.12 is pushed now to core/updates_testing. Please test when it's available. SRPMS: kicad-5.1.12-1.mga8 RPMS: kicad-5.1.12-1.mga8 kicad-doc-5.1.12-1.mga8 kicad-i18n-5.1.12-1.mga8 kicad-library-5.1.12-1.mga8
(In reply to Jani Välimaa from comment #53) > Kicad 6.0.0 was removed from core/updates_testing I support that version 6 goes to Backports (but Core for Mageia 9), in order to leave 5.1 for current users who cannot upgrade (but will have to for M9). One of those cases where a new version is too big a change for a straight update. Are you willing to put v6 in Backports/testing ? It would be a shame to waste the work you have put into it, and it looks important to offer it to users who want it. The wxgtk3.1 issue is driving me at least (if not others) mad. Can somebody say what changes were/are in versions more recent than the current issued: wxgtk3.1-3.1.5-0 and why? We know that wxgtk3.1-3.1.5-1 works for PlayOnLinux. I believe there is now a wxgtk3.1-3.1.5-2. As far as I know, these versions differ with respect to --with-opengl and --disable-glcanvasegl. Is there more than this? > Latest upstream release 5.1.12 is pushed now to core/updates_testing. Please > test when it's available. This is really good of you, Jani. I will try it once I can make room on my disc. What 'wxgtk3.1' version do you expect it to work with? I currently have 3.1.5-0, but can update to whatever is in updates_testing
Changes in wxgtk since the version in mga8 core/release. * Sun Jul 25 2021 wally <wally> 3.1.5-1.mga8 + Revision: 1737739 - new version 3.1.5 * Wed Apr 28 2021 daviddavid <daviddavid> 3.1.5-0.git20201230.1.1.mga8 + Revision: 1720341 - disable glcanvasegl support for now to allow kicad to work (mga#28352) * https://gitlab.com/kicad/code/kicad/-/issues/8320 So, official upstream 3.1.5 source tarball instead of git snapshot build with --disable-glcanvasegl. Every package in core/updates_testing should have been built against wxgtk-3.1.5-1.mga8 living also in core/udpates_testing. Updated pkgs from core/updates_testing should be used when testing.
Apr 28 18:18:00 2021 UTC (8 months, 1 week ago) by daviddavid - disable glcanvasegl support for now to allow kicad to work Apr 28 18:28:47 2021 UTC (8 months, 1 week ago) by daviddavid SILENT: pass '--with-opengl' by default compile option I do not see Jul 25 2021 wally <wally> 3.1.5-1.mga8 in Cauldron, but may be looking in the wrong place. But I do see that this is the one in core/updates_testing that has been so controversial; and reflects the two options noted above. Jan 3 09:57:53 2022 UTC (6 days, 9 hours ago) by wally - enable wxGLCanvas Wayland/EGL backend Jan 4 17:14:33 2022 UTC (5 days, 1 hour ago) by wally - disable EGL support again So these last two cancel each other out, and never made it to updates_testing. I will try the new kicad in core/updates_testing with both the old & new wxgtk3.1
Please don't confuse yourself with cauldron changes. Both mga8 and cauldron have been living their own lives since mga8 was forked. Every change in cauldron doesn't end to stable release. And wxgtk in mga8 core/updates_testing was pushed already about 8 months ago.
Installed all the kicad packages. I already had wxgtk3.1-3.1.5-1 installed. Opened an existing project and made some changes to the schematic. Ran ERC. Generated a BOM. Generated a PDF plot file. Imported the changes to an existing PCB layout. Checked the new components appeared and could be placed. Checked the 3D viewer worked. Exported a STEP file and checked it could be viewed using FreeCAD. Opened another project and checked that SPICE simulation from within KiCad was working. Will continue using, but looks OK to me. Thanks Jani.
Yes thanks Jani! Very thorough test Martin! Quick test here, mga98-64 Plasma, swedish, nvidia-current, 4K screen kicad 5.1.12-1 main app launches nicely, when clicking to launch i.e shema editor, no problem. (Earlier 5.1.9 with old wxgtk then popped up a message about it can not use OpenGL and fall back to software rendering)
(In reply to Jani Välimaa from comment #57) > Please don't confuse yourself with cauldron changes. Both mga8 and cauldron > have been living their own lives since mga8 was forked. Every change in > cauldron doesn't end to stable release. And wxgtk in mga8 > core/updates_testing was pushed already about 8 months ago. You are right (as usual!). I had lost this difference, must get back into it.
Kicad new version tests OK after installation of packages from bug 29848.
CC: (none) => herman.viaene
With Martin's thorough test comment 58 (big thanks for that), plus Morgan's confirmation comment 59 and Herman's confirmation https://bugs.mageia.org/show_bug.cgi?id=29848#c32 = comment 61 makes this big application tested OK: kicad-5.1.12-1 + wxgtk-3.1.5-1 Big thanks to all concerned; medal to Jani if we gave them!
Whiteboard: (none) => MGA864OK
Celebrations :) BTW, It also depends on wxpython4, (which in turn depends on wxgtk-3.1.5-1)
Depends on: (none) => 29291See Also: https://bugs.mageia.org/show_bug.cgi?id=29291 => (none)
Thanks. I wondered about this, but could not find any reference. The pkg is: python3-wxpython4-4.1.1-1.1
(In reply to Lewis Smith from comment #62) > With Martin's thorough test comment 58 (big thanks for that), plus Morgan's > confirmation comment 59 and Herman's confirmation > https://bugs.mageia.org/show_bug.cgi?id=29848#c32 = comment 61 makes this > big application tested OK: > kicad-5.1.12-1 + wxgtk-3.1.5-1 > Big thanks to all concerned; medal to Jani if we gave them! Whiteboard entry should be MGA8-64-OK rather then MGA864OK so that http://madb.mageia.org/tools/updates and the script used to push updates will recognize it. Fixed.
CC: (none) => davidwhodginsWhiteboard: MGA864OK => MGA8-64-OK
Rusty!
Validating, before it gets away again...
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
KiCAD is OK, but it must not be released together with wxgtk3.1 and wxpython4 in 29291 and 29848 as it do not work without them. KiCAD our users now have works almost OK, but will break from only 29291 and 29848. I am not sure how to concert this, if sysadmins pushing this from testing to updates relies on "Depends on" field? So to be sure for now reverted - just to pause it until all packages in wxgtk bug are ready to release.
Keywords: validated_update => (none)Status comment: (none) => Release with 29291 and 29848CC: sysadmin-bugs => (none)
restoring validation, as we track depends on...
Status comment: Release with 29291 and 29848 => (none)Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Great then :) Sorry for the noise.
Just to clarify, as this bug report is marked as depending on the python3-wxpython and wxgtk bugs, the script that pushes updates will not move the updates associated with this bug until they are ready to be pushed too, even if this bug report's packages would otherwise be ready (ok whiteboard entries, validated, and advisory keywords, and advisory loaded to svn).
Keywords: (none) => advisory
CC: lewyssmith => (none)
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2022-0013.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Script error? This got pushed with two unresolved "depends on"...
Addendum: No script problem, it was operator mistake. Such happens. Quickly solved by finishing all related packages. https://bugs.mageia.org/show_bug.cgi?id=29848#c114 Great work, all involved !
Errata updated.
Blocks: (none) => 29959
Blocks: 29959 => (none)