**** BEGIN LOGGING AT Thu Feb 28 02:59:57 2019 Feb 28 03:28:10 yes Feb 28 03:28:21 bitbake Feb 28 03:28:33 will build 1 or more output packages Feb 28 06:00:04 New news from stackoverflow: How to add a missing library (or executable or other file) to Yocto/bitbake Feb 28 06:38:51 Hi, how do I open a port in Yocto Feb 28 06:39:12 I tried my TCP/IP code but it doesn't work..it says connection refused Feb 28 06:39:18 which probably I need to open the port Feb 28 07:30:21 New news from stackoverflow: Compiling module using SDK throws warning message: libelf-dev not found Feb 28 07:53:34 khem: nice whe you can get something to reproduce! :) Feb 28 09:31:13 Don't suppose anyone can read gdb python backtraces? https://bugzilla.yoctoproject.org/show_bug.cgi?id=13209 is odd :/ Feb 28 09:31:14 Bug 13209: normal, Undecided, ---, richard.purdie, NEW , wic hangs causing oe-selftest failures Feb 28 10:22:18 Hi it's my first time here. Is there anyone online? Feb 28 10:23:41 SimoneNascivera: maybe ;-) Feb 28 10:24:34 Hi @ronybeck Feb 28 10:24:46 I'm using Yocto for the first time Feb 28 10:24:59 SimoneNascivera: Condolences :P Feb 28 10:25:09 :) Feb 28 10:25:28 And I cannot even build the quick start example properly Feb 28 10:25:46 I am also quite new to Yocto. Can't say I am enjoying it yet. Lots to learn. Feb 28 10:26:49 This is the error I'm getting: Feb 28 10:26:50 ERROR: gcc-cross-initial-i586-8.2.0-r0 do_populate_sysroot: Fatal errors occurred in subprocesses: Feb 28 10:26:50 Command '['strip', '--remove-section=.comment', '--remove-section=.note', '/media/simone/651173DD28B986DD/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-i586/8.2.0-r0/sysroot-destdir/media/simone/651173DD28B986DD/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-i586/8.2.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux.gcc-cross-initial-i586/i586-poky-linux-gcov-dump']' returned non-zero exit status 1: Traceback (most recent call last): Feb 28 10:26:50 File "/media/simone/651173DD28B986DD/poky/meta/lib/oe/utils.py", line 272, in run Feb 28 10:26:51 ret = self._target(*self._args, **self._kwargs) Feb 28 10:26:53 File "/media/simone/651173DD28B986DD/poky/meta/lib/oe/package.py", line 44, in runstrip Feb 28 10:26:55 output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT) Feb 28 10:26:57 File "/usr/lib/python3.5/subprocess.py", line 626, in check_output Feb 28 10:26:59 **kwargs).stdout Feb 28 10:27:01 File "/usr/lib/python3.5/subprocess.py", line 708, in run Feb 28 10:27:03 output=stdout, stderr=stderr) Feb 28 10:27:05 subprocess.CalledProcessError: Command '['strip', '--remove-section=.comment', '--remove-section=.note', '/media/simone/651173DD28B986DD/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-i586/8.2.0-r0/sysroot-destdir/media/simone/651173DD28B986DD/poky/build/tmp/work/x86_64-linux/gcc-cross-initial-i586/8.2.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux.gcc-cross-initial-i586/i586-poky-linux-gcov-dump']' returned non-zero exit status 1 Feb 28 10:27:31 I image that it's due to trying to strip an executable that shouldn't be stripped Feb 28 10:27:57 But even if I add INHIBIT_PACKAGE_DEBUG_SPLIT = "1" at the end of local.conf nothing change Feb 28 10:29:33 Could someone please help me with this issue? As mentioned, I cannot even build the example ;( Feb 28 10:31:07 SimoneNascivera: please use pastebin Feb 28 10:31:30 I'm sorry. Doing it now Feb 28 10:31:59 https://pastebin.com/G0xac77L Feb 28 10:32:20 SimoneNascivera: that isn't on windows is it? Feb 28 10:32:42 No it's on Ubuntu 16.04 Feb 28 10:33:31 SimoneNascivera: if you try and manually run that strip command, what does it say? Feb 28 10:33:48 SimoneNascivera: we really need the real error here to know why its not working Feb 28 10:35:05 https://pastebin.com/UiawZxr5 Feb 28 10:35:14 It gives this error Feb 28 10:36:33 SimoneNascivera: That is very odd. Its as if strip from your host isn't working properly, or that binary is somehow damaged Feb 28 10:36:56 SimoneNascivera: We have an Ubuntu 16.04 worker in our autobuilder so we test it which makes this all the more odd Feb 28 10:37:18 SimoneNascivera: How clean is the Ubuntu install? is it the standard toolchain Feb 28 10:38:21 RP: It's not a fresh Ubuntu install, since I use to work but it should be the standard toolchain Feb 28 10:39:25 SimoneNascivera: can you share that 586-poky-linux-gcov-dump binary? I can try strip on it here, see what happens Feb 28 10:39:33 Is there anything I should check in order to know if the toolchain I'm using is the standard one? Feb 28 10:39:43 Of course Feb 28 10:39:50 SimoneNascivera: what does strip --version say? Feb 28 10:40:13 GNU strip (GNU Binutils for Ubuntu) 2.26.1 Feb 28 10:40:40 and our autobuilder shows "GNU strip (GNU Binutils for Ubuntu) 2.26.1" Feb 28 10:40:50 so that seems to match Feb 28 10:44:21 https://www.dropbox.com/s/cwi1tak5j9gtbxj/i586-poky-linux-gcov-dump?dl=0 Feb 28 10:44:42 This is the exec Feb 28 10:44:59 SimoneNascivera: fails here the same way so the binary is corrupt Feb 28 10:45:26 RP: Uh interesting Feb 28 10:45:52 RP: I've done at least 3 clean build so I really don't know that to do Feb 28 10:48:01 RP: Could you please upload your i586-poky-linux-gcov-dump and then I try to substitute my old with with it and restart the build process? Feb 28 10:49:37 RP: does file say the binary is a elf? Feb 28 10:50:19 SimoneNascivera: I suspect something called uninative so I'd try disabling that, Feb 28 10:51:10 rburton_: yes, file reports nothing unusual Feb 28 10:52:39 SimoneNascivera: alongside the conf directory containing local.conf, create a classes directory and "touch uninative.bbclass" there to create an empty file classes/uninative.bbclass Feb 28 10:52:50 SimoneNascivera: try a clean build with that, see if that works Feb 28 10:54:17 RP: Ok thank you. I'm starting a clean build right now. As soon as I'll have news, I'll post them here Feb 28 10:57:05 SimoneNascivera: it is very odd as we do test that OS :/ Feb 28 11:00:30 RP: Should I create the folder in poky/build/classes? Feb 28 11:08:55 SimoneNascivera: yes, poky/build/classes/uninative.bbclass Feb 28 11:09:39 RP: Perfect, I just started the minimal build. I'll post here if I receive the same error Feb 28 11:10:08 SimoneNascivera: It might hopefully either rule out a whole set of code, or point at it... Feb 28 11:11:13 RP: okok Feb 28 11:26:40 Hi kergoth, I'm looking at meta-sourcery but I have a hard time determining what the necesarry work is just to compile the root fs with the external toolchain (so no sdk generation, or any additional stuff) Feb 28 11:27:20 kergoth: I was looking at glibc-sourcery.bb Feb 28 11:43:41 RP: do I need to fix up qemu split issues, or are you on it? Feb 28 11:44:15 kanavin: there is a fixup patch in next Feb 28 11:44:37 kanavin: need to sort missing maintainer. Trying to figure out this selftest failure first Feb 28 11:45:09 RP: yeah, I think it's better to move the missing binaries into qemu-native for image conversion purposes. They don't need gtk or sdl, so logically belong there. Feb 28 11:45:23 and then no recipe fixup should be needed Feb 28 11:46:30 kanavin: I can see it two ways. Dependency wise it make sense. You'd only do image conversion with system qemu though :) Feb 28 11:52:59 RP: not sure I understand the last sentence? to me, 'qemu-system-native' is 'full system emulators', so things like qemu-img (image manipulation utility) belong in the base qemu-native Feb 28 11:58:06 I don't insist though :) Feb 28 11:59:37 kanavin: the output of qemu-img is only useful with the system emulator binaries Feb 28 12:00:05 kanavin: I don't have a hard preference, just pointing out its only useful with system binaries, not the user ones Feb 28 12:00:37 RP: sure, if you're further along with fixing the failures, let's just proceed that way Feb 28 12:01:03 kanavin: the patch on the autobuilder fixes everything other than the missing maintainers Feb 28 12:02:59 RP: great! I guess that should be trivial to fix? :) Feb 28 12:03:52 Hello, I'm unable to build my custom recipe https://pastebin.com/xw1mk9J7 and I think its related to me not using the "build" variables correctly, can anyone point out any obvious errors Feb 28 12:04:19 I can see that my application is built under /tmp/work..../ked-project but It is not getting deployed Feb 28 12:05:44 willie, what build system is your project using? qmake? Feb 28 12:05:56 why are you including qt5.inc? Feb 28 12:06:13 if it's qmake, then inherit qmake should be good Feb 28 12:06:36 it is an qt application based on qmake Feb 28 12:06:56 remove the require of qt5 and all of do_install, just inherit qmake Feb 28 12:06:57 I have looked at examples from meta-qt and they inclued the qt.inc. I just assumed it was needed Feb 28 12:07:10 you were looking at recipes that were building qt Feb 28 12:07:47 Well, all the examples have require recipes-qt/qt5/qt5.inc Feb 28 12:07:55 in meta-qt5/recipes-qt/examples Feb 28 12:10:49 ERROR: ParseError at /linux/build/yocto/avalue_krogoth_4.1/sources/meta-avalue/recipes-qt/ked-project/ked-project_1.0.0.bb:15: Could not inherit file classes/qmake.bbclass Feb 28 12:11:26 my image is just a modified fsl-image-qt5 Feb 28 12:16:51 kanavin: yes, that should be straightforward Feb 28 12:17:00 willie: just "inherit qmake5" Feb 28 12:17:03 Had to add, inherit qmake5_base Feb 28 12:17:21 yea thanks :) Feb 28 12:17:52 eg quazip.bb in meta-qa5 Feb 28 12:18:22 rburton: So by including the qt5.inc i was trying to build entire qt for my application? insted of just using the already built library? (just trying to make sense out of everyting) Feb 28 12:18:45 well, you were pulling in bits of the qt recipe. Feb 28 12:34:57 rburton: and why is that wrong? All the example applications are doing it Feb 28 12:39:45 willie, the example applications are not about providing examples for writing a qt recipe, they're about providing examples of various bits of Qt API Feb 28 12:40:14 sadly, this is poorly documented, I couldn't find anywhere that one is supposed to use the qmake5 class, but this is how it works Feb 28 12:41:02 kergoth: can you give me some pointers? Feb 28 12:41:27 kanavin: Okay, yes I'm finding it hard to know what I'm supposed to do. It feels like im just trading on error for another atm Feb 28 12:43:20 RP: I am reworking the remaining patches, splitting them up better, and enabling both sdl and gtk+ - I'll verify that qemu would default to sdl, unless explicitly asked Feb 28 12:57:51 Sorry for my trivial questions :) But I was able to fix an error " ked-project not found in the base feeds (imx6dlsabresd cortexa9t2hf-neon-mx6qdl cortexa9hf-neon-mx6qdl cortexa9hf-neon cortexa9hf-vfp armv7ahf-neon armv7ahf-vfp armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all) By adding : ALLOW_EMPTY_ked-project="1" without really know what it does Feb 28 12:58:26 that means your ked-project package is actually empty, which is almost certainly not what you want Feb 28 12:59:03 Well it is not under /work/.../ked-project But you are saying that it was ported empty to rootfs? Feb 28 12:59:29 that means your binary was probably not even built Feb 28 13:00:35 That is not what i want, you suggested to remove the "do_install" function an add "Inherit qmake5" Feb 28 13:01:29 It feels like i need some function in the recipe? unless inherit qmake5 by default means it gets installed Feb 28 13:02:05 inherit qmake5 will provide all the needed functions for configuration, compilation and installation Feb 28 13:03:25 Okay, but you still think nothing was built regarding my error, let me install the image and get back to you Feb 28 13:06:57 hmm, why can't I run oe-pkgdata-util from within a bitbake script.. ERROR: Unable to connect to bitbake server, or start one Feb 28 13:18:42 ernstp: the parent bitbake is holding the bitbake lock? Feb 28 13:19:24 RP: ok, I thought that "connect to bitbake server" part should work still. Feb 28 13:19:41 RP: virgl patchset done, looking much better now, I think :) Feb 28 13:20:46 the only thing some people might not like is having to add 'sdl' to runqemu to enforce the SDL frontend, but qemu does prefer gtk+ over sdl if not specified Feb 28 13:22:38 ernstp: it would be two controlling UIs which doesn't work Feb 28 13:31:26 kananvin: You were right :( No application was found on the system. The recipe looks like this https://pastebin.com/JtiGfgSm and i have built the application on my desktop and ported it over with qtcreator and that works. Do you have any idea what I'm doing wrong? Feb 28 13:34:13 willie, remove INSANE_SKIP_${PN} += "installed-vs-shipped" Feb 28 13:34:25 that masks mistakes in your recipe Feb 28 13:34:30 kanavin: why not use intermediate variable instead of _remove for darwin as suggested before? Feb 28 13:35:06 JaMa: its not that easy sadly Feb 28 13:35:32 in the last iteration it looks easy Feb 28 13:35:47 JaMa, because there is no point: these things will just cause build failures, so unless someone provides a dedicated effort to enable them, direct _remove is totally fine Feb 28 13:35:58 ah there is still 8/8 for poky Feb 28 13:36:56 RP: this patch was forgotten https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=18bead102afabffcf3842ee099dcd22b8a598b8d Feb 28 13:37:54 kanavin: It was? https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=18bead102afabffcf3842ee099dcd22b8a598b8d ? Feb 28 13:37:58 RP: still don't see why intermediate variable won't work even with append from your local.conf.sample Feb 28 13:38:31 JaMa: in the nativesdk case you want it to work in the mingw case but not in the linux case Feb 28 13:39:10 JaMa: you'd have to put the intermediate variable in local.conf and it gets ugly very quickly Feb 28 13:39:35 RP: right, I think there was a moment when it wasn't in master Feb 28 13:39:38 or 2 intermediate in qemu I guess Feb 28 13:40:21 kanavin: probably my scripts working Feb 28 14:04:26 kanavin: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13194 - still some grumbling ptest issues with perl :/ Feb 28 14:04:32 Bug 13194: normal, Undecided, ---, ross.burton, NEW , [2.7 M2 RC2] perl ptest failure Feb 28 14:19:09 kanavin: also is gtk,gl=es valid option? my host qemu shows gl=es valid only for sdl display (but it might be a bug in --help text) I'm waiting for qemu to rebuild in OE Feb 28 14:21:07 JaMa, it is valid, help text is wrong Feb 28 14:53:50 how do you debug or log what steps that bitbake has taken Feb 28 14:54:27 i want to know what steps where taken when a custom .bb was done Feb 28 14:56:04 bitbake -e Feb 28 14:57:14 how do you put the build products of bitbake into one place that can be removed and and bitbake be restarted ? Feb 28 14:57:19 is this the TMP dir? Feb 28 14:57:38 or rather is there a bitbake clean Feb 28 14:59:07 yes, there is TMPDIR variable (default tmp-glibc) Feb 28 14:59:19 you can delete all that and rebuild from sstate (quick) Feb 28 14:59:57 in each component you will find temp directory with useful logs like log.do_compile for individual tasks Feb 28 15:00:16 in TMPDIR/log you'll find logs showing which tasks it was running Feb 28 15:01:22 kanavin: I cleaned the build and removed INSANE_SKIP_${PN} += "installed-vs-shipped" and allow empty. Now I'm seeing this error "Files/directories were installed but not shipped in any package:" I tried to follow this guy https://lists.yoctoproject.org/pipermail/yocto/2016-January/028127.html but still giving errors. Feb 28 15:02:01 New news from stackoverflow: Staging directories in yocto Feb 28 15:02:10 willie, following random advice from google search results is not the greatest idea. Can I see the full error message? Feb 28 15:04:13 kanavin: Iknow you are right, but I dont really see any alternatives atm : https://pastebin.com/hDjZJQRG Feb 28 15:04:57 willie, your binary goes into a non-standard location. any reason you want it in /opt? Feb 28 15:05:10 willie: include /opt/ked-qml-qt-project/bin/ked-qml-qt-project in FILES_${PN} if you really want it in this location Feb 28 15:06:58 Well not really, i just used the SDK under /opt. How would i change location to /usr/lib? Feb 28 15:07:54 Or, what is best practise to learn? Feb 28 15:08:07 I guess you need to tweak your qmake configuration file Feb 28 15:08:08 read the content of that .tar file Feb 28 15:09:20 Okay, so since i used qmake under /opt in QTcreator on my PC. the application also wants to be installed under /opt on target system Feb 28 15:11:02 the qmake5 class is telling the software it is building to install in /usr, so your app is not listening to that Feb 28 15:15:49 somebody got experience on sah-external-toolchain Feb 28 15:16:16 I'm trying to get my binary toolchain into the build Feb 28 15:18:47 sorry meta-external-toolchain :D Feb 28 15:20:15 I maintain it and wrote most of it. what's the question? Feb 28 15:21:00 I'm trying to understand the minimal skeleton required to compile the root fs with the toolchain Feb 28 15:21:08 no extra features like generating sdk at the moment :) Feb 28 15:21:56 interesting I made a typo: meta-webos/recipes-extended/tzdata/tzdata%.bbappend and bitbake doesn't complain that there isn't tzdata% recipe, but PN seems to be set to tzdata% not tzdata (like when % is used after _ as version wildchar), so FILESPATH was pointing to wrong directories Feb 28 15:22:02 hasssimir fenrig Feb 28 15:22:08 so like you recommended I was looking at meta-sourcery, but its quite big and I guess it does more then what I'm looking for Feb 28 15:22:28 so I started out creating my own tcmode Feb 28 15:22:53 JaMa: that sounds bizarre :/ Feb 28 15:23:06 this is one of the things that is required to get the the external toolchain to work, now I dont understand how the TCMODEOVERIDE is set Feb 28 15:23:12 or rather when its set Feb 28 15:23:31 # _prepend /OE/build/build-webos-master/meta-lg-webos/meta-webos/recipes-extended/tzdata/tzdata%.bbappend:8 Feb 28 15:23:34 # "/OE/build/build-webos-master/meta-lg-webos/meta-webos/recipes-extended/tzdata/tzdata%:" Feb 28 15:24:06 RP: ^ this is from FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:" Feb 28 15:24:06 fenrig: the big problem with external toolchains is making sure you have all the pieces the system expects, in the form it needs them in. They're hard to get right Feb 28 15:24:42 fenrig: TCMODEOVERRIDES is like MACHINEOVERRIDES or DISTROOVERRIDES. it lets you ensure the baseline configuration is still applied when you create your own based on it Feb 28 15:25:06 fenrig: I'd recommend setting it to ensure any overrides usage in meta-external-toolchain is still applied for your custom tcmode Feb 28 15:25:21 RP: okay, no probl. I'm trying to wrap my head around it Feb 28 15:25:38 fenrig: much of meta-sourcery makes assumptions based on what we know about that particular toolchain, i.e. automatically setting EXTERNAL_TARGET_SYS based on the expected toolchain binary prefixes Feb 28 15:25:44 kergoth: but I can set it to the tcmode that I'm declaring in that inc file, like sourcery does Feb 28 15:25:47 RP: I'll check why it didn't complain about missing recipe for tzdata% that's probably where it should be fixed I guess (% was originally meant only for versions, I hope people don't use it to match multiple recipes as well) Feb 28 15:25:47 but you can always set it explicitly too for the particular toolchain you're using Feb 28 15:26:03 explicitly is okay for me at this stage Feb 28 15:26:05 JaMa: I suspect they do :( Feb 28 15:26:39 fenrig: right. you could possibly even just use the meta-external-toolchain tcmode as is as a starting point, but including and adjusting tcmodeoverrides is a reasonable alternative. you shouldn't need anything else in that file to start with Feb 28 15:27:21 ah okay so tcmode of meta-external-toolchain will do the job as well for me? Feb 28 15:27:28 that's one thing the new meta-external-toolchain does differently, it uses search paths and files mirrors to look in alternate locations to deal with path differences when extracting files from the external toolchain, rather than assuming a fixed layout Feb 28 15:27:36 which makes it more generic than most Feb 28 15:28:00 more generic is a good idea :) Feb 28 15:28:05 still might need tweaks for particular toolchains, of course, but the baseline is more flexible Feb 28 15:28:16 it may well work as is, yes. i'd try that and see how it behaves Feb 28 15:28:17 but wait so I have an external toolchain Feb 28 15:28:22 so you are saying I can just do Feb 28 15:28:29 TCMODE in local conf Feb 28 15:28:30 set 1) TCMODE, 2) EXTERNAL_TARGET_SYS, and 3) EXTERNAL_TOOLCHAIN Feb 28 15:28:36 ah yes Feb 28 15:28:40 quite easy in fact Feb 28 15:28:48 that's the baseline configuration. which toolchain to use, the toolchain binary prefix to use, and the toolchain path Feb 28 15:28:49 thats why I couldnt wrap my head around it Feb 28 15:28:50 respectively Feb 28 15:28:58 everything else is bonus Feb 28 15:29:08 like dynamically parsing the binary toolchain Feb 28 15:29:23 to get the right layout/variables/files/headers Feb 28 15:29:29 meta-sourcery has extras for automatically determining external target sys, dealing with optimization flag particularities, and it adds a tcmode to rebuild glibc from source for that particular toollchain Feb 28 15:29:44 yeah I found that as well :) Feb 28 15:29:57 also I think I found some stuff on how to generate sdk's Feb 28 15:30:09 or I think its called ADT in yocto Feb 28 15:30:11 yeah, downside to the flexibility is more complexity in the bbclasses. if you just look at the -external recipes, it's fairly striaghtforward. the FILES_ variables determine not just packaging like in oe-core, but also which files to extract from the external toolchain Feb 28 15:30:30 so they need to be more explicit rather than big wildcards to avoid extracting wrong files Feb 28 15:31:02 ideally, the external toolchain builder would write metadata about what files belong to which packages to let us split the sysroot back up. i think crosstool does that. but most don't, sadly, hence hardcoding file lists Feb 28 15:31:21 kergoth: okay great :) Feb 28 15:31:31 thx for helping me :) Feb 28 15:31:38 I'm going to try your 3 step plan first Feb 28 15:31:44 the alternative is to just grab the entire toolchain sysroot and throw it in a single package, but that's not ideal either, as lots of external toolchains will build extra packages that'll clutter up your rootfs if you include them Feb 28 15:31:49 and fingers crossed it will get me to my first goal :P Feb 28 15:32:00 i.e. gdbserver, other debugging or profiling tools, etc Feb 28 15:32:27 Hey guys! I'm glad to see this channel is active! I've got no idea how Yocto works, but the guy who does is having problems and I was asked to look into it. Is there a way to tell it to pull RPMs from a remote server when you build an image? Feb 28 15:33:01 kergoth: okay, dont need it at the moment and even then I have gdb from the toolchain Feb 28 15:33:05 * kergoth nods Feb 28 15:33:18 give that a shot and let me know how it goes, if it fails at any point we can tweak from there Feb 28 15:33:22 Something like a recipy that has it go get the latest version of a package from a remote Smart server? Feb 28 15:33:35 kergoth: Thank you :) Feb 28 15:33:35 recipe* sorry. Feb 28 15:33:46 RP: you're right, it allows % in the name since the wildchard was added for bbappends http://git.openembedded.org/bitbake/commit/?id=31bc9af9cd56e7b318924869970e850993fafc5f Feb 28 15:34:00 smrtz: two options, try to coerce the image recipe to build from a feed rather than local recipes, or just host yocto sstate on your server and let it pull from that, which is a binary caching mechanism, including binary packages as well as other bits we use to build recipes from source Feb 28 15:34:29 Ok, I'll look into those now. Thanks! Feb 28 15:34:44 three, the last option is what you suggest, create recipes that pull down individual packages, but that's not ideal for a number of reasons Feb 28 15:34:51 RP: is it worth investigating what to do with BPN in immediate expansion in such case? or can we assume that people just use hardcoded name instead of PN/BPN in cases where they really want to match multiple? Feb 28 15:35:02 Why not? kergoth. Feb 28 15:35:08 i'd suggest hosting an sstate mirror, along with a sources mirror, for your engineers, and automatically updating both from your configuration management / autobuilder Feb 28 15:35:33 won't need to rebuild from source nearly as often, but avoids trying to coerce the system into something other than how it normally works Feb 28 15:35:59 kergoth: I'm the DevOps guy, so hosting more servers is actually a problem I can solve pretty easily. Thanks for the solution. Feb 28 15:36:14 i suspected :) no problem Feb 28 15:37:26 Also, we're locked into Morty for the time being, and RPMv5 is a pain. Is switching it with RPMv4 possible? Feb 28 15:37:37 kergoth: the TCMODE is default? for external toolchain? Feb 28 15:38:17 no, "default" is building oe-core's toolchain. you want to set it to external (or whatever the conf/distro/include/tcmode*.conf filename is Feb 28 15:39:11 okay Feb 28 15:41:13 kergoth: It *looks* like I should just be able to swap the two, but without knowing anything about this, I really don't know... Feb 28 15:41:53 Hello guys, Just want to thank everyone for the help today :) Feb 28 15:46:13 no idea on rpm version, someone else will have to assist with that Feb 28 15:46:19 when you build recipe does a package follow suit Feb 28 15:46:50 Ahh, alright. Feb 28 15:48:20 black_13: yes, as you were told yesterday Feb 28 15:49:24 sorry I have been puking nice flu want some Feb 28 15:54:28 The RPM version issue is our biggest issue at the moment. If you were going to start trying to switch it out, what path would you take? kergoth Feb 28 15:54:55 (I'm not looking for solid answers, just an idea of where I should start.) Feb 28 15:58:21 like i said, i know nothing about that, i don't even use rpm. someone else will jump in if they know the answer, there are experts in rpm in the channel Feb 28 15:59:15 i added PACKAGE_CLASSES = "package_ipk" to my local conf Feb 28 15:59:30 IMAGE_FEATURES += "package-management" Feb 28 15:59:41 smrtz: i got ipkg Feb 28 16:02:36 Hmm, I'll look into ipkg now... Thanks! Feb 28 16:04:06 smrtz: porting back to rpm4 was not simple. i'd switch to opkg unless you really need rpm. Feb 28 16:04:16 the patches are all in git so you could backport them... Feb 28 16:04:30 they're quite invasive though. rpm5->rpm4. smart->dnf. Feb 28 16:04:38 smrtz: https://github.com/black13/poky_qemu_arm/blob/master/build/conf/local.conf Feb 28 16:05:10 smrtz: do you know how to build the ipkgs or how to create a custom library Feb 28 16:05:28 that is how you enable the library to start Feb 28 16:07:12 black_13: nahh, but I can learn it. Feb 28 16:08:49 rburton_: We're not *super* locked into RPM, but it's how all of our apps are being built at the moment. Do you know how package signing works in opkg? Feb 28 16:09:21 or ipkg for that matter? Feb 28 16:15:16 what i want to understand is how or were to place a .bb file Feb 28 16:17:26 http://codepad.org/5NjHSuAS is the bblayers.conf as is how do i add extra layers Feb 28 16:26:57 jonmason: I'm trying the qemuarm64 patches and it just sits with an un-initialized display? :( Feb 28 16:28:45 jonmason: image does boot as I can ssh in, x doesn't start as there are no screens and the serial consoles seem messed up :( Feb 28 16:32:48 RP: you added the kernel-cache changes? Feb 28 16:33:17 jonmason: ah, no Feb 28 16:33:34 yeah, totally need those :) Feb 28 16:33:43 jonmason: that makes more sense Feb 28 16:33:54 I thought I pointed them out in the 0/2 message, but sorry if I didn't make it more obvious Feb 28 16:34:09 jonmason: I think I was thiniing zeddii already had them Feb 28 16:34:27 I said in that series not to include them :) Feb 28 16:34:38 I didn't know if that kernel warning was a deal breaker Feb 28 16:34:44 jonmason: you do make it quite clear there, not sure how I formed a different opinion :) Feb 28 16:35:36 RP: I can cycle them through pretty quickly. Want me to send a patch for that ? I have a couple of small things queued up that I can send at the same time. Feb 28 16:36:19 zeddii: is there a way I can test this without making the changes? Feb 28 16:38:10 there are only a couple of kernel config changes needed. You could make them by hand Feb 28 16:39:09 yah. or you'd need a fragment in a layer via a bbappend. but my sending a patch in the next 15 minutes is probably faster than that route :D Feb 28 16:39:34 zeddii: I'm just worried if this will break something :/ Feb 28 16:40:03 you could just pull in the qemuarm64-gfx patch and leave the others Feb 28 16:40:04 I'm not subbed to that mailing list so I don't have copies of the patches in any form that isn't mangled :( Feb 28 16:40:21 we did run into the qemuarm match problem before, yes, so once you apply it, it will be the default for qemuarm after my SRCREV bumps. Feb 28 16:40:45 zeddii: the arm64 graphics one looks safe as it just adds bits? Feb 28 16:41:12 zeddii: is there another way I can do the migration of qemuarma15 to qemuarm without making that change (or making it a different way)? Feb 28 16:41:25 zeddii: I thought we didn't want to do that. Can we just add something in to trigger it to use qemuarma15? Feb 28 16:42:06 was that for him or me? Feb 28 16:42:08 yah. I don't apply the patch that adds KMACHINE qemuarm to the qemuarm15 bsp Feb 28 16:42:23 and then you'd only get the changes when you build qemuarma15 Feb 28 16:42:45 zeddii: can we then just map to use qemuarm15 for qemuarm using configuration? Feb 28 16:43:10 which config ? like local.conf ? yes. it is possible. Feb 28 16:43:52 zeddii: we'd just add that the linux-yocto recipe in the branches we switch the qemuarm machine in Feb 28 16:45:56 kergoth: so I'm having no tune_arch var it seems Feb 28 16:46:05 RP: let me try and restate that, and let me know if this is what you are thinking Feb 28 16:46:15 fenrig: that's not defined by the external toolchain Feb 28 16:46:21 make sure MACHINE is valid Feb 28 16:46:38 also make sure your branches match. i.e. meta-external-toolchain master for oe-core master Feb 28 16:46:45 RP: I'd only apply it to a specific linux-yocto version, i.e. 4.19 and the switch for qemuarm would only happen in those kernel versions. Feb 28 16:47:21 kergoth: yeah no problem, I'm changing the machine :P Feb 28 16:47:57 zeddii: We'd switch qemuarm in master and then tell recipes to use the qemuarma15 config in linux-yocto Feb 28 16:48:21 zeddii: thereby meaning we can update kmeta in old releases without risk Feb 28 16:50:14 zeddii: Can I patch kmeta from SRC_URI? the kernel scripts aren't very happy about it Feb 28 16:50:58 zeddii: I think its trying to apply it to the kernel Feb 28 16:51:03 nope. it doesn't like that. it is additive. Feb 28 16:51:11 sorry. got three pings at once there. Feb 28 16:51:37 kergoth: okay I think I got it working Feb 28 16:51:59 but yes. I can *not* apply the KMACHINE fix to the kmeta, and also do a patch to the linux-yocto recipe to have qemuarm automatically use qemuarma15 in branches that you want. Feb 28 16:52:45 zeddii: "additive" isn't the descriptive word I'm using ;-) Feb 28 16:53:15 I'd have to see how you were trying to add it to the SRC_URI to advise better :P Feb 28 16:53:33 zeddii: how would I add a patch to SRC_URI to change the kmeta repo? Feb 28 16:54:17 to a completely different kmeta repo ? or just one with the changes you have ? Feb 28 16:54:35 zeddii: I have a patch to the kmeta repo I just want to apply Feb 28 16:57:36 heh. no one has asked me that one, at least not recently. since that repo is plunked down by the fetcher, and then found by the tools for configs, it isn't normally patched. Feb 28 17:02:29 New news from stackoverflow: Build all packages for an image Feb 28 17:03:15 RP: it is too loud to think where I am. I need to transit home. will be back in 15 mins. Feb 28 17:03:32 RP: I sent the perl ptest issue fix :) Feb 28 17:26:07 RP: back. Feb 28 17:26:25 can you send me your SRC_URI ? Feb 28 17:30:32 zeddii: sorry, been pulled into a meeting Feb 28 17:30:43 np. let me just do up a queue that should work. Feb 28 17:30:59 and I can see that what you want broke some time ago, I’ll fix it, but that’ll be tomorrow. Feb 28 17:31:06 zeddii: I just tried adding file://0001-qemuarm64-Add-graphics-support.patch but how it would know which repo to apply to Feb 28 17:31:18 yup. Feb 28 17:31:38 I’ll sort that part out, but will get you a series in the meantime. Feb 28 17:46:14 kanavin: great, thanks! Feb 28 17:51:46 kanavin: risk taking and put it into master :) Feb 28 17:52:11 RP: the perl thing? Feb 28 17:52:20 kanavin: yes Feb 28 18:04:50 zeddii: Sledgehammer approach http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=caf1dfed2aee3fa3ee4d94fdaa454a5a9d43792b ;-) Feb 28 18:05:17 * RP -> back later, had enough today for now Feb 28 18:13:45 kanavin: Alright, I'm going to try your VirGL changes... whats the best branch to use? Feb 28 18:14:51 JPEW, http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/qemu-split-virgl-gtk Feb 28 18:15:36 JPEW, can you tell what you're going to run? Feb 28 18:15:53 (which app etc?) Feb 28 18:16:21 I was going to try kmscube and weston Feb 28 18:16:39 ah. I tried both, they work :) Feb 28 18:16:44 cool Feb 28 18:17:09 note that weston needs to be configured for drm, default qemu config is for fbdev Feb 28 18:17:41 kanavin: Ok Feb 28 18:18:05 kanavin: Do I need any local.conf changes? Feb 28 18:18:54 JPEW, meta/recipes-graphics/wayland/weston-conf.bb Feb 28 18:21:37 JPEW, change to drm-backend.so in there Feb 28 19:06:46 kanavin: are you intending to enable drm for weston by default for qemu? Feb 28 20:33:35 RP: Hi, from the build I haven't received the previous error, but I gor a new one Feb 28 20:33:45 https://pastebin.com/1X7x56NT Feb 28 20:48:50 hi, I'm new to yocto and would like to install grub-mkstandalone in the target image without adding "grub" (and all the provided binaries) to "IMAGE_INSTALL_append" Feb 28 20:56:44 I tried to create a grub_2.02.bbappend and work on do_install_append() with no luck: I've also started playing with sysroot_stage_all_append() but I actually don't know if I'm on the right track Feb 28 22:18:21 anyone actually use sysvinit and want to test an upgrade for me Feb 28 22:20:11 rburton_: you actually tried it? :) Feb 28 22:52:28 jonmason: finally got arm64 graphics :) Feb 28 22:52:40 zeddii: we're therefore good on the arm64 patch Feb 28 22:53:24 zeddii: made my gross hack work to apply the patch :) Feb 28 22:53:33 RP: did it take effort or finally got around to it? Feb 28 22:53:54 jonmason: I was mostly in meetings and then getting food/family stuff Feb 28 22:54:33 about time for me to do the same :) Feb 28 22:54:42 So, is the warning a dealbreaker? Feb 28 22:54:47 jonmason: it is nice to see this finally work, I'm trying testimage now Feb 28 22:55:23 jonmason: The question is does the error log parser pick it up? I suspect the answer is yes and we either have to whitelist it or fix it Feb 28 22:55:46 jonmason: having such warnings is sub-optimal Feb 28 22:55:52 I know Feb 28 22:56:03 I'd like to get virtio working, which is the real solution Feb 28 22:57:39 jonmason: one step at a time I guess Feb 28 22:57:56 RP: it builds! Feb 28 22:58:00 I'm hopinh this is close enough, and I can get back to it after I get the arm64 build servers working Feb 28 22:58:11 rburton_: ship it! ;-) Feb 28 22:58:49 jonmason: I'm seeing what testimage says ;-) Feb 28 22:59:19 I'm not getting testimage to work here.. I only have log files that say host_00_* and most of them are reporting 'whatever it is': File not found Feb 28 22:59:30 i.e. Feb 28 22:59:30 cat host_00_df Feb 28 22:59:37 /bin/sh: df: command not found Feb 28 22:59:41 any idea what is causing this? Feb 28 23:02:29 fray: those are the host logs, ignore them Feb 28 23:02:43 it says that the test image failed.. but those are the only logs I see.. Feb 28 23:02:55 fray: what does the testimage task log say? Feb 28 23:03:07 where would that be, work directory or? Feb 28 23:03:31 fray: ${WORKDIR}/temp/log.do_testimage same as any other task Feb 28 23:03:53 ok.. going there to look.. the error message made it seem like that runtime-hostdump is where I needed to look Feb 28 23:04:15 * RP suspects we should rip that stuff out :/ Feb 28 23:05:04 DEBUG: runqemu started, pid is 11155 Feb 28 23:05:04 DEBUG: waiting at most 120 seconds for qemu pid (02/28/19 20:52:30) Feb 28 23:05:04 DEBUG: runqemu exited with code 1 Feb 28 23:05:04 DEBUG: Output from runqemu: Feb 28 23:05:04 runqemu - INFO - Continuing with the following parameters: Feb 28 23:05:04 runqemu - INFO - Setting up tap interface under sudo Feb 28 23:05:05 sudo: no tty present and no askpass program specified Feb 28 23:05:30 so it was trying to sudo..... that helps Feb 28 23:06:00 (I really dislike qemu using sudo) Feb 28 23:06:06 fray: a simpler test is "runqemu qemuXXX" Feb 28 23:06:16 fray: if that doesn't work, testimage is unlikely to Feb 28 23:06:33 fray: if you preconfigure the network devices, it doesn't need sudo Feb 28 23:07:04 fray: sudo `which runqemu-gen-tapdevs ` 1000 sharedsource 8 tmp/sysroots-components/x86_64/qemu-helper-native/usr/bin Feb 28 23:07:32 fray: sets up 8 network interfaces for qemu for UID 1000, GID sharedsource Feb 28 23:08:00 thanks.. Feb 28 23:08:27 jonmason: testimage isn't finding the consoles and doesn't look as happy Feb 28 23:08:37 jonmason: so progress but not quite right Feb 28 23:08:59 :/ Feb 28 23:09:02 jonmason: I'm trying "MACHINE=qemuarm64 bitbake core-image-sato -c testimage" Feb 28 23:10:08 that should be similar to what I was doing. Let me try it explicitly Feb 28 23:10:32 jonmason: obviously I built core-image-sato previously Feb 28 23:11:20 so runqemu qemux86-64 fails when I justc all it.. Hmmm Feb 28 23:11:38 retrying it with the testimage thing.. might be something esle.. Feb 28 23:11:42 it said it did add the networks Feb 28 23:11:49 (tap0-tap7) Feb 28 23:14:02 certainly seems to be trying harder.. I suspect that may have been the problem/solution.. thanks Feb 28 23:14:37 jonmason: testimage did fail, timeout on finding login console Feb 28 23:14:41 drat, no Feb 28 23:14:45 runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: could not configure /dev/net/tun (tap0): Operation not permitted Feb 28 23:14:51 same as when I ran qemu on the command line Feb 28 23:15:23 RP: I was able to do it by hand (last night). Rebuilding now to sanity check, but it'll probably be another 20 mins for it to finish Feb 28 23:16:57 fray: that gen-tapdevs should avoid that :/ Feb 28 23:17:15 jonmason: I'm going to have to sleep as my eyes can't take any more computers today Feb 28 23:17:46 jonmason: I think its the changes you made to the serial consoles, they're not compatible with what testimage expects Feb 28 23:18:00 NP, I'll see what I can see and maybe pick this up with you tomorrow morning Feb 28 23:18:05 jonmason: its good progress though, lovely to see graphics work there Feb 28 23:18:27 ya, I can see the tap interfaces are there.. but for some reason qemu is trying to screw with them Feb 28 23:18:34 is the testimage stuff in the standard tree? Feb 28 23:18:58 "ERROR: Task do_testimage does not exist for target core-image-sato (/home/jdm/yocto-dev/poky/meta/recipes-sato/images/core-image-sato.bb:do_testimage). Close matches: | ETA: 0:00:00" Feb 28 23:21:17 jonmason: INHERIT += "testimage" in local.conf Feb 28 23:22:02 thanks, assuming its the console stuff, I'll have a new series out tonight Feb 28 23:22:29 I'm going to be up late anyway, presentation tomorrow on how to do kernel dev in OE Feb 28 23:22:44 fray: check /tmp/qemu-tap-locks /etc/runqemu-nosudo files Feb 28 23:22:52 I have the title slide. so its like 90% done, right Feb 28 23:24:02 fray: for me I sometimes need to lock the tap devices already used e.g. by VPN for runqemu to skip them Feb 28 23:24:21 ya, I didn't have any already in use.. Feb 28 23:25:01 jonmason: I have some slides I need to sort next week :/ Feb 28 23:26:32 * RP heads afk Feb 28 23:27:34 RP: I'm presenting at SCaLE on (https://www.socallinuxexpo.org/scale/17x/presentations/kernel-development-workflows-using-openembedded) this and tomorrow is my first run Feb 28 23:28:06 I'm happy to send out the slides to anyone that wants them after I'm done Feb 28 23:30:19 there will be talk about our use of OE in LGE as well https://www.socallinuxexpo.org/scale/17x/presentations/openembedded-lg-products Feb 28 23:31:05 Cool, we should all meet up for dinner and maybe a hack-a-thon Feb 28 23:33:05 I won't be there but you can say hello to my manager Lokesh :) Feb 28 23:50:58 RP: good to hear. I’ll have the meta data updates out later tonight, so in your inbox for the morning. Mar 01 00:22:16 is the ar archiver available for yocto Mar 01 00:32:17 black_13: its part of binutils Mar 01 00:38:10 i am looking for a tool that will build ipkg packages Mar 01 00:42:40 http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg-build Mar 01 00:43:01 that's what we use to build an opkg Mar 01 00:43:35 tbh you can most likely use dpkg, the format is near identical (and i often use dpkg to inspect opkg) **** ENDING LOGGING AT Fri Mar 01 02:59:57 2019