**** BEGIN LOGGING AT Fri Feb 28 02:59:57 2020
Feb 28 06:00:14 <siva> how can i append my kernel config to .config file? i have a defconfig in my linux-imx_%.append
Feb 28 06:01:44 <siva> SRC_URI += "file://defconfig"
Feb 28 06:07:56 <siva> i noticed that my defconfig file is copied to the build directory. but .config didn't contain the changes
Feb 28 06:30:27 <tlwoerner> extracting an eSDK always fails with: Please set a MACHINE in your local.conf or environment
Feb 28 06:30:45 <tlwoerner> regardless of whether a MACHINE is set in the environment, on the cmdline, or both
Feb 28 06:30:51 <tlwoerner> none of the following succeed:
Feb 28 06:31:27 <tlwoerner> 1$ MACHINE=<m> ./oecore-x86_64-aarch64-toolchain-ext-nodistro.0.sh
Feb 28 06:31:46 <tlwoerner> 2$ ./oecore-x86_64-aarch64-toolchain-ext-nodistro.0.sh MACHINE=<m>
Feb 28 06:31:55 <tlwoerner> 3$ export MACHINE=<m>
Feb 28 06:32:01 <tlwoerner> 3$ ./oecore-x86_64-aarch64-toolchain-ext-nodistro.0.sh
Feb 28 06:32:21 <tlwoerner> 4$ export MACHINE=<m>
Feb 28 06:32:31 <tlwoerner> 4$ MACHINE=<m> ./oecore-x86_64-aarch64-toolchain-ext-nodistro.0.sh MACHINE=<m>
Feb 28 06:44:15 <tlwoerner> ah... the local.conf used to create the esdk didn't have a MACHINE set it in (it was set on the cmdline). setting a MACHINE in the original local.conf fixes this issue. esdk extraction gets further but then fails later on anyway
Feb 28 08:21:12 <angelo__> LetoThe2nd, mainly, dropbear is not finding the key when starting, looking for it in /var/lib.. while it is in /etc/dropbear..
Feb 28 08:21:22 <angelo__> this seems to be done from   poky/meta/classes/rootfs-postcommands.bbclass
Feb 28 08:21:33 <RP> khem: see the reply on the list to the make patch
Feb 28 08:23:02 <LetoThe2nd> angelo__: have you verified that this also applies to a "naked" poky build? in that case it is a bug worth looking into.
Feb 28 08:25:29 <angelo__> well, looks like without READONLY dropbear works fine
Feb 28 08:25:43 <angelo__> not tested personally, but this is what my collegues says
Feb 28 08:25:54 <angelo__> on same repo, without READONLY
Feb 28 08:26:30 <angelo__> looks like involved code is   https://pastebin.com/bwBhtAti
Feb 28 08:26:37 <angelo__> in  poky/meta/classes/rootfs-postcommands.bbclass
Feb 28 08:27:10 <LetoThe2nd> angelo__: please test it, because it really makes a difference. if its broken for a plain poky build, then its a bug worth looking into for us. if it works there, then its your problem.
Feb 28 08:27:32 <angelo__> LetoThe2nd, ok, will try
Feb 28 08:56:20 <angelo__> LetoThe2nd, in normal build it works
Feb 28 08:56:45 <yocti> New news from stackoverflow: How can I get the iptables match "ipv4options" working in yocto sumo? <https://stackoverflow.com/questions/60447900/how-can-i-get-the-iptables-match-ipv4options-working-in-yocto-sumo>
Feb 28 08:56:58 <LetoThe2nd> angelo__: then find out what your secrit sauce does in order to break it. :(
Feb 28 08:56:58 <angelo__> question: is rootfs-postcommands.bbclass is used only for readonly build ?
Feb 28 08:57:11 <LetoThe2nd> no, don't think so
Feb 28 08:57:16 <angelo__> mm ok thanks
Feb 28 08:58:50 <angelo__> LetoThe2nd, well code above i linked is called in   "read_only_rootfs_hook () {
Feb 28 08:58:50 <angelo__> "
Feb 28 08:58:56 <angelo__> so issue comes from there
Feb 28 08:59:49 <angelo__> the dropbear key can't be in rootfs generated since is created by dropbearkey.service, that's the issue
Feb 28 09:00:41 <LetoThe2nd> angelo__: but in a plain poky build with EXTRA_IMAGE_FEATUREs += "read-only-rootfs" it works?
Feb 28 09:01:20 <angelo__> ah, ok, will test plain poky
Feb 28 09:01:31 <angelo__> now i am in a bsp
Feb 28 09:01:51 <LetoThe2nd> *sigh*
Feb 28 09:02:11 <LetoThe2nd> i've been telling you for two days now. seriously, i'm out now until you've done that. sorry.
Feb 28 09:02:12 <angelo__> but from a grep, all dropbear occurences are in poky only
Feb 28 09:03:16 <angelo__> ok, thanks btw, sorry for chaos
Feb 28 09:15:32 <preminux> Hello, does anyone know when the sumo-next is becoming an official release like 2.5.4. TIA WP
Feb 28 09:15:48 <LetoThe2nd> preminux: hum probably "never"
Feb 28 09:16:30 <preminux> OK, that's also a statement :)
Feb 28 09:17:53 <kriive> Uhm, I always wondered what *-next releases actually were
Feb 28 09:18:31 <kriive> *branches, sorry
Feb 28 09:18:53 <LetoThe2nd> kriive: they are meant for the next releases, but sumo is just "old" and basically out of support, unless somebody steps up.
Feb 28 09:20:04 <kriive> Oh, got it
Feb 28 09:21:33 <kriive> I also am still on sumo, cause my BSP layer ships with sumo. It has a number of patches against linux-4.14 to make those three leds available to userspace that are a nightmare to port
Feb 28 09:22:11 <kriive> I guess I'll wait for them to bump yocto version to warrior
Feb 28 09:22:39 <LetoThe2nd> if your bsp layer is self-contained and does not bring any nasty dependencies, then you should totally be able to just bump it. there is no magic in shipping warrior or zeus with a 4.14 kernel
Feb 28 09:23:34 <kriive> I tried some time ago (was pretty new to yocto, still am but less lol) but didn't manage to find linux-4.14 in later releases
Feb 28 09:24:09 <kriive> I guess it was dropped somewhere warrior and zeus?
Feb 28 09:24:18 <kriive> somewhere between*
Feb 28 09:28:19 <kriive> Beginning in warrior linux-4.14 is not found anymore, at least here: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/?h=warrior
Feb 28 09:28:49 <LetoThe2nd> kriive: it often happens that kernel versions are dropped from poky, but your bsp is free to bring whatever it likes. thats what i meant with "self-containerd"
Feb 28 09:29:56 <kriive> Ah, ok, then it's not self-contained. It relies on oe linux-yocto, it does not bring its own linux recipe, patches on linux-4.14
Feb 28 09:32:37 <LetoThe2nd> kriive: you could still copy the relevant bits over and carry them yourself, but yeah, thats a bit more complicated then.
Feb 28 09:33:00 <kriive> I'll give it another try
Feb 28 09:33:01 <LetoThe2nd> our inhouse bsps completely replace the kernel so we are free to move back and forth.
Feb 28 09:33:06 <kriive> thank you
Feb 28 09:33:30 <kriive> LetoThe2nd: that's actually handy
Feb 28 09:34:17 <preminux> kriive: you can define PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom" in your machine file, create a recipe linux-yocto-custom.bbapend and there you can define the Linux version you like to have e.g. LINUX_VERSION = "4.4"# tag v4.4...  => commit afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dcSRCREV_machine="afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc"
Feb 28 09:34:58 <LetoThe2nd> preminux: thats the core bits, yes.
Feb 28 09:36:34 <kriive> Thank you guys, I am trying this right now :)
Feb 28 10:01:56 <kuschky2> milloni: just a feedback about the busybox date command and failing localization. Using date from coreutils by by append coreutils to IMAGE_INSTALL solved the problem for me. No further action was required. Now date is linked by /bin/date -> /bin/date.coreutils
Feb 28 10:18:50 <kriive> Do you think I can just copy poky/meta/recipes-kernel/linux/linux-yocto_4.14.bb in a layer of mine and use it in warrior/zeus or are there other things I should check?
Feb 28 10:20:05 <LetoThe2nd> kriive: "just copy" is a high expectation. if you asked for "use as a starting point to transfer into my own layer", then it would be a clear "yes"
Feb 28 10:21:14 <kriive> Ok, that will be my approach I certainly not have such high expectations lol
Feb 28 10:57:13 <yocti> New news from stackoverflow: Populating static libraries to SDK in yocto <https://stackoverflow.com/questions/60450176/populating-static-libraries-to-sdk-in-yocto>
Feb 28 11:07:38 <chabot> Hi, I set up an overlayFS mechanism updating the fstab file using, the base-files bbappend and it works great. I create the partitions using WIC. However it is difficult to manage several images some using overlayFS and some not. Is there any solution to specify this overlay partition in the wic .wks file directly ? I saw that the overlay fstype is
Feb 28 11:07:39 <chabot> not provided.
Feb 28 12:21:08 <shan1> Guys quick question. I am using `warrior` for an PHYTEC iMX6 board. I do not seem to have the `/dev/input/event0` interface.
Feb 28 12:21:43 <shan1> I checked the Device Tree Files and didn't find anything particular there. where does one enable this interface?
Feb 28 12:23:09 <LetoThe2nd> its only there if 1) the hardware actually permits input 2) the input subsystm in the kernel is activated
Feb 28 12:26:47 <shan1> it does i transitioned from old layers of the BSP to warrior and previously the `/dev/input/event0` was there. I used it to detect button presses.
Feb 28 12:27:21 <shan1> how to enable or check if the input subsystem is enabled in the kernel
Feb 28 12:27:27 <yocti> New news from stackoverflow: iMX 8M BSP Selection <https://stackoverflow.com/questions/60451628/imx-8m-bsp-selection>
Feb 28 12:29:54 <mcfrisk> shan1: check your effective kernel config from bitbake build or from kernel -dev package (it may have the effective config).
Feb 28 12:34:37 <shan1> mcfrisk you mean the menuconfig via `bitbake -c menuconfig linux-mainline` ?
Feb 28 12:50:26 <mcfrisk> shan1: or run "bitbake -c compile kernel_recipe" and check the effective .config file in build directory. menuconfig will give the menu but not the config file, though it's possible to search there too.
Feb 28 12:51:23 <shan1> I do not know which kernel recipe to look for
Feb 28 13:02:41 <shan1> I think I found it. I used `bitbake -c compile virtual/kernel` in Device Drivers  --> Event Debuggging and Event Input from `*` to `M`. then `bitbake -c compile virtual/kernel` and then `bitbake -c deploy virtual/kernel`
Feb 28 13:29:21 <shan1> didn't work :(
Feb 28 13:53:14 <shan1> LetoThe2nd or mcfrisk can you tell me if this is a good practice where I used the kernel modules for __EVDEV__ and then used the `fragment.cfg` file within an `linux_mainline_%.bbappend`. I used `SRC_URI_append = "file://fragment.cfg"
Feb 28 13:53:52 <shan1> I often see that such configuration are part of the `defconfig` file
Feb 28 14:50:33 <JPEW> kroon: Hmm, I wonder if that's because it can't figure out it needs to be excluded from the basehash....
Feb 28 14:55:21 <kroon> JPEW, I dunno.. running bitbake -e for the recipe, I can see that SOURCE_DATE_EPOCH is not in BB_HASHBASE_WHITELIST
Feb 28 14:55:55 <kroon> still, bitbake-dumpsig says its listed on the "basewhitelist:" line
Feb 28 14:56:01 <JPEW> kroon: Weird. What about just `bitbake -e` with no recipe?
Feb 28 14:56:48 <kroon> JPEW, then it is there
Feb 28 14:57:24 <kroon> i.e. SOURCE_DATE_EPOCH is back in BB_HASHBASE_WHITELIST
Feb 28 14:57:47 <JPEW> kroon: Right because there's no recipe to overriding the value
Feb 28 14:58:25 <JPEW> I suspect if you set SOURCE_DATE_EPOCH in local.conf it would get excluded in the basehash
Feb 28 14:58:43 <JPEW> But, that probably means the tricky way isn't an option :)
Feb 28 15:03:03 <kroon> JPEW, I tried setting it in local.conf but using a pn override, SOURCE_DATE_EPOCH_pn-my-recipe, but I guess thats not what you meant ?
Feb 28 15:03:23 <kroon> Cause its still in basewhitelist: with that
Feb 28 15:05:04 <RP> There is the possibility that the whitelist is treated as a configuration wide variable
Feb 28 15:07:30 * kroon wishes he knew what that meant :-O
Feb 28 15:10:32 <ruru4143_> Is there a way to turn this off? i don't want to be in your accesslog
Feb 28 15:10:32 <ruru4143_> DEBUG: For url git://git.domain.tld/repo.git;rev=f8e4ba37f67ba8a85c8622e1f705d7902b32dbc0 returning http://downloads.yoctoproject.org/mirror/sources/git2_git.domain.tld.repo.git.tar.gz
Feb 28 15:13:27 <JaMa> ruru4143_: define your own MIRRORS variable
Feb 28 15:16:50 <roussinm> How much work would it be take get gcc 9.2 working on Krogoth *only* for our company layer? I realize that I will get two libgcc inside the image, but at the moment this is not a concern.
Feb 28 15:21:50 <milloni> kuschky2: good to hear that!
Feb 28 15:22:09 <milloni> are you planning to report the bug to busybox? (if not, i can do it)
Feb 28 15:34:28 <ruru4143_> JaMa: thanks
Feb 28 15:59:19 <JPEW> RP: That's my suspicion
Feb 28 15:59:39 <JPEW> RP: I think I'm confusing the terminology for saying it :)
Feb 28 16:28:20 <yocti> New news from stackoverflow: need help installing the program image (BIN-file) to the imx6s device <https://stackoverflow.com/questions/60455321/need-help-installing-the-program-image-bin-file-to-the-imx6s-device>
Feb 28 17:25:09 <shan1> What is the error mean here?
Feb 28 17:25:12 <shan1> ```
Feb 28 17:25:23 <shan1> TypeError: 'float' object is not iterableERROR: Command 'script -e -q -c "recipetool --color=always create --devtool -o /tmp/devtoole8o6tysc 'https://github.com/shantanoo-desai/buttonflux/archive/v1.2.zip'  -x /home/des/Yocto/PHYTEC_BSPs/yocto_fsl_update/build/workspace/sources/devtoolsrcv1z1l3ys -N buttonflux" /dev/null' failed
Feb 28 17:25:59 <shan1> I get this error when creating a python recipe using `devtool add python3-buttonflux <github archive url to my repo>
Feb 28 17:35:51 <kriive> Will golang project that support modules be easier to build?
Feb 28 17:46:33 <shan1> I have documented the error as an SE Query [here](https://stackoverflow.com/questions/60456822/devtool-throws-typeerror-when-adding-a-recipe-for-a-python-application-in-yocto)
Feb 28 17:47:34 <kriive> jq
Feb 28 17:58:38 <yocti> New news from stackoverflow: devtool throws TypeError when adding a recipe for a python application in Yocto's Warrior <https://stackoverflow.com/questions/60456822/devtool-throws-typeerror-when-adding-a-recipe-for-a-python-application-in-yocto>
Feb 28 18:10:13 <Marex> khem: hey, do you know how the YP is registered as a legal entity in the US ? is it a non-profit ?
Feb 28 18:10:20 <Marex> I can't find the details
Feb 28 18:13:29 <armpit> Marex, YP is a Linux foundation project so Its covered by them
Feb 28 18:13:43 <Marex> armpit: ah OK
Feb 28 18:28:33 <shan1> How does one go about with recipes when devtool/recipetool is broken?
Feb 28 18:31:07 <zeddii> meaning, how you’d create one ?
Feb 28 18:32:38 <shan1> the problem with me is that my devtool is throwing an error and devtool is inherently calling recipetool. I had to write my recipe by hand. There are no others tools to generate recipes in Yocto apart from devtool or recipetool right?
Feb 28 18:33:15 <zeddii> right. but I can say that I’ve never used them, so I’m not a good reference. I just copy a similar one, edit it and go from there.
Feb 28 18:34:14 <shan1> how do you generate the `sha256sum` and `md5sums` for codes. I had to clone the repo, generate hashes manually and then had to insert them.
Feb 28 18:34:37 <zeddii> yup
Feb 28 18:34:50 <shan1> luckily I package my code with tar and zip balls from github so it is easy. How do you do that for direct git repos?
Feb 28 18:34:52 <zeddii> or I just bitbake it once, and bitbake spits out the proper value. cut and paste it in :D
Feb 28 18:35:03 <zeddii> there’s no shasum for git repos.
Feb 28 18:35:18 <shan1> Add just the revision hash?
Feb 28 18:35:23 <zeddii> yup
Feb 28 18:35:51 <kriive> shan1: for sha256sum I use the cli tool sha256sum
Feb 28 18:36:04 <kriive> For md5 use md5sum
Feb 28 18:36:18 <shan1> kriive Yup used the same for all things. I was just curious if there way something else
Feb 28 18:36:23 <kriive> Or else let bitbake as zeddii does it
Feb 28 18:36:41 * zeddii takes the path of least resistance :D
Feb 28 18:37:41 * kriive screams and cries to bitbake waiting for him to build its stuff
Feb 28 18:38:30 <shan1> @shan1: Tears off hair when it comes throws errors that even aliens can't understand
Feb 28 18:41:27 <tgamblin> That's not a bad thought. Maybe aliens haven't visited Earth because they are afraid we'll ask them to debug our code!
Feb 28 18:42:11 <kriive> But hey guys, I found a dev branch on my BSP github that supports warrior!
Feb 28 18:42:29 <kriive> And it actually works!
Feb 28 18:42:35 <shan1> And their first ever PR will be rejected by Linus because they didn't add enough documentation in the commit
Feb 28 19:06:36 <khem> zeddii: I see you have been teaching wrong things today :)
Feb 28 19:07:05 <zeddii> :D
Feb 28 19:07:40 <paulg> has zeddii ever taught "right" things?
Feb 28 19:08:45 * zeddii cannot deny the charges
Feb 28 19:19:54 <watchd0g> hi there,
Feb 28 19:20:02 <watchd0g> does anyone ever experienced someting like
Feb 28 19:20:07 <watchd0g> ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
Feb 28 19:20:33 <watchd0g> when ca-certificates r populating on the do_rootfs ?
Feb 28 19:20:45 <watchd0g> branch sumo
Feb 28 19:21:28 <paulg> If anyone could help you, it would probably be seebs...
Feb 28 19:22:10 <watchd0g> :D it would be great
Feb 28 19:22:16 <paulg> but from the error message, it kinda looks like a cross compile fail.
Feb 28 19:23:30 <paulg> what is your target deployment, and what is your build host?
Feb 28 19:23:41 <khem> watchd0g: are you using 32bit OS on build system
Feb 28 19:23:56 <khem> or perhaps multilib
Feb 28 19:24:41 <paulg> yeah, that too - what khem said.  ;-)
Feb 28 19:25:23 <paulg> [People still have 32 bit build systems?]
Feb 28 19:26:33 <khem> you might need to use PSEUDO_UNLOAD=1 <cmd> ...
Feb 28 19:26:38 <khem> some tools are 32bit
Feb 28 19:26:38 <watchd0g> nah, im using  64 bits debian at this moment
Feb 28 19:33:07 <seebs> watchd0g: that does look like you're running a 32-bit binary of *some* kind on a 64-bit host
Feb 28 20:11:06 <watchd0g> that's a bit strange because when building against thud i didnt have this problem on the same machine
Feb 28 20:11:20 <watchd0g> but in the meantime version of ca-certificates changed from sumo to thud
Feb 28 20:11:39 <khem> its possible new versions require more things
Feb 28 20:17:12 <shan1> Can `SRC_URI_append` use more than one file as a value or should one write each file as a seperate `SRC_URI_append`?
Feb 28 20:18:41 <shan1> I have some patches to the Device tree that do not enable a UART port but add EVDEV kernel module for the following `SRC_URI_append = "  file://patch1 \ file://patch2 \ file://my.cfg"`
Feb 28 20:21:01 <watchd0g> i guess that the good practices tells us to use multilines with \ when using append
Feb 28 20:21:29 <watchd0g> SRC_URI_append = " file://something \
Feb 28 20:21:32 <shan1> I tried the same but the patches don't get applied
Feb 28 20:21:35 <watchd0g> file://othersomething \
Feb 28 20:21:36 <watchd0g> "
Feb 28 20:21:58 <watchd0g> are u using = ?
Feb 28 20:22:03 <watchd0g> or += ?
Feb 28 20:23:02 <shan1> `=`
Feb 28 20:24:29 <shan1> for more file should it be `+=`?
Feb 28 20:24:57 <watchd0g> nop
Feb 28 20:25:45 <watchd0g> something related to the .bbappend u r using probably?
Feb 28 20:26:07 <shan1> here is the file https://github.com/iotfablab/meta-iotfablab/blob/master/recipes-kernel/linux-mainline_%25.bbappend
Feb 28 20:27:53 <shan1> it is so weird I ran the build again and now the evdev module is not added, but the patches are applied. it is either the patches or the cfg
Feb 28 20:30:35 <dmoseley> Has anyone generated XFS images for their rootfs with Yocto builds? I see the utils in meta-filesystems but Google is not showing me anything of note.
Feb 28 20:30:36 <watchd0g> on the first sight it looks like nice to me
Feb 28 20:31:15 <watchd0g> i always use the PN name like "${THISDIR}/${PN}:" when using patches, but that's not clearly the problem
Feb 28 20:31:41 <shan1> I am re-writing the SRC_URI_append  on each line and see what happens
Feb 28 20:32:58 <watchd0g> aren't you missing "linux" folder? dunno if that's relevant tbh
Feb 28 20:33:15 <shan1> added that. I missed that part.
Feb 28 20:33:28 <watchd0g> like recipes-kernel/linux/linux-mainline_%.bbappend
Feb 28 20:33:33 <watchd0g> ham ok
Feb 28 20:33:47 <shan1> :Fingers crossed:
Feb 28 20:36:12 <watchd0g> \o/
Feb 28 20:44:00 <shan1> watchd0g would you happen to know if it would be possible to check if `/dev/input` and a serial port `/dev/ttymxc0` could be checked within the `build` before loading the image on hardware?
Feb 28 20:56:03 <shan1> watchd0g didn't work :*
Feb 28 20:56:21 <shan1> oops sorry wrong emoji :(
Feb 28 20:56:51 <shan1> only the patches get applied not the cfg
Feb 28 21:03:04 <watchd0g> i guess i didnt understand your question, but now a days /dev it's just a virtual FS (kinda special)
Feb 28 21:03:52 <watchd0g> it holds no info about your uart nor touchscreen
Feb 28 21:05:14 <shan1> one last try is I might do a force compile of the kernel and use bitbake -c deploy virtual/kernel
Feb 28 21:06:17 <watchd0g> your problem could not be in the yocto "framework" but something related with applying fragments of kernel configuration
Feb 28 21:06:35 <watchd0g> i i've always applied defconf files but never a fragment
Feb 28 21:07:07 <shan1> would you believe it if I told you I tried adding a custom defconfig file too but it still didn't work
Feb 28 21:08:22 <shan1> via the SRC_URI_append.
Feb 28 21:09:36 <watchd0g> you probable have to include the recipe .inc file in order to "extend" it
Feb 28 21:10:16 <watchd0g> i guess you need something like "require recipes-kernel/linux/linux-mainline(..)"
Feb 28 21:10:20 <watchd0g> on top of your bbappend
Feb 28 21:11:23 <watchd0g> or so, something abount the dependencies of what your are trying to include
Feb 28 21:14:37 <watchd0g> but i know nothing about that topic :s
Feb 28 21:15:15 <watchd0g> look at this topic
Feb 28 21:15:17 <watchd0g> https://www.yoctoproject.org/pipermail/yocto/2014-May/019396.htmlhttps://www.yoctoproject.org/pipermail/yocto/2014-May/019396.htmlhttps://www.yoctoproject.org/pipermail/yocto/2014-May/019396.html
Feb 28 21:15:22 <watchd0g> ups
Feb 28 21:15:23 <watchd0g> https://www.yoctoproject.org/pipermail/yocto/2014-May/019396.html
Feb 28 21:22:43 <shan1> Can't figure it out. The force run didn't work too. :(
Feb 28 21:23:32 <shan1> let's see 12 hours at work and still can't figure it out. thanks anyways watchd0g
Feb 28 21:27:32 <watchd0g> shan1, have you checked the thread i posted?
Feb 28 21:28:19 <shan1> yes I did
Feb 28 21:30:02 <shan1> are you suggesting SRCREV_machine = "${SRCREV}" in the recipe?
Feb 28 21:30:23 <watchd0g> and the inc files too probably
Feb 28 21:31:29 <shan1> I wouldn't know where to begin with the inc files.
Feb 28 21:41:42 <shan1> @wat
Feb 28 21:52:54 <moto-timo> did cleansstate get slower recently or have I just got a bad memory?
Feb 28 22:05:32 <mranostay> moto-timo: those aren't mutually exclusive :)
Feb 28 22:22:19 <JPEW> Excellent! I think I have python's hierarchial logging framework plumbed into knotty correctly!
Feb 28 22:30:59 <stacktrust> Is there a good example of centrally defining version & product brand strings within OE/Yocto, including localization?
Feb 28 22:41:48 <stacktrust> One approach is version strings in local.conf or site.conf
Feb 28 22:42:34 <stacktrust> Another approach is a dedicated package which generates a text file that can be referenced from the sysroot of other packages
Feb 28 22:43:00 <JPEW> FWIW, we use local.conf/site.conf
Feb 28 22:43:26 <stacktrust> JPEW: do you have any version strings with timestamp of the build?
Feb 28 22:43:58 <JPEW> stacktrust: Not explicitly; I think /etc/version has that already
Feb 28 22:45:00 <JPEW> Although, I just checked on something I built today and it says 2018, so perhaps thats not working as expected
Feb 28 22:48:43 <stacktrust> that's a good point, this is useful: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/os-release/os-release.bb
Feb 28 22:49:14 <JPEW> Oh, ya
Feb 28 22:49:24 <JPEW> We put a lot of that in /etc/build
Feb 28 22:49:32 <JPEW> I can't recall the exact method ATM
Feb 28 22:50:03 <JPEW> ${IMAGE_BUILDINFO_VARS}
Feb 28 22:50:43 <JPEW> (and you have to inherit image-buildinfo)
Feb 28 22:51:01 <JPEW> It's nice because it has the SHA-1 of all the layers your using :)
Feb 28 23:00:51 <stacktrust> excellent
Feb 28 23:22:32 <TheMrRafus>  /msg NickServ identify Rafael13
Feb 28 23:23:46 <mranostay> heh probably want to change that password
Feb 28 23:26:47 <mranostay> TheMrRafus: hope you are changing your password :)
Feb 28 23:27:36 <TheMrRafus> Yes, It was a mistake, sorry
Feb 28 23:49:13 * moto-timo laughing. thanks mranostay
Feb 29 01:05:55 <mauz555> is the sdcard.bz2 format deprecated for wic in latest releases ?
Feb 29 02:52:34 <moto-timo> That moment when you realize a patch in foo/ will not be picked up by foo-native
Feb 29 02:52:42 <moto-timo> :facepalm:
Feb 29 02:53:33 <moto-timo> How to waste half a day for nothing
Feb 29 02:53:57 <kergoth> that shouldnt actually be the case. iirc we use ${BPN}, not ${PN} in FILESPATH
Feb 29 02:54:07 <kergoth> but examine bitbake.conf / base.bbclass for the actual values used
Feb 29 02:54:47 <moto-timo> at-spi2-atk-native very happily ignored a patch present in at-spi2-atk/
Feb 29 02:56:32 <moto-timo> https://git.openembedded.org/openembedded-core-contrib/commit/?h=timo/a11y-upgrades&id=28ff4923d73e56ea99c265ab4e470033b00054a8
Feb 29 02:58:54 <kergoth> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/base.bbclass#L82
Feb 29 02:59:00 <kergoth> ["${FILE_DIRNAME}/${BP}", "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"]
Feb 29 02:59:13 <moto-timo> harumph
Feb 29 02:59:16 <moto-timo> then WTF
Feb 29 02:59:38 <moto-timo> blame it on centos-7
**** ENDING LOGGING AT Sat Feb 29 02:59:59 2020