<pgwipeout[m]>
Huh, that's the first time I've seen one of those. I've always used extlinux or grub.
<alyssa>
"check kernel and dtb images" goran
<alyssa>
I think it should be booti actually
stikonas has quit [Read error: Connection reset by peer]
<pgwipeout[m]>
That's arm32?
<alyssa>
arm64
<pgwipeout[m]>
Oh. Uh uboot doesn't like compressed arm64 kernels generally. Something they just started working on.
<alyssa>
so no precompiled debian kernel for me? :-(
<pgwipeout[m]>
Afaik grub or efi is the only arm64 service that can cope. It's up to the bootloader to decompress it and U-Boot doesn't support that
<alyssa>
sigh
<alyssa>
Guess I'll build a kernel myself tomorrow. Boo :(
<pgwipeout[m]>
You could decompress it yourself.
hipboi has joined #linux-rockchip
<pgwipeout[m]>
Then pass the decompressed kernel to u-boot.
<alyssa>
worth a try 🤷
<pgwipeout[m]>
When I was digging into this a few days ago someone suggested scripting it and hooking into the install scripts.
hipboi has quit [Ping timeout: 268 seconds]
<pgwipeout[m]>
I'm still waiting for ubuntu to support compressed modules correctly.
hipboi has joined #linux-rockchip
kevery has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
<pgwipeout[m]>
Good evening Kevery, or good morning I believe for you.
hipboi has joined #linux-rockchip
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
hipboi has joined #linux-rockchip
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
kevery has quit [Ping timeout: 268 seconds]
kevery has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
kevery1 has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
kevery has quit [Ping timeout: 268 seconds]
kevery1 is now known as kevery
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 245 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 245 seconds]
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
kevery1 has joined #linux-rockchip
hipboi has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
hipboi has quit [Ping timeout: 248 seconds]
alpernebbi has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 248 seconds]
kevery1 is now known as kevery
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
archetyp has joined #linux-rockchip
hipboi has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
stikonas has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
alpernebbi has quit [Ping timeout: 258 seconds]
hipboi has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
hipboi has quit [Ping timeout: 258 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-rockchip
kevery has quit [Quit: kevery]
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 268 seconds]
hipboi has joined #linux-rockchip
<CounterPillow>
Should I wait for more feedback before sending a V2 of a patchset? I don't wanna be too spammy with my submissions
hipboi has quit [Ping timeout: 240 seconds]
<robmur01>
FWIW, I'd say unless you're changing so much that it's not worth people spending time looking at the previous version at all, or it's already well-reviewed and you're just making final tweaks to be merge-ready, then I'd typically suggest waiting at least a week between postings
<CounterPillow>
Alright, noted.
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
cp- has joined #linux-rockchip
hipboi has joined #linux-rockchip
Rathann has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
<alyssa>
robmur01: where is this documented? it just bit me. and this seems like a great way to bite newcomers frmo the github/lab world where you repush to an MR as soon as you address feedback
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 248 seconds]
<robmur01>
alyssa: My opinions are not formally documented anywhere :P It's far from a universal rule, just my experience with the particular subsystems and maintainers I've worked with over the years, and consequently it's the kind of cadence I've grown to prefer as a reviewer
<robmur01>
I believe netdev moves a lot faster, for example
<robmur01>
if I get sent 3 versions of a series in as many days, it purposely gets ignored for at *least* another week ;)
<alyssa>
But... why?
<mmind00>
alyssa: I guess generally you want to collect as much review from different people as possible per version, so if there is essentially one version for each review from A,B,C [over said 3+ days as people tend to not review patches when they hit their inbox ;-) ] it overloads people over said 3 days, it will overload peoples review capacity
<robmur01>
I've even had people send a new version in response to part of a review I'm in the middle of, before I've even got to the end of the series - that's super-annoying
<mmind00>
that last part should've just been "... it overloads peoples review capacity"
<alyssa>
again, how is this different from github/lab where you just repush as much as you want so people aren't looking at stale code?
hipboi has joined #linux-rockchip
<CounterPillow>
people look grumpily at their unread email inbox counter, I guess
<robmur01>
because when you have several different threads in your inbox all mixed up because other people's reviews have overlapped, there's a fair chance you *do* end up looking at stale code
hipboi has quit [Ping timeout: 252 seconds]
<robmur01>
versioning is one thing the email patch review process is the worst at
<alyssa>
definitely a huge point for gitlab imho
<robmur01>
if I need to spend half a day or more paging in context to properly review something, I'd rather have some confidence that that review isn't already going to be out-of-date by the time I've finished it
<robmur01>
plus experience has shown a fair correlation between patches which get respun really quickly and patches where the details haven't been well thought-through
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<robmur01>
I can think of some things which got to around v5 or v6 respinning for trivial comments before I've looked and pointed out something fundamentally wrong
<robmur01>
but at a glance, if something has reached v6 with apparent active review, as a maintainer or reviewer you'd be inclined to assume that major issues should have been worked out already, so may not be looking so hard
<robmur01>
another pain with email is dredging up all the previous discussion to remember what changed and/or was already discussed and avoid going round in circles
<robmur01>
waiting *too* long (i.e. months) between versions is also detrimental to that :)
<robmur01>
the best rule of thumb is probably to look at how fast the maintainers/reviewers for the relevant subsystem tend to respond, and try to match that kind of pace
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 252 seconds]
<alyssa>
robmur01: if you're trying to convince me that email review workflows aren't good, you've made some excellent points 😇
<robmur01>
After ~8 years, my relationship with email patch review is basically Stockholm syndrome. But at least it's not Gerrit..
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
<alyssa>
Woof woof.
<clarity>
meow.
hipboi has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
vagrantc has joined #linux-rockchip
stikonas has quit [Ping timeout: 258 seconds]
hipboi has quit [Ping timeout: 245 seconds]
stikonas_ has quit [Remote host closed the connection]
stikonas_ has joined #linux-rockchip
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 240 seconds]
hipboi has joined #linux-rockchip
hipboi has quit [Ping timeout: 252 seconds]
hipboi has joined #linux-rockchip
alpernebbi has quit [Quit: alpernebbi]
hipboi has quit [Ping timeout: 240 seconds]
chewitt has quit [Quit: Zzz..]
hipboi has joined #linux-rockchip
chewitt has joined #linux-rockchip
hipboi has quit [Ping timeout: 252 seconds]
hipboi has joined #linux-rockchip
archetyp has quit [Quit: Leaving]
hipboi has quit [Ping timeout: 252 seconds]
chewitt has quit [Read error: Connection reset by peer]