**** BEGIN LOGGING AT Fri Mar 01 02:59:57 2019 Mar 01 04:05:34 RP: I was able to get it working. "core-image-sato - OK - All required tests passed (successes=34, skipped=25, failures=0, errors=0)" Mar 01 04:05:34 You were right, it was the serial conf I changed which broke it. Looks to specifically be the hvc0 part, which I removed for spewing errors. Anyway, I'll change that part back and push it as a proper patch tomorrow. Mar 01 06:58:16 Hi! I'm trying to setup a CI environment for Yocto and it looks like the way to go is a 2-staged process. 1st stage is building only a recipe/layer and 2nd stage is building the whole image. I guess because of fastr build times and real integrations tests. But I'm struggling to just build a layer/recipe. Is there a simple way that I'm missing? Mar 01 07:27:57 daniel-k: actually its usually more like stage 1: setup the build including its configs 2: actually run the build Mar 01 07:40:07 LetoThe2nd, Are you talking about the release repository? I'm referring to the split application developer/system integrator. So app dev creates a new recipe that shall be CI built and tested. Mar 01 07:40:40 LetoThe2nd, at least that's what I understand from various resources such as presentations and talks referenced from the Yocto wiki Mar 01 07:48:23 daniel-k: well you can't build the recipe without all of the infrastructure. Mar 01 07:49:08 daniel-k: of course you can build the app recipe as a "simpler" test and the image as an "extended" test for buld time reasons Mar 01 07:49:54 but the real know-how in CI is not "which thing to bitbake", but "how to automate the build setup correctly" Mar 01 07:50:39 LetoThe2nd, that's what I thought would be the idea. I also have an eSDK so the required infrastructure would be there Mar 01 07:51:33 LetoThe2nd, But is there a way to build a recipe/layer in isolation? (I think you cannot bitbake a whole layer, right? Just recipes) Mar 01 07:52:52 With the eSDK, all image layers are already integrated and the only possibility I'm seeing so far is exchanging the "shipped" layer in the eSDK for the new revision that I want to CI build Mar 01 07:54:22 daniel-k: you cannot bitbake a layer at all Mar 01 07:54:34 daniel-k: you can bitbake recipes, which includes images Mar 01 07:55:29 and while you can technically use the esdk with its modify mechanism to add a recipe into it, this sounds really strange for CI Mar 01 07:55:53 i mean, it just adds another stage right upfront. where does the esdk come from? Mar 01 07:57:18 so the usual technique is to have a mechanism that sets up the layer stack and builds all-through Mar 01 07:57:51 LetoThe2nd, I build the eSDK myself: `bitbake core-image-base -c populate_sdk_ext` Mar 01 07:58:31 jonmason: great! Mar 01 07:59:02 LetoThe2nd, alright. I'm currently setting up the build for the release repo. From there it should not be that far to do the layer setup with a new PR and build that too Mar 01 08:00:00 daniel-k: "i'm building myself" is a sharp contrast to CI Mar 01 08:01:24 LetoThe2nd, so I will be building the eSDK as part of the CI too. Just right now I'm doing this manually. But once the image build CI is setup, it will also emit the eSDK. Or am I missing something? Mar 01 08:02:02 daniel-k: why even the esdk Mar 01 08:04:19 LetoThe2nd, good point. For CI, I don't need it. I somehow thought for "just building the layer" I would need the eSDK. But yeah, I should just build the whole image with the new changes. Mar 01 08:04:32 daniel-k: eeeexactly! Mar 01 08:04:35 RP: Hi, your solution solved the previous error but I got this new one while compiling glibc Mar 01 08:04:39 https://pastebin.com/1X7x56NT Mar 01 08:05:24 SimoneNascivera: There is something very wrong in that build :( Mar 01 08:05:33 LetoThe2nd, but it's quite convenient for developing recipes on my laptop. So I will still build as a CI artifact I think Mar 01 08:05:40 SimoneNascivera: what, I don't know :( Mar 01 08:05:46 RP: I kow :( Mar 01 08:05:57 SimoneNascivera: its for qemux86 right? Mar 01 08:06:05 daniel-k: as a secondary CI artifact, thats all fine. but the esdk should come from the CI, and not be used to feed it. Mar 01 08:06:26 LetoThe2nd, is there any resouce/open source project that has an example of layer setup for CI? I mean it shouldn't be that difficult, but why reinventing the wheel? :) Mar 01 08:06:46 RP: I think I'll try a fresh install of ubuntu at this point Mar 01 08:06:47 daniel-k: its difficult and everybody reinvents the wheel Mar 01 08:07:04 RP: yes it is Mar 01 08:07:11 daniel-k: you can look at 1) what the yocto qutobuilder does 2) look at kas 3) look at repo Mar 01 08:07:21 SimoneNascivera: I would love to know whether that fixed it... Mar 01 08:07:35 daniel-k: until now, there is no best practise and one-size-fits-all solution Mar 01 08:07:46 daniel-k: thats why i said, this is where the real know-how lies Mar 01 08:07:58 SimoneNascivera: As I said yesterday, we have 1604 used elsewhere including our autobuilder so we know this does work... Mar 01 08:08:30 * RP -> afk for a bit Mar 01 08:09:36 LetoThe2nd, thanks! what exactly is 3) repo? Repotool? The Yocto repo? Mar 01 08:09:53 daniel-k: repo. the tool google uses to manage android builds Mar 01 08:10:21 LetoThe2nd, I see Mar 01 08:10:23 thx Mar 01 08:40:59 Is it ok to use an SSTATE for builds with different target architectures? Mar 01 08:41:26 Like if I'm building the same image for both ARM and x86? Mar 01 08:41:58 I should rephrase my question. Is it ok to use *the same* SSTATE for those builds? Mar 01 08:43:21 Seems so. It's using the arch in the filenames Mar 01 09:02:15 I'm hitting this 'The postinstall intercept hook 'update_pixbuf_cache' failed"' error when building my rootfs, and it is related to not be able to find a loader.cache. Anyone experienced something similar and can point me in a direction? Mar 01 09:03:18 trying to understand unparsed line: 'IMAGE_INSTALL_append = " helloworld helloworld-dev' Mar 01 09:04:03 black_13: look close, and find that you use " in the beginning and ' in the end Mar 01 09:10:13 ah Mar 01 09:10:34 this is what i get for doing stuff at this hour Mar 01 09:18:31 trying to undestand what this says or where to start http://codepad.org/xpj6OmgR Mar 01 09:21:03 black_13: install: cannot stat '/home/jjosburn/Documents/programming/poky_qemu_arm/build/tmp/work/i586-poky-linux/helloworld/1.0-r0/hello': No such file or directory Mar 01 09:21:18 your do_install command is broken Mar 01 09:22:07 is that the file was never built Mar 01 09:22:16 because Mar 01 09:22:35 this is an arm build but it trying to build for x86 Mar 01 09:23:17 then not only this in your recipe is broken Mar 01 09:24:22 i think i figure it out Mar 01 09:26:44 the guy wrote this example up left things out Mar 01 09:30:35 i built but not opkg Mar 01 09:30:46 we are moving in the right direction though Mar 01 10:31:03 Anyone has any experience with adding ACLs in IMAGE_POSTPROCESS_COMMAND? Mar 01 10:31:47 It looks fine if you do setfacl and getfacl afterwards. And you can see the "+" at the end of the permissions if you do "ls -la" Mar 01 10:32:09 but if I do a setfacl -m g:GROUP:rx FILE Mar 01 10:32:29 the group permission in the "ls -la" is not changed in the pseudo environment Mar 01 10:32:52 and when I deploy it on the target the group I added to have access can not execute the file Mar 01 10:33:11 when I do the setfacl on the target the group permission is changed Mar 01 10:33:18 and it works as expected Mar 01 10:35:53 so something like this Mar 01 10:36:04 ls -la Mar 01 10:36:08 -r-x------ 1 root root 6672 Feb 28 11:11 FILE Mar 01 10:36:12 setfacl -m g:GROUP:rx FILE Mar 01 10:36:17 getfacl FILE Mar 01 10:36:21 # file: FILE Mar 01 10:36:25 # owner: root Mar 01 10:36:28 # group: root Mar 01 10:36:32 user::r-x Mar 01 10:36:36 group::--- Mar 01 10:36:39 group:GROUP:r-x Mar 01 10:36:43 mask::r-x Mar 01 10:36:47 other::--- Mar 01 10:36:50 ls -la Mar 01 10:36:53 -r-x------+ 1 root root 6672 Feb 28 11:11 FILE Mar 01 10:37:52 If I run this in my "normal" linux I get Mar 01 10:37:53 -r-xr-x---+ 1 root root 6672 Mar 1 11:37 FILE Mar 01 10:38:53 pseudo version is 1.7.4 Mar 01 10:43:01 Guest98965: firstly, please use pastebin Mar 01 10:43:52 sorry...will do next time Mar 01 10:45:22 Guest98965: what mckoan said Mar 01 10:46:29 how do you rebuild a recipe Mar 01 10:47:01 I build the image and as part of the IMAGE_POSTPROCESS command we have some setfacl calls Mar 01 10:47:16 so it is not part of a specific recipe Mar 01 10:50:12 brb Mar 01 10:50:48 black_13: run bitbake recipename, if it has changed then bitbake will rebuild it Mar 01 10:51:25 what happens if i delete tmp and rerun bitback Mar 01 10:51:29 sorry bitbake Mar 01 10:51:31 Guest98965: probably a bug in pseudo. xattrs *should* be preserved Mar 01 10:51:49 black_13: it generally just pulls all the packages from the sstate-cache Mar 01 10:52:31 how do you start fresh but but use the cache sources Mar 01 10:52:37 cached Mar 01 10:55:53 delete tmp Mar 01 10:56:30 it will just pull what i can from sstate-cache, building what it can't Mar 01 11:06:15 otavio, not at the moment, as then it would no longer run when virgl is not in use (which would be still the default for runqemu). It doesn't seem to be able to auto-detect those things, or try one then another etc. Mar 01 11:27:59 rburton: xattrs are preserved. I can see them when I do getfacl on the target. The difference is that the group permissions you can see in "ls -la" won't change when we do it in the build. They seem to be only affected when I do it on the target Mar 01 11:31:16 possibly a bug in pseudo Mar 01 11:46:38 hmpf :) Mar 01 11:48:33 kanavin: I see. Mar 01 12:07:36 khem: gcc 8.3 upgrade also breaks qtscript, there is fix in upstream, I'll add it soon Mar 01 12:48:34 Gtk-Message: 21:20:16.707: Failed to load module "pk-gtk-module" Mar 01 12:48:34 Gtk-Message: 21:20:16.708: Failed to load module "canberra-gtk-module" Mar 01 12:48:44 anyone know how to fis such messages? Mar 01 12:52:49 stop trying to load them Mar 01 12:53:05 canberra is from libcanberra Mar 01 12:53:41 not sure what would be telling gtk to load those Mar 01 12:54:16 hm i wonder if its the new setting data Mar 01 12:57:05 hm, nope Mar 01 12:57:51 my applications doesn't display the icons for buttons Mar 01 12:57:59 I am a complete idiot at guis Mar 01 12:59:30 Crofton: just like the rest of all proper engineers. Mar 01 13:04:20 LetoThe2nd, thanks! Mar 01 13:06:20 :) Mar 01 13:18:27 anyone has used "ssh" protocol for SSTATE_MIRROR ? Mar 01 13:19:26 while i am trying, bitbake is not giving any error but not considering cache available at the respective path Mar 01 13:53:24 Hello, What is best practice for an init script for an qt application: Do make it in the application recipe, or create a seperate recipe ? Mar 01 13:53:59 I did try to put it in the qt recipe but since i have "inhert qmake5" it does get included in rootfs. Mar 01 13:55:15 the inherit is nothing to do with t Mar 01 13:55:32 install the init script in the same recipe as your application Mar 01 13:55:55 well, both ways work, but if its in the recipe then you can't not have one without the other Mar 01 13:56:10 just install the file manually, and use the update-rcd class to set it up Mar 01 13:58:59 By installing manually, you mean a function in the .bb file? Mar 01 13:59:47 Thats what I ment with inherit, I dont have any functions becouse of it and i guess qmake5 does not know what to do with an init script Mar 01 14:03:27 Okay I found the class http://www.embeddedlinux.org.cn/OEManual/update-rc-d_class.html. Looks really nice thank you! Mar 01 14:06:03 kergoth: damn I found a configure thats still checking for arm-poky-linux-gnueabi-gcc Mar 01 14:06:11 could it be due to the machine config? Mar 01 14:21:05 its doing that on libtool-cross, so I should probably avoid this package Mar 01 14:33:10 So apperently i did not understand licencing the last time i did it.. How i assumed it works is: If i want to use update-rc.d i look where update-rc.d is located (In poky) then i copy the COPYING.MIT to my recipe and use the checksum Mar 01 14:33:13 Is this wrong? Mar 01 14:37:09 define “use”. meaning you have an rcX script in your recipe ? or something else ? Mar 01 14:40:02 I just put the checksum in LIC_FILES_CHKSUM= "file://COPYING;md5=mychecksum232322323" Mar 01 14:43:28 what I mean is. unless your recipe is extending (not just using) update rc.d, you don’t need to copy the license file. you just license what your recipe is doing. Mar 01 14:44:11 otherwise, recipes would have copies of all the license files from the source code they use. Mar 01 14:44:52 thats what i have been doing :p and it sucks Mar 01 14:45:15 So all i really need to do is use the checksum in poky in my recipe Mar 01 14:46:13 kergoth: found it, it was due to a glibc-external QA issue (shipped vs installed) Mar 01 14:46:31 kergoth: damn spoke too soon Mar 01 14:46:34 still have it XD Mar 01 14:50:08 willie: from whatI understand of your description .. yes. You are licensing what your recipe does, you can either use a license file from its source code, or reference / checksum one of the common ones. Mar 01 14:55:40 zeddii: Sorry if I'm explaining poorly. I just want to use update-rc.d in my custom-recipe :) Mar 01 14:56:36 then you shouldn’t need to reference update-rc.d’s license at all. it’s a separate package/recipe/class and it’ll do that itself. Mar 01 14:57:20 Hi guys, Quick question: Do you have a bug tracking system for bitbake? I think I have seen it before but can't find it Mar 01 14:58:20 Also, how do you do a search in the mailing lists? Mar 01 14:58:43 zeddii: I dont think so, I'm getting "Recipe file does not have license file information (LIC_FILES_CHKSUM)" if I dont include it Mar 01 15:00:08 you need to license your own recipe. I’m just saying that you don’t need to follow/copy the one from update-rc.d Mar 01 15:00:33 there are common/global license files you can reference, you don’t need your own copy if your source code doesn’t have one (i.e. your initscript) Mar 01 15:02:05 I think i need to re-read the project manual :) Mar 01 15:02:19 Thanks alot for your help zeddii! Mar 01 15:03:38 willie: peek at something like recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bb in oe-core, you’ll see that it just references something like I’m talking about Mar 01 15:07:59 fenrig: you can't avoid libtool-cross, 80% of the build depends on it. it just happens to be the first recipe to build that actually uses the external toolchain. if it fails, then the toolchain isn't working from its perspective. the prefix isn't an issue, as wrapper scripts are generated to deal with the differing prefixes. check config.log in the libtool-cross build directory Mar 01 15:08:22 fenrig: what are the unshipped files? Mar 01 15:16:16 fenrig: note that meta-external-toolchain is glibc-only at this time, i haven't finished musl-external yet Mar 01 15:16:24 shouldn't be too hard to do though Mar 01 15:18:25 hello everyone Mar 01 15:18:35 i’ve got a small and hope quick question Mar 01 15:18:59 is it possible to override SRCREV using environments variables? Mar 01 15:20:33 what i want is to lock software versions by commits using SRCREV, but i want to use one file to lock all versions, same way like Gemfile, package.json Mar 01 15:21:54 you can set anything with an environment variable, but the metadata always overrides it. so the recipe would have to use ?=. and you setting the value would affect all recipes, not just one, unless you set the vars with the _pn- override, in which case you'll have to add *all* of those to BB_ENV_WHITELIST/BB_ENV_EXTRAWHITE Mar 01 15:22:07 (we filter the environment, only vars in the whitelist are allowed to flow into the metadata) Mar 01 15:22:26 if you use the override, you woudln't need ?= unless the definitions in the metadata also use the override Mar 01 15:22:35 i already tried to use BB_ENV_WHITELIST but with no luck Mar 01 15:23:05 export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SRCREV_pn-rauc” && env 'SRCREV_pn-rauc=test’ && bitbake image Mar 01 15:23:07 like this Mar 01 15:23:23 is it correct using SRCREV_pn-rauc, where rauc is the name for the package? Mar 01 15:24:29 anyone has used "ssh" protocol for SSTATE_MIRROR Mar 01 15:24:59 liveder: uh, that wouldn't work Mar 01 15:25:12 'env' only sets the vars for the commandline it executes. it has nothing to do with your current shell Mar 01 15:25:31 env 'SRCREV_pn-rauc=test' bitbake image Mar 01 15:26:08 gaurang: doubtful, but it just uses the bitbake fetcher. if the url works in SRC_URI in a recipe it'd work in SSTATE_MIRRORS Mar 01 15:26:27 gaurang: so i'd test it that way first to make it easier to diagnose a failure. even put the full url to a specific sstate archive in SRC_URI in a recipe Mar 01 15:27:07 kergoth: i tried, bitbake is not throwing any error and not working too Mar 01 15:27:16 with the same, file:// works perfectly fine Mar 01 15:27:26 thanks! will try now Mar 01 15:27:35 you have to use a valid url that the bitbake fetcher supports. see the bitbake user manual Mar 01 15:29:18 SSTATE_MIRRORS ?= "file://.* ssh://IP/path/to/cache/PATH;downloadfilename=PATH" Mar 01 15:30:01 kergoth, works like a charm! thanks a lot Mar 01 15:30:13 i set the passphrase and login w/o credential Mar 01 15:44:24 gaurang: as i just told you, test it in SRC_URI in a recipe first. SSTATE_MIRRORS silently ignores a lot of states by design, to avoid spamming the user Mar 01 15:44:34 which makes it almost impossible to diagnose without digging into debug logs Mar 01 15:44:51 liveder: np Mar 01 15:45:45 and is there any way not to use env? :) as i want to execute prepare_env script first and only after that execute bitbake Mar 01 15:46:03 i doubt shell allows variable names with dashes in them Mar 01 15:46:09 so no, i don't think so Mar 01 15:46:27 yeah Mar 01 15:46:41 you have alternatives, though. you could source a script that puts them in thell arguments, and then you could pass that Mar 01 15:47:02 i.e. in foo.sh: set — SRCREV_pn-foo=bar; . ./foo.sh; env "$@" bitbake foo Mar 01 15:47:17 sounds good Mar 01 15:47:18 thanks! Mar 01 15:47:55 or you could source a script that defines a 'bitbake' wrapper function that runs env with the vars and bitbake under the hood, but that wouldn't separate configuration from execution Mar 01 15:48:17 so the shell arg approach is probably cleanest Mar 01 15:48:22 for some value of 'clean', anyway Mar 01 15:48:44 i'm not sure why you don't just define this in a bitbake .conf file though Mar 01 15:48:48 way cleaner than the environment Mar 01 15:49:01 echo SRCREV_pn-foo=bar >>conf/srcrevs.conf; echo 'include conf/srcrevs.conf' >>conf/local.conf Mar 01 15:49:19 * kergoth shrugs, to each his own :) Mar 01 15:50:05 :) Mar 01 15:50:17 if you're tracking branches, you could leave AUTOREV usage in the recipes and use buildhistory-collect -srcrevs to write a srcrevs.conf to lock down the autorevs at release time. p robably a different use case, though. we do that at mentor to allow autorev during development, but avoid the customer's builds contacting upstream unnecessarily Mar 01 15:50:54 i’m using gitlab-ci Mar 01 15:50:55 buildhistory-collect-srcrevs emits SRCREV_foo=bar lines for either all autorev recipes or all recipes, iirc Mar 01 15:51:01 * kergoth nods Mar 01 15:51:23 created yaml file with the following idea: Mar 01 15:51:31 poky: Mar 01 15:51:32 name: poky Mar 01 15:51:33 url: git://git.yoctoproject.org/poky.git Mar 01 15:51:35 branch: sumo Mar 01 15:51:36 commit: d3ad2438222050faf33e83598c1f6ecd25ff65b6 Mar 01 15:51:36 type: git Mar 01 15:51:47 so i want to lock git repositories as well Mar 01 15:51:58 in the same lock file i want to lock all our software we are using Mar 01 15:52:30 wrote small bash script to parse yaml file to work with git and now working on SRCREV Mar 01 15:53:09 how is this tracking done in enterprise solutions? :) Mar 01 16:13:35 kergoth, oh.. i got your idea with srcrevs.conf Mar 01 16:14:22 will use same approach but will just add it to .gitignore Mar 01 16:15:06 thanks Mar 01 16:28:20 np Mar 01 17:10:05 I'm running testimage on qemuarma15, and I'm seeing a python error Mar 01 17:10:37 ERROR: core-image-sato-1.0-r0 do_testimage: Error executing a python function in exec_python_func() autogenerated: Mar 01 17:26:23 this doesn't seem like something that is a shortcoming in the bsp recipe **** BEGIN LOGGING AT Fri Mar 01 17:26:40 2019 Mar 01 19:08:56 RP, armpit AB is ready for new work. Mar 01 19:09:20 3 workers still in process but no need to wait. Mar 01 19:39:22 what in vagrant would prevent yocto from building Mar 01 20:07:16 what is causing this http://codepad.org/CZB8pBWQ this happens when i try to run yocto in virtual box Mar 01 23:50:03 Is there a way to print the DISTRO_features et. al. with a bitbake command? Mar 01 23:50:09 I didn't see it in the docs Mar 02 00:07:12 I guess filtering -e is the way Mar 02 02:37:03 halstead, thanks.. I was off on jury duty Mar 02 02:37:20 armpit, Are you assigned to a trial? Mar 02 02:37:48 I was and it finished today **** ENDING LOGGING AT Sat Mar 02 02:59:57 2019