reports with examples that show the issue is sufficient.
If the issue were already closed, then opening a new report and referencing the
old one is preferred.
Seth
On Fri, May 27, 2022 at 10:48 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I recently reopened an issue [1] bec
I recently reopened an issue [1] because I found an old schematic that could be opened
properly by 5.1, but which gave "missing symbol" boxes when opened with 6.0 and
6.99.
However, while the effect is the same, the root cause may be different, so
maybe reopening the bug was the wrong
to fire when it is accessed at any index.
-Ian
On Fri, May 6, 2022 at 7:00 PM Seth Hillbrand mailto:s...@kipro-pcb.com>> wrote:
Hi Steven-
The second bug is locked down. We can't see it without proper access
credentials.
Seth
On Fri, May 6, 2022 at 6:45
There are two SIGABRT bugs reported on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=2079984
https://bugzilla.redhat.com/show_bug.cgi?id=2082394
The first bug was closed because it was not able to be reproduced. The second
one has apparently happened to the reporter several times, but
I'm guessing this has been delayed for bug fixes. I'll keep monitoring this list and the
Zulip "Stable Releases" stream for updates.
Steve
On 4/15/22 06:30 PM, Wayne Stambaugh wrote:
The 6.0 source branch repo has been frozen for the upcoming 6.0.5 stable
release. I plan on tagging
Thanks, Seth. I added that info to the Fedora bug, and if there turns out to
be a way to reproduce it, I'll open a KiCad issue.
Steve
On 3/25/22 11:35 AM, Seth Hillbrand wrote:
Hi Steve-
I think that this is related to https://gitlab.com/kicad/code/kicad/-/issues/7422
A segfault has been reported in Fedora, but the reporter says it is not
reproducible. Below is a link to the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2068449
Please let me know if this is a known issue, or if there is anything further
that we can do about it, given that it is not
On 3/18/22 04:59 PM, Wayne Stambaugh wrote:
The stable version 6.0.4 of KiCad has been released. The packages for most
major platforms should be available. The reason there was no 6.0.3 release is
that we found an issue with 6.0.3 before the official release announcement was
made and had to
On 3/4/22 08:11 AM, Steven A. Falco wrote:
I received a new bug [1] stating that there is a KiCad "failure to build" in
Fedora Rawhide. The bug reporter thinks it is due to a new version of cmake: 3.23.0.
I'm trying to get more information, and I'll try to reproduce the problem.
I received a new bug [1] stating that there is a KiCad "failure to build" in
Fedora Rawhide. The bug reporter thinks it is due to a new version of cmake: 3.23.0.
I'm trying to get more information, and I'll try to reproduce the problem.
When I do, I'll provide a link to the log containing
I'm not sure how many folks on this list care about what follows, but for those
who do...
KiCad has been granted an exception to the Fedora "major update policy". The
exception will only be used in the case of critical bugs / security issues.
Consequently, I'm currently building 6.0.2 for
On 2/16/22 01:52 PM, jp charras wrote:
Le 16/02/2022 à 19:38, Steven A. Falco a écrit :
I found "Fix overflow vulnerability in Gerbview" and possibly "Fix relative return
with nullptr condition". Are there other patches in the series, or are those two the only
ones that
On 2/16/22 01:17 PM, Seth Hillbrand wrote:
Distributions that would like to release a patched version of 5.1, 5.0 or 4.0
can cherry-pick the patch series. They should apply cleanly.
Seth
On Wed, Feb 16, 2022 at 9:16 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
One ad
, but if not, how involved would it be to patch 5.1.12, or perhaps to
spin a 5.1.13 just to fix this issue?
Steve
On 2/16/22 11:49 AM, Steven A. Falco wrote:
Excellent! I'll note that on the Fedora bugs.
Thanks,
Steve
On 2/16/22 09:44 AM, Ian McInerney wrote:
All 4 CVEs were
). There will be another email on the developer list later today
with more details.
-Ian
On Wed, Feb 16, 2022 at 2:18 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I've just received a large number of bugs against KiCad, supposedly due to
CVE-2022-23803, CVE-2022-23804, CVE-2022
I've just received a large number of bugs against KiCad, supposedly due to
CVE-2022-23803, CVE-2022-23804, CVE-2022-23946, CVE-2022-23947.
I don't have time to look into them, but I wanted to make them known. There
are apparently also bugs for this on the gentoo site - here is one:
On 2/7/22 04:46 PM, Wayne Stambaugh wrote:
On 2/7/2022 4:39 PM, Steven A. Falco wrote:
On 2/7/22 03:39 PM, Wayne Stambaugh wrote:
The goal is to release 6.0.2 on Friday, February 11th. If this is an issue for
anyone please let me know. I apologize that it's this late due to the Launch
On 2/7/22 03:39 PM, Wayne Stambaugh wrote:
The goal is to release 6.0.2 on Friday, February 11th. If this is an issue for
anyone please let me know. I apologize that it's this late due to the Launch
mailing list issue.
To confirm, do you mean that all the repos will be tagged with 6.0.2 on
Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I don't know if anyone is currently interested in deprecation warnings with
GCC 12, but I'm seeing messages like:
/builddir/build/BUILD/kicad-6.0.1/include/hashtables.h:36:25: warning:
'template struct std::binary_fu
I don't know if anyone is currently interested in deprecation warnings with GCC
12, but I'm seeing messages like:
/builddir/build/BUILD/kicad-6.0.1/include/hashtables.h:36:25: warning:
'template struct std::binary_function'
is deprecated [-Wdeprecated-declarations]
and
I had created a merge request
https://gitlab.com/kicad/code/kicad/-/merge_requests/1108 for a missing include
file, but I seem to have messed the MR up.
Thus, I closed that one and opened a new MR:
https://gitlab.com/kicad/code/kicad/-/merge_requests/1110
I'd appreciate it if this can be
On 1/19/22 05:18 PM, Eeli Kaikkonen wrote:
On Wed, Jan 19, 2022 at 9:13 PM Steven A. Falco wrote:
It would still be helpful if the doc repo could be tagged at the same point that
everything else is tagged, because every single Fedora package needs a correct version in
its name. For example
On 1/19/22 02:16 PM, Jon Evans wrote:
On Wed, Jan 19, 2022 at 2:12 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
Not to put words in your mouth, but it sounds like the code will be changed
so that when someone clicks on the Help menu, they will get the on-line
v
On 1/19/22 12:45 PM, Jon Evans wrote:
... snip ...
The point I was making is that someone who installs 6.0.1 today should get the
latest V6 branch docs (not the latest master branch) ideally.
Anyone with internet access should be able to get the latest docs, not the docs
at the 6.0.1 tag.
will
correspond to whatever is in the master branch. There is no process at the
moment for nightlies to build from any other branch, although I suppose one
could be added.
Steve
On Wed, Jan 19, 2022 at 11:52 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
Rig
nk we list this in the template as an option but it might be in the
middle of the text instructions.
Seth
On Wed, Jan 19, 2022 at 7:20 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
The Fedora nightly builds succeeded on F34 and F35 last night, but failed
on Rawhide. Rawhide r
Right now, the downstream (official) Fedora builds depend on a single tag for
all the components - source code, libraries, and docs.
I could substitute a SHA for the docs, but I'd have to hard-code the SHA in the
"spec file" that controls the build, the same way the tag is hard-coded in the
The Fedora nightly builds succeeded on F34 and F35 last night, but failed on
Rawhide. Rawhide recently switched to gcc 12, so that might be the cause of
the build failures.
I would write this up as an issue on gitlab, but the template requires version
information, which is not applicable in
On 1/11/22 04:02 PM, Seth Hillbrand wrote:
On Tue, Jan 11, 2022 at 12:48 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
On 1/11/22 03:24 PM, Seth Hillbrand wrote:
> We will not directly disable running in a VM.
>
> Our stance is that if there are
On 1/11/22 03:24 PM, Seth Hillbrand wrote:
We will not directly disable running in a VM.
Our stance is that if there are issues running KiCad in a VM, they should be
reported to the maker of the VM, not KiCad.
I'm going to have to disagree with that stance a little, Seth. The initial bug
On 1/11/22 02:33 PM, pmx wrote:
Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
I don't think the dialog would help any in the situation you are describing
with the artifacts on the screen. It was only shown on first start, so it
wouldn't give the choice in future runs (which would
On 1/11/22 12:31 PM, Ian McInerney wrote:
Hi Steve,
On Tue, Jan 11, 2022 at 3:47 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I've opened https://gitlab.com/kicad/code/kicad/-/issues/10375
<https://gitlab.com/kicad/code/kicad/-/issues/10375>
I'll be addi
on these
issues because fallback works for them, then we'll never fix them.
Seth
On Mon, Jan 10, 2022 at 8:55 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
In the past, when running eeschema or pcbnew for the first time, it would
ask if I wanted to try accelerated gr
In the past, when running eeschema or pcbnew for the first time, it would ask
if I wanted to try accelerated graphics. That no longer seems to be the case -
I don't get that dialog.
I don't know if the dialog was intentionally removed or if it is a bug, but I
think it is an issue either way,
I looked at CMakeLists.txt, and it appears that some of the old 5.x build flags
have been removed, and some new flags have been added.
In particular, the following scripting flags are gone (only
KICAD_SCRIPTING_WXPYTHON remains):
KICAD_SCRIPTING
KICAD_SCRIPTING_ACTION_MENU
I don't expect this will affect anyone here, but just to prevent a possible
blind-side, I wanted to announce that I've disabled building KiCad nightlies
for Fedora 33, as that release has hit end-of-life, and I expect that the
build-roots for F33 will disappear from Copr soon.
Steve
2021 at 3:13 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
On 11/18/21 03:04 PM, Johannes Maibaum wrote:
> Am Donnerstag, dem 18.11.2021 um 14:58 -0500 schrieb Jon Evans:
>> When do you need it by? The docs are nowhere near ready for the
>>
On 11/18/21 03:04 PM, Johannes Maibaum wrote:
Am Donnerstag, dem 18.11.2021 um 14:58 -0500 schrieb Jon Evans:
When do you need it by? The docs are nowhere near ready for the
final release, so if this isn't a hard requirement, I would suggest
not bothering to package the docs for now.
I hope
and won't be tagged
separately.
Seth
On Tue, Nov 16, 2021 at 7:14 AM Seth Hillbrand mailto:s...@kipro-pcb.com>> wrote:
They'll be tagged today
-Seth
On Tue, Nov 16, 2021, 6:27 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
So far, only the code/kicad r
Stambaugh wrote:
Hi Steven,
I don't remember the 3D model or documentation licensing changing. The source
license did change from AGPLv3+ to GPLv3+.
Cheers,
Wayne
On 11/16/21 11:17 AM, Steven A. Falco wrote:
As we get close to releasing 6.x builds, I'd like to make sure our packages
specify
As we get close to releasing 6.x builds, I'd like to make sure our packages
specify the correct license terms.
As of now, for Fedora, here is what we have.
Version 5.1.12:
===
Main package = AGPLv3+
3D Models = CC-BY-SA 4.0 with exception
documentation = GPLv3+ or CC-BY-3.0+
So far, only the code/kicad repo has been tagged for 6.0.0-rc1. In order to
build trial Fedora packages, as you describe below, I'll need the other 6 repos
tagged to match.
I realize that we are very early in this process, but is there a feel for when
the remaining repos will be tagged?
This is a test email - please ignore.
For some reason, the last email I received from launchpad was on 2021-10-08 at the time
the "Launchpad bug tracker closure" email went out.
Thus, I missed the emails about domain name changes, the 5.1.11 release, etc.
I've tried to reset my email address
Thanks, Wayne - that is a clear improvement.
Steve
On 9/14/21 11:13, Wayne Stambaugh wrote:
On 9/14/21 10:05 AM, Steven A. Falco wrote:
Thanks, Jeff. It looks like "make clean" does the right thing - it
removes "include/page_layout_reader_lexer.h", among others.
do that.
But I haven’t a clue how it’s /supposed/ to be. When I have a working build
(even if it’s clunky), I tend to be very hesitant to change /anything/. ;)
On 14 Sep 2021, at 14:27, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
It looks like the problem is that t
9/13/21 17:17, Steven A. Falco wrote:
I'm getting the following error compiling the 5.1 branch:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
In member function ‘void PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
/home/sfalco/src/kicad/kic
I'm getting the following error compiling the 5.1 branch:
/home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
In member function ‘void PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
Thanks for the pointer to the issue, Holger.
I've added a comment describing the root cause in detail, along with a proposed
patch for discussion. The patch would have to be cleaned up a bit, and tested
with Windows and Mac by devs who have access to those build environments. Or a
different
into libngspice.so.0
Btw, I tried using ABSOLUTE rather than REALPATH, but that is too aggressive.
It removed _all_ numbers from the file name, including the MAJOR ABI version.
Steve
On 8/23/21 2:36 PM, Steven A. Falco wrote:
Please look at eeschema/CMakeLists.txt around line 9. We have
0.0 or libngspice.so.0.0.1, which is too
specific for a hard-coded variable.
Why are we using REALPATH? Should that be changed to ABSOLUTE or something
else? I'm not a CMake expert btw, but it seems that REALPATH is not what we
want here.
Steve
On 8/23/21 1:42 PM, Steven A. Falco wro
ICE_DLL_FILE variable to
load the DLL, that is apparently why the more general ldd version is not used.
eeschema/sim/ngspice.cpp: m_dll.Load( NGSPICE_DLL_FILE );
So it seems the fix would be to truncate NGSPICE_DLL_FILE to remove the MAJOR.MINOR
component and just have -DNGSPICE_DLL_FILE=\&qu
explanation of how this works:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
On 8/23/21 10:29 AM, Steven A. Falco wrote:
I just got a bug report for the official Fedora version of KiCAD stating that
ngspice was not found. An attempt to perform a simulation results in KiCAD
crashi
hy the more general ldd version is not used.
eeschema/sim/ngspice.cpp:m_dll.Load( NGSPICE_DLL_FILE );
So it seems the fix would be to truncate NGSPICE_DLL_FILE to remove the MAJOR.MINOR
component and just have -DNGSPICE_DLL_FILE=\"libngspice.so.0\"
Steve
On 8/23/21 10:
I just got a bug report for the official Fedora version of KiCAD stating that
ngspice was not found. An attempt to perform a simulation results in KiCAD
crashing.
The Fedora KiCAD package specifies libngspice.so.0.0.0, but the library has now
bumped to libngspice.so.0.0.1. I would have
the problem. I've attached the patch to python3-wxpython4 in
case it is useful to anyone.
Steve
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1990001
On 7/30/21 11:39 AM, Steven A. Falco wrote:
I decided to file a bug on Fedora
I decided to file a bug on Fedora [1].
I also saw a similar issue on the wxWidgets site and added a comment [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1988466
[2] https://github.com/wxWidgets/Phoenix/issues/1963
Steve
On 7/30/21 10:58 AM, Steven A. Falco wrote:
I just updated
Install Python 3.10 and python-wxpython4 in a Rawhide install
2) Run python -c "import wx;print(wx.version())"
3) See if it errors
My guess is there will be an error in step 2, in which case we need to push it
upstream to wxPython and the Fedora Python maintainers.
-Ian
On Fri, Jul 3
The nightly build failed with an error when building KiCAD for Fedora Rawhide,
when discovering the python interpreter. I haven't tracked down the root cause
yet, but below are the error messages in case anyone has an idea on what can
cause this. Fedora has recently upgraded the python
On 7/6/21 12:04 PM, jp charras wrote:
Le 06/07/2021 à 17:55, Steven A. Falco a écrit :
On 7/6/21 11:30 AM, jp charras wrote:
Le 06/07/2021 à 17:17, Steven A. Falco a écrit :
I've found a project on github [1] that I am interested in, but I have not been
able to open the PCB file correctly
On 7/6/21 11:30 AM, jp charras wrote:
Le 06/07/2021 à 17:17, Steven A. Falco a écrit :
I've found a project on github [1] that I am interested in, but I have not been
able to open the PCB file correctly. It seems that 5.1 is too old to handle
this file, but 5.99 has several issues
I've found a project on github [1] that I am interested in, but I have not been
able to open the PCB file correctly. It seems that 5.1 is too old to handle
this file, but 5.99 has several issues, as described in [2].
It looks like the ground plane is not being processed properly. I also
Congrats Roberto! Glad to have you in a most prominent position!
Steve
On 7/6/21 8:03 AM, Wayne Stambaugh wrote:
I am happy to announce that Roberto Fernandez Bautista has accepted an
invitation to the KiCad lead development team. Roberto has made some
significant contributions to
For fun, I tried running through the README.md file. I hit a slight snag in that the
"flatpak install" prerequisite step failed with:
error: No remote refs found similar to ‘flathub’
It is simple to correct; just run this command prior to the "flatpak install"
step:
flatpak remote-add
I have a related qestion regarding "shebangs" in python code. In a few files
we have #!/usr/bin/env python3, which is great, because it fully specifies which
interpreter to use. For example tools/create_dark_theme.py has this.
In other files, the python version is not specified, and we just
logs..
Error: Login invalid/expired. Please visit https://copr.fedorainfracloud.org/api
<https://copr.fedorainfracloud.org/api> to get or renew your API token.
I gotta update that.
On Thu, 3 Jun 2021 at 22:29, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
The build you
of the docs to test that?
Steve
On 6/3/21 3:26 PM, Nick Østergaard wrote:
@Steven A. Falco <mailto:stevenfa...@gmail.com>
Did you have a look at building the docs for fedora with the other package?
It appears to still BuildRequires: asciidoc when I look in the spec file in
y 30, 2021 at 2:33 PM Steven A. Falco wrote:
I'm able to build the html pages, which is all we need for the nightlies, but I
am not able to build the pdf files. I get an error:
Could NOT find ASCIIDOCTORPDF (missing: ASCIIDOCTORPDF_COMMAND)
It looks like CMakeModules/FindASCIIDOCTO
octor-web-pdf".
Fedora has a package "rubygem-asciidoctor-pdf" which provides a program called
"asciidoctor-pdf".
I don't know if "asciidoctor-pdf" is equivalent to "asciidoctor-web-pdf". If
it is, then perhaps the cmake file should accept eith
as I don't use those distros and am not sure of the right
incantations.
If you can advise what should go into the README I'm happy to update it.
Also, please let me know if you run into any snags building the docs
with the new toolchain.
Best,
Jon
On Sun, May 30, 2021 at 1:49 PM Steven A. Falco
The Fedora nightly build for doc failed because it wanted asciidoctor, but all
it had was asciidoc.
I believe I just need to change the "buildrequires" from:
BuildRequires: asciidoc
to:
BuildRequires: rubygem-asciidoctor
in the kicad-nightly-doc.spec file.
However, I also noticed that
I confirm that Fedora already selects OCC in its build scripts, both for the
official 5.1 builds, and for the 5.99 nightlies. The default can change
without affecting Fedora.
Steve
___
Mailing list: https://launchpad.net/~kicad-developers
The Fedora builds are complete. The one for Rawhide is available today, and
the ones for F32, F33, and F34 are in testing. Those will become generally
available in 3 days, since I don't expect to receive enough positive karma to
shortcut the testing interval.
Steve
On 5/3/21 5:12
Thanks Seth - Fedora builds are underway.
Steve
On 4/27/21 11:25 AM, Seth Hillbrand wrote:
Docs and i18n have been tagged.
-Seth
On Tue, Apr 27, 2021 at 7:05 AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
+1
I will need doc and i18n to start the Fedora
+1
I will need doc and i18n to start the Fedora build.
Steve
On 4/27/21 8:59 AM, Jean-Samuel Reynaud wrote:
Hi,
Same with kicad-i18n...
Le 27/04/2021 à 14:35, Christoph Moench-Tegeder a écrit :
Hi,
## Wayne Stambaugh (stambau...@gmail.com):
I just pushed the stable release tag
On 3/11/21 8:43 AM, Jon Evans wrote:
Hi all,
As of 18037e2f, a new data file is generated during build that contains image
resources for KiCad.
This file should be installed to ${KICAD_DATA}/resources/images.tar.gz (So,
something like /usr/share/kicad/resources/images.tar.gz on Linux).
On 2/12/21 8:01 AM, Holger Vogt wrote:
Steven,
the info from Mamuro:
Hello:
I've pushed ngspice-34-2.fc35 / .fc34 with relevant changes.
Regards,
Mamoru
So please try again.
The fix is good, and I've closed the Fedora bug.
Thanks,
Steve
On 2/12/21 8:01 AM, Holger Vogt wrote:
Steven,
the info from Mamuro:
Hello:
I've pushed ngspice-34-2.fc35 / .fc34 with relevant changes.
Regards,
Mamoru
So please try again.
Thanks! I'll do that now.
Steve
___
Mailing list:
There is a new bug [1] that mentions that KiCAD fails to build in Fedora
rawhide.
The failure message is in the eeschema link step:
/usr/bin/g++ -Wall -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2
can
give you a better answer if this is not satisfactory.
Cheers,
Wayne
On 2/7/21 10:50 AM, Steven A. Falco wrote:
I received a bug report [1] that points out that the libraries on github
contain symbols that are not present in the official gitlab
repositories. The example cited is that [2] has
AM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I received a bug report [1] that points out that the libraries on github
contain symbols that are not present in the official gitlab repositories. The
example cited is that [2] has PCIexpress symbols, but [3], in the 5.1.9 tag,
I received a bug report [1] that points out that the libraries on github
contain symbols that are not present in the official gitlab repositories. The
example cited is that [2] has PCIexpress symbols, but [3], in the 5.1.9 tag,
does not. ([3] does have PCIe on master, but that doesn't help
We have the same problem with Fedora 32 because it also doesn't have the needed
ITS file.
I believe Ian is looking into a solution.
Steve
On 1/21/21 11:40 AM, Jean-Samuel Reynaud wrote:
Dear Ian,
Since this update some build fail on ubuntu. In fact there is
translation of some XML
You are correct, Nick. No changes are needed. The "make install" step copies
the files from linux/launchers into share/applications and the spec file picks them up
from there.
Steve
On 1/20/21 3:22 PM, Steven A. Falco wrote:
The kicad.spec file for Fedora runs desktop-fi
The kicad.spec file for Fedora runs desktop-file-install on the desktop files.
It will likely have to change. I'm running a test build now. Here is the
relevant code from the spec file:
# Desktop integration
for desktopfile in %{buildroot}%{_datadir}/applications/*.desktop ; do
On 12/23/20 9:36 AM, Wayne Stambaugh wrote:
On 12/23/20 5:20 AM, Carsten Schoenert wrote:
Hell Nick,
Am 23.12.20 um 10:07 schrieb Nick Østergaard:
Hi Carsten
This is a balancing act. Quite some time ago we decided that we should
make the release _announcement_ (on the website) when we have
On 12/22/20 3:14 PM, Wayne Stambaugh wrote:
5.1.9 has been tagged for release. Please tag the library, doc, and
translation repos for release. I don't think we have much in the way of
changes there so is a week to get these repos tagged and another week to
get packages built for a January 5th
The Fedora builds have completed:
Rawhide - in production repo now
F33 - in testing repo now - will move to production repo in 3 days
F32 - in testing repo now - will move to production repo in 7 days
F31 - in testing repo now - will move to production repo in 7 days
Steve
On 9/28/20
I've been chasing a build failure on the nightlies for Fedora Rawhide whereby
wxGTK3-devel is claimed to be missing, even though it is clearly installed.
This bug explains what is going on:
https://bugzilla.redhat.com/show_bug.cgi?id=1869030
Fixes for the bug are in progress, but there is
On 8/3/20 2:47 PM, Wayne Stambaugh wrote:
On 8/3/20 2:42 PM, Steven A. Falco wrote:
On 8/3/20 2:37 PM, Wayne Stambaugh wrote:
On 8/3/20 2:01 PM, Carsten Schoenert wrote:
Hello Ian,
Am 03.08.20 um 19:39 schrieb Ian McInerney:
I have now updated this so that we bundle the lemon parser code
On 8/3/20 2:37 PM, Wayne Stambaugh wrote:
On 8/3/20 2:01 PM, Carsten Schoenert wrote:
Hello Ian,
Am 03.08.20 um 19:39 schrieb Ian McInerney:
I have now updated this so that we bundle the lemon parser code inside
thirdparty and build it for ourselves (it is only 1 main c file that
was released
For Fedora, it should just be a one-liner to add lemon to the spec file:
BuildRequires: lemon
I'm running a test now, and I'll add it to the nightlies if it passes.
Steve
On 8/1/20 6:21 PM, Ian McInerney wrote:
No, it isn't a build error that is causing it. If you look at the status
Thanks Ian. Will do.
Steve
On 7/30/20 4:13 PM, Ian McInerney wrote:
You need to upgrade to GCC 10.2 to get rid of them - it was a bug with GCC. I
think 10.2 has landed in the Fedora stable repos now.
-Ian
On Thu, Jul 30, 2020 at 9:10 PM Steven A. Falco mailto:stevenfa...@gmail.com
On 7/20/20 8:28 PM, Steven A. Falco wrote:
On 7/20/20 6:01 PM, Ian McInerney wrote:
You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
It does look like it is that easy. I should have a build in another hour or
so.
On 7/20/20 6:01 PM, Ian McInerney wrote:
You should be able to switch the macros:
%make -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
It does look like it is that easy. I should have a build in another hour or
so. Then I'll load it into a VM and test. If that works
On 7/20/20 6:01 PM, Ian McInerney wrote:
You should be able to switch the macros:
%cmake -> %cmake
%make_build -> %cmake_build
%make_install -> %cmake_install
Then the builds and install will automatically use the proper out of tree
directory. See the change proposal page for more details:
On 7/20/20 5:37 PM, Seth Hillbrand wrote:
Hi Steve-
This looks like a build setup issue, not in our CMake code. We can build out
of tree (in fact, we really prefer it) right now. From the log, the broken
command is
/usr/bin/cmake -S . -B x86_64-redhat-linux-gnu
On 7/20/20 5:34 PM, Nick Østergaard wrote:
What does this mean if I want to test this locally?
Should I do the following or are there other options enforced in cmake?
git clone ...kicad...
mkdir build_outside_of_kicad
cd build_outside_of_kicad
cmake ...kicad...
To test locally, I use our
Fedora recently made a change to their cmake macros, to force packages to build "out
of tree". The developers responsible for this change plan to go through and fix up
the thousand or so packages that may break as a result, so they should eventually fix the
official downstream KiCAD package.
at 4:22 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I pushed a change to my KiCad code repo to add python 3.9 as a supported
version, because Fedora is actively rebuilding everything for python 3.9.
As this is my first contribution via gitlab, please let me know if I
c
I pushed a change to my KiCad code repo to add python 3.9 as a supported
version, because Fedora is actively rebuilding everything for python 3.9.
As this is my first contribution via gitlab, please let me know if I created
the merge request properly.
In particular, this should go into both
1 - 100 of 289 matches
Mail list logo
