<khem>
hmm so idea is per recipe build-tools tarball ?
<khem>
RP: I am building the usual suspects in meta-oe with go 1.22 and see if there are any hidden daemons
justache has quit [Ping timeout: 255 seconds]
justache has joined #yocto
zenstoic has quit [Quit: Connection closed for inactivity]
justache has quit [Ping timeout: 255 seconds]
justache has joined #yocto
davidinux has quit [Ping timeout: 264 seconds]
davidinux has joined #yocto
<moto-timo>
FWIW, the crops yocto-dockerfiles and poky-containers are updated to include fedora-37 (yes, I know it is already EOL), fedora-38, fedora-39 and opensuse-15.5
<moto-timo>
debian-12 is one of those distros that insists you should not use pip to install anything, so it will force a change in the test scripts
<moto-timo>
I also noticed the extsdk-container had lapsed out of weekly builds, so those are triggered again. GitHub Actions times out if the repo has not had any recent commits... but this repo doesn't need new anything... the underlying container needs updating to get new security and vulnerability fixes.
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
xmn has quit [Read error: Connection reset by peer]
<rfs613>
Piraty: not sure if this is what you are looking for, but usually you enable this check by adding INHERIT += "cve-check" to local.conf
<rfs613>
that way it runs as part of the normal image build, on every recipe. Alternatively you can run it for a single recipe by doing "bitbake -c cve_check recipiename"
<Piraty>
i want to understand what it does, i.e. see the api call or whatever
<Piraty>
can't really it in poky
<rfs613>
ah, well, best to look at the code - there are two parts, one to download the NVD database and produce a local version (sqlite? it's been a while since i looked)
<rfs613>
and the second part does lookups for each package against that database
<Piraty>
pulling the whole DB from nvd and store it in sql3 seems common for many of those cve tools
<rfs613>
yeah... you don't want to be querying on each build
<rfs613>
and incrementally updating the db makese sense too, it's huge
<Piraty>
matching a package to cpe and filtering irrelevant cve entries from db query's response is the hard part
<Piraty>
huge: no . is nvd hell slow at providing the db? yes
<rfs613>
that's part of it... but the DB itself often contains less-than-ideal information, filtering that (and perhaps trying to get it fixed) is also a big part
<rfs613>
especially it is hard to track fixes that get backported to olde maintenance branches... the way nvd tries to capture that is a frequent source of incorrect reports
<Piraty>
that bbclass file looks like the inbreed of Makefile + python3 i never wanted to see
<Piraty>
must be a pain to debug
<rfs613>
hehe i haven't deatl with it in a while (like a few years)
<rburton>
there is a plan to rip it out into a standalone tool for easier development/testing/etc.
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
luc4 has joined #yocto
rob_w has quit [Ping timeout: 272 seconds]
rob_w has joined #yocto
justache has quit [Ping timeout: 264 seconds]
justache has joined #yocto
xmn has joined #yocto
jmiehe has joined #yocto
sotaoverride is now known as Guest7005
Guest7005 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
sotaover1ide has joined #yocto
Dr_Who has joined #yocto
justache has quit [Ping timeout: 264 seconds]
justache has joined #yocto
rob_w has quit [Remote host closed the connection]
jmiehe has quit [Quit: jmiehe]
rsalveti has joined #yocto
Dr_Who has quit [Quit: ZZZzzz…]
<qschulz>
does anyone have a multi-repo setup within gitlab-ci with kas for testing merge requests from one repo still build in the other repo? (e.g. I have a public bsp layer and a private demo layer, I want to make sure when I push to the bsp layer, the demo layer still builds)
vladest has quit [Ping timeout: 264 seconds]
<yocton>
qschulz: partialy (not kas and it's still a WIP)
<qschulz>
yocton: if not kas, are you using the "new" layer tool in Yocto or something handcrafted?
frieder has quit [Remote host closed the connection]
<moto-timo>
qschulz: pidge and tgamblin and I were talking about such an architecture, but we haven't really gotten it going yet.
<moto-timo>
qschulz: happy to bounce ideas around. It seems like a fairly obvious direction to go in.
* moto-timo
also happy to use the new tool
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 264 seconds]
zpfvo has quit [Remote host closed the connection]
vladest has joined #yocto
<qschulz>
moto-timo: maybe I should shoot a mail on the ML, because I have a feeling this may require a bit more than a few lines on IRC :)
<moto-timo>
qschulz: agreed
<qschulz>
moto-timo: that'll take some time though, need to do some research on gitlab-ci multi-repo pipelines :)
<moto-timo>
qschulz: I get it. This is part of why we didn't get anything "baked" yet.
<qschulz>
moto-timo: I got a bit crazy last week and implemented dynamic child pipelines for runtime generation of jobs in gitlab ci :)
<qschulz>
(but nothing we could use for multi-repo stuff :/)
smokey has joined #yocto
Dr_Who has quit [Quit: ZZZzzz…]
Dr_Who has joined #yocto
kpo has joined #yocto
Dr_Who has quit [Ping timeout: 255 seconds]
ptsneves has quit [Ping timeout: 252 seconds]
Vonter has quit [Ping timeout: 246 seconds]
Vonter has joined #yocto
Saur78 has joined #yocto
Saur62 has quit [Ping timeout: 250 seconds]
smokey has quit [Quit: Client closed]
<moto-timo>
qschulz: I might just try to recreate the git submodules bot update script we had back in the "Living on Master" days (2018?)
<moto-timo>
qschulz: kas is great, but I am also trying to entertain the submodules folks.
<khem>
qschulz: if you like github actions then look at yoe distro ci and meta-clang ci
alperak has quit [Quit: Client closed]
alperak has joined #yocto
<moto-timo>
khem: as you know, yoe-distro is my poster child for both GitHub Actions and submodules.
<jdiez>
hi, I am trying to debug a build tool written in python (colcon) that seems to not detect one of the plugins it needs to build my recipe. The python `sys.path` looks correct. Is there any way I can run python (or other commands) in the native sysroot, as bitbake would?
Haxxa has quit [Quit: Haxxa flies away.]
<jdiez>
hm, i tried sourcing the temp/run.do_compile.XXX script but that actually called do_compile and `exit`ed my shell
<khem>
moto-timo: kool.. ( KDE plasma 6.0 released this week so 'c' is now 'k' for sometime )
<moto-timo>
khem: and it's all about Qt6 so there's that
Haxxa has joined #yocto
<khem>
but I am impressed with plasma6, this is the best release ever
<moto-timo>
khem: I have been intrigued by plasma, so I will have to take a look. I still want a "Yocto Project built daily driver desktop". Why not?
<khem>
yeah use meta-kde
<moto-timo>
👍
<khem>
my daily drivers are arch and nixos but thats just convenience
<moto-timo>
I guess I'm still on GNOME by default on Ubuntu and Debian.
<khem>
ugh caveman :)
<moto-timo>
I never quite got arch installing easily. I gave up on Gentoo when it broke my ethernet after a couple weeks of no upgrades. NixOS is interesting, but not a silver bullet.
<moto-timo>
I will freely admit that I do hold on to some old ways.
<khem>
I installed arch once in 2016 and since then I have been just doing pacman -Syu
<moto-timo>
yeah. but can you explain in a few sentences what you did in 2016? lol
<khem>
I want to keep this machine going till 2026 so I can say I managed a machine with rolling release for 10 years
<moto-timo>
I'm sure it got better. I looked at it in 2017-2018 I think.
<khem>
yes arch has a very good handbook follow step by step. you will never mess it up
<moto-timo>
I kind of wish we could claim arch was a support distro for YP. oh well.
<moto-timo>
Ok. The next workstation I will start with that.
florian_kc has joined #yocto
<khem>
you can also use some derivatives like EndevourOS, Garuda
<moto-timo>
I am tired of grumbling about ubuntu (snaps are horrible) and debian (too sluggish)
<moto-timo>
sluggish meaning they do not upgrade packages often enough
<khem>
they have graphical installers, I personally find Garuda quite impressive but never used it for long
<moto-timo>
Fedora is too much churn for me these days. RH engineers are doing all kinds of new things, but it's hard to stay in sync.
<khem>
Nixos is whole new game
<moto-timo>
I gave up on Fedora being a daily driver around fedora-28. When the Modularity stuff was churning HARD.
<khem>
especially with flakes AI tools become to easy to use
<moto-timo>
Oh, I have watched some NixOS live streams. It makes a lot of sense for infrastructure roll-out.
<moto-timo>
But I was watching the Mastodon livestream when Kris Nova gave up on NixOS because it eventually introduced new problems.
<moto-timo>
and I don't do enough virtualization for my daily drivers to make proxmox make sense.
<moto-timo>
I've also now got enough Terraform/OpenTofu under my belt that cloud infra is rolled out with that.
<JaMa>
jdiez: you can use devtool to simulate the env, but when I'm already in WORKDIR,then I usually source the corresponding run.do_* file (if it's shell task) after editting out the exit calls (3-4 of them typically)
<jdiez>
JaMa: yeah, the latter is what I did, and seemed to work for my purpose
<jdiez>
how do you do it with devtool?
simonew has joined #yocto
<halstead>
moto-timo: We had an ArchLinux worker for a bit and SUSE Tumbleweed for a long time. Does it make sense to test the build system on rolling releases though?
<JaMa>
khem: I'm close to 20 years of rolling gentoo install :)
<halstead>
I ran Gentoo on my home server for years when I had one. Arch is on my personal laptop and I love it.
<moto-timo>
halstead: It probably does not make sense. But we have a lot of folks in the field using Arch Linux as a daily driver (and Gentoo). In practice? I just add my own distro to the SANITY_TESTED_DISTROS and ignore the fact that it isn't tested by the AB.
* halstead
nods.
<moto-timo>
it's just this "we know you are using Arch Linux, why do we remind you that you aren't supported every time you run a build" nag that I wonder about.... but as I said. I have a hammer for that.
sev99 has joined #yocto
<moto-timo>
I also figure folks that are running Arch also don't give a crap about that warning. :)
<JaMa>
the hammer makes sense in this case, because each install will be different, so you manually adding it to SANITY_TESTED_DISTROS you agree that you're the warrantee of your OS
<moto-timo>
JaMa: very VERY good point.
<moto-timo>
sort of like "I_PROMISE_TO_STOP_USING_PYTHON_2"
<JaMa>
having it in e.g. poky's SANITY_TESTED_DISTROS would be very misleading on the other hand
<moto-timo>
I was even reminded about which versions are currently claimed in sanity tested distros when I added some new ones to crops yesterday. This is why those builds do not fail on warnings ;)
vladest has quit [Remote host closed the connection]
<moto-timo>
Also, for the record, a rolling Yocto Project release in the field was HIGHLY unpopular amongst customers.
<JaMa>
gentoo "works" for me as well, but living on the edge sometimes gives some challenges (which I don't mind but others might), being one of first to willingly switch to python 3.12, latest gcc, glibc-2.39 (and building uninative locally before it's built officially) :)
<moto-timo>
(ClearLinux proved that no one in embedded wanted a rolling release updating multiple times a day)
<moto-timo>
Also, going away to lunch and coming back and your build breaks is not going to make developers happy. (Training session I took on CL)
<JaMa>
I think it's very different to have rolling distro for devs (who can deal with some daily changes or even breakages) or having it for everybody (who don't really care about the underlaying OS)
<moto-timo>
This is the point.
<moto-timo>
Thanks for stating it so nicely.
<moto-timo>
and then there is the CIP end of things where nothing is allowed to change or update ever but yet it needs to be supported for 30 years and be secure and hardened.
<moto-timo>
(mostly tongue in cheek, but there is some truth)
<JaMa>
no problem, just release it perfect on 1st try :)
<moto-timo>
Release: develop it, test it, build it, ship it encased in lead and concrete and deploy it to the bottom of the ocean.
<moto-timo>
It will be perfect forever.
<moto-timo>
I think I'll start a new OS project called "Amber".
<moto-timo>
All commits and pull requests will be automatically rejected.
<moto-timo>
It will use the Linux 2.26 kernel of course.
<fray>
rolling releases are fine for operating system/integration developers.. but the screaming that comes from app devs, app integrators, devops teams, etc is remarkable..
<moto-timo>
and yet they want the newest NodeJS and the latest npms
<fray>
the only time I've heard the screaming 'reduced' on any sort of rolling release, is when those teams have to deal with CVEs in libraries they depend on
<moto-timo>
this
<moto-timo>
lol
<fray>
well of course, cause NPMS are never compromised
<moto-timo>
just like basing your critical infrastructure on an ephemeral OS that just updated to some random commit hash for 1000 repos an hour ago is JustFIne.
<moto-timo>
CloudChaos.
<moto-timo>
CloudChaOS.
<JaMa>
:)
<fray>
also the amount of "pip has it, just download the binary!"
<moto-timo>
cough
<moto-timo>
"Yes, you can install a binary wheel. Don't."
<moto-timo>
la la la
Kubu_work has quit [Quit: Leaving.]
<rburton>
moto-timo: aah clear linux such memories
<moto-timo>
rburton: I knew you would "enjoy" that
<moto-timo>
it did some very interesting things. but not for embedded.
<rburton>
absolutely
<rburton>
still surprised its (relatively) active
<moto-timo>
same
<moto-timo>
stress-ng is still updated regularly for it
<moto-timo>
(about the only thing I get notificatons about)
ptsneves has joined #yocto
Saur23 has joined #yocto
goliath has quit [Quit: SIGSEGV]
paulg has quit [Ping timeout: 240 seconds]
Saur78 has quit [Ping timeout: 250 seconds]
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
zenstoic has joined #yocto
paulg has joined #yocto
alperak has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
ptsneves has quit [Ping timeout: 260 seconds]
amitk has quit [Ping timeout: 260 seconds]
mvlad has quit [Remote host closed the connection]
smokey has joined #yocto
<smokey>
I am seeing this error from `bitbake secure-core-image` immediately after the build configuration is shown (before parsing): https://pastebin.com/w2AQ0V4Q
<smokey>
Not sure how to debug this...
jmd has quit [Remote host closed the connection]
flom84 has joined #yocto
jmd has joined #yocto
<smokey>
... I mean *after* parsing
tgamblin has quit [Ping timeout: 268 seconds]
<yocton>
Smokey: do you have "ext4" in IMAGE_FSTYPES? Sound like it is missing...
<RP>
JaMa: I'm more than happy for you to run crazy host distros, we're just not going to recommend or say we "support" them :)
<yocton>
Smokey: its weird to look for the do_image_ext4 of a initramfs image... I'd say the dependency (bootimage->ext4) is wrong not the fact that do_image_ext4 does not exists...
<vmeson>
yocton: I was thinking the same thing but didn't say anything since I haven't played with initramfs images lately.
<smokey>
RP: yes... we are creating a distro and I got thrown into it. :)
<RP>
yocton: I've merged those meta-oe exclusions but I'm wondering if we shouldn't write them to an inc file in the layer
<Ad0>
mckoan|away, I will try it, worth a shot
<Ad0>
thanks!
jmd has left #yocto [ERC 5.4 (IRC client for GNU Emacs 28.2)]
<yocton>
RP: that's a good idea! Having AB config handle this list feel like a waste of time
flom84 has quit [Ping timeout: 260 seconds]
<RP>
yocton: agreed, I think we can do better
vladest has joined #yocto
<mischief>
for bitbake --setscene-only, can i print what was missing? we're trying to see why our sstate appears to be missing a bunch of stuff at the moment.
<yocton>
Smokey: maybe bitbake -e ? (it does print where some task depends comes from). Also, "bitbake -g" might be useful (it generates the task dependency graph). Try for both secure-core-image-initramfs and secure-core-image