Re: [Kicad-developers] eeschema GAL renderer (with old tools)

[Jeff Young]

Awesome!

> On 28 May 2018, at 22:43, Tomasz Wlostowski  wrote:
> 
> Hi all,
> 
> This is to inform that I'm working on it (as the XOR-based rendering
> doesn't work under GTK3). I wrote a hacked GAL canvas which uses the
> legacy eeschema tool code. It's non-functional yet (editing-wise), but
> draws the schematics and the selection rectangles.
> 
> I'll publish the code as soon as it is in usable state.
> 
> Cheers,
> 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

[Kicad-developers] eeschema GAL renderer (with old tools)

[Tomasz Wlostowski]

Hi all,

This is to inform that I'm working on it (as the XOR-based rendering
doesn't work under GTK3). I wrote a hacked GAL canvas which uses the
legacy eeschema tool code. It's non-functional yet (editing-wise), but
draws the schematics and the selection rectangles.

I'll publish the code as soon as it is in usable state.

Cheers,
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] Making adding of additional symbol *-sym-table files more easy and user friendly?

[Carsten Schoenert]

Hi,

the following is clearly something about which hasn't a priority for the
current 5.0.0 finalization work.

I was thinking about also packaging the digikey-kicad-library [1] for
Debian. This is more an easy task so basically I've got a running
package which I can use in KiCad.

But ... the integration of the symbols and footprints is a bit boring
and time consuming as e.g. the adding of the various symbol libraries
needs to be done manually for every .lib file. And there are 143 of them! :)

The footprint editor has a wizard which helps to decrease the amount of
manually work but the user also needs to know there to find the .pretty
folder which may be for not well experienced user difficult.

So how could this be improved?
The footprint library wizard is basically a good thing and the symbols
editor should get a similar thing.
But I was also thinking about some more flexibility which could be used
by the packagers. So the following should be also usable and practical
on Windows Systems.

What about adding KiCad some intelligence to also look for files named
'subpackage.sym-lib-table' which are automatically included by the
schematic editor to expand or signalize the existence of more schematic
symbols from third parties? The search path for such files I'd lean
against the global file 'sym-lib-table' so first look at
/usr/share/kicad/template/ and /usr/share/kicad/library/ but also
locally in ~/.config/kicad
The format should be the same as the global symbol file.

The same could be done for the footprint editor?

And the editor(s?) could pick up that information and put some
(de)selection method within a dedicated tab for the submodul.

These are some ideas that are going around in my head, I don't know if
this would be doable or this is fully useful. But I'd like to see if the
management of the symbol libraries and also the footprint libraries
could be made much more easier.

[1] https://github.com/digikey/digikey-kicad-library

-- 
Regards
Carsten

___
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] More default fields in schematic

[Reece R. Pollack]

I believe you owe me 2c. We can discuss 2c in which currency later. :-)

I have five custom default fields defined:
 - Mfgr
 - Mfgr P/N
 - Dist
 - Dist P/N
 - Specifications

The first two give the manufacturer's name and part number; the second 
two give the distributor's name and part number; the third is a 
catch-all for specs that are important for ordering but aren't worth 
cluttering the schematic with.


My biggest issue with the current Default Fields is that I didn't start 
my current project with them, so using the field edit spreadsheet-like 
thingie often results in lots of noise in my commits as the empty 
default fields get added to components.


I was originally against adding such defined fields, as I expect it will 
add fields to components that will potentially conflict with those 
created by current users. However, if it doesn't do that, and has the 
support from parts distributors, I guess I could live with it.


On 05/22/18 10:56, Fabrizio Tappero wrote:

Hello,
I'd like to contribute with my 2c.

I completely agree with Kristoffer, there is a need for a "MPN" field 
hard coded exactly as "Value" field is hard coded in Kicad.


As Wayne mentions the current "Preferences - General Options - Default 
Fields" is not a bad option to add a "MPN" field. This is what I do 
and this is what all my PCB colleges at work do.


Above solution will however not help the majority to do the same. I 
would actually bet 2c that nearly nobody uses the Default Fields 
feature (most of the people probably do it component by component). 
And this makes it a not so useful feature.


Kicost is a god-made tool and for sure Dave will soon add MPN as a 
default field in Kicad.


Cheers
Fabrizio





On Tue, May 22, 2018 at 3:41 PM, kristoffer ödmark 
> 
wrote:


My updated patch forgot to add the files before doing the --amend.

So it only updated the commit message. Here is the real file

On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I
> would
> gladly change the fields to whatever would be decided.  Uniformity
> for
> plugins use would definitely be an advantage.
>
> -Ben
>
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> kristofferodmar...@gmail.com
> wrote:
>
> > Thanks! This is exactly what i was going for, non-intrusive
> > oppurtunity
> > for uniformity!
> >
> > I tested the bom2csv plugin, It did not include the empty fields.
> >
> > I also tested the bom_csv_sorted_by_ref, it did not include the
> > empty
> > values, but it included some values I had not specified, such as
> > Manufacturer and Vendor even if they were not provided in the
> > schematic.
> >
> > - Kristoffer
> >
> > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > > I think I like this new patch.  It provides the
/opportunity/ for
> > > uniformity, without getting in the way of those who want to go
> > > their
> > > own way.
> > >
> > > Do the BOM generators automatically output all default fields or
> > > only
> > > those with values?
> > >
> > > > On 22 May 2018, at 09:22, kristoffer ödmark
 > > > @gma
> > > > il.com > wrote:
> > > >
> > > > Please disregard my previous mail, it got mangled badly
> > > > somehow, it
> > > > did
> > > > not look like that in my editor at least.
> > > >
> > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > > Eeschema already supports creating default optional
fields in
> > > > > the
> > > > > configuration settings dialog. Used correctly, these will
> > > > > give
> > > > > you
> > > > > the
> > > > > same optional field names for every project without
having to
> > > > > add
> > > > > them
> > > > > by hand to each symbol and possibly typing in different
field
> > > > > names
> > > > > by
> > > > > accident.
> > > >
> > > > Different users will still type in different field names for
> > > > the
> > > > same
> > > > things though. What you describe works as long as there is
only
> > > > one
> > > > person in the entire projects lifetime, using only one
> > > > computer.
> > > >
> > > > > The proposed patch would intermingle the default fields
> > > > > with
> > > > > existing schematic symbol fields which would break existing
> > > > > BOMs
> > > > > which I
> > > > > don't think users will appreciate.
> > > >
> > > > The proposed patch will only change default settings, existing
> > > > users
> > > > with a config already in place will not be affected. I
realised
> > > > that
> > > > the fields now accept empty values as well, so 

Re: [Kicad-developers] V5 tag in bug tracker?

[Simon Richter]

Hi,

On 28.05.2018 15:15, Nick Østergaard wrote:

> I agree with Simon that we are likely to have an rc3. We can just rename
> the milestone if we change our mind. Afterall it does not cost us anything.

To me, a "release candidate" is something we feel could be a release
unless the wider testing that a rc gets compared to a nightly unearths
some showstopper bug.

If we decided to go for a release without having another candidate,
we're basically claiming that we don't need that testing.

An ideal timeline would be to tag rc3, wait a week and if no critical
bugs pop up, put the release label on the exact same version.

   Simon

___
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] Large board speed

[Tomasz Wlostowski]

On 25/05/18 18:53, Seth Hillbrand wrote:
> Hi Tom-
> 
> For a particularly large board I'm working on (32 layers, 124k tracks),
> current master takes 2.4s per connectivity update (clicks, moving
> footprints, enable layers, etc).  With the patch, connectivity search is
> 10ms per click.  
> 
> I did a merge with your tom-background-connectivity branch but I needed
> to rebase it to master before doing that.  The conflicts were with
> inserting the aWorker-CheckInterrupt() conditional in the itemList search. 
> 
Hi Seth,

I don't plan to use the background connectivity branch before 6.0 (as
it's incompatible with the legacy canvas). Your R-Tree patch though
looks very nice. I vote for merging it if Wayne's OK.

Tom

> -S
> 
> Am Fr., 25. Mai 2018 um 08:35 Uhr schrieb Tomasz Wlostowski
> >:
> 
> On 25/05/18 05:16, Seth Hillbrand wrote:
> > Here's an updated patch for working with large, complex boards in v5.
> >
> Hi Seth,
> 
> Thanks for the patch.
> 
> How much faster is it compared to the current master branch?
> 
> > Tom, I took your advice and put a light layer over an RTree for the
> > connectivity search.  Since this gets us bounding box collisions,
> we can
> > do commutative hits by using both items in the collision, eliminating
> > the need to iterate over the full list.
> 
> Great!
> >
> > I also did a test merge with your dev tree and had only a couple minor
> > conflicts, so I think our approaches will compliment well. 
> 
> Did you try to merge it with tom-background-connectivity branch?
> 
> 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

Re: [Kicad-developers] V5 tag in bug tracker?

[Nick Østergaard]

I figured I just made it since no 5.0.0 was made.

I agree with Simon that we are likely to have an rc3. We can just rename
the milestone if we change our mind. Afterall it does not cost us anything.

2018-05-28 14:25 GMT+02:00 Wayne Stambaugh :

> On 05/26/2018 04:13 PM, Simon Richter wrote:
>
>> Hi,
>>
>> On 26.05.2018 16:40, Wayne Stambaugh wrote:
>>
>> Do we really need an rc3?  I was going to make 5.0.0 the next milestone.
>>>   I think (hope) most of the bug fixes will be polishing at this point.
>>>
>>
>> If we're not going to release rc2 as it is, then it makes sense to make
>> an rc3, test it, and retag it as the release if we decide to not change
>> anything anymore.
>>
>
> Seems a bit redundant but OK.
>
>
>
>> Simon
>>
>> ___
>> 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] partially untranslated strings in simulation dialog

[Maciej Sumiński]

Thank you Marco, I have just pushed your patch.

Regards,
Orson

On 05/28/2018 11:37 AM, Marco Ciampa wrote:
> On Mon, May 28, 2018 at 07:55:16AM +0200, Carsten Schoenert wrote:
>> Hello Marco,
>>
>> Am 27.05.2018 um 12:10 schrieb Marco Ciampa:
 No apologies needed at all, Maciej!
 But I am sorry to say that it will not suffice, there are also some error
 message strings left out untranslated...
>> ...
 eeschema/dialogs/dialog_sim_settings.cpp
 109:DisplayError( this, wxT( "You need to select DC source 
 (sweep 1)" ) );
 139:DisplayError( this, wxT( "You need to select DC source 
 (sweep 2)" ) );

 ^
 Not translated
>>
>> this is for sure just a oversight by the developers and not a intended
>> behavior. 
> 
> Of course I know it. That was my point in saying that there is no need to
> apoligise!
> 
>> I'd hereby suggesting you prepare a patch about such strings.
>> I've seen this also from time to time but didn't get backed out a patch
>> yet due time limitations.
> 
> Here we go: see attach. I do not know if it is complete though, you know,
> I am a mere translator, not a programmer!
> 
> TIA
> 
> Best regards,
> 
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] KiCad 5.0.0~rc2 now available in Debian experimental

[Wayne Stambaugh]

Great work Carsten!

On 05/28/2018 03:25 AM, Carsten Schoenert wrote:

Hi,

I already wanted to make a fixed build about the GTK3+ vs. GTK2+ issues
of KiCad in Debian experimental while MiniDebConf in Hamburg but didn't
get it in time.

So I prepared on the last weekend the recent RC2 release and uploaded
this all to Debian experimental. This upload has switched back to
linking KiCad against wxWidgets with GTK2+ binding but also dropped the
SCRIPTING_PYTHON support due missing GTK2+ support for wxpython.

My poor testing hasn't shown any particular regression but maybe there
are corner cases we need to take before going further to Debian
unstable/testing.

I also updated the footprints, the schematic symbols and the 3D models.
The templates aren't have got a update since RC1 so no new upload here.

https://tracker.debian.org/pkg/kicad
https://tracker.debian.org/pkg/kicad-footprints
https://tracker.debian.org/pkg/kicad-symbols
https://tracker.debian.org/pkg/kicad-packages-3d
https://tracker.debian.org/pkg/kicad-templates

So if people on testing or unstable want to use these versions they need
to install them explicitly, even if they already have installed a
previous version from experimental, there is no automatic update normally.



___
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] V5 tag in bug tracker?

[Wayne Stambaugh]

On 05/26/2018 04:13 PM, Simon Richter wrote:

Hi,

On 26.05.2018 16:40, Wayne Stambaugh wrote:


Do we really need an rc3?  I was going to make 5.0.0 the next milestone.
  I think (hope) most of the bug fixes will be polishing at this point.


If we're not going to release rc2 as it is, then it makes sense to make
an rc3, test it, and retag it as the release if we decide to not change
anything anymore.


Seems a bit redundant but OK.



Simon

___
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] partially untranslated strings in simulation dialog

[Marco Ciampa]

On Mon, May 28, 2018 at 07:55:16AM +0200, Carsten Schoenert wrote:
> Hello Marco,
> 
> Am 27.05.2018 um 12:10 schrieb Marco Ciampa:
> >> No apologies needed at all, Maciej!
> >> But I am sorry to say that it will not suffice, there are also some error
> >> message strings left out untranslated...
> ...
> >> eeschema/dialogs/dialog_sim_settings.cpp
> >> 109:DisplayError( this, wxT( "You need to select DC source 
> >> (sweep 1)" ) );
> >> 139:DisplayError( this, wxT( "You need to select DC source 
> >> (sweep 2)" ) );
> >>
> >> ^
> >> Not translated
> 
> this is for sure just a oversight by the developers and not a intended
> behavior. 

Of course I know it. That was my point in saying that there is no need to
apoligise!

> I'd hereby suggesting you prepare a patch about such strings.
> I've seen this also from time to time but didn't get backed out a patch
> yet due time limitations.

Here we go: see attach. I do not know if it is complete though, you know,
I am a mere translator, not a programmer!

TIA

Best regards,

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364



>From 62688cba331490e9e6334fda0eca6cd9dbed1a41 Mon Sep 17 00:00:00 2001
From: Marco Ciampa 
Date: Mon, 28 May 2018 11:24:20 +0200
Subject: [PATCH] Make the Simulator error strings translatable

---
 eeschema/dialogs/dialog_sim_settings.cpp | 6 +++---
 eeschema/sim/spice_value.cpp | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/eeschema/dialogs/dialog_sim_settings.cpp b/eeschema/dialogs/dialog_sim_settings.cpp
index f67582653..78bafc0fa 100644
--- a/eeschema/dialogs/dialog_sim_settings.cpp
+++ b/eeschema/dialogs/dialog_sim_settings.cpp
@@ -96,7 +96,7 @@ bool DIALOG_SIM_SETTINGS::TransferDataFromWindow()
 // At least one source has to be enabled
 if( !m_dcEnable1->IsChecked() && !m_dcEnable2->IsChecked() )
 {
-DisplayError( this, wxT( "You need to enable at least one source" ) );
+DisplayError( this, _( "You need to enable at least one source" ) );
 return false;
 }
 
@@ -106,7 +106,7 @@ bool DIALOG_SIM_SETTINGS::TransferDataFromWindow()
 {
 if( empty( m_dcSource1 ) )
 {
-DisplayError( this, wxT( "You need to select DC source (sweep 1)" ) );
+DisplayError( this, _( "You need to select DC source (sweep 1)" ) );
 return false;
 }
 
@@ -136,7 +136,7 @@ bool DIALOG_SIM_SETTINGS::TransferDataFromWindow()
 {
 if( empty( m_dcSource2 ) )
 {
-DisplayError( this, wxT( "You need to select DC source (sweep 2)" ) );
+DisplayError( this, _( "You need to select DC source (sweep 2)" ) );
 return false;
 }
 
diff --git a/eeschema/sim/spice_value.cpp b/eeschema/sim/spice_value.cpp
index 18017cc5b..96663efa4 100644
--- a/eeschema/sim/spice_value.cpp
+++ b/eeschema/sim/spice_value.cpp
@@ -37,12 +37,12 @@ SPICE_VALUE::SPICE_VALUE( const wxString& aString )
 char buf[8] = { 0, };
 
 if( aString.IsEmpty() )
-throw std::invalid_argument( "Spice value cannot be empty" );
+  throw std::invalid_argument( _("Spice value cannot be empty") );
 
 LOCALE_IO dummy;// All numeric values should be in "C" locale(decimal separator = .)
 
 if( sscanf( (const char*) aString.c_str(), "%lf%7s", _base, buf ) == 0 )
-throw std::invalid_argument( "Invalid Spice value string" );
+  throw std::invalid_argument( _("Invalid Spice value string") );
 
 if( *buf == 0 )
 {
@@ -75,7 +75,7 @@ SPICE_VALUE::SPICE_VALUE( const wxString& aString )
 case 't': m_prefix = PFX_TERA; break;
 
 default:
-throw std::invalid_argument( "Invalid unit prefix" );
+	  throw std::invalid_argument( _("Invalid unit prefix") );
 }
 }
 
-- 
2.17.0

___
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] KiCad 5.0.0~rc2 now available in Debian experimental

[Carsten Schoenert]

Am 28.05.2018 um 10:01 schrieb Eeli Kaikkonen:
> The flag should be KICAD_SCRIPTING_WXPYTHON, is it? KICAD_SCRIPTING should
> be on. Action scripts work without wxpython support (unless they try to
> import and use wxpython explicitly).

Ahh, yes, I meant this. And the configuration is exactly about this.

https://salsa.debian.org/electronics-team/KiCad/kicad/blob/debian/sid/debian/rules#L40

-- 
Regards
Carsten Schoenert

___
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] KiCad 5.0.0~rc2 now available in Debian experimental

[Eeli Kaikkonen]

The flag should be KICAD_SCRIPTING_WXPYTHON, is it? KICAD_SCRIPTING should
be on. Action scripts work without wxpython support (unless they try to
import and use wxpython explicitly).

Eeli Kaikkonen


2018-05-28 10:25 GMT+03:00 Carsten Schoenert :

> Hi,
>
> I already wanted to make a fixed build about the GTK3+ vs. GTK2+ issues
> of KiCad in Debian experimental while MiniDebConf in Hamburg but didn't
> get it in time.
>
> So I prepared on the last weekend the recent RC2 release and uploaded
> this all to Debian experimental. This upload has switched back to
> linking KiCad against wxWidgets with GTK2+ binding but also dropped the
> SCRIPTING_PYTHON support due missing GTK2+ support for wxpython.
>
> My poor testing hasn't shown any particular regression but maybe there
> are corner cases we need to take before going further to Debian
> unstable/testing.
>
> I also updated the footprints, the schematic symbols and the 3D models.
> The templates aren't have got a update since RC1 so no new upload here.
>
> https://tracker.debian.org/pkg/kicad
> https://tracker.debian.org/pkg/kicad-footprints
> https://tracker.debian.org/pkg/kicad-symbols
> https://tracker.debian.org/pkg/kicad-packages-3d
> https://tracker.debian.org/pkg/kicad-templates
>
> So if people on testing or unstable want to use these versions they need
> to install them explicitly, even if they already have installed a
> previous version from experimental, there is no automatic update normally.
>
> --
> Regards
> Carsten Schoenert
>
> ___
> 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 5.0.0~rc2 now available in Debian experimental

[Carsten Schoenert]

Hi,

I already wanted to make a fixed build about the GTK3+ vs. GTK2+ issues
of KiCad in Debian experimental while MiniDebConf in Hamburg but didn't
get it in time.

So I prepared on the last weekend the recent RC2 release and uploaded
this all to Debian experimental. This upload has switched back to
linking KiCad against wxWidgets with GTK2+ binding but also dropped the
SCRIPTING_PYTHON support due missing GTK2+ support for wxpython.

My poor testing hasn't shown any particular regression but maybe there
are corner cases we need to take before going further to Debian
unstable/testing.

I also updated the footprints, the schematic symbols and the 3D models.
The templates aren't have got a update since RC1 so no new upload here.

https://tracker.debian.org/pkg/kicad
https://tracker.debian.org/pkg/kicad-footprints
https://tracker.debian.org/pkg/kicad-symbols
https://tracker.debian.org/pkg/kicad-packages-3d
https://tracker.debian.org/pkg/kicad-templates

So if people on testing or unstable want to use these versions they need
to install them explicitly, even if they already have installed a
previous version from experimental, there is no automatic update normally.

-- 
Regards
Carsten Schoenert

___
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