<LetoThe2nd>
rburton: yup I actually checked that photostream just an hour ago. thats what happens when two old grumpy white dudes try to be like the cool kids.
<rburton>
another 700 photos landed overnight or so, i guess that's the lot now
TheOne has joined #yocto
<TheOne>
Out of curiosity, besides the yocto experts here, are you experts in other areas as well or have you "only" specialized in this? Trying to understand how it all works as a junior :)
<tgamblin>
TheOne: This may not be exactly what you're asking about, but there are many people involved who come from physics and/or materials science backgrounds
jetm- has joined #yocto
Vonter has quit [Ping timeout: 260 seconds]
philmd- has joined #yocto
<LetoThe2nd>
random thought - I have a layer with a .templateconf, and its driving me nuts. any way to ignore it?
tgamblin has quit [Remote host closed the connection]
jetm has quit [Ping timeout: 272 seconds]
philmd- has quit [Ping timeout: 252 seconds]
jetm- has quit [Ping timeout: 260 seconds]
philmd has joined #yocto
<jonmason>
zeddii: The dev-kernel is still at 6.3. Seems weird that it's older than one of the supported kernels. Are you waiting on 6.5 to be released to bump it?
jetm has joined #yocto
rob_w has joined #yocto
jetm- has joined #yocto
tgamblin has joined #yocto
|Xagen has joined #yocto
sotaover3ide is now known as sotaoverride
Xagen has quit [Ping timeout: 245 seconds]
philmd- has joined #yocto
Yash75 has quit [Ping timeout: 246 seconds]
|Xagen has quit [Ping timeout: 272 seconds]
rfuentess has quit [Ping timeout: 240 seconds]
belsirk has joined #yocto
marc1 has quit [Read error: Connection reset by peer]
rfuentess has quit [Remote host closed the connection]
kscherer has joined #yocto
<jonmason>
zeddii: disregard, I was on mickledore, not master
BrianL has joined #yocto
sakoman has joined #yocto
<rburton>
poked a bit more at the NVD cve api and had yet another horrific discovery
Xagen has joined #yocto
mckoan is now known as mckoan|away
rob_w has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
GNUmoon has quit [Ping timeout: 240 seconds]
JerryM has quit [Quit: Konversation terminated!]
xmn has joined #yocto
rfuentess has joined #yocto
Canary has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
<Canary>
I've been having difficulty working with a custom license in a recipe. I cannot figure out how to add the license to the layer and set up the checksum in the recipe. Also, for clarity's sake, I am working with petalinux and not just pure yocto.
<fray>
Where is your error, when building the recipe or?
<Canary>
I'll get an error that LIC_FILES_CHKSUM points to an invalid file, followed by a path to the build directory where the license file does not exist.
<Canary>
My attempt at adding the license includes setting the LICENSE and NO_GENERIC_LICENSE[license name] vars in the recipe (as well as attempting to figure out a path for LIC_FILES_CHKSUM), and adding a LICENSE_PATH to layer.conf.
<fray>
ok.. Is the presented path your ${S} location (the source code location for that recipe) or is it the WORKDIR (that is the maind irectory)
<fray>
the error says that the path you specified doesn't exist
goliath has quit [Quit: SIGSEGV]
<rburton>
Canary: the hdparm recipe is a good example of a custom license where you can't just use SPDX names in LICENSE
<rburton>
as fray says, the relative paths are relative to ${S}
<fray>
The LIC_FILES_CHKSUM path will default into the S (source) directory. If you are changing your S value, then you need to adjust the path relative to S
<Canary>
I'll take a look at that hdparm recipe.
<fray>
So if it's completely custom, and the license is not located within the extracted sources. Often you need to add the licese to the SRC_URI (using the standard format), then the LIC_FILES_CHKSUM will be something like "file://../LICENSE;md5=..."
<fray>
(this assumes the S directory is a child of the WORKDIR, since WORKDIR is where the license will be downloaded. Alternatively you can do file://${WORKDIR}/LICENSE;md5=.... (I think that still works, but it's been a while)
<RP>
JPEW: that is with the latest runner patches afaik
<JPEW>
blerg
<Canary>
I think I'm still a bit fuzzy on where exactly the source directory and work directory refer to in relation to the project.
<rburton>
Canary: WORKDIR is temp/[arch]/[package]/[version], S defaults to a directory recipe-version/ under that directory.
<Canary>
Okay, so they both refer to a location that is created by yocto rather than anything I directly control.
<rburton>
yeah absolutely
<Canary>
Part of my problem has been getting the license file to get into there in the first place, and it sounds like the solution is to add it to the SRC_URI? I thought I'd tried that, but may have not done it right.
<rburton>
${S} is typically "the root of the source tree"
<rburton>
so the license file is _not_ part of the source?
<rburton>
first step in that case is tell people distributing the source that it really should include the license file
<rburton>
but yeah, if you have the license as a file then add it to SRC_URI and it will appear in WORKDIR too
<Canary>
First step is for me to really learn yocto and not do things wrong. This is my first attempt at a recipe, and I'm basically trying to add a firmware file into the project and wanted to do it right by including the license that goes with it.
<fray>
IMHO the license should always be listed in the SRC_URI (or part of the source). The SRC_URI can refrence files in a local directory, i.e.: recipes-test/my-recipe/files/LICENSE then your recipe just does SRC_URI = "file://LICENSE"
<fray>
(it is possible to point LIC_FILE_CHKSUM outside of the recipe path, but I discourage it with a few VERY minor exceptions.. basically recipes that don't have any source code it may be a valid)
<Canary>
Given that this is such a case without any source code, just a firmware file to copy into a location, should I do it another way, or should I just dump that license file into the files directory and add it to the SRC_URI?
<fray>
A file is still 'source' in the general sense. So I would have two entries in the SRC_URI, one for the license and one for the configurationf ile.
<fray>
a packagegroup would be an example of a recipe without sources. All it does is set dependencies
<Canary>
Now also worth asking, but this particular recipe is, as stated, to add firmware. I saw that there used to be an intel-maintained linux-firmware recipe. Is there anything like that under active maintainence that people are recommended to use?
<Canary>
okay, that looks like what I should probably be using. Still, I wanted to make sure I figured this license thing out regarless for when I start making real recipes.
leon-anavi has quit [Quit: Leaving]
<tlwoerner>
the aarch64 patches being added my meta-arm don't seem to apply error-free to linux-yocto 6.4
<tlwoerner>
s/my/by
<tlwoerner>
strangely, they aren't being applied to qemuarm64, so maybe nobody has noticed?
<Canary>
Does SRC_URI require two separate append operations, and not just adding all files at once?
<Canary>
nevermind, forgot to cancel the second new-line character.
<Canary>
That was probably what happened yesterday when I am pretty sure I had tried to do it this way.
<Canary>
Okay, so now my license is showing up in the build directory tree, but it is in [...]/linux-firmware/1.0-r0/, while LIC_FILES_CHKSUM apparently points to [...]/linux-firmware/1.0-r0/linux-firmware-1.0/
<rburton>
set LIC_FILES_CHKSUM to file://${WORKDIR}/mylicensefile
<rburton>
relative paths are relative to ${S}
<rburton>
because the usual case is "the LICENSE file in the tarball", so file://LICENSE is right
<Canary>
ah, yes, okay. Just like in my do_install where I use ${WORKDIR} to reference the firmware file.
<Canary>
What about SRC_URI? Should I be using ${WORKDIR} in there, too, or is that different?
<Canary>
Wait, no, of course not, that part's already working given the files are being copied into the work directory.
<rburton>
right, SRC_URI is either absolute remote URLs (http:...) or relative local file: URLs which are searched for near the recipe itself
goliath has joined #yocto
<rburton>
mrybczyn[m]: so the incremental CVE feed doesn't cover CPE changes, and the API for incremental CPE updates is "somewhat verbose" and means yet more API calls. urghhghghghghg.
<rburton>
unless this is meant to be machine-readable
<rburton>
"version_value": "Upto Version 1.2.103 (Current stable) [fixed: There's no fix yet]"
<rburton>
though this CVE is great. the exploit is a link to imgur.com
<mrybczyn[m]>
rburton: some new entries have it (from mid 2022 I think). But they didn't backport the data from nvd. At least this is what I understood.
<JPEW>
RP: The lz4 ptest is close to the edge of timing out. I think maybe that's what happened, but I'll try to figure out why it didn't say so and why the ptest-runner timedout when the old one didn't
<rburton>
mrybczyn[m]: *obviously* now for eg cve-2023-0459 nvd and mitre have different version information
<RP>
JPEW: some kind of buffer flushing issue?
<JPEW>
Possibly
<mrybczyn[m]>
rburton: rburton: why have I sais that merge of two databases is fun? Sniff...
frieder has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
yannd has quit [Ping timeout: 272 seconds]
Haxxa has quit [Remote host closed the connection]
<Canary>
I believe firmware is supposed to be installed into /lib/firmware, but the ${libdir} var gives me /usr/lib. Is there a var I should be using to install to /lib?
<Guest14>
https://github.com/systemd/systemd/pull/6918 that cannot be simply fixed. (The code where the patch is made is in systemd repository (not systemd-stable)) and the code that I have in HardKnott is really different (kirkstone is also different so I don't know if it fixes the problem or not).
<Guest14>
So, my question is: What are the steps to use udhcpc instead of systemd-networkd to configure the network ?
<Guest14>
udhcpc need to be run for each interface when an interface is up ?
<Guest14>
I have a WiFi STA interface and ethernet interface, I wan't to manage the two interfaces by a DHCP client.
<Guest14>
For the WiFi interface, I already have a script that is called when a CONNECTED/DISCONNECTED event appear (using wpa_cli -a /path/to/script). For eth0 I don't know if there is something like this.
<JPEW>
RP: Figured it out. Bad assumption on what the timeout meant that I "fixed"
<JPEW>
I assumed it was the total test timeout, it's actually how long to wait without seeing input, so a test that prints once a second would run forever
<JPEW>
not sure if we actually _want_ that, but fixes incoming soon
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
alessioigor has quit [Quit: alessioigor]
<tlwoerner>
jonmason: the kernel patches meta-arm adds for aarch64 don't apply cleanly for 6.4 (maybe it's just me?)
florian_kc has joined #yocto
<tlwoerner>
when i build with qemuarm64 they aren't added, so you won't see the problem there, but building for a "real" machine seems to hit it (or at least it does for me with meta-rockchip)
shimmer__ has joined #yocto
* zeddii
warms up the tar
<jonmason>
tlwoerner: ues, its a problem
<jonmason>
err..yes
<tlwoerner>
ah no worries!
<jonmason>
I have a patch....
<tlwoerner>
i really just wanted to make sure it wasn't just me on meta-rockchip
<jonmason>
essentially, they can all be removed
<tlwoerner>
sounds great! thanks
<jonmason>
its to prevent warnings for defconfig usage
<shimmer__>
Anybody know why the OpenEmbedded layer index shits the bed if you switch to branch fido?
<jonmason>
only 1 is needed on 6.4 now
<jonmason>
shimmer__: because it's ancient and unsupported
<jonmason>
tlwoerner: in the process of moving meta-arm back to using master
<shimmer__>
Ugh, I know, I'm trying to get our build updated to kirkstone but I'm trying to recreate what previous engineers did
<jonmason>
shimmer__: are you just trying to build a qemu or something?
<jonmason>
in case you needed it, which I'm sure you don't
<tlwoerner>
jonmason: :-)
<shimmer__>
No, we have a custom board with an NXP imx 6 solo x processor on it. We have an old version of Uboot on our build and I'm trying to update it. To do that I have to get an old Yocto build updated to modern repos. The old build is crashing because it doesn't know where to get mosquitto, and I can't figure it out using the layer index.
<shimmer__>
I may have to just scrap it and start over
<jonmason>
shimmer__: you might be able to get the old u-boot working in your layer. We hold back legacy versions for BSPs, and its not terrible to do
<jonmason>
you might do something like this for all of the recipes from fido, then verify it works, then update
<shimmer__>
Well, the goal is to update U-boot. They need to update emmc chips on the board and they need a newer version of uboot to do that
<jonmason>
baby steps
<jonmason>
get them on a modern build setup, then make it about the legacy versions (my suggestion)
rber|res has quit [Ping timeout: 260 seconds]
<shimmer__>
yeah, that seems like the path of least resistance, ok thanks for your help
shimmer__ has quit [Quit: leaving]
<jonmason>
you might even be able to use devtool to rebase the patches in u-boot and apply it to the latest version
<jonmason>
depending on how invasive they are
Ablu is now known as Ablu__
<vvn>
Don't you guys think that we should default TMPDIR to ${TOPDIR}/tmp/${DISTRO}? So that by default one can build any combination of machine/distro without interfering with the built artifacts?
<vvn>
RP: ^
Guest14 has quit [Quit: Client closed]
<denix>
how can I force runqemu to NOT use system libc? it starts the correct qemu-system-aarch64 from TMPDIR, but trips on /lib64/libc.so.6: version `GLIBC_2.34' not found
goliath has quit [Quit: SIGSEGV]
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
pabigot has quit [Ping timeout: 246 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian has quit [Killed (NickServ (GHOST command used by florian_kc!~florian@dynamic-002-244-182-046.2.244.pool.telefonica.de))]
florian_kc is now known as florian
florian_kc has joined #yocto
vladest has quit [Ping timeout: 252 seconds]
pabigot has joined #yocto
mvlad has quit [Remote host closed the connection]
kevinrowland has joined #yocto
kevinrowland has quit [Quit: Client closed]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RP>
vvn: not that many people build multiple distros in parallel and if they do, it is easy to change...
<RP>
vvn: people do find deep paths problematic
<fray>
I've done it and used to do it fairly regularly. The key was to have a distribution 'tmpdir' (which is generally required for multilibs anyway)
florian has quit [Ping timeout: 272 seconds]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 272 seconds]
nemik has joined #yocto
cavejohnson has joined #yocto
Kubu_work has quit [Quit: Leaving.]
Canary has quit [Quit: leaving]
paulg has quit [Read error: Connection reset by peer]
zwelch_ has joined #yocto
zwelch has quit [Read error: Connection reset by peer]
Minvera has quit [Ping timeout: 272 seconds]
florian has joined #yocto
cavejohnson has quit [Ping timeout: 272 seconds]
<RP>
JPEW: thanks! patches in testing...
paulg has joined #yocto
<RP>
vvn: I sometimes have done ${TOPDIR}/tmp-${DISTRO} too
amitk has quit [Ping timeout: 245 seconds]
kscherer has quit [Quit: Konversation terminated!]