<Guest34>
Under "Compatible Linux Distribution" where requirements are stated, the second bullet states: "At least 8 Gbytes of RAM, though a modern modern build host with as much RAM and as many CPU cores as possible is strongly recommended to maximize build performance."
<Guest34>
There is a repeat of the word "modern" Thank you.
asgj-gomspace has joined #yocto
Guest34 has quit [Quit: Client closed]
<asgj-gomspace>
Hi, I've noticed that I've been getting timeouts on git.yoctoproject.org as well as git.openembedded.org this weekend and morning. I assume this is a side-effect of the recent increase in AI scraper bots that I've heard about? Does anyone know if this is being worked on, or if we're just trying to "ride out" the DDOS wave?
alessio has joined #yocto
OnkelUlla has quit [Remote host closed the connection]
mckoan_ is now known as mckoan
enok has joined #yocto
Kubu_work has joined #yocto
rfuentess has joined #yocto
dgriego has quit [Ping timeout: 246 seconds]
OnkelUlla has joined #yocto
dgriego has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
savolla has joined #yocto
dgriego has quit [Ping timeout: 252 seconds]
yannd has quit [Remote host closed the connection]
frieder has joined #yocto
dgriego has joined #yocto
enok has quit [Ping timeout: 252 seconds]
micka has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<Guest74>
asgj-gomspace hi, we are noticing the same behavior.. you mentioned `recent increase in AI scraper bots`, what is that, is there some place I could read about it?
<sudip_>
same with, getting timeouts regularly now :(
<sudip_>
s/same with/same with me/
ericksonu has quit [Ping timeout: 244 seconds]
ad__ has quit [Quit: ZNC 1.9.0+deb2+b1 - https://znc.in]
ad__ has joined #yocto
<asgj-gomspace>
I got through (at least once) now. We have switched to the github mirror for the time being though.
Tyaku has joined #yocto
kanavin_ has quit [Remote host closed the connection]
kanavin has joined #yocto
<CrazyGecko>
foss should reverse it, that the crawlers need to mine some BTC to access the page. This would then sponsor foss with the computer power of these crawlers 😅
<Tyaku>
Hello, I'm going to ask here, I don't know where to ask, it's about DTS/SDIO.
<Tyaku>
We have a board with ESP32C6 acting as WiFi ship using SDIO. Currently the WiFi is working, only on startup. If the module restart (crash, software update) then we have to reboot the board to make it working again. I have identified (according to SDIO specifications) that when a SDIO device receive, it can only accept CMD0 and CMD5 and should discard other commands. These commands are only sent when the
<Tyaku>
kernel is booting. But I think it is related to 'non-removable' in dts. But If i remove 'non-removable' (and keep 'broken-cd') it simply wont start the SDIO on kerne boot or after (no clock).
<Tyaku>
Did someone have this kind of experience with SDIO low level drivers ?
<mcfrisk>
recipes-foo/bar/files is no longer in patch file search paths, and the searched paths include machine etc. How to get "files" back to the search dirs, when patch is not at all machine specific?
<rburton>
kanavin: did you see that LWN were approached by a company that does the selling of residential IPs for scans thing? brightdata.com
<rburton>
mcfrisk: why do you think it is no longer in the search path?
<mcfrisk>
because meta-arm/recipes-bsp/uefi/files/edk2_fix_epoch.patch is not found by edk2-firmware recipe and it only looks for paths which include machine and distro
<mcfrisk>
I've seen this now on a few recipes and I don't think the fixes have been correct
<kanavin>
rburton, did lwn report that somewhere?
<rburton>
kanavin: corbet on mastodon
<kanavin>
rburton, yikes
<rburton>
yeah
<rburton>
proudly claiming WE HAVE 140M RESIDENTIAL IPS who absolutely signed up for this and didn't just blinding install some stupid plugin
<rburton>
ends with :/home/rosbur01/Yocto/meta-arm/meta-arm/recipes-bsp/uefi/files/" here
<Guest74>
rburton thanks, should github fork be consider as a more stable source?
eduter has joined #yocto
<mcfrisk>
rburton: odd, then I must have broken something
<rburton>
Guest74: its definitely a backup instead of a master, but you can fetch from there if the real one is down. luckily git lets you have multiple remotes in a single clone, so you can pull from both.
<paulg>
well thanks. "...the selling of residential IPs for scans..." -- making sure Monday sucks arse like it always does, and dwindling my faith in humanity.
<rburton>
yeah
<paulg>
Which really, I thought bottomed out long ago.
<rburton>
that same company tried to sell mitigation strategies to lwn for _their own services_
<rburton>
serverless infra, mob style
<mcfrisk>
rburton: edk2-firmware 202408 and 202411 from different paths and former is failing, must not modify common .inc then. my fault...
<rburton>
jon has been trying to upgrade to a 2025 release but every upgrade another platform breaks
<mcfrisk>
rburton: tell me about it.. I will try to provide some fixes..
zeemate has joined #yocto
grma has quit []
grma has joined #yocto
<rburton>
mcfrisk: poke jonmason for his WIP
grma has quit []
grma has joined #yocto
<mcfrisk>
rburton: ack, doing 202408 to 202411 update first to our machines
<rburton>
mcfrisk: so how does edk2-firmware build for me and everyone else if your patch fixes a compile failure
<mcfrisk>
rburton: I think it builds but not all configs use the path which trigger this
<rburton>
mcfrisk: not sure i want to carry a patch forever. maybe try convincing upstream to use echo or printf as they're posix not coreutils?
ssweeny has quit [Quit: Gateway shutdown]
ssweeny has joined #yocto
<dl9pf>
I see a 502 bad gateway from git.yoctoproject.org atm . Pinging IT .
<alessio>
Same here
<RP>
dl9pf: crawlers hit us in waves :(
<bradfa>
That's frustrating :(
<asgj-gomspace>
this is crazy. Is there really no way to mitigate these bots?
<bradfa>
asgj-gomspace: there's seemingly no inexpensive way to, currently
<asgj-gomspace>
perhaps if you must have created an account and an API key in order to access the more expensive endpoints?
<asgj-gomspace>
Not a fun "solution" I know. But they seem to be going nuclear
ablu has quit [Ping timeout: 260 seconds]
ablu has joined #yocto
rob_w has quit [Remote host closed the connection]
<dl9pf>
RP: yes, i see. thats bad . IT apparently on it already.
frieder has quit [Ping timeout: 244 seconds]
frieder has joined #yocto
frieder has quit [Ping timeout: 265 seconds]
eduter has quit [Quit: Client closed]
eduter has joined #yocto
eduter has quit [Ping timeout: 240 seconds]
pbiel has joined #yocto
frieder has joined #yocto
Guest74 has quit [Ping timeout: 240 seconds]
<RP>
I wonder if it is time to split qemu-system-native up :/
042ABBIPG is now known as vmeson
vThor has quit [Quit: kill -9 $pid]
Guest74 has joined #yocto
reatmon_ has quit [Remote host closed the connection]
reatmon_ has joined #yocto
goliath has quit [Quit: SIGSEGV]
pbiel has quit [Remote host closed the connection]
pbiel has joined #yocto
florian_kc has joined #yocto
<rburton>
RP: per-arch?
savolla has quit [Quit: WeeChat 4.4.3]
manny2 has joined #yocto
<RP>
rburton: yes
<rburton>
RP: for space or time saving?
<RP>
rburton: both
<rburton>
curious what the numbers would be. how much time is spent taken build each arch.
<rburton>
you could do fun things with bbclassextend to magically invent qemu-system-[arch] recipes though :)
<RP>
rburton: I was thinking of bbclassextend :)
<rburton>
i'd be curious in seeing a bit of analysis on how big each specific arch is, and how much compile time is common vs per-target-arch
enok has joined #yocto
MQueiros has joined #yocto
berton has joined #yocto
manny2 has quit [Quit: Client closed]
<mcfrisk>
is edk2 the worst open source project to make sense out of? sure feels like it...
manny81 has joined #yocto
<rburton>
yes
<rburton>
well, no, there's worse
<rburton>
but its on The List
<kanavin>
rburton, is the patch review meeting in 13 minutes, or in 1h + 13min?
<rburton>
kanavin: 1h13m
<kanavin>
>:-|
<kanavin>
we should enforce european time zones
<RP>
kanavin: most project meetings are US time zones
<rburton>
kanavin: that's the thursday call :)
<MQueiros>
Hi folks :)
<MQueiros>
I work in a project where we are adding a QA check error when a recipe uses both excluded and included licenses. For instance, using 'LICENSE = "CLOSED & MIT"' causes a recipe to deploy not only Open source code/licenses, but also Closed source code/licenses. Therefore, we believe that the recipe should be split by Closed/Open instead of deploying
frieder has quit [Remote host closed the connection]
<rburton>
MQueiros: yes, your recipe should absolutely not mix closed and open pieces. i think the recipe should be doing that, as how do you propose yocto know _exactly_ what files have what licenses?
MQueiros has quit [Quit: Client closed]
MQueiros has joined #yocto
<MQueiros>
In these scenarios, we are planning on blocking spdx/archiver for the recipe. So the recipe cannot deploy licenses/sources before fixing those licensing issues. The recipe maintainer would be responsible for fixing things
<rburton>
right
<rburton>
definitely what i'd do. big error, stop doing this, split the recipe up so you can distribute the open bits easily without accidentally shipping the closed bits
<MQueiros>
Glad we are on the same page :)
<MQueiros>
Back to the original question, do you believe it could be worth it to upstream this QA check?
<MQueiros>
The custom QA check we are using internally uses the declared license, COPYLEFT_LICENSE_INCLUDE, COPYLEFT_LICENSE_EXCLUDE and license::is_included() to detect the mix and block integration.
<rburton>
sure, could be, worth posting at least
zeemate has joined #yocto
<MQueiros>
Ok, then we'll create a patch soon-ish and propose it upstream. Thanks for the help! :)
goliath has joined #yocto
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
mckoan is now known as mckoan|away
<JPEW>
RP: Adding cve_check works, but it doesn't detect CVE_STATUS as a dependency still; probably because it's getVarFlags() ?
enok has quit [Ping timeout: 248 seconds]
vThor has joined #yocto
vThor has quit [Changing host]
vThor has joined #yocto
enok has joined #yocto
pbiel has quit [Remote host closed the connection]
pbiel has joined #yocto
enok has quit [Ping timeout: 260 seconds]
mrpelotazo has joined #yocto
rfuentess has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
mrpelotazo has quit [Quit: Hasta la vista!]
mrpelotazo has joined #yocto
<RP>
JPEW: that would make sense, it probably doesn't scan for that
<JPEW>
Does that need fixed in bitbake then?>
<JPEW>
`status = d.getVarFlag("CVE_STATUS", cve)`
MQueiros has quit [Quit: Client closed]
leon-anavi has quit [Quit: Leaving]
mrpelotazo has quit [Quit: Hasta la vista!]
mrpelotazo has joined #yocto
mrpelotazo has quit [Client Quit]
mrpelotazo has joined #yocto
mrpelotazo has quit [Client Quit]
vermaete has joined #yocto
<vermaete>
Should a new recipe in meta-openembedded/meta-python add a maintainer line in maintainers.inc of poko/core-oe?
mrpelotazo has joined #yocto
<vermaete>
WARNING: python3-exhale-0.3.7-r0 do_recipe_qa: QA Issue: Recipe python3-exhale in /srv/pokybuild/yocto-worker/a-full/build/meta/recipes-devtools/python/python3-exhale_0.3.7.bb does not have an assigned maintainer. Please add an entry into meta/conf/distro/include/maintainers.inc. [missing-maintainer]
<vermaete>
well, I first send the new recipe to openembedded-core. What was not the correct place. And later to meta-python.
<halstead>
Crofton: Yes. they are falling back over almost as soon as I bring them up.
<Crofton>
I assume this is the AI crawler issue?
Guest83 has joined #yocto
<halstead>
Crofton: Yes. They are quite persistent. I'm going to put the proof of work in there and see what breaks.
<Crofton>
hmm
<Crofton>
this is very annoying
<Crofton>
If only DOGE would do something useful and shut these clowns down
<JaMa>
isn't Grok one of them? :)
druppy has joined #yocto
druppy has quit [Remote host closed the connection]
Guest83 has quit [Quit: Client closed]
eduter has quit [Quit: Client closed]
druppy has joined #yocto
enok has joined #yocto
pidge_ has joined #yocto
pidge has quit [Ping timeout: 260 seconds]
savolla has joined #yocto
<JPEW>
RP: The top two commits on poky-contrib:jpew/var-flag-deps might be worth you looking at
<rburton>
halstead: is there a particular path in cgit which hurts more? i'd survive with blame being disabled for example
<JPEW>
"Depend on all varflags" might very well break many things, so I'd understand if we just decided to explicitly add the deps on varflag variables instead of doing it implicitly
<JPEW>
Which "Add functions to add and remove variable dependencies" would make a lot easier :)
pbiel has quit [Remote host closed the connection]
pbiel has joined #yocto
<halstead>
rburton: I'm not 100% sure which path. I think it's more the quantity of requests. Running the syntax highlighting on the performance and test reports eats a lot of CPU. Browsing those in general does.
<eduter>
halstead Sorry for highlighting the issue again. I can see another person already brought this up. Thanks
<halstead>
eduter: No problem. I'm going to take cgit offline for a bit so at least clones succeed.
<eduter>
(Y)
<eduter>
(y)
<rburton>
maybe someone with power should add to the topic that we know git is up and down
<rburton>
with a gofundme to buy coffee/muffins/beer for the LF infra team
Guest18 has quit [Quit: Client closed]
<Crofton>
YEAH
eduter has quit [Quit: Client closed]
<Crofton>
OOPS CAPS LOCK
olani- has joined #yocto
sakoman1 has quit [Ping timeout: 265 seconds]
Guest18 has joined #yocto
<halstead>
I've taken cgit offline on the mirrors and put up a notice on downloads.yoctoproject.org until I have better mitigation in place. Clones will still work.
vermaete has joined #yocto
sakoman has joined #yocto
enok has quit [Ping timeout: 245 seconds]
enok has joined #yocto
vermaete has quit [Quit: Client closed]
<tlwoerner>
thanks halstead that's much better :-)
pidge has joined #yocto
pidge_ has quit [Ping timeout: 245 seconds]
<RP>
JPEW: hmm. I did like the decorator idea a bit more than magic functions. It is a clever solution, but perhaps too clever? :/
<RP>
JPEW: I'd be interested to see how often that "all varflags" triggers on our metadata
<JPEW>
RP: Ya, I wasn't sure. It's a very simple solution which I liked. Decorators are a probably because we don't actually fully parse the function, so we'd have to extract the decorator out of the AST (which is possible but not as simple)
<JPEW>
s/Decorators are a probably/Decorators are a problem/
<JPEW>
RP: Not many. I think the breakage would be if there are places where layers add flags to vars, as that means the layers would affect the task hash (looking at SPDXLICENSEMAP specifically)
Kubu_work has quit [Quit: Leaving.]
<RP>
JPEW: arguably we should be accounting for that kind of issue...
<JPEW>
Ya, fair. I suppose we can exclude the problematic ones
<RP>
JPEW: I think I'd want to run some experiments and convince myself
<RP>
JPEW: I can see why you've used the functions for the dependencies. I'll think about it a bit...
<JPEW>
RP: np. Play around with them and let me know. I'll look and see if there's any relevant tests that can be updated for them also
enok has quit [Ping timeout: 245 seconds]
Kubu_work has joined #yocto
<RP>
JPEW: I suspect this is where I got stuck last time. I was picturing adding some kind of markup to the functions but couldn't find markup you could get in the AST
goliath has quit [Quit: SIGSEGV]
cyxae has quit [Quit: cyxae]
<JPEW>
RP: Other than decorators, I'm not sure if there would be anything else you could do
<RP>
JPEW: I'd also wondered about specific function names XXX_vardeps
<JPEW>
RP: mmm, it also doesn't look like we parse the `def ...` definition of the functions, just the body, which makes decorators even harder
<JPEW>
Oh, or maybe not because we have the actual function object there
<JPEW>
hang on....
berton has joined #yocto
berton has quit [Read error: Connection reset by peer]
enok has joined #yocto
berton has joined #yocto
berton has quit [Read error: Connection reset by peer]
enok has quit [Client Quit]
enok has joined #yocto
<RP>
JPEW: it is properly python code so it should be parsed
<RP>
I was wondering if we could just add a property to the function but I wasn't sure how python does that other than decorators
<JPEW>
RP: Right. I just didn't look far enough back from the AST parsing to realize that. That makes it *much* simpler to use decorators
berton has joined #yocto
<JPEW>
RP: Updated the contrib branch with the decorator version. I like that the best so far
<JPEW>
Maybe not in bb.utils, but the idea makes sense
Guest74 has joined #yocto
enok has quit [Quit: enok]
enok has joined #yocto
<RP>
JPEW: that does look better, agreed
<RP>
JPEW: not sure on utils or the naming but I think it is the nicer option
<RP>
JPEW: vardeps_add and vardeps_exclude ? Not sure
<JPEW>
RP: I was trying to match the flag names
druppy has quit [Ping timeout: 252 seconds]
<JPEW>
Heh, and failed completely, because it's `vardepsexclude` :)
berton has quit [Quit: Leaving]
<JPEW>
RP: K I dropped the dummy function version and pushed an improved decorator version
<RP>
JPEW: right, I'm trying to at least try and fix inconsistencies in these things early if I can spot them...
<JPEW>
Ya, extra eyes early is good. Much harder to change later
pbiel has quit [Remote host closed the connection]
florian has quit [Ping timeout: 272 seconds]
pbiel has joined #yocto
manny69 has quit [Ping timeout: 240 seconds]
florian has joined #yocto
<RP>
vmeson: I've run a new mater-next build on the perf workers which should hopefully get more accurate results
<RP>
vmeson: the disk improvements looked right though
florian has quit [Ping timeout: 260 seconds]
olani- has quit [Ping timeout: 260 seconds]
<khem>
halstead:can we redirect them to github.com mirror or poky ?