<KanjiMonster>
RP: CVE-2022-3533 -> the nist website reference a commit that was added to 6.2 and backported to 6.1 in 6.1.2 (the file does not exist in 5.15, didn't check further)
<KanjiMonster>
CVE-2022-3606 as well
zpfvo has quit [Ping timeout: 245 seconds]
JaMa has joined #yocto
leon-anavi has joined #yocto
zpfvo has joined #yocto
florian has joined #yocto
sudip_ is now known as sudip
xmn has quit [Quit: ZZZzzz…]
<kanavin>
RP: kea 2.5.0 update is incorrect
<kanavin>
can we revert quickly?
<RP>
kanavin: can you give me more of a reason?
<kanavin>
RP: 2.5.0 is a development release, 2.4.0 is stable.
<kanavin>
RP: thanks, this was noted in patch review, but somehow slipped through
<kanavin>
I'm urging people to always run 'devtool latest-version' first, as that is 100% accurate or close to it
<sudip>
sorry, it was my mistake, devtool showed 2.4.0 but I didn't see 2.5.0 was development version :(
<kanavin>
sudip, inherit upstream-version-is-even ensures that only even versions are considered
<kanavin>
per upstream policy
<sudip>
I will send the 2.4.0 patch now, but seems like upstream is going to reject the reproducible build problem issue :(
<kanavin>
sudip, it's a beginners mistake, no need to be sorry at all, and we sometimes make mistakes too, such as forgetting to drop patches like this from staging branches :)
<kanavin>
sudip, please include all the links to what upstream said
<kanavin>
if the patch is rejected, it's good to at least have a pointer to it
<sudip>
sure
<kanavin>
maybe they'll change their mind later, or we find more convincing arguments... it helps to have the history available
florian_kc has joined #yocto
<KanjiMonster>
sudip: I suggest replying why reproducability is important/wanted and/or throwing links at them that do (e.g. https://reproducible-builds.org/)
AndreRicardo has joined #yocto
<sudip>
KanjiMonster: yes, that is why I later pointed them to Debian and showed the same problem there.
<KanjiMonster>
sudip: you only showed that the build path leaked into the debian package, but AFAICT you didn't explain yet why this is an issue. "Why should the result be the same for multiple builds?" clearly shows they don't understand the problem
<sudip>
yeah, I will need to write that reply explaining as much as I can, after I am back from my $dayjob.
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<RP>
KanjiMonster: thanks for the cve hints btw, I'm hoping rburton will pick those up shortly :)
<KanjiMonster>
RP: there are probably more; everyone is quick to set stuff as vulnerable, but marking versions as fixed/not affected ... ;)
<RP>
KanjiMonster: I know :/
JerryM has joined #yocto
<JerryM>
hey folks can someone tell me when I use an upstream hashserve if that connection is read-only or if the local hashserver can write to the upstream hashserve too
<dvergatal>
moto-timo: thx it worked
<RP>
JerryM: it depends on the mode the hashserve is running in iirc
<dvergatal>
btw. does anyone know what for useradd.bbclass has base-files in its DEPENDS ?
<dvergatal>
ahhh I see for the skel
<dvergatal>
now I have another stupid problem that if I'm trying to add some ownership for e.g. /etc/motd in base-files bbappend I have this stupid circular dependency because useradd.bbclass DEPENDS on base-files
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #yocto
<rburton>
KanjiMonster: the script i posted uses linuxkernelcves for more data. I filed tickets for those issues but the fixed SHAs didn't get incorporated, so I'm filing new ones now
<KanjiMonster>
rburton: extended the two tickets with exact (un-)affected kernel versions
<rburton>
yeah just saying thanks
<rburton>
I believe/hope that service works via magic from following the SHAs and tags when given the right content
<KanjiMonster>
I ignored everything that's EOL (unless it was the version that contained the original fix), let ubuntu handle their weird version choices themselves
<rburton>
i've even occasionally managed to get NIST to copy the fixed version data into the CVE entry
florian has quit [Remote host closed the connection]
florian has joined #yocto
manuel1985 has joined #yocto
<__ad>
hi, need to solve this issue
<__ad>
no providrtes found for libQt5Charts.so.5
<__ad>
(i am in hardknott)
kpo has quit [Ping timeout: 245 seconds]
<JerryM>
RP ah thanks, I had hoped using an upstream it might be read-only as I could use that for developers that don't update the sstate cache and have them writable by the build machines that do fill sstate
Minvera has joined #yocto
<rburton>
__ad: you either didn't depend on qt, or your qt didn't build the charts library
florian_kc has quit [Ping timeout: 245 seconds]
xmn has joined #yocto
GillesM has joined #yocto
GillesMM has joined #yocto
GillesMM has quit [Remote host closed the connection]
xmn has quit [Quit: ZZZzzz…]
jclsn has quit [Quit: WeeChat 4.0.1]
xmn has joined #yocto
sakoman has joined #yocto
hummerbliss has joined #yocto
ray-san2 has quit [Ping timeout: 252 seconds]
<hummerbliss>
Hello, is there a way to force a recipe to not use host gcc for compiling host native binaries ? Can we force it to use the compiler shipped with yocto for compiling host native binaries
<RP>
JerryM: you can run two servers off one database to have a readonly and a write server
<RP>
rburton: really surprised it was you who added that and not me!
shebbar has quit [Remote host closed the connection]
sugarbeet has quit [Ping timeout: 245 seconds]
<rburton>
hummerbliss: we don't build a native compiler. if your host compiler is terrible then you can use the buildtools tarball we provide, which has a modern gcc in
sugarbeet has joined #yocto
goliath has quit [Quit: SIGSEGV]
<hummerbliss>
understood thanks rburton
<GillesM>
en fait j'avais tellement de sources d'ardour que je lançais la version /usr/local/bin/ardour5
<vvn>
I'm trying to build an app with tensorflow-lite, the configure log shows that it is user-enabled, but meson doesn't detect the dependency, even though I do have .../recipe-sysroot/usr/lib/libtensorflowlite.so
<vvn>
Any idea what could be the cause of such error?
JerryM has quit [Read error: Connection reset by peer]
<rburton>
vvn: is it meant to be looking for a .pc file or something?
<rburton>
meson write a fairly verbose log file in ${B} fwiw
amitk_ has joined #yocto
<JerryM>
RP: I will have to try that thanks for the suggestion
<vvn>
found meson-log.txt
leon-anavi has quit [Quit: Leaving]
vvmeson has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
Minvera has quit [Ping timeout: 246 seconds]
<vvn>
rburton: so meson-log.txt indeed says that pkg-config --modversion tensorflow-lite returns 1 and Perhaps you should add the directory containing `tensorflow-lite.pc'. I've added 'inherit pkgconfig' to the tensorflow-lite recipe, but I have the same thing, no tensorflow-lite.pc file seem to be produced
<rburton>
you need that inherit in the recipe looking for tensorflow but if it tried that then it must have it already
<rburton>
i've no idea if tensorflow is meant to produce a .pc or not
<rburton>
iirc meson can also use cmake files, so maybe tensorflow should be shipping those?
<yates_work>
my goal is to create a recipe that will build my qt app for an armv7 target.
<yates_work>
that's not quite complete: i want to create a recipe that will build a statically-linked qt app. i.e. (from what i know of qt), qt has to first be built as static