<hsv>
i tried it and failed, but let me try again...
<qschulz>
maybe someone should recommend them to switch to kernel-yocto.bbclass instead of reinventing the wheel or maybe tell us why it does not fit their requirements?
sakoman has quit [Remote host closed the connection]
<hsv>
Could not find kernel config fragment /home/...snipped.../am437x/build/tmp/work/am437x_evm-poky-linux-gnueabi/linux-ti-staging/5.10.145+gitAUTOINC+8b51d20b6e-r3b/files/spidev.cfg
<qschulz>
hsv: I didn't say files/
sakoman has joined #yocto
_azcraft has joined #yocto
azcraft has quit [Ping timeout: 256 seconds]
<hsv>
ah, that works. thank you.
<mckoan>
hurray \o/
<hsv>
also i will call it spi_config.cfg since who knows what other tweaks may be required there.
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
sgw has quit [Ping timeout: 260 seconds]
_azcraft is now known as azcraft
florian_kc has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
camus has quit [Ping timeout: 260 seconds]
GNUmoon has quit [Ping timeout: 255 seconds]
Haxxa has quit [Ping timeout: 265 seconds]
GNUmoon has joined #yocto
prabhakarlad has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nathani has joined #yocto
Haxxa has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
sgw has joined #yocto
<alessioigor>
qschulz: Did you have a chance to view my yesterday pastebin about dependency loops?
Tyaku has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
florian has quit [Quit: Ex-Chat]
otavio has quit [Remote host closed the connection]
rob_w has quit [Quit: Leaving]
<nathani>
I've been struggling with shared DL_DIR. We have a shared build server for development and multiple user accounts. The git directories seem to always set up as 0644, which other users cannot overwrite if needed. I tried the BB_GENERATE_MIRROR_TARBALLS flag... no joy. Any suggestions are much appreciated, thanks!
mckoan is now known as mckoan|away
zpfvo has quit [Remote host closed the connection]
* zeddii
is --><-- close to finally debugging why a cleanall on simple packages takes upwards of 10 minutes on my builder. Lots of D state and sleeping processes.
<zeddii>
strace seems to just imply that it is my sstate cache being giant and taking forever to iterate.
<RP>
zeddii: this is why I tell people to use clean, not cleansstate or cleanall
<RP>
zeddii: large sstate not in the cache is a pain
<RP>
zeddii: most sstate accesses, we know the filename so we avoid this
<RP>
perhaps we should stop cleanall depending on cleansstate
<zeddii>
in this case, I did want to nuke everything since i'm getting a report of different behaviour and I want to be sure nothing is re-used in my existing build.
<zeddii>
so I hit it with a hammer :)
<zeddii>
I'll just go have lunch while it churns!
<hsv>
mv foo foo.deleteme; rm -rf foo.deleteme &
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #yocto
malsyned has joined #yocto
<vvn>
What are the requirements again for SSTATE_DIR and DL_DIR in terms of filesystem?
<malsyned>
How does AUTOREV work together with PV to set the PV at parse time? Whenever I try to set PV programmatically, I get "When reparsing <file>, the basehash value changed"
<kergoth>
malsyned: are you setting it with an event or anonymous python? that wont due, as the value has to be consistent every time it's used. inline python is the only way, and it can't change during the run either, so a cache would be advised (we use one for autorev)
<malsyned>
A bit about my set-up: my yocto tree sits as a subdirectory of my main application's source tree, and this recipe's job is to package whatever is checked out in the working directory. So the file it's reading exists prior to do_fetch and should be stable.
<nathani>
vvn I didn't see any requirements in the documentation specifically for the DL_DIR. But ext4 was recommended overall, which is what I'm using.
<malsyned>
Oh, also, I only get that error after I change about.py and run bitbake a second time.
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 260 seconds]
otavio has joined #yocto
alessioigor has quit [Quit: alessioigor]
<hsv>
Is naming a directory 'files' somehow magic in that the contents get copied across to ${WORKDIR} ?
<malsyned>
hsv I think you still have to mention the files you want from 'files/' in SRC_URI for them to get copied to WORKDIR. 'files/' is just in the default search path for SRC_URI.
<hsv>
So there is nothing magic about the name 'files', except convention? (just so i understand)
<hsv>
oh, sorry. i read ehat you said again.
manuel_ has quit [Ping timeout: 260 seconds]
mckoan_ has joined #yocto
mckoan|away has quit [Ping timeout: 264 seconds]
frieder has quit [Remote host closed the connection]
paulg has quit [Read error: Connection reset by peer]
roussinm has joined #yocto
paulg has joined #yocto
<kergoth>
hsv: it finds files via FILESPATH variable
<malsyned>
kergoth: I have fixed my issue, but I don't understand *why* this is the fix. I replaced PV = "${@get_version(d)}" with SRCREV = "${AUTOREV}" \n SRCPV = "${@get_version(d)}" \n PV = "${SRCPV}" and now it works like a charm, but I don't know why. I assume I'm triggering some sort of sstate behavior
<malsyned>
(I don't even know what AUTOREV would mean in the context of the file:// fetcher that this recipe uses)
<malsyned>
by using AUTOREV?
prabhakarlad has quit [Quit: Client closed]
<malsyned>
(update: the indirection through SRCPV doesn't appear to be necessary. Just setting SRCREV = "${AUTOREV}" seems to make it work, but I don't know why.)
<kergoth>
and he left before i could explain about vardepvalue
<kergoth>
oh well
nemik_ has quit [Ping timeout: 256 seconds]
nemik_ has joined #yocto
nemik_ has quit [Ping timeout: 246 seconds]
nemik_ has joined #yocto
malsyned has joined #yocto
malsyned has quit [Ping timeout: 256 seconds]
florian_kc has quit [Ping timeout: 268 seconds]
DvorkinDmitry has joined #yocto
money_ has joined #yocto
<DvorkinDmitry>
is there are any active GUI/HTML frontend to the Yocto? Is Toaster active or stalled?
<paulg>
I've got some old files with stuff like:
<paulg>
image.inc:IMAGE_INSTALL += "apache2"
<paulg>
I thought they generated an error if they didn't use IMAGE_INSTALL:append = " apache2" nowadays?
<paulg>
instead to my surprise, the lines were just silently ignored.
<RP>
paulg: += is still valid syntax, the reason it doesn't work is just due to the way the IMAGE_INSTALL variable is used/set
* RP
doesn't remember the specific reason
<RP>
kanavin_: I merged your python3 changes but somehow the autobuilder is now breaking with symbol errors. It would appear unrelated to your change, except that it bisects to it :(
<paulg>
RP so will that be true for KERNEL_FEATURES and DISTRO_FEATURES and other key variables too?
<RP>
paulg: it is because recipes are doing things like /core-image-minimal.bb:IMAGE_INSTALL =
<RP>
paulg: no, it is because image recipes set that to a value, overwriting the += you had
<RP>
paulg: try bitbake-getvar IMAGE_INSTALL and have a look at the history
<paulg>
if I change everything to FOOBAR:append = " foo" -- that seems best for consistency, or will that somehow also screw me?
mvlad has quit [Remote host closed the connection]
<RP>
paulg: it is like an arms race, I'd really not encourage that
<RP>
I hate the behaviour of IMAGE_INSTALL
<RP>
sadly I don't have the time to dive in and try and solve it :/
<kanavin_>
RP: it does seem as though native libraries ask for newer libc symbols than the ones available on the host (on debian 11 it's 2.31)
<RP>
kanavin_: notice the libs asking for this are from uninative. It should be finding the uninative libc as well
<RP>
kanavin_: I don't know why it is breaking like this and why it points at the python patches with bisection. I think this may be some other issue and we're just unlucky it points at these patches but I can't tell. The build does have other real failures too :(
<kanavin_>
RP: right. I'm just back from a day of travelling so can't look into it immediately :-/
* paulg
isn't quite sure what to do with all these old files using IMAGE_INSTALL - guess I'll report it and let vmeson deal with it. :-P
<RP>
kanavin_: no problem, I just thought I'd at least mention it in case this had been seen before or I'm missing something obvious.
<RP>
paulg: for IMAGE_INSTALL specifically you can make then :append most likely
<RP>
paulg: just don't do that for other things
<RP>
kanavin_: sadly I will have to resolve this as we can't build M1 now :(
<paulg>
RP - thanks, I'll give that a whirl vs. making vmeson angry twice in one day.
<kanavin_>
RP: sorry I can't help today :( I acquired a galactic headache on the train, and it just faded with some help from ibuprofen
<RP>
kanavin_: np, you don't recognise it so that is a good data point. Get some rest and hope it clears up quickly!
<kanavin_>
RP: I very vaguely remember we had similar uninative breakage before
<RP>
Why do bugs do this? No merge goes unpunished :)
<RP>
kanavin_: I thought that too :/
florian_kc has joined #yocto
* RP
suspects the presence of python3-config may be reconfiguring qemu somehow. I'll check into that
<RP>
kanavin_: it is some silly floating libpng dependency. Now I know what to look for this shouldn't hopefully be too bad
garyh has joined #yocto
<RP>
kanavin_: think I have the fix, thanks
sakoman has quit [Quit: Leaving.]
<garyh>
I'm building an intel-corei7-64 image using meta-intel. I need to modify /boot/loader/loader.conf and /boot/loader/entries/boot.conf. I've tried using devtool modify for systemd, systemd-conf, and systemd-bootconf, but the files were not in those recipes. What recipe do I modify to change loader.conf and boot.conf?
<rburton>
the wic tool writes those i believe
money_ has quit [Quit: money_]
olani has joined #yocto
<RP>
JPEW: would you be able to rebase your branch against master-next please? It will need tweaking but hopefully nothing too difficult
<RP>
JPEW: if we have that, we can then probably produce some patches for people to test
<JPEW>
RP: ya I'll get that done. Probably tomorrow though
<RP>
JPEW: np, I just wanted to mention -next should be in a decent state. I sent a couple of your patches to the list, hope that was ok :)
<RP>
JPEW: I merged the buildtools helper patch too so we can make the python version bump
<JPEW>
Yep that's fine. Thanks!
florian_kc has quit [Ping timeout: 260 seconds]
Tokamak__ has joined #yocto
Tokamak_ has quit [Ping timeout: 255 seconds]
garyh has quit [Quit: Client closed]
manuel_ has joined #yocto
manuel_ has quit [Remote host closed the connection]
manuel1985 has joined #yocto
<malsyned>
I have a recipe that uses only the file:// fetcher. I have PV being set by some immediate python that reads a file on disk. Can anybody tell me why this has sstate-based errors when run a second time unless I also say SRCREV="${AUTOREV}", and if there's a better way to accomplish what that
florian_kc has joined #yocto
<RP>
malsyned: that file probably isn't always available on disk
<RP>
malsyned: or, bitbake has cached the metadata and doesn't know when it needs to reparse (and hence update it)
<RP>
BB_DONT_CACHE = "1" in the recipe may help as AUTOREV implies that
<malsyned>
accomplishes?
<RP>
means bitbake will reparse the recipe every time
seninha has quit [Quit: Leaving]
sgw has joined #yocto
Tokamak__ has quit [Quit: Tokamak__]
Tokamak_ has joined #yocto
seninha has joined #yocto
Tokamak_ has quit [Ping timeout: 256 seconds]
<malsyned>
RP the file definitely always exists on disk. I think it's the second thing you said.
<malsyned>
I recall trying BB_DONT_CACHE = "1" and it not working like I expected, but I'll give it another shot while paying closer attention to what I'm doing and see what happens. Thanks for the tip.
money_ has joined #yocto
<RP>
malsyned: the challenge is that bitbake won't know when it needs to recalculate PV
Tokamak_ has joined #yocto
<malsyned>
Isn't that the same problem faced by git AUTOREV?
<RP>
malsyned: yes, which is why it disables caching as I mentioned
<malsyned>
Right right, gotcha
leon-anavi has quit [Quit: Leaving]
<malsyned>
Thanks for your help :)
prabhakarlad has joined #yocto
Tokamak_ has quit [Read error: Connection reset by peer]
florian_kc has quit [Ping timeout: 260 seconds]
kpo has quit [Read error: Connection reset by peer]
Tokamak_ has joined #yocto
sgw has quit [Quit: Leaving.]
manuel1985 has quit [Ping timeout: 256 seconds]
kpo has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
malsyned has quit [Ping timeout: 264 seconds]
Net147 has quit [Quit: Quit]
Tokamak_ has quit [Read error: Connection reset by peer]