Friday, 2019-07-12

*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC00:00
*** arielmr <arielmr!~quassel@187-163-217-93.static.axtel.net> has quit IRC00:07
*** rcw <rcw!~rcw@45.72.248.73> has joined #yocto00:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto00:14
*** florian__ <florian__!~florian_k@Maemo/community/contributor/florian> has joined #yocto00:31
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC00:35
khemRP: I am seeing packaging errors of this kind https://errors.yoctoproject.org/Errors/Details/251372/00:38
khemthis is with opkg backend but seems more PR server related any recent changes that could cause this ?00:39
khemI am seeing it across the board but failures are random00:39
khemhappens on ubuntu 18.04 machines primarily00:40
khemthis is full build e.g. https://errors.yoctoproject.org/Errors/Build/83864/ and you can see bunch of do_package errors00:41
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ivafyhrnsvjmooaf> has joined #yocto00:44
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC00:45
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has quit IRC01:02
*** huynq <huynq!65607042@101.96.112.66> has joined #yocto01:28
*** huynq <huynq!65607042@101.96.112.66> has quit IRC01:29
armpitkhem, I have seen that from time to time on thud01:46
khemhmm thats worrying01:50
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has joined #yocto02:25
*** rcw <rcw!~rcw@45.72.248.73> has quit IRC02:37
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ivafyhrnsvjmooaf> has quit IRC03:04
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC03:29
Marexhum, where's rburton when you want to reply to his PM03:52
*** stephano <stephano!~stephano@134.134.139.72> has quit IRC04:09
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto04:10
*** Chrusel76 <Chrusel76!c1669b04@193.102.155.4> has joined #yocto04:10
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC04:15
*** Chrusel76 is now known as Chrusel04:20
*** fatalhalt <fatalhalt!~fatalhalt@c-67-163-60-93.hsd1.il.comcast.net> has quit IRC04:31
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC04:33
*** Chrusel <Chrusel!c1669b04@193.102.155.4> has joined #yocto04:48
*** Chrusel is now known as chrusel04:48
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has joined #yocto04:58
*** agust <agust!~agust@pD95F1DFD.dip0.t-ipconnect.de> has joined #yocto05:00
*** khem <khem!~khem@unaffiliated/khem> has quit IRC05:32
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:36
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto06:17
chruseljust wondering: poky warrior was bumped to 2.7.1 eleven days ago, what is missing for releasing it? I also saw that https://wiki.yoctoproject.org/wiki/Weekly_Status is a little outdated ... do you feel okay 'Yocto SWAT Team' <3 ?06:18
yoctiNew news from stackoverflow: Audit daemon does not take rules from audit.rules <https://stackoverflow.com/questions/56337307/audit-daemon-does-not-take-rules-from-audit-rules>06:20
LetoThe2ndchrusel: probably autotests still missing, or nobody gotten round to actually check and properly release it06:20
LetoThe2ndchrusel: i personally tend to not take those tags overly serious, i just care about branches.06:21
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:22
*** litb <litb!~js@p5B2FEADA.dip0.t-ipconnect.de> has joined #yocto06:23
litbhello all06:23
litbwe want to compile our application separate from yocto. i.e without a recipe. but we still want to use the yocto compiler/linker etc, prefeably on the yocto build machine, directly using the yocto environment without the SDK06:24
litbis this possible?06:24
LetoThe2ndlitb: its only software, so anything is possible.06:25
LetoThe2ndlitb: but why not do the sdk dance? i mean, its exactly what you seem to want06:25
*** Crofton <Crofton!~Crofton@cust-west-pareq2-46-193-12-18.wb.wifirst.net> has joined #yocto06:27
litbLetoThe2nd, i was in the impression that the SDK is for the developers, to develop their programs independent from other developers and the CI-systems06:29
litbbut we want to compile our applications on the CI systems of course. and if we always have to rebuild and install a new SDK or update an SDK on the CI-systems (buildbot) just to be able to compile our application06:30
litbit seems that would be overkill06:30
LetoThe2ndlitb: hm. you could also use a pro-forma recipe and externalsrc06:44
litbhm, i forgot about that. main reason is that we want to avoid mixing our company sources and resources with opensource yocto things06:45
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yptewhrlkbackvzz> has joined #yocto06:45
LetoThe2ndnow thats a kind of no-reason06:46
LetoThe2nd"we want to build with an open source toolchain provided by an open source build system that we already on on our servers"06:47
litbLetoThe2nd, because when we release the source code of the system + the build scripts, we want the user to be able to rebuild the system. and our company software should not be part of that source code release06:48
LetoThe2ndyou can always set a breaking license on that pro forma recipe, but i mean in the end you'll probably want to ship your application anyways.06:48
LetoThe2ndlitb: there is more than enough documentation on that particular topic in the manual06:49
litbhm, I find there's little documentation. for example, I don't find documentation how to tell yocto: "download this recipe's SRC_URIs to an alternative DL_DIR"06:49
litbso that when done building the system, we can just zip-up the DL_DIR and create a mirror of it, for releasing it to the public06:50
LetoThe2ndlitb: providing the DL dir is not the way to go anyways.06:50
*** nighty <nighty!~nighty@b157153.ppp.asahi-net.or.jp> has joined #yocto06:50
LetoThe2ndlitb: we have the archiver class thats exactly meant to do what you want.06:50
LetoThe2nd-> create a source tarball for a particular build06:50
litbLetoThe2nd, it is not able to archive the sources in a way that yocto can use them to rebuild the system06:51
litbit just archives the sources and optionally the used recipes. but the sources are for example named in incompatible manner, not compatible to mirror-formats06:51
LetoThe2ndah. thats possible, yes.06:52
litbGPL requires that sources are released together with build scripts so that users can rebuild their own modifications06:52
LetoThe2ndlitb: GPLv3 requires this. major difference!06:52
LetoThe2ndanyways, for coming back to your actual problem. you'd have to somehow trick the build into providing a sysroot that you can use and harness from external.06:54
LetoThe2ndits certainly possible, but i'm not aware of any documented use06:54
litbLetoThe2nd, one thing that bugs is is that GPLv2 requires that build scripts be published with the source code. therefore, we would be required to publish yocto. but the archvier doesn't archive the buildsystem. just the recipes07:05
litbthe user may not need to be able to completely reproduce the system. but the build scripts need to be provided nontheless07:05
*** tgraydon <tgraydon!~tgraydon@134.134.139.83> has quit IRC07:05
LetoThe2ndlitb: gplv3 requires this, not gplv2. its the main reason why so many stick to old gplv2 versions.07:07
litbLetoThe2nd, GPLv2.0 says: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. "07:08
litbi think it's very plausible that this means that just providing the upstream tarballs + patches is not sufficient. this is also what we gathered from reading several books on gplv207:10
LetoThe2ndlitb: i think i have heard other interpretations too, but of course. better be safe than sorry.07:10
*** florian__ is now known as florian07:11
RPkhem: We have seen that occasionally on the autobuilder, did think there was a possible ulimit issue of some kind07:13
RPkhem: I ended up turning prserv off since it was corrupting buildhistory07:13
RPkhem: is that with a single prserv?07:14
mcfriskhmm, why are ptests compiled in S, B seems to point there? protobuf ptest compilation is failing07:17
litbLetoThe2nd, I suppose it's not possible to specify different download directories on a per-layer base?07:17
LetoThe2ndlitb: nope, never heard of that.07:17
LetoThe2ndi mean in the end its only software..... :P07:18
litbI wonder whether it's possible to build an SDK where the SDK contains the sources of specific packages, instead of the sstate-cache.07:18
LetoThe2ndhuh?07:18
LetoThe2ndthe sdk contains no sources and no sstate.07:18
LetoThe2ndthe esdk contains sstate.07:19
litbnormally the eSDK contains a populated sstate-cache with fixed checksums, so that you can't modify the recipes, but so that everything is already prebuilt07:19
litbsorry, meant esdk07:19
litbi wonder whether it's possible to let yocto build an SDK that builds everything from sources when saying "devtool build-image"07:20
LetoThe2nd"its only software"07:20
litbthen, the build-sdk step would only include those sources that one wants in his sdk. and we would just blacklist our company recipes or layer and it magically wouldn't be included in source-form in the sdk07:21
litbLetoThe2nd, how hard woudl it be to add this? does it sound useful at all, anyway?07:21
LetoThe2ndi can see usecases, so it might be worth doing it. how hard, no idea.07:22
LetoThe2ndRP: ^^^^^07:22
*** Crofton <Crofton!~Crofton@cust-west-pareq2-46-193-12-18.wb.wifirst.net> has quit IRC07:25
litbmaybe it suffices if we release the eSDK without sources actually, combined with the result of the archiver07:26
litbafter all, this would end up being the source code + scripts that control the build process. and the user is even able to modify source code and recompile the image07:26
litbLetoThe2nd, with "devtool modify", the user can point eSDK to the tarball created by the archiver, right?07:27
LetoThe2ndlitb: i think that should work, yes.07:30
litbnot that it barks out if they provide a tarball from the archiver, but devtool expects a git-workingdirectory because SRC_URI is a git uri07:31
RPlitb: I don't think it would be hard to do that07:32
*** Hodhr <Hodhr!~Hodhr@162.206.70.37.rev.sfr.net> has left #yocto07:32
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:33
*** mckoan|away is now known as mckoan07:33
mckoangood morning07:33
litbgood morning07:36
litbLetoThe2nd, is it advised against to publish the eSDK to the public/customers? advised against to publish it for license-compliance purposes?07:38
*** kaspter <kaspter!~Instantbi@183.128.188.113> has quit IRC07:38
LetoThe2ndlitb: i don't think so.07:38
litbhaven't read about this in the manual. is this just a creative way to be compliant?07:39
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto07:40
*** kaspter <kaspter!~Instantbi@183.128.188.113> has joined #yocto07:40
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:41
LetoThe2ndlitb: no i don't think so. what i meant to say is that i do not see any reason to *NOT* publish the esdk to customers.07:42
RPlitb: esdk was designed as a "half way house" between giving someone an sdk and the full build system07:45
RPlitb: e.g. how do you give an end user a way of rebuilding an image without the risk of the full build system?07:46
RPlitb: I think our view was that esdk is ok but we could still do better. Nobody has worked on trying another set of improvements to it as yet07:47
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto07:50
*** jwessel <jwessel!~jwessel@128.224.252.2> has quit IRC07:54
litbi'm creating a container-layer  "meta-<company>" that contains other layers. i.e "meta-<company>/meta-<company>-os" "meta-<company>/meta-<company>-bsp" etc. this naming is a bit long. is there something wrong with this?08:02
LetoThe2ndlitb: technically no, meta-openembedded uses the same approach. just note that depending on your CI, commits might trigger rebuilds of unrelated things, and that you will have an intermingled commit log.08:04
*** frsc <frsc!~frsc@200116b8249575005c35b5da6245705d.dip.versatel-1u1.de> has joined #yocto08:07
*** kayterina <kayterina!kayterina-@gateway/shell/matrix.org/x-gwbnntboxiejfbdu> has joined #yocto08:11
*** akrpic77 <akrpic77!c12e4b03@193.46.75.3> has left #yocto08:11
*** akrpic77 <akrpic77!c12e4b03@193.46.75.3> has joined #yocto08:11
*** akrpic77 is now known as ak7708:13
yoctiNew news from stackoverflow: Use different Sourcefiles in .bbappend (Immediate variable expansion) <https://stackoverflow.com/questions/57002931/use-different-sourcefiles-in-bbappend-immediate-variable-expansion> || Using Yocto with a distribution using python3 by defaults <https://stackoverflow.com/questions/28360862/using-yocto-with-a-distribution-using-python3-by-defaults> || Running Bitback with Python3, I have this error, Anyone can tell me the solution? <https://stackoverflow.com/questions/57002643/running-bitback-with-python3-i-have-this-error-anyone-can-tell-me-the-solution>08:20
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC08:36
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto08:38
*** luckywho <luckywho!~quassel@49.207.55.213> has joined #yocto08:41
*** lemagoup <lemagoup!~lemagoup@softbank-robotics-gw1.ter4.eqx2.par.cust.as8218.eu> has joined #yocto08:46
*** nighty is now known as cp08:59
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto09:00
*** cp <cp!~nighty@b157153.ppp.asahi-net.or.jp> has quit IRC09:00
litbone of my recipes needs to build a kernel module which is rather deep within the directories of a git repository of ours09:00
*** cp <cp!~cp@b157153.ppp.asahi-net.or.jp> has joined #yocto09:01
litbthe repository needs to be checked out by other recipes anyway. if i check it out in the kernel recipe, will yocto be smart enough to share the files between the recipes? i.e use hardlinks or something?09:01
litbi know it will clone only once into the DL_DIR. but the source needs to be in the work-directory. and for that it needs to be copied09:02
RPlitb: no, it won't. You could however use a parameter in the fetcher url to limit the path it checks out to be some subtree09:06
RP(it won't be smart enough to hardlink files)09:06
litbah, "subpath", thanks!09:07
RPlitb: sounds right, I'd have had to look at the code to know :)09:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:14
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC09:26
*** opennandra <opennandra!~marek@109-230-35-25.dynamic.orange.sk> has joined #yocto09:29
opennandrahello just want to check if anyone have recipe for google-fluentd: https://github.com/GoogleCloudPlatform/google-fluentd09:30
RPopennandra: have you checked the layer index?09:36
opennandraRP: yes09:36
RPopennandra: ok, good!09:36
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto09:36
opennandraRP: I plan to work on it if there is no recipe available09:37
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC10:01
litbwhat's wrong with this?   http://coliru.stacked-crooked.com/a/5fd350ef9bc8109b10:02
litbit keeps checking out "sources/foo" directly into ${WORKDIR} rather than into ${WORKDIR}/git10:03
litband it fails to apply the patch. even though it applies between   a/foo/Makefile   and b/foo/Makefile   . it complains "can't find file to patch at input line 5"10:03
litbthis file is  "b/foo/Makefile"10:04
litbin ${WORKDIR} there is a     foo/Makefile    . and the default "striplevel" option of patch files is  1. but even with an explicit ";striplevel=1" it won't work10:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:06
litbah i get it now... S = ... doesn't tell it where to checkout. but it tells yocto where to look for the source. the checkout dir is an option of the fetcher10:08
*** Dvorkin <Dvorkin!~Dvorkin@176.114.204.12> has quit IRC10:16
RPlitb: yes, get the checkout dir right and the rest should fall into place10:20
*** ak77 <ak77!c12e4b03@193.46.75.3> has quit IRC10:29
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC10:36
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:42
*** Wildzu <Wildzu!d4d5100d@212.213.16.13> has joined #yocto10:44
*** shan1 <shan1!86666183@dhcp-131.biba.uni-bremen.de> has joined #yocto10:55
shan1What is an efficient way to move from `krogoth` to `sumo`? Should I checkout the sumo branch in all the meta layers?10:57
tgoodwinshan1: that's usually the way I go; that and read the release notes in the mega manual because there have been a lot of changes since krogoth.11:00
JaMayes, but if you're upgrading now, then it's worth spending some extra efford to upgrade all the way to warrior11:00
JaMasumo is out of support already11:00
tgoodwin+1 what JaMa said, if you can.11:02
shan1I am dependent on the phytec board's development. I inquired through them and said that for the board I use they currently have only krogoth and  rocko support! sumo is a bit of an opptimistic shot for me.11:02
tgoodwinshan1: I recently jumped from rocko to thud and the main "gotcha" was changes to how DEPENDS and python modules interact, the need to install python-modules in my image, and boost changes breaking some of my libraries.11:05
shan1Okay! looks like a weekend project to take up!11:06
JaMashan1: depends on how much you actually need from phytec, I don't know their BSP but some BSPs are relatively easy to use with newer releases with small fixes11:06
shan1As of now I used their rocko dev for the board where the minimal image was build well. However when I tried bringing in InfluxDB recipes into it, it fails miserably.11:07
shan1Everything with golang and npm is much of a hassle.11:08
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:10
*** opennandra <opennandra!~marek@109-230-35-25.dynamic.orange.sk> has quit IRC11:14
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:15
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC11:18
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC11:23
*** shan1 <shan1!86666183@dhcp-131.biba.uni-bremen.de> has left #yocto11:25
*** Chrusel76 <Chrusel76!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto11:34
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC11:36
*** Chrusel76 <Chrusel76!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC11:39
*** Chrusel76 <Chrusel76!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto11:39
*** Chrusel76 <Chrusel76!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC11:41
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto11:41
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC11:46
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto11:47
*** Crofton <Crofton!~Crofton@109.190.253.16> has joined #yocto11:52
rburtontgoodwin: the python thing is a simple bug in the rdepends on numpy, patches welcome11:54
litbWhat's the best approach if you need to install an out-of-tree kernel module into its  own directory in  /root  as opposed to the stadnard directory in  /lib/modules/<kernel>   ?12:00
rburtonwhy would you do that?12:01
litbi'm thinking of using  module.class  but defining my  own do_install which would just manually install the   built .ko file to /root, and not call  module_install at all12:01
litbrburton, our current system does that, and while porting to yocto, i want to change as little as possiböe12:01
rburtonuse the usual class and then use a do_install_append to mv the file12:01
litbhope it won't break the system  if a  kernel-module-... package doesn't install its file to  /lib/modules tho.12:02
litbthanks, i will try that12:02
tgoodwinrburton: thanks, I haven't had a chance to do anything with it yet.  I'm chasing my tail with a bake that keeps crashing in different spots.12:04
tgoodwinones that don't make any sense...have worked for a long time, completely untouched by patches, etc.  Yay...12:04
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto12:06
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto12:13
*** luckywho <luckywho!~quassel@49.207.55.213> has quit IRC12:15
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC12:23
*** rcw <rcw!~rcw@128.224.252.2> has joined #yocto12:28
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC12:33
*** Chrusel_ <Chrusel_!~Chrusel76@x590feeba.dyn.telefonica.de> has joined #yocto12:43
*** yann <yann!~yann@85.118.38.73> has joined #yocto12:44
*** Chrusel_ <Chrusel_!~Chrusel76@x590feeba.dyn.telefonica.de> has quit IRC12:46
*** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC12:48
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC12:49
*** Wildzu <Wildzu!d4d5100d@212.213.16.13> has quit IRC12:50
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto12:55
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto12:59
*** Crofton <Crofton!~Crofton@109.190.253.16> has quit IRC12:59
*** Crofton <Crofton!~Crofton@109.190.253.16> has joined #yocto13:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC13:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:00
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has quit IRC13:00
*** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto13:01
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC13:03
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto13:04
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC13:07
*** TurkCypriot <TurkCypriot!4e873c2e@78.135.60.46> has joined #yocto13:19
TurkCypriotHiya ppl, i need help acout yocto toaster. When i try to build core-image-minimal from the command line it's done and i could run my os by using qemu13:20
TurkCypriotBut when i try to create another project from the Toaster web panel i am facing an error13:20
TurkCypriotBad path or missing 'conf' directory (/home/hakan/poky/build/conf)13:21
TurkCypriotHow can i get rid off it any ideas??13:21
TurkCypriotis there anyone alive up there?13:23
mckoanTurkCypriot: mix YP command line with Toaster is now as safe as expected. Read our experience here http://wiki.koansoftware.com/index.php/Toaster_setup_and_usage13:25
mckoans/now/not13:25
TurkCypriotClick on "New project", type a name and select "Import command line project", then specify the build path.13:27
TurkCypriotted build.13:27
TurkCypriotThis is what i am trying to do actually but i am facing this error13:27
TurkCypriotBad path or missing 'conf' directory (/home/hakan/poky/build/conf)13:27
TurkCyprioti'll keep givin a try13:28
TurkCypriotthank you very much mckoan.13:28
TurkCypriotlOL.13:30
TurkCypriotAnother issue now13:30
TurkCypriotDoesNotExist at /toastergui/newproject/13:30
TurkCypriotim selecting "import command line project" and seting the existing project directory as "Import existing project directory"13:31
TurkCypriotbut now im facing this issue13:31
TurkCypriotDoesNotExist at /toastergui/newproject/13:31
TurkCypriotels/query.py in get, line 38013:32
TurkCypriotkages',13:32
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:34
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:36
tlwoernerdoes the linux-yocto tooling allow a user to configure a kernel build by _defconfig? e.g. make lpc32xx_defconfig; make13:41
*** Crofton <Crofton!~Crofton@109.190.253.16> has quit IRC13:41
tlwoernerwith u-boot the *_defconfig is specified by UBOOT_MACHINE13:42
*** Crofton <Crofton!~Crofton@109.190.253.16> has joined #yocto13:42
tlwoerneranything similar for linux-yocto?13:42
TurkCypriotyes13:43
TurkCypriotit allows13:43
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC13:45
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto13:49
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC13:53
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC13:56
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC13:58
*** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto14:00
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto14:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:12
*** litb <litb!~js@p5B2FEADA.dip0.t-ipconnect.de> has quit IRC14:12
*** yann <yann!~yann@85.118.38.73> has quit IRC14:18
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:19
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto14:22
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:29
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:34
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC14:42
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto14:48
*** Crofton <Crofton!~Crofton@109.190.253.16> has quit IRC14:49
*** Crofton <Crofton!~Crofton@109.190.253.16> has joined #yocto14:50
*** prabhakarlad <prabhakarlad!~prabhakar@194.75.40.178> has left #yocto14:53
*** TurkCypriot <TurkCypriot!4e873c2e@78.135.60.46> has quit IRC14:57
*** woutervh <woutervh!~woutervh@84.199.255.188> has joined #yocto15:01
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:18
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC15:20
*** woutervh <woutervh!~woutervh@84.199.255.188> has quit IRC15:20
*** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto15:26
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto15:27
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto15:38
*** lemagoup <lemagoup!~lemagoup@softbank-robotics-gw1.ter4.eqx2.par.cust.as8218.eu> has quit IRC15:38
*** tprrt <tprrt!~tprrt@upc31-1-78-208-110-13.fbx.proxad.net> has quit IRC15:39
*** Crofton <Crofton!~Crofton@109.190.253.16> has quit IRC15:49
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC15:57
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC16:04
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:09
*** litb <litb!~litb___@p5B02F53B.dip0.t-ipconnect.de> has joined #yocto16:20
litbhello folks16:20
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC16:26
*** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has joined #yocto16:27
*** armpit <armpit!~armpit@2601:202:4180:c33:d1c7:76cb:bd3:8c78> has quit IRC16:29
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:39
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto16:44
*** mckoan is now known as mckoan|away16:55
khemRP: PRSERV_HOST = "localhost:0" is what we use in local.conf16:56
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto16:59
RPkhem: that isn't being shared so that isn't likely being useful16:59
*** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC17:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:02
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:03
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC17:04
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC17:05
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has joined #yocto17:06
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:25
*** Crofton <Crofton!~Crofton@cust-west-pareq2-46-193-11-36.wb.wifirst.net> has joined #yocto17:25
*** opennandra <opennandra!~marek@109-230-35-25.dynamic.orange.sk> has joined #yocto17:29
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto17:30
*** opennandra <opennandra!~marek@109-230-35-25.dynamic.orange.sk> has quit IRC17:34
*** opennandra <opennandra!~marek@109-230-35-25.dynamic.orange.sk> has joined #yocto17:38
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto17:40
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-yptewhrlkbackvzz> has quit IRC17:45
khemright we really dont use PR server17:51
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto17:53
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC17:54
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC18:04
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto18:05
khemhalstead: I am getting this error lately http://sprunge.us/EPGJSu on oe git, any ideas18:05
khemit seems to be related to server18:05
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC18:12
halsteadkhem, looks like the automated clean needs some tending to.18:12
opennandrahi, I'm trying to setup provision image which will flash build image to emmc storage. Basically I define provision image and add dependency on provisioned image and then add rootfs_postprocess to copy provisioned image. But provision image do_rootfs is finished earlier before other image and it fails. Any idea how to setup proper dependency here? Thx18:32
*** armpit <armpit!~armpit@c-71-204-143-8.hsd1.ca.comcast.net> has joined #yocto18:32
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:46
khemopennandra: you can add dependency on a given task of a recipe e.g. do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot"18:48
opennandraok I've added that and for copying [rovision image I plan to use  IMAGE_PREPROCESS_COMMAND18:49
*** yates <yates!~user@rrcs-96-10-234-158.midsouth.biz.rr.com> has joined #yocto18:50
opennandrakhem: so I need to add dependency on when first image is created ?18:50
khemyes18:50
yatesin a yocto recipe, how do i specify special inclucde paths, such as the "dbus-1.0" in /usr/include/dbus-1.0? I know it's with the -I option, but how do you get all the upper level build path in the -I ?18:51
opennandrakhem: well it fails because previous image is not yet created even added dependency18:52
yatesis it $S or $D?18:53
opennandrakhem: do_rootfs[depends] += "final-image:do_rootfs"18:53
opennandrayates: $S point to source and $D to destination18:54
JaMakhem: that git error is IMHO caused by too many rebases locally, I have it on many repos from different servers, so I don't think it's server related18:54
yatesi need to get at the sysroot path, i believe18:55
yates${includedir} ?18:57
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC18:58
JPEWyates: You want the ${STAGING_DIR} family of variables: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-sharing-files-between-recipes18:59
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto19:01
JPEWyates: most likely ${STAGING_DIR_HOST}19:02
yatesis this sort of stuff defined in the staging class?19:03
yatesis there a command for listing all recipes?19:08
yatesJPEW: is dbus (actually libdbus, the native C API to dbus) built by another recipe or is it somehow automatically included in the build environment?19:09
yateshow can you show what packages are generated by a recipe?19:14
yatesi've foudn the dbus recipe with "bitbake-layers show-recipes"19:14
yatesJPEW: so if the dbus recipe generates .../dbus-1.0/dbus.h (and others), then how would you use the ${STAGING_DIR_HOST} to access that path in my own recipe do_compile task?19:16
yatesor anyone..19:16
LetoThe2ndyates: the usual way is just DEPENDing19:21
yatesi've done that19:21
yatesbut i'm getting the error /Storage/production-hardware-revision-A-1.0/sources/poky/build-hw-test-image/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/smart-display/1.0+3398-r0/branches/production-1.0/lib/inc/dbusutil/dbusutil.h:8:23: fatal error: dbus/dbus.h: No such file or directory19:22
opennandrayates: which build systemd is thing recipe using19:22
opennandracmake, automake ... ?19:22
yatesopennandra: my own make file19:22
yatesgnumake19:22
yatesi need to specify -I ${sysrootstuf}/usr/include/dbus-1.0 in my compiles do that "#include "dbus/dbus.h" will find the file19:23
yatesso how do i get ${sysrootstuff}?19:24
opennandrayates: EXTRA_OEMAKE = "-"19:24
yatesyou mean (e.g.) EXTRA_OEMAKE = "dbus-1.0"?19:24
opennandrabut path to dbus it's in sysroot19:25
*** kroon <kroon!~kroon@37-247-29-68.customers.ownit.se> has quit IRC19:26
opennandracheck recipe temp dir and see which include directoeies yocto add19:26
opennandraalso do you have dependency for dbus in your recipe?19:26
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has quit IRC19:26
yateslet me ask the question this way: if i were running a compile command "gcc -c -I<path-to-toplevel-system-include-dir>/dbus-1.0 myfancycode.c", then what syntax at do_compile time with give me <path-to-toplevel-system-include-dir>>?19:27
yatesopennandra: i do already have the DEPENDS on dbus, yes19:28
yatesi can see dbus-1.0/dbus.h in my tmp folder (down deep)19:28
zeddiiby default the compiler is called with the sysroot parameter, which makes all the includes relative to that point.19:28
yatess/with give me/will give me/19:28
yateszeddii: yeah but you need to extend the sysroot down to the library's include subdirectory, in this case dbus-1.019:29
yateshow do i do THAT with a -I?19:30
yateslots of libraries work this way - their includes are in subdirectories under the main include directory19:30
yatesthis same code builds on my desktop linux, but i have defined the proper -I command to swoop down into the dbus-1.0 subdirectory so the compile includes that path in its searching19:32
yatesperhaps it's for versioning. you might have dbus-0.7 and dbus-1.0, e.g.19:33
yatessurely this isn't that unusual?19:33
* zeddii reads above. the EXTRA_OEMAKE is the right way to pass options to the build. or you'd have to append to CFLAGS, and oe_runake takes care of passing that into the build (assuming it is using gnu make).19:33
*** armpit <armpit!~armpit@c-71-204-143-8.hsd1.ca.comcast.net> has quit IRC19:34
opennandrayates: what about to use cmake and properly find dependencies19:34
opennandrathen it wil lsetup paths19:34
opennandraand all will be good :)19:34
yatesyeah, sure ... i'm going to rewrite my entire build system to accommodate this.. .19:35
yatespfffft.19:35
yateszeddii: regarding EXTRA_OEMAKE, let me read more. are you saying it appends an include directory to the compiler search paths like a "-I <path>" does?19:36
*** moosnat <moosnat!~moosnat@unaffiliated/moosnat> has joined #yocto19:36
zeddiiit is passed as-is to the call to make. so your makefile needs to be taking inputs from the environment, etc.19:37
yatesis just read this: https://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-EXTRA_OECONF19:37
yatesi thought i'd stated repeatly that i am NOT using automake/configure etc. just my own gnumake file19:38
* zeddii isn't gong to scroll through history19:38
* zeddii wanders off19:38
yateszeddii: better to wander off than give bad information due to a lack of understanding..19:39
zeddiihahahahah19:39
zeddiifunny.19:39
zeddiigreat way to ask for help you have.19:39
yatesi just grow weary of wasting hours troubleshooting the bad advice i often get. and it's Friday afternoon and i'm getting cranky...19:40
halsteadkhem, Can you check if the issue is resolved?19:41
khemhalstead: I will let you know once I push again to contrib19:53
opennandrayates: try use : STAGING_INCDIR19:53
opennandra-I ${STAGING_INCDIR}/... untested19:53
opennandrayou can at least get info where it is pointing19:53
opennandrain logs19:53
halsteadThank you khem.19:54
khemyates: usually pkgconfig solves such path issues since we have pkgconfig aware of cross-compiling it will add the sysroot automatically19:55
khemSTAGING_INCDIR is OE specific and should not be used inside component Make systems unless OE is all you care for building for. Usually its better to make component build systems independent of meta builders19:56
opennandrakhem: this is true but soemtimes you just need to use it ;) if you cannot fix you makefile19:56
khemwhen you head from San Francisco to Tokyo but do a 1 degree direction adjustment at beginning, thinking its small, you will end up being in hawaii instead of tokyo19:58
khemso I always recommend to do the 'right thing' when you know it19:58
opennandrakhem: understand, was just joking19:58
khemyates: on bad advice, Trust me you can dance - Vodka20:02
khemshould I heed to vodka ? prolly no :) but that my decision20:03
khemalso takes some knowing :)20:03
*** tgraydon <tgraydon!tgraydon@nat/intel/x-rzujamomzbcyupzr> has joined #yocto20:04
khemJaMa:git prune should fix it, but it does not for contrib repos somehow20:05
JaMakhem: ok, interesting - works for me20:08
yatesha. vodka is good - yah!20:10
*** rcw <rcw!~rcw@128.224.252.2> has quit IRC20:10
yateskhem: pkgconfig is a good suggestion20:12
yatesi use it some places already but not everywhere20:13
yates(stated after yates noticed khem had been speaking about more than just vodka...)20:13
JaMahalstead: can you please delete following 3 branches from meta-openembedded repo? http://git.openembedded.org/meta-openembedded/log/?h=jansa/dizzy jansa/fido jansa/master ?20:13
halsteadJaMa, Sure. Or I can add config to allow you to delete any jansa/* branch if you prefer.20:14
JaMayou can just delete them, they are really old and I shouldn't create any more of them :)20:15
halsteadJaMa, One moment.20:15
halsteadJaMa, Removed now.20:19
JaMahalstead: thanks20:19
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC20:25
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has joined #yocto20:30
*** Chrusel_ <Chrusel_!~Chrusel76@p5B2249B9.dip0.t-ipconnect.de> has quit IRC20:32
*** kaspter <kaspter!~Instantbi@183.128.188.113> has quit IRC20:43
*** kaspter <kaspter!~Instantbi@183.128.188.113> has joined #yocto20:44
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:46
*** litb <litb!~litb___@p5B02F53B.dip0.t-ipconnect.de> has quit IRC20:50
*** yann <yann!~yann@aputeaux-655-1-52-10.w86-195.abo.wanadoo.fr> has joined #yocto20:54
*** opennandra <opennandra!~marek@109-230-35-25.dynamic.orange.sk> has quit IRC20:56
*** Crofton <Crofton!~Crofton@cust-west-pareq2-46-193-11-36.wb.wifirst.net> has quit IRC20:57
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:06
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC21:08
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC21:10
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto21:11
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto21:16
*** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC21:48
yoctiNew news from stackoverflow: does yocto have a package called realpath <https://stackoverflow.com/questions/57013620/does-yocto-have-a-package-called-realpath> || Yocto renames packages <https://stackoverflow.com/questions/57013587/yocto-renames-packages>21:52
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-vxowlwydjalfelvc> has joined #yocto22:13
*** agust <agust!~agust@pD95F1DFD.dip0.t-ipconnect.de> has quit IRC22:14
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto22:52
*** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC22:55
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC23:59

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!