Friday, 2020-11-06

*** NiksDev <NiksDev!~NiksDev@> has quit IRC00:04
*** kiwi_29 <kiwi_29!> has quit IRC00:09
*** Bunio_FH <Bunio_FH!> has quit IRC00:38
*** Bunio_FH <Bunio_FH!> has joined #yocto00:40
*** kiwi_29 <kiwi_29!> has joined #yocto00:46
*** ericch <ericch!> has quit IRC01:01
*** leon-anavi <leon-anavi!~Leon@> has quit IRC01:06
*** dStruct <dStruct!~matt@unaffiliated/dstruct> has quit IRC01:24
*** dStruct <dStruct!~matt@unaffiliated/dstruct> has joined #yocto01:26
*** mattia1 <mattia1!~mattia@> has quit IRC01:29
*** dmoseley <dmoseley!~dmoseley@> has left #yocto01:32
*** paulg <paulg!> has quit IRC01:36
*** paulg <paulg!> has joined #yocto01:49
*** kiwi_29 <kiwi_29!> has quit IRC01:57
*** ak77 <ak77!> has quit IRC02:07
*** lukma <lukma!> has quit IRC02:14
*** lukma <lukma!> has joined #yocto02:29
*** camus1 <camus1!~Instantbi@> has joined #yocto02:30
*** kaspter <kaspter!~Instantbi@> has quit IRC02:31
*** camus1 is now known as kaspter02:31
*** jadax9 <jadax9!> has joined #yocto02:34
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has joined #yocto02:34
*** jpnurmi_ <jpnurmi_!jpnurmi@qt/jpnurmi> has joined #yocto02:34
*** jpnurmi <jpnurmi!jpnurmi@qt/jpnurmi> has quit IRC02:34
*** dirbaio <dirbaio!> has quit IRC02:34
*** paulg <paulg!> has quit IRC02:35
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC02:35
*** seebs <seebs!~seebs@> has quit IRC02:35
*** jadax <jadax!> has quit IRC02:35
*** denix <denix!> has quit IRC02:35
*** jadax9 is now known as jadax02:35
*** paulg <paulg!> has joined #yocto02:35
*** denix <denix!> has joined #yocto02:36
*** seebs <seebs!~seebs@> has joined #yocto02:38
*** dirbaio <dirbaio!> has joined #yocto02:39
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC02:39
*** goliath <goliath!> has quit IRC02:45
*** bjobjo <bjobjo!~bjobjo@2a01:79c:cebf:d688::9e6> has quit IRC02:50
*** bjobjo <bjobjo!~bjobjo@2a01:79c:cebf:d688::9e6> has joined #yocto02:51
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC02:59
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto03:00
*** manuel1985 <manuel1985!> has quit IRC03:03
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto03:03
*** manuel1985 <manuel1985!> has joined #yocto03:17
*** ahadi <ahadi!> has quit IRC03:20
*** ahadi <ahadi!> has joined #yocto03:22
*** hpsy1 <hpsy1!~hpsy@> has joined #yocto03:26
*** sakoman <sakoman!> has quit IRC03:26
*** hpsy <hpsy!~hpsy@> has quit IRC03:26
*** onkelpit <onkelpit!~pit@> has quit IRC03:33
*** onkelpit <onkelpit!> has joined #yocto03:35
*** maudat <maudat!> has quit IRC03:38
*** kiwi_29 <kiwi_29!> has joined #yocto03:58
*** kiwi_29 <kiwi_29!> has quit IRC04:02
*** vineela <vineela!~vtummala@> has joined #yocto04:08
*** vineela <vineela!~vtummala@> has quit IRC04:09
*** wberrier <wberrier!> has joined #yocto04:16
wberrierquestion about state cache: does it get invalidated if I run: MACHINE=<something besides what's in local.conf> bitbake <recipes> ?04:17
wberrierI'm building the same set of recipes on two "MACHINE" types, but I'm noticing that the second "MACHINE" is running a ton of "do_fetch", "do_unpack", "do_populate_lic". (NOTE: before starting either of these bitbake invocations I have removed my "downloads" directory, but left the state cache in tact)04:19
wberriermaybe I need to use separate build dirs for each MACHINE type?  Or possibly separate state caches?04:31
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC04:35
*** hpsy1 <hpsy1!~hpsy@> has quit IRC04:37
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto04:41
*** armpit <armpit!~armpit@2601:202:4180:a5c0:30:8e77:15b6:d55c> has quit IRC04:48
*** manuel1985 <manuel1985!> has quit IRC04:59
*** hpsy <hpsy!~hpsy@> has joined #yocto05:00
*** lexano <lexano!~lexano@> has quit IRC05:09
*** manuel1985 <manuel1985!> has joined #yocto05:12
*** armpit <armpit!~armpit@2601:202:4180:a5c0:30:8e77:15b6:d55c> has joined #yocto05:22
wberriermeaning, I wouldn't have expected to have to redownload a bunch of stuff if I retained my state cache...05:26
*** kiwi_29 <kiwi_29!> has joined #yocto05:49
*** vineela <vineela!vtummala@nat/intel/x-xubpedajirbhkzul> has joined #yocto05:49
*** AndersD <AndersD!> has joined #yocto05:49
*** kiwi_29 <kiwi_29!> has quit IRC05:53
*** ThomasD13 <ThomasD13!> has joined #yocto05:54
*** jobroe <jobroe!> has joined #yocto05:58
*** jobroe_ <jobroe_!> has joined #yocto06:02
*** jobroe <jobroe!> has quit IRC06:02
*** B0ned1ger <B0ned1ger!> has joined #yocto06:02
*** jobroe_ <jobroe_!> has quit IRC06:06
*** jobroe <jobroe!> has joined #yocto06:06
*** jobroe <jobroe!> has quit IRC06:11
*** jobroe <jobroe!> has joined #yocto06:13
*** vineela <vineela!vtummala@nat/intel/x-xubpedajirbhkzul> has quit IRC06:15
*** AndersD <AndersD!> has quit IRC06:17
*** beneth` <beneth`!> has joined #yocto06:31
*** w00die <w00die!~w00die@> has quit IRC06:35
*** w00die <w00die!~w00die@> has joined #yocto06:37
khemwberrier:  sstate can be shared among machines you dont need to keep them separate06:39
*** pohly <pohly!> has joined #yocto06:45
*** AndersD <AndersD!> has joined #yocto06:53
ThomasD13Good morning, I've got some QA warnings during building an image. I'm not sure if they should concern me. TI (which provides the configuration) says I should not worry about this :/06:55
ThomasD13For example: external-arm-toolchain-2019.12: external-arm-toolchain: /sbin/ldconfig is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]06:55
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto07:09
*** kaspter <kaspter!~Instantbi@> has quit IRC07:19
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:19
*** pharaon2502 <pharaon2502!> has quit IRC07:26
*** pharaon2502 <pharaon2502!> has joined #yocto07:27
*** agust <agust!> has joined #yocto07:33
*** mattia_ <mattia_!~mattia@> has joined #yocto07:47
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:47
LetoThe2ndyo dudX07:48
*** mattia1 <mattia1!~mattia@> has joined #yocto07:49
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto07:51
*** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:bcb4:f6ca:17f3:4047> has joined #yocto07:52
DanmerZalejandrohs yes, I can SSH to localhost from inside qemu but can't from qemu to my computer and from computer to qemu07:53
LetoThe2ndDanmerZ: are you using slirp? is this a really run of the mill linux on your host?07:56
DanmerZLetoThe2nd runqemu qemux86-64 example-image nographic slirp07:58
LetoThe2ndDanmerZ: slirp is the problem.07:58
LetoThe2ndDanmerZ: remove it and use the tun/tap interface07:58
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:58
DanmerZLetoThe2nd great, thank you07:59
LetoThe2ndIIRC there was a patch that fixes the port forwarding with slirp on the ML lately, but can't find it at the moment08:00
*** emrius <emrius!> has joined #yocto08:02
*** emrius <emrius!> has quit IRC08:04
*** mckoan|away is now known as mckoan08:13
*** oberstet <oberstet!~oberstet@> has joined #yocto08:27
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:30
*** sno <sno!> has quit IRC08:39
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:41
*** dev1990 <dev1990!> has quit IRC08:44
*** dev1990 <dev1990!> has joined #yocto08:46
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto08:46
*** sno <sno!> has joined #yocto08:48
*** frsc <frsc!> has joined #yocto08:57
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto08:58
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC09:02
*** ak77 <ak77!> has joined #yocto09:07
*** fbre <fbre!91fdde45@> has joined #yocto09:17
*** frsc <frsc!> has quit IRC09:18
fbreHi! My yocto shows the message "Started telephony service" during bootup. I could systemctl mask that service to switch it off, but is it maybe a package I need to remove from the poky distro?09:19
fbreMy distro just includes conf/distro/poky.conf but I believe it does not add packages for telephony stuff09:20
LetoThe2ndfbre: distros don't have packages. images do.09:22
fbrehmm, OK, my built Image is core-image-minimal which I tweaked a bit by using my own machine and distro09:23
rburtonfbre: ofono, turn off the 3g distro feature09:23
LetoThe2ndrburton: does that trigger some expansion in a packagegroup?09:24
fbreis ofono part of core-image-minimal?09:25
*** florian_kc is now known as florian09:25
fbreIs it      DISTRO_FEATURES_remove = " 3g "      ?09:28
LetoThe2nd_remove is bad.09:28
fbreor     DISTRO_FEATURES_remove = " ofono "   ?09:28
LetoThe2nd see note by chris09:28
LetoThe2ndbetter just set the features directly as needed.09:29
fbre3G_REMOVE ?= ā€œ3gā€09:34
fbre3G_remove = ā€œ${3G_REMOVE}ā€09:34
fbreThis way?09:34
fbrecopied from Chris' note09:35
LetoThe2ndwhat the problem with just writing the DISTRO_FEATURES = "..." line in your distro just as you want it to be?09:36
*** amerlyq <amerlyq!~weechat@unaffiliated/amerlyq> has joined #yocto09:39
*** eduardas <eduardas!~eduardas@> has joined #yocto09:41
fbreSince my .conf file just includes conf/distro/poky.conf  and actually calls    DISTRO_FEATURES_append = " myadditionalstuff ". Isn't it better to run the strategy to extend/shrink a base system   than to rebuild it from scratch? It's a principle of tweaking than to reinvent.  Maybe that's a  philosophy question but I'm not an expert and try to09:41
fbreaovid changing a running system09:41
amerlyqCan somebody share his SSD wear levels after some period of regularly building Yocto? I have concerns of build time on HDD .vs. costs of SSD.09:42
amerlyqI searched and found somewhere opinion that SSD dies after 0.5..1 years of building yocto daily09:42
LetoThe2ndfbre: generally i'd agree, but for things like DISTRO_FEATURES i've found just "nailing it down" the way i want it to be is working better.09:44
LetoThe2ndamerlyq: well, "opinion"09:44
fbreLetoThe2nd: OK, I trust your experience. Thanx a lot (y)09:45
LetoThe2ndamerlyq: it depends on the ssd so much, as well as the actual count of builds. one image build per day? 24hrs constantly fully loaded? that makes a huge difference.09:45
*** wertigon <wertigon!> has joined #yocto09:46
fl0v0Hi, i have a question concerning the recipe-sysroots. I try to build a recipe with a python binding extension. When building it tries to link against ssl, which leads to the error: recipe-sysroot-native/usr/lib/ file not recognized: file format not recognized. Is "recipe-sysroot-native" the correct one? Or shouldnt it link against recipe-sysroot ?09:46
LetoThe2ndfbre: there's nothing bad with puling poky in, if it works for your use case. i would just always reset/overwrite DISTRO_FEATURES to a known state that matches my needs below the include.09:46
LetoThe2ndfl0v0: if the thing you want to build (the binding) shall go onto the target, then -native is wrong.09:47
wertigonHey, quick question about psplash - Is there interest in a patch that adds support to disable the progress bar as a runtime option? :)09:47
fl0v0LetoThe2nd: yeah it should go on the target. Thought so, thanks for confirming09:47
fl0v0LetoThe2nd: Now i have to find out why it does use the wrong one :/09:48
fbreLetoThe2nd: I wonder a bit why 3g is part of a base image. It feels like very special to me since most of the embedded world is without mobile phone stuff09:48
LetoThe2ndfbre: see, thats why i don't trust the default distro features. QED.09:48
LetoThe2ndfl0v0: almost certainly some part of the build script not using the environment properly but sticking to its call directory.09:49
*** kiwi_29 <kiwi_29!> has joined #yocto09:49
LetoThe2ndwertigon: define "interest". if you've got something, then send a rfc patch and see what happens. :)09:52
amerlyqLetoThe2nd: basically two cases 1) Jenkins with clean nightly build + 40 builds daily from sscache; 2) DevPC, only sscache, around 30 incremental rebuilds daily with full image packing. Is it too much for SSD? Is it not? The main concern is Yocto writing too many very small files -- each resulting in rewrite of 1MB block of SSD, which totals to astronomic write load.09:53
*** kiwi_29 <kiwi_29!> has quit IRC09:54
*** dmation <dmation!~dmation@> has joined #yocto09:54
LetoThe2ndamerlyq: i think it mostly boils down to the real amount of data being written. the dwpd rating should give you a good idea there. i can say that most devs here build on ssds, and i haven't heard cases of unexpected burn-outs there.09:56
*** kaspter <kaspter!~Instantbi@> has quit IRC09:57
wertigonLetoThe2nd: Well, our use case; if our payload app ever crashes, we want to show the psplash with an error message but no loading bar, I have a patch ready but unsure if I should try to upstream. :)09:57
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:57
LetoThe2ndamerlyq: plus, if you're on a real setup, i'd expect raid controller+cache to do away with most of the smallish block amplification anyways.09:57
LetoThe2ndwertigon: it sounds like a legit usecase. i see nothing wrong with showing a rfc patch and stating that in the explanation.09:58
wertigonLetoThe2nd: Ok, let me just pretty it up and send then09:59
amerlyqLetoThe2nd: how about general tip from ?09:59
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:4d03:42b0:64f4:e63c> has joined #yocto09:59
*** tnovotny <tnovotny!> has joined #yocto09:59
wertigonIt's pretty good already, just want to double check whitespace etc09:59
amerlyq> Put the build directory on its own disk. This is good practice in its own right since the build system has a tendency to wear disks heavily.09:59
amerlyqand "heavily" it's like ~4 months in 2014-2015...10:00
LetoThe2ndamerlyq: that page is about 8 years old, i would outright ignore it.10:01
LetoThe2ndwe will soon transition our jenkins setup to an all-ssd one, just for the sake of pure performance10:02
dmationHi, Hopefully this is an easy question. If I run a step after build history has been updated to produce a report what's the best way to do this?10:03
*** NKataDelGorm00 <NKataDelGorm00!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto10:05
LetoThe2nddmation: i would make a fancybuildhistory.bbclass, which inherits buildhistory and adds what you want. then use the fancy one.10:05
*** ThomasD13 <ThomasD13!> has quit IRC10:06
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC10:06
dmationLetoThe2nd, that seems like a nice, simple solution. Do you think something like buildhistory_commit_append() work in this case?10:10
LetoThe2nddmation: i don't know. try and find out.10:11
dmationWill do, thanks for the lead10:11
LetoThe2ndhave fun!10:13
*** B0ned1ger <B0ned1ger!> has quit IRC10:15
*** elvispre <elvispre!> has quit IRC10:22
LetoThe2ndrburton: yay for another pythonsci10:25
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto10:27
Dracos-Carazzahi, is there a way to create mixedcase group names with the useradd.bbclass? I have a piece of precompiled legacy software, which should be integrated an the usergroups are hardcoded in the binaries -.-10:28
Dracos-Carazzalike HiImAGroupName10:29
*** pharaon2502 <pharaon2502!> has quit IRC10:31
*** pharaon2502 <pharaon2502!> has joined #yocto10:32
*** B0ned1ger <B0ned1ger!> has joined #yocto10:33
DanmerZI am trying to extract SDK extended bitbake myimage -c populate_sdk_ext and it fails with "do_sdk_depends: The file /usr/lib/ is installed by both collectd-plugins and collectd, aborting"10:44
DanmerZIs it something wrong with the image itself?10:44
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto10:50
LetoThe2ndDanmerZ: myimage bilds fine?10:51
*** B0ned1ger <B0ned1ger!> has quit IRC10:51
LetoThe2ndthen i would start digging intt the recipes, sounds like one bundles the lib into the -dev package accidentially10:53
*** B0ned1ger <B0ned1ger!> has joined #yocto10:53
*** B0ned1ge_ <B0ned1ge_!> has quit IRC10:57
*** kaspter <kaspter!~Instantbi@> has quit IRC10:59
*** kaspter <kaspter!~Instantbi@> has joined #yocto11:00
*** fbre <fbre!91fdde45@> has quit IRC11:01
*** leon-anavi <leon-anavi!~Leon@> has quit IRC11:34
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto11:34
*** berton <berton!> has joined #yocto11:43
eduardashello, can anyone provide me with a definitive answer whether it is possible to boot an aarch64 Linux kernel using a 32-bit (ARMv7) compiled mainline u-boot?11:56
*** mihai-- <mihai--!~mihai@unaffiliated/mihai> has joined #yocto12:10
*** paulg <paulg!> has quit IRC12:13
*** paulg <paulg!> has joined #yocto12:13
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has quit IRC12:13
*** mattia1 <mattia1!~mattia@> has quit IRC12:22
*** jobroe <jobroe!> has quit IRC12:33
LetoThe2ndeduardas: somebody in #armlinux certainly can12:51
LetoThe2ndeduardas: all the cool kids are there, we're just the boring neckbeards that compile stuff12:52
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto13:01
*** NKataDelGorm00 <NKataDelGorm00!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC13:03
fl0v0LetoThe2nd: ouch, that hurt :D13:03
eduardasLetoThe2nd: I still kind of expect a lot of people here to be more involved... If you only do bitbake recipes for a living and don't really have to do u-boot/kernel development, I envy you :)13:04
LetoThe2ndeduardas: it just depends. but your question is really soemthing they know instantly there.13:05
eduardasLetoThe2nd: I asked it yesterday on both u-boot and armlinux... did not get a reply within about half a workday13:06
LetoThe2ndeduardas: seriously? surprising.13:06
eduardasdon't know how annoying I should get :D13:07
eduardasthere is a u-boot contributor I could nag, but I'm trying to be polite13:07
eduardasand not to abuse people's time too much13:08
amerlyqIsn't it faster to build and check it yourself in that case?13:08
eduardasamerlyq: I did not get it to work, but my case was vendoruboot + mainline13:08
eduardasamerlyq: I don't really have a system on hand that supports both mainline u-boot + mainline Linux13:09
*** goliath <goliath!> has joined #yocto13:13
amerlyqIf you already tried, your best bet to find ready recipe from someone, or debug this yourself the hard way. AFAIK it must work if your CPU can work in compat mode with older instruction set of ARMv7, and kernel must be able to migrate into upper RAM after being loaded by uboot, but it has so much things which may go wrong, that you basically have only two above choices. Go nag them, or shoot13:13
*** lexano <lexano!~lexano@> has joined #yocto13:14
amerlyqBut with vendoruboot even if you get working recipe, you 50/50 won't be able to succeed with it anyway. So... jtag till second coming?13:14
*** tnovotny <tnovotny!> has quit IRC13:33
*** kaspter <kaspter!~Instantbi@> has quit IRC13:34
*** tnovotny <tnovotny!> has joined #yocto13:48
*** mattia1 <mattia1!~mattia@> has joined #yocto13:53
*** maudat <maudat!~moda@> has joined #yocto13:59
*** hpsy <hpsy!~hpsy@> has quit IRC14:17
*** hpsy <hpsy!~hpsy@> has joined #yocto14:17
*** dmation <dmation!~dmation@> has quit IRC14:17
*** sakoman <sakoman!> has joined #yocto14:19
*** hpsy <hpsy!~hpsy@> has joined #yocto14:23
*** fl0v0 <fl0v0!~fvo@> has quit IRC14:34
*** hpsy <hpsy!~hpsy@> has quit IRC14:35
*** AndersD <AndersD!> has quit IRC14:47
*** hpsy <hpsy!~hpsy@> has joined #yocto14:51
*** marble_visions <marble_visions!~user@> has quit IRC14:54
*** marble_visions <marble_visions!~user@> has joined #yocto14:55
*** mckoan is now known as mckoan|away14:58
*** ericch <ericch!> has joined #yocto15:15
*** carlsb3rg <carlsb3rg!~chrissc@> has joined #yocto15:26
carlsb3rggood afternoon15:26
roussinmRP: I think the patch I sent on bitbake-devel, has a bug on it. I use in the base class, but it's not defined, would it be fine to move the `mc` inside the base class NoCache?15:28
RProussinm: possibly, I'd need to look at that code in more detail...15:33
*** ericch <ericch!> has quit IRC15:41
*** ericch <ericch!> has joined #yocto15:41
carlsb3rgI'm using mdev in my distro and modprobing a kernel module. does mdev have any effect on what modprobe does and what creates and removes /dev/my-device-[0-1] every time I run modprobe (-r)?15:46
*** xtron <xtron!~xtron@> has joined #yocto15:46
carlsb3rgI'm having a really hard time setting permissions on the device node so regular users can use the device too :(15:46
*** B0ned1ger <B0ned1ger!> has quit IRC15:53
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto15:53
*** hpsy <hpsy!~hpsy@> has quit IRC15:54
*** hpsy <hpsy!~hpsy@> has joined #yocto15:54
*** kpo_ <kpo_!> has quit IRC16:15
*** kpo_ <kpo_!> has joined #yocto16:15
*** carlsb3rg <carlsb3rg!~chrissc@> has quit IRC16:16
*** NiksDev <NiksDev!~NiksDev@> has quit IRC16:22
wberrierkhem: thanks, I'll try a few more configurations/iterations to try avoiding downloading stuff during the build (after have deleted the downloads dir)16:37
*** amerlyq <amerlyq!~weechat@unaffiliated/amerlyq> has quit IRC16:45
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:46
*** B0ned1ger <B0ned1ger!> has joined #yocto16:47
*** w00die <w00die!~w00die@> has quit IRC16:51
*** xtron <xtron!~xtron@> has quit IRC16:52
*** w00die <w00die!~w00die@> has joined #yocto16:53
*** xtron <xtron!~xtron@> has joined #yocto16:54
*** eduardas <eduardas!~eduardas@> has quit IRC16:58
*** tnovotny <tnovotny!> has quit IRC17:19
dev1990hi, when I'm using ${IMAGE_ROOTFS} inside image.wks should I rename it to
dev1990is it *.in extension to expand variables inside wks ?17:22
dev1990I can't find any documentation on this topic17:24
kergothdev1990: yes, that's correct17:26
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:4d03:42b0:64f4:e63c> has quit IRC17:27
*** yann <yann!~yann@> has quit IRC17:28
dev1990ok thanks17:29
*** xtron <xtron!~xtron@> has quit IRC17:29
*** xtron1 <xtron1!~xtron@> has joined #yocto17:32
*** vineela <vineela!vtummala@nat/intel/x-rrqchjaryrwgiwka> has joined #yocto17:34
*** yann <yann!~yann@> has joined #yocto17:42
*** mihai-- is now known as mihai17:56
*** xtron1 <xtron1!~xtron@> has quit IRC18:00
*** mattsm <mattsm!> has quit IRC18:04
*** kiwi_29 <kiwi_29!> has joined #yocto18:05
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:08
*** mattsm <mattsm!> has joined #yocto18:16
*** kiwi_29 <kiwi_29!> has quit IRC18:18
*** mattsm <mattsm!> has quit IRC18:28
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto18:29
*** B0ned1ger <B0ned1ger!> has quit IRC18:32
*** mattsm <mattsm!> has joined #yocto18:33
*** B0ned1ge_ <B0ned1ge_!> has quit IRC18:35
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:49
*** wertigon <wertigon!> has quit IRC18:58
*** B0ned1ger <B0ned1ger!> has joined #yocto19:05
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC19:10
*** B0ned1ger <B0ned1ger!> has quit IRC19:10
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:38
*** laurittr <laurittr!> has joined #yocto19:39
*** kiwi_29 <kiwi_29!> has joined #yocto19:44
*** B0ned1ger <B0ned1ger!> has joined #yocto20:04
*** wberrier <wberrier!> has quit IRC20:06
*** B0ned1ger <B0ned1ger!> has quit IRC20:08
*** kiwi_29 <kiwi_29!> has quit IRC20:09
*** pharaon2502 <pharaon2502!> has quit IRC20:18
*** oberstet <oberstet!~oberstet@> has quit IRC20:22
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC20:25
*** kiwi_29 <kiwi_29!> has joined #yocto20:31
*** berton <berton!> has quit IRC20:38
*** kiwi_29 <kiwi_29!> has quit IRC20:41
*** kpo_ <kpo_!> has quit IRC20:42
*** kiwi_29 <kiwi_29!> has joined #yocto20:42
*** kpo_ <kpo_!> has joined #yocto20:43
*** kiwi_29 <kiwi_29!> has quit IRC20:46
*** kiwi_29 <kiwi_29!> has joined #yocto21:05
JaMazeddii: around? cloud-init you just imported fails with installed-vs-shipped QA21:13
zeddiireally ? works fine here. which arch ? I built for arm* and x86*21:14
JaMaI guess every arch in builds with systemd21:14
zeddiiI actually tested in on target, with systemd21:14
JaMathis was rpi4 world build21:15
zeddiiI have the same log from qemuarm64. I'll see if I can make it happen here, maybe my local distro is masking something.21:16
*** pohly <pohly!> has quit IRC21:22
*** B0ned1ger <B0ned1ger!> has joined #yocto21:28
JaMaFILES_cloud-init-systemd=" /usr/lib/systemd/*"21:28
JaMaexport nonarch_base_libdir="/usr/lib"21:29
JaMa#     "${nonarch_base_libdir}/systemd"21:29
JaMamaybe you're using something like usrmerge?21:30
zeddiionly if it's on in poky, I have an integration distro that just inherits that and builds, no significant tweaks.21:33
zeddiiI'll come up with a fix though, that should be using variables, the original cloud-init was super old.21:34
JaMaok, thanks21:37
*** wberrier <wberrier!> has joined #yocto21:44
*** B0ned1ger <B0ned1ger!> has quit IRC21:47
*** wberrier <wberrier!> has quit IRC21:47
*** wberrier <wberrier!> has joined #yocto21:49
*** yacar_ <yacar_!~yacar_@2a01:e0a:22a:7f40:bcb4:f6ca:17f3:4047> has quit IRC22:11
*** kiwi_29 <kiwi_29!> has quit IRC22:15
*** B0ned1ger <B0ned1ger!> has joined #yocto22:22
*** kiwi_29 <kiwi_29!> has joined #yocto22:23
*** B0ned1ger <B0ned1ger!> has quit IRC22:27
*** kiwi_29 <kiwi_29!> has quit IRC22:28
*** DanmerZ <DanmerZ!~op@> has quit IRC22:29
*** kiwi_29 <kiwi_29!> has joined #yocto22:29
*** kiwi_29 <kiwi_29!> has quit IRC22:51
wberrierkhem: thanks for the help.  Turns out I just needed separate DEPLOY_DIR for each MACHINE.  Then it doesn't re-download all the source.22:58
khemwberrier: hmm it should not need anything actually22:59
khemRP:  something is broken in master-next/bitbake I am getting do_populate_lic failures in random recipes but master works ok22:59
*** vineela <vineela!vtummala@nat/intel/x-rrqchjaryrwgiwka> has quit IRC23:00
*** kiwi_29 <kiwi_29!> has joined #yocto23:16
*** agust <agust!> has quit IRC23:17
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/> has quit IRC23:55

Generated by 2.17.2 by Marius Gedminas - find it at!