**** BEGIN LOGGING AT Mon Feb 26 03:00:02 2018 Feb 26 05:15:15 yay! Feb 26 09:05:41 hello Feb 26 09:05:52 LetoThe2nd, hey Feb 26 09:06:38 hi? Feb 26 09:06:44 LetoThe2nd, :) Feb 26 09:06:58 LetoThe2nd, a few days back I 've asked for help with my SDK generation problem, right Feb 26 09:07:15 so you suggested to a clean , and rebuild (populate_sdk) Feb 26 09:07:17 possible Feb 26 09:07:19 I tried, and Feb 26 09:07:32 the thing is still seems failing to produce (or shall I say, reproduce) a correct SDK: Feb 26 09:07:47 that sdk *.sh / install file, is missing some files, and seems broken Feb 26 09:08:02 is there another clean I can do, but not deleting all downloaded source files, Feb 26 09:08:09 and all built object files ? Feb 26 09:09:39 you might want to find out what is actually goind on by inspecting the log files Feb 26 09:11:05 tmp/work/$YOURMACHINEARCH/$YOURIMAGE/$YOURIMAGEVERSION/temp should have all the needed information to start digging Feb 26 09:11:16 mokay :( Feb 26 09:42:57 hey huys, I'm trying to get an implementation of logger but I'm not entirely sure where to find one. We've got one from busybox, but that one doesn't allow you to save to a specific file, which is a feature we need. Anyone knows where else to look? cheers! Feb 26 09:44:04 hum, define logger? Feb 26 09:44:23 i mean, something like jsut dumping a specific part of the syslog to a file? Feb 26 09:44:28 logger as in the package that writes to /var/log/messages Feb 26 09:44:44 man logger should work on desktop ubuntu for you :) Feb 26 09:45:09 not sure I get it right yet but this is the package in question i need Feb 26 09:45:39 well my impression is taht said file is pretty much distribution specific Feb 26 09:46:37 hmmmm alright Feb 26 09:47:12 i mean, whats the actual problem? your code is already instrumented, prints out messages, and you want them to end up in a log file? Feb 26 09:47:25 or do you still need your stuff to be instrumented? Feb 26 09:47:57 the problem is that the busybox implementation of logger doesn't let us write to a file, and /var/log/messages ends up in volatile, which we want in non-volatile Feb 26 09:48:07 then just don't use busybox Feb 26 09:48:23 hahaha indeed, that's why I'm looking for an alternative implementation :p Feb 26 09:48:34 in case you're running systemd, theres little magic in setting it up that way as far as i can tell Feb 26 09:48:43 problem is, not sure how to look for it Feb 26 09:48:59 here you go: https://www.freedesktop.org/software/systemd/man/journald.conf.html Feb 26 09:49:00 sorry i don't get your last message LetoThe2nd Feb 26 09:49:16 oh nice! Feb 26 09:49:54 if your system is using systemd as its init/whatever infrastructure, then all should basically be in place already. just configure it according to your needs. Feb 26 09:50:18 very nice, any preferred method on how to write into the log via the systemd? Feb 26 09:50:41 I mean, I guess it assumes you are making a service, more than whatever you want Feb 26 09:50:47 cli: logger. c code: man 2 syslog ... Feb 26 09:51:06 alright, nice, I'll play around with this a bit, many thanks! Feb 26 11:20:59 Dear All, Feb 26 11:21:05 If I want to add a nativesdk-packagegroup-XXX to SDK/eSDK, then I shall put Feb 26 11:21:11 TOOLCHAIN_HOST_TASK_append = "nativesdk-packagegroup-XXX" in my ./distro/XXX.conf ? Feb 26 11:21:16 Or is there any better place to place it? Feb 26 12:29:46 Hey guys, for some reason the /var/log is symlinked to volatile/log when I build core-mage-minimal, is there a way to change this behaviour? Feb 26 12:30:55 flying_sausages: here you go: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-VOLATILE_LOG_DIR Feb 26 12:31:30 nice, found it, cheers! Feb 26 14:23:18 Is there a way to make recipe (or task) A DEPEND on recipe B, but not rebuild A if B rebuilds (sort of an "order only" dependency)? Feb 26 14:24:05 JPEWhacker: see SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS Feb 26 14:24:48 JaMa: Thanks Feb 26 14:37:35 Would it be "OK" to use SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "foo->${PN}" in a bbclass? Feb 26 14:46:48 Sorry, I guess that would actually be SIGGEN_EXCLUDE_SAFE_RECIPES_DEPS += "${PN}->foo" for my purposes. Feb 26 15:14:23 * kergoth yawns Feb 26 15:15:02 JPEWhacker: it'd have to be a class that's inherited via INHERIT, so it ends up in the configuration metadata, rather than a class inherited by recipes via inherit, but otherwise i suspect so Feb 26 15:15:33 kergoth: Ya, it's for icecream so that should be true. Feb 26 15:17:45 still a little iffy, since it's more bitbake configuration than anything, but it should work. the only alternative that comes to mind would be changing how icecream is enabled, i.e. include a config file that both sets that and adds the class to INHERIT, but that changes the semantics, so probably more trouble than it's worth Feb 26 15:19:33 Sure. Icecream is a little different that most bbclasses in that it should try really hard to *not* rebuild just because you change some configuration Feb 26 15:20:18 * kergoth nods Feb 26 15:23:09 If I may ask about eSDK Feb 26 15:23:18 https://wiki.yoctoproject.org/wiki/Application_Development_with_Extensible_SDK Feb 26 15:23:25 http://www.yoctoproject.org/docs/2.4/sdk-manual/sdk-manual.html#sdk-adding-native-tools Feb 26 15:23:52 Advise to use eSDK and all libraries with devtool to develop the required recipe Feb 26 15:24:04 but what about having other development tools ? Feb 26 15:24:27 Like - is it possible to bundle to eSDK build some IDE, or host specific tools ? Feb 26 15:25:00 to ease deployment of SW bundle for development (like eSDK) Feb 26 15:25:43 lukma: I think you'd have to write recipes for them Feb 26 15:35:51 JPEWhacker: And then I shall be able to run e.g. screen to facilitate development ? Feb 26 15:36:28 shall those be screen-native or nativesdk-screen ? Feb 26 15:36:39 lukma: Maybe... I don't think that you would necessarily want to do that though Feb 26 15:37:04 JPEWhacker: For me it would be better to provide VM image Feb 26 15:37:13 with recommended OS for developemtn Feb 26 15:38:10 lukma: Ya thats also an option. Its probably easier to make sure everyone has the host tools installed on their system consistently than to try and add all the possible ones they need to the eSDK Feb 26 15:45:28 lukma: you can use the eSDK with any IDE, just be sure to source the environment file first to set it up Feb 26 15:45:45 lukma: there's eclipse integration but its a bit lame right now, people are working on updating it now Feb 26 15:51:23 rburton: I would like to have clear distinction Feb 26 15:51:39 eSDK provides all the SW necessary for development Feb 26 15:51:57 our eSDK is just the toolchain and packages required to develop for the target Feb 26 15:52:10 if you want it to include an entire IDE then you best get writing recipes for your ide Feb 26 15:52:21 and then all the packages which facilitate development (eclipse, screen, etc) Feb 26 15:53:03 rburton: But then - shall I put those packages into recipes as package-native Feb 26 15:53:09 or nativesdk-package ? Feb 26 15:53:21 they'll be nativesdk not native Feb 26 15:53:44 nativesdk are binaries you can run on the host in a SDK Feb 26 15:55:33 rburton: I see Feb 26 15:56:12 rburton: Is it a common practice to put extra packages (recipes) into eSDK ? Feb 26 15:58:35 rburton: How often do you pull patches into mut? Feb 26 16:11:06 JPEWhacker: when i can, depending on what else i'm doing and how much review the patches need Feb 26 16:12:58 rburton: vauge, but works for me ;) Feb 26 16:13:21 JPEWhacker: if there's patches you feel might have been missed then just ping me/rp Feb 26 16:13:49 rburton: Ya, I wasn't complaining, just curious. Will do Feb 26 16:14:48 hi all. Just like with have the virtual "IMAGE_BOOTLOADER" used in machine definition, i would like to introduce a IMAGE_BOOTLOADER_UTILS virtual (to install the good uboot-fw-utils depending on machine) Feb 26 16:14:54 what would be the cleanest way to do that ? Feb 26 16:36:54 * armpit wow, I got a clean build... Feb 26 16:46:37 armpit: its scary when its a shock isn't it! :) Feb 26 16:51:54 yeah, considering it looked like the build hung.. Feb 26 16:53:02 how long will the old cluster be off-line? Feb 26 16:53:56 armpit: we have a dilemma there. Do we try and move to the new autobuilder codebase for 2.5 or wait :/ Feb 26 16:54:08 see the weekly status as I put a bit in there about this Feb 26 16:59:10 * armpit shot, means i need to read something. aah, no pictures Feb 26 17:04:17 I have a recipe that's defined in MACHINE_EXTRA_RRECOMMENDS (confirmed by bitbake -e). But it's not getting built. Feb 26 17:05:28 i'm inheriting core-image and not core-image-minimal Feb 26 17:08:09 RP, I am responding to the status report /me not sure if thats the correct method Feb 26 17:15:18 The recipe in question is meta-freescale/recipes-core/udev/udev-rules-imx.bb, which is appended to machine extra in imx-base.inc, which is included through my machine Feb 26 17:15:43 's conf file Feb 26 17:21:44 armpit: that is good, makes a nice change to see a reply to it Feb 26 17:24:10 RP: did you chase zeddii for the devsrc patch recently? Feb 26 17:25:34 * armpit just got a Benny Hill image of RP chasing zeddii Feb 26 17:25:40 lol Feb 26 17:25:46 rburton: I know he's working on it... Feb 26 17:27:51 It is under test here, and we are testing it with the 'remove the need to run make scripts' patch as well. Feb 26 17:28:44 it passes those tests. I planned to send it tomorrow, once I double check the commit and confirm that everyone is ok with me yanking all the kernel source out of devsrc .. that being said, it is all covered in the commit message. I can just send it once I rebase and confirm it. Feb 26 17:29:19 yay Feb 26 17:29:24 thanks zeddii Feb 26 17:32:56 zeddii, I have 4.1 x86 spectre backports done. waiting for internal builds before I send you a pull request. Feb 26 17:33:36 cool. sounds good. I'm doing a batch of merges tomorrow, so it won't take long to turn it around. Feb 26 17:34:09 zeddii: tomorrow is great. We can run the patch through our testing too once we have it... Feb 26 17:34:37 ok. I'll see if I can get it out late today my time, so it'll be waiting in the morning for everyone else. Feb 26 18:20:05 Is "shared state cache" the right thing to enable if I want to have multiple users share the same bitbake build environment? Feb 26 18:22:33 they wont' share the same build environment, but the binaries that come out of the build will be shared, avoiding unnecessary rebuilds Feb 26 18:25:04 Only the binaries are shared? How about intermediaries? Feb 26 18:29:42 Also, is there a "portable" version of do_configure / do_compile scripts? I'd like to build a source using the SDK / Toolchain, but it takes time to configure the configure/build commands manually.. Feb 26 18:33:25 Adam_: why would you want to share intermediaries? if you're rebuilding glib then having the .o files isn't useful, you're rebuilding... Feb 26 18:36:28 rburton: I want to compile recipes from another computer without having to build a 2nd bitbake environment. So I thought perhaps shared state cache was the trick. Feb 26 18:37:10 * armpit hmm, AB now as negative time to finish.. Feb 26 18:37:55 armpit: Awesome. I wish all my builds would have finished 5 minutes ago Feb 26 18:39:40 JPEWhacker, you can get them done in the future if you put a builded in India ; ) Feb 26 18:40:41 Adam_: yes, sstate shares the binaries (per recipe) so is exactly what you want Feb 26 18:41:26 rburton: Ok thank you. That's all I needed Feb 26 18:50:46 * armpit dang it. after a month with out rain, I water the lawn on Sat and today its raining Feb 26 18:52:57 anyone have an idea why my MACHINE_EXTRA_RRECOMMENDS aren't getting through? Feb 26 19:07:50 RP, rburton ignore my last email. got the answers Feb 26 19:08:22 i looked at the task dependency explorer, and I don't see packagegroup-base or packagegroup-core-boot, but these should be there via core-image.bbclass, right? Feb 26 19:42:25 ok, got it figured. I'm using the meta-agl layer and their images all derive from minimal, so none will use MACHINE_EXTRA_RRECOMMENDS Feb 26 19:44:09 should have bitbake -e for IMAGE_INSTALL, that would have pointed me in the right direction Feb 26 19:51:05 rburton: just sent a v3 for glibc 2.27 try that out Feb 26 19:51:31 I have created two workspaces to confuse myself now a days Feb 26 20:02:02 khem, only two, where is the challenge in that ; ) Feb 26 21:14:01 * armpit hmm, I wonder how I create an OE BSP layer Feb 26 21:14:13 * armpit all I can find is Yocto bsp layer Feb 26 21:14:45 i think you're confused. yocto's buildsystem is oe, along with poky as the demo distro. a yocto bsp layer is an oe bsp layer Feb 26 21:15:02 should probably have a bsp layer template for bitbake-layers new layer, if it doesnt' have one already Feb 26 21:15:57 the docs regarding BSP all refer to Yocto context.. ie using the yocto-bsd scripts which only existed in the poky Feb 26 21:16:39 so if I wanted to create a BSP layer.. its from the point of view of Yocto/poky Feb 26 21:17:06 armpit: nice typo! "yocto-bsd scripts" Feb 26 21:17:21 kergoth, yes, I am tend to be confused ; ) Feb 26 21:17:46 hehe bsd... Feb 26 21:19:37 i assume that you missed the 'o', and meant 'yocto-bsod', right? Feb 26 21:21:15 * armpit yocto-freebsd Feb 26 21:40:26 Hmm, I think I need something like SIGGEN_EXCLUDERECIPES_NATIVESAFE... looks like there is already a list of recipes that need this behavior ('quilt-native', 'subversion-native', 'git-native', 'ccache-native') and I need to add another one Feb 26 21:40:53 currently just a hardcoded list in sstate_rundepfilter() Feb 26 23:11:29 armpit: yocto-layers and yocto-bsp don't exist anymore anyway Feb 26 23:22:57 rburton, its the Yocto docs. Feb 26 23:24:40 armpit: we only deleted it in master so unless you're looking at the master docs it will still be mentioned Feb 26 23:25:46 correct. those scripts only exit in yocto rocky but not in OE... its an OE problem Feb 26 23:25:57 s/exit/exist/ Feb 26 23:28:26 but the "current" manual does point out "http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#creating-a-new-bsp-layer-using-the-yocto-bsp-script" Feb 26 23:28:58 not sure to bug it or if Scott will clean up Feb 26 23:29:17 as part of SOP for a new release Feb 26 23:29:37 current=rocko Feb 26 23:30:20 armpit: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/documentation/bsp-guide/bsp.xml?id=056cc0c1dab79df6911552a690ca6b4dc302cc8b Feb 26 23:30:55 well there is a 2.4.1 version too. Feb 26 23:31:14 so web links a bit confusing IMHO Feb 26 23:31:26 current/ is an alias Feb 26 23:31:51 for the current release Feb 26 23:31:56 so is there a dev version ? Feb 26 23:32:06 yeah /inprogress/ Feb 26 23:32:18 its missing lots of content right now as its more in progress than usual :) Feb 26 23:32:25 (there's a bit of a doc refactor going on) Feb 26 23:32:40 * armpit wow, would have never guessed that one "inprogress" Feb 26 23:32:58 well there's a big link on the front docs pae Feb 26 23:33:01 * armpit its like talking to the wife.. wrong at every turn Feb 26 23:33:10 https://www.yoctoproject.org/documentation/inprogress Feb 26 23:33:16 "In-Progress Documentation" Feb 26 23:48:03 zeddii, regarding kernel fragments.. is there on regarding the enabling vulnerability for meltdown and spertre? Feb 27 00:03:55 armpit: they're default y I believe Feb 27 00:04:48 k. Feb 27 00:06:38 armpit: with a qemux86-64 build I see the following: Feb 27 00:06:38 CONFIG_PAGE_TABLE_ISOLATION=y Feb 27 00:06:38 CONFIG_RETPOLINE=y Feb 27 00:07:26 cool. thanks Feb 27 00:07:50 * armpit is a dork and could not see in on his arm board.. Feb 27 00:12:36 armpit: could be different for arm Feb 27 00:12:43 contents of /sys/devices/system/cpu/vulnerabilities/ might help Feb 27 00:15:49 re meltdown/spectre.. there is no specific fragement as the default is to enable mitigations.. Feb 27 00:16:09 if you did NOT want the mitigations enabled by default you would need to create a fragment to disable it.. (better to just use the kernel command line switch(es) Feb 27 00:30:49 fray, in the early patches you had to enable it. I believe its on by default now. its the sysfs part. dont' recall if it a bool or selectable. Feb 27 00:31:39 * armpit too many changes Feb 27 00:37:05 the meltdown version (Rocko) does not yet have the /sys stuff in it.. Feb 27 00:37:11 that will likel come in 4.18.21 Feb 27 00:37:35 the rocko work is based on roughly the January 17th series of work.. Feb 27 00:37:52 the sys inteface, spectre and other stuff came after that.. but the 'on-by-default' existed by then Feb 27 00:53:48 Attempted a bitbake core-image-sato using 2.4.1... It cannot find gtk-doc-native-1.25-r0. It gives the URL and I see file at http://ftp.gnome.org/pub/GNOME/sources/gtk-doc/1.25/. Anyone know anything about this error? Feb 27 01:27:09 Using mirrors fixed the issue with my build :) **** ENDING LOGGING AT Tue Feb 27 03:00:01 2018