I did pmbootstrap zap, update, then index, but it STILL tries to locally build these rather than fetching them from binary repo. Ubuntu 17.10, pmbootstrap up to date with master.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
Thanks for your report! Could you please try the following?
# delete the breeze-icons package to reproduce the issuesudo rm ~/.local/var/pmbootstrap/packages/armhf/breeze-icons-5.40.0-r0.apkpmbootstrap index# zap and update APKINDEX filespmbootstrap -y zappmbootstrap update# clear the log file (~/.local/var/pmbootstrap/log.txt, make a backup if you need it)pmbootstrap log -c# build it with verbose logging. hopefully this reproduces the same issue# (-> it builds the package and does not download it!)pmbootstrap -v build breeze-icons --arch=armhf# please attach this logfilecat ~/.local/var/pmbootstrap/log.txt
I had a similar issue on Manjaro where pmbootstrap tried to build the entire system from scratch (at step 2/5) instead of using the binary files.
Strangely, this issue didn't exist on Ubuntu-based distros or Fedora, but these both had their own issues in that graphical acceleration in QEMU wasn't supported. I could only get to a Weston screen by specifying gl=off in both. (Hildon and XFCE failed to open the framebuffer without graphics acceleration, as expected.) In the case of Ubuntu, I believe this is due to #906 (closed) , and in Fedora due to some sort of OpenGL issue related to libvirt.
@JLIT0: Thanks for reporting! If you could provide the verbose log (as written above) for the packages which get compiled instead of downloaded, that would be equally helpful.
All Qemu errors are worked around by using the LTS kernel for now, so that shouldn't be an issue anymore (that was just merged yesterday in #954).
Not sure if I'm running into the same issue with qt5-qtsensors 5.9.3-r0.
It seems that the check looks at the local repo first, and it's picking up my locally compiled 5.9.1-r0 and concluding that the package needs to be recompiled, without checking the online binary repo.
Turns out the fix is only for what @zhuowei described (reviews/testing welcome!), so I've created another issue to further debug @MoreRobustThanYou's original issue in #1023 (closed).