2024-02-01 15:24:26 <clandmeter> blaboon: ping
2024-02-01 15:39:11 <clandmeter> blaboon: Your credit expires soon
2024-02-01 15:48:15 <blaboon> the monthly credit for your account was set to expire at the end of january, but i extended that to the end of february 2025 a few weeks ago, so everything should be fine there (and i can see that today's monthly invoice did correctly pull from the extended credit pool)
2024-02-01 15:50:40 <blaboon> if you look at your account settings in the manager it should say the current credit is valid through february 2025
2024-02-01 15:50:56 <blaboon> march 2025*
2024-02-01 15:51:47 <ikke> ah yes, reading the year properly helps :) Thanks!
2024-02-01 15:52:04 <blaboon> which instance is having connectivity issues?
2024-02-01 15:52:27 <ncopa> blaboon: thank you!
2024-02-01 15:52:28 <ikke> No connectivity issues, we just got a notification that "Your linode credit expires"
2024-02-01 15:53:03 <blaboon> ahh, gotcha. thought the ping was in relation to the earlier convo
2024-02-01 15:53:14 <ikke> No, that's about infra hosted at ungleich
2024-02-01 15:54:05 <ikke> blaboon: btw, the e-mail says that we could reply to that e-mail, but it's coming from no-reply@.. ;-)
2024-02-01 15:57:39 <blaboon> heh. guessing those emails are sent out by an akamai system now and the email contents weren't updated to reflect that. i'll see if i can find out who runs that stuff these days
2024-02-01 16:04:41 <clandmeter> blaboon: thx for the support
2024-02-01 16:04:47 <clandmeter> completely missed the 25 :D
2024-02-01 16:05:05 <clandmeter> but i blame it on ikke ;-)
2024-02-01 16:05:11 <blaboon> no problem :)
2024-02-01 16:12:38 <ikke> ayakael: it appears that `bundle config set --global build.prometheus-client-mmap -j 16
2024-02-01 16:12:47 <ikke> helps with the non-existing directory issues
2024-02-01 16:13:03 <ikke> (This is still for 16.7, so only prometheus-client-mmap still)
2024-02-01 16:13:26 <ikke> I had the same, build succeeding locally but failing in CI
2024-02-01 18:47:45 <mps> 3.19 arm builders are inactive?
2024-02-01 18:48:19 <ikke> mps: yes, I'm moving them
2024-02-01 18:48:29 <mps> aha, ok
2024-02-01 19:08:20 <ikke> clandmeter: I guess e-mail ingress is working again :D
2024-02-01 19:41:05 <ikke> mps: aarch64 builder is running again
2024-02-01 19:42:22 <mps> ikke: yes, I see, thanks
2024-02-01 22:07:19 <ikke> mps: bepeop-no-robot asks about linux-asahi in #alpine-linux
2024-02-01 22:08:08 <mps> ikke: so you want me to join this channel?
2024-02-01 22:08:24 <ikke> mps: Just wanted to let you know
2024-02-01 22:08:49 <ikke> https://irclogs.alpinelinux.org/%23alpine-linux-2024-02.log
2024-02-01 22:11:15 <mps> OK
2024-02-01 22:39:07 <clandmeter> ikke: seems we are using pigz in abuild also for decompression, but it does not multithread :)
2024-02-01 22:39:27 <clandmeter> i was wondering why decompression was taking longer than compression
2024-02-01 23:02:23 <ikke> I think it's the algorithm that doesn't work very well parallelized 
2024-02-01 23:02:38 <ikke> ncopa: all 3.19 arm builders have been moved to che-bld-1 as well
2024-02-01 23:09:00 <clandmeter> Decompression can’t be parallelized, at least not without specially prepared deflate streams for that purpose. As a result, pigz uses a single thread (the main thread) for decompression, but will create three other threads for reading, writing, and check calculation, which can speed up decom- pression under some circumstances.
2024-02-02 01:47:29 <ncopa> awsome! thanks!
2024-02-02 01:48:13 <ncopa> re email, I tried to send an email to kdaudt at a.o the other day, but got some error. not sure if it my email client that is configured wrong
2024-02-02 01:49:12 <ncopa> someone sent me an email about how to unsubscribe to announce alpine. It looked like he had tried to send an email to unsubscribe+ but had no permissions to send there
2024-02-02 01:49:22 <ncopa> I think the announce is a read-only list IIRC.
2024-02-03 04:57:40 <KREYREN_oftc> mps, was looking into the ANX bug you said is there in the alpine issue.. i couldn't find any references to it but 6.6.14 was reportedly broken on gentoo and 6.6.15 worked
2024-02-03 20:02:19 <mps> KREYREN_oftc: in my test it fails on 6.6.15 and 6.7.3
2024-02-03 20:04:32 <KREYREN_oftc> mps, noted, have you reported it to kernel upstream?
2024-02-03 20:05:36 <mps> no
2024-02-03 20:05:56 <mps> I reported in #linux-sunxi channel
2024-02-03 20:06:15 <KREYREN_oftc> mps, i will handle it then, there is also a major issue with thermal management being broken in 6.5+ causing teres to overheat
2024-02-03 20:06:24 <KREYREN_oftc> so advisory now is to use the 6.1.74 kernel
2024-02-03 20:06:42 <mps> 6.5.x works fine for me
2024-02-03 20:07:48 <mps> reporting bug to kernel developers could be unpleasant
2024-02-03 20:07:59 <mps> bugs*
2024-02-03 20:56:36 <KREYREN_oftc> sunxi seems to be already handling that, try megi's kernel
2024-02-03 20:57:21 <mps> alpine use only mainline kernels
2024-02-03 21:18:41 <KREYREN_oftc> mps, i am not saying to use it on alpine i am saying to try it if you want to help with figuring out the issue
2024-02-03 21:18:50 <KREYREN_oftc> so that we know what needs to be adjusted in mainline
2024-02-03 21:23:13 <mps> KREYREN_oftc: this should be done by someone who use this machine daily like you
2024-02-03 21:37:30 <KREYREN_oftc> mps, oke
2024-02-03 21:38:48 <mps> I really don't have free time to 'hunt' this bug and don't have incentive because I don't use this machine
2024-02-03 21:39:18 <mps> I hope you understand me
2024-02-04 17:38:55 <KREYREN_oftc> mps, https://dpaste.com/AGQA2EEUQ it seems that this patch fixes ANX in 6.7.2 kernel as confirmed by gentoo maintainer of the device, i will be testing it now too and if it works it will be in the next minor release
2024-02-04 18:02:42 <ikke> going to reboot gbr-app-1, which hosts www.a.o, msg.a.o a, smtp.a.o a and others
2024-02-04 18:56:06 <ikke> rebooting nld-dev-1, which hosts x86* dev containers
2024-02-04 18:56:09 <ikke> mps: ^
2024-02-04 18:57:33 <mps> ikke: ok
2024-02-04 19:04:53 <ikke> it's back
2024-02-04 19:12:02 <mps> thanks
2024-02-06 08:37:59 <ikke> numono: apparently github is working on ipv6 support 
2024-02-06 10:07:26 <mps> KREYREN_oftc: I can confirm that patch at https://linux-sunxi.org/Olimex_Teres-A64#Broken_ANX6345_on_Linux_6.5.2B fixes bug ANX6345 driver
2024-02-06 10:08:11 <mps> if you post patch to LKML you can add me to Cc and I will add 'Tested-by' tag
2024-02-06 10:08:19 <KREYREN_oftc> mps, thanks for the test, sunxi is working on getting that patch mainlined and i am working on better QA for teres's kernel atm
2024-02-06 10:09:11 <KREYREN_oftc> mps, the patch is not what is going to get submitted they are implementing fractional clocks and trying to optimize the display it was just to see if it's what is causing the issue
2024-02-06 10:09:25 <mps> thank you for posting this
2024-02-06 10:10:02 <KREYREN_oftc> mps, if you know of any other issues with teres then let me know btw today i should have addressed all known issues with teres for them to be landing in the LTS
2024-02-06 10:10:10 <KREYREN_oftc> 6.1.75 considered production stable
2024-02-06 10:11:22 <KREYREN_oftc> mps, btw if you want to help then i am struggling at figuring out the kernel configuration and getting linux-lts from alpine to be able to boot teres
2024-02-06 10:12:16 <mps> KREYREN_oftc: last LTS is 6.6, and all these old -LTSs are just martketing of commercial entities 
2024-02-06 10:13:29 <KREYREN_oftc> mps, the issue with 6.6 is that NXP and alike are making too many changes that make it unreliable to dodge QA and cause issues on teres in the wild atm i am trying to figure out a solution to mitigate this
2024-02-06 10:13:35 <mps> KREYREN_oftc: I can upload my local .config for teres (actually A64 devices) and you can pick from it options/drivers to -lts config
2024-02-06 10:13:42 <KREYREN_oftc> usually the LTS is not a problem though
2024-02-06 10:13:48 <KREYREN_oftc> mps, that would help thanks
2024-02-06 10:14:15 <mps> latest LTS is ok, but old ones are not good idea
2024-02-06 10:14:21 <KREYREN_oftc> if you have more data on https://linux-sunxi.org/Olimex_Teres-A64 that would help also
2024-02-06 10:14:49 <KREYREN_oftc> mps, the anx6345 patch should be implemented soo and then it should be sane to use the 6.6 LTS
2024-02-06 10:15:15 <mps> I tested on 6.7.4
2024-02-06 10:15:20 <KREYREN_oftc> there was also a problem with thermals that should be fixed now
2024-02-06 10:15:41 <KREYREN_oftc> mps, last time i checked they seem to need at least 5 days to figure out the anx6345 code
2024-02-06 10:16:01 <KREYREN_oftc> it will be backported to LTS then
2024-02-06 10:16:09 <KREYREN_oftc> which should happen quickly
2024-02-06 10:16:30 <mps> thermal is detected at boot though I don't know if it works properly
2024-02-06 10:17:06 <KREYREN_oftc> mps, lacks declaration of trip points in DTS atm
2024-02-06 10:17:36 <KREYREN_oftc> which is not critical though
2024-02-06 10:18:28 <KREYREN_oftc> and i am looking into lima complaining about regulators which seems to be a u-boot bug that also doesn't seem to break anything atm
2024-02-06 10:18:43 <mps> config is here https://dev.alpinelinux.org/~mps/arm/sunxi/config-sunxi.aarch64
2024-02-06 10:18:52 <KREYREN_oftc> thanks <3
2024-02-06 10:19:32 <KREYREN_oftc> > CONFIG_CMA_SIZE_MBYTES=16
2024-02-06 10:19:39 <KREYREN_oftc> is that working for you without issues?
2024-02-06 10:19:59 <mps> yes
2024-02-06 10:20:20 <KREYREN_oftc> i have 32 on nixos and it's causing the system to crash especially while using gnome env and apps and has to be mitigated through setting `cma=128M` in kernel cli
2024-02-06 10:20:59 <mps> you run gnome on such small device?
2024-02-06 10:21:29 <mps> it has only 2GB RAM
2024-02-06 10:21:30 <KREYREN_oftc> mps, yep works really great too :D
2024-02-06 10:21:44 <mps> ok
2024-02-06 10:22:03 <mps> I have to go now, thanks for help
2024-02-06 10:22:10 <KREYREN_oftc> as long as you have SWAP declared bcs gnome is optimized to utilize swap to be more responsive
2024-02-06 10:22:14 <KREYREN_oftc> mps, oke
2024-02-06 10:22:28 <mps> swap on emmc, huh :)
2024-02-06 10:22:35 <KREYREN_oftc> yep
2024-02-06 10:22:55 <KREYREN_oftc> and i am working on eMMC upgrade that should cost around 25 EUR in any local repair shop and could get you 64GB ~ 128GB ^-^
2024-02-06 10:23:18 <mps> with alpine I don't have and don't need swap anywhere
2024-02-06 10:23:57 <mps> bbl
2024-02-06 10:24:00 <KREYREN_oftc> mps, can you try running epiphany and playing a random 1080p youtube video and monitor if it has DRM complains in the console?
2024-02-06 12:15:18 <mps> algitbot: retry master
2024-02-06 20:41:26 <numono> ikke: id be curious what github needs to work on ^^"
2024-02-06 20:42:05 <ikke> numono: they had an outage where their loadbalancers would reveive an ipv6 mapped ipv4 address and those were blocked by their ACLs
2024-02-06 20:42:08 <numono> anyway its still today one more good reason nowadays to migrate away from it
2024-02-06 20:47:59 <ikke> So many projects still use it, so it's hard to avoid
2024-02-06 20:52:36 <numono> yeah, its unfortunate
2024-02-07 19:59:25 <ikke> ayakael: hmm, now I'm getting failures again :/
2024-02-07 21:30:50 <nmeum> ikke: when setting up new builders for a -stable release: do you use the ./bootstrap.sh script or do you install rust, Go, … from the edge repositories?
2024-02-07 21:32:27 <ikke> nmeum: to build rust, we install rust-bootstrap from edge
2024-02-07 21:32:41 <ikke> for go we didn't had to do that anymore, but I suppose now we will have to again
2024-02-07 21:33:41 <nmeum> rust-bootstrap is just a virtual package provided by community/rust, right? if so: it would be the same for go again (i.e. you would have to install go-bootstrap)
2024-02-07 21:34:27 <nmeum> for go, we could alternatively also package intermediate versions and do gccgo -> go 1.20 -> go 1.22 but since they are planning on bumping the minimum go version every year now that will probably amount to maintaining a lot of go versions in the long run ':)
2024-02-07 21:36:33 <ikke> Yeah, doesn't sound like fun having to bootstrap go from scratch in the long run
2024-02-07 21:37:04 <ikke> and yes, it's a virtual package
2024-02-07 21:37:14 <ikke> because a package cannot have a makedepends on itself
2024-02-07 21:37:18 <nmeum> *nod*
2024-02-07 21:38:30 <ikke> So go is going the rust route, where every version needs the previous version to build?
2024-02-07 21:40:23 <nmeum> the version that was released a year ago, so Go 1.22 requires Go 1.20 and Go 1.24 will (likely) require Go 1.22 for bootstrapping
2024-02-07 21:40:43 <nmeum> basically they are planning to bump the minimum required Go version every year to be able to use the fancy new go features within the compiler code base itself
2024-02-07 21:41:12 <nmeum> https://go.dev/doc/go1.22
2024-02-07 21:41:13 <nmeum> > Go 1.22 now requires the final point release of Go 1.20 or later for bootstrap. We expect that Go 1.24 will require the final point release of Go 1.22 or later for bootstrap.
2024-02-07 21:41:24 <ikke> so yeah, similar to rust, except 2 versions back
2024-02-07 21:41:30 <nmeum> yep
2024-02-07 21:43:41 <mps> omg
2024-02-07 21:43:55 <mps> modern times
2024-02-07 21:47:57 <nmeum> I guess I understand why they believe it to be useful but it's really an annoyance for downstream packaging
2024-02-07 21:49:26 <mps> crystal do same method, use previous release to build new
2024-02-08 19:44:01 <ptrc> is there any way we could solve the "CI constantly filling up with chromium artifacts" issue a bit more permanently?
2024-02-08 19:44:14 <ptrc> ( not trying to complain, more like.. start a discussion about potential ideas )
2024-02-08 19:44:46 <ikke> run docker prune -af more frequently
2024-02-08 19:44:55 <ikke> docker system prune *
2024-02-08 19:45:16 <ptrc> perhaps in cron?
2024-02-08 19:45:26 <ikke> It is already run in a cron
2024-02-08 19:45:35 <ptrc> ah, well
2024-02-08 19:46:16 <ptrc> also, is there any way i could get onto the infra team? mostly to watch some colorful lines on graphs but also maybe help sometimes :p
2024-02-08 19:47:20 <ikke> clandmeter: ^
2024-02-08 20:04:57 <clandmeter> o/
2024-02-08 20:05:22 <clandmeter> im ok 
2024-02-08 20:10:00 <ikke> 👍
2024-02-08 23:51:05 <ptrc> btw, we have even more riscv64 segfaults, is there a way we could perhaps roll out an older version of qemu-riscv64 on the builder?
2024-02-08 23:51:20 <ptrc> i could test what's the latest version that doesn't have that specific segfault
2024-02-09 00:03:06 <ptrc> qemu-riscv64 from 3.18 ( 8.0.5 ) works just fine apparently
2024-02-09 00:19:12 <ptrc> nevermind, figured out the underlying issue
2024-02-09 06:18:46 <ptrc> > Could not send request to alpinelinux.org at https://matrix.alpinelinux.org:443: error sending request for url (https://matrix.alpinelinux.org/_matrix/federation/v1/user/keys/query): error trying to connect: invalid peer certificate contents: invalid peer certificate: CertNotValidForName
2024-02-09 06:18:55 <ptrc> does that still exist and work?
2024-02-09 06:20:06 <ikke> ptrc: numono was working on setting something new up for us
2024-02-09 08:40:18 <numono> ^^"
2024-02-09 08:43:41 <numono> the infra is ready for it, and i just need to find a few days to read the matrix docs and turn those info into an epic config
2024-02-09 08:51:55 <nmeum> https://github.com/golang/go/issues/65601#issuecomment-1934757654
2024-02-09 08:52:08 <nmeum> our armv7 CI is running on an aarch64 machine, right?
2024-02-09 09:14:16 <clandmeter> yes
2024-02-09 09:14:33 <clandmeter> in 32bit mode
2024-02-09 09:14:51 <clandmeter> ptrc: we will soon have native riscv64 builders and CI
2024-02-09 09:15:00 <ptrc> ooh, very nice
2024-02-09 09:15:06 <clandmeter> although im not confident its 100% stable
2024-02-09 09:15:17 <ptrc> one way to find out :p
2024-02-09 09:15:24 <clandmeter> so i need to put some power plug switch 
2024-02-09 09:15:30 <clandmeter> so we can toggle it remotely 
2024-02-09 09:16:02 <clandmeter> ikke: i have connected one pioneer to our wg
2024-02-09 09:17:05 <clandmeter> i think there are multiple issues with the pioneer boards
2024-02-09 09:17:33 <clandmeter> sometimes the reset is broken and it will not reset and stay off
2024-02-09 09:17:51 <clandmeter> sometimes it hangs and kernel does not show any msg on any tty
2024-02-09 09:18:16 <clandmeter> the intel nics are not that stable, so its better to keep using the realtek onboard
2024-02-09 09:18:53 <clandmeter> the performance is better compared to our epyc qemu user stuff
2024-02-09 09:24:26 <nmeum> what hardware are we using for the native riscv64 builders?
2024-02-09 09:24:54 <nmeum> clandmeter: so the armv7 CI is basically just a docker container on aarch64, right? just like you can run x86 containers on x86_64
2024-02-09 09:25:47 <clandmeter> nmeum: im not 100% sure, could be that they run in qemu but on a aarch64 system. ikke set it up so he will not 100%.
2024-02-09 09:26:02 <clandmeter> s/not/know
2024-02-09 09:26:35 <nmeum> ok, I will wait for him to reply then :D
2024-02-09 09:26:50 <clandmeter> nmeum: https://milkv.io/pioneer
2024-02-09 09:27:02 <clandmeter> i received two of them
2024-02-09 09:27:36 <nmeum> nice!
2024-02-09 09:27:55 <clandmeter> right, but they are development boxes
2024-02-09 09:28:04 <clandmeter> so they have some challenges 
2024-02-09 09:28:24 <clandmeter> they use linux as firmware :)
2024-02-09 09:30:33 <ikke> Yes docker containers on aarch64 with linux32 as entrypoint 
2024-02-09 09:30:44 <nmeum> what does "linux32 as entrypoint" mean?
2024-02-09 09:30:52 <nmeum> do they run a custom kernel?
2024-02-09 09:33:31 <ikke> No, regular aarch64-virt kernel 
2024-02-09 09:33:42 <nmeum> ok
2024-02-09 09:33:44 <nmeum> thanks
2024-02-09 09:33:47 <clandmeter> linux32 will switch the process 32bit mode
2024-02-09 09:33:53 <clandmeter> to*
2024-02-09 09:34:03 <nmeum> ah!
2024-02-09 09:34:15 <clandmeter> but you need a compat processor for it
2024-02-09 09:34:22 <clandmeter> which we do ofc
2024-02-09 09:34:36 <clandmeter> its similar to x86
2024-02-09 09:36:25 <clandmeter> ikke: didnt we run some stuff in qemu-system on arm?
2024-02-09 09:39:43 <ikke> Yes, CI does
2024-02-09 09:39:57 <nmeum> do I still have access to an armv7 container? I think I used to have access to one running on 172.16.23.125 but I can't reach it right now
2024-02-09 09:40:10 <ikke> Because its difficult to separate different arches on the same host with docker 
2024-02-09 09:40:24 <nmeum> would be good to bisect commits between go 1.21.6 and go 1.22.0 to figure out which commit causes the breakage on our ci
2024-02-09 09:40:35 <ikke> nmeum: can be that the container stopped
2024-02-09 09:41:43 <nmeum> ok, will look into it later. need to do some $dayjob stuff now
2024-02-09 11:19:58 <ikke> nmeum: I've started it again, but it's IP changed:
2024-02-09 11:20:00 <ikke> nmeum-edge-armv7        RUNNING 0         -      172.16.27.125 - 
2024-02-09 17:11:15 <nmeum> ikke: yep, that works. ty
2024-02-09 17:11:24 <ikke> 👍
2024-02-09 17:17:28 <nmeum> ok, i can reproduce it in the lxc too. time to bisect
2024-02-10 11:54:10 <mps> ikke: are you around
2024-02-10 11:55:46 <mps> I can't ssh to 172.16.252.24 while I can ping it from my local machine, looks like firewall issue
2024-02-11 07:35:24 <ikke> mps: Is it maybe something in wireguard that prevents routing between peers?
2024-02-11 07:36:30 <mps> ikke: no, ping works fine. and I can ssh to other machines on WG net
2024-02-11 07:37:59 <mps> ikke: I'm not sure it os firewall but just asking you about this. maybe you have set something differently for some net ranges or hosts
2024-02-11 07:38:14 <mps> s/os/is/
2024-02-11 07:38:23 <ikke> no
2024-02-11 07:38:50 <ikke> I see the traffic arriving on the wg0 interface, added explicit allow firewall rules, but those rules are never hit
2024-02-11 07:40:17 <mps> looks like you have set some kind of rate limit for ssh
2024-02-11 07:40:49 <ikke> that's on eth0
2024-02-11 07:43:25 <mps> ikke, fragment ssh from my machine to x86_64 container '07:41:04.833503 wg0   In  IP 172.16.252.2.41690 > 172.16.26.16.22: Flags [P.], seq 4042:4078, ack 4282,' 
2024-02-11 07:45:15 <mps> and, fragment of ssh to pioneer box '07:44:22.002316 wg0   In  IP 172.16.252.2.47736 > 172.16.252.24.22: Flags [S], seq 1881441285, win 33120, options [mss'
2024-02-11 07:45:37 <mps> on this last there is no answers
2024-02-11 07:47:29 <mps> so, ssh goes fine to all of lxcs, and only not to pioneer
2024-02-11 07:48:11 <mps> with ProxyJump ssh option I can connect to it
2024-02-11 07:51:01 <ikke> Only difference is that to pioneer it remains on wg0, while for other lxcs it'r routed from wg0 to dmvpn
2024-02-11 07:53:28 <mps> hm, looks like for some reason pioneer don't send ssh responses to requests from my machine but send ping response fine
2024-02-11 07:53:46 <ikke> maybe fw on the pioneer?
2024-02-11 07:54:27 <mps> I also thought so but admin assured me there is no firewall
2024-02-11 07:55:25 <ikke> I assume that's clandmeter? :P
2024-02-11 07:55:29 <mps> assured, hm, maybe not right word
2024-02-11 07:55:39 <mps> yes, clandmeter 
2024-02-11 07:56:43 <mps> also I thought it could be 'ip rule' set
2024-02-11 07:59:27 <mps> interesting is that I can't ping from pioneer my machine
2024-02-11 07:59:42 <ikke> How do you have access to the pioneer?
2024-02-11 08:00:12 <mps> yes, with ProxyJump over WG hub
2024-02-11 08:00:30 <ikke> ok, so it works directly from the hub, but not from a wg peer
2024-02-11 08:00:36 <mps> not through WG
2024-02-11 08:00:46 <mps> ikke: right
2024-02-11 08:00:46 <ikke> can you check the wg config?
2024-02-11 08:01:09 <mps> on pioneer?
2024-02-11 08:01:12 <ikke> yes
2024-02-11 08:02:51 <mps> on flash look it looks ok
2024-02-11 08:03:04 <ikke> What is AllowedIPs set to?
2024-02-11 08:04:38 <mps> AllowedIPs = 172.16.0.0/16, 2000::/3
2024-02-11 08:04:49 <ikke> ok, that's correct
2024-02-11 08:05:21 <ikke> and ip route?
2024-02-11 08:06:37 <mps> https://tpaste.us/1XWE
2024-02-11 08:07:40 <ikke> Can you try: `ip route add 172.16.252.0/24 via 172.16.252.1`
2024-02-11 08:08:50 <mps> ikke: this prefix route already exists
2024-02-11 08:09:02 <mps> 172.16.252.0/24
2024-02-11 08:10:38 <ikke> we could try to replace is but chance is that you lock yourself out
2024-02-11 08:10:49 <ikke> hmm, try a more specific route
2024-02-11 08:10:51 <mps> right
2024-02-11 08:11:21 <mps> I think routes are set correctly
2024-02-11 08:11:46 <ikke> From what I understood, wg does not do l2 forwarding, right?
2024-02-11 08:12:09 <mps> I think you are right
2024-02-11 08:12:33 <ikke> try: ip route add 172.16.252.16/28 via 172.16.252.1
2024-02-11 08:12:44 <mps> maybe it could with some tweaks but also IDK
2024-02-11 08:14:01 <mps> ikke: I would left these changes to clandmeter, don't want that we lock him out if machine
2024-02-11 08:14:15 <mps> s/if/of/
2024-02-11 08:14:46 <mps> I'm not in hurry and I hope you also not
2024-02-11 08:14:51 <ikke> Nope
2024-02-11 08:15:59 <mps> ok, thanks for help. when clandmeter appears we could try more to fix this issue
2024-02-11 10:00:03 <clandmeter> morning
2024-02-11 10:00:07 <clandmeter> what did i miss
2024-02-11 10:01:21 <clandmeter> mps did the wg fix help?
2024-02-11 10:01:33 <clandmeter> i mean you can still proxyjump now
2024-02-11 10:02:02 <ikke> clandmeter: you need to add a via route instead of subnet route for the /24
2024-02-11 10:02:36 <clandmeter> why would that be needed?
2024-02-11 10:02:47 <clandmeter> we are all on the same subnet
2024-02-11 10:03:10 <ikke> From what I understood from wg is that you cannot connect other peers over l2
2024-02-11 10:03:27 <ikke> you need to route via the gw
2024-02-11 10:03:45 <ikke> but icmp is working, hmm
2024-02-11 10:05:05 <clandmeter> correct
2024-02-11 10:05:12 <clandmeter> i guess you are also on wg network?
2024-02-11 10:05:49 <ikke> yes
2024-02-11 10:06:01 <clandmeter> from what i understand something is blocking ssh traffic on deu7-dev1
2024-02-11 10:06:26 <clandmeter> let me add your key to the pioneer box
2024-02-11 10:07:22 <ikke> ok, I've bypassed the FW and now ssh is responding
2024-02-11 10:07:34 <clandmeter> ikke: which key do you want me to add? all 3?
2024-02-11 10:07:54 <ikke> yes
2024-02-11 10:08:31 <ikke> Hmm, so it's still considered forwarding, interesting
2024-02-11 10:08:40 <clandmeter> done
2024-02-11 10:09:10 <clandmeter> 172.16.252.24 should work now for you
2024-02-11 10:09:30 <clandmeter> im trying to base of a new kernel for the pioneer from linux-edge
2024-02-11 10:09:35 <clandmeter> but we are bumping into issues
2024-02-11 10:09:38 <ikke> Yes, I'm in
2024-02-11 10:09:39 <clandmeter> seems some linker issue
2024-02-11 10:09:47 <ikke> mps: fyi, it should work now
2024-02-11 10:10:08 <ikke> Just puzzled why it's considered forwarded traffic, but I guess because it's not targeting the deu7 machine itself
2024-02-11 10:10:43 <ikke> clandmeter: for some reason, awall is not working on deu7
2024-02-11 10:10:53 <ikke> Perhaps to do with the switch to nftables
2024-02-11 10:11:17 <clandmeter> not working or not working properly?
2024-02-11 10:11:39 <ikke> Warning: firewall not enabled for inet
2024-02-11 10:11:41 <ikke> Firewall is not active
2024-02-11 10:11:46 <clandmeter> hmm ok
2024-02-11 10:12:12 <clandmeter> do we need to report it to kaarle?
2024-02-11 10:12:59 <ikke> Not sure yet if it's a local issue or an issue with awall
2024-02-11 10:13:16 <ikke> I did test it after the switch to nftables, and it was working
2024-02-11 10:14:03 <clandmeter> i guess we need to start converting iptables rules in aports to nftables?
2024-02-11 10:14:14 <clandmeter> like in dnsmasq
2024-02-11 10:14:56 <clandmeter> mps told me docker was one of the places to keep legacy code in the kernel
2024-02-11 10:16:23 <clandmeter> i never played much with the kernel and iptables and friends. but its a nightmare to understand all of it.
2024-02-11 10:17:18 <clandmeter> in any case, i like to start basing my sophgo kernel on edge kernel
2024-02-11 10:17:51 <clandmeter> and ones we have proper mainline support, we need to add riscv support to lts also
2024-02-11 10:18:16 <clandmeter> but that will probably take another year or so
2024-02-11 10:19:22 <mps> ikke: yes, it works now
2024-02-11 10:19:44 <mps> and yes, we should finally switch to nft
2024-02-11 10:20:02 <mps> I proposed this here about year ago
2024-02-11 10:20:38 <clandmeter> i guess you can go over aports and convert everything to nft and submit mr's :)
2024-02-11 10:21:39 <mps> I could but I will waste my free time on more interesting things, you know on what
2024-02-11 10:22:00 <clandmeter> climate change?
2024-02-11 10:22:05 <clandmeter> :p
2024-02-11 10:22:57 <mps> no, climate is in better hands, God allmighty and Alah
2024-02-11 10:24:07 <mps> starfive told me they would like to send me new SoC JH8110
2024-02-11 10:24:55 <mps> but now more seriously, I want to devote more time to riscv
2024-02-11 10:28:15 <ikke> clandmeter: fixed, needed to modprobe ip_tables and ip6_tables
2024-02-11 10:28:35 <clandmeter> heh, that could help :)
2024-02-11 10:28:45 <clandmeter> isnt that done by iptables initd?
2024-02-11 10:29:17 <ikke> no, apparently it just tells you to load the appropriate modules
2024-02-11 10:30:33 <clandmeter> i dont remember i need to load those manually
2024-02-11 10:30:50 <ikke> me neither
2024-02-11 10:31:06 <ikke> but I suppose that is related to the nftables switch
2024-02-11 10:31:27 <ikke> x_tables was already loaded for example
2024-02-11 10:32:41 <clandmeter> when did this switch happen?
2024-02-11 10:34:04 <ikke> 3.18 or so
2024-02-11 10:34:56 <mps> ssh again doesn't work
2024-02-11 10:36:04 <ikke> yes, hold on
2024-02-11 10:37:10 <mps> ok
2024-02-11 10:39:18 <clandmeter> 3.19 made the switch
2024-02-11 10:39:29 <clandmeter> this means anything since that release should support nft i guess
2024-02-11 10:39:58 <mps> clandmeter: right
2024-02-11 10:40:34 <mps> even openwrt ditched iptables about year (or more) ago
2024-02-11 10:41:27 <mps> I'm thinking to disable it in linux-edge anyway
2024-02-11 10:41:29 <ikke> mps: works again
2024-02-11 10:41:53 <mps> ikke: yes, thanks
2024-02-11 10:42:07 <clandmeter> mps: please make sure you dont break things
2024-02-11 10:42:10 <ikke> yeah
2024-02-11 10:42:59 <mps> break things sometimes is needed to force proper fix 
2024-02-11 10:43:18 <clandmeter> there are other ways to do it
2024-02-11 10:43:20 <mps> ;p
2024-02-11 10:43:35 <clandmeter> maybe you can look into docker, if that is one of the blockers
2024-02-11 10:43:52 <mps> clandmeter: hey, today is not day for serious talks :)
2024-02-11 10:44:21 <clandmeter> everyday is serious day 
2024-02-11 10:44:25 <mps> but in every joke there is a little joke
2024-02-11 10:44:41 <clandmeter> some serious days just suck more
2024-02-11 10:45:13 <mps> did I broke anything till now? ok, some small bugs
2024-02-11 10:46:31 <clandmeter> mps: do you want to look at the linker issue?
2024-02-11 10:46:43 <mps> yes
2024-02-11 10:47:20 <mps> but have to install some tools first, config them and prepare another coffee
2024-02-11 10:47:36 <clandmeter> btw, the other pioneer is also online, but not on wg yet
2024-02-11 10:47:51 <clandmeter> i need to attach a remote power plug to it
2024-02-11 10:47:55 <clandmeter> in case it hangs
2024-02-11 10:49:14 <mps> a lot of noise in your house now, I guess
2024-02-11 10:49:31 <clandmeter> ikke: i wonder if we should put them on the network 
2024-02-11 10:49:51 <clandmeter> or keep it on wg for now
2024-02-11 10:49:58 <clandmeter> mps: the fans are always 100%
2024-02-11 10:50:05 <clandmeter> there is no control yet
2024-02-11 10:50:18 <mps> uhm, not good
2024-02-11 10:51:11 <clandmeter> https://github.com/sophgo/linux/wiki#milk-v-pioneer-sg2042
2024-02-11 10:51:17 <mps> looks like I 'hang up' pioneer
2024-02-11 10:51:17 <clandmeter> follow that page for progress
2024-02-11 10:51:34 <clandmeter> yup
2024-02-11 10:51:35 <clandmeter> it hangs
2024-02-11 10:53:26 <clandmeter> weird thing is, the kernel does not output any error
2024-02-11 10:54:59 <mps> I started rsyncing your aports dir to my
2024-02-11 10:55:13 <mps> and it hangs
2024-02-11 10:55:32 <mps> everything hangs
2024-02-11 10:55:59 <mps> didn't looked on what media is root FS
2024-02-11 10:56:31 <mps> if it is mmc then it is expectable
2024-02-11 10:57:03 <mps> ping still works fine
2024-02-11 10:57:33 <clandmeter> tty non responsive
2024-02-11 10:57:51 <ikke> I could still ssh into it, but htop hang
2024-02-11 10:58:03 <ikke> oh no, it's running now
2024-02-11 10:58:08 <clandmeter> ah its back
2024-02-11 10:58:11 <clandmeter> wow 
2024-02-11 10:58:17 <clandmeter> that took like few minutes
2024-02-11 10:58:23 <clandmeter> so its an io thingy
2024-02-11 10:58:26 <ikke> yup
2024-02-11 10:58:33 <clandmeter> maybe upgrade the nvme
2024-02-11 10:58:39 <clandmeter> its some chinese unknown brand for me
2024-02-11 10:59:13 <clandmeter> i almost turned it off
2024-02-11 10:59:36 <clandmeter> i have a wifi power plug to but behind it. ill also be able to monitor power consumtion
2024-02-11 11:00:09 <clandmeter> i killed htop
2024-02-11 11:00:15 <clandmeter> forgot i was on serial :D
2024-02-11 11:00:59 <clandmeter> mps: did your sync complete?
2024-02-11 11:01:17 <mps> looks like it is
2024-02-11 11:02:07 <clandmeter> best is to run everything in tmux :)
2024-02-11 11:02:40 <mps> right
2024-02-11 11:03:01 <mps> how much cpus to build, -j16 ?
2024-02-11 11:03:08 <clandmeter> all of them ofc
2024-02-11 11:03:13 <clandmeter> btw
2024-02-11 11:03:18 <mps> ah ok
2024-02-11 11:03:20 <clandmeter> best is to start using lxc
2024-02-11 11:03:47 <clandmeter> but then we need to add it to the network, else you wont be able to ssh directly
2024-02-11 11:03:50 <ikke> btw, if you start using ips for wg, could you also record them in netbox?
2024-02-11 11:04:17 <clandmeter> sure, i hope i wont forget :)
2024-02-11 11:04:28 <ikke> I did add .24 already
2024-02-11 11:04:36 <clandmeter> add 25 too
2024-02-11 11:04:38 <ikke> Ok
2024-02-11 11:04:42 <clandmeter> ill use that for the other one
2024-02-11 11:04:43 <ikke> I also include the wg public key
2024-02-11 11:04:51 <ikke> in netbox
2024-02-11 11:05:03 <ikke> If we ever lose wg0.conf, we can regenerate it
2024-02-11 11:05:22 <clandmeter> you can get public from private 
2024-02-11 11:05:28 <mps> hm, nouveau, amd, radeon in this kernel enabled
2024-02-11 11:05:34 <ikke> clandmeter: that would not make sense
2024-02-11 11:05:56 <ikke> oh, sorry
2024-02-11 11:05:59 <ikke> yes, you can
2024-02-11 11:06:02 <clandmeter> :)
2024-02-11 11:06:09 <ikke> but then you need to ask everyone for the keys again
2024-02-11 11:06:10 <clandmeter> if you loose private, then its game over
2024-02-11 11:06:20 <clandmeter> oh like that
2024-02-11 11:06:31 <clandmeter> right, but did you backup private of the hub?
2024-02-11 11:06:44 <ikke> not yet :P
2024-02-11 11:07:05 <clandmeter> btw, i was thinking of using some tool to manage wg, not sure everyone would like it :)
2024-02-11 11:08:06 <clandmeter> my idea for the two pioneer boxes is to put them behind a APU2
2024-02-11 11:08:09 <ikke> clandmeter: I reserved the address for .25
2024-02-11 11:08:27 <clandmeter> and we connect the serial ports to the APU2
2024-02-11 11:09:07 <clandmeter> install dmvpn on the APU2
2024-02-11 11:10:06 <clandmeter> just need to find a right place to host/put them
2024-02-11 11:11:06 <clandmeter> mps: this box has an radeon card installed
2024-02-11 11:13:16 <clandmeter> i am thinking to remove both radeon card and intel 10G nic
2024-02-11 11:13:47 <clandmeter> but i think we will need tty for the bootloader
2024-02-11 11:13:55 <clandmeter> seems this does not want to show over serial
2024-02-11 11:27:50 <clandmeter> mps, can i reboot the machine?
2024-02-11 11:28:48 <clandmeter> i assume no response as a yes :)
2024-02-11 11:31:15 <mps> :)
2024-02-11 11:39:16 <clandmeter> hmm, without video card also no boot menu
2024-02-11 11:39:23 <clandmeter> somehow its forced to tty1
2024-02-11 11:39:35 <clandmeter> would be nice if we could fix that
2024-02-11 11:40:51 <clandmeter> no load is 80Watt
2024-02-11 11:48:10 <mps> hm, it should use serial console in that case
2024-02-11 11:48:37 <clandmeter> if i find time next week ill set it up
2024-02-11 11:48:55 <clandmeter> so around 107W at full load
2024-02-11 11:49:07 <clandmeter> vendor mentioned around 120w
2024-02-11 11:49:56 <clandmeter> mps: did you change anything on my aports?
2024-02-11 11:50:19 <mps> no
2024-02-11 11:50:33 <clandmeter> weird 
2024-02-11 11:50:42 <clandmeter> im getting missing mawk errors
2024-02-11 11:51:03 <mps> hah
2024-02-11 11:51:14 <mps> abuild deps removed it
2024-02-11 11:51:41 <clandmeter> ah you are playing on this as well
2024-02-11 11:51:50 <clandmeter> so better we move stuff to lxc
2024-02-11 11:52:36 <clandmeter> so i think ones they have power management under control, this 80w can go down
2024-02-11 11:59:32 <mps> huh, FS is very slow
2024-02-11 12:09:32 <mps> untarring kernel takes loooong
2024-02-11 12:12:39 <clandmeter> mps: use pigz
2024-02-11 12:13:01 <mps> 'abuild unpack'
2024-02-11 12:13:09 <clandmeter> i think with previous ssd it was faster
2024-02-11 12:13:18 <clandmeter> ill look into another ssd
2024-02-11 12:13:27 <clandmeter> ill probably add another sata one
2024-02-11 12:13:30 <clandmeter> for diskfiles
2024-02-11 12:13:34 <clandmeter> distfiles
2024-02-11 12:13:55 <mps> what FS driver you use
2024-02-11 12:14:47 <clandmeter> mount will tell you :)
2024-02-11 12:15:05 <clandmeter> system hangs again
2024-02-11 12:15:14 <mps> aha, in about 15 minutes when it unhangs
2024-02-11 12:15:25 <clandmeter> its ext4
2024-02-11 12:15:44 <clandmeter> maybe i need to remove the kernel arguments
2024-02-11 12:15:50 <clandmeter> i think upsteram also removed them
2024-02-11 12:17:13 <mps> I use f2fs on all media except rotational
2024-02-11 12:18:02 <clandmeter> this problem is not related to the FS
2024-02-11 12:18:24 <clandmeter> and its back
2024-02-11 12:18:51 <clandmeter> nvme_core.io_timeout=600 nvme_core.admin_timeout=600
2024-02-11 12:19:01 <clandmeter> not sure what these do
2024-02-11 12:24:51 <mps> dmesg => '[ 1651.811864] nvme nvme0: I/O 83 QID 1 timeout, completion polled'
2024-02-11 12:25:08 <mps> probably PCIe driver issue
2024-02-11 12:26:38 <clandmeter> do you want to boot with thse nvme opts disabled?
2024-02-11 12:26:42 <clandmeter> I have commented them out now
2024-02-11 12:27:03 <clandmeter> i think it will maybe cause more issues, but im not sure.
2024-02-11 12:27:30 <clandmeter> rvspace has some notes about it
2024-02-11 12:27:42 <clandmeter> https://forum.rvspace.org/t/nvme-i-o-timeouts/1545
2024-02-11 12:28:45 <mps> I remember that someone told on #riscv that this helped him
2024-02-11 12:29:10 <mps> but IDK will it help us, but you can try
2024-02-11 12:30:04 <clandmeter> ready for reboot?
2024-02-11 12:30:10 <mps> ok
2024-02-11 12:30:42 <clandmeter> im still not happy, something is messing with cmdline options
2024-02-11 12:30:50 <clandmeter> its dtb or u-root
2024-02-11 12:32:26 <clandmeter> haha
2024-02-11 12:32:29 <clandmeter> its still there
2024-02-11 12:33:52 <mps> clandmeter: does 'abuild build' works for you
2024-02-11 12:34:05 <clandmeter> its rebooting again
2024-02-11 12:35:58 <clandmeter> ah
2024-02-11 12:37:59 <mps> I will pull clean git repo from gitlab
2024-02-11 12:38:08 <mps> clone
2024-02-11 12:38:28 <mps> hm, again reboot
2024-02-11 12:38:41 <clandmeter> yes pls wait
2024-02-11 12:38:43 <clandmeter> im working on it
2024-02-11 12:38:46 <mps> ok
2024-02-11 12:38:53 <clandmeter> its taking grub.cfg 
2024-02-11 12:38:59 <clandmeter> not extlinux.conf
2024-02-11 12:39:04 <mps> I can do some things outside
2024-02-11 12:39:12 <clandmeter> i hope it will boot now
2024-02-11 12:42:40 <clandmeter> all hope is lost
2024-02-11 12:57:28 <clandmeter> https://tpaste.us/pagn
2024-02-11 12:57:30 <clandmeter> loveley
2024-02-11 12:58:42 <clandmeter> mps: i killed the grub.cfg (its from when i tried to boot efi)
2024-02-11 12:58:56 <clandmeter> so now cmdline is updated 
2024-02-11 12:59:09 <clandmeter> not sure its lovely with these nvme errors
2024-02-11 12:59:18 <clandmeter> lets try and see what it does
2024-02-11 13:00:30 <clandmeter> i dont trust this FORESEE XP1000F001T
2024-02-11 13:13:11 <mps> it has 128GB ram?
2024-02-11 13:51:56 <mps> clandmeter: I've got it with your config. /home/mps/packages/testing/riscv64/
2024-02-11 13:53:35 <clandmeter> you got what?
2024-02-11 13:54:55 <mps> kernel
2024-02-11 13:55:24 <mps> built without errors
2024-02-11 13:56:24 <mps> file name is wrong though
2024-02-11 13:56:48 <mps> I have to fix my APKBUILD for this
2024-02-11 13:57:05 <clandmeter> i have no idea what you are saying :)
2024-02-11 13:57:23 <mps> problem with LD solved
2024-02-11 13:57:33 <clandmeter> you used the same config?
2024-02-11 13:57:43 <mps> I think, yes
2024-02-11 13:57:47 <clandmeter> you think??
2024-02-11 13:57:50 <clandmeter> :)
2024-02-11 13:58:43 <clandmeter> what is the realpath of your config?
2024-02-11 13:58:47 <clandmeter> ill diff it
2024-02-11 13:58:49 <mps> and my thinking is wrong :)
2024-02-11 13:59:11 <mps> sorry, will look again in the evening
2024-02-11 14:00:08 <clandmeter> i think ill report it upstream
2024-02-11 14:00:12 <clandmeter> this should never happen
2024-02-11 14:00:21 <mps> you use this as config /home/clandmeter/aports/testing/linux-sophgo/sophgo.riscv64.config
2024-02-11 14:00:31 <clandmeter> yes
2024-02-11 14:00:36 <mps> ok
2024-02-11 14:36:33 <mps> in drivers/soc/sophgo/Makefile commenting out line 'obj-$(CONFIG_ARCH_SOPHGO)    += umcu/mcu.o' fixes build. not sure will kernel work
2024-02-11 15:04:22 <clandmeter> I think it’s mandatory heh
2024-02-11 15:17:14 <mps> why?
2024-02-11 15:18:19 <mps> IDK to be clear, but if it fails I'm not sure it is needed
2024-02-11 15:19:10 <mps> f59be39f50abd602cca98750621a8cf6f9a41f9c in their git tree
2024-02-11 15:20:57 <mps> dmesg => 2.226062] sg20xx-mcu 1-0017: hwmon: 'sg20xx-mcu' is not a valid name attribute, please fix
2024-02-11 16:47:25 <clandmeter> That’s the dtb 
2024-02-11 16:47:44 <clandmeter> the mcu is part of the board
2024-02-11 17:09:19 <mps> yes, it is but does it works now
2024-02-11 17:57:40 <clandmeter> mps: https://github.com/sophgo/linux-riscv/issues/104
2024-02-11 21:47:02 <mps> clandmeter: good
2024-02-12 09:36:19 <clandmeter> mps: bingo
2024-02-12 09:38:19 <mps> clandmeter: ?
2024-02-12 09:38:26 <clandmeter> i found the problem
2024-02-12 09:38:43 <clandmeter> its actually kind of easy to debug
2024-02-12 09:40:15 <mps> what is problem
2024-02-12 09:40:18 <clandmeter> the error is missing devm_hwmon_device_register_with_info
2024-02-12 09:40:32 <clandmeter> linker error
2024-02-12 09:40:33 <mps> yes, I saw this
2024-02-12 09:40:38 <clandmeter> so i checked where this comes from
2024-02-12 09:40:47 <clandmeter> https://www.kernel.org/doc/Documentation/hwmon/hwmon-kernel-api.txt
2024-02-12 09:40:55 <mps> from hwmon
2024-02-12 09:41:01 <clandmeter> seems hwmon is build as module
2024-02-12 09:41:20 <clandmeter> so setting it to Y fixes it
2024-02-12 09:41:33 <mps> ah, right it is
2024-02-12 09:41:41 <clandmeter> so its still a bug, but atleast can work around it
2024-02-12 09:42:00 <mps> and it must be in-kernel because mcu.o is in-kernel
2024-02-12 09:42:06 <clandmeter> exactly
2024-02-12 09:42:18 <clandmeter> well im not sure it needs to be
2024-02-12 09:42:32 <clandmeter> i guess it may need some additional code in kernel
2024-02-12 09:42:32 <mps> so, my guess at beginnig was right
2024-02-12 09:42:50 <clandmeter> you said THERMAL
2024-02-12 09:42:54 <clandmeter> iirc
2024-02-12 09:42:56 <mps> Kconfig should be fixed
2024-02-12 09:43:16 <clandmeter> anyways, glad its fixed
2024-02-12 09:43:19 <clandmeter> will report upstream
2024-02-12 09:43:36 <mps> no, when we started to talk about issue I wrote it is Kconfig or Makefile
2024-02-12 09:43:48 <clandmeter> yes, i know
2024-02-12 09:44:22 <clandmeter> my next steps will be to push your edge config + sophgo additions
2024-02-12 09:44:27 <mps> but I started with THERMAL problem and didn't had time to check hwmon
2024-02-12 09:45:22 <mps> though I build slimmed down kernel without THERMAL and HWMON as starting point to add one by one to check where it will be fail
2024-02-12 09:45:41 <mps> but network issue eat nearly all my time
2024-02-12 09:46:04 <clandmeter> would be nice to get parts of sophgo into edge kernel
2024-02-12 09:46:12 <clandmeter> so we can transition easily in the future
2024-02-12 09:46:37 <mps> but from error message it was clear that it is related to HWMON
2024-02-12 09:47:29 <mps> not sure it is good idea to add such pile of patches to kernel we ship
2024-02-12 09:48:32 <mps> you told yesterday that you don't like breakage of linux-edge
2024-02-12 09:49:49 <clandmeter> im not saying all of the things, just chery pick what seems logical 
2024-02-12 09:50:15 <clandmeter> anyways no rush, will take some time for sophgo to be stable
2024-02-12 09:51:35 <mps> their current kernel is 6.1 based and rebasing all this to 6.7 is not worth effort imo
2024-02-12 09:54:03 <mps> ah, they have https://github.com/sophgo/linux-riscv/tree/sg2042-master which is based on 6.8, this is better
2024-02-12 09:54:53 <mps> and not big pile of patches
2024-02-12 09:55:24 <mps> clandmeter: you put more work on my arms :)
2024-02-12 09:56:02 <clandmeter> forget it, we do it when its stable
2024-02-12 10:01:38 <mps> that is nearly how we now build linux-starfive, I take patches from some repo and apply them to stable
2024-02-13 00:15:02 <ptrc> https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf/-/merge_requests/17
2024-02-13 00:15:17 <ptrc> i'd appreciate if someone could double-check if i haven't made some silly mistake :)
2024-02-13 06:30:12 <ikke> merged it
2024-02-13 15:06:20 <ptrc> thanks :)
2024-02-13 15:46:06 <clandmeter> just letting know, we now have 2 pioneers functioning on our network
2024-02-13 15:46:16 <clandmeter> thx mps and ikke for helping out
2024-02-13 15:46:42 <clandmeter> ncopa: we can have a look at hosting native builders on them
2024-02-13 15:46:47 <clandmeter> if they are stable enough
2024-02-13 15:47:17 <clandmeter> ive been talking a bit with ikke about the setup of CI and builders for rv64
2024-02-13 15:47:59 <clandmeter> I think we can have 1 builder on pioneer, 1 dev box on pioneer, and CI on qemu-user
2024-02-13 15:48:16 <clandmeter> 1 builder would be actually 2, edge and next stable
2024-02-13 15:55:16 <ikke> clandmeter: one issue with having ci on qemu-user is that we still cannot enable tests, right?
2024-02-13 16:11:07 <clandmeter> right
2024-02-13 16:11:16 <clandmeter> test were a problem right?
2024-02-13 16:11:21 <clandmeter> i dont recall anymroe
2024-02-13 16:11:49 <ikke> I think that was already an issue when the port was initially created
2024-02-13 16:12:02 <ikke> I don't think we tested it recently though
2024-02-13 18:37:29 <clandmeter> ikke: do we need to rename the hosts?
2024-02-13 18:38:05 <ikke> We do if we want to have some consistency
2024-02-13 19:05:11 <clandmeter> be my guest :)
2024-02-13 19:05:23 <clandmeter> not sure what the actual policy is
2024-02-13 19:05:36 <clandmeter> I bindmounted the distfiles dir
2024-02-13 19:05:49 <clandmeter> its in the alpine conf, so for all users
2024-02-13 19:06:22 <ikke> nld-bld-x
2024-02-13 19:06:42 <clandmeter> x as in?
2024-02-13 19:06:46 <clandmeter> twitter?
2024-02-13 19:06:48 <ikke> a number
2024-02-13 19:06:53 <clandmeter> :)
2024-02-13 19:06:59 <clandmeter> yes but which number?
2024-02-13 19:07:02 <mps> :D
2024-02-13 19:07:12 <clandmeter> can start from 1?
2024-02-13 19:07:33 <ikke> They are the first ones using that scheme, so yes
2024-02-13 19:07:35 <ikke> (in nld)
2024-02-13 19:07:42 <clandmeter> oh ok
2024-02-13 19:07:58 <clandmeter> the old ones are still in old scheme
2024-02-13 19:08:02 <ikke> yes
2024-02-13 19:08:21 <ikke> nld8-dev1 and nld9-dev1
2024-02-13 19:08:29 <clandmeter> no predigits?
2024-02-13 19:08:46 <ikke> like -01?
2024-02-13 19:08:57 <clandmeter> nod
2024-02-13 19:09:00 <ikke> nope
2024-02-13 19:10:22 <clandmeter> set
2024-02-13 19:10:29 <clandmeter> what about the router?
2024-02-13 19:10:47 <mps> should we move dev lxcs for x86_64 to new dev machine
2024-02-13 19:11:01 <ikke> why? What new dev machine?
2024-02-13 19:11:08 <mps> s/for/from/
2024-02-13 19:11:25 <clandmeter> i think he means rv64 containers
2024-02-13 19:11:31 <mps> ikke: riscv lxcs 
2024-02-13 19:11:33 <ikke> ah
2024-02-13 19:11:46 <ikke> Yes, I think that's the goal
2024-02-13 19:11:58 <clandmeter> lets keep them for now
2024-02-13 19:12:09 <clandmeter> maybe these boxes get busy
2024-02-13 19:12:17 <clandmeter> so you have an alternative
2024-02-13 19:12:42 <clandmeter> or if we are limited in space, then ok.
2024-02-13 19:12:50 <mps> aha
2024-02-13 19:12:53 <mps> aha
2024-02-13 19:13:05 <clandmeter> mps: distfiles is shared on the new box
2024-02-13 19:13:05 <mps> hmm. sorry
2024-02-13 19:13:08 <clandmeter> also in your container
2024-02-13 19:13:24 <clandmeter> well maybe not just yet
2024-02-13 19:13:30 <clandmeter> let me reboot it
2024-02-13 19:13:34 <clandmeter> and it should show
2024-02-13 19:13:47 <mps> I didn't meant delete them on x86_64, move/copy to work on new
2024-02-13 19:14:09 <clandmeter> be aware we only have 1TB
2024-02-13 19:14:14 <clandmeter> and 500G distfiles
2024-02-13 19:15:30 <clandmeter> mps your lxc is restarted
2024-02-13 19:15:34 <clandmeter> should show shared distfiles
2024-02-13 19:16:12 <mps> are you sure lxc is started
2024-02-13 19:17:30 <mps> ping answers but ssh doesn't connect
2024-02-13 19:19:27 <clandmeter> did you add ssh to rc?
2024-02-13 19:19:46 <clandmeter> ikke: docker does not like mft
2024-02-13 19:19:48 <clandmeter> ntf
2024-02-13 19:20:34 <mps> clandmeter: I didn't, I expected you did
2024-02-13 19:20:51 <clandmeter> expect the unexpected 
2024-02-13 19:20:55 <ikke> ntf?
2024-02-13 19:21:00 <mps> I can't add it even
2024-02-13 19:21:10 <mps> if I can't connect
2024-02-13 19:21:51 <mps> nft?
2024-02-13 19:21:54 <clandmeter> https://tpaste.us/rjkD
2024-02-13 19:22:36 <ikke> netfilter
2024-02-13 19:22:57 <clandmeter> mps: try now
2024-02-13 19:23:12 <ikke> clandmeter: kernel updated without rebooting?
2024-02-13 19:23:13 <mps> clandmeter: now it works
2024-02-13 19:23:24 <clandmeter> ikke: nope
2024-02-13 19:23:28 <clandmeter> should be the right kernel
2024-02-13 19:23:52 <clandmeter> mps: should docker work on edge kernel?
2024-02-13 19:24:03 <ikke> is nftables enabled in the kernel?
2024-02-13 19:24:04 <mps> Linux mps-edge-riscv64 6.1.72-5-sophgo #6-Alpine SMP PREEMPT Mon, 12 Feb 2024 22:35:57 +0000 riscv64 Linux
2024-02-13 19:24:08 <mps> clandmeter: yes
2024-02-13 19:24:31 <mps> ikke: yes
2024-02-13 19:24:43 <clandmeter> msg="exec: \"fuse-overlayfs\": executable file not found in $PATH" storage-driver=fuse-overlayfs
2024-02-13 19:25:01 <mps> clandmeter rebased config on riscv64 linux-edge
2024-02-13 19:25:36 <clandmeter> do we need to install fuse-overlayfs?
2024-02-13 19:25:39 <mps> clandmeter: I see content of distfiles
2024-02-13 19:28:01 <clandmeter> ok
2024-02-13 19:28:51 <mps> 'ping www.google.com' doesn't work
2024-02-13 19:29:01 <clandmeter> right
2024-02-13 19:29:03 <clandmeter> dns is broken
2024-02-13 19:29:07 <clandmeter> for now use 1.1.1.1
2024-02-13 19:29:11 <mps> aja
2024-02-13 19:29:12 <clandmeter> or whatever you prefer
2024-02-13 19:29:15 <mps> aha
2024-02-13 19:29:21 <clandmeter> ikke: need to fix dnsmasq dns
2024-02-13 19:29:28 <mps> though 'aja' is fine :)
2024-02-13 19:29:43 <clandmeter> its dutch
2024-02-13 19:29:47 <clandmeter> dutch is tha best
2024-02-13 19:30:05 <clandmeter> seems for overlay i needed to modprobe it
2024-02-13 19:30:30 <mps> I agree about dutch
2024-02-13 19:30:56 <mps> finaly we found something about we all agree ;-)
2024-02-13 19:31:00 <clandmeter> i guess we need to load the iptables/nft modles
2024-02-13 19:31:29 <mps> clandmeter: they should be loaded automagically
2024-02-13 19:31:38 <clandmeter> there is not much loaded
2024-02-13 19:31:50 <clandmeter> https://tpaste.us/PEWb
2024-02-13 19:32:30 <mps> I'm always irritated by all this pile of module loaded when I run iptables
2024-02-13 19:32:58 <mps> sure, they are not loaded
2024-02-13 19:33:55 <clandmeter> also complains about aufs
2024-02-13 19:34:01 <clandmeter> its not in edge kernel
2024-02-13 19:34:03 <clandmeter> not sure we need it
2024-02-13 19:34:49 <clandmeter> failed to start daemon: Error initializing network controller: error creating default "bridge" network: Failed to Setup IP tables: Unable to enable NAT rule:  (iptables failed: iptables --wait -t nat -I POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE: Warning: Extension MASQUERADE revision 0 not supported, missing kernel module?
2024-02-13 19:34:49 <clandmeter> iptables v1.8.10 (nf_tables):  CHAIN_ADD failed (No such file or directory): chain POSTROUTING
2024-02-13 19:35:40 <clandmeter> those are the same errors i got with lxc bridge before
2024-02-13 19:35:56 <mps> veth module?
2024-02-13 19:36:21 <clandmeter> Warning: Extension MASQUERADE revision 0 not supported, missing kernel module?
2024-02-13 19:36:24 <mps> ah, you use bridge
2024-02-13 19:36:28 <clandmeter> it was the compat
2024-02-13 19:36:37 <clandmeter> i dont use anythign, just starting docker
2024-02-13 19:37:13 <mps> I didn't disabled anything related to iptables in linux-edge
2024-02-13 19:37:45 <mps> except if I'm blind (or worse, stuppid)
2024-02-13 19:38:10 <clandmeter> i think they are here
2024-02-13 19:38:17 <clandmeter> but its not automatically loaded
2024-02-13 19:38:21 <clandmeter> for whatever reason
2024-02-13 19:38:43 <clandmeter> there are also much more modules loaded on the other host
2024-02-13 19:38:47 <mps> does udev battery added to rc
2024-02-13 19:39:48 <clandmeter> im giving it a reboot
2024-02-13 19:39:59 <clandmeter> its like windows, who knows...
2024-02-13 19:40:39 <mps> yes, it is more and more windows like
2024-02-13 19:42:01 <mps> (remember time when I had uptime on server 3 and 4 years)
2024-02-13 19:42:10 <mps> servers*
2024-02-13 19:43:13 <clandmeter> i have one with 10+ :)
2024-02-13 19:43:39 <clandmeter> heh, it does not come back online :|
2024-02-13 19:43:50 <mps> hah, no one have access to it, even physical?
2024-02-13 19:45:07 <clandmeter> correct
2024-02-13 19:45:16 <clandmeter> offline till tmorrow morning :)
2024-02-13 19:45:41 <clandmeter> i can force a power toggle. 
2024-02-13 19:45:48 <clandmeter> but i would like to know whats going on
2024-02-13 19:46:11 <mps> I have one arm SBC working and I can't access it for about 5 years, but i know it still works
2024-02-13 20:42:44 <ikke> lol
2024-02-13 20:52:06 <mps> reading this https://www.top10vpn.com/research/wifi-vulnerabilities/ and https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=6415420f1c92012f64063c131480ffcef58e60ca I think we must backport iwd from edge to 3.19
2024-02-14 07:58:16 <clandmeter> ikke: we dont have docker alpine linux/riscv64?
2024-02-14 07:58:50 <clandmeter> i guess its because of missing stable?
2024-02-14 08:15:14 <ikke> I think i built something on nld-dev-1
2024-02-14 08:15:26 <ikke> We have docker for our ci 
2024-02-14 08:32:04 <clandmeter> yes i was holding it wrong
2024-02-14 08:32:08 <clandmeter> how to reg a runner?
2024-02-14 08:32:13 <clandmeter> the process has changed?
2024-02-14 08:39:25 <clandmeter> ikke: can you explain where to get all the tokens from?
2024-02-14 08:39:46 <ikke> You pre register a runner now 
2024-02-14 08:40:45 <ikke> For shared runners, you can do that here https://gitlab.alpinelinux.org/admin/runners
2024-02-14 08:40:51 <ikke> Top right 
2024-02-14 11:03:59 <clandmeter> ikke: i did that, but do i still need to use that compose thing we have?
2024-02-14 11:17:54 <ikke> clandmeter: That's the easiest way to register the various runners we use
2024-02-14 11:21:53 <clandmeter> ikke: the compose askes for much more tokens
2024-02-14 11:21:58 <clandmeter> thats whats confusing
2024-02-14 11:22:29 <ikke> It registers one shared runner, a group runner and a project runner
2024-02-15 09:54:44 <KREYREN_oftc> mps, have you made any progress on the teres's kernel?
2024-02-15 11:40:49 <mps> ncopa: is there problem with !57838
2024-02-15 11:42:03 <ikke> mps: it doesn't help that you marked it as a draft
2024-02-15 11:42:12 <ikke> it means that the MR is not ready to merge yet
2024-02-15 11:43:02 <mps> hm, I expected comment if something is bad or approve  and then change status
2024-02-15 11:43:42 <mps> but ok, changed it
2024-02-15 11:43:42 <ikke> It's the other way around. You mark it as ready, which means it's ready for review
2024-02-15 11:44:15 <ikke> draft means: I made an MR to test this package, but the MR is not ready yet, so don't merge / review it just yet.
2024-02-15 11:44:33 <mps> aha, understand
2024-02-15 11:45:42 <ikke> also, there is apparently a merge conflict
2024-02-15 11:45:47 <ikke> "Merge blocked: fast-forward merge is not possible. To merge this request, first rebase locally."
2024-02-15 11:46:44 <ikke> It has been upgraded to 4.0.12 in the mean time
2024-02-15 11:47:32 <mps> 
ACTION really hates rebasing

2024-02-15 14:14:48 <mps> looks line x86_64 CI have problem https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1278231#L4983
2024-02-15 14:15:06 <mps> and maybe also armv7 and aarch64
2024-02-15 14:15:32 <ikke> you amended the dotnet6 commit
2024-02-15 14:15:37 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57838/commits
2024-02-15 14:20:45 <mps> omg
2024-02-15 14:21:35 <mps> just closed MR
2024-02-15 15:06:16 <ikke> I could've helped you
2024-02-15 15:07:41 <mps> ikke: np, I created new MR with latest wireshark release !60892
2024-02-17 09:21:19 <mps> clandmeter: could we use sophgo machine for development from now (don't want to keep two dev containers)
2024-02-17 10:36:45 <mps> hm, nvm, looks like machine is not accessible
2024-02-17 13:23:31 <clandmeter> mps: the machines are online, they are active on CI
2024-02-17 13:26:41 <mps> clandmeter: I can't ping my lxc, so probably lost IP address
2024-02-17 13:28:58 <clandmeter> ikke: can you look at docker lxc setup?
2024-02-17 13:29:25 <clandmeter> i think docker is preventing the containers from receiving a dhcp address
2024-02-17 14:11:09 <mps> celie: minio-client needs 'cgo' in makedepends I guess
2024-02-17 15:43:31 <ikke> clandmeter: did you enable awall_dedicated_chains?
2024-02-18 16:29:34 <clandmeter> ikke: those machines do not have awall installed
2024-02-18 16:29:38 <clandmeter> they are behind the router
2024-02-18 16:29:42 <ikke> ah ok
2024-02-18 16:31:09 <ikke> And dhcp stopped working after you installed dhcp?
2024-02-18 16:31:11 <ikke> docker*
2024-02-18 16:31:49 <clandmeter> yes after docker
2024-02-18 16:32:30 <ikke> sounds similar to what we saw on nld-dev-1 then
2024-02-18 16:34:26 <ikke> Chain FORWARD (policy DROP)
2024-02-18 16:37:12 <ikke> yup
2024-02-18 16:37:17 <ikke> iptables -I FORWARD -p udp -m multiport --destination-ports 67,68 -j ACCEPT
2024-02-18 16:37:30 <ikke> mps container has an ip now
2024-02-18 16:37:39 <ikke> and now your container as well
2024-02-18 18:51:07 <clandmeter> ikke: thx
2024-02-18 18:51:24 <ikke> Need to find a way to make it permanent, though
2024-02-18 18:51:34 <ikke> How are you adding the masquerade rul?
2024-02-18 18:51:37 <ikke> rule
2024-02-19 10:04:52 <clandmeter> ikke: im not, i guess from docker
2024-02-19 11:15:08 <ikke> clandmeter: right, only for docker, I confused one of the bridges
2024-02-19 11:15:17 <ikke> So that means the containers do not have any internet, right?
2024-02-19 11:18:03 <clandmeter> they used to have internet
2024-02-19 11:18:20 <clandmeter> but it could be that docker messes up the networking
2024-02-19 11:20:11 <ikke> You need a masquerade rule for internet to work
2024-02-19 11:46:39 <clandmeter> ikke: it was working before docker 
2024-02-19 11:47:01 <ikke> without adding any specific iptables rules?
2024-02-19 11:53:45 <clandmeter> yes
2024-02-19 11:54:04 <clandmeter> there was no iptables installed
2024-02-19 11:54:17 <clandmeter> its a bridge on eth0
2024-02-19 11:54:45 <clandmeter> only needs routing 
2024-02-19 11:55:57 <ikke> oh, NAT is done on the router, of course
2024-02-19 11:56:10 <ikke> So it's the same isue, forwarding is blocked
2024-02-19 11:56:20 <ikke> Do you mind if I install awall on them with some simple policies?
2024-02-19 11:59:22 <clandmeter> go ahjead
2024-02-19 11:59:49 <clandmeter> another way is to add it to interface definition if its just a single rule
2024-02-19 12:06:07 <ikke> I have something, can you test it?
2024-02-19 12:40:07 <clandmeter> looks like it works
2024-02-19 12:41:22 <clandmeter> ikke: i think you killed ssh 
2024-02-19 12:55:41 <clandmeter> ikke: i cleared all the fw rules as ssh was no longer possible
2024-02-19 12:55:57 <ikke> Sure
2024-02-19 12:56:54 <clandmeter> did you create adp-ssh-server?
2024-02-19 12:56:56 <clandmeter> err
2024-02-19 12:57:13 <clandmeter> adp-ssh-server.json
2024-02-19 12:58:09 <clandmeter> ikke: the rtr zone is created by you?
2024-02-19 12:58:15 <ikke> Yes
2024-02-19 12:58:26 <clandmeter> oh its in the same file
2024-02-19 12:58:27 <clandmeter> duh
2024-02-22 21:09:57 <KREYREN_oftc> mps, https://itycodes.org/A64.html
2024-02-22 21:10:14 <KREYREN_oftc> we are working on the kernel modules documentation so this might help atm
2024-02-22 21:39:24 <mps> KREYREN_oftc: ok. and thanks. but this talk doesn't belong here
2024-02-22 21:40:02 <mps> maybe #linux-arm channel
2024-02-22 21:41:52 <KREYREN_oftc> #linux-arm is empty
2024-02-22 21:43:16 <mps> anyway this talk doesn't belong here, imo
2024-02-22 21:44:58 <mps> to be clear, I really appreciate your effort to make alpine better on A64 and don't want to be 'bad' to you
2024-02-22 21:45:52 <mps> and you really helped
2024-02-22 21:48:36 <mps> I'm ready to add all modules/options to linux-edge needed for A64. Creating issue (or even merge request) from someone and I promise I will take it into account (though I don't merge requests)
2024-02-22 21:49:02 <mps> I don't like*
2024-02-22 21:49:57 <mps> maybe someone could create #linux-arm
2024-02-22 21:50:02 <mps> oh no
2024-02-22 21:50:13 <mps> #alpine-arm
2024-02-22 21:51:19 <mps> (not good idea to talk publicly when having headache all the day)
2024-02-27 19:28:01 <mps> oh, didn't we had discussion somewhere with conclusion that anything 'systemd*' is unacceptable for alpine? !!61369
2024-02-27 19:29:18 <mps> KREYREN_oftc: Check latest linux-edge on A64 (TERES-I) please. I think everything is there though I didn't had time to test
2024-02-27 20:24:15 <ikke> mps: there is no blank ban on anything systemd
2024-02-27 20:24:52 <ikke> mps: except for the name, this seems to be a pretty standalone project
2024-02-27 20:25:08 <ikke> no dependency on libsystemd or something like that
2024-02-27 21:02:07 <mps> ikke: name is 'hurting' my eyes
2024-02-27 21:03:09 <mps> I mean, when I see it related to alpine
2024-02-27 21:04:31 <ikke> We can call the package not-systemd-boot
2024-02-27 21:05:14 <mps> :)
2024-02-27 21:05:46 <mps> no, not needed to change name
2024-02-27 21:06:23 <ikke> It was a joke :P
2024-02-27 21:06:55 <mps> I just express my fear that this is first step to full systemd in alpine. you know how these things goes: in small steps
2024-02-27 21:43:11 <minimal> I was actually in the process of packaging this myself, not for systemd-boot but just for thr systemd EFI stub - both gummiboot and stubbyboot are not actively developed and there's no other EFI stub alternative to use for UKI
2024-02-27 21:44:57 <minimal> I'm also writing an related tool for Alpine and considered making it compatible with a equivalent systemd tool but suspected someone might complain if the package installed a systemd-XYZ softlink
2024-02-27 21:45:06 <minimal> s/an related/an unrelated/
2024-02-27 21:49:57 <mps> minimal: u-boot works very fine
2024-02-27 21:56:43 <minimal> that's not a EFI stub
2024-02-27 21:57:04 <minimal> I'm refering to UKI booting
2024-02-29 11:18:38 <ikke> big spam wave, luckily all with the same mail domain
2024-02-29 16:06:44 <ikke> ncopa: vpsFree asks us to change the IP address of dl-master. The e-mail mentions to do that in vpsAdmin. Do we have access to that, or do we need to ask Jirutka to take care of it?
2024-02-29 16:55:03 <ncopa> i dont think we have access
2024-02-29 16:55:33 <ncopa> maybe you could send an email to jirutka, and ask if we could get access to the vpsAdmin?