<vmeson>
khem: for clang-cross_git.bb, to support lib32-foo, any tip on the magic suffix:
<vmeson>
+# PROVIDES = "clang-cross-i686"
<vmeson>
+PROVIDES = "clang-cross-${TUNE_ARCH}"
<vmeson>
hardcoded works, I'm not sufficiently x-compile savvy to guess at the right generic suffix, even after several tries.
zygny1 has joined #yocto
<vmeson>
TARGET_ARCH didn't work but maybe I just need to include the right file. consulting gcc-cross.inc ...
Guma__ has quit [Ping timeout: 252 seconds]
<vmeson>
( somehow the lib32-chromium-x11 build is busted. I don't really care but we have build bots that do...)
<khem>
vmeson I dont have need for multilib much so have not tested it regularly but then some one did do it some months ago
<khem>
whats are use for lib32-chromium
<vmeson>
khem: mostly the demanding build bots.... I could exclude that build. I may ping Kai how has been doing much of the multilib support for WR. Thx.
<khem>
I think you will mostly need to fix chromium recipe for multilib
<khem>
you can try building something simple like lib32-bash and set TOOLCHAIN = "clang" for it
<vmeson>
k
<khem>
and see if that builds
<khem>
if it does then compiler is ok
<vmeson>
roger.
<khem>
I am open to fixing the multilib case
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
AKN has joined #yocto
goliath has quit [Quit: SIGSEGV]
jclsn5 has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
AKN has quit [Ping timeout: 240 seconds]
zygny1 has quit [Quit: Client closed]
alex88 has quit [Ping timeout: 272 seconds]
sakoman has quit [Quit: Leaving.]
AKN has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
opello has quit [*.net *.split]
vquicksilver has quit [*.net *.split]
opello has joined #yocto
vquicksilver has joined #yocto
AKN has quit [Ping timeout: 250 seconds]
<landgraf>
RP: Hi. I have reproduced the resident bitbake bug locally and it doesn't take few hours to test anymore. Hopefully will be fixed soon :)
rob_w has joined #yocto
lucaceresoli has joined #yocto
jclsn5 is now known as jclsn
pgowda_ has joined #yocto
mvlad has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
GNUmoon has joined #yocto
rfuentess has joined #yocto
mmoneyron[m] has joined #yocto
florian has joined #yocto
<jclsn>
Good morning
Schlumpf has joined #yocto
<RP>
landgraf: that sounds good! :)
tnovotny has joined #yocto
<shoragan>
has anyone built something to derive a distro version from the git commit information?
<shoragan>
in /etc/build there's the branch and commit hash, but that's hard to compare for humans
<qschulz>
cb5r: you'd need to give us the error log to be able to help you
<RP>
shoragan: poky.conf already does DISTRO_VERSION = "3.4+snapshot-${METADATA_REVISION}"
<RP>
shoragan: you could probably get something like the commit count there
<shoragan>
ah, or commit data
<shoragan>
s/data/date/
<RP>
shoragan: yes, true
<shoragan>
thanks for the idea :)
<cb5r>
qschulz: What's the preferred nopaste site? Should the log.do_compile suffice or what else is usefuL?
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
<qschulz>
cb5r: anything works, just make it unlimited in time. You can anonymize your data if you want beforehand
<cb5r>
is 2y enough? cant find a working provider that stores forever :/
<dwagenk>
Currently UNINATIVE_MAXGLIBCVERSION causes problems with the eSDK on a developers machine. He's using Arch linux so his glibc is newer than the one in uninative. If I understand the commit messages around introduction of that variable correctly a host with newer glibc is only a problem if it contributes to a shared sstate. Am I right to assume that an eSDK user will not contribute to a shared sstate and thus the check could be disabled for eSDKs?
jqua[m] has quit [Quit: You have been kicked for being idle]
AKN has joined #yocto
<manuel1985>
Anyone any advice on how to let my qemux86-64 guest connect to the internet? I started it with slirp. The guest can ping the host. Also, I can ssh into the guest from the host. (qemu forwards localhost:2222 to the guests :22.)
<manuel1985>
The host has ipv4 routing enabled.
<manuel1985>
Do I manually need to adapt the routing tables?
florian has quit [Quit: Ex-Chat]
yolo has quit [Quit: Lost terminal]
dtometzki has quit [Ping timeout: 256 seconds]
jmiehe has joined #yocto
<RP>
qschulz, michaelo: How do you feel about automating the versioning in the docs?
<mihai>
anyone here playing with k3s from meta-virtualization? I'm having trouble understanding who, what, how does /var/lib/rancher/k3s/data/ gets created
<qschulz>
RP: do you have anything in mind?
<qschulz>
i'm all for automating as much as possible
<RP>
qschulz: a script which queries the current branch/tag and sets the versions magically
<RP>
qschulz: I'm seeing if I can write such a thing
<qschulz>
RP: you said last week you didn't want such a thing 😭
<qschulz>
the argument was that people can clone without tags
<RP>
qschulz: oh, yes. Gah :(
<qschulz>
or do you want this magical stuff in the yocto-autobuilder-helper?
<RP>
qschulz: I was thinking of it in the context of autobuilder-helper where this stuff is known
Herrie has joined #yocto
<RP>
but it would mean the branches/tags wouldn't be right
<qschulz>
RP: we need to start writing a wiki page or something to gather our thoughts, issues and reuiqrements because I feel like the lists endlessly grows and we have done nothing to make it easier on maintainers to get things right first try with as little work from them as possible
mihai has quit [Quit: Leaving]
mihai has joined #yocto
<qschulz>
one more thing I should have done long time ago
<RP>
qschulz: I think my argument about tags can be mitigated as even if the tags aren't there it should be able to work out which branch and hence series we're on
<RP>
and then it could just set the number to something silly
<qschulz>
RP: the yocto major.minor release number would be known at least
<RP>
qschulz: right, excatly
<RP>
qschulz: you're right, we need to think this through carefully
florian_kc has joined #yocto
prabhakarlad has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
florian__ has joined #yocto
florian_kc has quit [Ping timeout: 250 seconds]
florian__ has quit [Read error: Connection reset by peer]
florian__ has joined #yocto
<RP>
qschulz: just sent my script. I also realised we can detect missing tags and tell the user to update, that makes that issue simple
otavio has quit [Read error: Connection reset by peer]
<jclsn>
Hey, I am still having this issue with non-reproducible builds. Kind of frustrated by now. Would be happy for any advice on what else I could try
Qorin has joined #yocto
<qschulz>
cb5r: do you have your old build logs?
<qschulz>
cb5r: I assume the "error" is with -Werror=format-security flag
<qschulz>
which turns the format-security warning into an error if I'm not mistaken
<qschulz>
now, I couldn't see any direct addition of this flag
<cb5r>
You mean the old logs before I updated poky?
<qschulz>
and also.. no change for kdb
<qschulz>
cb5r: yes
<cb5r>
if my -cf clean image didnt remove them..? Are you interested in the cmopiler flag you mentioned?
<cb5r>
/whois cb
<qschulz>
cb5r: yes
<qschulz>
also, can you run bitbake-layers show-appends kbd ?
<cb5r>
Let me check
<qschulz>
to check you don't have a bbappend for it somewhere
<qschulz>
because I'm pretty sure we build everything automatically and if kbd wouldn't build from vanilla poky, we should have known and fixed it
<cb5r>
bitbake-layers show-appends kbd >>> No append files found
<qschulz>
cb5r: you can run bitbake -c compile -f kbd once you've checked out yuor layers with the old dunfell branch
<qschulz>
to get the compile log
<qschulz>
or actually, bitbake -e kdb | grep CFLAGS= should be enough
<cb5r>
I do have logs from poky 3.1.7 I have - which compiled successfully
<cb5r>
It also had -Wformat-security -Werror=format-security set
<rburton>
new gcc has more warnings
<qschulz>
cb5r: time to do a diff of the logs of 3.1.7 and 3.1.14 (not only compile but configure also
<rburton>
which if you set -Werror then you get more errors
<qschulz>
rburton: I would hope that between 3.1.7 and 3.1.14 gcc wouldn't change
<qschulz>
outside of CVEs
<rburton>
oh that's a native recipe
<rburton>
so, host gcc
<qschulz>
rburton: I don't think so? cb5r is talking about kbd not kbd-native
<qschulz>
*there are two pastebins)
<rburton>
oh i just saw gdk-pixbuf-native
<qschulz>
cb5r: for kbd since the recipes haven't changed, nor the flags, it can only be that the sources or configure task are different I guess
<qschulz>
so doing a diff of the logs would be probably helpful
<cb5r>
BTW: Quick recap of what I (also) did, because I don't know if it's relevant: I had a successful dunfell build with poky 3.1.7. Then I tried to include squeekboard, which requires gnome3 and rust - which I then included - and got some errors. Per your suggestion I then updated to poky 3.1.14 and now kbd fails. *shrug*
<cb5r>
I'm diffing right now
<qschulz>
cb5r: any change to any .conf file anywhere?
<cb5r>
Just the build/conf/device.conf: IMAGE_INSTALL_append = " squeekboard"
<cb5r>
* local.conf
mihai has quit [Quit: Leaving]
<rburton>
do a fresh clone of poky, and literally . oe-init-build-env ; bitbake kbd
<rburton>
(you may set DL_DIR first to save repeating the fetches)
<rburton>
but always good to test stuff like weird breakage in a clean tree with no modifications or custom configs
<cb5r>
The run.do_configure is identical - except for a missing bbnote() and die() func on poky 3.1.14.
<cb5r>
Alrighty - I'll completely set it up cleanly again
<rburton>
do nothing apart from setting DL_DIR, you want an entirely clean build to remove all other changes
<rburton>
as dunfell built on the autobuilder, so we need to find out what the difference is
<rburton>
maybe your host is newer than anything the AB tests with and you've hit a new pain point
<rburton>
arch users for example find build breakage before most people
<cb5r>
Yeah - I have never had a successful build under arch - I only use older ubuntu/debian (currently deb 11 for this build)
<cb5r>
I could also try deb 10 or even ubuntu 18.04 but I guess deb11 should be just fine??
<rburton>
yeah should be
<qschulz>
cb5r: listed as supported in the docs so yes
rob_w has quit [Remote host closed the connection]
shoragan has quit [Ping timeout: 256 seconds]
shoragan has joined #yocto
mihai has joined #yocto
<opello>
is there a nice way to PREMIRRORS git://github.com... SRC_URIs that don't have ;protocol=https to add it? even appending it unconditionally would be fine (to fix ls-remote calls now that github has blocked unauthenticated git binary protocol)
<opello>
using git://github.com/.*/.* git://github.com/PATH;protocol=https doesn't seem to work when there are other semicolon delimited parameters like ;branch=
<cb5r>
rburton: When you say "literally . oe-init-build-env" - do you really mean NOT to use the "setup-environment" script provided my OEM that calls oe-init-build-env?
<rburton>
cb5r: *just* poky. if that works we know its not the host and something else broke it.
<Qorin>
Hi everyone,
<Qorin>
i have a question regarding yocto variable.
<Qorin>
let's say I have 2 files: recipe.bb and recipe.bbclass.
<Qorin>
in recipe.bbclass there is this function
<Qorin>
do_task() {
<Qorin>
if [ -z "${FOO}" ]; then
<Qorin>
bbfatal "'FOO' not set."
<Qorin>
fi
<Qorin>
# do things
<Qorin>
}
<Qorin>
normally in recipe.bb, FOO would be defined as a recipe variable.
<Qorin>
FOO="bar"
<Qorin>
however I would like to move this into a function.
<Qorin>
i tried using d.setVar("FOO", "bar") or export FOO="bar"
<rburton>
Qorin: variables changed in one task don't persist to the next
<sotaoverride>
rburton: is it becuase now we wont have a way of tracking exactly what all python modules we'll end up using?
<rburton>
eys
<rburton>
yes
<rburton>
if you've a setup which has a billion python deps, then fine, but it's not how the core layers will encourage
<RP>
qschulz: I've sent an actual patch to give us something to discuss :)
<sotaoverride>
rburton: things like: httpaio and FastAPI, would you consider them something that's in the "billion python deps" realm?
<rburton>
i mean if you have a big app which has 100 deps and all locked to specific version, then just pip install the lot
<Qorin>
rburton ah i see. I have also tried to prepend export FOO="bar" to the do_task function however this also doesn't work.
<rburton>
just setting it in the recipe will work
<rburton>
no need to complicate things
<rburton>
if you need it set differently in different tasks, there are task overrides
<Qorin>
the thing is, to get the input for the variable, it needs to get the input from a tool. originally what I did is set the FOO variable in the recipe FOO="${@get_foo_from_network(d)}". this works, however since this is done this way during parsing of recipes when the tool fails due to network, parsing will also fail. would be nice if i can change it
<Qorin>
so that parsing is just parsing and not including execution.
<cb5r>
rburton: poky is FETCHING for ages now... Even though I've exported DL_DIR=.../yocto-dunfell/downloads <<< was that not correct?
<rburton>
cb5r: set it in local.conf
<rburton>
not sure if its on the whitelist
<rburton>
also, assuming you checked out dunfell and not using master as that would mean fetching a lot more stuff
<rburton>
Qorin: make the function take arguments then the recipe can get the value and pass tem
<cb5r>
Its on tags/yocto-3.1.14. I thought the export would suffice but looks like not... Its about half way through so probably 30 more minutes to go +.+ Should I just let it run for cleanliness sake or set the DL_DIR in local.conf and re-try from there?
* rburton
shrugs
<rburton>
depends how fast your internet is
<cb5r>
Not as fast as I would like it to be :P
goliath has joined #yocto
<sotaoverride>
should the df command be showing the currently active rootfs partition? I see my other patitions fine (all rootfs partitions are mounted at all times)
* RP
wonders whether to do much further with the docs script or not
<jclsn>
RP: What are these stare notifications?
<jclsn>
*star
prabhakarlad has quit [Quit: Client closed]
<RP>
jclsn: just irc formatting for /me XXX messages
<jclsn>
Let me try
* jclsn
is on the brink of a nervous breakdown
* jclsn
wonders if there is any other reason why bitbake could break his kernel build when the source is not checked out in workspace
<qschulz>
RP: thanks!
<qschulz>
RP: this is where things start to duplicate and we would like to avoid this
<RP>
qschulz: duplicate?
<qschulz>
basically, you have versions, lts?, eol?, name, etc... in switchers.js already
<qschulz>
some related entries in poky.yaml too
<qschulz>
and now this python script
<RP>
qschulz: right, I was hoping to make one of these definitive eventually
<jclsn>
So no one can help /me it seems
<jclsn>
Pity that didn't work
<qschulz>
RP: the replacements stuff could be part of yocto-vars so it's transparent to the user and done by sphinx directly
<qschulz>
documentation/sphinx/yocto-vars.py
<RP>
qschulz: right, that could be a future optimisation :)
<RP>
qschulz: I was trying to at least get something we could diff with the current yaml file and see if it worked
<RP>
qschulz: I can continue with this to tweak conf.py too and probably autogenerate switchers.js as well
<qschulz>
RP: up to you, I won't stop you working on the docs :D
<RP>
qschulz: question is whether it is the right direction
<qschulz>
but we have a "problem" with requiring some files from master branch to replace existing ones
<qschulz>
switchers.js being one of them
<RP>
qschulz: I don't think we can avoid that
<RP>
at least for one file
<qschulz>
RP: an additional git repo for common files
<RP>
do we really need that?
<RP>
for a single file
<qschulz>
RP: you have migration guides, release manuals also
sakoman has joined #yocto
<RP>
qschulz: that sounds like a different problem
<qschulz>
RP: too many problems :)
<qschulz>
need to start this wiki page to gather them all
<RP>
qschulz: I think I continue and try and solve the smaller subset of making the releases and getting the versions right
<qschulz>
RP: cannot hurt and worst case scenario it's a good inspiration and something to talk about
<jclsn>
qschulz: work/my-machine-fslc-linux-gnueabi/linux-fslc-imx/5.10.98+gitAUTOINC+8e27b711e7-r0/ I guess??
ar__ has joined #yocto
<RP>
qschulz: ok, patch to tie conf.py to set_versions added. I've not changed switchers.js since I think that is probably different enough we just update it on master
<qschulz>
jclsn: seems reasonable
<qschulz>
RP: will have a look, I'm preparing some changes for automatically fetching and building new yocto-docs and bitbake docs branches
<qschulz>
in yocto-autobuilder-helper
codavi has joined #yocto
<RP>
qschulz: I've tried to make the changes less invasive so we could retrofit to the older release branches easily and keep everything in sync. I think to make this backwards compatible we'd need to add POKYVERSION support
<moto-timo>
langdale ;)
<RP>
moto-timo: yes!
ar__ has quit [Ping timeout: 252 seconds]
jamestperk has quit [Ping timeout: 250 seconds]
madisox has quit [Ping timeout: 250 seconds]
ldts has quit [Ping timeout: 250 seconds]
rburton has quit [Ping timeout: 250 seconds]
<RP>
The combination of docs, python build, pseudo, bitbake performance and libtool at once means I think I need to lie down :)
<jclsn>
qschulz: Fetching binutils is taking ages again. Guess I can't do it today
ldts has joined #yocto
rburton has joined #yocto
<RP>
jclsn: wiping out DL_DIR will not help with your reproduction issue. It is very well isolated from your build output and I very much doubt will change anything other than you waiting for the downloads a lot
<RP>
We checksum anything coming into the build (or have git shas)
madisox has joined #yocto
jamestperk has joined #yocto
<jclsn>
RP: I know, I am just desperate and very unsure about everything
tgamblin_ has joined #yocto
tgamblin has quit [Ping timeout: 240 seconds]
<jclsn>
Did you ever experience issues using zsh?
<qschulz>
jclsn: shell tasks are run with your host;s shell, so if they are not zsh compliant or have a different behavior between bash, dash, zsh, you name it, then it could be an issue yes
<qschulz>
hence why it's important to write POSIX compliant shell tasks
<jclsn>
qschulz: Yeah I realized that shell scripts are not always compatible with bash if they are compatible with zsh
<qschulz>
jclsn: been bitten by this the last few weeks a bit more than I expected :)
<qschulz>
(not in Yocto to be clear)
AKN has quit [Ping timeout: 268 seconds]
<qschulz>
RP: what I thought would be a patch or two starts to be a bit bigger of a patch series than I ancitipated :D
<moto-timo>
Don’t look behind the curtain
<RP>
qschulz: I'm just having trouble stopping :)
<qschulz>
RP: I meant more about the patch series I'm working on for the autobuilder-helper script :)
<qschulz>
I've yet to look at my mails to see your patches :)
<RP>
qschulz: ah, right. Sounds like my problem :)
Minvera has quit [Ping timeout: 250 seconds]
Minvera has joined #yocto
tgamblin_ has quit [Remote host closed the connection]
pgowda_ has quit [Quit: Connection closed for inactivity]
tgamblin_ has joined #yocto
<jclsn>
qschulz: Yep, I could fix my Pyrex setup script for bash now. I should always test it in bash before pushing
<jclsn>
Scripts behave differently even with the shebang
<qschulz>
jclsn: not possible
tgamblin_ has quit [Quit: Leaving]
<jclsn>
qschulz: True story
<jclsn>
Ah seems like this isn't true for sourcing scripts
<qschulz>
jclsn: yup
<cb5r>
qschulz: bitbake kbd succeeded.
<jclsn>
Anyway
<jclsn>
Weekeed
* jclsn
needs beer
<qschulz>
cb5r: add your layers one by one and check
* jclsn
is going to start with Spanish wine actually
<cb5r>
qschulz: What is the best way to go about this? Just build anything from each layer?
<qschulz>
cb5r: add one layer after another and run bitbake -c cleansstate kbd && bitbake kbd
<qschulz>
if still not an issue, source your OEM script and see
<rburton>
cb5r: i'd start by adding your BSP layer and switching MACHINE
<rburton>
but you've demonstrated that its not a fundamental problem with oe-core
* RP
suspects that set_versions script just gained enough magic to be semi-sentient :/
<cb5r>
Aye aye, Sirs!
prabhakarlad has joined #yocto
<qschulz>
RP: what I would have loved to see for switchers.js and co was a JSON file with all the necessary info in it
<qschulz>
I think that was ndec dream too
<qschulz>
(just saying)
<ndec>
lol
<qschulz>
but loading a JSON from another file securely in JS was not straightforward to me
<qschulz>
(never done JS so can't really say it was a good investigation :D)
<cb5r>
Oh great - now openssl fails on do_configure +.+ I don't quiet understand how this is possible..? "bitbake-layers show-appends openssl" says there is nothing :l
<qschulz>
cb5r: only vanilla poky?
<cb5r>
the log.do_configure says "Something wrong with this line: ^@^@^@^@^@^@^@..........."
<cb5r>
qschulz: I added the other BSP layers to bblayers and set the MACHINE to my target and the DL_DIR while I was at it
<cb5r>
But now when I think of it - the target arch is somehow defined in the BSP layer from the OEM so that could be a problem I guess?
<RP>
qschulz: I just made switchers.js update from set_versions.py
<RP>
qschulz: the data we need doesn't lend itself to a nice json file
<cb5r>
I saw those thousands of ^@^@^@^@^@ somewhere in a *.po file this morning... Does anyone know what this means? Some kind of file corruption?
<ndec>
RP: how are you doing that?
<RP>
ndec: see the patches. Its pretty horrible in places but tries to make everything magically work
<ndec>
the reason why we talked about a JSON file was to have a 'database' with release information outside of git. so that a doc website (or anything else) could use it. are you achieving something like that?
<RP>
ndec: I'm using the git tags as the database
<qschulz>
cb5r: are you sure this is not something displayed by your text editor?
<ndec>
RP: ok, so the generation of switcher is dynamic (based on tags), but once it's on docs.yp.org it's 'static', right?
<RP>
ndec: correct
<qschulz>
RP: finally was able to send the patches, only 6... meh. Took time to make sure the output was identical
<cb5r>
Ofc I think that these are just undisplayable chars. However, it doesnt make sense to me where this comes from. Shouldnt this be like bash or python code or something?
<RP>
ndec: I know older releases would be nice to be dynamic with new data but I don't know the JS to do that
<cb5r>
qschulz: `less` warns about "binary file". This is what the configure log looks like: https://pastebin.com/S3jxsB8r
rfuentess has quit [Remote host closed the connection]
<rburton>
sounds like cb5r possibly has disk corruption
tnovotny has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
Minvera has quit [Read error: Connection reset by peer]
jmiehe has quit [Quit: jmiehe]
<cb5r>
rburton: It might be, idk... the zpool on my host doesn't report any corruption and inside the qemu VM @ ext4 I also don't see any cues about corruption *shrug* the nvme is brand new
<cb5r>
but its the second file today :/
dtometzki has joined #yocto
leon-anavi has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
florian__ has quit [Ping timeout: 250 seconds]
prabhakarlad has quit [Quit: Client closed]
florian__ has joined #yocto
mvlad has quit [Remote host closed the connection]
<manuel1985>
Anyone any advice on how to let my qemux86-64 guest connect to the internet? I started it with slirp. The guest can ping the host. Also, I can ssh into the guest from the host. (qemu forwards localhost:2222 to the guests :22.)
<manuel1985>
The host has ipv4 routing enabled.
<manuel1985>
Do I manually need to adapt the routing tables?
florian__ has quit [Ping timeout: 240 seconds]
<mihai>
manuel1985, with slirp qemu should be able to access the same network as your host, maybe you're behind a proxy
<cb5r>
manuel1985: if ipv4forwarding is enabled and a default route on both guest and host is set correctly, it should work. try `tracepath 1.1.1.1` on the guest to see where the routes are going.
<manuel1985>
Thanks both
florian__ has joined #yocto
leon-anavi has quit [Remote host closed the connection]