giseldo/neodataset huggingface dataset:
Footprint library browser don't works in Legacy toolset (lp:#1842483)

[Original report](https://bugs.launchpad.net/bugs/1842483) created by **Piotr Gałka (piotrgalka)**
```
5.1.4
When you have Legacy toolset active then Footprint library browser don't
works.
The footprint window instead being black is white and nothing is shown when
you select footprint.
When you switch from Modern to Legacy Library browser works till you rerun
KiCad (or only Footprint editor-not sure). The same if you switch from
Legacy to Modern - it don't helps till you rerun program.

The problem is that Legacy seems to be default (may be only in Footprint
Editor).
I have installed 5.1.4 (Windows) some time ago at two PCs. At one I'm
working, at second it is with default libraries. I wonted to search for one
footprint in default libraries so I run today Footprint Editor for the
first time then I run Library browser and zonk. I didn't understood what is
going on.

May be instead of fixing it the better would be to gray the Library Browser
in Footprint Editor menu when Legacy is selected (as Legacy is to be
removed).

Application: ModEdit
Version: (5.1.4)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6
libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit,
Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: pcbnew

Story points: 6.0
Strange tooltip for cvpcb filter (by symbol keyword) (lp:#1842477)

[Original report](https://bugs.launchpad.net/bugs/1842477) created by **Rene Poeschl (poeschlr)**
```
If i understand this filter correctly then it is the one that uses the
footprint filters as defined in the symbol. I feel keyword might be
confusing here as both the symbol and footprint also have keyword fields
(that are not used for this filter as far as i am aware)

Maybe "use the symbols footprint filter(s)" is a better tooltip (or
something similar)

I am on 5.1.4 in case this differs in nightly.
```
Original tags: eeschema ui

Story points: 6.0
Creating cache lib error multiplied (lp:#1842452)

[Original report](https://bugs.launchpad.net/bugs/1842452) created by **Piotr Gałka (piotrgalka)**
```
In my schematic I have only one element named T68CA.
Having my schematic opened I deleted that element from library.
{Precisely: It was alias. I renamed that alias. I reopened the symbol
editor to see the new symbol created with my old alias name. I deleted that
new symbol. So there are no that symbol in library.}
I closed the symbol editor and returned to schematic.
I closed schematic - nothing happened.
I opened schematic. It wonted to (I'm not sure words used here) rescue that
symbol.
I canceled it.
When I wonted to save schematic I got an error - Error1.png and it is OK.
I pressed [See details >>] button and I got Error2.png.

I think there should be only one error and not the probably endless list.

Application: KiCad
Version: (5.1.4)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6
libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit,
Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: eeschema

Story points: 6.0
Schematic junction implementation (lp:#1842438)

[Original report](https://bugs.launchpad.net/bugs/1842438) created by **eelik (eelik)**
```
The next is copied from https://bugs.launchpad.net/kicad/+bug/1842355.

I'm not sure if this is the right place to talk about this, but I find the
concept of independent junction dot weird. Junction should be a property of
two or more wires crossing (or endpoints touching, or endpoint touching
another line) and there shouldn't exist any junction without two wire
lines.

From the standpoint of implementation it may be easier to have separate
junctions but they should very strictly depend on existence of a wire
crossing. For example, instead of

junction: xcoord,ycoord

there could be

junction:
   wire: id
   wire: id

But at least, if they are separate independent entities, they should be
updated very stricly with any change made to wires. The update mechanism
should be "waterproof". I've seen different situations when junction don't
correctly reflect changes made to the wires.

It shouldn't be possible to add junctions where there are no wires
crossing, and there should never be need to remove junctions except from
where wires are crossing. "Add junction" shouldn't blindly add a junction
dot, it should only make a junction out of two wires crossing each other.
```
Original tags: eeschema

Story points: 6.0
eeschema ERC: "Pin not connected..." error wrong (false positive) using hierarchical labels (lp:#1842422)

[Original report](https://bugs.launchpad.net/bugs/1842422) created by **Dino Ghilardi (dino-ghilardi)**
```
In the attached file, there is a child sheet with a resistor connected to
two hierarchical labels both named "a".

Running ERC the result is that a "false positive" on the connection for the
two pins of the resistor is issued, but they are connected (verified
synchronizing the schematic with the pcb)

Placing the correct hierarchical pin on the child sheet block makes this
"false positive" disappear.

Cheers,
Dino.



--------------------------------
ERC report (mar 03 set 2019 14:08:06 CEST, Encoding UTF8 )

***** Sheet /
ErrType(6): Mismatch between hierarchical labels and pins sheets
   @ (160,02 mm, 91,44 mm): Sheet label sheetPinNotConnectedInside is not
connected to a hierarchical label.

***** Sheet /Sheet5D734418/
ErrType(6): Mismatch between hierarchical labels and pins sheets
   @ (140,97 mm, 97,79 mm): Hierarchical label a is not connected to a
sheet label.
ErrType(2): Pin not connected (use a "no connection" flag to suppress this
error)
   @ (152,40 mm, 97,79 mm): Pin 1 (Passive) of component R1 is unconnected.
ErrType(6): Mismatch between hierarchical labels and pins sheets
   @ (140,97 mm, 105,41 mm): Hierarchical label a is not connected to a
sheet label.
ErrType(2): Pin not connected (use a "no connection" flag to suppress this
error)
   @ (152,40 mm, 105,41 mm): Pin 2 (Passive) of component R1 is
unconnected.

 ** ERC messages: 5  Errors 0  Warnings 5

----------------------------------------------------
Application: Eeschema
Version: (5.1.4), release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.52.1 OpenSSL/1.0.2s zlib/1.2.8 libidn2/0.16 libpsl/0.17.0
(+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Platform: Linux 4.9.0-8-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.52.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: eeschema erc

Story points: 6.0
EESchema ERC: "Mismatch between hierarchical labels and pin sheets" error missing (lp:#1842420)

[Original report](https://bugs.launchpad.net/bugs/1842420) created by **Dino Ghilardi (dino-ghilardi)**
```
In master branch, the error "Mismatch between hierarchical labels and pin
sheets" is not issued anymore. In stable versions (5.1.2 and 5.1.4) still
works.

To reproduce it:
1)create a new hierarchical sheet
2) add a hier. pin with "Place hierarchical pin in sheet"
3) inside the child sheet place a resistor and connect it to two
hierarchical labels with a name different from the one in the parent sheet
block (call them both "a")
4) Run the ERC: No error is issued.

(attached file: the project with this issue)

Running ERC on the same file using stable version you get 3 errors for
"Mismatch between hierarchical labels": correct. (also two more errors that
are not correct, subject for another minor bug report)



Note: May be related to Bug #1781725, but there the "Mismatch between..."
error is reported to work correctly.
----------------------------------------------------------------------
Application: Eeschema
Version: (5.99.0-52-gefbc802f4), release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.52.1 OpenSSL/1.0.2s zlib/1.2.8 libidn2/0.16 libpsl/0.17.0
(+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Platform: Linux 4.9.0-8-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.52.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: eeschema erc

Story points: 14.0
Can't tune pcb trace length to be over 2147mm (lp:#1842367)

[Original report](https://bugs.launchpad.net/bugs/1842367) created by **Harvie (harvie)**
```
I need to create PCB with ridiculously long traces (4000 to 8000mm) and i
wanted kicad to generate the zig-zag pattern for me, so i've tried "tune
track length" feature. But it turns out the longest trace i can do is
2147mm, 2148mm and more can't be done.

Can you please increase this?

According to IRC it's probably caused by internal representation of length
in micrometers as signed 32 bit number... So i understand it might be hard
to increase.

Thank you
```
Original tags: pcbnew

Story points: 6.0
Eeschema: Phantom floating junctions on cut/copy/paste (lp:#1842355)

[Original report](https://bugs.launchpad.net/bugs/1842355) created by **Michael Kavanagh (michaelkavanagh)**
```
Cut and paste a block of schematic containing wire junctions. Observe
strange floating junctions shown in screen shot.

Application: Eeschema
Version: (5.99.0-51-g4c9e4c947), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1
Platform: Mac OS X (Darwin 18.7.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
    Boost: 1.70.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.54.0
    Compiler: Clang 10.0.1 with C++ ABI 1002

Build settings:
    KICAD_SCRIPTING=OFF
    KICAD_SCRIPTING_MODULES=OFF
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
    KICAD_STDLIB_DEBUG=OFF
    KICAD_STDLIB_LIGHT_DEBUG=OFF
    KICAD_SANITIZE=OFF
```
Original tags: eeschema

Story points: 8.0
macOS-specific menu bar items should be at the bottom (lp:#1842306)

[Original report](https://bugs.launchpad.net/bugs/1842306) created by **Michael Kavanagh (michaelkavanagh)**
```
Nitpicking, I know, but it's a bit jarring to (new) users expecting
Undo/Redo at the top of the Edit menu and instead getting "Start
Dictation..." and "Emoji & Symbols".

Also "Enter Full Screen" should be at the bottom of the View menu.

Application: KiCad
Version: (5.99.0-48-g762dabd75), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1
Platform: Mac OS X (Darwin 18.7.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
    Boost: 1.70.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.54.0
    Compiler: Clang 10.0.1 with C++ ABI 1002

Build settings:
    KICAD_SCRIPTING=OFF
    KICAD_SCRIPTING_MODULES=OFF
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
    KICAD_STDLIB_DEBUG=OFF
    KICAD_STDLIB_LIGHT_DEBUG=OFF
    KICAD_SANITIZE=OFF
```
Original tags: macos ui

Story points: 6.0
Idea: compatibility section in file formats (contains warning texts to be printed when opened in older versions) (lp:#1842285)

[Original report](https://bugs.launchpad.net/bugs/1842285) created by **Rene Poeschl (poeschlr)**
```
I just discovered a possibly useful feature in the eagle file format. They
include a section called compatibility which contains warnings to be
printed if opened in an older version.

Might be something interesting to add to kicad to prepare for a time when
the file format becomes much more stable than it is now (If only minor
additions are made then these can possibly ignored by the user. But the
user would need to know what they loose by opening in an older version.
This is one way of telling an older version which warning messages to print
without the older version even being aware of the features it does not
support.)

It could theoretically also include information for the parser on how to
replace some unknown things such that they can parse the file kind of
safely.

For example it could contain information which file format tags can be
ignored without changing the outputed file. The differential net clearance
setting added with v5 would be such an example. Ignoring it does not change
the viewed file it only removes a routing feature.

Chamfered pads are a different beast. They would only be able to be
replaced by another similar pad type and therefore change the file ->
should be an error. But instead of a parser error it would then say "you
use a kicad version that does not understand chamfered pads introduced in
version 6.0.0." which is much easier to understand by the user. (in reality
a warning could then only be produced by 7.x features as 5.x and earlier
does not understand this feature. But i have no example for such a future
release.)
```

Story points: 6.0
wishlist: eeschema: don't un-annotate on cut-and-paste (lp:#1842275)

[Original report](https://bugs.launchpad.net/bugs/1842275) created by **Dino Ghilardi (dino-ghilardi)**
```
In the current master version, when you cut and paste a part of a
schematic, it is un-annotated. On copy-paste that is good since you are
always adding components, but in a cut-paste it may let you loose some of
the work done.

Example:
You have a fully routed (complex) board.
You need to re-organize schematics moving some components from one sheet to
another, so you use "cut and paste" to do this.
When you paste the components they get un-annotated
When you re-synchronize the pcb you need to re-annotate components, then
the components you moved/reannotated are removed and put back as "new"
components with new reference, loosing the previous placement, so you need
to place the components once again. Also if the components get the same
reference they are removed and re-inserted as new components when you re-
syncronize the pcb.



Cheers,
Dino.

Note: may be this wish is related to Bug #1827503 "Implement more (and
custom?) annotation schemes"
```
Original tags: eeschema ui

Story points: 6.0
Timestamp generation unsafe for scripting, year 2038 (lp:#1842253)

[Original report](https://bugs.launchpad.net/bugs/1842253) created by **Simon Richter (sjr)**
```
Looking at GetNewTimeStamp() in the aptly named common/common.cpp, this
takes the lower 32 bits (as that is the definition of timestamp_t) of
current Unix time and, if needed, increments it to avoid collisions when
multiple components are created in the same second:

    timestamp_t GetNewTimeStamp()
    {
        static timestamp_t oldTimeStamp;
        timestamp_t newTimeStamp;
        newTimeStamp = time( NULL );
        if( newTimeStamp <= oldTimeStamp )
            newTimeStamp = oldTimeStamp + 1;
        oldTimeStamp = newTimeStamp;
        return newTimeStamp;
    }

This is reasonably safe for GUI operation, as we can assume that it is
unlikely that the user creates a large number of components, then closes
and reopens the program, and proceeds to add more components.

When eeschema gains scripting support, this might fall flat though when one
script creates a large array of components and subsequently terminates (so
the record of the highest ID in use is lost), and the user then starts
another script or begins editing manually.

This will also break down in 2038, when the 32-bit counter wraps around.
This is less of a collision risk, but we lose ordering.

Two changes, both somewhat beginner friendly:

 - find out why we're limited to 32 bits and what needs to be done to
change this.

It should be safe to replace timestamp_t by time_t, but there was probably
a good reason why that wasn't done. This needs some archaeology.

 - Move oldTimeStamp into the SCH_SHEET class and update it during load.

This requires that everyone generating timestamps does so with a sheet as
context, and there might need to be some handling for duplicate timestamps
on different sheets.

It might also make sense to stop generating identifiers from the current
time and just use incrementing numbers -- but we need to get better at
detecting duplicates then.
```
Original tags: starter

Story points: 6.0
Custom pad arc primitive start and center exchanged in dialog (lp:#1842199)

[Original report](https://bugs.launchpad.net/bugs/1842199) created by **Rene Poeschl (poeschlr)**
```
The custom shape primitive dialog shows the center as start point. The file
format calls these start and end (but start is the center strangely. Might
be something for v6 to fix as the file format is not really readable this
way.)

My kicad version:
Application: ModEdit
Version: 5.1.4-1.fc30, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.65.3 OpenSSL/1.1.1c-fips zlib/1.2.11 brotli/1.0.7
libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.9.0/openssl/zlib
nghttp2/1.39.2
Platform: Linux 5.2.9-200.fc30.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.65.3
    Compiler: GCC 9.1.1 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: pcbnew

Story points: 12.0
Constrain outline for zone still allows non-constrained outline (lp:#1842195)

[Original report](https://bugs.launchpad.net/bugs/1842195) created by **eelik (eelik)**
```
Constraining zone outline to n*45 degrees allows some weird things. Outline
can be something else than n*45 degrees. Video attached.

Application: Pcbnew
Version: (5.99.0-43-g33625dbd9), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6
libidn2/2.0.5 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: pcbnew

Story points: 10.0
Import Vector Graphics File: Cannot import if extension is not lowercase (lp:#1842180)

[Original report](https://bugs.launchpad.net/bugs/1842180) created by **Aleksandr Sh (dsa-t)**
```
If I try to import .DXF file, it says "There is no plugin to handle this
file type". If I change the extension to .dxf manually in File: field, it
imports properly (This works because Windows is case-insensitive, I guess).


Application: Pcbnew
Version: (5.1.4-40-gb991beb71)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6
libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: dxf import pcbnew

Story points: 14.0
EEschema 5.1.4: When trying to resize some wires in EESchema wrong end is consistently selected (lp:#1842175)

[Original report](https://bugs.launchpad.net/bugs/1842175) created by **Luis Mendes (luis-p-mendes)**
```
In EESchema, the same wire end seems to always be selected independently of
the end the user clicks, when trying to resize a wire. In such cases the
user has to delete the wire and redraw it.
```
Original tags: eeschema

Story points: 6.0