**** BEGIN LOGGING AT Tue Jul 03 03:00:00 2018 Jul 03 06:36:54 Does yocto itself have a license I should mention in my legal notes? Jul 03 06:49:33 Will there be a Yocto Dev Day at this years ELCE? If yes what day will it be? Jul 03 06:59:12 hello , assuming three tasks in order, if i add Jul 03 07:00:03 a task with conflicting instructions: before first, after the third, when will bitbake decide to execute the new task? Jul 03 07:22:11 cornel: it could be before or after the second task Jul 03 07:24:11 RP: so it's not even determnistic? Jul 03 07:25:56 cornel: you've specified there is no dependency so determinism isn't relevant Jul 03 07:26:15 cornel: in reality, bitbake will likely schedule one of them first and likely end up running both at the same time Jul 03 08:13:25 RP: thank you Jul 03 08:14:37 still i would have expected that if i define a task so that it builds before A and after B, bitbake will decide always in the same way Jul 03 08:15:53 now i have a more interesting issue. trying to build our image in an Ubuntu 1694 host, i get this error: do_rootfs: Could not invoke 'dnf' Jul 03 08:16:07 this is an attempt to migrate from yocto 2.0 to yocto 2.5 Jul 03 08:16:20 should iadd some feature in local.conf ? Jul 03 10:10:58 New news from stackoverflow: Yocto upgrade kernel with dnf Jul 03 10:13:45 i have an RPM that provides panme = pversion Jul 03 10:14:05 however, rootfs complains that nothing provides panme >= pversion Jul 03 10:14:11 what coud be wrong? Jul 03 10:14:28 s/rootfs/rootfs() Jul 03 10:14:50 do_rootfs() to be more precise Jul 03 11:11:08 New news from stackoverflow: Minnowboard Max Bootloader Jul 03 11:38:58 hi every one! I want to override/patch a file which is always installed by another layer. Jul 03 11:40:22 This is not in the source code which is fetched by the git and I think I can not apply a patch in my own layer Jul 03 11:42:14 Is there any way to change the file in my own layer? Jul 03 11:44:54 I have tried to append the do_install task and installing my own version of the file, with no success. do_fetch log shows that it's overwritten by the original one!! Jul 03 11:45:13 Any help is greatly appreciated. Jul 03 11:49:33 nasix: https://github.com/GENIVI/meta-ivi/blob/master/meta-ivi-test/recipes-core-ivi/vsomeip/vsomeip_%25.bbappend Jul 03 11:49:45 look at first two interesting lines Jul 03 11:58:57 just got a question from a friend: can we distribute the bitbake tasks in a computer network? Jul 03 12:00:27 you can use distcc/icecc/etc to spread the compile, but you can't share e.g. configure Jul 03 12:02:18 rburton: thank you Jul 03 12:02:32 the alternative would be a cluster, right? Jul 03 12:03:31 well it depends what you want to do. the yocto autobuilder has several machines because it does many independent builds so they can be spread. if you're compiling something huge frequently, then icecc can spread the compile over a cluster Jul 03 12:04:13 ok, thank you very much Jul 03 12:04:18 if its performance you're after, it's arguable that the better win is in assisting large projects to port away from autotools... mesa with meson builds in a fraction of the time it takes to configure with autotools Jul 03 12:07:46 is meson faster than ninja? Jul 03 12:11:20 New news from stackoverflow: dlib library with yocto Jul 03 12:12:20 cornel: meson uses ninja Jul 03 12:13:14 nobody in their right mind uses ninja directly Jul 03 12:23:00 rburton: oh, i see :) Jul 03 12:46:08 Hi, is this the right place to ask question regarding Yocto usage? Jul 03 12:46:16 sure Jul 03 12:46:56 Great, little bit understanding of YP and Bitbake on my side so far. Jul 03 12:47:21 One question regarding system lib, libc Jul 03 12:48:09 jethro 2.0.3 is in use here. It seems for that glib was the default system library Jul 03 12:48:42 However few packages are built then packed to image. Those packages are autotools-based. Jul 03 12:48:57 Generally no problem with building them, however one point is not clear. Jul 03 12:49:41 On one side YP2.0.3 uses glib as default system lib on another side recipes of those package refer to glib in explicte way Jul 03 12:50:18 glibc, i presume. glib is something else. Jul 03 12:50:43 Yes, you are right, sorry for irritation. Jul 03 12:51:37 This means following: configure script is started with --with-glib argument. This causes on configure script side calls to pkg-config to find if glibc is there Jul 03 12:52:38 If test positive LIBC and CFLAGS are set then passed to makefile. My question is if YP 2.0.3 uses glibc as default system lib why those explicite references are needed? Jul 03 12:53:01 It might well be that problem was self-made here in project. Jul 03 12:53:32 nothing will use pkgconfig to find if glibc is present Jul 03 12:53:43 because glibc doesn't ship .pc files Jul 03 12:54:28 but that is fairly common behaviour for glib, which does ship pkgconfig files Jul 03 12:55:15 Well, glib (GNOME lib ??) is out-of-scope Jul 03 12:55:53 I address the system lib with a.o. syscalls inside Jul 03 12:56:25 but glibc doesn't have a .pc file so nothing will use pkgconfig to find it Jul 03 12:56:37 so, you're mixing glibc and glib Jul 03 12:59:26 I see, I need to review my problem view. Thanks. Jul 03 13:00:08 its a very common pattern for software which uses glib to use pkg-config to find the headers and libraries Jul 03 13:00:42 sure Jul 03 13:01:18 also glibc isn't the only libc available, we used to support uclibc and now support musl and newlib alongside glibc Jul 03 13:20:47 hello does psplash should run on intel-nuc? Jul 03 13:21:20 I added it to image but no splash is displayed during boot + when run manually psplash I get: Error VT_SETMODE failed: Bad file descriptor Jul 03 14:17:06 if a LAYERDEPENDS_mylayer = "another-layer" is issued in a layer.conf, then does "another-layer" mean "sources/meta-another"? Jul 03 14:17:53 yates: it means a layer that sets BBFILE_COLLECTIONS in their layer.conf to another-layer Jul 03 14:17:58 generally, they match Jul 03 14:18:33 exceptions being 'core' (openembedded-core's meta/) and 'openembedded-layer' (meta-oe/meta-oe) Jul 03 14:20:25 ok Jul 03 14:21:05 "openembedded-layer" is the actual layer i was wondering about in my specific case. thanks for clarifying that. Jul 03 14:24:30 does the openembedded-layer specify a u-boot? Jul 03 14:24:38 i don't see it there. Jul 03 14:27:23 when building swupdate-image, i'm getting a do_compiler (actually it's linking) failure in linking u-boot, but it is not my project's u-boot. i don't understand where it is bringing in this other u-boot. Jul 03 14:28:15 does "your" u-boot provide recipes for the native tools ? Jul 03 14:28:18 here is the output: https://paste.fedoraproject.org/paste/0EqKG~uwGrGEHO1L-LGFzQ Jul 03 14:29:12 i've done a grep of every file in the project for "fw_env_flush" and the only hits are in the tmp Jul 03 14:29:30 abelloni: you mean like fw-utils (sp?)? Jul 03 14:30:07 yates: you need UBOOT_* variables to be set Jul 03 14:30:54 yates oops irrelevant Jul 03 14:31:31 lol, ok nayfe Jul 03 14:31:53 yates: yes, u-boot-fw-utils should provide libubootenv Jul 03 14:34:33 * yates is listening to Foreigner "4" while working - simply excellent! Jul 03 14:35:18 hey guys! is there any quick way to revert a "PACKAGECONFIG_remove = "timesyncd"" from a previous layer? Jul 03 14:36:07 saying PACKAGECONFIG_append = "timesyncd" does not seem to help as _remove seems to have priority :-( Jul 03 14:36:27 yates: fw_env_flush was fw_env_close before, so maybe you'r mixing u-boot versions Jul 03 14:36:59 luneff: if I remember correctly _remove is done at the end and is final Jul 03 14:37:33 :-( that's bad for me. connman's NTP doesn't work for me and timesyncd would be the best way for me :-( Jul 03 14:37:56 abelloni: i do see u-boot-fw-utils in a MACHINE_EXTRA_DEPENDS in the conf/machine/.conf Jul 03 14:38:21 luneff: no, remove happens after append. moan at the layer that turns off timesyncd using _remove? Jul 03 14:38:55 or fork it :) Jul 03 14:39:03 yes, automotive grade linux disabled it, and I want to cleanly get it back. Mans say about OVERRIDES variable... Jul 03 14:39:53 yates: what is version selected for recipes u-boot-fw-utils and u-boot? Jul 03 14:40:38 they did say in JIRA that the change was intended to overcome race conditions with connman's NTP. but I seem just to not get any time set at all :-) Jul 03 14:42:53 oh, seems as an old story: http://lists.openembedded.org/pipermail/bitbake-devel/2015-September/006416.html Jul 03 14:43:48 rburton: rebooting the f25 worker as nfs wasn't happy on it Jul 03 14:44:29 nayfe: here is the u-boot-fw-utils.bb file for my layer (a variscite vender-supplied layer): https://paste.fedoraproject.org/paste/KPl96wZDxCG8XCXL-BR-1g Jul 03 14:44:48 looking for u-boot now. Jul 03 14:46:32 yates: you can do something like bitbake -e u-boot-fw-utils | grep ^PV= Jul 03 14:48:40 PV="1.0" Jul 03 14:49:23 i have seeral u-boot recipes, not sure which is getting pulled in: https://paste.fedoraproject.org/paste/xypUQ1L3JR65qC0o1OMaFA Jul 03 14:55:42 nayfe: does this bitbake -e u-boot output give the answer: https://paste.fedoraproject.org/paste/pwImxk7FqzZ5huqvGMFbRQ Jul 03 14:56:12 no, wait Jul 03 14:59:29 Meeting? Jul 03 14:59:39 apparently so Jul 03 14:59:41 * rburton finds phone Jul 03 14:59:55 YPTM: Bridge is with Zoom at: https://zoom.us/j/990892712 Jul 03 15:00:05 YPTM: Richard joined Jul 03 15:00:09 YPTM: Has started Jul 03 15:00:15 YPTM: Stephen Joined Jul 03 15:00:30 YPTM: Nick Pongratz joined. Jul 03 15:00:45 YPTM ross joined Jul 03 15:00:46 YPTM: Bruce Ashfield joined Jul 03 15:01:21 zeddii_home: since you're here, is that devsrc recipe ready? Jul 03 15:01:25 YPTM Tom Rini joined Jul 03 15:01:43 RP: pretty much. I’m working on the 4.18 kernel today, but will include them all in my next series. Jul 03 15:01:45 YPTM: Rob Woolley joined Jul 03 15:01:52 YPTM: Joshua Watt joined Jul 03 15:01:55 zeddii_home: would be nice to get that one sorted Jul 03 15:01:58 YPTM: Scott Murray joined Jul 03 15:02:08 agreed. I need to do that mulitlib build again to be sure I squashed that one issue. Jul 03 15:02:31 zeddii_home: don't talk to me about multilib ;-) Jul 03 15:02:39 YPTM: Jan-Simon Möller joined Jul 03 15:02:46 YPTM: Denys joined Jul 03 15:02:48 “the name we cannot say” ;) :D Jul 03 15:02:49 YPTM: moto-timo joined Jul 03 15:03:10 zeddii_home: that could be so many things though! Jul 03 15:03:20 I'll share the link pre-emptively this time ;) https://docs.google.com/document/d/1Lr8KgkmmCZ84RF_ThIwnT3WWxMv_tUsHkpRV5PXTd0s/edit?usp=sharing Jul 03 15:05:29 * zeddii_home wonders if anyone else is hearing audio on the call. Jul 03 15:05:39 ha. murphy’s law Jul 03 15:06:43 https://wiki.yoctoproject.org/wiki/WW27_-_2018-07-02_-_Full_Test_Cycle_2.6_M1_rc1 Jul 03 15:07:37 Also, https://lists.yoctoproject.org/pipermail/yocto/2018-July/041670.html Jul 03 15:11:47 oops, zoom crashed, back Jul 03 15:11:54 is the bitbake Packages.gz suitable to be published as an opkg repository directly? Jul 03 15:12:02 yes Jul 03 15:12:05 so this meeting is not public? Jul 03 15:12:12 yates: yes it is Jul 03 15:12:17 [15:59:55] YPTM: Bridge is with Zoom at: https://zoom.us/j/990892712 Jul 03 15:12:50 yes, the meeting or yes the Packages is suitable? Jul 03 15:12:56 both Jul 03 15:13:09 i keep getting "This personal link name is not valid. Please check and try again" Jul 03 15:13:17 rburton: thanks Jul 03 15:25:22 YPTM is over Jul 03 15:26:02 RP: poky-contrib/jpew/hash-equivalence Jul 03 15:31:47 RP: how is buildbot installed on new AB? Ubuntu still has 0.8.12 version (even in xenial-backports) Jul 03 15:31:48 JPEW: At a quick read looks good. Keep in mind that for key in the_data.keys(): is *very* slow. I also see why you started down this rehashing route Jul 03 15:32:00 moto-timo: pip I think Jul 03 15:32:14 RP: are we at 1.0.0 or 0.9.x? Jul 03 15:32:27 moto-timo: 1.1.X I think Jul 03 15:32:34 RP: thank you Jul 03 15:32:47 RP: Ya, I was a little suprised there wasn't a way to (quickly) get all variables with a given varflag set Jul 03 15:32:54 RP: Or I just couldn't find it Jul 03 15:33:20 JPEW: there isn't a way as its very very slow Jul 03 15:33:35 JPEW: bitbake itself keeps some indexes to help that problem Jul 03 15:34:07 JPEW: I think this dynamic rehash thing is a red herring and you might want to focus elsewhere for now Jul 03 15:34:38 JPEW: I'd assumed that at the setscene stage we'd resolve the taskhashes into canonical versions, not at task exection time Jul 03 15:35:11 JPEW: if we do that there isn't a need to dynamically rehash runqueue Jul 03 15:35:45 RP: Hmm..... Jul 03 15:36:59 abelloni: i believe this is the u-boot version being used: https://paste.fedoraproject.org/paste/EzeSqyG6K6lUA3KZGaeOug Jul 03 15:40:29 RP: I think the problem I ran into is that I kept going in circles on that route.... So if you do that, it really doesn't make sense to me to have the sstate .siginfo files be named with the canonicalized hash (since they are how the task hash is actually calculated)? Jul 03 15:52:53 RP: And if the .siginfo is named after the taskhash it doesn't do any good unless someone builds one and puts in sstate.... at which point they may as well put the sstate object itself in the cache with the original taskhash name Jul 03 15:54:10 JPEW: we may want to rethink the way we download/use the siginfo files I guess Jul 03 15:54:23 JPEW: we don't actually need them in the build apart from debugging purposes Jul 03 15:54:37 RP: RIght, thats the other option is to make the .siginfo files non-mandatory Jul 03 15:57:17 JPEW: I think that may be the better option Jul 03 15:59:38 Fair enough, I'll try that out. Jul 03 19:39:41 is the argument to an "inherit" a layer? e.g., "inherit core-image"? Jul 03 19:40:59 yates: No, it's a .bbclass file Jul 03 19:59:08 see also the bitbake user manual, which documents the file format Jul 03 23:35:24 hey all, I'm relatively new to yocto, and I am trying to get a recipe set up that uses libnl, I'm using sumo and I've added libnl to the DEPENDS and RDEPENDS, but when I go to compile it throws a "netlink/netlink-compat.h: No such file or directory" error, and when I hard set it to use -I/usr/include/libnl3 it fails the qa (as I would expect) Jul 03 23:35:43 Am I missing something? (yes) Jul 04 00:50:28 christner_home: Its probably missing right include paths, does your package use pkgconfig to detect deps ? Jul 04 00:50:47 christner_home: if so then add inherit pkgconfig to your recipe Jul 04 01:23:47 how can I use gitpv.class ? Jul 04 01:24:22 or any mechanism to get package version from git describe --tags? Jul 04 01:25:12 desert: you can use SRCPV variable Jul 04 01:26:09 okay, y just googled srcpv what does it contain? Jul 04 01:26:30 ohh i see the manual Jul 04 01:26:46 the version string of the current package Jul 04 01:26:58 i'll echo it to see what's that Jul 04 01:35:50 khem: i get SRCPV = AUTOINC+1b482764fc Jul 04 01:36:27 git describe --tags gives me v3.0-703-g17e1935 Jul 04 01:38:24 desert: there is a no automatic mechanism for adding tag info to PV Jul 04 01:38:55 tags are floating and not going to work when one does not have n/w access e.g. Jul 04 01:39:06 even when you might have sources checked out Jul 04 01:40:40 can this work on a trusted lan where my repo is local? Jul 04 01:47:07 seems i can do GITVER=$(cd ${S} && git describe --tags) Jul 04 01:47:12 inside scripts but not outside Jul 04 01:48:07 however at meta-openembedded/meta-oe/classes Jul 04 01:48:15 i see gitpkgv.bbclass and gitver.bbclass Jul 04 02:23:37 khem: no, I started looking at pkgconfig, but currently its just using cmake for configuration **** ENDING LOGGING AT Wed Jul 04 03:00:04 2018