**** BEGIN LOGGING AT Thu Apr 13 03:00:03 2017 Apr 13 07:21:20 Good morning. I have a question regarding linux kernel fitImages: Is it somehow possible to include 2 kernel images and 2 dtb's (from 2 different branches) in ONE fitImage using yocto/oe? Apr 13 07:33:48 g0hl1n: with master it might be possible. in jethro we ended up copying poky kernel classes to another layer and renaming all paths, variables and tasks so that multiple kernels can be built for one machine target. Apr 13 07:36:43 mcfrisk: now that's good news :-) I'm currently migrating my stuff from jehro to master (pyro then). Is there somewhere some documentation on that? Apr 13 07:39:32 g0hl1n: I'm not following master so closely but I remember seeing major kernel class refactoring patches. check latest docs for kernel class details. Apr 13 08:35:51 Hi all, Oke this is a big step in the ounknown for me. Apr 13 08:36:13 I have a question about output files after creating an image with Yocto Apr 13 08:37:37 I use a TI AM335x SBC from goembed Apr 13 08:37:45 http://goembed.com/index.php/Products/detail/tpid/25 Apr 13 08:38:17 Now first of all I tested the board with the image which has been delivered with the board. Apr 13 08:39:00 All worked like a charm. Until the point that I tried to make my own image Apr 13 08:39:35 The board doesn't recognize the image on the SD card. Apr 13 08:39:43 I think the problem is the following: Apr 13 08:40:27 Goembed uses the following files to boot : - MLO - u-boot.img - uImage - uEnv.txt - rootfs.tar.bz2 Apr 13 08:41:16 when I create an image with yocto, there is no uEnv and image file. only a zImage. So I think this is the problem Apr 13 08:41:35 But I can't find a solution. Apr 13 08:42:00 This is probably a very stupid question, but I'm a beginner and trying to learn this by my self. Apr 13 09:00:57 TMJJ: for getting started, you should be able to just keep the mlo, uboot and uenv from the original. the kernel image type is controlled like that: https://www.openembedded.org/wiki/Kernel_Building#Kernel_image_type Apr 13 09:01:14 oh oops, outdated info. second please. Apr 13 09:04:29 TMJJ: the config variable is still called KERNEL_IMAGETYPE :) Apr 13 09:05:42 Oke Thanks I will have a look at it straight away! thanks for the quick support! have a nice day! Apr 13 09:06:02 TMJJ: doesn't the supplier provide a proper BSP layer for you to use? Apr 13 09:10:15 Not yet. I sended an email to the supplier, but no respons yet. On the website they say it's fully 'compatible' with beaglebone. So I downloaded the beaglebone BSP. I want to start with this BSP and then start to modify the layers to my preferences. Is this smart or not? Apr 13 09:14:14 pohly: you're mentioning some runqemu issue yesterday evening. what was it? Apr 13 09:15:26 ed2: for refkit, the "runqemu: do not rely on grepping images" patch changed the drive device type from "virtio" (the fallback when grep didn't find anything) to "SCSI" (the new default in qemuboot.bbclass). Apr 13 09:15:58 My tests were written based on the assumption that there is a /dev/vda and /dev/vdb, so they started to fail. Apr 13 09:16:09 Not really a bug, just some change in behavior. Apr 13 09:16:21 pohly: yes, the same happened to my tests. I had to change device names. Apr 13 09:16:42 ed2: I suspected that you might have had similar issues. Apr 13 09:18:29 TMJJ: depends. the point is what artifacts you do expect... a complete sdcard image, or something to write into the ROM, etc. if its really fully compatible, you maby jsut need to look up the available building target for the BBB Apr 13 09:18:43 pohly: yes, i pointed Robert to this and he fixed it: http://lists.openembedded.org/pipermail/openembedded-core/2017-April/135509.html Apr 13 09:21:25 TMJJ: this should give you an idea how the BBB sdcards can be generated: https://www.yoctoproject.org/downloads/bsps/morty22/beaglebone Apr 13 09:22:52 Thanks, I will go trough all of this. Apr 13 12:11:32 hello there Apr 13 12:11:38 anybody an Idea where I can find KERNEL_IMAGETYPE ?= "..." Apr 13 12:11:52 It should be some where under machine I think Apr 13 12:12:27 the error message: "do_kernel_checkout: S is not set to the linux source directory. Check the recipe and set S to the proper extracted subdirectory" likes me to do WHAT???? Apr 13 12:12:43 i don't use a git source for the kernel but at tar ball Apr 13 12:12:58 TMJJ: did you try this: bitbake -e | grep ^KERNEL_IMAGETYPE= Apr 13 12:13:53 I will try it straight away Apr 13 12:14:25 the checkout untar the archive in tmp/work/.../4.4.x-r1/ but not in tmp/work-shared/../kernel_source Apr 13 12:15:30 what is S and where do i set it? in recipes-kernel/linux/*.bb file?? Apr 13 12:17:50 crzier : this returns me the current Image type : bzImage. I would like to change it. is there a command for this as well? Apr 13 12:17:50 would be nice if one of the 258 people in here could give me the right hints Apr 13 12:34:33 * beeker23 sighs Apr 13 12:36:33 beeker23, maybe pastebin the recipe you are using Apr 13 12:43:56 Crofton|work https://paste.debian.net/927415/ Apr 13 12:52:27 what is S and where do i set it? Apr 13 12:54:06 is S the path where the kernel source gets unpacked? is it a relative path or a absolute path? is it a file:// url notation? Apr 13 12:55:50 beeker23: S is the path where it has been unpacked to, which includes any subdirectory that may be within the tarball that was unpacked Apr 13 12:56:18 you would set it in the recipe you are working on Apr 13 12:56:36 e.g. S = "${WORKDIR}/something" Apr 13 12:56:39 bluelightning: is the path relative to the build directory or absolute? Apr 13 12:57:02 absolute, but you specify the work directory using ${WORKDIR} like in the above example Apr 13 12:57:45 the work directory is where the source gets unpacked, then if the tarball contains a subdirectory, that's what you'd be pointing to with S Apr 13 12:57:51 hopefully that makes sense Apr 13 12:57:51 ${WORKDIR} is so to say the absolute path to the build dir? Apr 13 12:58:04 aha, ok! Apr 13 12:58:12 lets try it Apr 13 12:58:21 ${WORKDIR} will be substituted by bitbake for the work directory for the recipe Apr 13 12:58:34 I'm goin gto make a guerss something like Apr 13 12:58:49 S = ${WORKDIR}/tinker-4.4.6 ... Apr 13 12:59:11 the kernel ends up in a "funny" work dor? Apr 13 12:59:20 well, with quotes around the value, but yes Apr 13 12:59:32 "something like" Apr 13 13:00:59 TY Apr 13 13:01:24 for me it is S = "${WORKDIR}" Apr 13 13:01:48 hmm Apr 13 13:01:51 seems odd Apr 13 13:01:58 but unlike a git clone it unpacks the stuff in work/.... and not in work-shared/.. Apr 13 13:02:28 I would expect tarbal to unpack into a ./tinker-4.4.16 directory Apr 13 13:02:51 ok that is what I was wondering, but WORKDIR should do the right thing Apr 13 13:03:49 Crofton|work: it unpacks directly in tmp/work/tinker_rk3288-rk-linux-gnueabi/linux-rockchip/4.4.16-r1 Apr 13 13:04:11 which is $WORKDIR, i guess Apr 13 13:04:22 so the Makefile is in WORKDIR? Apr 13 13:04:27 yes Apr 13 13:04:30 ouch Apr 13 13:04:35 see how things work out Apr 13 13:04:42 it compiles now Apr 13 13:05:01 this error message is not very useful Apr 13 13:05:09 some other direcotris end up in workdir, I'd worry about strange interactions Apr 13 13:05:15 but if it works .... Apr 13 13:05:42 Crofton|work: i repacked the kernel tar ball because i was unsure what yocto expected Apr 13 13:06:18 well armed with this info, you should be able to sort things out better Apr 13 13:07:49 yepp, would be nice if the error message would hint to the solutions and not to an obfuscating blahblah Apr 13 13:09:41 it makes a do_package now Apr 13 13:09:49 done Apr 13 13:11:47 bluelightning, Crofton|work: ty very much Apr 13 13:16:15 beeker23: np Apr 13 13:16:45 bluelightning: dude go to bed Apr 13 13:16:53 beeker23: your tarball is non-standard; pretty much all tarballs people release contain a subdirectory so they don't explode files all over your current dir when you unpack them Apr 13 13:17:04 rburton: flaming MSR still needs writing :/ Apr 13 13:17:23 why do I leave it to past midnight? oh yeah, I have actual work to do... Apr 13 13:17:35 I shouldn't complain, really Apr 13 13:17:57 bluelightning: you are right. it's like i said above. i wasn't sure what S is and hadn't any clue that there is also a $WORKDIR Apr 13 13:18:18 beeker23: no worries Apr 13 13:23:09 yay! even wlan0 is up now Apr 13 13:24:56 MSR? Apr 13 13:26:38 Crofton|work: Monthly Status Report, in this case (not to be confused with Model-Specific Register) Apr 13 13:26:45 lol Apr 13 13:26:47 Intel loves loves loves its acronyms Apr 13 13:26:51 yeah Apr 13 13:29:43 ok, i'm off Apr 13 13:37:34 I'm still searching for a way to include 2 kernel images and 2 dtb's (from 2 different branches) in ONE fitImage... According to mcfrisk this should be possible in current master, but I'm unable to find anything in the manual or git history. Anybody has some ideas/pointers? Thanks! Apr 13 13:49:50 kergoth: hm pkgconf looks interesting Apr 13 14:24:55 is there an easy / recommended way of getting rid of the /opt/poky/... prefix in the nativesdk packages? Apr 13 14:40:21 mdnneo: no because thats the prefix Apr 13 14:41:40 rburton: so I cannot use them in a kind of chroot env with opkg or is this just the wrong way? Apr 13 14:42:59 they're designed to be standalone so why do you need a chroot? Apr 13 14:45:12 rburton: basically I want to use opkg with -o to create a kind of new one and use the created packages stored on a server Apr 13 14:45:47 I know I need to do the relocate afterwards but thats another story Apr 13 14:48:05 also I just wonder how it works if I try to extend an existing SDK via opkg if it is not installed to the default location Apr 13 14:52:01 so question regarding EXTRA_IMAGEDEPENDS, should it be translating to :do_populate_sysroot task depends? this appears to trigger population of the sysroot from those targets which seem like it might be undesirable? Apr 13 14:52:40 Hi everyone, maybe someone know but how do we know the plugins used during à gst-play ? thx :) Apr 13 14:53:19 ChrysD: #gstreamer would be more helpful Apr 13 14:56:20 ChrysD: i think there's a logging mode where gst-play will tell you what plugins it is building into a pipeline Apr 13 14:56:42 rburton : Good to know, i will check it thanks. Apr 13 15:03:10 mdnneo: presumably you could also treat your server as your target/MACHINE rather than SDKMACHINE, build an image with the file format as tar.gz, and unpack it on the server as root and chroot in Apr 13 15:06:50 kergoth: so if I got it right you say building not an SDK but an x86_64 image containing the stuff I want ... the server stuff you maybe got wrong ... this is a ipk repository where I push all my ipk's to use them with a host opkg Apr 13 15:07:02 ahh Apr 13 15:07:20 yeah, not 100% clear on your usage, but something along those lines might be an option, yes Apr 13 15:07:31 worth consideration, anyway Apr 13 15:10:10 so yes maybe the easiest use case I try to do is extending an existing SDK installed not in the default folder via a host opkg and the ipk package Apr 13 15:20:30 mdnneo: so if I understand correctly, you want to install additional packages into your SDK using opkg, but your SDK location does not match $somepath/opt/poky and installing additional nativesdk packages with opkg -o $somepath creates stuff in /opt/poky, but you want the files in $somepath directly? Apr 13 15:21:02 neverpanic: exactly Apr 13 15:21:51 Couldn't you just bind-mount $somepath to $somepath/opt/poky? Apr 13 15:32:04 neverpanic: :) works ... for now seems like a solution ... enough for today .. happy easter to everyone Apr 13 17:04:42 RP: FYI. I am seeing a couple of weird errors with the new useradd changes. I will work through them and get back to you once I know more, but just so you know that we are not done there yet... Apr 13 17:12:42 hello again. has anyone experience with the meta-debian minimal core image? can i add the standard debian.org repository to apt sources to complete the running system? Apr 13 17:41:26 Goodday gents, I am trying to build qemuarm and I've got FSTYPES += " vdi,vdmk". I've somehow got a dependancy on syslinux which is not compatible with arm-poky-linux-gnueabi. This is in krogoth. Apr 13 17:41:33 I don't need syslinux is there a way to remove it? Apr 13 17:44:06 what's the point of building a vmdk for a non-intel arch? maybe i'm missing something Apr 13 18:15:19 How to add en_US.UTF-8 locale to image? Apr 13 18:15:45 IMAGE_LINGUAS Apr 13 18:16:07 I've tried change GLIBC_GENERATE_LOCALES and IMAGE_LINGUAS but `locale -a` still just C and POSIX (no en_US.UTF-8 at all) Apr 13 18:16:59 kergoth: I tried that also: GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8" and IMAGE_LINGUAS = "en-us" Apr 13 18:17:16 but `locale -a` command shows just C and POSIX Apr 13 18:17:18 did you look at what packages were installed? Apr 13 18:17:24 check the package manager Apr 13 18:18:19 kergoth: what do you mean by what packages were installed? Apr 13 18:18:30 images are built by installing packages Apr 13 18:18:33 rpm, ipk, deb Apr 13 18:18:44 run opkg, rpm, or dpkg to list the installed packages Apr 13 18:18:57 specifically glibc-locale* Apr 13 18:19:08 the exact command depends on nwhat package manager you're using Apr 13 18:20:36 kergoth: thank you, opkg list | grep glibc-locale return nothing, so does that mean locales weren't installed? Apr 13 18:20:43 what image is this? Apr 13 18:21:09 core-image-minimal will likely not install them by design Apr 13 18:21:30 I'm building image for Intel Edison, the image is edison-image, I think it inherit from core-image Apr 13 18:22:05 make sure the image recipe isn't overriding you, or anyone else. use bitbake -e edison-image|grep IMAGE_LINGUAS= Apr 13 18:23:45 kergoth: it return IMAGE_LINGUAS=" " Apr 13 18:23:49 weird Apr 13 18:24:18 run bitbake -e edison-image | less and type /IMAGE_LINGUAS=, then scroll up. it'll show exactly what set it to that, and where Apr 13 18:25:06 let me try Apr 13 18:26:10 I see it here, but how to know which file this line defined? Apr 13 18:26:51 Ok, I see, it defined in meta-intel-edison/meta-intel-edison-distro/recipes-core/images/edison-image.bb Apr 13 18:27:11 set IMAGE_LINGUAS_pn-edison-image = "en-us" Apr 13 18:27:16 that'll override what the image is setting Apr 13 18:27:23 though i'd be curious why it was set that way Apr 13 18:27:38 you should likely create yourself a layer and an image in that layer (can copy edison-image) for any further customization Apr 13 18:27:49 the _pn- method in local.conf is really best for a temporary hack Apr 13 18:29:02 kergoth: Thank you very much, I'll try it now Apr 13 18:31:40 np Apr 13 18:42:43 kergoth: its work! en_US shown, thank you very much for your help! Apr 13 18:43:41 np, happy to help Apr 13 18:43:56 might want to ask the meta-intel folks why they empty it, though :) Apr 13 18:49:42 I have the same question :D Apr 13 20:44:32 well, i guess i forget the frankenstein yocto and go with debian from scratch again Apr 13 20:45:35 it's easier ;-) Apr 13 20:53:55 beeker23, I wouldn't recommend meta-debian Apr 13 20:54:37 Crofton|work: what would you recommend? Apr 13 20:54:47 and why Apr 13 20:54:51 well, I do not know what you are tryin gto do :) Apr 13 20:55:32 but as I recal, meta-debian trie sto make something debian like with OE, and that just seems like a path to make everyone unhapppy :) Apr 13 20:57:46 Crofton|work: why unhappy? i'm not sure if it is good for me to compile packages day-in, day-out. from different repositories. Apr 13 20:58:25 liek i aid, I don't understand what you are trying to do Apr 13 20:59:18 i don't know why you'd want a frankenstein monstrosity when you can just build a regular distro with oe like most people do, most things already have recipes anyway.. but as Crofton|work says, not familiar with your particular requirements Apr 13 21:00:25 Crofton|work: actually i'm just playing around with my newest gadget (tinker board). integrated the asus kernel source in yocto and made some packages. yocto is over complicated. find all the dependencies and setup a own repository... could be more straight forward. Apr 13 21:01:11 so I'm glad the tinker board works Apr 13 21:01:40 i don't see how it's that much more complex than building *any* distro from scratch, including debian. if you don't care about long term maintenance, buildroot would work, and if you don't care about building from source, you could certainly assemble filesystems from debian binaries Apr 13 21:01:49 Although you can build something that beahves like a traditional desktop image with YP, most of us are focus on application specific images Apr 13 21:01:50 works well, afaik. Apr 13 21:01:52 but homerolling is pointless IMO, you'd just be wasting time reinventing wheels Apr 13 21:02:00 and being able to maintain them over a period of years Apr 13 21:02:48 kergoth: thats what i said. debian from scratch is my way, i guess. Apr 13 21:02:56 Anyone know anything about how pseudo works? Apr 13 21:02:58 trying to make buildroot work for long term distro maintenance is why oe exists, because that sucked Apr 13 21:04:22 Saur: worst case you can just talk to its maintainer.. Apr 13 21:04:28 but what exactly is your question? Apr 13 21:04:53 kergoth: u see the point with bitbake and these layers and recipes. it's cool and things work well. just bitbake this and that. but i'm not sure if i like to maintain all these sources. Apr 13 21:05:09 ^u^i Apr 13 21:05:29 kergoth: Well, I am looking into some problems with the useradd changes RP and I did, and now I have ended up in a weird problem with pseudo. If I am in a devshell, and execute a script that contains the following two lines: Apr 13 21:05:29 no, i have no idea what your point is. the whole point of the layer structure and open source metadata is collaboration, so *you* aren't the one maintaining it all Apr 13 21:05:35 export PSEUDO_UNLOAD="1" Apr 13 21:05:36 in that it's no different than any other distro Apr 13 21:05:42 echo "$(echo hi all | tr -d '[:space:]')" Apr 13 21:06:07 kergoth: Then the echo will print an empty line. If I remove the export line, then it works as expected... Apr 13 21:06:11 Saur: seebs in this channel is peter seebach, the pseudo maintainer, he'd be the expert Apr 13 21:06:15 ah, interesting Apr 13 21:06:19 not a clue :) Apr 13 21:07:11 beeker23: debian has a repository of debian source packages just as we have repositories of recipes, and both include patches. the only difference is how they're distributed Apr 13 21:07:19 If I trace the script, it never even forks the tr in the first case... Apr 13 21:07:19 and the particular tools used to build them Apr 13 21:07:20 kergoth: well. i need to maintain my own yocto / oe project Apr 13 21:07:26 beeker23, are you working from a tarball or a git clone of a layer? Apr 13 21:09:05 Saur: That's really interesting! Apr 13 21:09:08 Crofton|work: the kernel for the tinker board was from a tar. but the whole packages got compiled via meta layers, more or less Apr 13 21:09:16 seebs: You don't say. ;) Apr 13 21:09:32 Off the top of my head, I have a vague recollection of there being some weirdness to do with locale issues, but I can't immediately see why that would matter. Apr 13 21:10:23 Just trying it in a plain old command prompt running under pseudo, I don't see that behavior. Apr 13 21:11:27 seebs: I have no idea how to run pseudo directly, I only run it through bitbake -c devshell ... Apr 13 21:12:14 Most of the time, my actual work on pseudo isn't in yocto at all, I have it as a standalone program. Apr 13 21:12:20 but i learned bitbake and the whole concept. it's good. but it's also tough work. Apr 13 21:12:22 So I just run "bin/pseudo" and get a prompt. Apr 13 21:14:32 beeker23, gets easier with time Apr 13 21:14:41 seebs: Any tips on how I can debug this? Apr 13 21:14:45 you have something that basically works Apr 13 21:15:36 Crofton|work: yeah, i see it. in the and is just bitkae this & that and install the package with whatever you prefer Apr 13 21:15:45 ^and^end Apr 13 21:16:58 https://www.amazon.com/Embedded-Systems-Prentice-Software-Development/dp/0133443248 Apr 13 21:17:02 is a recent book Apr 13 21:23:51 Crofton|work: i'm not so much into books anymore. my fear with oe / yocto is, that you have to trust the providers of the SRC_URI's, somehow. and thats why i think the steady work of the debian folk is trustworthy when it comes to qa. don't know the social structure of yocto/oe yet. and thats another point. Apr 13 21:24:19 ours as as good or better than debian :) Apr 13 21:24:46 :-) Apr 13 21:25:05 beeker23: source is checksummed, so you only have to trust the authors of the recipes, not that no upstream will be compromised Apr 13 21:25:14 Saur: I'm honestly not totally sure. I guess the first thing I'd probably do is try to reproduce it with just pseudo instead of the whole build environment, in case that's somehow part of whatever's happening. Apr 13 21:25:32 I've been involved for around 10 years, we have come a long way and continue to improve Apr 13 21:25:52 I don't recall how compatible the build environment usually is with the host, but if you can find the pseudo binary, which is in principle host native, you should be able to just run it directly Apr 13 21:25:59 $ /path/to/pseudo sh Apr 13 21:26:04 should give you a root-ish prompt. Apr 13 21:27:13 seebs: Yes, tried that now. I get the same result that way... Apr 13 21:31:01 bluelightning: you know what i mean. not all recipes come from the archive. some from github, some tar balls and so on.. ok. don't like to make bad vibes. and there is also no reason to. you are nice people and the project is a good approach. i really loved to make progress and if you are serious about keep your own distro maintained yocto would be a recommended way to go. i admit that. Apr 13 21:31:27 seebs: If I run "pseudo sh testscript.sh" then it works as it should, but if I run "pseudo sh" and then run testscript.sh from the prompt then it fails... Apr 13 21:33:02 beeker23: as you say, it's just a different approach. whatever works best for your situation. Apr 13 21:33:06 Crofton|work: and if i need to build a package from source, than it's a little step to write a recipe and contribute it Apr 13 21:33:11 regarding SRC_URI, though, its worth noting that yocto project maintains a source mirror Apr 13 21:33:46 seebs: However, if I create a second script and let it call the first script, then "pseudo sh testscript2.sh" fails... Apr 13 21:34:21 i still rather like the idea of trying an oe-based distro where everything is built out of self hosted git repositories, no reliance upon upstream hosting at all Apr 13 21:34:35 don't know if anyone has tried such a thing yet Apr 13 21:34:53 kergoth: thats what i mean. and thats serious work. Apr 13 21:35:13 i think most just maintain their own mirrors of the upstream sources, so their builds never have to contact upstream Apr 13 21:35:17 that's what mentor does Apr 13 21:35:31 heh, we should have a kickstarter to raise money to let kergoth work freely on all hi sideas :) Apr 13 21:35:36 hah Apr 13 21:36:23 that is really, really, odd Apr 13 21:36:43 anything in pseudo.log? Apr 13 21:37:11 seebs: Where do I find it? Apr 13 21:38:01 So pseudo will have a default pseudo path (something similar to /var/pseudo) which should have a pseudo.log in it. Apr 13 21:38:11 I think you can run it as PSEUDO_PATH=/tmp pseudo [...] Apr 13 21:38:18 and then it should be /tmp/pseudo.log. Apr 13 21:38:43 It's a pretty strange behavior, though, because I can't think of any way pseudo should be breaking piping or anything like it. Apr 13 21:39:12 ok, it's bed time. have nice days Apr 13 21:39:36 seebs: Nothing in the log that seems relevant... Apr 13 21:40:52 bluelightning: do you know if the devtool modify issues with bbclassextend have been resolved? i remember issues if you attempt to modify foo-native, not knowing any better, for example Apr 13 21:42:18 Can you dump your test scripts somewhere (e.g., gist.github.com) for me to try? What's the host environment? Apr 13 21:42:24 seebs: Ok, I have devtool'd pseudo-native now, so I can make any changes to it now. Apr 13 21:42:53 seebs: A reeeeally old fedora core 17... Apr 13 21:43:19 we had to keep stuff running on RHEL 4 for an unreasonably long time, so that *shouldn't* matter, I don't think. Apr 13 21:43:28 Unless there's a missing syscall or something? But that doesn't seem likely. Apr 13 21:44:11 seebs: Well, my test script is only the two lines: export PSEUDO_UNLOAD="1 and: echo "$(echo hi all | tr -d '[:space:]') Apr 13 21:44:30 and the tr can be replaced with cat or anything else with the same result... Apr 13 21:45:23 huh Apr 13 21:45:28 seebs: Any debug flags to pseudo that I can enable that could be relevant? Apr 13 21:46:27 hmm. Apr 13 21:47:46 okay so what happens if you replace "| tr..." with "| blah", where "blah" is a command that doesn't exist, and thus can't be executed? Apr 13 21:47:58 Does that fail in an expected way? Apr 13 21:48:57 seebs: Yes, it does. Apr 13 21:49:12 I'm trying to figure out what could be actually failing, and nothing obvious is showing up. I guess you could run with "-x w" to get wrapper logging, and then compare the output of two ways of invoking the script. Apr 13 21:50:10 What's odd is that it's not spawning the tr command in your other testing, but it's getting far enough to try but fail. Apr 13 21:50:13 huh. Apr 13 21:50:23 what about $(echo hi all | echo hello) Apr 13 21:51:04 seebs: That outputs hello... Apr 13 21:52:04 Okay, that gives us some information, it's running the second command. Hmm. But that might be using a builtin, maybe? Apr 13 21:52:32 seebs: Ah, the shell messing up. If I use /bin/echo then it is empty again. Apr 13 21:52:34 I wonder whether builtins are involved. Might be useful to make a tiny hello, world C program for comparison. Apr 13 21:52:37 Oooh. Apr 13 21:52:40 That's informative! Apr 13 21:52:59 How about $(/bin/echo foo)? Apr 13 21:53:26 if that expands to "foo", then it's actually running the command and the problem is specific to the pipe case. If it's empty, something else is going wrong possibly specific to command substitution. Apr 13 21:54:00 Aha, that failed as well.. Apr 13 21:55:55 Btw, echo "$(/bin/echox hi all)" gives the same empty result... Apr 13 21:56:22 It's obviously not running anything inside $(...) at all... Apr 13 21:59:42 Wait, now I'm confused. I thought that the "| blah" test failed in the expected way (... by which I meant "command not found" or something similar.) Apr 13 22:00:18 Hmm. Okay, next experiment: What if you try the same thing with a different sh? Like, /bin/sh, /bin/bash, install ksh and try that, etc. Apr 13 22:00:30 seebs: It did when I used echo ... | foo, so I guess the shell was doing stuff internally Apr 13 22:01:12 oh neat, if your sdk name has a space, it won't install :) Apr 13 22:03:57 seebs: It is a bash problem. If I use dash or zsh it works as expected... Apr 13 22:05:16 Crofton|work: doesn't surprise me, the sdk shell archive scripts are .. not great Apr 13 22:05:51 yeah Apr 13 22:08:24 i have bits to let the sdk auto-re-run the relocate scripts whenever you move it, but they just pile more ugliness on the existing ugliness, need to do a lot of cleanup on the baseline first Apr 13 22:08:24 heh Apr 13 22:31:03 seebs: Ok, I have another clue: the forked bash shell that is supposed to execve the code inside $(...) segmentation faults... Apr 13 22:39:34 oooh. Apr 13 22:39:56 I have a suspicion about that. Apr 13 22:40:07 seebs: Ok? Apr 13 22:40:27 So we've run into some weird stuff in the past with bash and environment variables. Apr 13 22:40:51 The bash code actually *redefines* setenv/getenv/etc., differently from libc's versions. Apr 13 22:43:04 Hmm. But that *shouldn't* be breaking anything, I don't think. Apr 13 22:45:01 Anyway, you'd probably need to build a copy of bash with debugging symbols and get a core file or something similar. Apr 13 22:45:27 seebs: Hmm, not exactly what I had planned for... :P Apr 13 22:46:02 yeah. alternatively, upgrade system to newer version and hope for the best. :P Apr 13 22:46:31 That's... Nearly five years old, so it may well be an older version of bash with different weird internal magic. Apr 13 22:46:32 seebs: Yeah, who else is stupid enough to run this old a system... Apr 13 22:47:07 FWIW, there actually ARE reasons for the strange getenv/setenv behavior; basically, bash wants to be able to manipulate its environment table efficiently, which it can't do if using raw setenv/getenv, especially because the POSIX API doesn't give you a way to do that without memory leaks. Apr 13 22:47:47 seebs: bash version is 4.3.30 Apr 13 22:47:49 So there's extra magic to intercept those calls (in case they're made by code bash is linked with), and shove things into the bash data structures, and then update the actual environment only right before an actual exec. Apr 13 22:47:54 huh! Apr 13 22:48:02 that is recent enough that it shouldn't be significantly different. Apr 13 22:48:15 Like, I'm on 4.3.46, which is... 2013, anyway. Apr 13 22:48:29 ah-hah Apr 13 22:48:53 I can reproduce this on modern bash, now that I know to actually invoke bash. Apr 13 22:49:20 seebs: Ok, so it is not only me then. Good to know... :) Apr 13 22:50:31 i'll see if i can reproduce the thing, but as a workaround, don't use bash? :P Apr 13 22:51:16 seebs: Unfortunately I do not think that works as a generic solution... Apr 13 22:52:54 huh Apr 13 22:53:30 seebs: I do not think we can tell all users of bitbake that they must not use bash as /bin/sh... Apr 13 22:54:08 well, yeah Apr 13 22:54:28 it's pretty weird, i'm not at all sure what's happening. Apr 13 22:54:59 4094 if (STREQN (assign, export_env[i], equal_offset + 1)) Apr 13 22:54:59 (gdb) p assign Apr 13 22:54:59 $1 = 0x979828 "_=/bin/cat" Apr 13 22:54:59 (gdb) p export_env[i] Apr 13 22:54:59 $2 = 0x0 Apr 13 22:55:01 welp Apr 13 22:56:10 seebs: You're debugging bash? Apr 13 22:56:43 yeah Apr 13 22:56:55 seebs: Better you than me I guess. :) Apr 13 22:57:56 Okay, so, I think I sort of see what's happening. It looks like, when pseudo tries to drop the LD_PRELOAD variable for PSEUDO_UNLOAD, it ends up zeroing out an entry in environ... but bash was tracking how many things it thought were in environ. Apr 13 22:58:34 ah Apr 13 22:58:35 So the problem is we're bypassing bash's fancy management... And thus breaking what it thinks it knows about the environment. Apr 13 23:06:14 seebs: I modified pseudo_dropenv() to always call SETENV() regardless of whether strlen(ld_preload) is 0 or not, and now it works... Apr 13 23:08:55 Yeah. Apr 13 23:09:17 I would really prefer to actually drop the environment entry if it's going to be empty, but that may be unsafe for bash. Apr 13 23:11:03 I should possibly also be catching execvpe, which is currently ignored. Apr 13 23:11:24 ... but honestly this is a nice easy one-liner so I think I'll go with it for now. Apr 13 23:14:23 I've pushed a proposed fix (which is basically yours) to master, it's commit b6b68db896f9963558334aff7fca61adde4ec10f. Apr 13 23:14:26 Nice catch! Apr 13 23:18:38 seebs: Could be simplified to: Apr 13 23:18:38 if (ld_preload) { Apr 13 23:18:38 SETENV(PRELINK_LIBRARIES, ld_preload, 1); Apr 13 23:18:38 } Apr 13 23:19:06 seebs: Anyway, as long as it is fixed, I am happy. :) Apr 13 23:23:16 except that if ld_preload is empty, we probably want to write an empty string rather than leaving the environment alone. Apr 13 23:23:27 ... although i suppose the check for non-empty contents is now pointless. Apr 13 23:23:41 this is why i try not to do anything by thursday afternoon or later in a week, i'm usually stupid by now **** ENDING LOGGING AT Fri Apr 14 03:00:01 2017