<khem>
paulg:no wonder why no one replies to my emails these days
<paulg>
khem, in a way that is a blessing? Take it as plausible deniability?
<khem>
yeah it is :)
Axman6 has joined #yocto
<Axman6>
G'day all, I'm trying to use the python tracemalloc module but it doesn't seem to exist in our python install. Is there a way to either build it as an ipk, or specify that our python package should be compiled with it?
<khem>
Axman6:its a builtin module I think
<Axman6>
That's what I thought, but it isn't available. We're using python 3.9, import tracemalloc fails and sys.builtin_module_names reports ('_abc', '_ast', '_codecs', '_collections', '_functools', '_imp', '_io', '_locale', '_operator', '_peg_parser', '_signal', '_sre', '_stat', '_string', '_symtable', '_thread', '_tracemalloc', '_warnings', '_weakref', 'atexit', 'builtins', 'errno', 'faulthandler', 'gc', 'itertools', 'marshal', 'posix', 'pwd', 'sys', 'time', 'xxsubtyp
<Axman6>
e')
<Axman6>
Looking at the cpython repo, i can't even say a way to disable it, I was hoping I could find somewhere where yocto was turning it off, apparently not. (not that I have a very good feel for how packages are built in yocto)
<khem>
Axman6: yocto cross compiles python3 and at times some modules may fail to build as they may be poking for stuff on build host
<khem>
so perhaps look into build logs of python for some hints
<Axman6>
Hmm, ok, will do
<Axman6>
well I found ./tmp-glibc/work/cortexa9t2hf-neon-oe-linux-gnueabi/python3/3.9.9-r0/build/config.log but there doesn't appear to be anything relevant in there
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #yocto
Jones42 has quit [Ping timeout: 252 seconds]
Jones42 has joined #yocto
Daanct12 has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
Perflosopher03 has joined #yocto
kanavin_ has joined #yocto
kanavin has quit [Ping timeout: 276 seconds]
<khem>
yeah thats perhaps right place to see if some test failed and disabled building this module
enok has quit [Ping timeout: 245 seconds]
<Axman6>
Not that I can see, doing a search in `/build`, I can find _a lot_ of tracemalloc.cpython-39.pyc files, but apparently they aren't on the device itself. Since doesn't come from a python package, I'm not sure how I'd build it separately
enok has joined #yocto
<Axman6>
Hmm, ingterestingly I can see in meta/recipes-devtools/python/python3/python3-manifest.json a bunch of files under "core" - I wonder if I can cargo cult this...
enok has quit [Remote host closed the connection]
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.5.2]
Daanct12 has joined #yocto
savolla has joined #yocto
alessio has joined #yocto
goliath has joined #yocto
frgo has joined #yocto
rber|res has joined #yocto
mbulut has joined #yocto
mckoan|away is now known as mckoan
mbulut has quit [Ping timeout: 244 seconds]
florian_kc has quit [Ping timeout: 252 seconds]
dgriego has quit [Ping timeout: 260 seconds]
dgriego has joined #yocto
dmoseley_ has joined #yocto
dmoseley has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
alessio has quit [Quit: alessio]
florian has joined #yocto
alessio has joined #yocto
rfuentess has joined #yocto
frgo has quit [Remote host closed the connection]
ptsneves has joined #yocto
florian has quit [Ping timeout: 268 seconds]
olani- has quit [Ping timeout: 260 seconds]
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
florian has joined #yocto
ptsneves has quit [Ping timeout: 265 seconds]
Tyaku has joined #yocto
leon-anavi has joined #yocto
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
Jones42 has quit [Ping timeout: 244 seconds]
<qschulz>
khem: that I can do nothing about sadly, this is a report you need to make to b4 community
<qschulz>
FWIW, I agree that this is unnecessary
florian_kc has joined #yocto
Jones42 has joined #yocto
florian has quit [Ping timeout: 265 seconds]
florian_kc has quit [Ping timeout: 265 seconds]
ptsneves has joined #yocto
Ad0 has quit [Ping timeout: 248 seconds]
alcroito has joined #yocto
florian has joined #yocto
florian_kc has joined #yocto
<landgraf>
TIL overlay-etc feature causes double mounting of /sys and shadowing of /sys/firmware/efi/ :-/
<rber|res>
Hi, Is there any kind of Delphi support available in the YP/OE? Don't ask why ;)
<RP>
rber|res: I've never seen that but I've never looked either
alcroito has left #yocto [#yocto]
Ad0 has joined #yocto
<JaMa>
rber|res: it's been 10+ years, but is Kylix or Lazarus still a thing for Delphi on linux? https://crosskylix.untergrund.net/ has some news even from 2017 :)
<rber|res>
@JaMa it should run on am32 - something link imx6
mihai has quit [Quit: Leaving]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
pidge has joined #yocto
<rburton>
Axman6: use the tools: $ oe-pkgdata-util find-path **/tracemalloc.py
<treje>
Hello everyone, I noticed that the yocto server is not responding.
<rburton>
yes, reported to admin
<treje>
Ok thank you so much rburton ! Do you happen to know when it will be back online ?
<mario-goulart>
BTW, out of curiosity, are the web code browsers of Yocto being affected by those evil crawlers that do not respect robots.txt? I don't mean right now, specifically, but in general.
<rburton>
treje: no idea, i'm not the admins and it depends on whats broken
Guest35 has joined #yocto
Guest35 has quit [Client Quit]
<treje>
ok thz rburton !
frgo has quit [Remote host closed the connection]
Guest51 has joined #yocto
Guest35 has joined #yocto
<RP>
mario-goulart: we're being hit hard by AI crawlers :(
<RP>
ivand: no, it has been reported, we're waiting on sysadmins being around
<rburton>
worked example of why irc's lack of history when you connect is a problem :)
ptsneves has quit [Ping timeout: 244 seconds]
<ivand>
my bad -- reconnected and missed a bunch of history since yesterday, thought it's loaded automatically
frgo has joined #yocto
mbulut has joined #yocto
mbulut has quit [Ping timeout: 244 seconds]
<mario-goulart>
RP: I feared. I had to convert a gitweb instance to static pages with crawler traps to be able to mitigate the attacks... It's a real plague of modern times.
<RP>
mario-goulart: We share setup with kernel.org and both are struggling
enok has joined #yocto
Xagen has joined #yocto
|Xagen has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
frgo has quit [Remote host closed the connection]
frgo has joined #yocto
Xagen has quit [Ping timeout: 268 seconds]
frgo has quit [Ping timeout: 244 seconds]
frgo has joined #yocto
ivand has quit [Ping timeout: 240 seconds]
sakoman has joined #yocto
florian_kc has quit [Ping timeout: 245 seconds]
florian has quit [Ping timeout: 248 seconds]
florian_kc has joined #yocto
florian has joined #yocto
enok has quit [Ping timeout: 246 seconds]
cyxae has joined #yocto
florian_kc has quit [Ping timeout: 246 seconds]
eduter has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
enok has joined #yocto
<eduter>
Hi all.
<eduter>
I am seeking for advice on the following task. I am intending to update my Yocto distro from kirkstone up to scarthgap. I have read the recommended way of doing this is to transition through each release in-between until I reach out scarthgap. Going through each "migration" document for each of the releases I need to transition into.
<eduter>
Is my understanding of this process correct?
<eduter>
Would it be a bad idea or a not-recommended idea trying to update directly from kirkstone to scarthgap?
<eduter>
In advance thanks for any kind of advice, suggestion or comment on this.
enok has quit [Client Quit]
enok has joined #yocto
<rburton>
eduter: either works - one larger migration or a few smaller ones (although the intermediate releases are EOL, so don't release anything based on them)
<eduter>
rburton thanks your message. I was hoping I could attempt to go through this process by doing a lone large migration, but then I read in some forums that they were recommending to go through smaller ones. I guess I will try doing one large and see how it goes. Thanks for your time and guidance :-)
<rburton>
eduter: just be sure to read all the intermediate migration guides so you know about all the changes
<JaMa>
eduter: it depends on how big layer you're migrating, I find it significantly easier to at least build test the intermediate releases as well to e.g. separate gcc-13 related issues which were introduced in different release than e.g. usrmerge, ideally you should also set some CI to track master as well, because it's even easier of you test e.g. gcc-15 upgrade in isolation, so you can fix all gcc-15 related
Jones42 has joined #yocto
<JaMa>
issues in one go (and you know that all build regressions in your layer are caused by gcc upgrade in that time)
<eduter>
JaMa Hi Jama, thanks a lot for your time and information. I am a kind of newbie on Yocto... I guess I am not aware of the gcc issues you are talking about... the gcc version kirkstone is using currently is 11.4.0
<JaMa>
e.g. for our LGE layers, gcc-15 itself causes 50 recipes from our layers (not counting meta-oe/oe-core recipes) to fail
<JaMa>
eduter: and scarthgap has 13.3.0. If your layer has only well written software then you might not even notice a change, but if you have a lot of legacy code which is not really actively maintained, then you might find a lot of issues when new gcc is used
<eduter>
JaMa does that mean that recipes from the Yocto project layers which require gcc to be compiled will failed... because the new available version of gcc on either (langdale, mickeldore, nanbield or scargthgap) is causing some errors?
<eduter>
JaMa got you! In my "custom layer" I do not recall having any recipe for building up a component implemented in C/C++ which may require gcc to be built/compile...
<JaMa>
other layers will hopefully be already updated by other people, I was talking about your own software
<eduter>
JaMa I have mainly components using shell scripts or RUST
<eduter>
JaMa Yes, understood. Only my "custom layer" and my "custom recipes" :-)
<eduter>
JaMa besides the fact that it is time to upgrade the Yocto release distro to scarthgap which is the next LTS since kirkstone... I am also interested in getting the RUST tool chain to avoid having to use the "meta-rust" layer.
<JaMa>
then I guess you're not in "big layer" category :) our repo has 2000 recipes and 2000 bbappends and a lot of it is for our own software (or forks of existing FOSS components)
frgo has quit [Ping timeout: 276 seconds]
<eduter>
JaMa I can confirm to you (Even though I am still a bit of a beginner in the Yocto world) that I am not using 2000 recipes in my "custom layer" xD.
<eduter>
JaMa so maybe I could give it a try and attempt to update from kirkstone LTS to scarthgap LTS? and see how it goes??
<eduter>
JaMa by the way, thanks a lot for your time. Conversations or comments like yours help me a lot to learn and catch new details or new stuff about Yocto context in general!!!!
<JaMa>
sure and if you find that it's difficult to figure it all out in one go, you can always do the build test with intermediate releases later
<eduter>
JaMa super! I will keep that in mind as "a good practice", to take things little by little.
<vmeson>
yocton: godbolt didn't ICE forall v 10.2 versions but only a couple of iterations so YMMV.
<yocton>
nope :>
<yocton>
vmeson: I also tried godbolt a bunch of times => no crashes but I guess they don't run the Debian g++
<vmeson>
yocton: so it seems
alessio has quit [Quit: alessio]
LainExperiments has joined #yocto
goliath has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
olani has quit [Remote host closed the connection]
olani has joined #yocto
Guest51 has quit [Quit: Client closed]
LainExperiments has quit [Ping timeout: 240 seconds]
mckoan is now known as mckoan|away
enok has quit [Ping timeout: 265 seconds]
rfuentess has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
leon-anavi has quit [Quit: Leaving]
047ABD9UT has quit [Ping timeout: 260 seconds]
078AA6DO6 has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
grma has quit []
grma has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
florian has joined #yocto
savolla has joined #yocto
florian_kc has joined #yocto
enok has joined #yocto
geoffhp has quit [Remote host closed the connection]
geoffhp has joined #yocto
eduter has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc is now known as florian
eduter has quit [Quit: Client closed]
eduter has joined #yocto
<eduter>
JaMa hello again JaMa, sorry I had to leave before fast. Thanks a lot for the link pointing to the errors. I will have a look at it now, out of curiosity!
<eduter>
JaMa I was not aware of this "errors.yoctoproject.org" website and the reported errors.
ivand has quit [Quit: Client closed]
GillesM has joined #yocto
GillesM has quit [Client Quit]
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #yocto
<khem>
eduter: keep in mind that rust compiler also gets updated between two different releases, so the gcc problem JaMa mentioned will occur for rust too, where your rust components might have dependencies or assumptions that worked with old rust compiler but do not work with new compiler anymore
<khem>
rust editions might help with some portability but not all
<eduter>
khem thanks for highlighting that this could be an issue as well for Rust compilers! In order to compile my RUST component, I had to add the "meta-rust" layer because I needed a newer toolchain than the one shipped in "kirkstone" (1.59). I added "meta-rust" layer and selected Rust toolchain "1.82". I think (I do not remember 100%) that "scarthgap"
<eduter>
comes with "1.82" or newer Rust toolchain, which might mean for me that the "meta-rust" layer is not needed anymore, maybe? I will test this at some point. Nevertheless, I think in my case it would be great to get a newer Rust toolchain available from "scarthgap" POKY distro release :-)
<RP>
eduter: this is what the mixin layers are intended for (newer rust or other components on LTS)
<khem>
yeah if you are inclined that way then you wont be disappointed
<eduter>
RP and khem I think it was necessary to use "meta-rust" layer due to the toolchain version, but if "scarthgap" LTS is providing a newer toolchain version then it should be positive for my needs :-)
<khem>
yocton:I looked at the clang code, there is no existing knob to expose this to build, I think it would have been good that way to add a packageconfig for dexp and disabled the knob by default so leave an easy way to enable it for folks who do not have other options than to use debian11
<khem>
I think a cmake option to enable/disable it might be good. perhaps something upstream would also accept
<yocton>
Ok, I'll work towards that :)
<khem>
and I am perfectly fine if we said clang does not work on debian11
ello has joined #yocto
<khem>
technically, there is another way, to bootstrap clang-native which would remove host compiler dependency but it adds to build time
ello_ has joined #yocto
<khem>
thats actually right way to build compilers but we try to save some build time by adding reliance on build host compilers, but given the matrix of distros we support maybe thats a better option
vThor has joined #yocto
<RP>
khem: it is more how we'd make the autobuilder handle that :/
<RP>
eduter: I guess my point is that the mixins approach was the way we're trying to encourage people to solve this for the LTS, so please do at least see if the rust upgrades for kirkstone/scarthgap work for you
<khem>
Practically, we have either forced to used buildtools everywhere or containerized the distro used to build yocto becuase there always were problems if user picked their favourite distro
<khem>
initially I was promoting the host OS independence but it only goes so far
<RP>
khem: I think we still manage a reasonable level of compatibility, we just need to document and detect the limits :/
<RP>
khem: it is the outlying layers where the real challenges tend to be
<RP>
khem: did you test that gomod fetcher change btw?
<khem>
gomod not yet havent gotten around it yet
<RP>
khem: ok, np. Just trying to decide what to do with patches
<eduter>
RP I may not have understood your point at first RP. What I understood from "mixins approach" is that in scarthgap LTS now the recipes and newer Rust toolchains available in the "meta-rust" layer, have been "mixed" inside the LTS "scarthgap" so there is no need to have an extra "meta-rust" layer? I will definetely test if I can build my RUST recipe
<eduter>
on "scarthgap" without using "meta-rust" layer :-)
<khem>
RP: yes I wish products just were built using core layer even then people do not want to use the supported N version of Fedora but they want the version they use on their desktop
ello_ has quit [Ping timeout: 246 seconds]
ello has quit [Ping timeout: 246 seconds]
<khem>
if you allow build distro freedom, in reality it means more than 1 distro could be used but with certain versions of those distros only, same dev works on products which are based on kirstone, some are dunfell and some are scarthgap, so either they have VMs or somehow contained the build OS.
<khem>
anyway those are just my problems :)
<RP>
khem: buildtools is the easier workaround for that
ello has joined #yocto
ello_ has joined #yocto
enok has quit [Ping timeout: 245 seconds]
<khem>
yes it is and perhaps should be used universally
<khem>
I think people will build less container based envs if it was default
wooosaiiii has quit [Remote host closed the connection]
wooosaiiii has joined #yocto
<khem>
JaMa:the krb5 changes for gcc15 seem to break its build when using clang20