<qschulz>
"You may use Windows Subsystem For Linux v2 to set up a build host using Windows 10, but validation is not performed against build hosts using WSLv2.
<qschulz>
The Yocto Project is not compatible with WSLv1, it is compatible but not officially supported nor validated with WSLv2, if you still decide to use WSL please upgrade to WSLv2.
xmn has quit [Ping timeout: 256 seconds]
xmn_ has joined #yocto
<qschulz>
since Kali is Debian based, it might just work but I've seen Pop os fail to be used on Stackoverflow questions even though it's based on Ubuntu
<rburton>
Amahnui: the one outreachy project we have this year is related specifically to FreeBSD, so you'll need to be running FreeBSD for that.
<Amahnui>
qschulz: Okay I'll install Ubuntu on my machine
<qschulz>
Amahnui: see what rburton just said above
<rburton>
for learning yocto to get started ubuntu is a good choice, but for the project itself you'll need freebsd.
<Amahnui>
rburton: Okay thank you I'll install FreeBSD rather
<Amahnui>
Thanks alot once more
<Amahnui>
Let me begin installing it right now
<Amahnui>
I'm really grateful 🙏
xmn_ has quit [Ping timeout: 246 seconds]
pasherring has joined #yocto
prabhakarlad has joined #yocto
xmn has joined #yocto
kroon has quit [Quit: Leaving]
xmn has quit [Ping timeout: 272 seconds]
Schlumpf has joined #yocto
michalkotyla has quit [Read error: Connection reset by peer]
<Schlumpf>
Hi, is there a simple way, to patch a Yocto config variable into a script source file?
<RP>
Does anyone have a deep knowledge of python threading, the GIL and signal handling?
<RP>
It looks like python intercepts signals and queues them for the main thread to process at some later date. Using pthread_sigmask therefore doesn't do what you expect as a python script using multiple threads may receive a signal in another thread, pass it to the main thread and raise it there despite SIG_BLOCK :/
michalkotyla has joined #yocto
<RP>
Saur[m]: ^^^ in case you wondered
<qschulz>
Schlumpf: you could use environment variables and pass those to the Yocto build?
<qschulz>
Schlumpf: BB_ENV_EXTRAWHITE from memory
xmn has joined #yocto
<Schlumpf>
qschulz: I need the other way. My recipe has contains a shell script to be installed to the image. This script needs to be patched with variables from a machine.conf file
<rburton>
RP: did a bit of CPE work, the lua cve will disappear next run
<RP>
rburton: thanks, I saw this week looked a bit of a mess :(
<rburton>
scared to look at the qemu one
<rburton>
s
pasherring_ has joined #yocto
pasherring has quit [Ping timeout: 245 seconds]
<sotaoverride>
Im a little lost with what Im seeing in the deploy folder, how is the rootfs growing 4 times when in et4 format? 1.4G Mar 25 18:07 Verdin-iMX8MM_opentrons-ot3-image.rootfs.ext4 235M Mar 25 18:09 Verdin-iMX8MM_opentrons-ot3-image-Tezi_0.0.1.tar
<rburton>
sotaoverride: because the ext4 has empty space in it
<rburton>
loopback mount it and see how much space is used, and how much is free
starblue has joined #yocto
<RP>
rburton: qemu ones look trivial to backport
<rburton>
yeah building now
<RP>
rburton: ah, cool :)
<barometz>
I have a weekly automated build that's supposed to update a local premirror, in which I echo `PREMIRRORS_prepend = ""` to local.conf to remove what own-mirrors.bbclass adds. This doesn't work (it's still downloading from the local premirror), presumably because I'm holding it wrong in some way. What's the right way to do this?
* RP
thinks with the updated patch on bitbake-devel, the parsing hangs should be better, as should the Ctrl+C handling when parsing
<rburton>
nice
<qschulz>
barometz: I assume your mirrors are added with PREMIRROS_prepend?
leon-anavi has joined #yocto
<qschulz>
and you want to remove them?
<barometz>
indirectly using own-mirrors.bbclass, yes.
<rburton>
barometz: all that does is add the empty string, it doesn't replace anything
<rburton>
INHERIT:remove = "own-mirrors" would be easier
<rburton>
well, you want _remove, but same thing
<qschulz>
barometz: you cannot undo _append/_prepend unless you use _remove
<rburton>
Amahnui: so the matrix irc bridge appears to be always-on (no missing backlog when you disconnect) and is free: https://app.element.io/#/room/#yoctoproject:matrix.org
<barometz>
alright, will try that, thanks. Figured I was misusing prepend (it looks as if it works differently from +=, but I don't think I ever read the bit of manual that really explains that)
<barometz>
excellent :) I'm leaving the project where I actually use Yocto this week, but this sounds like good reference material
shoragan[m] has quit [Quit: User was banned]
danielt has quit [Quit: User was banned]
khem has quit [Quit: User was banned]
Tartarus has quit [Quit: User was banned]
TurBoss has quit [Quit: User was banned]
ahs3[m] has quit [Quit: User was banned]
jaydeep51[m] has quit [Quit: User was banned]
ericson2314 has quit [Quit: User was banned]
jonesv[m] has quit [Quit: User was banned]
dwagenk has quit [Quit: User was banned]
lexano[m] has quit [Quit: User was banned]
zyga[m] has quit [Quit: User was banned]
cperon has quit [Quit: User was banned]
kayterina[m] has quit [Quit: User was banned]
cb5r has quit [Quit: User was banned]
jwillikers[m] has quit [Quit: User was banned]
barath has quit [Quit: User was banned]
NishanthMenon[m] has quit [Quit: User was banned]
suy|m has quit [Quit: User was banned]
hmw[m] has quit [Quit: User was banned]
sielicki has quit [Quit: User was banned]
denna[m] has quit [Quit: User was banned]
Lcvette[m] has quit [Quit: User was banned]
<rburton>
Amahnui: are you Abongwa, who mailed me?
T_UNIX[m] has quit [Quit: User was banned]
jaydeep51[m] has joined #yocto
lexano[m] has joined #yocto
zyga[m] has joined #yocto
khem has joined #yocto
ejoerns[m] has quit [Quit: User was banned]
kayterina[m] has joined #yocto
hansihe has quit [Quit: User was banned]
shoragan[m] has joined #yocto
moto_timo[m] has quit [Quit: User was banned]
Saur[m] has quit [Quit: User was banned]
mmoneyron[m] has quit [Quit: User was banned]
berton[m] has quit [Quit: User was banned]
hpsy[m] has quit [Quit: User was banned]
NishanthMenon[m] has joined #yocto
Perceval[m] has quit [Quit: User was banned]
jclsn[m] has quit [Quit: User was banned]
jaskij[m] has quit [Quit: User was banned]
YoussefAllagui[m has quit [Quit: User was banned]
janvermaete[m] has quit [Quit: User was banned]
agherzan has quit [Quit: User was banned]
falk0n[m] has quit [Quit: User was banned]
thierryE[m] has quit [Quit: User was banned]
MbinIcyer[m] has quit [Quit: User was banned]
mait[m] has quit [Quit: User was banned]
Alban[m] has quit [Quit: User was banned]
DasChaos[m] has quit [Quit: User was banned]
fabatera[m] has quit [Quit: User was banned]
qrsBRWNanyall[m] has quit [Quit: User was banned]
Spectrejan[m] has quit [Quit: User was banned]
ejoerns[m] has joined #yocto
danielt has joined #yocto
moto_timo[m] has joined #yocto
cb5r has joined #yocto
dwagenk has joined #yocto
Portia[m] has quit [Quit: User was banned]
michaelo[m] has quit [Quit: User was banned]
jonesv[m] has joined #yocto
hansihe has joined #yocto
ross[m] has quit [Quit: User was banned]
lexano[m] has quit [Client Quit]
khem has quit [Client Quit]
shoragan[m] has quit [Client Quit]
NishanthMenon[m] has quit [Client Quit]
jaydeep51[m] has quit [Client Quit]
kayterina[m] has quit [Client Quit]
ejoerns[m] has quit [Client Quit]
cb5r has quit [Client Quit]
dwagenk has quit [Client Quit]
danielt has quit [Client Quit]
moto_timo[m] has quit [Client Quit]
hansihe has quit [Client Quit]
jonesv[m] has quit [Client Quit]
zyga[m] has quit [Client Quit]
barath has joined #yocto
jwillikers[m] has joined #yocto
hmw[m] has joined #yocto
suy|m has joined #yocto
ericson2314 has joined #yocto
Tartarus has joined #yocto
Perceval[m] has joined #yocto
berton[m] has joined #yocto
jaskij[m] has joined #yocto
fabatera[m] has joined #yocto
agherzan has joined #yocto
Saur[m] has joined #yocto
TurBoss has joined #yocto
Lcvette[m] has joined #yocto
cperon has joined #yocto
YoussefAllagui[m has joined #yocto
janvermaete[m] has joined #yocto
jclsn[m] has joined #yocto
denna[m] has joined #yocto
<Amahnui>
rburton: yes I am
lexano[m] has joined #yocto
MbinIcyer[m] has joined #yocto
zyga[m] has joined #yocto
Spectrejan[m] has joined #yocto
kayterina[m] has joined #yocto
ahs3[m] has joined #yocto
Portia[m] has joined #yocto
NishanthMenon[m] has joined #yocto
sielicki has joined #yocto
michaelo[m] has joined #yocto
falk0n[m] has joined #yocto
mmoneyron[m] has joined #yocto
danielt has joined #yocto
qrsBRWNanyall[m] has joined #yocto
cb5r has joined #yocto
hpsy[m] has joined #yocto
T_UNIX[m] has joined #yocto
Alban[m] has joined #yocto
mait[m] has joined #yocto
thierryE[m] has joined #yocto
ross[m] has joined #yocto
<rburton>
Amahnui: I won't reply to your mail then :)
jaydeep51[m] has joined #yocto
amahnui[m] has joined #yocto
khem has joined #yocto
shoragan[m] has joined #yocto
ejoerns[m] has joined #yocto
moto_timo[m] has joined #yocto
dwagenk has joined #yocto
jonesv[m] has joined #yocto
hansihe has joined #yocto
<amahnui[m]>
> Amahnui: so the matrix irc bridge appears to be always-on (no missing backlog when you disconnect) and is free: https://app.element.io/#/room/#yoctoproject:matrix.org
<amahnui[m]>
Thanks a lot 🙏🏽
leon-anavi has quit [Remote host closed the connection]
<LetoThe2nd>
has there been some change in SRCPV between dunfell and master? IIUC, it is implicitly set in dunfell, but needs to be fetched from d on master in a python version?
leon-anavi has joined #yocto
xmn_ has quit [Ping timeout: 272 seconds]
<cperon>
Hi all, I have a question regarding the new override syntax using ':' instead of '_', this is new and mandatory to honnister/kirkstone. But it has been backported to dunfell but not hardknott ? is it correct ?
<Saur[m]>
clementp: Support for the new bitbake syntax is in Hardknott.
<Saur[m]>
RP: Interesting reading about the pthread_sigmask() issue. Seems it is pretty useless if some other random thread can cause it to be delivered to a thread where it is blocked...
<RP>
Saur[m]: that was my conclusion. I've gone back to your original approach but tweaked a bit to remove the globals
smsm has quit [Quit: Client closed]
<vvn>
how can I build the same image with two different WKS_FILE?
<qschulz>
vvn: not sure to understand the question? why would you need two different WKS_FILE if you want the same image?
<vvn>
qschulz: for machines with multiple bootable mediums, e.g. a BeagleBone Black SD card and eMMC where the layout may differ. Wouldn't it be the way to achieve this?
<qschulz>
vvn: arguably they are then different machines
<qschulz>
Last time I checked (a few months back) wic would only take the first WKS_FILE it encounters, so listing more does not help
<vvn>
qschulz: yeah and it would be easy to iterate over multiple WKS_FILE but then the IMAGE_LINK_NAME will be messed up.
<qschulz>
vvn: it's not actually THAT straightforward (but probably not very complex either) to do this
<qschulz>
the issue being with the name of the variables
<qschulz>
because there exists a WKS_FILES already
<vvn>
true
<qschulz>
vvn: but I personally would see support for WKS_FILE a nice to have
<qschulz>
vvn: I remember discussing this a few months back, gimme a sec to go through my IRC archive
<vvn>
qschulz: it feels always weird to e.g. grab meta-ti and create a new machine conf inheriting beaglebone.conf, or load a local.conf with sdcard/emmc specific and juggle between them
<vvn>
A concept of sub-machine would be nice, but I guess it's barely the same as a new machine config inheriting a main one...
<vvn>
qschulz: would you create a new my-beaglebone-sdcard.conf machine configuration yourself?
<vvn>
qschulz: FYI the context is scenarios where you want the main system on a medium different than the one used at factory, e.g. using the eMMC. You need some sort of bootstrap from an SD card image to either manually format the eMMC and provision them, or dd a pre-built image (hence the two WKS_FILE).
<vvn>
I guess manually formatting the eMMC is simple enough, but it just felt more robust to describe its layout in a WKS_FILE config at first.
barath has quit [Quit: Bridge terminating on SIGTERM]
hmw[m] has quit [Quit: Bridge terminating on SIGTERM]
suy|m has quit [Quit: Bridge terminating on SIGTERM]
YoussefAllagui[m has quit [Quit: Bridge terminating on SIGTERM]
berton[m] has quit [Quit: Bridge terminating on SIGTERM]
janvermaete[m] has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
lexano[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
fabatera[m] has quit [Quit: Bridge terminating on SIGTERM]
Perceval[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
ahs3[m] has quit [Quit: Bridge terminating on SIGTERM]
Saur[m] has quit [Quit: Bridge terminating on SIGTERM]
Portia[m] has quit [Quit: Bridge terminating on SIGTERM]
Lcvette[m] has quit [Quit: Bridge terminating on SIGTERM]
zyga[m] has quit [Quit: Bridge terminating on SIGTERM]
kayterina[m] has quit [Quit: Bridge terminating on SIGTERM]
MbinIcyer[m] has quit [Quit: Bridge terminating on SIGTERM]
jclsn[m] has quit [Quit: Bridge terminating on SIGTERM]
jaskij[m] has quit [Quit: Bridge terminating on SIGTERM]
ericson2314 has quit [Quit: Bridge terminating on SIGTERM]
jwillikers[m] has quit [Quit: Bridge terminating on SIGTERM]
ross[m] has quit [Quit: Bridge terminating on SIGTERM]
hpsy[m] has quit [Quit: Bridge terminating on SIGTERM]
mmoneyron[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
cperon has quit [Quit: Bridge terminating on SIGTERM]
Spectrejan[m] has quit [Quit: Bridge terminating on SIGTERM]
sielicki has quit [Quit: Bridge terminating on SIGTERM]
Alban[m] has quit [Quit: Bridge terminating on SIGTERM]
moto_timo[m] has quit [Quit: Bridge terminating on SIGTERM]
cb5r has quit [Quit: Bridge terminating on SIGTERM]
jaydeep51[m] has quit [Quit: Bridge terminating on SIGTERM]
hansihe has quit [Quit: Bridge terminating on SIGTERM]
thierryE[m] has quit [Quit: Bridge terminating on SIGTERM]
michaelo[m] has quit [Quit: Bridge terminating on SIGTERM]
danielt has quit [Quit: Bridge terminating on SIGTERM]
qrsBRWNanyall[m] has quit [Quit: Bridge terminating on SIGTERM]
T_UNIX[m] has quit [Quit: Bridge terminating on SIGTERM]
denna[m] has quit [Quit: Bridge terminating on SIGTERM]
NishanthMenon[m] has quit [Quit: Bridge terminating on SIGTERM]
TurBoss has quit [Quit: Bridge terminating on SIGTERM]
falk0n[m] has quit [Quit: Bridge terminating on SIGTERM]
jonesv[m] has quit [Quit: Bridge terminating on SIGTERM]
amahnui[m] has quit [Quit: Bridge terminating on SIGTERM]
mait[m] has quit [Quit: Bridge terminating on SIGTERM]
ejoerns[m] has quit [Quit: Bridge terminating on SIGTERM]
dwagenk has quit [Quit: Bridge terminating on SIGTERM]
jaydeep51[m] has joined #yocto
lexano[m] has joined #yocto
<qschulz>
vvn: The issue is that sometimes bootloader configuration also differs depending on the medium used to boot it
zyga[m] has joined #yocto
kayterina[m] has joined #yocto
khem has joined #yocto
shoragan[m] has joined #yocto
ejoerns[m] has joined #yocto
<qschulz>
in which case, you'd need a different machine anyway
Portia[m] has joined #yocto
NishanthMenon[m] has joined #yocto
moto_timo[m] has joined #yocto
dwagenk has joined #yocto
jonesv[m] has joined #yocto
hansihe has joined #yocto
barath has joined #yocto
jwillikers[m] has joined #yocto
hmw[m] has joined #yocto
suy|m has joined #yocto
ericson2314 has joined #yocto
Tartarus has joined #yocto
michaelo[m] has joined #yocto
danielt has joined #yocto
cb5r has joined #yocto
Perceval[m] has joined #yocto
berton[m] has joined #yocto
jaskij[m] has joined #yocto
<vvn>
qschulz: exactly. Which is the same problem has optimizing the build: do you use a common configuration (e.g. tuning) for two different machine with compatible SoC or do you optimize each one of them with specific configs... :/
fabatera[m] has joined #yocto
agherzan has joined #yocto
Saur[m] has joined #yocto
TurBoss has joined #yocto
Lcvette[m] has joined #yocto
cperon has joined #yocto
YoussefAllagui[m has joined #yocto
janvermaete[m] has joined #yocto
jclsn[m] has joined #yocto
denna[m] has joined #yocto
MbinIcyer[m] has joined #yocto
Spectrejan[m] has joined #yocto
ahs3[m] has joined #yocto
sielicki has joined #yocto
falk0n[m] has joined #yocto
<vvn>
I was tempted to use a common configuration and let the bootloader decide what to do depending on its boot source (which it can detect)
mmoneyron[m] has joined #yocto
qrsBRWNanyall[m] has joined #yocto
hpsy[m] has joined #yocto
T_UNIX[m] has joined #yocto
amahnui[m] has joined #yocto
Alban[m] has joined #yocto
ross[m] has joined #yocto
mait[m] has joined #yocto
thierryE[m] has joined #yocto
<LetoThe2nd>
ping on if anybody knows about the visibility of variables - have there been changes from dunfell to master? we're seeing a situation where we explicitly need to get SRCPV from d instead of it being around implicitly.
<rburton>
sounds very odd
<rburton>
got an example?
<rburton>
i suspect this isn't visibility but lifecycle, are you assigning via python?
<LetoThe2nd>
rburton: falls over on master, works on dunfell. if we also get SRCPV from d, like srcpv = d.getVar("SRCPV") instead of passing it, then it "works"
<rburton>
can i see an example of a caller from dunfell?
<rburton>
i'm actually surprised that worked in dunfell
akiCA has joined #yocto
codavi has joined #yocto
camus has quit [Quit: camus]
<rburton>
so python functions were changed in aece74876271f692296c5f792104c627e15b5c3e
<rburton>
which was 2.1
<rburton>
i think anon is handled differently
camus has joined #yocto
<rburton>
RP might remember better
akiCA has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
sigh. can anybody give me the 5yo version of NXPs HAB in the YOEP context?
Amahnui has quit [Quit: Connection closed for inactivity]
<RP>
rburton: I thought it was a while ago too, pre dunfell
<rburton>
that commit changed non-anon py to not expand inline ${FOO}, the message says we already don't expand anon py
<rburton>
so no idea how that worked for LetoThe2nd ;)
<qschulz>
LetoThe2nd: very little specific to NXP SoC
<LetoThe2nd>
qschulz: can you elaborate?
<qschulz>
basically what vendors need to implement is the first chain in the chain of trust
<qschulz>
i.e. bootrom verifying the bootloader (and usually only the part that is running in SRAM, in U-Boot terms: SPL/TPL)
<qschulz>
for NXP SoCs, it's done by CST (or some other acronym) which is accessible only after registering on their website and agreeing to an EULA
<qschulz>
though for imx6 generation of SoC, there's an open-source implementation done by boundary devices
Amahnui has joined #yocto
<LetoThe2nd>
qschulz: that means that the SPL/TPL must be signed with some key that correlates to something that gets provisioned at factory time, right?
<qschulz>
LetoThe2nd: would be too easy but in theory yes
sakoman has joined #yocto
<LetoThe2nd>
qschulz: and what is the practical "but"?
<qschulz>
for imx6, the HAB contains a hash of public keys used to authenticate the SPL
<qschulz>
(actually can contain up to 4 hashes)
<qschulz>
the SPL has the public key embedded, the bootrom will get the public key, then do the hash
<qschulz>
and check against the one in the fuses you burnt in factory (the hashes in the BootROM I talked about)
<LetoThe2nd>
qschulz: ok, so if I actually want to change the SPL later, then its enough if i sign it the same way, right?
<qschulz>
starting from there, I don't remember exactly but there's probably also a hash of the SPL somewhere in the signed part of the SPL so that the bootrom can validate the SPL is valid
<qschulz>
LetoThe2nd: yup, just need a private key whose public key's hash is one of the ones burnt in the SoC
<RP>
rburton: I'm curious where the behaviour changed :/
<LetoThe2nd>
qschulz: okay. so if i understand it correctly, in the build context its essentially some post processing stage that does the fancy signing.
<qschulz>
LetoThe2nd: *for the vendor specific part of the secure boot*, yes
<qschulz>
LetoThe2nd: also, I would highly recommend not automating this
<LetoThe2nd>
i hate secure boot and all that comes with it.
<LetoThe2nd>
not automating, as in not CI-ing?
* qschulz
will avoid mentioning your laptop has secure boot
* LetoThe2nd
knows and hates it on his laptop(s) too.
<qschulz>
LetoThe2nd: yes, you should gatekeep who has the rights to build binaries that can be installed on devices
<mckoan>
LetoThe2nd: it requires a lot of manual operations
<qschulz>
otherwise the whole point of authenticated/secure boot is missed
Gina has joined #yocto
<mckoan>
qschulz: you can sign it in a second step if necessary
<qschulz>
mckoan: yup
<qschulz>
mckoan: works a bit less with wic images but indeed :)
<LetoThe2nd>
kay, thanks.
<qschulz>
LetoThe2nd: ideally, signing should be done on a machine with no external (LAN, people, etc...) access except one person coming with a byubuykey or similar to sign
<qschulz>
Everybody does it differently and to each their own threat model obviously
<LetoThe2nd>
qschulz: you got it wrong. what you are talking about is "securing boot". what i am talking about is "ticking the secur boot checkbox" ;-)
<qschulz>
LetoThe2nd: yeah I guessed though :) might not have been wise to have said it on a public and archived channel though :p
<qschulz>
LetoThe2nd: but considering that NXP have their own BSP layers, you should probably be able to ask them for support
<qschulz>
because some of this stuff is not straightforward (without speaking of the Yocto integration)
<vvn>
Do one need to enable something in particular in order to have the /dev/root device described in the default /etc/fstab?
rob_w has quit [Remote host closed the connection]
<JaMa>
should uninative be compatible with a host distro which has newer libstdc++ than uninative build? it already checks for glibc version, but not gcc and right now in devel ubuntu jammy where libstdc++6 defaults to 12-20220319-1ubuntu1 from gcc-12 it causes errors like:
<JaMa>
| bin/cmake: /OE/lge/build/webosose/kirkstone/BUILD/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by bin/cmake)
Gina has quit [Ping timeout: 272 seconds]
<JaMa>
| ../bin/icupkg: /OE/lge/build/webosose/kirkstone/BUILD/sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ../lib/libicuuc.so.70)
camus has quit [Ping timeout: 260 seconds]
<JaMa>
because it mixes libstdc++ from host when building bootstrap cmake or icupkg and then sysroots-uninative/x86_64-linux/usr/lib/libstdc++.so.6 when trying to run them (with dunfell as well as kirkstone)
mnme has quit [Quit: Client closed]
<RP>
JaMa: no, newer on the host will not work
<JaMa>
should uninative.bbclass try to check that like it does for glibc?
camus has joined #yocto
<RP>
JaMa: yes
<RP>
JaMa: I'm sure I've meant to do that before :
<JaMa>
it might be only temporary, but still checking the version in hosts libstdc++ might be more reliable than gcc --version
<JaMa>
will try to find something portable as objdump /full-path-to-libstc won't work on different distros
<RP>
JaMa: if we can find a decent way to to it, agreed
hcg has joined #yocto
<Amahnui>
rburton: qschulz I have installed freebsd but it has no gui. It keeps telling me that my login is incorrect. I wish to ask if its normal that its just on the command line and if there is a way to put a gui on it.
<rburton>
you can install a ui, but i have no idea.
<rburton>
note that freebsd knowledge is considered a requirement for the outreachy project we have
<qschulz>
Amahnui: I would suspect incorrect keyboard layout for the login?
sakoman has quit [Ping timeout: 260 seconds]
<Amahnui>
rburton: I do, I'm currently learning it 🙏🏽
<Amahnui>
qschulz: I actually tested the keyboard and it is working as expected
pgowda_ has quit [Quit: Connection closed for inactivity]
<rburton>
Amahnui: we're very much not BSD users here, thus the outreachy, I suggest #freebsd for bsd-specific help
sakoman has joined #yocto
mckoan is now known as mckoan|away
<hcg>
Hi guys, I am busy preparing to move a major project of ours to the kirkstone release of Yocto. Most of our internal recipes in our layers use tags in the SRC_URI (i.e. we are not using SRCREV) and I receive the fetch error 'Recipe uses a floating tag/branch without a fixed SRCREV...' message. Does anyone know if there is a definitive discussion or
<hcg>
some documentation somewhere explaining why not to use tags?
<rburton>
the short version is 1) tag names are looked up every parse, so that's a lot of slow network traffic and 2) tags can move, so you don't have reproducible builds
<kergoth>
Arg, anyone have any tips for nailing down issues where pseudo is showing something that was changed outside of its control, even though as far as I can tell everything relating to this task is run in fakeroot/pseudo context?
<kergoth>
Unable to nail it down via inspection of the tasks, so is there any way to get more info? I recognize its probably hard given pseudo doesnt know what's going on outside of it, so its logs can't show anything new about that..
<JaMa>
hcg: if you use some nice naming scheme for tags and don't want to loose that with SRCREVs then e.g. in webOS we have a bbclass which couples PV and SRCREV in WEBOS_VERSION variable and it checks that specified SRCREV matches with expected tag
<vvn>
Should I add a custom udev rule to get the /dev/root device?
<qschulz>
vvn: IIRC, /dev/root is an mdev thing? I think we had to stop using it in script when we moved to eudev
<vvn>
qschulz: it will be very convenient in my case to abstract the sdcard or emmc, whether is being used. But I'm using systemd. Do you think I must add back a custom rule?
rfuentess has quit [Remote host closed the connection]
xmn has joined #yocto
florian has quit [Quit: Ex-Chat]
<rfs613>
kanavin_: am going to try out the dunfell mixin layer for docker, any tips on how to do this? My brain is having trouble reconciling the usual branch-per-yocto-version approach, versus dunfell-mixin approach of branch-per-package.
Minvera has joined #yocto
AKN has joined #yocto
BCMM has joined #yocto
<kanavin_>
rfs613, you need to check out the same repo twice into two different directories
<rfs613>
kanavin_: once for docker and once for go?
<kanavin_>
rfs613, yes
<rfs613>
kanavin_: okay, and it seems I replace meta-virtualization with the meta-lts-mixins@docker branch (I tried having both and fiddling with layer priorities, but it kept taking 19.x from meta-virt)
<kanavin_>
rfs613, you don't need meta-virt at all I think
Schlumpf has quit [Quit: Client closed]
<dirtyflag>
zeus: a do_compile_append() in a bbappend is not executed. What could i check ?
<kergoth>
bitbake -e yourrecipe and scroll down to do_compile and make sure its what you expect
<dirtyflag>
kergoth: thanks. do_compile is ok, but there is no do_compile_append, nor his content
<kergoth>
most likely your bbappend isn't being applied at all, then. at the top of the bitbake -e you'll see what files were parsed
<kergoth>
make sure your layer is in bblayers, make sure its layer.conf is correct, make sure its path lines up with the BBFILES in the layer.conf, and make sure its filename matches the recipe filename
<dirtyflag>
kergoth: thanks a loit, the last you listed was the issue
<dirtyflag>
*lot
leon-anavi has quit [Quit: Leaving]
AKN has quit [Read error: Connection reset by peer]
aleblanc[m] has joined #yocto
<rfs613>
kanavin_: I got it to build. One small issue, we were using python3-docker-compose from meta-virt, which doesn't exist in the mixin layer (not sure if it should go there?). But now going to try testing it, for some reason kernel isn't booting to userspace anymore, probably unrelated, but got to sort that out now ;)
pasherring_ has quit [Remote host closed the connection]
vquicksilver has joined #yocto
florian_kc has joined #yocto
<rfs613>
kanavin_: right, it is running now - hello-world and ubuntu test images seem to work. Minor warning because docker-init(tinit) version is a few commits ahead of the expected v0.19.0 tag.
<sotaoverride>
whats the best compression format for rootfs.ext4 that takes care of holes / empty space?
<sotaoverride>
loop mounted the rootfs.ext4 files and turns out most of it is just empty space (system has big partitions). I dont want to deal with uploading large files, and I havent looked into squashfs or anything else like that yet
<rfs613>
sotaoverride: the usual method in yocto is to use .wic and bmaptool
hcg has quit [Quit: Client closed]
<rfs613>
I think the advantage is this is more "transportable" between systems, as they are just regular files (one is your compressed image, and the other is a small file describing where the "empty" regions are).
<rfs613>
if you try uploading a sparse file, depending on many factors, it may well transfer the whole thing, or not be sparse upon arrival at the other side.
<sotaoverride>
is there a python module for bmaptool like how there's zipfile, or is bmaptool meant to be more of a command line utility
<sotaoverride>
id have to call it a a subprocess? whats the cleanest way of going about it?
<sotaoverride>
update utility/app I'm dealing with happens to be written in python
<rfs613>
sotaoverride: personally I've only used the command line tool for writing images to SD card etc. Yocto already supports generating rootfs in .wic format
<rfs613>
it looks like the command-line tool is in fact from this very same project...
Amahnui has quit [Quit: Connection closed for inactivity]
Minvera has quit [Remote host closed the connection]
amitk has quit [Ping timeout: 260 seconds]
<kergoth>
the image classes can write out a .wic.bmap file for use with bmaptool, just add wic.bmap to IMAGE_FSTYPES
<kergoth>
iirc rsync does pretty well at retaining sparseness. not sure which compression formats do it best, i'd expect gz or bz2 to be fine
florian_kc has quit [Ping timeout: 240 seconds]
mak has joined #yocto
GillesM has joined #yocto
davidinux has quit [Ping timeout: 260 seconds]
<RP>
khem: I think upgrading go so close to final release date might not be appreciated so I'm leaning towards not doing this FWIW
<amahnui[m]>
> Amahnui: we're very much not BSD users here, thus the outreachy, I suggest #freebsd for bsd-specific help
<amahnui[m]>
Its been giving me some issues
<amahnui[m]>
Thanks for the heads up
<amahnui[m]>
I'll join the freebsd group and table my problems there.
Amahnui has joined #yocto
<sielicki>
is there a mechanism within devtool to disable the application of patches? When doing an upgrade, I find myself in the situation often of having patches that won't apply cleanly, so I'd like to just be able to do `devtool modify X`, go into the autogenerated git directory, and run `git apply` and deal with the conflicts. But the problem is devtool errors out if those patches won't apply cleanly, so I have to go edit the bbappend first, then go
<sielicki>
forward with the workflow I described, then remodify the recipe to reenable the patches.
<sielicki>
anyone else ever desire this feature? Maybe I can contribute something.
<dirtyflag>
mmh, bringed in a bit newer recipe (as .bb) (imx-sc-firmware) into zeus, but now getting
<dirtyflag>
do_unpack: A valid package EULA with md5sum ... error
Amahnui is now known as bonalais
saumya__[m] has joined #yocto
<amahnui[m]>
I have some issues installing and using
<amahnui[m]>
freebsd on my computer After installing freebsd on my computer, I added a new user and password and everythin was fine, but when I tried to log into that account I kept getting the message that my login was incorrect
<amahnui[m]>
I don't know what to do now since I remember all the login details clearly Please I need help fixing it
<dirtyflag>
amahnui[m]: try #bsd
Minvera has joined #yocto
<amahnui[m]>
I actually meant to send it to the freebsd group
<amahnui[m]>
Thanks 🙏🏽
dkl has quit [Quit: %quit%]
aleblanc[m] has left #yocto [#yocto]
dkl has joined #yocto
Minvera has quit [Ping timeout: 260 seconds]
mvlad has quit [Remote host closed the connection]
ferry_ has joined #yocto
ferry_ has quit [Client Quit]
jqua[m] has joined #yocto
ar__ has joined #yocto
codavi has quit [Ping timeout: 260 seconds]
ar__ has quit [Ping timeout: 240 seconds]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
goliath has quit [Quit: SIGSEGV]
bonalais has quit [Quit: Connection closed for inactivity]