**** BEGIN LOGGING AT Fri Jan 26 03:00:03 2018 Jan 26 07:25:35 What package will provide udev automatically? Jan 26 08:15:17 : i think its udev-extraconf Jan 26 08:15:35 i see Jan 26 08:16:46 I'm using a bbappend on it for a extra rule Jan 26 08:28:16 hi everyone Jan 26 08:33:23 is there a way to apply patches wich are inside the sources of a package? Jan 26 08:34:26 (add patches to do_patch or SRC_URI after unpacking...) Jan 26 08:40:02 Aur313: override do_patch and get patches from {S} Jan 26 09:17:38 RP: Your fix for the missing dependencies not only kills performance: it loops forever here... Jan 26 10:18:50 In an attept to see how our yocto image runs on qemux86-64, it stops on MACHINE_FEATURES ext2 isn't set. No idea why. Is this something I can or should add to in local.conf? Jan 26 10:31:18 `bitbake my_package` builds my_package, but how can I build my_package-dev? Jan 26 10:31:25 sveinse: what actually fails? never seen anything check that before Jan 26 10:31:53 sveinse: its not set, and arguable it should be (there's a few others with the qemu machines override which eg x86-base sets) Jan 26 10:32:43 if I call `bitbake my_package-dev` I get: ERROR: Nothing PROVIDES 'my_package-dev'. Close matches: my_package my_package PROVIDES my_package-dev Jan 26 10:33:13 brrm: you bitbake a recipe, not a pacakge Jan 26 10:33:24 brrm: building the recipe will generate all the packages Jan 26 10:33:35 rburton: ok, thanks Jan 26 10:43:18 how can I add to the `EXTRA_OECMAKE` macro for the dev package only. I tried `EXTRA_OECMAKE_${PN}-dev += "-DTARGET_GROUP=test"` but it doesn't seem to work Jan 26 10:47:09 brrm: not without massive recipe manipulation. the two packages are created from the artifacts of ONE compilation step. so if you want two different configuration steps, it would mean actually splitting the build completely. Jan 26 11:09:13 rburton: my image recipes depend on packagegroup-base-ext2, which the qemu machine does not provide Jan 26 11:09:49 sveinse: personally i'd be not using that pacakgegroup ;) Jan 26 11:09:57 hdparm? :) Jan 26 11:10:10 those groups, basically, are showing their age Jan 26 11:13:13 rburton: ok, they're just.. convenient. Is is of course possible to split them into individual deps Jan 26 11:17:17 I'm really excited to see if Qt is runnable without x11 on qemu. *That* would open up a new world in terms of debugging platform Jan 26 12:30:55 I am looking for some help integrating a .dts and a .dtsi file into my bsp. I've added entries to my SRC_URI in my recipes-kernel/linux/linux-yocto_4.12.bbappend file, but I keep getting an error: "No rule to make target `sc589-ezkit.dts'." Jan 26 12:55:57 hi, what is the recommended way to clone a submodule in a recipe? Jan 26 13:23:29 lpapp: use the gitsm fetcher Jan 26 13:31:31 Son_Goku: are you same as Neal Gompa? :) Jan 26 13:31:40 kanavin: indeed Jan 26 13:31:43 what's up? Jan 26 13:31:55 Son_Goku: we're investigating into replacing bdb in rpm with lmdb Jan 26 13:32:02 Son_Goku: what's your take on that? Jan 26 13:32:04 aren't we all? ;) Jan 26 13:32:22 I don't like the approach of the Photon patch Jan 26 13:32:40 it seems as though you can't actually replace one with the other? for some reason rpm still looks for bdb, if I read the configure.ac correctly Jan 26 13:32:44 yeah Jan 26 13:32:59 Son_Goku: what is a Photon patch? Jan 26 13:33:08 VMware Photon (Linux distribution) Jan 26 13:33:21 the configure.ac needs to be adjusted, but one of the pre-requisites for Panu considering it is that libsolv doesn't care what database it looks at anymore Jan 26 13:33:58 he has a proposed patch for this, which I turned into PR form for easier viewing: https://github.com/openSUSE/libsolv/pull/235 Jan 26 13:34:34 Son_Goku: right. I guess the outcome is that I should stash the recipes and other oe-core fixes into a separate branch, and come back to them later when the situation settles? Jan 26 13:34:49 right Jan 26 13:35:08 my suggestion is to use that patch and have a patch developed for fixing configure.ac and throw that into an experimental branch Jan 26 13:35:33 but Fedora wants to be able to use NDB _or_ LMDB Jan 26 13:35:41 and everyone wants out of BDB Jan 26 13:35:45 Son_Goku: what is a NDB? Jan 26 13:36:00 I saw the configure switches, but it isn't actually explained anywhere! Jan 26 13:36:36 RPM's own internal next-generation database Jan 26 13:36:51 explained here: https://fedoraproject.org/wiki/Changes/NewRpmDBFormat Jan 26 13:37:57 Son_Goku: it doesn't actually explain, is the database storage handled by some external library, or is rpm code taking care of it all? Jan 26 13:39:16 i was hoping "lets make another database!" wasn't the answer to "the existing databases are rubbish what shall we do?" Jan 26 13:40:52 rburton: it seems like ndb is an internal thing Jan 26 13:41:01 anyway, we're not switching until fedora does Jan 26 13:41:02 rburton: yep, saw that, too bad we have not upgraded daisy :/ Jan 26 13:41:12 let them work out all the kinks first Jan 26 13:41:15 rburton: so maybe fetch_ ... _append? Jan 26 13:41:32 lpapp: might be worth reminding management how many critical security bugs are in daisy Jan 26 13:42:05 kanavin: rpm code internally Jan 26 13:42:25 rburton: yeah, banged my head against the wall a couple of times the last couple of years to no avail... but I am completely with you. Jan 26 13:42:31 rburton: well, that's why LMDB got merged in Jan 26 13:42:41 I should change the status quo and I wish I could. Jan 26 13:42:54 but there are a few problems with LMDB that make it so it's still considered experimental, even within RPM Jan 26 13:44:18 the biggest being the key size limit: https://bugzilla.redhat.com/show_bug.cgi?id=1086784#c21 Jan 26 13:44:19 Bug 1086784: was not found. Jan 26 13:44:32 you'd think the bot would know this is not a yocto bug... Jan 26 13:45:47 lpapp: i'd do a do_fetch[postfunc] so you could write it in shall, as do_fetch is python so an append would need to be python too. Jan 26 13:46:06 well, it mightneed to be an unpack postfunc actually Jan 26 13:47:40 rburton: the ndb creation, iirc, was motivated primarily by lmdb dragging their feet on fixing the issue with it Jan 26 13:52:12 Is there a step-by-step guide to writing a board support package? I cannot get mine to produce a dtb. Jan 26 14:01:41 Is there a better forum for me to ask my question? Jan 26 14:02:51 spierepf: yocto mailing list perhaps? Jan 26 14:03:09 as for step by step guide, there is a bsp guide in the yocto docs Jan 26 14:05:12 kanavin: I did ask on the mailing list. My question was of the form "I have problem 'X' and have tried solution 'Y' and got failure 'Z'" Jan 26 14:05:27 kanavin: My only response was did you try solution 'Y'? Jan 26 14:06:00 kanavin: The bsp guide doesn't talk about dtb files. Jan 26 14:08:58 spierepf: sadly, there is no guarantee of a useful response, that's why commercial support contracts and yocto consultancies exist :) Jan 26 14:11:09 spierepf, source of all infos is meta/classes/kernel-devicetree.bbclass Jan 26 14:11:36 it is not so easy to read and immediately understand Jan 26 14:18:03 kanavin: Do you mean that I can pay someone to answer my questions? Can you point me in that direction? Jan 26 14:22:38 spierepf: off the top of my head https://www.toganlabs.com/ https://www.ossystems.com.br/ Jan 26 14:23:44 spierepf: the first one in particular has this right on the frontpage :) "Spinning up a new board but need help with developing a Board Support Package? " Jan 26 14:24:45 kanavin: Perfect! Thanks so much! Jan 26 14:29:02 spierepf, just to let you know, line #16 of that class normalizes the name... Jan 26 14:29:06 basename "sc589-ezkit.dts" | sed 's,\.dts$,.dtb,g' sc589-ezkit.dtb Jan 26 14:29:22 (I have just read your first email) Jan 26 14:31:35 ant_man: Indeed. But it looks like the kernel is trying to generate a .dts file and not a .dtb file. This suggests to me that normalize_dtb is not being called. Jan 26 14:31:58 does your recupe include that class? Jan 26 14:35:46 ant_work: my conf/bblayers.conf file includes a reference to meta if that is what you mean. Jan 26 14:36:34 ant_work: do I need a more specific reference to meta/kernel-devicetree ? Jan 26 14:37:02 no, not anymore. long ago there was an .inc Jan 26 14:37:10 sorry I was confusing you Jan 26 14:37:16 KERNEL_DEVICETREE is enoughù Jan 26 14:39:13 ant_work: np. I appreciate you taking the time to look into it. Thanks. Jan 26 15:02:15 spierepf, I think indeed the problem is KERNEL_DEVICETREE, try renaming it to .dtb Jan 26 15:12:52 bye Jan 26 15:25:38 which is the best variable in my buildsystem to see whether I am building with yocto? Jan 26 15:29:40 ifeq ($(ARCH),arm) and else ifeq ($(HOST_ARCH),arm) Jan 26 15:29:45 were not good enough. Jan 26 15:31:52 the SDK environment script seems to use export ARCH=arm, so that is why I used that Jan 26 15:33:35 hmm, maybe my mistake, bitbake -e says HOST_ARCH="arm" Jan 26 15:38:05 lpapp: you want your makefile to detect if your building under yocto? sounds... horrible Jan 26 15:38:29 why not patch the environment script to set a variable, as you're building the sdk Jan 26 15:42:33 rburton: I want to detect whether it is an arm or intel build Jan 26 15:42:47 without further complication from the user. Jan 26 16:10:43 hello Jan 26 16:11:14 was there any bug at some point related to useradd not adding user in passwd file in the sysroots? Jan 26 16:15:58 when i do chown/chgrp with username/groupname does not work Jan 26 16:16:12 i am doing this in do_install Jan 26 16:24:20 ant_work: Same error, but new file: "No rule to make target `arch/arm/boot/dts/sc589-ezkit.dtb'" Jan 26 16:50:16 <_xthunderheartx_> cls Jan 26 18:01:29 Hey all, I am wondering if someone can show me an example of a recipe properly editing a system file, /etc/network/interfaces specifically. Jan 26 18:04:01 I only need to add lines, although totally overwriting the file would be workable too. Jan 26 18:08:06 New news from stackoverflow: How to build an app that can work on a Linux pc panel? Jan 26 18:08:54 majuk: I believe the proper way is to find whatever package is generating /etc/network/interfaces, then write a .bbappend file for that package that overwrites it with your version Jan 26 18:09:29 brianm_: Ah, ok, that hadn't occurred to me. Seems feasible. Thanks for the input. Jan 26 18:10:15 brianm_: by the by, my funky repo path thing I 'fixed' by just cloning it locally onto my machine and pointing the SRC_URI at that local copy. Jan 26 18:10:41 Work-arounds ftw Jan 26 18:11:11 majuk: np. Probably you'd add a do_install_append that copies your version over, or edits the existing one (e.g. echo 'my_extra_config' >> ${D}/etc/network/interfaces) Jan 26 18:11:33 majuk: that works as a workaround, though good luck getting someone else to compile it :) Jan 26 18:13:21 brianm_: lol, yea. One day we'll get a repo I can address properly. Hopefully. Jan 26 18:30:53 So I have a native recipe that is broken because it's looking for /usr/include/asm/errno.h Jan 26 18:32:59 creating a symbolic link to /usr/include/x86_64-linux-gnu/asm/ fixes it, but is there a better way to handle this? it's a cmake based recipe Jan 26 18:33:17 so this is apparently not the default do_install action in Yocto? "make install prefix=/usr localstatedir=/var sysconfdir=/etc" Jan 26 18:33:20 ? Jan 26 18:34:49 I am actually not even sure what to specify for those variables as /usr, /var and /etc/ might be some system-wide directory in this context? Jan 26 18:51:39 fray: would you be ok with audit defaulting to python3? Seems like we should be moving away from python2. Jan 26 19:58:54 I think my bsp layer is putting my .dts and .dtsi files in the wrong directory. How do I specify a destination location in a SRC_URI entry? Jan 26 20:09:14 khem: hmm, does your meta-clang stuff support using clang as the toolchain used to produce the nativesdk binaries? i guess that'd be crosssdk Jan 26 22:03:37 kergoth: I intended to. but there is a problem I have been lately Jan 26 22:03:54 no worries, was just wondering about the current state Jan 26 22:03:55 the problem is that it can not change -dynamic-linker Jan 26 22:03:59 ah Jan 26 22:04:09 other than that it works great Jan 26 22:04:49 this is because unlike gcc where we have seprate binaries for cross target crossdk in clang its a single compiler Jan 26 22:04:58 with different drivers Jan 26 22:05:33 oh, right Jan 26 22:05:40 and nativesdk case is a bit unique, I have a solution in mind which needs enhancing clang driver a bit Jan 26 22:06:19 so we can inject a prefix to dynamic-linker path Jan 26 22:08:36 then it will come out to be fine and SDK installer then can fix it correctly during install Jan 26 22:09:18 except dynamic-linker libraries seems to be loaded correctly Jan 26 22:10:56 khem: I have a gcc 7.3 upgrade in testing. Assuming I squash that are you ok with it. I had juro's help with some of the patches Jan 26 22:11:09 (its in master-next and building now) Jan 26 22:11:42 RP: yes Jan 26 22:11:56 send a note to ml too Jan 26 22:12:09 i will take a look at master-next Jan 26 22:12:54 khem: yes, will post the patch. This one is rather awaited though so now its released will need to get on with it! :) Jan 26 22:13:41 right Jan 26 22:16:27 RP: http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=a08ea094f2547c6ff4b14ab6c37912805e39a1c2 looks good Jan 26 22:16:37 thats what I was worried about Jan 26 22:17:08 I guess you will squash these all gcc commits into 1 Jan 26 22:17:09 khem: right, Juro sorted that Jan 26 22:17:13 khem: correct Jan 26 22:17:33 khem: just left them separate for testing Jan 26 22:17:40 cool, btw. gcc8 is coming out in april Jan 26 22:17:52 and glibc in second week of feb Jan 26 22:18:07 so I think we can get glibc upgraded for 2.5 Jan 26 22:18:08 khem: so gcc8 in the next release, glibc probably this one :) Jan 26 22:18:16 right Jan 26 22:18:19 khem: snap :) Jan 26 22:18:19 cool Jan 26 22:18:34 as always khem you rock! Jan 26 22:18:50 :) Jan 26 22:19:00 on fridays definitely I rock Jan 26 22:19:24 me too. team lunch with an adult beverage really helps the motivation Jan 26 22:19:36 haha Jan 26 22:19:53 moto-timo: We need to sort some (non)-virtual beer sometime :) Jan 26 22:20:06 llvm6 is released soon that we can plan for 2.5 as well Jan 26 22:20:07 RP: anytime Jan 26 22:20:16 perhaps when I'm not supposed to be avoiding alcohol :/ Jan 26 22:20:31 RP: perhaps that would be a good idea Jan 26 22:20:44 khem: do you run the gtest llvm tests? Jan 26 22:21:04 just read about it today Jan 26 22:27:11 moto-timo: yes I use gtest not for llvm but for lot of other stuff Jan 26 22:27:52 if you have lot of c++ it is helpful Jan 27 00:45:26 Often bitbake decides not to build a package because it's already been built Jan 27 00:45:42 How can I tell if a package has already been built? Jan 27 00:58:25 brianm_: maybe bitbake -n foo (trying that to to see how to best capture the output, I never use that option). Jan 27 01:03:42 it's not clear from building gettext-native so I'll try patch later Jan 27 01:04:25 this does seem like I might not understand your question. brianm_ are you asking how you can know if the package was pulled in from sstate-cache? That should be in the build logs: Jan 27 01:04:52 eg: tmp-glibc/log/cooker/qemux86/console-latest.log Jan 27 01:13:18 vmeson: Thanks, this is kind of what I want, bitbake -n is pretty useful Jan 27 01:13:19 vmeson: My real problem is I have a task dependency from foo.a to bar.b, but for some reason a rebuild of bar.b does not always cause a rebuild of foo.a Jan 27 01:13:52 I was hoping to debug it by inspecting if bar.b was "already built" / look at the state Jan 27 01:16:14 bitbake -g foo maybe? Jan 27 01:16:43 then look at the *.dot files Jan 27 01:47:44 brianm_: DEPENDS is what you need to use to express build time dep Jan 27 01:53:13 khem: I thought I had the dependencies set up right, but it seems there's a distinction between "B must be built to build A" and "if B is rebuilt, A must be rebuilt" Jan 27 01:55:40 I can't figure out how to explain "if B is rebuilt, A must be rebuilt" to bitbake Jan 27 01:57:16 if a.bb says DEPENDS += "b" and b changes then a should be rebuilt Jan 27 02:04:16 khem: what if b is marked as nostamp? What will happen when I try to build a? Jan 27 02:04:22 Will it get rebuilt on a warm build, or not? Jan 27 02:05:59 it appears a is not rebuilt, even though I want it to Jan 27 02:18:44 brianm_: thats interesting, do you know what dependencies do you have on a ? Jan 27 02:18:51 like .h or .a or .so **** ENDING LOGGING AT Sat Jan 27 03:00:02 2018