invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
manuel1985 has joined #yocto
<LetoThe2nd>
yo dud
<LetoThe2nd>
X
rfuentess has joined #yocto
camus has joined #yocto
michalkotyla has joined #yocto
mckoan_ is now known as mckoan
<mckoan>
good morning
alessioigor has joined #yocto
frieder has joined #yocto
jclsn has quit [Quit: WeeChat 3.7.1]
jclsn has joined #yocto
amitk_ has joined #yocto
Tyaku has joined #yocto
amitk has quit [Ping timeout: 264 seconds]
amelius has joined #yocto
amelius is now known as aduda
<hsv>
I'm trying to add linux spi device driver. lsmod shows it loaded but the device file needs creating manually and then it still cannot be read. Any ideas what i'm doing wrong please? - https://paste.debian.net/plain/1262122
camus has quit [Ping timeout: 265 seconds]
nemik has quit [Ping timeout: 268 seconds]
camus has joined #yocto
nemik has joined #yocto
amitk has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
ble[m] has quit [Quit: You have been kicked for being idle]
<qschulz>
o/
<jclsn>
Morning
rber|res has joined #yocto
Guest19 has joined #yocto
leon-anavi has joined #yocto
florian has joined #yocto
michalkotyla has quit [Quit: Connection closed]
<rburton>
RP: nice to see modules get thrown into the hash
<phako[m]>
rburton: I stumbled upon the meta-guacamayo layer on friday - I suppose that is dead as a dodo?
<rburton>
yeah
<rburton>
phako[m]: now i'm going to reminisce about what could have been
<phako[m]>
I'm sorry
<rburton>
(the app was the prototype UI for meego-tv, before it was drastically rescoped and we had to stop work on it)
<phako[m]>
wow. layers.openembedded.org is really unhappy if you do not have a master branch
<rburton>
phako[m]: ask moto-timo about that
<phako[m]>
or is it unhappy about the layer. hm
<rburton>
i think it does have an issue with non-master
<RP>
rburton: do you think the API is right?
<phako[m]>
no its also unhappy about me having created the account after submitting it
<RP>
rburton: it looks at the dependencies but not the code itself currently. Not sure if that is the right way to go or not
<phako[m]>
apparently
florian_kc has joined #yocto
nemik has quit [Ping timeout: 265 seconds]
nemik has joined #yocto
Tyaku has quit [Quit: Lost terminal]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
Guest82 has joined #yocto
<Guest82>
Hello, I'm currently using the SDK tools to develop a c project and that works great. (VS Code / Cmake, gcc/gdb path sourced from the SDK scripts etc.) I'm now investigating options to do the same for a new Rust project. So it's not about compiling code through bitbake for the image (yet), but setting up a cross compile environment for Rust from
<Guest82>
the SDK. Would you know if there is a (documented) way to do this?
<RP>
vmeson: might want to mention that in your presentation! :)
<Guest82>
Hi RP, I'm on 4.0 Kirkstone, is that what you mean?. So far I've tried to add rust-native and cargo-native to my IMAGE_INSTALL:append but bitbake is complaining that do populate_sdk rdepends on non-existent task do_package_write_deb in ....../rust_1.59.0.bb so I'm guessing that's not the correct or complete way to do it.
<rburton>
Guest82: have a look at the test case RP linked to. you can't put native stuff into an image: it wouldn't work.
<Guest82>
Thanks RP and rburton, will do!
vermaete has joined #yocto
<vermaete>
Could it be the PREMIRROR stuff in Yocto at master is broken? And how to debug it?
<rburton>
khem: i'm blaming some changes in meta-clang for breaking our qemuarm64+clang testimage. xorg doesn't start. I'm glaring at the pixman change :)
<vermaete>
I have:
alessioigor has quit [Quit: alessioigor]
<rburton>
vermaete: maybe? what do you mean by 'broken'
alessioigor has joined #yocto
<vermaete>
well, it was working. It did a sync (have air gapped network) of a lot of meta layers from the Internet.
<vermaete>
And now it's not working anymore.
<rburton>
that's still quite vague
<vermaete>
But I don't really know where to start debugging.
<rburton>
you did a fetchall, and now a build without networking is failing?
<vermaete>
I have in local.conf (what's still working on the release before the fetch)
<Guest82>
RP thanks for the suggestion, I have to stick to Kirkstone for compatibility with other layers but maybe these improvements will become available there at some point.
<Guest82>
Appending packagegroup-rust-cross-canadian-${MACHINE} to TOOLCHAIN_HOST_TASK in my image results in a segmentation fault build error for rust-llvm/1.59.0-r0. Hard to pin point exactly for me.
<RP>
Guest82: sadly we didn't get things fixed until after kirkstone shipped :(
frieder has quit [Ping timeout: 260 seconds]
KrisC has quit [Quit: WeeChat 1.9.1]
<LetoThe2nd>
RP: sounds like we need meta-lts-rust-backports... *cough*
<JaMa>
FWIW: I've also backported newer rust from langdale to kirkstone for meta-webosose, but not due to packaging fixes
zpfvo has joined #yocto
<Guest82>
RP no worries. Trying to google for these topics already told me it's not time yet for Yocto dummies like me, I'm sure it will mature over time.
<Guest82>
LetoThe2nd, Yep would be awesome, Mender...Kirkstone lts.
<Guest82>
Sticking to C++ for now...
<LetoThe2nd>
Guest82: it actually was more like, a bit ironic ;-)
demirok has quit [Quit: Leaving.]
sakoman has joined #yocto
frieder has quit [Ping timeout: 265 seconds]
<RP>
LetoThe2nd: well volunteered :)
<LetoThe2nd>
RP: that would be quite an experience, the un-rustiest, un-pythoniest person around to maintain a magic layer.
<RP>
LetoThe2nd: you think I know anything about rust? :)
<LetoThe2nd>
RP: at least you know YP internals and python, thats a lot more than me.
<Ad0>
is there a guide to add pregenerated host keys to openssh?
<Ad0>
is it even a good idea? boring to accept random keys from devices that are live
demirok has joined #yocto
<rburton>
Ad0: oe-core has a recipe for pre-generated keys for QA purposes, we don't care if the images which are built, boot once, and thrown away use the same keys
<JPEW>
RP: Hmm, you are deep in the dark arts with the inspect calls :)
<rburton>
at least i spent about an hour getting lost in a maze of cve reports, merge requests, issues, and commits
<rburton>
so i hope i didn't mark something fixed when it wasn't
<JaMa>
the fix still does apply to 4.3.0 in kirkstone (with some conflicts) the 0001-tiffcrop-subroutines-require-a-larger-buffer-fixes-2.patch is only in master with 4.4.0
<JaMa>
and yes, the maze is amazing, I'm getting lost as well
<RP>
JPEW: I couldn't decide if it was my lack of python skills or not! The code just felt a bit ugly :/
<RP>
JPEW: I did conclude I could probably drop the latter stacking bit and let the normal code handle it
fray has quit [Ping timeout: 248 seconds]
tomzy_0 has quit [Quit: Client closed]
pasherring has joined #yocto
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
kscherer has joined #yocto
<pasherring>
Hello, all. I'm trying to create a custom task for a few selected recipes. I am trying to understand what are the conditions for a stamp file to be create. Any of you could share some wisdom on that regard?
<vmeson>
RP, thanks and yes there are a few things that I still have to add to my talk.
cambrian_invader has joined #yocto
olani- has left #yocto [Using Circe, the loveliest of all IRC clients]
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
sgw has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
Guest82 has quit [Quit: Client closed]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
ecdhe_ has joined #yocto
alessioigor has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
alessioigor has quit [Quit: alessioigor]
rfuentess has quit [Remote host closed the connection]
<rburton>
khem: confirmed with a bisect that the meta-clang pixman change means xorg doesn't start
ecdhe_ has joined #yocto
<rburton>
getting the actual log now, i guess xorg is crashing
ecdhe_ has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
<rburton>
yes, xorg is segfaulting in pixman
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
<RP>
vmeson: probably also worth mentioing that rust became a toolchain feature for sdks
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
<RP>
JPEW: FWIW that inspect call to getsource has 130 calls taking 0.2s
<JPEW>
RP: Ah interesting. What about the compile() call?
manuel1985 has quit [Ping timeout: 260 seconds]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
gho has quit [Quit: Leaving.]
gho has joined #yocto
gho has quit [Remote host closed the connection]
ecdhe_ has joined #yocto
gho has joined #yocto
BrziCo has joined #yocto
gho1 has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
mckoan is now known as mckoan|away
gho has quit [Ping timeout: 260 seconds]
geoffhp has joined #yocto
gho1 has quit [Quit: Leaving.]
zpfvo has quit [Remote host closed the connection]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
zpfvo has joined #yocto
zpfvo has quit [Client Quit]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
<vmeson>
RP - okay
pasherring has quit [Ping timeout: 256 seconds]
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
pasherring has joined #yocto
ecdhe_ has joined #yocto
cambrian_invader has quit [Ping timeout: 260 seconds]
ecdhe_ has quit [Read error: Connection reset by peer]
cambrian_invader has joined #yocto
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 265 seconds]
<RP>
JPEW: As far as I can tell, the __import__ call takes around 0.006s
ecdhe_ has joined #yocto
ecdhe_ has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
ecdhe has quit [Read error: Connection reset by peer]
sgw has quit [Quit: Leaving.]
<BrziCo>
Hi guys, I'm creating image for RPi3 using meta-raspberrypi layer. From my colleague I recieved .dtbo file that he wants me to include in /boot/overlays folder on RPi3. I tried creating my recipe that would do that, but when i boot my RPi3 my dtbo file isn't there. Here is my recipe:
<pasherring>
BrziCo, it is strange that the do_deploy, the command used is install -d ..., whereas the error it shows install -D, which have different behaviors. This might be a lead :)
<pasherring>
Is there a way to run "bitbake -c cleanall" only for non-native recipes?
gsalazar has joined #yocto
florian_kc has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
tor has quit [Ping timeout: 265 seconds]
tor has joined #yocto
tor has quit [Client Quit]
manuel1985 has quit [Ping timeout: 265 seconds]
gsalazar has quit [Ping timeout: 268 seconds]
gsalazar has joined #yocto
BrziCo has quit [Ping timeout: 260 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
gsalazar has quit [Ping timeout: 265 seconds]
amitk_ has quit [Ping timeout: 248 seconds]
gsalazar has joined #yocto
<rburton>
pasherring: deleting tmp/ would be very effective
ecdhe has quit [Read error: Connection reset by peer]
<pasherring>
rburton, i see. but just too effective, hahahahaha. I'd like to keep the native goodies, but thoroughly recompile all the cross-compiled packages, for minimal effort.
ecdhe has joined #yocto
<rburton>
pasherring: it will all come from sstate in seconds
<pasherring>
rburton, Some context: here, we use -R path/to/some/tweaking.conf to tweak our images. E.g., control some variables that would end up impacting on the cross-compiled packages. When switching between these configs, sometimes the image becomes broken in a very weird way.
<pasherring>
so, currently, the workaround we use is: if switching *.conf files, delete tmp and sstate.
<rburton>
i can't see why deleting sstate would be needed
<rburton>
delete tmp if you think there's some weird failure to rebuild cleanly (recipe bug, fwiw), but sstate won't be a problem
<rburton>
unless you've found a new and exciting bug in -R
<rburton>
honestly, never seen it used before
<rburton>
but that would be easily tested in a minimal recipe
BCMM has joined #yocto
<pasherring>
because the broken packages somehow get set scened (or so I think), and the issue just just stucks there
seninha has quit [Remote host closed the connection]
<rburton>
right, replicate with a minimal recipe. if you use -R to change a config, does it correctly re-run or do the changes not actually impact the sstate hashes
<pasherring>
I see, I'll give it a try. The main concern here is that I cannot pinpoint the broken recipe (if any), the image simply gets broken. (and I'd say that an image cannot satisfy the "minimal recipe" class :P)
<rburton>
write a new recipe that just prints a number
<rburton>
or echos it to a file in a package, or something
<rburton>
then change that number with a -R conf file
<rburton>
it should rerun
<pasherring>
Ah, you mean that even if the -R conf never really touches the recipe's variables, it should rerun?
<pasherring>
I am under a fairly old bitbake release (rdk stuff), so, I am not sure if this is yet another corner case.
<pasherring>
BitBake Build Tool Core version 1.32.0
BrziCo has joined #yocto
<RP>
pasherring: it is possible some element of the configuration isn't making it into the sstate signatures. Would be interesting to know if the sstate overlaps between the two configurations and if you can replicate the failure if you copy in matching bits from a bad build into the good one and build it from sstate
<pasherring>
RP, I think I get it. But, this is a bit out of my bitbake-fu. sstate is basically witchcraft to me.
<pasherring>
You mean for me to run 3 builds, say C01.conf, C02.conf, C01.conf switching afterwards to C02.conf, and to collect the resulting sstate for each one of these, to understand the differences?
<RP>
pasherring: build the two configurations, then compare the sstate directories and see how much overlap there is in the hashes. If the hashes aren;t changing and the configuration is, that suggests one kind of problem
<RP>
alternatively, is some of the hashes are different and some aren't you could build the image from sstate using different mixes of the sstate which is the same, see if you can pinpoint any that breaks the image
<RP>
if the hashes are all different, sstate and the hashes aren't the problem
<pasherring>
Nice! This was what I was suspecting. I'll run clean builds and see what comes out then. Thanks for the input! =)
kscherer has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
<Ad0>
where is the appropiate place to have a recipe copy the authorized_keys in openssh to ~/root? my own recipe or a bbappend on openssh ? seems like having a bbappend messes up the patching
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #yocto
<Ad0>
couldn't do t he classic S = workdir
dgriego has joined #yocto
BrziCo has quit [Quit: Client closed]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
<RP>
An interesting dilemma. Bitbake wants to write out the codeparser cache and use it for the base configuration. But to load/write the cache, we need to know the variable CACHE or PERSISTENT_DIR which we can't know until the base configuration is parsed :/
nemik has joined #yocto
<RP>
hang on, why does cache have all this craziness in it's path name anyway?
dkl has quit [Quit: %quit%]
dkl has joined #yocto
* RP
feels another deletion patch coming on
<RP>
kergoth: any thoughts on "addpylib" ?
gsalazar has joined #yocto
<RP>
Would it be really bad if bitbake assumed a cache directory of TOPDIR/cache ?