**** BEGIN LOGGING AT Mon Jan 14 02:59:56 2019 Jan 14 08:22:58 good morning Jan 14 08:31:51 New news from stackoverflow: Yocto toolchain build fail Jan 14 09:19:29 Hi, while building gstreamer 1.14.0 , facing this issue "autoreconf: failed to run autopoint: No such file or directory Jan 14 09:19:30 autoreconf: autopoint is needed because this package uses Gettext Jan 14 09:19:30 ERROR: autoreconf execution failed." Jan 14 09:20:00 can anyone point me out how it can resolved ? Jan 14 09:47:25 kanavin: any news on perl? I think we may need to single thread this until we resolve the problem Jan 14 09:47:33 kanavin: too many AB failures :( Jan 14 10:24:01 RP: I will send a patch in a moment Jan 14 10:35:05 kanavin: thanks! Jan 14 10:56:18 RP: hope that's the last of them :-/ Jan 14 11:14:21 kanavin: we'll see! Jan 14 11:22:22 rburton: any thoughts on -next? Jan 14 11:23:23 * rburton looks Jan 14 11:24:18 drop the qemu/wic patch Jan 14 11:26:39 RP: apart from that, fine by me Jan 14 11:27:52 rburton: I already did! :) thanks Jan 14 11:32:54 reboot time bbiab Jan 14 12:00:33 Hi everyone! Jan 14 12:02:03 I'm trying to use the openssl1.1.0 recipe instead of openssl1.0.1 in Yocto Rocko, as consequence lots of packages that depend on openssl1.0.1 fail to build... Jan 14 12:03:09 Someone has experienced something similar? Is there a known patch to fix this (I haven't found it...)? Jan 14 12:19:17 malanecora: sadly openssl has botched the transition, 1.1 and 1.0 series are API incompatible Jan 14 12:20:01 malanecora: the easiest way is to upgrade to thud, where everything (at least in oe-core) has transitioned to 1.1, and should just work Jan 14 12:20:26 those are terribly bad news... :( Jan 14 12:21:00 why do you want 1.1.0? Jan 14 12:23:20 It's a system requirement, I'm not sure but maybe openjdk-8 has something to do here... Jan 14 12:23:57 I'm afraid some previous work could be lost "upgrading" to Thud Jan 14 12:24:41 you should upgrade continously, otherwise you'll end up in situations like this Jan 14 12:24:55 * cue expensive Yocto consultants Jan 14 12:25:03 Yes, now I know...haha Jan 14 12:25:12 oO( if you're afraid of losing worktime due to new versions, software development probably is not for you ) Jan 14 12:25:15 Jan 14 12:25:41 kanavin: cheap ones too? Jan 14 12:25:57 cheap Yocto consultants do not exist :) Jan 14 12:26:22 malanecora: i'd double check where the requirement actually is. you might be fine with 1.0 Jan 14 12:27:48 LetoThe2nd: I just came across with this project by "heritage" Jan 14 12:28:21 rburton: I will, thank you! Jan 14 12:28:28 malanecora: don't take me too seriously, i know most of the things how one ends up in those situations. Jan 14 12:35:19 LetoThe2nd: don't worry, I don't haha...I'll just check if changing from Rocko to Thud can lead to conflict or on the contrary it is just a straightforward step Jan 14 12:35:39 kanavin: btw, thank you too! Jan 14 12:35:59 Hi, how to I force bitbake to rebuild? I manually removed some cache dirs and the deploy dir, but 'bitbake -c cleanall' says there's nothing to do Jan 14 12:36:37 skynet: bitbake -c cleansstate Jan 14 12:36:43 skynet: "removed some cache dirs" sounds pretty fishy Jan 14 12:36:52 besides that, see kanavin :) Jan 14 12:37:42 skynet: easiest way is bitbake [recipe] -C unpack Jan 14 12:37:45 So long as isn't human_genome or something like that, skynet. Jan 14 12:37:46 ;-) Jan 14 12:38:48 using kanavin's hint it just says in the end: NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and all succeeded. Jan 14 12:39:02 tgoodwin: actually, i expect "skynet" to be capable of doing that Jan 14 12:39:20 skynet: cleansstate just cleans, you'll need to rebuild the recipe next. Jan 14 12:39:37 LetoThe2nd: sure it's capable (just please don't ...) Jan 14 12:40:52 LetoThe2nd: unfortunately T1000 is on vacation ;) Jan 14 12:42:57 For instance 'core-image-minimal' such a , right? Jan 14 12:45:27 skynet: thats an image recipe. it does not have any real own artifacts, so cleaning and rebuilding it will just reassemble whatever is already there. Jan 14 12:45:32 skynet: telling that to rebuild won't cause everything else to rebuild. Jan 14 12:45:48 Is there a "recommended" upgrading way? Or shall I just checkout the desired version branch/tag? Jan 14 12:46:12 malanecora: switch to the right branch, read release notes, make changes. Jan 14 12:46:36 skynet: so if you really want a total full rebuild, wipe your sstate and tmp Jan 14 12:46:46 What should I use for then? Jan 14 12:46:56 skynet: what do you want to rebuild? Jan 14 12:47:01 everything Jan 14 12:47:08 skynet: maybe you should start telling us what you *REALLY* want to do. Jan 14 12:48:06 if you want to force a clean build of everything, easy way is to delete tmp and sstate. that's very rare though. if this is for CI purposes (ie "do a clean build every night") then do the build with a new sstate dir. Jan 14 12:51:59 OK, First I had a standard yocto. I called "DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source fsl-setup-release.sh -b build-wayland" and after that "core-image-minimal". After that I added my own custom layer to yocto following https://dornerworks.com/blog/including-custom-executables-and-libraries-in-your-linux-image-with-yocto . After that I wanted to bitbake my new yocto but after both commands as mentioned in the beginning bitbake Jan 14 12:52:17 So I manually removed the cache dirs and deploy dirs. Jan 14 12:52:28 But bitbake still says there's nothing to do. Jan 14 12:53:25 maybe your layer jsut has no effect? Jan 14 12:54:02 The layer adds a helloworld.c and the recipe for it Jan 14 12:54:12 that guide is interesting but pretty complicated in some places, easy to get things wrong. Jan 14 12:54:22 well does that hello world thing compile? Jan 14 12:54:42 e.g. bitbake helloworld Jan 14 12:54:45 skynet: adding a layer doesn't add it to the image Jan 14 12:55:22 rburton: i suspect that the append is buggy or forgotten. and while that guide is interesting, imho it shows quite some really bad practises. Jan 14 12:56:08 Hmm, where can I find a simple newbie tutorial how to add a simple helloworld program to the yocto system in the right way? Jan 14 12:56:17 the official manual :) Jan 14 12:57:17 skynet: let me explain: that guide shows how to mangle source code into the metadata (bad) and appends a standard image (not exacly bad, but also not good) Jan 14 12:57:59 skynet: its way cleaner to create your own layer with a custom image recipe first, and add something that already exists. just to get into the modification workflow Jan 14 12:58:07 skynet: https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#usingpoky-extend-customimage Jan 14 12:58:16 hmm, OK, so it's not good to follow that dornerworks.com tutorial Jan 14 12:59:01 skynet: the tutorial is like googling the symptoms of a disease. frightening and misleading for standard people, but might be helpful for a medically trained person. Jan 14 12:59:19 skynet: it has some nice points that can be useful. but certainly not for a beginner. Jan 14 13:01:49 I'm having a look at chapter "3.2.1. Customizing Images Using local.conf" right now (following rburton's hint). Many questions appear :) First one: Where is that local.conf (in which directory)? Jan 14 13:02:00 build/conf Jan 14 13:04:01 Crofton: thank you Jan 14 13:04:22 skynet: by the way, thats 5. of the dornerworks tutorial. Jan 14 13:04:55 (so if you had actually read and followed it by the letter, you would'be known) Jan 14 13:05:52 local.conf is not mentioned at dornerworks Jan 14 13:07:18 ah yes. its bblayers.conf. my bad then for misreading. Jan 14 13:07:41 any tutorial for yocto that doesn't mention local.conf is misguided Jan 14 13:07:48 rburton: hrhr Jan 14 13:09:39 hello! whenever I modify a recipe with `devtool modify`, my new commit file gets a duplicate sequence number (0001-a.patch 0002-b.patch 0003-c.patch 0001-new_modification.patch). is this intended? how can I correct this? Jan 14 13:09:43 Chapter "3.2. Customizing Images" is written way more complicated than the dornerworks stuff. I don't get it reading it the second time... The good thing of the dornerworks is it just says mkdir this and edit that... but I don't want to complain... Jan 14 13:10:41 skynet: ? Jan 14 13:11:08 skynet: To add a package to your image using the local configuration file, use the IMAGE_INSTALL variable with the _append operator: Jan 14 13:11:11 IMAGE_INSTALL_append = " strace" Jan 14 13:11:28 ok, to help us improve - what is complicated here? Jan 14 13:11:39 (being serious!) Jan 14 13:17:11 LetoThe2nd: Well, to be fair Yocto itself is quite complicated at beginning! I guess he just has to get used to the system... Jan 14 13:18:11 well, after I have managed to run a standard yocto on my eval board, my next aim is to add a simple helloworld.c to the system for having that program on my eval board additionally. My feeling is it's just a couple of files and lines to be added in a few conf files. But scrolling through chapter 3.2 I don't see it clearly in a fast way. Jan 14 13:18:12 No doubt the docs are great though I cannot see the quick start. :) Jan 14 13:19:04 malanecora: not argueing that in the least. but claiming that a roughly 30 line paragraph is more complicated than a multipage how-to-create-your-own-layer-and-custom-compile-recipe is... surprising, to say the least. Jan 14 13:19:58 skynet: *sigh* because it does only *ONE* thing. it add the package "strace" to your image. we want to show you the necessary steps one by one. not all mangled together, like that "tutorial" does. Jan 14 13:21:34 let's release some tension by talking about my super simple problem: patch file sequence numbering. how can I re-number patches in a recipe? Jan 14 13:21:50 LetoThe2nd: touché...just saying haha Jan 14 13:21:55 * cengiz_io hides under desk Jan 14 13:21:57 malanecora: :-) Jan 14 13:24:17 skynet: once you understood how to add something to your image, you can proceed to creating a custom "something" that is added. thats how it usually is done. Jan 14 13:24:30 cengiz_io: no need to hide, probably just nobody knows. Jan 14 13:25:29 cengiz_io: while devtool is great for some usecases, it still has some rough corners. i wouldn't rule out a bug at all, so you might want to report it through bugzilla (or whatever we use these days) Jan 14 13:27:46 LetoThe2nd: I don't have the knowledge to decide whether it's a bug or not Jan 14 13:28:10 patch gets appended to tail of the SRC_URI but the number bugs me Jan 14 13:29:01 LetoThe2nd: oh wait. someone already asked it in lists: http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120629.html Jan 14 13:29:30 cengiz_io: :) Jan 14 13:39:05 Reading chapter 3.2.1: It says I should use a variable IMAGE_INSTALL_append. Well, but my local.conf does not contain a line whit that variable. What do the docs mean with "use"? Should I insert such line? The it tells it's possible to extend to IMAGE_INSTALL_append_pn-core-image-minimal. Should I do that now or not? You see, it's quite blurry... Jan 14 13:39:07 I actually need a concrete listing of commands and edit steps for copy'n'paste. Yes, it's good if it's explained what it means. But in the first run I don't want to read the explanation. I just want to use it for now. Jan 14 13:40:09 skynet: "i just want to use" is a good mindset for a doorhandle. for a distribution building system, less so. Jan 14 13:40:22 skynet: so yes, you just insert the line Jan 14 13:41:13 This is just my hint from the silly user's point of view ;-) No offending, just friendly meant. Sorry if it's too harsh Jan 14 13:41:33 skynet: i seriously suggest to work through the getting started documentation: https://www.yoctoproject.org/docs/2.6/brief-yoctoprojectqs/brief-yoctoprojectqs.html Jan 14 13:42:08 skynet: its written the way it is for a reason. after it, you'll have custom layer to add your stuff, and have a general idea of the local.conf file. Jan 14 13:42:15 Thanks for the links! I thing I have something to read now :-) Jan 14 13:42:35 (instead of a radnom bunch of "type this here" snippets, and no clue why they fail afterwards) Jan 14 13:43:18 * derRichard wonders why poky has -meta-*/ in .gitignore Jan 14 13:43:47 what is the use case? except that you don't see new files in layers? :( Jan 14 13:43:57 Well, the schedule wants us to benchmark by using some custom programs on the eval board in a short time. So it would be nice if I had such 'type this here' snippets ;) Jan 14 13:44:43 skynet: then tell the person that gave you the schedule that you don't have the required knowledge, and that you either need longer or somebody else has to do it. thats the real life Jan 14 13:45:41 no solution ;) I recommend quick start docs for adding plain custom programs instead of reading the full monty Jan 14 13:46:58 skynet: not meaning to be overly harsh either. but reaching out for a really complex product without prior knowledge means either invest time (yor own) or money (for a consultant). and expecting simple copy and paste instructions for exactly your case just is not going to work Jan 14 13:49:15 skynet: alternative option: install debian/ubuntu and just compile in-target Jan 14 13:49:28 skynet: way simpler for a one-of benchmark Jan 14 13:51:07 * skynet is ordering a round of free beer for the whole chat Jan 14 13:51:17 OK, thanks! Cheers and thanks Jan 14 13:51:46 cheers. Jan 14 13:51:50 * LetoThe2nd gets drunk on duty Jan 14 13:58:55 where are the files for kernel-dev specified? Jan 14 13:58:58 derRichard: yes, that. no chance to accidently commit new layers to poky. Jan 14 13:59:53 i've smart installed both kernel-dev and kernel-srcdev yet there seems to be files missing in /lib/module/..., e.g., the main module Makefile, which should bin in /lib/module/$(uname -r)/build Jan 14 14:00:18 s/should bin/should be/ Jan 14 14:00:46 in fact the entire build directory is missing Jan 14 14:00:58 and there is no Makefile at all under /lib/modules Jan 14 14:01:19 i'm trying to build a LKM on the target Jan 14 14:02:41 the kerne-dev package seems to lacking a lot of files: https://paste.fedoraproject.org/paste/FN6BfbFFsNTWizsDUU-Veg Jan 14 14:09:46 yates_home: easier to just make a recipe to build the module in bitbake? :) Jan 14 14:11:41 "easier" depends on your metric for "easy"... :) Jan 14 14:12:49 i'm in the first stage of development, so i'll probably be making lots of blunders and needing to rebuild 100 times a day. you really think bitbaking is faster in this scenario? Jan 14 14:13:12 yates_home: would be for me Jan 14 14:13:33 write the recipe once, not have to worry thereafter Jan 14 14:14:08 worry about what? i have to worry about the module src no matter which way i develop. Jan 14 14:14:34 especially if you have to reflash or upgrade something on the image, you'll accidentially lose your src at least once. Jan 14 14:14:37 speaking from experience. Jan 14 14:14:40 yates_home. was it you, or someone else that was also just asking this question about a week ago ? you want kernel-devsrc, not kernel-dev Jan 14 14:14:49 and then, you develop out of target :) Jan 14 14:14:52 yates_home: on-target building should work, and we test that on the ab, so i'd ask zeddii Jan 14 14:15:01 oh thanks zeddii :) Jan 14 14:15:09 yes it was me, and i've installed kernel-devsrc Jan 14 14:15:24 everything you need is definitely there. Jan 14 14:15:28 zero doubts about that. Jan 14 14:15:33 i still do not have the necessary Makefile, namely, /lib/modules/$(uname -r)/build/Makefile Jan 14 14:15:45 yates_home: it will get built the same way each time and installed in the image - not needing to worry about documenting that or doing it again Jan 14 14:16:24 yates_home, what release are you using ? Jan 14 14:16:29 LetoThe2nd: got that covered - the file is under source control Jan 14 14:16:39 zeddii: there's the rub: morty Jan 14 14:16:44 ah yes. Jan 14 14:16:49 that's the problem Jan 14 14:16:53 indeed Jan 14 14:16:59 the re-worked devsrc wasn't even a glimmer then. Jan 14 14:17:07 ha Jan 14 14:17:22 yates_home, the souce is under /usr/src/kernel, IIRC Jan 14 14:17:26 in that release. Jan 14 14:17:37 yes, i was just noticing the stuff there. Jan 14 14:17:53 make a symlink from the /lib/modules structure if you have Makefiles looking there. Jan 14 14:18:19 ok, let me crunch on that more. Jan 14 14:18:22 and you will need to do a "make ARCH= scripts" in that directory to get the reset of the build infrastructure re-created. Jan 14 14:18:31 s/reset/rest/ Jan 14 14:18:41 ok, good to know! Jan 14 14:19:19 thanks zeddii Jan 14 14:21:14 Hi all, I'm wondering about the difference between the docker containers provided by the crops-project - specifically crops/poky and crops/yocto - which one is recommended to use, and in the case of crops/yocto, should one use the -base or the -builder tags? Jan 14 14:25:25 YEAH, there was an image directory "build-wayland" in the yocto project root dir, it's in parallel to directory "downloads" and "sources". I removed that "build-wayland" and called again "bitbake core-image-minimal", and now it rebuilds everything. :-D Big jubilation here!! Jan 14 14:25:48 * skynet is ordering another round of free beer for the chat Jan 14 14:27:42 skynet: You do know that there are 240 people in here..? That is A LOT of beer you're buying... Jan 14 14:29:30 zeddii: is the ARCH i specify in the make command the result of the "arch" command (armv71 for my target)? Jan 14 14:30:16 jofr: the price of chat beer is cheap, just 4 bytes LOL Jan 14 14:30:54 or should it just be "arm"? that's the closest i see under the arch directory Jan 14 14:31:02 skynet: careful or we might now think we're worthless ;-) Jan 14 14:31:41 hehehe :) Jan 14 14:32:34 yates_home. yes. that should be it. Jan 14 14:32:58 * zeddii isn't sure how much mileage everything has running natively on an arm target Jan 14 15:04:07 yay patchbomb :) Jan 14 15:04:39 kanavin: not sure I dare look Jan 14 15:09:46 RP: you can read my msg to openembedded-architecture then :) Jan 14 15:13:02 rburton: ok, got the use case. Jan 14 15:17:45 success building my first "hello world" LKM on target! Jan 14 15:26:01 hi Jan 14 15:26:52 I'm writing a recipe for the monocypher library: https://monocypher.org/ Jan 14 15:27:12 Here it is: https://paste.ofcode.org/4fBx2ZjbVuzFp4dCcRrn6p Jan 14 15:27:34 but I get an error at do_package_qa: QA Issue: -dev package contains non-symlink .so: monocypher-dev path '/work/cortexa9hf-neon-poky-linux-gnueabi/monocypher/2.0.5-r0/packages-split/monocypher-dev/usr/lib/libmonocypher.so' [dev-elf] Jan 14 15:28:00 I disabled the package split Jan 14 15:28:05 kanavin: looks good :) I assume people can still select SDL? Jan 14 15:28:56 any idea how to solve this? Jan 14 15:30:28 RP: yes, of course! Jan 14 15:34:57 RP: also runqemu still defaults to non-gl variant with vmware vga driver Jan 14 15:44:05 ok I found that I need to add INSANE_SKIP_${PN}-dev = "dev-elf" Jan 14 15:45:14 kanavin: makes sense, thanks for confirming :) Jan 14 15:46:04 sometimes I see BitBake processing more than one recipe in one thread, with a + sign between them... like recipe_1+recipe_2... where can I find some info about that kind of behavior? Jan 14 15:46:06 didile: don't disable package split, fix the packaging Jan 14 15:46:55 rburton: how should I do that? Jan 14 15:50:21 didile: well why did you disable the package split? Jan 14 15:53:00 rburton: I disable -dbg and -doc packages actually Jan 14 15:53:18 rburton: because I don't need them Jan 14 15:55:37 rbuton: it saves a lot of compilation time Jan 14 15:56:14 that's not really anything to do with package splitting, that's just not building stuff Jan 14 15:58:07 the variables are INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and INHIBIT_PACKAGE_STRIP = "1" Jan 14 15:58:11 kanavin: boo to needing to build all of gtk+3-native :( Jan 14 15:58:48 didile: you do realise that just leave the debug symbols in the main package, so making them a lot larger Jan 14 16:00:48 rburton: I'm dreading to think of the performance implications :/ Jan 14 16:01:21 kanavin: dropping the gtk2 icon cache thing means that gtk2 and gtk3 can't coexist Jan 14 16:01:26 as they ship the same binary Jan 14 16:02:05 rburton: you mean INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and INHIBIT_PACKAGE_STRIP = "1" make the packages a lot bigger? Jan 14 16:02:11 yes Jan 14 16:02:40 I see Jan 14 16:02:41 you're not splitting out the debug symbols, so unless you've ensured they're not generated in the first place they'll be there still Jan 14 16:02:52 rburton: no I didn't know that Jan 14 16:03:26 Is there a way to bbappend a recipe that has its PV overridden by a different bbappend? For example, a_1.0.bb, a_%.bbappend (sets PV to 1.1), a_1.1.bbappend (results in "no recipes available") Jan 14 16:05:55 rburton: how could I remove the debug symbols instead? Jan 14 16:06:44 didile: don't pass -g to the compiler. For a small library the difference will be <1s. Jan 14 16:07:35 didile: why don't you just use the makefile provided? Jan 14 16:07:53 rburton: because it installs manpages too Jan 14 16:07:54 all your package splitting problems are because you're building it yourself instead of using the makefile Jan 14 16:08:22 so? they'll be in monocypher-doc and not installed unless you want them Jan 14 16:08:34 hm Jan 14 16:09:06 a lot of upstream makefiles are pretty dumb, but don't reinvent the wheel unless you've verified this Jan 14 16:09:11 I should package man pages with FILES_${PN˘ Jan 14 16:09:20 FILES_${PN}-doc? Jan 14 16:09:20 no need, default does the right thing. Jan 14 16:09:31 note that your hand-coded CC is building a library with the wrong name Jan 14 16:10:36 rburton: oe_runmake install DESTDIR=${D} gives me this error: https://paste.ofcode.org/AGvNGGrprkbGa36h3i8Rqn Jan 14 16:11:28 didile: look at the makefile to see what you need to set Jan 14 16:12:37 rburton: I only see DESTDIR to be empty Jan 14 16:13:06 makefile correctly defaults to PREFIX=usr/local Jan 14 16:13:21 but system packages install into $prefix, which is /usr Jan 14 16:13:31 so pass PREFIX=${prefix} in the recipe Jan 14 16:16:35 rburton: I removed the PACKAGE_SPLIT var so it's compiling a few things... Jan 14 16:23:26 rburton: it works fine :) Jan 14 16:24:02 rburton: the new recipe: https://paste.ofcode.org/5KbXqjX9SX2vXjwgakNacr Jan 14 16:44:18 Hi all, what is the good idea to apply a patch depending on the MACHINE type in a recipe ? Jan 14 16:44:44 prabhakarlad: use machine overrides to add to SRC_URI selectively Jan 14 16:48:24 kanavin: can you sling your qemu x11 patch to qemu-devel@nongnu.org Jan 14 16:48:37 iirc, you get moderated but not rejected Jan 14 16:48:42 (as a non-member) Jan 14 16:52:39 rburton: thank you :) Jan 14 16:54:10 * RP wonders why shell code is being fed to the python parser Jan 14 16:59:02 ah, its not, its inline python in shell. gah Jan 14 18:08:40 rburton: all of gtk+3-native is actually not that much, as many of the bits were already needed for g-i and qemu Jan 14 18:11:32 rburton: I guess we'll have to sort the conflict between gtk 2 and 3, but I can't honestly see the benefit of choosing between the two implementations of icon cache binary at this point Jan 14 18:18:17 well we need to rename one or both, but then themes need to call the binary, so surely alternatives is the way forwards (unless we universally drop gtk2 and then have the same problem with gtk4) Jan 14 18:31:19 rburton: yep, there theoretically could be a gtk2-only system I suppose Jan 14 18:32:49 in all other cases (gtk2+gtk3, gtk3 only) shipping the 3.x version of the utility should simply work without doing the alternatives thing Jan 14 18:33:47 I'll drop the patch, there was some reason I had to make it though Jan 14 18:36:09 If a layer is exposing a series of vendor-specific drivers for various hardware (and the vendor kernel), is that an appropriate use of adding MACHINE_FEATURES for each driver or is it more appropriate still to define specific machines? Jan 14 18:55:33 tgoodwin, public layer? Jan 14 18:56:06 tgoodwin: maybe its ok to do so Jan 14 19:07:27 RP: I looked at the result parser in runtime ptest and is very elaborate is supposed to do a simple thing, :/ Jan 14 19:16:28 Crofton: might become one, yes Jan 14 19:17:24 Where I'm tripping up is whether or not to set the default kernel parameters based a certain machine feature being set in a user's configuration, for example Jan 14 19:17:27 seems wrong Jan 14 19:40:35 alimon: so you better start working on it right away :) Jan 14 19:59:15 Is there a point in using uninative+yocto sstate while keeping up with master ? I'm using "http://sstate.yoctoproject.org/dev" but I never see any sstate reuse .. Jan 14 20:21:34 with master doesnt help much Jan 14 20:21:42 with release branches it might make sense Jan 14 20:22:56 ok Jan 14 20:32:12 alimon: I feel like that about a lot of oeqa :/ Jan 14 20:32:26 alimon: if it can be simplified I'm all for it Jan 14 20:34:27 New news from stackoverflow: Generating callstack from inside system call Jan 14 20:49:25 w00t?? did you replace the opkg-0.4.0 tarball with a real release one ?? checksum changed again and not autogen.sh is missing. guys, this is really bad Jan 14 20:53:27 on top of that, it refuses to build Jan 14 20:54:11 adelcast: ^^^ Jan 14 20:56:49 hey Piraty, you are talking about the binaries at http://downloads.yoctoproject.org/releases/opkg/? Jan 14 20:57:49 distfiles="https://downloads.yoctoproject.org/releases/opkg/opkg-${version}.tar.gz" Jan 14 20:58:54 yeah. saturday (for whatever reason) the checksum changed (from it's friday state) Jan 14 20:59:04 AFAIK, those binaries were only posted once, was there a delta of time where 2 different versions were uploaded? Jan 14 20:59:06 oh Jan 14 21:00:08 and i would swear to you they had an autogen.sh and now they don't Jan 14 21:01:00 I usually create the releases, and as part of my release process I run autogen.sh, then remove it (as well as other stuff, like .git, etc) Jan 14 21:01:33 so I am completely certain there has never been an autogen.sh on those tarballs Jan 14 21:02:54 ok lemme check, probably i screwed up and came yelling at you :-/ Jan 14 21:04:25 ok, lemme know if you still think there was an issue, I can check with yocto's IT contact to see if something changed on the backend Jan 14 21:05:27 so because you run autogen.sh already, i should not have to use autoconf or the other tools, that correct? Jan 14 21:06:14 correct Jan 14 21:06:45 hm Jan 14 21:07:17 https://privatebin.net/?1363b43c06c7c1e3#DqChCGpOPcawmMpxNTvm+LnNfnhcnfUgvDRgZwz4pV4= Jan 14 21:07:40 libtool wants me to run autoconf Jan 14 21:07:50 Piraty: 99% sure the tarball you originally had was actually a cgit generated archive Jan 14 21:08:07 you said the checksums matched, which wouldn't be the case for a cgit link vs the tarball adelcast built Jan 14 21:08:24 also, we'd have noticed if it changed, as the autobuilder would have warned Jan 14 21:08:56 i guess what happened, i changed the distfile string and it used the tarball from the cache, therefore there was autogen.sh present and when is switched machines, it had to download from the new mirror (which then was the real download.yocto...) Jan 14 21:09:04 my bad Jan 14 21:10:50 is it known that oe-init-build-env does not work with dash? Jan 14 21:11:12 I think so Jan 14 21:11:21 thanks rburton adelcast , and sorry for confusion Jan 14 21:11:21 (the default /bin/sh on ubuntu) Jan 14 21:12:21 just tracked this down on a ubuntu docker :-\ Jan 14 21:12:35 derRichard: it should, how was it failing? Or you mean the ability to specify the build directory? Jan 14 21:14:38 adelcast: what's this with your libtool version (see my attached faillog) Jan 14 21:14:44 2.4.6 is latest stable Jan 14 21:16:09 Piraty: libtool hasn't released in years which means people are using git snapshot versions Jan 14 21:17:36 RP: it fails to find the internal script: Can't open /scratch/rw/testing/new/scripts/oe-buildenv-internal Jan 14 21:18:02 but i passed the builddir as parameter Jan 14 21:18:04 let me try without Jan 14 21:18:46 nope, also wthout it fails Jan 14 21:19:33 derRichard: I thought it did work but dash is limited :/ Jan 14 21:19:42 it does on my setup Jan 14 21:20:08 debian 9 uses dash as well Jan 14 21:20:09 derRichard: does it help if you change to the directory first? Jan 14 21:20:28 kroon: but are you in a dash shell when starting the build? Jan 14 21:21:07 RP, doh. no, sorry Jan 14 21:21:11 * kroon shuts up Jan 14 21:21:21 RP: where should it change to? Jan 14 21:22:33 derRichard: I mean instead of "source /foo/bar/oe-init-build-env", "cd /foo/bar; source oe-init-env" Jan 14 21:22:59 na, it fails differently Jan 14 21:22:59 derRichard: You may already be doing that in which case ignore me Jan 14 21:23:03 http://paste.debian.net/plain/1060515 Jan 14 21:23:18 btw. dash has no "source" Jan 14 21:23:20 just "." Jan 14 21:23:25 try ./oe-init-build-env Jan 14 21:23:39 derRichard: I knew it didn't have one or the other, guessed wrong :) Jan 14 21:23:55 ./ also does not help, it cannot find oe-buildenv-internal Jan 14 21:24:04 no big deal here. i hate dash anyways with passion :) Jan 14 21:24:29 one of my docker scripts just used /bin/sh and ubuntu has brain dead defaults Jan 14 21:24:30 * RP isn't keen Jan 14 21:24:53 derRichard, you're not setting OEROOT in the env ? Jan 14 21:25:09 nope. should i? Jan 14 21:25:13 i never set it Jan 14 21:25:15 no Jan 14 21:25:27 but if I do, I get a similar error message Jan 14 21:25:32 yeah Jan 14 21:25:38 just checked, OEROOT is not set in my shell Jan 14 21:27:14 maybe we should just note in the manual that bash should be used? :-D Jan 14 21:28:38 i get the same error as well when run from dash Jan 14 21:28:56 good. at least it is not me :) Jan 14 21:28:58 maybe add sanity check in oe-init-build-env Jan 14 21:29:21 +1 Jan 14 21:30:27 that is surprisingly hard to do :/ Jan 14 21:30:56 or maybe oe-init-build-env is just has a bug that needs to be fixed.. Jan 14 21:31:37 RP: just check whether $BASH_VERSION is something sane? Jan 14 21:32:14 derRichard: then the people who use csh complain (and so on) Jan 14 21:32:30 I though dash worked.... there was a bugzilla for it that was assigned to me, I tested it, and closed.... Jan 14 21:32:31 *does* oe-init-build-env worth with csh? Jan 14 21:32:43 derRichard, does it work if you run it from the same dir ? Jan 14 21:32:48 no Jan 14 21:32:53 derRichard: I'm sure I remember patches but who knows Jan 14 21:33:03 derRichard, cause it does here Jan 14 21:33:11 interesting Jan 14 21:34:33 YOCTO #11775 Jan 14 21:34:43 IOW ". ./oe-init-build-env" does work on my debian 9 Jan 14 21:35:01 derRichard, we almost documented it years ago https://www.openembedded.org/wiki/OE-Core_Standalone_Setup Jan 14 21:35:06 ". openembedded-core/oe-init-build-env" does not, and I get a similar error message Jan 14 21:36:05 I always do cd /oe/oe core; . ./oe/init-build-env Jan 14 21:36:56 derRichard, you forgot the "." in your pastebin Jan 14 21:37:28 i mean the "./" as in ". ./oe-init-build-env" Jan 14 21:38:53 * derRichard hates dash even more Jan 14 21:38:57 thx Jan 14 21:39:28 dont think you can blame dash for that though Jan 14 21:39:53 thats because "." is not in your PATH Jan 14 21:40:35 i blame ubuntu for using not bash as /bin/sh Jan 14 21:41:23 derRichard, we try to avoid bashism in OE FWIW Jan 14 21:41:33 why? Jan 14 21:41:40 portability Jan 14 21:41:40 yocto runs on linux, nothing else Jan 14 21:43:19 yes, nut different linus distro hav edifferent shells Jan 14 21:43:39 derRichard: we do support running with /bin/sh pointing at dash Jan 14 21:43:48 derRichard: that is tested Jan 14 21:43:59 ant_home: which yocto supported distro does *not* ship bash? Jan 14 21:44:11 as default? Jan 14 21:44:15 yes Jan 14 21:44:17 derRichard: ubuntu defaults to /bin/sh as dash Jan 14 21:44:29 derRichard: and bash as the login shell Jan 14 21:44:32 but it has bash installed Jan 14 21:44:50 /bin/sh is still dash Jan 14 21:45:02 anyway, i don't care much. i have bash installed and all is good. just want to let you know :) Jan 14 21:45:08 RP: ideally we aim to purity :) moving towards musl libc to have POSIX complaince as well Jan 14 21:45:09 and we run bitbake's scripts under /bin/sh Jan 14 21:45:42 I added some comments to #11775 Jan 14 21:45:44 derRichard: I wish I didn't have to care ;-) Jan 14 21:45:46 * ant_home confeeses his install of OpenBSD Jan 14 21:48:24 RP: yocto depends on so many stuff, IMHO depending on bash does not hurt Jan 14 21:49:33 JPEW, ^^^ Jan 14 21:51:27 kroon: Hmm, interesting. I wasn't aware that sourcing it outside the directory it lives in was supported. I wonder if that is why the original bug was logged Jan 14 21:55:30 JPEW, yeah, well at least thats how I always do it (in bash, . openembedded-core/oe-init-build-env) Jan 14 22:03:40 derRichard: its not that simple sadly Jan 14 22:06:31 why? you depend even on python Jan 14 22:08:08 derRichard: we don't control many of the scripts we run which can call "/bin/sh". So either we start editing them to point at bash or we force people to change /bin/sh to point at bash, or we accept it can point at dash Jan 14 22:09:04 common source of confusion. folks often think the limitations are in bitbake/oe itself when it's really the underlying buildsystems we call into. much like the system default 'python' being 'python3' thing, until we addressed that in hosttools Jan 14 22:10:04 ok, makes sense Jan 14 22:14:21 is scons broken on sumo? Jan 14 22:14:22 PREFIX = os.path.normpath(sys.prefix).replace( os.getenv("BUILD_SYS"), os.getenv("HOST_SYS") ) Jan 14 22:14:25 TypeError: expected a string or other character buffer object Jan 14 22:14:34 it expects BUILD_SYS and HOST_SYS set Jan 14 22:14:51 if i add a "export BUILD_SYS", "export HOST_SYS" to the scons recipe, it builds fine Jan 14 22:15:00 there should be something setting those Jan 14 22:24:53 bitbake.conf does Jan 14 22:25:17 but in scons os.getenv("HOST_SYS") seems to return "None" Jan 14 22:29:01 derRichard: I think scons assumes you include one of the classes which exports then into the environment Jan 14 22:29:21 iirc one of the python bbclasses exports those Jan 14 22:30:06 RP: well the scons-native recipe itself fails to build... Jan 14 22:30:47 ./poky/meta/recipes-devtools/python/python-scons-native_3.0.1.bb to be correct Jan 14 22:31:46 derRichard: it just built for me with master... Jan 14 22:32:12 as i said, i'm on sumo Jan 14 22:32:38 on thud it also seems to build Jan 14 22:32:53 i did such a build yesterday Jan 14 22:32:59 derRichard: it could be a bug... Jan 14 22:33:22 yeah :) Jan 14 22:42:21 kergoth, in a .bb file, are all variable assignments parsed and overrides applied, before the "inherit" lines are acted upon ? Jan 14 22:42:51 depends on the version. recent versions apply overrides at expansion time rather than at the end of the parse when they used to be Jan 14 22:43:13 so now a variabler eference in an include/require/inherit line will be applied, but only the ones that exist at that point, not those set after that line Jan 14 22:48:34 kergoth, so include/require/inherit will "inline" the contents of the file, sort of like the C preprocessor and the "include" directive, and the argument to include/require/inherit will be expanded right there and then ? is that somewhat accurate ? Jan 14 22:48:48 essentially yes Jan 14 22:50:00 our lazy-ish variable expansion was inspired by gnu make, which is why they both have := to force immediate expansion Jan 14 22:50:28 kergoth, ok, thanks for clarifying Jan 14 22:51:33 was "-include" too ugly ? :-) **** ENDING LOGGING AT Tue Jan 15 02:59:58 2019