Monday, 2019-10-21

*** yizhao <yizhao!~zhaoyi@> has joined #yocto01:12
*** Ad0 <Ad0!~Ad0@> has quit IRC01:35
*** Ad0 <Ad0!~Ad0@> has joined #yocto01:41
*** radeks <radeks!> has joined #yocto03:19
*** kaspter <kaspter!~Instantbi@> has quit IRC03:27
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:29
*** kaspter <kaspter!~Instantbi@> has quit IRC03:35
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:36
*** radeks <radeks!> has quit IRC03:59
*** camus <camus!~Instantbi@> has joined #yocto04:07
*** kaspter <kaspter!~Instantbi@> has quit IRC04:08
*** camus is now known as kaspter04:08
*** kaspter <kaspter!~Instantbi@> has quit IRC04:19
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:19
*** inf <inf!~informati@unaffiliated/informatic> has joined #yocto04:37
*** camus <camus!~Instantbi@> has joined #yocto05:16
*** kaspter <kaspter!~Instantbi@> has quit IRC05:17
*** camus is now known as kaspter05:17
*** AndersD <AndersD!> has joined #yocto05:17
*** kaspter <kaspter!~Instantbi@> has quit IRC05:26
*** camus <camus!~Instantbi@> has joined #yocto05:26
*** camus is now known as kaspter05:28
*** kaspter <kaspter!~Instantbi@> has quit IRC05:36
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:36
*** agust <agust!> has joined #yocto05:50
*** goliath <goliath!> has joined #yocto06:03
bojonesDevicetrees on intel EFI platforms - anyone with experience with that?06:04
LetoThe2ndbojones: i can't remember it being mentioned here so far.06:13
bojonesLetoThe2nd, thanks06:17
*** yizhao <yizhao!~zhaoyi@> has quit IRC06:27
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto06:29
*** alessioigor <alessioigor!~alessioig@> has joined #yocto06:29
*** yizhao <yizhao!~zhaoyi@> has joined #yocto06:29
*** alessioigor <alessioigor!~alessioig@> has quit IRC06:32
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC06:33
*** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto06:36
*** nslu2-log <nslu2-log!~nslu2-log@> has quit IRC06:40
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto06:43
*** lucaceresoli <lucaceresoli!> has joined #yocto06:43
*** nslu2-log <nslu2-log!~nslu2-log@> has joined #yocto06:44
*** abhiarora44 <abhiarora44!uid396576@gateway/web/> has joined #yocto06:44
abhiarora44Hello, i have figured out what python modules and packages I don't need. I can save 20 MB space for now. In what location I should list these python modules and packages to prevent yhem bein added to the final image?06:45
LetoThe2ndabhiarora44: well don't add them to IMAGE_INSTALL06:46
abhiarora44Someone suggested BAD_RECOMMENDATION. please help me with location of the file/recipe in which it should be added.06:46
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:47
abhiarora44IMAGE_INSTALL adds python3-core, python3-email.... Etc.06:48
abhiarora44However, these pulls various python modules and packages. Only subset is needed for my application. Like removing setuptools, lub2to3, pip, disutils is required. However, IMAGE_INSTALL lists python3-core  etc...06:48
LetoThe2ndi repeat: then do not write those things into IMAGE_ISNTALL06:49
abhiarora44I got you sir. But my IMAGE_INSTALL doesn't add the packages I want to remove. Are you saying these small modules & packages are being added somewhere?06:50
LetoThe2ndor even better, do not write ANYTHING into IMAGE_INSTALL, and only list in the DEPENDS of your application what you need.06:50
abhiarora44my IMAGE_INSTALL
LetoThe2ndseeriously, we are getting nowhere that way06:51
LetoThe2nd(and why for godssake a jpg?!?)06:52
abhiarora44The modules that I want to remove are not being listed but still they are pulled in by above statements.06:52
*** litb <litb!> has joined #yocto06:52
litbhello folks06:52
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC06:52
litbif I want to have a class of mine to overlay a class of another layer, I do need to list my layer before the other layer, if a recipe of that other lay makes use of the class, right?06:52
*** TobSnyder <TobSnyder!~schneider@> has joined #yocto06:53
LetoThe2ndabhiarora44: and which of those lines adds the undesired things? why is it there then? and, really, those things belong into the DEPENDS of your application06:53
litbbecause at the time of use, my layer need to have been read-in already.06:53
LetoThe2ndlitb: its ordering dependent, right06:53
litbah. I suspect I will split-up my layer then. into one "overlaying" layer and then the actual content layer06:53
abhiarora44I am manually copying my python application.06:54
LetoThe2ndabhiarora44: then it might be a *VERY* *GOOD* idea to start chaging that now.06:54
abhiarora44One more question, can I use individual python modules/packages in DEPENDS of my application?06:56
LetoThe2ndabhiarora44: if they are seperate packages, yes.06:56
abhiarora44Or I have to use things like python3-core, python3-misc. I am not sure what they pulls.06:56
LetoThe2ndabhiarora44: its all about packaging. its the same things you write into IMAGE_INSTALL and DEPENDS06:57
*** tprrt <tprrt!~tprrt@> has joined #yocto06:57
LetoThe2ndabhiarora44: the package management of yocto does not know the internal package structure of those pyhton things. so it might be that you have to split up some things, or whatever.06:58
litbLetoThe2nd, is it considered an error to have an overlay layer as first layer in BBLAYERS, if the layer is intended to overlay classes of another layer, and I specify that other layer as a LAYERDEPENDS ?06:58
LetoThe2ndgenerally the appraoch should be 1) create your application layer 2) add the needed things into DEPENDS. 3) if those thigns are too big, look at the recipes that provide them and see if they can be reduced.07:00
*** kroon <kroon!~kroon@> has joined #yocto07:01
LetoThe2ndabhiarora44: because the -misc package is maybe not a collection, but jut a really big package. i don't know, i'm no python guy. so if your project requires reducing it, you might need to split the packageing process up07:01
litbDEPENDS must use recipe names, not package names AFAIK07:02
*** thaytan <thaytan!> has quit IRC07:02
LetoThe2ndlitb: no.07:02
abhiarora44@LetoThe2nd: that's where I am confused. I want to know where are the recipes that pulls things like python3-core and how they do that, then may be add my own package like python3-myown which pulls particular files from online and have an recipe for application which depends upon my python3-myown07:03
litbbut the manual says "DEPENDS is a list of recipe names. Or, to be more precise, it is a list of PROVIDES names, which usually match recipe names. "07:04
LetoThe2ndabhiarora44: i already pointed out that oe-pkgdata-util can tell you all of that07:04
LetoThe2ndlitb: see, thats a difference07:05
litbYes, I'm in error. But half of what I said is true ><07:05
*** thaytan <thaytan!> has joined #yocto07:05
LetoThe2ndlitb: if it makes you feel better, then "ok, you are half right." ;)07:06
litbabhiarora44, you can also say "bitbake -g <yourimagerecipe>" or the recipe that you build and that happens to "strangely" build python3-core"07:06
litband then use oe-depends-blah (forgot the name of that util). with that you can finid out why python3-core is built07:07
litbthat's how I'm developing my mingw target layer and eliminate the need to build bash and base-files and so on07:07
abhiarora44Got it. But I also want to know what python modules python3-core pulls.07:14
abhiarora44Will try oe-pkgdata-util again.07:15
abhiarora44Pardon for newbies questions. It's a bit hard to understand how to get information you need from yocto for me.07:16
LetoThe2ndabhiarora44: its all fine, but you need to leave some assumptions behind, and thats the hard part.07:17
abhiarora44Just want to clarify one point. Things like python3-core is purely yocto entity? They exist in yocto world only and yocto has some list somewhere which lists what to pull from where?07:20
LetoThe2ndsame for python3-misc, for example07:21
*** fberndl <fberndl!d445ba28@> has joined #yocto07:23
litbthere's a tool in devtool add  that scans python packages for imported modules and transforms them to yocto package names07:23
litbI don't know whether this scanner can be used in isolation to scan python code and print out used packages07:23
LetoThe2ndthats not exactly a yocto specific technique, as far as i can see:
mcfriskhi, I'm seeing bitbake hang on zeus due to circular dependency problems. any ideas how to debug these and find out where the loop is? Only hint to problems is the hanging bitbake process with warning "Identifying dependency loops (this may take a short while)..."07:29
*** goliath <goliath!> has quit IRC07:29
litbmcfrisk, for me, i'm on warrior, and I did have dependency loops between gettext and glib.07:32
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto07:33
litbmcfrisk, before it printed the loops, it said "enable debug flags to see packaqes involved", or something similar07:33
litbmaybe those flags can help identify the problem?07:33
mcfrisklitb: ok, I'll need to check each loop which eventually gets printed. just got "Initialising tasks...ERROR: 495 unbuildable tasks were found" until now but after 10 minutes something was printed out.07:40
mcfrisksome bbappend and class change is now triggering this but can't yet tell which one..07:40
*** yacar_ <yacar_!~yacar@> has joined #yocto07:42
litbhm, I remember I did "A_override += 'foo'"  at one time, and it had some bad effects. I can't remember what it was07:43
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:43
litbI think it did override another "A += 'foo'", but I'm not sure whether it's even possible to override immediate appends like that07:44
*** mckoan|away is now known as mckoan07:45
mckoangood morning07:45
*** yacar_ <yacar_!~yacar@> has quit IRC07:46
LetoThe2ndmckoan: not sure about that.07:47
abhiarora44LetoThe2nd: if they are only yocto entity, then i should be able to find what yocto does when it sees python3-core and python3-misc. I will also try tools that you have suggested but grep is what I can do quickly07:50
LetoThe2ndabhiarora44: like i said, i think i even sent you the very lines that show how -misc is created on the mailing list07:50
LetoThe2ndabhiarora44: and oe-pkkdata-util certainly can tell you a lot about the resulting packages07:51
*** amine <amine!> has joined #yocto07:55
qschulzLetoThe2nd: If I may shime in, I found this file interesting: explicit all the RDEPENDS of python packages which are not explicitly declared in bb files07:56
qschulznot exactly on point with the discussion but thought it was worth mentioning07:57
*** amine <amine!> has quit IRC07:58
LetoThe2ndqschulz: it is certainly helpful! my knowledge is only generic, and not on python in any way as i avoid it07:59
*** amine <amine!> has joined #yocto08:06
tprrtHello, I have a question about the packaging of sources for out-tree kernel module. The sources do not seem properly packaged, unless there is a trick?08:06
LetoThe2ndtprrt: why should sources be packaged at all?08:07
*** yacar_ <yacar_!~yacar@> has joined #yocto08:08
yoctiNew news from stackoverflow: Yocto doesn't copy to rootfs <>08:08
tprrtLetoThe2nd: I mean in the "-src" package to debug08:08
*** goliath <goliath!~goliath@> has joined #yocto08:10
qschulztprrt: you can have a look with bitbake -e virtual/kernel, search for FILES_${PN}-src. That's what's used for filling the -src package. If there are missing paths, they need to be added. Also, any file matched by 2+ FILES variable will only appear in the first package that is.. packaged.08:11
qschulzLetoThe2nd: for the SO question, *.so are not packaged in the normal package but in the -dev package. Only the lib*.so.* (note the dot after so) libs are packaged in "normal" pacjkage08:13
*** Dracos-Carazza_ <Dracos-Carazza_!> has joined #yocto08:14
LetoThe2ndqschulz: ah great, please correct me there!08:14
*** Dracos-Carazza <Dracos-Carazza!> has quit IRC08:14
tprrtqschulz: thx, I will check if FILES_${PN}-src is correctly set.08:15
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:17
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC08:21
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:25
*** yacar_ <yacar_!~yacar@> has quit IRC08:32
*** Bunio_FH <Bunio_FH!> has joined #yocto08:32
mckoanLetoThe2nd: totally agree. Even worse, flooded everywhere here :-(08:37
LetoThe2ndmckoan: huh?08:37
*** lucaceresoli <lucaceresoli!> has quit IRC08:39
*** Bunio_FH <Bunio_FH!> has quit IRC08:40
*** yacar_ <yacar_!> has joined #yocto08:46
qschulzLetoThe2nd: your answer to the good morning of mckoan an hour ago :)08:47
LetoThe2ndyes thats clear, but i'm suprised that he feels flooded.08:47
mckoanLetoThe2nd: I mean streets aroud are flooded08:48
*** lucaceresoli <lucaceresoli!> has joined #yocto08:49
LetoThe2ndmckoan: strange, didn't get any news about it.08:50
LetoThe2ndmckoan: hmm :-/08:52
LetoThe2ndmckoan: ah
LetoThe2ndmckoan: didn't get much news, weekend with kids and all.08:53
*** ruru4143 <ruru4143!> has joined #yocto09:02
*** rburton <rburton!> has joined #yocto09:03
qschulzoh wow, gl!09:05
*** kaspter <kaspter!~Instantbi@> has quit IRC09:07
litbhm, I need to use the ${var##*} bash syntax. how can I prevent yocto from messing with it?09:07
LetoThe2ndlitb: compilcated, i think yocto bash parser is not exactly...bash09:08
litbsince it's used only for variable expansion in yocto, I hope yocto won't touch that bash syntax though ?09:08
litbi'll find out09:08
LetoThe2ndthere was something on the ml lately. maybe i can find it09:14
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:15
LetoThe2ndnope, sorry.09:18
*** Bunio_FH <Bunio_FH!> has joined #yocto09:26
*** fberndl <fberndl!d445ba28@> has quit IRC09:27
qschulzLetoThe2nd: Isn't the shell used to run the tasks is the one default on your system? I don't remember exactly but I think it's using sh from the host?09:32
LetoThe2ndqschulz: possibly. i don't know enough about it to comment properly09:32
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC09:34
rburtonlitb: can you write a script outside of a class file to execute instead?  you can't assume bitbake sh funcs run in bash anyway09:37
litbrburton, ah I see, thanks!09:38
litbrburton, I avoid [[ and any other bashisms. However ${##} and %% operators are not listed as bashisms as far as I can see. not sure09:41
rburtonunfortunately bitbake uses ${} so that makes using advanced expressions 'tricky'09:41
rburtoni guess the parser should check that the contents are just alphanumeric and pass through if not09:42
litbhm, I see09:42
*** zwelch <zwelch!> has quit IRC09:45
*** mabnhdev <mabnhdev!0c260e0a@> has joined #yocto09:50
frosteyesHi folks. Is there any standard way for deploying a dtsi / including it in devicetree?09:53
litbmaybe it works similarly to kernel config snippets09:54
LetoThe2ndfrosteyes: a dtsi cannot be deployed independently, its not meant for that09:54
LetoThe2ndfrosteyes: a dts file is meant to include it at build time. the resulting dtb is to be deployed.09:54
frosteyesMy situation is that I have created a recipe for something I call "mem-layout" it is from a git archive, whers it contains a spec and some python code for generating dtsi, header and c files etc.09:54
frosteyesMy devicetree depend on mem-layout and will include it.09:55
LetoThe2ndwell then whats the point?09:56
frosteyesAt least this is the plan..09:57
frosteyesCurrently I have created a "do_compile()" in the recipe for generating the dtsi, etc. but is strugling on how to provide it for devicetree.09:59
frosteyesSo more if any have worked with devicetree's where the needed to include dtsi from the outside..09:59
LetoThe2ndthe recipe providing the final dtb probably has to provide virtual/kernel-devicetree or something10:00
litbmaybe he's trying to "deploy" the  files from that recipe as input to a different recipe?10:00
frosteyeslitb: yes10:00
litbI think the correct way to do this is using recipe-sysroot functionality?10:00
LetoThe2ndfrosteyes: well what builds the *ACTUAL* devicetree?10:00
LetoThe2ndfrosteyes: because thats the real question.10:01
frosteyesA seperate recipe "devicetree"10:01
kanavinrburton, cheers (re: license per image work)10:01
kanavinrburton, I honestly don't remember about python and glib ptests10:01
kanavinrburton, so which way should we go with sysprof? add polkit to core or add sysprof to meta-oe?10:02
LetoThe2ndfrosteyes: so your problem is to pass a build artifact from one recipe to the next one?10:02
rburtonkanavin: i'm leaning towards polkit in core, as systemd wants to use it a lot too10:02
frosteyesIs the plan... The reason is that the devicetree is a bit complex. It is a ZynqMP device where you have the processor subsystem configuration from the HDF, the FPGA part, so I end up with a number of dtsi to combing it for the devicetree.10:03
frosteyesLetoThe2nd: yes.10:03
litbin addition to FILES_SOLIBSDEV, there should be a FILES_SOLIBS that instead of being ${libdir}/lib*${SOLIBS} is ${bindir}/lib*${SOLIBS}10:03
*** alessioigor <alessioigor!~alessioig@> has joined #yocto10:03
litband ideally a SOLIBSDIR that's   either ${bindir} or ${libdir}, depending on presence of mingw32 machine. also BASE_SOLIBSDIR . I think many packages can make use of that and will avoid a .bbappend in the meta-mingw layer10:04
frosteyesSo I want the devicetree to depend on the needed "subcomponents", and pass the dtsi as an artifact for the devicetree..10:04
LetoThe2ndfrosteyes: well then i'd probably make the dtsi generation a -native recipe, have the devicetree generation recipe depend on iit and be done. or, pour both into a bigger one.10:04
frosteyesLetoThe2nd: Thanks. will look into the -native recipe and this part..10:05
LetoThe2ndfrosteyes: in a nutshell, native means shall run on the dev host and not be crosscompiled/deployed.10:06
frosteyesThis was execatly what I was looking for. Just did not know the terminology10:07
litbfrosteyes, AFAIK, you need to install the dtsi into one of the dirs listed in SYSROOT_DIRS_NATIVE or stage your files manually in SYSROOT_PREPROCESS_FUNCS10:07
litbthen you can just DEPENDS on your native recipe from the final DTB recipe10:07
frosteyeslitb: that was the other part I needed.10:07
frosteyesYou are the greatest...10:07
LetoThe2ndfrosteyes: i know, but thanks for the confirmation!10:08
frosteyesYocto is cool, but it takes some time to learn it :)10:08
qschulzLetoThe2nd: SO question turned out a little simpler (most probably missing php-modphp in IMAGE_INSTALL) but still explained the whole FILES and .so* thing anyway10:13
LetoThe2ndqschulz: hrhrhr10:14
LetoThe2ndqschulz: almost a classic "wtf is this IMAGE_INSTALL, lets just add a rootfs postpropcessing command!"10:14
RPkanavin: agreed on polkit fwiw10:43
RPkanavin: and the license stuff is cool :)10:43
*** abhiarora44 <abhiarora44!uid396576@gateway/web/> has quit IRC10:44
*** bluca <bluca!~bluca@> has joined #yocto10:50
*** kaspter <kaspter!~Instantbi@> has quit IRC10:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto10:51
*** radsquirrel <radsquirrel!> has quit IRC10:53
*** radsquirrel <radsquirrel!> has joined #yocto10:54
*** mabnhdev <mabnhdev!0c260e0a@> has quit IRC11:04
*** mabnhdev <mabnhdev!0c260e0a@> has joined #yocto11:12
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto11:14
*** Dracos-Carazza_ is now known as Dracos-Carazza11:20
kayterinahallo. Would perlbrew not work in yocto? as in "install and switch to older perl version, then bitbake <recipe>?11:28
kayterinaI don't know, where does it takes the perl path from?11:29
LetoThe2ndkayterina: looks like some runtime package management thing. headaches ahead.11:30
*** diego_r <diego_r!> has joined #yocto11:30
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC11:32
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto11:34
*** mabnhdev <mabnhdev!0c260e0a@> has quit IRC11:34
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto11:38
yoctiNew news from stackoverflow: raspberry pi3 can not launch application on primary HDMI Display, can launch on remote using ssh -x <>11:39
*** dv_ <dv_!~dv@> has quit IRC11:53
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:57
*** berton <berton!~berton@> has joined #yocto12:00
*** berton <berton!~berton@> has quit IRC12:04
*** berton <berton!~berton@> has joined #yocto12:04
*** dv_ <dv_!~dv@> has joined #yocto12:07
*** mabnhdev <mabnhdev!0c260e0a@> has joined #yocto12:10
mabnhdevI'm in the process of upgrading from Sumo to Warrior.  After the upgrade, I'm missing some archiver source packages that used to be generated in Sumo.  For example, I no longer see a source package for bzip2.  Any idea why?12:14
mabnhdevCorrection: source tarball; not source package12:15
*** bisbarn <bisbarn!> has joined #yocto12:15
bisbarnhey guys, I was wondering if someone knows what the actual task is that copies the images from ${IMGDEPLOYDIR} to ${DEPLOY_DIR_IMAGE}? I try to add some additional symlinks and thought this could be done by simply adding them to ${IMGDEPLOYDIR}.12:17
LetoThe2ndbisbarn: bad idea, rather make them into a simple package for reproductibility purposes12:20
qschulzbisbarn: sstate-cache of do_image_complete of your image recipe and following line12:21
qschulzIf I'm not mistaken, writting to non sstate-cache'd dir of the task where you're doing things with the dir is not the best idea12:22
qschulzso the symlinking could be done in IMAGE_POSTPROCESS_COMMAND actually because of
LetoThe2ndsounds awful, to be honest12:23
LetoThe2ndthis ist stuff that nobody who looks at your recipes will understand without thinking at least twice12:24
bisbarnmmhhh, basically i just want to add a "release" dir within ${DEPLOY_DIR_IMAGE} and add some symlinks (or cp) for the images with a version tag in addition, is there a best practice for this?12:24
LetoThe2ndah thats what you mean. ok forget everything i said then.12:25
LetoThe2nd(i read it as "add symlinks into the image, in some form of postprocessing step")12:25
bisbarnqschulz: are the images already copied into ${DEPLOY_DIR_IMAGE} when the IMAGE_POSTPROCESS_COMMANDs run?12:27
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto12:27
ecdheI was able to easily patch the kernel in my build by generating a patch file and adding to SRC_URI+=.12:28
* alessioigor waves all, I have a package that install files and directories (like bin, sbin, usr and so on) into the image directory. The same recipe in -native install /home/alessio.bogani/WIP[a very long host path] into image directory. What I have made wrong?12:29
ecdheI'd like to do that same thing with u-boot, but I'm having trouble finding which SRCREV to make my diffs against.12:33
LetoThe2ndecdhe: bitbake -e your u-boot and grep for ^SRCREV12:33
qschulzbisbarn: I don't think no. You write to sstate-inputdirs in the task and the sstate-cache takes that and write it to the sstate-outputdirs is what I guessed. So same as you would do in a do_install where you install in ${D} and not in the actual rootfs, I would try to do the symlink in IMGDEPLOYDIR directly and see what happens12:33
ecdheLetoThe2nd: My uboot recipe uses AUTOINC, will that still work?12:33
LetoThe2ndecdhe: if you tell your recipe to exlicitly always use latest HEAD, then it obviously will not have a specific SRCREV, right?12:35
ecdheLetoThe2nd: granted12:36
qschulzecdhe: use devtool12:36
qschulzyou'll get the sources directly, patched and everything. Work on top of the sources in the workspace, create the patches, update the recipe, devtool reset, you're done :)12:42
ecdheqschulz: good word, taking a look at this now12:49
ecdheqschulz: for a workflow, do i still want to modify code, generate patches, and include them in SRC_URI?  Or can I modify code and use it directly?   I'm just adding printfs to debug a problem so I'm not worried about strict source control12:52
LetoThe2ndecdhe: during the debug phase of things like u-boot, i usually recommend to just not use yocto/oe, but build manually.12:52
qschulzecdhe: use devtool, until you devtool reset, Yocto is going to use the sources (even non commited) in the workspace of devtool12:53
*** amine <amine!> has quit IRC12:53
*** AndersD <AndersD!> has quit IRC13:03
*** yacar_ <yacar_!> has quit IRC13:04
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:05
*** goliath <goliath!~goliath@> has quit IRC13:09
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto13:11
bisbarnqschulz: allright IMAGE_POSTPROCESS_COMMAND works. My previous task ran after do_image I guess that was the issue. If i understand it correctly do_image_complete runs after do_image and thus in parallel to my own task.13:12
bisbarnI'm not that happy with IMAGE_POSTPROCESS_COMMAND I'd rather use a task, currently trying to add the task with before do_image_complete13:14
qschulzthe thing is, if you don't use the sstate-cache'd dirs, you'll run into problems later13:14
mabnhdevgit status13:14
qschulzwhen you clean something or Yocto retriggers some functions13:14
qschulzfatal: not a git repository13:15
LetoThe2ndqschulz: git beer?13:15
bisbarnyeah I allways wanted to use IMGDEPLOYDIR, but as I said since my task ran in parallel it didn't copy it over to DEPLOY_DIR_IMAGE ;)13:15
qschulzIMGDEPLOYDIR is sstate-cache'd in do_image_complete, not in other tasks13:16
bisbarnahhh now I understand13:16
*** WillMiles <WillMiles!> has joined #yocto13:17
bisbarnwell than I'll stick with the postprocess command, thank you ;)13:17
*** yacar_ <yacar_!> has joined #yocto13:17
qschulzand  the do_rootfs task clean IMGDEPLOYDIR every time it's run:
qschulzmy pleasure, I didn't know as well, just where to look :)13:18
bisbarnguess I should do some reading on sstate :D13:18
qschulzbisbarn: IIRC, there'll be a talk on it next week at Yocto dev days, hopefully the slides and talk will be available later13:20
bisbarnthanks for the info!13:20
qschulzIf you find something interesting on sstate-cache, let me know because I told you everything I knew :D13:20
qschulzand that's a topic I'm really new at13:21
bisbarnwill do13:21
rburtonRP:  would it be useful if i split out a chunk of mut that should be safe13:21
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC13:22
*** feilz <feilz!> has quit IRC13:24
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:25
yacar_Hey guys, I'm working on my freetime and now a bit on company time on SPDX identifiers, on the first patches, I only add the SPDX id, but I didn't removed the former header stating the licence, do I also need to remove the old header?13:26
*** berton <berton!~berton@> has quit IRC13:27
yacar_rburton: Ok, I think I initially asked this question, but speaking with coworker I couldn't explain why we shouldn't erase the header?13:35
rburtonwell typically a comment is more explicit, Copyright (C) Intel 2010-2019  etc etc13:35
rburtonspdx doesn't encode the ownership, just the license13:36
rburtonso i guess a license comment can go if you're adding spdx but there should still be some comment, and i'm not sure i'd be bothered to clean up already merged patches13:36
rburtonthe important thing is spdx headers are in13:36
yacar_Sure ok !13:37
*** TobSnyder <TobSnyder!~schneider@> has quit IRC13:44
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC13:46
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC13:48
RPrburton: please13:51
*** AndersD <AndersD!> has joined #yocto13:51
*** goliath <goliath!> has joined #yocto13:52
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:59
*** yacar_ <yacar_!> has quit IRC14:00
*** yacar_ <yacar_!> has joined #yocto14:01
*** mabnhdev38 <mabnhdev38!0c260e08@> has joined #yocto14:02
*** mabnhdev45 <mabnhdev45!0c260e08@> has joined #yocto14:03
*** mabnhdev <mabnhdev!0c260e0a@> has quit IRC14:03
*** atenart <atenart!> has left #yocto14:10
litbI don't know WTF is going on!14:19
LetoThe2ndlitb: welcome to my life!14:21
litbthe compiler claims that in line build-mingw/tmp/work/core2-64-w64-mingw32/qtbase/5.12.3+gitAUTOINC+b527725766-r0/recipe-sysroot/usr/include/freetype2/freetype/config/ftconfig.h , I try to inclide "bits/wordsize.h"14:21
litbI figured that there's a class "multilib_header.bbclass" that appears to wrap this header and adds macros for the machine's word size, for whatever reason14:22
litbHowever, I did override that function of that class that does this, by writing in my machine config this:  oe_multilib_header_mingw32() { : }14:23
litband it apparently works! that literal file that the compiler complains about does *not* include that header! in fact there's no header at all within <sysroot>/usr/include/freetype2 that includes the header. Still, I get the compile error14:24
litbwhat's going on?14:24
litbthe error happens during run of qtbase's do_configure, and makes it so that Qt thinks I have no working freetype library14:24
tprrtqschulz: My issue of packaging source files of out of tree kernel modules, seems to come from the fact that in the bbclass package, the *.ko are not a part of the elf_file dictionary (eg oe.package.is_elf), then the step separating debug files are not run.14:25
tprrtFor the same reason the out of tree kernel module are not stripped.14:25
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC14:26
kanavinRP: cheers :)14:29
*** ericch <ericch!> has joined #yocto14:44
*** opennandra <opennandra!> has joined #yocto14:45
opennandrahi, I pla nto add mplayer to my project (not fork one but original) does anybody know if recipe exists ?14:46
*** jmiehe <jmiehe!> has joined #yocto14:46
opennandrayes mpv is fork but I need to add:
ecdheLetoThe2nd, qschulz, thanks for your help -- I just got my own uboot running.14:50
LetoThe2ndecdhe: \o/14:50
*** AndersD <AndersD!> has quit IRC14:51
Crofton|workone of the unofficial hangouts14:56
*** kroon <kroon!~kroon@> has quit IRC14:58
litbInteresting! Even though I did -C do_configure , Qt still kept the build/ ${B} folder around.14:59
litbi had to rm -rf the workdir/build/ folder, and then it did pick up the new sysroot.. apparently qmake caches preprocessing results..14:59
*** bisbarn <bisbarn!> has quit IRC14:59
JPEWlitb: bitbake -c clean {recipe} should work also15:00
JPEWlitb: `bitbake -C configure` is only going to force do_configure to re-run, not (necessarily) clean out any working directories.15:01
*** mabnhdev45 <mabnhdev45!0c260e08@> has quit IRC15:18
rburtonlitb: bug in the qt recipe, configure should cleandirs[B]15:21
rburtoneg meson.bbclass do_configure[cleandirs] = "${B}"15:22
rburton"before running configure, this directory should exist but be empty"15:22
*** jmiehe <jmiehe!> has quit IRC15:23
* RP notes a "zecke-rocks" easter egg15:23
*** stephano <stephano!> has joined #yocto15:24
litbJPEW, I thought I tried that, but I think I instead tried it on the recipe where the header came from. next time I'll use clean15:25
* armpit wonders if this is related to the warrior failure:
litbrburton, ah I see15:26
RParmpit: fails too fast to be that - never boots15:26
*** tprrt <tprrt!~tprrt@> has quit IRC15:26
*** diego_r <diego_r!> has quit IRC15:27
*** diego_r <diego_r!> has joined #yocto15:27
*** yacar_ <yacar_!> has quit IRC15:31
*** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC15:31
*** brodrigues <brodrigues!> has joined #yocto16:05
rburtonlitb: fwiw, assuming qmake does proper out of tree builds, is just a one line fix to the class.16:08
rburtonand improves life for everyone16:08
rburtonso patches welcome :)16:08
litbI'll see what I can do16:08
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC16:08
litbcurrently I need to get the MS shader compiler working, so that Qt can use ANGLE, which is something that translates OpenGL calls to Direct3d on windows16:09
yoctiNew news from stackoverflow: How to set cmake parameter CMAKE_MODULE_PATH in Yocto project recipe? <>16:10
litbsadly the shader compiler exists only as a windows .exe, so I need to do some trickery using wine-native to execute it16:10
litbI could just use desktop opengl to build Qt, but opengl is said to be in sad state on windows, so angle seems favourable16:10
*** litb <litb!> has quit IRC16:13
*** goliath <goliath!> has quit IRC16:31
*** Bunio_FH <Bunio_FH!> has quit IRC16:39
yoctiNew news from stackoverflow: Porting flask ASK to bare metal Linux <>16:40
*** diego_r <diego_r!> has quit IRC16:41
*** mckoan is now known as mckoan|away16:44
*** mabnhdev <mabnhdev!0c260e0a@> has joined #yocto16:45
rburtonif anyone is running fedora and wants to help debug a mysterious autobuilder error then help would be appreciated16:51
rburtonturn on reproducible builds, build perl, archive the packages, build perl again, diffoscope on the output16:52
yoctiBug 13606: normal, Undecided, ---, paul.eggleton, NEW , perl isn't always reproducible16:52
mabnhdevTrying this question one more time before I go to mailing list...  I'm upgrading my project from Sumo to Warrior.  I use the archiver to create tarballs of the patched sources in DEPLOYDIR/sources.  In Warrior, I'm missing some tarballs for packages in IMAGE_INSTALL.  One example is bzip2.  Any idea why the source tarballs are no longer generated -16:52
mabnhdevthey were generated in Sumo.  Is there any way for me to force them to be generated?16:52
rburtonmabnhdev: are you sure bzip is being used? maybe it was removed in oe-core for whatever deps you had16:53
mabnhdevrburton: the RPM is being generated.  It should follow that the archiver should generate the tarball, no?16:55
*** vineela <vineela!~vtummala@> has joined #yocto16:55
mabnhdevrburton: tmp/deploy/rpm/x86_64/bzip2-1.0.6-r5.x86_64.rpm16:57
mihaimabnhdev, I'm not sure but maybe you're asking about having package_tar in PACKAGE_CLASSES ?16:58
mihaiyou can define it in your local.conf16:59
*** fray <fray!> has joined #yocto16:59
mabnhdevmihai: I do have defined in my local.conf in IMAGE_INSTALL.  That was sufficient in Sumo.  Has something changed for Warrior?17:00
mihaiand can have both: PACKAGE_CLASSES = 'package_rpm package_tar'17:01
mihaimabnhdev, I don't think so, but it has nothing to do with IMAGE_INSTALL17:03
mihaiin your example above do you want both bzip2-1.0.6-r5.x86_64.rpm and bzip2-1.0.6-r5.x86_64.tar to be generated?17:03
mabnhdevmihai: Ah, I see the confusion.  I'm not looking for the source package.  I want the archiver's tarball.  i.e. tmp/deploy/sources/bzip2-1.0.6-r0-patched.tar.gz.17:04
kergothOT, but is quite handy17:05
mabnhdevmihai: Section of Mega Manual.17:06
mihaimabnhdev, oh, that17:06
mihaiI see17:06
JPEWrburton: I can take a look. Is it happening every time?17:09
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:12
mihaimabnhdev, try checking do_deploy_archives logs for some package, e.g. bzip217:19
*** Bunio_FH <Bunio_FH!> has joined #yocto17:20
*** zwelch <zwelch!> has joined #yocto17:21
*** zwelch <zwelch!> has quit IRC17:24
*** zwelch <zwelch!> has joined #yocto17:26
mabnhdevmihai: It looks like they are all coming from setscene...17:27
*** bluca <bluca!~bluca@> has quit IRC17:29
mabnhdevmihai: However, even the packages for which I do have archiver tarballs came from setscene also.17:29
zwelchi'm having trouble building an arm 4.14 kernel for a custom bsp. It seems the kernel metadata (yocto-4.14 branch) includes old patches that were eventually included in that series, so those fail to apply. After removing those, do_patch tries to apply patches for a different architecture (mips). I can't imagine that I'm the only one trying to build a 4.14 kernel, so i feel like i must be doing something wrong.... specifically, it looks like the17:30
zwelchyocto 4.14 kernel metadata was last updated around 4.14.16; many/most of the patches it includes got accepted upstream shortly after that release, so trying to build the latest 4.14 kernel fails in do_patch. shouldn't that repo's branches be trimmed of patches that get upstreamed?17:30
*** mabnhdev48 <mabnhdev48!0c260e0a@> has joined #yocto17:32
*** mabnhdev <mabnhdev!0c260e0a@> has quit IRC17:35
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:35
*** mabnhdev48 <mabnhdev48!0c260e0a@> has left #yocto17:35
*** mabnhdev <mabnhdev!0c260e0a@> has joined #yocto17:36
mischiefhey rburton17:38
rburtonJPEW: repeatedly enough for RP to think its fedora specific at least17:42
*** junland <junland!~junland@> has quit IRC18:06
*** junland <junland!~junland@> has joined #yocto18:08
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:12
*** opennandra <opennandra!> has quit IRC18:12
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:32
*** florian_kc is now known as florian18:36
*** diego_r <diego_r!~diego@> has joined #yocto18:54
mischiefis there a way to disable or otherwise limit glibc-locale? i don't really care about any locale usage on my system.19:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:12
kergothmischief: GLIBC_GENERATE_LOCALES controls what ones are generated, if any19:19
kergothIMAGE_LINGUAS then controls which of the generated ones are installed19:19
*** diego_r <diego_r!~diego@> has quit IRC19:28
*** brodrigues <brodrigues!> has quit IRC19:33
mischiefkergoth: thanks!19:40
mischiefkind of annoying when you pass -j 48 and glibc-locale tries to run 48 parallel processes on my local machine generating locales :-P19:40
*** tgamblin <tgamblin!~tgamblin@> has quit IRC19:41
kergothi often set it to just en_US.UTF-8 when in development19:42
Crofton|workeveryone be sure to congratualte RP for 9 years at the Yocto Project19:57
Crofton|workonly 9 years since we learned about the Pky build system under a Concrod in Cambridge19:58
*** rcw <rcw!~rcw@> has joined #yocto20:01
*** rcw <rcw!~rcw@> has quit IRC20:04
armpityou wont let that go20:06
RPCrofton|work: so many memories of that...20:07
*** armpit <armpit!~armpit@2601:202:4180:a5c0:2c50:19ce:4df8:e156> has quit IRC20:15
*** Ad0 <Ad0!~Ad0@> has quit IRC20:16
*** armpit <armpit!~armpit@2601:202:4180:a5c0:d068:d1f3:5f97:dff3> has joined #yocto20:19
*** diego_r <diego_r!~diego@> has joined #yocto20:20
*** Ad0 <Ad0!~Ad0@> has joined #yocto20:23
Crofton|workrp yeah20:44
*** stephano <stephano!> has quit IRC20:52
*** diego_r <diego_r!~diego@> has quit IRC20:57
*** WillMiles <WillMiles!> has quit IRC21:06
bluelightninghi folks, FYI the OE TSC meeting is now starting over at #oe-tsc, anyone is welcome to join, minutes will be posted later as well21:07
*** goliath <goliath!> has joined #yocto21:19
*** stephano <stephano!> has joined #yocto21:36
*** robbawebba <robbawebba!~rob@> has joined #yocto21:56
robbawebbaHello, I've got a question about including specific kernel config options for a specific image. How might I go about including a few kernel config options in one specific image? My first thought is to use config fragments, but I'm not sure how to include the config fragment in the kernel recipe's SRC_URI variable if we're building a specific image. Is this task possible? or is there a better approach I should22:01
robbawebbabe considering?22:01
*** agust <agust!> has quit IRC22:36
ecdherobbawebba: what about making a custom layer, with a recipe for each of the various fragments--then include the recipes in the definition of each image?22:57
*** goliath <goliath!> has quit IRC23:00
*** rburton <rburton!> has quit IRC23:08
*** JaMa <JaMa!> has quit IRC23:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:33

Generated by 2.11.0 by Marius Gedminas - find it at!