jsbronder has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
jsbronder has joined #yocto
xmn has quit [Quit: ZZZzzz…]
BCMM has quit [Remote host closed the connection]
tp43_ has quit [Ping timeout: 258 seconds]
dlan has quit [Quit: leaving]
dlan has joined #yocto
tp43_ has joined #yocto
dlan has quit [Quit: leaving]
dlan has joined #yocto
dlan has quit [Client Quit]
dlan has joined #yocto
sakoman has quit [Quit: Leaving.]
sakoman has joined #yocto
camus has quit [Ping timeout: 248 seconds]
camus has joined #yocto
paulg has quit [Ping timeout: 248 seconds]
rpcme has quit [Quit: Ping timeout (120 seconds)]
sakoman has quit [Quit: Leaving.]
amitk has joined #yocto
davidinux has joined #yocto
<mihai>
yo
rob_w has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
Ad0 has quit [Ping timeout: 252 seconds]
Ad0 has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
rob_w has quit [Ping timeout: 252 seconds]
rob_w has joined #yocto
zpfvo has joined #yocto
zyga has joined #yocto
leon-anavi has joined #yocto
d0ku has joined #yocto
dgriego has quit [Ping timeout: 258 seconds]
lexano has quit [Ping timeout: 268 seconds]
dgriego has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
lexano has joined #yocto
dgriego has quit [Ping timeout: 258 seconds]
dgriego has joined #yocto
florian has joined #yocto
<wCPO>
I'm adding a new file to the initramfs with a initramfs-framework_1.0.bbappend creating a new package. How should I install the new package? PACKAGE_INSTALL += "initramfs-module-foo" in local.conf?
<mihai>
wCPO: presuming you are using core-image-minimal-initramfs, you could install it with INITRAMFS_SCRIPTS:append = " initramfs-module-foo"
<wCPO>
mihai: we have our own image with "require recipes-extended/images/kvm-image-minimal.bb", kvm-image-minimal inherit core-image.
<mihai>
wCPO: ok, that's fine :) I meant using core-image-minimal-initramfs as initramfs / initrd
xmn has joined #yocto
mcon has joined #yocto
Frozen-compiler has joined #yocto
<Frozen-compiler>
Hey
<Frozen-compiler>
Am looking at this variable IMAGE_BOOT_FILES
<Frozen-compiler>
I can understand the kernel or grub being placed in a boot partition. But why would you want to put u-boot there ever?
<Frozen-compiler>
I guess there could be some special cases where u-boot is used even further in the bootlader chain (SPL -> somehting which can read the boot partition -> u-boot).
<Frozen-compiler>
But I haven't seen any cases for that.
<qschulz>
Frozen-compiler: BeagleBone boards booting from SD card do use the boot partition to get the SPL and U-Boot binaries AFAIR
<qschulz>
and in any case, it's just an example to show what you can do :)
<qschulz>
also, please use docs.yoctoproject.org now :)
<Frozen-compiler>
Oh, really. Thanks. I guess that means their bootloader in ROM can already read partition data as well as file systems.
<Frozen-compiler>
O, didn't know about docs.yoctoproject.org, thanks! Will do
goliath has joined #yocto
mranosta1 has joined #yocto
lucaceresoli has joined #yocto
<lucaceresoli>
hi, I have a vendor layer adding more MACHINEOVERRIDES than I would like:
<lucaceresoli>
I want to remove the 'mali400:' prefix in my own machine conf, how can I do it?
<lucaceresoli>
anything like MACHINEOVERRIDES_remove than works with colon-separated lists?
<lukma>
Dear Community:
<lukma>
When creating foo-dbg package (with included .debug stuff)
<lukma>
I do encounter following error: "RecursionError: maximum recursion depth exceeded in comparison "
<lukma>
I do guess that the created directories and files consume so much resources that python on the build machine returns this error
<lukma>
hence, the question - is it possible to increase the stacksize from the Yocto/OE? (via e.g. local.conf)
<lukma>
Or I need to fiddle with 'ulimit' in the shell which runs bitbake builds ?
<mihai>
lucaceresoli: have you tried it with _remove, actually :remove ?
<lukma>
To be more precise - "Failure expanding variable SUMMARY:glibc-tests-dbg, expression was ${SUMMARY} - Debugging files which triggered exception RecursionError: maximum recursion depth exceeded in comparison"
<lukma>
When I have only PACKAGES = "${PN}" - without the '-dbg' one everything works correctly
<lukma>
even better :-) -> SUMMARY:${PN}-gdb·=·"foo" fixes the issue ....
<lucaceresoli>
mihai, yes, but :remove does not seem to work:
<lucaceresoli>
ERROR: ParseError at [...]: unparsed line: 'MACHINEOVERRIDES:remove = "mali400:"'
<qschulz>
if python anonymous function work in configuration file, you could try to d.setVar(MACHINEOVERRIDES) in there
<qschulz>
lucaceresoli: otherwise, next step is just to define your own machine configuration file that is loosely based on the one from your vendor
<qschulz>
usually MACHINEOVERRIDES is modified via =. operator (or .= ?)
<qschulz>
in which case you could redefine the whole MACHINEOVERRIDES
<qschulz>
but I wouldn't surprised if :remove only works on space-separated lists to be sure to have an exact match and not a substring
<bantu>
Hello everyone. What is the expected process for adding the packages of MACHINE_EXTRA_RRECOMMENDS to my image?
<lucaceresoli>
qschulz, anonymous python sounded interesting, but unfortunately does not work:
<lucaceresoli>
Note: the original string was: "mali400:vcu:zynqmpev:zynqmp:cortexa72-cortexa53:aarch64:armv8a:sc3c"
<lucaceresoli>
Instead or removing "mali400:" it added a "vcu:" in the middle
<qschulz>
lucaceresoli: where did you add this MACHINEOVERRIDES in the conf file?
<qschulz>
before/after the include/require?
<lucaceresoli>
as if the line in the bsp layed doing 'MACHINEOVERRIDES_prepend_zynqmpev = "mali400:vcu:"' were executed twice, with my python line in between the two
<lucaceresoli>
I added the magic line at the very end of my machine conf file, way after the includes
<qschulz>
if you pipe to | awk '/^# \$FOOBAR \[/,/^FOOBAR/'
<qschulz>
you should have the history of MACHINEOVERRIDES and understand where the second vcu is coming from
<qschulz>
but in any case, not working :/
<lucaceresoli>
qschulz: stupid me, I haven't done it yet!
<qschulz>
you could do the same trick with OVERRIDES though
<qschulz>
maybe that'd work? But bad vendor layer, bad :p
amitk_ has joined #yocto
<qschulz>
it makes VERY little sense to use machine overrides as overrides for MACHINEOVERRIDES :)
<lucaceresoli>
qschulz: I've been looking into the history of MACHINEOVERRIDES and it looks fine... I'm more and more puzzled
<lucaceresoli>
qschulz: gaah, my current best plan is to not include that .inc file anymore and just copy the lines I need in my own
amitk has quit [Ping timeout: 250 seconds]
<lucaceresoli>
qschulz: but thanks for the support!
<qschulz>
lucaceresoli: that is a good plan
<qschulz>
we usually recommend ditching whatever you receive from the vendor and only import (maybe even rewrite) the recipes/conf files you really need
<lucaceresoli>
qschulz: very wise recommendation! For some reason I always try to keep my layer minimal and reuse the base layers as far as possible, but it's not always a good idea, practically speaking.
<abelloni>
well, what is coming from the silicon vendor usually makes sense, what is coming from SoM vendors, I would definitively trash
<RP>
rburton: we have a weird issue with buildtools that your test is highlighting. Basically the pseudo-native built on a system using new buildtools doesn't work to run native binaries
<RP>
relocation error: /home/pokybuild/yocto-worker/buildtools/build/./build/tmp/work/x86_64-nativesdk-pokysdk-linux/buildtools-extended-tarball/1.0-r0/testimage-sdk/bitbake-build-mklpu__g/tmp/sysroots-components/x86_64/pseudo-native/usr/lib/pseudo/lib64/libpseudo.so: symbol dlerror, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
<RP>
which is because it should look in libdl afaict
abelloni has quit [Quit: leaving]
<RP>
rburton: I think it was your staticdev packaging which breaks it. I can fix that but I've realised that any distro with glibc 2.34 by default will break pseudo :(
<wCPO>
mihai: I'm still trying to grasp yocto :) Adding INITRAMFS_SCRIPTS:append = " initramfs-module-non-existing" to our image doesn't seem to change anything. PACKAGE_INSTALL += "initramfs-module-ramrootfs" neither, hmm
<rburton>
RP: huh
<qschulz>
bantu: if you inherit core-image in your image recipe and do NOT have NO_RECOMMENDATIONS set or redefine CORE_IMAGE_BASE_INSTALL, you should have nothing to do
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
<RP>
rburton: well, I can't make it work at all, it isn't your patch, its deeper :(
<rburton>
oh great and our CI just broke with the pkgconfig thing jama had
<RP>
I don't know how to fix pseudo with glibc 2.34, I don't have the linker knowledge :(
<bantu>
qschulz: I am using core-image-minimal (which inherits core-image) and don't have any of the other options. I see the packages being built but not included in the image.
<cocoJoe>
core-image set IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}
<cocoJoe>
but core-image-minimal redefine IMAGE_INSTALL
<cocoJoe>
to only include packagegroup-core-boot
<qschulz>
cocoJoe: thanks, missed that one :)
* kanavin
thinks gnulib should jump off a cliff right now
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
<cocoJoe>
qschulz you are welcome :-D I am struggling with it now, I can get my image to stop including packagegroup-base-extended
<rburton>
RP: looks like clone3 is causing a lot of the problems in containers. is that correctly handled by pseudo?
abiliomarques has joined #yocto
<abiliomarques>
hi, I'm trying to compile the basic QEMU image, but I get #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib." while building m4-native
<rburton>
guessing that you're using a pretty old release
<rburton>
what release of yocto are you using
<rburton>
?
<mihai>
wCPO: you need to add that to a .conf file or in a .bbappend to core-image-minimal-initramfs
<abiliomarques>
well, now that you mention it... I blindly googled quick start and followed the instructions that seemed familiar. I wanted to get the environment warm while I had the lunch break... and yeah, says 2.0 on the URL
<rburton>
abiliomarques: switch to the latest release, it will work
abelloni has joined #yocto
<abiliomarques>
is building the jethro branch ... not to use it as an excuse, but on top of the documentation it says "for the latest version of this manual... see (link)" ... but says "associated with this yocto project release"
<rburton>
RP: so i'm doing the same as you, can you share the uninative tarball you're using?
<abiliomarques>
I should read before assuming things, but I guess other open source projects trained me to click the link to get to the latest documentation (as for the project)
<rburton>
(url of)
<RP>
rburton: how do you mean you're doing the same as me?
<rburton>
abiliomarques: you've obviously not been trained enough by google to check the versions. google constantly returns old docs for our docs
<rburton>
RP: what uninative tarball are you using?
<RP>
rburton: the new 3.3 one merged in master
<rburton>
ah ok
<rburton>
ah yes i didn't see that merge :)
<rburton>
well there goes my theory of making the builds fail in nspawn
<wCPO>
mihai: thanks. I had a suspicion it was something like that. The image and initramfs two different things :)
<abiliomarques>
I know what you mean, I normally get there, and then click on the link on top that bring you to the latest version of the document for the project, not for the release (that's what I mean with other projects "trained me", pavlov style) I'm sorry for such a rookie mistake
<mihai>
wCPO: yup :)
<wCPO>
So the file is indeed getting added now. Now I just need to figure why a qemuboot.conf isn't created for the newest iso
<RP>
Does anyone know if you can tell ld to link to a weak symbol?
xmn has quit [Ping timeout: 250 seconds]
xmn has joined #yocto
<wCPO>
"addtask do_write_qemuboot_conf after do_rootfs before do_image" so if I have only modified the initramfs, would it run?
<override_>
I have an emmc partition /dev/mmcblk0p3 and in my yocto deploy dir I have a rootfs image Verdin-iMX8MM-image.rootfs.ext4, I need suggestions for ways of brining over the rootfs image to the said partition. Feel like what im currently doing is long winded, doing extra mounts.. Is there a way of doing this with just bmap, no cp and mount?
rob_w has quit [Remote host closed the connection]
<cocoJoe>
override_ is the /dev/mmcblk0p3 on the same machine as the yocto deploy dir?
<cocoJoe>
I have use IMAGE_FSTYPES += "wic wic.bmap" and then bmaptool copy image.wic /dev/mmcblk0p3
<override_>
cocoJee, /dev/mmc/blk0p3 is on the board, deploy dir in on the build machine..
goliath has quit [Quit: SIGSEGV]
<override_>
im not trying to write the entire disk image (wic image) this /dev/mblkop3 is just a partition I have on the the board which I can use as a root file system partition
<override_>
my hope is Verdin-iMX8MM-image.rootfs.ext4 in yocto dir is just an image for the root filesystem..
<wCPO>
do_write_qemuboot_conf is indeed only called when the the rootfs is modified it seems, not when modifying just the initramfs
<cocoJoe>
override_ ahh okay, I guess you cannot avoid mounting the partition if you want to write to it, but the dd og cat should be able to make a byte wise copy of the rootfs (I think you are right the .ext4 is just the rootfs)
<override_>
cocoJee: can I somehow uses bamp instead of cat or copy, since bmap is supposedly so much better?
<cocoJoe>
override_ you can try bmaptool copy image.ext4 /dev/partition :-D
<override_>
cocoJoe: can bmaptool work on partitions directly, or would the partition need to be mounted first?
<cocoJoe>
override_ ahh that is what you mean.. you should write to the device in /dev/mmc/blk0p3, not mount it..
<override_>
cocoJoe: im just a little confused becuase i feel like you cant copy to a device cp/cat (you have to mount the device first) but I guess you can bmaptool copy the image onto a device
jwillikers has joined #yocto
<override_>
im just a little lost bettween when all mounting is required and if a an image is mounted or copied :/
<cocoJoe>
override_ you can dd to it and cat should work as well, I dont think cp will work tho
<override_>
cocoJoe: dd and cat an image onto a disk directly you mean?
<cocoJoe>
yep
<override_>
cool thanks.
<cocoJoe>
cat image.ext4 /dev/disk/partition
<override_>
I was definitely doing something long winded before..
<cocoJoe>
no wait I am not sure about that cat command
<cocoJoe>
you might have to play around with the bs
<override_>
got it, Ill give bmap tool a try too
<override_>
think we dont have to worry about the bs bs when using bamp
<override_>
bmap*
<override_>
what good is setVarFlags("FOO", {"func": True}) for when I can just FOO[func]=True?????????
<qschulz>
override_: you cannot do FOO[func]=True from within a python function
<override_>
qschulz: ill let that sink in a little..
<override_>
wont I have to send the function a reference to FOO when I use setVarFlags too?
<qschulz>
override_: use setVarFlag first, I feel like it's better to do it one flag after the other instead of using a dict
<qschulz>
override_: "the function" ?
troth has quit [Quit: Leaving.]
<override_>
qschulz: you said I cant call FOO[func] from within a function .. I was trying to figure out why not? call setVarFlags from within a fuction would require passing the function a reference to the object whose flags we're trying to mess around with
<qschulz>
override_: for bitbake python functions, use d
<qschulz>
it's the datastore
<qschulz>
d.getVarFlag to get the value of FOO[func] from within a bitbake python function
<override_>
and each recipe gets its own datastore Im guessing
<override_>
seeing some self.d in the manual
<qschulz>
it's a copy of the global datastore I'd guess
<qschulz>
built from the variables contained in configuration files
<qschulz>
that's why you can't pass a variable from one recipe to another
camus has quit [Quit: camus]
goliath has joined #yocto
<mcon>
I am having problems with GitLab pipelines (not strictly a yocto problem, please redirect as needed). After the build step I get all relevant "artifacts", but I didn't find the right spell to make them available to later stages (deploy and test). can someone help?
Guest81 has quit [Quit: Client closed]
paulg has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
<rburton>
mcon: you need to use the artifacts keyword in build to save them. all artifacts from the build stage will be passed to the test stage, but you can control it with dependencies. https://docs.gitlab.com/ee/ci/yaml/#artifacts
<rburton>
fwiw, we stopped splitting build/test as artifact transfer was a pain
<mcon>
rburton: Thanks, you are always very helpful. Unfortunately I seem to be missing something. Here is my simple .gitlab-ci.yml https://dpaste.org/ib3U and artifacts are indeed produced (I can manually download them from GitLab), but I cannot see them anywhere from later stages.
<mcon>
rburton: I cannot keep build/deploy-test stages together because they will run on different runners (different machines too).
<kranzo[m]>
<mcon> "rburton: Thanks, you are..." <- i think u wanna use the cache
<kranzo[m]>
@mcon for different machines u need shared cache
<mcon>
kranzo[m]: Sorrry I fail to understand what You mean. Can you elaborate, please?
<kranzo[m]>
there is a difference between chache and artifacts on gitlab
<kranzo[m]>
cache
<mcon>
kranzo[m]: I *think* GitLab-CI should do the copying work for me (if I find a way to ask nicely)
<kranzo[m]>
but give me a minute, so that i dont confuse the terms here
<mcon>
kranzo[m]: Thanks.
camus has joined #yocto
Guest39 has joined #yocto
sethfoster has joined #yocto
<sethfoster>
Hey folks, is this the right place to ask questions about some odd build configurations with setting task dependencies in a yocto build
<qschulz>
sethfoster: ask and you shall discover :)
<kranzo[m]>
mcon you are right, the next stages should download the artifacts, but i remember that there were some unintuitive elements if you use container and multiple runnner, do you compile bare metal or in conatiners?
<sethfoster>
languishing on bitbake-devel, but not quite what I need). The main tool is called gclient, which is what I'll say from now on.
<sethfoster>
I have a recipe for gclient-native which works great, but it's a fetcher, so I overrode do_fetch in my custom recipe to use it. This therefore requires gclient to be present in the sysroot in do_fetch, which is of course unusual
<sethfoster>
So I set do_fetch[deptask] = "do_populate_sysroot", but that sets _all_ of DEPENDS as a dependency for do_fetch
<sethfoster>
Is there a way to just add do_populate_sysroot for gclient-native as a dependency to electron do_fetch?
<sethfoster>
This is dunfell.
<sethfoster>
Sorry for the essay, figured context would be useful.
goliath_ has joined #yocto
goliath has quit [Ping timeout: 252 seconds]
<mcon>
kranzo[m]: I'm compiling on bare metal. Also deploy runner is bare metal (currently on the same machine, but that will change soon). As said compilation is completely ok and artifacts *are* uploaded. Problem is I don't see them in later stage :(
<kranzo[m]>
did you actiuually check if the content is correct in the artifacts?
<qschulz>
sethfoster: I think you need to create a new fetcher for that
<qschulz>
with it's own protocol for detection in src_uri
<qschulz>
e.g. crate:// git:// and the like
<sethfoster>
Yeah that's definitely the correct, maintainable way. I was kind of hoping to have a way to just hack around it for now since the goal is actually to answer the question "is this worth it"
<sethfoster>
I want to see how electron behaves when it's doing drm-direct rendering, but the chromium binaries in their official builds don't support it
<sethfoster>
I guess optimization like limiting the dependency set here doesn't really matter just for evaluation
<mcon>
kranzo[m]: Yes. I can confirm artifacts manually downloaded from Gitlab are actually OK (an archive named "artifcacts" containing all relevant files).
<mcon>
IMHO Problem is actually in the preparation of later stages
<kranzo[m]>
mcon: yeah i understood and i remember i had the problem as well but i think my problem was another one ...
<qschulz>
sethfoster: otherwise look into what's in do_populate_sysroot and try to check if there's a way to bypass DEPENDS for that one
<qschulz>
mmmmmmmmm
<sethfoster>
qschulz: oh that's a lot simpler than I had been assuming. i guess fetchers are basically free to rely on the build host having it setup?
<sethfoster>
having it setup = having the tool used for the fetch setup, sorry
<qschulz>
what about: DEPENDS_task-fetch = "gclient-native" in addition to do_fetch[deptask] = "do_populate_sysroot" ?
<qschulz>
for hacking around
<qschulz>
this overrides DEPENDS for the fetch task to be gclient-native only
<sethfoster>
ooh I think that's exactly what I would want
goliath_ has quit [Quit: SIGSEGV]
<sethfoster>
Although I think that your linked example actually solves my x/y problem - I had been assuming that the only way to add a fetcher would be to make a local fork of bitbake and try and get it upstreamed, but of course I can just add to BBPATH in the layer
<wCPO>
Is it possible to use addtask with only before?
<sethfoster>
I'll try both. Thank you qschulz!
<barath>
does anyone know whether uninative is enabled by default? the manual says that poky includes it by `require conf/distro/include/yocto-uninative.inc` but grepping through poky, I can't find anything that uses it or a file by that name
<barath>
is the documentation outdated and it's enabled by default in some other way?
<kranzo[m]>
have a look at the last to pipelines.. in this way the pipeline failes without the untracked flag
<qschulz>
sethfoster: good luck :)
sakoman has joined #yocto
<qschulz>
barath: what's the url of the doc you're reading?
<qschulz>
but yes, uninative should be enabled by default
<qschulz>
it was on thud, the only release I really worked with
<qschulz>
it was enabled with uninative in INHERIT
<qschulz>
I think it was enabled back in krogoth or jethro already (since my previous company disabled it because it broke icecc in those older versions)
<barath>
"In the Poky reference distribution this is enabled by default through meta/conf/distro/include/yocto-uninative.inc. Other distributions that do not derive from poky can also "require conf/distro/include/yocto-uninative.inc" "
<qschulz>
barath: docs.yoctoproject.org is the up-to-date version but the one you're looking at is not too old either (stopped at dunfell)
<qschulz>
seems like the docs need an update for that one since yocto-uninative isn't explicitly included anywhere... to what it should be replaced with.. i don't know
<barath>
strange wrt ripgrep ignoring it then
<barath>
possibly due to our poky being a submodule itself, in our yocto dir/project
<qschulz>
didn't find anything in poky git repo
<kranzo[m]>
> <@barath:matrix.org> strange wrt ripgrep ignoring it then
<kranzo[m]>
by default rg is ignoring everything metioned in any vcs ignore files
<kranzo[m]>
> possibly due to our poky being a submodule itself, in our yocto dir/project
tlwoerner has quit [Remote host closed the connection]
<barath>
well poky's .gitignore contains !meta-poky, which should negate the earlier meta-* entry... but it seems that !meta-poky does actually work for ripgrep
<barath>
oh well
<rburton>
yeah, atom also failed to parse the gitignore correctly
Guest86 has joined #yocto
<barath>
*!meta-poky does not actually work for ripgrep
d0ku has quit [Remote host closed the connection]
goliath has joined #yocto
<mcon>
kranzo[m]: If I understand correctly your example this doesn't really mimic my case. Of course next stage, running exactly in the same place as the previous one will find "leftovers". problem happens when you either run on separate machines or you use "manual" stages to decouple build and deploy (possibly with cleanout in the middle).
<RP>
I'm out of ideas on how to fix this at this point :(
<kranzo[m]>
mcon: it is up uand downloading so should work on different machines
<rburton>
mcon: are you remembering that everything will be in artifacts/ in the test job?
<kranzo[m]>
mcon: could you post the log of your jobs? would help to debug
<rburton>
replacing your scripts with "echo THIS IS A BUILD IMAGE >tmp/deploy/etc" in build and then checking the files exist in test would be a first step to make sure the jobs are doing what you expect
<mcon>
rburton: Sorry I don't understand what you mean. My problem is "Downloading artifacts" step is completely absent from my deploy logs (see: https://dpaste.org/QDoR)
<rburton>
mcon: fwiw our test jobs had needs: job: build-foo in to get the right artifacts in the right job
Guest86 has quit [Quit: Client closed]
<barath>
does anyone know if there's a quick way to check whether my build/image is using the uninative tar ball? I see it downloaded, but...
bps has quit [Ping timeout: 268 seconds]
<rburton>
NATIVELSBSTRING in the build configuration will say 'universal' instead of eg ubuntu-20.04
<prabhakarlad>
Hi all, I am wondering why timeout utility is not included as part of coreutils, there is a comment stating "gets a special treatment and is not included in this", can i get around and install timeout utility?
awafaa has quit [Read error: Connection reset by peer]
YogeshSiraswar_ has quit [Read error: Connection reset by peer]
dagmcr has quit [Read error: Connection reset by peer]
armpit has quit [Read error: Connection reset by peer]
CosmicPenguin has quit [Read error: Connection reset by peer]
NishanthMenon_ has quit [Read error: Connection reset by peer]
behanw has quit [Read error: Connection reset by peer]
<rburton>
prabhakarlad: its part of coreutils...
lucaceresoli has quit [Quit: Leaving]
<prabhakarlad>
coreutils is included as part of my image (core-image-minimal), but the timeout utility seems to be missing.
NishanthMenon_ has joined #yocto
CosmicPenguin has joined #yocto
behanw has joined #yocto
dagmcr has joined #yocto
YogeshSiraswar_ has joined #yocto
armpit has joined #yocto
awafaa has joined #yocto
<rburton>
here its at /usr/bin/timeout.coreutils, with a symlink
<rburton>
ah, the symlink might be missing?
<rburton>
no, should be there
<prabhakarlad>
ls /usr/bin/timeout.coreutils
<prabhakarlad>
ls: /usr/bin/timeout.coreutils: No such file or directory
<rburton>
are you sure you actually have coreutils installed
<prabhakarlad>
Yes pretty sure doing a bitbake -c cleansstate coreutils and then later bitbake core-image-minimal does actually build coreutils.
<qschulz>
you can have something built but not installed in an image
<rburton>
the easiest way is to just look at the image manifest (next to the image), or the package manager on the target
xmn has quit [Quit: ZZZzzz…]
<rburton>
JPEW: we might want to consider putting 'extended' pkgdata in a different directory tree, as stuff like oe-pkgdata-util iterates over every file (and aborts when it tries to parse a json.zstd)
Frozen-compiler has quit [Quit: Client closed]
<JPEW>
rburton: Ah, I didn't realize that
<rburton>
just discovered the hard way :)
<JPEW>
Would `${PKGDATA_DIR}/extended` be OK?
<rburton>
yeah
<JPEW>
K
<prabhakarlad>
right looking at the it just has the below utils:
<rburton>
you might not have sigssuspend for some reason?
<rburton>
check the configure log
goliath has quit [Quit: SIGSEGV]
<prabhakarlad>
rburton: good point let me check the configure log.
dev1990 has joined #yocto
florian has quit [Quit: Ex-Chat]
<RP>
vmeson: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /media/build1/poky/build/tmp/work/x86_64-linux/rust-native/1.54.0-r0/rustc-1.54.0-src/build/bootstrap/debug/deps/libproc_macro_error_attr-9c7a09885c50c72e.so)
<RP>
vmeson: I think this may struggle in cases where uninative and the host libc version differ
<vmeson>
RP fun!
<barath>
rburton: ty
<RP>
vmeson: glibc 2.34 and pseudo break with uninative and I have no idea how to fix it
<RP>
vmeson: I'm therefore a little frustrated with these kinds of errors atm
zpfvo has quit [Remote host closed the connection]
<kranzo[m]>
what is the merge cycle for master-next into master in poky?
<kranzo[m]>
or better oe-core
<kranzo[m]>
and how can i request a backport to hardknott? :D
<smurray>
kranzo[m]: that first one's a RP question. For the second, you'd send a request for a backport to the oe-core list after it's gotten into master
vmeson has quit [Quit: Konversation terminated!]
vmeson has joined #yocto
<RP>
kranzo[m]: which patch are we talking about? Some merge quickly, some need more testing
<RP>
kranzo[m]: speed depends on how many build failures we get in testing too
<kranzo[m]>
my patch from yesterday got merged into master (Allow global override of golang GO_DYNLINK), i was just thinking about the timescales to expect :)
<kranzo[m]>
so am i right, patches get applied to master-next, pipelines run (how often?), if success merge into master?
nerdboy_p is now known as nerdboy
nerdboy has quit [Changing host]
nerdboy has joined #yocto
BCMM has quit [Ping timeout: 268 seconds]
florian has joined #yocto
bps has joined #yocto
bps has joined #yocto
<RP>
kranzo[m]: that is the correct flow, yes. The tests are batched and run manually and take hours
bps has quit [Ping timeout: 248 seconds]
tlwoerner has joined #yocto
florian has quit [Ping timeout: 252 seconds]
tp43_ has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
bps has joined #yocto
bps has quit [Changing host]
bps has joined #yocto
bps has quit [Ping timeout: 248 seconds]
mranostaj has quit [Remote host closed the connection]
mranosta1 is now known as mranostaj
bps has joined #yocto
<tlwoerner>
fray: Error, the PACKAGE_ARCHS variable (all any noarch ${PACKAGE_EXTRA_ARCHS:tune-mips32r2el-24kc} qemumips) for DEFAULTTUNE (mips32r2el-24kc) does not contain TUNE_PKGARCH (${MIPSPKGSFX_VARIANT:tune-mips32r2el-24kc}-nf)
<tlwoerner>
DEFAULTTUNE = "mips32r2el" works but DEFAULTTUNE = "mips32r2el-24kc" doesn't
<khem>
So I wonder if it is yet another pain to migrate coming our way hoping to have it in next LTS
<vmeson>
khem: yes, I tried to upgrade to 3.0-alpha-X months ago and there were some problems. I'm trying to arrange for Yi Zhao to have time to work on it for that we're ready to merge early in the next release.
leon-anavi has quit [Quit: Leaving]
abiliomarques has quit [Remote host closed the connection]
jwessel` has joined #yocto
jwessel` has left #yocto [#yocto]
jwessel has joined #yocto
jwessel has quit [Quit: Coyote finally caught me]
jwessel has joined #yocto
Guest39 has quit [Quit: Client closed]
tgamblin has quit [Ping timeout: 240 seconds]
tgamblin has joined #yocto
sethfoster has quit [Quit: Lost terminal]
darknighte has joined #yocto
xmn has quit [Quit: ZZZzzz…]
dev1990 has quit [Quit: Konversation terminated!]
dvorkindmitry has joined #yocto
<dvorkindmitry>
how to enable gcc-plugins for gcc-cross?