seninha has quit [Remote host closed the connection]
Vonter has joined #yocto
Ram-Z has joined #yocto
cambrian_invader has joined #yocto
dtometzki has joined #yocto
Emantor has joined #yocto
woky has joined #yocto
seninha has joined #yocto
RP has joined #yocto
barometz has joined #yocto
pabigot has joined #yocto
nemik has joined #yocto
JaMa has joined #yocto
Herrie has joined #yocto
Tokamak has joined #yocto
ptsneves has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
starblue has quit [Ping timeout: 252 seconds]
rber|res has joined #yocto
starblue has joined #yocto
RobertBerger has quit [Ping timeout: 252 seconds]
fitzsim has joined #yocto
seninha has quit [Remote host closed the connection]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sakoman has quit [Quit: Leaving.]
beneth has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
Tokamak has joined #yocto
sakoman has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
beneth has quit [Read error: Connection reset by peer]
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
Guest9076 has joined #yocto
Guest9076 has quit [Client Quit]
Telgareith8 has joined #yocto
Telgareith has quit [Read error: Connection reset by peer]
Telgareith8 is now known as Telgareith
goliath has joined #yocto
olani has quit [Ping timeout: 248 seconds]
mrnuke has quit [Read error: Connection reset by peer]
mrnuke has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
astlep has joined #yocto
<LetoThe2nd>
yo dudX
hcg has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
pbergin has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
frieder has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
mvlad has joined #yocto
Guest40 has joined #yocto
Guest40 has quit [Client Quit]
zpfvo has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
zpfvo has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<dacav>
Hi. I'm trying to obtain a bare-metal build in yocto, so I can embed the image for an auxiliary MCU in my linux build. I managed to build one library successfully (based on newlib includes), and I thought of setting its prefix as /opt/<libname>, so I can `-I /opt/<libname>/include` from the depending recipes.
<dacav>
Question 1: is this approach correct?
<dacav>
Question 2: can I make a variable available to recipes that depend on mine? E.g. export LIBNAME_PREFIX=/opt/<libname>
hcg has quit [Quit: Client closed]
goliath has joined #yocto
jclsn has joined #yocto
<qschulz>
RP: I know, back to the slow brainstorming to find a way to deal with all this. I think I'll still push the changes somewhere to explain what I did and what are the shortcomings and why it's a bad idea to go for what I had in mind
<qschulz>
RP: didn't see your midnight message before answering. So. The issue is that I'm trying to build the migration manuals from the master branch (git checkout master -- documentation/migration-manuals) but from the branch the autobuilder is currently building
<LetoThe2nd>
dacav: what you want is a multiconfig build. first build the baremetal thing, then have the second build embed the results from the first one.
<qschulz>
ptsneves: patches welcome (or at least a bug in bugzilla in the documentation section)
<LetoThe2nd>
dacav: for the correct approach to build bare metal for newlib, instead of hacking up stuff, please look at the included examples.
GNUmoon2 has quit [Remote host closed the connection]
<qschulz>
RP: the issue is that this means we need to make the migration maunals buildable with different versions of sphinx (since pre-kirkstone is on 3.x.x and now we're on sphinx > 4 (new buildtools has 5.x.x IIRC)
GNUmoon2 has joined #yocto
<dacav>
LetoThe2nd: thanks. By { first baremetal, then a second build embeds the results } do you mean to build the baremetal outside yocto, and have a yocto recipe that embeds the result?
<qschulz>
RP: this is the one issue I talked about yesterday, there are other issues with the approach I worked on
<dacav>
LetoThe2nd: also, could you point me at the examples you mention?
<ptsneves>
LetoThe2nd: multiconfig works with baremetal? I thought it worked only with different machines but still linux distros
<LetoThe2nd>
ptsneves: it certainly works with baremetal :-)
<dacav>
Thanks. I'll check it out ;)
<ptsneves>
LetoThe2nd: great news
<LetoThe2nd>
no giving everything away now though, keep the fun for dublin :-)
<ptsneves>
yeah was looking at the presentation link you posted and no materials posted yet :D But the baremetal-helloworld.bb seems to have much stuff i was not aware of
<LetoThe2nd>
;-)
<qschulz>
RP: I might not be giving enough context for you to understand though, especially since I worked totally on my own on that..
xmn has quit [Quit: xmn]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
xmn has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
olani has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
olani has quit [Remote host closed the connection]
<RP>
qschulz: I don't totally understand but I might be slightly closer :)
ardo has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
ardo has joined #yocto
florian has joined #yocto
leon-anavi has joined #yocto
<dacav>
LetoThe2nd: quick question about multiconfigs: will they work under dunfell? tl;dr - We are stuck to dunfell for reasons, and upgrade is planned but not for right now.
<LetoThe2nd>
dacav: yes.
<dacav>
I'm asking because bitbake dies badly with 'taskdata[mc].add_provider(localdata[mc], self.recipecaches[mc], k)' triggering a KeyError.
<dacav>
If it is supposed to work, maybe it is then something wrong I'm doing.
<LetoThe2nd>
dacav: my bet is on "something that you're doing" :-)
<dacav>
In general, yes. In this specific case I always have the doubt of { If I'm using a version that is really old, will this be even feasible }. Hence the question
<dacav>
Good to know it is, now let's embrace the sorrow.
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<LetoThe2nd>
dacav: dunfell is fine, its under active maintenance.
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
florian_kc has joined #yocto
<ptsneves>
does anybody know how long glibc.GlibcSelfTest should test on average?
<jclsn>
Is there a simple way in Yocto to make /var a separte partition?
<ptsneves>
jclsn: is wic an option?
<LetoThe2nd>
jclsn: its technically beyond the rootfs, so wic would certaily be involved.
<LetoThe2nd>
plus some tuning of the fstab, probably. i think there is some example concerning volatile logs
<jclsn>
ptsneves: We are already using .wic image, so what do you mean?
<ptsneves>
so just add a partition for far in your wks file
<ptsneves>
that is how i would go for it.
<jclsn>
LetoThe2nd: Yeah I was just wondering if there was a Yocto switch. The problem is that since we have made rootfs read-only, some services like systemd-backlight are failing
<jclsn>
So we want to make /var a separate partition with read-write permissions
<ptsneves>
for that scenario you should actually be looking at volatiles not a separate partition
<jclsn>
Volatiles?
<ptsneves>
how systemd does it for readonly rootfs
florian_kc has quit [Remote host closed the connection]
<ptsneves>
jclsn: yes but your "real" issue should not be handled with an extra partition /var. It should be fixed with volatile-binds
<jclsn>
ptsneves: But if they are volatile, they don't persist till the next boot, do they?
<jclsn>
I can sure write to that folder
<ptsneves>
they will persist :)
<jclsn>
I just tried that by creating an empty file
<jclsn>
It was gone after reboot
<ptsneves>
bind the bind mounts to a real partition
<jclsn>
Ah I get it
<jclsn>
If I set this int he volatile recipe, it will be writable
<jclsn>
ptsneves: They are not recursive though are they? Because /var/lib is already there and my file in question is in /var/lib/systemd/backlight
<ptsneves>
hmm should be, but mount is kind of a overlaying thing so i do not know how if the order might be important
<ptsneves>
i do not know by heart honestly :( only the general path to achieve what you mean
<jclsn>
Okay thanks I will figure it out
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #yocto
<LetoThe2nd>
is there a generic way to express a dependency on the rootfs being completed? use case is embedding a checksum in a partition.
<ptsneves>
mytask[depends] = "myimage:do_rootfs"
<ptsneves>
?
xmn has quit [Quit: ZZZzzz…]
<LetoThe2nd>
thats non-generic as it involves the name of the image.
<ptsneves>
set the image name as a variable set on your local.conf
<LetoThe2nd>
hm no, this is not applicable to the workflow in question.
<ptsneves>
so i am not sure what you mean by generic
<LetoThe2nd>
like, a way to depend on "virtual/image:do_image", as starters.
<qschulz>
LetoThe2nd: what exactly do you want to do?
<ptsneves>
that makes little sense...what image? also there is no PROVIDER for images AFAIK
<qschulz>
LetoThe2nd: because you have ROOTFS_POSTPROCESS_COMMANDS and the like
<LetoThe2nd>
qschulz: put the checksum of partition1 on partition2, essentially. with the content of partition2 being created in a class.
<ptsneves>
the way i have seen this done is with the global variable conf i mentioned. It is how dm verity is setup on meta-security.
<LetoThe2nd>
hmmm...
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
<jclsn>
hmm unfortunately adding the path to volatile-binds doesn't work. I think this is because systemd-backlight creates that file only when shutting down or booting. It is not there during compile time
Schlumpf has quit [Quit: Ping timeout (120 seconds)]
<jclsn>
Maybe you have to add it to volatile-systemd-services somehow
zpfvo has joined #yocto
<jclsn>
Ah no those services are taking care of the mounting
<jclsn>
It is weird. The systemd-backlight service fails on boot, but you can manually restart it after
<jclsn>
Because the volatile-binds are actually working
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
murych has joined #yocto
seninha has joined #yocto
<jclsn>
ptsneves: Well, I got the service to work. Actually the volatile-binds are working well. The problem is that those are not persistent after a reboot.
<jclsn>
So the backlight can't be restored, because the file containing the value doesn't exist
<jclsn>
Isn't there something like persistent-binds.bb? :D
<jclsn>
ls
olani has joined #yocto
ardo has quit [Read error: Connection reset by peer]
<qschulz>
we have overlayfs support in kirkstone IIRC
olani has quit [Remote host closed the connection]
olani has joined #yocto
olani has quit [Client Quit]
nad27 has joined #yocto
davidinux has quit [Ping timeout: 248 seconds]
davidinux has joined #yocto
nad has quit [Ping timeout: 252 seconds]
nad27 has quit [Client Quit]
nad has joined #yocto
destmaster84 has joined #yocto
<jclsn>
qschulz: Pity we are on honister then ^^
<jclsn>
It is there though
zpfvo has quit [Ping timeout: 252 seconds]
camus has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
prabhakarlad has quit [Quit: Client closed]
camus has joined #yocto
destmaster84 has quit [Quit: Client closed]
lexano has joined #yocto
xmn has joined #yocto
<jclsn>
qschulz: I just wonder: If I have /var/lib contained in the volatile-binds and it gets reset after every boot, does this mechanism also delete parts of my /data partition if I mount it there?
<jclsn>
Because I am trying to mount /data/backlight to /var/lib/systemd/backlight
<RP>
derRichard: not sure there is one yet
<derRichard>
RP: yeah, the problem seems to be rather new. /me just ran into it ;-\
prabhakarlad has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
<qschulz>
jclsn: no clue, I'm not using overlayfs nor volatile binds
brazuca has joined #yocto
zpfvo has joined #yocto
<Alban[m]1>
<jclsn> "Because I am trying to mount /..." <- On my systems i'm using a rw /var/lib together with a ro rootfs, it work quite well.
<jclsn>
Okay
<jclsn>
It is maybe a bit less trouble to just use a rw /var partition
<qschulz>
jclsn: that's what the overlayfs allows you to do
<qschulz>
everything RO, except the overlayfs
<Alban[m]1>
Its up to you how fine grained you want things to be.
<jclsn>
Or how much of a workload I prefer
<Alban[m]1>
Sure, i for example don't want /var/cache or /var/tmp to go to disk
<Alban[m]1>
Unless you really want to be able to overwrite parts of your rootfs image i would not go with an overlay
<qschulz>
Alban[m]1: overlays are overwriting only if you're writing to files that already exist. Otherwise the original rootfs and the overlay are merged
<jclsn>
I don't get this overlayfs stuff
frieder has quit [Remote host closed the connection]
<jclsn>
Pity there isn't a good example
<Alban[m]1>
Sure, i should have say modify, something you often don't want when using an ro rootfs
<jclsn>
qschulz: We already have a /data partition mounted
<ptsneves>
derRichard: that is also the way i do it
zpfvo has quit [Remote host closed the connection]
Tokamak has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Tokamak has quit [Client Quit]
arielmrmx has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #yocto
paulg has quit [Quit: Leaving]
amitk has quit [Ping timeout: 260 seconds]
Guest63 has joined #yocto
<vvn>
hi there -- is it a best practice to have :mydistro override in bbappended recipes found in my distro layer or is that redundant?
<kergoth>
that is a best practice, yes, to ensure the layer isn't changing the build if you don't choose to use that distro. this allows multiple machine and distro layers to be enabled in bblayers but only have the configured ones affect the build
<kergoth>
same for machine in bsp layers
<kergoth>
see also the yocto-check-layers script
<vvn>
thank you
<kergoth>
more important for machine than distro, practically, but still best
<kergoth>
ideally no layer would change the build until you opt-in to what it provides in your configuration
<kergoth>
no problem
<vvn>
that makes sense, so that you can build totally different environment from the same bitbake instance without messing with bblayers.conf
<vvn>
(environment as in multiconfigs)
<kergoth>
exactly, it means you can easily switc hit around solely with local.conf, or you can use multiconfig to build all different configs in a single go
<kergoth>
yep
<kergoth>
a bit of a hassle to add overrides *everywhere*, but it becomes habit eventually
<vvn>
indeed, hence my question
<kergoth>
RP: I kind of feel like every variable assignment should be = except for the specific case of assignments in *config* files parsed after local.conf, or globally inherited classes, to allow direct assignments in local.conf to work as the user would expect, and those should all use ??=. Everything else, everywhere, should use = and move their inherit line if they have to. Then we could further reduce confusion by moving toward making
<kergoth>
all variable operations lazy with the explicit operator to clear pending operations that we'd previously discussed.
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
agners has joined #yocto
brazuca has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
prabhakarlad has quit [Quit: Client closed]
<RP>
kergoth: It would be interesting to see if we could move towards that
pbergin has quit [Ping timeout: 244 seconds]
<Guest63>
Hi
<Guest63>
I am trying include linux-firmware-i915 into the kernel image, for that i added `RDEPENDS_${PN} += " linux-firmware-i915 "` in kernel recipe
<Guest63>
I cannot use DEPENDS as linux-firmware RPROVIDES `linux-firmware-i915`
<Guest63>
the firmware blob is built into the kernel image but as a consequence of `RDEPENDS_${PN} += " linux-firmware-i915 "` it is installed in rootfs `lib/firmware` directory
<Guest63>
I removed it this leftover from the rootfs by using ROOTFS_POSTPROCESS_COMMAND
<Guest63>
is there any other clean way to achieve the same
<Guest63>
All i want is linux-firmware-i915 is included into the kernel image without poluting the rootfs
<Guest63>
Please let me know
brazuca has quit [Ping timeout: 252 seconds]
goliath has quit [Quit: SIGSEGV]
vladest has quit [Quit: vladest]
mvlad has quit [Remote host closed the connection]
vladest has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
florian has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]