Jonathan, I hear you. I rolled back to ngspice-26 for the 5.1.4
release, and I think it probably makes sense to roll back to
ngspice-26 for 5.1.5 as well.
I am not really comfortable with the state of this situation. We're
running nightlies with 30, and release with 26, but how long until
Hi folks!
Does anyone want to help with the macOS notarization effort? It would
be a great way to learn about how everything goes together :)
Adam Wolf
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
The windows build box for the stable and nightly builds use boost 1.68.
On Wed, 28 Aug 2019 at 21:18, Blair Bonnett wrote:
>
>
> On Wed, 28 Aug 2019 at 21:04, Ian McInerney wrote:
> >
> > Going up to 1.67 won't be possible, since 18.04 is estimated to be
> > supported by KiCad until 2023
> >
On Wed, 28 Aug 2019 at 21:04, Ian McInerney
wrote:
>
> Going up to 1.67 won't be possible, since 18.04 is estimated to be
supported by KiCad until 2023 (
http://kicad-pcb.org/help/system-requirements/).
Ah, good point. I was only considering the official repos (KiCad 4) rather
than PPAs/people
Going up to 1.67 won't be possible, since 18.04 is estimated to be
supported by KiCad until 2023 (
http://kicad-pcb.org/help/system-requirements/). If anything, it might make
sense to go to 1.59 now, and re-evaluate it farther in the v6 development
(such as when the Python minimum version is also
Hi all,
I've recently been playing with some features I'd like to add to KiCad
(will be able to submit a patch soon I hope). As part of this, I'm adding
some unit tests. I see that unit_test_utils.h within the qa has a number of
macros working around Boost pre-1.59, and there's some features
Hello guys!
I hope everything is going well.
I have a request for Jean: I see you have the kicad 4 package up to ubuntu
18.04. Great work indeed!
In those days I got a new laptop running ubuntu 19.04 and it is a x86_64
based.
I was wondering if you can have kicad 4 for this ubuntu 19.04. Yesterday
Hi Ian,
On Wed, Aug 28, 2019 at 04:36:03PM +0200, Ian McInerney wrote:
> Just to be clear, I was only going to focus on cleaning up the static
> linkage in the current build process. While items in common could be moved
> into a new DLL, I don't have enough experience with that to try to attempt
Just to be clear, I was only going to focus on cleaning up the static
linkage in the current build process. While items in common could be moved
into a new DLL, I don't have enough experience with that to try to attempt
it right now.
-Ian
On Wed, Aug 28, 2019 at 4:31 PM Thomas Pointhuber
wrote:
Please go for it. The separate DLLs make it hard to design a python api
where eeschema and pcbnew can share resources.
Regards, Thomas
Am 28.08.19 um 16:03 schrieb Simon Richter:
> Hi,
>
> On Wed, Aug 28, 2019 at 10:47:52AM +0200, Ian McInerney wrote:
>
>> I think that the only way to really
Hi,
On Wed, Aug 28, 2019 at 10:47:52AM +0200, Ian McInerney wrote:
> I think that the only way to really fix this is to split common up into
> some smaller units,
I had the same idea already. This works for some parts (for example I was
able to split off dlist as an experiment), but the
Thanks! I reported the same issue earlier today[1] so I guess it could
be marked as duplicate.
[1] https://bugs.launchpad.net/kicad/+bug/1841752
Cheers
On Wed, Aug 28, 2019 at 3:24 PM Seth Hillbrand wrote:
>
> Note: Changing thread to avoid hijacking.
>
> On 2019-08-28 08:05, Jonatan Liljedahl
Ian,
I'm guessing that getting rid of the circular build dependencies would
probably get rid of most if not all of these issues so I'm all for this.
Cheers,
Wayne
On 8/28/19 5:33 AM, Ian McInerney wrote:
> Correction, dxf2idf didn't need gal, it needed opengl as a dependency
> (which also
Note: Changing thread to avoid hijacking.
On 2019-08-28 08:05, Jonatan Liljedahl wrote:
It would be great if you could roll back to ngspice-26 in 5.1.5, at
least for macOS, since it seems completely broken (can't simulate
op-amps, etc).
Cheers
/Jonatan
Hi Jonatan-
Please see bug tracker[1]
It would be great if you could roll back to ngspice-26 in 5.1.5, at
least for macOS, since it seems completely broken (can't simulate
op-amps, etc).
Cheers
/Jonatan
On Wed, Aug 28, 2019 at 1:58 PM Wayne Stambaugh wrote:
>
> On 8/27/19 3:56 PM, Seth Hillbrand wrote:
> > Hi All-
> >
> > I know
On 8/27/19 3:56 PM, Seth Hillbrand wrote:
> Hi All-
>
> I know 5.1.4 is still in its infancy but I am hoping that we can plan
> for a 5.1.5 during September (fixing at least 2 critical bugs). We've
> been a bit rocky with the point updates, so I'd like to propose a sequence:
>
> 1) Sometime
Correction, dxf2idf didn't need gal, it needed opengl as a dependency
(which also wans't specified in the CMakeLists.txt file...). But now I will
still run into the circular dependency problem that John posted in that bug
report, so I still want to refactor the common library into smaller chunks.
Thanks for the pointers. After digging into this some more, I think what is
happening is that including the sanitizers changes the behavior of the
linker. It seems that it really doesn't like undefined symbols when linking
executables, even if there is no visible dependency path that leads to
18 matches
Mail list logo
