mihai has quit [Read error: Connection reset by peer]
xmn has quit [Read error: Connection reset by peer]
Vonter has joined #yocto
xmn has joined #yocto
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
marex has quit [Ping timeout: 246 seconds]
prabhakarlad has joined #yocto
marex has joined #yocto
enok has joined #yocto
rbox has quit [Ping timeout: 255 seconds]
rbox has joined #yocto
rbox has quit [Client Quit]
enok has quit [Ping timeout: 240 seconds]
rbox has joined #yocto
kanavin_ has quit [Quit: Leaving]
xmn has quit [Ping timeout: 260 seconds]
jmd has joined #yocto
enok has joined #yocto
leon-anavi has joined #yocto
vthor has quit [Ping timeout: 260 seconds]
ablu has quit [Read error: Connection reset by peer]
enok has quit [Ping timeout: 240 seconds]
ablu has joined #yocto
Kubu_work has joined #yocto
florian_kc has joined #yocto
mckoan|away is now known as mckoan
enok has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
altru has joined #yocto
florian_kc has joined #yocto
florian_kc has quit [Ping timeout: 255 seconds]
mvlad has joined #yocto
<qschulz>
tlwoerner: I for sure can work on rebasing :)
florian has joined #yocto
<qschulz>
tlwoerner: are you interested in backporting it to scarthgap too?
<kilobyte_ch>
Ok, I have debugged my gitsm:// issue further. I think I know the issue now. The commit hash of the submodule is not present in any branch. Thus it fails to check it out. But the commit is present on the git server. Is there a way to tell Yocto that it should clone the whole Git Repository (and whole Git Repository of the submodule) before checkout?
<kilobyte_ch>
This is the issue on git level. I let yocto clone the submodule repo. When tinkering with it manually I can checkout branches which are contained in a branch, but can't checkout ones NOT contained in a branch: https://paste.debian.net/1318686/
<RP>
kilobyte_ch: there is a fetcher option to disable the branch checks iirc
<JaMa>
nobranch
<RP>
busybox as a project looks a little worrying :/
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<zeddii>
Hmm. I did build it. let me see if i did arm64 in that test
xmn has joined #yocto
mvlad_ has joined #yocto
mvlad has quit [Read error: Connection reset by peer]
mvlad has joined #yocto
RyanEatmon has quit [Quit: Client closed]
mvlad_ has quit [Ping timeout: 255 seconds]
mvlad_ has joined #yocto
mvlad has quit [Ping timeout: 255 seconds]
mvlad has joined #yocto
mvlad_ has quit [Ping timeout: 260 seconds]
mihai has joined #yocto
Dracos-Carazza_ is now known as Dracos-Carazza
mrybczyn has joined #yocto
<mrybczyn>
RP the VEX work is coming today. Three patches for oe-core just went out, I'll be sending a message with an overview and a link to the repo for the tool shortly
<mrybczyn>
RP RFC of course, there are a few things to sort out still, but my questions will be easier to ask when people can see the code :)
<RP>
mrybczyn: sounds great, definitely the right thing to do!
simonew has joined #yocto
leon-anavi has quit [Quit: Leaving]
<RP>
mrybczyn: did you have some questions to ask based on the patches?
<mrybczyn>
RP yes but I'm typing the "cover letter" :)
<RP>
mrybczyn: fair enough, I just had a read of the patches and wondered :)
<RP>
mrybczyn: patch 3 can probably just merge?
<mrybczyn>
RP you're a fast reader then :)
<RP>
mrybczyn: I read a lot of patches!
florian_kc has joined #yocto
<mrybczyn>
RP We have an issue with the kernel CVEs, we will merge when it is confirmed that this patch isn't part of the cause
<mrybczyn>
RP the kernel CVEs from the new CNA are a nice test case...
<mrybczyn>
RP but they parse really well
<RP>
mrybczyn: parsing well is cool. I feel I don't have enough info on the rest to comment yet!"
<qschulz>
modify the FILES for the mali-csffw-license to try to add LICENSE instead of LICENCE (S instead of C)
<qschulz>
the former doesn't exist, the latter does
<qschulz>
so now, the -license package should basically be empty
<qschulz>
first... I don't think ALLOW_EMPTY is set anywhere for that package, so I don't see any warning about an empty package
<qschulz>
second, I have -arch108 RDEPENDS on -license
<qschulz>
if I IMAGE_INSTALL the -arch108 package, the build passes but the packages aren't actually installed
simonew has quit [Ping timeout: 272 seconds]
<qschulz>
well the content of -arch108 package is for sure not in the image
GNUmoon2 has quit [Remote host closed the connection]
alessioigor has quit [Quit: Client closed]
GNUmoon2 has joined #yocto
simonew has joined #yocto
mihai has quit [Quit: Leaving]
florian_kc has joined #yocto
<RP>
zeddii: second autobuilder confirmed there is some arm/arm64 gcc 14 looking glitch left
mihai has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
<RyanEatmon>
RP Do you just want the update for the migration guide? or the changes for the classes.rst and variables.rst as well?
<RP>
RyanEatmon: both if they make sense please. The migration guide can point at the main docs if it makes sense to
mckoan is now known as mckoan|away
mihai has left #yocto [Leaving]
mihai has joined #yocto
<halstead>
RP: I'm just getting started. I can try looking up historic load levels and enable them if it's not already tracked.
mihai has quit [Client Quit]
mihai has joined #yocto
michaelo has joined #yocto
<RP>
halstead: thanks, I just wanted to mentioned it as it happened just in case. Still not sure why we ran into that then :/
<zeddii>
RP: I just pushed something to master-next for Xen.
<JaMa>
zeddii: why is a fix for gcc-14 OE specific? :)
<zeddii>
because it shut up the QA warning
<zeddii>
hehe
<zeddii>
and I have zero intent to send it upstream.
<JaMa>
I would use Pending in such case (to avoid needing to distinguish the really Inappropriate from others) :)
<zeddii>
that's fair. I can tweak it to that.
<JaMa>
not just because of me
<zeddii>
naw. it'
<zeddii>
it's good feedback. I Was just doing it quickly and should have searched more for a better state
<JaMa>
we should add TooLazyRightNow state :)
<zeddii>
+1 !
Kubu_work has quit [Quit: Leaving.]
<JaMa>
to distinguish upstreamable .patch files which are good adapts for good samaritan janitor to send them upstream
<JaMa>
adepts
* zeddii
tweaked it to this:
<zeddii>
Upstream-Status: Pending [the xen folks understand the code and the right fix .. I don't]
<RP>
khem: libtool upgrade to 2.5.0 test patch in master-next
<RP>
we got a few patches merged which is nice
<JaMa>
hehe, that's how I often feel and then the horor when I realize that my temporary fix is better than what our developers came with internally :)
<zeddii>
:) imposter syndrom is real
<khem>
RP: I hope its not a train wreck for packages
<RP>
khem: you might want to try and sort out the 0008 clang patch with upstream libtool
<JaMa>
icu, boost, gstreamer update in the same "batch" of updates already made enough work for next weekend :)
<khem>
RP: I see that your master-next branch is carry a patch to gcc for supporting libc++, that looks good to me btw.
<RP>
khem: I'm nervous about that one
<RP>
I did merge the new libc-headers and kernel updates
<khem>
JaMa, zeddii : this is GCC's static analyser in action, its finding a real bug there, passing a negative array index, so the parent function should be checked IMO, returning 0th element for all negative array indices might get by the static analyser but bug still might manifest
<zeddii>
yah, that's what my commit message said :)
<zeddii>
but it's not a bug I'm going to fix, I mentioned it to the AMD xen folks, but I'm not in the business of fixing xen or being able to test that.
enok has quit [Read error: Connection reset by peer]
enok has joined #yocto
Saur_Home34 has quit [Ping timeout: 250 seconds]
sugarbeet has quit [Read error: Connection reset by peer]
enok has quit [Ping timeout: 240 seconds]
<RP>
khem: were those performance issues resolved btw? I added an attempted fix at that profiling traceback
<halstead>
JPEW: there's no indication in resource graphs that the hashserv was overloaded in the last 12 hours. I'm checking logs next.
florian_kc has joined #yocto
enok has joined #yocto
sugarbeet has joined #yocto
Saur_Home46 has joined #yocto
enok has quit [Quit: enok]
enok71 has joined #yocto
Saur_Home66 has quit [Ping timeout: 250 seconds]
enok71 is now known as enok
florian_kc has quit [Ping timeout: 268 seconds]
vvn has quit [Read error: Connection reset by peer]
v0n has joined #yocto
<JPEW>
RP, halstead: Those errors are all where the connection gets established, so it would _seem_ to be some sort of infrastructure related problem; either the server is too busy to handle the requests, or something along the way is silently rejecting the connection
<JPEW>
Let me see what the timeout for the connection is
simonew has quit [Ping timeout: 264 seconds]
<JPEW>
It's 10 seconds. Looks like TCP has no timeout at all (other than the natural timeout for establishing a connection, which is usually pretty long IIRC).
GNUmoon2 has quit [Ping timeout: 260 seconds]
GNUmoon2 has joined #yocto
RyanEatmon has quit [Quit: Client closed]
<halstead>
JPEW: I don't see the issue at this log level. Probably hitting a connection limit on the reverse proxy
<JPEW>
halstead: That was my guess. Does the reverse proxy do the TLS termination also?
<halstead>
JPEW: yes. Right now it's nginx doing both.
f has joined #yocto
f has quit [Remote host closed the connection]
f has joined #yocto
<halstead>
There really is nothing weird in the logs at that time. A few scripted attacked before and after but nothing that should have caused timeouts.
florian_kc has joined #yocto
f has quit [K-Lined]
amitk_ has quit [Ping timeout: 256 seconds]
Kubu_work has joined #yocto
enok has quit [Ping timeout: 240 seconds]
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
jmd has quit [Remote host closed the connection]
<RP>
zeddii: green meta-virt with -next now :)
ecdhe has quit [Ping timeout: 264 seconds]
mvlad has quit [Remote host closed the connection]
ecdhe has joined #yocto
Kubu_work has quit [Quit: Leaving.]
ecdhe has quit [Read error: Connection reset by peer]