berton has quit [Quit: Connection closed for inactivity]
lexano has quit [Ping timeout: 268 seconds]
davidinux2 has quit [Ping timeout: 256 seconds]
davidinux2 has joined #yocto
Xagen has joined #yocto
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
hnez has quit [Server closed connection]
aardo has quit [Server closed connection]
ardo has joined #yocto
ecdhe has quit [Server closed connection]
ecdhe has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MrFrank has quit [Server closed connection]
MrFrank has joined #yocto
Minvera has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
jmd has joined #yocto
khimaros has quit [Server closed connection]
khimaros has joined #yocto
jmd has quit [Remote host closed the connection]
alessioigor has joined #yocto
leon-anavi has joined #yocto
Ad0 has quit [Ping timeout: 252 seconds]
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
adrianp has joined #yocto
Ad0 has joined #yocto
adrianp has quit [Ping timeout: 250 seconds]
goliath has joined #yocto
ddee has joined #yocto
CrazyGecko has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
rob_w has joined #yocto
alessioigor has quit [Remote host closed the connection]
ddee has quit [Quit: Client closed]
ehussain has joined #yocto
alperak has joined #yocto
frieder has joined #yocto
mcfrisk has quit [Server closed connection]
mcfrisk has joined #yocto
mckoan|away is now known as mckoan
grma has joined #yocto
Kubu_work has joined #yocto
zpfvo has joined #yocto
ahussain has joined #yocto
ehussain has quit [Ping timeout: 268 seconds]
ahussain is now known as ehussain
alessioigor has joined #yocto
enok has joined #yocto
mvlad has joined #yocto
alessioigor has quit [Remote host closed the connection]
mbulut has joined #yocto
alessioigor has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
enok71 is now known as enok
berton has joined #yocto
ray-san2 has quit [Remote host closed the connection]
ray-san2 has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
alessioigor has quit [Remote host closed the connection]
enok has quit [Ping timeout: 256 seconds]
azuriel has joined #yocto
<azuriel>
hi, my yocto project uses the last kirkstone-4.0.19 and I wanted to "bbappend" the openssh recipe in order to apply the last CVE-2024-6387 patch that will be released in a few days through kirkstone-4.0.20, so I added "SRC_URI += " file://CVE-2024-6387.patch" in my openssh_%.bbappend but it seems that patch is not applied. Did I miss something?
enok has joined #yocto
<RP>
azuriel: the approach sounds basically correct. Did you check what SRC_URI looks like with bitbake -e openssh ?
_lore_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Daanct12 has joined #yocto
_lore_ has joined #yocto
_lore_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
_lore_ has joined #yocto
rfuentess has quit [Remote host closed the connection]
<azuriel>
RP: my bad, I think my problem is I presumed the patch is not applied, but I'm not sure anymore, thank you for your help!
<rburton>
azuriel: the log.do_patch will tell you exactly what patches were applied
xmn has quit [Ping timeout: 256 seconds]
enok has quit [Ping timeout: 268 seconds]
azuriel has quit [Quit: Client closed]
ecdhe has quit [Ping timeout: 256 seconds]
alessioigor has joined #yocto
florian_kc has joined #yocto
alessioigor has quit [Remote host closed the connection]
ablu has quit [Read error: Connection reset by peer]
ablu has joined #yocto
alessioigor has joined #yocto
rfuentess has joined #yocto
Jones42 has joined #yocto
wak has quit [Server closed connection]
wak has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.3.4]
jmiehe has joined #yocto
azuriel has joined #yocto
lexano has joined #yocto
jmiehe has quit [Quit: jmiehe]
<kanavin_>
rburton, that apparmor thing is a facepalm, isn't it?
<kanavin_>
I left a comment trying to express that
<kanavin_>
disabiling networking in child processes is better for security, but let's not allow that!
<rburton>
the view of canonical is that user namespaces are exposing too much of the kernel to userspace
sotaoverride has quit [Killed (silver.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
<kanavin_>
I think we should just make bitbake print a pret-a-porter apparmor profile when it can't perform the operation and ask users to install it
<rburton>
there's a sysctl you can use too
sotaover1ide has joined #yocto
<kanavin_>
I don't know, when an elaborate and difficult-to-understand security system is altogether disabled, the outcome is less security :)
ehussain has quit [Remote host closed the connection]
ehussain has joined #yocto
Bardon_ has joined #yocto
Bardon has quit [Ping timeout: 272 seconds]
qorin has joined #yocto
azuriel has quit [Quit: Client closed]
<qorin>
hi all. do you know if it is possible to do a cve check on all the packages included in the image without having to build ?
<KanjiMonster>
qorin: yes; add 'INHERIT += "cve_check"' to your .conf, and then run 'bitbake --runall cve_check <your-image-recipename>'
<qorin>
thank you KanjiMonster !!!
<KanjiMonster>
though be aware that it looks like it will miss quite a few newer CVEs since quite a few recent CVEs seem to have no version attached in the database ("awaiting analysis")
<qorin>
will do! i am planning to have this cve check task as part of my nightly pipeline
ecdhe has joined #yocto
pivi has quit [Ping timeout: 268 seconds]
pivi has joined #yocto
MattWeb has joined #yocto
jmiehe has joined #yocto
Minvera has joined #yocto
shoragan has quit [Quit: quit]
shoragan has joined #yocto
ehussain has quit [Ping timeout: 260 seconds]
jmiehe has quit [Quit: jmiehe]
ehussain has joined #yocto
ehussain has quit [Read error: Connection reset by peer]
ehussain has joined #yocto
<JPEW>
RP: Ok, I'll look
rob_w has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 246 seconds]
azuriel has joined #yocto
<tgamblin>
While trying to upgrade python3-pytest-subtests to 0.13.0 I've noticed that the unpack directory seems to be 'tmp/work/core2-64-poky-linux/python3-pytest-subtests/0.13.0/sources-unpack/pytest_subtests-0.13.0/'. I don't see 'sources-unpack' documented anywhere or on the list. Is there somewhere specific I should look for an example?
<tgamblin>
My upgrade is failing because it's looking for the LICENSE in tmp/work/core2-64-poky-linux/python3-pytest-subtests/0.13.0/pytest-subtests-0.13.0/LICENSE, but I see it at tmp/work/core2-64-poky-linux/python3-pytest-subtests/0.13.0/sources-unpack/pytest_subtests-0.13.0/LICENSE
ehussain has quit [Quit: ehussain]
enok has joined #yocto
<azuriel>
passing from kirkstone 4.0.12 to kirkstone 4.0.19, sudo does not behave exactly like before: when before I could execute a symbolic link to a binary I whitelisted (for instance "user ALL=(userb) NOPASSWD: /home/userc/bin/executable-file"), now I need to add this symbolic link too in my sudo whitelist. Is it ring a bell for someone?
CrazyGecko has quit [Quit: Konversation terminated!]
<rburton>
tgamblin: thats probably the _ vs - confusing bitbake's attempt at pretending nothing changed
ecdhe has joined #yocto
rfuentess has quit [Remote host closed the connection]
azuriel has quit [Quit: Client closed]
xmn has joined #yocto
alessioigor has quit [Remote host closed the connection]
leon-anavi has quit [Remote host closed the connection]
jmiehe has joined #yocto
alessioigor has joined #yocto
<tgamblin>
rburton: pytest-subtests has changed from - to _ in the tarball name on the latest release. I've been trying to work around that with the upgrade, which is what led to this issue
<tgamblin>
I set PYPI_SRC_URI with the downloadfilename qualifier so that it'd pick up the tarball correctly, but then it can't find LICENSE
<rburton>
i'll add that to my list of known annoying pypi packages because i have a wip branch to refactor the fetching bits
<rburton>
set the pypi_package to have the _?
<rburton>
(and remove other workarounds)
<tgamblin>
rburton: will try once my server's back up :)
mbulut has joined #yocto
mckoan is now known as mckoan|away
qorin has quit [Quit: Client closed]
<tgamblin>
rburton: that is certainly a simpler fix than what I was doing, thanks
<reatmon_>
If I have an http file in the SRC_URI and the file changes on the server, how do I get bitbake to redownload it and not go with the file in the download cache? Is changing the md5sum for the file enough? or do I need to manually remove the file from the download cache?
alessioigor has quit [Remote host closed the connection]
azuriel has joined #yocto
Guest42 has joined #yocto
Guest42 has quit [Client Quit]
ramacassis has joined #yocto
tangofoxtrot has quit [Server closed connection]
azuriel has quit [Quit: Client closed]
goliath has joined #yocto
<RP>
JPEW: I now see what you mean about the targets list and agree we can add the other tasks. What we didn't touch on is the arm failures above the x86 ones, there are a lot more of those
<RP>
JPEW: I think those are hashequiv issues
tangofoxtrot has joined #yocto
<rburton>
tgamblin: pypi and - vs _ is "fun"
<tgamblin>
rburton: Yeah. I could swear I had done some work related to that in the past, but maybe I'm just dreaming...
jmd has joined #yocto
tgamblin has quit [Ping timeout: 264 seconds]
jmiehe has quit [Quit: jmiehe]
Kubu_work has quit [Ping timeout: 252 seconds]
ramacassis has quit [Ping timeout: 250 seconds]
Kubu_work has joined #yocto
zpfvo has quit [Remote host closed the connection]
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
Kubu_work has quit [Ping timeout: 256 seconds]
Kubu_work has joined #yocto
tgamblin has joined #yocto
Saur_Home81 has quit [Quit: Client closed]
Saur_Home81 has joined #yocto
<yocton>
reatmon_: changing the hash should be enough, you should even see a warning about bitbake redownloading the file
frieder has quit [Remote host closed the connection]
locutusofborg_ has quit [Ping timeout: 264 seconds]
LocutusOfBorg has quit [Ping timeout: 264 seconds]
mbulut has quit [Quit: Leaving]
alessioigor has joined #yocto
berton has quit [Quit: Connection closed for inactivity]
alessioigor has quit [Remote host closed the connection]
<fray>
I hit an issue with Scarthgap, figured I'd ask here before going to the mailing list... I've got a multilib recipe (libgcc), that is failing in do_create_spdx, it's trying to hash a directory. I can fix this by changing the check from '.exists()' to isfile(...).. but I'm wondering if something else is broken by allowing the directory in the list of files
<fray>
the issue is it checks for 'exists', but then right after it tries to hash the file.. which is a directory
brrm has quit [Excess Flood]
brrm has joined #yocto
<rburton>
JPEW: ^
* JPEW
looks
<JPEW>
fray: Why is there a directory in your debug source?
<JPEW>
That's.... bizzare to say the least :)
<fray>
tehre is a series of directories.. I'm trying to understand if that's ok or not
<JPEW>
I don't think it makes sense because what would a debugger do with a directory for the "source" of a file?
<JPEW>
(Not that SPDX shouldn't be a little more graceful here, but I think your debug info might also be borked?)
<fray>
going into the loop, the value of 'debugsrc' is '/usr/src/debug/libilp32-gcc/13.3.0/libgcc', so the generated debugsrc_path becomes: <tmpdir>/work/cortexa72-cortexa53-ilp32-xilinxmllibilp32-libgcc/13.3.0/package/usr/src/debug/...
<fray>
I can't find where that is being added to the list BTW
<fray>
since it must be coming in via the oe.packagedata.read_subpkgdata_extended, I can't find it in the files (maybe I'm not looking at the right ones?)
<fray>
looking at the generated RPM package, there are DEFINITELY directories listed there, but they're listed so attriburtes can be defined properly.. but that isn't the raw data.. I'm not sure what I'm looking at here
<JPEW>
IIRC they are the .json.zst files, but they are just the output of... objdump listing the debug sources I think
<JPEW>
Maybe objdump(?) is listing things we don't actually care about
<fray>
I 100% bet it is
<fray>
OK, looking the first entry in libilp32-libgcc-dev for debugsrc IS the directory
<JPEW>
Weird
<fray>
I've not changed the toolchain at all.. this is a baremetal build though so it's NOT Linux
<fray>
(newlib)
alperak has quit [Quit: Connection closed for inactivity]
Jones42 has quit [Ping timeout: 272 seconds]
<fray>
JPEW well in the emit function I see nothing verifying the path exists or is a file..
<fray>
wait it does a stat.. so means it has to exist.. but doesn't check the type
<fray>
ok, hcecking the output of dwarfsrcfiles the directory is DEFINITELY in the output
<fray>
trying to track it down
<fray>
coming from the generated 'libgcc.a'
<fray>
JPEW, I'm sufficiently convinced that the check for exists needs to move to isfile in create-spdx.. I'll finish testing and send up patch(es)
<JPEW>
fray: Fair enough
<fray>
guessing this is an artifact of something to do with baremetal (not sure what, but something)
<fray>
also his a problem with aarch64-ilp32, but that can be worked around easily enough (since there is no standard ilp32 config in the arches)
<JPEW>
Ya fair.... maybe it makes sense, but I can't see how a directory in the debug source info is actually useful in practice
<fray>
shrug, no idea.. but gcc put it there and I'm not modifying that code in anyw ay
mvlad has quit [Remote host closed the connection]
alessioigor has joined #yocto
geoffhp has joined #yocto
dmoseley has joined #yocto
<vvn>
can you have concurrent builds in the same TOPDIR *if* TMPDIR is different?
<fray>
yes
<fray>
that is how multiconfigs work
<vvn>
wonderful then, thank you
<vvn>
fray: even between different versions of yocto though?
<vvn>
thinking about that bitbake lock, buildhistory, etc.
<RP>
vvn: no, you can't in general. Only with multiconfig
<vvn>
ok, better stay with a different BDIR per build then.
goliath has quit [Quit: SIGSEGV]
sakman has joined #yocto
<vvn>
RP: what about reusing the same BDIR in sequential builds? Would that work or should it be cleared first?
<denix>
JPEW: is Pyrex still being actively supported/maintained? If so, any plans to add Ubuntu 24.04 LTS?
<JPEW>
Ya, it is, and yes I will
<denix>
thanks!
<fray>
JPEW another issue, I'm getting failures due to missing sstate with the mlib..
<fray>
(need to hop back into the VPN to capture it for you) I know RP said there was some seding or whatever on the sstate name, and I think that's triggering the problem
mbulut has joined #yocto
<fray>
ERROR: meta-xilinx-toolchain-1.0-r0 do_populate_sdk: 1. No SPDX file found for package libilp32-libgcc-dbg, False sstate:libilp32-libgcc:cortexa72-cortexa53-ilp32-xilinxmllibilp32-elf:13.3.0:r0:cortexa72-cortexa53-ilp32:12: sstate:libilp32-libgcc::13.3.0:r0::12:
<RP>
vvn: reusing a BDIR happens all the time and is fine
<fray>
Any suggestion on where I can look to try to figure the above out?
<fray>
(the 1. I added to figure out where the message was coming from, it's the first place in the create-spdx-2.2 where 'No SPDX file found for package...' is
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
<fray>
I think there is a bug, it doesn't seem to be processing the mlib arch
Minvera has quit [Ping timeout: 264 seconds]
<fray>
definitely a bug.. "pkgarch" and "SSTATE_PKGARCH" are not the same in a mlib configuration
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alessioigor has quit [Remote host closed the connection]
kanavin_ has quit [Server closed connection]
kanavin_ has joined #yocto
<MattWeb>
Who would be the right person to ask about multi config performance issues when you have a lot of image configs?
<fray>
each multiconfig will cause 'another' system to be created, so the more recipes (layers), more multiconfigs and the number of available recipes to parse continues to increase..
<fray>
In my configuration I can do 3 relatively fine, but start going beyond 3 and parse time gets excessive. We've looked into this in the past and there wasn't that much that could be done
<MattWeb>
Any suggestions on alternatives? We see the same thing
<fray>
I break the builds up
<fray>
configure 3-5 multiconfigs and build, clear my config add a different 3-5.. repeat for my combinations
<fray>
to be clear, build time is roughly the same or better.. but parse time is where it gets to be a problem..
<fray>
and you only need multiconfigs if the machine, or distro changes. You don't need it just to choose a different image.. (or chnge IMAGE_FEATURES) that can done other ways
<MattWeb>
Noted. I'll pass that on to a couple others on my team
<RP>
MattWeb: is the timing scaling linearly or not? Parsing should scale linearly. The task graph computations are potentially trickier though
<fray>
We noticed that after a few it seems more exponential (non scientific opinion)
<fray>
At one point (distant past) it seemed to be creating multiconfigs of multiconfigs.. but I've not even looked to see if it's doing that anymroe
<RP>
fray: that does need investigation then
<fray>
Again, distant past, maybe even before langdale, what I saw when looking at something was: mc:foo:bar and mc:foo_foo:bar (or something like that) I forget exactly.. It was like the multilib problem that they can end up nesting
<fray>
again, this was a LONG time ago (at least 2 years), so take what I'm saying with a heavy grain of salt
<fray>
ok, I have a maybe working version
<fray>
package.bbclass I added a 'ALL_MULTILIB_SSTATE_ARCHS' (like the PACKAGE_ARCHS), and then moved the create-spdx-2.2.bbclass to use it, and it's working
<fray>
tomorrow I'll work to port it into master and submit it for more formal review. since I'm on scarthgap