<splatch>
hey, here I am back with same trouble as before, a failed intel-microcode update during the build. I have no clue why this happens, but it did work before with warrior (I haven't made any changes in this part, except rising meta-intel layer version). I keep getting exit code '2'.
<splatch>
Writing selected microcodes to: /build/tmp/work/corei7-64-intel-common-connectorio-linux/intel-microcode/20210608-r0/microcode_20210608.bin
<splatch>
/build/tmp/work/corei7-64-intel-common-connectorio-linux/intel-microcode/20210608-r0/microcode_20210608.bin: error while flushing file data: Input/output error
rob_w has quit [Ping timeout: 258 seconds]
<splatch>
is my hard drive corrupted ?
rob_w has joined #yocto
manuel1985 has joined #yocto
frieder has joined #yocto
leon-anavi has joined #yocto
florian has joined #yocto
ilunev has joined #yocto
ilunev has quit [Client Quit]
<splatch>
filesystem check done, doing clean build once again
<rburton>
Looks like the disk is failing, check smart status
<splatch>
could be, I have nvme+f2fs setup from 2016 which proven to be very fast but also a bit fragile on power drops. Anyhow fsck reported no errors and I see no issues with microcode. Now I am back to host contamination on a fresh build. I have feeling this is going to be a long day.
<splatch>
> Currently 2 running tasks (3656 of 3685) 99%
<timbert[m]>
Hey! Is there a way to use project version from CMake inside a bitbake recipe (without writing a parser for CMakeLists.txt 😉 )?
<LetoThe2nd>
timbert[m]: use what for?
<timbert[m]>
<LetoThe2nd "timbert: use what for?"> I want to use the project version from CMake as PV variable
<LetoThe2nd>
timbert[m]: in that case, no.
<LetoThe2nd>
timbert[m]: how would bitbake obtain it without fetching source?
<timbert[m]>
<LetoThe2nd "timbert: how would bitbake obtai"> You are right, it can not get the version without the sources. But maybe there is a way of lazy evaluation to set PV after fetching the sources.
<LetoThe2nd>
timbert[m]: nope.
<timbert[m]>
<LetoThe2nd "timbert: nope."> I was able to set PV from a plain text file located at the source code, but I found no way to do this with cmake.bbclass
<qschulz>
timbert[m]: how?
<LetoThe2nd>
timbert[m]: you can happily set the pv inside the recipe to whatever you want, but once it relies on the source being present its an outright bug. no way discussing that away.
<LetoThe2nd>
timbert[m]: and even worse, if it includes actually executing code you are effectively breaking reproducibility. so you might have a hack that works for your one usecase, ok. but this is not the general design of things, and it is explicitly unsupported.
<rburton>
so you *can* set PKGV during the build but you need to set PV before the build, so you don't really gain anything
<LetoThe2nd>
qschulz: i guess by having the source not fetches seperately but shipped next to the recipe, or something similar.
<LetoThe2nd>
e.g. source+metadata conglomeration
<rburton>
in that world, setting PKGV would make sense
<timbert[m]>
<LetoThe2nd "qschulz: i guess by having the s"> Excatly. I have layers and source code as submodules.
<timbert[m]>
> <@LetoThe2nd:libera.chat> qschulz: i guess by having the source not fetches seperately but shipped next to the recipe, or something similar.
<timbert[m]>
* Exactly. I have layers and source code as submodules.
<LetoThe2nd>
*shrug*
<rburton>
you still need to parse the cmakefile though
<rburton>
unless cmake can tell you what the version is
<LetoThe2nd>
in which case you would have a hidden dependency on cmake during parse time.
<rburton>
no, you can set PKGV later
<rburton>
in a do_package prefunc
<LetoThe2nd>
rburton: but how does this relate to PV? how could i do a PREFERRED_VERSION if the version is not even known until the packaging is finished?
<rburton>
you still need a PV for the recipe
<rburton>
but that can be 1.0
<rburton>
during the build PKGV can be set to the real version
<rburton>
PREFERRED_VERSION will only look at PV, that's the compromise
<LetoThe2nd>
so PKGV is actually only put into the package for the stream? no idea why i would want that.
vmeson has quit [Ping timeout: 240 seconds]
<rburton>
yeah
<rburton>
i doubt its actually used much, but you might want to mangle versions
prabhakarlad has quit [Ping timeout: 246 seconds]
<rburton>
nothing in core at least explicitly uses it, it all relies on the default (which is obviously PV)
<LetoThe2nd>
i can see it being useful for some forms of distribution management where you feed package repositories, but certainly not for orchestrating an image build.
<rburton>
so in meta-oe there's a gitpkgv.bbclass which lets you have ugly PV but rewrite PKGV to include tag names
<rburton>
but i *think* the bulk of that logic is in core now anyway?
<LetoThe2nd>
rburton: good luck with that (thinking)
vmeson has joined #yocto
hpsy has quit [Quit: Leaving.]
Falital has joined #yocto
<qschulz>
rburton: and would Yocto use that PKGV for version-specific RDEPENDS?
<qschulz>
rburton: RDEPENDS_${PN} = "package (operator version)" is what I'm talking about
<BuZZ-T>
is anyone here using eclipse for development in the "pre Eclipse Yocto Plugin" era?
<BuZZ-T>
eh.. i mean in the "post Eclipse Yocto Plugin" era :)
camus1 has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus has joined #yocto
rob_w has quit [Ping timeout: 272 seconds]
camus1 has quit [Ping timeout: 252 seconds]
bizulk has joined #yocto
<bizulk>
Hello. I have an issue building for raspberry pi 1 (host x86_64 ubuntu 20) : task poky/meta/recipes-devtools/gcc/gcc-cross_11.1.bb:do_compile
<bizulk>
I have a lot of undefined reference like this one : build-rpi/tmp/hosttools/ld: lto-lang.c:(.text+0x3279): undefined reference to `builtin_info'
rob_w has joined #yocto
BuZZ-T has quit [Quit: BuZZ-T has left the building...]
BuZZ-T has joined #yocto
Schlumpf has quit [Quit: Client closed]
<bizulk>
I am using master branch
bizulk72 has joined #yocto
bizulk has quit [Ping timeout: 246 seconds]
xmn has quit [Quit: ZZZzzz…]
<bizulk72>
there is a tip that I would like to test : "build glibc without static PIE support", but how can I do that
crawler has quit [Remote host closed the connection]
lukma has joined #yocto
<splatch>
BuZZ-T: I don't do any C stuff, so I am set with regular text editor. If you need debuging capabilities I believe you have all necessary tools in Eclipse CDT. I am not sure what yocto plugin used to do as information available online is fairly limited.
<lukma>
Dear All, I do have the question regarding 'uninative'. As fair as I see, by default (in the poky.conf) require conf/distro/include/yocto-uninative.inc is inherited. Moreover, I do know that for eSDK this uninative is used to build its "host" tools. I do have a question then - is this libc version used also for "normal" built of -native packages for using bitbake ?
<lukma>
but with eSDK wrapped to OCI container :-)
<lukma>
he/she just runs it from there
<RP>
lukma: right, the above open bug?
<lukma>
RP: Yes, this is the bug
<RP>
lukma: if you run your build of the eSDK in the container environment, the eSDK should then work in that container environment even with the above bug
<RP>
or help us fix the above bug...
<lukma>
RP: I also thought about the workaround: Create OCI container with Poky for x86_64
<lukma>
then in the bitbake recipe run this container with bindings to the yocto build directories
<lukma>
execute the bitbake populate_sdk_ext
<lukma>
(so it would use the sysroot + -native stuff from the OCI container)
<lukma>
and then install it with the installer
<lukma>
the questions are as follows:
<lukma>
1. Will bitbake allow/correctly handle running container it ist task (like "build" task) ?
<lukma>
2. Have anybody tried to use --bind container option with bitbake?
<RP>
lukma: bitbake will run in a container fine. Just don't try and run bits of the build in the container and bits outside
<RP>
and I do think certain bind mount options will cause problems due to the way bitbake uses the filesystem. Exactly what issues those are I don't know, mostly related to copy-on-write
<rburton>
fwiw, the crops container guide explicitly says to bind your build directory into the container
<lukma>
RP: Do you have any idea how and if it would be possible to add OCI container (as a "skin") to yocto/OE build ?
<lukma>
IMHO I would also need to "wrap" in some way bitbake populate_sdk_ext into the OCI container (bo build it into it and install)
<lukma>
that would solve this problem
<RP>
lukma: it would be way easier just to fix pseudo ;-)
<lukma>
and as a result I would have the OCI container with eSDK built inside it and it installed.
<lukma>
RP: Maybe you are right :-) I will look into the bug report ...
<lukma>
but I need a backup plan
<rburton>
lukma: core-image-base, also make it depend on the populate_sdk_ext task, then in a rootfs-post-process install the eSDK into it
<rburton>
easy
camus has quit [Ping timeout: 258 seconds]
<lukma>
RP: But this bug has "High major" Importance....
prabhakarlad has joined #yocto
<RP>
lukma: right, we're aware this is a major problem and I'm going to need to try and fix it
<RP>
lukma: it was reasigned to me yesterday as there is nobody else to work on it (or any other esdk bug)
<lukma>
RP: So you are the "one" :)
<qschulz>
rburton: and now I'm quite confused. What's the difference between pyrex and kas-container then :D ?
<rburton>
qschulz: well kas-container comes with kas built in :)
<RP>
lukma: I'm more than a little frustrated and saddened we have nobody working on the esdk :(
<lukma>
RP: From my perspective - eSDK is the first tool, which is seen by developer
<lukma>
externa or internal
<RP>
lukma: well, yes. Hence my feelings on the subject. How do we encourage people to help though?
<paulg>
bribes?
<RP>
paulg: wish I had the capability :)
<qschulz>
rburton: that I figured, but I'm not using kas yet, thus I'm more interested in what makes them different outside of kas :p
<rburton>
can the LF stump up £100 to anyone who sends a merged patch that fixes it :)
<rburton>
qschulz: i imagine, pyrex/kas/crops containers are all 99% identical (just the build deps), it's the little bit of glue that makes them different
jwillikers has joined #yocto
<RP>
ndec: could we have bug bounties? :)
<RP>
rburton: would be YP itself rather than the LF, no idea if we could so that
<BuZZ-T>
splatch: the yocto plugin provided a convient way to create autotools, cmake and make file projects from eclipse. It has setup the correct PATH a.s.o. to build/deploy and debug the binaries generated in eclipse. Thats what it has done.
<BuZZ-T>
splatch: But I made a few steps in the right direction, i'm able to setup the automake projects using the eSDK way.. when eclipse started from a "sourced" sdk environment, then the build and debug with is working with a few tweaks.
<BuZZ-T>
its not what our devs were used to too, but at least i know that eclipse is generally usable.
<RP>
rburton: did you work out why parted was intermittent?
goliath has joined #yocto
rob_w has quit [Ping timeout: 255 seconds]
<rburton>
RP: no, didn't look. need a better way to mine the ptest logs
rob_w has joined #yocto
<paulg>
zeddii, if you are bored, you can probably nuke v5.10/standard/base-aufsv2 and v5.10/standard/base-noaufs ; we don't need them polluting the branch namespace, or reminders of that LTP/cgroup horror.
<yates>
if i set BBFILES = "${TOPDIR}/*", does that mean .bbappend files of any base name will be incorporated from any level directory, recursively, under ${TOPDIR}?
<rburton>
no
<yates>
what is the syntax to specify that?
<yates>
oh wait
<yates>
i should be using ${LAYERDIR}
<rburton>
the idiom is BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
* paulg
needs to revisit the topic of nuking other old branch polluting cruft.
otavio has joined #yocto
<yates>
is BBFILES further constrained by BBFILE_PATTERN_{layer-name} in the layer's layer.conf file if it is present?
<yates>
i guess i really don't see the use in the BBFILE_PATTERN variable. the layer's BBFILS are already specified by BBFILES
<yates>
s/BBFILS/BBFILES/
<rburton>
no, pattern is the reverse lookup and idiom is just BBFILE_PATTERN_layername = "^${LAYERDIR}/"
<yates>
there aren't just arbitray questions. i have a layer.conf file with both BBFILES and BBFILE_PATTERN_blah (as well as BBFILE_COLLECITONS and BBFILE_PRIORITY_blah)
<yates>
arbitrary
<rburton>
good
<rburton>
you need all of those
<yates>
ok, so what is their perpose/meaning?
<yates>
sheesh. can't type today (or spell)
<rburton>
BBFILES is "this is the glob to find files to parse"
<rburton>
so the idiom is BBFILES += "${LAYERDIR}/recipes-*/*/*.bb"
<rburton>
erm, and *.bbappend
<yates>
right
<yates>
what about BBFILE_PATTERN_blah?
<rburton>
BBPATTERN is the reverse for finding the layer of an arbitrary file, because this stuff grew organically
<rburton>
the idiom is eg BBFILE_PATTERN_core = "^${LAYERDIR}/"
LetoThe2nd has quit [Quit: Connection closed for inactivity]
dvorkindmitry has joined #yocto
<dvorkindmitry>
If I generate sdk with -c populate_sdk ... command, and then re-run it on another day, I got error "No such file or directory:... /locale". Because SDK links are reffering to old dir. How can I avoid this problem in dunfell?
Guest4 has joined #yocto
sakoman has joined #yocto
gjohnson has quit [Remote host closed the connection]
leo_sandoval has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
gjohnson has joined #yocto
<RP>
dvorkindmitry: is there some date reference in the path? Seems a little strange :/
<dvorkindmitry>
RP, there are! i my Distro.conf: SDK_VERSION = "${@d.getVar('DISTRO_VERSION')}"
gjohnson has quit [Remote host closed the connection]
<dvorkindmitry>
and DISTRO_VERSION = "3.1.2-${DATE}
<dvorkindmitry>
RP, sorry. forgot to show you DISTRO_VERSION="3.1.2-${DATE}
<RP>
dvorkindmitry: I suspect the best way forward is to find out why the rebuild doesn't work smoothly. Which task is failing? this is for the populate_sdk task right?
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
Neur0mante has joined #yocto
Neur0mante has quit [Client Quit]
Neur0mante has joined #yocto
Guest4 has quit [Quit: Client closed]
tnovotny has quit [Quit: Leaving]
<dvorkindmitry>
RP, right. I always get this problem rebuilding SDK on next day, case some of SDK directories are named with <DATE> and I need date in final file, but don't know how to regenerate date reference: https://pastebin.com/ZqCtdP2A
zyga-mbp has joined #yocto
<RP>
dvorkindmitry: since the sdk task is re-running, the next question to ask is where the date is being encoded that causes the problem such that a new run doesn't account for the new date
leon-anavi has quit [Quit: Leaving]
camus1 has joined #yocto
camus has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
florian has quit [Quit: Ex-Chat]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kroon>
mckoan|away, OutBackDingo, yes I've used Toradex Easy Installer, but I think its overly cumbersome.. unless I can skip the gui somehow and send the image over the SDP/USB link
<kroon>
thats why "uuu" looked interesting, but as I understand it I have to send first a specialzed u-boot with support, then the image I want to write
Neur0mante has quit [Read error: Connection reset by peer]
<kroon>
and I don't know where to get that specialized u-boot from
<kroon>
and I can't find a recipe for building uuu-native or mfgtools-native
<rburton>
question: do we want to support <500MB ext4 file systems which can't handle y2038 bugs
<rburton>
currently, file systems smaller than 500mb don't get big enough inodes for 64-bit times
<rburton>
very tempted to patch that down to 100mb or something ...
florian_kc has joined #yocto
xmn has joined #yocto
<kroon>
rburton, maybe not set inode size to 128 for "small"/"floppy"/"hurd" in e2fsprogs ? thats what I did as a workaround
<rburton>
yeah
<rburton>
was considering changing the cutoff for small to 100mb or something
<rburton>
but i just discovered that in wic we force all filesystems to be 'default', not small
<rburton>
so maybe just duplicate that in the bare file system creation?
nerdboy has quit [Remote host closed the connection]
<jordemort>
kroon: the u-boot you need for uuu is not actually that specialized, it just needs fastboot support compiled in
<jordemort>
i just use the u-boot.imx in tmp/deploy/images/${MACHINE} and i'm fine
<kroon>
jordemort, hmm ok, I tried that: "uuu -b emmc_all u-boot.imx image.wic" with no success
<jordemort>
so i save that as "script.uuu" and then run "uuu script.uuu"
<kroon>
jordemort, ok and you use yocto to build the mfgtools kernel and initramfs ?
<jordemort>
kroon: yep!
<kroon>
I can't build "fsl-image-mfgtool-initramfs" with MACHINE="colibri-imx7-emmc"
<kroon>
I get "u-boot-imx-mfgtool PROVIDES u-boot-mfgtool but was skipped: incompatible with machine colibri-imx7-emmc (not in COMPATIBLE_MACHINE)"
<kroon>
And "u-boot-fslc-mfgtool PROVIDES u-boot-mfgtool but was skipped: You cannot use UBOOT_MACHINE and UBOOT_CONFIG at the same time."
<jordemort>
hm not sure, i'm an imx7sabresd
<jordemort>
er imx7dsabresd
<kroon>
yeah im guessing toradex MACHINE's only cares about toradex easy installer support :-/
<jordemort>
yeah i'm not using those layers, just meta-freescale
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
vmeson has quit [Ping timeout: 255 seconds]
jmiehe has quit [Quit: jmiehe]
vmeson has joined #yocto
<perdmann_>
does, for example, {@urllib.parse.quote} automatically import urllib?
dtometzki has quit [Ping timeout: 265 seconds]
<jordemort>
can anyone help me understand the difference between itbImage and fitImage? itbImage also seems to be FIT
JaMa has quit [Quit: off]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
camus1 has joined #yocto
camus has quit [Ping timeout: 246 seconds]
camus1 is now known as camus
<RP>
perdmann_: sadly not
<perdmann_>
RP: so how do i know which modules are available and which not?
florian_kc has quit [Ping timeout: 252 seconds]
<RP>
perdmann_: basically os, sys and bb I suspect
<RP>
and oe
florian_kc has joined #yocto
<perdmann_>
RP: ok ....
Falital has quit [Quit: Connection closed]
v2d has joined #yocto
<v2d>
hi there -- I get an "do_rootfs: The postinstall intercept hook 'update_udev_hwdb' failed" error related to qemu-native when building from my CI. Seems to be related to RedHat derivated distros. Is it a known issue by any chance?
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
zyga-mbp has joined #yocto
Vonter has quit [Ping timeout: 272 seconds]
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kroon has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
florian_kc has quit [Ping timeout: 252 seconds]
jmiehe has joined #yocto
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
amitk has quit [Ping timeout: 272 seconds]
florian_kc has joined #yocto
<dvorkindmitry>
RP, are you there? sorry for the delay in answer
florian_kc has quit [Ping timeout: 255 seconds]
BuZZ-T has quit [Ping timeout: 272 seconds]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
<dvorkindmitry>
I have SDK_VERSION = "${@d.getVar('3.1.3-${DATE}')}", so when I build SDK on the next day, some directories of the SDK are not cleared amd refer to previous day (by name). How to clear SDK build and reassemble it again?
<dvorkindmitry>
there is no "cleanall/cleansstate" action inside "populate_sdk" action :)
jmiehe has quit [Quit: jmiehe]
jwillikers has quit [Remote host closed the connection]