Tuesday, 2020-06-09

*** camus1 <camus1!~Instantbi@> has joined #yocto00:48
*** kaspter <kaspter!~Instantbi@> has quit IRC00:48
*** camus1 is now known as kaspter00:48
*** tolszak_ <tolszak_!~tolszak@apn-37-248-250-24.dynamic.gprs.plus.pl> has joined #yocto00:53
*** tolszak <tolszak!~tolszak@apn-31-0-21-156.dynamic.gprs.plus.pl> has quit IRC00:53
*** robert_yang <robert_yang!~robert@> has quit IRC01:01
*** robert_yang <robert_yang!~robert@> has joined #yocto01:02
*** rcw <rcw!~rcw@104-195-225-201.cpe.teksavvy.com> has quit IRC01:19
*** robert_yang <robert_yang!~robert@> has quit IRC01:20
*** robert_yang <robert_yang!~robert@> has joined #yocto01:20
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto01:44
*** robert_yang <robert_yang!~robert@> has quit IRC02:01
*** robert_yang <robert_yang!~robert@> has joined #yocto02:02
*** kaspter <kaspter!~Instantbi@> has quit IRC02:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:24
*** paulg <paulg!~paulg@135-23-37-86.cpe.pppoe.ca> has quit IRC02:48
*** volpi <volpi!4e2b4835@HSI-KBW-078-043-072-053.hsi4.kabel-badenwuerttemberg.de> has quit IRC03:02
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC03:16
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC03:20
*** pbb <pbb!~quassel@pleroma.pbb.lc> has quit IRC03:24
*** pbb <pbb!~quassel@pleroma.pbb.lc> has joined #yocto03:30
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto03:33
*** KindTwo <KindTwo!kindone@freenode/father-christmas/kindone> has joined #yocto04:24
*** KindOne <KindOne!kindone@freenode/father-christmas/kindone> has quit IRC04:24
*** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto04:27
*** armpit <armpit!~armpit@2601:202:4180:a5c0:590a:7b35:9222:2f9> has quit IRC04:27
*** KindTwo is now known as KindOne04:29
*** robert_yang <robert_yang!~robert@> has quit IRC04:30
*** robert_yang <robert_yang!~robert@> has joined #yocto04:31
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-vihiaowlqayrchbs> has quit IRC04:33
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC04:35
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto04:39
*** armpit <armpit!~armpit@2601:202:4180:a5c0:40c8:e68d:70bd:3b6> has joined #yocto04:40
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-hhjhwrfcknoqkknw> has quit IRC04:43
*** kaspter <kaspter!~Instantbi@> has quit IRC04:49
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:50
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC04:50
*** robert_yang <robert_yang!~robert@> has quit IRC04:51
*** robert_yang <robert_yang!~robert@> has joined #yocto04:51
*** jobroe <jobroe!~manjaro-u@p579eb62f.dip0.t-ipconnect.de> has joined #yocto04:51
opellowhat is the name for the variable suffix in cases like PREFERRED_VERSION_<recipe BPN> or RDEPENDS_<machine>?  it seems like it could be "variable override," but that seems maybe inaccurate04:52
opello(it does seem like maybe they are separate cases with the latter being an override and the former being some kind of package specifier ... but it'd be nice to know where that vocabulary is described to make cross-referencing it against the documentation easier)04:56
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC05:04
*** NiksDev3 <NiksDev3!~NiksDev@> has quit IRC05:08
*** ibinderwolf <ibinderwolf!~quassel@etrn.topcontrol.it> has joined #yocto05:10
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:8df7:a74c:c7f0:84d4> has quit IRC05:13
*** otavio <otavio!~otavio@> has joined #yocto05:16
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto05:16
*** gtristan <gtristan!~tristanva@> has quit IRC05:29
*** nameclash <nameclash!~nameclash@ip1f11b23e.dynamic.kabel-deutschland.de> has joined #yocto05:31
*** sgw <sgw!~sgw@> has quit IRC05:42
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto05:45
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC05:49
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto05:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC05:53
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto05:56
*** pohly <pohly!~pohly@p5b05684a.dip0.t-ipconnect.de> has joined #yocto05:57
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC05:57
*** gtristan <gtristan!~tristanva@> has joined #yocto06:18
*** frsc <frsc!~frsc@2003:a:e7a:6200:dcca:24d9:d4d5:17a> has joined #yocto06:24
*** mckoan|away is now known as mckoan06:43
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC06:50
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto06:53
*** nameclash <nameclash!~nameclash@ip1f11b23e.dynamic.kabel-deutschland.de> has quit IRC06:56
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:56
*** robert_yang <robert_yang!~robert@> has quit IRC06:57
*** robert_yang <robert_yang!~robert@> has joined #yocto06:57
*** nameclash <nameclash!~nameclash@ip1f11b23e.dynamic.kabel-deutschland.de> has joined #yocto07:02
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:08
*** tolszak_ <tolszak_!~tolszak@apn-37-248-250-24.dynamic.gprs.plus.pl> has quit IRC07:11
*** robert_yang <robert_yang!~robert@> has quit IRC07:14
*** robert_yang <robert_yang!~robert@> has joined #yocto07:14
*** davidinux <davidinux!~davidinux@> has joined #yocto07:17
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto07:21
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC07:23
*** tprrt <tprrt!~tprrt@> has joined #yocto07:26
*** robert_yang <robert_yang!~robert@> has quit IRC07:26
*** robert_yang <robert_yang!~robert@> has joined #yocto07:27
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:32
*** Guest44602 <Guest44602!~Thunderbi@> has joined #yocto07:33
*** alejandrohs <alejandrohs!~alejandro@> has joined #yocto07:34
*** kroon <kroon!~kroon@> has joined #yocto07:46
*** csanchezdll <csanchezdll!~user@galileo.kdpof.com> has joined #yocto07:53
*** robert_yang <robert_yang!~robert@> has quit IRC07:57
*** robert_yang <robert_yang!~robert@> has joined #yocto07:57
*** hpsy <hpsy!~hpsy@> has joined #yocto08:04
*** fneddy <fneddy!02f7f68a@x2f7f68a.dyn.telefonica.de> has joined #yocto08:04
*** robert_yang <robert_yang!~robert@> has quit IRC08:06
*** robert_yang <robert_yang!~robert@> has joined #yocto08:07
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC08:08
fneddyHi, i have a question and i couldn't find an answer so here i am now:   is it possible to declare a dependency in that way that whenever i build recipe 'A'  recipe 'B' should also be rebuild. independent if the source of 'B' changed?08:12
*** chris_ber <chris_ber!~quassel@> has joined #yocto08:14
Letothe2ndfneddy: i think a DEPENDS should already do that trick08:14
*** robert_yang <robert_yang!~robert@> has quit IRC08:16
*** robert_yang <robert_yang!~robert@> has joined #yocto08:17
fneddyok, then i have done something wrong in my recipe, till try to debug. good to know that i am on the right way through :)08:18
Letothe2ndfneddy: what is the *actual* problem, though? because this sounds very much like a x-y situation.08:19
fneddywe have a recipe B that generates some files that are used in A.  But we cannot use an *old* result of B. so whenever A rebuild B should also rebuild.08:20
Letothe2ndthat is just rewording, plus describing the dependency backwards.08:21
*** robert_yang <robert_yang!~robert@> has quit IRC08:26
*** robert_yang <robert_yang!~robert@> has joined #yocto08:26
qschulzMmmm just wondering if there is a way to create a dot file to find which recipes are dependent on a specific recipe and ideally in a tree fashion08:28
Letothe2ndfneddy: or wait. A uses the files of B. so you really want B(!!) to rebuild if A rebuilds? so, if the *consumer* is being rebuilt you also want the producer to follow?08:28
qschulzI could grep the dot file but then I lose the information of whether it's a direct dependency or not08:28
Letothe2ndfneddy: because in that case - no, thats not how it works.08:30
*** ant__ <ant__!~ant__@host-195-31-129-205.business.telecomitalia.it> has joined #yocto08:31
*** yacar_ <yacar_!~yacar_@91-168-169-253.subs.proxad.net> has joined #yocto08:35
*** kroon_ <kroon_!~kroon@> has joined #yocto08:39
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto08:40
*** kroon <kroon!~kroon@> has quit IRC08:42
*** Prem <Prem!0e8bb7dd@> has joined #yocto08:44
*** gtristan <gtristan!~tristanva@> has quit IRC08:45
*** robert_yang <robert_yang!~robert@> has quit IRC08:45
*** robert_yang <robert_yang!~robert@> has joined #yocto08:46
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto08:47
fneddyhmm, will try around. i will come back when i understand the problem better.08:47
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:55
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC08:55
*** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC08:58
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC08:59
*** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto09:01
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto09:07
*** kriive <kriive!~kriive@> has joined #yocto09:14
*** gtristan <gtristan!~tristanva@> has joined #yocto09:27
*** florian_kc is now known as florian09:37
*** Guest44602 <Guest44602!~Thunderbi@> has quit IRC09:39
*** Prem <Prem!0e8bb7dd@> has quit IRC09:43
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:8df7:a74c:c7f0:84d4> has joined #yocto09:43
*** robert_yang <robert_yang!~robert@> has quit IRC09:50
*** robert_yang <robert_yang!~robert@> has joined #yocto09:52
kriiveHi guys, my bin_package recipe complains about libXdamage.so.1 and a whole lot of libXblahblah missing09:57
kriiveBut I made my recipe DEPEND on it, what am I doing wrong?09:57
Letothe2ndkriive: you are using a bin_package. </SCNR>09:57
kriiveYeah ahahah indeed09:58
kriiveBut that's my only option, employer said: we must use this specific version of teamviewer (which is only available in an ancient .deb downloaded from Ubuntu years ago) before we can actually consider using you fancy solution based on Yocto09:59
*** gaston53 <gaston53!c50120ff@> has joined #yocto09:59
gaston53hello, who has informations about kernel menuconfig of the yocto project ?10:00
gaston53bitbake -c menuconfig virtual/kernel10:00
*** robert_yang <robert_yang!~robert@> has quit IRC10:00
*** robert_yang <robert_yang!~robert@> has joined #yocto10:01
qschulzgaston53: what's the actual question?10:01
Letothe2ndkriive: i have to admit unless i can actually bill your employer for it, i do not feel inclined to give more advice than "look at the bin_package class to see what it does, look at the error logs, have fun wasting your time with it."10:01
qschulzkriive: you're probably missing a lot of RDEPENDS aren't you/10:01
Letothe2ndqschulz: as he didn't even say when or when doing hat that error occurred? ;-)10:02
qschulzkriive: DEPENDS and bin_package do not make sense at all10:03
qschulzDEPENDS is for build time, but you're not "building" the source code because well... it's already pre-compiled for you10:03
Letothe2ndqschulz: unless the bin_package in question has fun with pre-postinstall scripts....10:04
* Letothe2nd is being the grumpy Jester :)10:05
gaston53qschulz menuconfig is used to add or remove some features. For example, I want to remove SPI support from my kernel. When I look for SPI in device drivers ( in the menuconfig ) and hit `shift+?` to see informations about this SPI, a window appears with some informations10:05
gaston53depends on : ....10:05
gaston53selected by : ...10:05
gaston53selects : ...10:05
gaston53should I remove the SPI without taking care about those ?10:06
gaston53and rebuild my image10:06
qschulzgaston53: "should I not take care of dependencies?" well.. :)10:07
kriiveThat's my question, one of the error says: nothing provides libXdamage.so.1 needed by teamviewer-12.1.83885. But my RDEPENDS has explicitly libxdamage in it, that's what confuses me10:08
gaston53qschulz dependencies will be carried automaticaly when I rebuild the kernel ?10:08
gaston53that's the use of the menuconfig10:09
gaston53right ?10:09
qschulzgaston53: yes but not exactly10:09
kriiveLetothe2nd: yes, but that prepostinstall will come later, I haven't managed to reach that point yet10:09
qschulzgaston53: rule 1: do not edit defconfig by hand but it seems you're already following this one10:09
Letothe2ndkriive: billing address?10:09
qschulzthe issue with using menuconfig only is that it does not save the changes in a defconfig. Only in the local .config10:10
gaston53qschulz I have tried to do it by hand but when I rebuild the kernel I must select each time if I want to add X or to add Y feature10:10
qschulzgaston53: so when your recipe is rebuilt, depending on which task has to be done again, it'll erase your changes10:10
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC10:10
kriiveLetothe2nd: Gotta pay university bills man sorry, I will try something else haha10:11
qschulzgaston53: there is a reason menuconfig exists, so do not edit by hand :)10:11
Letothe2ndkriive: have fun then!10:11
qschulzgaston53: so.. once you've saved your config with menuconfig, you probably need to run savedefconfig as well10:11
qschulzthen with this defconfig (available in WORKDIR/build of your recipe IIRC), add it to your recipe or patch the original defconfig you used10:12
qschulzthat's the very basic workflow, but Yocto provides support for kernel defconfig fragment (.scc of .cfg files) so you can also do diffconfig I think and just add this fragment to your recipe. This is supported if kernel-yocto is inherited by your recipe10:13
qschulzWhich isn't the case for all BSPs, so you have to check10:13
gaston53qschulz yes I read about this10:14
gaston53qschulz let's go back to my first questions10:14
gaston53If I remove, for example, SPI10:14
gaston53the " selects " feature will be removed also10:15
gaston53if they are not used by something else10:15
gaston53right ?10:15
qschulzgaston53: not necessarily, if something else depends on it or selects it, it'll stay10:15
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto10:16
gaston53" depends on "10:16
qschulzkriive: I suspect libdamage package is providing libXdamage.so.1.X and not libXdamage.so.1 which should be a symlink10:16
gaston53if I chose to put SPI again10:16
qschulzgaston53: or if explicitely enabled10:16
gaston53should I select " depends on " manualy in the menuconfig10:16
gaston53or will be selected automaticaly10:17
qschulzgaston53: mmmm actually I think I'm wrong. If you have selected a Kconfig entry which does a "selects" I think it does not un-select them. Anyway, that's a topic more for some other IRC channel :)10:17
qschulzgaston53: yes, depends on needs to be satisfied before you can enable the Kconfig option which has the "depends on"10:18
gaston53if they are enabled autmaticaly it will be better :/10:19
qschulz(you should have seen that you can't even select and see the option (except in the search) if the depends on is not satisfied10:19
*** bobo <bobo!~Thunderbi@> has joined #yocto10:19
*** bobo is now known as Guest7373910:19
qschulzgaston53: you can't, because it's a reverse dependency and some are architecture dependent10:19
qschulzso how do you know which one to enable? (some Kconfig options have a depends on THIS && THAT || THOSE10:20
qschulzgaston53: but just to be clear, that's nothing to do with Yocto (menuconfig and Kconfig mechanism)10:21
gaston53qschulz I was about asking last question but you made me stop :p10:21
gaston53so where can I ask about this ?10:22
qschulzabout what? I answered your question fully  I think. What's missing?10:23
gaston53you said to me that's nothing to do with yocto10:23
gaston53and I am asking in Yocto room10:23
qschulzIndeed, but what is missing in your understanding of the Kconfig selection?10:24
qschulzYou should be able to join #linux on freenode. Don't know if it's the proper channel /me shrugs10:25
gaston53my last question about " selected by " ... for example SPI is selected by ethernet , I remove SPI , but I don't remove ethernet10:25
gaston53you see ? SPI will be re-enabled if I don't remove ethernet ?10:25
qschulzMy understanding is that selects is just an optional dependency. So if you remove SPI, Ethernet should still be there. No guarantee that it compiles but my understanding is that you can have ethernet without SPI, otherwise you'd have a depends on10:28
qschulzAnd tbh, that's something you can test :)10:28
*** armpit <armpit!~armpit@2601:202:4180:a5c0:40c8:e68d:70bd:3b6> has quit IRC10:29
qschulzgaston53: https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html and I'm out :) We polluted a bit too much #yocto with kernel specific questions :) Good luck!10:31
gaston53qschulz thanks and sorry for that10:32
qschulzkriive: so probably needs to patchelf on the original binary to make it depend on the correctly versioned lib or make the package from libdamage to also give libXdamage.so.1 (which should be provided by libdamage-dev but IMO bad idea to add it to your RDEPENDS as it brings a few things you don't need IIRC)10:33
*** armpit <armpit!~armpit@2601:202:4180:a5c0:40c8:e68d:70bd:3b6> has joined #yocto10:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC10:43
*** robert_yang <robert_yang!~robert@> has quit IRC10:48
*** robert_yang <robert_yang!~robert@> has joined #yocto10:49
*** m1ster_r0b0t <m1ster_r0b0t!~m1ster_r0@80-110-44-28.static.upcbusiness.at> has quit IRC10:56
*** m1ster_r0b0t <m1ster_r0b0t!~m1ster_r0@80-110-44-28.static.upcbusiness.at> has joined #yocto10:56
*** gtristan <gtristan!~tristanva@> has quit IRC11:10
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto11:12
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d154318.dynamic.kabel-deutschland.de> has quit IRC11:15
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@ip4d154318.dynamic.kabel-deutschland.de> has joined #yocto11:16
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC11:17
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto11:22
*** gaston53 <gaston53!c50120ff@> has quit IRC11:24
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC11:27
kriiveqschulz: thank you! I tried adding libXdamage to my RDEPENDS, with no luck haha11:28
kriiveBut I guess I will try to change strategy11:28
*** mattovsky <mattovsky!~mattovsky@dedicated-aid154.rev.nazwa.pl> has quit IRC11:29
kriiveMaybe using docker + X11 forwarding or stuff like that11:29
*** hipr_C <hipr_C!~Thunderbi@45-18-201-130.lightspeed.lsvlky.sbcglobal.net> has joined #yocto11:34
*** fneddy <fneddy!02f7f68a@x2f7f68a.dyn.telefonica.de> has quit IRC11:34
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:8df7:a74c:c7f0:84d4> has quit IRC11:36
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto11:37
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-trfbgixrwsurunjn> has joined #yocto11:38
*** berton <berton!~berton@> has joined #yocto11:43
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto11:50
*** Dracos-Carazza_ is now known as Dracos-Carazza11:50
*** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/kiwiirc.com/ip.> has quit IRC11:59
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto12:10
*** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/kiwiirc.com/ip.> has joined #yocto12:15
*** paulg <paulg!~paulg@135-23-37-86.cpe.pppoe.ca> has joined #yocto12:16
*** chandana73 <chandana73!~ckalluri@> has quit IRC12:19
*** chandana73 <chandana73!~ckalluri@> has joined #yocto12:20
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto12:27
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC12:28
*** aidanh_ is now known as aidanh12:28
*** sgw <sgw!~sgw@> has joined #yocto12:33
*** sno <sno!~sno@p4fe931fc.dip0.t-ipconnect.de> has quit IRC12:37
*** wertigon <wertigon!~per@c-7968225c.021-396-7673741.bbcust.telenor.se> has joined #yocto12:42
wertigonOkay, running circles in the docs here for something that should be super-easy - how the heck do I run a command *in* the image rootfs?12:42
wertigonI want to generate a couple of files at the end of the image creation, and I've managed to get most things to work, but it's not inside the root -_-12:43
RPwertigon: Add a function to  ROOTFS_POSTPROCESS_COMMAND ?12:45
*** maudat <maudat!~moda@mtrlpq2848w-lp130-04-70-29-226-188.dsl.bell.ca> has joined #yocto12:49
wertigonThat might be it, thank you!12:50
wertigonHmmm, maybe...?12:51
wertigonNo, I do have it in there12:52
*** kriive <kriive!~kriive@> has quit IRC12:52
kanavin_homeRP: cheers for the update set - I ran it through AB to make it smooth for you :)12:53
wertigonwhat I want to do is to run ldconfig, within the root jail12:53
kanavin_homeRP: the list of outdated recipes is very short now \0/ the only significant item there is qemu 5.0 update12:53
Letothe2ndwertigon: and what if the rootfs arch cannot execute on your host?12:53
Letothe2ndwertigon: that sounds very much like you are actually trying to band-aid something completely different.12:54
wertigonLetothe2nd: Yeah, that's kinda my problem :P12:54
kanavin_homeRP: (you can mention that in the status email perhaps)12:54
Letothe2ndwertigon: try to fix the problem instead of adding band-aid, maybe?12:54
*** frsc <frsc!~frsc@2003:a:e7a:6200:dcca:24d9:d4d5:17a> has quit IRC12:55
wertigonLetothe2nd: What I want to do is reduce the boot times by NOT having systemd generate certain files it should have pre-generated to begin with12:55
*** frsc <frsc!~frsc@2003:a:e7a:6200:dcca:24d9:d4d5:17a> has joined #yocto12:55
RPkanavin_home: it was very smooth, thanks. I did notice the builds and the fact it built cleanly! :)12:56
wertigonmore specifically, /etc/ld.so.cache and /etc/udev/hwdb.bin12:56
RPkanavin_home: I was wondering how the list looked now! :)12:56
Letothe2ndwertigon: hum just do the stuff that gets applied upon image feature read-only-rootfs, then?12:56
RPkanavin_home: you should give the qemu maintainer a good kick to sort that...12:56
wertigonThis can be done by running ldconfig12:56
wertigonLetothe2nd: I have applied that image feature12:57
yann|workI have a system cross-build setup starting to work - except for the interesting stuff, the one that needs kernel debuginfo. stap expects to find the kernel debug info somewhere, but vmlinux isn't exported to STAGING_KERNEL_BUILDDIR.  If I copy it manually, however, the build does work.  Is there any reason not to copy it in kernel.bbclass::do_shared_workdir ?12:57
wertigonNo luck :(12:57
*** yann|work is now known as yann12:57
RPwertigon: those are supposed to be generated at build time. Are you saying they don't get generated or that they're regenerated at first boot?12:58
RPwertigon: we have to consider the cross case which is why ldconfig-native is used for the ld cache, not ldconfig12:58
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto12:59
Letothe2ndi still there is something weird there, as i have a pretty run of the mill ro rootfs here and the files are around.13:00
qschulzwertigon: BAD_RECOMMENDATIONS += "eudev-hwdb"?13:04
qschulz(if it's eudev you're using, which I doubt.. but there might be a similar trick for udev?)13:04
wertigonRP: Regenerated13:06
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC13:06
wertigonThey are generated but keeps getting regenerated13:06
wertigonIf I look in the overlayfs13:06
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto13:07
RPwertigon: so the question is what is wrong with the files causing them to be regenerated13:07
wertigonRP: Yes, that or systemd is simply regenerating them out of spite13:07
wertigonOr rather, as a standard action13:08
RPwertigon: definitely possible, or its seeing timestamps not matching13:08
wertigonHmmm, maybe if I copy /etc/udev/hwdb.bin to /lib/udev/hwdb.bin regen13:08
wertigonI'll try that atleast13:09
yannwe can't even bring vmlinux into recipe-sysroot, since it is not exported to sysroot either13:09
yannsmurray: did you have a clean way to handle this case ?13:10
kanavin_homeRP: for qemu I have a WIP patch, which caused lots of red on the AB, so I was hoping the maintainer would get to it... :) http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates-later&id=216aea02e5a7fd13f0be368b5bd37ca852b5d3bc13:11
RPkanavin_home: have a link to a failed build?13:11
kanavin_homeRP: yes, just a sec13:11
smurrayyann: that was an outstanding issue when I was looking at it, iirc I patched the kernel recipe to deploy vmlinux so it could be used13:12
kanavin_homeRP: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/103713:13
yannsmurray: ok, I guess sending such a patch in the series will be a good way to start the discussion ;)13:13
RPkanavin_home: interesting, build failures. I can probably debug that...13:14
RPkanavin_home: one thing which puzzles me. I ran 'devtool check-upgrade-status' and it shows me things like "INFO: mc                       4.8.24          Ross Burton <ross.burton@arm.com> "13:19
RP$ bitbake mc -e | grep ^PV=13:19
rburtonalso no way is mc mine13:19
RPkanavin_home: any idea why it would show
RPrburton: hahaha13:20
Letothe2ndwhat, no "MC Ross"?13:20
RPrburton: RECIPE_MAINTAINER_pn-mc = "Ross Burton <ross.burton@arm.com>"13:20
rburtonRP: clearly thats your baby13:20
RPrburton: I've always been puzzled why you owned it but...13:21
rburtonRP: if i own it, can i remove it from core13:22
RPrburton: not until I'm on holiday13:22
rburtonthat could take forever13:22
RPrburton: I did say that smiling :)13:22
*** kroon_ <kroon_!~kroon@> has quit IRC13:24
Letothe2ndwhat, there is no metal cover of "dreadlock holiday"? (re: RP on holiday)13:25
kanavin_homeRP: you have meta-gpl2 enabled13:29
kanavin_homesomehow devtool picks up the version from there13:30
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC13:32
smurrayheh, so mc is up for grabs wrt a maintainer?13:34
Letothe2ndsmurray: your chance to become MC Scott!13:35
*** philipp <philipp!d948d099@> has joined #yocto13:37
philippHi guys, i have a question regarding the yocto builds TMPDIR. We have a project, that builds yocto using docker containers. Now when we mount the yocto TMPDIR via the docker daemon, it takes a long time because of the selinux relabeling of about 7 million files under the tmpdir. Is there a way to reduce the amount of files ?13:38
smurrayLetothe2nd: heh13:39
Letothe2ndphilipp: i think there is a way to get rid of selinux.....13:39
Letothe2ndsmurray: hi513:39
smurrayphilipp: one option would be trying rm_work, that cuts down quite a lot13:40
philippyes it is, but we are using openshift with a special storageclass13:40
philippthere is no switch to disable selinux13:40
*** robert_yang <robert_yang!~robert@> has quit IRC13:40
Letothe2ndphilipp: technically you can use rm_work, but that of course has other drawbacks.13:41
smurrayphilipp: https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-classes-rm-work13:41
Letothe2ndsmurray: hi5 again13:41
smurrayLetothe2nd: would have been faster, but google gives the 1.8 version of the docs pages at the top of results for some reason13:42
*** robert_yang <robert_yang!~robert@> has joined #yocto13:42
Letothe2ndyeah google loves 1.8, i know.13:42
Letothe2ndprobably they're building some internal stuff on it.13:42
philippthanks guys13:43
philippill suggest that to our devs13:43
Letothe2ndsuggest getting rid of selinux :)13:43
philippi know, but unfortunately, there is no way to tell openshift not to use selinux for mountpoints13:44
philippits hardcoded13:44
philippits actually hardcoded within the persistent volume driver by vmware13:44
Letothe2ndphilipp: on the other hand, you can use that as marketing material "super duper safe builds" or something along those lines :)13:45
philipp:D  +13:45
philippit takes docker so long to mount the volume, that the kubernetes api gets a timeout13:46
philippand while selinux relabeling, the whole docker-daemon api gets unresponive, which results in a kubernetes node loss13:46
philipp7 million files13:46
philippnot too much actually13:46
philippin todays dimensions13:47
Letothe2ndguess there's a reason why the most of us just use dedicated build hosts :)13:47
philippwe had that before, buts its some kind of consolidation project13:47
smurrayI've got the same issue here, crops up when a relabel gets triggered after a policy update on my build machine13:47
Letothe2ndwhoa even better! "super duper safe and synergy enabled builds!"13:48
smurraywhich isn't usually too frequent, but has happened a couple of times after going to F3213:48
Letothe2ndyou should consider yourself lucky, being blessed with such an infrastructure :)13:48
* Letothe2nd is having a weird day. who could've guessed.13:48
JPEWphilipp: I'm not too familiar with selinux + docker; why is it relabling?13:48
philippbasically when you use docker -v hostvolume:containervolume:Z , the :Z will trigger a restorecon -VR on the volume13:49
*** TobSnyder1 <TobSnyder1!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto13:49
philippto ensure selinux labels are matching13:49
philippeven if its already labeld correctly it takes 2-3 minutes13:49
philippbecause its looping over all files and directories recursively13:50
JPEWphilipp: Can you bind mount in the working directory instead of using a volume?13:50
philippsure we could, but we want to make use of vmware vsan dynamic volumes13:50
philippwhat basically happens is, that the kubernetes api will tell the vmware api to gives a new vmware volume, this vmware volume will be attached to the host and then mounted into the docker container13:51
wertigonHmm, yeah, moving the hwdb.bin to the lib folder actually worked o_O13:51
philippwhen resuing that volume for the next build / container, it will check the selinux labels13:51
wertigonI think atleast13:51
wertigon... No, nevermind, it did not. -_-;;13:52
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC13:52
philippi dont even know why the next builds needs the files from the previous build13:53
philippi guess to speed up things13:53
philippi know nothing about yocto^^13:53
Letothe2ndphilipp: erm no?13:53
Letothe2ndphilipp: the thing worth sharing is sstate-cache, not tmp13:53
philippah yeah13:54
philippssstate-cache is already on nfs13:54
philippand shared13:54
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto13:54
*** ant__ <ant__!~ant__@host-195-31-129-205.business.telecomitalia.it> has quit IRC13:54
philippah so we can start with a fresh tmpdir for every build?13:55
rburtonyes, you can13:55
philippand it wont be slower?13:55
rburtonif you have sstate-cache and dl_dir preserved between runs, it will just pull from sstate-cache what doesn't need to be rebuilt13:55
philippwhy am i spending hours to fix a problem, that doesnt even exist13:56
Letothe2ndphilipp: marginally, the pulling from sstate takes a little time too, but thats probably negelctable13:56
Letothe2ndphilipp: hum because super duper safe builds?!?13:56
JPEWphilipp: Ya, "sharing" TMPDIR across different builders isn't viable. It *can* make incremental builds a little faster than sstate if the builds are on the same host, but you'll go crazy if you try to use it across instance :)13:58
philippacross hosts is no problem13:59
philippbecause of the kubernetes dynamic volumes13:59
philippwhich will automatically be mounted on the correct docker host13:59
philippbut ill just tell them to use a new tmpdir volume for each build13:59
philippbecause everything that can possible be put on NFS, is already on NFS13:59
*** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-ostirxbgxbptvsam> has joined #yocto14:00
philippalright, thanks for clarifying things up for me14:00
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC14:02
*** robert_yang <robert_yang!~robert@> has quit IRC14:10
philippok our dev says: its neccessary to take the tmpdir into the next stage to minimize build steps14:10
*** robert_yang <robert_yang!~robert@> has joined #yocto14:10
Letothe2ndphilipp: why don't you just send your dev in here?14:11
philippno way14:12
Letothe2ndso let me recapitulate. "we're suffering because we decided upon this beautiful platform and are totally convinced that our process it the true only one way, so we're not even going to discuss that."14:13
Letothe2ndsounds like the perfect situation for improvement, i agree :)14:14
philippwell the platform is really beautiful for cloud-native container-ready applications14:14
qschulzhaven't followed the whole thing, but if the task hash is different between builds, copying the tmpdir won't change anything as it'll be cleaned anyway14:14
Letothe2ndphilipp: thats all nice and such, but in this case it causes a lot of self-inflicted pain obviously, and the "dev says, won't discuss" is like "why should we care" then, at least for me - and yes i know that sounds arrogant and probably elitist. sorry, at least a little.14:16
qschulzand if building with copied tmpdir is faster even with sstate-cache enabled, I suspect there is something very wrong going on which is bypassing the sstate-cache or not using it at all for some recipes? it smells either like stinky hacks or the dev does not know what Yocto's doing behind the scenes14:16
philippi dont know, ive told him that there is only one possible solution: do not reuse the tmpdir14:21
RPphilipp: I'm late to the conversation but we did design tmpdir to be able to be thrown away "cheaply"14:22
philippim not going to consult him about the consequences of this, because ive never worked with yocto before14:22
* Letothe2nd sighs and leaves for good.14:23
*** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has joined #yocto14:33
paulbarkerphilipp: Sounds like you're trying to use a sledge hammer to crack a nut.14:36
Letothe2ndpaulbarker: pointless violence FTW!14:36
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto14:36
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC14:39
*** robert_yang <robert_yang!~robert@> has quit IRC14:45
*** robert_yang <robert_yang!~robert@> has joined #yocto14:46
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto14:48
chris_berhello, i struggle with a cmake recipe. The recipe is local and i added the recipe myself along with the files. I used `devtool modify myrecipe` to edit the content but i am not able to build because cmake can't find the files although it is working when i call cmake itself: https://bitbin.it/lPf81fK0/14:53
*** frsc <frsc!~frsc@2003:a:e7a:6200:dcca:24d9:d4d5:17a> has quit IRC14:54
chris_beri am new to cmake and i got the feeling the way i added/created the recipe could be wrong14:54
dl9pfYPTM: Jan-Simon is on14:55
qschulzchris_ber: file://* does not work14:56
Letothe2ndchris_ber: i don't think SRC_URI does glob. its all just this: do not stuff your sources into the recipe.14:56
Letothe2ndchris_ber: make it a freestanding repository. (and yes, tahts jsut exactly what i showed you)14:56
*** nameclash <nameclash!~nameclash@ip1f11b23e.dynamic.kabel-deutschland.de> has quit IRC14:57
*** gtristan <gtristan!~tristanva@> has joined #yocto14:58
smurrayYPTM: Scott Murray is on14:58
qschulzchris_ber: using devtool with local files is also debatable. You already have the files so just use bitbake directly. I suspect you might have run devtool modify <recipe> early when your recipe was wrong and the files haven't been copied (correctly). Until you do devtool reset <recipe> the devtool'ed recipe will be used by bitbake14:58
qschulzbut as Letothe2nd said, it's strongly advised to use external repositories (such as git, or (versioned) tarballs)14:59
chris_berqschulz: it also tried file://prom/src/...15:01
Letothe2ndchris_ber: you're wasting your time on bad, hard to maintainable practises.15:01
qschulzchris_ber: you can't use * in SRC_URI in any way. So either you add them one by one, or you add one more directory below files which you include (WITHOUT USING *) or you use an external repository (and no, I'm not talking about externalsrc :) )15:02
chris_berLetothe2nd: i know, our problem is, that this approach will led to many many rerpositories because we are developing a framwork(packagegroup). I tried to use "devtool modify recipe" and it works fine with local files15:03
Letothe2ndchris_ber: then use a multirepo. but everything is better than bundling stuff into the layer.15:04
rburtonYPTM ross joined15:04
qschulzchris_ber: so you'd rather be bound to a buildsystem rather than handle multiple repos? e.g. if you later decide to move to another buildsystem such as Buildroot, then the whole history is messed up15:04
qschulzI mean, I am in no way in a good place to critic this as we're doing this (but I hate it)15:04
Letothe2ndchris_ber: what if, in some distant future, like... in two weeks, decides that using that "framework" without yocto would be cool? like, making a deb package?15:05
chris_berqschulz: :)15:05
Letothe2ndqschulz: great minds think alike!15:05
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has quit IRC15:05
qschulzchris_ber: "I tried to use "devtool modify recipe" and it works fine with local files" that is confusing to me, what do you mean by that?15:06
* Letothe2nd finally calls it a day!15:06
qschulzare you doing devtool modify and then cmake? you should use devtool build <recipe> :)15:06
qschulzLetothe2nd: o/15:06
chris_beri discussed with my colleagues about how to handle the framework and the recipes and they like to put in one repo because devtool can handle this with updates. Neverless a lot of books, blogs etc recomend(or at least use local files)15:07
qschulzso... 1) devtool reset <recipe> and remove the workspace, 2) use bitbake for building the recipe. Does not work? Send the log and the recipe :)15:07
*** wertigon <wertigon!~per@c-7968225c.021-396-7673741.bbcust.telenor.se> has quit IRC15:07
*** dexterlb <dexterlb!~dexterlb@qtrp.org> has joined #yocto15:08
chris_beri used devtool modify myr and then devtool build myr15:08
chris_beri know the procedure with reset etc15:08
qschulzchris_ber: the files are taken from the devtool workspace, so if you have changed your local files since your devtool modify, that won't update the ones in your workspace15:09
chris_berqschulz: i didn't modfy any file, because bitbake/devtool struggled with cmake15:10
qschulzchris_ber: if your workspace files and local files are in sync (please check) and it still does not work, then we'll need the error log15:10
*** philipp <philipp!d948d099@> has quit IRC15:10
chris_berok, give me a sec15:10
qschulzchris_ber: wild guess (common mistake) you probably aren't using the variables given by Yocto but using hardcoded ones in your cmake files15:11
chris_beri posted the complete CMakeFile.txt15:11
qschulzyou have others :) Anyway, true, if the error is really the one in the pastebin you sent us, the files haven't probably been installed correctly15:13
qschulzcould you go to the $WORKDIR of the recipe you're trying to build?15:13
qschulz(tmp/work/<arch>/<recipe_name>/<recipe_version> usually)15:13
qschulzand check that all your files are there?15:14
chris_berqschulz: i reseted the workspace, fixed the licence and run bitbake image again. The files are at the directory you mentioned. The noob-thing is, that it now complains about missing headers. I think you got right and i mixed something with the workspace up. I will know check the includes15:20
qschulzchris_ber: good, making progress :)15:22
chris_berin Germany we call this: Von einem Fettnäpfchen zum nächsten. Don't know the translation but i will find the next issue ;)15:23
qschulzchris_ber: gesundheit15:24
chris_berbut you recommended again we should use external repos. So multirepo is git thing?15:25
qschulzchris_ber: I haven't got much experience in dealing with that but anyway, you'll need a mechanism to git clone the meta layers that aren't yours (e.g. openembedded-core, poky, meta-openembedded, meta-qt5 whatever)15:26
*** leon-anavi <leon-anavi!~Leon@> has quit IRC15:27
fraygit-repo (an android related project) is used by a lot of people to manage multiple repositories15:27
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto15:28
qschulzchris_ber: I don't know exactly what Letothe2nd was talking about, maybe git submodules? he also presented kas recently on Twitch so maybe something to have a look at15:28
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC15:32
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto15:36
*** rob_w_ <rob_w_!~rob@ppp-93-104-37-8.dynamic.mnet-online.de> has joined #yocto15:37
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC15:40
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC15:43
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto15:44
*** rcw <rcw!~rcw@104-195-225-201.cpe.teksavvy.com> has joined #yocto15:49
*** tprrt <tprrt!~tprrt@> has quit IRC15:51
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC15:56
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC15:59
*** Frazer <Frazer!~frazer.cl@> has left #yocto16:11
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:11
*** vineela <vineela!~vtummala@> has joined #yocto16:15
*** robert_yang <robert_yang!~robert@> has quit IRC16:34
*** robert_yang <robert_yang!~robert@> has joined #yocto16:34
*** KindTwo <KindTwo!kindone@freenode/father-christmas/kindone> has joined #yocto16:35
*** KindOne <KindOne!kindone@freenode/father-christmas/kindone> has quit IRC16:37
*** KindTwo is now known as KindOne16:40
*** vineela <vineela!~vtummala@> has quit IRC16:40
*** kaspter <kaspter!~Instantbi@> has quit IRC16:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:42
*** vineela <vineela!~vtummala@> has joined #yocto16:44
*** filip <filip!~filip@78-80-26-170.nat.epc.tmcz.cz> has joined #yocto16:57
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC16:57
*** filip <filip!~filip@78-80-26-170.nat.epc.tmcz.cz> has quit IRC16:59
*** koty0f <koty0f!~filip@78-80-26-170.nat.epc.tmcz.cz> has joined #yocto17:00
*** koty0f <koty0f!~filip@78-80-26-170.nat.epc.tmcz.cz> has quit IRC17:02
edenis there a way i can pass a value from the external environment into yocto for use inside of a shell task *without* having that value recorded in any log/run files? it's a secret API token.17:03
*** koty0f <koty0f!~filip@78-80-26-170.nat.epc.tmcz.cz> has joined #yocto17:03
RPeden: write it in a file and have it loaded from the file in those scripts?17:06
*** vineela <vineela!~vtummala@> has quit IRC17:08
*** koty0f <koty0f!~filip@78-80-26-170.nat.epc.tmcz.cz> has quit IRC17:09
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:11
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto17:12
*** volpi <volpi!4e2b4835@HSI-KBW-078-043-072-053.hsi4.kabel-badenwuerttemberg.de> has joined #yocto17:12
*** mckoan is now known as mckoan|away17:19
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto17:25
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:27
*** nerdboy <nerdboy!~sarnold@> has joined #yocto17:43
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:43
edenRP: it's already in an env var. is there no way to avoid writing it out?17:57
edeni tried reading out of origenv and asked a question yesterday about it. doing so makes the task metadata hashes not consistent.17:57
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC18:00
*** nerdboy <nerdboy!~sarnold@> has joined #yocto18:01
*** nerdboy <nerdboy!~sarnold@> has quit IRC18:01
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto18:01
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto18:02
*** vineela <vineela!vtummala@nat/intel/x-dtbjwblucmaxciaw> has joined #yocto18:03
*** alejandrohs <alejandrohs!~alejandro@> has quit IRC18:13
*** alejandrohs <alejandrohs!~alejandro@> has joined #yocto18:14
*** koty0f <koty0f!~filip@nat-40.starnet.cz> has joined #yocto18:15
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto18:37
*** kaspter <kaspter!~Instantbi@> has quit IRC18:38
*** armpit <armpit!~armpit@2601:202:4180:a5c0:40c8:e68d:70bd:3b6> has quit IRC18:40
*** armpit <armpit!~armpit@2601:202:4180:a5c0:254a:4327:67e1:d5be> has joined #yocto18:42
*** kaspter <kaspter!~Instantbi@> has joined #yocto18:52
*** yacar_ <yacar_!~yacar_@91-168-169-253.subs.proxad.net> has quit IRC19:15
*** TobSnyder <TobSnyder!~schneider@p2e50e9c2.dip0.t-ipconnect.de> has joined #yocto19:24
*** ant__ <ant__!~ant__@host-82-60-190-241.retail.telecomitalia.it> has joined #yocto19:28
otavioRP: Is it possible for someone to push https://patches.openembedded.org/patch/172015/ ?19:32
otavioWe've been using it but hacking it byhand, which is not nice ;-)19:34
*** davidinux <davidinux!~davidinux@> has quit IRC19:46
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has quit IRC20:02
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC20:13
*** chandana731 <chandana731!~ckalluri@> has joined #yocto20:16
*** chandana73 <chandana73!~ckalluri@> has quit IRC20:16
*** koty0f <koty0f!~filip@nat-40.starnet.cz> has quit IRC20:21
*** sno <sno!~sno@p4fe931fc.dip0.t-ipconnect.de> has joined #yocto20:22
RPeden: well it would do unless you exclude it from the taskhash20:22
RPotavio: who is listed as the layer maintainer?20:22
otavioRP: Mark Hatle <mark.hatle@kernel.crashing.org> and Jason Wessel <jason.wessel@windriver.com>20:29
*** rob_w_ <rob_w_!~rob@ppp-93-104-37-8.dynamic.mnet-online.de> has quit IRC20:29
RPfray: can we marge the above patch please?20:30
RPor jwessel? :)20:30
*** pohly <pohly!~pohly@p5b05684a.dip0.t-ipconnect.de> has quit IRC20:35
*** carlsb3rg <carlsb3rg!5cdd8817@23.92-221-136.customer.lyse.net> has joined #yocto20:36
carlsb3rghi guys...I'm going through Josef Holzmayr's live series, and got to the part where I'm building a custom kernel20:40
carlsb3rgand "something" has caused core-image-minimal to grow a whole lot...gnome desktop and everything is getting compiled...20:41
*** mranosta1 <mranosta1!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto20:42
carlsb3rgany hints on how to figure out where something has obviously gone wrong?20:42
*** mranosta1 <mranosta1!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto20:42
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC20:44
carlsb3rgthe only really blatant copy/paste I have done is that I copied qemux86.conf instead of qeumarm.conf that @Letothe2nd used, and they are quite different, but I can't figure out which setting bloated my image20:50
carlsb3rgI used https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemux86.conf, where $Letothe2nd used https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemuarm.conf20:51
*** TobSnyder <TobSnyder!~schneider@p2e50e9c2.dip0.t-ipconnect.de> has quit IRC20:52
alejandrohscarlsb3rg: you can use bitbake -g to track down where the dependencies are coming20:58
*** chandana73 <chandana73!~ckalluri@> has joined #yocto21:01
*** chandana731 <chandana731!~ckalluri@> has quit IRC21:01
*** vineela1 <vineela1!~vtummala@> has joined #yocto21:02
*** vineela <vineela!vtummala@nat/intel/x-dtbjwblucmaxciaw> has quit IRC21:02
*** vineela <vineela!~vtummala@> has joined #yocto21:03
*** vineela1 <vineela1!~vtummala@> has quit IRC21:03
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC21:10
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:10
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto21:11
*** berton <berton!~berton@> has quit IRC21:12
carlsb3rgtrying to browse task-depends.dot...can't say I'm any wiser21:21
alejandrohscarlsb3rg: that should do it, if you say gnome is being built you can see where the dependency to build gnome is coming from21:22
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:22
carlsb3rgI can see that gnome-desktop-testing comes from meta/recipes-support...no idea why recipes-support is being cooked tho21:24
*** mranosta1 is now known as mranostay21:29
jwesselThat is a pretty reasonable patch.  I'll see if it can be merged.21:30
*** vineela1 <vineela1!~vtummala@> has joined #yocto21:36
*** vineela <vineela!~vtummala@> has quit IRC21:36
*** vineela <vineela!~vtummala@> has joined #yocto21:37
*** vineela1 <vineela1!~vtummala@> has quit IRC21:37
jwesselotavio The patch is merged.21:40
carlsb3rgfinally resolved some licence file issues etc and my wic is 46M...so it seems my actual image is respecting core-minimal-image constraints even though a lot more is getting build21:53
*** vineela <vineela!~vtummala@> has quit IRC21:58
*** robert_yang <robert_yang!~robert@> has quit IRC22:00
*** robert_yang <robert_yang!~robert@> has joined #yocto22:00
*** maudat <maudat!~moda@mtrlpq2848w-lp130-04-70-29-226-188.dsl.bell.ca> has quit IRC22:13
*** nerdboy <nerdboy!~sarnold@> has joined #yocto22:30
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto22:31
*** qschulz <qschulz!~quentin@ns326003.ip-37-187-106.eu> has quit IRC22:32
*** qschulz <qschulz!~quentin@ns326003.ip-37-187-106.eu> has joined #yocto22:35
*** carlsb3rg <carlsb3rg!5cdd8817@23.92-221-136.customer.lyse.net> has quit IRC22:39
*** jae1 <jae1!~jaewon@c-73-162-13-38.hsd1.ca.comcast.net> has joined #yocto22:40
*** creich <creich!~creich@p200300f6af28d810000000000000039b.dip0.t-ipconnect.de> has quit IRC22:43
*** creich <creich!~creich@p200300f6af28d810000000000000039b.dip0.t-ipconnect.de> has joined #yocto22:44
*** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has joined #yocto22:49
*** robert_yang <robert_yang!~robert@> has quit IRC22:51
*** robert_yang <robert_yang!~robert@> has joined #yocto22:51
*** ant__ <ant__!~ant__@host-82-60-190-241.retail.telecomitalia.it> has quit IRC22:51
*** agust <agust!~agust@p508b67ab.dip0.t-ipconnect.de> has quit IRC22:53
*** jae1 <jae1!~jaewon@c-73-162-13-38.hsd1.ca.comcast.net> has quit IRC22:53
*** Guest73739 <Guest73739!~Thunderbi@> has quit IRC22:58
*** robert_yang <robert_yang!~robert@> has quit IRC23:09
*** robert_yang <robert_yang!~robert@> has joined #yocto23:09
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC23:21
*** jrdn <jrdn!~jrdn@S010668ff7b6b7383.ok.shawcable.net> has quit IRC23:23
RPjwessel: thanks!23:35

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