**** BEGIN LOGGING AT Fri Jan 11 02:59:57 2019 Jan 11 07:25:55 is there a way to deploy the full list of installed packages and their versions into the image (similar to image-buildinfo which seems to only do that for the layers)? Jan 11 07:43:47 CoLa|work: i'm not aware of any readymade solution, but you can always crate a custom class that basically is image-buildinfo and adds the bits and pieces that you want Jan 11 09:41:08 JPEW, with the two package.bbclass patches applied that I sent to ml, I can do "bitbake busybox" from scratch with no changes in depsig.* Jan 11 10:32:00 rburton: when you say mostly green, ok to merge? :) Jan 11 10:32:32 rburton: eclipse glitched Jan 11 10:33:01 yes, damned eclipse Jan 11 10:34:20 rburton: automate patch needs signoff and description Jan 11 10:34:27 * LetoThe2nd offers some eclipsing for you to cheer up: https://www.youtube.com/watch?v=fsgWUq0fdKk Jan 11 10:39:45 rburton: merged some of it, have questions on the rest Jan 11 10:40:30 oh just noticed i left the netbase one in there that i hadn't totally reviewed yet! Jan 11 10:41:09 RP: yeah sorry, failed to prune sufficiently Jan 11 10:41:34 so we have lots of tasks that set +do_patch[umask] = "022" Jan 11 10:41:40 why not just do that on startup? Jan 11 10:43:56 rburton: we should probably add something which allows that to be configured Jan 11 11:18:53 New news from stackoverflow: IP Tables for Yocto Krogoth Jan 11 11:18:54 If i wish to bake nodejs lighttpd and lftp into my bild does this all come under EXTRA_IMAGE_FEATURES? Jan 11 11:19:12 Or do i use the IMAGE_INSTALL_append? Jan 11 11:19:27 Isaac_: usually one creates a new image recipe and adds it to IMAGE_INSTALL Jan 11 11:22:21 IMAGE_INSTALL ?= "nodejs lighttpd lftp" Jan 11 11:22:31 LetoThe2nd: Like so? Jan 11 11:22:39 IMAGES_ISNTALL += "nodejs lighttpd lftp" Jan 11 11:23:24 LetoThe2nd: Jan 11 11:23:30 LetoThe2nd: Ok i will try this. Jan 11 11:45:29 khem: thanks for the binutils patches Jan 11 12:23:44 rburton: do you know if Martin Jansa is here? Jan 11 12:26:18 kanavin: he goes by JaMa Jan 11 12:39:39 rburton: basically I ran out of ideas about how to make qemu+virgl work Jan 11 12:39:49 https://bugzilla.yoctoproject.org/show_bug.cgi?id=12938#c5 Jan 11 12:39:50 Bug 12938: enhancement, Medium+, 2.7 M2, Martin.Jansa, NEW , virglrenderer+spice support in qemu-native with accelerated GL Jan 11 12:40:30 what's especially annoying is that it does work for plenty of people, so it's probably some kind of user error Jan 11 12:40:56 yeah Jan 11 12:41:09 wasn't it JPEW who also had it working? Jan 11 12:41:59 I don't really remember if it was Jan 11 12:42:33 at this point I would just try with a host qemu, but surprise, Ubuntu ships it with virgl disabled Jan 11 12:45:04 armpit: did you get anywhere with nfs-ganesha? I've a few patches to upstream but their contribution process makes me cry (gerrithub!) if you've got that setup, i'll throw you the patches :) Jan 11 13:27:59 I'm beginner in python and I would like to know if there is a way to debug step by step the bitbake server Jan 11 13:59:39 rburton, kanavin: Yes, I have qemu+virgl working, but I use host qemu not the one from oe-core Jan 11 14:00:07 JPEW: right - I found what was the issue with qemu-gtk (seemingly random lockups) Jan 11 14:00:17 we might yet get this into oe-core proper :) Jan 11 14:00:35 host qemu is not really an option, as for example Ubuntu does not support virgl in qemu Jan 11 14:11:04 kanavin: You probably noticed I merged perl. We'll see what that brings! :) Jan 11 14:11:29 RP: I sent patches for meta-oe that fix at least some of the damage :) Jan 11 14:11:51 but basically yes, I'm (in)famous for such changes ;) Jan 11 14:12:20 RP: Seen any strange bitbake crashes/hangs on the autobuilder? I think I have some proof that we need the fork handlers for persist_data :( Jan 11 14:12:45 kanavin: it brings us up to date which is good in many different ways Jan 11 14:12:51 JPEW: not really, no Jan 11 14:13:06 RP: I will also try to work on python, time permitting Jan 11 14:13:13 RP: OK Jan 11 14:13:22 with that in place, we should be again mostly updated Jan 11 14:13:25 JPEW: I really don't want to go there :( Jan 11 14:13:47 kanavin: yes, that is the next biggest piece, then we're looking pretty good Jan 11 14:14:11 JPEW: too many pieces to go wrong :( Jan 11 14:14:26 RP: Ya, I get it. Using sqlite as an IPC mechanism isn't as straight forward as I was hoping Jan 11 14:15:21 Probably means that persist_data needs to be compeltely redone to do something else.... what that is I don't know Jan 11 14:15:49 JPEW: agreed Jan 11 14:16:35 JPEW: probably more like PR server with a RPC call? Jan 11 14:16:49 single server started by cooker and connected to by the workers? Jan 11 14:19:30 New news from stackoverflow: How to include correct libssl version into yocto-build to run .net-core application? Jan 11 14:24:02 RP: Ya. I'm a little worried about the I/O throughput, but probably best to start with the simplest implementation and run tests to see if it will suffice Jan 11 14:24:54 JPEW: we do occasionally still see PR server timeouts :( Jan 11 14:25:55 persist_data is read mostly, so I think some sort of intelligent local caching would work (e.g. the server tracks what keys each client has "checked out" and tells them when they change, otherwise the client keeps using the local cache) Jan 11 14:26:46 JPEW: for the hash equivalence case there can certainly be optimisation as they don't change Jan 11 14:26:56 RP: Yet :) Jan 11 14:28:21 JPEW: hmm :) Jan 11 14:29:43 I though that was the end use case; trivially change a recipe and none of the downstream tasks have to re-run. AFAIK, doing that in a single invocation of bitbake will almost *have* to change the hash for running tasks. Jan 11 14:29:55 Err, change the unihash Jan 11 14:30:23 Unless you get lucky and someone made that *exact* same change to the recipe and reported it to the hash server Jan 11 14:30:24 JPEW: once a given worker has requested a hash, its not going to change in the lifetime of that worker's task execution Jan 11 14:30:58 Yes, thats correct Jan 11 14:32:20 I suppose if the persist_data server lived in the same process that manages the runqueue (bbserver?) it could access the persist_data directly to get the up-to-date hashes Jan 11 14:33:08 Although, at that point I don't really see a lot of use in continuing to lump it in with persist_data; it should probably be it's own thing? Jan 11 14:33:26 JPEW: it may be worth making it its own thing Jan 11 14:33:37 JPEW: persistdata is horrible Jan 11 14:34:07 Agreed.... maybe we can just kill it Jan 11 14:34:56 Might there be an easier alternative to BB_URI_HEADREVS? Jan 11 14:35:55 JPEW: that code does need some store of data :/ Jan 11 14:36:10 its all fairly simple and could be made PR server like Jan 11 15:18:37 Hi! Anybody here having yocto linux on an imx8 board? Jan 11 15:18:55 meta-freescape supports imx8, should look at that layer and its maintainers Jan 11 15:21:03 thanx a lot! Jan 11 15:22:14 coming back from #meta-freescape. There is no such chat on IRQ here. Jan 11 15:22:34 I mean IRC Jan 11 15:23:05 s/scape/scale/ Jan 11 15:23:14 meta-freescape is a layer, not an irc channel Jan 11 15:24:26 uhm I was looking for someone I can ask a fast question about an NXP eval board with an i.MX8 running yocto linux Jan 11 15:24:35 try NXP Jan 11 15:26:00 (I'm not trying to be a troll, but it's hard for most of us to comment about specific eval boards.. the semi vendor is much more suited to answering those types of questions.) Jan 11 15:26:48 OK, yes. I just had a little hope to find another user of it maybe here in the chats. It's faster than email or forums. Jan 11 15:27:02 Thanks anyway to all Jan 11 15:27:39 Hi, i'm totally confused what yocto is for Jan 11 15:27:50 its basically a build system for embedded linux right ? Jan 11 15:28:15 rather then a speific kernel ,its for putting together a choice of kernel root fs drivers etc in an easier way ? Jan 11 15:28:16 Yocto Project is for building an embedded Linux operating system that meets your projects specific needs. It is highly configurable, customizable and extendable. Jan 11 15:28:53 it's not just a kernel, it includes cross compiled toolchain, and user space applications (all compiled from source) meaning it's YOUR configuration that is used.. not some random configuration from someone else Jan 11 15:29:37 if all you want is a kernel, there are other options that are easier to get started. However, if you are trying to build a project (hobby or commercial), the Yocto Project gives you all of the tools you will need Jan 11 15:29:38 yea ok, but in terms of porting linux to a custom board, the configuration of u boot and kernel is abstracted and done through Yocto ? Jan 11 15:29:46 with its build scripts Jan 11 15:30:18 uboot is often considered to be above the operating system. Depending on your configuration, you may need to use the cross compilers and build it separately Jan 11 15:30:38 paul_99: yes, it compiles everything from the sources the scripts find on internet GIT servers, even the toolchain for development. So you will get a consistent system that you can even reconstruct in 10 years when you may need to rebuild old firmware versions again for e.g. bugfixing support Jan 11 15:30:57 the kernel is usually patches, configured and built as part of the Yocto Project builds. However, this can also be avoided if you really don't want that.. but doing it in a unified method makes it easier to support long term. Jan 11 15:43:26 if all you're doing is bringup of a new board, building u-boot and kernel on their own during the development process is quicker, though I'd still use yocto to build and maintain the images and rootfs for long term maintenance Jan 11 15:51:17 hey everyone Jan 11 15:52:23 anyone knows how to use FILESYSTEM_PERMS_TABLES without host contamination? I know I can ignore this QA on local.conf but I need a permanent solution for my layer Jan 11 15:55:34 I'm confused by 'without host contamination?' in that question Jan 11 15:56:04 the permissions tables are a way to globally set what filesystem elements should be.. such as anything that creates '/bin' it should be set 0755 Jan 11 15:56:54 where can i find prepared release tarballs for opkg ? if the answer is "nowhere, clone the latestt tag", what do i need to set in ACLOCAL_FLAGS ? Jan 11 15:57:14 (since yocto now hosts opkg) Jan 11 15:59:18 Piraty: SRC_URI = "http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz" says the recipe Jan 11 15:59:31 replace BPN with opkg and PV with 0.4.0, and you've got a URL Jan 11 16:11:55 thanks Jan 11 16:12:07 i didn't check yocto recipies in specific Jan 11 16:13:02 i have an old system where opkg-cl is installed, what is that about ? Jan 11 16:13:56 well, checksum for your download mirror was the same as the cgit link Jan 11 16:14:10 is still get ./configure: line 13311: syntax error near unexpected token `0.20' Jan 11 16:14:40 i'd have a look at line 13311 and see what bash is running Jan 11 16:16:23 true Jan 11 16:16:27 gimme 1 sec Jan 11 16:20:26 ./configure: line 13311: `PKG_PROG_PKG_CONFIG(0.20)' Jan 11 16:20:37 you need pkgconfig installed Jan 11 16:21:02 (autoconf should have thrown you some warnings) Jan 11 16:22:30 i don't have it installed, and no, autogen.sh didn't complain Jan 11 16:22:52 yay autoconf, its a bit rubbish like that. install pkgconfig. Jan 11 16:23:14 that i already assumed, thanks ;) Jan 11 16:23:22 autohell being autohell i guess Jan 11 16:25:28 autohell being autohell i guess Jan 11 16:25:30 oops Jan 11 16:25:40 thanks rburton ;) Jan 11 16:31:18 kanavin: did i mention https://github.com/mesonbuild/meson/issues/1849 to you before? Jan 11 16:32:18 with a bit of fixing to the meson class and meson itself, we might be able to drop the qt/pkgconfig patch we carry Jan 11 16:35:01 armpit: do you test apparmor with ptest? it won't build here Jan 11 16:35:09 armpit: (tries to run a target binary at build time) Jan 11 16:36:15 rburton, I have not sure what is current state is Jan 11 16:36:31 what machine? Jan 11 16:36:34 x86-64 Jan 11 16:36:51 | make: Entering directory '/data/poky-tmp/master/work/corei7-64-poky-linux/apparmor/2.12-r0/apparmor-2.12/parser/tst' Jan 11 16:36:51 | LANG=C ../apparmor_parser -S -I errors >/dev/null errors/okay.sd Jan 11 16:36:51 | /bin/sh: 1: ../apparmor_parser: not found Jan 11 16:36:54 k, will take a look Jan 11 16:37:03 (not found == loader not found, the file exists but its a target binary) Jan 11 16:37:15 got a slew of little fixes here too Jan 11 16:37:31 k Jan 11 16:44:03 fray: I was getting warnings with the message "host contamination"... I managed how to solve it though, thanks! Jan 11 16:49:58 New news from stackoverflow: Building Yocto Linux Image with my own program inside of Image Jan 11 16:56:40 where can i find more information on the configure flags of okpg ? for example --enable-fast-install Jan 11 16:57:37 adelcast: ^ Jan 11 16:58:13 is there any source of information besides the super-old code.google site? Jan 11 16:58:14 well, that's a libtool thing Jan 11 16:58:14 http://tinf2.vub.ac.be/~dvermeir/manual/autobook/autobook-1.2/autobook_86.html Jan 11 16:58:28 oh wow thats a really old link, sorry Jan 11 16:58:49 ah didn't know, thanks rburton Jan 11 16:59:07 opkg does have man pages for opkg, opkg.conf and opkg-key Jan 11 16:59:20 and yeah, rburton is right, that's not an opkg flag Jan 11 16:59:50 For configure flags you'd just run './configure --help' I think Jan 11 17:00:29 that's where i got it from Jan 11 17:00:36 libtool specific stuff is not marked ass such Jan 11 17:00:46 s/ass/as/ ;) Jan 11 17:10:43 my target gcc package (smart install gcc) did not provide gcc but rather arm-fslc-linux-gnueabi-gcc et al. is there a package which defines the standard (shortened) tool names? Jan 11 17:11:02 of course i could just make symlinks, but just curious Jan 11 17:14:59 gcc-symlinks, iirc Jan 11 17:17:01 yes! thanks rburton Jan 11 17:17:48 and g++-symlinks for g++ Jan 11 17:18:16 Is patchwork for oe-core playing up? Seems to be rejecting a lot of patches as not applying to master recently, mine included Jan 11 17:20:50 is what it thinks master is correct? Jan 11 17:21:20 It thinks master is 65c419b8c4, can't find that commit in oe-core or poky so not sure where it's got that from Jan 11 17:24:47 halstead: ^ Jan 11 17:57:12 g++ is complaining: g++: error trying to exec 'as': execvp: No such file or directory Jan 11 17:57:20 sounds like the assembler isn't installed (as)? Jan 11 17:57:28 do you have to install this separately TOO? Jan 11 17:57:42 its prefixed too Jan 11 18:01:22 i'm not seeing a prefixed "as" either in either of gcc, g++ Jan 11 18:02:03 kanavin: why do we see this now after the patches merge: https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/168/steps/7/logs/step1b :/ Jan 11 18:03:09 kanavin: also https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/170/steps/7/logs/step1b Jan 11 18:03:40 is there some other package i need besides gcc, gcc-symlink, g++, g++-symlink Jan 11 18:03:52 RP: i saw that once, disappeared if i cleaned/rebuilt Jan 11 18:03:57 assumed it was one of those things Jan 11 18:04:42 binutils? Jan 11 18:05:26 yates_home: yes, as is from binutils Jan 11 18:05:39 yates_home: maybe binutils-symlinks Jan 11 18:06:19 RP: ok. binutils-symlinks was not required to get plain old "as" Jan 11 18:07:35 yates_home: sure but you mentioned the other ones ;-) Jan 11 18:09:34 RP: it's a parallel build race :( I had fixed a few of those with upstream, and though that numerous green runs of AB is enough proof Jan 11 18:09:56 RP: I will notify them again now, until then we may have to revert to non-parallel make runs Jan 11 18:11:48 kanavin: ok, thanks. At least we know what it is! :) Jan 11 18:12:15 * RP -> in search of pizza Jan 11 18:12:17 RP: https://github.com/arsv/perl-cross/issues/72 let's see if they come up with a patch quickly (historically they did), if not, we can do non-parallel builds Jan 11 18:12:41 basically building dynaloader ahead of other items should do the trick I think Jan 11 18:12:43 kanavin: sounds like a plan, thanks Jan 11 18:13:05 RP: cheers :) Jan 11 18:13:51 rburton: can you take that up (the meson thing)? Jan 11 18:14:10 kanavin: yeah Jan 11 18:14:58 kanavin: great to see the perl-cross people being proactive with issues Jan 11 18:15:27 yep Jan 11 18:15:50 I think perl upstream still doesn't support or test parallel builds, so we're just weeding those issues now Jan 11 18:16:00 right Jan 11 18:16:13 when can we ditch perl entirely Jan 11 18:16:19 I think it's worth it, from 4 minutes to 30 seconds Jan 11 18:16:44 also, popt is now 9 years unmaintained, so people really need to start moving away from that Jan 11 18:17:00 rburton, what about python 2? Jan 11 18:17:11 we have less than a year to drop it :) Jan 11 18:17:15 kanavin: so close to getting rid of that! Jan 11 18:17:40 i think mesa can use py3 in git now Jan 11 18:17:52 right dinner is done. have a good weekend all. Jan 11 18:18:32 good weekend to you too Jan 11 18:30:48 RP: yes, you were perfectly logical! i was just pointing out the inconsistency Jan 11 18:32:24 paulbarker, Between Dec 19th and the 22nd something happened that caused patchwork's repo to get stuck. Maybe there was a non-FF push to oe-core that it couldn't deal with. It is fixed now. Jan 11 18:33:11 paulbarker, rburton RP I'm taking a little time to see if there is an easy way to keep patchwork from getting stuck this way again. Jan 11 18:41:49 Is there a shortcut for "bitbake -c clean -c cleansstate && bitbake " ? Jan 11 18:49:12 "-c clean -c cleansstate" will do nothing, for one. or ather, it'll only run cleansstate Jan 11 18:49:21 -c only accepts a single task, it's not cumulative Jan 11 18:49:35 beyond that, no, any clean task really has to be done in a separate bitbake commandr ight now Jan 11 18:49:50 use shell aliases Jan 11 18:49:51 we've discussed possibly adding a clean runqueue to get around it, but it's not done yet Jan 11 18:49:55 yeah, i use a shell function for that Jan 11 18:50:03 and if you use memres it's even faster Jan 11 18:54:26 ok Jan 11 18:56:02 although "-c clean -c cleansstate" does seem to do what I expected here ... Jan 11 18:56:29 are there some deps between the tasks Jan 11 18:58:17 aye, so I only needed cleansstate :-) Jan 11 19:01:16 yes, it runs cl eansstate, and cleansstate already encompasses clean Jan 11 19:03:23 cleanall > cleansstate > clean Jan 11 19:10:07 now I just need to find doc on how to use/enable memres Jan 11 22:14:25 wooot checksum for the opkg tarball changes within a few hours, wtf Jan 11 22:25:45 is it a github generated tarball by chance? Jan 11 22:25:51 those are known to be regenerated Jan 11 22:40:53 ehm, not that often. also, it is pulled from https://downloads.yoctoproject.org/releases/opkg/opkg-0.4.0.tar.gz **** ENDING LOGGING AT Sat Jan 12 02:59:57 2019