**** BEGIN LOGGING AT Mon Jan 16 03:00:01 2017 Jan 16 10:11:40 pohly: your tips on postinst logging came in handy, thanks! :) Jan 16 10:12:32 RP: are you sure that was from me? Jan 16 10:12:42 I don't remember anything about that ;-} Jan 16 10:17:32 pohly: https://patchwork.openembedded.org/patch/109491/ - seems it was you :) Jan 16 10:19:58 Yep. But that was over a year ago - I'm not expected to remember that, am I? ;-} Jan 16 10:20:21 Of course not :P Jan 16 10:20:54 pohly: The sad thing was I could remember someone had sent a patch but I couldn't find it for a while :/ Jan 16 10:23:52 hi! Jan 16 10:24:24 i've a little issue with ssh Jan 16 10:24:37 i'd like to fetch a private repository from gitlab Jan 16 10:24:52 i can clone my repository with ssh using the `git` command Jan 16 10:25:01 but bitbake cannot fetch de sources Jan 16 10:25:15 I get an error: ssh: Could not resolve hostname gitlab.com:eeproperty: Name or service not known Jan 16 10:25:39 CyrilF: what is the SRC_URI you are using? also what mechanism are you using for auth? Jan 16 10:26:31 I adde my public RSA key to my gitlab account Jan 16 10:26:59 here is my uri: git://git@gitlab.com:eeproperty/VestaApp.git;protocol=ssh Jan 16 10:27:34 CyrilF: Ah theres your problem, your src_uri should be 'git://git@gitlab.com/eeproperty/VestaApp.git;protocol=ssh' Jan 16 10:28:53 i see... Jan 16 10:29:12 that solved this issue thanks :) Jan 16 10:30:46 Hi, Since a while I have an issue with kernel-fitimage.bbclass, there is a python error. In fact, there is a fix proposed in october, but it's seem still not apply... https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg88558.html why ?? Jan 16 10:31:35 This fix works for me; and without it, the recipe can't work at all without UBOOT_SIGN_ENABLE option... Jan 16 10:32:10 condo4: But i have pinged my patch 3 times ><... tbh I am not sure why it keeps getting missed Jan 16 10:32:15 unfortunatelly, that doens't clone the repo Jan 16 10:32:24 CyrilF: Same or different error? Jan 16 10:32:35 different Jan 16 10:32:42 as it's an other task Jan 16 10:32:55 CyrilF: Whats the error? Jan 16 10:33:27 the /git directory stay empty Jan 16 10:33:44 I must run git pull manually Jan 16 10:33:57 CyrilF: whats the full error message? which task, etc. Jan 16 10:34:06 nrossi: I saw your different pinged... since this patch is very important to make recipe working, why it's still not apply mainline ? Jan 16 10:34:09 task: do_configure Jan 16 10:34:31 ls: cannot access './poky/build-neo/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/vesta-app/2.0.0+gitAUTOINC+4da585bffe-r0/git/*.pro': No such file or directory Jan 16 10:35:11 * RP notes that rss is not entirely well on the new AB :( Jan 16 10:35:12 this is a Qt5 app Jan 16 10:35:23 not surprising I guess Jan 16 10:37:17 CyrilF: Make sure it is checking out the source you expect to that directory mentioned Jan 16 10:38:42 the sources should by cloned in a git directory Jan 16 10:38:51 (named `git`) Jan 16 10:39:58 there is a `.git` directory in it so the local repository is created but not cloned Jan 16 10:40:22 I must run `git pull` (or `git fetch`?) to get the sources Jan 16 10:40:29 from the remote repo Jan 16 10:41:12 CyrilF: not sure what you mean. The git fetcher in bitbake should fetch the remote and clone the repo into the workdir with the directory name "git/" Jan 16 10:41:55 yes but it didn't clone it Jan 16 10:45:41 it creates an empty "git/" directory with an empty README.md file and the right "git/.git/" directory Jan 16 10:48:31 the clone step is missing Jan 16 11:01:17 ed2: did you get a chance to look at https://patchwork.openembedded.org/series/4708/# ? Jan 16 11:03:10 mborzecki: yes, I did. It looks good to me, thank you. Jan 16 11:03:30 great :) thanks Jan 16 11:20:22 CyrilF: If there is an empty readme, chances are its your repo that is "empty". the git fetcher does not create a readme file. Jan 16 12:04:45 hey everyone Jan 16 12:04:53 I'm trying to use devtool to build a recipe Jan 16 12:05:07 I keep getting the following error: Jan 16 12:05:10 OSError: [Errno 13] Permission denied: '/../dl' Jan 16 12:05:13 ed2: any luck with the rss wic patches? I did try a quick hack but wasn't successful with it :/ Jan 16 12:05:14 anyone knows what that is? Jan 16 12:05:55 bernarrrrrrrrrrr: did you set that path in local.conf to anywhere? Jan 16 12:06:19 er, did you set that path anywhere in local.conf? Jan 16 12:12:35 RP: not yet, just starting. I was off on Friday. Jan 16 12:13:01 ooo I mean :) Jan 16 12:14:42 ed2: ah, ok, np Jan 16 12:37:58 @nrossi: my repo isn't empty Jan 16 12:38:24 CyrilF: are you checking out the expected ref/rev? Jan 16 12:39:08 hm, this could be the stupid reason Jan 16 12:41:41 @nrossi: you were right Jan 16 12:42:33 I have a warning "VestaApp/app.conf is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination" Jan 16 12:42:37 but it compiles :) Jan 16 12:51:06 does anybody know why MACHINE variable is not present in 'bitbake -e core-image-minimal' output? Jan 16 12:51:47 @nrossi: thanks :) Jan 16 12:52:00 CyrilF: No problem, :) Jan 16 12:53:16 ed2: because it's unexported. i thought i had a patch to make it appear anyway Jan 16 12:53:47 rburton: and how to export it? Jan 16 12:53:49 oh i never posted it, damn Jan 16 12:54:04 its known to break things Jan 16 12:54:10 rburton: yep Jan 16 12:54:29 can't recall what - and it would be good if MACHINE was unexported in specific recipes instead of all, yes Jan 16 12:54:50 Make sure MACHINE isn't exported Jan 16 12:54:50 # (breaks binutils at least) Jan 16 12:54:50 MACHINE[unexport] = "1" Jan 16 12:55:06 to be honest that might be all due to the make -e we used to do Jan 16 12:55:10 so that may be stale Jan 16 12:55:23 want to uncomment that line and see if anything breaks? Jan 16 12:56:16 RP: ^ do you have an opinion? Jan 16 12:58:45 ross/env is now rebased and outputs unexported variables in the -e output Jan 16 12:58:58 i'll clean it soon and post Jan 16 13:01:29 rburton: works for me: Jan 16 13:01:30 $ bitbake core-image-minimal -e |grep ^MACHINE= Jan 16 13:01:30 MACHINE="qemux86-64" Jan 16 13:01:50 rburton: probably it will breake when rebuilding binutils Jan 16 13:02:02 rburton: i.e. if I remove sstate Jan 16 13:02:40 i can fire a clean build to see what happens overnight, i have scripts for this sort of fun Jan 16 13:02:55 hi, is there a pre defined way in yocto to include install things in sdcard image to flash a nand/nor device (like, kernel, dtb, ubifs) ? Jan 16 13:05:59 i mean, first generate bootloader, kernel, dtb, ubifs and include them with a install script in a sdcard image ? Jan 16 13:07:42 grma: you can look at wic image configuration for beaglebone and edgerouter machines in meta-yocto-bsp. Jan 16 13:08:17 ed2: thx, i will look Jan 16 13:08:23 grma: beaglebone has dtb and kernel on the first partition and known to work Jan 16 13:11:39 rburton: I'm pretty sure some build scripts in things like binutils and glibc use this variable name and the exported value causes obtuse failures (or did) Jan 16 13:12:03 but if we're not using make -e anymore, will it break? Jan 16 13:14:11 rburton: make doesn't clear the environment Jan 16 13:14:25 rburton: these were scripts iirc Jan 16 13:14:36 it was years ago though Jan 16 13:14:50 rburton: keep in mind we really want to clean up the environment, not add to it. Jan 16 13:15:04 * RP wonders why MACHINE might be exported Jan 16 13:15:48 another good question Jan 16 13:16:15 lets just remove that unexport line :) Jan 16 13:18:01 rburton: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=82dd73248db6eb9be25db48081a573d7027a204f :/ Jan 16 13:18:39 what the hell Jan 16 13:18:39 rburton: also, http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=034861cf5bc4e8e3deaecf1198b5aeb4f276ddf0 Jan 16 13:18:51 so is it exported or not ;) Jan 16 13:19:30 totally running a full build test tonight with those two unexports removed Jan 16 13:20:22 RP: wasn't it when people where building for multiple machines from cmdline? Jan 16 13:20:30 *were Jan 16 13:20:30 rburton: it's not exported as far as I can see. I have MACHINE[unexport] = "1" in my bitbake.conf Jan 16 13:20:46 and base.bbclass also unexports it again Jan 16 13:21:04 but it is never exported anyway… Jan 16 13:21:19 so lets delete the unexports, -e works again, and nothing changes Jan 16 13:21:29 hm Jan 16 13:21:38 oh its the env var thing isn't it Jan 16 13:21:44 MACHINE=foo bitbake bar Jan 16 13:21:48 yep Jan 16 13:22:05 ant_work: sorry missed your comment above Jan 16 13:22:20 iirc it was an Angstrom thing Jan 16 13:23:27 rburton: and http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/base.bbclass?id=e4bb4ba86be48108552e8aa8895e1dac25a6770a :/ Jan 16 13:24:09 rburton: yes, but we no clean out the environment so that shouldn't be an issue Jan 16 13:24:17 right Jan 16 13:24:21 this needs retesting Jan 16 13:24:28 AR taken Jan 16 13:35:28 * RP notes oe-selftest smashes the local sstate cache Jan 16 13:35:49 RP: If your free, just wanted to query if you know why this patch (https://patchwork.openembedded.org/patch/133134/, and those mentioned in the newest message) have been missed?, if its a matter of me missing something? Jan 16 13:36:36 nrossi: I think we've likely just failed to pick them up, sorry. rburton? Jan 16 13:37:16 RP: its just someone was asking about it on this channel before. And I am about to send a big series and wanted to make sure I wasn't doing something wrong :) Jan 16 13:38:53 thanks for the ping, sorry Jan 16 13:39:08 nrossi: resending is probably going to be the best way to move forward Jan 16 13:39:59 RP: ok, i will resend it as a full series with cover :). Just ignore those patches Jan 16 13:44:08 nrossi: thanks and sorry, please do remind us if we miss patches Jan 16 13:44:38 RP: no problem, i think i just managed to send it at the wrong time, right during a release ;) Jan 16 13:48:40 nrossi: right, that would mean it would be on the back burner :/ Jan 16 13:51:11 nrossi: see ross/mut2, hopefully that was everything? Jan 16 13:51:19 (poky-contrib) Jan 16 13:52:27 rburton: That was the 3 yep, thanks, quick enough to stop me from sending the series as RP suggested above ^ Jan 16 13:52:39 :) Jan 16 13:53:58 nrossi: just wasn't sure if they still applied cleanly Jan 16 14:03:09 * RP finally makes the build work but can't remember why he was fixing it Jan 16 14:03:27 because it was broken? :P Jan 16 14:03:46 CTtpollard: well, yes, but there was some other specific issue which triggered me to run this in the first place Jan 16 14:08:55 been there done that. Then you're sitting there with a weirdly specific patch but no idea what to do next Jan 16 14:23:28 Good morning, there seems to be a new way to set preferred_version using default_preference? How do I set the preferred version of net-snmp to 5.72 for example? Jan 16 14:26:30 I am trying to add a post processing hook to prepend a small header to my vmlinux .bin file. I tried adding to IMAGE_POSTPROCESS_COMMAND but it seems to be run too early. Is there an easy way to fire something after kernel_do_deploy() gets called? Jan 16 14:49:03 nrossi: patchbomb! Jan 16 14:50:07 rburton: Yep :) hope its not too big Jan 16 15:03:49 Hi All, I need some help regarding Toaster interface. I am running a production instance of the Toaster using Krogoth 2.1.2 and on a Ubuntu 16.04 machine. It works fine but for command line builds it is not showing the build progress correctly. In fact progress bar gets stuck on 80 or 90 % something. All the setup was working under Jethro but after upgrading it to Krogoth it started showing this. Any help would be appreciated. Than Jan 16 15:04:31 Where should I look for any possible issue? Jan 16 15:25:05 hello, what to do when a fetch of a file succeeds, but the file is not put in the corresponding work directory? Jan 16 15:25:53 this is a local file I try to get with SRC_URI += " file://sw-description" Jan 16 15:29:17 this is related to a problem some other people had making SWUpdate work for them: https://groups.google.com/forum/#!topic/swupdate/O2VdV7SBVr0 Jan 16 15:30:07 so anywho my colleague has helped me get debug symbols for my yocoto build. Jan 16 15:30:12 I am also trying to integrate meta-swupdate with my project and get stuck with a similar problem Jan 16 15:30:20 ive got a failure in setfiles from yocto during the selinux build Jan 16 15:30:36 im a newbie when it comes to this but it looks like Jan 16 15:30:59 the code is trying to get attributes of dir entries Jan 16 15:31:04 and they are null Jan 16 15:31:34 then later it tries to do a strcmp without checking that the pointer could be null and thus it segfaults. Jan 16 15:32:15 now why this code path is not taken on a previous build is something i have not determined Jan 16 15:32:38 i guess i need to do another build with debug info on the build that worked so i can run them side by side Jan 16 15:54:59 rburton: RP: I just noticed DISTRO_VERSION in meta-poky doesn't include "snapshot-${DATE}" in master, is that intentional? Jan 16 16:00:13 joshuagl: no Jan 16 16:07:27 RP: patch sent to poky@ Jan 16 16:21:43 which recipe create the user nobody? Jan 16 16:22:19 i see it be used in meta-oe layer, but cant find the creation of the user... Jan 16 16:35:12 hmm, using tinfoil API, how do I get the final rdepends? I mean after the used dynamic libraries are added there. Jan 16 16:36:39 It seems that from "tinfoil.cooker.recipecaches[''].rundeps" I get only those that are explicitly specified in the recipe. Jan 16 16:38:57 ipuustin: presumably you've done a build before trying to look for complete rdepends? Jan 16 16:40:15 joshuagl: Yes, at least I built the recipe which I was investigating. Would I need to build a complete image? Jan 16 16:41:03 ipuustin: no, that should be enough for the RDPEPENDS of the recipe to be able to be complete Jan 16 16:46:05 ipuustin: I don't know enough about tinfoil to know whether that's expected to work, oe-pkgdata-util reads the files generated during packaging (as does toaster, iirc) Jan 16 16:46:58 joshuagl: ok, thanks. It could be that I'll end up reading the same files :-P Jan 16 16:47:26 rburton: i'm doiing a clean build without sstates to discard possible failures Jan 16 16:47:30 RP: may I see what you tried to make wic working in your rss branch? Jan 16 16:47:33 in gobject and qemu upgrade Jan 16 16:47:44 ipuustin: might be worth a mail / bug report ? Jan 16 16:48:05 ed2: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss&id=9df92c717589063920c87fce5a9b177b6093cd37 Jan 16 16:48:21 ed2: it a) needs to clean that out again when its finished and b) doesn't work Jan 16 16:48:23 rburton: i just see your comment Jan 16 16:48:49 joshuagl: I'll investigate bit more still and then do that if I can't figure it out Jan 16 16:49:03 RP: thanks. What does 'bitbake sysrootfs' build? Jan 16 16:49:37 grrrr! Jan 16 16:49:44 pseudo experts needed: how does one debug it? Jan 16 16:49:45 ed2: it populates the old sysroot directories with anything already built Jan 16 16:50:02 I am hitting an issue which seems to be due to pseudo doing chroot() differently than the host Jan 16 16:50:10 the simplest solution to debugging pseudo is to assume that it's user error Jan 16 16:50:16 this has worked for me about 80% of the time Jan 16 16:50:49 ideally, come up with a reproducer smaller than "run bitbake" so you can focus on the actual thing that's failing. Jan 16 16:50:52 kanavin: perhaps you could describe the difference you're seeing? Jan 16 16:51:23 kanavin: turning it into a specific reproducer if you can and then tracing through pseudo has worked for me before Jan 16 16:52:08 RP: actually, my real question is how to enable debug output from pseudo? Jan 16 16:52:36 kanavin: PSEUDO_DEBUG= Jan 16 16:52:49 the number thing is sort of obsolescent Jan 16 16:53:11 pseudo -h should list debug flags. Jan 16 16:53:11 seebs: but does work ;-) Jan 16 16:53:24 0:$ PSEUDO_DEBUG=r bin/pseudo ls Jan 16 16:53:24 Warning: PSEUDO_PREFIX unset, defaulting to /home/seebs/src/pseudo. Jan 16 16:53:24 root_path [fopen64, 4081]: '/proc/filesystems' from '/proc/filesystems' Jan 16 16:53:24 root_path [opendir, 9647]: '/home/seebs/src/pseudo' from '.' Jan 16 16:53:51 RP: the use case if you wonder is: open a fd to /, chroot to something, fchdir to that saved fd, chroot to . Jan 16 16:54:03 RP: works in plain Linux, fails with pseudo Jan 16 16:54:14 (this is the technique rpm4 is using to enter and leave chroots) Jan 16 16:54:18 kanavin: in case you don't realise, seebs is the maintainer ;-) Jan 16 16:54:34 rpm5's chroot works with pseudo. hmm. Jan 16 16:54:41 lemme look at that. Jan 16 16:56:56 seebs: I think rpm5 is doing it differently altogether Jan 16 16:57:40 hmm. it seems to work for me. What is the "failure"? Jan 16 16:58:20 kanavin: rpm4 has worked in the past too which makes me think this has worked at some point Jan 16 16:58:37 'worked' anyway, it did build rootfs Jan 16 16:58:55 https://gist.github.com/seebs/b0eab96e4eaee74b38161687bcd7b6d1 Jan 16 16:59:11 I can do that sequence and pseudo is correctly reporting root paths that match my expectations. Jan 16 16:59:59 seebs: what is the contents of t? Jan 16 17:00:38 https://gist.github.com/seebs/10dcb7ed22281a880f93daa035fb223c Jan 16 17:01:52 seebs: list the contents of / before and after. The issue is that / is not actually pointing to original / at the end of the sequence. Jan 16 17:02:48 it still points to the "f" Jan 16 17:03:40 hmm. Jan 16 17:04:01 root_path [open, 9207]: '/' from '/' Jan 16 17:04:12 that means that pseudo's actually opening the root filesystem /, or at least, it thinks it is. Jan 16 17:05:49 I should support two hardware sharing same kernel. The only difference beetween my two boards is .dtb file. I 1/ create a conf/machine/hard{1,2}.conf Jan 16 17:06:10 i was thinking about creating two kernels: linux-amlogic-hard1 and linux-amlogic-hard2 Jan 16 17:06:22 both would include linux-amlogic.inc Jan 16 17:06:35 and only differ by installed DTB in deploy dir Jan 16 17:06:46 seebs: ‎I have to be away from keyboard now, so can't respond for a couple hours Jan 16 17:06:47 is it "correct" in the yocto-way-of-doing-things ? Jan 16 17:08:37 Okay. I confirm that I do get the expected contents post-chroot. Jan 16 17:09:06 although glob output is a bit surprising, in the chroot'd case it says "//bin" instead of "/bin". Jan 16 17:09:40 But yes, it's successfully escaping the chroot. Jan 16 17:10:03 seebs: thanks, I'll keep digging Jan 16 17:14:50 Hi, I'm building an image using yocto/krogoth and I've run in to the 2Gig limit for mkfs.fat resize. Anyone have a suggestion how to move forward. Its building ext4 and fails during the do_bootimg task Jan 16 17:25:32 thats the file size isn't it - the ext4 partition is 2gb, not the fat file system Jan 16 17:26:00 rburton: Yea thats right Jan 16 17:26:05 because FAT has a 2gb file size limit Jan 16 17:26:11 yes exactly Jan 16 17:26:19 this would be why we want to drop hddimg :) Jan 16 17:26:36 in my case i can just remove debug packages for now to reduce size, but ultimately another solution would be awesome Jan 16 17:26:38 don't use hddimg is one solution Jan 16 17:26:53 Is there another option? Jan 16 17:27:39 If its in the manual somewhere that's good enough for me I just don't know where to look, I haven't seen any related switches Jan 16 17:28:37 wic, i guess? Jan 16 17:28:52 i'll admit that i want to live-boot a usb stick 99% of the time so get by with hddimg Jan 16 17:30:21 I guess i can find all the relevant information in a bbclass somewhere? Jan 16 17:30:31 ask ed2 :) Jan 16 17:30:56 I'm not aware of how to even turn it off at this point :D Jan 16 17:31:08 I'm using wic already to produce an img but it is an hddimg Jan 16 17:31:32 Well at least I know where I'm at now, thanks for the info Jan 16 17:33:04 Strike5150: I spent some time trying to get rid of using hddimg by wic: http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131174.html Jan 16 17:33:40 ed2: Ok thanks, I'll give it a read Jan 16 17:51:08 RP: wic gets native sysroot path from STAGING_DIR_NATIVE. In your branch it points to tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native Jan 16 17:54:29 RP: I went a bit further after I changed the code to use STAGING_DIR Jan 16 17:55:33 RP: now wic breakes failing to find mkdosfs. bitbake dosfstools-native && bitbake build-sysrootfs doesn't help :( Jan 16 17:55:54 RP: i don't see mkdosfs under ./tmp Jan 16 18:01:24 ed2: "bitbake dosfstools-native; bitbake build-sysrootfs" should put it there Jan 16 18:01:52 RP: this is what I did. Jan 16 18:02:24 RP: and it didn't help. see my message above. Jan 16 18:04:11 ed2: $ find ./tmp/sysroots -name mkdos* Jan 16 18:04:11 $ bitbake build-sysrootfs Jan 16 18:04:11 $ bitbake build-sysroots Jan 16 18:04:12 $ find ./tmp/sysroots -name mkdos* Jan 16 18:04:12 ./tmp/sysroots/x86_64/usr/sbin/mkdosfs Jan 16 18:04:16 ed2: worked for me Jan 16 18:04:41 sorry, should be a bitbake dofsutils-native in there Jan 16 18:08:45 ed2: heading afk for a bit, back in a few hours Jan 16 18:09:19 ERROR: Nothing PROVIDES 'dosfsutils-native'. Close matches: Jan 16 18:09:19 dosfstools-native Jan 16 18:09:19 elfutils-native Jan 16 18:09:19 mtd-utils-native Jan 16 18:16:10 ed2: typo but you know that I mean, it did work here :/ Jan 16 18:38:06 do any of you guys do fixes for meta-selinux layer? Jan 16 19:50:31 RP: it started to work. only 4 tests are still failing Jan 16 20:05:03 ed2: "started" meaning you have a patch? Jan 16 20:05:46 Finally, rpurdie/wip-rss is starting to look a bit healthier: https://autobuilder.yocto.io/tgrid Jan 16 20:05:47 RP: I have local changes. I'll commit them when I'm done. Jan 16 20:06:02 ed2: fair enough, thanks Jan 16 20:07:09 seebs: I think I found it - the issue happens if fchdir() and second chroot() happen from a fork()d child Jan 16 20:13:04 RP: first successful package installation with dnf and rpm4 just happened \0/ Jan 16 20:26:45 kanavin_home: nice :) Jan 16 20:34:51 hi, I get a "File format not recognized" cause bitbake tries to link a x86 shared library instead of the arm one. how can tell a reciepe to use the non-native version? Jan 16 20:35:02 I+ Jan 16 20:37:02 I have a bbclass with ruby-cross which builds native gems. but while building it uses the wrong libs and I am not able to find the configuration issue here :\ Jan 16 20:52:01 zauberstuhl: there must be an error on the makefile Jan 16 20:57:09 kanavin: hmm. still seems to work, for me, I think? Jan 16 20:57:12 if (fork()) { int status; wait(&status); return 0; } Jan 16 20:57:16 inserted that above fchdir. Jan 16 20:59:31 So the branch executing fchdir() is the one that got a zero back from fork, and thus, child process. Jan 16 21:06:29 aehs29: ahh thank you sir indead it was a typo in my makefile-patch function Jan 16 21:24:03 RP: i pushed my commits to ed/wic/rss. Only one test case is failing. Jan 16 21:25:29 RP: it's done using your approach: bitbake build-sysroots Jan 16 21:26:54 ed2: I was going to say, those changes don't look so bad :) Jan 16 21:27:34 ed2: In that case we may need to look a little more carefully at how we a) document using wic and b) ensure the wic tests clean out the build-sysroot afterwards Jan 16 21:27:53 ed2: we need a bitbake("build-sysroots -c clean") in there somewhere Jan 16 21:29:17 ed2: Do I need all the commits there or just the top 4? Jan 16 21:31:34 RP: it depends on either you rebased your branch on latest master or not. Jan 16 21:32:04 RP: as I had to cherry-pick couple of commits from ross/mut Jan 16 21:32:23 RP: now they're probably in master Jan 16 21:33:06 RP: i'll add tearDown method and run bitbake("build-sysroots -c clean") there Jan 16 21:35:34 ed2: so it does depend on those fixes? ok. The tearDown sounds good Jan 16 21:38:29 RP: yes, it does. I'm not sure they're all in master already. I can check if needed. Jan 16 21:44:44 ed2: Its fine, I'll just pull them in locally. I can't update my main branch as there is an autobuilder run active against it atm Jan 16 21:45:48 actually, I can since its completed enough now Jan 16 21:46:00 What precisesly goes into sysroot? I'm debugging uim which fails to find anthy during configure after a wipe-sysroot, yet it is listed in DEPENDS. It is the target's sysroot I should be looking at, right? Jan 16 21:46:46 So I'm trying to figure out what anthy package it claims to have installed in the sysroot. and from where. Jan 16 21:47:39 ed2: I wonder how we fix these: https://autobuilder.yocto.io/builders/nightly-wic/builds/141 :/ Jan 16 21:48:33 sveinse: the sysroot population artefacts are separate from packages, keep that in mind Jan 16 21:51:42 RP, those are under sysroot-destdir? Jan 16 21:52:03 sveinse: yes Jan 16 21:54:27 RP: would it work if we add dependency to build-sysroots? Jan 16 21:54:57 ed2: no, since you need to run build-sysroots at the right point, it doesn't have dependencies Jan 16 21:56:29 RP: then we need some meta sysroot recipe as you proposed earlier. wic-tools or something Jan 16 21:57:20 RP: we can make wic image recipes depend on it. Jan 16 21:57:41 RP: it will require to change wic code again, but that's not a big deal. Jan 16 21:57:41 Can I list what is installed in the sysroot? E.g. is there an updated manifest somewhere? Jan 16 22:02:19 My ./sstate-control/manifest-lm-sp-anthy.populate_sysroot sais anthy.h exists there, BUT I cannot find the file present in the present sysroots... Jan 16 22:04:36 ed2: It does sound like we'll need to do that. Can I leave that with you> Jan 16 22:04:38 ? Jan 16 22:05:10 sveinse: look at the sstate-control files, those list what is installed. If its not there and in the manifest, something bad happened Jan 16 22:06:14 RP, it seems like that is the case. And its consistently. I'm easily recreating this on new machines Jan 16 22:06:34 RP: sure. I'll try to sketch something tomorrow. Jan 16 22:12:25 What is the difference between sstate-control/manifest-*-anthy.packagedata and sstate-control/manifest-*-anthy.populate_sysroot ? Jan 16 22:14:00 sveinse: they are for different tasks Jan 16 22:14:32 sveinse: do_packagedata is the task that writes out packagedata (which we can use to look up information about packages independent of packaging format configured) Jan 16 22:14:58 Control question: are the sstate-control/*.populate_sysroot files erased on wipe-sysroot? Jan 16 22:15:08 sveinse: do_populate_sysroot is what populates the sysroot shared with other recipes Jan 16 22:15:24 sveinse: should be, but I don't use that script much Jan 16 22:17:42 It is not. So it could be a leakage from a previous build then. I guess I can delete sstate-control/* prior to running bitbake uim -C unpack ? Jan 16 22:21:22 you really shouldn't be manually deleting anything from that folder Jan 16 22:22:04 doing so will result in errors later on because it will find files that have already been populated and aren't listed in the manifests Jan 16 22:22:29 well, I ran wipe-sysroot and then deleted the folder Jan 16 22:22:58 I need to figure out why my sysroot isn't populated with files necessary for uim to configure correctly Jan 16 22:23:44 it's ruining our builds -- we can't trust the sstate cache, so its kinda serious Jan 16 22:26:05 just so I understand - is the problem that the files are never populated, or that they are only populated if not restoring from sstate? Jan 16 22:28:17 The files are present if a build without sstate cache is enabled. BUT if you run wipe-sysroot; bitbake uim -C unpack, my guess is that this is a sysroot leakage from previous builds. Jan 16 22:29:57 To recap: the uim bb file lists DEPENDS on anthy. By searching the tree I find that anthy.h is present in anthy's sysroot-destdir (like it should), but ultimately not in the final sysroot Jan 16 22:37:45 Looking at the sstate-control dir, I now got two files: manifest-lm-sp-anthy.packagedata and manifest-x86_64-anthy-native.populate_sysroot. Jan 16 22:38:05 So why didn't it populate the device's sysroot? I think that is the key question Jan 16 22:39:15 Can I populate a specific sysroot package with a bb command? Jan 16 22:45:04 man, this is hard and confusing Jan 16 22:46:27 sveinse: bitbake -c populate_sysroot recipename Jan 16 22:46:47 I honestly would avoid using wipe-sysroot unless you know what that is doing, it's not a part of normal build operations Jan 16 22:47:49 bitbake -c clean recipename will remove items from the sysroot for that recipe, if you run bitbake -c populate_sysroot recipename after that then the files will be restored from sstate Jan 16 22:49:22 bluelightning: I was instructed to by rburton. Never the less, I ereased tmp and build uim all over (bitbake uim -C unpack), and my previous observations still hold: No anthy in the target's sysroot, only the host sysroot Jan 16 22:49:47 unpack only unpacks source though, that's not going to put stuff into the sysroot Jan 16 22:49:58 right, wipe-sysroot is one of rburton's scripts Jan 16 22:50:26 can this be a tune vs machine issue? Jan 16 22:53:13 what if you use -C configure instead? Jan 16 22:53:18 bluelightning: uhm, might you be mixing -c and -C here? Because I'm using -C to invalidate a stamp, not to stop at that task. Jan 16 22:53:36 right perhaps I am Jan 16 22:54:11 because the package is being configured and built (but without the proper libs) Jan 16 22:54:37 sveinse: what's in DEPENDS for the uim recipe? Jan 16 22:55:38 DEPENDS="anthy ..." as the first item actually Jan 16 22:56:31 What does this do: DEPENDS_class-target = "..."? Jan 16 23:00:41 sveinse: that sets DEPENDS for uim as opposed to uim-native or nativesdk-uim (assuming native and/or nativesdk are in BBCLASSEXTEND respectively) Jan 16 23:00:57 sveinse: is anthy in that overridden value as well? Jan 16 23:01:02 Will this construct work: Jan 16 23:01:16 DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'libxft libxt', '', d)}" Jan 16 23:15:13 running bitbake -c populate_sysroot anthy and run bitbake -C unpack uim, *then* it works properly. Then the files are present in the sysroot Jan 16 23:16:42 So why does not bb respond by populating the sysroot when its recipe clearly sais DEPENDS="anthy ..."? :o Jan 16 23:19:51 bluelightning: wipe-sysroot is awesome! :) Jan 16 23:20:15 sveinse: can you check what the final value of DEPENDS ends up being by using bitbake -e uim ? Jan 16 23:20:40 sveinse: DEPENDS += is not going to work if you've also got DEPENDS_class-target = Jan 16 23:21:53 fwiw the class-target override on depends isn't needed, bitbake is clever enough to ignore a recipe depending on itself Jan 16 23:22:05 bluelightning: no, it is not. It is literally spelled out as above. See meta-openembedded/meta-oe/recipes-support/uim/uim_1.8.6.bb:l16 if you'd like Jan 16 23:22:16 oh looking at the wrong recipe Jan 16 23:22:41 yeah uim is broken Jan 16 23:23:02 well, so much is broken there Jan 16 23:23:15 yup :( Jan 16 23:23:30 _class-target += will not work like the author probably assumed Jan 16 23:24:04 ignoring why gtk+3 etc is only a target and not native dependency, as there's nothing to control that behaviour, the important thing is that the depends should be DEPENDS_append_class-target Jan 16 23:24:08 jup. ...and guess what, our product in the marked depends on it :( Jan 16 23:24:55 sveinse: change that DEPENDS_class-target += to DEPENDS_append_class-target = Jan 16 23:25:03 so, what can I do (with my little humble experience)? Jan 16 23:25:35 ah, rburton already said what I said, reading comprehension fail on my part Jan 16 23:27:13 recipe specific sysroots (currently WIP by RP) would have meant this issue would have been noticed and probably fixed earlier Jan 16 23:27:33 i fixed two bugs which RSS would make redundant this morning so i can't wait :) Jan 16 23:28:17 actually, I sent a question to the oe-core mail list asking that if recipe has some error -- others than what we talked about now: Jan 16 23:28:40 Such as "I see that it defines quite many packages that end up empty, e.g. uim-anthy. The files the FILES_uim-anthy does exist in the installation, but they are gobbled up by the FILES_${PN} rule in package splitting." Jan 16 23:29:05 Would you agree that that isn't correct? Jan 16 23:29:25 that's standard: have PACKAGES and FILES for all possible packages, and then if they're empty they won't be generated Jan 16 23:29:51 the problem with this recipe is that its got too many implicit dependencies for what makes those packages Jan 16 23:30:06 ideally youd have a load of PACKAGECONFIGs to control what is being built Jan 16 23:31:16 rburton: yes, but uim defines the package uim-anthy with its own RDEPENDS_uim-anthy, but the uim-anthy files are found in uim and uim-anthy is empty... Jan 16 23:31:38 oh right Jan 16 23:31:43 that's just broken Jan 16 23:31:52 exactly Jan 16 23:31:58 sounds like the recipe hasn't been touched for ages and needs to be rewritten :) Jan 16 23:32:40 I'm willing to contribute a fix, but I'm still recipe rusty and probably need some guidance/review Jan 16 23:34:43 start by understanding why uim needs uim-native, building explicitly just what is required for that in native builds, and then doing a more complex build for target Jan 16 23:34:55 ideally adding a PACKAGECONFIG for every option you can fiddle Jan 16 23:35:36 got it Jan 16 23:35:44 eg libsdl shows how to do a pile of packageconfigs that respect distro features *and* change for target or native builds Jan 16 23:36:09 yeah, I am familiar with PACKAGECONFIG Jan 16 23:37:20 btw, does any of you know libedit? Because that is one library which leaks into uim depending on previous sysroots. I am unsure if it shall be enabled or disabled by default Jan 16 23:37:38 RP: ok why is mut on the ab failing all over because of sigkills Jan 16 23:38:54 ie kernel fetch failed with sigkill Jan 16 23:40:26 halstead: AB machines appeared to be OOMing frantically earlier, any ideas? Jan 16 23:40:33 going to fire a new build to see what happens Jan 16 23:41:14 rburton, I've been offline all day. I can peek. Jan 16 23:42:02 halstead: ross/mut2 on the main AB is full of fails from processes being killed, but nothing in the random dmesg i looked at was eating loads of ram. all a bit mysterious. Jan 16 23:42:17 but its late, i've just fired mut on main and master on the new cluster, so fingers crossed :) Jan 16 23:42:49 * halstead crosses his fingers. Jan 16 23:43:43 * sveinse shouts Yeah! Finally Jan 16 23:44:39 rburton, It's interesting that it was killing processes with what looks like 40GB of memory available. Jan 16 23:45:50 ha Jan 16 23:45:54 yeah. 'interesting' Jan 16 23:46:16 times like this i'm glad i can just shout "halstead! it's being stupid again!!' ;) Jan 16 23:46:21 g'night! Jan 16 23:46:41 rburton, Goodnight. Hopefully I can figure something out. Jan 16 23:47:10 rburton: goodnight. Thank you very much for your aid! Jan 17 00:19:16 hi, is there an alternative for cleaning multiple recipes? since bitbake -c cleansstate gem-* isn't working Jan 17 00:34:42 DEPENDS_append_class-target can be used to specify native or nativesdk depends. How do you do the oposite? Add deps that only applies to the target? Best would be via PACKAGECONFIG, but how do I refrain native* from pulling in that dep? Jan 17 00:36:20 uim requires libedit on target, but there is no libedit-native, and I don't really need it. How can I a) not depend on libedit for any native target, and b) change the configure options to omit it Jan 17 00:50:56 sveinse: DEPENDS_append_class-target are target only depends. The trick is that the target can depend on -native during the build (if it needs to run something on the host during build). In your case you should just depend on libedit as a RDEPENDS no? ... Jan 17 00:51:29 sveinse: What i think you are after is a PACKAGECONFIG[libedit] = "--with-libedit,--with-libedit=no,,libedit" Jan 17 00:51:52 sveinse: And have a PACKAGECONFIG ??= "libedit", PACKAGECONFIG_class-native ??= "" Jan 17 01:05:11 nrossi: clever, thanks Jan 17 01:05:55 About that: I see --with-libedit=no quite a number of places, as opposed to --without-libedit. Why is that? Jan 17 01:09:25 sveinse: Check the configure, ./configure --help. I was just reading the source .ac file for what arg to disable, and it looked like it only checks for --with-libedit=no Jan 17 01:09:45 pretty sure they're basically identical. Jan 17 01:09:50 when you pass —without=, the value is no Jan 17 01:09:55 s/=// Jan 17 01:10:25 nrossi: libedit and RDEPENDS: no. configure will detect its missing and disable it, so it needs to be in DEPENDS Jan 17 01:11:25 sveinse: that depends, generally it is better to be explicit than just assuming auto-detection Jan 17 01:12:15 exactly, I'm adding that Jan 17 01:28:39 any online code paster that recognizes bb files? Jan 17 01:31:19 Anyways, here is my humble attempt at fixing uim_1.8.6.bb in meta-openembedded: https://bpaste.net/show/78966587bb71. Very interested in feedback! Jan 17 01:34:30 sveinse: it would be easier to review in the form of a patch, is that something you could produce? Jan 17 01:35:04 bluelightning: yes of course, hang on Jan 17 01:40:51 bluelightning: here. https://bpaste.net/show/6798f0e42c93. Diffed against jethro, but krogoth is very similar Jan 17 01:43:17 sveinse: the two x11 lines in the PACKAGECONFIG default value should be combined into ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 gtk', '', d)} \ Jan 17 01:43:44 sveinse: RDEPENDS_uim = "libuim0 libedit" RDEPENDS_uim-anthy = "takao-fonts anthy libanthy0" will still trigger dependence on libedit, anthy Jan 17 01:44:21 yeah, and if it's actually linking to those libraries none of that should be necessary Jan 17 01:44:53 takao-fonts would need to be explicit though presumably - but you'd do that via the rdepends parameter in the PACKAGECONFIG line Jan 17 01:45:15 sveinse: the PACKAGECONFIG[gtk] line ought to have config options - does it not provide any ? Jan 17 01:45:16 yeah, agreed. Now that files end up in the right packages, the so-resolver can figure that out Jan 17 01:45:57 bluelightning: I honestly don't know. our use case of uim is without x11 and gtk, so that it a black box for me. Sorry Jan 17 01:46:45 sveinse: "--without-gtk2 --with-gtk3" -> should be in the [gtk] packageconfig Jan 17 01:47:20 actually it looks like it supports gtk2 / 3 or nothing, so I would just have a PACKAGECONFIG for gtk and gtk3, drop the one for x11, and control the default for those from x11 in DISTRO_FEATURES Jan 17 01:48:45 nrossi: yes perhaps, but the thing is that it was included in the uim-native before... Jan 17 01:48:57 sveinse: also if you are going for cleaning up, worth moving the "--without-*" from EXTRA_OECONF into PACKAGECONFIG[*] options, even if you only fill out the disabled side Jan 17 01:49:25 nrossi: will do (whatever they are) Jan 17 01:50:08 rdepends, is that the fourth argument to PACKAGECONFIG, right? Jan 17 01:50:18 sveinse: yep Jan 17 01:50:34 sveinse: but its specific to only the ${PN} package Jan 17 01:51:20 nrossi: yes, I did know that Jan 17 02:20:36 mkII of the fixup. Now it starts to look more neat: https://bpaste.net/show/0c65dc682577 Jan 17 02:26:34 Now its long over due for sleep. Night guys Jan 17 02:38:40 Running into an issue with populate_sdk_ext in meta-qt5 Jan 17 02:39:42 I don't see an issue tracker or anything on their github repo though (https://github.com/meta-qt5/meta-qt5). Do the OE projects use an external issue tracker or are they strictly running off of mailing lists? Jan 17 02:54:35 themikenicholson: depends on the project/layer. see the readme **** ENDING LOGGING AT Tue Jan 17 03:00:02 2017