**** BEGIN LOGGING AT Mon Jul 10 03:00:03 2017 Jul 10 07:37:22 hi, I'm adding license details from recipes to buildhistory so that I can do some checks after build to recipe which we use, but changes to buildhistory are not used until recipes are compiled from sources, and we happen to use sstate heavily. Is there a way to force rebuilds of everything, or better yet force checking buildhistory recipe data from sources? Jul 10 07:51:50 mcfrisk: where did you make your changes? Jul 10 07:59:55 bluelightning: in buildhistory.bbclass Jul 10 08:00:08 mcfrisk: sorry I meant in which function in there Jul 10 08:01:50 I thought I catched all cases by editing: buildhistory_emit_pkghistory, write_recipehistory, write_pkghistory Jul 10 08:02:20 and when recipe is recompiled, the data is filled for recipes and binary packages Jul 10 08:04:00 hmm: sstate_install[vardepsexclude] += "buildhistory_emit_pkghistory" Jul 10 08:04:06 that explains it Jul 10 08:14:11 if got it right, buildhistory_emit_pkghistory is ignored in by sstate cache signature checks and changes to it don't retrigger any rebuilds. But why? Because enabling/disabling builhistory shouldn't trigger rebuild of everything? For image and sdk's the buildhistory data is always written out, and for SRCREV in.. Jul 10 08:14:30 write_srcrev Jul 10 08:36:29 mcfrisk: that's correct, we don't want enabling buildhistory to cause a whole bunch of tasks to re-execute Jul 10 08:37:14 if you want the data repopulated though you can just delete your TMPDIR and it'll get repopulated as it's restored from sstate Jul 10 08:38:42 bluelightning: in jethro at least, deleting tmp doesn't help, to add new data to buildhistory, like LICENSE, I need to rebuild all recipes. Jul 10 08:39:20 I think I will take that sstate cache signature check out from our tree. we want buildhistory always and we want it to be uptodate. Jul 10 08:40:02 mcfrisk: hmm, I can't immediately explain that... the code should be executed regardless of whether it's restoring from sstate or not Jul 10 08:41:00 bluelightning: problem is data in sstate is not uptodate with changes to buildhistory.bbclass. E.g. the added LICENSE field is not in ssate cache. Only way to regenerate the recipe data is to force a rebuild. Jul 10 08:41:26 mcfrisk: yes but the buildhistory data does not go into sstate, that's the thing Jul 10 08:42:46 bluelightning: hmm, then I can't explain from where buildhistory is pulling old data. Maybe from git history? Not from files in buildhistory since we wipe it clean before building everything to make sure old packages and images are removed from there. Jul 10 08:43:18 mcfrisk: don't know, unfortunately I'm a bit short of time to debug it at the moment Jul 10 08:43:29 we really should have a test for this sort of thing but at the moment we don't Jul 10 08:44:35 bluelightning: ok, thanks anyway. I can hopefully work around this. And I should send patches upstream.. sadly our jethro is, well getting funky.. Jul 10 08:47:59 gah, wiping buildhistory and building busybox with 100% sstate hits results in no data about busybox in buildhistory directory :( Jul 10 09:06:52 hi o/ Jul 10 09:07:17 In a .bbclass I have overloaded do_fetch but it is never call even if I do "EXPORT_FUNCTIONS" Jul 10 09:09:38 don't set EXPORT_FUNCTIONS as thats probably why its not working :) Jul 10 09:09:46 just do_fetch() in your class, and inherit it in the recipe Jul 10 09:11:40 hum I though it was necessary to tell yocto that we are overloading "base tasks" Jul 10 09:11:53 nope Jul 10 09:12:06 just like if you want to override do_compile you just write do_compile() Jul 10 09:12:16 EXPORT_FUNCTIONS is for more complicated uses Jul 10 09:14:13 lol it works xD Jul 10 09:14:55 "do_compile" and not "classname_do_compile"? Jul 10 09:16:18 using export functions and the classname prefix just complicates things Jul 10 09:16:30 ok Jul 10 09:16:44 doc is not really clear on that. Jul 10 09:16:46 but ok Jul 10 09:17:04 docs shoud just say if you want to replace a task, just write do_whatever() Jul 10 09:17:40 ok Jul 10 11:14:29 Hi all, I'm new here so please excuse me if my question is strange :) I have an issue after upgrading to Krogoth due to the following commit: d3ee5489c9 Jul 10 11:15:32 which issue s_jankowitsch ? Jul 10 11:15:45 It causes my source directory to be deleted. The thing is, the source is not fetched from anywhere else but is part of my git repo. Jul 10 11:16:36 I was expecting this only to clean the source dir if SRC_URI is not empty, but this is not the case. Jul 10 11:16:50 Is my config uncommon or is that a bug? Jul 10 11:17:10 Is my config uncommon or is that a bug in OE? Jul 10 11:18:32 Jethro had a comment: TODO: Investigate if we can remove -> the question is, was this use case maybe not considered? Or is it just invalid? :) Jul 10 11:34:51 hi, I'm sorry if this has been asked a thousand times but I having trouble googling a good solution... Jul 10 11:36:28 I want to in a generic way, build image a, archive everything in deploy, then do _something_ (clean etc), build image a-dev, and archive everything in deploy just like if this was a clean build Jul 10 11:36:53 but I want to do it as fast as possible, these images are very similar variants Jul 10 11:48:24 sstate cache is pretty fast but it would be nice to avoid setting up all the sysroot and x86_64-linux/ stuff again Jul 10 12:14:00 hello, is anyone using weston on i.MX 6 here? Jul 10 12:14:48 I am doing Yocto builds with Variscite BSP based on Yocto Morty ... to remove screen tearing I followed the advice described here: https://community.nxp.com/thread/450727 Jul 10 12:15:03 I removed screen tearing, but it reappears after wakeup from suspend to RAM Jul 10 12:15:26 the meta-freescale layer in Yocto uses a patch for weston to enable the g2d-renderer for it: https://github.com/Freescale/meta-freescale/blob/master/recipes-graphics/wayland/weston/0002-MGS-2521-ccc-Enable-g2d-renderer-for-weston-1.11.patch Jul 10 12:15:43 that is why weston on my platform uses the FB_MULTI_BUFFER environment variable Jul 10 12:15:55 I added export FB_MULTI_BUFFER=4 to the beginning of the script /usr/bin/weston-start Jul 10 12:16:15 It removed screen tearing, but it reappears after wakeup from suspend to RAM Jul 10 12:17:29 still, I am very unsure where is the proper place to source the environment variable or what fixes I should do to avoid screen tearing after waking up after suspend to RAM Jul 10 12:32:20 eduardas_m: my impression is that wayland on iMX is a quite immature implementation still... Jul 10 12:33:01 with the binary blob driver Jul 10 12:36:16 ernstp: so what would be your recommended backend usable with Qt Quick 2 on this platform? Jul 10 12:36:33 doesn't X11/egl work? Jul 10 12:37:10 haven't tried it myself Jul 10 12:38:20 ernstp: they do... haven't really checked for screen tearing and suspend issues yet though Jul 10 12:38:22 Hi all =) Jul 10 12:38:33 How do you SRC_URI from a Private repo in gitlab? Jul 10 12:38:42 I have generate SSH Keys Jul 10 12:39:00 I have already put the public key to the gitlab part Jul 10 12:40:23 ernstp: the thing is that it would be kind of disappointing to use x11 when everything in the Linux space seems to be moving to wayland Jul 10 12:40:48 eduardas_m: though I guess the support is pretty widespread... http://doc.qt.io/qt-5/embedded-linux.html Jul 10 12:41:24 ernstp: AFAIK Wayland is already used by AGL (Automotive Grade Linux) Jul 10 12:41:34 eduardas_m: sure, but proprietary+embedded and you're 10 years back :-) Jul 10 12:41:56 eduardas_m: yeah I'm not saying that Wayland in itself is immature, I think it's quite nice these days Jul 10 12:42:13 but specifically the iMX support seems a bit sketchy imho Jul 10 12:42:28 ernstp : Any problem with I.MX6? ahah Jul 10 12:42:59 ChrysD: eduardas_m's problem :-) Jul 10 12:43:42 ernstp : I'm new in embedded world and I faced with lot of problems with I.MX6 and I see that working with that stuff is more like a nightmare then a heaven... So much problem with that. Jul 10 12:43:58 ChrysD: your SRC_URI stuff should work fine, what did you try... ? Jul 10 12:44:24 ernstp : Nothing for now. I try to get a file from a private repo in gitlab. Jul 10 12:44:27 ChrysD: https://www.yoctoproject.org/irc/latest.log.html#t2017-07-10T12:14:00 Jul 10 12:44:48 ChrysD: if you have experience with wayland on imx6, I would be glad to hear it Jul 10 12:45:27 I worked a bit with iMX6+yocto, I thought meta-freescale was nice and well maintained, and the X11 environment was quite stable Jul 10 12:45:40 yeah meta-freescale seems very good Jul 10 12:45:43 video decode acceleration and graphics acceleration worked fine Jul 10 12:45:57 but i didn't worked with a board that support meta-freescale :s Jul 10 12:45:59 did some multimedia/html5 stuff... Jul 10 12:46:27 ernstp: so no screen tearing? Jul 10 12:46:31 eduardas_m : not really Jul 10 12:46:37 eduardas_m : i don't have screen tearing to Jul 10 12:46:51 ChrysD: on x11? Jul 10 12:47:00 eduardas_m: didn't do suspend/resume... Jul 10 12:47:29 khem: i think you need to push your localedef repo Jul 10 12:48:47 ernstp: you were doing a fullscreen app on x11? what compositor were you using? Jul 10 12:49:10 eduardas_m: yes. no compositor. Jul 10 12:50:17 no need to use a compositor if you have a fullscreen app? Jul 10 12:50:23 ernstp: I only worked with sato images that include matchbox when using x11 Jul 10 12:50:49 so I am not sure how to configure x11 for a fullscreen app Jul 10 12:51:04 I am still very new to embedded linux Jul 10 12:53:24 eduardas_m : DISTRO_FEATURES_remove = "argp irda pcmcia zeroconf x11 ptest multiarch wayland" Does it means that i don't use wayland and x11? Jul 10 12:56:34 eduardas_m : i think I don't need one. I use Eglfs from Qt + KMS as output. SO I don't have window manager. ( But as I don't really understand the graphics management in Linux, I can't really help you ). Jul 10 12:57:03 eglfs seems interesting, never tried it Jul 10 12:57:39 From Qt website : EGLFS is a platform plugin for running Qt5 applications on top of EGL and OpenGL ES 2.0 without an actual windowing system (like X11 or Wayland). Jul 10 12:57:52 So yeah I think i'm not using X11 and wayland. Jul 10 13:03:03 if you want to try X11 start with modifying matchbox-session: https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-graphics/matchbox-session/matchbox-session/matchbox-session Jul 10 13:08:16 ChrysD, ernstp ok thank you both for the information, will try to dig deeper myself Jul 10 13:09:46 https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_change_and_add_startup_scripts Jul 10 13:23:51 * zeddii pops up from vacation Jul 10 13:37:25 rburton: I acked the mesa patch; it works just fine here Jul 10 13:37:33 just saw, already in mut Jul 10 13:38:06 rburton: great. It does seem to be the best approuch Jul 10 13:38:28 rburton: I will fix meta-freescale to stop referring to egl for platform setting Jul 10 13:39:20 rburton: I also noticed that the etnaviv fix was merged on master. Thanks! Jul 10 13:40:58 hello Jul 10 13:41:08 uhoh Jul 10 13:41:26 hello rburton Jul 10 13:41:41 hi robsta! Jul 10 13:41:57 we talked about packaging an rpm using bin_package Jul 10 13:42:08 seems to work as expected but 2 questions: Jul 10 13:42:13 what does this mean http://www.yoctoproject.org/docs/1.6.3/ref-manual/ref-manual.html#ref-classes-bin-package Jul 10 13:42:19 i don't understand the "note" Jul 10 13:42:20 1.6.3?! Jul 10 13:42:42 so, bin_package assumes that you've unpacked stuff into ${S} Jul 10 13:43:12 but the default value of S is PN-PV, ie libfoo-1.2 Jul 10 13:43:31 which RPMs don't have as they contain a file system structure, so they unpack ./usr/bin/foobar Jul 10 13:43:32 ok Jul 10 13:43:44 (google came back with that link) Jul 10 13:43:59 it still seems to work Jul 10 13:44:09 so, tell the unpack code to create a directory PN-PV to put the archive into Jul 10 13:44:22 BP is shorthand for BPN-PV Jul 10 13:44:31 related question, what's the easiest way to put the rpm content only into the SDK, not target image? Jul 10 13:44:46 put it in TOOLCHAIN_TARGET_TASK in the image recipe Jul 10 13:44:58 eg TOOLCHAIN_TARGET_TASK_append = " libfoo" Jul 10 13:45:25 cool, thanks rburton Jul 10 14:11:51 Hi, I'm currently trying to activate coloured output on my yocto image with the use of nano. I'm connected via ssh/putty. Putty has the standard options but it shows no colour. If I type in ls --color=auto I get a coloured output so I know that it has to be possible somehow. But the nanorc file is missing so I don't know where this is hidden now. Anybody who already activated coloured output on his image? Jul 10 14:26:54 Maybe your TERM is set wrong? Jul 10 14:30:42 I_need_colour: try 'tput colors' Jul 10 14:31:39 Also make sure you have ncurses-terminfo-base and ncurses-terminfo installed Jul 10 14:37:19 for cleaning tmp/deploy/images/, what do you think about bitbake-layers show-recipes -i deploy | sed ... | xargs bitbake -c clean ? Jul 10 14:41:06 tput colors returns 8 - I have no clue what this means for me :) I added include "/usr/share/nano/c.nanorc" to the ~./nanorc file and it puts out some colors but at the same time everytime that I start nano it always puts out a lot of error e.g. Error on line 8 : Bad regex "[[:<:]] (for|if|while|do|else and about 10 more errors Jul 10 14:59:44 Ah I found a way a bit tricky but now it works. The error are coming from \< and \> in the c.nanorc files that have to be replaced with \b. If this is changed no more errors and one can manually add them to ~/.nanorc Jul 10 15:01:22 Now only one more step until I will find out how I can make ls --color=auto a continous state Jul 10 15:18:47 I_need_colour: The output of `tput colors` is the number of colors ncurses tells applications are supported by your terminal when the applications ask for that Jul 10 15:19:14 You should make that print 256 if you want good color support (ls will still no auto-enable color support, but other applications will) Jul 10 15:20:30 ncurses looks at the $TERM environment variable to determine whether your terminal supports colors. In most cases, $TERM is forwarded over SSH (for putty, you can configure the value in the settings, make sure it's xterm-256color for example) Jul 10 15:21:51 In addition, ncurses needs certain database files matching the value of the $TERM environment variable, e.g. one for xterm-256color. Those are in /usr/share/terminfo ad shipped by the ncurses-terminfo-base and ncurses-terminfo packages, so you should have those installed. Jul 10 18:30:12 I am trying to build a binary for the Beaglebone PRU. I need to first compile the pasm assembler on the host. Is there a good example recipe on how to do something like this? Jul 10 18:42:10 rburton: u-boot is released Jul 10 18:42:20 rburton: i sent the final patch Jul 10 19:02:18 rburton: are there tests with read-only rootfs and systemd as init system? systemd-tmpfiles-setup.service and ldconfig.service are unhappy because they can't write. Jul 10 19:03:27 There are indeed several tmpfiles.d entries which do not exit in the read-only rootfs. We probably need some mechanism similar to sysusers.d, where these settings are applied to the rootfs during image creation. Jul 10 19:04:43 And ldconfig.service needs to be checked why it isn't happy with the existing, pre-generated ldconfig. I think it also (unnecessarily) re-generates that during each first-boot. Jul 10 19:05:02 Are these known problems or should I file bugs? Jul 10 19:05:56 why should tmpfiles be created at rootfs time? they're temporary and should only exist in the running system image and then be discarded on power-off Jul 10 19:13:57 pohly: maybe that cobination is missing, please file bugs Jul 10 19:15:53 (FYI, in my own builds -- I typically disable the ldconfig processing. It's unnecessary and causes problems with these types of systems.. however if it IS enabled, it should work properly -- I'll let others define what 'properly' is. I wouldn't be surprised if the ldconfig.service was to run ldconfig on every boot) Jul 10 19:16:11 pohly: I suspect it is missing. I've encounter a few bugs WRT to that combination as well Jul 10 19:17:19 Hm, I recall some funny business with ldconfig back then… let me check my logs. Jul 10 19:17:19 fray: tmpfiles.d is used for all kinds of things, including the creation of config files or directories in /etc. Jul 10 19:17:52 that doesn't sound like it's being used properly then Jul 10 19:19:06 It's part of systemd's "restore factory settings" mechanism. We either need to make sure that the system has those settings (my preferred solution) or modify the configuration so that the mechanism doesn't throw errors when used in a read-only system. Jul 10 19:19:54 pohly: Are you seeing the ld.so.cache regeneration with an x86_64 target? Jul 10 19:20:17 neverpanic: yes Jul 10 19:20:58 I don't happen to have any builds with systemd enabled currently.. so it's difficult for me to check Jul 10 19:22:15 nevermind, the issue I had in mind is already fixed: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch?id=3ece01215a7b038dbd5cde313754c42d134a887f Jul 10 19:32:05 I've filed YOCTO #11777 and YOCTO #11776. Jul 10 21:54:18 rburton: i have updated the branch with right SRCREVs, replied to your email as well Jul 10 21:55:32 khem, hi, the klibc patch did not land in patchwork apparently, maybe a missing square bracket [meta-initramfs]? Jul 10 21:56:40 ant_home: ah yes Jul 10 21:57:20 ant_home: I am seeing some local failures which probably are new because not klibc is building so dependend recipes are failing now since they never built for me in past Jul 10 21:57:25 I need to check that Jul 10 21:57:40 mwanwhile it will be good if you can test it out Jul 10 21:57:42 on arm Jul 10 21:57:50 ah, ok, with musl obviously Jul 10 21:58:22 actually with both Jul 10 21:58:27 since some changes are common Jul 10 21:58:34 with glibc all is fine, at least with gcc6.x Jul 10 21:58:41 ok thats cool Jul 10 21:58:52 then try musl Jul 10 21:58:58 I mean klibc-static binaries Jul 10 21:59:14 yeah I have changed flags Jul 10 21:59:23 it's long I tested shared Jul 10 21:59:26 atleat for armv7+ it might be different Jul 10 21:59:35 do you use rpi ? Jul 10 21:59:37 as well Jul 10 22:00:03 no Jul 10 22:01:15 khem, btw there is a new kernel regression in 4.13-rc so I really must use an old gcc6 for a while Jul 10 22:01:53 otherwise I'd add new variables to the mix Jul 10 22:05:17 khem, once fixed klibc the last open issue I have seen is OPIE with musl Jul 10 22:05:34 lacks some definitions Jul 10 22:05:51 does anyone here use ccache.bbclass? Jul 10 22:07:53 you mean still skips that explicitely? Jul 10 22:09:13 I personally abandoned it long ago, tmpfs is much better solution to improve build time Jul 10 22:09:29 ant_home: yeah I would suggest to stick to one variable at a time Jul 10 22:09:50 rburton: I know some users who deal with webkit Jul 10 22:09:52 yeah :/ Jul 10 22:09:53 use it Jul 10 22:10:15 they come from buildroot world Jul 10 22:10:43 * rburton has some patches and wants to make sure it still works properly :) Jul 10 22:11:03 poky-contrib:ross/ccache, i'll clean up messages and post to the list tomorrow Jul 10 22:12:40 huh Jul 10 22:12:43 khem: ERROR: Nothing PROVIDES 'virtual/none-poky-none-binutils'. Close matches: Jul 10 22:12:43 virtual/x86_64-poky-linux-binutils Jul 10 22:13:11 autobuilder blew up all over with that with your series in Jul 10 22:14:49 Missing or unbuildable dependency chain was: ['core-image-minimal', 'buildtools-tarball', 'virtual/none-poky-none-binutils'] Jul 10 22:14:59 works for me though : Jul 10 22:47:03 * clsulliv just remembered I'm on SWAT duty this week Jul 10 22:47:10 * clsulliv starts looking over buildlog Jul 10 22:47:24 rburton: I wonder which patch could do that Jul 10 22:50:48 is it some hidden issue that its bringing to front seems to me **** ENDING LOGGING AT Tue Jul 11 03:00:03 2017