**** BEGIN LOGGING AT Mon Jun 19 03:00:04 2017 Jun 19 07:37:35 can I assume someone is looking at the refkit autobuilder issues (since the failure seems to change on every build it looks like it's being tweaked)? Jun 19 07:38:41 hmm, they're actually builds from different branches so maybe not being being tweaked after all Jun 19 08:06:48 joshuagl: you probably know something about nightly-refkit? Jun 19 08:07:48 should I be filing bugs on the various failures or talk to someone? Jun 19 08:09:02 jku: we shouldn't be running that against older branches, that part is a bug for me Jun 19 08:09:12 ok Jun 19 08:09:46 jku: there's a bug in refkit's oe-init-build-env which breaks on many of the workers (which you'll see as RunPreamble failures). Probably best to ignore nightly-refkit until the patch for that lands Jun 19 08:09:51 right Jun 19 08:10:25 once it's in a known good state we'll want to include it in SWAT. refkit is on YP bugzilla :-) Jun 19 08:12:04 but someone is handling the oe-init-build-env bug? I don't see a PR for refkit Jun 19 08:12:50 there's a bug in BZ Jun 19 08:13:18 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11640 Jun 19 08:13:20 Bug 11640: normal, Medium, 2.4 M1, mikko.ylinen, IN PROGRESS REVIEW , oe-init-build-env fails on some versions of bash when not sourced from same directory Jun 19 08:21:09 joshuagl: I don't understand how that fixes the preamble failure on master though... ths issue seems to be that the script wants "/openembedded-core/oe-init-build-env" Jun 19 08:22:32 where does that "openembedded-core" directory come from ? or is it part of refkit checkout? Jun 19 08:22:58 it's looking relative to where the source command was invoked, rather than relative to the script that was sourced. The script is part of refkit and lives at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-refkit/build/refkit/openembedded-core/oe-init-build-env Jun 19 08:23:41 ah that makes more sense Jun 19 08:25:23 I don't know if it's an upstream bash bug that the usage of BASH_SOURCE responds differently on different bash versions Jun 19 09:01:20 is it possible to add a generic post-install action for all packages? Jun 19 09:01:55 I want to use dump_syms from breakpad to generate breakpad compatible symbol files from all binaries and files and the .debug directories Jun 19 09:08:11 appending to PACKAGEBUILDPKGD seems like the right way Jun 19 09:38:15 so, there's a breakpad_svn.bb, how can I override that to breakpad_git.bb in my own layer? Jun 19 09:39:38 set PREFERRED_PROVIDER in your configuration Jun 19 09:39:43 ah, of course Jun 19 09:40:03 well, PREFERRED_VERSION even Jun 19 09:40:28 PREFERRED_VERSION_breakpad="1.2.3+git%" or whatever the version of your recipe is Jun 19 09:40:40 % to wildcard the git sha, assuming you've embedded that in the PV Jun 19 09:44:20 yup, figured it out Jun 19 09:44:51 the breakpad stuff was a bit more complicated, I guess it's easiest to look at how the debug splitting works Jun 19 10:05:12 ed2: Does wic write to /etc when its building an image? Jun 19 10:05:43 ed2: https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/1183/steps/BuildImages_1/logs/stdio - "tar: ./etc: file changed as we read it" Jun 19 10:06:25 ed2: something changed while do_image_tar was running, the other tasks were do_image_jffs2 and do_image_wic. I was wondering if wic would make changes? Jun 19 10:07:03 RP: yes, it does. It updates fstab. Jun 19 10:07:30 ed2: so how are other tasks meant to run in parallel without the files changing? Jun 19 10:08:06 ed2: nothing is meant to write to the rootfs during do_image_xxx :( Jun 19 10:08:12 can it fiddle the fstab in the generated image instead of the source rootfs? Jun 19 10:08:37 rburton: it will have to mount it Jun 19 10:08:51 use debug2fs? Jun 19 10:11:01 RP: this is not something new. this functionality was in wic from the very beginning. I enabled updating /boot lately. Now I understand why wic didn't do it before. Jun 19 10:11:54 ed2: it may not be new but it is unfortunately a bug :( Jun 19 10:11:55 RP: you can revert my patch for now. I'll either copy root before modifying to use debug2fs. Jun 19 10:12:20 ed2: the issue didn't trigger on /boot but on /etc Jun 19 10:12:50 RP: yep, it's because fstab is in /etc :) Jun 19 10:13:02 RP: here is the patch to revert: http://lists.openembedded.org/pipermail/openembedded-core/2017-June/138228.html Jun 19 10:13:22 ed2: ah, ok Jun 19 10:13:34 rburton: are you going to queue that? Jun 19 10:13:47 yeah will do now Jun 19 10:16:16 rburton: thanks Jun 19 10:22:51 rburton: there was a weird linking issue in ofmv in mut on friday ... Jun 19 10:23:23 that ofmv upgrade seems to be in master so I'm wondering if that was that fixed or what Jun 19 10:23:53 (only happened in world-lsb) Jun 19 10:24:12 yeah i was wondering if its a lsb-specific warning thing Jun 19 10:25:55 rburton does it use the same compiler? Jun 19 10:27:26 how do dependencies for PACKAGECONFIG entries work? Jun 19 10:27:42 trying to find how (for example) PACKAGECONFIG[qt5] declares a dep on qt5 Jun 19 10:27:42 iirc lsb uses security_flags whereas non-lsb doesn't Jun 19 10:27:52 jku: so same compiler, different compiler flags Jun 19 10:29:26 hmm ok . edk2/ovmf has some very wacky linker scripts that I don't understand ... but I guess that's why they do checks on the symbol table alignment, and that check is failing Jun 19 10:36:29 I'm not sure why openssl-native (1.0.2j in morty) does not populate the sysroot with anything useful - what am i missing ? Jun 19 10:43:31 yann: works for me, ./x86_64-linux/usr/lib/libssl.so.1.0.0 exists Jun 19 10:44:15 I feared there would be something broken :) Jun 19 10:44:43 the fact I'm building morty on Debian 9 may be a source of problem Jun 19 10:44:54 wouldn't break that much Jun 19 10:45:04 * rburton should upgrade Jun 19 10:46:04 the problem I get into is rpm not linking, not having -lssl on its cmdline in the first place - which neatly explains why the linker does not find the relevant symbols Jun 19 10:46:21 but since it was able to build, I suspect it found the host headers Jun 19 10:48:22 i'm considering to cleansstate openssl, but wouldn't it remove the sstate for other versions too ? I'd hate that Jun 19 10:49:22 (anyway I guess I can still rm the relevant files from the sstate directly to be sure) Jun 19 10:52:26 cleansstate will remove *all* state for the recipe you state Jun 19 11:07:12 Cloning into bare repository '/scratch/wood_build/build/downloads/git2/indt333..scratch.ram.ti-axsb-kernel.omap'... Host key verification failed. fatal: Could not read from remote repository. getting this while fetch Jun 19 11:07:40 was trying steps mentioned here http://yocto.yoctoproject.narkive.com/nzFHk3dC/a-simpler-way-of-creating-an-using-a-local-kernel-repository-beaglebone-example Jun 19 11:56:51 Hi. I'm new to yocto. Is there any reason to cross compile from a x64 ubuntu when I'm going to run my application on a x64 yocto? Jun 19 11:57:59 eirikb: there are, especially to confirm reproductibility and dependency tracking Jun 19 11:58:52 eirikb: plus, there can be slight variations in the abi. Jun 19 12:00:33 I don't know much about the cross compiling, what I have now is a Dockerfile which uses phusion/baseimage (Ubuntu-based) parent for building. It's not my app, I'm just building it Jun 19 12:01:19 eirikb: no idea how this is related to what you want to do. Jun 19 12:02:08 The application I'm currently building using ubuntu is going to run on yocto Jun 19 12:02:44 Hello, I'm writing recipe where i need mkimage command, and I have the DEPENDS = "u-boot-mkimage-native", but it complains about libssl.so.1.0.2 missing. Thus command failing. Jun 19 12:03:15 eirikb: ok, but the dockerfile is certainly not related to anything with crosscompiling. plus, it is not going to run on yocto - if, then it is going to run on poky :) Jun 19 12:04:08 i see the library here `tmp-glibc/work/x86_64-linux/u-boot-mkimage-native/1_2017.01-r0/recipe-sysroot-native/usr/lib/libssl.so.1.0.2` Jun 19 12:04:16 LetoThe2nd: The point about the docker is that it handles dependencies, such as specific version of boost library. It is going to run on poky yes Jun 19 12:04:27 eirikb: is this some arcane closed source thing, or is the dockerfile visible for the rest for us? Jun 19 12:05:19 eirikb: i read that as: the dockerfile writer manually tracks dependencies and nails them down, resulting in hard to maintain build script :) Jun 19 12:05:35 LetoThe2nd: It's closed source, but the main thing is libboost, and some other libraries I get from apt (libx11-dev, zlib1g-dev) Jun 19 12:06:12 rburton: removing the buggy openssl sstate selectively and cleaning both openssl-native and rpm-native, and it works correctly now Jun 19 12:06:14 eirikb: well we do have packages for boost, libx11 and zlib. so thats a non-issue. Jun 19 12:06:31 not sure what happenned, but something looks fishy Jun 19 12:06:49 eirikb: and if packaged properly, a specific version can be requested within some limits. Jun 19 12:07:19 LetoThe2nd: The dockerfile is a means for me to not mess around with my desktop linux Jun 19 12:07:51 eirikb: and so is openembedded. its a means for clean crosscompiling and not to mess with your desktop. Jun 19 12:08:18 LetoThe2nd: I wouldn't have to install boost locally? Jun 19 12:08:28 eirikb: no why would you? Jun 19 12:08:50 I've read boost have to be install, simply unpacking it and pointing to it (e.g., LD_LIBRARY_PATH) isn't enough Jun 19 12:09:07 eirikb: it sounds like you are messing up a whole lot of things. Jun 19 12:09:26 By using docker? Jun 19 12:10:28 eirikb: no, generally. maybe we should start with a rough explanation what an OE-based buildprocess actually does` Jun 19 12:10:52 That would probably help, since I don't know anything about yocto Jun 19 12:11:54 eirikb: in short: oe only needs a working toolchain and a lot of disk space. then it builds a custom tailored linux distribution from scratch. thats also why there is no "yocto linux" - they just all differ. Jun 19 12:13:22 eirikb: so for any properly packaged application, it knows compile-time dependencies and run-time dependencies. a dependency tree is formed, and built from bottom to top. Jun 19 12:14:23 eirikb: and it does all that in sysroots with user rights, so you do not need to have to tinker with your desktop linux, other than having the bare requisites for compiling stiff installed (those can be seen in the yocto project quick start) Jun 19 12:16:13 eirikb: so if your application needs parts of boost at compile time (probably headers), and/or parts of them at run time( boost::system for example), then these would be prepared and used accordingly. Jun 19 12:16:46 does that make sense to you? Jun 19 12:18:18 Maybe. I have a makefiles, some vague knowledge of dependencies, and an existing installation of yocto Jun 19 12:18:59 so what parts are not clear? Jun 19 12:19:13 have you actually tried to read and follw the quick start guide? Jun 19 12:19:52 I have not Jun 19 12:20:00 then i would suggest to do so. Jun 19 12:20:34 I haven't done anything beside making it build in docker, then I was told I needed cross-compilation, and I didn't find anything on google so I asked that question here Jun 19 12:21:14 if I have «ROOTFS_POSTPROCESS_COMMAND += something» in a normal package .bb, is that run for the complete rootfs or just the rootfs for that package? Jun 19 12:21:29 I asked because I didn't think it would matter much, I run bunch of debian, ubuntu, centos-built applications on my archlinux, works fine as long as it's x64. So I had to google, then without result I had to ask Jun 19 12:21:55 well then to make it clear. openembedded/poky, as supported by the yocto project is *not* a toolkit for magically crosscompiling things, its a technology to build custom linux distributions. Jun 19 12:22:53 as the architecture the custom distribution runs on is not necessarily the same as the build host, it might often include cross compilation. but thats a means of doing stuff, not the main purpose. Jun 19 12:25:17 So you are saying the problem is my just-make-it-work attitude, but it would technically work? Jun 19 12:26:40 eirikb: no, the problem is that you have probably not grasped what OE is and does. Jun 19 12:27:26 Yes I think so as well. And probably my focus about running "make" and getting some binary files, while the whole toolchain might be, if I'm not mistaking, about outputting a whole distro? Jun 19 12:28:12 do not think of OE as a toolchain to compile stuff. thats just not what it is. Jun 19 12:41:46 I regret my second question. My first was answered, thank you. I think my second should have been: "Ok, thanks. I have to compile an app (not mine) with some dependencies (e.g., libboost, specific version) to run on an existing poky installation, got any links I can read up on?" And then you later mentioned quick start guide, looking at that now, thanks :) Jun 19 12:42:29 eirikb: have whoever created the poky installation hand you the corresponding sdk, and then use that. Jun 19 12:43:06 eirikb: the sdk actually contains a toolchain that you can use to crosscompile. Jun 19 12:43:52 eirikb: and its usage should be mostly documented in the yocto doc set too :) Jun 19 12:45:14 The author can probably guide me a lot as well, he sits down the hall Jun 19 12:46:05 eirikb: then tell him that you want an sdk for the installation he provided. he will know waht you mean. Jun 19 12:46:14 I will. Thanks Jun 19 12:54:58 I'm always surprised to get some packages not rebuilt. Here, after cleaning up all old openssl-native (enough rpm-native to build), I'm getting a later build error on libical, because it links to libcurl which needs to libssl... and curl-native was not rebuilt after openssl-native Jun 19 12:55:02 what do I miss ? Jun 19 12:57:21 Can anyone help me here, I am trying to fetch this kernel source git://git.omapzoom.org/kernel/omap.git;protocol=ssh;branch=p-ti-lsk-linux-4.4.y-next Jun 19 12:58:37 but seeing this https://paste.ubuntu.com/24899159/ Jun 19 13:02:20 Ramose: well, why protocol ssh? why not http/https? Jun 19 13:02:55 Ramose: i get no route to host with ssh/port22, but looks like http works and is listed on the hosts web ui http://git.omapzoom.org/?p=kernel/omap.git;a=summary Jun 19 13:03:57 nrossi: Can git it be used as protocol ? Jun 19 13:04:54 Ramose: you can, but i would recommend http instead of using the git protocol Jun 19 13:06:23 ok, Thanks Jun 19 13:06:45 I just replaced it with git and seems to be working Jun 19 13:30:53 sandsmark: neither. Jun 19 13:31:08 figures Jun 19 13:31:41 found out that I need to find the path for all the .debugs for all the stuff in the image anyways, so I'm back to just using inherit breakpad for everything instead of doing it automatically Jun 19 13:32:49 I assume there isn't a way to do something like .bbappend to a bbclass? Jun 19 13:33:27 to have a global PACKAGE_PREPROCESS_FUNCS Jun 19 13:34:05 just inhert a new class Jun 19 13:34:08 in your local.conf Jun 19 13:34:12 INHERIT+=myclass Jun 19 13:34:20 i guess a better question is what are you trying to do Jun 19 13:34:56 I'm trying to automatically generate breakpad symbol files for all packages on my image Jun 19 13:34:59 oin/in Jun 19 13:35:04 bah, can't type today Jun 19 13:35:37 (I guess my initial description of what I'm doing got lost in the existential discussion above) Jun 19 13:36:05 but to do that I somehow need to append to PACKAGE_PREPROCESS_FUNCS for all packages I install Jun 19 13:36:23 yeah just make a class you can inherit either per recipe or globally Jun 19 13:36:46 once you've made it work per recipe you can just inherit it globally and you're sorted Jun 19 13:37:16 there's already one that works per recipe Jun 19 13:37:20 lemme dig up a link Jun 19 13:37:28 https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/classes/breakpad.bbclass Jun 19 13:37:28 so your work is done then :) Jun 19 13:38:01 ewwww Jun 19 13:38:08 yeah, that's what I thought :p Jun 19 13:38:39 if it can't work out what to do on its own then you can't inherit it globally, obviously Jun 19 13:38:55 exactly Jun 19 13:39:20 whats wrong with the usual debug splitting stuff? if you want remote bug reporting there are numerous tools that deal with coredumps Jun 19 13:39:27 I put this in my image.bb, but then I need to install debug symbols in my image file; http://ix.io/xFw Jun 19 13:39:35 rburton: yeah, breakpad is one of them :) Jun 19 13:39:43 but it needs its .sym files Jun 19 13:39:57 *deals with coredumps* being the important bit in my statement Jun 19 13:39:59 which are generated from either binaries with debug symbols, or stripped binaries + path to debug lib Jun 19 13:41:42 why can't that class run dump_syms for every binary in the package Jun 19 13:42:16 it can, but it needs to be run for all dependencies as well Jun 19 13:42:28 (or should) Jun 19 13:42:28 so every package runs it for everything that is executable Jun 19 13:42:48 oe-core *already does this* for debug file stripping, so its not exactly rocket science Jun 19 13:43:38 yeah, but that is done in package.bbclass, iirc? Jun 19 13:43:56 hence why I wanted to append to the package.bbclass Jun 19 13:44:12 so what that breakpad class does it extend the list of tasks involved in packaging Jun 19 13:44:23 its the right approach, it just hardcodes a name instead of just doing the right thing Jun 19 13:44:49 yeah, but only for a single package, I can't get every package I add to my image to inherit that class, can I? Jun 19 13:45:04 you can if you inherit the class globally Jun 19 13:45:19 so, in my local.conf basically? Jun 19 13:45:24 or your distro configuration Jun 19 13:45:24 yes Jun 19 13:45:26 sweet Jun 19 13:45:37 thanks, I think that's the missing piece of my puzzle Jun 19 13:46:09 you just need a class that does the right thing in all situations Jun 19 13:46:58 indeed Jun 19 13:47:09 that's doable though Jun 19 13:47:38 just walk bindir and libdir and look for executable files Jun 19 13:57:59 oh doh, globally inheriting something in local.conf and then DEPENDing on something in that class didn't work too well Jun 19 13:58:15 I guess I should be more specific in that INHERIT Jun 19 13:58:33 sandsmark: i was waiting for you to discover this :) global inherits need to be a bit clever Jun 19 13:58:48 indeed Jun 19 13:58:51 eg only do stuff for target recipes Jun 19 13:59:09 I'm not too clever but I'm good at bruteforcing a working solution :p Jun 19 13:59:47 for example you can use class-target overrides Jun 19 13:59:52 recipes-devtools/binutils/binutils.inc:DEPENDS_append_class-target = " chrpath-replacement-native" Jun 19 14:01:23 ah, nice Jun 19 14:16:53 Hi all, can anyone help me sort this issue out? One sub-package in my recite eats me all debug binaries - so they are missing in the packages where they are listed... Jun 19 14:17:02 all: ^^ Jun 19 14:17:35 phatina: probably the FILES for that particular subpackage is defined too aggressively. Jun 19 14:18:13 LetoThe2nd: is lists all the contents (binaries, tests specificaly) Jun 19 14:18:18 or its a recent release which automatically puts all .debug symbols into PN-dbg for you Jun 19 14:18:37 phatina: pastebin the recipe, makes helping so much easier Jun 19 14:18:49 ... just copy+pasting... Jun 19 14:19:27 phatina: you know, the real important thing about copypasta is just like real pasta. the timeframe of cooking has to be right! Jun 19 14:19:27 https://paste.fedoraproject.org/paste/1CDwHvIN0rdQNRfxY2G17g Jun 19 14:21:12 LetoThe2nd: package iotivity-service-samples-dbg contains all the binaries and tests in /usr/bin/.debug Jun 19 14:21:35 modern yocto says don't have more than one -dbg package Jun 19 14:22:03 rburton: do you have link for that statement, please? Jun 19 14:23:04 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b7766e4bbe61d025346365de4cbafcae56909c27 Jun 19 14:24:15 rburton: thak you Jun 19 14:24:46 rburton: so if I really want to have several -dbg packages, I could NOAUTOPACKAGEDEBUG = "1" and then leave the recipe as is, am I correct? Jun 19 14:24:47 (its in the release notes too but that was easier to find) Jun 19 14:24:50 yes Jun 19 14:24:59 set that and you're left to deal with it yourself Jun 19 14:25:32 rburton: yeeey, thanks a lot Jun 19 15:00:09 Hello my opkg does not work as intended any can help ? :( Jun 19 15:00:24 * opkg_download: Failed to download http://148.251.78.235/releases/17.01.2/packages/arm_cortex-a9_vfpv3/telephony/Packages.gz, wget returned 8. Jun 19 15:01:43 8 Server issued an error response. Jun 19 15:01:47 bittin: have you checked that file is available? Jun 19 15:01:59 CTtpollard: yeah it is i could download it with Chromium Jun 19 15:02:04 try with wget :) Jun 19 15:02:11 bittin: have you tried with wget on the system using bitbake? Jun 19 15:02:32 Failed to redirect to /releases/17.01.2/packages/arm_cortex-a9_vfpv3/telephony/Packages.gz on bugs.lede-project.org Jun 19 15:02:35 with wget Jun 19 15:02:42 what is bitbake? Jun 19 15:05:46 hi, i use poky pyro and this patch is applied there http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6fcb96076ca60ef30062fda0ff8308cc840ab07d , but i still got the error Jun 19 15:09:23 Who's the current contact to request a new layer on git.yoctoproject.org? Jun 19 15:16:41 netprince in #lede-dev solved my problem :) Jun 19 15:24:03 kergoth: halstead is the admin, he can likely help if there's an additional process piece too Jun 19 15:26:39 okay, thanks. working on splitting up meta-sourcery into meta-external-toolchain for the generic components and meta-sourcery for the bits truly specific to our toolchain, to make it easier for folks to know what to keep and what not to when looking to support their own external toolchains, if folks agree, was thinking about adding the other layer to git.y.o Jun 19 15:32:09 I can't immediately see why anyone would disagree with that Jun 19 15:32:31 * kergoth nods Jun 19 15:35:06 Thanks for the help :) Jun 19 15:35:12 Please, where is located the file to configure the kernel ? Thanks. Jun 19 15:41:52 ChrysD, bitbake -c menuconfig virtual/kernel Jun 19 15:42:04 does nobody uses populate_sdk ? Jun 19 15:42:48 vm_ : that's the way to acces to menuconfig but i remember that there is a file somewhere with the list of kernel configs. BTW thanks. Jun 19 15:42:59 vm_ : I use populate_sdk why? Jun 19 15:43:02 tons of folks use populate_sdk, what exactly is your question? Jun 19 15:43:36 when i try to build it, it returns error 255 is too long with chrpath Jun 19 15:44:02 its the error like here http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6fcb96076ca60ef30062fda0ff8308cc840ab07d Jun 19 15:45:00 i got pyro, there it is , but i still got this error with one package nativesdk-u-boot-mkimage Jun 19 15:45:39 ChrysD, there is also mostly a defconfig file inside recipes-kernel/linux/somefolder Jun 19 15:45:53 vm_ : ok thanks Jun 19 15:47:20 my guess is you were thinking about the linux-yocto kernel and its config fragments? that's the only way i could see you'd run into a list of available configs. but you aren't limited to the existing fragments, you can set anything you want in the kenrel configuration Jun 19 15:55:35 does the sdk is not installed when one package like nativesdk-u-boot-mkimage fails ? or where do i find the sdk? Jun 19 15:56:36 first, populate_sdk doesn't install an sdk, it builds one, with an installer that you run to install the sdk Jun 19 15:56:47 and that's correct, a build failure will result in no emission of an sdk installer at all Jun 19 15:58:13 hmm, do you all build in a dir like /a/ to have no long path names? Jun 19 16:07:19 vm_: no Jun 19 16:09:14 rburton, thx Jun 19 16:13:29 is there a way to "disable" the package nativesdk-u-boot-mkimage in the -c populate_sdk build? Jun 19 16:14:24 why would you want to do that? Jun 19 16:15:56 because it throws error about too large; maximum length 255 Jun 19 16:16:18 rburton, this error https://patchwork.openembedded.org/patch/34653/ Jun 19 16:16:21 can you not do the build in a higher directory? :) Jun 19 16:17:07 rburton, higher ? deeper to the root dir , or? thats why i asked if you all build in /a/ Jun 19 16:17:22 you must have a very deep directory to hit that error Jun 19 16:17:31 rburton, no Jun 19 16:18:35 what release of oe are you using? Jun 19 16:18:44 pyro Jun 19 16:19:20 strange , the error is since 2012 Jun 19 16:19:22 how deep is your build path? Jun 19 16:20:17 21 chars Jun 19 16:22:07 mine is 23, and works Jun 19 16:22:13 so i suspect its not actually the build path depth Jun 19 16:22:31 what is the actual log? Jun 19 16:26:27 Executing python function perform_packagecopy Jun 19 16:26:27 ERROR: nativesdk-u-boot-mkimage: chrpath command failed with exit code 7: Jun 19 16:26:59 too large; maximum length 255\n" Jun 19 16:26:59 DEBUG: Python function perform_packagecopy finished Jun 19 16:26:59 DEBUG: Python function do_package finished Jun 19 16:26:59 ERROR: Function failed: perform_packagecopy Jun 19 16:28:13 this line looks strange b"new rpath '$ORIGIN/../../../../../../../home/ Jun 19 16:40:47 vm_: confirmed, works for me Jun 19 16:42:18 DEBUG: Executing python function perform_packagecopy this seemed to produce the error,where can i find that func? Jun 19 16:42:40 meta/classes/package.bbclass:python perform_packagecopy () { Jun 19 16:42:57 rburton, thx Jun 19 16:45:24 it seemed to call rpath_replace where can i find that? Jun 19 16:47:07 $ git grep rpath_replace Jun 19 16:47:07 meta/classes/chrpath.bbclass:def rpath_replace (path, d): Jun 19 16:47:14 its in chrpath.bbclass Jun 19 16:47:22 thx Jun 19 16:48:58 aw nuts Jun 19 16:59:43 funny error from yoctoautobuilder property value too long Jun 19 17:00:45 seemed that def process_file_linux is producing the error Jun 19 20:55:32 http://hackaday.com/2017/06/19/intel-discontinues-joule-galileo-and-edison-product-lines/ Jun 19 20:56:38 not good for OE/YP Jun 19 21:11:30 Khem__, hi, any more patch for gcc7 / armv5 ? Jun 19 21:12:25 iirc I tested including the no-thumb patch but kernel was miscompiled (XZ) Jun 19 21:12:53 Aloa ! Jun 19 21:24:28 ant_home: only armv5 device I have tested is qemuarm Jun 19 21:24:37 and it uses kernel 4.10 Jun 19 21:25:00 ant_home: if you dig a bit more into the nature of error I might be able to help Jun 19 21:26:10 right, the loog was short on serial Jun 19 21:26:14 Terminal ready Jun 19 21:26:15 Uncompressing Linux... Jun 19 21:26:15 XZ-compressed data is corrupt Jun 19 21:26:15 -- System halted Jun 19 21:26:42 si it is at the very beginning Jun 19 21:27:17 I'l lretry gc7 soon with 4.1x Jun 19 21:27:49 I am just finishing one problematic kernel patchset.. :/ Jun 19 21:42:18 yeah that seems like very early Jun 19 21:42:26 it could also be due to size of binary Jun 19 21:42:38 and limits on where the kernel image is emitted at Jun 19 21:42:54 and your bootloader might be reading few bytes less Jun 19 21:43:09 say if kernel image size has grown with gcc7 recompile Jun 19 21:43:18 do you use u-boot ? Jun 19 21:43:29 or what is your boot scenario Jun 19 21:49:00 Khem__, same kernel size, does sizecheck, boots if compiled with gcc6 Jun 19 21:49:37 tried two flavors, with and without initramfs Jun 19 21:50:29 if it things compression data is corrupt that usually is due to size issues Jun 19 21:51:17 is it compiling the initrd/rootfs with gcc7 too ? Jun 19 21:51:35 I would suggest to just compile kernel with gcc7 and reuse working rootfs Jun 19 21:51:46 to narrow it down further Jun 19 21:52:31 ok Jun 19 21:52:43 armv4 is the same? Jun 19 21:53:00 did not test yet Jun 19 21:53:27 you have armv4 too ? Jun 19 21:53:32 yes Jun 19 21:53:41 collie Jun 19 21:53:46 wow do you work for a museum :) Jun 19 21:54:49 strang ehobby, eh Jun 19 21:55:12 oh ok Jun 19 21:55:23 you might want to get patches backported to kernel like https://patchwork.kernel.org/patch/8610021/ Jun 19 21:55:36 armv4 is being deprecated in gcc7 Jun 19 21:55:43 yes... Jun 19 21:57:26 do you have that patch ? Jun 19 21:58:58 did not check if it is in OE yet Jun 19 21:59:17 read long ago that msg about deprecating it Jun 19 21:59:39 still, isn't gcc6 pathed for v4bx? Jun 19 21:59:49 *oe's gcc6 I mean Jun 19 22:00:03 yes Jun 19 22:00:08 ah, ok Jun 19 22:00:59 is there a chance for you to run 4.9+ kernel Jun 19 22:03:57 I was building 4.10 with gcc6 for armv5 and it did boot Jun 19 23:21:38 Greetings. I'm working on a large project that uses poky and bitbake and yocto to create an embedded linux distribution. I want to add an RDEPENDS to the project (specifically: http://git.yoctoproject.org/cgit/cgit.cgi/meta-cloud-services/tree/meta-openstack/recipes-support/salt). But I'm getting the error 'nothing RPROVIDES 'salt'' Jun 19 23:24:20 Do I add meta-openstack to some sort of provider list, or do I copy the bitbake recipes into my project? Jun 19 23:50:27 drewbert: is meta-openstack in your bblayers.conf? **** BEGIN LOGGING AT Tue Jun 20 00:12:07 2017 Jun 20 02:41:59 kergoth: is shallow clone support in core now ? Jun 20 02:42:33 khem: yes, though i still need to email scott to get it added to the docs Jun 20 02:42:58 to be clear, shallow mirror *tarball* support is in, shallow *clones* aren't viable due to limiations of the git remote protocols Jun 20 02:43:15 kergoth: ok superb, Jun 20 02:43:19 how can I use it ? Jun 20 02:43:25 I want to add it to gcc recipes Jun 20 02:44:25 https://github.com/openembedded/bitbake/commits/master, scroll down to 'Commits on May 26, 2017' Jun 20 02:44:49 'fetch/git: add support for shallow mirror tarballs' describes basic usage, the commits after it which add further enhancements to that describe how to set the vars that control those Jun 20 02:46:19 ok thanks Jun 20 02:46:28 so it can be done per recipe too I suppose Jun 20 02:46:41 BB_GIT_SHALLOW = "1" and BB_GENERATE_SHALLOW_TARBALLS = "1" Jun 20 02:46:54 is what I need to add along with git uri Jun 20 02:47:20 as the first commit says, BB_GENERATE_SHALLOW_TARBALLS already defaults to 1 if BB_GIT_SHALLOW and BB_GENERATE_MIRROR_TARBALLS are enabled Jun 20 02:47:44 but yep, then when you fetch next, it'll emit a gitshallow_ tarball in DL_DIR. deploy that to your mirror of choice and that'll be fetched and used instead of the full tarball Jun 20 02:47:44 that comment is bit confusing Jun 20 02:47:58 i don't see what's confusing about it Jun 20 02:48:21 # This defaults to enabled if both BB_GIT_SHALLOW and Jun 20 02:48:21 # BB_GENERATE_MIRROR_TARBALLS are enabled Jun 20 02:48:21 BB_GENERATE_SHALLOW_TARBALLS ?= "1" Jun 20 02:48:52 as it says ,if you have BB_GIT_SHALLOW and BB_GENERATE_MIRROR_TARBALLS enabled, then shallow tarball generation defaults to enabled Jun 20 02:48:55 perhaps it should be BB_GIT_SHALLOW ? Jun 20 02:48:59 if not, then not Jun 20 02:49:07 i don't undersatndt he question Jun 20 02:49:38 there are 3 variables mentioned here, BB_GIT_SHALLOW, BB_GENERATE_MIRROR_TARBALLS, and BB_GENERATE_SHALLOW_TARBALLS. the 3rd defaults to enabled if the other two are enabled, otherwise it defaults to disabled Jun 20 02:49:46 i don't see how to explain it any clearer than that Jun 20 02:49:58 ok what I read is that 2 variables BB_GENERATE_MIRROR_TARBALLS Jun 20 02:49:58 and BB_GIT_SHALLOW if enabled then BB_GENERATE_MIRROR_TARBALLS is enabled by default Jun 20 02:50:13 which seems to be obvious Jun 20 02:50:25 no, it's not Jun 20 02:50:28 because they're mutually xclusive Jun 20 02:50:36 if a shallow tarball is being generated, a full tarball is not Jun 20 02:51:02 and BB_GIT_SHALLOW controls both the default behavior of tarball creation *and* whether we *fetch* shallow tarballs Jun 20 02:51:13 if you want to fetch them but not generate them, that's where the mirror tarball variables are useful Jun 20 02:51:44 oh I mistook MIRROR for SHALLOW Jun 20 02:51:47 hrmm Jun 20 02:52:01 unless you have very specific requirements, its unlikely you'll ever need to set BB_GENERATE_SHALLOW_TARBALLS, as it defaults to enabled if the other 2 are in use, which they usually are when populating a mirror Jun 20 02:52:29 yeah it makes sense Jun 20 02:52:39 i've used it from tiem to time when i need to generate full tarballs regardless of whether i'm fetching and using shallow ones or not Jun 20 02:52:52 I was reading BB_GENERATE_MIRROR_TARBALLS and BB_GENERATE_SHALLOW_TARBALLS Jun 20 02:52:52 same Jun 20 02:52:55 ah Jun 20 02:53:26 i'm open to any suggestions on improving usability, as far as i know mentor is the only one that's done anything with this, so the more the merrier Jun 20 02:53:54 if I just set BB_GIT_SHALLOW = "1" Jun 20 02:54:08 then does it set some defaults for BB_GIT_SHALLOW_DEPTH Jun 20 02:55:13 yes, good point, i think i forgot to mention that in the commit message Jun 20 02:55:21 it defaults to a depth of 1 if BB_GIT_SHALLOW_DEPTH is None / unset Jun 20 02:55:30 ok cool Jun 20 02:55:34 if you set it to 0 or the empty string, it'll disable it Jun 20 02:55:52 which sounds redundant, why not just change BB_GIT_SHALLOW for that case, but it's mainly to support cases where multiple names/branches are in use Jun 20 02:56:06 so you can enable it as a whole, set the default depth to 0, then set just one branch to 1, or whatever Jun 20 02:57:08 Hmm, I have an idea for meta-sourcery/meta-external-toolchain.. rather than manually maintaining the FILES variables, use a task in the internal toolchain recipes to write out files lists and use them in the external toolchain build. could check those files into the external toolchain layer, just wouldn't have to maintain them manually for i.e. glibc Jun 20 02:58:10 —depth 1 means it will only have history of last 1 rev ? Jun 20 02:59:06 yeah. iirc epth of 1 == just keep the top commits. so it's the total number of commits including srcrev, not just how much history there is, hence 0 being equivalent to disabled Jun 20 02:59:12 s/commits/commit/ **** ENDING LOGGING AT Tue Jun 20 03:00:02 2017