<coldspark29[m]>
I am pretty new to Yocto and am hoping that I can find some initial assistance here
<JosefHolzmayr[m]>
if i had to guess then i'd say that this is a bug in the recipe.
<coldspark29[m]>
Yeah and unfortunately NXP doesn't provide support for Chromium
<JosefHolzmayr[m]>
(because, this is what the message actually suggests - and sorry, building the combination of browser + graphics stack + acceleration is not exactly a beginner level problem)
<coldspark29[m]>
Hmm the weird thing is that it builds fine for the i.MX8, but this is the i.MX6
gsalazar has joined #yocto
<JosefHolzmayr[m]>
then you'll have to dig into the machine configurarations, and find out what the one machine sets/enables that the other doesn't. if i had to guess again, then the libdrm provider is filtering on compatible machines. or something similar.
<coldspark29[m]>
Okay thanks will have a look at them
rfuentess has joined #yocto
goliath has quit [Quit: SIGSEGV]
Belsirk has joined #yocto
rfuentess has quit [Ping timeout: 240 seconds]
fray has quit [Ping timeout: 268 seconds]
prabhakarlad has joined #yocto
fbre has joined #yocto
Tyaku has joined #yocto
fray has joined #yocto
Tyaku has quit [Client Quit]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
kayterina has joined #yocto
Tyaku has joined #yocto
<coldspark29[m]>
How to you actually run ``bitbake-layers`` etc? Is it discouraged to put the binaries in ``/usr/bin``, because I find it a bit tedious to always specify the whole path ``poky/bitbake/bitbake-layers`` to inspect the layers
<qschulz>
coldspark29[m]: if you source the poky oe-init-buildenv sdcript, it's part of your PATH and you can call it directly
Tyaku has quit [Quit: Lost terminal]
<coldspark29[m]>
qschulz: But just as long as I keep that shell window open I assume?
<coldspark29[m]>
Ah I might have moved that poky foldet
<qschulz>
coldspark29[m]: yes, the source applies only to the current shell
<coldspark29[m]>
Yeah but it doesn't work. Maybe because I use zsh
<qschulz>
i use zsh
<qschulz>
so maybe you can tell us what you're doing and what's the error you're seeing?
florian has joined #yocto
<coldspark29[m]>
I just called ``oe-init-build-env`` and it doesn't find bitbake
<qschulz>
because you're supposed to source the script not call it
<coldspark29[m]>
Ah right
Tyaku has joined #yocto
Tyaku has quit [Client Quit]
Tyaku has joined #yocto
<coldspark29[m]>
Now it finds it. If I do this in an already set up build environment, will it overwrite the buld folder?
<coldspark29[m]>
I also use custom buidl folder names
<qschulz>
pass your BUILDDIR directory as an argument to oe-init-build-env and it'll set it up correctly
<qschulz>
it'll not overwrite whatever you already have
<coldspark29[m]>
Okay, so I have to source the file every time I open a new shell. Thanks
<qschulz>
yes
<qschulz>
well, if you want to build from that shell
<qschulz>
or use bitbake tools
<coldspark29[m]>
Yep
<coldspark29[m]>
But why not install bitbake globally?
<coldspark29[m]>
There must be a good reason
<qschulz>
because bitbake version is fixed for a given release of openembedded-core and other layers
<qschulz>
so if you have multiple builds each from different yocto/oe-core versions, you effectively have different bitbake too
<coldspark29[m]>
Thought so
<qschulz>
also... you could run a bitbake from multiple different projects (different repos and layers) at the same time, which is not possible from the same bitbake
<qschulz>
because it's setting up a lock to avoid concurrent use of bitbake for the same project
Tyaku has quit [Quit: Lost terminal]
<coldspark29[m]>
Yeah Yocto can get messy. I see that
Guest69 has joined #yocto
<qschulz>
bitbake is not allowing concurrent use of itself specifically so that Yocto cannot get messy ;)
Tyaku has joined #yocto
BCMM has joined #yocto
<RP>
JaMa: there is a patch in master-next which attempts to fix the task accounting for the UI. Not well tested yet but testing welcome
<RP>
rburton: ^^^
<fbre>
Hi, if I have a .wic file in my RAM disk, how can I write it to partition? Can I use the tool dd to write the image? 7zip sees two files in the .wic file, 0.fat and 1.img
<fbre>
(As I have a running yocto, I want to overwrite the boot and root partition with a newer yocto build)
<fbre>
... I mean a running yocto should overwrite its own boot and root partition
pabigot has quit [Ping timeout: 245 seconds]
jmiehe has joined #yocto
pabigot has joined #yocto
<JosefHolzmayr[m]>
are there prebuilt (e)sdks for poky releases somewhere?
<fbre>
Seems, dd if=/tmp/1.img of=/dev/mmcblk1p2 bs=512 count=698982 could do the job but I'm not sure
<JosefHolzmayr[m]>
fbre: leave out the count and just dd, usually. but in most cases you don't want to target the partition, rather go for the whole nand device.
<JosefHolzmayr[m]>
yet, this is something that the documentation for your hw should cover.
<fbre>
JosefHolzmayr[m] thanx!
eduardas has joined #yocto
<fbre>
JosefHolzmayr[m] not sure what you mean with sdk.
Tyaku has quit [Quit: Lost terminal]
Guest69 has quit [Ping timeout: 256 seconds]
<fbre>
JosefHolzmayr[m] Do you want to develop user space apps based on yocto and you're looking for a toolchain?
Tyaku has joined #yocto
fbre has quit [Quit: Client closed]
fbre has joined #yocto
<JosefHolzmayr[m]>
fbre: Not exactly, but close enough, yes.
<rburton>
JosefHolzmayr[m]: -toolchain- is populate_sdk, -toolchain-ext- is populate_sdk_ext. iirc, the esdks are they're build as minimal so they need to download the sstate to be usable (instead of being 3GB tarballs)
Guest69 has quit [Quit: Client closed]
<JosefHolzmayr[m]>
rburton okay thanks, will check it out.
<JosefHolzmayr[m]>
-minimal is perfectly enough.
willo has quit [Ping timeout: 260 seconds]
willo has joined #yocto
xmn has quit [Read error: Connection reset by peer]
xmn has joined #yocto
<coldspark29[m]>
Is there any way to speed up the chromium build? It takes up to 4 hours on my machine
<JosefHolzmayr[m]>
coldspark29 to some extent: get faster storage, get more CPUs. Besides that: nope. Chromium is just hide.
<JosefHolzmayr[m]>
*huge.
yates has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
<coldspark29[m]>
Yeah it's awful. I am trying to find the misconfiguration of the recipe and I have to wait for hours after every try
<coldspark29[m]>
I need a Threadripper hahahaha
<JaMa>
it takes around an hour on threadripper-3970x-128gb
<fbre>
I have a running user app on my device which receives the .wic file via webinterface. I put it in the RAM disk /tmp and want to extract it. Then I want to do: dd if=/tmp/0.fat of=/dev/mmcblk1p1 bs=512 and dd if=/tmp/1.img of=/dev/mmcblk1p2 bs=512
<rburton>
but a wic file isn't an archive
<rburton>
if you're sending a file system that gets written directly to disk, i'd be sending something with checksums
<fbre>
This is to exchange the boot and root partition
<rburton>
(sounds like you're reinventing swupdate fwiw)
<rburton>
but basically, a typical wic is a disk image. you can't just extract the file systems unless you're root and loopback mount it. make a new artifact which is the partitions in an archive.
<fbre>
ok, making a new artifact seems to be a good idea. And yes, it must be secured with checksums or ssl signing
<fbre>
I'm curious about swupdate fwiw now. I must find out what that is
<fbre>
I was just wondering because 7zip.exe can extract a .wic file
<qschulz>
fbre: you have plenty of update SW
<qschulz>
rauc, mender.io, swupdate, are the ones that comes to my mind right now
<rburton>
fbre: 7zip web site says it can browse disk images
<rburton>
which is why it works
<rburton>
on linux, just loopback or fuse mount
<fbre>
Usually, I update my user apps and system libs via opkg. This way I install into my current layer of the running overlayfs (which is in partition 3 and 4). But rarely I have the situation to exchange the base system as well, and this is partition 1 and 2
<fbre>
For the base system, I thought writing the .wic file to flash is a good idea. It just contains the lower layer of the overlayfs (with just the root filesystem of a naked yocto Linux) without the actual firmware
kayterina has quit [Quit: Leaving]
<fbre>
opkg can't read disk images, right?
<coldspark29[m]>
<JosefHolzmayr[m]> "coldspark29 to some extent..." <- You think Firefox builds faster?
<coldspark29[m]>
Or have you tried ^^
dtometzki has quit [Ping timeout: 265 seconds]
<JosefHolzmayr[m]>
coldspark29 I haven't tried. I just can rightfully state that they are huge when compared to most other applications we see in the yocto ecosystem.
<coldspark29[m]>
Ok
jwillikers has joined #yocto
xmn has quit [Ping timeout: 265 seconds]
warthog9 has quit [Quit: Leaving]
Belsirk is now known as rfuentess
<fbre>
Now I've bitbaked a bmap-tools ipk file. Is it a good idea to extract the disk image with bmap-tools?
<fbre>
or maybe even write the .wic file using bmaptool
<fbre>
(?)
warthog9 has joined #yocto
<smurray>
fbre: it'll be a lot faster to write with bmaptool, that's the point
<fbre>
I'm find that example of "sudo bmaptool copy dev-image-20190528085324.rootfs.wic.gz /dev/sdX" in the internet which seems so as if one can write a .wic file to flash.
<fbre>
But I wonder if I can write ONLY partition 1 and 2 and do not delete my partition 3 and 4
<fbre>
Maybe I have to play around with that tool and trial and error what happens
<qschulz>
fbre: create a wic file with only partition 1 and 2
<qschulz>
but honestly, just use a SW updater
Guest8 has joined #yocto
<smurray>
fbre: it might be possible to modify the .bmap file to skip some ranges, but that'd take some hacking on your part
<fbre>
qschulz: my .wic file just contains partition 1 and 2. But I'm not sure if bmaptool destroys 3 and 4
<Guest8>
for some reason my virtual/kernel (linux-raspberrypi) and my external modules (using inherit module) have different kernel versions specified in them (4.19.93 SMP preempt mod_unload modversions aarch64 vs 4.19.93). any idea how i can go about trying to resolve this?
<smurray>
fbre: bmaptool will only write out blocks with data, so maybe not, but it's possible it'd nuke your partition table if the new image only has 2 partitions
<fbre>
smurray: (y)
<smurray>
fbre: but as qschulz says, most people use a updater in products, e.g. swupdate, rauc, Mendor, etc.
<fbre>
Hmm, at the moment I cannot realize how those updaters logically assign in my known world of tools '=D I just know dd, bmaptool and opkg
<fbre>
Is it a third tools category for putting software in flash?
<smurray>
yeah, google swupdate or rauc, they have good documentation on what they do
<fbre>
grmpf... bitbake python3-pkg-resources leads to ERROR: Nothing provides 'python3-pkg-resources'. But it's needed by python3-setuptools and this is needed by bmap-tools
<qschulz>
fbre: are you sure python3-pkg-resources isn't a package built by a recipe?>
<qschulz>
jonmason: I don't think I've ever had access to the directory from a browser
<qschulz>
if you give it a full path that Yocto would be requested I guess it'll work?
<fbre>
qschulz ah OK, I've found it in tmp/deploy/ipk/aarch64
<fbre>
Seems bitbaking python3-setuptools have build it as well
<jonmason>
qschulz: I added it to my local.conf and build times appear to be the same without it being present (at ~30 mins for qemuarm)
<jonmason>
I was hoping that it was just a permission problem
rfuentess has quit [Remote host closed the connection]
<qschulz>
jonmason: are you building a machine that is available in the sstate-mirror and using uninative?
rfuentess has joined #yocto
<qschulz>
also, I think there's something related to hashserv
<qschulz>
fbre: the partition might be mounted already?
<fbre>
yes, it is
<fbre>
it's my lowest layer in the overlayfs
rfuentess has quit [Ping timeout: 252 seconds]
<fbre>
Probably I have put the .wic.gz file to flash first, then reboot and call bmaptool from the initramfs (before the root filesystem is mounted so to speak)
<fbre>
*have to put
yates has joined #yocto
Belsirk is now known as rfuentess
<yates>
is there a way to get one of the yocto manuals, e.g., the sdk-manual, as a pdf
<yates>
?
<qschulz>
yates: I don't know if there's a download link already but if you compile the docs yourself with `make latexpdf` you should get that
<yates>
ok that's reasonable, thanks qschulz
<qschulz>
docs are either in poky/documentation or yocto-docs git repo
<JosefHolzmayr[m]>
will it help if i bribe esdk with cookies and beer?
<jonmason>
you can mix beer and cookies
<jonmason>
beer needs salty/savory
<JosefHolzmayr[m]>
thats illegal in at least 42 states.
<jonmason>
now beer and a nice, soft pretzel
<qschulz>
cheese
<jonmason>
yes!
<JosefHolzmayr[m]>
but i don't want no cheese now, i want an installed esdk
<qschulz>
cheese is not for you Josef
<jonmason>
I want cheese now
<qschulz>
or are you the one to bribe to get a working esdk?
<jonmason>
ok, we will give JosefHolzmayr[m] cheese if he gets the esdk working
<JosefHolzmayr[m]>
uh-huh
<JosefHolzmayr[m]>
but anways, all i can see is a variety of setscene tasks failing with exit code 1.
<JosefHolzmayr[m]>
and no clue why.
<yates>
i'm trying to do some analysis on do_populate_sysroot for libgcc via "bitbake -c populate_sysroot libgcc" but yocto isn't running the task because it things it's already complete. is there a way to remove state information for just this task of just this recipe so bitbake will rerun?
<yates>
i'm hacking the run.do_populate_sysroot functions so i can see better what's happening
<qschulz>
yates: -f
<yates>
qschulz: thanks!
<JosefHolzmayr[m]>
hum. standard sdk installs, and as it also brings runqemu it might even be good enough for my use case. but something no worky again https://hastebin.com/ojoyisonux.sql
<JosefHolzmayr[m]>
(and yes, i sourced the environment. otherwise it wouldn't be on the path, obviously)
rcw has joined #yocto
<smurray>
JosefHolzmayr[m]: I think this makes you the eSDK maintainer, have at it
<JosefHolzmayr[m]>
?
<JosefHolzmayr[m]>
right now i'm substantially more confused than even usual for me.
sakoman has joined #yocto
<smurray>
JosefHolzmayr[m]: not a lot of people use eSDK, and it's lightly maintained, so I was joking that you're the maintainer now since you're using it
<smurray>
JosefHolzmayr[m]: fray may be the person with some ideas, he poked at it a bit recently
<JosefHolzmayr[m]>
smurray: ah okay. thats what you meant.
<qschulz>
though since they are actively working on 5.10 AFAICT, I would say there might not be any future update of this branch?
<mcfrisk>
qschulz: yes, that's the crappy, buggy version that we use. Not good. Need a newer 5.4.y to fix lots of crashes in non-SoC parts of the kernel
<smurray>
mcfrisk: linux-fslc in dunfell branch of meta-freescale is on 5.4.119...
<smurray>
mcfrisk: I think Andrey probably moved onto the 5.10 kernels instead, might be worth asking him
<mcfrisk>
what was the fslc relationship to meta-imx?
<smurray>
meta-imx is NXP's own thing AFAIK, no community contributions
<smurray>
but that's probably a question for otavio as I'm likely missing some nuances
<smurray>
sure, even dunfell works for i.MX8, the specific ask was for a kernel closer to upstream 5.4.y
<fbre>
linux-fslc-imx_5.4.bb says LINUX_VERSION = "5.4.129" from KBRANCH = "5.4-2.3.x-imx"
<fbre>
works even with RT patch
<smurray>
sure, and upstream is at .147, I assume mcfrisk meant he wanted something closer to that
<fbre>
not with RT patch, and RT patch is good for i.mx8
<Ad0>
I get from curl on an ssl site I know works well in my regular browser "curl failed to verify the legitimacy of the server and therefore could not ... "
<smurray>
fbre: mcfrisk said nothing about the RT patch, if it works for you, great
<rburton>
Ad0: is ca-certificates installed
<Ad0>
yes
<Ad0>
I installed the root certificate
jd40 has joined #yocto
<Ad0>
I run update-ca-certificates but it does not show up in /etc/ssl/certs/ca-certificates.crt
<Ad0>
it successfully creates a link in /etc/ssl/certs tho
<jd40>
Hey folks, I was working on some recipes and was wondering something.
<jd40>
if I have a DEPENDS="recipe" that recipe has a PV and PR, is there a good way to retrieve those in the current recipe?
<rburton>
not really
<jd40>
I was afraid of that, well thanks anyway
<kergoth>
Hmm, does Yocto maintain info about what CVEs were fixed by a recipe upgrade? The patches get dropped, so the CVE: metadata isn't there any longer, is there a database for that, or not covered anywhere?
ThomasD13 has quit [Ping timeout: 252 seconds]
<rburton>
you can infer it from the cve database
<rburton>
we tend to go and get that fixed if its incomplete
<qschulz>
jd40: if you explain what you are trying to achieve maybe we can guide you through a proper solution?
<kergoth>
rburton: which one, nvd?
<rburton>
yeah
eduardas has quit [Quit: Konversation terminated!]
<jd40>
I'm working on our update package that can be used to update deployed systems, basically it's a archive of several build artifacts
tre has quit [Remote host closed the connection]
vd has joined #yocto
<qschulz>
jd40: you can deploy a file from each recipe that is providing their version and make the recipe building the archive read those files, you need to not forget to add the proper dependency on the deploy task for that archive recipe otherwise you might have races
jd40 has quit [Quit: Client closed]
jd60 has joined #yocto
jd60 is now known as jd40
<jd40>
qschulz that might indeed be a good solution, I'll see if I can make that work, thank you.
<Ad0>
qschulz, rehash: warning: skipping duplicate certificate in gd-class2-root.pem
<Ad0>
it's already there ...
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fbre>
hmm grmpf.... calling bmaptool from my initramfs leads to this error:
<fbre>
File "/usr/lib/python3.8/os.py", line 675, in __getitem__
<fbre>
raise KeyError(key) from None
<fbre>
KeyError: 'PATH'
<fbre>
Any idea what I can do?
<RP>
fbre: set the PATH environment variable in the call site?
<fbre>
The .sh script sets PATH a few lines before
<fbre>
before the call of bmaptool
BCMM has quit [Quit: Konversation terminated!]
<kergoth>
fbre: forget to export it?
<Ad0>
rburton, it was the server cert that was misconfigured
dtometzki has joined #yocto
<otavio>
mcfrisk: 5.4 is being updated but what you need?
<otavio>
mcfrisk: we have it on dunfell for example
<fbre>
kergoth, yeah good hint. Adding "export" helps
<mcfrisk>
otavio: I'd need an 'NXP' blessed tree with 5.4 LTS merges which can be used on imx8 by vendors. I'd point them to it instead of giving me v5.4.70 with a lot of known bugs like fuse crashes
jmiehe has quit [Quit: jmiehe]
fbre has quit [Quit: Client closed]
rfuentess has quit [Remote host closed the connection]
<fray>
Internally our guys are working off master of tcf-agent because it fixes issues like walking arm thumb code and better supporting clang 12. Should I put together a tcf-agent update or master? (There hasn't been a new "release", and the current tcf agent is based on 1.7.0 tag.
prabhakarlad has quit [Quit: Client closed]
<moto-timo>
fray: seems like a good idea
<fray>
ok.. so I'm not stupid.. (My problem is I have no way to test it, but like I said, another team is 100% using the latest code. So I know it 'works for them'. I just hate keeping patches internal.)
florian has quit [Quit: Ex-Chat]
jd40 has left #yocto [#yocto]
fitzsim has joined #yocto
zpfvo has quit [Remote host closed the connection]
rcw has quit [Quit: Leaving]
gsalazar has quit [Ping timeout: 268 seconds]
jmiehe has joined #yocto
rcw has joined #yocto
otavio has quit [Remote host closed the connection]
<moto-timo>
fray: especially since the 1.7 branch hasn’t seen any attention since 2018. It would be nice if upstream would do a new “release”
<fray>
I had that happen before when things were either missing from the sstate-cache or files were getting corrupted..
<fray>
(the faled exit code 1 thing)
<fray>
if you can figure out what that is (I'm guessing lack of the state-cache file).. then we can traceback why..
<yannd>
a bit off-topic: anyone investigated the idea of using bitbake to build a downstream distro of debian/fedora/whatever ? The idea would be to have a "magic layer" providing upstream deb/rpm with mostly do_fetch and do_package_write_{deb,rpm}, and the necessary bits to make them usable in sysroots
<yannd>
that would not really help to modify packages, only to add custom distro-specific packages - modified packages would have to be translated to bb's, so yes that's not perfect
<yannd>
the upside would be the ability to customize vitrually any distro
<sgw>
Hi Guys, I should probably know this, but will consult this oracle, is there a set of tests for the SDK? I know that eSDK has a couple of test cases in the oe-selftest. Thx
<JosefHolzmayr[m]>
yannd: look at what the isar guys or elbe are doing - its basically what you described, for debian.
<JosefHolzmayr[m]>
fray: was distracted, sorry. hm. sadly this happens on the "official" esdks, and on something that i created. i suspect something wrong in the target container to run it, but i have no clue on how to approach it.
<JosefHolzmayr[m]>
moto-timo: english speaking people say: "great minds think alike". german speaking people say: "two idiots, one idea"
<moto-timo>
yannd: in theory if you could get fedbootstrap integrated you could do similar for Fedora.
<moto-timo>
🍻
<yannd>
nice, thx!
<fray>
I've only seen it when a disk is broken (corrupting files) or hashes are changing during extraction..
<fray>
but if you can dig into the eSDK logs you should be able to find the error triggering the exit 1..
<fray>
I'm guessing [without anything further] that the setscene file is not there, so 'file not found'
<JosefHolzmayr[m]>
moto-timo: hi5
<fray>
the only time I saw that behavior is when the eSDK config and the actual config were out of sync [or things ran in the wrong order]..
jmiehe has quit [Remote host closed the connection]
<vd>
from a recipe_%.bbappend file, ${PV} is literally '%'. What should I do to get the proper package version?
Vonter_ has joined #yocto
Vonter has quit [Read error: Connection reset by peer]
<manuel>
wtf I added ptest to my DISTRO_FEATURES and now it's rebuilding more or less everything. Altough I didn't put ptest-pkgs in the IMAGE_FEATURES. Why is that?
<manuel>
I'm including only one -ptest package so I'd have expected to see that one getting rebuilt only.
<RP>
manuel: ptests often have a lot more dependencies and it has to build them for everything even if you don't add them all to an image
amitk_ has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
xmn has joined #yocto
amitk_ has quit [Ping timeout: 268 seconds]
markus5h[m] is now known as mahu[m]
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
yates has quit [Quit: rcirc on GNU Emacs 25.2.2]
florian has joined #yocto
rcw has quit [Quit: Leaving]
<RP>
jonmason: thanks, I put the patches on the AB for testing (along with another slighly risky patch of mine)
bluelightning has joined #yocto
<jonmason>
Good. I made sure it worked locally but didn't run testimage