| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 01:12 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 01:35 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 01:41 | |
| *** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto | 03:19 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.187> has quit IRC | 03:27 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has joined #yocto | 03:29 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has quit IRC | 03:35 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has joined #yocto | 03:36 | |
| *** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC | 03:59 | |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 04:07 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has quit IRC | 04:08 | |
| *** camus is now known as kaspter | 04:08 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 04:19 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 04:19 | |
| *** inf <inf!~informati@unaffiliated/informatic> has joined #yocto | 04:37 | |
| *** camus <camus!~Instantbi@222.67.188.177> has joined #yocto | 05:16 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 05:17 | |
| *** camus is now known as kaspter | 05:17 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:17 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has quit IRC | 05:26 | |
| *** camus <camus!~Instantbi@222.67.188.176> has joined #yocto | 05:26 | |
| *** camus is now known as kaspter | 05:28 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has quit IRC | 05:36 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has joined #yocto | 05:36 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:50 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 06:03 | |
| bojones | Devicetrees on intel EFI platforms - anyone with experience with that? | 06:04 |
|---|---|---|
| LetoThe2nd | bojones: i can't remember it being mentioned here so far. | 06:13 |
| bojones | LetoThe2nd, thanks | 06:17 |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has quit IRC | 06:27 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto | 06:29 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has joined #yocto | 06:29 | |
| *** yizhao <yizhao!~zhaoyi@60.247.85.82> has joined #yocto | 06:29 | |
| *** alessioigor <alessioigor!~alessioig@140.105.207.227> has quit IRC | 06:32 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has quit IRC | 06:33 | |
| *** rubdos <rubdos!~rubdos@2a02:578:859d:701:a846:9858:21a:9451> has joined #yocto | 06:36 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has quit IRC | 06:40 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 06:43 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 06:43 | |
| *** nslu2-log <nslu2-log!~nslu2-log@23.141.224.193> has joined #yocto | 06:44 | |
| *** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-yxkdpzomftudhvnt> has joined #yocto | 06:44 | |
| abhiarora44 | Hello, 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 |
| LetoThe2nd | abhiarora44: well don't add them to IMAGE_INSTALL | 06:46 |
| abhiarora44 | Someone suggested BAD_RECOMMENDATION. please help me with location of the file/recipe in which it should be added. | 06:46 |
| LetoThe2nd | *sigh* | 06:46 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:47 | |
| abhiarora44 | IMAGE_INSTALL adds python3-core, python3-email.... Etc. | 06:48 |
| abhiarora44 | However, 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 |
| LetoThe2nd | i repeat: then do not write those things into IMAGE_ISNTALL | 06:49 |
| abhiarora44 | I 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 |
| LetoThe2nd | or even better, do not write ANYTHING into IMAGE_INSTALL, and only list in the DEPENDS of your application what you need. | 06:50 |
| abhiarora44 | my IMAGE_INSTALL https://usercontent.irccloud-cdn.com/file/Cw5SCZMP/irccloudcapture1913995326.jpg | 06:51 |
| LetoThe2nd | seeriously, we are getting nowhere that way | 06:51 |
| LetoThe2nd | (and why for godssake a jpg?!?) | 06:52 |
| abhiarora44 | The modules that I want to remove are not being listed but still they are pulled in by above statements. | 06:52 |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has joined #yocto | 06:52 | |
| litb | hello folks | 06:52 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 06:52 | |
| litb | if 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@95.90.163.47> has joined #yocto | 06:53 | |
| LetoThe2nd | abhiarora44: and which of those lines adds the undesired things? why is it there then? and, really, those things belong into the DEPENDS of your application | 06:53 |
| litb | because at the time of use, my layer need to have been read-in already. | 06:53 |
| LetoThe2nd | litb: its ordering dependent, right | 06:53 |
| litb | ah. I suspect I will split-up my layer then. into one "overlaying" layer and then the actual content layer | 06:53 |
| abhiarora44 | I am manually copying my python application. | 06:54 |
| LetoThe2nd | abhiarora44: then it might be a *VERY* *GOOD* idea to start chaging that now. | 06:54 |
| abhiarora44 | One more question, can I use individual python modules/packages in DEPENDS of my application? | 06:56 |
| LetoThe2nd | abhiarora44: if they are seperate packages, yes. | 06:56 |
| abhiarora44 | Or I have to use things like python3-core, python3-misc. I am not sure what they pulls. | 06:56 |
| LetoThe2nd | abhiarora44: its all about packaging. its the same things you write into IMAGE_INSTALL and DEPENDS | 06:57 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 06:57 | |
| LetoThe2nd | abhiarora44: 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 |
| litb | LetoThe2nd, 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 |
| LetoThe2nd | generally 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@213.185.29.22> has joined #yocto | 07:01 | |
| LetoThe2nd | abhiarora44: 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 up | 07:01 |
| litb | DEPENDS must use recipe names, not package names AFAIK | 07:02 |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has quit IRC | 07:02 | |
| LetoThe2nd | litb: no. | 07:02 |
| litb | oh | 07:03 |
| 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-myown | 07:03 |
| litb | but 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 |
| LetoThe2nd | abhiarora44: i already pointed out that oe-pkgdata-util can tell you all of that | 07:04 |
| LetoThe2nd | litb: see, thats a difference | 07:05 |
| litb | Yes, I'm in error. But half of what I said is true >< | 07:05 |
| *** thaytan <thaytan!~thaytan@180-150-69-32.b49645.syd.nbn.aussiebb.net> has joined #yocto | 07:05 | |
| LetoThe2nd | litb: if it makes you feel better, then "ok, you are half right." ;) | 07:06 |
| litb | abhiarora44, you can also say "bitbake -g <yourimagerecipe>" or the recipe that you build and that happens to "strangely" build python3-core" | 07:06 |
| litb | and then use oe-depends-blah (forgot the name of that util). with that you can finid out why python3-core is built | 07:07 |
| litb | that's how I'm developing my mingw target layer and eliminate the need to build bash and base-files and so on | 07:07 |
| abhiarora44 | Got it. But I also want to know what python modules python3-core pulls. | 07:14 |
| abhiarora44 | Will try oe-pkgdata-util again. | 07:15 |
| abhiarora44 | Pardon for newbies questions. It's a bit hard to understand how to get information you need from yocto for me. | 07:16 |
| LetoThe2nd | abhiarora44: its all fine, but you need to leave some assumptions behind, and thats the hard part. | 07:17 |
| abhiarora44 | Just 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 |
| LetoThe2nd | yes. | 07:20 |
| LetoThe2nd | same for python3-misc, for example | 07:21 |
| *** fberndl <fberndl!d445ba28@212.69.186.40> has joined #yocto | 07:23 | |
| litb | there's a tool in devtool add that scans python packages for imported modules and transforms them to yocto package names | 07:23 |
| litb | I don't know whether this scanner can be used in isolation to scan python code and print out used packages | 07:23 |
| LetoThe2nd | thats not exactly a yocto specific technique, as far as i can see: https://stackoverflow.com/questions/9232568/identifying-the-dependency-relationship-for-python-packages-installed-with-pip | 07:27 |
| mcfrisk | hi, 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!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 07:29 | |
| litb | mcfrisk, 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 #yocto | 07:33 | |
| litb | mcfrisk, before it printed the loops, it said "enable debug flags to see packaqes involved", or something similar | 07:33 |
| litb | maybe those flags can help identify the problem? | 07:33 |
| mcfrisk | litb: 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 |
| mcfrisk | some bbappend and class change is now triggering this but can't yet tell which one.. | 07:40 |
| *** yacar_ <yacar_!~yacar@80.215.161.48> has joined #yocto | 07:42 | |
| litb | hm, I remember I did "A_override += 'foo'" at one time, and it had some bad effects. I can't remember what it was | 07:43 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:43 | |
| litb | I think it did override another "A += 'foo'", but I'm not sure whether it's even possible to override immediate appends like that | 07:44 |
| *** mckoan|away is now known as mckoan | 07:45 | |
| mckoan | good morning | 07:45 |
| *** yacar_ <yacar_!~yacar@80.215.161.48> has quit IRC | 07:46 | |
| LetoThe2nd | mckoan: not sure about that. | 07:47 |
| abhiarora44 | LetoThe2nd: 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 quickly | 07:50 |
| LetoThe2nd | abhiarora44: like i said, i think i even sent you the very lines that show how -misc is created on the mailing list | 07:50 |
| LetoThe2nd | abhiarora44: and oe-pkkdata-util certainly can tell you a lot about the resulting packages | 07:51 |
| *** amine <amine!~amine@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 07:55 | |
| qschulz | LetoThe2nd: If I may shime in, I found this file interesting: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/python/python3/python3-manifest.json explicit all the RDEPENDS of python packages which are not explicitly declared in bb files | 07:56 |
| qschulz | not exactly on point with the discussion but thought it was worth mentioning | 07:57 |
| *** amine <amine!~amine@static-176-158-51-218.ftth.abo.bbox.fr> has quit IRC | 07:58 | |
| LetoThe2nd | qschulz: it is certainly helpful! my knowledge is only generic, and not on python in any way as i avoid it | 07:59 |
| *** amine <amine!~amine@static-176-158-51-218.ftth.abo.bbox.fr> has joined #yocto | 08:06 | |
| tprrt | Hello, 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 |
| LetoThe2nd | tprrt: why should sources be packaged at all? | 08:07 |
| *** yacar_ <yacar_!~yacar@80.215.161.48> has joined #yocto | 08:08 | |
| yocti | New news from stackoverflow: Yocto doesn't copy libphp7.so to rootfs <https://stackoverflow.com/questions/58482161/yocto-doesnt-copy-libphp7-so-to-rootfs> | 08:08 |
| tprrt | LetoThe2nd: I mean in the "-src" package to debug | 08:08 |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:10 | |
| qschulz | tprrt: 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 |
| qschulz | LetoThe2nd: 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" pacjkage | 08:13 |
| *** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has joined #yocto | 08:14 | |
| qschulz | http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n299 | 08:14 |
| qschulz | http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n314 | 08:14 |
| LetoThe2nd | qschulz: ah great, please correct me there! | 08:14 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d1530cd.dynamic.kabel-deutschland.de> has quit IRC | 08:14 | |
| tprrt | qschulz: thx, I will check if FILES_${PN}-src is correctly set. | 08:15 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:17 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:21 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-umjpeeizdmxzwlwe> has joined #yocto | 08:25 | |
| *** yacar_ <yacar_!~yacar@80.215.161.48> has quit IRC | 08:32 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 08:32 | |
| mckoan | LetoThe2nd: totally agree. Even worse, flooded everywhere here :-( | 08:37 |
| LetoThe2nd | mckoan: huh? | 08:37 |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 08:39 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 08:40 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 08:46 | |
| qschulz | LetoThe2nd: your answer to the good morning of mckoan an hour ago :) | 08:47 |
| LetoThe2nd | yes thats clear, but i'm suprised that he feels flooded. | 08:47 |
| mckoan | LetoThe2nd: I mean streets aroud are flooded | 08:48 |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 08:49 | |
| LetoThe2nd | mckoan: strange, didn't get any news about it. | 08:50 |
| mckoan | LetoThe2nd: https://www.corriere.it/ | 08:51 |
| LetoThe2nd | mckoan: hmm :-/ | 08:52 |
| LetoThe2nd | mckoan: ah https://www.tagesschau.de/ausland/italien-unwetter-121.html | 08:53 |
| LetoThe2nd | mckoan: didn't get much news, weekend with kids and all. | 08:53 |
| *** ruru4143 <ruru4143!~ruru4143@vmi243882.contaboserver.net> has joined #yocto | 09:02 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:03 | |
| qschulz | oh wow, gl! | 09:05 |
| *** kaspter <kaspter!~Instantbi@222.67.188.181> has quit IRC | 09:07 | |
| litb | hm, I need to use the ${var##*} bash syntax. how can I prevent yocto from messing with it? | 09:07 |
| LetoThe2nd | litb: compilcated, i think yocto bash parser is not exactly...bash | 09:08 |
| litb | since it's used only for variable expansion in yocto, I hope yocto won't touch that bash syntax though ? | 09:08 |
| litb | i'll find out | 09:08 |
| LetoThe2nd | there was something on the ml lately. maybe i can find it | 09:14 |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto | 09:15 | |
| LetoThe2nd | nope, sorry. | 09:18 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:26 | |
| *** fberndl <fberndl!d445ba28@212.69.186.40> has quit IRC | 09:27 | |
| qschulz | LetoThe2nd: 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 |
| LetoThe2nd | qschulz: possibly. i don't know enough about it to comment properly | 09:32 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 09:34 | |
| rburton | litb: can you write a script outside of a class file to execute instead? you can't assume bitbake sh funcs run in bash anyway | 09:37 |
| litb | rburton, ah I see, thanks! | 09:38 |
| litb | rburton, I avoid [[ and any other bashisms. However ${##} and %% operators are not listed as bashisms as far as I can see. not sure | 09:41 |
| rburton | unfortunately bitbake uses ${} so that makes using advanced expressions 'tricky' | 09:41 |
| rburton | i guess the parser should check that the contents are just alphanumeric and pass through if not | 09:42 |
| litb | hm, I see | 09:42 |
| *** zwelch <zwelch!453bd872@fluffy.superlucidity.net> has quit IRC | 09:45 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has joined #yocto | 09:50 | |
| frosteyes | Hi folks. Is there any standard way for deploying a dtsi / including it in devicetree? | 09:53 |
| LetoThe2nd | huh? | 09:53 |
| litb | maybe it works similarly to kernel config snippets | 09:54 |
| LetoThe2nd | frosteyes: a dtsi cannot be deployed independently, its not meant for that | 09:54 |
| LetoThe2nd | frosteyes: a dts file is meant to include it at build time. the resulting dtb is to be deployed. | 09:54 |
| frosteyes | My 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 |
| frosteyes | My devicetree depend on mem-layout and will include it. | 09:55 |
| LetoThe2nd | well then whats the point? | 09:56 |
| frosteyes | At least this is the plan.. | 09:57 |
| frosteyes | Currently 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 |
| frosteyes | So more if any have worked with devicetree's where the needed to include dtsi from the outside.. | 09:59 |
| LetoThe2nd | the recipe providing the final dtb probably has to provide virtual/kernel-devicetree or something | 10:00 |
| litb | maybe he's trying to "deploy" the files from that recipe as input to a different recipe? | 10:00 |
| frosteyes | litb: yes | 10:00 |
| litb | I think the correct way to do this is using recipe-sysroot functionality? | 10:00 |
| LetoThe2nd | frosteyes: well what builds the *ACTUAL* devicetree? | 10:00 |
| LetoThe2nd | frosteyes: because thats the real question. | 10:01 |
| frosteyes | A seperate recipe "devicetree" | 10:01 |
| kanavin | rburton, cheers (re: license per image work) | 10:01 |
| kanavin | rburton, I honestly don't remember about python and glib ptests | 10:01 |
| kanavin | rburton, so which way should we go with sysprof? add polkit to core or add sysprof to meta-oe? | 10:02 |
| LetoThe2nd | frosteyes: so your problem is to pass a build artifact from one recipe to the next one? | 10:02 |
| rburton | kanavin: i'm leaning towards polkit in core, as systemd wants to use it a lot too | 10:02 |
| frosteyes | Is 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 |
| frosteyes | LetoThe2nd: yes. | 10:03 |
| litb | in 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@140.105.207.227> has joined #yocto | 10:03 | |
| litb | and 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 layer | 10:04 |
| frosteyes | So I want the devicetree to depend on the needed "subcomponents", and pass the dtsi as an artifact for the devicetree.. | 10:04 |
| LetoThe2nd | frosteyes: 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 |
| frosteyes | LetoThe2nd: Thanks. will look into the -native recipe and this part.. | 10:05 |
| LetoThe2nd | frosteyes: in a nutshell, native means shall run on the dev host and not be crosscompiled/deployed. | 10:06 |
| frosteyes | This was execatly what I was looking for. Just did not know the terminology | 10:07 |
| litb | frosteyes, 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_FUNCS | 10:07 |
| litb | then you can just DEPENDS on your native recipe from the final DTB recipe | 10:07 |
| frosteyes | litb: that was the other part I needed. | 10:07 |
| frosteyes | You are the greatest... | 10:07 |
| LetoThe2nd | frosteyes: i know, but thanks for the confirmation! | 10:08 |
| frosteyes | Yocto is cool, but it takes some time to learn it :) | 10:08 |
| qschulz | LetoThe2nd: SO question turned out a little simpler (most probably missing php-modphp in IMAGE_INSTALL) but still explained the whole FILES and .so* thing anyway | 10:13 |
| LetoThe2nd | qschulz: hrhrhr | 10:14 |
| LetoThe2nd | qschulz: almost a classic "wtf is this IMAGE_INSTALL, lets just add a rootfs postpropcessing command!" | 10:14 |
| RP | kanavin: agreed on polkit fwiw | 10:43 |
| RP | kanavin: and the license stuff is cool :) | 10:43 |
| *** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-yxkdpzomftudhvnt> has quit IRC | 10:44 | |
| *** bluca <bluca!~bluca@88.98.246.218> has joined #yocto | 10:50 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 10:50 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 10:51 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 10:53 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 10:54 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has quit IRC | 11:04 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has joined #yocto | 11:12 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 11:14 | |
| *** Dracos-Carazza_ is now known as Dracos-Carazza | 11:20 | |
| kayterina | hallo. Would perlbrew not work in yocto? as in "install and switch to older perl version, then bitbake <recipe>? | 11:28 |
| kayterina | I don't know, where does it takes the perl path from? | 11:29 |
| LetoThe2nd | kayterina: looks like some runtime package management thing. headaches ahead. | 11:30 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 11:30 | |
| *** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC | 11:32 | |
| *** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto | 11:34 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has quit IRC | 11:34 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 11:38 | |
| yocti | New news from stackoverflow: raspberry pi3 can not launch application on primary HDMI Display, can launch on remote using ssh -x <https://stackoverflow.com/questions/58485346/raspberry-pi3-can-not-launch-application-on-primary-hdmi-display-can-launch-on> | 11:39 |
| *** dv_ <dv_!~dv@62.178.50.190> has quit IRC | 11:53 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:57 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 12:00 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 12:04 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 12:04 | |
| *** dv_ <dv_!~dv@62.178.50.190> has joined #yocto | 12:07 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has joined #yocto | 12:10 | |
| mabnhdev | I'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 |
| mabnhdev | Correction: source tarball; not source package | 12:15 |
| *** bisbarn <bisbarn!~bisbarn@p5DF44FB8.dip0.t-ipconnect.de> has joined #yocto | 12:15 | |
| bisbarn | hey 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 |
| LetoThe2nd | bisbarn: bad idea, rather make them into a simple package for reproductibility purposes | 12:20 |
| qschulz | bisbarn: sstate-cache of do_image_complete of your image recipe https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image.bbclass#n278 and following line | 12:21 |
| qschulz | If 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 idea | 12:22 |
| qschulz | so the symlinking could be done in IMAGE_POSTPROCESS_COMMAND actually because of https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image.bbclass#n270 | 12:23 |
| LetoThe2nd | sounds awful, to be honest | 12:23 |
| LetoThe2nd | this ist stuff that nobody who looks at your recipes will understand without thinking at least twice | 12:24 |
| bisbarn | mmhhh, 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 |
| LetoThe2nd | ah 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 |
| bisbarn | :) | 12:27 |
| bisbarn | qschulz: are the images already copied into ${DEPLOY_DIR_IMAGE} when the IMAGE_POSTPROCESS_COMMANDs run? | 12:27 |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 12:27 | |
| ecdhe | I 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 | |
| ecdhe | I'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 |
| LetoThe2nd | ecdhe: bitbake -e your u-boot and grep for ^SRCREV | 12:33 |
| qschulz | bisbarn: 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 happens | 12:33 |
| ecdhe | LetoThe2nd: My uboot recipe uses AUTOINC, will that still work? | 12:33 |
| LetoThe2nd | ecdhe: if you tell your recipe to exlicitly always use latest HEAD, then it obviously will not have a specific SRCREV, right? | 12:35 |
| ecdhe | LetoThe2nd: granted | 12:36 |
| qschulz | ecdhe: use devtool | 12:36 |
| qschulz | you'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 |
| ecdhe | qschulz: good word, taking a look at this now | 12:49 |
| ecdhe | qschulz: 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 control | 12:52 |
| LetoThe2nd | ecdhe: during the debug phase of things like u-boot, i usually recommend to just not use yocto/oe, but build manually. | 12:52 |
| qschulz | ecdhe: use devtool, until you devtool reset, Yocto is going to use the sources (even non commited) in the workspace of devtool | 12:53 |
| *** amine <amine!~amine@static-176-158-51-218.ftth.abo.bbox.fr> has quit IRC | 12:53 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 13:03 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 13:04 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:05 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 13:09 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.142.95> has joined #yocto | 13:11 | |
| bisbarn | qschulz: 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 |
| bisbarn | I'm not that happy with IMAGE_POSTPROCESS_COMMAND I'd rather use a task, currently trying to add the task with before do_image_complete | 13:14 |
| qschulz | the thing is, if you don't use the sstate-cache'd dirs, you'll run into problems later | 13:14 |
| mabnhdev | git status | 13:14 |
| qschulz | when you clean something or Yocto retriggers some functions | 13:14 |
| qschulz | fatal: not a git repository | 13:15 |
| LetoThe2nd | qschulz: git beer? | 13:15 |
| bisbarn | yeah 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 |
| qschulz | IMGDEPLOYDIR is sstate-cache'd in do_image_complete, not in other tasks | 13:16 |
| bisbarn | ahhh now I understand | 13:16 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 13:17 | |
| bisbarn | well than I'll stick with the postprocess command, thank you ;) | 13:17 |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 13:17 | |
| qschulz | and the do_rootfs task clean IMGDEPLOYDIR every time it's run: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image.bbclass#n250 | 13:17 |
| qschulz | my pleasure, I didn't know as well, just where to look :) | 13:18 |
| bisbarn | guess I should do some reading on sstate :D | 13:18 |
| qschulz | bisbarn: IIRC, there'll be a talk on it next week at Yocto dev days, hopefully the slides and talk will be available later | 13:20 |
| bisbarn | thanks for the info! | 13:20 |
| qschulz | If you find something interesting on sstate-cache, let me know because I told you everything I knew :D | 13:20 |
| qschulz | and that's a topic I'm really new at | 13:21 |
| bisbarn | will do | 13:21 |
| rburton | RP: would it be useful if i split out a chunk of mut that should be safe | 13:21 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 13:22 | |
| *** feilz <feilz!~feil@212-50-143-116.co.dnainternet.fi> has quit IRC | 13:24 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13: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@181.220.83.67> has quit IRC | 13:27 | |
| rburton | nah | 13:29 |
| 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 |
| rburton | well typically a comment is more explicit, Copyright (C) Intel 2010-2019 etc etc | 13:35 |
| rburton | spdx doesn't encode the ownership, just the license | 13:36 |
| rburton | so 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 patches | 13:36 |
| rburton | the important thing is spdx headers are in | 13:36 |
| yacar_ | Sure ok ! | 13:37 |
| *** TobSnyder <TobSnyder!~schneider@95.90.163.47> has quit IRC | 13:44 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.142.95> has quit IRC | 13:46 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 13:48 | |
| RP | rburton: please | 13:51 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 13:51 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 13:52 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:59 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 14:00 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 14:01 | |
| *** mabnhdev38 <mabnhdev38!0c260e08@12.38.14.8> has joined #yocto | 14:02 | |
| *** mabnhdev45 <mabnhdev45!0c260e08@12.38.14.8> has joined #yocto | 14:03 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has quit IRC | 14:03 | |
| *** atenart <atenart!~atenart@ar1.ack.tf> has left #yocto | 14:10 | |
| litb | I don't know WTF is going on! | 14:19 |
| LetoThe2nd | litb: welcome to my life! | 14:21 |
| litb | the 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 |
| litb | I 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 reason | 14:22 |
| litb | However, I did override that function of that class that does this, by writing in my machine config this: oe_multilib_header_mingw32() { : } | 14:23 |
| litb | and 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 error | 14:24 |
| litb | what's going on? | 14:24 |
| litb | the error happens during run of qtbase's do_configure, and makes it so that Qt thinks I have no working freetype library | 14:24 |
| tprrt | qschulz: 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 |
| tprrt | For the same reason the out of tree kernel module are not stripped. | 14:25 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 14:26 | |
| kanavin | RP: cheers :) | 14:29 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 14:44 | |
| *** opennandra <opennandra!~marek@mail.guep.com> has joined #yocto | 14:45 | |
| opennandra | hi, I pla nto add mplayer to my project (not fork one but original) does anybody know if recipe exists ? | 14:46 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 14:46 | |
| tgamblin | opennandra: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=mplayer | 14:47 |
| opennandra | yes mpv is fork but I need to add: http://www.mplayerhq.hu/design7/dload.html#source | 14:48 |
| ecdhe | LetoThe2nd, qschulz, thanks for your help -- I just got my own uboot running. | 14:50 |
| LetoThe2nd | ecdhe: \o/ | 14:50 |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 14:51 | |
| Crofton|work | https://www.meltdown.bar/franchise | 14:56 |
| Crofton|work | one of the unofficial hangouts | 14:56 |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:58 | |
| litb | Interesting! Even though I did -C do_configure , Qt still kept the build/ ${B} folder around. | 14:59 |
| litb | i 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!~bisbarn@p5DF44FB8.dip0.t-ipconnect.de> has quit IRC | 14:59 | |
| JPEW | litb: bitbake -c clean {recipe} should work also | 15:00 |
| JPEW | litb: `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@12.38.14.8> has quit IRC | 15:18 | |
| rburton | litb: bug in the qt recipe, configure should cleandirs[B] | 15:21 |
| rburton | eg meson.bbclass do_configure[cleandirs] = "${B}" | 15:22 |
| rburton | "before running configure, this directory should exist but be empty" | 15:22 |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 15:23 | |
| * RP notes a "zecke-rocks" easter egg | 15:23 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 15:24 | |
| litb | JPEW, 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 clean | 15:25 |
| * armpit wonders if this is related to the warrior failure: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-graphics?h=zeus&id=3f5c70649a9aaa13ef755ea57576d2bd6d9d2e60 | 15:25 | |
| litb | rburton, ah I see | 15:26 |
| RP | armpit: fails too fast to be that - never boots | 15:26 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 15:26 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 15:27 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 15:27 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 15:31 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC | 15:31 | |
| *** brodrigues <brodrigues!~brodrigue@apolo.padtec.com.br> has joined #yocto | 16:05 | |
| rburton | litb: fwiw, assuming qmake does proper out of tree builds, is just a one line fix to the class. | 16:08 |
| rburton | and improves life for everyone | 16:08 |
| rburton | so patches welcome :) | 16:08 |
| litb | I'll see what I can do | 16:08 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:08 | |
| litb | currently 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 windows | 16:09 |
| yocti | New news from stackoverflow: How to set cmake parameter CMAKE_MODULE_PATH in Yocto project recipe? <https://stackoverflow.com/questions/58490097/how-to-set-cmake-parameter-cmake-module-path-in-yocto-project-recipe> | 16:10 |
| litb | sadly the shader compiler exists only as a windows .exe, so I need to do some trickery using wine-native to execute it | 16:10 |
| litb | I could just use desktop opengl to build Qt, but opengl is said to be in sad state on windows, so angle seems favourable | 16:10 |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has quit IRC | 16:13 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 16:31 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:39 | |
| yocti | New news from stackoverflow: Porting flask ASK to bare metal Linux <https://stackoverflow.com/questions/58490539/porting-flask-ask-to-bare-metal-linux> | 16:40 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 16:41 | |
| *** mckoan is now known as mckoan|away | 16:44 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has joined #yocto | 16:45 | |
| rburton | if anyone is running fedora and wants to help debug a mysterious autobuilder error then help would be appreciated | 16:51 |
| rburton | turn on reproducible builds, build perl, archive the packages, build perl again, diffoscope on the output | 16:52 |
| rburton | (https://bugzilla.yoctoproject.org/show_bug.cgi?id=13606) | 16:52 |
| yocti | Bug 13606: normal, Undecided, ---, paul.eggleton, NEW , perl isn't always reproducible | 16:52 |
| mabnhdev | Trying 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 |
| mabnhdev | they were generated in Sumo. Is there any way for me to force them to be generated? | 16:52 |
| rburton | mabnhdev: are you sure bzip is being used? maybe it was removed in oe-core for whatever deps you had | 16:53 |
| mabnhdev | rburton: the RPM is being generated. It should follow that the archiver should generate the tarball, no? | 16:55 |
| *** vineela <vineela!~vtummala@134.134.137.75> has joined #yocto | 16:55 | |
| mabnhdev | rburton: tmp/deploy/rpm/x86_64/bzip2-1.0.6-r5.x86_64.rpm | 16:57 |
| mihai | mabnhdev, I'm not sure but maybe you're asking about having package_tar in PACKAGE_CLASSES ? | 16:58 |
| mihai | you can define it in your local.conf | 16:59 |
| *** fray <fray!~fray@kernel.crashing.org> has joined #yocto | 16:59 | |
| mabnhdev | mihai: I do have defined in my local.conf in IMAGE_INSTALL. That was sufficient in Sumo. Has something changed for Warrior? | 17:00 |
| mihai | and can have both: PACKAGE_CLASSES = 'package_rpm package_tar' | 17:01 |
| mihai | mabnhdev, I don't think so, but it has nothing to do with IMAGE_INSTALL | 17:03 |
| mihai | in 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 |
| mabnhdev | mihai: 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 |
| kergoth | OT, but https://github.com/netromdk/vermin is quite handy | 17:05 |
| mabnhdev | mihai: Section 7.32.3.1 of Mega Manual. | 17:06 |
| mihai | mabnhdev, oh, that | 17:06 |
| mihai | I see | 17:06 |
| JPEW | rburton: I can take a look. Is it happening every time? | 17:09 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:12 | |
| mihai | mabnhdev, try checking do_deploy_archives logs for some package, e.g. bzip2 | 17:19 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:20 | |
| *** zwelch <zwelch!453bd872@fluffy.superlucidity.net> has joined #yocto | 17:21 | |
| *** zwelch <zwelch!453bd872@fluffy.superlucidity.net> has quit IRC | 17:24 | |
| *** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has joined #yocto | 17:26 | |
| mabnhdev | mihai: It looks like they are all coming from setscene... | 17:27 |
| *** bluca <bluca!~bluca@88.98.246.218> has quit IRC | 17:29 | |
| mabnhdev | mihai: However, even the packages for which I do have archiver tarballs came from setscene also. | 17:29 |
| zwelch | i'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 the | 17:30 |
| zwelch | yocto 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@12.38.14.10> has joined #yocto | 17:32 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has quit IRC | 17:35 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 17:35 | |
| *** mabnhdev48 <mabnhdev48!0c260e0a@12.38.14.10> has left #yocto | 17:35 | |
| *** mabnhdev <mabnhdev!0c260e0a@12.38.14.10> has joined #yocto | 17:36 | |
| mischief | hey rburton | 17:38 |
| rburton | JPEW: repeatedly enough for RP to think its fedora specific at least | 17:42 |
| JPEW | K | 17:42 |
| *** junland <junland!~junland@142.93.201.46> has quit IRC | 18:06 | |
| *** junland <junland!~junland@142.93.201.46> has joined #yocto | 18:08 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-umjpeeizdmxzwlwe> has quit IRC | 18:12 | |
| *** opennandra <opennandra!~marek@mail.guep.com> has quit IRC | 18:12 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:32 | |
| *** florian_kc is now known as florian | 18:36 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 18:54 | |
| mischief | is 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 #yocto | 19:12 | |
| kergoth | mischief: GLIBC_GENERATE_LOCALES controls what ones are generated, if any | 19:19 |
| kergoth | IMAGE_LINGUAS then controls which of the generated ones are installed | 19:19 |
| *** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 19:28 | |
| *** brodrigues <brodrigues!~brodrigue@apolo.padtec.com.br> has quit IRC | 19:33 | |
| mischief | kergoth: thanks! | 19:40 |
| mischief | kind of annoying when you pass -j 48 and glibc-locale tries to run 48 parallel processes on my local machine generating locales :-P | 19:40 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 19:41 | |
| kergoth | ha | 19:42 |
| kergoth | i often set it to just en_US.UTF-8 when in development | 19:42 |
| Crofton|work | everyone be sure to congratualte RP for 9 years at the Yocto Project | 19:57 |
| Crofton|work | only 9 years since we learned about the Pky build system under a Concrod in Cambridge | 19:58 |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 20:01 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 20:04 | |
| armpit | you wont let that go | 20:06 |
| RP | Crofton|work: so many memories of that... | 20:07 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:2c50:19ce:4df8:e156> has quit IRC | 20:15 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 20:16 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:d068:d1f3:5f97:dff3> has joined #yocto | 20:19 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 20:20 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 20:23 | |
| Crofton|work | rp yeah | 20:44 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC | 20:52 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 20:57 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:06 | |
| bluelightning | hi folks, FYI the OE TSC meeting is now starting over at #oe-tsc, anyone is welcome to join, minutes will be posted later as well | 21:07 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:19 | |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 21:36 | |
| *** robbawebba <robbawebba!~rob@12.206.203.186> has joined #yocto | 21:56 | |
| robbawebba | Hello, 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 should | 22:01 |
| robbawebba | be considering? | 22:01 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 22:36 | |
| ecdhe | robbawebba: 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!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:00 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:08 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 23:21 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:33 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!
