Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Forums Feed: #armbian-rss | This channel is logged -> irc.armbian.com
drobo_00 has quit [Ping timeout: 256 seconds]
<ArmbianTwitter> @laubwicht (Laubwicht): it´s out of date but, i try to install a Quake3 dedicated Server on Orange Pi One plus, running Armbian. Is ther any HowTo ou there? This installation drives me crazy 😐 https://t.co/LaH6yCW6CZ (25s ago)
sdoran has quit [Ping timeout: 246 seconds]
sdoran has joined #armbian
<ArmbianTwitter> @iKenwright (Duncan Kenwright): Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t.co/jYvVN5o3ev https://t.co/0uOtMK6vrz (24s ago)
sdoran has quit [Ping timeout: 265 seconds]
sdoran has joined #armbian
mirage335 has quit [Ping timeout: 252 seconds]
mirage335 has joined #armbian
xec has joined #armbian
lykt has quit [Quit: leaving]
xecuter has quit [Ping timeout: 256 seconds]
chewitt has quit [Quit: Zzz..]
chewitt has joined #armbian
lykt has joined #armbian
sassinak-work has quit [Ping timeout: 252 seconds]
sassinak-work has joined #armbian
<ArmbianTwitter> @Brombeerkatze (ShadowSpirit): RT @laubwicht: it´s out of date but, i try to install a Quake3 dedicated Server on Orange Pi One plus, running Armbian. Is ther any HowTo… (31s ago)
<Werner> Good morning.
<ArmbianTwitter> @DieZuckerbude (Ben Zucker 🍰): Building #ioquake3 for #arm64 architecture on @armbian https://t.co/vEKqltGrXp (25s ago)
IgorPec_ was kicked from #armbian by Werner [IgorPec_]
retropikzel has joined #armbian
<IgorPec> morning
<ArmbianTwitter> @thepine64 (PINE64): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (20s ago)
<ArmbianTwitter> @marosuke2600_d (まろまろ先輩(NoizNeko)@バ-チャル大学生): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (26s ago)
<ArmbianTwitter> @armbian (armbian): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (25s ago)
<ArmbianTwitter> @r_theren (RTheren): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (16s ago)
<ArmbianTwitter> @sahajsarup (Sahaj Sarup @ home): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (25s ago)
Toast has joined #armbian
macc24 has joined #armbian
archetech has quit [Quit: Leaving]
sassinak-work has quit [Remote host closed the connection]
sassinak-work has joined #armbian
piter75 has joined #armbian
count-doku has joined #armbian
<count-doku> Morning
<IgorPec> hej
<Werner> Hi
<IgorPec> how are you today?
<count-doku> Fine. Beautiful weather outside, had my morning coffee :D
<IgorPec> yeah, nice and calm aroun here too
<IgorPec> nobody around
<IgorPec> it seems we didn't set a good hour for US west coast folks :(
<IgorPec> sfx2000 will need to get up early :)
<count-doku> yeah on the other hand guys like gprovost will need to stay up until like midnight
<IgorPec> yeah, i know. its difficult since we are scattered around
<count-doku> it is. I will be afk for some time, work to do for 'rl job'. Till later
<IgorPec> ok
JMCC has joined #armbian
JMCC has quit [Client Quit]
JMCC has joined #armbian
JMCC has quit [Client Quit]
<ArmbianTwitter> @BrianLinuxing (Brian Linuxing 🇮🇪 🇪🇺💙 #StayInDoorsWithLinux): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (9s ago)
rotaticus has joined #armbian
IgorPec has quit [Remote host closed the connection]
JMCC-teacupx has joined #armbian
JMCC-teacupx has quit [Quit: Leaving]
IgorPec has joined #armbian
IgorPec has quit [Changing host]
IgorPec has joined #armbian
JMCC has joined #armbian
JMCC has quit [Client Quit]
JMCC-teacupx has joined #armbian
<JMCC-teacupx> exit
JMCC-teacupx has quit [Client Quit]
<ArmbianTwitter> @IMineBlocks_com (IMineBlocks ⛏️): @iKenwright @armbian @RosettaAtHome @thepine64 @theC4Labs Can you provide a little more detail on the hardware used. The board & compute units that you have. Thankyou. (15s ago)
Siraj has joined #armbian
Siraj has left #armbian [#armbian]
Siraj has joined #armbian
Siraj has left #armbian [#armbian]
<ArmbianTwitter> @erchache2000 (erchache2000): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (7s ago)
rotaticus has quit [Ping timeout: 260 seconds]
sassinak-work has quit [Ping timeout: 260 seconds]
sassinak-work has joined #armbian
Siraj has joined #armbian
Siraj has quit [Remote host closed the connection]
<ArmbianTwitter> @BarnesSW (Sean Barnes): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (5s ago)
rotaticus has joined #armbian
gprovost has joined #armbian
macc24 is now known as maccraft
maccraft is now known as maccraft123
maccraft123 is now known as macc24
martinayotte has joined #armbian
JMCC-teacupx has joined #armbian
<JMCC-teacupx> Hi there
<Werner> Hello
<JMCC-teacupx> I guess you already finished, didn't you? Sorry, I could not make it earlier.
chewitt has quit [Quit: Zzz..]
<count-doku> no starts in half an hour
<count-doku> @igorpec can you explain how https://github.com/armbian/build/pull/1856 would work?
<IgorPec> hi
<IgorPec> well, we keep hearing that this and that feature from mainstream kernels is missing
<IgorPec> this is an attempt to merge down all common features
<count-doku> ah so as an example, lets say I would do that for mvebu. Than I would just take your PR branch, and try to get the mix between upstream kernel config and our kernel config with maximum enabled modules?
<IgorPec> actually this job is not per family, but per section
<IgorPec> since its mainly the same accross the kernels, especially now at 5.4
<IgorPec> we can skip this job for older kernels
<count-doku> but our kernel configs are still per family?
<IgorPec> yes, if you sort out "USB media drivers" for mvebu its more or less a copy paste job to do the same in all others
<IgorPec> and lets say in a year, there will be one config
<IgorPec> all this job merged
<count-doku> ok so if I took "General Setup -> Networking Options" I would try to get the upstream config integrated in all family configs for that part?
<IgorPec> JMCC-teacupx: no, we haven't started yet ;)
<IgorPec> in 20 minutes
<count-doku> How would we do board/family specific kernel changes then? With patches?
<IgorPec> board/family kernel features we don't change ... which is why we have separated files
<IgorPec> i hope one day we will be able to merge them. now we can't
SteeMan_ has quit [Quit: This computer has gone to sleep]
<IgorPec> withour rework
SteeMan_ has joined #armbian
<IgorPec> family specific features you don't change. everything else
<count-doku> ok got it now
<IgorPec> and that everthing else must be identical with sunxi, meson, mvebu, ...
<count-doku> yeah. My main worry was, if there is some family specific kernel feature which needs to stay _disabled_ it might get enabled when pulling down changes.
<count-doku> Like for mvebu enabling PCIe breaks pcie :D
Miouyouyou has joined #armbian
<Miouyouyou> Meow
<IgorPec> yeah, which is why we have to do it with care and not merge without review
<IgorPec> meow
<IgorPec> cound-doku: https://armbian.atlassian.net/browse/AR-182 perhaps add worries as a comment
<Miouyouyou> No catches on the "Crash dump" line. So, I guess I'll just check for Kwiboo V4L2 patches and check what's the issue with Tinkerboard networking.
<IgorPec> but are there other reports of networking problems, can you replicate?
<Miouyouyou> I've hit a few SSH issues with the Tinkerboard, but I'll need to do some client/server test between my PC and the Tinkerboard just to be sure
Siraj has joined #armbian
<Miouyouyou> What worries me more are the HDMI issues, and the fact that I heard Ayaka (Randy Li) complaining about how clocks definitions were broken on mainline kernels. That might explain the intermittent Ethernet issues, as I'm pretty convinced that Ethernet peripherals require very accurate clocks.
<ArmbianTwitter> @0xDEADBEEFCAFE (Ricardo B): @iKenwright @RosettaAtHome @armbian @thepine64 @theC4Labs Is that a stack of clusterboards? (21s ago)
chwe_ has joined #armbian
chwe_ has quit [Client Quit]
chwe_ has joined #armbian
<IgorPec> we start few minutes past 3pm, but you are welcome to say hi at anytime - to check who is around
<gprovost> Hi @IgorPec so you are going to call each of us to give a small status report ?
<chwe_> hi, but only half here..
<Miouyouyou> Oh, so it's ch|we
<chwe_> or chv|ve_ cause chwe was already occupied.. :D
<Miouyouyou> You could go all l33t and go ch|w3 :3
<Werner> Just tell me if you decide to register a nick at Freenode so I can assign auto voice for any well-known community member and/or contributor. You can also request a project affiliation cloak.
raver has quit [Read error: Connection reset by peer]
<Miouyouyou> I did it. Else I couldn't join #linux-rockchip ... Which is as dead as ever
<piter75> Hi!
<gprovost> Ok good then I will talk for marvell when it's our turn, will be the right time to ask who is in charge of marvell arm64 :P
<Miouyouyou> Hi!
<IgorPec> piter75: martinayotte: lanefu: Siraj: alive?
<Miouyouyou> I have "the voice !"
<Werner> Indeed.
<Siraj> Hi, I am siraj, just joined the armbian
<Miouyouyou> Hello Siraj
<IgorPec> hi
<IgorPec> well, i will just started since first part is anyway just acking who is here. i never saw this many armbian folks in this channel before :) great!
<IgorPec> I would welcome you all and I hope next time we will not need to type. We will discuss which technology we might use next time by the end of the meeting
<Miouyouyou> Pidgeon carrier technology, for the future !
<IgorPec> 2. Release officier. Me and Lane were already doing this job which is now almost well documented. Main thanks goes to @lanefu for producing the document based on our go triough
<IgorPec> is there anyone that wants to experience this role for the upcoing release or me and Lane will need to throw a coin :)?
<IgorPec> i give you few minutes to scan the docs
* Miouyouyou looks at the coin
<IgorPec> free to ask questiin / don't toch the coin :)
<Miouyouyou> oooh :C
<count-doku> that coin has a lot of sides
<Miouyouyou> It's almost like a D100
<IgorPec> the job is to supervise the ongoing release cycle ... ok, we can also get back to this later on.
<gprovost> Nice documention
<IgorPec> now, i would like to call out for groups about what they are doing. If you can, you are welcome to ajust Jiras (that I will have less work with this later on)
<IgorPec> starting with
<IgorPec> allwinner:
<IgorPec> @martinayotte works on upgrade to 5.6.y
<IgorPec> Perhaps Martin is not around. Anyone alse from the Allwinner group?
<IgorPec> I am mainly working on bugs and testing new boot loader
<IgorPec> then @gprovst an update on your side?
<gprovost> ok then
<gprovost> so for MARVELL familly
<gprovost> For mvebu family, we have 2 pretty forward issues that already listed in Jira.
<gprovost> - AR-159 use RTC instead of fake-hwclock (assignee : gprovost)
<gprovost> We will try to close the few other issues listed on github mvebu project page : https://github.com/orgs/armbian/projects/3 and add them first in Jira next week, they are not crucial to 20.05 and still need to discuss with mvebu team what we want to do.
<gprovost> - AR-150 disable debian stretch build for helios4 now that OMV5 is released as stable (assignee : count-doku)
<gprovost> Then, as questioned by count-docu above, we are expected to test and confirm everything is alright on Clearfog and Helios4 for AR-182 'WIP: Merge kernel features from upstream'
<gprovost> That's all for mvebu, no blocker or timing issue in order to complete the above work for 20.05 relrease.
<gprovost> Another small task, since we have our new board helios64, we will be renaming our github repo from helios4 -> kobol therefore we will need to update the pointer in armbian build for helios4 u-boot legacy (assignee : gprovost).
<gprovost> @count-doku, do you want to add something ?
<count-doku> yeah some question for disabling stretch
<gprovost> Yes ?
<count-doku> do we just disable automatic image creation or disable supported building via build script?
<gprovost> just disable auto image creation
<count-doku> ok
<IgorPec> how is situation with u-boot at mvebu family? can be upgreated to latest?
<gprovost> Well first I was thinking we can get ride of the legacy
<count-doku> Looking good for Helios4, not so good for Clearfog. See todo here: https://github.com/orgs/armbian/projects/3
<martinayotte> @IgorPec: I'm here, but need another coffee first ...
<IgorPec> martinayotte: ok, np. hold on
<IgorPec> count-doku: ok, then defenetly not for the 20.05
<chwe_> martinayotte: you can have mine.. I'm on the 10th or so.. :D
<IgorPec> count-doku: gvprovst: anything else specific for mvbebu?
<gprovost> Not really
<count-doku> I think we could maybe get helios and clearfog on the same uboot and drop legacy till 20.05, or @gprovost?
<gprovost> yes i agree
<IgorPec> ok, great. if you come up with anything, bring it up by the end of this session
<count-doku> But mainline uboot not possible till 20.05
<count-doku> One more thing
<gprovost> all on Uboot v2019.04
<count-doku> nvm.
<gprovost> ok then i have a question to Igor
<IgorPec> ok
<gprovost> who is in charge of mvebu64 ?
<gprovost> Will nice to know what's the status on this
<IgorPec> it was ... one moment
<IgorPec> ebin-dev
<IgorPec> he was taking care for espressobin for some time, but haven't heard from him lately
<count-doku> Hmm he's also not in the boards-marvell team: https://github.com/orgs/armbian/teams/boards-marvell
<IgorPec> and there we have a CSC contribution for Machiattobin
<IgorPec> not very alive
<IgorPec> but there is nothing to be done in this regard. IIRC sfx2000 had some ideas to bring up this new repacked Espressobin
<IgorPec> but that's about it. Let's move on.
<IgorPec> actually let's move back to @martinayotte
<gprovost> ok
<IgorPec> martinayotte: ping
<count-doku> ping timeout...
<Miouyouyou> Not enough coffee
<IgorPec> hehe :) it seems coffee doesn't function yet
<IgorPec> yes, then let's move on to Rockchip.
<Miouyouyou> Such a nice platform...
<IgorPec> Miouyouyou: Chwe_: Tonymac32: Piter75:
<IgorPec> 32bit stuff first, Tinkerboard
<Miouyouyou> This is getting easier now. There's a few network issues... And no official software support for the staging VPU driver.
<Miouyouyou> Aaaand HDMI timings maybe ? Saw the poor guy with his HDMI/VGA adapter, it sure must be hard to work with a screen with a big black hole on the center.
<IgorPec> :) yeah. I assume those troubles are all related only to current mainline kernel, right?
<IgorPec> and you have checked in most recent upstream mainline kernel if anyone doing something?
<Miouyouyou> Yeah, mostly. I wouldn't bet too much on the HDMI clock timings, though, since I'm not sure that people like mmind test these boards with "weird" screens setups.
<Miouyouyou> Mainline support for RK3288 mostly focus on Chromebooks.
<IgorPec> HDMI2VGA is certainly not a top priority issue, yeah
<chwe_> don't think so..
<Miouyouyou> So VPU/GPU will come. HDMI... not so much. Though, I had a patch at one moment that diverted the timings definitions to the DTS file
<martinayotte> IgorPec: I'm back with my cup of coffee ...
<chwe_> 1920x1080.. and I guess they're mostly happy.. :-/
<IgorPec> (proceed to 64bit rockchip at will)
<Miouyouyou> Yeah
chewitt has joined #armbian
<IgorPec> matinayotte: we are at Rockchip, join with ideas or wait until this speach is out, then we go to Allwinner
<chwe_> who else from rk is here?
<piter75> I don't have any ongoing tasks right now but the long term goals I am looking at are:
<piter75> reducing the fragmentation of 64bit families (u-boot, legacy kernels)
<IgorPec> chwe_: piter75 and tonymac32
<Miouyouyou> For RK3399, I've just reinstalled mine today so I can't really check for many things. I'll just try Kwiboo patches, see if they lead somewhere in terms of Video Decoding.
<gprovost> BTW for Rockchip, aprayoga will soon join the effort on Armbian since Heliso64 is based on RK3399
<piter75> @gpr
<JMCC-teacupx> Miouyouyou: Do you know if any work is being done for VPU encoding support on mainline?
<piter75> @gprovost nice to hear that :)
<gprovost> You will start to see us getting involve in the coming weeks
<IgorPec> and we have some stability issues on Rock64
<Miouyouyou> JMCC-teacupx, I see a few patches here and there, but the software support is still fairly missing, which might be the real issue now.
<chwe_> IgorPec: due to? rock64 had quite some iterations didn't it?
<Miouyouyou> But Kwiboo seems to have a working setup, so I'll see.
<IgorPec> chwe_: don't know yet. there are some forum posts which are in uknown state. ahh, i see rockpro64 https://forum.armbian.com/topic/12861-last-effort-regarding-rockpro64-kernel-panics/
<IgorPec> but its legacy kernel
<JMCC-teacupx> Miouyouyou: I can't find the "like" button on this darn IRC thing, but consider that as "liked"
<Miouyouyou> Yay !
* Miouyouyou 👍
<IgorPec> Merging RK3399 and Rockchip64 ... to make MALI works. Do we have an agreement and plan for that?
<Miouyouyou> On which kernel do you want to merge Mali ?
<Miouyouyou> On 5.4 it might be still be doable
<JMCC-teacupx> No, it's on legacy
<Miouyouyou> After that... I'll have to check with the latest kernel drivers provided by ARM, but... it's really becoming a pain.
<Miouyouyou> Oh ok
<chwe_> for this release I would only bring them to the same kernel source
<chwe_> without a merge yet.
<Miouyouyou> "One kernel to boot them all"
<chwe_> someone ever tried to load mali as module? to avoid the mess?
<IgorPec> chwe_: explain ... to solve the diffs with patches?
<Miouyouyou> Yeah... I think it depends on symbols that are not exported anymore. So you might have to add a few "exports" here and there in the kernel.
<chwe_> as far as I know.. as soon as you've mali for rk3399 and rk3328 in the same kernel it messes up right?
<JMCC-teacupx> Well, it did, more than a year ago
<chwe_> rochchip64 is based on friendly arms kernel
<JMCC-teacupx> Maybe Ayufan sorted out the mess upstream already, I didn't check
<chwe_> rk3399 on ayufans
<chwe_> so first we would both bring to one of them..
<piter75> chwe_ it's the other way round
<JMCC-teacupx> We could start by trying all RK33XX with Ayufan's and see if we are lucky
<piter75> but that's the first fragmentation point
<chwe_> and then in the follow up releases we could adjust the patches to get 'one kernel'
<chwe_> next would then be 'one u-boot'.. and then we can merge..
<JMCC-teacupx> piter75: Can you elaborate on that?
<chwe_> and let Miouyouyou sort out the mali mess.. :P
<Miouyouyou> Yeah, by the time Panfrost will be stable anyway :3
<piter75> I meant rk3399 is FriendlyARM's and rockchip64 ayufans
<IgorPec> yes, this is correct
<chwe_> well but you don't wanna backport panfrost to 4.4 kernel right? (for mainline, they already share the same patchset and sources)
<Miouyouyou> I was able to run glmark2 using the panfrost driver and DRM on a Tinkerboard
<IgorPec> on mainline kernel?
<JMCC-teacupx> Yes, and that is why I think that, in case we choose one of them for merging, it shoud be Ayufan, since he is also supposed to support rockPro64
<Miouyouyou> Oh, on the 4.4 I remember they used a specific part for Mali ? The definitions are not in the DTS
<Miouyouyou> I tested it with a mainline kernel, yes
<martinayotte> Let's try to get rid of Ayufan since he didn't do any commits since Oct 2019
<piter75> I am leaning towards ditching ayufan's legacy kernel and moving to FriendlyARM's as a first step and maybe
<piter75> martinayotte +1
<piter75> and maybe to Rockchip's BSP if it fits us
<Miouyouyou> Anyway, what's the issue with Mali on 4.4 kernels ? If you compile it as a module it crashes, or... ?
<piter75> chwe_ mentioned trying rk1808 and it will not be possible with ayufan's
<JMCC-teacupx> RK's BSP could be a good choice, since they have stable tags
<chwe_> well ayufan is more or less inactive for a while now.. if we want to add other rk SoCs in the future a new home for us will be needed anyway.. :D
<ArmbianTwitter> @DieZuckerbude (Ben Zucker 🍰): Setup #Quake III Arena dedicated server on #ARM64 platform using #ioquake3 and #armbian. https://t.co/HdkLsdksqa (9s ago)
<piter75> I am supporting RK3308 and had to use Rockchip's BSP as base
<Miouyouyou> Yay ! DOOM 3 ! Oh no, wait, Quake 3.
<JMCC-teacupx> Miouyouyou: Last time we tested, when you enabled both mali Utgard and Midgard, led to some conflict that broke the devfreq driver
<piter75> we could use stable branch/tags as JMCC-teacupx says
<JMCC-teacupx> IIRC, it was even when you put them as modules
<Miouyouyou> JMCC-teacupx, Ah... I guess that you'll have to check for the "compatible-with" entries in the drivers, in order to avoid them loading simultaneously for the same hardware.
<JMCC-teacupx> I mean, the board worked, but GPU was working at half speed, due to broken devfreq
<piter75> I could take on trying to move rockchip64 legacy to FriendlyARM's for v20.05 but would need some rk3328 testers for that ;p
<chwe_> how often does friendlyarm pull from rockchip?
<chwe_> or do we run into the same then again?
<piter75> when they release something so it will be stale again
<JMCC-teacupx> IMO, for legacy BSP kernels the best is to stick with a tag/stable branch, and focus our work on mainline, as we are doing with the Tinkerboard
<piter75> FriendlyARM is used with rk3399 so it will be a lesser change
<IgorPec> ok, so make sense to start with a https://github.com/rockchip-linux/kernel
<chwe_> someone not enough to do so that he can maintain a kernel for us.? :P
<piter75> ok, let's move them both to rockchip-linux but that will be hard for v20.05
<chwe_> piter75: I guess that would be impossible..
<Miouyouyou> JMCC-teacupx, Did the issue also happen when setting the clock rate manually through the sysfs entries ?
<IgorPec> chwe_: what seems impossible?
<chwe_> maybe leave that AS IS and work on this over two releases?
<JMCC-teacupx> Miouyouyou: It just would not let you do it, it stuck with some frequency that was not even listed in available_freqs
<chwe_> move rk3399 and rockchip64 to https://github.com/rockchip-linux/kernel in this release
<JMCC-teacupx> chwe_: +1 to leave it for the following release
<chwe_> there's quite some work from ayufan which we would to bring in..
<IgorPec> I belive this rockchip split / merge / upgrade is going over the scope of this meeting
<Miouyouyou> JMCC-teacupx, Ah... This might be due to the driver not using the DTS definitions, but using some specific files added into the kernel tree. That's what they did on the Rockchip BSP, and the frequencies are listed in there, IIRC. Basically, you can write your own frequency scaler and add it to the driver.
<IgorPec> let's discuss this furthert on forum. there are a few other things we should go trought
<chwe_> well then leave 4.4 for the moment.. and bring mainline to 5.6 would make sense for this release..
<IgorPec> agree, let's focus to 5.6 with RK for 20.05
<piter75> chwe_ +1
<martinayotte> +1
<IgorPec> martinayotte: Allwinner
<IgorPec> how far we are, any deep troubles you have, ...?=
<martinayotte> I'm currently doing my Allwinner Garden tour, and maybe commit for 5.6.y will come tomorrow of Monday ...
<martinayotte> s/of/or/
<IgorPec> ok, if you need any hand, i can step up
<IgorPec> a lot of my (dirty) patches are my work ;)
<martinayotte> Great ! BTW, my tour is almost only headless, so no fancy testing, but since it is for DEV, no worries ...
<IgorPec> yes, it would be fine to bring up video and 3d but also not sure if we have a dedicate person working on that
<IgorPec> what about u-boot upgrade? have you tried anywhere?
<IgorPec> i only did some testingws with A20 / 2020.04RC4
<martinayotte> I've tested OPi3 and OPiPC+ until now. Today will be OPi+2E and OPiWin and maybe more
<IgorPec> is there a viable chance to upgrade u-boot in this release?
<IgorPec> to upcoming 2020.04
<IgorPec> or to at least 2020.01 ?
<martinayotte> I'm always working on head, so it is currently 2020.05
Saurabh009 has joined #armbian
<IgorPec> 2020.05 right, perhaps too close. well
<IgorPec> well, let's move on to general stuff
<IgorPec> meson64: anyone doing something? I have updated mainline for N2/C2 , sound on N2 needs adjustements
<IgorPec> Changing download images compression format
<IgorPec> opinions on=
<martinayotte> I've N2/C2/K2 boards, but didn't updated since weeks/months
<IgorPec> Marton: ok, no problm. Shall we drop 7z for gz?
<JMCC-teacupx> What is the reason behind it? Compatibility with USB imager?
<martinayotte> I think so ...
<IgorPec> the reason is to make it simpler for users
<IgorPec> 7z is not compatible with Etcher neither
<JMCC-teacupx> Oh well, I was always for this idea, even back then with Etcher, so +1 for it
<JMCC-teacupx> But, does USBimager not support .xz?
<martinayotte> +1 for me too
<JMCC-teacupx> That saves about 15-20% bandwith
<gprovost> USBimager ?
<martinayotte> I use it twice, seems to be Ok
<count-doku> New supposed cool tool for flashing sd card images
<IgorPec> USB imager is only partially related to this. It has to work fine with Etcher and USBimager
<gprovost> do you have a link to this USB imager tool
<JMCC-teacupx> So .xz has the high compression ratio of .7z, and can be flashed directly with Etcher
<JMCC-teacupx> Not sure about the new USBimager, didn't use it
<gprovost> thanks
<IgorPec> going away from 7z means we don't store more files in the archive
<IgorPec> SHA and SIG must be separate
<IgorPec> that's the main diff, unpack and burn at once will probably be supported in both imager programs
<IgorPec> and USBImager supports "on-the-fly: .gz, .bz2, .xz" ... so technically its not diff, chexking is enabled
<IgorPec> by default
<JMCC-teacupx> If we want to make it easier for the novice user, the fact is none of them does SHA sum check, so it won't make a difference for them
<JMCC-teacupx> And advanced users can download the shasum file separately, as they do with so many other things
<IgorPec> right, it will be just better UX design, nothing elese in the essence
<IgorPec> ok, if none is against, this will be changed when possible
<IgorPec> next
<JMCC-teacupx> But, just to make sure it didn't get lost in the messages, I vote for .xz if it is supported by USBimager
<IgorPec> this can be done already for 20.02.x version
<IgorPec> JMCC: ok, both are supported
<JMCC-teacupx> well, pigz and pixz have the same syntax, it would be just changing a letter
<IgorPec> OK, xz then.
<IgorPec> next
<IgorPec> Ubuntu 20.04 and Debian Bullseye for all?
<IgorPec> Now, in 6 months ?
<IgorPec> they are both ready to roll, but support status will remain not-supported
<IgorPec> until final release
<IgorPec> Creating images with GPT parititon
<IgorPec> ... a few more and we are done. I go to make a coffe in the mean time
<Werner> Are there considerable advantages from GPT over MBR?
<martinayotte> Partition ? Maybe it should be a choice in Armbian menu or cmdline ...
<IgorPec> you can extract armbian directly to 2G+ partition
<IgorPec> i am asking what will break if we set it default?
<IgorPec> legacy kernels are gone ...
<Miouyouyou> Aren't GPT issues more a bootloader thing than anything ?
<IgorPec> i would say so, yes
<IgorPec> if we don't know, an experiment and research is needed
<Miouyouyou> Most chromebooks use GPT, so for these boards, it will be handled.
<martinayotte> Probably there are some unknown
<Miouyouyou> I'm pretty sure that Android systems used GPT or cmdline partitioning, and don't care about old DOS partition mechanisms.
<IgorPec> right, let's make few tests on the way
<IgorPec> please make a comment if you find out something to that Jira
<Miouyouyou> Alright
<IgorPec> "board status update on download pages and build engine (wip, supported, eol)"
<IgorPec> Any complains about statuses: https://www.armbian.com/download/
<IgorPec> "decide upon best meetings hours and technology" and "misc / open discussion" is all what is left on the agenda
<JMCC-teacupx> I think this time may be a little too early for people in the Americas
<Miouyouyou> Well, first, we have to determine the time zone of every member
<martinayotte> Nothing to say on my side, except maybe 1 hour later would be better for having enough coffee :-P
<IgorPec> @gprovost what is your last possible hour?
<Miouyouyou> Maybe 6PM GMT could do it for Americans.
<Miouyouyou> I don't know if we have Asian members.
<martinayotte> My time zone is EST/EDT
<martinayotte> been currently 10h25 AM
<Miouyouyou> I'm on GMT+2
<count-doku> GMT+2
<JMCC-teacupx> GMT+2 too
<Werner> GMT+2 as well
<gprovost> GMT+9
<gprovost> sorry GMT+8
<Miouyouyou> Australia ?
<gprovost> Singapore
<IgorPec> 11pm your local time is too late for you?
<IgorPec> to start a meeting
SteeMan_ has quit [Quit: This computer has gone to sleep]
<gprovost> It depends when, if week days I'm ok.
<count-doku> Saturday. Is about next meeting
<Miouyouyou> "I want my sleep during the weekends"
SteeMan_ has joined #armbian
<gprovost> I mwan if it's once in while I'm ok
<gprovost> don't worry since i'm about the only on Asia side
<Miouyouyou> 13pm GMT (10pm GMT+9 then) ?
<gprovost> I'm ok with 1pm or 2pm GMT ;-)
<IgorPec> 2pm GMT is 7am for US east coast
<gprovost> Anyway we are also going in lockdown mode, so i won't be out for the next 4x Saturday :P
<Miouyouyou> Yay ! Lockdown mode !
<IgorPec> which is why we can meet here :))
<Miouyouyou> It's an international trend !
<gprovost> Hehe, yeah well i don't like this trend :P
<Miouyouyou> Ooooh :C
<IgorPec> ok, next meeting 2 pm GMT time. what about technology? shell we use multimedia?
<gprovost> personally i think audio is going to be awkward
<IgorPec> and which, if
<Miouyouyou> Shall we use "Skype ? Discord ? Slack ? Rocket.chat ? qTox ? AnotherTechnology ?"
<Miouyouyou> Or plain IRC
<IgorPec> gprovost: why :) perhaps true, just asking at this point. i am also just fine with IRC
<JMCC-teacupx> If we are on lockdown, we won't be shaved :D
<IgorPec> meeting routines can be improved
<gprovost> I have a thick french accent, you won't understand me
<IgorPec> i am shaved .)
<Werner> I have the Slack organization still set up. Still does not make sense if not everyone is fine with it.
<IgorPec> i have video meetings every day
<Tonymac32> hello miouyouyou
<count-doku> Slack vs IRC does not really make a big difference imho
<gprovost> I like slack or rocket.chat
<Miouyouyou> Hello Tonymac32
<gprovost> I agree
<IgorPec> oh hey Tony
<gprovost> i think IRC is fine for now
<gprovost> Ok guys i'm checking out
<gprovost> all the best to you
<Werner> IRC is also better for guests I think to just come in without registration and stuff.
<gprovost> stay safe
<IgorPec> good. great thanks goes to Werner for maintaing the channel and its goodies
<JMCC-teacupx> gprovost: good night, man
<Werner> It is a pleasure :)
<gprovost> night night guys
<Tonymac32> somehow my day job has continued to find10+ hours of things for me to do a day, sorry. And IRC is basic and works.
gprovost has left #armbian [#armbian]
<IgorPec> gprtovost: thank you for beeing around
<Werner> IRC is .great :P
<ArmbianHelper> great, adjective, synonym for Armbian
<JMCC-teacupx> LOL
<Tonymac32> ha
<IgorPec> there is more :)
<Werner> toys :D
<Miouyouyou> Oh, there's mattermost with IRC and Slack bridges too, just to add the confusion
<count-doku> @igor can you exend my wordpress rights so i can also edit helios page?
<IgorPec> Toymac32: stuff that you miss is the logs, perhpas we can hear you out now? what's going on with meson/rockhip
<count-doku> *extend
<Miouyouyou> Anyway, IRC at the moment
<IgorPec> cound-doku: yes
<IgorPec> moment
<Werner> I researched a bit about IRC Slack bridge but I gave up on it. Too much effort for little usefulness
<IgorPec> count-doku: done, perhaps you might need to logout/login
<count-doku> thanks
<Miouyouyou> I'll try to play with different chat systems and see how they work during the month
<Tonymac32> piter75 has been contributing most to rockchip 33xx boards, I don't have a lot of input there. Meson64 is looking pretty good, the HDMI stuff is probably unavoidable, I can see if anything in upstream can help the LTS 5.4
<Tonymac32> My rockchip 32xx boards have not demonstrated any weird display issues, even with my cursed HDMI->DVI Acer
<Werner> I am out for now as well. Need to do something to keep myself fit. See you later.
<IgorPec> tonymac32: tnx. also we have decided to move image compression to xz and drop 7z
<Miouyouyou> Yeah, but did you try HDMI->VGA with an old 800x600 CRT, hmm ? :3
<Miouyouyou> See you later Werner
<Tonymac32> miouyouyou haha no.
<IgorPec> werner. thanks, see you around
<Tonymac32> I would like to try to get N2 onto mainline uboot if someone more driven than me hasn't already done it.
<count-doku> How to get supported progressbar to 100%? https://www.armbian.com/clearfog/
<SteeMan_> As a newbie, that generally lurks in the TV Box sub-forum, I have concerns about the fragmentation between core Arabian and the TV Box builds, is this a concern for anyone else?
<Miouyouyou> You have to pay 1500 muffins
<IgorPec> that's kernel property
<IgorPec> count-doku
<count-doku> ah ok
DaRock has quit [Ping timeout: 250 seconds]
<Miouyouyou> Well, I don't own any TV Box myself
<count-doku> Sorry @SteeMan_ no core Arabian support here
<SteeMan_> For example while this chat was going on, balbes150 released a new build 20.05.1 which from a versioning perspective is very confusing
<Miouyouyou> And they tend to be even less supported than standard boards on mainline kernels (because most users don't even think about upgrading them).
<SteeMan_> and it concerns me that he wasn't online for this chat, as he drives a lot of the work over there
<IgorPec> SteeMan_: we are trying to get closer, but this task is gigantic
<SteeMan_> but he is mostly a one-man show
<IgorPec> nobody is prohibiting helping him.
<SteeMan_> I have offered, trying to figure out where my skills fit in
<Tonymac32> yeah, and from a philosophical point of view, TV boxes present a few issues the core Armbian user doesn't like, setup is usually a bit tricky (stick a toothpick into your Stereo jack and then do some voodoo with the Android recovery system, etc)
<IgorPec> our team is already way too small to control hardware which is possible to have control over ( documentation, vendor support)
<Miouyouyou> WARNING: Smashing the box from frustration might void your warranty
<Tonymac32> and TV boxes have 0 BOM/quality control a great majority of the time. that's why even when you know what TV box you have, you have to choose between 2-3 different DTB's, because the vendors change things randomly
<Tonymac32> actually, that reminds me of a certain 3k3328 board that haunts me
<IgorPec> ... which is frustrating and time consuming at least
<SteeMan_> Oh I understand the challenges, but I think there are some things with the website and documentation that could help newbies on the TV box side
<IgorPec> documentation about what?
<count-doku> Then propose your ideas / changes?
<Miouyouyou> 3328 : The haunting house
<Tonymac32> that SoC, and Rockchip... uuugh
<SteeMan_> For example I think I have seen and answered the same question in the forum about users trying to use armbian-config to copy to emac, but that process is different on the TV box builds
<SteeMan_> but no where is it clear to an end user that this is the case
<IgorPec> this means there is no support for eMMC
<IgorPec> and amrbian-config can't work without
<Miouyouyou> I suggest writing a small README.md in a github repository (or gist), and then opening a thread and try proposing a change to the documentation
<Miouyouyou> Don't hesitate to work on something and try to impose it. Most of the users impose us their problems without asking :3
<IgorPec> ... and find someone that will write documentation how to hack this and that tv box ... which is essentially a summary of Tvboxes forums
<SteeMan_> There is support for emmc, but the TV box way is to run a script located in /root manually - an example of the fragmentation happening
<Miouyouyou> TVbian
<IgorPec> that script is not a work of armbian
<IgorPec> its the work of someone that hacks tvboxes and put armbian on them.
<IgorPec> in most cases this is Oleg (balbes150) but it can be anoynone in the wilderness
<Tonymac32> yeah that is the diffivult part, it is about 80% armbian, the user space has a lot of brilliant work that is not ours in it
<JMCC-teacupx> SteeMan_ Please notice that balbes was invited to this chat, but for some reason he just could not make it. He is part of the team too, and a very relevand and appreciated member
<IgorPec> why we should allocate resources to write manual for the things we don't work with??
<JMCC-teacupx> *relevant
<Miouyouyou> Well, that's why I recommend writing first a README.md somewhere, with all the information. Then ask for integration. If it's not integrated, it's still a relevant documentation :3
<SteeMan_> I understand, but the perception of the general public is that it is, as the whole source of information on TV box support under Arabian occurs in the Arabian forum. So any newbie who googles that they want linux on their tv box will end up here, thinking that these boxes are supported, and then only realize the truth after spending a lot of time digging through forum posts.
<IgorPec> we try a lot to tell people what we support and what don't
<Tonymac32> I see what you're saying, it shares the name
<IgorPec> that's should be clear
<Miouyouyou> That's why TVbian would be a nice alternative name :3
<SteeMan_> I will work on something for the documentation as you suggest. I am not requesting that you work on this, just help point new users in setting the proper expectations and directing them to the resources that do exist
<IgorPec> ok, i agree something should be done, or done better
<Miouyouyou> See, that's why Mozilla imposed their "trademark" rule in their licences at some point.
<IgorPec> so this is more like an UX problem
<Tonymac32> For example I was toying with the idea of making a more compact fork for things like the DUO/etc, but was going to rebrand it so no one got confused
<JMCC-teacupx> Miouyouyou: you're gonna hurt your lips with all these cat smiles :3
<Miouyouyou> JMCC-teacupx, Never :3
piter75 has quit [Remote host closed the connection]
<Miouyouyou> Maybe the real improvement would be to add a "rebranding" documentation, telling people who want to maintain Armbian for unsupported boards how to rename the whole thing, in order to avoid confused users.
<SteeMan_> Thanks for listening to my rant, keep up the great work, I am very impressed with the more formal processes you are putting in place, great work
<count-doku> Also going for now, have a good weekend everyone!"
count-doku has quit [Quit: Leaving]
piter75 has joined #armbian
<IgorPec> Perhaps just more strict "Community support", more marketing that TV boxes are stricktly "AS IS"
<IgorPec> we were talking about that with Balbes recently
<IgorPec> He was proposing to change the name to "Armbian TV"
<JMCC-teacupx> Sorry, I must leave too. Take care and stay well, people. Bye.
<ArmbianTwitter> @TLLim888 (TL Lim): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (15s ago)
<Miouyouyou> See you JMCC-teacupx
<IgorPec> ok, by , see you thanks
<martinayotte> Ciao !
<Tonymac32> IgorPec my N2 and NanoPC T4 have both successfully overnighted rosetta@home flawlessly
<Tonymac32> see you jmcc
JMCC-teacupx has quit [Quit: Leaving]
<IgorPec> tonymac32: but xu4 is having troubles, right?
<IgorPec> btw. I have now 31 devices connected to the testing facility :)
<Tonymac32> yeah, I won't rule out that it could be a client program problem though
<Miouyouyou> Rule number 1 : It's always the user fault. Rule number 2 : No, it's the developers fault !
<SteeMan_> The problem with Arabian TV is that it implies that the purpose of the work is to support things like kodi and other video streaming type stuff, not as a general purpose linux environment for arm boxes
<Miouyouyou> It will soon evolve into Barbarian TV
<piter75> I have to go too. Thanks for the meeting!
<piter75> See you! :)
<Miouyouyou> See you!
piter75 has quit [Remote host closed the connection]
<Tonymac32> Miouyouyou for some reason it faceplants when it finishes a work package and the board just hangs. I reduced threads, I reduced CPU speed, locked speed, changed governors, same result. I've been preoccupied, need to change kernels and see what happens
<Miouyouyou> That's why I don't really understand why people don't use LibreElec distributions for TV boxes. I mean, they're targeted towards this userbase.
<Miouyouyou> Tonymac32, Is it long to finish a work package ? If it's not, maybe "strace" can help.
<Tonymac32> well no, SteeMan_ is using it as a desktop
<Tonymac32> for the work packages, yeah, 5 hours a go
<Tonymac32> Oleg's work is using these TV boxes as general computing platforms. It's nice, but you get strange random behaviors, and the setup is kind of a pain
<Miouyouyou> Hmm... a look at the software code might be faster, I don't know.
<Miouyouyou> Armbox then ?
<Tonymac32> if you have a "standard" one made by one of the big board houses it is ok. If you get a knockoff one that is mostly the same, it is a nightmare
<Miouyouyou> If the "TV" make people think about Kodi
<SteeMan_> Actually, I have two servers running on TV boxes that I build mainline kernels for weekly, and I also use another box as a desktop environment, in total I have 6 boxes that I play with for various reasons
<Tonymac32> right. I have an S905X2 box that sadly was a shitty Android TV, so now it's a destop I'm preparing for my son
<Tonymac32> 9/10 times though I'd probably just get an SBC that usually has some attempt at quality control (read forums for exceptions) ;)
<Miouyouyou> Anyway, I'm pretty sure that Armbian for TV boxes should have its own website, with its own set of warnings and documentation. This will be simpler. That way, the main work is shared but the specificities are handled by each team.
<Miouyouyou> The whole goal, kernel-wise, is to have everything mainlined anyway (Even reboot patches, yes)
<IgorPec> miouyouyou: armbian for tv boxes is not our project, that's problem
<Miouyouyou> IgorPec, Well, Armbox tv with their own website then :3
<IgorPec> its forket project that have in mind to put Armbian on tv boxes. which is good and bad
<Miouyouyou> As long as the users find their forums instead of Armbian forums, it's ok, no ?
<Tonymac32> miouyouyou you reminded me of one part of Tinker Hell that might be changing in 5.6 or 7, actually
<IgorPec> as long as they don't push on us
<Miouyouyou> Tonymac32, Not in 5.6. Maybe 5.7 ?
<IgorPec> for sorting things
<Tonymac32> the rk808 driver has been getting a lot of tweaking I've seen
<Tonymac32> concerning shutdown behaviour
<Miouyouyou> Ah, it's the real culprit
<SteeMan_> Right now I think the biggest 'bad' is the fact the the whole project is a one person (babes) and I don't think he has time/resources/desire to set it up as an entirely separate fork
<IgorPec> anything else is out of our conrol. I can ask Balbes to change the name (actually he already proposed since he understands the problem) ... so somehing has to be done
<IgorPec> there are a few more people that operate in this area, but they are not acting as a group
<Miouyouyou> Armbian forks subforums then ? With a big "Unsupported" flag ?
<IgorPec> perhaps. and where we can move all the exotics
<SteeMan_> Which is why tv boxes have quietly existed under the infrastructure of Arabian. But that isn't sustainable IMHO
<Miouyouyou> Is that the auto-correction kicking in ?
<IgorPec> arabian :)
<SteeMan_> Which is why I wanted to have some discussion on this as part of the 20.05 development chat, to discuss how this should evolve
<SteeMan_> :-) probably, or just fat fingers typing
<IgorPec> SteeMan_: we would need to talk about this in a separate meeting with balbes present
<Tonymac32> I rebuilt my main Armbian build machine to clean up some accumulated garbage, properly set up the filesystem on my NVMe. I have never known such speed
<IgorPec> also @Siraj expressed to help around, mainly around TVboxes. He is now merging our config files, which is anyway our common problem
<Miouyouyou> From eMMC to NVME
<Tonymac32> from spinning rust to NVMe
<Miouyouyou> It's like going from a 5400RPM to NVMe
<IgorPec> haha
<Miouyouyou> Yeah, exactly :3
<Tonymac32> I have the NanoPC T4 set up with / on NVMe, it is ridiculous
<Miouyouyou> "Instant writes ? That exist ?"
amarok7702_ has quit [Quit: Leaving]
<Miouyouyou> "Suddenly, I really feel that it could replace a real PC"
<Miouyouyou> The bootloader handles booting from NVMe ? (Haven't checked)
<Tonymac32> Bootloader has to be on SD/eMMC/SPI
<Miouyouyou> So it's chaining ?
<Tonymac32> T4 has an eMMC, it probably wasnt the correct method, but I had to nand-sata-install twice
amarok7702 has joined #armbian
<Miouyouyou> Booting from the eMMC and then mounting the NVME as / ?
<Tonymac32> yep
<Tonymac32> so my x86 build machine doesn't support NVMe boot either, so it's set up the same
<Tonymac32> boots the spinner, mounts / on nvme
<Miouyouyou> Interesting... So you only have the kernel on the eMMC, that you can upgrade and the rest on the disk... That's a nice combo.
macc24 has quit [Ping timeout: 264 seconds]
<IgorPec> Steeman_: I would say a good step is that tvboxes part starts to function as a group. Balbes needs help with maintinging, which can be then lead to a upper level and come closer with armbian to lower maintainace costgs
<IgorPec> my errror correction doesn't function :) its evident
<Miouyouyou> Well, yeah, I can see that you spelt it Armbian.
<Miouyouyou> :3
<lanefu> omg im sooo sorry
<Miouyouyou> It's okay. Just edit the logs and nobody will know.
<lanefu> lol
<IgorPec> haha :)
<lanefu> sooo many logs to read :P
<lanefu> glad you all got to chat
<lanefu> any big take-aways?
<IgorPec> yeah, nobody volonteered for the next release officer :)
<lanefu> Would you like me to do it again?
<IgorPec> i would be happy to assist you
<lanefu> okay yeah lets do that
<IgorPec> i think we made it good and i promise, next one is on me
<IgorPec> each time is less pain since we are getting a good stucture
<lanefu> still gotta read the notes, i would like to make sure we haev a better way to keep rc-images seperate from teh stable ones
* Tonymac32 watches build script via htop tree, impressed
<IgorPec> lanefu: you mean on the www.armbian.com/download pages
<lanefu> yeah... don't want to clobber the "stable" ones there.. if we can add them via archive great..
<IgorPec> current logic is as follows: 1-4 recommended (usually 2 right aftger the board picture) and "Other images" below
<IgorPec> under other we have "all" whatever its there + two links (too much if you ask me) "Older versions / legacy"
<IgorPec> those latter should be merged somehow
<IgorPec> so what how do you think this should be changed?
<lanefu> well just a quick side note.. I've always thought the "check other download options" is hard to see.. its kind of hidden with the light grey color
<IgorPec> its just a scroll helper
<IgorPec> i think that's alright. we want to keep most of people on recommended stuff
<IgorPec> while what i thunk is missing. an answer to "why you don't have bionic(buster) version"#
<lanefu> yeah I almost thing just having that bottom list be larger adn more description would be teh most helpful
<lanefu> so yeah i agree
<IgorPec> before we start changing that, we should solve automated mirror selection
<lanefu> yeah good idea
<IgorPec> that would eliminate the need to have those extra buttons
<lanefu> how many /downloads visits do you get per day?
<IgorPec> 10-20.000 reqests / day
Saurabh009 has quit [Quit: Leaving]
dddddd has joined #armbian
<lanefu> Okay so i just relized that Perl-nginx script runs on dl.armbian.com, not armbian.com/downloads... it's just dynamically generating a redirect
<IgorPec> that is generated with "update scripts"
<IgorPec> they re-generate links that buster_current is linked to most recent versions, makes torrents and links on the download pages below
<IgorPec> this is only done when at least one image is uploaded
<IgorPec> plus there is caching enabled on the wordpress layer
<IgorPec> those are staic html pages which updates in cron / on changes
<IgorPec> yes
<lanefu> okay
<IgorPec> Buster_current -> archive/Armbian_20.02.1_Tritium-h5_buster_current_5.4.20.7z
<IgorPec> this is on the filesystem
<IgorPec> and that nginx perl script takes care that this works
<IgorPec> this is quite handy, especially now if we change to xz
<IgorPec> link for outside is unchanged
<IgorPec> we don't need to translate
<IgorPec> and old style links are also live Debian_buster_next.7z -> the same file
<lanefu> what your mirror locations..... your hosted server, and your server at home?
<lanefu> *what are
<IgorPec> in term of hardware?
<lanefu> i'm just wondering if you have other mirrors
<lanefu> or if those are the only 2
macc24 has joined #armbian
<IgorPec> yes + mirrors
<IgorPec> i am one of the mirrors as well
<lanefu> how many mirrors are there
<IgorPec> 4
<lanefu> okay
<lanefu> are they in different countries?
<IgorPec> china, bulgarija, denmakr and slovenia
<IgorPec> that's what we have, i didn't put much effort into it. basically they came and propose
xec has quit [Remote host closed the connection]
xecuter has joined #armbian
<Werner> Back
<lanefu> okay.... so i think we should make dl.armbian.com into a script (ex: python flask, aws lambda function) that dynamically redirects users to the appropriate mirror, image etc
<IgorPec> but that download infrastructure must be HA
<IgorPec> if that is down, we have no mirroring
<lanefu> yeah, as a aws lambda we can make it very reliable
<Werner> Btw what I was thinking about downloads. Maybe before the user gets the https download of the image he wants put another hint there to use torrent if somehow possible to reduce the traffic on our side?
<lanefu> will be HA
<IgorPec> werner: that's optional, first we have to make better use of what we have
<IgorPec> lanefu: ok, how?
<IgorPec> rework this perl scripting?
<lanefu> yeah.. re-write as a python lambda
<lanefu> just need to figure out how we want to manage teh configuration
<IgorPec> ok, let me give you the actual conf
<lanefu> sweet
<IgorPec> PM on forum
<ArmbianTwitter> @iKenwright (Duncan Kenwright): @0xDEADBEEFCAFE @RosettaAtHome @armbian @thepine64 @theC4Labs Yes, SoPine modules, x7 (27s ago)
<lanefu> IgorPec: got it... can you send me the list all the mirrors
<IgorPec> added there
<ArmbianTwitter> @iKenwright (Duncan Kenwright): @IMineBlocks_com @armbian @RosettaAtHome @thepine64 @theC4Labs These are the pine64 clusterboards https://t.co/FWeiTBWJow with SoPine modules https://t.co/QxCyWveptd running Arminian. DM for any more info, I’d be pleased to assist. (1s ago)
<IgorPec> remember that mirrors only have files, no links
<IgorPec> so you have to construct the url on the dl
<lanefu> yep yep
<lanefu> okay this will be fun
<lanefu> i'll update the jira ticket
<IgorPec> great ! :)
<lanefu> I'll need to figure out how we we want to do configuration updates
<IgorPec> i am also working on xz support on the dowload infrastructure now
<lanefu> but shouldnt be a big deal
<lanefu> cool
<IgorPec> pixz compresses fast when there are lots of cores
<Miouyouyou> Alright, I'll get going. See you everyone :3
Miouyouyou has quit [Quit: Leaving]
<ArmbianTwitter> @CoinSenero (Senero): PiNode-XMR updated. Full node ( for single board computers ) not just Raspberry Pi --- Armbian Buster & Hardware testers needed. New Web UI proposal with help needed from the community. via /r/Monero https://t.co/PbmZwz3Y96 https://t.co/kZY0wbLbe9 those unfamiliar with the pro… (12s ago)
<IgorPec> lanefu: nice haircut :)
<ArmbianTwitter> @0xDEADBEEFCAFE (Ricardo B): @iKenwright @RosettaAtHome @armbian @thepine64 @theC4Labs I love the fact they come with ethernet on the edge connector. I wish all these boards standardized on having ethernet/USB on either edge connectors or pins. (28s ago)
rotaticus has quit [Ping timeout: 265 seconds]
<lanefu> IgorPec: hahaha thanks
<IgorPec> its just like mine :)
<lanefu> i miss my hair
<lanefu> hats are weird
<lanefu> now
<IgorPec> you get used to
<lanefu> its funny i can feel the cold even like when changing rooms
<ArmbianTwitter> @0xDEADBEEFCAFE (Ricardo B): @iKenwright @RosettaAtHome @armbian @thepine64 @theC4Labs I'd love to see more compute modules compatible with the clusterboard. Is the spec open, @thepine64? It's mostly the GPIO pins, the ethernet, HDMI out and USB, right (and power, of course)? (2s ago)
<ArmbianTwitter> @IMineBlocks_com (IMineBlocks ⛏️): @iKenwright @armbian @RosettaAtHome @thepine64 @theC4Labs Thankyou (13s ago)
Siraj has quit [Remote host closed the connection]
<ArmbianTwitter> @thepine64 (PINE64): RT @iKenwright: @IMineBlocks_com @armbian @RosettaAtHome @thepine64 @theC4Labs These are the pine64 clusterboards https://t.co/FWeiTBWJow w… (23s ago)
<ArmbianTwitter> @VeryMetal_dev (Henri ⌨️🖥️👨‍🔧🖋️✏️😷): RT @iKenwright: @IMineBlocks_com @armbian @RosettaAtHome @thepine64 @theC4Labs These are the pine64 clusterboards https://t.co/FWeiTBWJow w… (21s ago)
chwe_ has quit [Quit: Konversation terminated!]
<ArmbianTwitter> @kjjaeger (Kenneth J. Jaeger): RT @iKenwright: Moving to Ralph@home as Seti@home has now finished distributing WU! @RosettaAtHome @armbian @thepine64 @theC4Labs https://t… (21s ago)
<ArmbianTwitter> @kjjaeger (Kenneth J. Jaeger): RT @iKenwright: @IMineBlocks_com @armbian @RosettaAtHome @thepine64 @theC4Labs These are the pine64 clusterboards https://t.co/FWeiTBWJow w… (29s ago)
maccraft has joined #armbian
macc24 has quit [Ping timeout: 264 seconds]
retropikzel has quit [Quit: Leaving]
SteeMan_ has quit [Quit: This computer has gone to sleep]
SteeMan has quit [Quit: Leaving]
SteeMan_ has joined #armbian
SteeMan_ has quit [Quit: This computer has gone to sleep]
maccraft has quit [Ping timeout: 265 seconds]
macc24 has joined #armbian
Naka is now known as Nakaori
IgorPec has quit [Quit: Leaving]
SteeMan_ has joined #armbian
macc24 has quit [Ping timeout: 265 seconds]
Toast has quit [Ping timeout: 260 seconds]
IgorPec has joined #armbian
IgorPec has joined #armbian
IgorPec has quit [Changing host]
NeuroScr has joined #armbian
<ArmbianTwitter> @iKenwright (Duncan Kenwright): @IMineBlocks_com @armbian @RosettaAtHome @thepine64 @theC4Labs Just noticed the autocorrect they are of course running @armbian not Arminian... I have no idea how to help with the latter! (10s ago)