FS#47903 - [kicad] error with repo build disappears with manual build

Attached to Project: Community Packages
Opened by Sjoerd Timmer (sjoerd) - Tuesday, 26 January 2016, 12:48 GMT
Last edited by Morten Linderud (Foxboron) - Saturday, 06 June 2020, 14:40 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Kyle Keen (keenerd)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
When placing traces in opengl mode every mouse click results in an "Error during data upload to GPU memory" (modal dialog, after closing the program continues to work properly). This is probably an upsteam bug. However:
This can be fixed by doing:
yaourt -G kicad
cd kicad
makepkg -i

There is 1.15MB diskspace change between the packages...

Additional info:
* kicad 4.0.1-2
* tested on x86_64 intel cpu with onboard graphics (two different machines actually)
This task depends upon

Closed by  Morten Linderud (Foxboron)
Saturday, 06 June 2020, 14:40 GMT
Reason for closing:  None
Comment by Doug Newgard (Scimmia) - Tuesday, 26 January 2016, 14:25 GMT
Does rebuilding in a clean chroot fix it? I'm guessing not, the build system is likely detecting something on your system and automatically building support for it.
Comment by Sjoerd Timmer (sjoerd) - Tuesday, 26 January 2016, 15:48 GMT
You are correct. I just rebuilt kicad in a chroot and I get a 0MB package upgrade size with respect to the binary from the repo. The error is indeed present with this build. Would it help if I sent you the output of "pacman -Q"/"hwinfo"/etc. Is there anything in particular that could be helpfull?
Comment by Kyle Keen (keenerd) - Tuesday, 26 January 2016, 16:44 GMT
hwinfo won't be too helpful. The problem is a missing dependency in our kicad package, not upstream. So it'll be something in 'pacman -Q' but probably only a single item out of the +1000 you likely have installed. If you want to do some detective work, can you narrow down which package is missing?
Comment by Doug Newgard (Scimmia) - Tuesday, 26 January 2016, 17:09 GMT
A comparison of the build log between your system and a clean chroot may help.
Comment by Sjoerd Timmer (sjoerd) - Friday, 29 January 2016, 08:42 GMT
Doug Newgard: excellent idea! On it now...
Comment by Sjoerd Timmer (sjoerd) - Friday, 05 February 2016, 12:10 GMT
It is very hard to pinpoint when this bug does and does not occur. I have built several times inside and outside of chroot environments. Results are varying. Last week all versions built in chroots were faulty and all builds on the host system were non-buggy. However, doing repeating the steps (to produce buildlogs) results in buggy build all the time....
Comment by Sjoerd Timmer (sjoerd) - Friday, 05 February 2016, 12:20 GMT
Also, I did not see any noticable differences in the buildlogs. I have deleted them now to do some fresh builds after a kernel update and system reboot. The only differences I noticed before are different build folders and the presence of hardening-wrapper on the host (which is absent in chroot). When the new builds are done I'll post the buildlogs here...
Comment by Sjoerd Timmer (sjoerd) - Friday, 05 February 2016, 14:06 GMT
No, it has now become impossible to fix this bug by recompiling:s
I have no idea what changed :s
Comment by Ivy Foster (escondida) - Thursday, 10 October 2019, 04:17 GMT
Does this bug still exist in the current version? I'm not sure how to place a trace in order to test it.

Loading...