Re: [Kicad-developers] RC2 has been released.
I just jumped directly to https://launchpad.net/kicad and hovering on the download links on the right you can see those links. 2015-11-09 2:37 GMT+01:00 Wayne Stambaugh : > That is strange. I wonder if the path has something to do with what > page is open when you upload it. As long as users can download the file > it should be OK. If I get some time, I'll mess around with it and see > if I can get it in the https://launchpad.net/kicad/4.0 path. > > On 11/8/2015 6:01 PM, Nick Østergaard wrote: >> Hi Wayne >> >> Thank you for realasing. Although the download link is a bit strange.. >> it still partly refers to rc1. >> >> https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz >> >> But anyway, I guess we can just say that the docs, and their >> translations, and the GUI translations shall be done in two weeks if >> they want to be included with the release. The same witht he libs, if >> anything is is left to be done, and we can just take a snapshot of the >> libs and put it on the download page. >> >> 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : >>> I just finished up getting all of the relevant code for RC2 uploaded to >>> launchpad so let's fire up those autobuilders and get some rc2 packages >>> out there for testing. I'm hoping this will be the last rc before the >>> stable release. Let's keep our fingers crossed. We need start thinking >>> about branching or tagging the library, documentation, and translation >>> repos so that packagers can build consistent packages for their >>> respective platforms. Thanks to everyone who made this possible. I'm >>> going to step away from my computer for a while and enjoy the adult >>> beverage of my choice. >>> >>> Cheers, >>> >>> Wayne >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plans for (OpenGL-/Cairo-/Default-) canvases after stable?
On 08.11.2015 22:43, Bernhard Stegmaier wrote: > is there any roadmap/plan for how to go on with the three canvases in pcbnew > after the stable release? Hi Bernhard, Yes, there is a plan. In short: - Port the remaining features of the "legacy" canvas such as component auto-placement or delete-track-while-routing to the GAL. We'll appreciate any help with assembling a list of features still missing in the GAL canvases. - Improve the speed of the Cairo renderer so it's fast enough at least for an Arduino-sized board. - Drop the legacy canvas before the next stable release. Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] memory leak in meander placer [was: RC2]
On 07.11.2015 21:41, Wayne Stambaugh wrote:
And speaking of pns, there is still CID 106401 where
PNS_MEANDERED_LINE::MeanderSegment can memory leak.
Here's a patch for that.
Cheers,
T.
>From cd30ed5522dcced484ad6b0a80a0c35e1171c957 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?=
Date: Mon, 9 Nov 2015 10:19:31 +0100
Subject: [PATCH] router: fixed memory leak in the meander placer
---
pcbnew/router/pns_meander.cpp | 31 ---
pcbnew/router/pns_meander.h | 5 +
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/pcbnew/router/pns_meander.cpp b/pcbnew/router/pns_meander.cpp
index 5bca9bb..6739401 100644
--- a/pcbnew/router/pns_meander.cpp
+++ b/pcbnew/router/pns_meander.cpp
@@ -61,11 +61,12 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
do
{
-PNS_MEANDER_SHAPE* m = new PNS_MEANDER_SHAPE( m_placer, m_width, m_dual );
-m->SetBaselineOffset( m_baselineOffset );
-m->SetBaseIndex( aBaseIndex );
+PNS_MEANDER_SHAPE m( m_placer, m_width, m_dual );
-double thr = (double) m->spacing();
+m.SetBaselineOffset( m_baselineOffset );
+m.SetBaseIndex( aBaseIndex );
+
+double thr = (double) m.spacing();
bool fail = false;
double remaining = base_len - ( m_last - aBase.A ).EuclideanNorm();
@@ -79,10 +80,10 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
{
for( int i = 0; i < 2; i++ )
{
-if ( m->Fit( MT_CHECK_START, aBase, m_last, i ) )
+if ( m.Fit( MT_CHECK_START, aBase, m_last, i ) )
{
turning = true;
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
side = !i;
started = true;
break;
@@ -95,9 +96,9 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
for( int i = 0; i < 2; i++ )
{
-if ( m->Fit ( MT_SINGLE, aBase, m_last, i ) )
+if ( m.Fit ( MT_SINGLE, aBase, m_last, i ) )
{
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
fail = false;
started = false;
side = !i;
@@ -106,17 +107,17 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
}
}
} else {
-bool rv = m->Fit( MT_CHECK_FINISH, aBase, m_last, side );
+bool rv = m.Fit( MT_CHECK_FINISH, aBase, m_last, side );
if( rv )
{
-m->Fit( MT_TURN, aBase, m_last, side );
-AddMeander( m );
+m.Fit( MT_TURN, aBase, m_last, side );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
started = true;
} else {
-m->Fit( MT_FINISH, aBase, m_last, side );
+m.Fit( MT_FINISH, aBase, m_last, side );
started = false;
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
turning = false;
}
@@ -124,9 +125,9 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
}
} else if( started )
{
-bool rv = m->Fit( MT_FINISH, aBase, m_last, side );
+bool rv = m.Fit( MT_FINISH, aBase, m_last, side );
if( rv )
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
break;
diff --git a/pcbnew/router/pns_meander.h b/pcbnew/router/pns_meander.h
index 88fb2cc..5d1ae51 100644
--- a/pcbnew/router/pns_meander.h
+++ b/pcbnew/router/pns_meander.h
@@ -416,6 +416,11 @@ public:
m_baselineOffset = 0;
}
+~PNS_MEANDERED_LINE()
+{
+Clear();
+}
+
/**
* Function AddCorner()
*
--
1.9.1
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] memory leak in meander placer [was: RC2]
Le 09/11/2015 10:32, Tomasz Wlostowski a écrit : > On 07.11.2015 21:41, Wayne Stambaugh wrote: > And speaking of pns, there is still CID 106401 where > PNS_MEANDERED_LINE::MeanderSegment can memory leak. > > Here's a patch for that. > > Cheers, > T. I committed this patch. Thanks. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
Wayne, You've released the source tarball against the RC1 milestone. I'd delete it from there and re-release it against the RC2 milestone. Best Regards, Brian. On 9 November 2015 at 08:17, Nick Østergaard wrote: > I just jumped directly to https://launchpad.net/kicad and hovering on > the download links on the right you can see those links. > > 2015-11-09 2:37 GMT+01:00 Wayne Stambaugh : >> That is strange. I wonder if the path has something to do with what >> page is open when you upload it. As long as users can download the file >> it should be OK. If I get some time, I'll mess around with it and see >> if I can get it in the https://launchpad.net/kicad/4.0 path. >> >> On 11/8/2015 6:01 PM, Nick Østergaard wrote: >>> Hi Wayne >>> >>> Thank you for realasing. Although the download link is a bit strange.. >>> it still partly refers to rc1. >>> >>> https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz >>> >>> But anyway, I guess we can just say that the docs, and their >>> translations, and the GUI translations shall be done in two weeks if >>> they want to be included with the release. The same witht he libs, if >>> anything is is left to be done, and we can just take a snapshot of the >>> libs and put it on the download page. >>> >>> 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : I just finished up getting all of the relevant code for RC2 uploaded to launchpad so let's fire up those autobuilders and get some rc2 packages out there for testing. I'm hoping this will be the last rc before the stable release. Let's keep our fingers crossed. We need start thinking about branching or tagging the library, documentation, and translation repos so that packagers can build consistent packages for their respective platforms. Thanks to everyone who made this possible. I'm going to step away from my computer for a while and enjoy the adult beverage of my choice. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp >> > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] kicad StepUp 3D MCAD exporter has landed Hackaday.com!
Hi to all, I'm pleased to share that kicad StepUp 3D MCAD exporter has landed Hackaday.com! http://hackaday.com/2015/11/08/kicad-script-hack-for-better-mechanical-cad-export/ http://hackaday.com/ Thanks a lot to Hackaday staff for the nice review!!! :) Maurice PS more 3D features for an easier ECAD MCAD collaboration are coming... ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
Thanks. I'll take a look at it as soon as I get a chance. On 11/9/2015 7:29 AM, Brian Sidebotham wrote: > Wayne, You've released the source tarball against the RC1 milestone. > I'd delete it from there and re-release it against the RC2 milestone. > > Best Regards, > > Brian. > > On 9 November 2015 at 08:17, Nick Østergaard wrote: >> I just jumped directly to https://launchpad.net/kicad and hovering on >> the download links on the right you can see those links. >> >> 2015-11-09 2:37 GMT+01:00 Wayne Stambaugh : >>> That is strange. I wonder if the path has something to do with what >>> page is open when you upload it. As long as users can download the file >>> it should be OK. If I get some time, I'll mess around with it and see >>> if I can get it in the https://launchpad.net/kicad/4.0 path. >>> >>> On 11/8/2015 6:01 PM, Nick Østergaard wrote: Hi Wayne Thank you for realasing. Although the download link is a bit strange.. it still partly refers to rc1. https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz But anyway, I guess we can just say that the docs, and their translations, and the GUI translations shall be done in two weeks if they want to be included with the release. The same witht he libs, if anything is is left to be done, and we can just take a snapshot of the libs and put it on the download page. 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : > I just finished up getting all of the relevant code for RC2 uploaded to > launchpad so let's fire up those autobuilders and get some rc2 packages > out there for testing. I'm hoping this will be the last rc before the > stable release. Let's keep our fingers crossed. We need start thinking > about branching or tagging the library, documentation, and translation > repos so that packagers can build consistent packages for their > respective platforms. Thanks to everyone who made this possible. I'm > going to step away from my computer for a while and enjoy the adult > beverage of my choice. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >>> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
On 11/8/2015 6:01 PM, Nick Østergaard wrote: > Hi Wayne > > Thank you for realasing. Although the download link is a bit strange.. > it still partly refers to rc1. > > https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz > > But anyway, I guess we can just say that the docs, and their > translations, and the GUI translations shall be done in two weeks if > they want to be included with the release. The same witht he libs, if > anything is is left to be done, and we can just take a snapshot of the > libs and put it on the download page. I'm wondering if we should branch the translation and doc repos. Once new features and strings are added to kicad during the next development cycle, updating the translation and doc repos will not make sense against the 4.0 stable release of kicad. Creating 4.0 branches of the doc and translation repos would allow for new translations and improved documentation for the 4.0 stable release. There would be some cross-over between the 4.0 and development repos which would be a bit more work. I'm OK with tagging the current repos as well. The downside to that is there will be no new translations or doc improvements until the next stable release. I'll leave that up to the doc and translation folks. Tagging and a snapshot archive makes sense for the lib repo. > > 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : >> I just finished up getting all of the relevant code for RC2 uploaded to >> launchpad so let's fire up those autobuilders and get some rc2 packages >> out there for testing. I'm hoping this will be the last rc before the >> stable release. Let's keep our fingers crossed. We need start thinking >> about branching or tagging the library, documentation, and translation >> repos so that packagers can build consistent packages for their >> respective platforms. Thanks to everyone who made this possible. I'm >> going to step away from my computer for a while and enjoy the adult >> beverage of my choice. >> >> Cheers, >> >> Wayne >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
2015-11-09 14:54 GMT+01:00 Wayne Stambaugh : > On 11/8/2015 6:01 PM, Nick Østergaard wrote: >> Hi Wayne >> >> Thank you for realasing. Although the download link is a bit strange.. >> it still partly refers to rc1. >> >> https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz >> >> But anyway, I guess we can just say that the docs, and their >> translations, and the GUI translations shall be done in two weeks if >> they want to be included with the release. The same witht he libs, if >> anything is is left to be done, and we can just take a snapshot of the >> libs and put it on the download page. > > I'm wondering if we should branch the translation and doc repos. Once > new features and strings are added to kicad during the next development > cycle, updating the translation and doc repos will not make sense > against the 4.0 stable release of kicad. Creating 4.0 branches of the > doc and translation repos would allow for new translations and improved > documentation for the 4.0 stable release. There would be some > cross-over between the 4.0 and development repos which would be a bit > more work. I'm OK with tagging the current repos as well. The downside > to that is there will be no new translations or doc improvements until > the next stable release. I'll leave that up to the doc and translation > folks. Tagging and a snapshot archive makes sense for the lib repo. I think just tagging it should be sufficient to generate a release tarball on github (4.0.0.0). If we need followup changes we can make a leaf branch from there or later on the master branch with 4.0.0.1. I don't think -n is good here, because multiple packaging systems use a dash number notation to describe revisions of the packaging scripts themselves. The triplet is reserved to the kicad source, so we must need some other indicator for auxiliary stuff. But we really need to align the version numbers across the source code, docs, translations and libs. >> 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : >>> I just finished up getting all of the relevant code for RC2 uploaded to >>> launchpad so let's fire up those autobuilders and get some rc2 packages >>> out there for testing. I'm hoping this will be the last rc before the >>> stable release. Let's keep our fingers crossed. We need start thinking >>> about branching or tagging the library, documentation, and translation >>> repos so that packagers can build consistent packages for their >>> respective platforms. Thanks to everyone who made this possible. I'm >>> going to step away from my computer for a while and enjoy the adult >>> beverage of my choice. >>> >>> Cheers, >>> >>> Wayne >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of Spice net-list from EESchema
Hello, I've got no opinions, so I implemented the patch(es). Please look at it. I've tested it with LTSpiceIV and NgSpice, and they both now work without a problem with the standard KiCad components. No special components for simulation purposes are needed. Best regards, Martin. - Původní zpráva - Odesílatel: x...@sms.cz Příjemce: kicad-developers@lists.launchpad.net Datum: Tue, 03 Nov 2015 16:44:46 +0100 Předmět: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of Spice net-list from EESchema > Hello, > > I reported the bug #1511552 and suggested to provide a patch. I'd like to hear > your suggestions and objections to what I was to going to do. > > In short (details in the bug report): > > In EESchema, it is hard to create a schema that can be used simultaneously for > Spice simulations and Pcb creations. For instance, because the pin order of > the components for Pcb and for Spice needs to be different. The following two > patches have resolved some of the problems: #706558, #743027. But there are > still other problems that persist: > > 1. Prefixes of component references in schemas follow different conventions > (e.g. https://en.wikipedia.org/wiki/Reference_designator) than those required > by Spice. > > 2. Component values (like 3k3 or 2M7) commonly used in schemas don't work in > Spice. > > 3. The default KiCad component libraries are not prepared for Spice > simulations. Which is a problem for a KiCad newbie who a) does not have his > own modified libraries b) isn't even aware of the need of such library > modifications and wonders why the simulation doesn't work (like me some days > ago). > > So I'm proposing to create another patch in the line of the two already > accepted patches, as described in the bug report. I'm aware that the current > Spice netlist exporter is poorly designed and that the two already accepted > patches are kind of hack. And my patch will be no different. But I don't have > time and energy to implement a full-featured Spice support. > > Please, read my intended patch design in > https://bugs.launchpad.net/kicad/+bug/1511552/comments/2, and provide comments > and suggestions. So that I don't spend my time on an improvement of a feature > that will be rejected then. It's possible to implement only some of the > suggested points, and leave the rest for a post-processing. > > Thank you, > Martin. > __ > Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, > @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz > COMDOM Antispam - www.comdomsoft.com > > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > -- __ Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz COMDOM Antispam - www.comdomsoft.com ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
This should be correct now. Thanks for the heads up. On 11/9/2015 7:29 AM, Brian Sidebotham wrote: > Wayne, You've released the source tarball against the RC1 milestone. > I'd delete it from there and re-release it against the RC2 milestone. > > Best Regards, > > Brian. > > On 9 November 2015 at 08:17, Nick Østergaard wrote: >> I just jumped directly to https://launchpad.net/kicad and hovering on >> the download links on the right you can see those links. >> >> 2015-11-09 2:37 GMT+01:00 Wayne Stambaugh : >>> That is strange. I wonder if the path has something to do with what >>> page is open when you upload it. As long as users can download the file >>> it should be OK. If I get some time, I'll mess around with it and see >>> if I can get it in the https://launchpad.net/kicad/4.0 path. >>> >>> On 11/8/2015 6:01 PM, Nick Østergaard wrote: Hi Wayne Thank you for realasing. Although the download link is a bit strange.. it still partly refers to rc1. https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz But anyway, I guess we can just say that the docs, and their translations, and the GUI translations shall be done in two weeks if they want to be included with the release. The same witht he libs, if anything is is left to be done, and we can just take a snapshot of the libs and put it on the download page. 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : > I just finished up getting all of the relevant code for RC2 uploaded to > launchpad so let's fire up those autobuilders and get some rc2 packages > out there for testing. I'm hoping this will be the last rc before the > stable release. Let's keep our fingers crossed. We need start thinking > about branching or tagging the library, documentation, and translation > repos so that packagers can build consistent packages for their > respective platforms. Thanks to everyone who made this possible. I'm > going to step away from my computer for a while and enjoy the adult > beverage of my choice. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >>> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plans for (OpenGL-/Cairo-/Default-) canvases after stable?
2015-11-09 9:49 GMT+01:00 Tomasz Wlostowski : > On 08.11.2015 22:43, Bernhard Stegmaier wrote: >> is there any roadmap/plan for how to go on with the three canvases in pcbnew >> after the stable release? > > Hi Bernhard, > > Yes, there is a plan. In short: > - Port the remaining features of the "legacy" canvas such as component > auto-placement or delete-track-while-routing to the GAL. We'll > appreciate any help with assembling a list of features still missing in > the GAL canvases. There are some bugs that mention missing ports of some tools. Should we start to tag bug reports with a new tag to distinguis/find them easily? And then we can add new bugs with that tag to compose this list of features still missing in the GAL canvases? Tag suggestion: missing-tool or others? > - Improve the speed of the Cairo renderer so it's fast enough at least > for an Arduino-sized board. > - Drop the legacy canvas before the next stable release. > > Regards, > Tom > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] auto-place footprints small bug
IFAIK, the autoplace routine uses the board outline bounding box which will be a rectangle created by merging all of the outline drawing items so the results you are seeing are not surprising. The autoplace tool is very crude. We would have to move to a fully polygonal design to accomplish what you are trying to do. You could add it to the wishlist but it will be fairly low on the priority list. On 11/7/2015 7:06 PM, Marco Ciampa wrote: > If you create a non rectangular, say circular, edge cut shape, autoplace > footprint function thinks it is rectangular and puts elements inside and > outside borders. I did not tried complex shapes but it should misbehave > similarly... > > Please test if it's me that I am not able to use it... > > Regards, > > -- > > > Marco Ciampa > > I know a joke about UDP, but you might not get it. > > ++ > | GNU/Linux User #78271 | > | FSFE fellow #364 | > ++ > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of Spice net-list from EESchema
Martin, I've expressed my concerns about your proposal in the bug tracker but I will elaborate on that on the dev mailing list so other devs can give you there feedback as well. Your proposed changes may solve your immediate problem but the present more of their own. What I am proposing is a robust solution that doesn't rely on heuristics and assumptions and does not create maintenance issues for our library devs. Here is what I would accept: 1) Create a custom spice library with the appropriate symbols with custom spice fields. I prefer not to have spice fields in the stanard symbol libraries. If you need footprints to correctly match you spice symbol library, than you should create them as well if you want to product boards from your spice schematics. Most users that I know will create separate circuits for simulation. This also removes the burden of the lib devs to add the "Spice_Node_Sequence" field to every new symbol that requires it. 2) Do not attempt to convert schematic values to spice values (1M to 1MEG). This is a solution in search of a problem. It obfuscates how spice works and will lead to as many problems as it solves. 3) Rather than use a specific field like "Spice_Node_Sequence" to set a single spice parameter, use a generic field name like "spice" with key/value pairs so that you can include any spice specific settings in a single field. For example a "spice" field of "node_seq=C,B,E trans_type=X model=/path/to/spice_model.sp1, ..." could be used to set the node sequence, the spice transistor model type of a transistor symbol, and the spice model file for a symbol. No need guess about the transistor spice model type. This would be fairly straight forward to do with wxStringTokenizer. You would need to decide on a separator that makes the most sense. A space would probably not be the best choice if you want to use file names and paths. A ; or : might be a better choice. On 11/3/2015 10:44 AM, x...@sms.cz wrote: > Hello, > > I reported the bug #1511552 and suggested to provide a patch. I'd like to hear > your suggestions and objections to what I was to going to do. > > In short (details in the bug report): > > In EESchema, it is hard to create a schema that can be used simultaneously for > Spice simulations and Pcb creations. For instance, because the pin order of > the components for Pcb and for Spice needs to be different. The following two > patches have resolved some of the problems: #706558, #743027. But there are > still other problems that persist: > > 1. Prefixes of component references in schemas follow different conventions > (e.g. https://en.wikipedia.org/wiki/Reference_designator) than those required > by Spice. > > 2. Component values (like 3k3 or 2M7) commonly used in schemas don't work in > Spice. > > 3. The default KiCad component libraries are not prepared for Spice > simulations. Which is a problem for a KiCad newbie who a) does not have his > own modified libraries b) isn't even aware of the need of such library > modifications and wonders why the simulation doesn't work (like me some days > ago). > > So I'm proposing to create another patch in the line of the two already > accepted patches, as described in the bug report. I'm aware that the current > Spice netlist exporter is poorly designed and that the two already accepted > patches are kind of hack. And my patch will be no different. But I don't have > time and energy to implement a full-featured Spice support. > > Please, read my intended patch design in > https://bugs.launchpad.net/kicad/+bug/1511552/comments/2, and provide comments > and suggestions. So that I don't spend my time on an improvement of a feature > that will be rejected then. It's possible to implement only some of the > suggested points, and leave the rest for a post-processing. > > Thank you, > Martin. > __ > Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, > @potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz > COMDOM Antispam - www.comdomsoft.com > > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
On 11/9/2015 9:13 AM, Nick Østergaard wrote: > 2015-11-09 14:54 GMT+01:00 Wayne Stambaugh : >> On 11/8/2015 6:01 PM, Nick Østergaard wrote: >>> Hi Wayne >>> >>> Thank you for realasing. Although the download link is a bit strange.. >>> it still partly refers to rc1. >>> >>> https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz >>> >>> But anyway, I guess we can just say that the docs, and their >>> translations, and the GUI translations shall be done in two weeks if >>> they want to be included with the release. The same witht he libs, if >>> anything is is left to be done, and we can just take a snapshot of the >>> libs and put it on the download page. >> >> I'm wondering if we should branch the translation and doc repos. Once >> new features and strings are added to kicad during the next development >> cycle, updating the translation and doc repos will not make sense >> against the 4.0 stable release of kicad. Creating 4.0 branches of the >> doc and translation repos would allow for new translations and improved >> documentation for the 4.0 stable release. There would be some >> cross-over between the 4.0 and development repos which would be a bit >> more work. I'm OK with tagging the current repos as well. The downside >> to that is there will be no new translations or doc improvements until >> the next stable release. I'll leave that up to the doc and translation >> folks. Tagging and a snapshot archive makes sense for the lib repo. > > I think just tagging it should be sufficient to generate a release > tarball on github (4.0.0.0). If we need followup changes we can make a > leaf branch from there or later on the master branch with 4.0.0.1. I > don't think -n is good here, because multiple packaging systems use a > dash number notation to describe revisions of the packaging scripts > themselves. The triplet is reserved to the kicad source, so we must > need some other indicator for auxiliary stuff. But we really need to > align the version numbers across the source code, docs, translations > and libs. I just thought of something. We will need a way to fetch the built documentation for packaging on platforms that don't have the native tools to build the docs from source. I still have not had any success building the docs from source on windows. This means that if we do tag the doc repo rather than branch it, we will need to be able provide builds from the tagged version of at least the pdf files for all languages. I'm assuming this can be done. If not, we will have to find alternative. > >>> 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : I just finished up getting all of the relevant code for RC2 uploaded to launchpad so let's fire up those autobuilders and get some rc2 packages out there for testing. I'm hoping this will be the last rc before the stable release. Let's keep our fingers crossed. We need start thinking about branching or tagging the library, documentation, and translation repos so that packagers can build consistent packages for their respective platforms. Thanks to everyone who made this possible. I'm going to step away from my computer for a while and enjoy the adult beverage of my choice. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
Yes, this can be done very easily. There is already binaries on http://docs.kicad-pcb.org/ that can be downloaded as a zip or tar.gz file. I might try to tage some with an rc2 tag to prepare everything and every packager. I forgot to do that, but probably tomorrow. 2015-11-09 22:23 GMT+01:00 Wayne Stambaugh : > > > On 11/9/2015 9:13 AM, Nick Østergaard wrote: >> 2015-11-09 14:54 GMT+01:00 Wayne Stambaugh : >>> On 11/8/2015 6:01 PM, Nick Østergaard wrote: Hi Wayne Thank you for realasing. Although the download link is a bit strange.. it still partly refers to rc1. https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz But anyway, I guess we can just say that the docs, and their translations, and the GUI translations shall be done in two weeks if they want to be included with the release. The same witht he libs, if anything is is left to be done, and we can just take a snapshot of the libs and put it on the download page. >>> >>> I'm wondering if we should branch the translation and doc repos. Once >>> new features and strings are added to kicad during the next development >>> cycle, updating the translation and doc repos will not make sense >>> against the 4.0 stable release of kicad. Creating 4.0 branches of the >>> doc and translation repos would allow for new translations and improved >>> documentation for the 4.0 stable release. There would be some >>> cross-over between the 4.0 and development repos which would be a bit >>> more work. I'm OK with tagging the current repos as well. The downside >>> to that is there will be no new translations or doc improvements until >>> the next stable release. I'll leave that up to the doc and translation >>> folks. Tagging and a snapshot archive makes sense for the lib repo. >> >> I think just tagging it should be sufficient to generate a release >> tarball on github (4.0.0.0). If we need followup changes we can make a >> leaf branch from there or later on the master branch with 4.0.0.1. I >> don't think -n is good here, because multiple packaging systems use a >> dash number notation to describe revisions of the packaging scripts >> themselves. The triplet is reserved to the kicad source, so we must >> need some other indicator for auxiliary stuff. But we really need to >> align the version numbers across the source code, docs, translations >> and libs. > > I just thought of something. We will need a way to fetch the built > documentation for packaging on platforms that don't have the native > tools to build the docs from source. I still have not had any success > building the docs from source on windows. This means that if we do tag > the doc repo rather than branch it, we will need to be able provide > builds from the tagged version of at least the pdf files for all > languages. I'm assuming this can be done. If not, we will have to find > alternative. > >> 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : > I just finished up getting all of the relevant code for RC2 uploaded to > launchpad so let's fire up those autobuilders and get some rc2 packages > out there for testing. I'm hoping this will be the last rc before the > stable release. Let's keep our fingers crossed. We need start thinking > about branching or tagging the library, documentation, and translation > repos so that packagers can build consistent packages for their > respective platforms. Thanks to everyone who made this possible. I'm > going to step away from my computer for a while and enjoy the adult > beverage of my choice. > > Cheers, > > Wayne > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RC2 has been released.
No hurry. Just something to think about before the stable release. Thanks. On 11/9/2015 4:26 PM, Nick Østergaard wrote: > Yes, this can be done very easily. There is already binaries on > http://docs.kicad-pcb.org/ that can be downloaded as a zip or tar.gz > file. I might try to tage some with an rc2 tag to prepare everything > and every packager. I forgot to do that, but probably tomorrow. > > 2015-11-09 22:23 GMT+01:00 Wayne Stambaugh : >> >> >> On 11/9/2015 9:13 AM, Nick Østergaard wrote: >>> 2015-11-09 14:54 GMT+01:00 Wayne Stambaugh : On 11/8/2015 6:01 PM, Nick Østergaard wrote: > Hi Wayne > > Thank you for realasing. Although the download link is a bit strange.. > it still partly refers to rc1. > > https://launchpad.net/kicad/4.0/4.0.0-rc1/+download/kicad-4.0.0-rc2.tar.xz > > But anyway, I guess we can just say that the docs, and their > translations, and the GUI translations shall be done in two weeks if > they want to be included with the release. The same witht he libs, if > anything is is left to be done, and we can just take a snapshot of the > libs and put it on the download page. I'm wondering if we should branch the translation and doc repos. Once new features and strings are added to kicad during the next development cycle, updating the translation and doc repos will not make sense against the 4.0 stable release of kicad. Creating 4.0 branches of the doc and translation repos would allow for new translations and improved documentation for the 4.0 stable release. There would be some cross-over between the 4.0 and development repos which would be a bit more work. I'm OK with tagging the current repos as well. The downside to that is there will be no new translations or doc improvements until the next stable release. I'll leave that up to the doc and translation folks. Tagging and a snapshot archive makes sense for the lib repo. >>> >>> I think just tagging it should be sufficient to generate a release >>> tarball on github (4.0.0.0). If we need followup changes we can make a >>> leaf branch from there or later on the master branch with 4.0.0.1. I >>> don't think -n is good here, because multiple packaging systems use a >>> dash number notation to describe revisions of the packaging scripts >>> themselves. The triplet is reserved to the kicad source, so we must >>> need some other indicator for auxiliary stuff. But we really need to >>> align the version numbers across the source code, docs, translations >>> and libs. >> >> I just thought of something. We will need a way to fetch the built >> documentation for packaging on platforms that don't have the native >> tools to build the docs from source. I still have not had any success >> building the docs from source on windows. This means that if we do tag >> the doc repo rather than branch it, we will need to be able provide >> builds from the tagged version of at least the pdf files for all >> languages. I'm assuming this can be done. If not, we will have to find >> alternative. >> >>> > 2015-11-08 23:11 GMT+01:00 Wayne Stambaugh : >> I just finished up getting all of the relevant code for RC2 uploaded to >> launchpad so let's fire up those autobuilders and get some rc2 packages >> out there for testing. I'm hoping this will be the last rc before the >> stable release. Let's keep our fingers crossed. We need start thinking >> about branching or tagging the library, documentation, and translation >> repos so that packagers can build consistent packages for their >> respective platforms. Thanks to everyone who made this possible. I'm >> going to step away from my computer for a while and enjoy the adult >> beverage of my choice. >> >> Cheers, >> >> Wayne >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] howto getting pcbnew board path and name from inside python console
I just check this an on windows using process viewer and KIPRJMOD is set
to path where the board file is located. If there is no pro file and
the path is writable, pcbnew will create a default pro in the same path.
On 11/3/2015 4:18 AM, easyw wrote:
> Hi,
> if I open a project in kicad and then the board I can get the var import os
> os.getenv('KIPRJMOD')
>
> but if I open just the board directly from pcbnew, the var is empty...
>
> in which way I can get board name and path?
>
> thanx
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Plans for (OpenGL-/Cairo-/Default-) canvases after stable?
On 11/9/2015 1:49 PM, Nick Østergaard wrote: > 2015-11-09 9:49 GMT+01:00 Tomasz Wlostowski : >> On 08.11.2015 22:43, Bernhard Stegmaier wrote: >>> is there any roadmap/plan for how to go on with the three canvases in >>> pcbnew after the stable release? >> >> Hi Bernhard, >> >> Yes, there is a plan. In short: >> - Port the remaining features of the "legacy" canvas such as component >> auto-placement or delete-track-while-routing to the GAL. We'll >> appreciate any help with assembling a list of features still missing in >> the GAL canvases. > > There are some bugs that mention missing ports of some tools. Should > we start to tag bug reports with a new tag to distinguis/find them > easily? And then we can add new bugs with that tag to compose this > list of features still missing in the GAL canvases? Tag suggestion: > missing-tool or others? missing-gal-tool? Makes sense to me. This way they can be tagged as fixed as they are implemented. > >> - Improve the speed of the Cairo renderer so it's fast enough at least >> for an Arduino-sized board. >> - Drop the legacy canvas before the next stable release. >> >> Regards, >> Tom >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of Spice net-list from EESchema
Wayne, thank you for your reaction. Here I'll state how I see it and comment your answer. At first, I'd like to say that I tried to make no revolution, but only to extend the functionality that already IS in KiCad the same way it is implemented NOW. I can imagine a better realisation of the functionality I implemented. Especially, if KiCad supported plugins, I would create my own plugin and didn't try to persuade you to accept my patch. Hopefully, if Mark Roszko implements a general netlist generator he announced, the problem might get resolved. In point 3) you write that you don't like the user field "Spice_Node_Sequence". Neither do I. But this user field IS already supported by KiCad, I didn't make it up. And there is also another one, "Spice_Model" (or rather "spice_model"). They were introduced in a patch five years ago, see my bug for the reference. So I only added a third field. And tried to stay backward compatible. Technically I could do it the way you suggest, but this would require diversion from the way how the functionality is implemented now. I tried to avoid that in the perspective that my patch will be accepted more easily. In point 2) you suggest not to translate schematic values. My view is this: When you draw an electric schema, you follow customs of electric schemas - e.g. you use "Q" for a transistor reference and "2M2" for a resistor value. Why should you break this convention only because you're going to use the schema for Spice simulation? My idea is that the schema should be "agnostic", it should look the same and use the same components whatever the purpose is for which it was created. Of course, you can say that you don't want it to be agnostic. But why, if this can be achieved quite easily? There is also another way how to look at it. KiCad uses a language, Spice uses a different one. The intent of the netlist exporter is to do the translation from the KiCad language to the Spice language. If you speak English and your collegue speaks Chinese, you would use English words in your speach, and not mix it with Chinese words to make the task of the interpreter easier. The same way, there's no reason for why you should use Spice values in your KiCad schema, you should keep with standards. I've already tried to create several schemas with standard KiCad libraries in my patched copy of KiCad and simulate them directly in NgSpice and LTSpiceIV. And that worked like a charm. So why to defend against that possibility? In point 1) you mention mainly maintenance problems of the libraries. In fact, I patched the libraries only because I thought it might be a good idea to help beginners with KiCad. As I remember myself how much effort it was to learn that I cannot use the standard libraries for simulations. And then to find libraries that work. Because e.g. the KiCad "pspice.lib" does not work either (the diode there has an incorrect order of pins). But the modified library is not a merit of the patch, it's just a bonus that could help others. I accept that there may be a problem of maintenance. But also, I'd like to emphasize that the libraries are not altered in any way, they are only amended with the information on Spice fields. They will work and look the same as before. To summarize it: Some of the changes can be performed in a post-processor. But not the correction of pin order and of reference prefixes. Because this information is not available to the post-processor. It should be part of the component definition, or be manually inserted into the el. schema. Anyway, the (code) patch is rather small and - in my view - makes working what should have been working already. Best regards, Martin. - Původní zpráva - Odesílatel: Wayne Stambaugh Příjemce: kicad-developers@lists.launchpad.net Datum: Mon, 9 Nov 2015 16:10:24 -0500 Předmět: Re: [Kicad-developers] Bug #1511552 - Fixes to Incorrect export of Spice net-list from EESchema > Martin, > > I've expressed my concerns about your proposal in the bug tracker but I > will elaborate on that on the dev mailing list so other devs can give > you there feedback as well. Your proposed changes may solve your > immediate problem but the present more of their own. What I am > proposing is a robust solution that doesn't rely on heuristics and > assumptions and does not create maintenance issues for our library devs. > Here is what I would accept: > > 1) Create a custom spice library with the appropriate symbols with > custom spice fields. I prefer not to have spice fields in the stanard > symbol libraries. If you need footprints to correctly match you spice > symbol library, than you should create them as well if you want to > product boards from your spice schematics. Most users that I know will > create separate circuits for simulation. This also removes the burden > of the lib devs to add the "Spice_Node_Sequence" field to every new > symbol that requires it. > > 2) Do not attempt to convert schematic values to
[Kicad-developers] Packaging questions for RC builds and 4.0.0 builds
Hi folks! What's the thought process here on making builds for RC and 4.0.x builds? I should probably have another job in the Mac Jenkins builder that just watches the 4.0 line, and when there are updates, it builds another build and pushes it somewhere on downloads.kicad-pcb.org--but not in the nightlies section. I'll change the text in the README too, removing references to nightlies. Any other changes/ideas that anyone can think of? Adam Wolf Cofounder and Engineer W&L, LLC ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Packaging questions for RC builds and 4.0.0 builds
What I did for the windows build was to make a new package description file which used the tarballs and I can just edit that and rerun manually. So yes, I think creating another job for it is a good/easy way to handle it. Because there are multiple "independent" repos it might not be ideal to auto trigger it. 2015-11-10 3:10 GMT+01:00 Adam Wolf : > Hi folks! > > What's the thought process here on making builds for RC and 4.0.x builds? > > I should probably have another job in the Mac Jenkins builder that just > watches the 4.0 line, and when there are updates, it builds another build > and pushes it somewhere on downloads.kicad-pcb.org--but not in the nightlies > section. > > I'll change the text in the README too, removing references to nightlies. > > Any other changes/ideas that anyone can think of? > > Adam Wolf > Cofounder and Engineer > W&L, LLC > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
