LainExperiments has quit [Ping timeout: 240 seconds]
astlep5504018066 has quit [Ping timeout: 272 seconds]
LainExperiments has joined #yocto
Xagen has joined #yocto
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
LainExperiments has quit [Quit: Client closed]
ello has quit [Read error: Connection reset by peer]
ello has joined #yocto
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #yocto
stgl has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
LainExperiments has joined #yocto
enok has joined #yocto
LainExperiments has quit [Ping timeout: 240 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 276 seconds]
Articulus has quit [Ping timeout: 276 seconds]
PhoenixMage has quit [Remote host closed the connection]
<Oxbef>
AdrianF: Thanks for the reply and for your work on ide-sdk. I watched your presentation a few days ago actually
<Oxbef>
I'm waiting for my test environment to finish compiling so I can try that out
<Oxbef>
Is it your recommendation that it be used directly in a yocto build environment rather than from a standalone eSDK ?
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tammranil has quit [Remote host closed the connection]
tammranil has joined #yocto
amitk_ has quit [Remote host closed the connection]
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
ello has quit [Ping timeout: 252 seconds]
enok has quit [Ping timeout: 276 seconds]
ello has joined #yocto
ello has quit [Ping timeout: 265 seconds]
ello has joined #yocto
ello has quit [Ping timeout: 248 seconds]
<AdrianF>
Oxbef: Yes, is is used directly from the bitbake environment. It is not included in the eSDK installer. We updated also the documentation to cover that recently.
<AdrianF>
Oxbef: There is no reason for a static installer, if it is possible to replicate a bitbake environment as simple as installing an eSDK installer and if the bitbake environment has all the features of the eSDK installer. That's basically the feature of providing a cross-compile environment-... file.
<AdrianF>
Oxbef: Feature wise, I think there is no longer any advantage with the eSDK installer.
<AdrianF>
Oxbef: Replicating the bitbake environment basically means: Setup the layers and the build folder with the build configuration (e.g. with git sub-modules, bitbake-setup, kas...). The you need a shared sstate-cache which is now also an official feature.
leon-anavi has joined #yocto
rob_w has joined #yocto
CrazyGecko has quit [Ping timeout: 246 seconds]
goliath has joined #yocto
mckoan|away is now known as mckoan
enok has joined #yocto
mathieud1 is now known as mathieudb
mathieudb has quit [Changing host]
mathieudb has joined #yocto
frieder has joined #yocto
nerdboy has quit [Ping timeout: 245 seconds]
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
frgo has joined #yocto
dmoseley has quit [Ping timeout: 244 seconds]
dmoseley has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
olani- has quit [Ping timeout: 252 seconds]
enok has quit [Ping timeout: 260 seconds]
<derRichard>
sometimes "checking sstate mirror object availability" runs over and over. is this normal? currently it runs the 12th time in a row. all i did was moving from one scarthgap release to another one.
<derRichard>
my sstate mirror is fast, but each run still takes about one minute.
Jones42 has joined #yocto
frieder has quit [Ping timeout: 244 seconds]
ablu has quit [Ping timeout: 252 seconds]
ablu has joined #yocto
savolla has joined #yocto
davidinux has joined #yocto
florian has joined #yocto
frieder has joined #yocto
<ederibaucourt>
AdrianF: I did make fixes for ide-sdk to work through the eSDK during the initial submission. Is this no longer supported?
<ederibaucourt>
AdrianF: BTW, I received feedback on the VSCode extension of people using ide-sdk for "complex CMake applications". They were loving it :D
paulg has quit [Remote host closed the connection]
<AdrianF>
ederibaucourt: First of all we need to define the term eSDK. It can be understand as "The eSDK installer" generated by populate_sdk_ext or it can be understand as "an eSDK bootstrapped directly from the bitbake environment" set up e.g. by devtool ide-sdk.
OnkelUlla has quit [Read error: Connection reset by peer]
OnkelUlla has joined #yocto
leonanavi has joined #yocto
Jones42 has quit [Ping timeout: 244 seconds]
leon-anavi has quit [Ping timeout: 276 seconds]
Jones42 has joined #yocto
rob_w has quit [Remote host closed the connection]
<AdrianF>
I think we should replace the current implementation of populate_sdk_ext with two new approaches to replicate the full bitbake environment: The dynamic approach with shared state cache and bitbake setup driven by Alex. And if necessary, a populate_sdk_ext that just creates a tar of the bitbake environment without relocating anything or restricting
<AdrianF>
the environment that provides e.g. devtool but not bitbake. Maybe the second one is easy to implement later based on the first one.
rob_w has joined #yocto
<RP>
AdrianF: you are right that reworking the eSDK was being put off until we worked out what bitbake-setup was doing
florian has joined #yocto
rob_w has quit [Ping timeout: 260 seconds]
<AdrianF>
Just to be clear. The goal is not to force anyone to use bitbake. Tools like CMake, Meson or Cargo need to be what application developers see. Absolutely.
<AdrianF>
But the goal must also be that bitbake is available in any environment if you want to use it to change your SDK. Providing a special, static Yocto environment without bitbake hardly makes sense. If the user does not change anything, bitbake simply reuses everything from the sstate-cache. That's how it works anyway.
<AdrianF>
In a nutshell, I think we are aiming for: bitbake-setup replicates the bitbake environment as easy as calling populate_sdk_ext and install the installer.
<AdrianF>
devtool ide-sdk bootstraps the SDK with the tool-chain environment file and/or with IDE configuration for a particular recipe.
savolla has quit [Quit: WeeChat 4.4.3]
rob_w has joined #yocto
enok has joined #yocto
rob_w has quit [Ping timeout: 248 seconds]
paulg has joined #yocto
rob_w has joined #yocto
CrazyGecko has joined #yocto
florian_kc has joined #yocto
olani- has joined #yocto
<kanavin_>
AdrianF, "populate_sdk_ext that just creates a tar of the bitbake environment" - I have a working prototype for that too. We should launch bitbake-setup first, then we can look into that.
<JaMa>
RP: was "bitbake.conf: Start to separate out gcc related variable definitions" pushed to master and then removed or is git.oe.org mirror out of sync again? as I've seen it in master on one server when CI was running and don't see it now
<RP>
JaMa: it was meant just to be added, it shouldn't have been removed
<RP>
JaMa: I suspect an out of sync mirror
<JaMa>
ok, will send e-mail to helpdesk if it doesn't re-appear soon
florian_kc has quit [Read error: Connection reset by peer]
* RP
feels a bit better now the release information is being used a bit more consistently, the toaster fixtures get checked and we validate SANITY_TESTED_DISTROS
<JaMa>
halstead: if you happen to be here, then mirrors went backwards again as last week, will send e-mail to helpdesk later if you want
<AdrianF>
kanavin_: That looks awesome!
<kanavin_>
AdrianF, I initially tried to make it as a bitbake task, but quickly ran into the problem of running bitbake inside bitbake (it goes into deadlock). It's probably solvable, but it was faster to get to a working prototype in the form of an external script.
<kanavin_>
AdrianF, bitbake task implementation would also have difficulty in being tweaked or customized. A script can just take command line options. I'm sure you know the confusing zoo of ESDK variables.
<AdrianF>
kanavin_: Would it make sense to have something like --sstate=[included,manifest,none] Instead of just --no-sstate? I'm thinking about a possibility to relax the requirement for providing a full featured sstate mirror infrastructure. There are still a few challenges to make the working secure, fast, world-wide and whatever requirements different
<AdrianF>
users have on top.
savolla has joined #yocto
<kanavin_>
AdrianF, what's the difference between included and manifest?
Jones42 has quit [Ping timeout: 252 seconds]
<AdrianF>
kanavin_: Offering a manifest (a file containing all the artifact names which are needed for this SDK) as a basis for a script which downloads the sstate-artifacts into SSTATE_DIR independently from bitbake. In theory that's not needed. But in practices it would probably enable users to handle sstate artifacts in a custom way.
Jones42 has joined #yocto
florian_kc has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
<kanavin_>
AdrianF, maybe, I don't know. The vast majority will want the sstate that is needed for the build they currently have, and only that sstate, and the script figures this out for them.
savolla has joined #yocto
savolla has quit [Client Quit]
<AdrianF>
kanavin_: The challenge which I see is providing a sstate-cache mirror infrastructure. Yocto does that publicly with a CDN without security. That's not a solution for most downstream projects. So who does then a easy to setup and maintainable solution look like (with or without hash equivalnce server)? When security and scalability is needed,
<AdrianF>
that's not so easy. Saying that's the list of files we need, drop it into SSTATE_DIR is at least easy to understand and to implement somehow. It also allows incremental updates which is not possible with "included in the tar".
<kanavin_>
ah, you want to replace the actual sstate objects with a list of them in the tarball itself?
savolla has joined #yocto
<AdrianF>
kanavin_: yes.
<kanavin_>
but bitbake can do this for you too: if targets are known you can ask it to run setscene-only or something similar, and then you'll have populated SSTATE_DIR
<AdrianF>
kanavin_: Yes, I know and that's the perfect solution. But there are many use cases and requirements which make it very hard to get that working (with security).
<AdrianF>
kanavin_: Another use case for the manifest, which I see: You have a build machine with many sstate artifacts. Which artifacts are part of a released SDK, which are obsolete and can be deleted?
<kanavin_>
AdrianF, you can check what went into the tarball, and delete the rest. I agree that the tarball can simply always have the manifest, and actual objects are optional. Maybe it already does, I forgot!
<kanavin_>
I guess you should just play with the script, take the branch because it has important supporting commits for it.
<AdrianF>
kanavin_: Having alsway a manifest would probably be the best. Agree.
frgo has quit [Quit: Leaving...]
enok has quit [Ping timeout: 248 seconds]
florian_kc has quit [Ping timeout: 276 seconds]
Guest9884 has joined #yocto
<Guest9884>
Hello!
<Guest9884>
i currently working on a project that uses multiple architectures (x86 / ARM etc.)
<Guest9884>
The current goal is to create a common base for all systems. The first step is to unify the bootloader.
<Guest9884>
My decision was u-boot - Currently i'm working on x86 (generic intel mainboard with efi support)
<Guest9884>
I already build u-boot for efi and can load and execute the kernel.
<Guest9884>
At the moment i have the following issue: When i load the kernel i have to specify a fixed path - For example "ext4load efi 0:2 03000000 /boot/vmlinuz"
<Guest9884>
When there is no other storage device this is not an issue, but when i add an usb drive the device id is changing - Now i have to load it from "...efi 1:2..."
<Guest9884>
Is there any way to use names/uuids/paths directly as devid alternative?
tchx84 has joined #yocto
tgamblin has joined #yocto
<kanavin_>
I guess this question is better asked in a u-boot forum?
frieder has quit [Ping timeout: 252 seconds]
<tchx84>
Hi everyone, quick question about PERSISTENT_DIR... I understand that keeping that directory's contents for future builds can speed up things, but can that directory be shared across multiple parallel builds like with SSTATE_DIR? This is, assuming a scenario where I have multiple builds running on a single machine, already sharing SSTATE_DIR.
florian_kc has joined #yocto
frieder has joined #yocto
wojci has joined #yocto
<kanavin_>
tchx84, PERSISTENT_DIR is specific to a particular build, so no.
<kanavin_>
it can speed up that one build, but you can't use it to speed up other builds.
<kanavin_>
in any case, sharing SSTATE_DIR will give you 99.99 percent of possible speedups
<RP>
mathieudb: The above is from the repoducible fail on master-next, probably not from any patches there :(
rob_w has quit [Remote host closed the connection]
savolla has quit [Quit: WeeChat 4.4.3]
<khem>
one corelation I can make is that uninative got glibc 2.41 lately, so it could be that too since its invoking native libraries and uninative
wooosaiiii has quit [Ping timeout: 252 seconds]
tchx84 has quit [Ping timeout: 240 seconds]
<RP>
perhaps but I'd have probably expected it sooner
wojci has quit [Ping timeout: 276 seconds]
<Oxbef>
AdrianF: Thank you for your response regarding the use of the eSDK vs other approaches.
<Oxbef>
I've got a lot of pieces to tie together in my org to come up with a standard environment for us. I am actively trying out the ide-sdk feature to see if this will fit with the workflow.
frieder has quit [Remote host closed the connection]
grma has quit [Remote host closed the connection]
ptsneves has joined #yocto
Oxbef has quit [Ping timeout: 246 seconds]
Oxbef has joined #yocto
<JaMa>
RP: I see that most of -next branches were removed from oe-core, but not origin/rocko-next was that intentional?
<JaMa>
RP: it has couple gnupg commits from rburton which aren't in rocko branch, but I don't think anyone will miss them now :)
<RP>
JaMa: it was the only one which was unmerged. I wasn't sure what to do with it
<RP>
JaMa: I was tempted to delete it...
CrazyGecko has quit [Quit: Konversation terminated!]
<JaMa>
RP: ok, I see (I thought it as just overlooked)
enok has joined #yocto
grma has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 268 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pvogelaar has joined #yocto
pvogelaar has quit [Remote host closed the connection]
tchx84 has joined #yocto
florian has joined #yocto
tgamblin has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 260 seconds]
cyxae has quit [Quit: cyxae]
cyxae has joined #yocto
sotaoverride has joined #yocto
Kubu_work has quit [Quit: Leaving.]
mckoan is now known as mckoan|away
tchx84 has quit [Ping timeout: 240 seconds]
davidinux has quit [Quit: WeeChat 4.3.1]
Jones42 has quit [Ping timeout: 248 seconds]
Jones42 has joined #yocto
Jones42 has quit [Ping timeout: 260 seconds]
savolla has joined #yocto
ptsneves has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
florian has quit [Ping timeout: 248 seconds]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
GillesM has joined #yocto
GillesM has quit [Remote host closed the connection]
Xagen has joined #yocto
leonanavi has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 is now known as enok
savolla has joined #yocto
druppy has joined #yocto
enok has quit [Remote host closed the connection]
druppy has quit [Quit: druppy]
druppy has joined #yocto
savolla has quit [Quit: WeeChat 4.4.3]
Slimey has quit [Remote host closed the connection]
savolla has joined #yocto
florian has joined #yocto
Slimey has joined #yocto
goliath has joined #yocto
Jones42 has joined #yocto
Kubu_work has joined #yocto
florian has quit [Ping timeout: 265 seconds]
Jones42 has quit [Ping timeout: 245 seconds]
florian has joined #yocto
savolla has quit [Ping timeout: 248 seconds]
savolla has joined #yocto
Jones42 has joined #yocto
Jones42 has quit [Ping timeout: 268 seconds]
florian has quit [Ping timeout: 260 seconds]
florian has joined #yocto
savolla has quit [Ping timeout: 260 seconds]
savolla has joined #yocto
enok has joined #yocto
enok71 has joined #yocto
enok has quit [Ping timeout: 252 seconds]
enok71 is now known as enok
cyxae has quit [Quit: cyxae]
druppy has quit [Ping timeout: 252 seconds]
ptsneves has quit [Ping timeout: 260 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]