Re: [Kicad-developers] GitHub Mirror not updating?
Hi Simon, Wayne, > If they have local work, the sanest approach is to rebase on top of > origin/master and delete the offending commits at the same time by doing > an interactive rebase > > $ git rebase -i origin/master > > This gives a list of all commits that don't have identical content in > the old and new history. Since the filtered branch is the same except > for those four, the first four lines will be > > pick ea31730b4 Handle error returns from lstat. > pick e83420f19 Remove file accidentally commited in ea31730b4 > pick e27e6ee16 Also catch null dereference in case wxASSERT was skipped. > pick e1925b89c Remove file accidentally added in e27e6ee1 I think you can remove the need for an interactive rebase and manual editing of the commit list by using something like: $ git rebase sha_of_old_master --onto origin/master Where sha_of_old_master is the sha of the master branch just before this blob-removing history editing takes place. Alternatively, I *think* that the --fork-point option might even resolve this automatically (based on the reflog), but I'm not entirely sure. Also, this rebase command should also work for users that have no local commits (as an alternative to the reset --keep Simon proposed), so this could be a single command for everyone to use to bring their branches up to date. Gr. Matthijs signature.asc Description: PGP 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-dev-nightly PPA builds for artful outdated?
Hi Jean-Samuel, > Launchpad doesn't support anymore build for artful. So it will no more > available. Ah, that explains. A quick google for this didn't turn up any info, but I should probably have dug a bit deeper. > Have you try Xenial PPA ? (not sure if it's working...) Hm, I recall I moved to artful because xenial and zesty didn't work out in terms of dependencies, but I tried again just now and things seem to work (both the kicad-5 and kicad-dev-nightly versions). It did miss the libglew1.13 package (neither Debian stable or oldstable have this particular version), but I could just install that manually from xenial. Maybe that missing dependency threw me off before, but it's easy enough to fix :-) If only PPA's would just support building against Debian/stable, that would make a lot of stuff easier. Or perhaps I should just move to Ubuntu instead... Thanks for your thoughts! Gr. Matthijs signature.asc Description: PGP 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-dev-nightly PPA builds for artful outdated?
Hey folks, > I've been trying to update to the latest nightly build, but it seems > that the PPA has stopped building version for artful (17.10). Seems the same thing happens for the kicad-5 release PPA (it has only 5.0.0 for Artful). For the kicad-5-nightly PPA, no artful builds are available at all. Gr. Matthijs signature.asc Description: PGP 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
[Kicad-developers] kicad-dev-nightly PPA builds for artful outdated?
Hey folks, I've been trying to update to the latest nightly build, but it seems that the PPA has stopped building version for artful (17.10). The latest version is: kicad 201807190649+829ba27~83~ubuntu17.10.1 js-reynaud (2018-07-19) (from https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-dev-nightly) The other distributions in the PPA have today's build available. Was support for artful intentionally dropped, or is something wrong somewhere? I'm not quite how the process behind a PPA works, apparently. I also looked at the build logs around the time of the last succesful build, and it seems there have been no (failing) attempts after that, so it looks like artful builds were just switched off? I'm interested in the Artful build, since I'm running Debian/stable and artful seems to match stable best (installing bionic replaces libcurl3 with libcurl4, require an upgrade of half my system to testing...) Any chance to get the artful builds up-to-date again? Anything I can do to help? Gr. Matthijs signature.asc Description: PGP 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] Making adding of additional symbol *-sym-table files more easy and user friendly?
Hi Carsten, it seems this ties in what an earlier proposal I did, see this post (and the followup discussion): https://lists.launchpad.net/kicad-developers/msg33224.html My proposal was to ship a (fp|sym)-lib-table file along with library packages, and then (explicitly) include that from the main table. I'm not sure I understand your proposal exactly, but it seems you propose something similar, as well as a standard location for these tables so they get added by default? And, in addition to (not) including a secondary table, also allow only including or exluding some libraries from the secondary table? All of these sound like good ideas to me :-) Gr. Matthijs signature.asc Description: PGP 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] Future plans on the KiCad library releases?
Hi Wayne, > This is not a trivial issue to fix. I'm not sure there is a good answer > for this issue. It's certainly not trivial, but I believe a fix would not be terribly hard either. Let me repeat my original proposal here: > I can imagine that KiCad either gets a way to: > 1) include all libraries in a given directory (e.g. > /usr/share/kicad/something). This should be re-evaluated whenever > KiCad starts up, so there should be an explicit > "/usr/share/kicad/library/*.lib" entry in the table (or something > like that), as opposed to actually putting each library in the table > individually, or > 2) include a secondary library table from the normal one. Then any kicad > library package can ship such a secondary library table, and update > it to reflect the new list of libraries. > > I think these would apply to both symbols and footprints equally. Option > 2) seems more elegant and flexible to me. Both options should be able to > provide pretty seamless library upgrades for users (and can even be > extended to third party library collections, or a user's own libraries). So far, you've only responded to this proposal itself by saying you don't want KiCad to decide what libraries to load, but, as I already pointed out in a previous reply, both of these options would be opt-in through an entry in the global library table (or something similar). The above proposal only makes sure that the library list gets upgraded, not the actual schematics that point to any symbols that are now moved into another library. I think upgrading the library list is the most important, since (in the eyes of users) it is a fairly trivial change (in terms of what needs to happen, not necessarily in terms of implementation) that is annoying to do every time (remove all libraries and re-add all libraries, or compare the list of libraries to the files to see if anything changes). Automatically updating existing schematics when one of its symbols moved to a different library would of course be awesome if that could happen as well. I also made a suggestion about that: > One way I can imagine this works is to also include a "rename" > specification (perhaps similar to the current rename.json), which can be > used by KiCad to automatically migrate older symbol references. Or > perhaps the rescue dialog can be improved to look among other libraries > for a symbol with the same name and let the user choose between > relinking to such a symbol, or resueing one from the cache. Gr. Matthijs signature.asc Description: PGP 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] Future plans on the KiCad library releases?
Hi Wayne,
> I was not being sarcastic. Here is what I meant:
Thanks for clarifying.
> For stable version 5, the libraries should be tagged and used for all
> stable 5 point releases (5.0.1, 5.0.2, ...). Most corporate users
> prefer consistency over having the latest libraries so installing the
> next point release of kicad will not change the libraries.
Ok. Then my proposal does not apply at all to these users, since their
libraries are completely unchanged within the (e.g.) v5 release cycle.
My proposal *does* apply to users that:
1. Upgrade their libaries when upgrading from (e.g.) v5 to v6.
2. Upgrade their libraries ("at their discretion") within the (e.g.) v5
cycle.
Even though in both cases, it is certainly acceptable to have uses
expect some disruption in their library organisation (e.g. symbols that
changed in a non-compatible manner, moving pins around), it would also
be nice if these upgrades could be as smooth as possible (removing the
need to manually figure out what changes were made to the library
filenames and what symbols were moved where).
Also, users from #2 are also beta-testing library changes, which
improves the libaries seem by the #1 users, which seems like an
additional reason to make it easier to upgrade often.
Gr.
Matthijs
signature.asc
Description: PGP 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] Future plans on the KiCad library releases?
Hi Wayne, > > > [Proposal to make library upgrades easier] > > > > As a user, 1% agree. > > Me too! If users want to constantly update their libraries, that's > their choice but kicad installers should not be forcing this on users. > We should have a fixed set of libraries that are tagged for a release > series so users have consistent libraries to work with until the next > stable release. I wouldn't be very happy if my libraries were > completely changed when I updated to a new point release of KiCad. > Users in corporate environments tend to value stability more than having > the latest libraries. I'm not sure what you mean here. - Do you actually mean you agree and think something like my proposal should be agreed? - Do you think my proposal includes forcing users to upgrade more often? I am merely proposing to make upgrades easier *when* they happen. How often a user upgrades seems unrelated. - Are you sarcastic and think this is an issue only for users that "constantly update their libraries"? I suspect the latter is what you meant, and if so, I tend to disagree, since even if such an upgrade happens only rarely (e.g. corresponding with a KiCad majore release or Linux distribution upgrade), as a user I would still like to see the upgrade happens smoothly, without requiring manually rebuilding my entire library table. Also, I (and probably others) am actually interested in getting the latest library versions, mostly to get new symbols and fixes for existing symbols. Of course, backward-incompatible changes are a hindrance here, but I think there has already been some talk to limit such changes, including library renames, to (for example) major release versions. I guess adding new libraries within one major release cycle would be non-disruptive, though, so that would still benefit from my proposal. Gr. Matthijs signature.asc Description: PGP 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] Future plans on the KiCad library releases?
Hi Maciej, > I can easily imagine a message saying: "Why do you guys modify my > perfectly organized symbol library table when I update the libraries > package? I have carefully picked the libraries that are useful to me, so > I do not need to go through a long list when selecting components. Now I > need to reorganize them again!". > > Just saying that one size does not fit everyone. Perhaps there is a > smarter solution in between, like a possibility to import/export > sym-lib-table. This way one can easily update the official library list > if needed, and otherwise the table is not touched. This is pretty much what I proposed, namely to put an explicit entry in the global list which says "Include all libraries in this dir", or "Include all libraries in this external table". You can still remove that entry and include individiual libraries, which will then stay just like you configured them. The alternative, which I think you're afraid I'm proposing would indeed be to do some kind of magic transformations to a library table just based on the paths of each library, and that does not seem a good idea to me either. Gr. Matthijs signature.asc Description: PGP 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] Future plans on the KiCad library releases?
Hi Wayne, Carsten, On Mon, Jan 15, 2018 at 12:49:00PM -0500, Wayne Stambaugh wrote: > I agree 100%. Once we tag the v5 stable libraries, package devs should > clone from that version for every v5 point release to prevent the issue > you are describing. I think there might be a misunderstanding here. Wayne, I think you're saying that there should be a *single* "v5" that is shipped along with 5.x.x KiCad releases? I think Carsten was suggesting to have regular library releases, but use a "v5" tag in the version number to indicate that it is intended for use with any KiCad 5.x.x version. Also, your wording implies (to me) that you're assuming that the libraries will be shipped along with the binary (which I guess makes sense on a Windows-installer based system), but I'm pretty sure that most Linux distros will want to put the libraries in separate packages, which are separately upgraded from the main KiCad binaries. I'm not sure if these misunderstandings really exist, but it seems useful to point them out. Gr. Matthijs signature.asc Description: PGP 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] Future plans on the KiCad library releases?
Hi Wayne, > KiCad should not be determining which libraries get loaded just because > our library layout gets more complex. I would reject any design changed > that loaded libraries outside the users control. Maybe I'm misreading > this but it kind of sounds like that to me. My proposal would indeed be to load libraries, without the user configuring each individual library. However, the user would configure the entire thing (e.g. "load *all* libraries from the default distribution") and can disable the entire thing (and load libraries individually) if he wants more control. As a user, that is exactly the amount of control I want. I don't realy care about which official libraries are in my library list exactly, I just want all of them so I have the broadest choice in components and footprints. Additionally, I don't really want to think about this when upgrading. If I upgrade the libraries package, I really want to still be able to just use all official libraries, without having to check after each upgrade if there is perhaps a new .lib file that was not there before (which, I think, involves removing them all and re-adding them as the easiest way to do that). Currently, if some symbols are split off into a new library, and I forget to check this, they will silently disappear from my choice of symbols, and I might not even realize this (and simply assume a symbol I am looking for does not exist yet). Even if I wanted to go through the trouble of checking the library list on upgrades, I might not always actually realise that I've upgraded when using distribution packages that get upgraded as part of a bigger upgrade. What I write here is how *I* would like to see things as a user. I can imagine this applies to more, if not most, users as well. One additional caveat I recently realized: Even if you would automaticlaly update the list of libraries, you will additionally need to rename/remap some symbols, since symbol references include the library name in v5. One way I can imagine this works is to also include a "rename" specification (perhaps similar to the current rename.json), which can be used by KiCad to automatically migrate older symbol references. Or perhaps the rescue dialog can be improved to look among other libraries for a symbol with the same name and let the user choose between relinking to such a symbol, or resueing one from the cache. Gr. Matthijs signature.asc Description: PGP 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] Future plans on the KiCad library releases?
Hi folks, > > 3. What are the plans for providing coherent library names and the > > introducing new libraries? > We will try to limit such problems. But it might still happen that a library > will be split up into multiple libs if the library gets too large. I had an idea on solving this. Not sure if this is the right place for this suggestion (since it probably requires code changes in KiCad), but it seems relevant enough. I can imagine that KiCad either gets a way to: 1) include all libraries in a given directory (e.g. /usr/share/kicad/something). This should be re-evaluated whenever KiCad starts up, so there should be an explicit "/usr/share/kicad/library/*.lib" entry in the table (or something like that), as opposed to actually putting each library in the table individually, or 2) include a secondary library table from the normal one. Then any kicad library package can ship such a secondary library table, and update it to reflect the new list of libraries. I think these would apply to both symbols and footprints equally. Option 2) seems more elegant and flexible to me. Both options should be able to provide pretty seamless library upgrades for users (and can even be extended to third party library collections, or a user's own libraries). Has something like this ever been considered before? Gr. Matthijs signature.asc Description: PGP 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] Some thoughts on symbol remapping
Hey Rene, > This is not as easy as simply a one to one mapping. The connectors > library has been split into 3 libs. Most other libs into even more. > (Especially manufacturer specific libs.) > In reality the best option for old projects will be to have the v4 libs > installed in addition to the new libraries. Hm, that will get messy. Also, doing that will prevent automatically migrating AFAICS, since the remap will permanently link the symbols to the old libraries. In that case, I guess rescuing symbols from the cache into a rescue lib might work just as well as keeping v4 symbols installed. > And there is another complication. A lot of symbols that had invisible power > pins have been updated to split the power pins in a separate unit as visible > pins. (Example: logic gate ics and op amps) Right, so the reality is that manual work is needed on most symbols anyway, so no need to make automatic migration work at all, I guess that makes some sense. This probably something that needs good documentation and announcements, to prevent user surprise and disappointment. Gr. Matthijs signature.asc Description: PGP 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] Some thoughts on symbol remapping
Hi Wayne, > >> If the remapping algorithm cannot find the exact library match which > >> is currently being used (and should be in the project library list or > >> the cache) to provide the symbol, then there is no way to determine > >> the correct library and therefore cannot be remapped. It also means > >> that your schematic is already broken. This is why you should not > >> skip the rescue feature. > > I can't quite remember if I skipped the rescue dialog (quite possibly), > > but I can imagine a user (such as me) would reason that there is no need > > for rescueing symbols into a rescue library, since all symbols are > > available in their newly set lib table. > > The symbols in your legacy schematic are almost certainly not in the new > symbol library table given the recent changes to the symbol libraries. I was under the impression that symbols mostly got moved around, and only some of them got renamed, but perhaps that impression is wrong. > They are in your old symbols libraries if you haven't updated them or in > your project cache library. Rescuing symbols from the cache is required > to ensure that same symbols that you used to design the schematic. Agreed: If the symbols are not in the new libraries (or not with the same name), rescuing is the way to go. > > Specifically: If my symbols are not available in the old-style library > > list, but are available in the new-style library table, I can see three > > outcomes: > > 1. If I perform a rescue, I get all symbols remapped to the rescue lib. > > This is false. If the cache is corrupt or the symbol cannot be found in > any of the libraries in the project library list, I was working under the assumption of a working cache, should have made that explicit. > > 2. If I cancel the rescue, all symbols are unmapped. > This is false. As long as the symbol can be found in a library in the > project library list (not the symbol library table) it will get > remapped. As I stated, I'm assuming that the symbol is *not* found in the project library list (which I called the "old-style library list"), for example because the old libraries are no longer available or libraries got renamed. > > 3. If I cancel the resecue and my fallback-guessing suggestion is > > implemented, most of my symbols will be mapped correctly (and > > possibly some will be incorrect). > This is false. There is no guarantee that any of the symbols will be > correct or even found by searching through the symbol library table. I did not expect any guarantees, that's why I said most will be correct, some might be incorrect. Perhaps I'm estimating the ratio between correct and incorrect more positive than it is, though. Gr. Matthijs signature.asc Description: PGP 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] Some thoughts on symbol remapping
Hi Wayne, > The symlink issue has been fixed so duplicate libraries will not show up > in the project symbol library table with different nicknames. I noticed some issues with my previous build (2017-12-22), but using the 2018-01-03 build, symlinks (both in the directory and filename) indeed seem to be handled correctly. > > The procedure implemented now (find the symbol in the old list first) > > totally makes sense. However, I would think that *if* this procedure > > fails, looking up the symbol by name in the new list could be a good > > fallback? > > Doing this would completely defeat the purpose of the symbol library > table and reintroduce the bug that has existed since the beginning of > the project. Symbols are now required to be mapped to a specific > library. No more searching through the list of libraries and hoping > that the first instance of a symbol is the correct one. I'm not suggesting to do this all the time, only during remapping. So at that time, the library list is the old one, and is still subject to this ambiguity bug anyway. Also, I'm suggesting to *only* do this if the remapping otherwise fails, so this would just be a best-effort guess. Better to have most of these symbols right, then all of them unmapped? AFAIU any mismappings would also be identified by the subsequent rescue dialog and pointed out to the user. > If the remapping algorithm cannot find the exact library match which > is currently being used (and should be in the project library list or > the cache) to provide the symbol, then there is no way to determine > the correct library and therefore cannot be remapped. It also means > that your schematic is already broken. This is why you should not > skip the rescue feature. I can't quite remember if I skipped the rescue dialog (quite possibly), but I can imagine a user (such as me) would reason that there is no need for rescueing symbols into a rescue library, since all symbols are available in their newly set lib table. Specifically: If my symbols are not available in the old-style library list, but are available in the new-style library table, I can see three outcomes: 1. If I perform a rescue, I get all symbols remapped to the rescue lib. 2. If I cancel the rescue, all symbols are unmapped. 3. If I cancel the resecue and my fallback-guessing suggestion is implemented, most of my symbols will be mapped correctly (and possibly some will be incorrect). As a user, I would prefer outcome #3 over the other two. To fix my schematic from outcome #1 and #2, I will have to manually fix up all involved symbols to point to the right library again (having them point into the rescue library makes the schematic work, but is not preferred when the symbols are available in the symbols). > > [ About code that adds missing old-style libraries to the project > sym-table] > Yes, it exists in eeschema/dialogs/dialog_symbol_remap.cpp. Ah, I expected this to happen only for libraries containing remapped symbols, but I see now it happens for all libraries in the schematic, which makes sense. Thanks. A related question: How are the changes in library layout intended to be handled, when combined with the remapping dialog? AFAIU the migration to the new kicad-symbols repository also involves renaming a lot of libraries (e.g. Connectors.lib -> Connectors_Generic.lib). If you upgrade to this new library layout, the (v4) library list must also be updated to match the new library names? Or is there some automatic conversion for this? When you're still running v4, this can be fixed by manually fixing the library list with the new library names. But when running v5, the library list can (AFAICS) no longer be edited, but it is also assumed to be correct by the remap dialog (which it will not be, then). Or am I missing something here? This would also be a case where the fallback I suggested above could be helpful, though I guess a more reliable method would be better here. Gr. Matthijs signature.asc Description: PGP 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] Some thoughts on symbol remapping
Hi Wayne, I just tried the remapping tool as well, and wanted to share some thoughts on it. This e-mail, where you're explaining how the remapping process works seemed like an appropriate place to reply. I tested this two weeks ago, using the 2017-12-22 daily build ppa, but didn't get around to writing up my experiences until now. Remapping of most of the symbols in my project failed. I couldn't quite reproduce what was failing (and in my reproduction attempts, I think I overwrote the .pro file backup, so can't start from scratch), but I think the problem was that I used to have /usr/share/kicad/library as a symlink, but added the libraries using their canonical path to the library table. I realize that there was a recent fix for this, but I had that fix included (looking at the build date). I suspect that fix only works when the actual file is a symlink, not when a directory further up the hierarchy is a symlink, but I didn't actually test this. > The remapping will not look up by symbol name in the symbol library > table if the symbol is not found in the original library in the old > library list that it was loaded from. I was quite surprised that this didn't happen. In particular, the remapping tool said it couldn't find some symbols, while they were certainly available in the list of libraries I configured. I did not understand why it would not find them. The procedure implemented now (find the symbol in the old list first) totally makes sense. However, I would think that *if* this procedure fails, looking up the symbol by name in the new list could be a good fallback? As I said before, I can't quite figure out what the problem was for me, but I can imagine various ways where library layouts, or library locations change. Especially considering that a project is only remapped when it is opened, it might be that we'll be remapping projects years after the upgrade to v5, or maybe we'll be remaping projects published by others, in both cases it seems likely that libraries live in different places. Would it not make sense to do a best-effort matching in this case, instead of just not remapping the symbols? Some extra confusion rose from the fact that, even though the symbols failed to remap, they were still shown properly. Only when opening the schematic a second time after remapping, the symbols were shown as question marks. I suspect that directly after remapping, eeschema still had the original libraries loaded, which were removed from the project file the second time. Would it make sense to actually unload the old libraries after remapping (if this is indeed what happens)? > Look for the library by path and full file name in the global symbol > library table. If the library cannot be found in the global symbol > library table and the file exists, add this library to the project > symbol library table and give it a unique name if necessary. Is this last part implemented already? I couldn't find any reference in the code when I looked, and I *think* my setup should have triggered adding new libraries instead of failing to remap. Gr. Matthijs signature.asc Description: PGP 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
