**** BEGIN LOGGING AT Thu Apr 02 02:59:57 2020
Apr 02 07:09:45 <CruX|> hello, can you recommend eeprom memory tester which is accessible via /sys/.../eeprom ? (i'm using my own driver based on at25 driver) I want to test random unaligned reads/writes
Apr 02 07:10:39 <CruX|> most of tools is ysing mmap which can't be used
Apr 02 07:11:27 <LetoThe2nd> CruX|: none that i knew of in public.
Apr 02 07:14:06 <CruX|> LetoThe2nd: thx
Apr 02 07:39:18 <yocti> New news from stackoverflow: cmake based bitbake recipe : sysroot missing? <https://stackoverflow.com/questions/45363081/cmake-based-bitbake-recipe-sysroot-missing>
Apr 02 08:46:10 <sstiller> Cloning poky from git.yoctoproject.org runs with 3..15 KiB/s. Can I also use github.com/kraj/poky?
Apr 02 08:47:14 <LetoThe2nd> sstiller: thou shalt not.
Apr 02 08:48:04 <LetoThe2nd> sstiller: and i get 6MBits+X downstream, so the reason is somewhere on your side probably.
Apr 02 08:50:02 <sstiller> LetoThe2nd: With other servers I have no problem.
Apr 02 08:51:19 <LetoThe2nd> sstiller: it might of course be a regional problem or such, but $ADMIN is not awake at these times, and anything other than the official repo is certainly not to be recommended.
Apr 02 08:53:10 <sstiller> LetoThe2nd: OK, tried to clone it on another computer in another city and it runs fine there.
Apr 02 08:54:05 <LetoThe2nd> :)
Apr 02 08:54:47 <LetoThe2nd> sstiller: i'd suggest that if it persists, write to the ML in 2 or 3 hrs.
Apr 02 08:55:11 <LetoThe2nd> beyond that, sorry for the inconvenience, but nothing i can do.
**** BEGIN LOGGING AT Thu Apr 02 09:00:55 2020
Apr 02 09:15:41 <sstiller> LetoThe2nd: No need to feel sorry about that ;-) I think, I can blame my ISP.
Apr 02 09:39:42 <yocti> New news from stackoverflow: yocto: how do I install header files along with kernel module in sdk <https://stackoverflow.com/questions/60780322/yocto-how-do-i-install-header-files-along-with-kernel-module-in-sdk> || Unable to build as dependencies are missing in recipe-sysroot - yocto <https://stackoverflow.com/questions/60988365/unable-to-build-as-dependencies-are-missing-in-recipe-sysroot-yocto>
Apr 02 10:08:35 <jkimblad> I want to execute a "git describe" on the source fetched from a recipe using git autorev. Then save the output of the command in a file on the target system. Is there any easy way of doing so?
Apr 02 10:10:30 <LetoThe2nd> jkimblad: depends on your definition of easy, probably.
Apr 02 10:11:40 <LetoThe2nd> for a one-recipe, quick-n-dirty solution its probably enough to do the describe in do_install and pipe it to the desired destination, plus including the destination in FILES_
Apr 02 10:12:03 <LetoThe2nd> for something sustainable, this becomes complicated quickly.
Apr 02 10:13:07 <jkimblad> Alright, is the source fetched as a git repo then? My understanding was that it isnt.
Apr 02 10:13:38 <LetoThe2nd> jkimblad: look at ${S} and find out, i also don't know.
Apr 02 10:18:58 <jkimblad> Alright, thank you for your help. This definitly makes it easier than whatever i was trying to do  \o/
Apr 02 10:56:34 <ebail> Hi guys. I want to use ovs/dpdk with Yocto Zeus on top of a Xeon Intel(R) Xeon(R) CPU E5-2680 v4. My Yocto machine requires genericx86-64.conf and overrides genericx86-64:. With that DPDK fail to compile because he is looking for SSE4.1 specific instructions that my Xeon is capable of. So it looks like I need meta-intel and I managed to compile dpdk requiring intel-corei7-64.conf in my machine.
Apr 02 10:58:00 <ebail> meta-intel defines 3 machines in https://git.yoctoproject.org/cgit.cgi/meta-intel/tree/conf/machine?h=zeus and I don't know what should be the right one for my Xeon.
Apr 02 10:58:20 <ebail> Is my approach the right one ? Thanks
Apr 02 11:01:10 <LetoThe2nd> ebail: without digging deeper, it sounds basically correct.
Apr 02 11:06:59 <rburton> ebail: you definitely want to use meta-intel.  intel-corei7-64 is the default
Apr 02 11:07:26 <rburton> i'd have to look at ark to know is the e52680 is skylake-onwards for the skylake bsp ,i know my xeon isn't
Apr 02 11:08:59 <rburton> ebail: yeah you're broadwell, same as me, so use intel-corei7-64
Apr 02 11:09:16 <rburton> (genericx86* is a terrible bsp)
Apr 02 11:10:05 <ebail> rburton: LetoThe2nd thanks. The description of the machine does not mention SSE4
Apr 02 11:10:12 <ebail> ref: https://git.yoctoproject.org/cgit.cgi/meta-intel/tree/conf/machine/intel-corei7-64.conf#n4
Apr 02 11:10:46 <rburton> right, that should be updated
Apr 02 11:10:59 <rburton> the bsp actually targets a fairly specific chipset onwards
Apr 02 11:11:18 <rburton>  - intel-corei7-64
Apr 02 11:11:18 <rburton>    This BSP is optimized for Nehalem and later Core and Xeon CPUs as
Apr 02 11:11:18 <rburton>    well as Silvermont and later Atom CPUs, such as the Baytrail SoCs.
Apr 02 11:11:18 <ebail> is it correct also to require intel-corei7-64 and overide genericx86-64 and my own machine definition
Apr 02 11:11:20 <rburton> from readme
Apr 02 11:11:26 <ebail> rburton: right
Apr 02 11:11:50 <rburton> if you're make your own BSP then at least inherit or copy corei7-64, ignore genericx86-64 entirely
Apr 02 11:12:06 <ebail> rburton: I do
Apr 02 12:44:29 <yann> Don't we have a way to prevent runtime config file changes in a dependency to trigger rebuilds  - those changes that get literally into packages without any build impact of dependencies?  It's always annoying to see how much CPU can get wasted by such changes :|
Apr 02 12:46:29 <LetoThe2nd> yann: only if you rip them out into seperate recipes and exploit hashequiv, as far as i understand it.
Apr 02 12:47:25 <yann> so that would not work for the last case that just hit me, ie. touching rules in eudev
Apr 02 12:47:47 <LetoThe2nd> yann: yup.
Apr 02 12:47:55 <yann> I still have to look at hashequiv, indeed
Apr 02 12:48:19 <LetoThe2nd> OTOH i really don't tinker with config files that much usually, so its mostly a no-problem for most users (me guesses)
Apr 02 12:49:15 <yann> in my case I'm getting rid of an old layer with useless stuff in .bbappend.  It's a PITA to remove useless junk and have the whole system rebuilt
Apr 02 12:49:32 <yann> cannot help people with spring cleanup...
Apr 02 13:38:34 <Dima_Sharihin> good time of day, guys. Is there any way to strip out python from 'gobject-introspection' package. I use lua binding (LGI), that use .typelib data, however, it isn't necessary to ship whole Python runtime to use a couple of binary files
Apr 02 13:53:00 * clementp[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/fUVspxTMtQrVqqclXncPYzkT >
Apr 02 13:53:18 <clementp[m]> But I got an error :(
Apr 02 13:53:18 <clementp[m]> ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
Apr 02 13:53:28 <clementp[m]> No match for argument: python3-pyueye
Apr 02 13:54:46 <clementp[m]> in my build script I do this : echo "IMAGE_INSTALL_append = \" python3-pyueye\"" >> conf/local.conf
Apr 02 13:55:15 <LetoThe2nd> clementp[m]: well maybe there is nothing that provides that?
Apr 02 13:55:30 <clementp[m]> I'm missing something :( ? Thanks for your help :)
Apr 02 13:56:04 <LetoThe2nd> clementp[m]: you probably missed writing a recipe: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=pyueye
Apr 02 13:57:14 <clementp[m]> The log I send is the file "python3-pyueye_4.90.0.0.bb"
Apr 02 13:58:34 <LetoThe2nd> clementp[m]: and the recipe by itself buids?
Apr 02 13:58:49 <LetoThe2nd> .e.g. bitbake python3-pyueye
Apr 02 13:58:56 <clementp[m]> yes, it's a module
Apr 02 13:59:06 <clementp[m]> the Python application will be load at runtime
Apr 02 13:59:16 <clementp[m]> haa sorry will test
Apr 02 14:00:04 <clementp[m]> Yes
Apr 02 14:00:35 <LetoThe2nd> and where is it located?
Apr 02 14:01:16 <clementp[m]> meta-company/recipes-devtools/python/
Apr 02 14:01:30 <LetoThe2nd> does sound right on first glance.
Apr 02 14:01:31 <clementp[m]> should I put it in the dynamic-layers ?
Apr 02 14:01:44 <LetoThe2nd> then you'll have to provide the full error log on a pastebin.
Apr 02 14:01:58 <qschulz> LetoThe2nd: what is weird is the error message. Usually you get "Nothing RPROVIDES python3-pyueye", not "no match for argument"
Apr 02 14:02:12 <LetoThe2nd> qschulz: yup. but stranger things have happened too.
Apr 02 14:02:57 <qschulz> clementp[m]: and what if you put by yourself the IMAGE_INSTALL_append = " python3-pyueye" in your conf/local.conf, without the build script?
Apr 02 14:03:34 <clementp[m]> https://pastebin.com/7s7yk9Wp
Apr 02 14:05:09 * clementp[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/jbcVuLlsOqKuYEJZFHMiIekN >
Apr 02 14:05:35 <clementp[m]> maybe should have change to +=
Apr 02 14:06:51 <qschulz> clementp[m]: nope :) https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-IMAGE_INSTALL
Apr 02 14:06:55 <qschulz> look in the grey box
Apr 02 14:06:55 <kroon> clementp[m], which packages are prodiuced when you bitbake the recipe ?
Apr 02 14:06:57 <LetoThe2nd> clementp[m]: well technically the IMAGE_INSTALL_appen is wrong anyways, if you insist on the local.conf you shouls use CORE_IMAGE_EXTRA_INSTALL. or better, create a custom image.
Apr 02 14:07:39 <qschulz> LetoThe2nd: both are okay? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/images/core-image-minimal.bb#n3
Apr 02 14:08:20 <clementp[m]> I'm building from core-image-minimal the error occurs during the "do_rootfs"
Apr 02 14:09:02 <LetoThe2nd> kroon: yup, next thing to check.
Apr 02 14:09:20 <LetoThe2nd> clementp[m]: bitbake -e your recipe and look at what is in PACKAGES
Apr 02 14:11:07 * clementp[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/InnjeKcpSOXPlYEEvWxIMCCZ >
Apr 02 14:11:28 <LetoThe2nd> qschulz: sure, but the key point is that many mess up with the eval order of IMAGE_INSTALL therefore CORE_IMAGE_EXTRA_INSTALL is safe
Apr 02 14:11:49 <LetoThe2nd> clementp[m]: can't you just log in properly? i'm really tired of having to read you in the browser.
Apr 02 14:14:51 <clementp[m]> LetoThe2nd: sorry don't understand what you mean...  Maybe it's my matrix client client that's doing weird things.
Apr 02 14:15:21 <LetoThe2nd> clementp[m]: yep. we only get "has sent a long message and then a random link".
Apr 02 14:15:59 <clementp[m]> Ok sorry for that ☹︎, Good to know
Apr 02 14:17:31 <clementp> # $PACKAGES [2 operations]#   set /home/<company>/<board>-build-script/<board>-release-bsp/sources/poky/meta/conf/bitbake.conf:286#     "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"#   set /home/<company>/<board>-build-script/<board>-release-bsp/sources/poky/meta/conf/documentation.conf:316#     [doc] "The
Apr 02 14:17:32 <clementp> list of packages to be created from the recipe."# pre-expansion value:#   "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"PACKAGES="defaultpkgname-dbg defaultpkgname-staticdev defaultpkgname-dev defaultpkgname-doc defaultpkgname-locale  defaultpkgname"
Apr 02 14:18:28 <LetoThe2nd> yeah but what actually ends up inside? and what is PN?
Apr 02 14:19:04 <clementp> PACKAGES="defaultpkgname-dbg defaultpkgname-staticdev defaultpkgname-dev defaultpkgname-doc defaultpkgname-locale  defaultpkgname"
Apr 02 14:19:15 <LetoThe2nd> that sounds wrong.
Apr 02 14:19:33 <clementp> Ok understood I did bitbake -e
Apr 02 14:19:43 <clementp> instead of bitbake -e <IMAGE>
Apr 02 14:19:54 <LetoThe2nd> bitbake -e your recipe.
Apr 02 14:20:23 <LetoThe2nd> like i said: 14:09 < LetoThe2nd> clementp[m]: bitbake -e your recipe and look at what is in PACKAGES
Apr 02 14:20:37 <clementp> PACKAGES=""
Apr 02 14:20:51 <clementp> It's empty
Apr 02 14:21:10 <LetoThe2nd> clementp[m]: so your recipe, for whatever reason, does not provide any packages. hence nothing can be installed. thats your debugging start, then.
Apr 02 14:22:49 <clementp[m]> this was for the <Image> for python3-ueye:
Apr 02 14:22:52 <clementp[m]> PACKAGES="python3-pyueye-dbg python3-pyueye-staticdev python3-pyueye-dev python3-pyueye-doc python3-pyueye-locale  python3-pyueye"
Apr 02 14:26:13 <LetoThe2nd> something is fihy there and i can't put my finger on it.
Apr 02 14:31:32 <clementp[m]> will retry for clean build :(
Apr 02 14:36:28 <qschulz> clementp[m]: bitbake -e python3-pyueye returns PACKAGES="python3-pyueye-dbg python3-pyueye-staticdev python3-pyueye-dev python3-pyueye-doc python3-pyueye-locale  python3-pyueye" right?
Apr 02 14:36:40 <clementp[m]> yes
Apr 02 14:36:58 <qschulz> clementp[m]: the next thing you can do is look into tmp/deploy/packages/*/ and look if there are python3-pyueye packages in there
Apr 02 14:37:31 <qschulz> then if there is a python3-pyueye package, inspect it to check if there;s something in it?
Apr 02 14:38:15 <qschulz> also, if there's no specific need for rpm packages, you can use ipk packages instead, those are more tested IIRC (and if it works, at least we know there is an issue with rpm packages for this recipe and maybe something to fix)
Apr 02 14:40:50 <clementp[m]> Actually I don't need packages at all
Apr 02 14:41:27 <LetoThe2nd> qschulz: rpm is the poky default and should be fine, deb is more of a problem child.
Apr 02 14:42:41 <qschulz> clementp[m]: you do :) that's how Yocto creates the rootfs ;)
Apr 02 14:43:24 <qschulz> clementp[m]: so, any package in tmp/deploy/rpm?
Apr 02 14:43:32 <qschulz> LetoThe2nd: ack
Apr 02 14:43:34 <clementp[m]> qschulz: Ok I thought it was intented for people maintaining a repo
Apr 02 14:43:45 <clementp[m]> rebuild in progress
Apr 02 14:43:50 <clementp[m]> should take around 20min..
Apr 02 14:44:22 <qschulz> clementp[m]: that is possible as well. Ah you cleaned everything?
Apr 02 14:45:27 <clementp[m]> Someone decide to build a 5-7K€ machine with 2xXeon Gold but I have a simple fucking HDD optimized for low-comsuption -_-
Apr 02 14:45:47 <clementp> Yes i have rm -rf the output build folder,
Apr 02 14:46:10 <qschulz> clementp[m]: or try to build in RAM :)
Apr 02 14:46:37 <qschulz> have the sstate-cache and dl_dir on your HDD, the rest in RAM, that's what I do
Apr 02 14:47:16 <qschulz> but depending on the amount of RAM per CPU core you have, you might have to tweak the number of parallel builds to not go OOM
Apr 02 14:47:44 <LetoThe2nd> if you have enough ram the hdd shouldn't really matter anyways, thats my experience
Apr 02 14:48:04 <qschulz> LetoThe2nd: if you have the workdir on the hdd.....
Apr 02 14:48:38 <LetoThe2nd> qschulz: caching takes care of that. sure, not 100%, but the difference was neglectable in my tests.
Apr 02 14:50:22 <clementp> 32GB per CPU i think
Apr 02 14:51:25 <LetoThe2nd> clementp[m]: then the hdd really doesn't matter that much.
Apr 02 14:52:04 <rburton> clementp[m]: inherit rm_work so build tree are deleted, and change the commit timeout on the filesystem. recipe can be built and deleted before it even touches the disk.
Apr 02 14:52:21 <qschulz> LetoThe2nd: I also don't want to clutter my HDD, (I started with a 250GB SSD which was full pretty quick with 5 machines and different projects :) ). So now, everything in RAM and I safely remove everything when I want or when I reboot :)
Apr 02 14:53:06 <LetoThe2nd> qschulz: of course, YMMV. i am always talking about my personal experience
Apr 02 14:53:29 <qschulz> LetoThe2nd: same same hi5
Apr 02 14:54:23 <LetoThe2nd> lo5
Apr 02 14:54:42 <LetoThe2nd> fistbump
Apr 02 14:54:42 <qschulz> LetoThe2nd: :o leaving me hanging like this how dare you
Apr 02 14:55:03 <LetoThe2nd> nah, thats what i teach my kids. hi5 - lo5 - fistbump. in that order.
Apr 02 14:55:05 <qschulz> LetoThe2nd: true. social distancnig, even on IRC. Good. Then, namaste
Apr 02 14:55:16 <clementp> rburton already the case echo "INHERIT += \"rm_work\"" >> conf/local.conf
Apr 02 14:55:47 <clementp> What is the commit timeout ?
Apr 02 14:56:31 <qschulz> clementp[m]: IIUC from context, the time when your system takes files in RAM and put it on the disk
Apr 02 14:56:37 <qschulz> RAM/cache
Apr 02 14:58:12 <qschulz> you lower that time, more writes and you kill your disk faster but safe data. you increase that time, healthy hdd but data is lost if powercut between "commits" (well same for first case, but you increase the chance of this happening)
Apr 02 14:58:30 <qschulz> I'll let rburton confirm or throw me by the window for my wrong explanations :)
Apr 02 14:58:47 <clementp[m]> In /etc/fstab
Apr 02 14:59:52 <qschulz> clementp[m]: that's not important at the moment :) let's tackle your issue first
Apr 02 14:59:54 <clementp[m]> UUID=cf146c17-43b0-47c0-b971-86a3c1d689e4 / ext4 defaults 0 0
Apr 02 14:59:54 <clementp[m]> =>
Apr 02 14:59:54 <clementp[m]> UUID=cf146c17-43b0-47c0-b971-86a3c1d689e4 / ext4 commit=1000  0 0
Apr 02 15:00:53 <clementp[m]> 24 running task (2865 of 3565)
Apr 02 15:01:42 <qschulz> you need more CPU
Apr 02 15:02:56 <clementp[m]> This machine is so badly configured :(
Apr 02 15:03:49 <clementp[m]> Epyc with PCIe SSD is on it's way
Apr 02 15:03:57 <clementp[m]> and it's cheaper than this one
Apr 02 15:04:29 <qschulz> clementp[m]: I was joking :) I have 32GBof RAM and 12 cores it's good enough for my everyday builds. We have a big one for releases or jenkins
Apr 02 15:04:50 <qschulz> clementp[m]: yeah, AMD new CPUs are dirt cheap for build machines compared to the Intel ones
Apr 02 15:05:54 <clementp[m]> Yeah and there "Turbo Boost" is just marketing shit, after 20sec you go back to the base clock
Apr 02 15:06:13 <clementp[m]> AMD cache and clock is insane for the price
Apr 02 15:13:41 <clementp> qschulz still same error : do_rootfs: Could not invoke dnf No match for argument: python3-pyueyeError: Unable to find a match
Apr 02 15:14:18 <qschulz> any package in tmp/deploy/rpm/ named python3-pyeuye?
Apr 02 15:14:24 <clementp> I past again the bb
Apr 02 15:14:26 <clementp> SUMMARY =  "pyueye"DESCRIPTION = "pip3 install pyueye"HOMEPAGE = "https://pypi.org/project/pyueye/"LICENSE = "BSD-3-Clause"LIC_FILES_CHKSUM = "file://PKG-INFO;md5=d93c89ef0026a2ecf28a6a7bea9d1062"SRC_URI[md5sum] = "0398e0d39d241921a8290b5c891f0e63"SRC_URI[sha256sum] = "54c389176d359259c930f22035f1c006df37b4be9a71954a7fa864d679adc3a4"PYPI_PACKAGE =
Apr 02 15:14:27 <clementp> "pyueye"PYPI_PACKAGE_EXT = "zip"inherit pypiBBCLASSEXTEND = "native nativesdk"
Apr 02 15:14:34 <clementp> just in case it had been cropped with Matrix client
Apr 02 15:15:06 <clementp> python3-pyueye-dbg-4.90.0.0-r0.aarch64.rpm  python3-pyueye-dev-4.90.0.0-r0.aarch64.rpm
Apr 02 15:15:09 <clementp> in aarch64
Apr 02 15:15:44 <clementp> around 6kB
Apr 02 15:16:16 <JaMa> anyone seeing "ERROR: kmod-26-r0 do_package: Can NOT get PRAUTO, exception No module named '_sysconfigdata'" with latest master (and python-3.8 from e.g. ubuntu 20.04)?
Apr 02 15:16:58 <qschulz> clementp: and no python3-pyueye-4.90.0.0-r0.aarch64.rpm?
Apr 02 15:17:47 <clementp[m]> no
Apr 02 15:17:49 <clementp[m]> only dbg or dev
Apr 02 15:18:01 <qschulz> clementp[m]: there you go, no package for you, Yocto is not happy :)
Apr 02 15:18:21 <qschulz> clementp[m]: bitbake -c install python3-pyueye
Apr 02 15:19:13 <qschulz> go to your workdir for this recipe (something like tmp/work/*/python3-pyueue/4.90.0.0-r0)
Apr 02 15:20:04 <qschulz> clementp[m]: check the files in image/ what are the paths?
Apr 02 15:20:35 <qschulz> clementp[m]: a "normal" package has the files defined in FILES_${PN}
Apr 02 15:20:58 <qschulz> there might be some trickery done by pypi bbclass but that I can't help with :/
Apr 02 15:21:49 <qschulz> so basically, you have to find a way to make the files move from your dbg or dev package to your normal package by tinkering with your recipe (and possibly FILES_${PN} or some flags passed during the install task)
Apr 02 15:24:48 <clementp[m]> qschulz: the path for images is build_imx8qm/tmp/deploy/images/imx8qm-<board>
Apr 02 15:25:18 <clementp[m]> ha sorry you mean when I rebuild the package
Apr 02 15:25:46 <qschulz> yup
Apr 02 15:34:00 <clementp> qschulz ./aarch64-poky-linux/python3-pyueye/4.90.0.0-r0/deploy-rpms/aarch64/python3-pyueye-dbg-4.90.0.0-r0.aarch64.rpm
Apr 02 15:34:17 <clementp> ./aarch64-poky-linux/python3-pyueye/4.90.0.0-r0/deploy-rpms/aarch64/python3-pyueye-dev-4.90.0.0-r0.aarch64.rpm
Apr 02 15:38:22 <qschulz> clementp: ./aarch64-poky-linux/python3-pyueye/4.90.0.0-r0/image what's in there
Apr 02 15:39:29 <clementp> nothing
Apr 02 15:40:51 <yocti> New news from stackoverflow: bitbake do_package corrupts *.pc files for libqb <https://stackoverflow.com/questions/60995214/bitbake-do-package-corrupts-pc-files-for-libqb>
Apr 02 15:44:42 <qschulz> ls -lah ./aarch64-poky-linux/python3-pyueye/4.90.0.0-r0/ ? have you done bitbake -c install python3-pyueue and not just bitbake python3-pyueue?
Apr 02 15:51:35 <clementp> drwxr-xr-x   4096 Apr  2 16:58 deploy-rpmsdrwxr-xr-x   4096 Apr  2 17:19 imagedrwxrwxr-x   4096 Apr  2 17:19 pseudodrwxr-xr-x   4096 Apr  2 17:19 pyueye-4.90.0.0drwxrwxr-x   4096 Apr  2 17:19 recipe-sysrootdrwxrwxr-x   4096 Apr  2 17:19 recipe-sysroot-nativedrwxrwxr-x   4096 Apr  2 17:19 sstate-install-package_write_rpmdrwxrwxr-x  12288 Apr  2
Apr 02 15:51:35 <clementp> 17:41 temp
Apr 02 15:52:18 <clementp> I can rm this folder and redo thecommand
Apr 02 15:54:16 <clementp> empty
Apr 02 15:55:43 <clementp> bitbake -c clean python3-pyueye
Apr 02 15:55:51 <clementp> bitbake -c install python3-pyueye
Apr 02 15:56:06 <clementp> python3-pyueye/4.90.0.0-r0/image folder is empty
Apr 02 15:56:59 <clementp> the log do_install doesn't show the python package
Apr 02 15:57:54 <clementp> do_install() {    base_do_install}base_do_install() {        :}
Apr 02 16:06:33 <qschulz> clementp: inherit pypi distutils3
Apr 02 16:09:12 <clementp> | DEBUG: Executing shell function do_compile| Traceback (most recent call last):|   File "setup.py", line 41, in <module>|     from setuptools import setup| ImportError: No module named 'setuptools'| ERROR: python3 setup.py build_ext execution failed.
Apr 02 16:09:44 <clementp> setuptools ?
Apr 02 16:10:03 <qschulz> clementp: my absence of knowledge in python module building is showing a little bit too much :)
Apr 02 16:10:08 <clementp> ok
Apr 02 16:10:12 <clementp> Same for me :(
Apr 02 16:10:14 <clementp> i will try
Apr 02 16:10:21 <clementp> thank you very much for your help
Apr 02 16:10:37 <qschulz> clementp: you need to find some sort of make install but for your python module
Apr 02 16:11:15 <qschulz> have you checked that other tasks have done at least something, unlike install?
Apr 02 16:12:17 <clementp> they are using setuptools
Apr 02 16:12:29 <clementp> but I think the setup.py provide by the vendor doesn't compile...
Apr 02 16:12:35 <clementp> or doesn't setup...
Apr 02 16:12:42 <clementp> I will try to patch it
Apr 02 16:14:55 <clementp> qschulz  are you from bootlin ?
Apr 02 16:15:06 <qschulz> clementp: not anymore
Apr 02 16:16:09 <clementp> Hoooo sad, but thank you very much anyway, I read 2 years ago your presentation on secure boot when I need to implement one, was very clear and instructive
Apr 02 16:17:08 <clementp> Haa I see you are at StreamUnlimited
Apr 02 16:17:23 <clementp> they implement streaming for Google Cast ;à
Apr 02 16:17:26 <qschulz> clementp: thanks, much appreciated :)
Apr 02 16:17:36 <qschulz> clementp: indeed they do, well not only that but they do that yes :)
Apr 02 16:19:57 <matthewzmd> can anyone tell me how to run the demos in meta-qt5/recipes-qt/examples?
Apr 02 16:20:49 <clementp> qschulz  had to do the secure boot for this application, funny loop :)
Apr 02 16:22:23 <clementp> but make sense because I suppose that now you implement secure boot for their customer
Apr 02 16:24:02 <qschulz> clementp: that's part of the package yes. But once it's done, it's done, not much more to do :) It was done before I arrived at StreamUnlimited so didn't touch it (well, i recently broke it BUT that's not the question :D)
Apr 02 16:24:30 <qschulz> matthewzmd: add the qt example to the packages installed by your image recipe, boot your image, execute the binary?
Apr 02 16:55:47 <clementp> qschulz: Thanks it works, I added "inherit pypi setuptools3" and patch the setup.py. No it's included in the rootfs :)
Apr 02 17:00:14 <JPEW> RP: OK, I think I know why that SDE failure is occuring, but I have no idea what to do about it
Apr 02 17:01:39 <JPEW> RP: It looks like when you use multilib, it finalizes the datastore for both the base recipe *and* the virtual recipe (might be butchering the term here)
Apr 02 17:02:21 <JPEW> RP: The base recipe finalization is the one that races with the simultaneous execution of the non-base recipe
Apr 02 17:03:03 <JPEW> RP: I have some logging that makes the very apparent if you want to see it for yourself
Apr 02 17:04:31 * JPEW wonders if we can tell this is happening when attempting to extra the SDE....
Apr 02 17:07:37 <RP> JPEW: oh, interestiong
Apr 02 17:07:49 <RP> JPEW: it will do both as it won't know which one it needs
Apr 02 17:07:55 <JPEW> Right
Apr 02 17:08:45 <JPEW> You could possibly push BBEXTENDVARIANT and BBEXTENDCURR down into the the finalization to make it only parse the one it needs?
Apr 02 17:10:43 <JPEW> Or.... make virtual:multilib:X:do_unpack depend on do_unpack .... not great
Apr 02 17:15:03 <JPEW> Anyway, I have to make my weekly venture for groceries and watch the kids now... I'll think about it and be back tomorrow.
Apr 02 17:16:13 <RP> JPEW: I think we did already add a mechanism to do it, its just not being used from bitbake-worker most likely
Apr 02 17:17:21 <RP> JPEW: I worry we have to expand BBCLASSEXTEND with the base datastore :/
Apr 02 17:17:39 <RP> ie. without expanding the base datastore we might not know which extensions we have
Apr 02 17:41:19 <yocti> New news from stackoverflow: Building dependencies in yocto for GO language project <https://stackoverflow.com/questions/60997241/building-dependencies-in-yocto-for-go-language-project>
Apr 02 18:04:07 <bri> Hiho!  Is it possible to include ${S} in SRC_URI?  For example: SRC_URI += " file://foo.c;subdir=${S}/somedir"
Apr 02 18:05:04 <bri> When I do so, I get a python RecursionError in bitbake.  Is there another way to achieve the above?
Apr 02 18:05:18 <neverpanic> subdir=somedir should do the same thing, the paths are relative to $S
Apr 02 18:05:43 <bri> path is relative to ${WORKDIR}.  At least that's where it's putting it.
Apr 02 18:07:02 <bri> In my case, S is the git subdir or WORKDIR.  So, I can just add "git" is the place of ${S} above, but I'd prefer to do it in a way that doesn't break if S changed.
Apr 02 18:07:29 <bri> ... git subdir OF WORKDIR, I mean
Apr 02 18:09:35 <JPEW> RP: Had an idea: https://lists.openembedded.org/g/openembedded-core/message/136961
Apr 02 18:10:02 <JPEW> RP: Did some initial test and it appears to work as expected, but now I *really* do need to go :)
Apr 02 20:19:19 <armpit> is anyone else not able to connect to github ?
Apr 02 20:21:02 <tgamblin> armpit: working for me, a little slow though
Apr 02 20:21:42 <armpit> yeah.. slow. my git pull failed twice.. thanks for responding
Apr 02 20:40:05 <RP> JPEW: I think I have something
Apr 02 20:41:53 <yocti> New news from stackoverflow: QtCreator Static Analyzer is failing on yocto "gnu/stubs-soft.h" is missing <https://stackoverflow.com/questions/60756453/qtcreator-static-analyzer-is-failing-on-yocto-gnu-stubs-soft-h-is-missing>
Apr 02 20:42:39 <RP> JPEW: have sent it out, its a totally different way of potentially solving it
Apr 02 21:46:16 <dp> Hi all. Is there a default variable existing in Yocto that lets me tell it to ignore any SSTATE_MIRRORS set in local.conf, and/or any way I can globally disable sstate cache?
Apr 02 21:46:55 <dp> I'm looking at running a "build reproducibility" job to prove that I can rebuild without sstate cache
Apr 02 21:47:18 <dp> Wanted to check here if there's already a var/config for this rather than creating my own in local.conf
Apr 02 22:05:13 <zibri> dp: there's a --no-setscene flag that tells bitbake not to consider sstate objects
Apr 02 22:06:18 <RP> dp: why not just clear SSTATE_MIRRORS?
Apr 02 22:07:00 <dp> Yeah, that's what I'll do if there's no existing flag. I can just conditionally set SSTATE_MIRRORS in the default local conf, based on the value of an env var
Apr 02 22:07:41 <RP> dp: SSTATE_MIRRORS_forcevariable = ""
Apr 02 22:07:58 <RP> dp: zibri is probably right about the commandline option
Apr 02 22:08:03 <dp> Oh TIL about _forcevariable
Apr 02 22:08:24 <RP> dp: its just an OVERRIDE
Apr 02 22:08:33 <dp> zibri, Thanks, the description for that looks perfect
Apr 02 22:37:11 <dp> Heh. Looks like we had a regression anyway - pipeline was already exporting SSTATE_MIRRORS='' before calling bitbake but some smarty pants decided to change from `?=` to `=` in the template local conf 😃
Apr 02 22:37:36 <dp> I'll use the flag too, for extra surety though :)
Apr 02 22:41:07 <neverpanic> Oh, and if you're playing around with env variables, make sure to look at BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE, and do ensure those don't creep into the sstate cache hashes or you'll end up not using the sstate cache, but not for the reasons you might think…
Apr 02 22:41:36 <neverpanic> We've been there before with an LD_PRELOAD of libeatmydata.so
Apr 02 22:49:00 <dp> hahaha thanks
Apr 03 00:54:34 <moto-timo> RP: next round of docs changes (especially install-buildtools and buildtools-extended-tarball) inbound
**** ENDING LOGGING AT Fri Apr 03 02:59:56 2020