**** BEGIN LOGGING AT Thu Apr 04 02:59:57 2019 Apr 04 06:40:57 does u-boot support modifying configuration through *.cfg file, like SRC_URI += 'file://example.cfg' ? Apr 04 10:00:22 Hello, I'm still trying to do stuff I don't understand :) https://pastebin.com/T9wZWkx8 thankful for any tips Apr 04 11:04:02 willie2: Make a kernel- and u-boot recipes that pull in those repos, build them and they should provide virtual/kernel and virtual/bootloader (respectively) and then in your image or machine recipes, you should set those as your preferred provider for those packages (the "virtual" ones). Apr 04 11:05:37 It's actually quite likely that you could even bbappend to your existing u-boot and kernel recipes and just override the SRC Apr 04 11:07:31 (SRC_URI and SRCREV) Apr 04 11:24:21 jofr: thanks for your help, a implementation question, I'm I supposed to create a new u-boot? e.g recipes-bsp/u-boot/u-boot-custom.bb? Apr 04 11:31:50 marka, g-ir-scanner should not be executed for native recipes at all, if it is, then it's a bug somewhere Apr 04 11:32:20 which recipe is having the issue? Apr 04 11:36:44 psrcode: sorry to bother you, the lttng ptest timeout is causing us a few other problems. Is there a way I could easily fix/workaround it? Apr 04 11:37:14 alimon: happen to be around? I'm guessing you're travelling? Apr 04 11:55:22 willie2: Probably not.... Apr 04 11:55:35 willie2: First of all, you should never change anything in the upstream layers. Apr 04 11:56:05 willie2: I always create your own layer where you override stuff from upstream. Otherwise you're going to have a bad day at some point. Apr 04 11:56:11 jofr: In my own layer ofcourse Apr 04 11:57:07 So in your layer, you should be able to create a u-boot_.bbappend and then override the SRC* veriables Apr 04 11:57:13 variables* Apr 04 11:57:44 jofr: Now it looks like this https://pastebin.com/mVUdBqnU Apr 04 12:01:10 willie2: You have a couple of .bb's.. Sure there aren't some upstream recipes that you coulds .bbappend to instead? Apr 04 12:01:37 willie2: That you you're re-using the upstream code instead of duplicating it in your own repositoriy/layer Apr 04 12:01:55 willie2: That way you're* Apr 04 12:02:03 I can't type today! Apr 04 12:02:15 :D Apr 04 12:03:07 jofr: Well the qt application is custom and the scripts to take care of it, but i can probably use the poky/meta-recipes-bsp/u-boot. Since i think they based their custom u-boot on it Apr 04 12:04:53 hey guys! please help the stupid me :-) I want to get chromium on x11. I need X. Should asking for "xorg-server" and something like "xserver-nodm-init" suffice? DISTRO_FEATURES set Apr 04 12:06:26 any packagegroup with reasonable defaults? Apr 04 12:12:15 willie2: Cool. Apr 04 12:12:50 willie2: Are you over in Malmköping? Apr 04 12:13:28 jofr: :o Apr 04 12:14:11 jofr: I'm not but they guys I'm doing this for are. Do you know them? Apr 04 12:14:31 willie2: Don't think so... Apr 04 12:15:18 luneff: core-image-x11 is an example of a image that just boots X Apr 04 12:15:21 jofr: Then how did you figure that out? Apr 04 12:15:47 willie2: I just Googled Tjeders. And since (for some reason) our company ISP is in Sweden it favors swedish results or something :P Apr 04 12:16:35 rburton, thanks! It lists x11-base , will try Apr 04 12:16:51 jofr: Oh :) Well i work at Acte solutions! Apr 04 12:30:41 RP: I am looking into the timeouts just now, it seems as though ptest-runner is erroneously thinking the tests haven't printed anything for the default timeout of 5 minutes and killing them off, even though they are Apr 04 12:31:17 kanavin: hmm, a bug in ptest-runner then? Apr 04 12:32:01 kanavin: rburton and I think when a timeout happens, things are not getting killed properly so we have a patch testining on the AB now to see if that is part of the issue Apr 04 12:32:18 kanavin: I think your theory is worth following Apr 04 12:32:35 RP: possibly, I am in the 'staring at the code' phase now Apr 04 12:32:45 kanavin: that was my hunch this morning too but i was trying to stare at code whilst talking :) Apr 04 12:32:46 extra complication: the thing is written in C Apr 04 12:32:53 kanavin: fair enough. I suspect multiple issues in here Apr 04 12:33:31 kanavin: we do have alimon around who wrote/maintains it Apr 04 12:47:19 rburton, RP: it's a buffering issue in the pipe between ptest-runner and ptests Apr 04 12:47:44 yay kanavin Apr 04 12:47:53 tldr: "c is hard" Apr 04 12:47:55 ptest-runner receives the child's output in big buffered chunks, and timeouts if the buffer is slow to fill Apr 04 12:48:14 how big is big? Apr 04 12:48:15 willie2: I see! I'm in Denmark (Hillerød) - but I'm Icelandic myself. Are you across the water in Göteborg? Or over in Stockholm? Apr 04 12:48:19 my unix-fu is slightly rusty, I don't remember right away how to control that Apr 04 12:49:07 kanavin: oh the send buffer? Apr 04 12:52:06 no, the fd pair created via pipe2() and passed to the child Apr 04 12:52:48 kanavin: why would that buffer large amounts? Apr 04 12:53:34 RP: I have no idea, but run for instance openssh ptest directly, and then via 'ptest-runner openssh' and note the difference in how things get written to the terminal from the child tests Apr 04 12:53:40 RP: need to run to grab lunch! Apr 04 12:53:41 F_SETPIPE_SZ? Apr 04 12:54:03 jofr: cool! I'm from Stockholm :) Apr 04 12:54:13 must be buffering heavily if ptest-runner can actually timeout waiting for output Apr 04 12:54:37 rburton, kanavin: what doesn't happen in this code is the pipes don't get cleared after something is killed? Apr 04 12:54:51 and are reused between ptests? Apr 04 12:55:11 huh Apr 04 12:56:51 rburton: I think that means that stderr gets dumped only when something later writes to it again (such as the failing python3 ssl test) Apr 04 12:57:02 which would explain why its in the logs at the same place each time Apr 04 12:57:06 yes Apr 04 12:57:21 need to flush it out when bailing Apr 04 12:59:28 rburton: I'm puzzled why poll wouldn't say reading is possible sooner though Apr 04 13:00:29 Hi, I have a kernel image which is built with yocto and I can boot it from SD card. Now I copied it from SD card to the flash of the eval board, and try to boot from SD card. That fails. Why? Do I need to compile a kernel image of another type? If yes, where can I read that in the yocto docs? Apr 04 13:01:27 RP: seems like a safe thing to do would be to ensure that the pipes are flushed when timing out, and stop re-using them Apr 04 13:01:53 rburton: right, just not sure we fully understand why this is breaking Apr 04 13:03:26 fbre, how does it fail? Apr 04 13:09:48 jofr: I made a u-boot-imx_2016.04.bbappend that just adds SRC_URI +="git://my/local/repo. It builds but it is still using the old source. Apr 04 13:13:48 rburton: I think the problem is its not flushing output streams Apr 04 13:14:57 willie2: You need to either use = to replace it, or do a SRC_URI_remove first Apr 04 13:16:25 doesn't explain the timeout but would explain the logging Apr 04 13:27:46 rburton, kanavin: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b68875cfe44e63a4de5f2d2a728a207d6d02996f look sane? Apr 04 13:28:09 rburton: I know the second patch is yours, will fix that, just want to quickly test before a meeting Apr 04 13:31:54 RP: looks reasonable Apr 04 13:33:59 Crofton: If the SD card is plugged, it boots although the jumper pins are set to "boot from SPI NOR flash" and not from SD card. But if the SD card is not plugged into the eval board, simply nothing happens. The serial console doesn't show anything. Apr 04 13:39:55 RP: it reads from two decscriptors there, but you flush only when reading from the second one? Apr 04 13:41:03 fbre, what is the borad? Apr 04 13:49:38 ah, I found out now my mistake is to put the file "Image" (about 26MB) at address 0x0 of the flash of the board. But I should rather put the u-boot image to address 0x0, which is just about 60KB. Then that first stage u-boot loader loads the second stage u-boot loader which is about 600KB and that loads "Image" (which is the Linux kernel) as third step. Apr 04 13:50:16 Sorry, I have to understand the boot mechanism at first. Apr 04 13:52:02 My next question is to found out how I must change the yocto configuration in a way that the first stage u-boot should load the second-stage u-boot from SPI NOR flash instead of SD card. Apr 04 13:52:29 Do you know where I find that in the yocto files? Apr 04 13:58:40 I think, as I wrongly flashed the Linux kernel (file is called "Image"), it still boots with SD card plugged because booting from SD card is a fallback if booting from SPI NOR flash fails. Apr 04 14:06:19 I set IMAGE_FEATURES = "tools-profile tools-debug" in my image recipe just to see what nice tools that would give me, but the manifest remains unchanged. (The setting is at least not completely ignored, if I also add "foo" I get the expected error with the list of supported features) Apr 04 14:10:03 My u-boot image has the string "sd" in the filename. So I guess it's has built for SD card. I wonder what the magic yocto config file is to change the target device type to SPI NOR flash. Apr 04 14:14:22 fbre: I have not the slightest idea, because I have never built U-Boot in Yocto. But the first place I would search around is the environment of your recipe. You get it using "bitbake -e". If you search who sets the sd part you might find possible alternatives. Apr 04 14:15:40 fbre: most likely you need to adjust your UBOOT_CONFIG or UBOOT_MACHINE. you should examine the machine .conf for your machine. (conf/machine/${MACHINE}.conf) Apr 04 14:16:38 cool hints, thank you, guys! :-) Apr 04 14:17:24 kanavin: I need to explain that, basically I avoid it flushing stdout all the time, only when stderr is in action Apr 04 14:17:36 kanavin: stdout should be the common case Apr 04 14:17:40 (you'd hope) Apr 04 14:18:35 RP: I did my own testing, and only the stdout fd ever gets any input. Also flushing does not resolve the problem at all; it seems like we do read from the input buffer all that there is :( Apr 04 14:19:47 u1106: I think you must write the following instead: EXTRA_IMAGE_FEATURES_append += " tools-profile" Apr 04 14:20:12 kanavin: see the python3 test log output on the autobuilder, there is problematic output there on stderr afaict Apr 04 14:20:31 kanavin: I'm flushing the output buffer, not the input one Apr 04 14:21:43 RP: I am testing with just openssh for now, and what I am seeing doesn't make any sense :( I am flushing the output buffers as well, but the 'truncated output written in chunks' problem is still there, which means the problem is in the input buffer somehow Apr 04 14:22:25 u1106: I put that in an extra file, say my.conf and then build yocto with: bitbake core-image-minimal --read=my.conf Apr 04 14:23:14 kanavin: I think we're looking at different problems Apr 04 14:23:21 u1106: but you can also put it in your conf/local.conf Apr 04 14:23:26 kanavin: is it just at the end of the tests? Apr 04 14:23:53 nope, in the middle of them too Apr 04 14:25:05 if (pfds[0].revents != 0) { Apr 04 14:25:05 while ((n = read(fds[0], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) Apr 04 14:25:05 - fwrite(buf, n, 1, fps[0]); Apr 04 14:25:05 + fwrite(buf, n, 1, fps[0]); fwrite("hallo", 5 ,1 ,fps[0]); fflush(fps[0]); Apr 04 14:25:09 fbre: hmm, I think _append is always written with a "=" not with a "+=". Not sure whether the "+" would harm. The manual says IMAGE_FEATURES belongs into the recipe, not into conf https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html#usingpoky-extend-customimage-imagefeatures Apr 04 14:25:18 and same for fps[1] Apr 04 14:26:45 rburton: your patch seems dangerous as I think it caused the runner to commit suicide :/ Apr 04 14:27:39 rburton: loads of ptests not in the output and it didn't run for as long Apr 04 14:27:59 rburton: only took an hour instead of three Apr 04 14:28:45 u1106: I'm pretty sure it's the way as I suggest to you. Because I also installed that package tools-profile Apr 04 14:29:47 Ok, I'll try. Maybe the code has not read the manual ;) Apr 04 14:29:59 rburton: small flaw in the patch, how does group in he child make it to the parent? :) Apr 04 14:30:19 u1106: at least that works for me ;) Apr 04 14:30:22 rburton: needs to be -child Apr 04 14:31:20 RP: rburton: the gobject-introspection issue was a transient issue related to the fact I was pulling my build forward Apr 04 14:32:38 u1106: you can also do this magic in your local.conf file: CORE_IMAGE_EXTRA_INSTALL_append ?= "perf procps" Apr 04 14:32:42 once I started to dig, pulling some commits off and doing more builds caused it to no longer be reproducible Apr 04 14:33:20 u1106: the names I use are just examples of packages. You can use your own packages instead. Apr 04 14:33:57 I tried to reproduce the transient issue, pulling off several hundred commits and stepping forward, doing builds as I go. Unfortunately no joy. Apr 04 14:35:13 at any rate, no need to make any adjustments to the use of the scanner cache for the -native builds. nothing to see here. Apr 04 14:38:07 fbre: sure I can install packages I know of / come to my mind and I have several already. I was just curious what "tools-profile" would provide, I could not find the list of dependencies in the source so I just tried to build it. But that seemed to confirm my reading of the source that there is nothing... Apr 04 14:38:25 the only outcome is a reminder I need to do more fresh builds before digging into a build failure Apr 04 14:43:03 u1106: "tools-profile" contains all the kernel debugging Gedöns like trace-cmd and perf and so on Apr 04 14:43:44 u1106: for profiling of the Linux kernel, and tracing and stuff Apr 04 14:44:03 u1106: I don't know a command to show the content of a package either Apr 04 14:46:34 u1106: https://layers.openembedded.org/layerindex/recipe/80780/ Apr 04 14:46:48 fbre: oe-pkg-util does that, but an IMAGE_FEATURE is not a package Apr 04 14:47:50 fbre: right that packagegroup I also saw in the source. But why doesn't it get built and installed here? Apr 04 14:48:43 u1106: not with my suggested lines either? Apr 04 14:49:56 fbre: haven't been able to try yet, I have a "more important" build running Apr 04 15:04:08 fbre: s/oe-pkg-util/oe-pkgdata-util/ (Just noted when working on higher priority item that bash completed a bit differently than what I had typed in irc) Apr 04 15:07:29 u1106: I have here: CORE_IMAGE_EXTRA_INSTALL_append ?= "opkg" and EXTRA_IMAGE_FEATURES ?= "package-management" and PACKAGE_CLASSES = "package_ipk" Apr 04 15:08:15 u1106: just to have the opkg stuff available Apr 04 15:10:17 fbre: Thanks for your help for now, I need to return to this later, need to get some merge done in the next 50 minutes... Apr 04 15:11:01 yo, I'm also almost on my way home :) See yeah Apr 04 15:43:15 kanavin: I'm wondering if you broke python3 relocation :/ Apr 04 15:43:30 kanavin: (http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/python/?id=e2c3247c233876ab090c9ce3d5325a6d46ab350f removed the create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} PYTHONHOME='${prefix}' TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo' PYTHONNOUSERSITE='1') Apr 04 15:44:10 jae1: I think we need to add that bit back to the python3 recipe, then update as we discussed on #13208 Apr 04 15:45:10 RP: could well be. I didn't add many bits of the'old stuff' Apr 04 15:45:33 RP: on the other hand, I made progress with the ptest buffering issue Apr 04 15:45:51 kanavin: I'm curious what you found? Apr 04 15:46:04 rburton: btw, in triage you got the python ptest issues, I took strace and lttng Apr 04 15:46:24 RP: https://lists.yoctoproject.org/pipermail/yocto/2019-April/044722.html Apr 04 15:46:36 how to perform 'if NOT env exists ${var}' in hush shell for u-boot Apr 04 15:46:53 I just tested this, and with the patch, the output is received as at happens Apr 04 15:46:58 *as it happens Apr 04 15:47:19 (patch is erroneous, it adds some debug stuff, only the 'stdbuf' chunk is important) Apr 04 15:49:57 kanavin: can we call setlinebuf() on the fd directly rather than need coreutils? Apr 04 15:50:28 kanavin: good find though! Apr 04 15:51:32 kanavin: https://linux.die.net/man/3/setlinebuf Apr 04 15:51:37 RP: I think we can't - we operate on file descriptors, and setlinebuf operates on FILE* Apr 04 15:51:59 I do wonder what magic stdbuf does though Apr 04 15:52:05 I might go and read its source code Apr 04 15:53:41 kanavin: I was just thinking that... Apr 04 15:54:04 kanavin: sounds like wrappers around setvbuf Apr 04 15:55:04 kanavin: unless the intermediate process is now doing the buffering :/ Apr 04 15:57:29 RP: yes, a LD_PRELOAD hack Apr 04 16:15:17 Hi, is this the right place to ask about bitbake? Apr 04 16:19:22 yes Apr 04 16:21:26 ok. I'm wondering if it's possible to create a recipe or bbappend file which would remove building a certain recipe, but still keeps building its dependencies? Apr 04 16:21:57 So if A depends on B, i want to write an A.bbappend which would stop A from building, but keeps building B Apr 04 16:22:33 replace A.bbappend with any mechanism that could achieve that Apr 04 16:23:38 New news from stackoverflow: CMake could not find Perl Apr 04 16:23:57 alcroito, create a new recipe that would have exactly same list of dependencies as A Apr 04 16:24:11 what is the use case? Apr 04 16:28:10 hey guys! has anyone tried installing Google Chrome Market plugins into a Yocto build? I think integrating h264ify from the beginning is a good idea :-) Apr 04 16:37:34 kanavin that works if you have one package, but if i have a whole tree of packages, copy pasting isn't feasible. The use case is to get an sdk with a sysroot with all dependencies, without the actual packages Apr 04 16:37:56 to be more precise, i'm trying to get a sysroot of all dependencies of qt, without actually building qt Apr 04 16:49:02 alcroito: dare i ask why? Apr 04 16:49:32 rburton yes, i'm working on the cmake qt port (build qt with cmake), and i want a sysroot with qt dependencies Apr 04 16:49:49 *sysroot* or sdk Apr 04 16:49:59 sysroot, but that's provided by the sdk Apr 04 16:50:33 why not just add qt to the sdk and ignore the fact that qt is in it? Apr 04 16:51:26 because adding a new dependency recipe or modifying an existing one forces rebuilding whole of qt, and that takes too long Apr 04 16:51:38 hence my desire to get rid of the qt building part Apr 04 16:51:45 fine, just copy the dependency list Apr 04 16:52:12 Like i said, it's not entirely feasible if they are chosen dynamically from multiple recipes and bbapends Apr 04 16:52:52 bitbake qt -e |grep DEPENDS= Apr 04 16:52:55 there's the list Apr 04 16:54:49 ok, that's a step in the direction that I needed. but that's dependencies for only one qt package, i'd have to do it multiple times for each module Apr 04 16:55:36 yes Apr 04 16:57:15 But coming back to the original question, it is not possible to dynamically alter which recipes should NOT be built, and to also get the dependencies of those recipes? Apr 04 16:59:36 i guess you could use a bbappend to delete qt's do_compile do_configure do_install etc etc Apr 04 16:59:46 RP: even after fixing the buffering, 5 minutes timeout seems genuinely too short for some of tests in python3 and lttng-tools Apr 04 17:00:06 RP: I am now re-running them outside of ptest-runner to determine just how much time they need Apr 04 17:00:10 rburton: ^^^ Apr 04 17:02:33 kanavin: are you sure some of these aren't hangs? tests taking longer than 5 mins seems bad :/ Apr 04 17:02:46 OT, but ha, https://github.com/sdushantha/macbook-keyboard-visualizer Apr 04 17:02:46 kanavin: I know the lttng issue has a fix upstream Apr 04 17:03:00 i assume do_compile, etc are tasks. Would it be possible to remove the tasks from a single location for multiple recipes, instead of doing it in multiple bbappend files? Apr 04 17:03:56 alcroito, just wondering what CPU and how much RAM do you have? Apr 04 17:04:19 some 4c / 8th intel cpu, 32g ram Apr 04 17:04:58 alcroito, you might find that getting a 32 core threadripper might be cheaper than the time you lose fighting with this, and then building stuff on a low-core machine Apr 04 17:05:58 heh, perhaps. Apr 04 17:06:08 But I'm stubborn like that Apr 04 17:06:19 and rumours are, a 64 core one is coming this year Apr 04 17:08:31 even with 64 cores, rebuilding qtwebengine takes about the same time as building world with oe-core :/ Apr 04 17:09:16 kanavin: stdbuf is horrible :/ Apr 04 17:09:54 RP: alternatively, we might just raise ptest-runner's timeout from five minutes Apr 04 17:11:01 kanavin: the buffers should flush at 4k max. I wonder if pipe size is being a factor here Apr 04 17:11:11 kanavin: I'll ponder while I go for food Apr 04 17:11:31 RP: openssh definitely is not a hang, it completes fine here with the stdbuf fix applied Apr 04 17:11:54 RP: running python3 now to see which of its tests take long and whether it genuinely hangs Apr 04 17:12:21 kanavin: I suspect lttng genuinely does hang fwiw, I suspect the others dont Apr 04 17:13:01 RP: right, then I won't run that. python3's httplib test does seem stuck, I'll probably head home then. Apr 04 17:32:00 ok a different question, is it possible to create a unified sysroot that can be sourced via the setup environment shell script, without creating an sdk? Apr 04 17:37:30 that's basically the definition of an sdk already, just not zipped/tarred up Apr 04 17:40:28 yes, but from what i've seen the paths in the "environment-setup-cortexa9hf-neon-poky-linux-gnueabi" bash script expect the sysroot to be installed in a specific location, so it doesn't seem relocatable Apr 04 17:40:46 sdk installation runs relocation scripts which fix this Apr 04 17:41:03 which means it won't work without installation Apr 04 17:41:14 if those scripts aren't run, the sysroot won't be usable, as even if you deal with library relocation (i.e. $ORIGIN in rpath) that won't fix relocation issues in scripts (sed replacement) or dynamic linker (ld-linux.so.2) Apr 04 17:41:24 no sysroot with binaries you want to *run* will work without relocation Apr 04 17:41:26 sdk or not Apr 04 17:41:45 if it's just libraries and headers, it's fine Apr 04 17:41:47 for running, of course, but i'm only concerned with build Apr 04 17:41:52 and you can change how the sdk is packaged Apr 04 17:41:58 then it's irrelevent Apr 04 17:42:15 is your only concern the hardcoded paths in environment-setup? Apr 04 17:42:24 ys Apr 04 17:42:26 yes* Apr 04 17:42:55 that can be trivially worked around, if you can assume a certain amount of sanity in the user's shell Apr 04 17:43:17 Could you elaborate? Apr 04 17:43:28 alcroito: https://github.com/MentorEmbedded/meta-mentor/blob/cf21e7507fc9469c3185d360461697ad5d8af315/meta-mentor-staging/recipes-core/meta/meta-environment.bbappend Apr 04 17:43:36 that does it Apr 04 17:44:13 there's no *standard* method to determine the path of the script being sourced Apr 04 17:44:19 i.e. posix doesn't define it Apr 04 17:44:31 but bash and zsh have their own methods, and some other shells will set $0, though not all Apr 04 17:44:48 hence the comment about user shell sanity Apr 04 17:44:56 that append just addresses it for bash and zsh, the most common ones Apr 04 17:46:19 So the script essentially determines the location of the current environment dir name, and uses sed to replace the hardcoded paths with the determined location? Apr 04 17:46:28 i think a combination of this append and customizing how the sdk is packaged (set SDK_PACKAGING_FUNC) should address your issue Apr 04 17:46:54 it determines the location of itself (environment-setup) and assumes that's the root of the sdk and substitutes it, yes Apr 04 17:47:10 ok, i'll have to give it a go, thanks! Apr 04 17:47:14 np, good luck with it Apr 04 17:47:24 i should probably submit that append upstream at some point Apr 04 17:47:30 slightly less work for the relocation scripts Apr 04 19:09:58 RP: quick question on how the autobuilder work, does it ssh into the system and run ptest etc or does it uses the a tty/console redirection? I'm asking because I'm having trouble running the ptest for lttng-tools via runqemu nographic (when a lot of output is happening fast) but no problem when sshing into the system an running the ptest that way. Might be a problem in ptest-runner ... Apr 04 19:10:45 it is most probably a problem in ptest-runner since I can execute the test manually and everything works fine Apr 04 19:38:37 psrcode: it runs it via ssh Apr 04 19:39:16 psrcode: is it an emulation speed issue with the console in runqemu? Apr 04 19:39:32 okai Apr 04 19:40:02 tbh i'm not sure, it's a musl build and I can't get gdb to run neither gdbserver... Apr 04 19:40:17 psrcode: we're having a few problems with ptest-runner's i/o :/ Apr 04 19:40:24 psrcode: ah, there was a thread about this somewhere Apr 04 19:40:45 I would assume no since I can run the same test fine manually Apr 04 19:41:45 psrcode: https://lists.yoctoproject.org/pipermail/yocto/2019-April/044720.html Apr 04 19:41:55 psrcode: we're wondering if pie is broken on musl Apr 04 19:45:25 arf Apr 04 19:46:48 psrcode: I'd love to not have ptest hanging in lttng if you have any idea how to just fix that piece! :) (or point me at how to fix it) Apr 04 19:47:19 well I was about to send you the patches but stumbled upon this... Apr 04 19:47:59 i'll do a last checkup with ptest under ssh Apr 04 19:51:24 about PIE/musl, i'll be a bit bitter, but it wouldn't be the first time musl is *broken*. sorry khem. We have a saying here at efficios: "musl the poor's man glibc" Apr 04 19:55:55 psrcode: it does sometimes have some challenges... ;-) Apr 04 20:09:38 anyone have anything to start off https://wiki.yoctoproject.org/wiki/FutureMigrationGuide ? Apr 04 20:09:44 RP: rburton: ^ Apr 04 20:09:56 khem also ^ Apr 04 20:10:31 bluelightning: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=warrior-next&id=26d27d6a79fb336e9a47611698306da15e98fe8b ? Apr 04 20:10:37 bluelightning: planning to merge that Apr 04 20:10:43 RP: ok, thanks Apr 04 20:10:49 * RP hopes nobody cares/notices Apr 04 20:10:58 naturally I will be doing my usual commit trawl but advance pointers/raw material is helpful :) Apr 04 20:11:15 bluelightning: gcc-cross-initial and glibc-initial removal Apr 04 20:11:21 again, hopefully most don't notice/care Apr 04 20:11:42 right, worth noting though Apr 04 20:11:53 change to use perl-cross ? Apr 04 20:13:18 RP: gcc-cross-initial and glibc-initial removal was most noticible when restoring gcc-7 recipes for warrior, but even there it was easy to follow what gcc-8 recipes did Apr 04 20:13:54 JaMa: right, I don't think there was anything gcc8 specific in what we did. Should have done it years ago :/ Apr 04 20:14:55 bluelightning: please mention ARM tune changes, but with the ongoing discussion now on the ML I'm not sure what the summary should say Apr 04 20:16:37 JaMa: ok, I've short-noted it for now and hopefully the dust will settle before the release and then we can document it properly Apr 04 20:17:09 RP: hmm, does the perl-cross change have any possibly user-visible fallout? Apr 04 20:24:44 interesting... I'd missed that python 3.4 introduced enum support Apr 04 20:28:43 bluelightning: just that it changed the perl build a lot and there may be sideeffects from it Apr 04 20:29:09 JaMa, bluelightning: I have no plans to change the tunes for 2.7 Apr 04 20:45:33 kanavin: I think we might be able to just add -u to the sed command in the openssh ptest runner Apr 04 20:47:07 RP: understood, I was thinking about thumb enabled by default (so that people aren't surprised that TUNE_PKGARCHs are now different and binary feeds broken, but it's already from thud, not new in warrior, sorry for noise Apr 04 20:48:10 RP: and the new changes might be hard to describe in release notes as there isn't good agreement if the change was for better or worse and what the tunes actually should do Apr 04 20:48:58 JaMa: right, those patches are 2.8 discussion and I'm still not convinced its the right thing to do. I need to reply to that thread Apr 04 20:49:13 105 build jobs in queue, time to take a nap :) Apr 04 20:49:17 gnite Apr 04 20:49:23 JaMa: 'night! Apr 04 21:51:53 RP: let me know how it goes: http://lists.openembedded.org/pipermail/openembedded-core/2019-April/280909.html Apr 04 21:52:29 psrcode: was just reading those and about to queue some tests, thanks! Apr 04 21:54:04 psrcode: just fired a build with those in... Apr 05 02:29:23 psrcode: have you root caused it to be a musl problem ? Apr 05 02:29:49 RP: I sent a libgcc fix which we need on warrior and master both Apr 05 02:30:24 RP:https://patchwork.openembedded.org/patch/160125/ Apr 05 02:31:00 bluelightning: good idea, I will look into it Apr 05 02:32:42 psrcode: musl has shown the mirror to many apps to get their act together, tonnes of patches have landed into different apps, about correctness and portability Apr 05 02:33:51 PIE issues are hardly musl related, if you will debug them they are due to wrong assumptions Apr 05 02:34:05 in app code or gcc itself **** ENDING LOGGING AT Fri Apr 05 02:59:57 2019