**** BEGIN LOGGING AT Fri Aug 11 03:00:01 2017 Aug 11 06:40:35 hi, how can i install a dbteplate into /usr/share Aug 11 06:44:25 Guest70595: if its a file that you already have, maybe created externally in some way, then basically create a recipe this way: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#packaging-externally-produced-binaries Aug 11 06:45:29 LetoThe2nd: Ty Aug 11 07:35:57 yates: You were welcome to PM me but it was an hour after I clocked off work when you messaged. Aug 11 07:38:41 So how do/should I tidy up images in tmp/deploy/images/images/? The README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt implies that I should not be deleting them. The content of the file then hints that maybe a I should be deleting them and calling bitbake -c clean . Aug 11 07:39:05 As does the fact that just calling -c clean seems to have no impact on the files left in the directory. Aug 11 07:43:27 deploy is now under sstate control, you have to do -c cleansstate Aug 11 07:53:39 ant_work: thank you. I will give that a go. Aug 11 07:56:02 ant_work: I am using 2.1.3. Should it work there? I still seem to have the same number of image files as before Aug 11 07:57:06 ant_work: Does look like it is regenerating them now though. So if I rm them then call -c cleansstate that should have the effect I am after. Aug 11 07:58:44 afais it's since 6d969ba image: Deploy images to IMGDEPLOYDIR Aug 11 07:58:44 Changed deployment directory from DEPLOY_DIR_IMAGE to Aug 11 07:58:44 IMGDEPLOYDIR... Aug 11 08:06:48 Well it does not delete any files for me. Aug 11 08:07:26 It does cause them to be regenerated on the next bitbake call. So I think it is targetting the files I need it to. Just nothing deletes them. Aug 11 08:08:06 I have a continuous build system and I wanted to tidy up a bit between runs so that the date stamped output files do not keep accumulating for weeks on end. Aug 11 08:08:28 ~40 MB is not a huge amount of disk space but it all adds up over the years. Aug 11 08:08:55 Adds up a lot if I leave uncompressed images around as they are more like ~250 MB. Aug 11 08:34:54 Ahhh Aug 11 08:35:42 -c clean does work. It is possibly some edge case where .rootfs.rpi-sdimg.xz gets left behind. All the other .rootfs.* files only have their latest filestamp version after a -c clean followed by a bitebkae. Aug 11 11:53:27 marquiz_: hey Aug 11 11:58:16 hi Aug 11 12:05:09 hello, I'm trying to deploy some python packages in my image and some of them are missing in "meta-openembedded/meta-python/recipes-devtools/python" layer Aug 11 12:05:16 marquiz_: I just saw https://patchwork.openembedded.org/series/8187/# Aug 11 12:05:23 so I wrote this simple recipe: http://dpaste.com/1WNNAHV Aug 11 12:05:25 is "gnupg" gpg2? Aug 11 12:05:30 but the fetch steps fails because of wrong url: http://dpaste.com/330DYEN Aug 11 12:05:31 yes Aug 11 12:05:36 ah, cool Aug 11 12:05:39 Someone can give me some suggestion? Aug 11 12:06:05 marquiz_, also, are you the guy who works on gbp-rpm? Aug 11 12:06:40 Son_Goku: basically, yes, although i haven't had the time to invest in that lately Aug 11 12:07:11 what's left in gbp-rpm to upstream into gbp? Aug 11 12:07:20 I saw that main gbp seems to have some rpm functionality Aug 11 12:11:50 Son_Goku: yes, upstream supports rpm Aug 11 12:12:05 Son_Goku: but, there's a long list of features not upstreamed Aug 11 12:26:37 marquiz_: well, you can add one more feature not supported ;) Aug 11 12:26:50 rpm, as of 4.14, now supports full datestamp changelog entries Aug 11 12:27:01 so the SUSE-style changes datestamps are now valid for rpm itself Aug 11 12:27:29 they don't need to be truncated when merged into the %changelog section, and you can write changelog entries directly that way Aug 11 12:38:24 Son_Goku: patches are welcome :) Aug 11 12:39:27 marquiz_: if you rebase against current upstream gbp, I might :) Aug 11 12:40:34 Son_Goku: is there something you need from my branch? otherwise you could send a github pull request directly upstream Aug 11 12:41:01 I don't know what you have verses upstream at this point Aug 11 12:41:08 I just found out about gbp-rpm today Aug 11 12:43:51 Son_Goku: ok ;) Aug 11 14:24:53 my image's deploy directory includes a "blah.sdcard" file, which i copied via "dd if=blah.sdcard of=/dev/" Aug 11 14:26:12 but it's not booting right: https://da.gd/Dwf0f -> https://paste.fedoraproject.org/paste/vBqDL1YMmtNpJb9g-X0OVQ/ Aug 11 14:27:15 any clue what i'm doing wrong? Aug 11 14:28:47 will the "dd ..." command automagically configure all the necessary partitions and file system types? Aug 11 14:29:00 no Aug 11 14:29:33 seems like your root FS is ext4, but the filesystem is bigger than your SD card: EXT4-fs (mmcblk0p2): bad geometry: block count 947200 exceeds size of device (160768 blocks) Aug 11 14:30:16 Maybe you should make sure your filesystem is smaller so that it fits on your SD card? Aug 11 14:31:02 i guess that's possible, i haven't looked into what the image is puttin gon the rootfs, but it's a 16 GB sdcard. Aug 11 15:07:33 neverpanic: so the correct file system on the target sdcard is NOT created by dd and the source .sdcard file? Aug 11 15:16:14 Well, it seems whatever you dd'd did contain a partition table and filesystems, just your sdcard wasn't large enough for those. Aug 11 15:19:02 -rw-r--r-- 2 yates yates 675282944 Aug 10 17:35 hw-test-image-imx6ul-var-dart-20170810202047.rootfs.sdcard Aug 11 15:19:34 as i said, it's a 16 GB sdcard. Aug 11 15:19:52 The file might be sparse. The size of the file on your disk is not necessarily the size of the filesystem in it. Aug 11 15:20:45 gparted is also reporting the ext4 partition as being only 628 MiB Aug 11 15:20:59 gparted shows the first partition is unallocated of size 4 MiB, the second partition if a fat16 fs of size 8 MiB, and the third partition is ext4 fs of size 628 MiB. there is final fourth partition "unallocated" of size 13.83 GB Aug 11 15:21:52 something's getting hosed somewhere, this isn't just a "it's too big for the disk" problem. Aug 11 15:23:21 either yocto or whatever tool it depends on isn't generating a proper .sdcard file, or dd isn't copying correctly, or the processor boot loader doesn't correctly interpret the sdcard file systems Aug 11 15:24:23 Well, that matches your log output. It says your mmcblk0p2 is 643072 KiB (= 628 MiB). Apparently you're on 4 KiB blocks for a block size of 160768 blocks. The filesystem says it's 947200 blocks (i.e. 3.6 GiB), though Aug 11 15:24:43 So something's very wrong here Aug 11 15:25:38 You could try loop-mounting the filesystem on your host and see if that works. Aug 11 15:25:46 is there somewhere in the recipes or elsewhere in the yocto build that specifies the final ext4 filesystem size it should use for the .sdcard file? Aug 11 17:01:10 is there a bug in the .sdcard generation routine? gparted reports a bad superblock magic number for the ext4 partition: https://da.gd/tolL -> https://paste.fedoraproject.org/paste/XtRQKX5cSRnyFl80M0vMew/ Aug 11 17:03:51 neverpanic: i found some information on how to extend the rootfs size in .sdcard here: https://community.nxp.com/docs/DOC-105521 Aug 11 17:07:22 still no joy booting, although it's a different problem now. Aug 11 17:07:45 https://da.gd/YGNNF -> https://paste.fedoraproject.org/paste/Y96V3X9nTJ~ZkGY8e0lpEA/ Aug 11 17:07:54 that's as far as it gets, then halts. Aug 11 17:42:08 kergoth: ok thx! Aug 11 18:04:28 yates: Make any progress? That u-boot log you posted ~hour ago looks normal. Aug 11 19:00:50 ok i found the issue. Aug 11 19:00:54 unbelievable. Aug 11 19:01:32 my dd command was getting input/output errors. presumably because i was using a usb cable to the sdcard reader that was a bazillion feet long... Aug 11 19:01:49 it boots just fine now. Aug 11 20:19:44 Having a little trouble: My local.conf has a bunch of CORE_IMAGE_EXTRA_INSTALL packages listed. However, after bitbake -gc , those packages don't appear in the pn-depends.dot. Aug 11 20:25:52 ok, seems like I need to add a packagegroup to my custom layer then add that packagegroup to a custom image Aug 11 20:26:03 Anyone feel free to jump in here. Aug 11 20:32:01 hi ! How do I diagnose whats wrong here: Aug 11 20:32:01 "the basehash value changed from e7329806d9b0ba88ab462a928d464fe2 to c7148535f98d558e0d40951b18d738e8. The metadata is not deterministic and this needs to be fixed." Aug 11 22:07:43 did you muck with metadata when build was going on ? Aug 11 22:07:57 if so then just rebuild and it will be ok Aug 11 22:08:21 otherwise you have some tasks which are using DATE or DATETIME in variable references Aug 11 22:08:32 you can compare signatures of tasks Aug 11 22:22:46 yep, trying https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc) right now Aug 11 22:25:38 khem: sdcard_image-socfpga.bbclass is missing Aug 11 22:25:38 IMAGE_CMD_[vardepsexclude] += "IMAGEDATESTAMP" Aug 11 22:26:28 yeah you might want to add DATETIME DATE and TIME too **** ENDING LOGGING AT Sat Aug 12 03:00:00 2017