yocti has quit [Killed (NickServ (GHOST command used by yocti`))]
zeddiii has joined #yocto
yocti` is now known as yocti
Amynka_ has joined #yocto
Ch^W_ has joined #yocto
tct has joined #yocto
targetdi1k has joined #yocto
sotaover3ide has joined #yocto
prabhakarlad has joined #yocto
tokamak has quit [*.net *.split]
sotaover1ide has quit [*.net *.split]
silbe has quit [*.net *.split]
zeddii has quit [*.net *.split]
tin_ has quit [*.net *.split]
Amynka has quit [*.net *.split]
Crofton has quit [*.net *.split]
targetdisk has quit [*.net *.split]
praneeth_ has quit [*.net *.split]
halstead has quit [*.net *.split]
flynn378 has quit [*.net *.split]
Ch^W has quit [*.net *.split]
stacktrust_ has quit [*.net *.split]
jbo has quit [*.net *.split]
smurray has quit [*.net *.split]
olof has quit [*.net *.split]
MrFrank has quit [*.net *.split]
stacktrust_ has joined #yocto
smurray has joined #yocto
MrFrank has joined #yocto
praneeth_ has joined #yocto
tin_ has joined #yocto
olof has joined #yocto
tokamak has joined #yocto
goliath has joined #yocto
halstead has joined #yocto
flynn378 has joined #yocto
Crofton has joined #yocto
<LetoThe2nd>
yo dudX
frieder has joined #yocto
alessioigor has joined #yocto
zpfvo has joined #yocto
Kubu_work has joined #yocto
rfuentess has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
florian has joined #yocto
pabigot has quit [Ping timeout: 246 seconds]
pabigot has joined #yocto
florian_kc has joined #yocto
Guest23 has joined #yocto
leon-anavi has joined #yocto
davidinux has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
davidinux has joined #yocto
AndreRicardo has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
davidinux has quit [Ping timeout: 240 seconds]
silbe has joined #yocto
davidinux has joined #yocto
davidinux1 has joined #yocto
davidinux has quit [Ping timeout: 246 seconds]
Guest23 has quit [Quit: Client closed]
Guest23 has joined #yocto
<Guest23>
Is it already known whether Poky 4.3 will support building on Fedora 38?
el_gatito has joined #yocto
astlep55040 has joined #yocto
astlep5504 has quit [Ping timeout: 246 seconds]
davidinux1 has quit [Ping timeout: 260 seconds]
<LetoThe2nd>
Guest23: you have think about it in a slightly different way. poky will definitely receive patches to build on newer glibcs, probably relatively soon. so in the beginning, it will build on F38, expectedly. and once they do the next glibc update, it will probably break again. this is a peculiarity of fedora, and anything that is a rolling release.
d-s-e has joined #yocto
davidinux1 has joined #yocto
d-s-e has quit [Ping timeout: 256 seconds]
mvlad has joined #yocto
davidinux1 has quit [Ping timeout: 256 seconds]
<adrianf>
Guest23: For me Fedora 38 works without problems since uninative was updated (kirkstone, master). The question is probably when it will be added to SANITY_TESTED_DISTROS.
mihai has quit [Quit: Leaving]
<Guest23>
Yeah for mickledore it also works though there was some recipe in meta-intel which I cannot remember currently which did not work with the newer glibc version
<Guest23>
Oh it was not even meta-intel, it was OVMF. Which I had to patch to use uninative 4.0
d-s-e has joined #yocto
<RP>
adrianf: we usually do that once we have some builds confirming things work..
<RP>
I wish we did better at the process but it does involve multiple people and steps
pabigot has quit [Ping timeout: 245 seconds]
<qschulz>
I tried to build 4.0.11 which I assume has the new uninative but it didn't build on fedora38, so I guess I did something wrong? (it failed in dnf-native at least)
<rburton>
zeddiii: am i right in thinking meta-virt and oe-core disagree about python-dtc? our builds are failing as lopper can't find python3-dtc-native
zelgomer has quit [Ping timeout: 240 seconds]
d-s-e has joined #yocto
otavio_ has quit [Remote host closed the connection]
otavio_ has joined #yocto
g0hl1n has quit [Ping timeout: 245 seconds]
g0hl1n has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Tyaku_ has joined #yocto
<smooge>
/C/C
<smooge>
woops sorry
Tyaku_ has quit [Quit: Lost terminal]
xmn has joined #yocto
<zeddiii>
rburton: I've been away, I'm updating and re-testing my meta-virt master-next now, so I'll fix it shortly if so.
valdemaras has joined #yocto
<rburton>
zeddiii: cool
<rburton>
Guest23: the next branches are for staging and testing, and are not _guaranteed_ to be in advance of the real branch
<LetoThe2nd>
zeddiii: can I get your gut feeling on backporting docker-compose to kirkston in a custom layer? or is there some version dependency that causes it to be just mickledore and later?
<zeddiii>
docker-compose is only tricky in that it isn't the python3-docker-compose you want, as it isn't updated anymore, I'm dropping that recipe completely in this release. so it is the docker-compose_git.bb
<zeddiii>
which is a non-vendored git repo, so it has the big SRC_URI to fetch all the bits, I'm not 100% sure if some of those could have go version entanglements with older releases.
<LetoThe2nd>
zeddiii: so building docker-compose_git.bb on kirkstone should be somewhat feasible?
<zeddiii>
it should be yes. just go itself is the question mark for me.
<LetoThe2nd>
kay. will give it a spin then.
AndreRicardo has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<d-s-e>
is it possible to set bitbake dependencies dynamically? Something like mutiple do_sometask[depends] += "${FOO}:do_deploy" inside a do_configure task, with FOO coming from a list of names?
<rburton>
sure, as long as it evaluates to the right thing and the right point in time
<vvn>
d-s-e: you can do it in an anonymous python
<rburton>
ie this is in the wic class: do_image_wic[depends] += "${@' '.join('%s-native:do_populate_sysroot' % r for r in ('parted', 'gptfdisk', 'dosfstools', 'mtools'))}"
<rburton>
or do_populate_sdk[depends] += "${@' '.join([x + ':do_populate_sysroot' for x in d.getVar('SDK_DEPENDS').split()])} ${@d.getVarFlag('do_rootfs', 'depends', False)}"
davidinux1 has quit [Ping timeout: 260 seconds]
<d-s-e>
oh yes, python, sometimes I forget the possibilities ;)
davidinux1 has joined #yocto
Tyaku has joined #yocto
<Tyaku>
Hi, Is it possible to "force" the rebuild of a recipe on every build ? My objective is to store in the image, something like the "build date". As we don't always rebuild the image entirely (because we are in development), we cant use the kernel build time or something like that).
<Tyaku>
My objective would be to get a recipe that store in a file the currenttime when "built". I don't know if it's the best option.
AndreRicardo has joined #yocto
AndreRicardo has quit [Client Quit]
<rburton>
Tyaku: mark the task that does the change with the nostamp flag and it will rerun every time
<rburton>
that will mean you rebuild an image even if there's no changes, because you said you wanted it to run fresh every time
Cristos has joined #yocto
<Cristos>
Hello
AndreRicardo has joined #yocto
<Cristos>
I have a general question regarding Qt5 layer. I need to build it with a particular version of openssl (1.1.1) instead of the default one (3.x). Yet, there is no version of openssl in the qt5 meta layer, just PACKAGECONFIG_OPENSSL and PACKAGECONFIG[openssl] entries. How to write a bbappend to change the openssl version for Qt5?
<Tyaku>
Hum hum, yeah everytime I call bitbake it will rebuild the rootfs/image. Yeah it's not necessary optimum.
<Tyaku>
There is no such thing directly managed by yocto ? during the image creation for example something that set the current date somewhere ?
<rburton>
well only if you ask it for the image
<rburton>
sure you can absolutely drop a file into the image during rootfs time
valdemaras has quit [Quit: valdemaras]
<rburton>
just write the file in a rootfs postprocess hook
<Tyaku>
Is there something "ready to be used" somewhere or do we have to do it "from scratch" (bbappends on the recipe that generate the rootfs/image.)
<Tyaku>
ok
<Tyaku>
Thanks I will search/check how to do it with your terms.
<rburton>
you'll already have /etc/timestamp in your rootfs
<rburton>
_but_ it defaults to a static timestamp for reproducibility, so just unset the right variable
<rburton>
you want to look in rootfs-postcommands.bbclass
g0hl1n has quit [Ping timeout: 245 seconds]
sakoman has joined #yocto
xmn has quit [Quit: ZZZzzz…]
<Tyaku>
Thanks, I'm trying to set 'REPRODUCIBLE_TIMESTAMP_ROOTFS=""' in the local.conf. First observation: It is rebuilding lot of things (linux-imx etc) so it will take a lot of time on each builds.
<Tyaku>
According to this. I think one of the best option, will be to configure REPRODUCIBLE_TIMESTAMP_ROOTFS="XXXXXXXXXXX" when we have to build a "release"
<jonmason>
hopefully this can get either accepted or the can fix it more properly, then we can cherry-pick it back to 6.4
<RP>
jonmason: thanks. has this been discussed with zeddii?
tct is now known as jbo
<jonmason>
I asked him about the requirements to get a patch added to linux-yocto, and he said "I rule with an iron fist". Ok, he didn't say that, but it was implied ;-)
<jonmason>
personally, I'd prefer for it to be accepted upstream, and then we can wait for it to get pulled back into the LTS
<jonmason>
but, as you can see, it's fairly tame
<zeddii>
heh. I'm ok to take the patch whenever. jonmason, feel free to lob it at linux-yocto whenever and I'll put it on the branches. I just finished another round of -stable
<RP>
jonmason, zeddii: given this is the last blocker to getting 6.4 by default, I think we can't wait for upstream...
<jonmason>
RP: was the systemd thing resolved?
<RP>
jonmason: I have a patch which I believe might
<jonmason>
ok, I'll send to the relevant mailing list
* RP
is tempted to ask "which systemd thing"
<RP>
we have about 5 :/
<jonmason>
kernel + systemd + networking
<RP>
jonmason: I have a patch for the 6.4 systemd blocker
<jonmason>
I was going to bisect it, if no one else got to it. as i _think_ I've fixed the edk2 update issues
<RP>
jonmason: we don't need to, we kind of know what happened
<RP>
(network device renaming was added to the kernel somewhere in 6.2 and systemd triggers off it)
<jonmason>
I hate systemd
<RP>
jonmason: the thing everyone wants as default? :)
rber|res has quit [Remote host closed the connection]
belgianguy has joined #yocto
vladest has quit [Ping timeout: 246 seconds]
<belgianguy>
Hi all, I've stumbled on a board (Myon I, by Keith and Koep) which I wanted to install Linux on. However I can't find meta info for use in Yocto, it has some similarities to DragonBoard410c, would that be a good starting point?
<belgianguy>
(I am very new to all this embedded Linux stuff)
<LetoThe2nd>
belgianguy: technically i would say "start with meta-qcom and beat it until it works" :)
<belgianguy>
Hi @LetoThe2nd, thanks, I had indeed already stumbled on meta-qcom (there are 2 different repos though)
<belgianguy>
Are there any examples that use meta-qcom which detail beatings administered? :)
<LetoThe2nd>
belgianguy: qcom stuff is not the easiest, unfortunately.i might have somebody who can help you there, but not sure if they are around on IRC
<belgianguy>
I did install Yocto and did its initial "first image tutorial", but now am kinda lost as in what to look into to get the hang of it
<belgianguy>
As first and foremost I don't want the blue magic smoke to escape from my board :) so I want to check everything that I don't accidentally make a short-lived toaster
<LetoThe2nd>
belgianguy: "did install yocto" sounds kinda wrong in itself already, sorry. did you follow a specific tutorial? or do you mean you did a first build as outlined on docs.yoctoproject.org?
<belgianguy>
Yes, the first build as outlined on the project page
<LetoThe2nd>
belgianguy: okay. just to sort out the wording then - you did a first build based on the YP technology for a qemu based platform. this did not install anything anywhere.
<belgianguy>
LetoThe2nd, ah, thanks, then I will pursue those topics now, and try and see if I can make a jump to the qcom stuff at the end :)
<belgianguy>
or find some other pathways that I need to traverse before attempting that :)
<LetoThe2nd>
belgianguy: have fun! to be honest, I'd try to get a proper understanding of layers, recipes, machines and distros before actually going for qcom stuff - mostly because handling it properly will require said understanding.
<belgianguy>
LetoThe2nd, added them to the list, the better prepared I am the better the result will be, thanks!
<LetoThe2nd>
np. off for tonight, then.
<belgianguy>
@LetoThe2nd, thanks and good night!
<halstead>
RP: I've sent one very borked patch and a corrected patch directly to you for RC testing.
zwelch_ has quit [Ping timeout: 245 seconds]
<RP>
halstead: thanks, I think it might be better if abelloni pulls this in to one of this builds rather than me adding to the mix on the autobuilder!
<RP>
halstead: I've put the patch in master-next so abelloni can find it
<halstead>
RP, hopefully you changed the comment ;)
<halstead>
Or... I suppose it's fine in master-next. We can change it before it goes into master.
zwelch has joined #yocto
<RP>
halstead: I was meaning to remind myself to check! The versions didn't change, this one is for new patchelf patches
Guest67 has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
<RP>
halstead, abelloni: I've started a build with uninative in
<RP>
dl9pf, smurray, denix: There is a uninative test patch in master-next FWIW
Kubu_work has quit [Quit: Leaving.]
florian has quit [Ping timeout: 256 seconds]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
olani- has quit [Remote host closed the connection]