<mcfrisk>
cleansstate is slower than a rebuild, I find this odd
florian_kc has joined #yocto
frieder has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX
<PhoenixMage>
It is my personal opinion there is no such thing
xmn has quit [Quit: ZZZzzz…]
florian_kc has quit [Ping timeout: 245 seconds]
<LetoThe2nd>
?
xmn has joined #yocto
zpfvo has joined #yocto
Kubu_work has joined #yocto
mischief has quit [Server closed connection]
mischief has joined #yocto
Yash17 has quit [Quit: Client closed]
<PhoenixMage>
I am not a morning person
<PhoenixMage>
Hence to such thing as a good morning
<PhoenixMage>
no
amitk_ has joined #yocto
florian_kc has joined #yocto
gsalazar has joined #yocto
zpfvo has quit [Ping timeout: 250 seconds]
bps2 has joined #yocto
florian_kc has quit [Ping timeout: 245 seconds]
olani has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
LocutusOfBorg has joined #yocto
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 245 seconds]
zpfvo has joined #yocto
Thorn has quit [Ping timeout: 252 seconds]
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
zpfvo has joined #yocto
Haxxa has quit [Remote host closed the connection]
Haxxa has joined #yocto
xmn has quit [Ping timeout: 250 seconds]
xmn has joined #yocto
florian_kc is now known as florian
manuel__ has joined #yocto
prabhakarlad has joined #yocto
manuel_ has quit [Ping timeout: 260 seconds]
Thorn has joined #yocto
kpo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
tetrakist has joined #yocto
xmn has quit [Ping timeout: 246 seconds]
Patrick38 has joined #yocto
Patrick38 has quit [Client Quit]
pvogelaar has joined #yocto
starblue2 has quit [Ping timeout: 250 seconds]
starblue2 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mvlad has joined #yocto
zpfvo has quit [Ping timeout: 246 seconds]
<dacav>
Hi. Is there a way to supply extra flags for a certain machine only? e.g EXTRA_OECMAKE:foo += "-DOPTION=value", while keeping a common EXTRA_OECMAKE definition?
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
zpfvo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
dv_ has quit [Ping timeout: 240 seconds]
<LetoThe2nd>
dacav: thats exactly what machine overrides are for. it works exactly as you guessed: EXTRA_OECMAKELappend:raspberrypi3 = " whatever"
<dacav>
LetoThe2nd: Weird: in my case it seems to replace EXTRA_OECMAKE completely
<dacav>
I had to resort to a temporary variable with the common part
<LetoThe2nd>
dacav: look closer, theres an :append hidden in there. though i might have gotten the order wrong.
<dacav>
I noticed the append. I use +=, but I've tried with append earlier
dv_ has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<rburton>
overrides and += don't work
<rburton>
if you override, you need to use append
<rburton>
(modern bitbake will tell you this)
* JaMa
still fighting with patchelf and loosing :/
<dacav>
Wow, thanks rburton
<dacav>
any good reason to use +=, or should I just stick to :append?
<JaMa>
+= is still fine for non-conditional appends to space separated variables like DEPENDS
AKN has joined #yocto
<JaMa>
:append is more difficult to "overwrite" e.g. if .bbclass uses DEPENDS:append, then as benefit it doesn't matter if you inherit it before or after DEPENDS, but in rare cases where you need to undo :append (e.g. removing a patch file from SRC_URI:append, because you've already applied it in your fork, simple assignment to SRC_URI in your .bbappend won't overwrite it and SRC_URI:remove = "that-applied.patch"
<JaMa>
also isn't nice
<JaMa>
so it depends on the use case :)
<dacav>
Thanks JaMa. I've to say I'm not really fond of bitbake's language, but it makes sense.
<kanavin>
dacav, we all struggle with some aspects of it, but it's very difficult to improve in a way that doesn't break everything
<dacav>
Yes, I can immagine
<dacav>
Actually, given the complexity level, I think yocto is quite good
<kanavin>
dacav, direct sdk is when you don't actually produce a separate SDK archive, but simply use bitbake to obtain a SDK environment
<kanavin>
this is relatively new, you need langdale or mickledore to use it
<dacav>
I can't picture it :) So the regular SDK has the `populate_sdk` task, and you get the .sh to install. How about the direct?
<kanavin>
you are allowed to ask jogness and tglx if 2023 is the year of mainline preempt-rt :)
matthias_de has joined #yocto
<LetoThe2nd>
There is a very high probability that there will be some form of social after YPDD. But given the fact that it is unofficial, there cannot be official planning for it by definition.😁
<kanavin>
we'll just walk in the most promising (quality drinks and food wise) direction from the conference venue
<matthias_de>
kirkstone as some layers i am using are not having mickledore support. Is there a way to use the esdk like this in kirkstone somehow?
<kanavin>
matthias_de, there is not, unless you want to backport the needed changes into a custom fork of kirkstone
<kanavin>
or ask those 'some layers' to maintain themselves properly
<matthias_de>
Well, the layers are the ones coming from TI (meta-arago/meta-ti). They do have the layers in master but there is no mickledore branch. I was reluctant to go to master as the dedicated branches seemed to be more stable, but maybe this is what I need to do
<matthias_de>
Sorry, I meant: They do support mickledore in master, but there is no dedicated mickledore branch
<kanavin>
matthias_de, that may only mean that there is no need to make a separate branch just yet. mickledore is very new.
<kanavin>
there are other layers which do 'lazy' branching in a similar manner
<kanavin>
so they've regressed at some point, and that perhaps needs fixing first
<RP>
kanavin: I have a fix for lttng-tools, I've been discussing that. For strace, it is accept() vs accept4() in the logs, probably a libc issue
<kanavin>
RP: ah, accept vs accept4 is because we build glibc in a way that uses 'best available' kernel APIs, and no other distro does, so strace is oblivious to the issue
<kanavin>
(OLDEST_KERNEL setting)
paulg has joined #yocto
prabhakarlad has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<JaMa>
RP: should we run patchelf-uninative multiple times on the same binary (when there are multiple hardlinks to it?) chrpath and strip seems to run only once per binary, but uninative_changeinterp doesn't handle that and repeated calls to patchelf result in different binaries
AKN has quit [Ping timeout: 246 seconds]
<adrian_>
matthias_de: we are using the new SDK with kirkstone. It's one commit which needs to be cherry-picked, if I remember correctly: 2e48d588bb980a1b8ede11275e2dd0602cdd6917
adrian_ has quit [Remote host closed the connection]
<matthias_de>
adrian_ That would be great. Let me look at this commit.
xmn has joined #yocto
Xagen has joined #yocto
adrian_ has joined #yocto
<RP>
kanavin: can we file a bug with strace ?
<RP>
JaMa: that is an interesting question. Perhaps we should fix patchelf to check the path it is changing to ?
<RP>
JaMa: it is meant to be harmless to do that and there is clearly a bug in patchelf :(
Xagen has quit [Client Quit]
Xagen has joined #yocto
<JaMa>
RP: will try that, it's one of my leads to uninative-4.0 breakage, but still cannot reproduce identically broken binary as populate_sysroot does, so maybe something else influences it as well
tetrakist has quit [Quit: Leaving]
AndreRicardo has joined #yocto
<AndreRicardo>
Hello, I'm trying to keep the machine-id even when software update runs. This is so that journald logs are not lost between updates.
<AndreRicardo>
but I'm getting a FileNotFoundError: [Errno 2] No such file or directory: '/home/andre/yocto/ltf-yoctotmp/tmp/work/vetscan_rpi4-poky-linux-gnueabi/ltf-dev-image/development-r1/rootfs/etc/machine-id'
<AndreRicardo>
seems that it creates a link to a non existent file on my machine
<AndreRicardo>
ls -al /home/andre/yocto/ltf-yoctotmp/tmp/work/vetscan_rpi4-poky-linux-gnueabi/ltf-dev-image/development-r1/rootfs/etc/machine-id
<AndreRicardo>
lrwxrwxrwx 1 andre andre 25 Jun 22 15:39 /home/andre/yocto/ltf-yoctotmp/tmp/work/vetscan_rpi4-poky-linux-gnueabi/ltf-dev-image/development-r1/rootfs/etc/machine-id -> /var/local/etc/machine-id
AKN has joined #yocto
sakoman has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
<JaMa>
RP: not calling patchelf-uninative at all (because in mkfs.ext4 case the interpreter is already set correctly, seems to help) will add it in my build to confirm that and then will follow-up with the issue ticket in upstream
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<AndreRicardo>
Example after running software update, the machine-id changed and now have two entries in /var/log/journal/
<AndreRicardo>
vs-ltf-B-13:~# ls /var/log/journal/
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
AKN has joined #yocto
pvogelaar has quit [Quit: Client closed]
<roussinm>
I finally had time to submit my patch to have -src package present in the nativesdk, https://lists.openembedded.org/g/openembedded-core/message/183233, but the host-contaminated error, I just don't get it. The user is the same everywhere, maybe the qa error shouldn't show up for this case?
ptsneves has joined #yocto
AKN has quit [Read error: Connection reset by peer]
amitk has quit [Ping timeout: 250 seconds]
zpfvo has quit [Ping timeout: 246 seconds]
AndreRicardo has quit [Ping timeout: 246 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mvlad has quit [Remote host closed the connection]
zpfvo has joined #yocto
mvlad has joined #yocto
kpo has quit [Ping timeout: 246 seconds]
<moto-timo>
khem: I had to make the decision whether to bring the board (knowing I would not have much time to work on it)... I chose to not bring the board to PRG. Next time.
<khem>
ok no worries
matthias_de has quit [Ping timeout: 246 seconds]
<khem>
perhaps someone at conference will surely carry one
matthias_de has joined #yocto
<moto-timo>
khem: I did bring the controller and display ;)
<moto-timo>
Call to arms!
Xagen has joined #yocto
manuel__ has quit [Ping timeout: 250 seconds]
Xagen has quit [Client Quit]
<LetoThe2nd>
moto-timo: call to BFG!
<LetoThe2nd>
moto-timo: i am carrying a beagleplay to demo, but it will run chocolate-doom in demo mode only. :-(
goliath has quit [Quit: SIGSEGV]
goliath has joined #yocto
Xagen has joined #yocto
seccar has quit [Ping timeout: 245 seconds]
goliath has quit [Quit: SIGSEGV]
ptsneves has quit [Ping timeout: 245 seconds]
<kanavin>
RP: thanks, the bug description is fine
<kanavin>
I fell asleep meanwhile :D
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
kanavin: I've updated master-next with patches for lttng-tools. Upstream have said they might be willing to make those backports into stable releases for us
<RP>
kanavin: I've changed the "disable ptest" strace patch to disabling 64 bit time since I think strace is more appropriate that way until they fix it
dmoseley has joined #yocto
<RP>
kanavin: that takes the regressions down to just the current ones
<RP>
s/current/existing/
dwagenk has quit [Remote host closed the connection]
duncan^ has quit [Quit: WeeChat 3.0]
<kanavin>
RP: right, which begs the question of adding qemux86-ptest to a-full?
banditopazzo[m] has joined #yocto
<RP>
kanavin: idealistically great idea. In reality, without more people helping work on these things...
Xagen has joined #yocto
<kanavin>
RP: I can help get it to a point where it passes
<RP>
kanavin: who deals with the intermittent failures week in week out though? :/
<RP>
kanavin: it is close to passing, just the strace issue and the glib-networking one is likely the known problem we're chasing :/
<kanavin>
RP: strace issue can probably be solved with a patch that converts accept to accept4 in expected test output
<kanavin>
not sure why it won't show on 64 bit ptest, needs to be looked at
<kanavin>
it might be because glibc only takes it into use on 32 bit
<kanavin>
as for intermittent failures, I can look into those too. it's all going to be filed under y2038 work.
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
kanavin: the 32 bit old syscall APIs are a bit weird, there is no accept syscall, it goes via sockname() and hence a glibc wrapper. 64 bit x86 probably has the syscall
dmoseley has quit [Client Quit]
dmoseley has joined #yocto
matthias_de has quit [Quit: Client closed]
prabhakar has quit [Quit: Connection closed]
dmoseley has quit [Client Quit]
rfuentess has quit [Remote host closed the connection]
bps2 has quit [Ping timeout: 245 seconds]
prabhakar has joined #yocto
prabhakarlad has joined #yocto
florian has quit [Quit: Ex-Chat]
dmoseley has joined #yocto
dmoseley has quit [Client Quit]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Xagen has joined #yocto
dmoseley has joined #yocto
florian_kc has quit [Ping timeout: 246 seconds]
dmoseley has quit [Client Quit]
zpfvo has quit [Quit: Leaving.]
dmoseley has joined #yocto
Thorn has quit [Ping timeout: 250 seconds]
mckoan is now known as mckoan|away
dmoseley has quit [Client Quit]
dmoseley has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 246 seconds]
frieder has quit [Remote host closed the connection]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rfs613>
rburton: how are you accessing it? via stat(2) or similar call, you get 'struct timespec' which are UTC. But if you use stat(1) command, it will display those timestamps in the current system timezone. You can set TZ=UTC to see the difference.
<rfs613>
rburton: hmm, "this method returns a floating-point value" ... so Python is evidenly doing some conversion. Maybe just the obvious one... or maybe not... hard to know ;-)
kpo has joined #yocto
<rfs613>
but some quick tests seems to confirm it is UTC
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has joined #yocto
beroset has quit [Quit: Client closed]
Xagen has joined #yocto
pvogelaar has joined #yocto
beroset has joined #yocto
florian_kc has joined #yocto
<tgamblin>
Has anyone encountered broken pipe and/or "sed: couldn't flush stdout: resource temporarily unavailable" errors when trying to run the python3-ptests in a local build, and know if there's specific qemuparams or local.conf changes needed to get around that?
pabigot has quit [Ping timeout: 260 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kpo has quit [Ping timeout: 245 seconds]
mvlad has quit [Remote host closed the connection]
<tgamblin>
s/python3-ptests/python3 ptests/
Xagen has joined #yocto
Xagen has quit [Client Quit]
Xagen has joined #yocto
adrian_ has quit [Ping timeout: 240 seconds]
Xagen has quit [Client Quit]
Xagen has joined #yocto
pvogelaar has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<rburton>
tgamblin: is that with a ptest that runs sed on the output? I wrote some code so you don’t need to do that if it uses unittest or pytest. The actual python3 ptest are a special case though right now.