**** BEGIN LOGGING AT Thu Jan 17 02:59:57 2019 Jan 17 08:46:28 New news from stackoverflow: Yocto Source Location to be customized? Jan 17 09:05:59 Hi Jan 17 09:06:40 I would like to change (with a recipe or bbappend from my layer) the SRC_URI of a linux recipe located in another layer. What the right way to do it? Jan 17 09:08:01 Using bbappend seems to be error prone, because it will overwrite other bbappend modifications, so I duplicate the recipe in my own layer, but it seems also bad because the bbappend will be applied on the original and duplicated recipe Jan 17 09:19:22 use bbappend and check with bitbake -e that it does what you wanted it to do Jan 17 09:20:04 ykrons: SRC_URI_append in a bbappend will apply on top of anything other bbappends do to SRC_URI Jan 17 09:40:13 should I wipe sstate cache when switching from sumo to thud? seeing lots of weird compile errors when trying the gcc 7.4 update patch on thud. Jan 17 09:40:24 mcfrisk: no Jan 17 09:41:01 then it's something else: Exception: FileExistsError: [Errno 17] File exists: '/home/mcfrisk/src/yocto/poky/build/tmp/sysroots-components/i586/xorgproto/usr/include/X11/Xosdefs.h' -> '/home/mcfrisk/src/yocto/poky/build/tmp/work/i586-poky-linux/libxau/1_1.0.8-r0/recipe-sysroot/usr/include/X11/Xosdefs.h' Jan 17 09:42:51 oh, maybe I failed to wipe tmp before building Jan 17 09:43:36 was not in build directory when calling "rm -rf tmp" Jan 17 10:07:52 is there a initramfs setup that continues to mount a real rootfs from disk and continues to boot from that? Jan 17 10:08:50 there's "live" which seems to boot into the ramdisk and then stop... Jan 17 10:09:18 live should boot the full image Jan 17 10:09:23 if it doesn't you've got a bug Jan 17 10:20:19 I'm just reading through them Jan 17 10:21:20 that would be the ROOT_DISK... Jan 17 10:21:45 but how do I set which disk to use? Jan 17 10:27:57 there's a variable called ROOT_DEVICE that's never used... Jan 17 10:29:15 Hi, my new layer ./mybsp/sources/meta-t800 is in a parallel dir to ./mybsp/sources/poky. I'm in ./mybsp and call "yocto-check-layer sources/meta-t800" but it hangs for a while and then prints out error msg "... RuntimeError: Generating signatures failed...". Any idea? Jan 17 10:30:10 bluelightning, I would like to change the repository URL in SRC_URI. Will the first or the latest URL be used by the fetch mechanism? Jan 17 10:31:12 Do I call the script in the wrong way? Jan 17 10:31:58 JaMa, using bbappend with bitbake -e means I will have to compare with and without the bbappend until I get the same settings. It seems to be hard to maintain Jan 17 10:32:37 https://www.yoctoproject.org/docs/2.4.4/dev-manual/dev-manual.html#yocto-check-layer-script does not mention such error can happen. Jan 17 10:53:49 Here's how yocto-check-layer fails: https://pasteboard.co/HWQPnXo.png Jan 17 10:54:01 It looks very cryptic Jan 17 10:55:07 hello, I have created a personnal image type but adding IMAGE_CLASSES += "myimgtype" and/or IMAGE_FSTYPES += "myimgtype" doesn't call the IMAGE_CMD_myimgtype ... any hint about that ? thx. Jan 17 11:25:37 JaMa, bluelightning_, I have tried with SRC_URI_prepend to add my new git url before the one of the original recipe. My url seems to be used but I have issues because fetch also tries to fetch the original url. My goal is realy to sustitue my url to the recipe original url. Jan 17 11:27:41 ykrons, I'm late to the conversatoin, but just set SRC_URI with =? Jan 17 11:29:11 ykrons: of course it fetches both, you prepended so both URLs are listed Jan 17 11:29:29 if the SRC_URI only has the repo in then just set it with = in your append Jan 17 11:29:47 otherwise you can use _remove to get rid of the one you don't want, then _prepend to add the one you do want Jan 17 11:31:09 Crofton|work, my SRC_URI is already set by the original recipe, so I think ?= will never be applied Jan 17 11:31:35 rburton, I don't know _remove, seem to be what I need. I will have a look Jan 17 11:31:57 assuming that the url has a load of patches you want to apply still Jan 17 11:32:03 if it doesn't just SRC_URI= Jan 17 11:34:13 yes, that is some patches. Seem to be what I need. Thanks Jan 17 11:53:43 RP: yay, AUH keeps crunching :) Jan 17 11:53:57 we should do something about maintainers who don't pay attention to it though Jan 17 11:53:58 Any idea why yocto-check-layer fails?: https://pasteboard.co/HWQPnXo.png Jan 17 11:55:51 rburton: I really can't see anything in init-live.sh that boots from an installed system. it either tries to boot from an installer image on disk (like cdrom), or jump into a live ramdisk Jan 17 12:05:16 Sometimes packages have their extra files (patches, config, etc.) in /files but sometimes in /. Is either one preferred (and the other being legacy that hasn't been cleaned up yet)? Jan 17 12:05:21 nobody here has an example of custom IMAGE_TYPES plz ? :D Jan 17 12:06:16 JP4u: image_types.bbclass is all custom image types Jan 17 12:08:44 I need label=boot at least... Jan 17 12:12:03 rburton: i agree but i have spend one hour on it I have always error on ' No IMAGE_CMD defined for 'custimg' " despite IMAGE_CMD () { echo "All is done!"} in custimg.bbclass inherited of image and images_types, there is a misterous solution ? Jan 17 12:12:21 I know i have probably forgotten something... Jan 17 12:14:03 JP4u: IMAGE_CMD_custimg right Jan 17 12:15:29 RP: huh, bitbake is hanging on startup today Jan 17 12:15:43 can't connect to the server Jan 17 12:16:36 hm ok a dead socket, or something Jan 17 12:16:53 rburton: There is something more to do because it's hat I have made :( Jan 17 12:17:35 pastebin, hard to debug over psychic means Jan 17 12:19:43 looks like intel-edison has an init-live.sh that actually uses ROOT_DEVICE: https://github.com/htot/meta-intel-edison/blob/pyro64-acpi/meta-intel-edison-distro/recipes-core/initrdscripts/files/init-live.sh Jan 17 12:24:36 rburton: stale process holding the lock? Jan 17 12:24:41 yeah Jan 17 12:24:54 kanavin: yes, was happy to see the emails! Jan 17 12:25:15 rburton: I hope is clear https://pastebin.com/V3PHb27t Jan 17 12:29:16 hi guys, I'm trying to work with devtool in order to generate some kernel patches easily Jan 17 12:30:05 everything is fine up to "devtool modify linux-mainline" but then once I try to build it I got some weird parsing error... Jan 17 12:32:22 see : https://pastebin.com/yjvJN8Rq Jan 17 12:33:08 I'm rebuilding the kernel now from classic yocto, then I'll redo the SDK, and once done I'll do it again, byt I'm not sure that'll do, because I already start over the SDK part... Jan 17 12:41:46 I bet there's probably something kind of stupid that I forgot... What you guys think ? Jan 17 12:42:10 Hmm, when I change SSTATE_SCAN_FILES in a recipe it doesn't seems like that causes a rebuild. So old broken version in sstate-cache is still used. Doing a cleansstate and rebuilding solves this, but I assume it should be automatic? Jan 17 12:42:46 yacar: I think you have some strange character in your kernel or dts path variable somewhere Jan 17 12:43:03 or the path to your workspace or devtool directory Jan 17 13:00:13 @ernstp, I'm looking into that but I don't think that I have anything weird about that... Jan 17 13:01:57 ShellParser._parse_shell(value=' :\n import shutil Jan 17 13:02:28 is it trying to parse python code as a shellscript? do you have some do_something_append somewhere? Jan 17 13:03:49 The only modification that I did is to add an patch that adds a dts, but I'm not even selecting the dts Jan 17 13:04:01 and the dts I've added is only a copy of another one Jan 17 13:06:27 here is the faulty package : https://pastebin.com/4VETqKk8 Jan 17 13:11:15 rburton: in image.class, image_cmd = localdata.getVar("IMAGE_CMD") return none, like the .bbclass wasn't parsed o.0 Jan 17 13:23:19 I'm gonna try without my custom patch to see if this change anything Jan 17 13:30:01 hi. since i couldn't get my head around it that quickly, maybe someone can give some hints or explain: regarding the yocto development+build+deployment process, how are the stages "image creation" a.k.a. "fiddle with yocto and compile a basic rootfs" and application development and deployment (a.k.a. "deliver the combined product, image+apps) coupled? is there a feedback mechanism of applications into stage 1 so everythin gets compiled in the same run when Jan 17 13:30:02 deployment is done? do application devs add their stuff into the image on their own? doesn't that have the risk of highly outdated linux-components or (on the other side of that aspect) overhad to developer who has to include his stuff in regularly updated images ? please enlighten me ;-) Jan 17 13:39:12 no one here can provide some hint on custom image type class ? thx xD Jan 17 13:41:21 Any idea why yocto-check-layer fails?: https://pasteboard.co/HWQPnXo.png Jan 17 13:45:02 JP4u: why is your paste private? Jan 17 13:49:07 Piraty: I don't think everything is compiled in the same run, except in the release candidate phase when you will not update anymore but just resync once and then fix the final build for everything smoothly compiles together Jan 17 13:51:24 Piraty: you just once create a toolchain for the developer where he sticks to for a longer time Jan 17 14:03:10 rburton: why not ? ^^ it's my default conf sorry, you can't access ? Jan 17 14:03:48 https://pastebin.com/n2R83QCw Jan 17 14:04:38 JP4u: presumably the integrated fit image code isn't good enough? Jan 17 14:05:00 and you inherited that class in your image? Jan 17 14:14:06 I'm running into a dnf error during the do_rootfs step of my image: No match for argument read-edid. I know I've run into this before, but don't recall how I fixed it. I did a clean on my image recipe, but that didn't fix it. Jan 17 14:14:23 rburton: you're right, the integrated fit image is not fully what i need so i have made a bbclass do exactly what i need Jan 17 14:14:31 T-800: thanks so far. so the SDK consisting of image+compilers (+ libs separated?) are handed to devs, and when applications are frozen, they get their own recipe and compiling can happen alltogether, that's how you mean? Jan 17 14:14:46 rburton: and you inherited that class in your image? -> yes Jan 17 14:16:21 Piraty: yes, sounds reasonable to me Jan 17 14:16:36 and to be honest i have take sdcard_image-rpi.bbclas as example Jan 17 14:18:20 I also tried doing a cleanall on the read-edid package, but that also didn't fix it. Jan 17 14:19:41 T-800: ah so that way image creators can check if stuff still works when they update core components Jan 17 14:23:46 Does openjdk-7's build fail in Yocto Thud? Jan 17 15:49:40 rburton: he he more info, if we add IMAGE_CMD_xxx directly inside image_types.bbclass no trouble and everything works, maybe an include issue on my side Jan 17 16:27:27 is oe-lite a fork of bitbake/OE core? https://gitlab.com/oe-lite Jan 17 16:31:05 armpit: originally yes, it still has some bitbake code, though it replaced other parts of it Jan 17 16:31:33 it uses a database for its metadata, not DataSmart, has a slightly different file format, and uses an 'oe' tool with multi-repo management as well as build commands Jan 17 16:31:52 some parts are quite interesting and worth potentially adopting on our end, i.e. dependencies to specify event handler execution order Jan 17 16:32:16 they use a PLY-based parser rather than regex, which is nice Jan 17 16:33:36 it's rather more opinionated than the way we tend to do things, sacrificing a bit of flexibility to impose conventions Jan 17 16:34:06 i reviewed most of its code at one point, and had a number of discussions with esben about it Jan 17 16:34:20 (i think that was his name, anyway) Jan 17 16:34:29 * kergoth pokes at his memory Jan 17 16:38:43 kergoth: sounds right Jan 17 16:39:19 armpit: did my reply about the manual tests make sense? Jan 17 16:46:04 RP, yes Jan 17 17:14:19 I'm having an issue getting my xorg.conf into my rootfs. I've appended xserver-xf86-config in my layer, and put my custom xorg.conf into my files directory. I can see from bitbake -e that FILESPATH does include the directory where I put my xorg.conf, but for some reason it's not ended up in my image. Jan 17 17:16:23 Actually, it's even showing up in the xserver-xf86-config image directory. Just not ending up in my image rootfs Jan 17 19:22:38 any idea why the value of a gpio, after being exported and the direction set to output, cannot be set to "1"? it stays stubbornly at "0" Jan 17 19:23:05 (through sysfs) Jan 17 19:32:15 yates_home: not sure, what SoC are you using? Jan 17 19:32:18 native GPIO or port expander GPIO? Jan 17 20:50:41 robbawebba: fsl imx6ull on a variscite dart 6ul SoM Jan 17 20:51:26 ds2: not sure how to answer that. if you mean is it part of the SoC, yes it is Jan 17 20:53:40 this gpio used to be part of a regulator: here is the relevent dtsi snippet: i added status = "disabled"; https://paste.fedoraproject.org/paste/ORizi1FM~f-pgFKyypfnEA Jan 17 21:01:29 yates_home: I'm more familiar with x86_64 SoCs and working with a BIOS, so this is just a guess, but would the status = "disabled" attribute possibly block you from controlling the GPIO? Have you tried removing the GPIO property from the dtsi so the GPIO is no longer associated with this regulator, and can be used from sysfs? Jan 17 21:02:54 robbawebba: yates_home: This is just a guess though. I was dealing with something recently in a BIOS DSDT where a GPIO was defined exclusively as an ACPI Event Interrupt, but I wanted it to generate an interrupt to the kernel as well. Jan 17 21:06:24 robbawebba: i did try removing the gpio property, but that won't compile Jan 17 21:07:38 the funny thing is, when it's disabled it IS available for sysfs. when i export it, then "cat /sys/kernel/debug/gpio" i see it belongs to sysfs. i just can't set the value to 1 Jan 17 21:08:15 Hi, is there an equivalent to BBMASK to hide a bbclass and an .inc file ? Jan 17 21:11:46 i think i see what's happening Jan 17 21:11:58 i'm mucking with the muxing for that gpio in uboot. Jan 17 21:12:00 doh! Jan 17 21:26:15 yates_home: ahhh interesting! I'm glad you solved it! **** ENDING LOGGING AT Fri Jan 18 02:59:57 2019