**** BEGIN LOGGING AT Tue Oct 30 02:59:59 2018 **** BEGIN LOGGING AT Tue Oct 30 06:24:04 2018 **** BEGIN LOGGING AT Tue Oct 30 06:51:22 2018 **** BEGIN LOGGING AT Tue Oct 30 08:35:23 2018 Oct 30 09:33:02 the manual mentions 'base-files' recipe, can't seem to find it in the source tree of sumo Oct 30 09:38:38 ok recipes-core, of course Oct 30 10:15:43 It's not quite obvious from the documentation, but does kas accept a (git) URL for its YAML file? The examples git-clone the repo containing it and then kas is run on the YAML Oct 30 10:27:44 hi Oct 30 10:28:22 angelo_ts: hey Oct 30 10:28:28 i would like to change a busybox option only for an higher layer image recipe, how should i do this ? Oct 30 10:28:56 angelo_ts: what do you mean with "higher layer image recipe"? Oct 30 10:29:56 i have a rootfs image that inherits from a more generic rootfs image recipe that i don't want to change Oct 30 10:31:43 (inheriting by a .inc) Oct 30 10:31:47 You have a layer (and add it to your bblayers), bbappend to the busybox recipe and build your image Oct 30 10:32:31 jofr: no, that will be applied to every image Oct 30 10:32:41 that's the fact Oct 30 10:33:21 angelo_ts: not sure you can do it Oct 30 10:34:04 angelo_ts: but you couls differentiate the busybox recipes, busybox_A busybox_B Oct 30 10:34:05 Ahh Oct 30 10:34:26 So you could basically write a busybox wrapper recipe. Oct 30 10:35:22 jofr: the point here is how the busybox recipe can figure out which image is being built Oct 30 10:36:58 ok thanks for the hints, will study a solution Oct 30 10:37:45 FWIW, I would write a two busybox wrappers, one does does nothing but RPROVIDES a "virtual/buxybox" and depends on the upstream busybox recipe. Another with your modifications. Then for different images, I'd set the PREFERRED_PROVIDER_virtual/busybox to the one you want. Oct 30 10:38:09 But that's sort of assuming that all the image recipes are yours.. :/ Oct 30 10:38:10 angelo_ts: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconf Oct 30 10:38:34 thx Oct 30 10:39:30 angelo_ts: IMAGE_INSTALL_append_pn-imagename-minimal = " busybox-A" Oct 30 10:40:55 mckoan, thanks Oct 30 10:41:20 angelo_ts: YW Oct 30 11:23:19 hello, after moving to Thud that uses glibc 2.28, libc has a --disable-crypt option on by default, so building some toybox tools like su, login, passwd fail because of undefined reference to `crypt' Oct 30 11:23:48 what is the most proper way to address this? Oct 30 11:24:10 rburton: time to do http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=64f529f0ff63ea258d89754f8e4c1bdba235ee2b ? Oct 30 11:24:34 rburton: not needing py2 would be nicer but... Oct 30 11:24:51 I could just remove the build flag, but as far as I understand there should be a proper replacement that provides the crypt function within Yocto Oct 30 11:25:49 eduardas_m: you can DEPENDS on libxcrypt Oct 30 11:28:06 RP: thank you, that worked Oct 30 11:37:15 RP: oh cunning Oct 30 11:37:41 put 'because arch are idiots' in the comment Oct 30 11:38:31 * Crofton puts rburton on report Oct 30 11:40:27 RP: pinged dwmw about infradead Oct 30 11:41:03 rburton: I also asked :) Oct 30 11:41:06 ha Oct 30 11:41:15 rburton: others are joining that list sadly Oct 30 11:41:24 maybe the flood of mails will encourage him to get it up Oct 30 11:41:26 oh, who? Oct 30 11:41:29 gentoo? Oct 30 11:41:35 rburton: ubuntu :( Oct 30 11:41:39 wtf Oct 30 11:41:59 rburton: and clear Oct 30 11:47:42 RP: 'that seems suboptimal. far from home right now, not sure if hpa can do anything' Oct 30 13:06:26 hm.. git.infradead.org appears to be down Oct 30 13:06:28 mtd-utils Oct 30 13:32:57 I have a problem generating rootfs after move to Thud from Sumo Oct 30 13:33:00 WARNING: parted.postinst returned 1, marking as unpacked only, configuration required on target. Oct 30 13:33:12 ERROR: Postinstall scriptlets of ['parted'] have failed. If the intention is to defer them to first boot, Oct 30 13:33:24 then please place them into pkg_postinst_ontarget_${PN} (). Oct 30 13:33:42 Not really sure what that means Oct 30 13:43:14 eduardas_m: It looks like parted is trying to run a "post install" script (e.g. a script that runs after the package is installed) and failing. Oct 30 13:43:55 It used to be that post install scripts could that couldn't run at image creation time could "defer" to the first boot by failing Oct 30 13:44:11 It looks like they possibly changed that to be explicit in thud? Oct 30 14:18:28 this is appropriate ffor a local.conf correct ?? PREFERRED_VERSION_python3-idna="2.5" Oct 30 14:18:30 this is appropriate ffor a local.conf correct ?? PREFERRED_VERSION_python3-idna="2.5" Oct 30 14:25:24 Hi, I am trying to user systemd timer feature instead of installing crontab! but can not figure it out! some thing is missing! please let me know if you have any guide for that... Oct 30 14:26:34 https://wiki.archlinux.org/index.php/Systemd/Timers https://www.freedesktop.org/software/systemd/man/systemd.timer.html Oct 30 15:37:51 Hi, while running some bash commands (with if/do while) inside do_install I get parse error, Is there a better way of doing this which I am missing ? Oct 30 15:40:19 prabhakarlad: are you sure the sh is valid? note that the parser doesn't handle $(( yet Oct 30 15:40:48 also note that you may not get those ran in bash, could be whatever sh is pointing at Oct 30 15:42:08 rburton: yes the sh is valid, command like firmware_version=($(echo $firmware_version | awk '{split($0,a,".");print a[1]; print a[2];print a[3]}')) this fails Oct 30 15:43:00 Is there a way I could avoid this ? Oct 30 15:43:53 well the outer brackets fail to do what you expect here Oct 30 15:44:47 simplify the code until you have a minimal test case then we can fix the parser Oct 30 15:46:32 rburton: sure will do. thank you :) Oct 30 15:55:14 RP: ndec: I created a simple LAVA test definition to run runtime testing (testimage) in LAVA, RP: currently is using a tarball generated by testexport but could be done with the full poky + layers in this option will require more space and logic to make a tarball, https://github.com/alimon/test-definitions/commit/4691b67daca26658b669ac0e79e4f27cbf6ed88d Oct 30 15:59:17 alimon: interesting. How would that be triggered? Oct 30 15:59:56 alimon: does that mean you had that running successfully on Linaro's board farm? Oct 30 16:01:43 RP: I run in my own LAVA instance Oct 30 16:01:47 ran* Oct 30 16:02:23 RP: I trigerred manually but the good thing is that dosen't require connections from Autobuilder to LAVA server Oct 30 16:02:48 To get the results the AB can pull using the LAVA API Oct 30 16:09:26 New news from stackoverflow: Include libraries in /deploy/rpm to the Yocto image Oct 30 16:15:44 alimon, so the AB needs a Lava tube ? Oct 30 16:17:52 RP, I notice 'bin/sh: 1: checkvnc: not found' in some of the build logs. Oct 30 16:18:04 is it a build script bug? Oct 30 16:19:47 armpit: its something we need to fix in the autobuilder Oct 30 16:20:24 k Oct 30 16:20:34 alimon: I guess what we need to figure out is the best practice for an autobuilder to do the triggering and results pulling Oct 30 16:20:45 armpit: probably should have a bug for it Oct 30 16:20:53 k Oct 30 16:23:34 rburton: got around with it by doing bash -C ${WORKDIR}/script.sh ;) Oct 30 16:28:32 RP: armpit Yes there is the current helper to generate LAVA templates but makes the assumption that the AB and LAVA server are in the same network and that you have access to the board directly from the Autobuilder Oct 30 16:30:40 alimon: right. Perhaps I should introduce you to Aaron and you could help us with review of some of the patches? Oct 30 16:31:23 alimon: https://gitlab.com/aaron.chun.yew.chan/YoctoAutobuilder2/commits/generic and https://gitlab.com/aaron.chun.yew.chan/yocto-autobuilder-helper/commits/generic Oct 30 16:32:39 RP: armpit One target is to be able to define LAVA test jobs by machine, and to publish the image and the testsuite somewhere Oct 30 16:33:43 RP: ok i will take a look to the Aaron patches Oct 30 16:46:33 denix, armpit: Is https://bugzilla.yoctoproject.org/show_bug.cgi?id=12586 still a problem? Oct 30 16:46:34 Bug 12586: normal, Medium+, 2.99, richard.purdie, NEW , yocto-check-layer fails signatures due to TUNES between ARM archs Oct 30 16:48:19 RP, k Oct 30 16:58:13 RP: I haven't tried it recently. I should probably start checking it in preparation to the release and a new round of compat checks... Oct 30 17:02:36 denix: can you remember what the command was you tried? We do run the layer check on the autobuilder which is why I'm a little puzzled Oct 30 17:05:13 RP: according to logs, it was poky with meta-yocto-bsp and the check layer was called with -m qemuarm and beaglebone-yocto at the same time Oct 30 17:20:11 * zeddii is a one bikeshed commend patch sender Oct 30 17:26:59 denix: you didn't actually put the command in there, the -m may be the difference Oct 30 17:32:28 denix: just tried and managed a trackback so filed a bug for that. Lets try again... Oct 30 17:37:35 RP: is this being looked at for the release - https://bugzilla.yoctoproject.org/show_bug.cgi?id=12963 Oct 30 17:37:36 Bug 12963: normal, Medium+, 2.6 M4, liezhi.yang, NEW , nativesdk-opkg prefixes all internal paths with $SDKPATH and won't work Oct 30 17:38:15 denix: no, 2.6rc1 was just built Oct 30 17:38:45 RP: it affects master and past few releases, including rocko. I was told morty was fine though Oct 30 17:39:12 denix: if its been around that long and people didn't notice its not really a release blocker then? Oct 30 17:39:56 RP: I might need to bisect the changes based on that time frame - maybe I can spot the issue... Oct 30 17:39:58 denix: that sigs issue is still present and worries me a lot more :/ Oct 30 17:41:04 denix: help in tracking it down and/or fixing it would be much appreciated Oct 30 18:10:59 RP: denix: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-module-addresses-dur.patch?h=yocto-4.14 this patch should be dropped from the kernel cache, it's also in the kernel tree http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v4.14/standard/base&id=b746cda333ff Oct 30 18:11:05 and it does cause collision Oct 30 20:25:39 RP: http://git.yoctoproject.org/cgit/cgit.cgi/meta-external-toolchain/commit/?h=sumo&id=6421c9456570635022e5c3fc9bb0d4b7f910ce20 interesting little bug, not yet sure why it doesn't affect bitbake builds but only devtool/bitbake-layers, and only when other layers are adding to existing namespace packages like oe. will rework the impl and submit as a fix to base.bbclass's oe_import Oct 30 20:25:45 * kergoth gets more coffee Oct 30 20:27:10 ugh, my upstream submission backlog is so behind, and haven't been able to contribute otherwise nearly as much as usual lately. need to work on that Oct 30 20:38:49 is there a way to emulate AUTOREV-ing for http based downloads? i.e. force fetching always and avoid updating SRC_URI[md5sum/sha256sum] every time the file changes? Oct 30 20:59:52 denix: short answer is no afaik Oct 30 21:00:13 rburton: thanks Oct 30 22:48:34 The yocto mega manual says that gcc's sysroot is "poisoned", for the compiler built by yocto. Does that mean that passing --sysroot on the command line has no effect? Oct 30 22:50:20 no Oct 30 22:50:35 it means it won't try and include stuff from /usr implicitly Oct 30 22:50:39 you *need* to pass --sysroot Oct 30 22:50:47 No, in fact they are the only way to get a working build from how I understand the docs Oct 30 22:51:11 That's to catch recipes that ignore the compiler flags bitbake passes Oct 30 22:51:23 the compiler is built with a default sysroot of /not/exist Oct 30 22:56:25 Ok, that's what I was hoping for. I'm working on an scons based build recipe and I'm able to verify that --sysroot is being properly passed to gcc during the build, however the build fails on a file with: #include I have verified that /usr/include/freetype2/ft2build.h does in fact exist and -I/usr/include/freetype2 is being passed a compiler argument. Any idea why this might fail? Has anyone seen anything similar? Oct 30 22:56:57 sounds like the scons file went and happily probed the host for headers, because its broken Oct 30 22:57:08 happens all the time, people assuming that /usr/include is a good place to look Oct 30 22:57:13 (they're wrong) Oct 30 22:57:25 yeah, that should be -I/usr/include/freetype2, right? Oct 30 22:57:33 yeah Oct 30 22:57:41 assuming that prefix is /usr etc etc Oct 30 22:57:46 also, when you say sysroot, that's the recipe-specific one I assume? Otherwise you may just need a DEPENDS on freetype Oct 30 22:58:53 Yep, the recipe specific one. Oct 30 23:02:13 The command that is failing is: x86_64-poky-linux-g++ ... --sysroot=/workdir/build/tmp/work/corei7-64-poky-linux/sockeye-godot/1.0-r0/recipe-sysroot ... -I/usr/include/freetype2 ... Oct 30 23:02:15 Should the compiler not resolve /workdir/build/tmp/work/corei7-64-poky-linux/sockeye-godot/1.0-r0/recipe-sysroot//usr/include/freetype2/ft2build.h when it sees #include ? Oct 30 23:02:37 yes, but you've got -I/usr/include in there Oct 30 23:02:39 which is wrong Oct 30 23:02:42 No, because you (or rather, scons) gave it -I/usr/include/freetype2, which is wrong, it shouldn't look there Oct 30 23:02:50 ^5 Oct 30 23:02:51 You need to figure out why scons adds -I/usr/include/freetype2 Oct 30 23:02:59 ^5 Oct 30 23:03:29 OH! Ok. I thought the compiler would search all paths that start with the sysroot and end with -I. Oct 30 23:04:01 No, in fact it's the other way round. --sysroot affects the default include paths, but those get searched last. Oct 30 23:04:35 and everything you pass with -I is taken verbatim - it must be, otherwise you could never add -I../include and have it resolve to your source directory Oct 30 23:04:52 we can check for autoconf scripts that end up finding files on the host in /usr/include, but the sanity check doesn't exist for scons Oct 30 23:04:56 so patches welcome there too Oct 30 23:05:03 Ah. So the sysroot only affects the _default_ search paths. So, in -I must always be absolute in yocto? Oct 30 23:05:42 yes Oct 30 23:05:46 There's no Yocto specific thing there, it's just standard GCC behavior (and clang is the same). -I will always take unmodified, whether that's relative or absolute. Oct 30 23:05:47 not yocto, gcc Oct 30 23:05:58 * rburton stops joining in and lets neverpanic handle this Oct 30 23:06:00 bedtime! :) Oct 30 23:06:08 rburton: I was about the say the same ;-) Oct 30 23:06:13 Good to know. I'll submit patches if I can come up with a general solution for scons. Oct 30 23:42:32 hi #yocto, what is the general way to build an image for a NOR device with UBIFS? I want several partitions in one output file. I know I could do it via multiubi, but I don't find a example or something like that... Maybe someone has an example for me? **** ENDING LOGGING AT Wed Oct 31 02:59:58 2018