<RP>
JaMa: glad to have it tracked down a bit at least!
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
jtoomey has joined #yocto
jtoomey has quit [Read error: Connection reset by peer]
davidinux has quit [Quit: WeeChat 2.8]
davidinux has joined #yocto
ptsneves has joined #yocto
<ptsneves>
does anybody know how i can see the execution log of a self test?
<ptsneves>
-v does not show me much
coref[m] has quit [Quit: You have been kicked for being idle]
<rburton>
Saur[m]: commented on the bug
<RP>
ptsneves: it isn't easy, usually I look at the code and put in debug prints if needed
<ptsneves>
@RPS
<ptsneves>
RP Ok good to know. I am going this way. I will try to submit a patch to the docs stating that cls.logger.info or just using the logger is the way to do prints as print() does not show anything.
<RP>
ptsneves: sounds good, thanks!
<ptsneves>
i have another question. Is there any way to run a test without needing to wipe the build dir, including state cache and download dir? I just short-circuited the check that forces this but then i have a feeling the test does not run correctly. Any clues?
<rburton>
you don't need to do that?
<rburton>
i mean, why do you think you need to wipe a build dir to run a test
jpuhlman has quit [Ping timeout: 255 seconds]
jpuhlman has joined #yocto
davidinux has quit [Quit: WeeChat 2.8]
davidinux has joined #yocto
goliath has joined #yocto
amahnui1 has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
armhzjz has joined #yocto
armhzjz has quit [Quit: armhzjz]
<RP>
rburton: probably as selftest runs in it's own build directory
<RP>
ptsneves: firstly, configure a location for an sstate-dir and dl_dir and it will share those
<ptsneves>
rburton because otherwise i get "2022-05-26 12:51:43,826 - oe-selftest - ERROR - Build directory /home/pneves/Projects/yocto-superproject/poky/build-st already exists, aborting"
<rburton>
oh that's selftest being stupid. pass -j1
<ptsneves>
ModuleNotFoundError: No module named 'testtools'
<ptsneves>
:(
<RP>
ptsneves: pip install it?
bps3 has joined #yocto
<ptsneves>
without -j1 i did not have that error modulenotfound issue.
<RP>
rburton: the -j thing will just mean it creates a new dir each time. If you don't have a separate sstate/dldir configured it will do lots of rebuilding/downloading
<RP>
ptsneves: -j says "enable parallelism" which means instead of build-st it will use build-st-<PID>. It needs modules for parallelism
Guest43 has joined #yocto
<ptsneves>
ok. so that is not really what i am interested on. Furthermore the testtools in my pip3 takes me to errors.
<ptsneves>
+ self.logger.warning("Build directory %s already exists, assuming it is correctly configured" % newbuilddir)
<ptsneves>
+ return (builddir, newbuilddir)
<ptsneves>
bb.utils.mkdirhier(newbuilddir)
<ptsneves>
would this be fine to submit?
Guest43 is now known as Patrick2
<Patrick2>
Hi, I try to build for a TI processor the first time. As far as i understand i can chose if i want to use u-boot-spl or x-loader. Is there a way to chose that in meta-ti ?
<RP>
ptsneves: no, we don't "assume things are correctly configured". Instead we should have an explicit command line option
<RP>
ptsneves: I think other code will break as it assumes it has a clean build directory, not an existing one to try and beat into shape :(
<ptsneves>
ok, so is it worth to add such a command line option?
<RP>
ptsneves: I'll admit I sometimes want to do that but I don't know how well it will work
<RP>
I have hacked it locally to do this before myself :/
<RP>
I just worry about the bug reports as we don't support it
<ptsneves>
RP :( it's just that when developing a test cased needing to wipe everything every time is very unproductive
<RP>
ptsneves: see what I said above, you don't have to wipe sstate or dl_dir
leon-anavi has quit [Quit: Leaving]
<RP>
ptsneves: you can see the concern that the tests assume starting in a clean location, not trying to reconfigure something
<RP>
the tests are specifically designed to reuse sstate/dldir where possible
<ptsneves>
RP Yes i can understand. It just makes dev harder, but fixing that is not my goal so the patch proposal would be only as a nice to do. So on the re-use of SSTATE and DL_DIR should i use build/conf/local.conf or build-st/conf/local.conf for that? I am not sure which one is the "real" build dir for this case
leon-anavi has joined #yocto
<RP>
ptsneves: sefltest copies your local.conf so just configure somthing there in your normal build dir and selftest will reuse it
<ptsneves>
perfect!
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
<RP>
rburton, jonmason: good we closed the arm tiny bug but do we need to add to the automated qa?
nemik has quit [Ping timeout: 240 seconds]
<jonmason>
I build it in my gitlab ci
nemik has joined #yocto
<RP>
jonmason: this should probably be in the official test matrix too though? e.g. so the test results are in the releases etc?
<rburton>
would be good
<RP>
I can write the patch I guess?
<RP>
jonmason, rburton: qemuarm or qemuarm64? or both?
<jonmason>
I do all 3. The trick is that sshd doesn't start in tiny
<jonmason>
So all I do is ping
<RP>
jonmason: we're supposed to have some tests for tiny. Looking at the AB config, not sure they;'re run though :/
<jonmason>
I'm doing altcfg and rt kernels where they should work
<jonmason>
qemuppc rt is broken for me. I'll get around to looking at that eventually
<jonmason>
and getting ssh working on tiny is on my todo list
<RP>
jonmason: nice. We don't test -rt on the AB but there is an open bug for that
<jonmason>
It was working in the previous kernel
<jonmason>
And it should really be working on all the qemus
<jonmason>
When it's working I'll let you know. Then it'll be easy to add to the ab
<RP>
jonmason: we could just add the working ones now :)
<RP>
jonmason: that built ok so I'll enable it
<ernstp>
derRichard: which exact yocto version are you running?
<denix>
Patrick2: there's no x-loader - it has been dead and deprecated long ago
<Patrick2>
denix Ah, i see. I dont have a JTAG debugger at home, are there any possiblities to debug that? Or should I just invest in a simple debugger?
<Patrick2>
denix maybe i should add some information: It is an old Beaglebone 2009 C3; The MLO which comes out of the Yocto build is not booting, no output at all.
<denix>
Patrick2: that would depend on what you need to debug
<Patrick2>
denix * iam on dunfell. If I exchange the MLO (SPL), then its booting... SO i need to debug that.
<denix>
Patrick2: ah, that board is very old. I don't think it has been tested in years and it also got deprecated
<denix>
Patrick2: you can try #beagle and ask if there are any recent known good images (Debian, not Yocto) that support such old board
<denix>
are you Guest43 there?
<Patrick2>
denix most likely you are right, but i think its a bit sad, for my usage it will be more then enough. So as a start i could integrate the prebuilt MLO from the Internet i downloaded.
<Patrick2>
denix yes iam!
<Patrick2>
denix so an old Image from the website (2018) is working.
<denix>
Patrick2: well, that image was built from sources and sources are still available. it's just a matter to figure out what regressed in recent 3-4 years...
<Patrick2>
denix haha, i see:-D the git diff will be huge i guess. I still lack a lot of understanding, which i need to gain first.
<Patrick2>
I definetly think it would be easier to buy a RPi. But i still think I should know how this works.
<denix>
Tartarus: is the original BeagleBoard from 2009 still supported in U-boot?
<Guest87>
would it be possible to extend toasters functionality to include the option to download generated images/files for recipes? I'm thinking things like files from the deploy folder and key files from tmp/work in recipes
<Patrick2>
denix kindoff oftopic question now: Will a segger jtag debugger be enough? I usually work with Lauterbach
<Patrick2>
Segger jlink edu
<derRichard>
ernstp: so far i saw it on zeus, dunfell and hardknott. just upgraded to kirkstone, let's see whether i face it there too
oberonc has joined #yocto
<oberonc>
I have an issue with logind
<oberonc>
I want to keep proceeses running after I exit ssh
<oberonc>
for that to happen I changed KillUserProcesses=yes to KillUserProcesses=no
<oberonc>
in /etc/systemd/logind.conf
<oberonc>
and restarted
<denix>
Patrick2: yeah, don't know on that one
<oberonc>
but "$ sudo loginctl show-user"
<oberonc>
.. still has:
<oberonc>
KillUserProcesses=yes
<oberonc>
why ?
amahnui1 has quit [Quit: Connection closed for inactivity]
<rburton>
RP: so if foo.bb has RDEPENDS=bar, why does foo:do_populate_sysroot depend on bar:do_populate_sysroot
<sotaoverride>
i brought over fsoverlay.bbclass to whatever openembedded tree the bsp im working on is using. what does this error mean? missing required distro feature 'overlayfs' (not in DISTRO_FEATURES)
<rburton>
it means the required distro feature 'overlayfs' is not in your DISTRO_FEATURES
<rburton>
overlayfs is opt-in, so you need to ask for it
<sotaoverride>
doesnt the bbclass already do that for you? REQUIRED_DISTRO_FEATURES += "systemd overlayfs"
<rburton>
that defines the required distro features
<rburton>
its up to your distro to set the features it has
<sotaoverride>
thanks
<RP>
rburton: historically that would have been required, it probably isn't now
<rburton>
its annoying when dealing with dependency cycles
<RP>
rburton: you're going to make me change that just before you leave on vacation aren't you?
<rburton>
haha
<rburton>
maaaybe
<rburton>
i'll make a note to comment it out and try a build when I get back :)
<RP>
rburton: did you look at those cve warnings?
<rburton>
bah, no. I can do this afternoon after I've ran a chore
<RP>
rburton: I can do it if you want
* RP
just doesn't want to annoy swat too much
<rburton>
if a patch isn't on the list by 5pm tonight, i'm sorry so please do
<sotaoverride>
need help with this https://gyazo.com/3c7777395d11b4722dbdcfe28aa7c1b5 (trying to make overlayfs work with my bsp), or just have someone share an example of a systemd or some other intit script that brings up mount overlays
* RP
wishes he could leave for a few weeks and make things "someone elses problem". Sadly I'd just come back to it
<rburton>
sotaoverride: that says you didn't copy the oe.overlayfs class (meta/lib/oe/overlayfs.py)
<rburton>
the easiest way to backport a function is to cherry-pick the commits, not copy files, as it's easy to miss files or related changes
<rburton>
yudjinn[m]: you need to update that bit of anon py in the layer to work with modern python. or just delete the ${@build_date(d)} bit as its just pointless churn to cause rebuilds
<yudjinn[m]>
the thing is It works with python3, just not python2 (if I manually run it), rburton are you suggesting I just override this step to do nothing in my conf?
<rburton>
i'm suggesting you delete that bit entirely as it's pointless
<rburton>
*surely* meta-tegra supports newer than zeus
<yudjinn[m]>
I'm on the dunfell branch of meta-tegra, and ideally we dont want to make changes directly in the 3rd party layers
<RP>
rburton: it is going to break if we remove that :/
prabhakarlad has quit [Quit: Client closed]
<RP>
rburton: basically we look like we're injecting dependencies at slightly the wrong point on the dependency chart
<RP>
rburton: I did confirm that m4-native blows up without that too
<landgraf>
Do we have triage meeting today?
<RP>
landgraf: yes
<RP>
rburton: I don't think we have syntax for "get the rdepends of the recipes this task depends upon"
<landgraf>
RP: Thanks
<Tartarus>
denix: Yeah, original beagles should work, but I don't test mine often
sakoman has joined #yocto
* RP
notes his insane config options and tries again
<jaskij[m]>
I'm experimenting with LXC containers, including building them with Yocto. Would there be interest in a layer providing a minimal container to build Yocto?
<sotaoverride>
my bsp uses a git submodule for openembedded-core layer, its currently on ecd636154e7cfc1349a7cfd8026a85eafa219535 layers/openembedded-core (yocto-3.1.8), can someone help me figure what commit I can cherry pick to add overlayfs.bbclass? its a git submodule, so Im also trying to see if cherry picking would work. I tired merging master into the submodule but thats gicing me a lot of conflicts and might
<sotaoverride>
also break some of the recipes.
prabhakarlad has quit [Quit: Client closed]
mckoan is now known as mckoan|away
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
gpanders has joined #yocto
Guest43 has joined #yocto
Schiller has joined #yocto
Schiller has quit [Client Quit]
tgamblin has joined #yocto
goliath has quit [Quit: SIGSEGV]
<yudjinn[m]>
what does the error message "no recipes available for: ..." mean?
Tokamak has quit [Ping timeout: 246 seconds]
Tokamak has joined #yocto
manuel1985 has joined #yocto
<jonmason>
it means that you are missing a layer or using the wrong name
eggman has quit [Quit: brb]
eggman has joined #yocto
<yudjinn[m]>
hm.. I'm trying to build meta-tegra on dunfell and am getting `Nothing RPROVIDES 'cuda-command-line-tools-libcupti'`
<JaMa>
RP: there are 3 possible fixes for do_patch issue, A) needs extra .patch for quilt which probably won't be upstreamable, B) might bring long-forgotten issues when ${S}/patches isn't wiped between do_unpacks, C) creates empty file just to keep new quilt happy - A) and B) are in https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/master but now I'm tempted to just do C), do you have any
<zwelch>
yudjinn[m]: it probably means the name of the recipe changed. i usually look through git log and search for the old recipe name, as that usually turns up the commit where it got renamed.
cambrian_invader has quit [Ping timeout: 256 seconds]
cambrian_invader has joined #yocto
Wouter0100 has quit [Read error: Connection reset by peer]
Wouter0100 has joined #yocto
manuel has joined #yocto
<manuel>
If I add an out-of-tree kernel module to KERNEL_MODULE_AUTOLOAD, will a `bitbake -c compile -f virtual/kernel` do the trick? Or do I need to bitbake my kernel module recipe?
<JaMa>
manuel: it's postinst in /etc/modules-load.d/basename.conf file in the package with that module, so you need to rebuild the module (not the kernel itself)
<manuel>
moto-timo: Thanks, have these slides open right now. Am diagnosing why my module doesn't get autoloaded.
<manuel>
JaMa: thanks
<JaMa>
most often it's due to different basename and modulename (e.g. - and _)
mvlad has quit [Remote host closed the connection]
<JaMa>
check the content of the package, if the modules-load.d call is there and the module name in modprobe call works on target
<manuel>
moto-timo: I am at slide 106 of https://elinux.org/images/3/38/YPS2022.05_d0s03_kernel-hands_on.pdf and get the expected results. However, when I add "hello" to KERNEL_MODULE_AUTOLOAD, it doesn't get loaded. Is there anything which prevents module autoloading for out-of-tree kernel modules?
<manuel>
IIRC in lab 3 KERNEL_MODULE_AUTOLOAD worked as expected.
<manuel>
In other words, is KERNEL_MODULE_AUTOLOAD not meant to be used for out-of-tree kernel modules?
<RP>
JaMa: hmm, interesting. I think if we wipe ${S}/patches we should be wiping .pc as well. I'm starting to think we should just "ban" ${S} == ${WORKDIR} as unworkable
mrnuke has quit [Ping timeout: 248 seconds]
<RP>
re: glibc, I'm half tempted to try and send some patches, it would be nice to clarify things there
* RP
realistically doesn't have the time
gpanders has left #yocto [WeeChat 3.4.1]
mrnuke has joined #yocto
ecdhe has quit [Ping timeout: 240 seconds]
<moto-timo>
⏱
<yudjinn[m]>
on dunfell, I'm running into: `ERROR: Nothing RPROVIDES 'python-subprocess' `, what is supposed to provide this?
kevinrowland has joined #yocto
ecdhe has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<smurray>
yudjinn[m]: python3-core. If you need to track modules -> package for the Python standard lib modules down, good place to check is meta/recipes-devtools/python/python3/python3-manifest.json, it drives that
<yudjinn[m]>
isn't python-subprocess part of the standard lib, though?
<smurray>
yudjinn[m]: it is, but they get split into binary packages per that manifest. iirc, the RDEPENDS for python3 doesn't pull modules in, you either need to add the python3-modules meta-package or pick them individually
<yudjinn[m]>
can you give me an example?
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<smurray>
yudjinn[m]: of what, pulling module packages in?
<yudjinn[m]>
of how you'd address this
<smurray>
yudjinn[m]: look at the RDEPENDS definitions in some of the other recipes in meta/recipes-devtools/python
behanw has quit [Quit: Connection closed for inactivity]
<yudjinn[m]>
ahhhh I think I follow now, thanks!
<smurray>
yudjinn[m]: ah, your error message says "python-subprocess", not "python3-subprocess", I missed that. You need to either fix whatever it is you're trying to build to use python3, or live with using meta-python2 for the last release of Python 2.x
<yudjinn[m]>
I can up it to python3-subprocess, but that was not resolving the issue, just moving it
<smurray>
yudjinn[m]: whatever recipe has a dependency on python-subprocess is out of date, basically, Python 2.x support was removed before dunfell
<yudjinn[m]>
yep, this is a project that was running on zeus and I'm working on bringing to dunfell
<smurray>
yudjinn[m]: if it's in some layer you don't control, like a BSP, meta-python2 is an option, but Python 2.x is EOL now so upgrading to 3 is what you'd really want to be doing
<yudjinn[m]>
yep, I'm setting everything to python3
<yudjinn[m]>
hm, maybe I'm missing something else. python-subprocess doesnt have a separate recipe
seninha has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 276 seconds]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
seninha has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
seninha has quit [Quit: Leaving]
zwelch has quit [Quit: Leaving]
ntlctx has quit [Quit: Connection closed for inactivity]