dev1990__ has quit [Quit: Konversation terminated!]
Guma has joined #yocto
<Guma>
Hello Everyone. I am fairly new to Yocto. I have yocto project "DISTRO_VERSION = "2.0.3". I was able to build and flush my dev board. Board boots fine. After SDK was generated I installed it to /opt/apq8053-sdk/. Next I sourced in environment-setup-armv7a-vfp-neon-oe-linux-gnueabi. Now I have my cmake external project that I am trying to cross compile. Now when I try to run "cmake -DCMAKE_TOOLCHAIN_FILE=${OE_CMAKE_TOOLCHAIN_FILE} .."
<Guma>
from my project build/ folder I get error. Quick check of env variables is that OE_CMAKE_TOOLCHAIN_FILE is not defined. I also looked at "/opt/apq8053-sdk/sysroots/x86_64-oesdk-linux/usr/share" and I do not see cmake/ folder with expected OEToolchai
<Guma>
nConfig.cmake
<Guma>
I also googled around and found this "There seems to be a bug in the imminent Yocto Project 2.5, Sumo, release. Here, sysroots/x86_64-chargestorm-linux/usr/share/cmake/OEToolchainConfig.cmake seems to be omitted."
<Guma>
I am on older version then 2.5
<Guma>
A temporary solution suggested was to add TOOLCHAIN_HOST_TASK += "nativesdk-cmake-dev"
<Guma>
Is this correct suggestion? If so where do I add this line?
<Guma>
I this proper place to add "meta/classes/populate_sdk_base.bbclass"
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
gioyik has quit [Remote host closed the connection]
gioyik has joined #yocto
<moto-timo>
2.0.3 was released January of 2016. 5 years ago. please get your vendor to update
<moto-timo>
^6 years ago
<Guma>
moto-timo I will try but for now I like to get this going. Any help is welcomed...
goliath has joined #yocto
Guma has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guma has joined #yocto
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
Guma has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<qschulz>
this will return the package (if built) in which the file is available, you install the package in your image and you should be good to go
<ziga>
Very useful! I will use this!
<ziga>
I was toggling to the target and using ldconfig -p | less up untill now...
j7lc8l[m] has joined #yocto
<coldspark29[m]>
qschulz: Any idea how to use kas in combination with pyrex?
<qschulz>
coldspark29[m]: use kas checkout, then pyrex to debug your stuff I'd say?
camus has quit [Read error: Connection reset by peer]
<coldspark29[m]>
Ah guess you just use kas to checkout
camus has joined #yocto
<coldspark29[m]>
Yeah I could have thought of that myself actually. My first impulse is always asking someone else and while I hit the send button, I answer my own question ^^
<hmw[m]>
Hi,
<hmw[m]>
i'm trying to add KF5ModemManagerQt to a cmake project using a yocto sdk ( where the package is inlcude) but im getting build issues
<hmw[m]>
fatal error: modemsignal.h: No such file or directory
mariusz1 has quit [Ping timeout: 240 seconds]
<qschulz>
coldspark29[m]: glad to have play the role of rubber duck :)
<qschulz>
hmw[m]: wild guess but your cmake project does nto use the CFLAGS/CXXFLAGS/LDFLAGS correctly
<qschulz>
i.e. usually overridden directly in the CmakeLists.txt
<coldspark29[m]>
qschulz: Interesting that there even is a term for it ^^
<hmw[m]>
<qschulz> "i.e. usually overridden directly..." <- how do i fix it ?
<hmw[m]>
i excluded all CMAKE_C_FLAGS CMAKE_CXX_FLAGS CMAKE_LDFLAGS_FLAGS
florian has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
<kanavin_>
RP: sorry for pushy language, I should've toned it down
<kanavin_>
RP: the more I look at it, the more it seems like universe is best way out for repro tests
<kanavin_>
this whole virtual/ and alternatives thing has grown organically over the years, and needs to be somehow redesigned i'd say
<coldspark29[m]>
Any idea how insert linebreaks in the generated local.conf with kas?
<coldspark29[m]>
* insert linebreaks for comments in the
<RP>
kanavin_: universe isn't the right thing and there is a "design" kind of there, it just isn't well documented. I'll reply in a bit, basically I think we need to ensure the virtual/XXX or the recipes are all used somewhere in core and if they aren't, it suggests a different problem
<RP>
we should probably test that somehow
<kanavin_>
RP: but go-runtime is used, it just isn't packaged - we need to ensure the latter bit
<dacav>
Hi. I've got here a 3rd party bsp layer (from xilinx) that fails to apply a patch to qemu. The patch is named '0010-configure-Add-pkg-config-handling-for-libgcrypt.patch'. Is this familiar to anyone?
<rburton>
JPEW: ha wow
<kanavin_>
dacav, you need to ask xilinx perhaps?
<qschulz>
coldspark29[m]: we don't have enough info or context. In any case, I think it's just YAML syntax so just go with that and look for answers specific to YAML
<coldspark29[m]>
Yeah, I am just looking into that but can't find it. What i basically want is to write explanatory comments like int he original local.conf created by Yocto
<dacav>
kanavin_: yes. That would be a route. Just wondering if someone saw such a problem here.
<qschulz>
coldspark29[m]: multiline string is usually started with the | character IIRC
<dacav>
Interestingly, the same patch is also applied by poky
<coldspark29[m]>
qschulz: Yes, but only for everything that follow the comment
<RP>
kanavin_: if it is used somewhere, it should get packaged in world builds :/
<kanavin_>
RP: and yet it doesn't, and that's the original problem that got me so agitated ;)
<qschulz>
coldspark29[m]: did you try a scalar with a # comment in it? does it make it to the local.conf?
dev1990 has joined #yocto
<kanavin_>
it only gets packaged if you build it directly, or if you build an image that includes something that depends on it
<kanavin_>
RP: to reproduce, 'bitbake go-helloworld', inspect tmp/deploy/rpm
<kanavin_>
go-helloworld rpms will be there, but go-runtime rpms will not
<RP>
kanavin_: does helloworld actually need go-runtime ?
<kanavin_>
RP: just building to confirm
<RP>
kanavin_: I see go.bbclass only has a DEPENDS, not an RDEPENDS
<RP>
kanavin_: go-target and packagegroup-go-sdk-target should be the things which trigger the rpms to get built
<kanavin_>
RP: yes, go-helloworld does actually have go-runtime in .spec
<kanavin_>
but the rpm is not there :-/
<coldspark29[m]>
qschulz: No a # does not land in the local.conf
<RP>
kanavin_: there isn't anything telling bitbake it may be a runtime dependency :/
<RP>
kanavin_: I suspect the dependency comes in as part of an image
d0ku has joined #yocto
<kanavin_>
RP: yes, and as we don't have images with go-helloworld in repro tests, and rely on 'world' to sweep up everything, go-runtime ends up not being tested
<kanavin_>
and possibly others
<hmw[m]>
<qschulz> "hmw: wild guess but your cmake..." <- i needed to change:
<hmw[m]>
find_package(Qt${QT_VERSION_MAJOR} COMPONENTS Widgets DBus Xml REQUIRED)
<kanavin_>
RP: that's why I proposed lifting those exclusions in world
<RP>
kanavin_: I'm more worried about why the packagegroup and compiler don't pull it in
<RP>
kanavin_: the fact the rpm's don't get built does suggest there is a bit of a dependency glitch somewhere though :/
<coldspark29[m]>
@qschulz Oh yes a scalar works. Didn't know what it is
<coldspark29[m]>
Thanks :)
<RP>
kanavin_: I see you're running builds. I'd just warn the ab isn't at full strength and has a lot of new workers and "new" issues with them :/
<kanavin_>
RP: right, I guess I'll let this one run through, but not start any new ones until halstead declares completion.
<RP>
kanavin_: I think it will be for me to get things working at this point :/
<kanavin_>
RP: sorry, do you mean fixing rdepends or should I cancel the ongoing a-full?
<RP>
kanavin_: His side looks to be mostly done but there are a few issues the new systems are highlighting
<kanavin_>
I just built 'go' and go-runtime isn't there :-/ there's a serious issue there it seems
<RP>
kanavin_: the a-full is ok, I just wanted to warn it may see some interesting failures
<RP>
kanavin_: I do have a large queue in -next too which may overlap with some of yours
<kanavin_>
RP: only the go repro bits, the rest are manual (e.g. not from auh) package updates that weren't yet done by others
<kanavin_>
new systemd for example, which would benefit from a-full
<RP>
kanavin_: ok, fair enough
<RP>
a number of the patches in -next have issues :(
<kanavin_>
RP: yes, coming from me they wouldn't :) but it's also good to encourage others to send updates :-/
<RP>
kanavin_: I know, I tend to try and let others add them where possible though ;-)
<RP>
kanavin_: I think adding do_build[rdeptask] += "do_package_write_rpm" to package_rpm.bbclass does what we want
<RP>
ipk/deb will need similar
<kanavin_>
RP: yes, I was just looking at what that fateful do_build change actually contained
<kanavin_>
it dropped do_build[credeptask] += "do_package_write_rpm"
mariusz1 has joined #yocto
<kanavin_>
or do you mean adding do_package_write_rpm[recrdeptask] += "do_package_write_rpm" ?
<kanavin_>
otherwise that change would be effectively reverted, no?
<RP>
kanavin_: I'm suggesting rdeptask instead of recrdeptask
<kanavin_>
aah
<RP>
it is a compromise but should be much less overhead
<kanavin_>
my bitbake-fu isn't that good - maybe it's a good thing that over the years I haven't had to learn much about those things, as that means it 'just works' almost all of the time ;)
<kanavin_>
I need to look up rdeptask vs recrdeptask now
<RP>
kanavin_: one is recursive, one isn't
<RP>
kanavin_: and yes, it is nice in many ways people haven't needed to care :)
<kanavin_>
RP: the downside is the bus factor is close to 1 :(
<RP>
kanavin_: yes :(
Vonter has joined #yocto
<RP>
kanavin_: I've queued a build with the rdeptask change in, we'll see
<kanavin_>
RP: cheers :)
<coldspark29[m]>
How can I checkout a certain branch like gatesgarth with kas?
<coldspark29[m]>
Putting it in refspec didnt't work and I can't find anything on it in the documentation
<qschulz>
coldspark29[m]: give the commit hash
<qschulz>
+it
<coldspark29[m]>
Ah okay, this seems a bit bad for the overview though
<coldspark29[m]>
Would be nice to specify the branch
<coldspark29[m]>
* the branch by name, but well
<qschulz>
I disagree
<qschulz>
you want reproducibility
<qschulz>
using a branch will not guarantee that
<coldspark29[m]>
True
<qschulz>
it might work somehow but I don't think it's a good idea anyway
<coldspark29[m]>
We are currently using repo and it specifies the branch. I thought that this was intended somehow
<RP>
kanavin_: your build has some fun with the mdadm upgrade and udev :/
<coldspark29[m]>
I like kas much better than repo though :)
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
d0ku has quit [Ping timeout: 240 seconds]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<ziga>
I managed to build my application with "bitbake application" and it was compiled as "tmp/work/cortexa8hf-neon-poky-linux-gnueabi/application/1.0-r0/application-1.0/fotovolt_gui". But when I include it in my image with "IMAGE_INSTALL += "application" I can't find it on the target. Any idea?
<ziga>
I edited the recipes with "devtool edit-recipe application" and "devtool edit-recipe image".
<qschulz>
it'll show the files that the package you install contains
<coldspark29[m]>
@schulz: Any idea how to use environment variables in a yaml script for kas? I need to expand one for the url of a repository
<qschulz>
I assume you forgot to have an install target in your cmake or a proper do_install (the former is better)
<coldspark29[m]>
s/schulz/qschulz/
<qschulz>
coldspark29[m]: there's autocompletion usually in your IRC/matrix client so you don't have to type it by hand :)
<qschulz>
coldspark29[m]: no I don't know, you could always do a small sed before running kas though
<coldspark29[m]>
True
<ziga>
Okay! I will take a look at that and report back if I can't solve!
<ziga>
Thank you!
<coldspark29[m]>
There should be support for it in kas though
<coldspark29[m]>
I actually can't believe it isn't ^^
<ziga>
@qschulz I used "oe-pkgdata-util list-pkg-files application" and it returned an empty list. Probably I really have to do what you said.
<coldspark29[m]>
Seems like yaml doesn't support environment variables though.
<qschulz>
ziga: add an install target in your cmake :)
<ziga>
I use qmake... :/
<ziga>
What now?
<qschulz>
ziga: propbably possible too, look at other qmake recipes
<ziga>
Ok. I have to dive a bbit. Thanky again!
<coldspark29[m]>
Time of a github issue! ☝️
<coldspark29[m]>
s/of/for/
<qschulz>
coldspark29[m]: provide a usecase too so it's easier to convince people to work on it
<qschulz>
BTW, weren't you supposed to send a patch? I don't remember :p
<qschulz>
Ah yes, the EDITOR stuff
<qschulz>
but that was for pyrex :)
<coldspark29[m]>
qschulz: JPEW is not in favor of the idea. He said he hasn't come up with a good solution yet.
<coldspark29[m]>
He wants to implement it in general, but said our idea would create problems. I don't really see why, but well
<coldspark29[m]>
s/in general/somehow/
<rburton>
kanavin_: re your toolchain question, i've been meaning to switch meta-arm to use multiconfig for the machines where you have a 64-bit primary core but a 32-bit A or M core on the side, instead of using those binary compilers.
<coldspark29[m]>
> <@qschulz:libera.chat> BTW, weren't you supposed to send a patch? I don't remember :p
<coldspark29[m]>
* JPEW is not in favor of the idea. He said he hasn't come up with a good solution yet.
<qschulz>
coldspark29[m]: ah I see you opened an issue on Github, missed that one :)
<qschulz>
coldspark29[m]: would have been great to have the discussion on the github issue :)
<qschulz>
I might send a patch to "force" him to answer on the github issue/PR so that we have a trace somewhere :)
<coldspark29[m]>
qschulz: Yeah, IRC is volatile
<qschulz>
or if you have the logs of the discussion, it'd be great to add it to the issue
<coldspark29[m]>
We discussed it here
<qschulz>
coldspark29[m]: we have logs though
Vonter has quit [Ping timeout: 240 seconds]
<qschulz>
so just need to get the date at which this discussion happened and we'll find the logs :)
<coldspark29[m]>
qschulz: Can't find the logs in Matrix. No idea why
<coldspark29[m]>
devtool edit-recipe is not important enough to go through all of that hassle
Vonter has joined #yocto
<coldspark29[m]>
I guess I can try editing the dockerfile
<coldspark29[m]>
Prove my point and make a PR
sherbrechtsmeier has joined #yocto
sherbrechtsmeier has quit [Client Quit]
<hmw[m]>
hi i'm planning to convertet a project from qmake to cmake can a bb file support both ??
<qschulz>
hmw[m]: both at the same time wouldn't make much sense, but yes, qmake and cmake based projects are supportde
<hmw[m]>
<qschulz> "hmw: both at the same time..." <- i meen that i don´t like changing it back and forward when i need to build a "old" application
<qschulz>
hmw[m]: have two recipes then, with the same name but a different version and put DEFAULT_PREFERENCE = "-1" in the old one
<qschulz>
then you just need to select the reciep to build in your loca.conf with PREFERRED_VERSION_application = "<old_version<"
<qschulz>
if you don't do anything, then the newer version will be built
<qschulz>
it;s likely possible to have both qmake and cmake but i'm not sure it's worth the headaches it can potentially produce :)
akiCA has joined #yocto
<JPEW>
coldspark29[m]: GitHub issue is fine :)
<coldspark29[m]>
Hmm I just tried adding all the requiered editors in the Dockerfile and also set an `alias vi="vim"`, but it still doesn't find vi
akiCA has quit [Quit: Leaving]
<kanavin_>
rburton, right, but this is for the 32 bit primary core to host a compiler for the rtos core
<rburton>
oh you want an on-target compiler?
tgamblin_ has quit [Quit: Leaving]
tgamblin has joined #yocto
<coldspark29[m]>
<JPEW> "coldspark29: GitHub issue is..." <- Thanks, which container would be the one running devootl. I just tried adding them in the Alpine container which is probably wrong.
<coldspark29[m]>
which basically sets up the build directory. It overwrite all configurations I have made with kas and without it, it doesn't work. So I am wondering if Freescale relies on repo and this script, whether I should go with kas at all
<rburton>
fwiw, there's likely no real reason to use their setup script if you want to use kas
<coldspark29[m]>
I mean I could just do all the modifications from the script myself somehow, but it doesn't seem reasonable to duplicate efforts. Also, if Freescale does update their repo one day, I would have to do it all over
<coldspark29[m]>
rburton: Yeah, I am just not seeing the advantage of kas yet
Vonter has joined #yocto
<coldspark29[m]>
It seems like a cleaner solution than repo, but if I have to rewrite the script, it might just get too much work.
<rburton>
just use oe-init-build-env from oe-core
Vonter has quit [Ping timeout: 240 seconds]
<coldspark29[m]>
Ah seems like I just had a typo and the bblayers.conf was faulty
<coldspark29[m]>
It does compile now
<qschulz>
coldspark29[m]: meh, you probbaly don't need any of this stuff, just include the layers this script is adding to your kas.yaml file and add the ACCEPT_FSL_EULA variable to your local.conf (though.. one is not supposed to automate that, hence probably the script)
<coldspark29[m]>
Although it shows me an error when I clone the first time
<qschulz>
coldspark29[m]: that's not enough info unfortunately for us to be able to help you
Vonter has joined #yocto
<coldspark29[m]>
It is our own repository on Gerrit that I am cloning via ssh. It shows an error, but everything works afterwards.
<coldspark29[m]>
s/repository/meta-layer/
sherbrechtsmeier has quit [Quit: Client closed]
Tokamak has joined #yocto
<coldspark29[m]>
If I take it out of the cloning list, there is no error. All other layers come from Github or Gitlab. I think Gerrit and ssh is just not well supported or there is an issue with our Repo.
<coldspark29[m]>
qschulz: Is there a way to let kas setup Pyrex as well?
<coldspark29[m]>
When I I let it checkout pyrex, it complains that there is no layer.conf inside, because it is technically not a layser I guess
<qschulz>
kas is for production, pyrex for dev
<qschulz>
so just clone and setup pyrex manually
nodeboy[m] has quit [Quit: You have been kicked for being idle]
<qschulz>
you're trying to have kas do the same thing as repo but that's not really what it's for?
nodeboy[m] has joined #yocto
nodeboy[m] has left #yocto [#yocto]
olani has joined #yocto
florian has quit [Ping timeout: 256 seconds]
TundraMan has joined #yocto
marka has quit [Ping timeout: 240 seconds]
florian has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<camaronut>
Since then I've added more debugging output to rpmbuild. It turns out the SSL package is occasionally getting no files added to it's linked list of things to do, so it's effectively trying to create an empty cpio archive inside the RPM, which is only caught when it attempts to close out the cpio by writing a trailer.
<RP>
rburton: what was the cause of the cpio thing you were seeing?
<RP>
rburton: camaronut was seeing it with dunfell
<rburton>
hm
<RP>
camaronut: it seems strange that a zero length list of files would do that, sounds like a bug :/
<RP>
camaronut: did you find a fix?
<RP>
rburton: it may be you just worked around it?
<rburton>
my problem was was insane parallism causing fork() to fail
<rburton>
i just reduced XZ_THREADS a lot
<rburton>
oh and ZSTD_THREADS too
<rburton>
as some rpms use zstd instead
<rburton>
on my machine, there are 256 'cores', BB_NUMBER_THREADS and PARALLEL_MAKE is set to 32, but ZSTD_ and XZ_THREADS is 8
<RP>
rburton: dunfell wouldn't be using zstd though
<rburton>
true
<RP>
rburton: perhaps it is a different issue, just sounded similar
<camaronut>
RP: not yet. I got stalled up trying to understand the linked list they're using to add files. The debug I had was in the while() loop that added files to the cpio. That while loop is never entered.
<qschulz>
also, if built within a container, you have a few other settings to set right? like max number of pids and mount a tmpfs in /tmp for some reason
<qschulz>
but eh, that's all I can bring to the discussion :p
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton>
mine was obvious as the package log was full of permission denied errors
<camaronut>
qschulz: we are using a docker container...
<RP>
camaronut: might be worth a look at that code upstream, see if any fixes were made
<camaronut>
72 thread machine
<camaronut>
RP: Yup. Upstream reimplemented the OpenMP changes that were proposed for building the packages.
<camaronut>
RP: I'll look some more.
<qschulz>
camaronut: pids_limit = 1000000 in containers.conf (for podman)
<qschulz>
+ --tmpfs /tmp for podman run too
<qschulz>
that was what was needed for us to make it work
<camaronut>
qschulz: thanks for the tip! I'll take a look at those for our setup.
florian has quit [Ping timeout: 256 seconds]
argonautx has joined #yocto
locutusofborg_ is now known as locutusofborg
locutusofborg has quit [Changing host]
locutusofborg has joined #yocto
locutusofborg is now known as LocutusOfBorg
Guma has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
Guma__ has joined #yocto
Guma has quit [Ping timeout: 256 seconds]
Guma__ is now known as Guma_
Guma_ has quit [Client Quit]
Guma has joined #yocto
Guma has quit [Client Quit]
zpfvo has quit [Remote host closed the connection]
Guma has joined #yocto
<codavi>
Is there any specific reason why 'SECURITY_CFLAGS' variable (-D_FORTIFY_SOURCE=2 -Wformat etc) gets added to 'CC' rather than 'CFLAGS' ? Readily noticeable in SDK environment-setup file.
<codavi>
This makes it hard to make a debug build for apps but Poky/SDK itself is built regularly (not debug) without doing something to remove security flags from 'CC'
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guma has quit [Client Quit]
Guma has joined #yocto
Guma has quit [Client Quit]
Guma has joined #yocto
Guma has quit [Client Quit]
tlhonmey has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 256 seconds]
tlhonmey has joined #yocto
Guma has joined #yocto
Guma__ has joined #yocto
Guma has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Tokamak has joined #yocto
goliath has joined #yocto
Guma__ is now known as Guma
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
amitk has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 240 seconds]
d0ku has quit [Ping timeout: 256 seconds]
d0ku has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
d0ku has quit [Ping timeout: 256 seconds]
risca has joined #yocto
amitk_ has quit [Ping timeout: 240 seconds]
Guma has quit [Quit: Good Night Everyone...]
florian has joined #yocto
ziga has quit [Quit: Leaving]
ziga has joined #yocto
<kanavin_>
RP: I noticed immediately, but didn't have the heart (or guts) to tell you off :) besides, webkit ignored all of my submissions so far, or maybe I'm using the wrong channel somehow
<kanavin_>
at least openssl should be fairly simple
<JPEW>
kanavin_: Did you go though WebKit bugzilla?
<kanavin_>
JPEW, I think so - you can check the links in the patches I submitted
<kanavin_>
there's a script that creates bugzilla tickets from the command line and attaches the patch from what I remember
<JPEW>
kanavin_: Ya, thats what I did
mvlad has quit [Remote host closed the connection]
yates has joined #yocto
<yates>
is there a way to generate a call graph (dependency graph) for an application built within yocto?
<rburton>
nothing yocto specific
<rburton>
assuming you mean at the binary level, and not package management level
<yates>
yes, at the binary level. anything non-yocto specific?
<yates>
(read: anything, anywhere, that can do this?)
<yates>
i was looking at sourcetrail and lucidchart
<yates>
how are you, rburton? Happy New Year
<RP>
kanavin_: the webkit one needs someone with ruby knowledge. I'm sure I could figure it out but there are other more pressing issues
<RP>
kanavin_: I was just wondering if you'd say anything :)
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
ziga has quit [Ping timeout: 240 seconds]
mrpelotazo has quit [Read error: Connection reset by peer]
<camaronut>
RP: I looked through the upstream rpm git logs. There's a few changes that mention they fix data races, but the patches would not apply cleanly to what Dunfell currently has. I just forklifted rpm 4.16.1.3.bb (and files) from hardknott and ran my repro script. So far I've repackaged openssl 11 times and it's fine. I'll continue to run the
<camaronut>
script overnight and report back the results.
goliath has quit [Quit: SIGSEGV]
mrpelotazo has joined #yocto
<RP>
camaronut: thanks for the info. sakoman might fine it interesting too
<jonmason>
Honestly, I'm concerned why a bed would even need YP
<fray>
Sleep number has a lot of IoT in their controllers now
<jonmason>
I can be paranoid
lucaceresoli has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
florian has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
<tlhonmey>
jonmason: Because obviously you need to be able to adjust the firmness of your bed from your smartphone. What other way would there be to do it?