chep has quit [Read error: Connection reset by peer]
chep` has joined #yocto
chep` is now known as chep
chep has quit [Client Quit]
chep has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
bhstalel has joined #yocto
MrTatillon has joined #yocto
wooosaiiii has quit [Ping timeout: 272 seconds]
wooosaiiii has joined #yocto
Bardon has joined #yocto
mvlad has joined #yocto
florian has quit [Ping timeout: 245 seconds]
florian has joined #yocto
florian has quit [Ping timeout: 248 seconds]
amitk has joined #yocto
Saur_Home62 has quit [Quit: Client closed]
Saur_Home62 has joined #yocto
florian has joined #yocto
mckoan is now known as mckoan|away
florian has quit [Ping timeout: 276 seconds]
<rburton>
kanavin: i'm surprised the ptests pass for py313 on armv5 as its not just the mimallo that uses that instruction, but the object code itself
<kanavin>
rburton, did you test them?
<kanavin>
the ptests?
<rburton>
kanavin: nope, i was away all friday
<kanavin>
because AB doesn't do it
<rburton>
i assumed thats how you found the crash
<kanavin>
rburton, no, it was found via runtime python test which only does rot13 on Hello World string
<kanavin>
and that does pass
<kanavin>
after the fix
<rburton>
hm curious
<kanavin>
rburton, the bug looks ok though, if mrc isn't being hit now, it may be hit later on with further code changes
alcroito has left #yocto [#yocto]
<kanavin>
better to eliminate it completely from the binary
<rburton>
right
<kanavin>
rburton, perhaps you could create a pull request as well? Otherwise we'll be waiting weeks if not more for someone to make a decision, but with a pr things will move quicker.
<kanavin>
Even if you're not sure which option is better, just pick one.
<rburton>
kanavin: i've copied in our resident-at-arm python maintainer so i'll see what he suggests
<rburton>
i'd have to get approval from him to push a MR anyway thanks to legal process so there's no change to timeline :)
Saur_Home6 has joined #yocto
Saur_Home62 has quit [Ping timeout: 256 seconds]
DharmeshRobertBo has joined #yocto
<DharmeshRobertBo>
I am facing issue when upgrade package Bind V9.11.37 to V9.18.24 in Dunfell Yocto.
<DharmeshRobertBo>
error MSG: Dhcp isc/boolean.h not a file or directory.
<DharmeshRobertBo>
please help to resolve this error.
<JaMa>
DharmeshRobertBo: Dunfell is out of support
<DharmeshRobertBo>
| In file included from ../includes/dhcpd.h:91,
<DharmeshRobertBo>
| from dhcp4o6.c:28:
<DharmeshRobertBo>
| ../includes/omapip/isclib.h:51:10: fatal error: isc/boolean.h: No such file or directory
<rburton>
you'll have to debug where that file should be and why it isn't there, or where it is and why the build isn't looking there. If you're doing the upgrade we don't have the files that you have.
<DharmeshRobertBo>
Tried multiple scenario to resolve the errors, like adding files manually but then there are other dependency files, then it is dhcp related errors facing,
<DharmeshRobertBo>
$ bitbake bind
<DharmeshRobertBo>
this is compiled success but when $bitbake core-image-minimal that time it getting failure with dhcp other macro/ typedef missing like that.
<kanavin>
then you need to update dhcp as well
<kanavin>
or better, just update to kirkstone or scarthgap
<DharmeshRobertBo>
Tried with dhcp V4.4.2 to V4.4.3 Scarthgap also but same errors.
<kanavin>
backporting to old yocto is unpredictable and difficult at the same time
DharmeshRobertBo is now known as Dharmesh1234
florian has joined #yocto
Dharmesh1234 has quit [Quit: Client closed]
<MrTatillon>
Hi,
<MrTatillon>
I'm stacking my problems with shared-mime-info-native build.
<MrTatillon>
looks like you need more c++ headers on the host
<MrTatillon>
the file system is part of libstdc++
<MrTatillon>
”
<MrTatillon>
I installed libstdc++33, but no better
<MrTatillon>
My Zypper can't update gcc-c++
<MrTatillon>
ChatGPT told me “This means that your version of the GNU C library (glibc) is obsolete” but Zypper told me I was up to date.
<MrTatillon>
I don't understand why it's so complicated to build with an officially supported distribution?
<MrTatillon>
Do you know what other distribution I could use to have fewer compilation problems?
<MrTatillon>
Translated with DeepL.com (free version)
<rburton>
MrTatillon: did you do as the docs say and ran "sudo zypper install python gcc gcc-c++ git chrpath make wget python-xml diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip python3-pexpect xz which python3-Jinja2 rpcgen zstd lz4 bzip2 gzip hostname libacl1"
<rburton>
also i see the autobuilder configuration uses buildtools, so possibly the docs are out of date. run install-buildtools and then activate the buildtools environment first.
rm5248 has joined #yocto
<rm5248>
hello, I'm upgrading a Yocto project of mine(Kirkstone->Scarthgap) and it's failing when doing the sysroot native. Python3 has a problem with: ModuleNotFoundError: No module named 'imp'. Has anybody seen this before?
<MrTatillon>
rburton yes I did
<MrTatillon>
Ok, I will look at run install-buildtools
<rburton>
rm5248: sounds like your host distro is too new, can you paste more of the log? this is probably fixed already
<rm5248>
I'm using Debian 12 which worked fine with kirkstone, I'd be surprised if that is too new
<rburton>
dnf will be running in our native python, which is newer. but that suggests that your dnf is not the one we ship, as that works
<rm5248>
that sounds correct, it feels like there is a caching issue someplace but I'm not sure where. I did try cleaning the dnf recipe
<rburton>
delete tmp, try again. the sensible thing to do would be a fresh clone of poky on the right branch, clean build dir, no other configuration, just build an image (which uses dnf by default). if that works you know the problem is with you, not yocto itself.
<sofsal>
HI. I'm trying to use systemd-nspawn containers in my yocto image. I haven't been able to make it work, so I was wondering if anyone knows of a course or a person who can help
<sofsal>
I'll appreciate any recommendations
mbulut has quit [Ping timeout: 244 seconds]
<rburton>
sofsal: can you expand on 'make it work'
<rm5248>
Hmm.... I cleaned my tmp dir but I still have problems with dnf. My CI machine(running ubuntu, not debian) is also failing with the same problem.
<rburton>
rm5248: did you try with a pristine poky?
<rm5248>
Not yet, let me try that.
<rm5248>
I'll also try a full clean build tonight to see if that fixes anything.
rfuentess has quit [Remote host closed the connection]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
mjm has joined #yocto
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #yocto
sotaoverride has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
Saur_Home6 has quit [Quit: Client closed]
Saur_Home6 has joined #yocto
Saur_Home37 has joined #yocto
bhstalel has quit [Quit: Client closed]
Saur_Home6 has quit [Ping timeout: 256 seconds]
<kanavin>
rburton, I'd rather skim the slides
florian has quit [Quit: Ex-Chat]
aduskett has quit [Quit: Konversation terminated!]
<khem>
rber|res:are you passing right flags to compiler to it builds for 1. correct ABI 2. Uses PIC/PIE
<khem>
r7 is framepointer on arm 32bit ABI can not be clobbered without permission
<rber|res>
@khem: I am trying to build something which has syscalls as a dependency and the problem is syscalls - https://github.com/jasonwhite/syscalls
<rber|res>
You mean I will need to patch it?
<rburton>
kanavin: lots of content that isn't in the slides to be honest
<khem>
rber|res:yes, and perhaps its using thumb1 ISA, what is your target machine ?
<khem>
yes it does. another common glitch OE stuff falls into is our tuples are not same as rust or llvm's understanding, e.g.ull compiler cmdline for specifying ABI
<khem>
they deduce it from triplet/tuple
<khem>
so it might be using arm-poky-linux-gnueabi and deciding its a 32bit soft-float ARM ABI without thumb support
<rber|res>
hmm
<khem>
so look into build.rs for such logic
<khem>
OE differs from rest of linux distros on this
<rber|res>
I am waiting for a build to finish and will give it a try - thanks
PhoenixMage has joined #yocto
sofsal has quit [Quit: Client closed]
florian has joined #yocto
<rber|res>
Hardcoded it builds, but I am trying to find out the tuple to compare against
Saur_Home91 has joined #yocto
Saur_Home37 has quit [Ping timeout: 256 seconds]
tangofoxtrot has quit [Ping timeout: 246 seconds]
tangofoxtrot has joined #yocto
_lore_ has quit [Ping timeout: 272 seconds]
_lore_ has joined #yocto
<khem>
thumb*-*-gnueabihf
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<rber|res>
armv7-resy-linux-gnueabihf seems to be a winner
<derRichard>
i'm a bit confused by meta-freescale (scarthgap), what is supposed to provide virtual/libgbm when mainline-bsp is used?
Saur_Home91 has quit [Quit: Client closed]
Saur_Home91 has joined #yocto
<rber|res>
@khem I guess I will need to patch in my other recipe, where syscalls is a dependency the same thing again and DEPENDS or so does not really work
<rber|res>
also I had to use some NOLOCK trick to get it to compile, since it wants to update Cargo.lock
Saur_Home75 has joined #yocto
Saur_Home91 has quit [Ping timeout: 256 seconds]
Kubu_work has quit [Quit: Leaving.]
<derRichard>
note to myself: add opengl to distro features, mesa seems to provide all of that :D
jmiehe has joined #yocto
jmiehe has quit [Quit: jmiehe]
Saur_Home39 has joined #yocto
mvlad has quit [Remote host closed the connection]
Saur_Home75 has quit [Ping timeout: 256 seconds]
Vonter has quit [Ping timeout: 252 seconds]
<rber|res>
Hmm syscalls builds now, but I would like to build lurk-cli and this seems to be more tricky