OK, let’s try again…
select_trace_kicad_bug.zip (3.7 KB)
1 Like
I can select both.
But its awkward. ZD1 can be selected on both ends and ZD3 only on the left, from the clarify selection drop down menu.
I noticed that the two tracks are ever so slightly tilted (0.0003mm over ~25.5mm)and not horizontal. If you edit them to be horizontal, they can be selected normally again.
3 Likes
Yes I know they can be selected at the end, but normally they should be selectable when clicked at any part of the trace - e.g. in the middle (at least it is that way with other traces).
Tilted you say… possible its the effect of this “weird angle” bug introduced in 5.1.5. Anyway, such tilt should not prevent the tace from being selected.
Just checked: after I manually correct this slight tilt by entering equal Y coordinates for both ends of the segment, it can be selected “normally” - so the weird angle is the culprit here. However:
- why they’re tilted?? (probably the 5.1.5 Interactive router weird track angles bug)
- why can’t select trace with uneven coordinates?
1 Like
I can confirm with 5.99.0-556-gb53501d8c on Windows 10. It’s clearly a bug and I don’t remember seeing a report about this. Please report it and attach the same file.
As a temporary workaround you can select the segment by drawing a selection box to the left (a blue, inclusive selection box) so that it crosses the midline of the segment.
Application: Pcbnew
Version: (5.99.0-556-gb53501d8c), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Build date: Dec 21 2019 22:14:29
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.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
1 Like
The correct “canonical” link to the 5.1 log (gitlab, not github, although github should still be a mirror):
And to the bug database:
Unfortunately I can’t find a milestone for 5.1.6 in the bug reports.
1 Like
The 5.1.6 milestone is here right now. The plan is to make these milestones into group-wide ones so that we have a single milestone to track the code and library issues.
1 Like
OK just reported the issue:
2 Likes
The bug has been closed, but I only see commits to Master, although the bug is tagged for 5.1.6
It has happened before that a bug which affected both versions was closed after fixing it for only one version. Sometimes the fix is cherry-picked into the other branch a bit later. If it doesn’t appear within a couple of days, it’s worth commenting in the bug report.
As it was tagged for 5.1.6 in the first place, this would not be cherry picking, the commit was to the wrong branch, so I may have to submit a new bug report as the defect remains unfixed
In my opinion the commit was to the right branch, it just wasn’t applied to another right branch, and the report lacks another right version tag.
it depends on the situation whether some developer fixes 5.1 or 5.99 first and then cherry-picks the fix to the other. But finally the bug report should reflect both IMO.
I don’t know if the gitlab issue system could handle versioning for bugs so that it could be marked as affecting two versions and then marked as fixed for only one. At least as of now those situations are handled ad-hoc manually and therefore there may be inconsistencies. I suggest commenting on the same report.
I opened this discussion in the dev mailing list.
1 Like
The bug exists in both 5.1 and master branches, therefore it is milestoned with the oldest release it exists in as per KiCad issue tracker guidelines.
In this case the fix gets committed to the master branch, then usually after a few days of testing in the nightlies (to make sure it doesn’t break anything major) it gets cherrypicked to the 5.1 branch.
3 Likes
There has now been a commit to 5.1.x to fix this bug, so can @fred4u try the latest pre 5.1.6 Nightly build to see if all is well now?
This may seem trivial, but where can I find the latest nightlies for pre-5.1.6 (and not the pre-6 nightlies).
I assume only several fixes are cherrypicked onto the 5.1.5 “stable” branch there, so I might give it a try.
The 5.1.x Nightlies are available here
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/5.1/
Choose the most recent for 32 or 64 bit as appropriate
As 5.1.x does not allow new features, these releases are almost as stable as the official releases, but the standard “Back up your work” warning applies, as you should also do for ANY upgrade
I cannot test this myself as the download time is 8 hours and growing, there must be a network problem somewhere
Just downloaded kicad-5.1-jenkins-510-x86_64 without major issues…
I’m on Jenkins (5.1.5-52-g344440955)-1, release build, and this bug seems to be fixed now.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.