seninha has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 252 seconds]
seninha has joined #yocto
davidinux has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
seninha has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
seninha has joined #yocto
seninha has quit [Client Quit]
seninha has joined #yocto
seninha has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
prabhakarlad has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
sakoman has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
kevinrowland has quit [Ping timeout: 252 seconds]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<PhoenixMage>
What are the differences between the normal packages and the nativesdk packages?
<PhoenixMage>
From what I have read they are the packages that are compiled for the build host to use to cross compile?
thomasd13 has joined #yocto
sakoman has quit [Quit: Leaving.]
beneth has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
rob_w has joined #yocto
<mcfrisk>
PhoenixMage: nativesdk is target for recipes compiled for the host, e.g. Linux x86_64, SDK environment. In the SDK user want to have a cross compiler, and possibly some tools. Those are built by the nativesdk target.
amitk has joined #yocto
mvlad has joined #yocto
zkrx has quit [Read error: Connection reset by peer]
mckoan|away is now known as mckoan
<mckoan>
good morning
zkrx has joined #yocto
rfuentess has joined #yocto
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
odra_ has joined #yocto
d-s-e has joined #yocto
zpfvo has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
odra__ has joined #yocto
odra_ has quit [Read error: Connection reset by peer]
xmn has quit [Quit: ZZZzzz…]
xmn has joined #yocto
prabhakarlad has joined #yocto
<qschulz>
d-s-e: if the whole filename is kubernetes_git.bb, that's fine, if it's kubernetes_git_something.bb not good
milosv has joined #yocto
alvaropg[m] has joined #yocto
leon-anavi has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
d-s-e has quit [Ping timeout: 252 seconds]
milosv has quit [Quit: Konversation terminated!]
xmn has quit [Quit: ZZZzzz…]
d-s-e has joined #yocto
<d-s-e>
qschulz: yes, the name is kubernetes_git.bb
odra__ has quit [Remote host closed the connection]
odra__ has joined #yocto
Payam has joined #yocto
<qschulz>
d-s-e: then it should be fine on that side
behanw has joined #yocto
<d-s-e>
qschulz: that's what I also thought. It's also interesting, that bitbake-getvar shows the correct values for PATH and PN.
greenwhale has joined #yocto
<greenwhale>
LAYERDIR is the path of the current layer. How can I, in the terminal, echo this variable to view the path? For example, I want to do echo ${LAYERDIR}
florian has joined #yocto
<greenwhale>
pwd gives ~/poky/meta-tek, I should then get the same if I do echo ${LAYERDIR} correct?
<qschulz>
greenwhale: no, echo will only print into the log file
<qschulz>
greenwhale: you're looking for bbwarn probably
<qschulz>
(or bbnote but it's hidden by default IIRC)
<greenwhale>
I basically want to play with the variables to become with using yocto, i.e. it says LAYERDEPENDS lists the layers, without running the entire yocto build I thought there might be a way to achieve this. Then I'll try to work with bbwarn
<qschulz>
greenwhale: I didn't understand what exactly you want to do, can you rephrase?
<greenwhale>
Yes, my goal is to learn yocto. For that I wanted to play with the variables that exist when making recipes such as the variable LAYERDEPENDS which supposedly lists layers or the variable LAYERDIR which provides the path of the current layer. I don't want to put these variables just in a recipe and use them straight away then run the build. I want
<greenwhale>
to actually see what happens if I use the variable LAYERDIR, that is I want some way to execute a function with this variable LAYERDIR as argument and that it gives me, in this case, the path of the current layer.
<qschulz>
bbwarn will print the content of the variable on your console when it is run
<greenwhale>
then that is just what I need, thanks!
<qschulz>
(bb.warn if it's a python function, bbwarn if it's shell function)
<greenwhale>
Ah good to know, thanks!
greenwhale has quit [Quit: Client closed]
zkrx has quit [Read error: Connection reset by peer]
zkrx has joined #yocto
ptsneves has joined #yocto
rob_w has quit [Remote host closed the connection]
<LocutusOfBorg>
hello, anybody from meta-freescale here?
<LocutusOfBorg>
<BTS> libraw 0.19.2-2+deb10u1 uploaded to buster-security with urgency high by Helmut Grohne <helmut@subdivi.de> https://tracker.debian.org/libraw
<LocutusOfBorg>
<BTS> Opened #1019921 in debian kernel 5.10.0-18-amd64 by Christian Butterweck <christian1...@gmail.com> «Kernel incompatible with Intel Atom Processor (Coprocessor) driver C3758 / C3xxx». https://bugs.debian.org/1019921
<LocutusOfBorg>
I would like to understand why wayland is required dependency for i.MX8.
<LocutusOfBorg>
people of meta-digi removed the dependency, because the library works fine with framebuffer :)
<LocutusOfBorg>
so, maybe meta-freescale should do it too?
Schlumpf has joined #yocto
seninha has joined #yocto
<qschulz>
otavio: ^ question for you I assume :)
thomasd13 has quit [Ping timeout: 264 seconds]
seninha has quit [Quit: Leaving]
seninha has joined #yocto
<PhoenixMage>
mcfrisk: Thanks, thats what I thought
behanw has quit [Quit: Connection closed for inactivity]
kmaincent[m] has joined #yocto
<otavio>
LocutusOfBorg: please send a PR for it. I can review it for sure
d-s-e has quit [Ping timeout: 252 seconds]
davidinux has quit [Read error: Connection reset by peer]
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
davidinux has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
<otavio>
qschulz: thx for the hands up ;-)
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
florian has quit [Quit: Ex-Chat]
<dacav>
I've got a source project that provides a few binaries, depending on how cmake is parametrised. I'd like to write a recipe foo.bb, and to have PROVIDES += "bar baz". After creating a recipe with `devtool add` under my workspace, I'm using `devtool build bar` but it doesn't work. Is using `bitbake bar` also OK?
<mckoan>
dacav: describe "doesn't work"
<mckoan>
devtool calls bitbake
<dacav>
ERROR: No recipe named 'bar' in your workspace
beneth has joined #yocto
<mckoan>
dacav: figure out why recipe named 'bar' isn't in your workspace
<dacav>
there's no bar.bb, there's foo.bb that PROVIDES bar
<qschulz>
dacav: I assume this will work only for DEPENDS
<dacav>
Ah, from other recipes, then. Yet it looks like a raw bitbake will pick it up.
<mckoan>
or use PREFERRED_PROVIDER
ecdhe has quit [Ping timeout: 244 seconds]
<dacav>
Isn't that meant to handle the case where multiple packages provide the same name, as opposite to one package providing multiple names?
<mckoan>
dacav: yes
ecdhe has joined #yocto
kscherer has joined #yocto
<LocutusOfBorg>
otavio, ack
xmn has joined #yocto
wkawka has joined #yocto
<wkawka>
Hi, how can I install within do_install function whole directory?
<wkawka>
i tried like this ` install -d my_dir ${D}/destdir`
<wkawka>
but it is empty
<dacav>
wkawka: install has a few forms. The one you mention treats all arguments as directory names, and creates them all, but does not install anything.
<dacav>
Probably you want to do `install -d` of the directory, as it was a mkdir, and then install individual files to it using the `-t` form.
<dacav>
install is a bit confusing :) but the manpage is showing all the various forms.
<wkawka>
yes, but there are plenty of them, so `-t ` extracts all files and subdirs from my source dir?
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
<dacav>
wkawka: I'm afraid you'll have to loop some
<dacav>
how about using `find`?
<dacav>
find -type d -exec install -d
<dacav>
and then
<dacav>
find -type f -exec install -t
<dacav>
something around those lines.
<wkawka>
why just not cp -r?
<wkawka>
I don't need to give them permissions at all
<dacav>
In principle you can do that too, yes. install has a few additional things useful, such as the possibility of invoking a strip program, and a sensible permission scheme for installed files... but it is not rocket science, a `cp` will do.
zpfvo has quit [Remote host closed the connection]
<JPEW>
RP: Could be, can you save off the build directory by chance?
<JPEW>
Huh.... interesting that avahi is starting up this time....
<JPEW>
Is the AB under load by chance?
<RP>
JPEW: I think it wasn't too bad load wise
<RP>
JPEW: I've not looked in detail but I should try and save it off
<RP>
JPEW: maint may have wiped it, will need to check
<JPEW>
I'm pretty sure that the post-install scripts are restarting services and it's just a timing thing if a later test happens to see it as "up" or not
<RP>
JPEW: maint cleaned it :(
<JPEW>
I think there might be a way to wait for system to finish whatever it things needs to be happening....
<JPEW>
RP: That's OK, it
<JPEW>
it wouldn't shed much more than we had from the other one
<JPEW>
(or I'm guessing at least)
<RP>
JPEW: ok. I just wanted to mention in case the logs showed anything interesting/useful
<JPEW>
RP: Ya it does actually
<JPEW>
RP: Can we reboot qemu after the post-install is... re-installed?
<JPEW>
Is it weird to use uninstalling and installing post-install scripts as the test for seeing if packages can be installled?
tarxf_ has joined #yocto
tarxf_ has quit [Client Quit]
<RP>
JPEW: I suspect we were also testing that the scripts work
<RP>
JPEW: we should probably look at rewriting the tests. Rebooting qemu may be possible but would probably cause a new set of races
<JPEW>
I don't know much about postinst, but I think one of the scripts it's running is the culprit
<JPEW>
Normally, postinstall would run on first boot(?) and pretty early (before sysinit.target, which is... early in systemd parlance); I wouldn't be surpised if running it after the system is all up and running causes some weird unexpected behavior (like interrupting services for example :)
<JPEW>
MIght be nice to see what actual postinit scripts are running to narrow it down
<RP>
JPEW: run-postinsts is meant to run the postinsts on target that didn't run during rootfs construction. once that happens, it should never be run again
<RP>
JPEW: so it is a really bad idea as a test arget
<RP>
JPEW: in theory once it has run, it should never run again
<RP>
JPEW: the way it does that would explain why it can rerun and I bet the scripts aren't designed to handle that
<RP>
(update-rc.d -f run-postinsts remove)
<RP>
why are we using this as the test target? :/
otavio has quit [Remote host closed the connection]
<RP>
JPEW: I think it was used as it makes a nice easy always available -dev package, but it is silly
<RP>
answer is definitely to rewrite the test
<JPEW>
RP: Ya, I suspect that will fix the bug
florian_kc has joined #yocto
<RP>
sorry, I should have looked at this earlier in the week. I've been trying to take it a bit easier whilst M3 was in QA
<JPEW>
RP: It's OK; knowing the problem is half the battle :)
<RP>
JPEW: indeed it is. Tracking it down to the postinst tests is really helpful
rsalveti has quit [Quit: Connection closed for inactivity]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
goliath has quit [Quit: SIGSEGV]
sakoman has quit [Quit: Leaving.]
florian_kc has quit [Ping timeout: 264 seconds]
sgw has quit [Remote host closed the connection]
<Ch^W_>
RP: Any argument against removing the trailing / from buildtools in poky/.gitignore? We ran into a backward compatibility situation (loooooooong story) that involves the use of a buildtools symlink instead of a directory.