**** BEGIN LOGGING AT Wed Jun 27 03:00:01 2018 Jun 27 03:02:33 aehs29: Could you elaborate on why _remove should be avoided? Jun 27 03:28:15 jynik: basically remove is final, if something tries to put stuff back on it wont be possible Jun 27 03:28:41 jynik: you may ask why would you put stuff back on, but believe me it happens Jun 27 03:29:51 aehs29: Sure, I could imagine one layer doing one thing, another elsewhere, and so on. Jun 27 03:29:54 jynik: usually youd try to do something like that from another layer for some specific reason which that layer requires, but the remove operation will come at the end, and it would still be removed Jun 27 03:30:09 Makes sense, thanks Jun 27 03:30:15 jynik: np Jun 27 03:31:06 Been working with sumo on Ubunt 18.04 for the last week or two -- so far so good Jun 27 03:31:12 *Ubuntu Jun 27 03:32:04 zeddii: zeddii_home Im working on getting poky-tiny to work on arm, linux-yocto-tiny is incompatible with arm, because of the way it is set up, would we want to do the same that we have for x86 or would i tbe better to have something different?, at this point Im using OVERRIDES to provide a defconfig Jun 27 03:32:18 jynik: nice Jun 27 03:32:40 huh ? Jun 27 03:33:21 if we want to support anything in linux-yocto, no defconfigs. so I can easily create a top level BSP description for it. Jun 27 03:33:49 * zeddii_home goes to look. Jun 27 03:34:06 zeddii_home: no yeah of course, im just saying thats what I have right now to skip the error Jun 27 03:34:12 gotcha. Jun 27 03:34:32 which kernel rev are you working with ? 4.14 ? Jun 27 03:35:34 zeddii_home: I built 4.15 but it really doesnt matter, the latest? Jun 27 03:35:48 zeddii_home: ERROR: Could not locate BSP definition for qemuarm/tiny and no defconfig was provided Jun 27 03:35:54 yah. 4.15 is fine. Jun 27 03:35:59 zeddii_home: so qemuarm/tiny doesnt exist Jun 27 03:39:59 I just created it here. doing a quick smoke test. Jun 27 03:40:36 zeddii_home: oh awesome, let me know if you need anything from me Jun 27 03:42:08 New news from stackoverflow: Where is the source code of PetaLinux Xen? Jun 27 04:24:11 aehs29: caling it a night now, but I just pushed what qemuarm needs to configure for poky-tiny Jun 27 04:24:38 can send a patch tomorrow Jun 27 04:41:41 zeddii_home: alright, thanks! Jun 27 06:42:40 New news from stackoverflow: How to build customer added *.bb files on Yocto project? Jun 27 06:59:53 exit Jun 27 07:12:47 New news from stackoverflow: Fetch failed in OE BitBake Jun 27 07:29:23 good morning folks :) can i set yocto compile parameters for grub ? i always get an error on compile recipe for target 'cs5536.module' failed and disk.module and usb.module and all receipe failed Jun 27 08:28:37 chronos: hi, which yocto version do you use? Jun 27 08:29:18 nayfe 2.2 morty Jun 27 08:42:12 chronos: maybe backport grub new recipes to morty or migrate to new yocto version Jun 27 08:46:08 how to backport grub new recipes? Jun 27 08:48:20 chronos: first can you pastebin your compile log ? you can create a layer and put recipes in it to backport Jun 27 08:53:25 nayfe ofcourse one moment Jun 27 08:57:18 nayfe: http://batman.gyptis.org/zerobin/?12c64a1484e16774#/pzGbERDSM9KUsfO0JSZABqI5mLC9bT2m4GQ6RqdaIs= Jun 27 08:57:27 is the compile log of grub Jun 27 08:59:38 chronos: which host distro do you have ? Jun 27 09:09:14 debian Jun 27 09:12:57 maybe found a solution patching the bb file with BUILD_LDFLAGS += "-no-pie" Jun 27 09:43:18 New news from stackoverflow: Gumstix Overo Yocto run on boot Jun 27 12:00:46 Is there a way to configure the compression used for the kernel image (uImage)? Running file on the uImage generated says that Linux is compressed with gzip. Modifying meta/classes/kernel-uimage.bbclass to pass "-C lzma" to uboot-mkimage does not change this (likely the wrong place and way anyway). Also, I am not able to switch the kernel compression algo using "make menuconfig" when running Jun 27 12:00:52 "linux-yocto -c devshell". Any ideas? Jun 27 12:01:56 background: I have a U-Boot binary which I can (currently) not update and that is not able to decompress gzip. However, lzma works. Jun 27 12:08:06 hey guys! I seem to mess my rpm generation: I got wrong rpm name that differs from my recipe name. Is there any override for the produced package name? setting ${PN} doesn't help... Jun 27 12:37:49 i'm getting this error when trying to generate the initrd for meta-swupdate: https://paste.fedoraproject.org/paste/W1H3ukqfjThyRy4J9afs9w Jun 27 12:37:56 as described here: http://sbabic.github.io/swupdate/swupdate.html Jun 27 12:39:39 maxin: you're SWAT this week? Jun 27 12:40:10 maxin: https://autobuilder.yocto.io/builders/nightly-no-x11/builds/1092/steps/BuildImages/logs/stdio needs to be filed as a parallel make race in libsdl2 in master Jun 27 12:41:27 RP: ok, will file it.. Jun 27 12:41:33 maxin: thanks Jun 27 12:54:47 hello, I'm trying to use YP with initramfs Jun 27 12:54:52 https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-an-initramfs-image Jun 27 12:55:26 I don't understand how to check if everything has been built Jun 27 12:56:16 my runtime tests are always mounting /dev/mmcblk0p2 and I don't have any evidence of the initramfs step Jun 27 12:57:29 I wonder if anybody already experienced a initramfs system wit YP/OE Jun 27 12:59:21 or have any advice Jun 27 13:01:14 in the generated .cpio.gz I see an init.d/99-finish Jun 27 13:01:31 which is expected to run exec switch_root -c /dev/console $ROOTFS_DIR ${bootparam_init:-/sbin/init} Jun 27 13:01:57 but looks like is not called Jun 27 13:39:01 hmm in which recipe is the anytun tunnel daemon ? i could not find it Jun 27 13:39:22 or is it kernel side? Jun 27 13:57:21 what does this message mean? "No IMAGE_CMD defined for IMAGE_FSTYPES entry 'ext4.gz.u-boot' - possibly invalid type name or missing support class" Jun 27 14:00:00 i think its because it doesnt known your fstype ext4.gz.u-boot Jun 27 14:00:01 yates: No command has been defined to build that image type. You probably need to add the class that provides that command to IMAGE_CLASSES Jun 27 14:01:25 yates: or inherit it directly.... I was never clear on when you do one or the other Jun 27 14:02:33 whats thats means on compiling for qemux86 Jun 27 14:02:35 EBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i586-linux', 'common'] Jun 27 14:02:41 Is www.yoctoproject.org down for anyone else? Jun 27 14:02:42 ERROR: Function failed: do_compile (log file is located at Jun 27 14:02:48 on libdrm Jun 27 14:06:07 JPEW: up here Jun 27 14:08:49 chronos: Don't think there is a recipe for anytun yet, you may have to write one. Jun 27 14:10:24 ok :) Jun 27 14:18:57 JPEW: thanks, let me track that down. Jun 27 15:06:05 is the Overview Manual relatively new? Jun 27 15:06:11 https://www.yoctoproject.org/docs/2.5/overview-manual/overview-manual.html Jun 27 15:42:40 * yates sighs Jun 27 15:54:21 JPEW: what is an IMAGE_CMD? i cannot find it discussed in the overview manual Jun 27 15:57:40 IMAGE_CMD is an implementation detail of how images are constructed, i doubt overview goes into that much detail of how image types are defined and selected Jun 27 15:57:56 u-boot image types are defined in different places depending on the version you're using Jun 27 15:58:08 older releases might need image_types_uboot added to IMAGE_CLASSES Jun 27 15:59:29 kergoth: ok, thanks. Jun 27 16:01:08 for example, "IMAGE_CMD_ext4" in image_types.bbclass, this is encoding an image (or more generally, a file or files) into an ext4 file system within the output file itself? Jun 27 16:03:13 it creates an ext4 image file from a directory, if that's what you mean Jun 27 16:05:48 what would the string "u-boot" mean as part of an IMAGE_FSTYPES spec, e.g., "ext4.gz.u-boot"? is it simply a helpful label for what the file is? Jun 27 16:06:03 no, it's another image type Jun 27 16:06:26 aka a compression/conversion type, much as .gz alters .ext4 to compress it Jun 27 16:06:49 as i said, the uboot image types are defined in different classes depending on the version you're using Jun 27 16:07:11 so ext4.gz.u-boot would impy ext4 encoding, followed by gz compression, followed by u-boot encoding? Jun 27 16:07:15 imply Jun 27 16:07:23 basically, yes Jun 27 16:07:37 3 steps with different image commands for each Jun 27 16:08:07 each step is delimited by a "."? Jun 27 16:08:42 yep Jun 27 16:12:48 does bitbake expect there to be a single, composite IMAGE_CMD_ext4.gz.u-boot defined, or does it parse the "." delimiters and invoke each of IMAGE_CMD_ext4, IMAGE_CMD_gz, and IMAGE_CMD_u-boot? Jun 27 16:13:47 yates: latter Jun 27 16:13:54 right, thank you. Jun 27 16:14:04 combinational explosion otherwise! Jun 27 16:14:10 boom! Jun 27 16:14:38 was the u-boot type defined in morty? Jun 27 16:14:40 also lets you chain in fun ways like a gpg signature of a lz compressed ext4 Jun 27 16:15:01 or after morty? Jun 27 16:15:11 i can't find it in any layer Jun 27 16:15:21 find . -name "*" -type f -exec grep -Hn IMAGE_CMD_u-boot {} \; Jun 27 16:15:36 yields nada Jun 27 16:16:01 i already told you this Jun 27 16:16:11 in older releases, it's defined in image_types_uboot, which you'd add to IMAGE_CLASSES Jun 27 16:16:13 http://layers.openembedded.org/layerindex/branch/morty/classes/?q=uboot&search=1 Jun 27 16:16:20 first class in that list at that link Jun 27 16:19:41 it's CONVERSION_CMD not IMAGE_CMD for conversion/compression commands in most recent releases. really old releases used COMPRESSION_CMD, and older ones that that didn't have the multi-level image construction at all Jun 27 16:19:54 s/that that/than that/ Jun 27 16:20:02 kergoth: yes, i see that now. an hour or two ago i was still too ignorant to even understsand what you were saying. Jun 27 16:20:16 fair enough, there's definitely a learning curve :) Jun 27 16:20:24 yah. Jun 27 16:24:38 should the IMAGE_CLASSES extension be added to build/conf/local.conf? Jun 27 16:25:13 generally the addition to IMAGE_CLASSES would be done near where ext4.gz.uboot was added to IMAGE_TYPES in the first place, i.e. the MACHINE .conf Jun 27 16:25:21 but local.conf works for a temporary fix, yes Jun 27 16:26:05 ok Jun 27 16:34:30 zeddii_home: I just tested the tiny-arm kernel and it seems that it wont boot, Im getting lots of bad register offset errors Jun 27 16:36:15 should i use "+="? IMAGE_CLASSES += "image_types_uboot" Jun 27 16:36:45 where are all those operators defined? i saw it in the docs somewhere sometime in a universe far, far away... Jun 27 16:36:51 ?=, ??=, etc Jun 27 16:38:43 anyway, i added IMAGE_CLASSES += "image_types_uboot" in my build/conf/local.conf; now i'm getting this: https://paste.fedoraproject.org/paste/541hthJByOlRe-CH-Hn--w Jun 27 16:38:48 best to use _append Jun 27 16:39:20 that's a lazy/postponed operation, to make sure it's added at the end, to avoid clobbering any existing value if a recipe or class uses ?= to set the default value (set only if not already set) Jun 27 16:39:30 IMAGE_CLASSES_append = " image_types_uboot" Jun 27 16:39:42 best reference is probably the bitbake user manual, iirc that's on yoctoproject.org too Jun 27 16:39:44 oh Jun 27 16:39:46 yates: you can look at the bitbake manual Jun 27 16:39:49 that covers the full file format Jun 27 16:40:22 right. Jun 27 16:46:00 i'm still getting this error: https://paste.fedoraproject.org/paste/541hthJByOlRe-CH-Hn--w Jun 27 16:53:12 if you look at stefano babic's response here, he is saying (i think) this is due to a problem building libubootenv.a: https://groups.google.com/forum/#!topic/swupdate/6OClitnoLdc Jun 27 16:53:33 how you get from this error to that cause is a complete, utter mystery to me. Jun 27 17:25:51 kergoth, rburton: any thoughts? Jun 27 17:59:50 there is a SRCREV in sources/meta-swupdate/recipes-support/swupdate/swupdate_git.bb. what git repo is it SRCREVing?!? Jun 27 18:00:47 i nix'ed the version_git(d) function there and instaed just harded SRCREV to the git hash and it's working now: https://paste.fedoraproject.org/paste/WEp85yC-6zzfw0dZPsBATQ Jun 27 18:00:57 SRCREV applies to the git:// uri in SRC_URI Jun 27 18:00:57 s/harded/hardcoded/ Jun 27 18:01:26 if therea re multiple, then each url gets ;name=somename and you define SRCREV_somename, and also probably want SRCREV_FORMAT to ensure SRCPV / PV still makes sense Jun 27 18:01:42 ah, i hate it when recipes do their own version hacking Jun 27 18:03:45 kergoth: i see that there is a SRC_URI in the swupdate.inc file, so this SRCREV is for the git repo in that SRC_URI? Jun 27 18:11:21 is there one place somewhere in the docs that all these environment variables are defined (e.g., SRCPV, SRC_URI, etc.)? Jun 27 18:12:36 it's not in the bitbake manual Jun 27 18:13:01 the yocto reference has a variable index Jun 27 18:17:40 i see nothing here about a SRCREV_FORMAT variable: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html Jun 27 18:17:49 s/see/can find/ Jun 27 18:22:13 kergoth: what are you saying about the SRCREV_FORMAT variable? i didn't understand. Jun 27 18:22:41 yates: https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#var-SRCREV_FORMAT Jun 27 18:22:43 it only applies when there are multiple git urls in SRC_URI, i only mentioned it since you were asking how SRCREV applies to the git repositories being fetched Jun 27 18:24:05 ah. there aren't so i'll drop it. Jun 27 18:24:07 thanks RP Jun 27 18:47:29 Is everything run in tasks in rocko run in jails? I'm having problems calling hg commands. It complains about the keyring needing http authorization, but used in non-interactive mode. This usually indicates that hg is unable to use the users normal keyring. Jun 27 18:48:30 not a jail, no, but the envoronment is filtered/sanitized to prevent host contamination of the build env and avoid problems with reprpducibility Jun 27 18:49:40 I wonder then how I can debug what it might be filtering that keyring needs. I assume HOME and some unix sockets are in play Jun 27 18:50:46 id start by dropping into devshell and try using the commandline keyriing tool Jun 27 18:50:51 * kergoth shrugs Jun 27 18:52:58 Hmm, I'm not getting a devshell. The recipe failes even before that (addtask do_script_setup after do_unpack before do_patch) Jun 27 18:57:34 It is ssh from git that stops it. It doesn't recognize the server host ID, so it wants to ask for permission. Ergo, ~/.ssh/ doesn't seem to be available from the devshell Jun 27 18:59:09 Ah, because ssh from devshell tries to access incorrectly /home/root/.ssh Jun 27 19:00:01 Yet $USER and $HOME is set correctly Jun 27 19:06:44 The devshell runs under fakeroot, so it is not representative of the environment of tasks not run as fakeroot Jun 27 20:08:53 Hi guys, I have a requirement on my project to have a simple UI w/ touch screen. I don't really need X. There is never going to be more than one app. Any suggestions for a good window toolkit? X is OK if there isn't anything else but ideally I could just use something that controls the frame buffer directly. Jun 27 20:10:22 dennism: We're using Qt for this on an embedded target Jun 27 20:10:41 I've heard QT can do it. Jun 27 20:10:42 ..but Qt isn't consideres lightweight thou. It's an entire system Jun 27 20:11:02 I found there used to be a gtk-fb project too Jun 27 20:11:09 otoh, Qt support in Yocto is decent Jun 27 20:11:11 but that looks like it died with 2.0 Jun 27 20:11:40 How is their touch/multi-touch support? Jun 27 20:13:17 dennism: It has both. I can vouch for touch, but we're not using multi-touch (yet), so I cannot say anything of how well it works Jun 27 20:15:10 been googling around to see if someone has had luck with it. Lots of "we're going to try" or "it should work" posts. Jun 27 20:34:04 rburton_: is https://autobuilder.yocto.io/builders/nightly-arm/builds/1160/steps/Building%20Toolchain%20Images/logs/stdio that mesa build race? Jun 27 20:36:45 aehs29: I noticed that arm-tiny boot issue as well. I’m checking to see if I’ve missed a patch on the branch, or something went horribly wrong in the config. the tiny-base configuration is drastically different than the standard one, so I need to compare. Jun 27 20:43:28 RP: yes, grrr Jun 27 20:43:36 RP: remind me tomorrow morning and i'll chase it again Jun 27 20:49:02 rburton_: happened on mips too :( Jun 27 20:49:16 yeah its a pain that one Jun 27 20:50:02 thats why i have an almost-working meson port of mesa Jun 27 20:51:09 rburton_: fair enough. Given the mesa issues are known next otherwise looks ok Jun 27 21:35:12 did something happen to these files: https://autobuilder.yocto.io/pub/releases/yocto-2.4.2/machines/genericx86/bzImage-genericx86.bin Jun 27 21:35:54 yocto-2.4.2 disappeared, but other ones remain Jun 27 22:17:14 zeddii_home: yeah I just did a quick check, it seems that the tiny one is getting a different ARM version on the config that might not be compatible with qemu, the merge script actually complains about it saying that its not in the final config, so its likely caused by a missing dependency that Kconf doesnt find, but I havent had time to check which dependency it is Jun 28 00:22:38 aehs29: yah. that’s how the tiny kernel works, it pretty much turns *everything* off and then it must be turned on explicitly. so if there were default/assumptions in the BSP, they’ll pop out in that build Jun 28 00:22:52 which is probably what we are seeing, and we just need to set some explicit options in the -tiny variant. **** ENDING LOGGING AT Thu Jun 28 03:00:02 2018