Three symbol stores are now available at https://symbols.kicad.org for
Windows developers/users to troubleshoot crashes.
These stores are automatically updated on nightly builds and stable
releases.
The nightly and testing symbols are only kept for 30 days however to
conserve disk space.
--
Hey folks,
We are planning to introduce the use of the Sentry platform into KiCad.
Sentry https://sentry.io/ is open source platform to capture application
events, crash dumps, and other random analytics.
Both their hosted platform (https://github.com/getsentry/sentry) is open
source and the
Franck,
That is a feature request and belongs in the issue tracker for
consideration of 7.0.
This is purely about 6.0.1 which is bug fixes only. We do not add any new
features in 6.0 as per the rules.
On Fri, Jan 7, 2022 at 5:18 AM Franck Bourdonnec
wrote:
> Hello,
> I have a simple one.
>
The existence of the `thirdparty` folder is purely because we want a
locked-in time snapshot of sources with numerous bugfixes we make over
time. We don't want upstream packages because upstream is either dead, or
too much of a pain to deal with.
> It eases version control and reduces the cmake
More accurate, the actual fixed issues
https://gitlab.com/kicad/code/kicad/-/issues?label_name=status%3A%3Afix-committed_title=5.1.11=all
based on the milestone and fix-committed tag.
Unfortunately, a bunch of noise commits end up under the milestone.
On Sat, Oct 30, 2021 at 11:15 AM Wayne
ngspice 35 should be in the windows nightly by tomorrow
On Thu, Aug 12, 2021 at 11:15 PM Mark Roszko wrote:
> I'm slowly updating vcpkg for it.
>
> Probably in a few days it'll appear in nightlies.
>
> On Mon, Aug 9, 2021 at 5:27 PM Jon Evans wrote:
>
>> Thank
I'm slowly updating vcpkg for it.
Probably in a few days it'll appear in nightlies.
On Mon, Aug 9, 2021 at 5:27 PM Jon Evans wrote:
> Thanks Holger, I tested a fix and it works now (6b48825a)
>
> Updated
> https://gitlab.com/kicad/packaging/kicad-mac-builder/-/merge_requests/344
> to bump to
has_value was added in boost 1.68.
There is an argument we should be supporting boost 1.65 due to Ubuntu 18
On Fri, Jul 16, 2021 at 6:06 AM Dino Ghilardi
wrote:
> Hello Alex,
> I had the same issue compiling with boost 1.67.0.
>
> Compiling with boost 1.69 did not have the issue on my
>The number of issues is about 1170 on any day since a few months. My goal
is to reduce the number of open issues to a bare minimum or eliminate them
You realize we only have <100 real issues right? You cannot look at the
silly total displayed and assume. You have to drill down by tags.
A vast
Yes. The entire plan is to have at minimum a RC1 release for bug
testing,etc. However the date is a shifting target of optimism.
On Sun, Jun 20, 2021 at 7:25 AM David wrote:
> Hi,
> I'm hoping to get version 6 of Kicad installed for the students in the
> University where I work. Are there
Thanks to Erico bringing attention to it
https://gitlab.com/kicad/code/kicad/-/merge_requests/852 openssl is no
longer a dependency for builds on linux and msys2.
This was a holdover from curl linking openssl < 1.1.0 which
necessitated the end application implementing thread locks and curl did
pkgconfig is only available for builds within vcpkg for builds of libraries.
kicad does not build within vcpkg, it builds outside vcpkg using vcpkg.
This is the intended mode of use for applications.
On Tue, Mar 23, 2021 at 12:09 PM Wayne Stambaugh
wrote:
> Did I misunderstand Marks's comments
> Does vcpkg support pkg-config?
vcpkg can use pkg-config for building its own libraries.
However vcpkg will not share it outside of itself, meaning kicad has no
ability to use it easily
On Mon, Mar 22, 2021 at 3:18 PM Wayne Stambaugh
wrote:
> Would pkg-config work on all platforms? I know it
Beware the complaints that will spawn when this pushes. Because of the
KICAD6_blah variables that will be pointing to the old paths as its saved
to the config file even if not changed from default
On Sun, Mar 21, 2021 at 5:31 PM Seth Hillbrand wrote:
> Accidental build directory has been
You say it's first class but the spice gui needs alot of loving. The tool
framework is also ducktaped poorly into it.
On Thu, Mar 18, 2021 at 7:14 PM Seth Hillbrand wrote:
> Do we still need spice as a build option? It would be nice to bring down
> the number of permutations out there and the
pic first -- if other
> > software is successfully using websockets to provide a good interface to
> > 3dconnexion hardware on Windows, maybe it is not as bad as you fear?
> >
> > -Jon
> >
> > On Thu, Feb 25, 2021 at 9:38 AM Mark Roszko > <mailto:m
mpiled with new-enough Boost versions, or
> investigate a different websockets library.
>
> I'm not sure the overlap of 3dconnexion users and 18.04 users is large
> enough to rule that approach out, at least if there are no other issues
> with Beast.
>
> -Jon
>
> On Thu, Fe
* Boost 1.65 being the version Ubuntu 18.04 LTS currently has and are
committed to support until EOL.
On Thu, Feb 25, 2021 at 9:19 AM Mark Roszko wrote:
> Markus,
>
> We currently require support for a minimum of boost 1.59 due to Linux
> distros lagging behind. boost/beast is
Markus,
We currently require support for a minimum of boost 1.59 due to Linux
distros lagging behind. boost/beast is not a viable option as beast did not
appear in boost until 1.66.
>From some offhand sounding out we may be able to bump the minimum to 1.65
but that doesn't help :/
Regards,
That github page while still functioning is abandoned. It's pointed at
master and at the master just before it was converted to the 6.0 library
format.
On Sun, Feb 7, 2021 at 10:50 AM Steven A. Falco
wrote:
> I received a bug report [1] that points out that the libraries on github
> contain
The problem with a new header though is we will need to add yet another
build flag to kicad that a user will have to setbecause we can't
guarantee all platforms will have ngspice > 35 or whateveto look for a new
"version.h"
On Wed, Feb 3, 2021 at 7:04 AM jp charras wrote:
>
> Le 03/02/2021
> but remember usually you need to run the install
target to make sure you got all the proper binaries whereever you run
it from.
Currently you have to copy all the vcpkg binaries manually to the install
folder.
On Sat, Dec 19, 2020 at 3:57 PM Nick Østergaard wrote:
> Hi Stefan
>
> (You did
If it
>> is about dependencies, maybe I missed to install something in vcpkg. I
>> installed the recommended libraries as per the web documentation:
>>
>> boost cairo curl glew gettext glm icu ngspice opencascade opengl openssl
>> python3 wxwidgets zlib.
>>
&g
gt; and I'm on wxwidgets 3.1.4. But one week or so ago, everything was ok.
> Trouble started after upgrading vcpkg.
>
> -Martin
>
>
>
> *Von:* Mark Roszko
> *Gesendet:* 16 November 2020 20:56
> *An:* deve...@worldinone.at
> *Betreff:* Re: [Kicad-developers] MSVC compile:
Ah it's a bug in vcpkg I need to fix upstream.
For now you'll need to include in your kicad install folder for debug, the
non-debug versions of freetype, zlib, bz2 and libpng
On Mon, Nov 16, 2020 at 1:44 PM Mark Roszko wrote:
> Ah I've been meaning to fix that. There's something wr
Ah I've been meaning to fix that. There's something wrong with the
compilation settings and/or wxdynamiclibrary loader that's causing it not
to load DLLs from the application's executable directory, very specifically
for the OCE plugin.
On Mon, Nov 16, 2020 at 6:22 AM wrote:
> Compiling the
>It does mention that it is just the environment that is 64 bit only, but
not the mingw toolchains, so I don't really think this affects us.
It does,* just not right now. *The writing is on the wall for 32-bit x86.
Microsoft officially has marked 32-bit Windows 10 EOL and I believe it's
being
gt;
> On Thu, 5 Nov 2020, Mark Roszko wrote:
>
> > Your issues in (1) are by design.
> >
> > Whether that design is correct or not is another story.
> >
> > I actually removed that behavior on Windows because Microsoft has a
> stable api to determ
Your issues in (1) are by design.
Whether that design is correct or not is another story.
I actually removed that behavior on Windows because Microsoft has a stable
api to determine top level window for focus.
Linux does not and GDK used to be but with the fragmented x11/wayland mess,
they
Update to latest, there's a bad exception handler that causes the context
already locked error. There was another bug that actually caused an
exception.
On Wed, Nov 4, 2020 at 2:11 AM wrote:
> The current source (~7am UTC) crashes in pcbnew at opengl_gal.cpp(598) due
> to “Context already
Ah, I forgot to document that.
The "lazy way" is to copy all the DLLs from \vcpkg\installed\\bin
to your kicad install bin folder
The next lazy way that should work is to add the vcpkg installed triplet to
PATH
The third way that I haven't used is to use launch.json to set PATH to the
vcpkg
Great, thanks for the heads up.
I need to update the vcpkg.
On Sun, Oct 18, 2020 at 10:38 AM Holger Vogt wrote:
> ngspice-33 is available.
>
>
> ngspice shared library tested with KiCad on macOS, Linux, MS Windows.
>
>
> ___
> Mailing list:
You should be able to click a button to ignore the warning.
On Mon, Oct 12, 2020 at 8:54 PM Brian Piccioni
wrote:
> That makes sense. I tried installing the same file which installed
> perfectly this morning and it hung. I'll wait a few days and try again ...
>
> On 2020-10-12 6:1
It's just the usual Microsoft Smartscreen filter acting up. Heuristics are
flagging it. There's nothing that can be done about it until their
heuristics recalculate.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
Yea I'm with Nick on this one. As it standards, 10.12 is past EOL now.
10.13 EOL is in 2 months. Supporting outdated (and as an extension
insecure) OSes just encourages users to make the bad decision to keep using
them.
On Wed, Sep 30, 2020 at 11:26 AM Nick Østergaard wrote:
> If people needs
Looking at that draft announcement, it has the usual "look at the 5.1.7
milestones page for list of issues fixed" link which needs to be fixed.
Or rather there's also a slight mess on the gitlab side. It seems there are
two 5.1.7 milestones, one at the repo level and one at the group level and
I actually got that MSYS2 error awhile backas for why, I don't know, I
haven't been arsed to rebuild the msys2 install yet again.
I'm waiting on vcpkg to merge opencascade which was blocked on 32-bit
builds being broken, the MSVC team responded with a workaround to the
compiler bug so now
p it
> in memory. Watch for modifications on disk, or else lock it
> exclusively. Things like that.
>
> I'm not sure I really see the advantage of a CSV-backed "database" over
> the existing KiCad library system, if we're talking about a single user.
>
> -Jon
>
&
>Sqlite was a quick way to test if my ideas would work.
There are ODBC wrappers for SQLite
> I mean libreoffice would do for the management.
Yes, and you know what you would use? Not CSV files.
LibreOffice Base / Microsoft Access.
This is the office suite database that's basically SQLite
Every package in vcpkg is a dev package as that is its purpose ;)
linux distros just make a distinction with -dev to make headers and link
libs a separate download/save space.
On Mon, Aug 17, 2020 at 4:02 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:
> Ah I see! Sorry I
> I assume this is due to the way the make script determines if it is Linux
or Windows.
KiCad does not determine the Operating system. CMake does.
You are somehow invoking or mixing executables between windows and linux.
i.e. if you have CMAKE.exe in path, it may be executed inside your wsl2
FYI, the website repo is now deployed from gitlab instead of github
https://gitlab.com/kicad/services/kicad-website
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
depending on how we want to handle Python/wxPython.
>
> >
> > On Thu, 6 Aug 2020, 02:05 Mark Roszko, > <mailto:mark.ros...@gmail.com>> wrote:
> >
> > ngspice and wxwidgets 3.1.4 have been merged on vcpkg.
> >
> > On Sun, Aug 2, 2020 at 5:55 PM
ngspice and wxwidgets 3.1.4 have been merged on vcpkg.
On Sun, Aug 2, 2020 at 5:55 PM Wayne Stambaugh wrote:
> +1
>
> On 8/2/20 2:08 PM, Seth Hillbrand wrote:
> > Nice work! Thanks, Mark
> >
> > On Sat, Aug 1, 2020 at 11:26 PM Mark Roszko > <mai
Sigh, almost as bad as QT 5 minors being majors without ever bumping the 5
because "qt5" is a marketing brand they don't want to replace from the
commercial standpoint.
On Tue, Aug 4, 2020 at 9:15 AM Ian McInerney
wrote:
>
>
> On Tue, Aug 4, 2020 at 1:44 PM Mark Roszko wrote
Been working on Phoenix, I basically have something working to build,
though it'll be awhile before I have anything to share.
However, here's the fun part:
wxPhoenix 4.1.0 only works with wxWidgets 3.1.4 and above
wxPhoenix 4.0.7 only works with wxWidgets 3.0.x series
There's a fun gap with
> unfortunately that is a typical thing how problems are getting "solved",
>simply embed the required third party code. From a security perspective
>this is mostly a nightmare as also typically nobody ever touches such
>code again as it "works" for all times.
>Embedded code is quite in no way
/file/tool/lemon.c
On Sun, Aug 2, 2020 at 6:37 PM Mark Roszko wrote:
> MSVC support is a work in progress so it's not that its not supported,
> it's just someone needs to fix it ;)
>
> On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista <
> roberto.fer@gmail.com&
MSVC support is a work in progress so it's not that its not supported, it's
just someone needs to fix it ;)
On Sun, Aug 2, 2020 at 6:06 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:
> Just tried your branch and unfortunately couldn't get it to compile on
> Visual Studio (even
Nightlies temporarily broken until a new msys2 file is added into the build.
libssp-0.dll
On Sun, Aug 2, 2020 at 1:27 PM Mark Roszko wrote:
> Nick has fixed the Windows nightlies, rejoice
>
> The builds are flagged dirty for what its worth.
>
> On Sat, Aug 1, 2020 at 9:04 AM
Nick has fixed the Windows nightlies, rejoice
The builds are flagged dirty for what its worth.
On Sat, Aug 1, 2020 at 9:04 AM Eeli Kaikkonen
wrote:
> [image: image.png]
>
> Something wrong with the Windows nightly builds?
>
> The commit 0c77 is from 30 July, I remember seeing that same
versions.
>
> -Ian
>
> On Sun, Aug 2, 2020 at 4:58 AM Mark Roszko wrote:
>
>> I am working on a MSVC build chain slowly amongst my ADHD heh.
>> Though I'm focusing on Win64 builds, Win32 would be trivial. It's just a
>> measure of how much is it worth it. Microsoft has in
towards life support status.
On Sat, Aug 1, 2020 at 11:31 PM Seth Hillbrand wrote:
>
> On Sat, Aug 1, 2020 at 7:31 PM Mark Roszko wrote:
>
>> Ah right, as it stands, the only way to use a new install of msys2 32-bit
>> now is to patch it on startup because
to begin to
diverge from the 64-bit builds
There may need to be a decision made about continued 32-bit support for
KiCad Windows.
On Sat, Aug 1, 2020 at 10:20 PM Mark Roszko wrote:
> Only just noticed this
>
> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-
Only just noticed this
https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported
As a whole to KiCad, only 6% of Windows users will be affected.
I did change the website awhile back to more prominently push people onto
64-bit builds.
Just the world finally moving forward
You would think we want a spider to kill bugs :D
On Thu, Jul 16, 2020 at 11:16 PM Brian Piccioni
wrote:
> I'm guessing because it finds bugs?
> On 2020-07-16 11:14 p.m., Ben Ellis wrote:
>
> Hi all,
>
> Does anyone know why the DRC symbol is a ladybug? Asking for a friend
>
> Best,
> Ben
>
>
> I also think it would enable independent software developers to build
software on top of, or around kicad, further enhancing its value.
They should be contributing to KiCad first ;)
These plans for separation have been around for years, the problem is the
amount of devs is limited and their
a look at wxPython phoenix and the build system is...something
> else.
> >>> Is anyone more experienced with Python build systems?
> >>> It seems like the happy path for vcpkg is for projects that use cmake.
> >>> This hybrid of Python and C++ with custom b
t; C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> (_find_package)
> 23:48:21 CMakeLists.txt:586 (find_package)
>
> On Tue, 7 Jul 2020 at 01:49, Mark Roszko wrote:
> >
> > 1. cmake scripts alrea
1. cmake scripts already work with wxwidgets, that was already done awhile
back. I've been building with MSVC for awhile
One dependency that'll need "porting" is ngspice.
But let me put this out there, does it make sense to leave ngspice to a
higher level distro and not built as part of kicad?
While more extensibility is great. I can only say expecting the user to use
python exclusively for adding the new behavior like for issue #2339 is very
crude. Not everyone is a programmer or wants to be to draw a schematic. A
lot of functionality that's not overly specific should be considered
Might I suggest the file format being documented into the repo first?
That way any new additions to the format should involve adding to said
documentation.
On Fri, May 29, 2020 at 9:12 AM Wayne Stambaugh
wrote:
> As soon as the rebase and CI pipeline completes, the merge request to
> disable
Ah just a defect with recent changes I made and me never using www. It
shall be fixed.
On Sat, May 23, 2020 at 10:39 AM Wayne Stambaugh
wrote:
> It was the URL issue but I'm in agreement with Ian. The old URL should
> redirect to the new one.
>
> On 5/23/20 10:35 AM, Ian McInerney wrote:
> >
s:
> https://semaphoreci.com/blog/free-open-source-cicd
>
> That might be an alternative/addition for the local server from Adam Wolf?
>
> I am not sure it's possible to trigger the semaphoreci build directly from
> gitlab, but it's possible from github.
> And since kicad still
90% chance AppVeyor won't work because its build time restricted to 60
minutes. And KiCad builds quite slowly on the free services taht only
provide 1 or 2 cores.
An alternative, there's also the Azure Pipelines KiCad account where I run
Coverity. It has unlimited minutes for open source project
I made it better, maybe
On Wed, May 6, 2020 at 6:00 PM Nick Østergaard wrote:
> I have done it, could't be bothered with the bullet points though. :)
>
> On Wed, 6 May 2020 at 23:11, Wayne Stambaugh wrote:
> >
> > If you have time, I'm fine with that. Thanks for the help.
> >
> > On 5/6/2020
Yes. This is a coverity scan bug. They are aware of it since 2017 when I
harassed their manager about it but maintaining the open source offering is
ultra low priority for them. They were promising they would refocus on
"bring it up to Synopsis standards" this year but so far it hasn't happened.
https://gitlab.com/kicad/services/kicad-doc
On Sun, Apr 5, 2020 at 6:59 AM Marco Ciampa wrote:
> It seem a bit odd but ... I can't fine the docs repos anymore...
> On github the doc repos are frozen and on gitlab the repos I used to use
> just vanished ...
> What's going on here?
> Did I miss
Any plans for a 5.1.6 tag? It's been 4 months since the last one with some
commits piled up.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
Rebasing is still required if enabling LFS after already having added a
file previously. LFS is simply a hack on top of Git rather than a protocol
level improvement.
On Mon, Jan 20, 2020 at 1:42 PM Jon Evans wrote:
> I can say from experience that enabling LFS would be a lot more hassle
> than
https://scan8.coverity.com/reports.htm#v22582/p10844/fileInstanceId=29833683=10148075=280285
467if( s1.Distance( ip ) <= 1 || s2.Distance( ip ) <= 1 )
468{
469s1opt = SEG( s1.A, ip );
470s2opt = SEG( ip, s2.B );
471
wxWidgets has a interesting maze of macros to determine how to do
printf on Windows. I wonder what it ends up doing. There is a special
case just for MINGW32 but not MINGW64.
https://github.com/wxWidgets/wxWidgets/blob/cc931612eec2e3ea49200ebff45042135f3c3f9c/include/wx/wxcrtvararg.h#L84
On
>A tongue-in-cheeck suggestion: don't let any commit go to the repo if the
>commit message doesn't have the word "because" at least once.
Well, 2014 was still a older era in KiCad development
On Sat, Dec 28, 2019 at 12:18 PM Eeli Kaikkonen
wrote:
>
>
>
> On Sat, Dec 28, 2019 at 5:52 PM Ian
But that 1.600 is not a double/floating number, it truncated from the
double of 1.600088817841970012523233890533447265625
The entire complaint I believe is when it comes to serializing to JSON
in 99% of software of all languages, you do not apply custom
formatting to convert doubles
Just throw in a linear regression somewhere and we can say KiCad has
AI based routing ;)
On Mon, Dec 2, 2019 at 4:25 PM Tomasz Wlostowski
wrote:
>
> On 02/12/2019 21:51, Kliment (Future Bits) wrote:
> > The video looks very much like to me like the trace is following a
> > voronoi cell boundary
There are UX issues with just changing that dropdown.
Currently it's quite literally page size. Not templates.
Template is the separate entry labeled "Page layout description file".
(Just noticed, it should probably display the default loaded template
which may hint the user to make a change)
If
> Nick, is packaging Windows your domain? Is there any way I could help to
get them included in an updated 5.1.5 release or 5.1.6? I know the GitLab
stuff is taking a lot of time from everybody but I don't want to let this
wither away.
He is the main mainter yes.
If you want to help him.
ation" and "Donate
> > via CERN" to
> > > distinguish them. I know that they are separated people tend
> > to not
> > > read things despite our best intentions.
> > >
> > >
Just throwing it out there.
Is there any point in continuing 32-bit builds for Windows? 64-bit has been
the default arch for over a decade on Windows now. Linux distros are in the
process of purging 32-bit. macOS threw 32-bit into a deep dark hole this
year.
Pros:
1. Don't need to package twice
ng if we should also change the
> donate buttons to "Donate via Linux Foundation" and "Donate via CERN" to
> distinguish them. I know that they are separated people tend to not
> read things despite our best intentions.
>
> Cheers,
>
> Wayne
>
> On 11/23/19 8
Honestly, it would be awesome if we leveraged Azure Pipelines. For OSS it
provides *unlimited minutes of* *Windows, OSX,Linux builds with up to 10
parallel jobs at a time.*
Though the integration may not be as nice as it is with GitHub. But it
blows away just a single build box and the standard
> I assume git merges will still go through SSH and not require 2FA either
way?
Yes, this just protects the account from third party remote compromise.
On Tue, Nov 26, 2019 at 8:13 AM Jeff Young wrote:
> Was there a resolution on the 2FA question? (I used to have to use it for
> Adobe’s VPN
>always add custom backend system later to complement free infra.
We do have free infrastructure that can run backend code at CERN. Just
needs to package up in a docker container and run as non-root inside the
container. Assuming also it's not some resource hog of a system that eats
the entire
> I don't have, or want, a cell phone (or any Google account).
You do not need a cell phone. You can use a computer based TOTP supporting
authentication app such as Authy or FOSS KeePassXC (
https://keepassxc.org/screenshots/)
> A simple password is not perfect, but at least it is easy to use and
GitLab does send emails when SSH keys are added by default, but it's not
enough.
It's about GitLab (and even GitHub) allowing you to edit code right in the
web interface without needing to touch git.
But yes, GitLab does support 2FA. It is optional per account by default BUT
it can be mandated on
Can the use of 2FA be mandated across the entire group since we have a
fresh start?
It's been killing me that it's not required for GitHub and it really is a
vulnerability to not enforce. KiCad is a decent value target for malicious
code placement since it is a desktop app.
at myself. We can try a donate page and see
> how
> > it works. We can always change it if we don't like it.
> >
> > On 11/22/19 3:53 PM, Mark Roszko wrote:
> > > I'm not sure about adding a second button in the header.
> > >
> >
It has potential to reduce clicks.
But feel free to suggest a change in the visual style that can
accommodate two buttons without degrading the website visually or
psychology reducing donations too (the "wow these guys look desperate"
effect)
On Fri, Nov 22, 2019 at 5:49 PM Drew Van Zandt
v 22, 2019 at 2:50 PM Wayne Stambaugh
wrote:
>
>
> On 11/22/19 2:39 PM, Mark Roszko wrote:
> >> I need to add a "Donate via Linux Foundation" button to the KiCad
> > website main page.
> >
> > But is it in addition to or to replace CERN?
>
> In a
> I need to add a "Donate via Linux Foundation" button to the KiCad
website main page.
But is it in addition to or to replace CERN?
On Fri, Nov 22, 2019 at 12:03 PM Wayne Stambaugh
wrote:
> I just pushed a blog post to the KiCad website that KiCad has joined the
> Linux Foundation so
eam releases.
On Wed, Oct 23, 2019 at 12:43 PM Wayne Stambaugh
wrote:
> On 10/23/2019 10:52 AM, Mark Roszko wrote:
> > Can there ever be a statement written somewhere that says "KiCad strives
> > to support Ubuntu LTS Latest and Previous, Debian Latest, etc"?
Can there ever be a statement written somewhere that says "KiCad strives to
support Ubuntu LTS Latest and Previous, Debian Latest, etc"?
Basically defining what is considered "older Linux distros" vs "supported".
KiCad is unique in not building linux packages directly compared to most
other major
We would just run it on the same CERN openshift cluster as the website.
I would volunteer as this is literally what I do at work (maintain a 100+
man GitLab instance among many other bits of infrastructure) but the real
question is what is the benefit?
You really don't want to be modifying
GitHub/GitLab style interfaces depend on using labels for everything. So
yes, someone should define the workflow ahead of time, including label
usage.
[image: image.png]
On Thu, Oct 10, 2019 at 5:30 AM Ian McInerney
wrote:
> On a similar note, the issue workflow will need to be modified if
t's clear who
> originally posted it and the context is not lost.
> >
> > Regards,
> > Andrew
> >
> >
> > On Wed, Oct 9, 2019 at 4:36 PM Wayne Stambaugh
> wrote:
> >>
> >> On 10/9/19 3:32 PM, Mark Roszko wrote:
> >> >> I've
> I've applied for an open source GitLab license. Assuming we get
accepted,
Technically not required for now. The license just unlocks extra features
but the base free feature set is more than adequate for now.
>Would it be possible to migrate open bug reports to GitLab? I suspect
>we could
ight" ) + ":" for translation, not
>>> _(
>>> > "Height:" )? As far as I understand, now we will need to have 2
>>> > translations, first for "Height" and second for "Height:" but that's
>>> > basically same word
>The long term plan is to build an MSI based installer, because that leaves
MSI is an absolute actual disaster to maintain and when it implodes you
have to whip out the registry editors and system clenaers to erase any
vestigal traces of metadata it uses to be able to even correct a package.
Even
> Since making every hole in the pcb costs time, manufacturers calculate
the price of the PCB using also that number.
A long time ago, holes cost alot. These days if your manufacturer is
charging alot per hole, you should run far away. Usually manufactuers
include 20k-40k holes in the base price
I wouldn't use anything before 2015 since that was before C++11 support was
"finished".
Simon, did you ever try 2019 since it's been out for awhile now?
On Tue, Jul 2, 2019 at 6:54 AM Simon Richter
wrote:
> Hi,
>
> > What is the minimum version of MSVC required for building this?
>
> I use
1 - 100 of 449 matches
Mail list logo
