ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Off-Topic: #armbian-offtopic | Logs: -> irc.armbian.com
Suspect has quit [Quit: Leaving]
archetech has quit [Quit: Konversation terminated!]
archetech has joined #armbian
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #armbian
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #armbian
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #armbian
p0g0_ has joined #armbian
p0g0 has quit [Ping timeout: 260 seconds]
lyri has joined #armbian
maknho has quit [Ping timeout: 260 seconds]
maknho has joined #armbian
pablocastellanos has quit [Ping timeout: 260 seconds]
pablocastellanos has joined #armbian
cheakoirccloud has quit [Quit: Connection closed for inactivity]
<DC-IRC>
<bret> mm, well with HDMI disconnected it works fine, though the strange thing is that it was only GB6 that was showing this. Oh well, will come back to that another time
<DC-IRC>
<bret> I lied, something's definitely fucky somewhere. UnixBench gets a system index score of 5 on one of the big cores vs 416 on the Rock 5B. It's not thermally throttling, something else is going on but it seems to be exhibiting rather randomly
Unit193 has quit [Quit: [TLS] Client upgrade]
Unit193 has joined #armbian
stipa_ has joined #armbian
stipa has quit [Ping timeout: 255 seconds]
stipa_ is now known as stipa
Suspect has joined #armbian
p0g0 has joined #armbian
p0g0_ has quit [Ping timeout: 250 seconds]
archetech has quit [Quit: Leaving]
Suspect has quit [Quit: Leaving]
<Werner>
--test
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian
<Werner>
--übersetzter text
<ArmbianHelper>
translated text [de~>en]
<DC-IRC>
<Tenkawa> does it only handle one set of languages?
<Werner>
It takes any input language (detected automatically) and translates into english. However does work for IRC only atm
<DC-IRC>
<Tenkawa> If not how do you trigger it I want to test it
<DC-IRC>
<Tenkawa> Ok.
<Werner>
Just put -- before the text you want to translate
<Werner>
--so zum beispiel
Tenkawa has joined #armbian
<ArmbianHelper>
For example [de~>en]
<DC-IRC>
<Tenkawa> ok
<Tenkawa>
--watashi no name wa
<ArmbianHelper>
watashi no name wa [ja~>en]
<Tenkawa>
--atashi no name
<ArmbianHelper>
atashi no name [ja~>en]
<Tenkawa>
hmmm it knows the language but not translating
<Werner>
Maybe it expects japanese characters?
<DC-IRC>
<Tenkawa> hmm.. could be
<Tenkawa>
theres a second spelling too
<Tenkawa>
more formal
<Tenkawa>
--Watashinonamaewa
<ArmbianHelper>
Watashinonamaewa [ja~>en]
<Tenkawa>
--je parle anglais?
<ArmbianHelper>
I speak English? [fr~>en]
<Werner>
--привіт
<ArmbianHelper>
Hello [uk~>en]
<Werner>
--你好
<ArmbianHelper>
Hello [zh-CN~>en]
<Tenkawa>
Yeah so its looking for the double byte characters
Tenkawa has left #armbian [Was I really ever here?]
<DC-IRC>
<Tenkawa> That... I never learned lol
<DC-IRC>
<Tenkawa> At one time I could conversationally get by in French, Japanese, and Korean... but never the latter 2 in writing
<DC-IRC>
<Werner> --Jetzt funktioniert das hier auch
<ArmbianHelper>
Now it works here too [de~>en]
<DC-IRC>
<Tenkawa> nice
fakeshell_ has joined #armbian
junaid_ has joined #armbian
fakeshell_ has quit [Quit: Leaving]
cheakoirccloud has joined #armbian
junaid_ has quit [Quit: leaving]
junaid_ has joined #armbian
<IgorPec>
warming up
<Werner>
Ah yes, 1h earlier here due to daylight savings...
<IgorPec>
Focus on making a list of supported boards and jump into bug fixing mode ASAP so release is possible by the end of May.
TRS-80 has joined #armbian
<IgorPec>
- focus in quality - less supported count and better (open download pages and forum so we are all seeing the same)
<IgorPec>
- focus in stabilizing build framework / CI (build fwrk team)
<IgorPec>
- introduce “Retired family” - working configurations (mvebu family, which else?)
<Werner>
If you want to have something noticeable you want to highlight out in the summary later feel free to use one of those "commands for everyone" explained here: https://wiki.debian.org/MeetBot
<IgorPec>
#topic FYI
<Werner>
#topic FYI
ArmbianHelper changed the topic of #armbian to: FYI (Meeting topic: Armbian Release planning 23.05)
<IgorPec>
Stuff to know beforehand - MC presents meeting relevant news and rules of engagement:
<IgorPec>
note 1: IRC translator: If your English is poor, simply write in your native language. Start your sentence with -- at the beginning.
<IgorPec>
rule 1: When you get a voice, please be quick and concise (1-2 min) and make it clear when you stop. (“No more, I’m done”)
<IgorPec>
rule 2: If meeting is going out of desired agenda, MC will use “STOP STOP STOP”, wait to get attention and then proceed with the meeting agenda. Please stop chatting and listen.
<IgorPec>
rule 3: Please highlight important information appropriately by putting a keyword in front of your message: #info #action #idea #help check tips below.
<IgorPec>
#topic board maintainers
<Werner>
#topic board maintainers
ArmbianHelper changed the topic of #armbian to: board maintainers (Meeting topic: Armbian Release planning 23.05)
junaid_ has quit [Remote host closed the connection]
<IgorPec>
#action what to move down to unsupported, what to keep
<IgorPec>
#topic Allwinner
<IgorPec>
schwar3kat via email "orangepi-r1, orangepi-r1plus-lts, orangepizeroplus All stable images were good when I last tested."
<Werner>
#topic board maintainers - Allwinner
ArmbianHelper changed the topic of #armbian to: board maintainers - Allwinner (Meeting topic: Armbian Release planning 23.05)
<IgorPec>
#info schwar3kat via email "orangepi-r1, orangepi-r1plus-lts, orangepizeroplus All stable images were good when I last tested."
<IgorPec>
Nanopim1, Bananapim3, Bananapim64, Orangepizero2 (legacy doesn’t build), Bananapi, Orangepizeroplus, Tritium-h3, Tritium-h5, PINE A64-LTS, Nanopi Duo, Duo2 (doesn’t boot), Orangepi R1, Banana Pi Pro, Nanopi Neo Plus2, Orangepipc are in theory supported
<IgorPec>
do we have any Allwinner person around to tell us more about status?
<Werner>
OPi02 legacy would be critical due to lack of mainline stuff iirc
<rpardini>
No, but I'm generally worried about armhf -- due to zImage hacks/de-hacks/etc
<IgorPec>
here we don't get to linux yet
<IgorPec>
its something related to assembling boot loader which is propriatery in this case
<IgorPec>
it worked at old system, fails at new
<IgorPec>
#action fix opizero2
brentr has joined #armbian
<IgorPec>
and second thing - retire complete 32b allwinner?
<IgorPec>
is that too soon?
<IgorPec>
retire = fix sources
<rpardini>
not sure I understand
<IgorPec>
do not upgrade kernels anymore
<Werner>
Boards like Opi0 are still widely used
<Werner>
I think it would be fine not to put any more effort into edge but keep them on lts
<IgorPec>
heisath said for mvebu to stop changing kernels
<IgorPec>
and keep it at 6.1.y
<rpardini>
I'd keep current = 6.1.y for the foreseeable future anyway for all families if possible. it's LTS.
<tonymac32>
yes
<Werner>
Hm I guess keeping on 6.1 is fine since it is supported until end of 2026
<rpardini>
gotta have a grotesquely good reason to bump current up from 6.1.y on any family
<tonymac32>
I can't imagine any reason to
<IgorPec>
ok
<IgorPec>
then this is clear, we do nothing in this regard, keeping CURRENT at 6.1 lts
<DC-IRC>
<FakeShell> #info nanopim1 has working images for both ubuntu and debian bookworm without any major issues
<Werner>
#agreed stop bumping armhf kernels further than 6.1.y
<rpardini>
I'd say stop bumping _all_ 'current' kernels further than 6.1.y
<IgorPec>
ok. other thing is - pretty much unknown state on half of organges and nanopis 32bit
<Werner>
@rpardini until next LTS kernel?
<adeepv>
rpardini: +1
<brentr>
+1
<IgorPec>
Orange pi One ... it probably works, but don't have maintainer
<tonymac32>
+1
<Werner>
It does, for server tasks at least since I have one running
brentr97 has quit [Quit: Client closed]
<rpardini>
#agreed Stop bumping _all_ 'current' kernels further than 6.1.y (at least during 2023)
<IgorPec>
ok
<brentr>
What would be the benefit of bumping further than 6.1.y on these little systems?
<IgorPec>
currently none
<Werner>
Having new kernel features that are not directly linked to hw like optimizations in various code or whatever
<rpardini>
#idea Stop calling any and all vendor kernel "current" - case in point: odroidxu4.
<rpardini>
#idea Rename "legacy" kernels which are actually "vendor" kernels to BRANCH=vendor (case in point rk3588-legacy)
<Werner>
I guess close do nobody needs those
<IgorPec>
#idea changing terminology of “Maintained Hardware” vs “Unmaintained (CSC/EOL/TVB) / Other” into “Armbian maintained” vs “Community maintained” or similar.
<tonymac32>
rpardini agreed
<IgorPec>
this makes it easier to solve the problem of Orangepi One, which probably works, but we don't know status
<IgorPec>
so it will go below
<adeepv>
rpardini with "vendor" kernels we need a more families
<Werner>
Where it fits. Legacy armhf kernel is no vendor kernel for example
<Werner>
More like old-current ^^
<tonymac32>
legacy armhf rk3288 is vendor kernel
<rpardini>
to me "vendor" is any kernel that we can't rebase on top of mainline and get less than 1000 commit patches
<Werner>
*armhf aw kernel
<Werner>
Sorry for mixeup
<tonymac32>
;) I forgot the current focus family, apologies
<IgorPec>
any other saga around Allwinner except we need to get more help to cleanup patch mess
<TRS-80>
IgorPec: To clarify, you are proposing dropping the (CSC/EOL/TVB) setails and simplifying down to either "Armbian" or "Community" Maintained?
<TRS-80>
s/setails/details.
<ArmbianHelper>
TRS-80 meant to say: IgorPec: To clarify, you are proposing dropping the (CSC/EOL/TVB) details. and simplifying down to either "Armbian" or "Community" Maintained?
<rpardini>
adeepv: I see. Amlogic will have 2 "vendor" kernels possibly (4.x and 5.4.y)
<IgorPec>
and "Maintained Hardware" -> "Maintained with Armbiab help" or similar
<adeepv>
rpardini for s4 family for example out vendor kernel different from khadas vendor kernel...
<Werner>
agree. However "community maintained" still implies some sort of maintainership which might not be true. Therefore "status unknown" might be more realistic in some cases...
<adeepv>
*our
<IgorPec>
Werner yes, but that maintainership is outside our domain and control
<IgorPec>
we don't know if its maintained or not, status unknown
<IgorPec>
but can be fully ok or completly broken
<rpardini>
adeepv: I see no problem in "vendor-jethub" BRANCH, which is only enabled for jethub boards.
<IgorPec>
# topic Amlogic
<tonymac32>
rpardini amlogic should have no vendor kernels for anything older than s4
<Werner>
#topic board maintainers - amlogic
ArmbianHelper changed the topic of #armbian to: board maintainers - amlogic (Meeting topic: Armbian Release planning 23.05)
<adeepv>
rpardini problem with deb-pkgs which builds for family and future updates
<rpardini>
Okie so not much work from my side on amlogic the last few months, mostly reacting to Neil
<rpardini>
current=6.1.y should be relatively stable
<rpardini>
edge=6.2.y also decent, even more so sometimes
<IgorPec>
and most board should be ok with minor issues
<adeepv>
#agree with current=6.1
<rpardini>
there's a bit of mess with u-boot
<tonymac32>
why do we have a khadas kernel and an s4 kernel. And what about anything living in the media kernel (I thought there was some khadas in there)
<IgorPec>
s4 kernel ?
<rpardini>
s4 is upcoming still ppl
<rpardini>
we're future-planning ;-)
<tonymac32>
ok. give it it's own family if it's not on the mainline amlogic train
<adeepv>
rpardini u-boot after 2022.04 has some bug with efi code which cause boot-loop with some amlogic boards
<rpardini>
we gonna need some s4 kernel for VIM4/VIM1S.... and adeepv's gonna need some s4 kernel for his new stuff
<IgorPec>
#info possible another legacy kernel to support VIM4
<adeepv>
tonymac32 amlogic has 4.9 and 5.4 kernels. all chipset from 4.9 are working in mainline kernel (as I know)
<rpardini>
adeepv: true, 22.04+ and low-RAM (<1gb?) boards have some snafu
<tonymac32>
adeepv correct
lyri has quit [Ping timeout: 248 seconds]
<IgorPec>
just some exotic features are problem
<adeepv>
rpardini i disabled all efi stuff in board configs for new versions of u-boot
lyri has joined #armbian
<rpardini>
yeah the main contention point in meson64 is the clock-phase conundrum
<rpardini>
I'd say for current=6.1.y we keep as is, but keep moving with mainline for edge/6.2+
<adeepv>
tonymac32 But for the new s4 family each vendor will have its own fork of the amlogic 5.4 kernel
<rpardini>
anyway I'd say we only plan for s4 for 23.08+ release
<IgorPec>
we might cooperate with khadas and in that case their kernel gets in
<rpardini>
23.05 might have something, but not "regulated"
<adeepv>
rpardini I looked at uboot 2019 code from amlogic, it turns out they use the same method I did for phase shifting: the phases are specified in dts
<tonymac32>
#idea split meson64 into gx, g12, and s4 families
<rpardini>
I'd for sure call it BRANCH=vendor-<something> and not "legacy"
<IgorPec>
yes, it can be called whatever
<IgorPec>
we just need to adjust scripting to follow the logic
<rpardini>
tonymac32: that split does not cure any pain with the clock phase though, which is between different boards in SM1 family
<IgorPec>
any other Amlogic realated
<tonymac32>
yes but we're getting a lot of special cases on more recent boards, while older boards are just along for the ride and nearly maintenance free
<rpardini>
oh Neil added the CM4 Amlogic module
<rpardini>
just commemorating, no action needed.
<IgorPec>
action = at least maintainer that would boot it up
<rpardini>
yeah, action = get samples from vendor and assign full maintainer
<rpardini>
Neil did literally all himself, uboot, kernel, and Armbian stuff
<IgorPec>
this is in motion. waiting for reply
<IgorPec>
so in case someone listening and have a desire for BPI CM4 with a mother board ... PM
* rpardini
raises hand "PM"
<IgorPec>
in case nothing other in the land of Meson ?
<IgorPec>
#topic development Marvell
<Werner>
#topic board maintainers - Marvell
ArmbianHelper changed the topic of #armbian to: board maintainers - Marvell (Meeting topic: Armbian Release planning 23.05)
Suspect has joined #armbian
<rpardini>
Well, my 2c: I severely broke Marvell build with armbian-next. Should be fixed, with help from ManOfTheSea. Thanks for patience
<IgorPec>
me and Manofthesee are trying to give life to Ebin v42 ... callled Ultra
<IgorPec>
its broken without your breakage ;)
<IgorPec>
anyway. here we also have 32bit
<rpardini>
yeah -- it might still be broken, but patch-wise and such, not build system.
<IgorPec>
where Heisath had an idea to formally retire a board
<IgorPec>
as there is nothing going on hw wise
<IgorPec>
no changes for months
<IgorPec>
its an old machine, things works and they will only break down with upgrade.
lyri has quit [Ping timeout: 248 seconds]
<rpardini>
yeah but we'll wanna bump the family kernel and end up frakking up the stable board, won't we?
<IgorPec>
no other hardware in section #marvell
lyri has joined #armbian
<IgorPec>
whole family is covering two devices
<IgorPec>
armada a380 in router and nas variant
<rpardini>
well... yeah in this case some BIG COMMENTS in family file are enough
<IgorPec>
only we can break this hw ... is the point
<rpardini>
yeah. if we stick current to 6.1.y for the next 12 months we should have a year of peace there
<rpardini>
if/when 6.1.y is "too old" we move it to legacy, sans-current, and be done with it
<IgorPec>
the point is that nobody will be checking this anymore
<brentr>
Can we agree, in general, not to bump kernels on unmaintained hardware?
<IgorPec>
and in lets say 6 months someone will shop up crying "id doesn't" boot, fail after upgrade
<IgorPec>
it has to be entire family. in this case its possible
<rpardini>
well lets then downgrade it to whatever we call "maintained on best effort community basis"
<IgorPec>
as both devices we want to retire
<rpardini>
or EOS or whatever. Naming things == hell
<IgorPec>
what i am talking about here is. Kernel = 6.1.20 ... goodbye
<IgorPec>
frozen, kernels are not produced anymore. is this viable?
<rpardini>
oh you mean KERNELBRANCH='tag:v6.1..20` ?
<IgorPec>
yes
<rpardini>
no problem for me
<rpardini>
+1
<IgorPec>
se we know what is the status ... build system can throw out some warning
<rpardini>
eventual interested user/semi-developer can go, bump it manually, fix patches if needed and send PR if wants 6.1.329 in 12 years
<IgorPec>
yes, something like that
<brentr>
+1
<IgorPec>
so we get off from responsibility to KNOW its status at any time
<IgorPec>
#action froze mvebu 32 bit
<IgorPec>
#action froze mvebu 32 bit
<IgorPec>
#topic Rockchip
<Werner>
#topic board maintainers - Rockchip
ArmbianHelper changed the topic of #armbian to: board maintainers - Rockchip (Meeting topic: Armbian Release planning 23.05)
<IgorPec>
Rockpi-s (i2s), Nanopi-r4s(network sometimes fails), Rock-5b (powering, mainline?), Rockpi 4a (not all models are covered), Rock64, Rockpi E(does not boot), Rock 3(?), Orangepi-r1, Renegade, RockPro64, Tinkerboard2(does not boot), Nanopineo3
<tonymac32>
32-bit rockchip
<tonymac32>
or 64 bit
<IgorPec>
32b start
<Werner>
Nanopi-r4s is unstable for me but since nobody else reports I guess its just my board
<rpardini>
armhf rockchip is _also_ subject to my worry ref. zImage and such
<IgorPec>
rapardini: but this will be fixed soon, right?
<rpardini>
#iforgot in Amlogic, there's algo armhf meson, which is in "unknown" state.
<rpardini>
so we merged a PR "to see how it goes"
<rpardini>
it needs... _seeing_
<IgorPec>
hzyitc keep it updated
<rpardini>
I mean, I can't _see_ it myself cos I don't have armhf boards
<rpardini>
tl-dr: every board that boots zImage or uImage needs testing, period.
lyri has quit [Ping timeout: 250 seconds]
<IgorPec>
ok. like i said, lets focus to bugs hunting from today on
<tonymac32>
it is only tinkerboard 1 and tv box for rockchip. I believe I tested after we talked about the boot issue
<IgorPec>
not from next month on
<rpardini>
if broken, fix we shall, and fast, but still needs testing...
lyri has joined #armbian
<IgorPec>
yes, testing testing testing ... we need earlier due many changes in build assemly process
<rpardini>
tonymac32: that was the 1st cycle of zImage problems, which I fixed with a hammer. @ hzyitc did further work
<rpardini>
#idea send rpardini some armhf boards
<rpardini>
not too many, mind you
<IgorPec>
rpardini can send you one allwinner
<IgorPec>
lets move on #rockchip
<rpardini>
ok. 64bit but say 3399 only for now?
<IgorPec>
Jock is keeping 32b in good shape i would say
<rpardini>
Paolo rocks
<IgorPec>
for 64bit ... speak up
junaid_ has joined #armbian
<IgorPec>
TRS-80 how is adventure with PBPRO going?
<rpardini>
well there has been progress with rockchip64 patches cleanup
<rpardini>
but still, we have _evil_ patches in there
<tonymac32>
boards affected by switch of source configs to board configs need tested
<tonymac32>
I need to retract a few that got into non-rockchip64 boards because I was tired and got into a rythm
<rpardini>
I think at least 2 "overwriting" patches, helios64 and smth else, and also bad/terrible patching of pinebookpro
<tonymac32>
I haven't gotten a replacement for my helios64 yet, so it is still production. no testing until the replacement arrives
<rpardini>
lets look at family file super quick
<IgorPec>
anyone has radxa e25
<tonymac32>
TB2 not booting is new info to me, but it is also a csc
<rpardini>
rockchip64: current = 5.15.y // edge = 6.1.y
<tonymac32>
that needs bumped
<IgorPec>
i saw that too, tb2 was working for me
<tonymac32>
current should be 6.1.y
<rpardini>
tb2 works indeed
<IgorPec>
last time, but haven't tested after rpardini messed up the system ;)
<tonymac32>
pffft
<rpardini>
well I wouldn't bump before we decide on those evil patches
<rpardini>
not saying that 5.15.y is in good state, no
<IgorPec>
#action rockchip needs further patch cleaning
<rpardini>
3399 specially I think
<tonymac32>
hmm, IIRC 5.15 has more issues than 6.1, we've been exclusively tuning on 6.1
<rpardini>
also in 3399 territory: BRANCH=legacy is completely abandoned 4.x ?
<IgorPec>
oh, yes
<IgorPec>
that is in terrible state
<rpardini>
tonymac32: that might very well be true. when I said tb2=works is on 6.1y
<tonymac32>
same, I ahven't built a 5.15 in forever
<IgorPec>
one solution would be to move to 5.10.y legacy
<TRS-80>
IgorPec: Apologies I was summoned to breakfast. PBP is working on recent images I tried, I can test more if needed, now that I have PBP onto eMMC.
Unit193 has quit [Ping timeout: 615 seconds]
<IgorPec>
TRS-80: can you update instructions on what are best ways to get it working on PBP download pages?
<TRS-80>
IgorPec: I can, but my recommentation would be 'install tow-boot to SPI' are you OK with that?
<IgorPec>
yes, i am ok with it
<TRS-80>
will do then
<IgorPec>
whatever works
<Werner>
#action TRS-80 adjusts setup instructions for pbp on download page
<rpardini>
#idea lets have instructions for board on a Markdown heredoc _inside the board file_
<tonymac32>
ew
<IgorPec>
keeping this updated is ...
<IgorPec>
ok
<IgorPec>
so no volonteer for sorting out legacy 3399 ? :)
<IgorPec>
if not, removing?
<tonymac32>
rpardini not a bad idea trs-80 tow-boot? really?
<rpardini>
TRS-80: "install towboot to SPI" seems to be the generally accepted community solution, does nit?
<TRS-80>
rpardini: Yes, that's where I got the idea in fact.
<IgorPec>
this is good enough solution for PBP as nobody doesn't want to do it better
* tonymac32
shrugs it's knock-off u-boot with some cheap chrome paint so why not
<TRS-80>
In fact apparently you can even boot generic UEFI image this way on PBP(!).
<tonymac32>
just like with u-boot
<rpardini>
Exactly. And that thing could even move pbp to arm64 generic image (plus some acpi=off and grub dtb injection)
<TRS-80>
tonymac32: They are trying to solve same problem we are just in a different way.
<IgorPec>
alternativly - if we know which u-boot works, then that
<tonymac32>
I can test it
<IgorPec>
pbp is also one of those - lets patch it up and forget about
<tonymac32>
tow-boot offeres 0 extra functionality of u-boot, just an interface
<rpardini>
s/that thing/towboot, or some decent EFI capable bootloader in SPI/
<ArmbianHelper>
rpardini meant to say: Exactly. And towboot, or some decent EFI capable bootloader in SPI could even move pbp to arm64 generic image (plus some acpi=off and grub dtb injection)
<tonymac32>
but, if the vendor is blessing tow-boot, then it should be preferred and we then ignore bootloaders for the thing
<IgorPec>
pbp is not worth the time. that's the problem
<IgorPec>
i would rather see we enable Apple M1 and Snapdraggon
<TRS-80>
The problem on PBP is not 'which u-boot' but rather they stopped putting anything on SPI. And ex factory (Manjaro) image does not look as SD card. So 'anything on SPI' I think should work. I am willing to test.
<rpardini>
yes and everyone I know how has it, has towboot in SPI.
<TRS-80>
It's worth my time because it's the only modern laptop/netbook I own. :)
<rpardini>
it's a bit like Armbian's mainline uboot for Amlogic. I wish we had time/ppl to supply said towboot build, but we don't, so we go with the vendor
<IgorPec>
well, there are different hw revisions of Pinebooks and quality issues
<IgorPec>
which is impossible to fix
<tonymac32>
yeah
<rpardini>
well yeah, I'd say write that in the Markdown board docs
<rpardini>
;-)
<tonymac32>
and again, towboot *is* u-boot. They seem to avoid that fact as much as possible in marketting
<IgorPec>
fixing dtb injection for Snapdraggon is better investment than 100+ fixing of PBP
<tonymac32>
lol yeah
<rpardini>
dtb injection for Snapdraggon == gimme
<TRS-80>
So I can babysit on my own time, as I already been doing. Which I am going to keep doing regardless. Might as well try and bring what I learn to more people via Armbain.
<TRS-80>
if you guys wil laccept the patches
<rpardini>
TRS-80: definitely do. I'd start by removing stuff we have that breaks stuff, instead of adding more, though.
<IgorPec>
TRS-80: we accept patches, but have to understand how much time was lost for this sh* and its still takin time
<tonymac32>
the tow-boot thing is purely "download from and flash to" instructions, yes?
<IgorPec>
ok, lets move on
<DC-IRC>
<Jason123> well I had manjaro without anything flashed onto the spi and it booted micro sd card
<IgorPec>
#info wet wish to sort out 3399 legacy and bump it to 5.10.y
<TRS-80>
@Jason123 Talk to me after please, I would like more info.
<IgorPec>
if no more rockchip
<IgorPec>
#topic others
<rpardini>
Jason123: great, go into Manjaro source's, find the towboot build, port it to Armbian, test it, submit PR
<Werner>
#topic board maintainers - others
ArmbianHelper changed the topic of #armbian to: board maintainers - others (Meeting topic: Armbian Release planning 23.05)
<TRS-80>
tonymac32: I will FLUP with you as well.
<TRS-80>
(After)
<IgorPec>
Odroid XU4
<IgorPec>
works, its old
<IgorPec>
anything else? except a bunch of RISCV
<rpardini>
ok, xu4: rename "BRANCH=current" to BRANCH="vendor"
<DC-IRC>
<Jason123> manjaro uses uboot though
<rpardini>
otherwise it looks like xu4 has a mainline kernel
<tonymac32>
right
<IgorPec>
what about upgrade?
<rpardini>
Jason123: yeah whatever it is. steal it and PR and we'll think about it
<IgorPec>
it will fail
<IgorPec>
until we don't have a mechanism for easy upgrade and switching, changing the name = +troubles, no gain
<rpardini>
it shouldn't fail, just not-upgrade
<IgorPec>
so, we better not touch
<TRS-80>
I can test ODROID-XU4, I still have one in production. I even have a spare in this case.
<IgorPec>
as its die out hw
<IgorPec>
xu4 works
<rpardini>
yeah I just don't like the "current" there. I think its the only family where current is not really mainline-ish
<IgorPec>
this is hw from 2015
<DC-IRC>
<Jason123> is the issue with the pinebook pro with armbian on emmc not booting into micro sd card?
<IgorPec>
i would agree on change once we would have automation behind
<DC-IRC>
<Jason123> the odroid xu4 is not mainline?
<tonymac32>
I have a stack of XUF/MC1's
<IgorPec>
xu4 is mainline, just our kernel is not
<IgorPec>
as its attached to hardkernel branch
<IgorPec>
its close to
<TRS-80>
@Jason123 I can talk to you re: PBP after meeting, but now we are on to other topics.
<DC-IRC>
<Jason123> this is a meeting?
<tonymac32>
right, we had some stability difficulties a couple years ago
<TRS-80>
@Jason123 yes
<IgorPec>
#action change branch when upgrade mechnism works
<rpardini>
yeah, it's a vendor kernel. it's not "legacy" and it's not a mainline "current". it's a "vendor" kernel.
<DC-IRC>
<Jason123> honestly did not know what I expected just thought this was a regular talk
<IgorPec>
killing upgrade is not an option here
<IgorPec>
rename = kill
<rpardini>
I'd do this together with others, like rk3588, and yes we will have a kill upgrade, but we will in peace with our souls.
<IgorPec>
i would do when this is automagical
<rpardini>
oh, automagical as in, rpardini automagically coded it into the system? :-D
<IgorPec>
as i agree with you that name is not appropriate, but this is old 32b kernel which we might perhaps rather retire
<IgorPec>
then code automagic
<IgorPec>
what about riscv stuff?
<IgorPec>
which goes under "others"
<rpardini>
exactly my point. if I was suggesting to rename "current" to "actual" I'd agree we need automagical
<tonymac32>
make new kernel family available in the armbian-config somehow, users can switch or just never get new kernel updates if they don't choose
<rpardini>
but no, I am suggesting DEMOTING a "current" to "vendor", so no automagic needed here IMHO
<IgorPec>
armbian-config is in terrible state due to lack of maint :(
<rpardini>
I have checked with psychologist, and I've orders to not touch armbian-config, armbian-install, or any dialog-driven bash stuff for the next 10 years.
<IgorPec>
damn
<tonymac32>
:D
<DC-IRC>
<Jason123> could change rk3588 to "vendor"when mainline becomes usable
<tonymac32>
todo for 2028
<IgorPec>
#info riscv sparks little interest. leave as is
<IgorPec>
rpi4 and uefi?
<IgorPec>
uefi with dtb injection
<IgorPec>
for 8cx
<IgorPec>
what can be done here?
<rpardini>
rpi: we had fixes for esp flag in rpi3b (tested), and missing DTB since 6.1.y (fixed)
<rpardini>
rpi: current = 6.1.y / edge = 6.2.y, both foundation kernels (I'd also change those to "vendor" to say the truth).
<IgorPec>
so rpi is fully functional? it would be nice to have - overlay support within armbian-config
<IgorPec>
#action also rpi kernel naming adjustement proposed
<DC-IRC>
<Jason123> pi3b is supported by mainline?
<rpardini>
rpi4b overlays need bigger treatment, I'd say in a larger "ovelays in general" effort
<IgorPec>
what is the prime issue here?
<rpardini>
jason123: this is the Release meeting yes?
<IgorPec>
in overlay handling
<rpardini>
it's inconsistent all around
<rpardini>
each family does its own thing, prefixes, fixups, Makefile patching
<IgorPec>
understand. isn't overlay just adding a txt to config.txt or whatever that files is at rpi?
<DC-IRC>
<Jason123> did not know this was a release meeting
<tonymac32>
#idea overlays stored in folder and copied to kernel sources for compilation instead of patched in.
<rpardini>
yes with rpi overlays are prebuilt by foundation kernels and loaded magically together with dtb by rpi's bootloader
<Werner>
Now you know :)
<tonymac32>
yeah, and the txt file method doesn't work with extlinux, efi, etc
<IgorPec>
as i understand we "just" need to inplement mechanism specifically for rpi?
<IgorPec>
as no existing works
<rpardini>
I refuse to do any work that is rpi-specific, though.
<IgorPec>
ok
<rpardini>
rather do 20x more work, but useful for all.
<IgorPec>
i am just trying to understand
<TRS-80>
<3 rpardini
<IgorPec>
ok, what about Snapdraggon, apple'
<IgorPec>
what we can do here
<tonymac32>
separate overlay building from image building is an option, then have a package. in the case of rpi we don't need to build them, but could pacakge them
<tonymac32>
apple is a black hole, interesting but not valuable IMHO
<IgorPec>
overlays are packed with the image on rpi AFAIK
<IgorPec>
apple is ... well
<rpardini>
I am extremely interested in both Snapdragon and Apple M1/M2. Send them to me and I will make them bend to the power of my `acpi=off` magic
<tonymac32>
it's the hardware version of ReactOS
<IgorPec>
#action get some apples and oranges to Richardo
<IgorPec>
alright
<tonymac32>
snapdragon is a good place to spend some time
* TRS-80
wanted to do #fruit but didn't want it recognized as a keyword
<rpardini>
I've MSM8998 trauma, but yes, the new ones seem worth looking into
<IgorPec>
ok, will try to get one and sent it RIchardo
<IgorPec>
# topic Infrastructure
<Werner>
#topic infrastructure
ArmbianHelper changed the topic of #armbian to: infrastructure (Meeting topic: Armbian Release planning 23.05)
<rpardini>
ok Infra wise, we've circa 1 month to deliver code, test it and produce a working RC
<IgorPec>
i'll just sum up what works now
<rpardini>
there's _much_ code to be written if we wanna have release that is consistent
<rpardini>
a big part of it is repository management
<IgorPec>
apt.armbian.com and nightly beta.armbian.com packages repository are updading daily
<IgorPec>
this was off for about one month
<IgorPec>
now its in action
<IgorPec>
stable and nightly images are producable
<adeepv>
I have a question about versioning: we should revert to semver-like version numbers for nightly kernel/os images
<IgorPec>
3rd party applications with Armbian repositories, Chromium is now inside our repo, synched daily
<rpardini>
yeah but we'll probably need some more radical changes in repo organization (one-common-to-all, one-per-release) right
<adeepv>
hash in the version number is cool, but leads to strange effects when trying to update)
<IgorPec>
what problems are here?
<rpardini>
adeepv: tl-dr: bump the REVISION ("VERSION" file) to get consistent updates, there's no other way around it.
<adeepv>
The hash of the new version is not always larger than the hash of the old version
<IgorPec>
aha, yes
<IgorPec>
that's expected
<IgorPec>
version has to bump
<TRS-80>
That name though ('os'), is this permanent or temporary? I thought we were trying to convince people it's actually a build system (which just so happen to publist the artifacts of said system for convenience)?
<rpardini>
adeepv: the hashes are just that, hashes, they don't have any sorting properties. I tried to have kernels and uboots with (Makefile) version in front, but that does not always help.
<IgorPec>
TRS-80: perhaps the name is not fully the best for this, yes
<TRS-80>
IgorPec: If this is output of CI, or the CI itself maybe it call it 'CI' or 'artifacts' or whatever more appropriate.
<IgorPec>
We are not joking about and also are producing an OS.
<IgorPec>
#action switching the name of current OS repisotiry
<rpardini>
I'd say "armbian/os" repo is essentially "the default userpatches"
<IgorPec>
yes, it has that too
<rpardini>
and soon the "targets.conf" repo
<IgorPec>
repo management should perhaps be placed somewhere else
<adeepv>
rpardini I'm talking specifically about nightly builds of packages and images, they should have an incrementing part with semver-like version
<rpardini>
say armbian/os is what makes armbian.com images, using the Armbian.org build system ;-)
<TRS-80>
So, build will remain as is?
<IgorPec>
yes, build won't change
<rpardini>
adeepv: oh, yes. for nightlies we need to bump the "VERSION" file in a consistent manner and that will also work.
<TRS-80>
So armbian/os is CI pipeline and produced images / artifacts?
<IgorPec>
yes. but also contains some OS defaults
<adeepv>
IgorPec: Yeah, it's like this
<adeepv>
and for kernel/bsp/etc packages also
<TRS-80>
IgorPec: OK, as it would need those to feed into 'build' to produce the images. I think I begin to understand.
<rpardini>
yeah its a bit "userpatches" + "what to build" + "how to build"
<TRS-80>
Or maybe you mean like our cutomizations, too. Deviations from vanilla Debian?
buzzmarshall has joined #armbian
<IgorPec>
customizations of armbian build system
<rpardini>
anyway in my view, infra/CI/versioning/repository/matrix is the main focus of work
<rpardini>
for the whole of April
<IgorPec>
yes
<rpardini>
I'll refrain from family/board/pkg work in favor of this by default
<IgorPec>
#info help in CI is most welcome
<IgorPec>
its more important than hw specific at this stage
<IgorPec>
this is true Arbmian problem, while HW support is still pretty common
<IgorPec>
ok
<IgorPec>
lets wrap this up
<Werner>
regarding infra. what's the current status of armbian paste?
<TRS-80>
I like this new split. Correct me if I am wrong but this means if someone wanted a more 'vanilla' Debian (not that we add much) but it should be easier to do so going forward just by submitting the appropriate arguments to the build script. Amirite?
<IgorPec>
Werner: it was fixed, but we need to try
<rpardini>
#weforgot rk3566 / 3568 / 3588
<rpardini>
#weforgot UEFI
<IgorPec>
UEFI we didn't. i was asking before in #others
<Werner>
Indeed
<rpardini>
oh ok.
<IgorPec>
#topic misc
<Werner>
#topic misc
<IgorPec>
what we forgot
ArmbianHelper changed the topic of #armbian to: misc (Meeting topic: Armbian Release planning 23.05)
<joshaspinall>
couple of quick Q's from me if I may?
<rpardini>
uefi: current = 6.1.y / edge = 6.2.y -- I'd say both in good state, arm64 has patches for Phytium D2000 which is working good.
<IgorPec>
shoot
<rpardini>
rk3588-legacy with amazingfate effort, kedge2 in media, etc.
<joshaspinall>
the Pine A64-LTS is in the meeting notes, but not on the linked forum post; I assume as it missed the last release?
<joshaspinall>
Also, to confirm that this also covers the SOPine module (same board, different package)?
<IgorPec>
AFAIK those two are the same HW wise
<IgorPec>
can boot same image
<Werner>
What about discussion of board status? demote to csc, promote to support and so son
<joshaspinall>
just for clarity I guess, same image different board package
<joshaspinall>
If anyone has a SOPine carrier board, or the A64-LTS SBC board from previous maintainership, please get in touch! Am currently running the Clusterboard.
<joshaspinall>
And finally, apologies if I should have chipped in earlier with these, first meeting, thanks!!
<TRS-80>
Welcome, joshaspinall.
<IgorPec>
Joshua: no problem. If you have access to website - you are welcome to edit info
<IgorPec>
if not PM
<rpardini>
joshaspinall: what family are those boards...?
<IgorPec>
allwinner
<joshaspinall>
A64
<DC-IRC>
<FakeShell> i don't know if anyone noticed my first message about allwinner but nanopi m1 is working fine with nightlies and basically all images
<joshaspinall>
got to shoot for dinnertime, thanks all. Will check my website access later
<IgorPec>
Werner: demote and promote , perhaps editing this document
<IgorPec>
its a snapshot of what is supported and have maintainers, which is not the same as forums
<Werner>
Yeah, I'm on
<IgorPec>
otherwise we can close down the meeting
<IgorPec>
this list is going to be making there
<IgorPec>
anything else?
<Werner>
Yeah I guess so. Anyone wanna add something? Last chance
<TRS-80>
Do you want me to add pinebookpro here now on HedgeDoc or submit patch later putting myself as Maintainer?
<TRS-80>
or both?
* rpardini
stops showing off his mad markdown skilllzzz
<DC-IRC>
<FakeShell> x to remove? what if its working?
<IgorPec>
Fakeshell: if you know its working is already "supported" kind of
<IgorPec>
the case here is that if there are no active people behind, we don't really know
<IgorPec>
there is around 50 boards in auto testing facilit
<Werner>
#endmeeting
ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Off-Topic: #armbian-offtopic | Logs: -> irc.armbian.com
<DC-IRC>
<TheBug> In the same house as the three little bears.
<TRS-80>
OK, so I gather the database is automatically parsed now (perhaps by CI?) -> https://www.armbian.com/authors/. Is my understanding correct (as I will be putting this in my patch)?
<IgorPec>
rpardini this is crm driven now
<IgorPec>
for about a year
* TRS-80
doesn't get out much, either, lol
<TRS-80>
news to me as well
<IgorPec>
we can keep this table, but if its not accurate and unmaintained, makes no value
<IgorPec>
if person hasn't been around for one year, but its still in that table ...
<rpardini>
Took a look at https://www.armbian.com/authors/ -- don't know more than 80% of listed people, never saw or heard from them, much less any PRs
<rpardini>
ok 80% was exaggeration, but at least half are not active in 2+ years
<IgorPec>
and table that nobody clean can opnmly be worse
<IgorPec>
80% of the people there you can track down and are actually from that list
<TRS-80>
rpardini: Those kind of problems are outside of my scope. ;) I am only asking 'which is the one true way' so I can get rid of other ways.
<rpardini>
this is wordpress plugin?
<IgorPec>
of maintainers. some take this job serious, some not. there is little we can do about that
<IgorPec>
no, this is custom coded
<IgorPec>
but its just JSON -> HTML snippet
<IgorPec>
people data is in JSON format
<rpardini>
ok yeah one day I will have time to investigate that
<rpardini>
for now only curious and impotent
<Werner>
rpardini, check your queries :)
<IgorPec>
don't need to deal with everything
<IgorPec>
its a lot of coding and planing and organising ...
p0g0 has quit [Ping timeout: 248 seconds]
<rpardini>
sounds like CRM/ERP problems at a startup, but, ok.
<IgorPec>
i only study API here, there rest is other people work
<TRS-80>
rpardini: Personally I also preferred text based way, but Igor seem to prefer this database way. You see, this is what you get when I disappear for some time. ;)
<IgorPec>
text based you can do to some extend, but from on point you need to decide
<Werner>
,unload meetbot
<IgorPec>
vi is also a cool editor
<ArmbianHelper>
The operation succeeded.
<IgorPec>
rpardini its like having vi as IDE
<rpardini>
never touched vi in my life, thanks.
<IgorPec>
for few lines of code its perfectly enough
<rpardini>
I can ":q" out of it and thats it
<rpardini>
I learned "pico" back in the days, so I can only use "nano" if I'm in a command line
<IgorPec>
and at one point editin a database via CLI becomes terrible stupid
<TRS-80>
IF you can exit, you got further then me. :D
<IgorPec>
i still know people which uses vi for most of their tasks ;)
<rpardini>
to me, stupid is having 2 sources of truth about things, which disagree
<IgorPec>
rpardini: TRS80 will remove one
<TRS-80>
rpardini: And that was my only and main concern, plus being accurate in my understanding, so I can remedy that by going back to only one source of truth.
<rpardini>
no, I mean board.conf is the only source of truth, we should have most info, instructions, maintainers, info, etc, all in there, and _generate_ a database if needed.
<IgorPec>
rpardini how you will keep this info accurate is the biggesrt challange
<TRS-80>
Actually, I like this idea even better. Thought it myself many times in fact.
<IgorPec>
now how you will store it
<DC-IRC>
<Tonymac32> I agree that we could put the board instructions in the board conf
<rpardini>
you keep it much more accurate in board.conf in git than a "database" somewhere, IMHO
<DC-IRC>
<Tonymac32> If the board maintainer is not keeping up, then that boards info won't be accurate, but a database does not solve this issue anyway
<rpardini>
instructions, maintainers, forum link, etc
<IgorPec>
a project needs contact database
<rpardini>
most "maintainers" listed there dont' even know the board.conf name of their board
<rpardini>
they're... not maintainers.
<DC-IRC>
<Tonymac32> Shhhhhh
* TRS-80
is very much in favor of this approach
<IgorPec>
and i can keep it accurate with crm significantly more effective
<rpardini>
they're "interested folks that have the board"
<DC-IRC>
<Tonymac32> I got yelled at for that observation
* TRS-80
also agrees
<IgorPec>
we have many different system
<IgorPec>
also forum
<rpardini>
no PRs = no maintainer
<IgorPec>
wordpress
<IgorPec>
PR doesn't make it a maintainer
<IgorPec>
negaticve
<IgorPec>
read requirements
<rpardini>
you gotta atleast PR yourself as a maintainer in the board.conf if you wanna be a maintainer
<IgorPec>
nope
<IgorPec>
you need to provide information
<TRS-80>
I guess the idea is to open up (loosen) 'Maintainer' requirements a bit. Otherwise less people might sign up. We have to reel them in slowly. lol
<IgorPec>
"Maintainers must not necessarily be persons with development experience"
<Werner>
true
<IgorPec>
in theory it could be without Github account
<rpardini>
I simply disagree. Calling "interested person that has the board" a maintainer helps literally no one, except the marketing dept maybe?
<TRS-80>
rpardini: Let them walk before they run.
<IgorPec>
how do i know if board works or not?
<IgorPec>
who will tell that?
<TRS-80>
Consider it recruitment. You don't have an rpardini fall into your lap every day you know.
<IgorPec>
a) i plug the board and see
<IgorPec>
b) asks around
<rpardini>
True and fair. I just like coming clean at once. Every meeting theres talk of ghost maintainers, and faraway databases...
<IgorPec>
c) have a fancy automated system which is expensive
<IgorPec>
d) have maintainers
<rpardini>
I understand it all and abide by the rulings, sirs
<IgorPec>
this meeting was also to determine if we have real or ghost maintainers
<IgorPec>
many people heats up quickly but this is LT responsibility
<TRS-80>
rpardini: I take your point. I even think that way myself some times. But imagine larger scope of whole project. We need to always be trying to bring more people in. Reduce friction in doing so.
* TRS-80
still auto-joins #armbian-onboarding whenever he gets on IRC
<IgorPec>
"interesent to support" persons falls out as we expect something from them
<rpardini>
well we'll secretly keep count of actually-useful-onboarded people and do a big prize at end of year then?
<IgorPec>
a person that adds a board, stick around for a while gets there
<IgorPec>
but if a persons sticks around or not, has to be verfied in some way
<rpardini>
adds a board, supports it a while, I'd agree
<rpardini>
add a board and run, no
<IgorPec>
yes, but wait here
<IgorPec>
most of the people on that list of maintainers got this way in
<rpardini>
I'd measure by having maintainers commit things like "- March/23: tested current & edge builds. works. no 2nd ethernet. thnxbye; --rpardini" to board
<IgorPec>
but as people get bored, have no time ... etc
<TRS-80>
That's what we are doing in meetings. Like a roll call. Show up (and participate) or board 'supported' status gets dropped.
<IgorPec>
i do my best to check for this info in the backstage and via those meetings
<rpardini>
simple, succint, useful, marks them as "merged PR" on Github, gets starts, helps marketing, gets more people involved
<IgorPec>
you can't push on people like that
<IgorPec>
its their good will
<rpardini>
well you definitely see my point, I also see yours
<rpardini>
for now I propose have "instructions" for download page in board.conf _only_ (not maintainers!)
<rpardini>
if it works well we can think about maintainer and maintainer notes in future
<IgorPec>
i chose this way as all others costs my time like 50 x more
<IgorPec>
its not just you me and few people that will do this way
<rpardini>
yeah I see your point, keep your db Igor, no problem. it's great.
<rpardini>
really.
<IgorPec>
and its totally confising as we are dragging HW and build framework
<rpardini>
I shouldn't have even gone there.
<IgorPec>
i am maintaining this db for other reasons
<IgorPec>
this is just one part. commit data is in the git
<IgorPec>
so there should not be a problem
<rpardini>
fun idea, generate a git shortlog since armbian-next switch on main
<rpardini>
then compare to what you have in db
<IgorPec>
most of this stuff is way too complicated for most people
<rpardini>
what? `git shortlog 07dc..HEAD` ?
<rpardini>
it's... almost quasi-readable, depending on author
<IgorPec>
yes. and how you would extend and improve that ?
<rpardini>
first thing, do a .mailmap -- then start enforcing decent commit messages -- then use data to determine who's active and who's not -- move instructions into board.conf -- move maintainers test notes into board.conf -- profit.
<rpardini>
but yeah, I've said enough
<rpardini>
on this subject
<rpardini>
for a year
<rpardini>
let me go back to my cage and code Python
<rpardini>
:salute:
<TRS-80>
rpardini: It's not that your ideas are not good, it's that IgorPec have made conscious decision to focus (very) limited time and attention on more pressing matters.
<IgorPec>
looking at GitLog is important, but its just one perspective
<IgorPec>
its too limited
<TRS-80>
All of us (including you) have more important things to be doing. But maybe one day, someone has time to implement something better, and we go with that.
<IgorPec>
people that generate this log needs support
<IgorPec>
and having someone between lame end users and us is golden
* IgorPec
go to find some food. then looking into the Git ;)
<TRS-80>
rpardini: FWIW, I always wondered the same thing, why not put everything into boards.conf file. But now we have this instead. Maybe one day.
<IgorPec>
we are loosing the point of why this info is there
<TRS-80>
In this case it seems to me basically like a contacts database?
<IgorPec>
if X commited support for board ... is he a maintainer? Or just someone having a spare time to add this?
<rpardini>
TRS-80: I think indented heredocs in bash do wonders. Some editors actually support marking/injecting certain heredocs as another language, so you can get Markdown syntax help and coloring inside the bash heredoc.
<IgorPec>
no. he just added a code. Becoming a maintainer is set of rules and obligations
<rpardini>
Also, if we had say board.conf.md (separate file) general editor support would be better (even Github has web editor), but having 2 files gives me chills
<rpardini>
he's at least "involved"
<IgorPec>
is it?
<rpardini>
in a confirmation sense, yes
<TRS-80>
rpardini: So yeah heredoc sounds better. But let's listen to IgorPec, I think he is trying to tell us 'that's solving the wrong problem'.
<rpardini>
guy1 is listed as maintainer, guy2 is listed as maintainer. only guy1 has commited. so it is confirmation
<IgorPec>
git commit = maintainer
<IgorPec>
this perspective makes troubles here
<rpardini>
if random guy3 commits, but not listed as maintainer, maybe he should be recruited?
<IgorPec>
a maintainer does not need to commit anything
<rpardini>
etc.
<TRS-80>
driveby patch != Maintainer
<rpardini>
that's where we HARD disagree, but ok.
<rpardini>
a maintainer had to commit. a random commiter does not become maintainer.
<IgorPec>
a person that knows what is wrong with the board and keep that list is more valuable
<rpardini>
a maintainer who does not commit is not real maintainer. commit, even if its just "I tested this and its broken" note.
<TRS-80>
rpardini: Maybe think of 'Maintainer' as ~'expanding the pool of people who can maybe spend a little time testing images and maybe help out on forum'
<IgorPec>
commiting is technical act driven by your brain or maintainers brain
<rpardini>
ok then the person who looks at forum and commits is the _real_ maintainer
<IgorPec>
in fact it is
<IgorPec>
but
<TRS-80>
I suppose there are degrees. But we know who is doing what. Why push away people who may be interested to get involved only a little at first?
<IgorPec>
you have two option here
<rpardini>
forum interested people with board = great, but not maintainers. I will _not_ relent from this opinion, although I agree with "not doing anything about it"
<IgorPec>
doing whatever whoever (end user) tolds you
<TRS-80>
I myself shied away from 'becoming Maintainer' for a long time because requirements were too strict.
<IgorPec>
then find more appropriate naming for that
<rpardini>
"becoming maintainer" should be 100% automated. you commit yourself into the maintainer list, open PR, get approved, and bingo, you're a maintainer.
<rpardini>
if you don't commit in say 12 months time, you're automatically demoted as maintainer. simple.
<rpardini>
every time you build and test, you commit a note, send a PR, get approved. nothing "technical" about it.
<IgorPec>
won't work
<IgorPec>
people are on the other side
<IgorPec>
and on this too
<TRS-80>
I don't think the naming is as much of a problem as sticking to a consistent story of what a maitainer's responsibilities actually are. Which have been lessened over the years, which I think it a good move.
<TRS-80>
rpardini obviously disagrees, and that's OK. :)
<IgorPec>
richardo is looking too much from his perspective here. He is certainly a top maintainer
<TRS-80>
yes, not everyone is an rpardini, not even close in fact
<rpardini>
TRS-80: my itch is this. I make a change to build system that affects board X. I look up the X's maintainers, and find a ghost.
<rpardini>
I wish I could go and find a very vague list of "possibly interested people which said they have the board and are willing to test" .
<IgorPec>
and I want to remove ghoses reguraly
<rpardini>
that would be a _huge win_
<TRS-80>
I thought that's what this database was (possibletesters). Of course some may come and go. I don't think that changes with any of the requirements you propose above.
<rpardini>
so it's a _list_ instead of one, and clear indication if that person is actively working on the code, or just someone "willing to test", "willing to test, has UART"
<TRS-80>
'has UART' should be added to form / requirments
<rpardini>
btw "willing to test, has UART" is a great very valuable asset. better than any ghost maintainer
<IgorPec>
database is just a tool that makes this process - if need to be manual - a lot easier
<rpardini>
manual == outdated
<IgorPec>
meetings are ghost hunters
<rpardini>
always
<TRS-80>
rpardini: FWIW, even my old table supported notion of multiple maintainers, not sure about new system, but it should
<IgorPec>
but we had a docs.armbian.com driven now
<TRS-80>
perhaps even with a 'primary' and some 'secondaries' or numeric rank
<IgorPec>
it was not automated, it was a very rigid system that works ok if you have 5 people to handle
<rpardini>
seems like problem is we have a huge influx of interested people and too many maintainers and we can't choose from the best one
<rpardini>
while reality is very, very far from that.
<IgorPec>
if you have absolutely no control over the database, then you are lost before starting
<TRS-80>
rpardini: Consider it marketing for the project. :)
<IgorPec>
database = have a lot more info then name related to board
<rpardini>
yeah great mkt, "Armbian has an army of maintainers that can't be bothered to commit git notes about testing their boards"...
<rpardini>
database == outdated
<TRS-80>
rpardini: I was being a bit tongue-in-cheek
<IgorPec>
you can't ask them to do that
<IgorPec>
i mean you can ask them, but telling them they are idiots ... and you lost even that small
<TRS-80>
However how are we even supposed to make board+image = boot y/n or other reports? I almost asked in meeting. A simple form I think would be great for that. But maybe we have something already?
<IgorPec>
we don't have acceptance criteri or job interview reqirements
<rpardini>
yeah, no idea. I believe tests when they send me bootlogs or dmesg dumps, otherwise no.
<TRS-80>
OR even better an opt-in question on first boot?
<IgorPec>
automation
<TRS-80>
which could do automated report, testing
<IgorPec>
that tests for them and us
<IgorPec>
is the only wway
<TRS-80>
I know, it needs development, but does seem (by far) the best way.
<TRS-80>
For God's sakes please keep it anonymous.
<IgorPec>
we had situations in the past that people didn't even run a build tests
junaid_ has quit [Ping timeout: 248 seconds]
<rpardini>
yeah, and how useful is having such a "maintainer"...
<IgorPec>
like never, not just forgot here and there
<IgorPec>
not useful
<IgorPec>
but we are over that.
<IgorPec>
good board maintainer should not be seen much around as everything works well ;)
<IgorPec>
i know that this doesn' eat reality
<rpardini>
looking at docs.armbian.com, it sends me to armbian.com/download for a list of supported boards. i find one which I'm supposedly maintainer for, and it says "maintainer needed"
<rpardini>
so yeah, whatever Igor.
<TRS-80>
Anyway, rpardini, I don't think you can hold everyone to same standard as yourself, as you are one of very few top maintainers. I mean you can, but you will only drive yourself crazy, man. JMHO
<IgorPec>
yes, no database is source of truth
<IgorPec>
its chaotic
<IgorPec>
whole documentation is a mess
<IgorPec>
but this is what we have
* TRS-80
goes off to work on it
<rpardini>
ok yes so given that, immediately dismiss all ideas as "won't work" is a great strategy yes.
<rpardini>
i'm outta here folks, for real.
<rpardini>
:salute:
rpardini has quit [Quit: gone]
<IgorPec>
all those databases sources are maintained manually and nobody and all is maintaining it
<IgorPec>
wordpress = own database, no synhronisation except board download files
<IgorPec>
Jira = own databases, no sync
<IgorPec>
github = own database no sync
<IgorPec>
maintainers file = own databases
<IgorPec>
igor crm = own database, has one sync = authors
<IgorPec>
forum = own database, no sync
<TRS-80>
rpardini left, but I guess that was what he was driving at. I don't want to speak for him but one of his points seemed to be trying to get a 'single source of truth'.
<IgorPec>
yes, i am not that stupid
<IgorPec>
but to get this into one source of truth ...
<TRS-80>
I guess it comes down to choice of tools and who will maintain them
<IgorPec>
who will do it?
<IgorPec>
its for 6-12 months of work
<TRS-80>
I don't have a strong opinion either way, I see both/all sides, just trying to mediate a bit.
<TRS-80>
I know.
<IgorPec>
yes, its so easy to say, but the problem is extreme from my POW
<IgorPec>
and don't have a solution
<TRS-80>
And I give you a lot of credit for keeping focussed.
<TRS-80>
It's hard to keep things going when they aren't perfect.
<IgorPec>
its terrible mess if you look into any direction
<TRS-80>
don't look too close I guess lol
<TRS-80>
OK I am going to go work on some stuff.
<IgorPec>
yeah, i have to off
<TRS-80>
Unless you have anything else for me?
<IgorPec>
no
<TRS-80>
Cheers IgorPec
<IgorPec>
cheers
<DC-IRC>
<Tonymac32> Scope definitions will help. For example I really don't care if the forums/etc are synchronized, if they deviate at the very least there must be a single thing we point at and say "this is The Truth". I honestly don't care about other maintainers either, but a decent role for the build system board config file is to have metadata pertaining to who cares for that board, as well as all the board specifics. I see this as work on the caretake
<DC-IRC>
<Tonymac32> It is logical to be able to live inside the cloned build system and not have to track down other information streams for the basics
<TRS-80>
That was ~ my thinking as well, but apparently we have this database now. Which is not really a database, I should quit calling it that. It's really a JSON text file, apparently. However what about the more sensitive data like people's addresses (to ship samples), real names, phone numbers, etc.? I guess I see the utility of a private 'database'. The fact it's 'easy to use' (Just fill out a form) is just like the cherry on top.
<TRS-80>
JMHO.
<DC-IRC>
<bret> It's at this point of reading the scrollback I should apologise for not being as active as I could have been in regards to being the maintainer for the BananaPi M5. Rescuing a dog has taken up so much of the last 3 months I've just not looked at anything 😦
<TRS-80>
@bret It's fine. People come and go. I myself only got roped into meeting on accident because I logged on to IRC for something else and this channel is on my auto-join list. I didn;t even know there was a meeting. Now I have some work to do. lol Anyway just do whatever you can, whenever you can. And try and be 'present' as much as possible, in some form (IRC, forums, submit PRs, etc.).
<DC-IRC>
<bret> The meetings are a little tough as they're at 23:00 for me and getting up at 05:30 each morning means I'm normally dead and in bed by that time 😄 I think my mirrors are still working as expected so that's the most contribution I can actively offer right now
<DC-IRC>
<bret> I have about 12 boards on the backburner to test and review, waiting for the angry emails from vendors 😓 then the more angry emails when I actually publish them and comment on their complete lack of support
<DC-IRC>
<bret> I should list them somewhere so that if anything needs testing then I'd be happy to do ad-hoc stuff (like on the BananaPi CM4 that I'm playing with at the moment) but it's impossible to say I can do X hours at Y time at the moment
<TRS-80>
Maybe just update what boards you have and are willing to test at https://www.armbian.com/update-data/. This goes for @bret as well as anyone else in channel who is willing to do so.
<DC-IRC>
<bret> Sure, I think I can manage that heh. A little strange that that form seems to require a surname but not a first name, not sure if intentional or not
<TRS-80>
I see the asterisk but don't know if it's actually enforced. Just put first name in Surname if you want. Igor is not Google nor the NSA.
<TRS-80>
I am only known by this handle, even in this project (but also everywhere on the Internet).
<DC-IRC>
<bret> Oh, I'm sure I've already entered more information previously, no worries on that front
<DC-IRC>
<bret> I've been pretty terrible at choosing usernames on the internet 😅
<TRS-80>
I have very strict 'identities' with consistent user names, even IP addresses.
<TRS-80>
Totally separate from my real identity.
<TRS-80>
Different email servers, on different hosts, etc.
<DC-IRC>
<c0rnelius> they call it; paranoid
<TRS-80>
OF course this took some effort to set up. But that's how much I care about my privacy. Every single person I hand an email address out to gets a unique one.
<TRS-80>
@c0rnelius Just a man ahead of my time in this cypherpunk tech dystopia we find ourselves in.
<TRS-80>
Also, good day to you. :)
<DC-IRC>
<c0rnelius> hey you.
<DC-IRC>
<rpardini> hey, I'm back
<DC-IRC>
<rpardini> where's this 23.xx uboot for rk3588 I hear about?
<DC-IRC>
<bret> bah, that just reminds me that I need to actually try the updated image that Cool Pi pushed out for their 4B. Not entirely confident that they've fixed the issue of it thermally throttling after about 10s in firmware, especially when they say they've magically designed and created a heatsink for the board now 😄
<DC-IRC>
<Tenkawa> @rpardini 3568.. not 3588
<DC-IRC>
<rpardini> oh that's even better, actually...
<DC-IRC>
<rpardini> should I go digging in `pyavitz/debian-image-builder` ? 😄
<DC-IRC>
<Tenkawa> Its still a wip...
<TRS-80>
Since you guys are here, do you concur with Tony that RK3568 is looking pretty good in mainline? Asking for a friend (who might be interested in PineNote 2).
<DC-IRC>
<c0rnelius> its using 2022.07 as I know that works.
<DC-IRC>
<Tenkawa> there's so many intertwining dependencies we are finding
<DC-IRC>
<c0rnelius> 2023.04-rc4 kind of has support but I haven't really tested it beyond compilation as I don't have the HW.
<DC-IRC>
<Tenkawa> The crypto config is stacked up bad
<DC-IRC>
<c0rnelius> i guess its rc5 now?
<DC-IRC>
<rpardini> Oh. I was looking for something for the ODROID-M1 -- Armbian's currently shipping none on image, and none for SPI.
<DC-IRC>
<rpardini> If it booted NVMe, that would be awesome.
<TRS-80>
Oh sorry, apparently it's RK3566 based (maybe that's similar enough).
<DC-IRC>
<rpardini> I made it build the vendor's u-boot once, but was just not worth it.
<DC-IRC>
<Tenkawa> It has a very odd setup compared to most
<DC-IRC>
<rpardini> I think both 66/68 are very well supported kernel wise, save for vdec/venc of which there was none not long ago, dunno how it is now.
<DC-IRC>
<Tenkawa> currently my M1 needs to be reflashed
<DC-IRC>
<rpardini> The ODROID-M1 (68) is shipping with a fully mainline kernel and works very well in my (non-desktop) experience
<DC-IRC>
<rpardini> The quartz64a (66) is still hijacked to media family, but runs pretty good with edk2 and generic arm64.
<TRS-80>
They are talking about April release but I am not going to jump on it right away.
<DC-IRC>
<c0rnelius> I have some M1 patches for 2022.07, but the dts is limited to sd/mmc. I doubt pcie would even work if the nodes and such were added.
<DC-IRC>
<rpardini> So both on 66/68 the question is more about u-boot or edk2 support; kernel is very good.
<DC-IRC>
<c0rnelius> you also need to disable pboot to use it.
<DC-IRC>
<Tenkawa> yeah.. petitboot... uggh
<DC-IRC>
<rpardini> Like on the quartz64a, I could get either u-boot and no NVMe, or edk2 and NVMe; but the UEFI boot fails due to missing ACPI glue. So had to force down to DTB usage. A bit quirky.
<DC-IRC>
<rpardini> Like on the quartz64a, I could get either u-boot and no NVMe, or edk2 and NVMe; but the UEFI ~boot fails~ ethernet fails due to missing ACPI glue. So had to force down to DTB usage. A bit quirky.
<DC-IRC>
<rpardini> Like on the quartz64a, I could get either u-boot and no NVMe, or edk2 and NVMe; but the UEFI ~~boot fails~~ ethernet fails due to missing ACPI glue. So had to force down to DTB usage. A bit quirky.
<DC-IRC>
<c0rnelius> did get the radxa e25 kind of working though. short of one of the eth ports not functioning for some reason.
<DC-IRC>
<rpardini> but yeah Radxa's Rock-3 / CM3 / etc have lacking mainline DTs, Lane's been bitching about them for years
<DC-IRC>
<rpardini> E-25 is just another CM3 carrier no?
<DC-IRC>
<c0rnelius> yes it is. its in 6.3 now.
<DC-IRC>
<c0rnelius> along with the cm dtsi
<DC-IRC>
<rpardini> good to hear. I thought these CM alternatives would be more popular a year ago.
<DC-IRC>
<c0rnelius> yeah I don't have the hw myself. someone just asked me to look into it. looks like a nice little board.
<DC-IRC>
<c0rnelius> except all the leds it has. my goodness.
<DC-IRC>
<c0rnelius> @rpardini oh yeah. I got that overlay working for the N2 spi.
<DC-IRC>
<rpardini> oh nice
<DC-IRC>
<rpardini> it does slow down the eMMC right, so can't be default...
<DC-IRC>
<rpardini> but yeah useful to deinfest machine from petitboot isnt it.
<DC-IRC>
<c0rnelius> very much so. thanx for pointing it out. if only to remove pboot.
<DC-IRC>
<rpardini> I think it's the exact same for the VIM3
<DC-IRC>
<rpardini> although I never got uboot working from SPI on the VIM3, for lack of interest / builtin emmc.
<DC-IRC>
<c0rnelius> would be kind of pointless under that circumstance 🙂
<DC-IRC>
<rpardini> nah, it would be nice to boot SPI to NVMe on the VIM3... but yeah, the eMMC not going anywhere, so might as well boot from there.
<DC-IRC>
<rpardini> awesome. I'll be stealing that and more from `pyavitz/debian-image-builder` very soon 😉
<DC-IRC>
<rpardini> very soon being, a lie. eventually.
<DC-IRC>
<c0rnelius> take whatever 😉
<DC-IRC>
<c0rnelius> thats why its there
<TRS-80>
Hopefully licensed appropriately. :)
archetech has joined #armbian
<DC-IRC>
<c0rnelius> i don't have one on my github
zeemate has joined #armbian
<DC-IRC>
<c0rnelius> i mean... if i was doing anything shifty I would just keep everything to my self.
<TRS-80>
That's not the point. The way copyright works is that you retain all rights unless publishing under some license that says otherwise. Now of course, chances of anything coming of it are slim. However, them's the rules. It's actually a common misconception.
<DC-IRC>
<c0rnelius> i don't (C)
<DC-IRC>
<c0rnelius> nothing
<DC-IRC>
<c0rnelius> not even my scripts
<TRS-80>
In almost all countries, you have one by default. That's how it works. Unless you have published a license stating otherwise. Which is the problem with these 'do what you will' and other nonsense licenses. They aren't actually legal (to some extent or another).
<DC-IRC>
<c0rnelius> I'm to lazy 🙂 so yeah the GitHub suffers from laziness
Unit193 has joined #armbian
<TRS-80>
Normally I would say 'choose what license you want' however Armbian build system is GPL-2.0 so you might want to follow that for compatibility reasons. https://www.gnu.org/licenses/gpl-howto.html
<TRS-80>
A more permissive license would actually be fine as well.
<TRS-80>
wait a sec let me double check that before I spread BS
<DC-IRC>
<c0rnelius> in this use case I find it would be disingenuous. all the tools I'm using are spoken for and licensed already.
<TRS-80>
Oh are your repos just clones? If so they probably have licenses. But if they are your own work, you should (strongly) consider publishing a license.
<DC-IRC>
<c0rnelius> i get what ur saying, but its whatever to me. If I felt like I was doing something completely original I would of course stamp it.
<DC-IRC>
<c0rnelius> the builder isn't a clone.
<TRS-80>
But you pieced it together from other places, maybe plus some of your own work? If so maybe license it under appropriate (upstream) license.
<DC-IRC>
<c0rnelius> Which goes to my point. Its bash. There are of course parts in the builder that look like other bash scripts. Kind of hard to get around that. Also I find inspiration by looking around. Same could be said for the Makefile. How many diff ways can I write the Makefile?
<DC-IRC>
<c0rnelius> Should I license the README too?
<TRS-80>
But that's a different question. Which only matters if you worked at Oracle and then left and wrote a very similar competing product. Then people are talking about 'clean room implemetation' and 'tainted' and stuff like that. None of which applies here.
<DC-IRC>
<c0rnelius> How about (C) how my bash script flashes a u-boot binary? I mean it starts to become absurd.
<DC-IRC>
<c0rnelius> YEah. None off it applies indeed.
<TRS-80>
You can license documentation separately but for what we are talking about it's fine just to put one COPYING file in the root of the project, as described in first link I posted.
<TRS-80>
However saying that's separate issue does not negate my original and main thrust which is: without specifying /some/ license, your published work is by default, Copyright.
<DC-IRC>
<c0rnelius> Only time I have bothered following licensing protocol is when I was doing Icons and such or theming as it made more sense there.
<DC-IRC>
<c0rnelius> whatever u say... I mean. I'm using works that follow a license. It is by default using the license those works do. Putting a (C) one a bash script in my opinion is a step to far. But peps can do what they want.
<DC-IRC>
<c0rnelius> If they wan't their name all over everything. So be it.
<TRS-80>
It's not about vanity, it's about publishing. If it's your real name you are worried about, I do not publish anything under mine. But I do publish under a license.
<TRS-80>
Of course that falls apart quickly if it ever goes to court. But chances of that are slim to none with little hobby projects like we are talking about here.
<DC-IRC>
<c0rnelius> 🙂
<DC-IRC>
<c0rnelius> yeah. no one cares
<TRS-80>
In a practical sense, you are mostly right and it doesn't matter. However that doesn't change what the law actually is. Especially if we are on public record here as copying any parts of that into Armbian, which is a GPL-2 licensed project.
<DC-IRC>
<c0rnelius> i've never once had anyone ask me before booting an img. Is this properly licensed? I mean the scripts and all that jazz?
<DC-IRC>
<c0rnelius> The kernel is licensed.
<DC-IRC>
<c0rnelius> u-boot and whatever
<TRS-80>
Because just using the software is less of a concern. Copying it, especially into a licensed project, is a whole another matter.
<DC-IRC>
<c0rnelius> all we are all doing for the most part is editing and injecting code to make it work for our use case.
<TRS-80>
The main conception I wanted to correct was that by default everything is Copyright, as that's common misconception. What you do after that is up to you and I really don't want to waste any more time arguing about it.
<TRS-80>
*mis-conception
<TRS-80>
Although, in particular, if it goes into Armbian, which is GPL-2 licensed project.
<TRS-80>
Just something to be aware of.
<DC-IRC>
<c0rnelius> a coping license would probs make more sense in this use case.
<DC-IRC>
<c0rnelius> copying*
<TRS-80>
I think so. But the word 'COPYING' for the license file is mainly a Gnu convention, AFAIK. You can also call it 'LICENS' or whatever. But those are common ones.
<TRS-80>
LICENSE, sorry
<TRS-80>
Chances of anything coming of it, again, are slim to nil. But that doesn't change how it works.
<DC-IRC>
<c0rnelius> tobetter just uses the copying license in his repo and he is HK dev.
<DC-IRC>
<Tenkawa> @TRS-80... in the end... if some is following copyrights for using others work and doesn't want to take credit or to add any new ones for their work.. they are "not" required to... that is their own choice
<TRS-80>
Well in that case they should just reproduce in their repo whatever license(s) exists for upstream work.
<TRS-80>
Otherwise, as published, it is under Copyright.
<TRS-80>
(with no license)
<DC-IRC>
<c0rnelius> TRS-80 just likes going on about this. He was doing this like two years 😄
<TRS-80>
Pardon me c0rnelius, do you have a moment to hear the words of our Lord and Saviour rms? :D
<DC-IRC>
<Tenkawa> TRS-80: I don't so leave my sanctity be
lemonzest has quit [Quit: WeeChat 3.6]
Suspect has quit [Ping timeout: 252 seconds]
junaid_ has joined #armbian
junaid_ has quit [Remote host closed the connection]