**** BEGIN LOGGING AT Mon Feb 24 02:59:57 2020
Feb 24 03:06:53 <yocti> New news from stackoverflow: YOCTO:Where does Beaglebone black firmware directory located at core image sato build? <https://stackoverflow.com/questions/60144209/yoctowhere-does-beaglebone-black-firmware-directory-located-at-core-image-sato>
Feb 24 06:44:23 <bernardoaraujo> I'm doing some experiments with a ROCK64, using the meta-rock64 BSP. I have a Poky core-image-base running.
Feb 24 06:44:44 <bernardoaraujo> Problem is that after boot, eth0 is never up by default. I need to run "ifup eth0" to bring it up. If ethernet cable is disconnected when I bring it up, it will not start a DHCP transaction after I plug it in. I only get a local IP if I bring it up WHILE the ethernet cable is connected.
Feb 24 06:44:47 <bernardoaraujo> I would appreciate any tips on how to get eth0 up on boot.
Feb 24 08:17:43 <LetoThe2nd> bernardoaraujo: add/enable whatever network manager you like. popular choices these days are ifupdown, nm, systemd-networkd, connman.
Feb 24 08:21:10 <bernardoaraujo> hi Josef! I checked the manifest, "init-ifupdown aarch64 1.0-r7" is there
Feb 24 08:23:07 <LetoThe2nd> bernardoaraujo: then do your configuration in etc/network/interfaces
Feb 24 08:27:43 <bernardoaraujo> this is the wired section of it, without doing any customizations
Feb 24 08:27:49 <bernardoaraujo> https://www.irccloud.com/pastebin/Z9Gtt6Yw/
Feb 24 08:29:07 <LetoThe2nd> well i'm no ifupdown user, hence i can only guess. but "technically" this looks correct, given the assumption that ifupdown is started
Feb 24 08:32:50 <bernardoaraujo> I just went mobile, but when I get home I'll double check whether ifupdown is starting as a service at boot... good point, thanks!
Feb 24 08:33:43 <LetoThe2nd> have fun.
Feb 24 08:49:03 <angelo__> hi , what is exactly yocto read-only rootfs doing ?
Feb 24 08:49:29 <LetoThe2nd> angelo__: it makes the rootfs read-only.
Feb 24 08:49:32 <LetoThe2nd> :)
Feb 24 08:52:07 <angelo__> LetoThe2nd, mm, i can mount it rw
Feb 24 08:52:14 <kanavin_home> the idea is basically security: if rogue agents can't write there, their ability to do damage is limited
Feb 24 08:52:40 <LetoThe2nd> angelo__: well of course, by manual intervention you can do almost anything
Feb 24 08:53:02 <angelo__> LetoThe2nd, so it is thought to be used as RO
Feb 24 08:53:10 <LetoThe2nd> angelo__: but it comes up as RO, and the build process incorporates some tweaks needed to do that.
Feb 24 08:53:45 <angelo__> ok, so mainly tweaks related to system settings that should be not persistent or things like that ?
Feb 24 08:54:08 <LetoThe2nd> angelo__: for example ssh key generation.
Feb 24 08:54:37 <LetoThe2nd> angelo__: the first and foremost tweak of course being "ro" in the fstab instead of "rw" :P
Feb 24 08:58:13 <angelo__> mm no clear fstab thing ... isn't mount mode defined by the kernel params ?
Feb 24 08:58:49 <LetoThe2nd> angelo__: its more like fstab defines it and kernel overrides. embedded is a bit special there.
Feb 24 09:02:55 <angelo__> LetoThe2nd, ok
Feb 24 09:02:58 <angelo__> thanksù
Feb 24 09:07:54 <yocti> New news from stackoverflow: Where are bitbake python functions documented <https://stackoverflow.com/questions/24769944/where-are-bitbake-python-functions-documented>
Feb 24 09:17:17 <ernstp> howdy, trying to learn more about WIC, WKS, bmap etc, haven't looked at it before
Feb 24 09:18:14 <ernstp> feels like I'm missing something. with meta-freescale and imx7dsabresd I get a wic.gz and wic.bmap...  what do I do with those?
Feb 24 09:19:24 <LetoThe2nd> ernstp: you should be able to just zcat the wic.gz to sd-card, or whatever medium you use.
Feb 24 09:19:54 <LetoThe2nd> ernstp: bmap is (AFAIK) a config file for some flasher tool, ask google about it.
Feb 24 09:20:18 <ernstp> doh, I was stuck on 3.16. Creating Partitioned Images Using Wic in the manual, didn't see 3.17. Flashing Images Using bmaptool :-)
Feb 24 09:20:44 <LetoThe2nd> hrhr
Feb 24 09:20:48 <ernstp> LetoThe2nd: I think you're supposed to use bmap-tool in there...
Feb 24 09:21:11 <ernstp> I'm guessing that it does a little bit more than just dd/zcat
Feb 24 09:21:38 <LetoThe2nd> ernstp: i have no idea, never used it. my targets are "different" (TM)
Feb 24 09:22:09 <ernstp> LetoThe2nd: yeah same here, but working with the Sabre reference board now a bit
Feb 24 09:23:17 <paulbarker> bmap-tools is excellent, the bmap file says which blocks in the image contain actual data and only those are copied to the target device
Feb 24 09:30:10 <Chrusel> bmaptool is really excellent and worth to look at it! Using the tool may speed up the flashing time significantly.
Feb 24 09:45:44 <perdmann> I want to use ubifs for the kernel image, but when i create the image in Linux i cannot mount it in uboot. i always get ECC Errors (-74) . Is there a solution to this?
Feb 24 09:45:56 <perdmann> It looks like uboot uses another ECC then kernel...
Feb 24 09:46:55 <LetoThe2nd> perdmann: if you're using raw nand and setting up ecc manually (as opposed to emmc, for example), well then, this is certainly possible.
Feb 24 09:47:02 <LetoThe2nd> solution: look at the ecc setups :)
Feb 24 09:48:36 <[Sno]> JaMa: I checked http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205012.html Friday evening - all 4 build fine
Feb 24 09:52:23 <perdmann> LetoThe2nd i want to use ubifs to get management for bad blocks etc.pp.  Its not an emmc, its a raw NAND
Feb 24 09:52:55 <LetoThe2nd> perdmann: then you also want to look at both your uboot and kernel config to make sure things match
Feb 24 09:54:36 <perdmann> Where do i need to search for that? I already compared the MTD and UBI configs, they looked okay
Feb 24 09:55:08 <LetoThe2nd> board setup routing might eb a good start
Feb 24 09:56:27 <perdmann> routing? Or did you mean routine in uboot?
Feb 24 09:56:55 <LetoThe2nd> i meant routine, sorry for typo
Feb 24 09:57:18 <perdmann> No problem. I just wanted to ensure that i understand you correctly :D
Feb 24 10:04:25 <perdmann> maybe i should add that: as far as i understood our Processor, in Linux we use a hardware ECC …
Feb 24 10:05:31 <LetoThe2nd> perdmann: then you should myke sure that uboot also sets up and uses that hw ecc.
Feb 24 10:09:26 <perdmann> LetoThe2nd actually i totally did not remember this fact -.-
Feb 24 10:09:56 <LetoThe2nd> :)
Feb 24 10:16:16 <siva> i am getting the below error for my recipe
Feb 24 10:16:36 <siva> do_package_qa: QA Issue: No GNU_HASH in the elf binary
Feb 24 10:18:13 <LetoThe2nd> siva: does https://forums.xilinx.com/t5/Embedded-Linux/No-GNU-HASH/td-p/832423 apply to your case?
Feb 24 10:24:27 <siva> thanks
Feb 24 10:24:35 <siva> it fixed the issue
Feb 24 10:25:08 <LetoThe2nd> siva: where can send my invoice? i take 5€ per google.
Feb 24 10:30:15 <ChrisStuart> Hi, I'm trying to build an image with GCC installed on it and can't quite work out why I'm not getting that! Working on thud, I have packagegroup-core-buildessential in my IMAGE_INSTALL list, is that not the right way to do it?
Feb 24 10:31:09 <LetoThe2nd> ChrisStuart: it probably should do, but adding "tools-sdk" to IMAGE_FEATURES (as indicated in the template local.conf) should be easier
Feb 24 10:32:42 <ChrisStuart> @LetoThe2nd I will give that a go, thank you. Thought I'd popped that in before!
Feb 24 10:49:31 <mcfrisk> how to re-use machine config snippets from other layers? requires directive doesn't work. Should I copy all config files from generic BSP layer to device specific one?
Feb 24 10:54:36 <LetoThe2nd> mcfrisk: require doesn't work, why?
Feb 24 10:55:35 <mcfrisk> LetoThe2nd: requires works for the first level dependency. Then the SoC specific bits need more config files which are not found from the search path. It snow balls into complex setup..
Feb 24 10:55:49 <LetoThe2nd> mcfrisk: hmmm
Feb 24 10:57:04 <LetoThe2nd> mcfrisk: from my understanding the require-nesting should support an arbitrary depth. if it doesn't, then i'm not sure if that is by intent or by bug
Feb 24 10:58:24 <mcfrisk> from meta-ti the machine configs find poky/meta/conf/machine/include/soc-family.inc correctly. From my custom layer the machine config can't find the meta-ti .inc files which I'd like to re-use. Maybe I'm missing some machine search path magic across layers..
Feb 24 10:59:06 <LetoThe2nd> mcfrisk: i'd guess that there is just a relative path in there somewhere, as opposed to requiring the full inside-layer path
Feb 24 11:02:07 <mcfrisk> LetoThe2nd: between meta-ti and poky the relative paths work for soc-family.inc but I can't get the same working from custom BSP layer to meta-ti. must be missing something really trivial..
Feb 24 11:03:45 <LetoThe2nd> mcfrisk: maybe but i can't put my finger onto it too, sorry.
Feb 24 11:08:21 <yocti> New news from stackoverflow: Dpkg-reconfigure keyboard-configuration equivalent in opkg <https://stackoverflow.com/questions/60374051/dpkg-reconfigure-keyboard-configuration-equivalent-in-opkg>
Feb 24 11:08:26 <mcfrisk> LetoThe2nd: found it, typo elsewhere in include files...
Feb 24 11:08:34 <LetoThe2nd> mcfrisk: \o/
Feb 24 11:38:27 <yocti> New news from stackoverflow: How to create recipe (Yocto build environment) for Nodejs modules <https://stackoverflow.com/questions/60374760/how-to-create-recipe-yocto-build-environment-for-nodejs-modules>
Feb 24 11:38:34 <RP> mcfrisk: was going to say, that should work
Feb 24 11:39:47 * LetoThe2nd hi5es RP
Feb 24 12:12:42 <siva> i am getting the below error for my linux-imx_%.bbappend changes
Feb 24 12:13:55 <siva> sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-kernel/linux/linux-imx_4.14.98.bb:do_compile) failed with exit code '1'
Feb 24 12:14:10 <siva> make[2]: arm-poky-linux-gnueabi-gcc: Command not foun
Feb 24 12:15:00 <siva> i have commented out all the SRC_URI
Feb 24 12:15:21 <LetoThe2nd> siva: put your append on a pastebin, please.
Feb 24 12:17:46 <gaston53> hello
Feb 24 12:17:53 <gaston53> Does anyone help me here ?
Feb 24 12:18:08 <gaston53> I have errors related to SDK
Feb 24 12:18:10 <gaston53> https://pastebin.com/EXWSfQyC
Feb 24 12:19:57 <siva> https://pastebin.com/GLbLwiQW
Feb 24 12:20:21 <siva> i have added a new machine type imx6uloib
Feb 24 12:22:37 <LetoThe2nd> siva: that looks kind of weird. not really like a machine bbappend, or only partically.
Feb 24 12:23:13 <LetoThe2nd> siva: i mean, why are you setting EXTRA_OEMAKE for all kinds of stuff?
Feb 24 12:24:05 <LetoThe2nd> siva: so again, my advice from last week repeated: comment out stuff until the breakage goes away.
Feb 24 12:25:38 <[Sno]> RP: preview of make compiling with mingw is available at github.com:rehsack/poky.git
Feb 24 12:25:42 <siva> this error goes away only if i change the name of linux-imx_%.bbappend to linux-fslc_%.bbapend
Feb 24 12:25:59 <LetoThe2nd> siva: i explained already last week why that is.
Feb 24 12:26:11 <[Sno]> RP: final will come when I submitted the patches upstream and add remarks :)
Feb 24 12:26:47 <siva> https://pastebin.com/GhVWCteP
Feb 24 12:26:53 <siva> pls check this one
Feb 24 12:27:34 <LetoThe2nd> siva: and?
Feb 24 12:28:42 <siva> basically this bbappend was working with jethro version. when i tried to migrate to SUMO, i am getting this build erros
Feb 24 12:30:08 <LetoThe2nd> siva: in that case i would guess that something in your patches is buggy. that it is hard-setting things. like arm-poky-linux-gnueabi somewhere, which is not true anymore.
Feb 24 12:32:12 <siva> ok, i have compared my machine.conf with imx6ulevk.conf. but couldn't find any thing obvious
Feb 24 12:33:54 <LetoThe2nd> thats not what i meant
Feb 24 12:34:34 <LetoThe2nd> look at your defconfig, does it set CROSS_COMPILE?
Feb 24 12:38:48 <gaston53> hello, does anyone read my post
Feb 24 12:39:26 <LetoThe2nd> gaston53: yes.
Feb 24 12:39:52 <gaston53> LetoThe2nd https://pastebin.com/EXWSfQyC
Feb 24 12:40:04 <gaston53> I am missing some thing in my SDK
Feb 24 12:40:15 <LetoThe2nd> gaston53: i have read it, no more and no less. that what you asked.
Feb 24 12:42:51 <gaston53> what is this  " real-ld "
Feb 24 12:42:54 <gaston53> ?
Feb 24 12:43:09 <gaston53> and how can I install what is missing ?
Feb 24 12:43:18 <LetoThe2nd> probably the real, actual linker binary.
Feb 24 12:43:42 <gaston53> he is saying that there are some missing files inside it
Feb 24 12:43:49 <gaston53> but it is not a directory
Feb 24 12:43:54 <gaston53> I can't access to it
Feb 24 12:44:00 <gaston53> to see what is there
Feb 24 12:44:55 <gaston53> bash: cd: /opt/poky-atmel/2.5.3/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/7.3.0/real-ld: Not a directory
Feb 24 12:47:49 <gaston53> LetoThe2nd do you have an idea about it ?
Feb 24 12:48:02 <LetoThe2nd> gaston53: none right in the first 5 seconds.
Feb 24 12:48:33 <gaston53> LetoThe2nd hmmm
Feb 24 12:56:03 <erbo> gaston53: real-ld is not a directory, is a binary. That binary is saying it can't find those files.
Feb 24 12:58:40 <RP> [Sno]: cool, thanks
Feb 24 12:58:40 <gaston53> erbo ah okey, so my problem is, that files are non installed, or the path is unclear for it
Feb 24 12:58:57 <gaston53> erbo How can I install those files in my SDK ?
Feb 24 12:59:09 <erbo> the problem is that your VS setup doesn't work well with the yocto cmake toolchain config
Feb 24 12:59:17 <erbo> It's not a Yocto problem, it's a VS problem
Feb 24 12:59:51 <erbo> I've tried to help you out it the SO question, but don't really have any more idea
Feb 24 13:00:40 <erbo> People here will not be able to provide the answers either, since they have so little information. The SO question at least have details on what you're trying to do.
Feb 24 13:00:40 <gaston53> erbo i see .. thank you anyway
Feb 24 13:01:51 <gaston53> erbo =(
Feb 24 13:03:38 <erbo> Here's a link to the SO question, if anyone wants to read to get more context: https://stackoverflow.com/questions/60336326/cmake-project-using-external-sdk-toolchain-file-cross-compile-error
Feb 24 13:04:15 <erbo> I'm assuming that's your thread gaston53, seemed to close to be a coincident :)
Feb 24 13:04:38 <gaston53> erbo haha it's me ;)
Feb 24 13:04:43 <gaston53> :(
Feb 24 13:05:17 <gaston53> the pseudo is an old one " Gonn "
Feb 24 13:11:57 <erbo> gaston53: did you watch the video on VS and Yocto SDK I mentioned last week?
Feb 24 14:35:21 <kriive> Hi guysss, what would be a good way to initialize a database? Using a self-deleting systemd oneshot service?
Feb 24 14:35:41 <kriive> I mean Initialize a mysql/mariadb schema
Feb 24 14:35:57 <kriive> Or are there better Yocto best practices?
Feb 24 14:36:16 <LetoThe2nd> kriive: why can't you just deploy a readily initialized db?
Feb 24 14:36:28 <kriive> Ugh, can I do that?
Feb 24 14:36:38 <LetoThe2nd> why not?
Feb 24 14:36:49 <LetoThe2nd> i mean, its just some files in the end, or not?
Feb 24 14:38:24 <LetoThe2nd> of course it depends a bit on your memory layout etc... but it certainly worth considering.
Feb 24 14:39:12 <kriive> Yes, it's surely worth considering, I am now wondering if I can do that and have a random password at first boot
Feb 24 14:40:00 <kriive> Gonna dig in mariadb docs brb
Feb 24 15:24:14 <rburton> having a recipe that builds the database and just ships the file seems like a sensible idea
Feb 24 15:24:20 <rburton> assuming that binary format is portable
Feb 24 15:24:39 <rburton> if its not then either run it in a qemu or do it on first boot
Feb 24 15:25:47 <LetoThe2nd> rburton: it for sure depends a bit, but thats an option.
Feb 24 15:26:38 <LetoThe2nd> i personally rather favor having the db creation bundled with the application that actually needs it in the end, but YMMV
Feb 24 15:26:49 <LetoThe2nd> also, remember migration strategies etc.
Feb 24 15:33:57 <rburton> right bundling the database creation with the app makes absolute sense if there's just one recipe that touches it
Feb 24 15:34:14 <rburton> reason not to do that is if you want to do package upgrades
Feb 24 15:34:21 <rburton> don't want to delete the database when you upgrade
Feb 24 15:34:36 <rburton> so a postinst 'if database doesn't exist, create' makes sense
Feb 24 15:34:43 <rburton> but again, at rootfs time if possible
Feb 24 15:56:26 <milloni> i'm going to have some time to look into https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305
Feb 24 15:56:28 <yocti> Bug 5305: enhancement, Medium, Future, bruce.ashfield, IN PROGRESS IMPLEMENTATION , Make sanitized kernel headers available
Feb 24 15:57:05 <milloni> is the approach outlined in the bbclass posted by Peter Kjellerstedt still good?
Feb 24 15:57:34 <milloni> that is, do we want to add a class that puts the headers in the ${WORKDIR} for each recipe that wants to use them
Feb 24 15:58:00 <milloni> or do we want to stick them into the staging sysroot in /kernel-includes or similar?
Feb 24 15:58:20 <LetoThe2nd> rburton: if. in my standard case for example the db storage is not available at rootfs time, and i have one middleware app thats reponsible. hence, this one ships the creation and migration schemes.
Feb 24 16:07:21 <zeddii> milloni: there’s already something in progress for that, I need to udpate that bug.
Feb 24 16:07:40 <zeddii> jsut install them to usr-alt and be done with it is the answer
Feb 24 16:08:19 <zeddii> nothing can really go into the shared workspace, it’s just a set of nasty bugs waiting to happen, and the sizes are small, so they jsut need to be per-recipe in their sysroots
Feb 24 16:08:53 <zeddii> I’ll put some updates in it shortly, I’ve just been distracted with wrestling 5.4 into master.
Feb 24 16:09:25 * LetoThe2nd notes: "zeddii has been distracted with wresting."
Feb 24 16:09:36 <zeddii> WWE!
Feb 24 16:09:58 <LetoThe2nd> \m/
Feb 24 16:11:23 <zeddii> in fact, I need to go through and bodyslam all of my bugs, they are almost all out of date
Feb 24 16:11:29 <zeddii> s/bodyslam/update/
Feb 24 16:12:01 * LetoThe2nd hands zeddii a cheap foldable plastic chair.
Feb 24 16:12:15 <zeddii> now you are talking!
Feb 24 16:13:06 <LetoThe2nd> want a cheap yellow shirt, too?
Feb 24 16:13:29 <zeddii> yah. plus arm and head bands.
Feb 24 16:13:36 <LetoThe2nd> awesome!
Feb 24 16:14:01 * LetoThe2nd now imagines showing up like that at OEDEM.
Feb 24 16:14:26 * zeddii makes a mental note to work that into dublin
Feb 24 16:15:05 <LetoThe2nd> go go go!
Feb 24 16:15:46 <LetoThe2nd> your presentation shall be named: "zeddii knows best!"
Feb 24 16:18:17 <RP> JPEW: we have another of the corrupt hashequiv issues rearing its head again
Feb 24 16:18:29 <smurray> zeddii: having fought with kernel fragment issues across various BSPs while taking AGL to zeus, I'm wondering if getting fragment support hoisted into kernel.bbclass is moving any closer to feasible?
Feb 24 16:20:47 <derRichard> hey
Feb 24 16:21:39 <derRichard> what happened to git.freescale.com?
Feb 24 16:22:13 <milloni> zeddii: OK
Feb 24 16:23:01 <milloni> zeddii: one more question then, is /usr+alt already packaged in a package?
Feb 24 16:23:10 <milloni> if not, what package should it go to
Feb 24 16:23:25 <zeddii> it doesn’t really need to be packaged at all. to be honest.
Feb 24 16:23:48 <milloni> wont the QA checks complain about files not being packaged?
Feb 24 16:23:57 <zeddii> just a class that you inherit that installs the headers into your sysroot, since fundamentally it is something that can conflict very easily.
Feb 24 16:24:07 <zeddii> I said installed into sysroot, not deployed.
Feb 24 16:24:56 <zeddii> smurray: i have a patch that does just that, it just won’t make this release. I can point you to it, I just have to make sure it still works with the latest juggling we did.
Feb 24 16:26:48 <smurray> zeddii: no, that's fine, AGL won't want to carry a custom kernel.bbclass, just hoping it gets in at some point so I can remove/simplify various merge-config.sh hacks
Feb 24 16:27:19 <milloni> zeddii: when i did it for my build, i did it like this: oe_runmake INSTALL_HDR_PATH=${D}${HEADERS_PATH} headers_install
Feb 24 16:27:30 <milloni> what's the right path to install them? (i assume ${D} isn't)
Feb 24 17:14:05 <rcrudo> I've avahi-daemon installed in my image but I'm not installing it explicitly. Is there a way to find out which recipe is installing it?
Feb 24 17:15:36 <armpit> zeddii, I am seeing a 5.2.29 build failure on yocto-tiny on zeus. https://errors.yoctoproject.org/Errors/Details/392434/
Feb 24 17:16:10 <armpit> I see 5.2 has been updated but no patches on list
Feb 24 17:17:49 <rburton> rcrudo: easy way is to remove it with rpm or whatever on the target and see what complains
Feb 24 17:19:02 <armpit> also on yocto-linux
Feb 24 17:24:27 <JPEW> RP: Oh? Whats the symptom?
Feb 24 17:37:37 <RP> JPEW: consider https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/955 , http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6c43f76248b5c37ce213667cb794ff81901cc3b1 , http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d578418f6076efc180793a8c925bf7ec143b1db4 and https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200224-2dgphw45/packages/diff-html/
Feb 24 17:37:52 <RP> JPEW: i.e. bad maintainer data got in, now despite it being fixed, its still there
Feb 24 17:38:20 <RP> JPEW: how do we get rid of it?
Feb 24 18:01:47 <RP> JPEW: thinking we may just have to bump a version into the checksum and invalidate all the output hashes? :/
Feb 24 18:09:19 <xyzzy42> Is it still the case that a variable set in a .bbclass can't be changed in another layer?  https://stackoverflow.com/questions/51002891/overwriting-yocto-classes-through-meta-layer
Feb 24 18:19:23 <smurray> xyzzy42: it's still the case that you can't bbappend a bbclass, but instead need to overlay it completely, if that's what you're asking
Feb 24 18:20:47 <xyzzy42> smurray, It seems I can use _append and _remove in the machine configuration to modify variables set in a bbclass.
Feb 24 18:21:09 <smurray> xyzzy42: yes, that's always been the case
Feb 24 18:21:52 <smurray> xyzzy42: _append and _remove are processed at the end of parsing, so they'll pretty much always work
Feb 24 18:23:12 <xyzzy42> smurray, but you can't have one recipe modify variables used by another recipe, right?  I gather that's because processing one recipe does not include all other recipies.
Feb 24 18:23:50 <smurray> xyzzy42: which class are you trying to over-ride some variable from? And yes, recipe specific variables are local to that recipe
Feb 24 18:25:28 <xyzzy42> smurray, mender-part-images.bbclass, https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/classes/mender-part-images.bbclass#L267
Feb 24 18:26:42 <xyzzy42> I've used _remove in my machine config, which is also where the bootloader is chosen with preferred_provider virtual/bootloader, to fix this.  It seems like this a good way to do it.
Feb 24 18:27:37 <smurray> for image bootloader dependency tinkering like that, that's probably reasonable
Feb 24 18:28:00 <xyzzy42> the firmware I've inherited had a "do anything to make it work" design, no kludge was too much.  I'm trying to actually do things right.
Feb 24 18:28:51 <xyzzy42> I think the truth here is that the mender layer has a flaw and should have added the u-boot dependency in a different way
Feb 24 18:28:56 <smurray> xyzzy42: might be worth pinging the Mender folks to see if they can make it more easily configurable with e.g. a variable that has the bootloader dependency
Feb 24 18:30:04 <xyzzy42> I think this isn't even the real bootloader dependency.  They added a hack because using some kind of grub-efi boot on arm still needs u-boot.
Feb 24 18:31:01 <xyzzy42> But I've never used grub and EFI on arm (why?) so I'm not totally sure
Feb 24 19:01:22 <JPEW> RP: Is the maintainer a whitelisted variable?
Feb 24 19:02:21 <JPEW> Oh, right I see, it was a bug that they weren't included in the taskhash
Feb 24 19:14:24 <JPEW> RP: So is this an example of a "diverging hash", where the same taskhash (pre bug fix) produces two different output hashes?
Feb 24 19:58:29 <tgamblin> JPEW: RP: have you recently run into an issue with reproducible builds where oe-selftest passes .ipk tests, but subsequently complains about a nonexistent build-st/tmp-glibc/deploy/deb path?
Feb 24 19:58:42 <tgamblin> I saw it once and I'm trying to confirm whether or not it's just me
Feb 24 20:04:51 <armpit> zeddii, Ill give the 5.2 update a try on zeus. thanks
Feb 24 20:11:51 <bernardoaraujo> LetoThe2nd: solved my networking problem from this morning... My build is based on warrior, and systemd-networkd couldn't find config files for wired interfaces
Feb 24 20:11:57 <bernardoaraujo> following this helped https://hub.mender.io/t/how-to-configure-networking-using-systemd-in-yocto-project/1097
Feb 24 20:12:59 <bernardoaraujo> building on zeus didn't show the same issue.. but I'm adding the bbappends to my distro layer anyways
Feb 24 20:21:27 <JPEW> tgamblin: I haven't see that
Feb 24 20:23:14 <tgamblin> JPEW: Hmm. Might just be me. Here's the output for the record, though https://pastebin.com/zkkbv5QP
Feb 24 20:25:05 <kroon> JPEW, would you by any chance know how to override SDE_FILE in a recipe ? (http://lists.openembedded.org/pipermail/openembedded-core/2020-February/293398.html)
Feb 24 20:27:00 <metalMajor> Hello, I have a question about the populate_sdk task. I am using the installer to install the generated SDK, and that works very well, but actually for my use case, I am only interested in the target directory "aarch64-poky-linux". This is because I am using a cross compilation toolchain that runs on macOS and so I only need the “target”
Feb 24 20:27:01 <metalMajor> sysroot. Is there a way that I can get the target directory in one go, instead of having to create and install the sdk first?
Feb 24 20:27:59 <JPEW> kroon: Ya, I saw your email... let me take a look
Feb 24 20:28:30 <JPEW> kroon: Out of curiosity, why do you want to override it?
Feb 24 20:32:43 <kroon> JPEW, its for a recipe that doesn't have any sources, it just creates an ext4 file-system using files it DEPENDS on. But I'd like to use ${SOURCE_DATE_EPOCH} in the recipe to set file timestamps to a reproducible date
Feb 24 20:33:37 <kroon> But the code in reproducible_build.bbclass falls back to fixed_source_date_epoch() = 0
Feb 24 20:33:52 <JPEW> kroon: Ya, I always though that was weird :)
Feb 24 20:35:56 <JPEW> kroon: Ok, right. We change do_deploy_source_date_epoch() to fix a race condition, which makes that comment a partial lie
Feb 24 20:36:09 <JPEW> It's a little more complicated that it indicates
Feb 24 20:37:35 <JPEW> Hmm, I have an idea
Feb 24 20:46:05 <JPEW> kroon: Try this: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=d091d2aa53ea417f70c10f5ce89151820c3db9ce
Feb 24 20:46:17 <JPEW> Maybe that should be the first check....
Feb 24 20:47:25 <kroon> JPEW, ok, testing
Feb 24 20:48:27 <JPEW> kroon: Ok... hopefully it works because I didn't really even make sure it parses :)
Feb 24 20:52:01 <kovalevsky> Hi there, when I run bitbake <my-recipe>, does this will build other recipes that will require or do I have to build them separetely?
Feb 24 20:54:03 <kroon> hmm I'm drawing blanks.. isn't it possible to set a bitbake variable to the output of some shell command ? is only embedded python supported ?
Feb 24 20:55:53 <kroon> JPEW, thanks for the proposed patch; at least it parses, but a lot of stuff needs to rebuild, so I wont have a results right away
Feb 24 20:57:44 <JPEW> kroon: Hmm, I wouldn't think that would cause a lot of rebuilds...
Feb 24 20:57:56 <JPEW> Unless you have SOURCE_DATE_EPOCH set somewhere
Feb 24 20:58:15 <JPEW> kroon: No, I don't think you can set a variable to shell output
Feb 24 21:05:11 <kroon> JPEW, i'd expect if we change how SOURCE_DATE_EPOCH is calculated, it should lead to lots of rebuilding.. no ?
Feb 24 21:05:53 <kroon> JPEW, but maybe not for the -native ones..
Feb 24 21:06:24 <kroon> assuming -native doesn't care about reproduibilty
Feb 24 21:22:03 <RP> tgamblin: not seen that either
Feb 24 21:22:10 <RP> JPEW: yes, it is another example
Feb 24 21:28:38 <mischief> is it possible to chain image/conversion types together with more than 2 levels? e.g. IMAGE_FSTYPES = "ext4.foo.bar.baz" ?
Feb 24 21:34:14 <JPEW> kroon: Doesn't yet. I guess I would be suprised if that patch *actually* change the SDE value
Feb 24 21:39:29 <kroon> JPEW, first try and it does looks like I can set SOURCE_DATE_EPOCH directly in the recipe
Feb 24 21:43:20 <mischief> i guess another question.. im trying to figure out how to add something to my rootfs (e.g. via an image class) but only for a particular machine.. but it's not clear how i can avoid getting that applied to my initramfs image too.
Feb 24 21:47:34 <kroon> JPEW, time for sleep, will do some more testing tomorrow
Feb 24 22:39:37 <paulbarker> RP: Is there any info around on how to run the bitbake tests?
Feb 24 22:41:21 <RP> paulbarker: "bitbake-selftest"
Feb 24 22:41:45 <RP> bitbake-selftest --help has info
Feb 24 22:42:45 <paulbarker> RP: Ok I'll dig into the source of that command
Feb 24 22:43:44 <paulbarker> Ah I need `bitbake-selftest bb.tests.blah`, it's not quite the same as `oe-selftest`
Feb 24 22:45:04 <RP> paulbarker: ah, yes. Sorry, wasn't sure what you were asking
Feb 24 22:47:19 * JPEW wonders why bitbaker-layers doesn't seem to work well with multiconfig....
Feb 24 22:50:27 <paulbarker> RP: Looks like we're missing a test for fetching git submodules from a mirror even without enabling git shallow tarballs
Feb 24 22:54:40 <RP> paulbarker: that could well be true :(
Feb 24 23:00:13 <kovalevsky> does somebody know if I run bitbake <my-recipe> if this will build first other dependent recipes first ?
Feb 24 23:00:25 <bluelightning> kovalevsky: correct, it will
Feb 24 23:02:13 <kovalevsky> @bluelightning, thanks
Feb 24 23:02:36 <kovalevsky> If there is a way that I can take a closer look at what's inside a do_compile task for an specific recipe?
Feb 24 23:04:21 <kovalevsky> Currently I am building a rust application and it looks to me that all the dependencies are build without any issue, however, when I try to build the recipe that contains my application, I think I got an issue with libloading v0.5.2 that I am not quite understand yet, and the issue happens at do_compile.
Feb 24 23:05:09 <bluelightning> kovalevsky: probably the best way is to let it fail like you have and then look at run.do_compile in temp under the workdir for the recipe
Feb 24 23:06:28 <bluelightning> kovalevsky: if needed you can find the recipe workdir using bitbake -e recipename | grep ^WORKDIR=
Feb 24 23:07:30 <kovalevsky> bluelightning, got it. I can see now the run.do_compile
Feb 24 23:08:22 <kovalevsky> However, I see several ones that the only difference is a number appending
Feb 24 23:08:39 <kovalevsky> probably due the fact of compiling several times and having each record?
Feb 24 23:09:06 <bluelightning> kovalevsky: yep, every time the task runs it creates a new one... there's a run.do_* symlink to the most recent one
Feb 24 23:10:17 <kovalevsky> bluelightning, roget that.
Feb 24 23:12:12 <kovalevsky> bluelightning, thanks that helps a lot.
Feb 24 23:12:19 <bluelightning> no worries
Feb 25 01:49:24 <mischief> argh. does anyone know how to fix this? https://ghostbin.co/paste/pzapd/raw i am trying to write a recipe for https://github.com/ianlancetaylor/libbacktrace .
**** ENDING LOGGING AT Tue Feb 25 02:59:57 2020