Re: [Kicad-developers] [PATCH] Missing library in template/kicad.pro

[Samuel Dolt]

Don’t commit my patch. It has some issues ( see my previous link to github).

Beside that it would be nice to move this file to kicad-library on Github. It 
will be easier to librarians to make change.

Thank you everyone for all your great work

Samuel Dolt


> Le 12 mars 2015 à 23:21, Samuel Dolt  a écrit :
> 
> Hi,
> 
> I just found that default kicad.pro file doesn’t have all library.
> 
> ( 
> https://github.com/samdolt/kicad-library/commit/9a1bf84ac7423f93d068f1908d4dc6e05773282b#commitcomment-10170392
>  
> 
>  )
> 
> Best Regards,
> Samuel Dolt
> 
> 
> 
> 
> ___
> 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] Launchpad bug status

[Brian Sidebotham]

On 12 March 2015 at 20:53, Wayne Stambaugh  wrote:
>
>
> On 3/12/2015 2:10 PM, Nick Østergaard wrote:
>> But now to my real comment on this: I don't think we should do this. I
>> might seem like a great concept at first, but rember the limited man
>> power, and not to forget it will not be too motivating for people in
>> the long run to do housekeeping on the tracker that, IMHO does not
>> really add any information, other than blur where the bugfix is
>> available. This is way more manual work, and this takes time and it
>> will even make it possible for some bugs not to be closed (here closed
>> means Fix Released) at all anyway.
>
> I don't see it that way.  Take bug
>
> https://bugs.launchpad.net/kicad/+bug/1428245
>
> for instance.  This bug fix has been release to the public in the
> product branch and nightly builds.  This bug has no meaning to the
> current stable release and only ever effected the product branch after
> the differential pair router code was merged.  I defy you to show me
> where in the bug report that shows which branch the bug report was filed
> against and what other branches it may or may not effect.  If we
> continue with the current system, it looks like we never fix any bugs
> when we actually fix most bugs fairly quickly.  There has got to a less
> confusing way to manage our bug tracker.

lp:kicad is the branch. Launchpad words things a bit weird in my
opinion. The fact is that you *can* target any of your series per bug.
This would not necessarily be the job the bug reporter, but instead
would be the job of a triager. Using the bug tracker effectively is
not just having a mass on untargetted bugs. So for each bug you get a
"target to series" link.

From the "target to series" you can select any of the series to place
this bug against. For the bug you linked to, just select product. If
you select both product and stable you get two sets of status for the
bug.

For KiCad, fix committed makes no sense for the product series, so
once a fix is committed you will probably go straight to fix released.
In Stable at the same time, assuming the fix is immediately
back-ported you would select Fix committed, then when you do a release
on that series, Launchpad marks all bugs set as Fix committed on the
stable series to Fix Released automatically. Of course, we currently
don't want to backport bugfixes to the stable branch and do bugfix
releases, but when someone's wanting to see if the bug is filed they
will (should?) search for bugs against the stable series and expect to
find a fix committed report.

All this takes careful resource though. To use the bug tracker
properly takes a lot of management, but if there are volunteers and
the system can be explained you'll have a much better view of what
bugs are currently against the product series. At the moment, there's
only 1 bug targeted at the product series! So it will take a large
triage effort to make sense of what's already there.

I created a quick dual-series targetted bug on KiCad-Winbuilder so you
can see what it looks like:
https://bugs.launchpad.net/kicad-winbuilder/+bug/1398881

Resource, Resource, Resource ( as I keep telling my bosses! )

Best Regards,

Brian.

___
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] Missing library in template/kicad.pro

[Samuel Dolt]

Hi,I just found that default kicad.pro file doesn’t have all library.( https://github.com/samdolt/kicad-library/commit/9a1bf84ac7423f93d068f1908d4dc6e05773282b#commitcomment-10170392 )Best Regards,Samuel Dolt

add_library_in_kicad_pro.diff
Description: Binary data

___
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] Better SHAPE_CONVEX for the PNS router

[Mathias Grimmberger]

Hi everybody,

below is an improved patch to add a SHAPE_CONVEX for the PNS router. The
patch was generated against revision 5508.

In this version nice tight octagonal "hulls" are created for convex
polygons. I think it should work for arbitrary convex polygons (as long
as the requested distance between polygon and hull is larger than about
20) - but this probably just means I overlooked some corner case.

A trace snaking around some pads each arbitrarily rotated looks quite
weird... ;-)

I also think I figured out the "breakouts" stuff. This works nicely for
pads rotated by 45 degrees, but looks weird if the pad is rotated e.g.
by 30 degrees.

Finally I fixed a small bug in SHAPE_LINE_CHAIN, which ignored the
parameter aClearance when computing a bounding box.


Enjoy,

MGri


=== modified file 'common/geometry/shape_collisions.cpp'
--- common/geometry/shape_collisions.cpp2015-03-09 10:06:54 +
+++ common/geometry/shape_collisions.cpp2015-03-12 19:44:01 +
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 typedef VECTOR2I::extended_type ecoord;
 
@@ -165,6 +166,32 @@
 }
 
 
+static inline bool Collide( const SHAPE_CIRCLE& aA, const SHAPE_CONVEX& aB, 
int aClearance,
+bool aNeedMTV, VECTOR2I& aMTV )
+{
+bool found;
+const SHAPE_LINE_CHAIN& lc( aB.Vertices() );
+
+found = lc.Distance( aA.GetCenter() ) <= aClearance + aA.GetRadius();
+
+if( !aNeedMTV || !found )
+return found;
+
+SHAPE_CIRCLE cmoved( aA );
+VECTOR2I f_total( 0, 0 );
+
+for( int s = 0; s < lc.SegmentCount(); s++ )
+{
+VECTOR2I f = pushoutForce( cmoved, lc.CSegment( s ), aClearance );
+cmoved.SetCenter( cmoved.GetCenter() + f );
+f_total += f;
+}
+
+aMTV = f_total;
+return found;
+}
+
+
 static inline bool Collide( const SHAPE_CIRCLE& aA, const SHAPE_SEGMENT& aSeg, 
int aClearance,
 bool aNeedMTV, VECTOR2I& aMTV )
 {
@@ -189,6 +216,20 @@
 }
 
 
+static inline bool Collide( const SHAPE_LINE_CHAIN& aA, const SHAPE_CONVEX& 
aB, int aClearance,
+bool aNeedMTV, VECTOR2I& aMTV )
+{
+return Collide( aA, aB.Vertices(), aClearance, aNeedMTV, aMTV );
+}
+
+
+static inline bool Collide( const SHAPE_CONVEX& aA, const SHAPE_CONVEX& aB, 
int aClearance,
+bool aNeedMTV, VECTOR2I& aMTV )
+{
+return Collide( aA.Vertices(), aB.Vertices(), aClearance, aNeedMTV, aMTV );
+}
+
+
 static inline bool Collide( const SHAPE_RECT& aA, const SHAPE_LINE_CHAIN& aB, 
int aClearance,
 bool aNeedMTV, VECTOR2I& aMTV )
 {
@@ -204,6 +245,13 @@
 }
 
 
+static inline bool Collide( const SHAPE_RECT& aA, const SHAPE_CONVEX& aB, int 
aClearance,
+bool aNeedMTV, VECTOR2I& aMTV )
+{
+return Collide( aA, aB.Vertices(), aClearance, aNeedMTV, aMTV );
+}
+
+
 static inline bool Collide( const SHAPE_RECT& aA, const SHAPE_SEGMENT& aSeg, 
int aClearance,
 bool aNeedMTV, VECTOR2I& aMTV )
 {
@@ -228,6 +276,13 @@
 }
 
 
+static inline bool Collide( const SHAPE_CONVEX& aA, const SHAPE_SEGMENT& aB, 
int aClearance,
+bool aNeedMTV, VECTOR2I& aMTV )
+{
+return Collide( aA.Vertices(), aB, aClearance, aNeedMTV, aMTV );
+}
+
+
 template
 inline bool CollCase( const SHAPE* aA, const SHAPE* aB, int aClearance, bool 
aNeedMTV, VECTOR2I& aMTV )
 {
@@ -264,6 +319,9 @@
 case SH_SEGMENT:
 return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
 
+case SH_CONVEX:
+return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
+
 default:
 break;
 }
@@ -283,6 +341,9 @@
 case SH_SEGMENT:
 return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
 
+case SH_CONVEX:
+return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
+
 default:
 break;
 }
@@ -302,6 +363,9 @@
 case SH_SEGMENT:
 return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
 
+case SH_CONVEX:
+return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
+
 default:
 break;
 }
@@ -321,10 +385,35 @@
 case SH_SEGMENT:
 return CollCase( aA, aB, 
aClearance, aNeedMTV, aMTV );
 
-default:
-break;
-}
-
+case SH_CONVEX:
+return CollCase( aB, aA, 
aClearance, aNeedMTV, aMTV );
+
+default:
+break;
+}
+
+case SH_CONVEX:
+switch( aB->Type() )
+{
+case SH_RECT:
+retu

Re: [Kicad-developers] Announcing work on providing windows nightlies

[Brian Sidebotham]

On 12 March 2015 at 17:48, Wayne Stambaugh  wrote:
>
>
> On 3/12/2015 1:37 PM, Nick Østergaard wrote:
>> 2015-03-12 18:26 GMT+01:00 Wayne Stambaugh :
>>>
>>>
>>> On 3/12/2015 1:26 PM, Nick Østergaard wrote:

 Den 12/03/2015 18.16 skrev "Wayne Stambaugh" >>> >:
>> [snip]
> FYI.  Using the msys2/mingw64 builds of wxWidgets 3.0.2-3, wxWidgets is
> compiled with -std=gnu++11 which breaks the KiCad build.  I'm guessing
> that KiCad will build with the -std=gnu++11 option but I haven't tried
> it yet.  I filed a bug report so I'm guessing it will be fixed soon so
> you may run into problems.  You can always downgrade the wxWidgets
> package to 3.0.2-2.

 I have not experinced any compilation issues, although I would like to
 use the new docs from ciampix repo and get the GUI translations in an
 more lightweight repo, for example in the new doc repo or even a
 standalone git repo. I am able to split the repo and keep comnit history.

 Byt maybe I am just not on -3. I will have a look later.
>>>
>>> It was just pushed to the repo yesterday so if you haven't upgraded in
>>> the last day or so, your still using -2.  I just tried to compile KiCad
>>> using -3 with -std=gnu++11 and now it's choking on boost.  Do yourself a
>>> favor an do not upgrade until -4 is released.
>>
>> Do you have a link to the report? I can't find it in the open issues
>> at Alexpux/MINGW-packages on github.
>
> I filed it on the old SourceForge bug tracker here:
>
> http://sourceforge.net/p/msys2/tickets/138

Nick, thank-you for posting this to the list!

Wayne,

Thanks for the confirmation. I was bit by this last night while trying
to test the KiCad-Winbuilder stuff. I soon realised that it was doomed
after the wxWidgets-3 push. Hopefully they'll get it sorted out pretty
quickly.

Thanks for reporting the bug, looks like they're getting on with it
pretty quickly.

This is exactly why it makes sense for us to use the pacman stuff to
build with; Because it's one build system that we're all trying to
support. Plus, it means no more maintenance of external projects like
wxwidgets-cmake, etc. for me! Phew!

Best Regards,

Brian.

___
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] Launchpad bug status

[Wayne Stambaugh]

On 3/12/2015 2:10 PM, Nick Østergaard wrote:
> 2015-03-12 16:45 GMT+01:00 Adam Wolf :
>> This sounds like a step up from what we're doing now.
> 
> Sort of and sort of not at all.
> 
>> On Thu, Mar 12, 2015 at 10:38 AM, Wayne Stambaugh 
>> wrote:
>>>
>>> There was a question asking how bugs are closed.
>>>
>>> https://answers.launchpad.net/kicad/+question/263366
>>>
>>> I didn't have a good answer so I dug around a bit and found some
>>> information on the Launchpad blog about the meaning of bug status tags.
>>>
>>> http://blog.launchpad.net/general/of-bugs-and-statuses
> 
> yeah... that is just how launchpad is.
> 
>>> I also changed the status of two bugs from "Fix Committed" to "Fix
>>> Released" and the "Open Bug" count was reduced by two.  Given the way we
>>> have been handling bugs, it looks like none of bugs are ever fixed.
>>> This is confusing for new developers and doesn't really make a lot of
>>> sense.  I am proposing that we change the way we handle bugs as follows:
>>>
>>> * Once a bug fix has been committed to the project branch it should be
>>> tagged as "Fix Committed" as we have always done.
> 
> Yes, keep this. But in addition to this, see some suggestions further down.
> 
>>> * The bug report status should be changed to "Fix Released" once bug is
>>> confirmed as fixed by someone other than the person that authored the
>>> bug fix.  I'm assuming bugs can be changed back to "New" if the
>>> committed fix did not actually fix the bug but I haven't tried it yet.
> 
> I sort of have a strong opinion on this. It is not like I have been
> comitting much to kicad, although I have sent a "micro" patch here and
> there for bug fixes. But I have been using a nice chunk of my spare
> time to improve KiCad by watching the bugtracker and try to keep it
> tidy, to help the "real" developers get motivated to fix bugs. This by
> making sure they will not meet bugs where not enough information is
> needed, and if possible and time allows, I will see if I can
> replicate. Again to give more datapoints for the one willing to fix
> the bug. I also try to do other things to motivate newcomers, but I
> will leave this out of this thread.
> 
> But now to my real comment on this: I don't think we should do this. I
> might seem like a great concept at first, but rember the limited man
> power, and not to forget it will not be too motivating for people in
> the long run to do housekeeping on the tracker that, IMHO does not
> really add any information, other than blur where the bugfix is
> available. This is way more manual work, and this takes time and it
> will even make it possible for some bugs not to be closed (here closed
> means Fix Released) at all anyway.

I don't see it that way.  Take bug

https://bugs.launchpad.net/kicad/+bug/1428245

for instance.  This bug fix has been release to the public in the
product branch and nightly builds.  This bug has no meaning to the
current stable release and only ever effected the product branch after
the differential pair router code was merged.  I defy you to show me
where in the bug report that shows which branch the bug report was filed
against and what other branches it may or may not effect.  If we
continue with the current system, it looks like we never fix any bugs
when we actually fix most bugs fairly quickly.  There has got to a less
confusing way to manage our bug tracker.

> 
>>> * For legacy bug fixes, if the "Fix Committed" date is over a month, it
>>> can be changed to "Fix Released" even if the fix has not been confirmed
>>> as long as there are no additional complaints after the committed fix.
> 
> I think the "Fix Released" should only be on bugs that is actually
> released as a "release" (also known as stable) and not a "nightly" or
> "product" version. The fact that launchpad does not consider a
> comitted bugfix closed is just terminology. If you search, you will
> see lengthly discussions on this on the bugs for launchpad, and
> probably on some mailing list somewhere.
> 
> What I think we should do, is to use the facilities that launchpad
> have and mark bugs for a release version, and then IIRC when the
> release is released, the bugs will be marked as fix released by the
> launchpad janitor.

I hope your right, if not we will have to go back through the bug list
an tag them as released manually which is no better than what I am
proposing.

> 
> So by keeping fix comitted on bugs against the product repo, will mean
> that users that use the either the release or nightly will have an
> easy time to see where the bugfix is. For example a bug could be fixed
> in the product, but then some user using the release version will note
> the same bug, he might even search the bug tracker and identify the
> bug that he is experincing, and he can see it is fix comitted. Then no
> further action is needed for anyone, which is good and how it should
> be.
> 
> Also we could start to use the "Confirmed" status some more, and point
> newcomers (and other d

Re: [Kicad-developers] Launchpad bug status

[Nick Østergaard]

2015-03-12 16:45 GMT+01:00 Adam Wolf :
> This sounds like a step up from what we're doing now.

Sort of and sort of not at all.

> On Thu, Mar 12, 2015 at 10:38 AM, Wayne Stambaugh 
> wrote:
>>
>> There was a question asking how bugs are closed.
>>
>> https://answers.launchpad.net/kicad/+question/263366
>>
>> I didn't have a good answer so I dug around a bit and found some
>> information on the Launchpad blog about the meaning of bug status tags.
>>
>> http://blog.launchpad.net/general/of-bugs-and-statuses

yeah... that is just how launchpad is.

>> I also changed the status of two bugs from "Fix Committed" to "Fix
>> Released" and the "Open Bug" count was reduced by two.  Given the way we
>> have been handling bugs, it looks like none of bugs are ever fixed.
>> This is confusing for new developers and doesn't really make a lot of
>> sense.  I am proposing that we change the way we handle bugs as follows:
>>
>> * Once a bug fix has been committed to the project branch it should be
>> tagged as "Fix Committed" as we have always done.

Yes, keep this. But in addition to this, see some suggestions further down.

>> * The bug report status should be changed to "Fix Released" once bug is
>> confirmed as fixed by someone other than the person that authored the
>> bug fix.  I'm assuming bugs can be changed back to "New" if the
>> committed fix did not actually fix the bug but I haven't tried it yet.

I sort of have a strong opinion on this. It is not like I have been
comitting much to kicad, although I have sent a "micro" patch here and
there for bug fixes. But I have been using a nice chunk of my spare
time to improve KiCad by watching the bugtracker and try to keep it
tidy, to help the "real" developers get motivated to fix bugs. This by
making sure they will not meet bugs where not enough information is
needed, and if possible and time allows, I will see if I can
replicate. Again to give more datapoints for the one willing to fix
the bug. I also try to do other things to motivate newcomers, but I
will leave this out of this thread.

But now to my real comment on this: I don't think we should do this. I
might seem like a great concept at first, but rember the limited man
power, and not to forget it will not be too motivating for people in
the long run to do housekeeping on the tracker that, IMHO does not
really add any information, other than blur where the bugfix is
available. This is way more manual work, and this takes time and it
will even make it possible for some bugs not to be closed (here closed
means Fix Released) at all anyway.

>> * For legacy bug fixes, if the "Fix Committed" date is over a month, it
>> can be changed to "Fix Released" even if the fix has not been confirmed
>> as long as there are no additional complaints after the committed fix.

I think the "Fix Released" should only be on bugs that is actually
released as a "release" (also known as stable) and not a "nightly" or
"product" version. The fact that launchpad does not consider a
comitted bugfix closed is just terminology. If you search, you will
see lengthly discussions on this on the bugs for launchpad, and
probably on some mailing list somewhere.

What I think we should do, is to use the facilities that launchpad
have and mark bugs for a release version, and then IIRC when the
release is released, the bugs will be marked as fix released by the
launchpad janitor.

So by keeping fix comitted on bugs against the product repo, will mean
that users that use the either the release or nightly will have an
easy time to see where the bugfix is. For example a bug could be fixed
in the product, but then some user using the release version will note
the same bug, he might even search the bug tracker and identify the
bug that he is experincing, and he can see it is fix comitted. Then no
further action is needed for anyone, which is good and how it should
be.

Also we could start to use the "Confirmed" status some more, and point
newcomers (and other devs) to the confirmed bugs, if they want a task.
Then people like be can spend more time on the "New" bugs instead.

But in short. I think manually marking bugs as "Fix released" should
not be done.

Also a tip; people should start using the advanced search filter to
get the bug characteristics they are interrested in. If you use
firefox, you can bookmark it and give it a certain key, you can just
write in the address field. I use "kb" for the bugs that I look at the
most. Alternatively just a regular bookmark.

>> If anyone has any comments, please speak up.  Once we have a consensus
>> on this, I will make it an official project policy.

I have spoken. I hope you will seriously consider my response, even
though I wrote a lot of text. If the last part is a bit unclear or you
disagree (or even agree), please reply.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.n

Re: [Kicad-developers] Announcing work on providing windows nightlies

[Wayne Stambaugh]

On 3/12/2015 1:37 PM, Nick Østergaard wrote:
> 2015-03-12 18:26 GMT+01:00 Wayne Stambaugh :
>>
>>
>> On 3/12/2015 1:26 PM, Nick Østergaard wrote:
>>>
>>> Den 12/03/2015 18.16 skrev "Wayne Stambaugh" >> >:
> [snip]
 FYI.  Using the msys2/mingw64 builds of wxWidgets 3.0.2-3, wxWidgets is
 compiled with -std=gnu++11 which breaks the KiCad build.  I'm guessing
 that KiCad will build with the -std=gnu++11 option but I haven't tried
 it yet.  I filed a bug report so I'm guessing it will be fixed soon so
 you may run into problems.  You can always downgrade the wxWidgets
 package to 3.0.2-2.
>>>
>>> I have not experinced any compilation issues, although I would like to
>>> use the new docs from ciampix repo and get the GUI translations in an
>>> more lightweight repo, for example in the new doc repo or even a
>>> standalone git repo. I am able to split the repo and keep comnit history.
>>>
>>> Byt maybe I am just not on -3. I will have a look later.
>>
>> It was just pushed to the repo yesterday so if you haven't upgraded in
>> the last day or so, your still using -2.  I just tried to compile KiCad
>> using -3 with -std=gnu++11 and now it's choking on boost.  Do yourself a
>> favor an do not upgrade until -4 is released.
> 
> Do you have a link to the report? I can't find it in the open issues
> at Alexpux/MINGW-packages on github.

I filed it on the old SourceForge bug tracker here:

http://sourceforge.net/p/msys2/tickets/138

> 
>
> We hope to get the repo under the KiCad umbrella to keep it together
> in one place.
>
> For nightly builds Adam Wolf has offered a build server, so he will
> eventually start pushing builds to [4] as we do for the OS X builds.
>
> Regards
> Nick Østergaard
>
> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> [3] http://www2.futureware.at/~nickoe/
> [4] http://downloads.kicad-pcb.org/

___
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] Announcing work on providing windows nightlies

[Nick Østergaard]

2015-03-12 18:26 GMT+01:00 Wayne Stambaugh :
>
>
> On 3/12/2015 1:26 PM, Nick Østergaard wrote:
>>
>> Den 12/03/2015 18.16 skrev "Wayne Stambaugh" > >:
[snip]
>>> FYI.  Using the msys2/mingw64 builds of wxWidgets 3.0.2-3, wxWidgets is
>>> compiled with -std=gnu++11 which breaks the KiCad build.  I'm guessing
>>> that KiCad will build with the -std=gnu++11 option but I haven't tried
>>> it yet.  I filed a bug report so I'm guessing it will be fixed soon so
>>> you may run into problems.  You can always downgrade the wxWidgets
>>> package to 3.0.2-2.
>>
>> I have not experinced any compilation issues, although I would like to
>> use the new docs from ciampix repo and get the GUI translations in an
>> more lightweight repo, for example in the new doc repo or even a
>> standalone git repo. I am able to split the repo and keep comnit history.
>>
>> Byt maybe I am just not on -3. I will have a look later.
>
> It was just pushed to the repo yesterday so if you haven't upgraded in
> the last day or so, your still using -2.  I just tried to compile KiCad
> using -3 with -std=gnu++11 and now it's choking on boost.  Do yourself a
> favor an do not upgrade until -4 is released.

Do you have a link to the report? I can't find it in the open issues
at Alexpux/MINGW-packages on github.

>>> >
>>> > We hope to get the repo under the KiCad umbrella to keep it together
>>> > in one place.
>>> >
>>> > For nightly builds Adam Wolf has offered a build server, so he will
>>> > eventually start pushing builds to [4] as we do for the OS X builds.
>>> >
>>> > Regards
>>> > Nick Østergaard
>>> >
>>> > [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
>>> > [2] https://github.com/nickoe/kicad-windows-nsis-packaging
>>> > [3] http://www2.futureware.at/~nickoe/
>>> > [4] http://downloads.kicad-pcb.org/

___
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] Announcing work on providing windows nightlies

[Wayne Stambaugh]

On 3/12/2015 1:26 PM, Nick Østergaard wrote:
> 
> Den 12/03/2015 18.16 skrev "Wayne Stambaugh"  >:
>>
>>
>>
>> On 3/12/2015 12:00 PM, Jonatas wrote:
>> > Great job,
>> >
>> > Last week I made a compilation test using own msys2 64bis packages
>> > (mingw_x86_64 *). He did compile kicad in 64bis successfully. Not tested
>> > it working yet, but the interface opens normally.
>> >
>> > It will be great to have build night of windows. Compiling from source
>> > is painful and takes time.
>> >
>> > I suggest you have the binary version of the 64bit kicad. Currently
>> > kicad-WinBuilder makes only 32 bits of binary of kicad.
>> >
>> > greetings,
>> >
>> > Jonatas Evaristo
>> > Electronic Engineer
>> >
>> > 2015-03-12 9:14 GMT-03:00 Nick Østergaard  
>> > >>:
>> >
>> > Greetings
>> >
>> > Just to announce it for the people interested: Windows nightlies
>> > should soon be a reality.
>> >
>> > A week or so ago I started looking into packaging the windows builds
>> > that was created in MSYS2, where I made a script and upgraded
> the NSIS
>> > install script to make it work together, including python scripting.
>> > This currently seems to work. My work is currently hosted on
> [2], but
>> > I will try to merge it with [1] soon. I have stashed some builds on
>> > [3], that interested people can try out. Be aware that they are in
>> > testing, but feedback would be appreciated.
>> >
>> > I discovered that Brian Sidebotham was looking into making the kicad
>> > winbuilder use MSYS2, so I am working together with Brian Sidebotham
>> > on upgrading the kicad winbuilder to use the MSYS2 environment,
> which
>> > should ease the creation of the toolchain and the dependencies. This
>> > work is currently on [1].
>>
>> FYI.  Using the msys2/mingw64 builds of wxWidgets 3.0.2-3, wxWidgets is
>> compiled with -std=gnu++11 which breaks the KiCad build.  I'm guessing
>> that KiCad will build with the -std=gnu++11 option but I haven't tried
>> it yet.  I filed a bug report so I'm guessing it will be fixed soon so
>> you may run into problems.  You can always downgrade the wxWidgets
>> package to 3.0.2-2.
> 
> I have not experinced any compilation issues, although I would like to
> use the new docs from ciampix repo and get the GUI translations in an
> more lightweight repo, for example in the new doc repo or even a
> standalone git repo. I am able to split the repo and keep comnit history.
> 
> Byt maybe I am just not on -3. I will have a look later.

It was just pushed to the repo yesterday so if you haven't upgraded in
the last day or so, your still using -2.  I just tried to compile KiCad
using -3 with -std=gnu++11 and now it's choking on boost.  Do yourself a
favor an do not upgrade until -4 is released.

> 
>> >
>> > We hope to get the repo under the KiCad umbrella to keep it together
>> > in one place.
>> >
>> > For nightly builds Adam Wolf has offered a build server, so he will
>> > eventually start pushing builds to [4] as we do for the OS X builds.
>> >
>> > Regards
>> > Nick Østergaard
>> >
>> > [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
>> > [2] https://github.com/nickoe/kicad-windows-nsis-packaging
>> > [3] http://www2.futureware.at/~nickoe/
>> > [4] http://downloads.kicad-pcb.org/
>> >
>> > ___
>> > 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] Announcing work on providing windows nightlies

[Nick Østergaard]

Den 12/03/2015 18.16 skrev "Wayne Stambaugh" :
>
>
>
> On 3/12/2015 12:00 PM, Jonatas wrote:
> > Great job,
> >
> > Last week I made a compilation test using own msys2 64bis packages
> > (mingw_x86_64 *). He did compile kicad in 64bis successfully. Not tested
> > it working yet, but the interface opens normally.
> >
> > It will be great to have build night of windows. Compiling from source
> > is painful and takes time.
> >
> > I suggest you have the binary version of the 64bit kicad. Currently
> > kicad-WinBuilder makes only 32 bits of binary of kicad.
> >
> > greetings,
> >
> > Jonatas Evaristo
> > Electronic Engineer
> >
> > 2015-03-12 9:14 GMT-03:00 Nick Østergaard  > >:
> >
> > Greetings
> >
> > Just to announce it for the people interested: Windows nightlies
> > should soon be a reality.
> >
> > A week or so ago I started looking into packaging the windows builds
> > that was created in MSYS2, where I made a script and upgraded the
NSIS
> > install script to make it work together, including python scripting.
> > This currently seems to work. My work is currently hosted on [2],
but
> > I will try to merge it with [1] soon. I have stashed some builds on
> > [3], that interested people can try out. Be aware that they are in
> > testing, but feedback would be appreciated.
> >
> > I discovered that Brian Sidebotham was looking into making the kicad
> > winbuilder use MSYS2, so I am working together with Brian Sidebotham
> > on upgrading the kicad winbuilder to use the MSYS2 environment,
which
> > should ease the creation of the toolchain and the dependencies. This
> > work is currently on [1].
>
> FYI.  Using the msys2/mingw64 builds of wxWidgets 3.0.2-3, wxWidgets is
> compiled with -std=gnu++11 which breaks the KiCad build.  I'm guessing
> that KiCad will build with the -std=gnu++11 option but I haven't tried
> it yet.  I filed a bug report so I'm guessing it will be fixed soon so
> you may run into problems.  You can always downgrade the wxWidgets
> package to 3.0.2-2.

I have not experinced any compilation issues, although I would like to use
the new docs from ciampix repo and get the GUI translations in an more
lightweight repo, for example in the new doc repo or even a standalone git
repo. I am able to split the repo and keep comnit history.

Byt maybe I am just not on -3. I will have a look later.

> >
> > We hope to get the repo under the KiCad umbrella to keep it together
> > in one place.
> >
> > For nightly builds Adam Wolf has offered a build server, so he will
> > eventually start pushing builds to [4] as we do for the OS X builds.
> >
> > Regards
> > Nick Østergaard
> >
> > [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> > [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> > [3] http://www2.futureware.at/~nickoe/
> > [4] http://downloads.kicad-pcb.org/
> >
> > ___
> > 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] Announcing work on providing windows nightlies

[Nick Østergaard]

Den 12/03/2015 17.00 skrev "Jonatas" :
>
> Great job,
>
> Last week I made a compilation test using own msys2 64bis packages
(mingw_x86_64 *). He did compile kicad in 64bis successfully. Not tested it
working yet, but the interface opens normally.
>
> It will be great to have build night of windows. Compiling from source is
painful and takes time.
>
> I suggest you have the binary version of the 64bit kicad. Currently
kicad-WinBuilder makes only 32 bits of binary of kicad.

If you look at [3] then you will see I build both i686 and x86_64, and I
intend keeping it that way.

> greetings,
>
> Jonatas Evaristo
> Electronic Engineer
>
> 2015-03-12 9:14 GMT-03:00 Nick Østergaard :
>>
>> Greetings
>>
>> Just to announce it for the people interested: Windows nightlies
>> should soon be a reality.
>>
>> A week or so ago I started looking into packaging the windows builds
>> that was created in MSYS2, where I made a script and upgraded the NSIS
>> install script to make it work together, including python scripting.
>> This currently seems to work. My work is currently hosted on [2], but
>> I will try to merge it with [1] soon. I have stashed some builds on
>> [3], that interested people can try out. Be aware that they are in
>> testing, but feedback would be appreciated.
>>
>> I discovered that Brian Sidebotham was looking into making the kicad
>> winbuilder use MSYS2, so I am working together with Brian Sidebotham
>> on upgrading the kicad winbuilder to use the MSYS2 environment, which
>> should ease the creation of the toolchain and the dependencies. This
>> work is currently on [1].
>>
>> We hope to get the repo under the KiCad umbrella to keep it together
>> in one place.
>>
>> For nightly builds Adam Wolf has offered a build server, so he will
>> eventually start pushing builds to [4] as we do for the OS X builds.
>>
>> Regards
>> Nick Østergaard
>>
>> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
>> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
>> [3] http://www2.futureware.at/~nickoe/
>> [4] http://downloads.kicad-pcb.org/
>>
>> ___
>> 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] Announcing work on providing windows nightlies

[Wayne Stambaugh]

On 3/12/2015 12:00 PM, Jonatas wrote:
> Great job,
> 
> Last week I made a compilation test using own msys2 64bis packages
> (mingw_x86_64 *). He did compile kicad in 64bis successfully. Not tested
> it working yet, but the interface opens normally.
> 
> It will be great to have build night of windows. Compiling from source
> is painful and takes time.
> 
> I suggest you have the binary version of the 64bit kicad. Currently
> kicad-WinBuilder makes only 32 bits of binary of kicad.
> 
> greetings,
> 
> Jonatas Evaristo
> Electronic Engineer
> 
> 2015-03-12 9:14 GMT-03:00 Nick Østergaard  >:
> 
> Greetings
> 
> Just to announce it for the people interested: Windows nightlies
> should soon be a reality.
> 
> A week or so ago I started looking into packaging the windows builds
> that was created in MSYS2, where I made a script and upgraded the NSIS
> install script to make it work together, including python scripting.
> This currently seems to work. My work is currently hosted on [2], but
> I will try to merge it with [1] soon. I have stashed some builds on
> [3], that interested people can try out. Be aware that they are in
> testing, but feedback would be appreciated.
> 
> I discovered that Brian Sidebotham was looking into making the kicad
> winbuilder use MSYS2, so I am working together with Brian Sidebotham
> on upgrading the kicad winbuilder to use the MSYS2 environment, which
> should ease the creation of the toolchain and the dependencies. This
> work is currently on [1].

FYI.  Using the msys2/mingw64 builds of wxWidgets 3.0.2-3, wxWidgets is
compiled with -std=gnu++11 which breaks the KiCad build.  I'm guessing
that KiCad will build with the -std=gnu++11 option but I haven't tried
it yet.  I filed a bug report so I'm guessing it will be fixed soon so
you may run into problems.  You can always downgrade the wxWidgets
package to 3.0.2-2.

> 
> We hope to get the repo under the KiCad umbrella to keep it together
> in one place.
> 
> For nightly builds Adam Wolf has offered a build server, so he will
> eventually start pushing builds to [4] as we do for the OS X builds.
> 
> Regards
> Nick Østergaard
> 
> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> [3] http://www2.futureware.at/~nickoe/
> [4] http://downloads.kicad-pcb.org/
> 
> ___
> 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] Launchpad bug status

[jp charras]

Le 12/03/2015 16:38, Wayne Stambaugh a écrit :
> There was a question asking how bugs are closed.
> 
> https://answers.launchpad.net/kicad/+question/263366
> 
> I didn't have a good answer so I dug around a bit and found some
> information on the Launchpad blog about the meaning of bug status tags.
> 
> http://blog.launchpad.net/general/of-bugs-and-statuses
> 
> I also changed the status of two bugs from "Fix Committed" to "Fix
> Released" and the "Open Bug" count was reduced by two.  Given the way we
> have been handling bugs, it looks like none of bugs are ever fixed.
> This is confusing for new developers and doesn't really make a lot of
> sense.  I am proposing that we change the way we handle bugs as follows:
> 
> * Once a bug fix has been committed to the project branch it should be
> tagged as "Fix Committed" as we have always done.
> 
> * The bug report status should be changed to "Fix Released" once bug is
> confirmed as fixed by someone other than the person that authored the
> bug fix.  I'm assuming bugs can be changed back to "New" if the
> committed fix did not actually fix the bug but I haven't tried it yet.
> 
> * For legacy bug fixes, if the "Fix Committed" date is over a month, it
> can be changed to "Fix Released" even if the fix has not been confirmed
> as long as there are no additional complaints after the committed fix.
> 
> If anyone has any comments, please speak up.  Once we have a consensus
> on this, I will make it an official project policy.
> 

That's OK for me.


-- 
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

[Kicad-developers] Launchpad bug status

[Wayne Stambaugh]

There was a question asking how bugs are closed.

https://answers.launchpad.net/kicad/+question/263366

I didn't have a good answer so I dug around a bit and found some
information on the Launchpad blog about the meaning of bug status tags.

http://blog.launchpad.net/general/of-bugs-and-statuses

I also changed the status of two bugs from "Fix Committed" to "Fix
Released" and the "Open Bug" count was reduced by two.  Given the way we
have been handling bugs, it looks like none of bugs are ever fixed.
This is confusing for new developers and doesn't really make a lot of
sense.  I am proposing that we change the way we handle bugs as follows:

* Once a bug fix has been committed to the project branch it should be
tagged as "Fix Committed" as we have always done.

* The bug report status should be changed to "Fix Released" once bug is
confirmed as fixed by someone other than the person that authored the
bug fix.  I'm assuming bugs can be changed back to "New" if the
committed fix did not actually fix the bug but I haven't tried it yet.

* For legacy bug fixes, if the "Fix Committed" date is over a month, it
can be changed to "Fix Released" even if the fix has not been confirmed
as long as there are no additional complaints after the committed fix.

If anyone has any comments, please speak up.  Once we have a consensus
on this, I will make it an official project policy.

___
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] Launchpad bug status

[Adam Wolf]

This sounds like a step up from what we're doing now.

On Thu, Mar 12, 2015 at 10:38 AM, Wayne Stambaugh 
wrote:

> There was a question asking how bugs are closed.
>
> https://answers.launchpad.net/kicad/+question/263366
>
> I didn't have a good answer so I dug around a bit and found some
> information on the Launchpad blog about the meaning of bug status tags.
>
> http://blog.launchpad.net/general/of-bugs-and-statuses
>
> I also changed the status of two bugs from "Fix Committed" to "Fix
> Released" and the "Open Bug" count was reduced by two.  Given the way we
> have been handling bugs, it looks like none of bugs are ever fixed.
> This is confusing for new developers and doesn't really make a lot of
> sense.  I am proposing that we change the way we handle bugs as follows:
>
> * Once a bug fix has been committed to the project branch it should be
> tagged as "Fix Committed" as we have always done.
>
> * The bug report status should be changed to "Fix Released" once bug is
> confirmed as fixed by someone other than the person that authored the
> bug fix.  I'm assuming bugs can be changed back to "New" if the
> committed fix did not actually fix the bug but I haven't tried it yet.
>
> * For legacy bug fixes, if the "Fix Committed" date is over a month, it
> can be changed to "Fix Released" even if the fix has not been confirmed
> as long as there are no additional complaints after the committed fix.
>
> If anyone has any comments, please speak up.  Once we have a consensus
> on this, I will make it an official project policy.
>
> ___
> 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] Announcing work on providing windows nightlies

[Jonatas]

Great job,

Last week I made a compilation test using own msys2 64bis packages
(mingw_x86_64 *). He did compile kicad in 64bis successfully. Not tested it
working yet, but the interface opens normally.

It will be great to have build night of windows. Compiling from source is
painful and takes time.

I suggest you have the binary version of the 64bit kicad. Currently
kicad-WinBuilder makes only 32 bits of binary of kicad.

greetings,

Jonatas Evaristo
Electronic Engineer

2015-03-12 9:14 GMT-03:00 Nick Østergaard :

> Greetings
>
> Just to announce it for the people interested: Windows nightlies
> should soon be a reality.
>
> A week or so ago I started looking into packaging the windows builds
> that was created in MSYS2, where I made a script and upgraded the NSIS
> install script to make it work together, including python scripting.
> This currently seems to work. My work is currently hosted on [2], but
> I will try to merge it with [1] soon. I have stashed some builds on
> [3], that interested people can try out. Be aware that they are in
> testing, but feedback would be appreciated.
>
> I discovered that Brian Sidebotham was looking into making the kicad
> winbuilder use MSYS2, so I am working together with Brian Sidebotham
> on upgrading the kicad winbuilder to use the MSYS2 environment, which
> should ease the creation of the toolchain and the dependencies. This
> work is currently on [1].
>
> We hope to get the repo under the KiCad umbrella to keep it together
> in one place.
>
> For nightly builds Adam Wolf has offered a build server, so he will
> eventually start pushing builds to [4] as we do for the OS X builds.
>
> Regards
> Nick Østergaard
>
> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> [3] http://www2.futureware.at/~nickoe/
> [4] http://downloads.kicad-pcb.org/
>
> ___
> 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] Announcing work on providing windows nightlies

[Miguel Ángel Ajo]

Awesome Nick!,  

   Good work. :)  

Miguel Ángel Ajo


On Thursday, 12 de March de 2015 at 13:14, Nick Østergaard wrote:

> Greetings
>  
> Just to announce it for the people interested: Windows nightlies
> should soon be a reality.
>  
> A week or so ago I started looking into packaging the windows builds
> that was created in MSYS2, where I made a script and upgraded the NSIS
> install script to make it work together, including python scripting.
> This currently seems to work. My work is currently hosted on [2], but
> I will try to merge it with [1] soon. I have stashed some builds on
> [3], that interested people can try out. Be aware that they are in
> testing, but feedback would be appreciated.
>  
> I discovered that Brian Sidebotham was looking into making the kicad
> winbuilder use MSYS2, so I am working together with Brian Sidebotham
> on upgrading the kicad winbuilder to use the MSYS2 environment, which
> should ease the creation of the toolchain and the dependencies. This
> work is currently on [1].
>  
> We hope to get the repo under the KiCad umbrella to keep it together
> in one place.
>  
> For nightly builds Adam Wolf has offered a build server, so he will
> eventually start pushing builds to [4] as we do for the OS X builds.
>  
> Regards
> Nick Østergaard
>  
> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> [3] http://www2.futureware.at/~nickoe/
> [4] http://downloads.kicad-pcb.org/
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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] Announcing work on providing windows nightlies

[Wayne Stambaugh]

Awesome work!  I'm sure our windows users will appreciate it.

On 3/12/2015 8:14 AM, Nick Østergaard wrote:
> Greetings
> 
> Just to announce it for the people interested: Windows nightlies
> should soon be a reality.
> 
> A week or so ago I started looking into packaging the windows builds
> that was created in MSYS2, where I made a script and upgraded the NSIS
> install script to make it work together, including python scripting.
> This currently seems to work. My work is currently hosted on [2], but
> I will try to merge it with [1] soon. I have stashed some builds on
> [3], that interested people can try out. Be aware that they are in
> testing, but feedback would be appreciated.
> 
> I discovered that Brian Sidebotham was looking into making the kicad
> winbuilder use MSYS2, so I am working together with Brian Sidebotham
> on upgrading the kicad winbuilder to use the MSYS2 environment, which
> should ease the creation of the toolchain and the dependencies. This
> work is currently on [1].
> 
> We hope to get the repo under the KiCad umbrella to keep it together
> in one place.
> 
> For nightly builds Adam Wolf has offered a build server, so he will
> eventually start pushing builds to [4] as we do for the OS X builds.
> 
> Regards
> Nick Østergaard
> 
> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> [3] http://www2.futureware.at/~nickoe/
> [4] http://downloads.kicad-pcb.org/
> 
> ___
> 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] Announcing work on providing windows nightlies

[Adam Wolf]

Great work everyone!

Having good nightlies for the platforms should really cut down on the
packaging issues/bugs when we cut the next versioned release, and will
really help users to be able to use our work as we finish it!

Adam Wolf
Cofounder and Engineer
W&L


On Thu, Mar 12, 2015 at 7:14 AM, Nick Østergaard  wrote:

> Greetings
>
> Just to announce it for the people interested: Windows nightlies
> should soon be a reality.
>
> A week or so ago I started looking into packaging the windows builds
> that was created in MSYS2, where I made a script and upgraded the NSIS
> install script to make it work together, including python scripting.
> This currently seems to work. My work is currently hosted on [2], but
> I will try to merge it with [1] soon. I have stashed some builds on
> [3], that interested people can try out. Be aware that they are in
> testing, but feedback would be appreciated.
>
> I discovered that Brian Sidebotham was looking into making the kicad
> winbuilder use MSYS2, so I am working together with Brian Sidebotham
> on upgrading the kicad winbuilder to use the MSYS2 environment, which
> should ease the creation of the toolchain and the dependencies. This
> work is currently on [1].
>
> We hope to get the repo under the KiCad umbrella to keep it together
> in one place.
>
> For nightly builds Adam Wolf has offered a build server, so he will
> eventually start pushing builds to [4] as we do for the OS X builds.
>
> Regards
> Nick Østergaard
>
> [1] https://github.com/BrianSidebotham/KiCad-Winbuilder
> [2] https://github.com/nickoe/kicad-windows-nsis-packaging
> [3] http://www2.futureware.at/~nickoe/
> [4] http://downloads.kicad-pcb.org/
>
> ___
> 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] Announcing work on providing windows nightlies

[Nick Østergaard]

Greetings

Just to announce it for the people interested: Windows nightlies
should soon be a reality.

A week or so ago I started looking into packaging the windows builds
that was created in MSYS2, where I made a script and upgraded the NSIS
install script to make it work together, including python scripting.
This currently seems to work. My work is currently hosted on [2], but
I will try to merge it with [1] soon. I have stashed some builds on
[3], that interested people can try out. Be aware that they are in
testing, but feedback would be appreciated.

I discovered that Brian Sidebotham was looking into making the kicad
winbuilder use MSYS2, so I am working together with Brian Sidebotham
on upgrading the kicad winbuilder to use the MSYS2 environment, which
should ease the creation of the toolchain and the dependencies. This
work is currently on [1].

We hope to get the repo under the KiCad umbrella to keep it together
in one place.

For nightly builds Adam Wolf has offered a build server, so he will
eventually start pushing builds to [4] as we do for the OS X builds.

Regards
Nick Østergaard

[1] https://github.com/BrianSidebotham/KiCad-Winbuilder
[2] https://github.com/nickoe/kicad-windows-nsis-packaging
[3] http://www2.futureware.at/~nickoe/
[4] http://downloads.kicad-pcb.org/

___
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] Polish support file for asciidoc

[Marco Ciampa]

On Sat, Mar 07, 2015 at 11:49:21AM +0100, Marco Ciampa wrote:
> I just haven't make up my mind about where to put i18n screenshots. What
> do you think is better? Inside the images dir like this:
> 
> images (for common images like icons)
> images/it
> images/pl
> images/en
> 
> etc.
> 
> or instead with a localized images dir like this:
> 
> images (for common images like icons)
> images-it
> images-pl
> images-en
> 
> etc.
> 
> or something else?

Since evidently it is not coming out any critical issues regarding this
choice, I am keeping the gerarchical structure like this:

images/it
images/pl
images/en

etc. and

images/common

for common images like icons so translators know that they can simply
copy image link strings without any need for translation.

thanks!

For package maintainers: nationalized packages should always depend on
en package since en is a fallback for images links.

--


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

Re: [Kicad-developers] fix proposal for the 3D shading issues.

[jp charras]

Le 09/03/2015 22:04, Mário Luzeiro a écrit :
> Hello kicad developers!
> I submitted a patch to fix the current shading issues with some models.
> 
> https://bugs.launchpad.net/kicad/+bug/1351618
> https://bugs.launchpad.net/kicad/+bug/1351618/+attachment/4339230/+files/3d-viewer-shadding-improovements_issue1351618.patch
> 
> This patch added an options to use or not the normals from models (as some 
> models come with, not nice normals).
> The source code also try to repair some bad normals and will flag (in red) 
> the vertices with bad normals in the model.
> .. as other small clean & fixes
> 
> I appreciate if you can merge it in the trunk development or let me know if 
> you would like some changes.
> 
> Thanks in advance,
> Mario Luzeiro

I committed your patch; Thanks.

I recently noticed an other issue, related to material, in demo ecc83.
Valves (which have transparent areas) are incorrectly shown.
If the option "Render Material Properties" is off, the valve is
correctly shown (obviously the transparent areas are no more transparent).
But if the option is on, a lot of basic shapes are missing (not
necessary transparent areas).
In old stable version, the rendering is OK.

May I ask you to have a look at this issue?

Thanks in advance.


-- 
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] [PATCH] fix 2x memory leak and misc field warnings in PNS stuff

[Wayne Stambaugh]

I believe uncommit will remove all of the changes since r5495 as well as
r5495.  I don't think that is what you want to do.  Uncommit would have
been fine if there were no other commits after r5495 but it's too late
for that now.  I doubt it's worth the effort at this point.

On 3/10/2015 3:12 PM, Bernhard Stegmaier wrote:
> Maybe this helps:
> http://stackoverflow.com/questions/9730755/is-there-a-bazaar-equivalent-to-git-commit-amend
> 
> 
> Regards,
> Bernhard
> 
>> On 10 Mar 2015, at 17:57, Maciej Sumiński > > wrote:
>>
>> Mark,
>>
>> I committed your patch in 5495, but by oversight I have not used your
>> name as the author. I sincerely apologize for the error, I promise to be
>> more careful next time.
>>
>> If anyone knows a way to fix it without forceful overwriting the
>> repository, please let me know. I really hope you are not offended by my
>> mistake.
>>
>> Kind regards,
>> Orson
>>
>> On 03/10/2015 05:08 AM, Mark Roszko wrote:
>>> Fixes 1 leak in pns_line_placer and 1 leak in pns_node.
>>> Assorted field intialization.
>>>
>>> Based on coverity.
>>>
>>>
>>>
>>> ___
>>> 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