<usvi>
rburton: the simple helloworld project builds always with same checksums. the more complex canbus-handler project is path-dependant
rfuentess has joined #yocto
mckoan_ has joined #yocto
mckoan|away has quit [Ping timeout: 248 seconds]
Algotech has quit [Ping timeout: 252 seconds]
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
dmoseley has quit [Ping timeout: 276 seconds]
Kubu_work has joined #yocto
dmoseley has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<usvi>
I got an idea. I will peel off stuff from canbus-handler until it resembles the helloworld
florian has joined #yocto
<usvi>
do intermediate builds and check when does the checksum stabilize
leon-anavi has joined #yocto
<usvi>
ok my idiot workmate had bundled in a stupid watchdog .so which is not stripped
merit has quit [Remote host closed the connection]
merit has joined #yocto
guest20 has joined #yocto
Articulus has quit [Quit: Leaving]
merit has quit [Remote host closed the connection]
merit has joined #yocto
merit has quit [Remote host closed the connection]
merit has joined #yocto
ehussain has joined #yocto
merit_ has joined #yocto
merit has quit [Remote host closed the connection]
merit_ is now known as merit
wojci has joined #yocto
<rburton>
unstripped is fine assuming it gets the right debug path remapping done
<rburton>
honestly i please just run diffoscope across two of your packages and it will tell you what the problem is
<usvi>
I will
olani- has joined #yocto
olani_ has joined #yocto
prabhakalad has joined #yocto
<RP>
usvi: which version of yoctoproject/bitbake are you seeing this on?
<RP>
usvi: actually, I don't think it is what I was wondering about so ignore me. As rburton says, seeing what changed is important. Even running strings on the two binaries and comparing may be insightful
olani- has left #yocto [Using Circe, the loveliest of all IRC clients]
olani_ has left #yocto [Using Circe, the loveliest of all IRC clients]
olani has quit [Remote host closed the connection]
olani has joined #yocto
<usvi>
(it seems diffoscope is failing to start. displays a curl/wget download prompt and hangs in there forever but this is ubuntu issue, not yocto issue)
<usvi>
it is listing location of this single hpp file with full path
<RP>
usvi: that at least gives a hint at which build of the build/code might be struggling. I'd look at where that header is used and then at the compile logs and see what commands are being used to compile it
<usvi>
(compiling the program with make on host without yocto and running strip+strings shows /usr/include/nlohmann/json.hpp , so nlohmann or build imprints the header name inside the binary => not a yocto problem)
<qschulz>
IIRC we had already forked opkg and maintained most of it ourselves but openwrt won't be using opkg anymore going forward
<RP>
qschulz: we were the original!
<qschulz>
Ah, one more thing openwrt forked then and is regretting (hello Buildroot :D)
<RP>
we took it over from handhelds.org, kind of, with the name change from ipkg to opkg
<qschulz>
RP: so this changes nothing for us I guess
<RP>
qschulz: no
<qschulz>
except that we lose one big user of the package manager, though it was probably heavily forked
<qschulz>
RP: thanks for the history lesson :)
<RP>
qschulz: I'm not sure we've seen many patches from them
<RP>
qschulz: its a crazy history!
xmn has quit [Quit: ZZZzzz…]
ehussain has quit [Remote host closed the connection]
rob_w has quit [Remote host closed the connection]
<rburton>
qschulz: i'm really interested in apk though and do wonder if we should integrate it.
<rburton>
pretty sure there's at least two wip branches for integration and a package manager that has wide adoption is good
<qschulz>
rburton: IIRC there was an attempt at supporting apk a few years ago
<usvi>
every header inclusion includes the path /_\
<rburton>
qschulz: the refactoring of the package code was motivated by an out-of-tree apk backend but i can't remember where it is
xmn has joined #yocto
sakoman has quit [Ping timeout: 252 seconds]
ptsneves has joined #yocto
goliath has joined #yocto
<LetoThe2nd>
if I want to inject version specific patches, shouldn' t FILESEXTRAPATHS:prepend := "${THISDIR}/${PV}:" in the xxx_%.bbappend do the trick? So as long as the patch files in the various PV-named directories are named the same, I'd expect the right one to be picked up. But bitbake doesn't seem to find them.
<rburton>
LetoThe2nd: PV is already in the search path
<rburton>
well, PN-PV/ is
<LetoThe2nd>
rburton: ok?
<LetoThe2nd>
rburton: so in my example I would expect u-boot-2024.04 to be picked up, but nay :-(
<rburton>
oh right bbappend, yeah you'll need to add it
Wouter01002 has joined #yocto
Chaser has quit [Ping timeout: 252 seconds]
<LetoThe2nd>
rburton: is there a way to dump the search path generation? something is just not like I expect it.
<rburton>
yeah its just a bitbake variable, so bitbake-getvar
<rburton>
or the fetch log will list where its looking
vquicksilver has quit [Ping timeout: 245 seconds]
sakoman has quit [Ping timeout: 255 seconds]
<LetoThe2nd>
the fetch log (a.k.a. error) is about 200 lines, and manually reading it not exactly a lot of fun.
<LetoThe2nd>
and the entries relative to the bbappend don't seem to have ${PN}-${PV}, but always defaultpkgname-1.0
<ak77>
hmm.. is there a way to prevent modesetting during boot, let weston do the modesetting? (rpi4)
vquicksilver has joined #yocto
sakoman has joined #yocto
Chaser_ has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
<jdiez>
hi, i have about a gigabyte of files in /opt/$sdk/$version/sysroots/$target/usr/lib/openssl/ptest. how can I exclude those from the sdk build? I don't have `ptest-pkgs` in SDKIMAGE_FEATURES
<rburton>
jdiez: what release?
<jdiez>
scarthgap
<rburton>
jdiez: SDKIMAGE_FEATURES talks about the native part of the sdk, so you have ptest in DISTRO_FEATURES. brute force: turn off ptest entirely if you don't want it. or set PTEST_ENABLED=1 in a openssl bbappend. ptest shouldn't in the sdk sysroots so that's a bug for sure.
<jdiez>
oe-pkgdata-util says these files are owned by openssl-dbg. I also have removed `dbg-pkgs` from my SDKIMAGE_FEATURES
<rburton>
ah i knew this was familiar
<rburton>
one solution would be to cherry-pick dfaf1cba9f30c6b07836fe217e1ebc83bc6aec8a and 92f09a4269e45e09643a7e7aafd2811cfd47cb68
<jdiez>
from openembedded (i assume) or poky?
<jdiez>
hm dont see those commits on either repo
<rburton>
those are oe-core shas
<jdiez>
thank you
<mischief>
i seem to have a bug with icecc not being used by out-of-tree kernel recipes
<LetoThe2nd>
rburton: so yeah the ${PN}-${PV} definitely expands to "defaultpkgname-1.0", which feels extremely unintended to me.
jclsn has quit [Quit: WeeChat 4.4.3]
<rburton>
LetoThe2nd: how are you determining that?
<LetoThe2nd>
rburton: inspecting FILESEXTRAPATHS in bitbake -e
<rburton>
maybe its evaluating too early, that would be annoying (thank to the :=)
<Saur>
rburton: We have a meta-apk layer that was never taken into production and noone has worked on it for a couple of years due to personnel changes.
<LetoThe2nd>
rburton: hints on how to change it?
<rburton>
LetoThe2nd: not sure you can from a bbappend
<rburton>
you need to use := to get the right THISDIR but then you can't use PV as it hasn't been determined yet (afaict)
<rburton>
maybe just use files/ and embed PV into the filename of the patch (bit ick)
<JaMa>
git grep branch_meta-qt6 '6\.6\.0' doesn't show any other place in yocto-autobuilder2 nor yocto-autobuilder-helper still using 6.6.0
<mathieudb>
JaMa: hmmm, let me check
<qschulz>
LetoThe2nd: that's something I was bothered about too a few years ago
<qschulz>
I think this would be a very good addition to bitbake-getvar or something like that
<qschulz>
or oe-something-util-whatever
<qschulz>
but I never got the time to look into it and now I barely do stuff in Yocto anymore :/
jclsn has joined #yocto
<LetoThe2nd>
qschulz: yeah possibly. I'm just doing way too little real hands on too, and if I do then its most build testing.
<mathieudb>
JaMa: it seems correct in the configuration, maybe the autobuilder was not restarted since this modification
<mathieudb>
RP: any clue about this ? Was the ab restarted in the past 10 days ?
<JaMa>
mathieudb: ok, lets see what happens when the build is started
<mathieudb>
JaMa: this build will likely use 6.6.0. I believe we have to restart the whole autobuilder service
<JaMa>
it might build fine with 6.6.0
<JaMa>
I was just surprised to see it and was wondering if it fetches the current configuration when the build is started, I didn't know that it needs restart to refresh yocto-autobuilder2
<JaMa>
ah valkrie was updated and this is the "old" autobuilder?
<rburton>
ah yeah don't look at typhoon
adadad has joined #yocto
<mathieudb>
Oh, I didn't pay attention ! Yes, probably typhoon was not restarted for a long time
<JaMa>
and I didn't notice that my old browser tab points to old AB and there was a build scheduled few hours ago, so I assumed it's just waiting in queue
xmn has quit [Read error: Connection reset by peer]
Xagen has joined #yocto
xmn has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
adadad has quit [Quit: ZNC 1.9.1+deb2+b1 - https://znc.in]
adadad has joined #yocto
adadad has quit [Quit: ZNC 1.9.1+deb2+b1 - https://znc.in]
adadad has joined #yocto
adadad has left #yocto [#yocto]
jclsn has quit [Quit: WeeChat 4.4.3]
steelswords94 has quit [Read error: Connection reset by peer]
steelswords94 has joined #yocto
pbiel has quit [Ping timeout: 272 seconds]
miau_miau has joined #yocto
gspbirel56 has quit [Ping timeout: 244 seconds]
rfuentess has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 248 seconds]
xmn has joined #yocto
druppy has joined #yocto
dankm has quit [Remote host closed the connection]
dankm has joined #yocto
<rburton>
zeddii: what's your plan for kernel upgrades before the next release?
alb3rt0 has joined #yocto
<rburton>
zeddii: are you skipping 6.11 and jumping straight to 6.12 when it comes out?
<alb3rt0>
do we have existing recipes for bitbake TI TMS320F2837?
<rburton>
alb3rt0: isn't that a microcontroller that can't run linux?
xmn has quit [Ping timeout: 252 seconds]
zpfvo has quit [Remote host closed the connection]
<zeddii>
6.12 and 6.6, + -dev at 6.13+
<zeddii>
6.1 deleted.
<alb3rt0>
rburton yes, I would like just bitbake and create the artifact
<RP>
JaMa, mathieudb: we probably need to reconfig or restart the controller
<rburton>
alb3rt0: you should ask TI if they have a layer to do that as they're active yocto developers. if your code is using zephyr then there's a meta-zephyr, for example
<RP>
JaMa, mathieudb: I'm fairly sure it was "reconfig"'d so it probably needs a full restart, which will kill all builds
<RP>
and I should have read on first, you worked that out :/
_whitelogger has joined #yocto
aliwithay has joined #yocto
aliwithay has quit [Client Quit]
xmn has joined #yocto
xmn has quit [Read error: Connection reset by peer]
gspbirel56 has joined #yocto
gspbirel56 has quit [Ping timeout: 252 seconds]
<rfs613>
RP: any feedback on my patch for make_last() in rootfs-postcommands?
ptsneves has joined #yocto
gspbirel56 has joined #yocto
xmn has joined #yocto
alb3rt0 has quit [Quit: Client closed]
RobW has joined #yocto
miau_miau has left #yocto [#yocto]
miau_miau_miau has joined #yocto
_whitelogger_ has quit [Remote host closed the connection]
jsbronder has quit [Remote host closed the connection]
druppy has joined #yocto
jsbronder has joined #yocto
_whitelogger_ has joined #yocto
carpincho has quit [Quit: Leaving.]
<RP>
rfs613: from what I remember it looked fine, I was waiting for it to get through testing
<RP>
I was a little surprised that code wasn't working
<rfs613>
RP: me too ;-)
<rfs613>
I had noticed that backup files (like /etc/shadow- with a dash on the end) were still present in the rootfs
<rfs613>
there's a task to clean those up, and it runs, but runs before users are created.
prabhakalad has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
cyxae has quit [Quit: cyxae]
cyxae has joined #yocto
cyxae has quit [Quit: cyxae]
cyxae has joined #yocto
cyxae has quit [Quit: cyxae]
cyxae has joined #yocto
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
tolnanwo has quit [Ping timeout: 260 seconds]
tolnanwo has joined #yocto
mbulut has joined #yocto
<usvi>
RP: ok, my stuff is finally fixed. the pure header library I was including in my code was caching the path for assert calls. I needed to prefix the inclusion with #define NDEBUG and the path is finally gone. not a yocto bug, sorry for the noise and thank you for your help
miau_miau_miau has quit [Ping timeout: 248 seconds]
tolnanwo has quit [Ping timeout: 260 seconds]
tolnanwo has joined #yocto
tolnanwo_ has joined #yocto
tolnanwo has quit [Ping timeout: 260 seconds]
tolnanwo_ has quit [Ping timeout: 260 seconds]
Kubu_work has quit [Quit: Leaving.]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
<rburton>
usvi: if its using __FILE__ then -ffile-prefix-map will rewrite the path for you anyway, so i'm curious how its getting the path without using __FILE__ or anything else that gets remapped by gcc if you use the correct flags