Wednesday, 2017-10-04

*** sgw <sgw!swold@nat/intel/x-hvvllkwulxgrjtci> has quit IRC00:06
*** scottrif <scottrif!> has left #yocto00:07
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:12
*** Snert__ <Snert__!~snert_@> has quit IRC00:18
*** berndhs <berndhs!> has quit IRC00:22
*** jg <jg!~jg@2601:18f:981:82c5:a800:914c:7bb3:48f7> has quit IRC00:34
*** nighty- <nighty-!> has joined #yocto00:37
*** zarzar <zarzar!> has quit IRC00:57
*** zarzar <zarzar!> has joined #yocto00:57
*** msvb-lab <msvb-lab!> has quit IRC01:04
*** majuk <majuk!> has joined #yocto01:08
*** majuk <majuk!> has quit IRC01:13
*** sjolley <sjolley!sjolley@nat/intel/x-ciqxqwbmfqgkmnhx> has quit IRC01:15
*** sjolley <sjolley!~sjolley@> has joined #yocto01:16
*** msvb-lab <msvb-lab!> has joined #yocto01:17
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has quit IRC01:20
*** demonimin <demonimin!~demonimin@> has joined #yocto01:24
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto01:24
*** sgw <sgw!> has joined #yocto01:53
*** stephano <stephano!~stephano@> has quit IRC01:56
*** sgw1 <sgw1!~swold@> has joined #yocto01:56
*** sgw <sgw!> has quit IRC01:57
*** sgw1 is now known as sgw02:09
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto02:35
*** bavery_fn <bavery_fn!bavery@nat/intel/x-fcyewideeesvwxyf> has joined #yocto02:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC03:03
*** RP1 <RP1!> has quit IRC03:06
*** dreyna <dreyna!> has quit IRC03:12
*** martinkelly1 <martinkelly1!> has joined #yocto03:29
*** martinkelly1 <martinkelly1!> has quit IRC03:58
*** learningc <learningc!> has joined #yocto04:05
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC04:15
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto04:16
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:23
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC04:44
*** gtristan <gtristan!~tristanva@> has quit IRC04:50
*** AndersD <AndersD!> has joined #yocto05:09
*** gtristan <gtristan!~tristanva@> has joined #yocto05:14
*** AndersD <AndersD!> has quit IRC05:18
*** AndersD <AndersD!> has joined #yocto05:20
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC05:20
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto05:29
*** sjolley <sjolley!~sjolley@> has quit IRC05:35
*** sjolley <sjolley!~sjolley@> has joined #yocto05:36
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto05:37
*** quite <quite!quite@unaffiliated/quite> has quit IRC05:48
*** nandi_ge___ <nandi_ge___!~nandor@> has quit IRC05:58
*** open-nandra <open-nandra!> has joined #yocto05:58
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto06:05
*** zerus_ <zerus_!> has joined #yocto06:09
*** pohly <pohly!> has joined #yocto06:11
*** aurele <aurele!> has quit IRC06:18
*** aurele <aurele!> has joined #yocto06:18
*** agust <agust!> has joined #yocto06:34
*** Kakounet <Kakounet!> has joined #yocto06:39
*** hnje <hnje!~hnje@> has joined #yocto06:44
*** Bunio_FH <Bunio_FH!> has joined #yocto06:52
*** vdehors <vdehors!~vdehors@> has joined #yocto06:54
*** fl0v0 <fl0v0!> has joined #yocto06:55
*** mdnneo <mdnneo!~umaucher@> has joined #yocto06:56
*** kpo <kpo!> has joined #yocto07:01
*** kpo <kpo!> has quit IRC07:02
*** t0mmy <t0mmy!~tprrt@> has joined #yocto07:03
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC07:04
*** kpo <kpo!> has joined #yocto07:05
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto07:10
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC07:11
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto07:11
*** mtahmed <mtahmed!b8178784@gateway/web/freenode/ip.> has quit IRC07:12
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:542:cbc3:487e:1c37> has joined #yocto07:15
*** grma <grma!~gruberm@> has joined #yocto07:16
*** rob_w <rob_w!~bob@> has joined #yocto07:16
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:16
*** rubdos <rubdos!> has quit IRC07:30
*** rubdos <rubdos!> has joined #yocto07:34
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto07:40
*** diego_r <diego_r!~diego@> has joined #yocto07:42
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:542:cbc3:487e:1c37> has quit IRC07:45
*** ant_work <ant_work!> has joined #yocto07:51
*** edgar444 <edgar444!uid214381@gateway/web/> has joined #yocto07:52
*** kpo <kpo!> has quit IRC07:53
*** toscalix <toscalix!~toscalix@> has joined #yocto07:59
*** joshuagl <joshuagl!joshuagl@nat/intel/x-khnwhlcvclnjxmwr> has joined #yocto08:05
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:12
*** _AndersD <_AndersD!> has joined #yocto08:17
*** AndersD <AndersD!> has quit IRC08:17
learningcWhen I bitbake -c menuconfig virual/kernel , where is my .config saved in the poky directory?08:53
LetoThe2ndlearningc: in the unpacked source tree of the kernel, AFAIK. doesn't the kernel-dev manual by the yocto project explicitly state it?08:55
*** cornel <cornel!~cornel@> has joined #yocto08:56
cornelis there a way to configure bitbake so that it will NOT rename bad checksum files?08:57
cornelbecause: we are several users, and most of us have updated the recipe to the latest version, which contains the right checksum but several have the old broken recipe and everytime they try to build, the file gets renamed08:58
cornelso, from time to time, some of us fix the filename again08:59
cornelwhich leads to unpredictable results08:59
cornelwsn't bitbake designed with multi-users in mind?09:00
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:00
LetoThe2ndcornel: multiple users on a shared sstate, but not multiple users on a single working copy.09:01
cornelso the source files must be unique for each user?09:01
LetoThe2ndwhich source files?09:01
*** ChrysD <ChrysD!c16cc543@gateway/web/freenode/ip.> has joined #yocto09:01
cornelthese files that get renamed09:02
cornelwe have some local mirrors09:02
LetoThe2ndcornel: are we talking about the recipes? the application sources?...09:02
ChrysDHi all, my ##OEROOT## seems not working. From which "branch" of poky does the ##OEROOT## works ?09:02
cornelnot recipes09:02
cornelthe recipes take the binaries from a common directory09:02
cornelLetoThe2nd, ^09:02
cornellike archives09:02
LetoThe2ndcornel: i admit i don't get what you are sharing, and what not. the point is, multiple users are meant to share a) the download directory b) the sstate-cache. they are *not* meant to share a common build directory.09:03
cornelLetoThe2nd, that's fine, it's not about a common build09:04
corneland as a side note, i know is not working for the common download directory09:04
cornelat least not always09:04
cornelbut that's another story09:04
*** rburton <rburton!> has joined #yocto09:06
cornelanyway, let's go back to the original question: can bitbake be configured to not rename bad checksum files09:09
rburtonwhats the problem?09:11
cornelthe problem is that one bad recipe contained a bad checksum09:12
corneland we are many users09:12
cornelthe recipe was fixed but not all users did this09:12
corneland all those who did not, keep renaming the source files which prevents the build for those that have the right recipe09:12
rburtonhow would changing bitbake configuration help, as you'd have to push that to the users that haven't updated the recipe? :)09:13
cornelso we have to keep renaming the file back from time to time09:13
rburtonif you have a read only source mirror you can stop that sort of thing09:13
cornelif the rename does not happen, the problem is only to the users that have not update\09:13
cornelrburton, good point09:13
corneli have to try this :)09:14
rburtonread only, populated in a cron job09:14
rburtonthe fix is to get the users to update, obviously.  no matter what the solution is, you need to get the users to update *something*09:14
*** linus_ <linus_!> has joined #yocto09:14
cornelrburton, thank you, the read-only trick may be good enough09:15
*** rovanceo_ <rovanceo_!~rovanceo@> has quit IRC09:16
cornelrburton, right, but if one is in romania, another in malaysia, another in germanu and another in usa, and there are also some automated builds controled by another team(s), syncing all get a little complicated09:16
cornelas said, if the rename is not happening, all users that update are good, and those are not will read the signs :)09:16
rburtoni wonder if bitbake stops if the bad checksum filename already exists09:17
rburtonyou could touch it, then tell everyone  to update if they get the error.09:17
*** rovanceo_ <rovanceo_!~rovanceo@> has joined #yocto09:21
ChrysDI wanted to update my bblayers to the ##OEROOT## version and get problems. "Unable to parse ##OEROOT##/meta/conf/layer.conf": file ##OEROOT##/meta/conf/layer.conf not found in /home/user/Yoctodir/build.... I don't know why he is searching in the build dir. I thought OEROOT is the absolute path to where oe init setup is...09:30
cornelto conclude, i'd like to request this enhancement: stope renaming bad checksum files09:31
cornelor maybe there is a hidden benefit for this that i don't know09:32
rburtonChrysD: doesn't ##OEROOT## get transformed if you use it in a bblayers.conf.template, not in bblayers.conf09:32
*** gtristan <gtristan!~tristanva@> has quit IRC09:32
ChrysDrburton : oh ok, so it's when i charge with TEMPLATECONF that oeroot get transformed, thanks !09:33
ChrysDrburton : i get the template conf only when i do oe-initsetup... or there is a way which we can do a kind of "bitbake <image> <templateconf>" ?09:34
rburtonthe template is only used when you populate a new build directory, that's right09:34
*** gtristan <gtristan!~tristanva@> has joined #yocto09:37
ChrysDrburton : thanks.09:38
ChrysDrburton : i offer you a coffee.09:38
zerus_Is their an easy way to clean/invalidate the sstate of a specific recipe from within the recipe itself? To force that the packages is rebuilt from scratch every single time.09:43
LetoThe2ndzerus_: depends on the reason you want for forcing to rebuild09:44
LetoThe2ndzerus_: if its about aplicaiton development, you probably want externalsrc09:44
zerus_LetoThe2nd: It's a temp solution for picking a application binary built from an external sysroot. That always will be picked from the same location (which of course will fool the sstate). I will lokk into externalsrc09:45
LetoThe2ndzerus_: sounds like it would probably fit09:47
rburtonzerus_: why not just put the full path in SRC_URI?09:48
*** rauz <rauz!> has joined #yocto09:52
zerus_rburton: hmm yeah, that would probably work. Then the normal mechanism will handle new checksums of the binary pointed out by SRC_URI I guess? I will give it a shoot09:53
cornelrburton, in our particular setup, even without write and execute rights, if i'm a member of the group, i can still mv file filebad09:54
cornelmaybe it's a problem in our setup09:54
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:54
rburtonyou just need access rights on the parent directory09:54
rburtonso it comes down to how does bitbake do the rename09:55
rburtonmv will do the right thing, but the syscalls bitbake uses may be different09:55
corneli see :(09:55
cornelmaybe using a git large filesystem would fix this09:56
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC09:58
*** vdehors <vdehors!~vdehors@> has quit IRC09:58
learningcafter I bitbake -c compile, where does it put the image? I cannot find it in deploy/images/board10:09
*** yann <yann!~yann@> has joined #yocto10:10
LetoThe2ndlearningc: compile does just what it says, it compiles10:14
LetoThe2ndlearningc: just bitbake the target recipe without command, so it does the whole process10:15
learningcThe target recipe or the target kernel?10:15
learningcI meant, image recipe or kernel recipe10:16
LetoThe2ndif its the kernel, just do bitbake virtual/kernel10:16
learningcThen it will produce the image of the kernel?10:16
LetoThe2ndit should10:16
learningcI have removed networking from the kernel, but when I bitbake, I get an error, how can I fix this?10:27
*** |King_InuYasha| <|King_InuYasha|!> has quit IRC10:28
*** King_InuYasha <King_InuYasha!> has joined #yocto10:28
*** King_InuYasha <King_InuYasha!~kvirc@fedora/ngompa> has joined #yocto10:28
rburtonlearningc: helps if you say what the error is10:28, do_compile) failed with exit code '1'10:29
melonipoikaopen-nandra how is your upgrade to pyro going?10:29
learningccannot compile10:29
melonipoikawe just managed to build an image :-)10:29
melonipoikait wasn't too painful, a few build time dependencies missing in some of our recipes, remote True from calls to getVar and pretty much that's it10:30
learningcarch/arm/mach-shmobile/built-in.o: In function `mmd_write_reg.constprop.1':10:30
learningc| :(.text+0x12d4): undefined reference to `mdiobus_write'10:30
learningcI get errors like this10:30
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC10:30
learningcarch/arm/mach-shmobile/built-in.o: In function `r8a7790stoutfull_add_standard_devices':10:31
learningc| :(.init.text+0x43f8): undefined reference to `phy_register_fixup_for_uid'10:31
learningcanother error of the like10:31
LetoThe2ndlearningc: well thats a problem of your kernel respectively its configuration itself.10:34
LetoThe2ndlearningc: in my experience, the best way is to work on the kernel outside of the OE build until it is sufficiently finished, or close enough10:35
learningcLetoThe2nd, How can I do that10:35
learningcHow to do it "outside" ?10:35
LetoThe2ndlearningc: 1) get arm toolchain, from linaro for example10:36
LetoThe2ndlearningc: 2) get your kernel sources10:36
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto10:36
LetoThe2ndlearningc: 3) enter kernel sources, and (basically) do ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make10:36
LetoThe2ndlearningc: insert steps for modifying your config and/or sources as needed10:37
learningcAnd that's it?10:38
LetoThe2nddepending on your specific needs and state of kernel source there might be bits and pieces needed here and there. but basically, yes.10:38
learningcI see10:39
learningcI think bitbake created some object files from previous compile and using them for the new .config file. How can I tell bitbake to rebuild from scratch?10:41
LetoThe2ndlearningc: -c clean10:41
open-nandramelonipoika: I plan to do it but in maybe 2 weeks :)10:46
open-nandrameloipoika: great it work for you10:47
*** rovanceo_ <rovanceo_!~rovanceo@> has quit IRC10:47
*** rovanceo_ <rovanceo_!~rovanceo@> has joined #yocto10:48
melonipoikaok! in two weeks maybe you can jump directly to Rocko :-)10:51
*** ChrysD <ChrysD!c16cc543@gateway/web/freenode/ip.> has quit IRC10:51
learningcI see there is -c cleansstate too, when should I use it? Is it better than -c clean?10:57
*** Snert_ <Snert_!> has quit IRC11:03
*** Snert <Snert!> has joined #yocto11:04
*** edgar444 <edgar444!uid214381@gateway/web/> has quit IRC11:12
learningcI did bitbake virtual/kernel -c clean, then bitbake virtual/kernel -c menuconfig, modify then save to .config, then bitbake virtual/kernel.  But the images produced does not seem to have the new changes from the .config file.  Is there something I am missing?11:14
JaMalearningc: you should also use savedefconfig task and then update the newly created defconfig in the metadata11:14
JaMawhen the configure task is re-executed your saved changes from menuconfig will be overwritten11:15
learningcJaMa, and step by step instruction? savedefconfig task is an option? -c savedefconfig ?11:17
*** quite <quite!quite@unaffiliated/quite> has joined #yocto11:17
*** quite <quite!quite@unaffiliated/quite> has quit IRC11:24
*** quite <quite!quite@unaffiliated/quite> has joined #yocto11:25
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC11:26
*** juvenal <juvenal!> has joined #yocto11:27
*** vdehors <vdehors!~vdehors@> has joined #yocto11:36
*** avalluri <avalluri!~avalluri@> has quit IRC11:43
*** avalluri <avalluri!~avalluri@> has joined #yocto11:44
*** avalluri <avalluri!~avalluri@> has quit IRC11:47
*** avalluri <avalluri!~avalluri@> has joined #yocto11:47
*** learningc <learningc!> has quit IRC11:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:52
*** juvenal <juvenal!> has quit IRC11:55
*** juvenal <juvenal!> has joined #yocto11:57
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC11:58
otaviosgw: matt did reply; he is testing it.12:02
*** avalluri <avalluri!~avalluri@> has quit IRC12:04
*** avalluri <avalluri!avalluri@nat/intel/x-iowlmfgcmblwddha> has joined #yocto12:04
*** ipuustin <ipuustin!> has quit IRC12:11
*** Martian <Martian!~martian@> has joined #yocto12:12
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto12:14
*** grma <grma!~gruberm@> has quit IRC12:19
*** Shurelous <Shurelous!~igor@> has joined #yocto12:22
*** juvenal <juvenal!> has quit IRC12:24
*** juvenal <juvenal!> has joined #yocto12:30
*** nighty-- <nighty--!> has joined #yocto12:33
*** hnje <hnje!~hnje@> has quit IRC12:34
*** ipuustin <ipuustin!> has joined #yocto12:44
*** Willy-- <Willy--!188a097e@gateway/web/freenode/ip.> has joined #yocto12:48
*** marka <marka!> has joined #yocto12:48
*** khem <khem!~khem@unaffiliated/khem> has quit IRC12:50
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto12:56
*** grma <grma!~gruberm@> has joined #yocto12:57
*** lamego <lamego!jose@nat/intel/x-kfjcyghwghxofpls> has joined #yocto12:57
*** _AndersD <_AndersD!> has quit IRC13:01
*** hamis <hamis!~irfan@> has quit IRC13:04
*** open-nandra <open-nandra!> has quit IRC13:08
TamisIt is possible for a recipe to stage some files to sysroots before do_compile?13:08
TamisIs it*13:09
rburtonwhy on earth would you want to do that?13:11
*** peacememories <peacememories!> has joined #yocto13:12
Tamisrburton: hmmm I know that this is not correct. But I am wondering if it was possible13:15
*** Kakounet <Kakounet!> has quit IRC13:16
Tamisrburton: The actual case is that some .so's from a recipe A need some headers files from a recipe B. And recipe B needs the so's from recipe A to be build13:17
kanavinTamis: write a separate recipe for those things, and make the one that has do_compile depend on it13:18
kanavinso B_headers -> A_so -> B_final13:18
kanavinthree recipes13:19
TamisThat's was also on my mind. I tried not to write 3 recipes and download the repo twice.13:19
TamisBut I guess I have to do that way13:20
ramcqhow can I get access to the source/build dir of a package after it's built?13:21
rburtonramcq: what for?13:21
*** peacememories <peacememories!> has quit IRC13:23
ramcqrburton: because suggests didn't do anything13:23
ramcqrburton: (supported by no change in -dumpspecs output, and nothing particularly inspiring in readelf on the resulting binaries)13:23
rburtontmp/work has the build and source trees in13:23
rburtonassuming that you're not using rm_work, or it didn't restore from sstate instead of building13:24
rburtonyou can force a recipe to build by doing something like bitbake foo -C unpack (where -C says mark this task as needing to be ran, and then do a usual build)13:24
kanavinI think 'devtool modify foo' is a lot easier in this case13:25
kanavinalso because it's then far easier to tweak the source code13:25
kanavinand produce commits/patches as needed13:26
ramcqright - but here I'm not looking to modify it, just to poke around in configure logs and other generated junk to see where those options got to13:26
kanavinramcq: you don't have to actually do any modifications, but it makes such poking a lot easier13:28
kanavinramcq: especially if you find that you do need to tweak something after all13:28
ramcqso how do I get it to build according to the recipe?13:29
ramcqor does it do that?13:29
kanavinramcq: first issue 'devtool modify foo', then 'bitbake foo' as usual13:29
kanavinit will tell you where the sources are (build/workspace/sources/foo typically), and the same directory will have symlinks to logs and build dirs13:30
*** zarzar1 <zarzar1!~zarzar@> has joined #yocto13:30
*** cdreher <cdreher!~cdreher@> has joined #yocto13:30
kanavinwe're really not promoting devtool enough13:30
ramcqis it possible that the gcc recipes are weird enough that they need to all be build with devtool? error about gcc/libgcc1/ missing13:33
* ramcq tries devtool modify gcc-runtime and then we'll see what happens...13:34
*** zarzar <zarzar!> has quit IRC13:34
rburtongcc is *very* weird, it uses the gcc-shared recipe to have a single source tree13:34
rburtoninstead of fetching the gcc source N times13:34
kanavinramcq: indeed, devtool may not work for really weird cases13:36
kanavinthen you can find stuff in tmp/work/..., but it's awkward :)13:36
diego_rfor the FSL / NXP guys in the channel: anybody having problems fetching firmware-imx? $ git clone git:// \ Cloning into 'imx-firmware'... \ fatal: read error: Connection reset by peer13:37
ramcqok, so back to tmp/work - how do I temporarily disable rm_work too then...? :)13:39
frayremove rm_work from USER_CLASSES13:40
rburtonramcq: easy check is did you turn it on in local.conf (its not on by default, so "you" turned it on)13:41
otaviodiego_r: I just tried to clone it here and it succeed. It is dead slow though ...13:44
*** Kakounet <Kakounet!> has joined #yocto13:45
otaviorburton: I asked about lttng yesterday. Should I drop the backported patches and bump to 2.9.4?13:46
diego_rotavio: thanks. 'dead slow' is definition of fsl regular repositories speed. I'll try to do the same from some other server around the world and see if it succeeds, thanks13:46
rburtonotavio: for master.  for rocko i think the patches we've got are safest.13:46
*** zarzar1 <zarzar1!~zarzar@> has quit IRC13:46
*** zarzar <zarzar!~zarzar@> has joined #yocto13:46
otaviorburton: so I'll wait for the merge and I do the normal general upgrade of it13:47
otaviorburton: just bear in mind that 2.9.4 is bugfix only13:47
otaviorburton: but your call13:47
*** Kakounet <Kakounet!> has quit IRC13:49
*** AndersD <AndersD!> has joined #yocto13:51
*** Argylelabcoat <Argylelabcoat!> has joined #yocto13:52
*** Argylelabcoat <Argylelabcoat!> has quit IRC13:54
*** Argylelabcoat <Argylelabcoat!> has joined #yocto13:56
sgwotavio: thanks for the update on go13:56
*** Kakounet <Kakounet!> has joined #yocto13:56
sgwotavio: does the lttng update have more fixes than what you back ported?  Does it address newer kernels (4.14)?13:57
otaviosgw: :-) most of work was from matt13:57
otaviosgw: yes13:57
otaviosgw: imo it is a must13:57
zeddii_homethe lttng update is a must for what ? the current release ?13:59
* zeddii_home suspects people are getting caught up in the BS of LTS tagging13:59
*** Argylelabcoat <Argylelabcoat!> has quit IRC14:00
*** bbarr <bbarr!> has quit IRC14:06
otaviozeddii_home: not for initial but for ongoing maintenance. At NXP BSP we are using 4.13 kernel which fails with current and we are already working for 4.14 which will be LTS so a lot of people will adopt it14:08
zeddii_homeso it can go into a dot release later.14:08
zeddii_homethere’s a constant stream of kernels that will follow, ‘future proofing’ is a made up argument.14:08
*** bbarr <bbarr!> has joined #yocto14:08
otavioyes; we don't need to delay the release due that14:09
zeddii_homecool. that was my only concern.14:09
*** aurele <aurele!> has quit IRC14:09
otaviobut should get merged soon14:09
zeddii_homeagreed. I’m obviously going to do 4.14 + a new kernel for the reference linux-yocto’s in the coming months, so I’ll hit it as well.14:09
zeddii_homeand then delete all my old crappy LTS kernels from master :D yay!14:10
tcpdumpIm getting this error when I make a build:  image-1.0-r0 do_rootfs: lmsensors not found in the feeds        I can do bitbake lmsensors and it builds fine.14:13
tcpdumpAny idea why it would build using bitbake directly, but when inlcuded as   IMAGE_INSTALL_append = " lmsensors"   it fails with that error?14:13
*** _xthunderheartx_ <_xthunderheartx_!~x_xthunde@> has quit IRC14:14
*** rcw <rcw!~rwoolley@> has joined #yocto14:14
*** rcw <rcw!~rwoolley@> has joined #yocto14:15
boucman_workhey all14:17
boucman_workis there an easy way to enable/disable a kernel option conditionnaly (based on a machine feature in my case)14:17
zeddii_homeboucman_work: depends on what kernel recipe you are using.14:18
boucman_workso far the best I can do is conditionnaly include a .cfg fragment withe weird SRC_URI tricks...14:18
*** ant_work <ant_work!> has quit IRC14:18
otaviozeddii_home: yey!14:18
zeddii_homeyah. or set a KERNEL_FEATURE if you are based on kernel-yocto.14:18
boucman_workzeddii_home: i'm using an ugly BSP provided kernel... let's stay at "if I use the yocto provided one" and i'll deal with all the mud :P14:18
zeddii_home;) I completely understand.14:19
boucman_workzeddii_home: i'll look into KERNEL_FEATURES, I had missed that one...14:19
zeddii_homeI have an old bug to integrate things a bit more between the techniques, some of which will go into the next release. but it really is the wild west, so hard to do :D14:19
boucman_workok, I'll just read all the K* variables in the yocto doc, I guess :P14:20
*** armpit <armpit!~armpit@2601:202:4001:9ea0:2065:7bde:ea98:9b86> has quit IRC14:20
zeddii_homeboucman_work: feel free to ping me as well. I have plenty of experience on this front.14:21
boucman_worksure, I will..14:21
*** sjolley <sjolley!~sjolley@> has quit IRC14:22
*** gtristan <gtristan!~tristanva@> has quit IRC14:23
*** aurele <aurele!> has joined #yocto14:23
*** sjolley <sjolley!sjolley@nat/intel/x-fiujbnojxoffbsbp> has joined #yocto14:24
*** angrysiamese <angrysiamese!> has quit IRC14:26
*** angrysiamese <angrysiamese!> has joined #yocto14:26
*** majuk <majuk!> has joined #yocto14:28
*** sjolley <sjolley!sjolley@nat/intel/x-fiujbnojxoffbsbp> has quit IRC14:30
*** sgw <sgw!~swold@> has quit IRC14:30
*** sgw <sgw!> has joined #yocto14:31
*** Argylelabcoat <Argylelabcoat!> has joined #yocto14:33
*** mdnneo <mdnneo!~umaucher@> has quit IRC14:34
diego_rotavio: it seems firmware-imx works for me too now. Thanks14:34
*** sgw <sgw!> has quit IRC14:37
*** milindur <milindur!> has quit IRC14:44
*** gtristan <gtristan!~tristanva@> has joined #yocto14:45
*** milindur <milindur!> has joined #yocto14:50
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:94e2:7fe6:ea28:d106> has joined #yocto14:51
*** lexano <lexano!> has quit IRC14:53
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:55
*** AndersD <AndersD!> has quit IRC14:58
*** rcw <rcw!~rwoolley@> has quit IRC15:06
*** lexano <lexano!~lexano@> has joined #yocto15:06
*** vdehors <vdehors!~vdehors@> has quit IRC15:11
*** sgw <sgw!swold@nat/intel/x-yaoloxhdlupieihn> has joined #yocto15:14
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:19
*** yann <yann!~yann@> has quit IRC15:21
*** juvenal <juvenal!> has quit IRC15:22
*** Kakounet <Kakounet!> has quit IRC15:27
*** juvenal <juvenal!> has joined #yocto15:29
*** Martian <Martian!~martian@> has quit IRC15:32
*** juvenal <juvenal!> has quit IRC15:38
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:44
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC15:50
*** martinkelly1 <martinkelly1!> has joined #yocto15:51
*** fl0v0 <fl0v0!> has quit IRC16:06
*** mattsm <mattsm!> has quit IRC16:07
*** Bunio_FH <Bunio_FH!> has quit IRC16:08
*** mattsm <mattsm!> has joined #yocto16:09
*** dave0x6d <dave0x6d!uid190567@gateway/web/> has joined #yocto16:13
*** grma <grma!~gruberm@> has quit IRC16:17
*** stephano <stephano!~stephano@> has joined #yocto16:24
*** Snert_ <Snert_!~snert_@> has joined #yocto16:24
*** armpit <armpit!~armpit@2601:202:4001:9ea0:d49e:b0ae:9202:32ab> has joined #yocto16:30
*** juvenal <juvenal!> has joined #yocto16:31
*** toscalix <toscalix!~toscalix@> has quit IRC16:39
*** WillMiles <WillMiles!> has joined #yocto16:39
*** bavery_fn <bavery_fn!bavery@nat/intel/x-fcyewideeesvwxyf> has quit IRC16:42
*** Argylelabcoat <Argylelabcoat!> has quit IRC16:47
*** Argylelabcoat <Argylelabcoat!> has joined #yocto16:48
*** juvenal <juvenal!> has quit IRC16:48
*** juvenal <juvenal!> has joined #yocto16:58
*** diego_r <diego_r!~diego@> has quit IRC16:59
*** jku <jku!> has joined #yocto17:02
*** tavish <tavish!~tavish@unaffiliated/tavish> has joined #yocto17:05
*** juvenal <juvenal!> has quit IRC17:08
*** aehs29 <aehs29!~aehernan@> has quit IRC17:11
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:13
*** jg_ <jg_!~jg@2601:18f:981:82c5:a800:914c:7bb3:48f7> has joined #yocto17:23
*** FabKna <FabKna!> has joined #yocto17:27
*** sachit <sachit!> has quit IRC17:28
*** sachit <sachit!> has joined #yocto17:28
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC17:29
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto17:30
*** pohly <pohly!> has quit IRC17:39
*** yann <yann!> has joined #yocto17:41
*** bavery_fn <bavery_fn!bavery@nat/intel/x-xcasbtsytzmacfkg> has joined #yocto17:44
FabKnaI have a layer which differs a bit regarding the image to build. Im wondering whats the best way of implementing this in a recipe / recipe append.17:50
FabKnaE.g., I have a kernel append to load an additional cfg for image A and another cfg for image B.17:51
FabKnaIs it possible (and best practice) to set a global variable KERNEL_FEATURE_A and check it in the append?17:53
*** aehs29 <aehs29!~aehernan@> has joined #yocto18:29
*** aehs29 <aehs29!~aehernan@> has quit IRC18:34
*** aehs29 <aehs29!~aehernan@> has joined #yocto18:35
*** jku <jku!> has quit IRC18:38
*** juvenal <juvenal!> has joined #yocto18:39
*** zerus_ <zerus_!> has quit IRC18:42
*** t0mmy <t0mmy!~tprrt@> has quit IRC19:08
*** bluelightning <bluelightning!~paul@> has joined #yocto19:08
*** bluelightning <bluelightning!~paul@> has quit IRC19:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:08
*** dave0x6d <dave0x6d!uid190567@gateway/web/> has quit IRC19:13
*** juvenal <juvenal!> has quit IRC19:30
*** kpo_ <kpo_!> has joined #yocto19:31
*** juvenal <juvenal!> has joined #yocto19:31
*** ant_home <ant_home!> has joined #yocto19:39
*** juvenal <juvenal!> has quit IRC19:42
*** juvenal <juvenal!> has joined #yocto19:45
*** clsulliv <clsulliv!~clsulliv@> has left #yocto19:49
*** clsulliv <clsulliv!~clsulliv@> has joined #yocto19:49
*** juvenal <juvenal!> has quit IRC19:54
*** peacememories <peacememories!> has joined #yocto20:04
*** milindur <milindur!> has quit IRC20:04
*** tavish <tavish!~tavish@unaffiliated/tavish> has quit IRC20:06
*** Willy-- <Willy--!188a097e@gateway/web/freenode/ip.> has quit IRC20:08
*** milindur <milindur!> has joined #yocto20:20
*** John_K_ <John_K_!446fc350@gateway/web/freenode/ip.> has joined #yocto20:21
John_K_Looking for help with Toaster - production server - django not found20:22
*** stephano <stephano!~stephano@> has quit IRC20:24
*** stephano <stephano!~stephano@> has joined #yocto20:24
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC20:24
*** milindur <milindur!> has quit IRC20:33
FabKnaJohn_K_ I tried the production instance with mysql a few months ago and gave up as this is absolutely not working for many reasons.20:34
John_K_@FabKna, Thanks... I've been on this for 3 weeks and did 2 clean CentOS installs... Instructions are not clear about env info...20:36
FabKnaYeah I agree I think it is really bad that this instructions is only as it is never tested.20:37
FabKnaAnd I tried it several weeks20:38
FabKnatry yocto-autobuilder20:38
FabKnait is in my opinion better than toaster20:38
FabKna is an example docker image20:39
John_K_Well, I got it to work directly, without Apache...20:42
FabKnayep same here20:42
John_K_I'll take a look at that, but client was pretty specific that he wanted it with apache20:42
John_K_and installed on bare metal.20:43
*** JaMa <JaMa!~martin@> has quit IRC20:43
FabKnaI worked a few months with it. However, toaster has drawbacks in my opinion, e.g., debugging infos are not enough for me.20:43
John_K_I will definitely pass this on.... thanks again20:44
FabKnaJohn_K_: As said I tried it several weeks with apache and mysql and env info is only one thing... you have to fix many more issues to get it working and these issues are not documented anywhere20:44
FabKnafor example, I had to alter the mysql database and so on. In the end I was happy with the built in django server20:45
John_K_not sure why they built-in won't handle a half dozen developers20:46
*** juvenal <juvenal!> has joined #yocto20:56
*** joshuagl <joshuagl!joshuagl@nat/intel/x-khnwhlcvclnjxmwr> has quit IRC20:57
*** milindur <milindur!> has joined #yocto21:00
*** peacememories <peacememories!> has quit IRC21:02
*** juvenal <juvenal!> has quit IRC21:08
*** bbarr <bbarr!> has quit IRC21:10
*** lamego <lamego!jose@nat/intel/x-kfjcyghwghxofpls> has quit IRC21:12
*** dave0x6d <dave0x6d!uid190567@gateway/web/> has joined #yocto21:13
*** martinkelly1 <martinkelly1!> has quit IRC21:21
*** stephano <stephano!~stephano@> has quit IRC21:26
*** stephano <stephano!~stephano@> has joined #yocto21:26
*** Shurelous <Shurelous!~igor@> has quit IRC21:26
*** stephano <stephano!~stephano@> has quit IRC21:27
*** stephano <stephano!~stephano@> has joined #yocto21:27
*** stefan___ <stefan___!> has quit IRC21:31
*** WillMiles <WillMiles!> has quit IRC21:42
*** marka <marka!> has quit IRC21:49
*** FabKna <FabKna!> has quit IRC21:52
*** jratz <jratz!> has joined #yocto22:02
*** jratz <jratz!> has quit IRC22:09
*** martinkelly1 <martinkelly1!~martin@> has joined #yocto22:17
*** stephano <stephano!~stephano@> has quit IRC22:17
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:17
*** Argylelabcoat <Argylelabcoat!> has quit IRC22:26
*** rburton <rburton!> has quit IRC22:27
*** RP1 <RP1!> has joined #yocto22:32
*** igor <igor!~igor@> has joined #yocto22:33
*** majuk <majuk!> has quit IRC22:41
*** ferry_ <ferry_!~quassel@> has joined #yocto22:42
*** majuk <majuk!> has joined #yocto22:42
*** agust <agust!> has quit IRC22:42
*** ferry_ <ferry_!~quassel@> has quit IRC22:42
*** juvenal <juvenal!> has joined #yocto22:43
*** majuk <majuk!> has quit IRC22:46
*** RP1 <RP1!> has quit IRC22:53
*** jratz <jratz!> has joined #yocto22:54
*** nemunaire <nemunaire!~nemunaire@2a01:e35:8bb7:3c60::a> has quit IRC22:55
*** jratz <jratz!> has quit IRC22:59
*** nighty-- <nighty--!> has quit IRC23:01
*** RP1 <RP1!> has joined #yocto23:12
*** jratz <jratz!> has joined #yocto23:15
*** bavery_fn <bavery_fn!bavery@nat/intel/x-xcasbtsytzmacfkg> has quit IRC23:17
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC23:18
*** juvenal <juvenal!> has quit IRC23:19
*** stephano <stephano!~stephano@> has joined #yocto23:19
*** jratz <jratz!> has quit IRC23:19
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto23:23
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto23:25
*** jratz <jratz!> has joined #yocto23:36
*** nemunaire <nemunaire!~nemunaire@2a01:e35:8bb7:3c60::a> has joined #yocto23:38
*** bavery_fn <bavery_fn!~bavery@> has quit IRC23:38
*** jratz <jratz!> has quit IRC23:40
*** jratz <jratz!> has joined #yocto23:44

Generated by 2.11.0 by Marius Gedminas - find it at!