invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #yocto
sakoman has joined #yocto
grma has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
tunahan has quit [Quit: tunahan]
tunahan has joined #yocto
seninha has quit [Quit: Leaving]
sakoman has quit [Quit: Leaving.]
thomas__ has joined #yocto
mkazantsev has joined #yocto
Schlumpf has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
alessioigor has joined #yocto
nemik has joined #yocto
jclsn has quit [Quit: WeeChat 3.8]
amitk_ has joined #yocto
<Entei[m]>
How do you guys migrate from one version of Yocto to another? For eg, I had created a branch (which has my own layer) from langdale branch. Now mickledore is available. But simply doing a git merge results in a heap load of merge conflicts.
rob_w has joined #yocto
<Entei[m]>
Is creating a new branch from latest stable release branch (and then copy pasting my layer) the only way to migrate? Or is there a better solution which keeps my added files?
<Entei[m]>
Sorry, I do realise this is more of a git question than specifically Yocto question. But I feel it's valid.
<landgraf>
Entei[m]: are doing git merge in core layers? Doesn't seem right thing to do :)
<landgraf>
Entei[m]: I guess you have to switch core layers and then adjust yours (nor merge)
<Entei[m]>
landgraf: How exactly?
<landgraf>
Entei[m]: cd <path_to_core_layers> && git checkout langdale ; cd <path_to_your_layer> && git checkout -b langdale && edit conf/layer.conf && try to build && fix failures if any commit and celebrate if not
<landgraf>
Entei[m]: but it depends on your build system etc
<Entei[m]>
Oh I got an idea from this. Maybe I could try maintaining my layer as a separate git repo and add that a submodule
<Entei[m]>
* add that as a submodule
<landgraf>
It's up to you. git-repo, kas, submodule etc
rfuentess has joined #yocto
zpfvo has joined #yocto
mason has quit [Ping timeout: 264 seconds]
mvlad has joined #yocto
<LetoThe2nd>
Entei[m]: if you have added files to an existing layer, then thats the core problem. you either should keep all your modifications in your own layer, or submit them upstream.
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
<Entei[m]>
<LetoThe2nd> "Entei: if you have added files..." <- Haven't touched any file from poky core
<LetoThe2nd>
Entei[m]: but other layers?
nemik has joined #yocto
mkazantsev has quit [Remote host closed the connection]
<Entei[m]>
<LetoThe2nd> "Entei: but other layers?" <- Just added my own layer where all customizations occur. My layer includes files from yocto's layers
vladest has quit [Ping timeout: 252 seconds]
<LetoThe2nd>
Entei[m]: "includes files from Yoctos layers". So you copied stuff over?
<Entei[m]>
<LetoThe2nd> "Entei: "includes files from..." <- No. 'include' syntax in my layer's recipes
<LetoThe2nd>
Entei[m]: so what is the actual problem? your layer supposedly matches a specific release. then you branch out for a new release, and do the modifications for the upgrade on that branch. depending on your maintenance strategy, you either deprecate the old one, or not.
<Guest72>
Please， the pseudo use some systemcall which has been removed from glibc，like __fxstatat64, what can I do for this
<LetoThe2nd>
Guest72: send patches?
<Guest72>
I have a patch，but I'm not sure if it is a right way
<Guest72>
it works in my host
<LetoThe2nd>
Guest72: good start! put it onto the mailing list for review, thats the classic way :-)
vladest has joined #yocto
<Entei[m]>
<LetoThe2nd> "Entei: so what is the actual..." <- I was thinking on the lines of creating a single branch,say, devel, which would continuously be updated as per yocto releases. Today devel is branched from yocto-4.1, tomorrow I would merge updates from yocto-4.2. That was the idea
<LetoThe2nd>
Entei[m]: you can of course have a "main" or "devel" branch that always tracks the current state of upstream. It really depends on your maintenance strategy and requirements.
<Guest72>
I'm afraid
<Entei[m]>
LetoThe2nd: But upstream is divided into unstable (master) and the releases (kirkstone, langdale, mickledore etc). I don't want to track master branch, but rather the current stable release.
<LetoThe2nd>
Entei[m]: then call your branch "stable" and do that? but its a uncommon approach, as there can be multiple stable releases at a time and it will confuse your users. Branches named after releases is the current concensus.
<LetoThe2nd>
Guest72: no need to, why is that?
<Entei[m]>
LetoThe2nd: Yeah I think that's the approach I'll be taking now. My layer as a submodule, and then branch off the latest stable release
<Guest72>
I'm new , I'm afraid for have mistakes
<qschulz>
Guest72: even experienced people make mistakes :)
<qschulz>
that's what reviews are for
<LetoThe2nd>
Guest72: that definitely is not a problem. we have a very constructive discussion culture, and are very well aware of the fact that humans are not perfect.
<Guest72>
oh oh,
<Guest72>
I have send a mail to maintainer for some advice
<Guest72>
thanks for your help
<LetoThe2nd>
yw. let me know if you need something else.
<LetoThe2nd>
there was some script to delete old stuff from sstate, can anybody just give me a short pointer?
Guest72 has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
<qschulz>
find -atime +30 -delete ? :D
leon-anavi has joined #yocto
florian_kc has joined #yocto
ptsneves has joined #yocto
<LetoThe2nd>
qschulz: hehe
<rich1234>
Is there a specific way to write to the boot partition? I have one device which uses MLO and u-boot.img, and i get that to boot into the u-boot shell from my yocto output. I have another board that uses "tiboot3.bin, tispl.bin, u-boot.img" but I am having trouble getting the u-boot shell from that
<LetoThe2nd>
rich1234: can you please try to rephrase? it seems that you are mixing up build time (yocto) and runtime (u-boot shell), and those are only indirectly related. especially when it comes to early stage booting, it is very hw dependent.
bps has quit [Ping timeout: 276 seconds]
<rich1234>
Basically, I have used Yocto to build for two different machines. One is the am57xx-evm, and I can take the MLO file and u-boot.img files and put it into my boot partition on my SD card and it'll work just fine. I have built for another device "j721s2-evm" and from the TI documentation it seems like I just need to put three files on the boot
<rich1234>
partition of my SD card to launch a u-boot shell. I am not so familiar with bootloaders, so I don't know if you have to write the files to a specific location on the SD card or if there is something more to just copying these three boot files that I am missing. As it is difficult to debug why the u-boot shell isn't being launched other than my
<rich1234>
machine setup is wrong
<rich1234>
Perhaps more suited to the TI forums but I was wondering if anyone had any ideas
<LetoThe2nd>
rich1234: i still can't follow. you build, then you copy the files over, and you expect the u-boot shell to appear? it doesn't do, though - but what happens?
amitk__ has joined #yocto
<rich1234>
nothing happens, with TI's provided SDK it outputs the log onto /dev/ttyUSB2. Likewise with the am57xx-evm images, I get my u-boot output on /dev/ttyUSB0
amitk_ has quit [Ping timeout: 246 seconds]
<rich1234>
So it makes me wonder if I have built for the wrong machine or I am missing something fundamental
<ptsneves>
how do i force the git fetcher to use the file:// prefix on a git repository? I need this because I find no way to make the fetcher --no-local
<landgraf>
just like protocol=https for github etc
<ptsneves>
landgraf: the default protocol is file:// when the URL parameter is not specified. Setting it has no effect and leads to an error just the same.
<landgraf>
hmmm. bug?
<ptsneves>
I think so and there is no workaround with the FETCHCMD_git unfortunately.
<landgraf>
ptsneves: it should be possible to use premirror as a workaround, unless it's broken too
<LetoThe2nd>
ptsneves: sounds like you're trying to replicate externalsrc
<ptsneves>
landgraf: If it tries to clone with the file protocol then I am not sure.
<ptsneves>
LetoThe2nd: I did not think of that! I just got this issue to triage something that used to work, but your insight is good.
<landgraf>
ptsneves: it extracts tarball with git repo inside
<ptsneves>
landgraf: ah but then i would need to prepare such tarball and I would like to avoid changing the sources delivery. I will try the externalsrc route before.
<landgraf>
ptsneves: yes, that's why it's a workaround.
seninha has joined #yocto
goliath has joined #yocto
rob_w has quit [Quit: Leaving]
rfuentess has quit [Remote host closed the connection]
seventh-chord5 has joined #yocto
vladest has quit [Quit: vladest]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
thomas__ has quit [Ping timeout: 260 seconds]
mkazantsev has quit [Remote host closed the connection]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
Bhstalel has joined #yocto
Guest39 has joined #yocto
<Bhstalel>
Hello everyone, if I have some advanced and well presented Yocto videos, is there a possibility to upload them to the official Yocto youtube channel ?
<Guest39>
bhstalel I am definitely interested in that, can you share the link if you've already uploaded it to your own channel?
<rburton>
LetoThe2nd: ^
seventh-chord5 has quit [Quit: Client closed]
seventh-chord has joined #yocto
<LetoThe2nd>
bhstalel: definitely, it just depends a bit on copyright respectively original source.
<Bhstalel>
I have slides and I recorded them in my native language, I am just looking for the possibility, if it is okay, then I will record them in english
<Bhstalel>
My content will be well presented and detailed, I have already some diagrams shared by Yocto official Linkedin profile, and I am top6 #yocto answers provider on stackoverflow.
<seventh-chord>
Hi! I'm building a custom distro based on dunfell, and I had an issue where a bunch of packages were missing from the SDK. What happend was that one package which was being included as a dependency of a complementary package was conflicting with a package that I was installing directly through `TOOLCHAIN_TARGET_TASK`. This caused opkg to error out,
<seventh-chord>
but since this happened during the `install_complementary` stage, the error was ignored (package_manager.py, install_complementary() calls install(..., attempt_only=True). Based on the comment in the file it looks like this is to allow the SDK to build even if not all complementary packages are found, which sounds reasonable. But it has the
<seventh-chord>
unfortunate side effects of hiding other errors. Also, isn't the `oe-pkgdata-util` step in the function supposed to filter out -src/-dev/etc. packages which don't exist anyways?
<Bhstalel>
I just want to contribute to the community and help everyone understanding well Yocto.
<seventh-chord>
Sorry if this isn't the right place for this kind of question. Also, just to clarify, I'm able to solve the concrete problem I have. My question is rather about whether it makes sense for the code to do `attempt_only=True`, shouldn't this always be an error instead of a warning?
vladest has quit [Remote host closed the connection]
jpuhlman has quit [Ping timeout: 252 seconds]
Guest39 has quit [Quit: Client closed]
<LetoThe2nd>
bhstalel: thanks for that! we just want to avoid re-publishing things for some reasons. so if you already have a personal channel, then we can add your videos to our 3rd-party list at https://www.youtube.com/playlist?list=PLD4M5FoHz-TxHvWIsBmGMNnLud8EPGljX (that one is rather new). if you want to "donate" the content to us, then we can probably put it onto the official channel
Guest39 has joined #yocto
<LetoThe2nd>
bhstalel: please note that the latter makes monitoring and asking eventual questions more complicated for you, so generally i would prefer the personal channel way, and we will happily promote it. especially in your native language!
vladest has joined #yocto
vladest has quit [Client Quit]
vladest has joined #yocto
<Bhstalel>
LetoThe2nd I can find you always in this channel ? Or if you have other way to contact you it would great also.
vladest has quit [Client Quit]
<LetoThe2nd>
LetoThe2nd: you can usually find and ping me here (EU office times), or mail to jester@theyoctojester.info :-)
<Guest39>
LetoThe2nd you're a jester? please entertain us :)
<LetoThe2nd>
Guest39: what do you call a build that passes in less than 2 minutes?
<Guest39>
LetoThe2nd no idea... :)
<LetoThe2nd>
Guest39: BORING!
<Guest39>
LetoThe2nd xD nice one, thanks now I have gained some energy
fullstop_ has joined #yocto
perfinion has quit [Ping timeout: 252 seconds]
fullstop has quit [Ping timeout: 252 seconds]
Guest39 has quit [Quit: Client closed]
florian has quit [Ping timeout: 252 seconds]
florian has joined #yocto
fullstop_ is now known as fullstop
<Bhstalel>
I always teach Yocto with real cooking examples do_fetch=shopping, ..., and one time someone got do_compile issue, so I told him "did you clean your fruits?" I meant did you do do_patch and he got the idea hhh
amitk_ has joined #yocto
perfinion has joined #yocto
olani has quit [Ping timeout: 248 seconds]
tunahan has quit [Quit: tunahan]
<Entei[m]>
Heys guys I keep getting this error saying `Error when bootstrapping CMake: Cannot find a compiler that supports C++11 and the specified C++ flags`.
<Entei[m]>
I am using the exact same release as before (when the build worked without issues), just on Fedora 38 this time around (earlier was Fedora 37). I unfortunately don't have Fedora 37 work machines with me right now to test, but don't see why it would be a distro issue tbh.
tunahan has joined #yocto
<rburton>
what recipe?
<rburton>
i'm guessing cmake-native, so it needs a host compiler to build
<Entei[m]>
rburton: yeah cmake-native. Sorry forgot to mention
dShapo has joined #yocto
dShapo has quit [Client Quit]
<Entei[m]>
I have installed every pre-requisite package as mentioned on Yocto Quick build webpage, even tried installing second time, all listed packages are installed
<rburton>
what yocto release?
<rburton>
and sharing the full cmake-native fail log would be useful
<eFfeM>
qschulz: thanks, guess it is in the inherits cmake; moving it to the bottom did not help, now I just added
<eFfeM>
FILES_${PN}-dev = ""
<eFfeM>
because I do not have adev package anyway
<qschulz>
eFfeM: yeah ok
xmn has joined #yocto
<qschulz>
so the issue is that the default PACKAGES has the dev package handled before the ${PN}
<qschulz>
and the PACKAGES variable is read left from right
<qschulz>
any file matching a FILES_<pkg> in the order of appearence in PACKAGES will be only put in the first match
<qschulz>
so it goes into your dev package because of that
<eFfeM>
yeah I knew abou the first match, but apparently the inherit generated that
<eFfeM>
couldn't really find in temp how things are generated
<eFfeM>
and ofc it is friday afternoon, often not the time of the week I'm shapest
amitk_ has quit [Ping timeout: 256 seconds]
<rburton>
Entei[m]: the test code is segfaulting, which is fun. we don't have fedora38 workers in the cluster yet so i'd try asking upstream cmake about it. if you want to dig further, try building cmake from scratch outside of yocto.
<rburton>
eFfeM: is that library explicitly not versioned? shared libraries should be versioned.
kscherer has joined #yocto
<eFfeM>
rburton: no idea, there is no versioned so file. I just knocked up a recipe because a co-worker wanted to use this for debugging. I'm not familiar with the code
<qschulz>
eFfeM: PACKAGES is set by bitbake.conf by default
<smurray>
RP: I've been delayed on the Rust mixin layer by needing to do some firefighting on some breakage in AGL, will get to it next week
<khem>
lucaceresoli_: I see you did not pick the cpio ptest patch is there some issue with it that I should know ?
<khem>
ah rust mixin, I thought meta-rust is in that role alreay
otavio has quit [Ping timeout: 265 seconds]
amitk_ has quit [Ping timeout: 248 seconds]
sakoman has quit [Ping timeout: 250 seconds]
Thorn has joined #yocto
florian_kc has joined #yocto
car1t has joined #yocto
ptsneves has joined #yocto
mvlad has quit [Remote host closed the connection]
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
amitk_ has joined #yocto
car1t has quit [Quit: leaving]
alessioigor has quit [Quit: alessioigor]
BWhitten has quit [Ping timeout: 276 seconds]
<smurray>
khem: I need something specifically to upgrade the Rust in kirkstone, and based on the recent dev call discussions, I'm not alone. wrt meta-rust, tbh, I'd understood it to be somewhat redundant now that oe-core had the toolchain merged in
Minvera has quit [Remote host closed the connection]
amitk__ has joined #yocto
amitk has quit [Ping timeout: 265 seconds]
amitk_ has quit [Ping timeout: 276 seconds]
amitk has joined #yocto
kroon has joined #yocto
kroon has quit [Client Quit]
kroon has joined #yocto
kroon has quit [Read error: Connection reset by peer]