**** BEGIN LOGGING AT Mon Apr 24 03:00:02 2017 Apr 24 06:27:50 Someone can help me please I always have some errors messages when I try to bitbake a 32 bit image : ERROR: core-image-base-1.0-r0 do_bootimg: Function failed: build_hddimg (log file is located at /home/bill/poky/build/tmp/work/genericx86-poky-linux/core-image-base/1.0-r0/temp/log.do_bootimg.17773) Apr 24 06:27:50 ERROR: Logfile of failure stored in: /home/bill/poky/build/tmp/work/genericx86-poky-linux/core-image-base/1.0-r0/temp/log.do_bootimg.17773 Apr 24 06:36:21 NOTE: Trying to install /home/bill/poky/build/tmp/deploy/images/genericx86/bzImage as /home/bill/poky/build/tmp/work/genericx86-poky-linux/core-image-base/1.0-r0/core-image-base-1.0/hddimg/vmlinuz Apr 24 06:36:21 install: cannot stat ‘/home/bill/poky/build/tmp/deploy/images/genericx86/bootia32.efi’: No such file or directory Apr 24 06:36:46 someone can help me please ? Apr 24 07:26:18 someone can tell me if a yocto image works on an AMD 32 processor please ? Apr 24 07:36:15 hamydea : Look through meta-amd Apr 24 08:13:39 someone can tell me if a yocto image works on an AMD 32 processor please ? Geode LX800 Apr 24 08:20:40 hamdyaea : Look through meta-amd. Everything is there. Apr 24 08:21:46 ChrysD: there are the video driver only and it's broken Apr 24 08:22:56 and I need to know if a yocto image can be bitbake for this computer : https://www.syslogic.com/ProductDocuments/deu/DS_M-COMPACT8-v1.0.pdf Apr 24 08:23:00 how can I know ? Apr 24 08:26:14 hamdyaea : it should work for this computer. Apr 24 08:27:09 hamdyaea : if you check internet for this processor you ahve some yocto project. You have to check yourself more. Apr 24 08:28:19 hamdyaea : I'm new in yocto but as for me yocto = intel, i won't be surprised that there is no amd processor support. Apr 24 08:28:36 hamdyaea : Can't help with this Apr 24 08:29:41 hamdyaea : But according to this link, yocto "started" to accept amd processor platform https://www.linuxfoundation.org/news-media/announcements/2014/04/embedded-linux-yocto-project%E2%84%A2-announces-amd-and-mentor-graphics-new Apr 24 08:29:48 * rburton didn't see backlog but if the AMD is x86-compatible then the genericx86 BSP, meta-intel, and meta-amd exist Apr 24 08:31:00 hamdyaea : and if you refer to the meta-amd/common/readme # meta-amd/common This layer contains metadata that is appropriate for all AMD-based platforms. Settings in this layer should use appropriate variable suffixes to ensure they only apply to expected boards. Apr 24 08:32:03 hamdyaea: what are you trying to do? Apr 24 08:35:54 ChrysD: Thanks for the information Apr 24 08:36:31 hamdyaea : When I say started, if you checked the date of the article, it was on 2014 Apr 24 08:39:29 hamdyaea: amd and x86 are binary compatible so if you just want something to boot then the genericx86 machine in meta-yocto-bsp will work. meta-amd would be for specific tuning and hardware quirks for specific boards: falcon, seattle, step eagle. (whatever they are) Apr 24 08:40:05 hamdyaea: Hope you don't take this the wrong way, but it seems like you're making you life overly complicated by building your own distribution for your box? :) Apr 24 08:40:33 hamdyaea: Also, according to the PDF you posted, this box has an Intel Atom processor. Why are you messing about with AMD? Apr 24 08:44:13 Hello! I added the following qt examples to my image: IMAGE_INSTALL += "cinematicexperience qt5-opengles2-test". As a result, in do_rootfs I get the following errors: Apr 24 08:44:14 [log_check] Error opening package - qtdeclarative-dev-5.7.0+git0+d48b397cc7-r0.cortexa9hf_neon.rpm [log_check] Error opening package - qtdeclarative-staticdev-5.7.0+git0+d48b397cc7-r0.cortexa9hf_neon.rpm [log_check] Error opening package - qtdeclarative-dbg-5.7.0+git0+d48b397cc7-r0.cortexa9hf_neon.rpm Apr 24 08:44:33 These packages exist, however they have a size of 0 bytes. I do not know how to proceed? Apr 24 09:00:06 rburton: OK I will try Apr 24 09:00:41 hamdyaea: but if the box does have an atom as joif says, then you want meta-intel's BSPs Apr 24 09:01:17 JoiF: I have two computers of this series : the ml6 and the ml8 the ml8 is an intel atom and the ml6 is an AMD.. Apr 24 09:04:28 so they're effectively binary compatible and you can just use a genericx86 machine on them Apr 24 09:29:03 rburton: I try to test with something already bake from there : http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.1/machines/ Apr 24 10:35:02 What is the difference between using SRC_URI="...;rev=abc" vs setting SRCREV="abc"? Apr 24 10:35:48 kanavin: would you like to own #11181? I know you love removing stuff as much as I do. Apr 24 10:36:29 Because I see failures on building the recipe if the SRC_URI rev is updated on hg. Then it complains that the repo does not contain this rev, and I'm wondering if this is due to either an error in the fetcher or if the recipe is wrongly written Apr 24 10:37:12 It works if I clean the sstate cache. Then it will refetch the repo and thus get the newly added SCM revision Apr 24 10:37:21 sounds like the fetcher is bust Apr 24 10:37:27 never used hg though Apr 24 10:38:21 rburton: generically, setting SRC_URI rev= should be enough? Apr 24 10:39:24 i'd prefer SRCREV Apr 24 10:40:00 An omit rev= from SRC_URI? I'll try that to see if that fixes the problems. Apr 24 11:35:41 rburton: yes, sure Apr 24 11:47:55 someone know how to add python-pip ? Apr 24 11:48:02 python 2 Apr 24 11:50:27 https://layers.openembedded.org/layerindex/branch/master/recipes/ is usually a good place to start -- based on a search meta-python layer has python-pip recipe Apr 24 11:51:17 hamdyaea : It's sure tant in meta-oe you will find a python packages or using some Image_features. Apr 24 12:29:22 nrossi: I'm trying to run QEMU w/meta-xilinx, but getting a virtio error: qemu-system-aarch64: -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02: No 'PCI' bus found for device 'virtio-net-pci' Apr 24 12:29:51 nrossi: And Google isn't much help.. Apr 24 12:30:03 nrossi: Have you stumbled upon this/such a problem? Apr 24 12:50:17 JoiF: which branch? Apr 24 13:00:22 nrossi: Morty Apr 24 13:01:10 nrossi: MACHINE=qemu-zynq7 bitbake core-image-minimal followed by runqemu qemu-zynq7 Apr 24 13:01:51 nrossi: I'm beginning to suspect that this is a PEBKAC on my behalf Apr 24 13:02:08 JoiF: maybe not, let me do a test Apr 24 13:12:00 nrossi: What also puzzles me is that those parameters aren't coming from the *.qemuboot.conf file that it claims to be using Apr 24 13:12:52 JoiF: they are coming from the runqemu script, but it shouldn't be occuring Apr 24 13:44:59 JoiF: hmmm cant reproduce, in the deploy/*.qemuboot.conf does it have the qb_slirp_opt and qb_tap_opt strings? Apr 24 13:46:09 JoiF: Also, can you confirm that runqemu ouputs "CONFFILE: ..." as the expected path Apr 24 13:47:55 nrossi: It does not. Neither qb_tap_opt nor slirp. Apr 24 13:47:57 runqemu - INFO - CONFFILE: /mnt/yocto/irma-nat/build/tmp/deploy/images/qemu-zynq7/core-image-minimal-qemu-zynq7-20170424114648.qemuboot.conf Apr 24 13:48:08 Path seems reasonable to me :) Apr 24 13:48:23 JoiF: what commit id of meta-xilinx are you on? Apr 24 13:54:01 nrossi: Errr.. Let me check a few things.. Apr 24 13:55:37 nrossi: So, about that PEBKAC.... Apr 24 13:59:25 JoiF: mixing branches? :) Apr 24 13:59:36 nrossi: Yup! Apr 24 13:59:49 nrossi: Sowwy... Apr 24 14:04:54 nrossi: saster of meta-xilinx and morty of poky Apr 24 14:05:07 s/saster/master/ Apr 24 14:05:56 JoiF: yes that would be problematic, surprised you got as far as you did Apr 24 14:09:39 nrossi: Haha Apr 24 14:09:48 nrossi: It's almost running now. Apr 24 14:10:14 I.e. qemu actually runs, but then just hangs after "[ 1.671398] usbhid: USB HID core driver" Apr 24 19:51:12 Is there a correct way to have a script which calls `cmake` work correctly in the SDK? It appears that cmake is aliased to provide the right toolchain file, but that alias doesn't exist in executed shell or makefiles. Do I just need to have those shell scripts that call cmake be SDK aware and append the CMAKE_TOOLCHAIN_FILE? that seems a bit dirty Apr 24 19:53:11 jmesmon: the env file should do it Apr 24 19:53:18 I guess you are talking about SDK Apr 24 19:55:25 yep, in the SDK. env file has 'alias cmake="cmake -DCMAKE_TOOLCHAIN_FILE=$OECORE_NATIVE_SYSROOT/.../OEToolchainConfig.cmake"' Apr 24 19:55:39 But shell aliases aren't inherited by child processes Apr 24 19:56:13 So unless I call cmake directly by typing it, the CMAKE_TOOLCHAIN_FILE cmake variable isn't set Apr 24 19:56:24 This is in morty, btw. Apr 24 19:58:16 jmesmon: are you trying to automate cmake calls? Apr 24 19:59:03 usually SDK env works well for interactive use Apr 24 20:00:41 may be creating small scriptlets instead of alias is what you can think of using here Apr 24 20:04:10 hmm, I can't find that bit in the env file Apr 24 20:13:25 Crofton|work: it's in the native sysroot environment-setup.d/cmake.sh Apr 24 20:13:47 (presuming your sdk includes nativesdk-cmake or similar) Apr 24 20:14:44 hmm Apr 24 20:22:33 I suppose khem is suggesting that I modify the cmake recipe to generate a wrapper script with the name `cmake` that passes the appropriate CMAKE_TOOLCHAIN_FILE flag, and install real cmake as something like `cmake.real`? Apr 24 21:15:10 hi there anyone has luck in getting prelink working with yocto ? Apr 24 21:49:45 embexus: we use prelink by default? Apr 24 21:51:09 jmesmon: we do have a function which creates such wrapper scripts (create_wrapper and create_cmdline_wrapper) iirc Apr 24 22:19:39 FATAL ERROR: python callback ??? failed, aborting! Apr 24 22:19:42 that's not useful, dnf Apr 24 22:20:47 heh, and I'll bet there was a sea of meaningless red backtrace prior to that one line gem.... Apr 24 22:21:33 nope Apr 24 22:21:39 absolutely fine rootfs Apr 24 22:21:41 then bang Apr 24 22:23:08 well, I guess "dnf" is living up to its namesake of "Did Not Finish"... Apr 24 22:24:06 hm a patch to grub in 2015 isn't in our build Apr 24 22:32:26 * paulg wishes grub didn't depend on 32bit toolchain ; I'd dump grub2 in a heartbeat for my 64bit x86 builds in a heartbeat otherwise.... Apr 24 22:34:48 speaking of which, damn you grub Apr 24 22:34:52 * rburton -> bed **** ENDING LOGGING AT Tue Apr 25 03:00:02 2017