<DarkKnight>
Hi all, sstate-cache is architecture dependent or machine dependent or...? I want to save sstate-cache, and I'm wondering how should I classify the directories to do so. By arch or machine or..?
dtometzki has joined #yocto
<qschulz>
DarkKnight: share the whole directory between all your projects, nothing to think about :)
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
DarkKnight has quit [Quit: Client closed]
dtometzki has quit [Read error: Connection reset by peer]
dtometzki has joined #yocto
guest2341 has joined #yocto
florian_kc has joined #yocto
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #yocto
seninha has joined #yocto
destmaster84 has joined #yocto
<RobertBerger>
There are rumors that the gitsm fetcher is instable. Is this the case? RP?
Guest13 has quit [Quit: Client closed]
<rburton>
not really
<rburton>
we use it a lot
davidinux has quit [Quit: WeeChat 2.8]
<RP>
RobertBerger: it is much better than it was
* RP
still doesn't like it
hcg has quit [Quit: Client closed]
<landgraf>
RobertBerger: it has few limitations in corner cases
destmaster84 has quit [Quit: Client closed]
Schlumpf has joined #yocto
<jclsn>
I am just wondering: What is actually achieved by the virtual-binds recipe being built by default?
<jclsn>
It seems like a portion of the /var partition that is writeable, although the / partition including /var is read-only, which is not persistent
<jclsn>
So like a storage for files that need to be written, but are not important enough to keep around
<jclsn>
Thus it will get in the way of my persistent backlight problem and I should probably remove virtual-binds. I am just wondering what consequences that might have, because there is probably a good reason for it to be activated by default
<qschulz>
jclsn: probably for kernel logs/syslogs to persist and help debugging
<jclsn>
But it is not persistent
<qschulz>
My bad, didn't read carefully the message :/
<qschulz>
but that would be an answer, many programs actually need to write to /var/log, and I assume they probably assume it's writeable
leonanavi has joined #yocto
leon-anavi has quit [Ping timeout: 260 seconds]
<jclsn>
hmm pity that no one is here that has in-depth knowledge about volatile-binds
<jclsn>
RP: ?
<jclsn>
qschulz: No need to apologize. You are trying to be helpful as always. Thank you :)
<qschulz>
jclsn: it's a bit hard to find a compromise between answering/trying to guide fast and leaving it unanswered
<qschulz>
I usually try to spend some time if I see the last question hasn't been answered for a few hours or something
<jclsn>
But you should not feel responsible for my problems
<qschulz>
maybe other people do work the same way and I basically make it harder for you to get proper help
<qschulz>
who knows /me shrugs
<jclsn>
No, you are very helpful most of the time
<jclsn>
Even now you were. I just have not found my solution yet
<RP>
jclsn: I don't know that code
<RP>
our history is very small devices with flash where you didn't want a ton of writes to the rootfs so this probably stems from that
<jclsn>
Your answer actually makes sense. I think the volatile-binds are there for logs and host keys etc. Since we have the read-only rootfs the host key get lost after every reboot, because the voltile binds are not persistent. But they make debugging during one boot possible. So I guess the most easy way is to get rid of the volatile-binds, use a separate read-write /var partition and if I want to have
<jclsn>
some ultra-persistent configurations, I can use an overlayfs from my /data partition
<jclsn>
RP: So reduce the number of logs being stored you guess?
<RP>
jclsn: I'm totally guessing but yes. Keep in mind this stuff has been messed around for over a decade too so it is also possible the setup is now just a bit corrupted
<jclsn>
RP: I thought you were the ultra guru to poke here. If not you, who is it? ^^ Are they gone already
<jclsn>
?
<RP>
jclsn: No one person knows everything about the system. I'm one of the few of the early people left and I do my best to try and keep everything going the write way but with the shear scope and number of directions the project gets pulled, it is challenging :/
<RP>
people don't realise that often to answer a "simple" question like this I'd have to spend an hour remembering things about it and/or spend that time reading logs and the history
<jclsn>
RP: I understand. Is the project being funded btw? I mean no one can maintain this in their free time in the long run
<RP>
jclsn: I'm funded and we do have a few others but mostly not focused on active development
<qschulz>
jclsn: funds aside, RP has been working too much for too long already. We're lacking contributors/maintainers/reviewers for a long time now :/
<RP>
jclsn: for me the problem is burnout. I can't do everything (or know everything)
<jclsn>
qschulz: I would really like to but my current company does only care for our internal tickets
<qschulz>
and having RP digging into things, amplifies this issue because then we don't grow the knowledge base among contributors/users and this increases even more the pressure on the single point of failure :/
<qschulz>
jclsn: it was not specifically directed at you, just to be clear :)
<landgraf>
jclsn: according to original commit message volatile-binds is for systemd-enabled systems only
<RP>
jclsn: there are a lot of companies doing that and assuming someone else will make the upstream work :/
<landgraf>
I guess it can be disabled if you don't have one
<jclsn>
RP: Yeah I know that feeling. I have been renovating my flat the past 9 monts, working full-time plus some hobby projects, plus trying to have some free time
<jclsn>
I wouldn't know how to do this if I had a family
<jclsn>
And I guess some of you do
<RP>
landgraf: that sounds right and would explain why I have a gap in knowledge as I try and avoid systemd :D
<landgraf>
RP: Today will be my last bug triage meetign as huawei employee btw :-(
<RP>
landgraf: I'm really sorry to hear that, you've done some really useful/helpful things
<landgraf>
I'd keep bug assigned to me for now but I don't know yet if I'll find something YP related
<jclsn>
RP: I know, I also think they should treat the environment they live and work in with more reciprocity
<RP>
landgraf: YP skills are very much in demand so I hope so! :)
<RP>
jclsn: Yocto Project is having a bit of a membership recruitment drive at the moment as we know the current situation is going to end badly
<landgraf>
RP: will see. I really like the project (taking into account I saw yocto for the first time one year ago :D )
<landgraf>
so my yocto skills are quite limited by fixing small bugs here and there
<jclsn>
RP: Membership recruitment drive?
<RP>
landgraf: I wouldn't underestimate yourself as you have dived into some complex things which many others struggle with. Seeing new people getting involved is one of the things which gives me hope for the future!
<landgraf>
jclsn: many companies use YP without contributing fixes/patches/enhancements back to the project.
<landgraf>
which doubles work of all parties involved. Sharing is better
<jclsn>
RP: Oh only industry giants or FAANGs mostly
<qschulz>
landgraf: upstreaming costs money/time in short term and not all employees are willing to do it without it being enforced company policy
<landgraf>
qschulz: I know this unfortunately
<landgraf>
downstream patches are evil :)
<qschulz>
landgraf: and they cost so much in the long run
<landgraf>
qschulz: I/ve been workeing mostly with opensource so "Upsteam first!" was the main rule
<jclsn>
I have been telling my colleagues and boss a long time to use open-source BSPs and invest our time there, but we are still using NXP BSP, Vivante and Chromium instead of Etnaviv and webkit
guest2341 has quit [Remote host closed the connection]
guest2341 has joined #yocto
<jclsn>
I would rather work on those issues there with you than to write something in this nasty NXP forum, which constantly inserts line breaks and messes with the text written
<jclsn>
I think NXP is trying their best though. No bad blood
brazuca has joined #yocto
prabhakarlad has quit [Quit: Client closed]
guest2341 has quit [Remote host closed the connection]
vladest has quit [Quit: vladest]
vladest has joined #yocto
Schlumpf has quit [Quit: Client closed]
zwelch has quit [Read error: Connection reset by peer]
<agherzan>
Not only that specific patch but the entire series without the restructuring
<agherzan>
Mainly:
<agherzan>
1. shadow sub id files
<agherzan>
2. patch for shadow nss
<agherzan>
3. cleanup subid files in the current implementation (without rewriting things)
<agherzan>
Would that be acceptable?
zpfvo has quit [Ping timeout: 268 seconds]
zpfvo has joined #yocto
Schlumpf has joined #yocto
xmn has joined #yocto
guest2341 has joined #yocto
sakoman has joined #yocto
<landgraf>
agherzan: backport and send with branch prefix and CC Steve ? I think it's the way docs suggest
<agherzan>
landgraf: indeed. I was looking for an initial assessment that this is deemed reasonable for kirkstone
<landgraf>
agherzan: otherwise you may want to repeat your question as sakoman just joined IRC channel :)
<landgraf>
not sure how matrix integration works (or doesn't work) here :-/
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
kscherer has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
thomasd13 has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
Schlumpf has quit [Ping timeout: 252 seconds]
<Guest63>
Hi qschulz
<Guest63>
I was able to build i915 firmware into kernel image by adding `RDEPENDS_${PN} += " linux-firmware-i915 "` in kernel recipe
<Guest63>
but the downside is this installs firmware in rootfs
<rburton>
thats because you set it as a runtime depends, so it's doing exactly what you want
pbergin has quit [Quit: Leaving]
<qschulz>
Guest63: you didn't answer the question :)
<qschulz>
how did you get the firmware built into the kernel binary?
<qschulz>
because RDEPENDS is definitely not the way to go for this to happen and I'm wondering how you did it
<qschulz>
(DEPENDS on linux-firmware is the only correct way BTW)
<qschulz>
and you don't need any RDEPENDS because that's not what you want and it's not needed anyway if you correctly put the firmware blob inside the kernel binary
<qschulz>
(I'm genuinely asking how you did it, so we can work from there to undo or adapt what's been done so far into something that could work)
prabhakarlad has joined #yocto
<Guest63>
sorry if i am not clear enough
<Guest63>
your questions reminds me something , which am testing now
<Guest63>
Please give me 5-10 minutes to get back you
<qschulz>
Guest63: ok, adding DEPENDS = "linux-firmware" in your kernel recipe should be enough
<qschulz>
DEPENDS += probably also
hcg has joined #yocto
guest2341 has quit [Remote host closed the connection]
sakoman has quit [Remote host closed the connection]
sakoman has joined #yocto
tdufret[m] has quit [Quit: You have been kicked for being idle]
frieder has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
zpfvo has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
vladest has joined #yocto
<hushmoney>
meta-xilinx provides a recipe which they want you to specify SRC_URI from machine config as in HDF_PATH ?= "...", but if i use https:// then bitbake fails due to no SRC_URI[sha256sum]. i wonder how can i set SRC_URI[sha256sum] from machine conf?
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
<hushmoney>
if i use SRC_URI:pn-external-hdf[sha256sum] then i see the value in bitbake -e external-hdf, but when i try to build it still fails
dtometzki has quit [Read error: Connection reset by peer]