<rburton>
usvi: worth skimming as it has some useful stuff in about versioning but yeah if you're installing a library then it should be versioned
ehussain has joined #yocto
ahussain has joined #yocto
ehussain has quit [Ping timeout: 255 seconds]
ahussain is now known as ehussain
davidinux1 has joined #yocto
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
CrazyGecko has joined #yocto
Guest56 has joined #yocto
<Guest56>
how do I override the make command to use the host make instead of native-systemtools for a single layer? I tried MAKE:task-compile = "/usr/bin/make" in meta-custom/conf/local.conf but it gets ignored
frieder_ has quit [Quit: Leaving]
mbulut has joined #yocto
<usvi>
rburton: looks solid, thank you very much !
<usvi>
I was just scavenging the internet for shared libraries best practices guide
<Scorpi>
I would like some insight in the nativesdk part of Yocto. I looks to me as if a hardcoded patch is used during the build process ("/usr/local/oe-sdk-hardcoded-buildpath") which is later replaced by the real path to the sysroot. This also seems to apply to the LD loader path, is this later changed using patchelf --set-interpreter or similar?
frieder has quit [Ping timeout: 252 seconds]
<Scorpi>
s/hardcoded patch/hardcoded path/
<RP>
Scorpi: that sounds about right. It is so we don't rely on the host system's glibc version
frieder has joined #yocto
<RP>
Scorpi: scripts/relocate_sdk.py is the relocation script for the SDK that updates things. We also support some magic sections we remap value sin
<Scorpi>
RP: thanks
<Scorpi>
Where am I supposed to report a bug in a recipe in meta-openembedded/meta-oe? Is this considered a Yocto component is this handled by openembedded.org?
<RP>
Scorpi: openembedded-devel list
<RP>
Scorpi: there aren't enough people willing to support a bugzilla workflow for meta-oe
<Scorpi>
RP: thanks++
Guest56 has quit [Quit: Client closed]
sotaoverride has quit [Ping timeout: 272 seconds]
sotaoverride has joined #yocto
Jones42 has joined #yocto
PhoenixMage has joined #yocto
frieder has quit [Ping timeout: 252 seconds]
aduskett has joined #yocto
mbulut has quit [Ping timeout: 265 seconds]
frieder has joined #yocto
ehussain has quit [Ping timeout: 265 seconds]
albeu has joined #yocto
florian_kc has joined #yocto
davidinux has quit [Ping timeout: 272 seconds]
davidinux has joined #yocto
davidinux has quit [Quit: WeeChat 4.3.1]
Jones42 has quit [Read error: Connection reset by peer]
sotaoverride has quit [Ping timeout: 252 seconds]
sotaoverride has joined #yocto
davidinux has joined #yocto
frieder has quit [Ping timeout: 260 seconds]
frieder has joined #yocto
tostr has quit [Remote host closed the connection]
raghavgururajan has quit [Remote host closed the connection]
sfo has quit [Remote host closed the connection]
jonesv has quit [Remote host closed the connection]
tleb has quit [Remote host closed the connection]
tleb has joined #yocto
sfo has joined #yocto
raghavgururajan has joined #yocto
tostr has joined #yocto
jonesv has joined #yocto
mbulut has joined #yocto
ehussain has joined #yocto
sotaoverride has quit [Ping timeout: 276 seconds]
sotaoverride has joined #yocto
mbulut has quit [Ping timeout: 265 seconds]
mbulut has joined #yocto
mbulut has quit [Ping timeout: 246 seconds]
rob_w has quit [Remote host closed the connection]
rob_w has joined #yocto
mbulut has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
Jones42 has joined #yocto
frieder has quit [Ping timeout: 265 seconds]
cyxae has joined #yocto
Minvera has joined #yocto
albeu has quit [Quit: albeu]
thomasxweber has quit [Quit: Client closed]
thomasxweber has joined #yocto
nerdboy has quit [Ping timeout: 245 seconds]
<dankm>
JPEW: nothing specific, just SPDX 3 support. We have customers chomping at the bit for it over 2.2, and we have management unwilling to give us enough time to properly update, so LTS releases it is for us for now.
<JPEW>
dankm: There were a few more invasive changes in bitbake that SPDX 3 required, so the original plan was not to backport them to the LTS
Xogium has quit [Remote host closed the connection]
Xogium has joined #yocto
rob_w has quit [Remote host closed the connection]
<RP>
dankm: it is also outside the "no new features" policy for the LTS
florian_kc has joined #yocto
<dankm>
Sure, wasn't sure if spdx 3 was a new feature or not. Thanks for the confirmation, though!
jmd has joined #yocto
gspbirel56 has joined #yocto
aduskett has quit [Remote host closed the connection]
<mbulut>
i'm a bit confused about how a recipe that inherits go-mod fetches the sources
<mbulut>
it seems like the sources of the actual package (not the dependencies) get fetched as a submodule
<mbulut>
i need to patch the sources (using devtool modify) but unsure how patching would work when the patch is generated from my commit to the submodule...
<mbulut>
any idea how to do this properly?
Kubu_work has quit [Quit: Leaving.]
prabhakalad has quit [Quit: Konversation terminated!]
<RP>
mbulut: the build happens in stages, do_fetch, do_unpack and then do_patch. Patches are applied in do_patch so apply once all the submoduels are unpacked
<mbulut>
yeah i know that but how would the patch task know that the patch is to be applied to the submodule and not the top level source repo?
<RP>
mbulut: it doesn't care. It applies a patch to ${S}, ie the sources directory
<RP>
mbulut: it doesn't need to know how things are structured underneath. it does mean your patch won't quite match something you'd submit to the upstream submodule
<mbulut>
so you suggest to just create a commit in the submodule, then git format-patch it and put it to files just as usual?
<RP>
no, I'm suggesting you need a patch at the top source level
<RP>
use quilt to create it rather than git?
<RP>
or take the git one and add to the directory levels as needed
* RP
is old school and hand edits patches :/
<mbulut>
yeah the old skool hack is what i had tried next but wondered about a "proper" way to deal with this kind of scenario
<mbulut>
haven't used quilt too much to create patches -- i assume from what you say that it can generate a patch from top level source where the change is in a submodule?
fff has joined #yocto
<RP>
mbulut: quilt is what do_patch uses to apply patches, you can use it to create them too
fff has quit [Remote host closed the connection]
Ad0 has quit [Ping timeout: 252 seconds]
ddd has joined #yocto
ddd has quit [Remote host closed the connection]
druppy53 has quit [Quit: Client closed]
druppy has quit [Ping timeout: 252 seconds]
<mbulut>
RP, ok the patching worked as you suggested, thx
<mbulut>
i had to fix the directory levels by hand though -- even with quilt
<mbulut>
from a devtool modify session i did: quilt new, quilt add, changed file and finally quilt refresh
<RP>
you probably needed to do quilt new in a different directory?
frgo has joined #yocto
frgo has quit [Ping timeout: 245 seconds]
<mbulut>
i was in workspace/sources/cosign
<mbulut>
on a side note, quilt wasn't in PATH after i had executed devtool modify
cyxae has quit [Quit: cyxae]
<mbulut>
so ran the quilt binary that was in the normal recipe-sysroot-native
<RP>
mbulut: patches to improve things welcome, I'm a litte surprised it wasn't :/
<RP>
I guess I should be saying to at least file a bug so we can track the issue
<RP>
I'm feeling a bit demoralised myself since we don't have many people working on things like devtool
<mbulut>
dude if you knew how much i'd love to give sth back but company policies don't allow contributing to OSS
<mbulut>
this sentence alone sounds so odd, i know
<RP>
mbulut: yet you ask questions here and accept help and said company presumably benefits from OSS
<mbulut>
yes
<mbulut>
i know
<RP>
frustrating all around
<mbulut>
believe me, i'm making trouble about this on every occasion in our companny
<mbulut>
finally some people seem to start listening but we're not there yet
Ad0 has joined #yocto
<RP>
mbulut: I hope it works out and change happens
<mbulut>
if work wouldn't consume my day and night, i'd at least do sth in "my" time at night but i'm not there yet either :S
<mbulut>
i need to revise my work-life-balance
<RP>
mbulut: you and me both!
druppy has joined #yocto
<RP>
mbulut: is there anything we should be doing which might help convince such companies to help out more?
<mbulut>
idk, maybe a collage of 10s videos from companies that say "we contribute to OSS and it didn't hurt?"
<mbulut>
yeah but maybe sth more visible like a session in the next conference
<mbulut>
because we have people going there and they could take those messages back home with them to tell our decision makes "look, they were scared like us but it didn't hurt em"
<RP>
which conference?
<mbulut>
embedded linux conference
<mbulut>
i went to argue all the way up to the helicopter pod people in our business but concerns about IP and prejudice seemed too deep in their subconsciousness
<mbulut>
so i took a different strategy to crack that but it'll take some time...
frgo has joined #yocto
<RP>
mbulut: I'm not sure you'd get a presentation like that at a conference like ELC as it is kind of accepted by most people there that you need to collaborate with OSS :/
<RP>
mbulut: there is a big difference between collaborating on the OS or support software and your own special software/value add
<mbulut>
yeah, you got a point there
<RP>
At the OS level you don't want to be carrying changes, that costs you and doesn't add value
frgo has quit [Ping timeout: 252 seconds]
<RP>
That would be the point I'd be trying to make - at least let you collaborate on the pieces where it can save you money!
<RP>
I mean there are obviously different kinds of changes but in most cases... You know what I mean! :)
florian has quit [Ping timeout: 248 seconds]
<mbulut>
yeah
<mbulut>
the bigger concern seems to be that folks might be "wasting" time on contributing back instead of just get the job done
<mbulut>
it's a culture thing, esp for companies that based their products on WEC instead of Linux just a couple years back
<mbulut>
that said, even Microsoft understood the concept of OSS :P
<RP>
The world has changed a lot!
frgo has joined #yocto
<JPEW>
mbulut: You have to figure out what (specific) "business use case" OSS fulfills, and explain it to the execs that way; and it's a process. We started because we couldn't (reasonably) use newer SoCs without OSS, and it's grown from there (once we demonstrated how much it helped)
druppy has quit [Ping timeout: 255 seconds]
<fray>
part of open source is people build their work on others. By contributing back others can consume the work you did, which means in the future you can then consume their work. Theoretically the new the work the fewer bugs and more new (useful) features there would be.. things that you probably couldn't do alone..
<fray>
So your options are "be a consumer, and limit your work to what you can afford to do, and OSS is a supplier" or "You become part of the community and then the community is more willing to HELP you, and future product development as part of the process."
<JPEW>
fray: Right, but the abstract doesn't (in my experience) make sense to the execs. It's helpful to have that, but for a _specific_ problem you face
frgo has quit [Ping timeout: 265 seconds]
<mbulut>
yeah, the nut to crack is not the devs, you know that. you have to convince execs with arguments they can easily convert to gross margin growth and other KPIs they care for
<mbulut>
and JPEW points to the right direction in that
<JPEW>
mbulut: Correct. It got easier to argue the abstract once we "got the foot in the door", since it was a proven net gain
<fray>
Exec language.. you can purchase for free but then you have to support yourself, and are responsible for everything yourself. You can give back your useful (but not business specific) changes, and then get favors from others. You get a positive reputation, and people don't consider you a bad actor.
<fray>
This of course assumes the execs don't treat the world as theirs to exploit...
<fray>
for those execs, there is no 'future' thinking, and thus no reason to contribute back.. at that point it's time for developers to find a new job since that company will be screwed in 2-5 years (from at kleast a software perspective)
<mbulut>
to be fair, the reasons why such culture change takes more or less time can be manifold
<fray>
step 1, get permission to USE open source.. step 2 get permission to contribute back fixes.. step 3 get permission to 'start' (or manage) an open source project.. #1 is much easier then 3.. #2, if you can show isn't "expensive" can be done in most organizations.. #3 is hard
<mbulut>
if it's just a company with some bearded people in one room and a bunch of suits in the other, it may be easier
<mbulut>
but if your "company" is actually a tree of companies spanning the globe, with decision makers spread across multiple time zones, it's not the simplest task to find a new common culture
<fray>
it uses to be that #1 and then #2 were blocked by lawyers.. but many corporate lawyers now have references that OSS (with appropriate development process) is safe.. makes it easier to then justify the contributions