2024-03-01 13:04:40 <ncopa> I am not able to reproduce the test failure on my ppc64le dev container: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61406
2024-03-01 13:05:00 <ncopa> i notice that our gitlab-runner-ppc64le runs old kernel
2024-03-01 13:05:05 <ncopa> and alpine 3.16
2024-03-01 13:05:13 <ncopa> do we dare to upgrade it to 3.18?
2024-03-01 13:05:22 <ncopa> or maybe 3.19?
2024-03-01 13:06:20 <ncopa> not sure we should upgrade anything to 3.19 until this is fixed: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15607
2024-03-01 13:07:50 <ncopa> the host needs to be updated to latest 3.16 in any case
2024-03-01 16:12:46 <ikke> ncopa: I need to send an e-mail to them
2024-03-01 16:13:06 <ikke> ncopa: fyi, I've upgraded nld-dev-1 (dev containers) without issue to 3.19
2024-03-01 16:13:23 <ncopa> ok. good to know
2024-03-01 16:13:28 <ncopa> i suppose lxc-top does not work
2024-03-01 16:18:24 <ikke> let me check
2024-03-01 16:18:41 <ikke> yeah, I think it shows issues
2024-03-01 16:18:43 <ikke> never used it before
2024-03-01 16:19:00 <ikke> If I use arrow keys, I see cgroup errors
2024-03-01 21:59:48 <ptrc> could someone take a look at arm CI runners?
2024-03-01 21:59:59 <ptrc> > tar: kubeone-1.7.3/CHANGELOG.md: Cannot change mode to rwxr-xr-x: Operation not permitted
2024-03-02 18:07:48 <ikke> ptrc: Since when did this start? Maybe a musl issue?
2024-03-02 18:07:56 <ptrc> o
2024-03-02 18:08:03 <ptrc> i've seen it like, maybe 2 days ago
2024-03-02 18:08:04 <ikke> Not sure, but it's strange
2024-03-02 18:08:08 <ptrc> but only on CI
2024-03-02 18:08:11 <ptrc> nothing like that on the builders
2024-03-02 18:08:14 <ptrc> and only the 32-bit arm ones
2024-03-02 18:08:20 <ikke> https://git.alpinelinux.org/aports/commit/?id=18e4c04733b4
2024-03-02 18:08:29 <ikke> That was yesterday
2024-03-02 18:10:35 <ikke> ptrc: I suspect seccomp
2024-03-02 18:10:41 <ikke> If new syscalls are used
2024-03-02 18:11:21 <ikke> though, there should not be a lot of changes
2024-03-02 18:30:34 <ikke> don't get any errors when I build manually on the same hosts
2024-03-02 18:41:06 <ikke> anoying
2024-03-02 19:21:00 <mps> algitbot: retry master
2024-03-02 20:18:42 <ikke> fchmodat2(3, "direnv-2.34.0/test/scenarios/symlink-dir/bar", 0755, AT_SYMLINK_NOFOLLOW) = -1 EPERM (Operation not permitted)
2024-03-02 20:25:25 <ikke> ptrc: upgrading alpine (from 3.18) seems to fix it
2024-03-02 22:37:08 <ptrc> ooh, nice
2024-03-02 22:37:09 <ptrc> thanks :)
2024-03-03 02:46:50 <ptrc> i'm not sure if the topic has been mentioned before, but has anyone looked into getting some statistics per path from fastly cdn? package usage data would be very useful in some cases
2024-03-03 07:24:39 <ikke> ptrc: I'm not sure how actually usefull that is except for getting some rough idea. You fail to capture packages used by other mirrors or even private mirrors
2024-03-03 16:07:56 <ptrc> i don't think the usage statistics would differ too much between mirrors?
2024-03-03 16:08:09 <ptrc> and dl-cdn is the most commonly used one, i would assume
2024-03-03 18:52:22 <clandmeter> ptrc: any idea on how to do that?
2024-03-03 18:52:36 <ptrc> not yet
2024-03-03 18:52:37 <clandmeter> if we do we might need to announce it
2024-03-03 18:52:44 <clandmeter> as we always said we dont track anything
2024-03-06 11:45:49 <ncopa> do we have the riscv64 machines connected to zabbix so we get stats of load etc?
2024-03-06 11:46:02 <ikke> Not at the moment
2024-03-06 21:53:06 <mps> ikke: are you around. I can't ssh from pioneer lxc (172.16.30.101) to x86_64 lxc (172.16.26.16) but ping works. iirc it was some firewall problem earlier
2024-03-06 21:53:25 <mps> do you remember what was solution
2024-03-06 21:55:11 <ikke> I do remember it somewhat, but too tired right now to dive into it again
2024-03-06 21:57:16 <mps> ok, no hurries. Also I'm tired. Will upgrade linux-edge tomorrow
2024-03-07 09:05:23 <mps> eh, https://postmarketos.org/blog/2024/03/05/adding-systemd/
2024-03-07 09:05:34 <mps> :)
2024-03-07 11:41:09 <ncopa> I wonder if we have problems with CLOCK_REALTIME on our ppc64le docker: https://github.com/docker/for-win/issues/8326
2024-03-07 11:43:07 <ncopa>   File "/builds/alpine/aports/main/python3/src/Python-3.12.2/Lib/test/test_time.py", line 143, in test_clock_settime
2024-03-07 11:43:07 <ncopa> OSError: [Errno 38] Function not implemented
2024-03-07 11:43:07 <ncopa>     time.clock_settime(time.CLOCK_REALTIME, t)
2024-03-07 11:43:32 <ncopa> from here: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1294945
2024-03-07 13:31:18 <ncopa> alright, think it is docker issue. It passes in my ncopa-edge-ppc64le container
2024-03-07 13:32:50 <ncopa> maybe we should upgrade gitlab-runner-ppc64le from 3.16 to 3.19?
2024-03-07 13:33:44 <ncopa> do we have anybody available in case it fails to boot?
2024-03-07 13:36:45 <ikke> I guess we need to send them an e-mail
2024-03-07 13:41:24 <ncopa> maybe I create an issue for infra?
2024-03-07 13:41:36 <ncopa> I'd just like to upgrade the docker version to latest
2024-03-07 13:42:10 <ncopa> or I just upgrade it, reboot and hope for the best?
2024-03-07 13:42:18 <ncopa> and we ping them if it fails to boot?
2024-03-07 15:43:09 <ncopa> ok i am rebooting it now
2024-03-07 15:43:27 <ikke> alright
2024-03-07 15:43:30 <ikke> let's see
2024-03-07 15:43:54 <ikke> fyi, I did try to add the pioneer boxes to monitoring yesterday, but the traffic is still being blocked for some reason
2024-03-07 15:44:11 <ncopa> might be clandmeters network blocks it?
2024-03-07 15:44:53 <ikke> it's vpn
2024-03-07 15:44:57 <ncopa> gitlab-runner-ppc64le stopped to respond to pings
2024-03-07 15:46:05 <ncopa> then it came back for a  ~10 seconds
2024-03-07 15:46:13 <ncopa> and now its gone again
2024-03-07 15:47:33 <ncopa> the machine responds to ping bug does not accept ssh connections
2024-03-07 15:47:53 <ncopa> maybe sshd was not configured to autostart
2024-03-07 15:49:45 <ncopa> ok. I need to write email to IBM... sorry about that
2024-03-07 15:50:23 <mick_ibm> the boxes at osu?
2024-03-07 15:50:48 <ikke> yes
2024-03-07 15:50:58 <ikke> alpine-p9
2024-03-07 15:54:21 <mick_ibm> i just reached out to lab admin now 
2024-03-07 15:54:55 <ikke> thanks
2024-03-07 15:56:19 <ikke> I don't think it's just sshd that's not running, there is no outbound configuration either
2024-03-07 15:56:27 <ikke> output traffic (zabbix agent)
2024-03-07 15:57:13 <mick_ibm> Ramereth
2024-03-07 15:58:39 <ncopa> hi mick_ibm! so happy to see you!
2024-03-07 15:58:51 <mick_ibm> hello again :) 
2024-03-07 16:01:05 <ncopa> might be firewall issue. if they can do:  `iptables -I INPUT  -p tcp -m tcp --dport 22 -j ACCEPT`, then I'll log inand clean it up
2024-03-07 16:02:52 <ncopa> mick_ibm: so I dont need to write an email?
2024-03-07 16:05:47 <clandmeter> ikke: im not blocking anything
2024-03-07 16:05:56 <clandmeter> but could the the alpine gw infrond of it
2024-03-07 16:06:17 <mick_ibm> Ramereth is the admin but its about 08:00 in the morning here. i messaged him on slack but might be too early. so perhaps email is best to summarize the problem easier - i can provide the email address if you need it
2024-03-07 16:07:07 <ikke> mick_ibm: I gave ncopa the powerdev mail address
2024-03-07 16:07:20 <mick_ibm> oh sweet thanks
2024-03-07 16:07:41 <ncopa> ok. I upgraded the machine to alpine v3.19, with 6.6.21 and rebooted it. it responds to ping but no longer accept ssh connections
2024-03-07 16:09:08 <Ramereth> ncopa: I'm in a meeting right now but I can take a look later this morning. Please send an email to support@ with details
2024-03-07 17:09:54 <Ramereth> ikke ncopa: looks like my IPMI password isn't working. I will need to go into the data center later this morning and connect up a console to resolve that and also see what's going on. Please also send an email so we can get a ticket going
2024-03-07 17:11:36 <ikke> Ramereth: I'll send one
2024-03-07 17:13:20 <ncopa> thanks. im in a meeting now, sorry
2024-03-07 17:30:34 <ikke> Ramereth: request has been sent and received
2024-03-07 17:30:47 <Ramereth> +1
2024-03-07 17:30:56 <Ramereth> how urgent is it getting this back online? 
2024-03-07 17:34:03 <ikke> Not super urgent, but we cannot build any ppc64le packages atm
2024-03-07 17:34:10 <ncopa> I was aware of the risk when I did the reboot and calculated downtime a few hours to a day max
2024-03-07 17:34:15 <ikke> ^
2024-03-07 17:34:37 <Ramereth> I will get to it this early afternoon PST
2024-03-07 17:35:12 <ikke> 👍
2024-03-07 17:35:12 <ncopa> thank you!
2024-03-07 21:43:58 <Ramereth> ikke ncopa is it back online properly?
2024-03-07 21:44:32 <Ramereth> I guess so? lol
2024-03-07 21:44:40 <ikke> heh, yes
2024-03-07 21:44:44 <ikke> I can ssh into it again, thanks!
2024-03-07 21:45:22 <ncopa> its up! thanks! what was the problem?
2024-03-07 21:45:26 <Ramereth> great. I will explain more in the ticket later what appeared to have happened
2024-03-07 21:45:38 <Ramereth> but nothing you did wrong on your end
2024-03-07 21:46:04 <ncopa> ok. thanks. then I can sleep well :)
2024-03-07 22:07:27 <mps> nice, risvc64 CI is active by default
2024-03-07 22:09:07 <ikke> yes
2024-03-10 18:11:37 <ikke> mps: can you check if the connection from pioneer to x86_64 works now?
2024-03-10 18:12:08 <ikke> ncopa: we're now getting data from the pioneer boxes
2024-03-10 18:12:41 <ikke> clandmeter: I've added an extra rule to the router to allow traffic from lxc to dmvpn
2024-03-10 18:14:58 <mps> ikke: still doesn't work, ping does
2024-03-10 18:17:55 <ikke> seems to work for me, what is the ip address you try to ssh to?
2024-03-10 18:19:01 <mps> 172.16.26.16
2024-03-10 18:19:46 <ikke> from where?
2024-03-10 18:20:03 <mps> I can ssh from 172.16.26.16 to 172.16.30.101
2024-03-10 18:20:17 <ikke> I can ssh the other way around as well
2024-03-10 18:20:29 <mps> but not reverse
2024-03-10 18:21:04 <ikke> https://tpaste.us/XyMD 
2024-03-10 18:21:28 <mps> hm just started to work
2024-03-10 18:22:48 <mps> strange
2024-03-10 18:24:40 <mps> scp also works
2024-03-10 18:24:56 <mps> ikke: thanks
2024-03-11 12:50:58 <nmeum> ikke: when you have the time, could you set me up with a ppc64le lxc to debug https://gitlab.alpinelinux.org/alpine/aports/-/issues/15862 ? I have wireguard access
2024-03-11 21:54:20 <mps> could someone build rust-1.74.1 pkg in separate aports. needed for asahi kernel 6.8
2024-03-11 21:55:02 <mps> I'm tired (and angry somewhat) with 'smart' new things
2024-03-11 21:55:46 <mps> we have rust aport without maintainer
2024-03-11 21:56:26 <mps> important pkg doesn't have maintainer. not good at least
2024-03-11 21:57:02 <ncopa> cant you patch kernel 6.8?
2024-03-11 21:58:08 <mps> ohm sorry maintainer is set with latest commit
2024-03-11 21:59:11 <mps> ncopa: mmaybe, but it is not worth effort (I think) and not what we should do to keep 'things' sane in alpine
2024-03-11 22:00:10 <mps> all this mess is not good but I really don't have idea how to solve it in alpine
2024-03-11 22:01:11 <mps> we are coming to point where we have to rethink about these problems
2024-03-11 22:01:18 <mps> IMO, ofc
2024-03-11 22:02:49 <mps> I have feeling these new langs and their ecosystem will become high burden for us
2024-03-11 22:03:36 <mps> sorry for angry words
2024-03-11 22:06:31 <ncopa> no, i agree. they are a burden when it is expected that you can simply pick any version of given language
2024-03-11 22:06:49 <ncopa> have that with python too nowadays. python 3.12 does not work? just use python 3.11
2024-03-11 22:07:13 <mps> heh, yes
2024-03-11 22:08:12 <mps> I feel that we would have to think in near future how to solve such problem for alpine
2024-03-11 22:08:28 <mps> problems*
2024-03-11 22:09:21 <mps> but good night for now, "morning is wiser than evening"
2024-03-12 00:42:05 <celie> Sorry for reviving a discussion that ended a few hours ago, but don't we have Rust 1.76 in edge aleady?
2024-03-12 00:45:48 <celie> and Alpine 3.19 also has Rust 1.75
2024-03-12 00:49:01 <celie> or does the Asahi kernel need 1.74.1 specifically, and not something newer than that?
2024-03-12 07:49:58 <mps> celie: kernel needs exactly 1.74.1 rust version. it doesn't build without (heavy?) patching
2024-03-12 07:50:54 <mps> I mean, mainline kernel 6.8 need this
2024-03-12 07:51:46 <mps> you can try in its tree `make rustavailable` to see
2024-03-12 08:52:29 <ikke> That means Asahi cannot be built at the moment 
2024-03-12 08:53:49 <mps> ikke: right
2024-03-12 08:55:16 <mps> I built rust 1.73.0 with locally preserved rust 1.72 and I tried to build rust 1.74.1 with it but it failed
2024-03-12 08:57:20 <mps> knowing this problem in advance about 6 months ago I proposed to keep versioned rust aports in testing but ncopa was against and didn't made it (now I see I should and don't care what he thinks though I understand his 'fears')
2024-03-12 08:58:26 <mps> and problem is not related only to asahi, there is first driver written in rust in mainline and not related to asahi kernel
2024-03-12 09:02:34 <ikke> It's a problem with the rust ecosystem
2024-03-12 09:03:25 <mps> yes. this is what wrote above (about these new langs)
2024-03-12 09:04:56 <celie> Did you build Rust 1.74.1 with 1.73 or 1.72?
2024-03-12 09:06:34 <mps> celie: with 1.73
2024-03-12 09:06:41 <celie> Ok
2024-03-12 09:07:00 <mps> tried to build, it failed to build
2024-03-12 09:08:38 <celie> Ah, there was this delicate dance between 1.72 and 1.74 where main/rust was switched to LLVM
2024-03-12 09:10:19 <celie> and we also had to partially revert a patch
2024-03-12 09:11:33 <celie> Anyway, i think that patch was only needed on 32-bit ARM
2024-03-12 09:13:09 <celie> So, if you're trying to build Rust locally on aarch64, then maybe you can skip that patch (revert-pr-114382) altogether
2024-03-12 09:13:41 <celie> Sorry, switch to LLVM 17*
2024-03-12 09:15:51 <celie> Probably you will still have to rebuild Rust 1.73 with LLVM 17, before building 1.74.1, but without having to apply the patch then revert half of it on the next rebuild (and the other half again...), it saves quite a bit of trouble
2024-03-12 09:29:28 <mps> celie: I tried without this patch, anyway it doesn't apply to 1.74
2024-03-12 09:32:36 <mps> I can build kernel with some other distro but I'm trying to think what would be good enough solution for alpine
2024-03-12 09:51:56 <celie> The patch needs to be not applied to 1.73
2024-03-12 09:53:52 <celie> I mean, i am under the impression that you followed what was done to main/rust in aports
2024-03-12 09:55:27 <celie> For aports, revert-pr-114382.patch was applied to 1.73.0-r0 to solve the 32-bit ARM build issue
2024-03-12 09:56:09 <celie> Then for 1.73.0-r1, two things happened: _llvmver was increased to 17, and half of revert-pr-114382.patch was reverted
2024-03-12 09:57:24 <celie> Lastly, 1.73.0-r1 was used to build 1.74.1-r0, where revert-pr-114382.patch was completely removed
2024-03-12 09:57:44 <mps> celie: 1.73 build fine without any problem
2024-03-12 09:58:14 <mps> I looked patched and see most is already in 1.74 upstream
2024-03-12 09:58:55 <celie> Yes, if 1.73 builds fine without the patch, then you don't have to bother with it
2024-03-12 10:03:49 <mps> hm, maybe not explained correctly, patch is needed for 1.73 and with it build is fine
2024-03-12 10:04:18 <celie> Can you try without it?
2024-03-12 10:04:31 <mps> patch is removed with upgrade to 1.74 and you did this so I guess you remember
2024-03-12 10:04:55 <mps> which? 1.73?
2024-03-12 10:05:04 <celie> Yes
2024-03-12 10:05:16 <celie> Try building 1.73 without revert-pr-114382.patch
2024-03-12 10:05:23 <mps> why if it build fine with patch
2024-03-12 10:05:54 <celie> because you will have to partially revert it on the next rebuild
2024-03-12 10:06:19 <mps> ok, will try later
2024-03-12 10:06:31 <celie> In other words, if you build 1.73 with revert-pr-114382.patch, then you will need a 1.73.0-r1 before you get to 1.74
2024-03-12 10:07:07 <celie> Without the patch, it probably doesn't matter, you can go to 1.74 straight away
2024-03-12 10:07:55 <celie> but we did two things in 1.73.0-r1 (one involved the patch), the other was switching to LLVM 17
2024-03-12 10:08:57 <celie> I think LLVM 17 support was only added to Rust 1.73
2024-03-12 10:10:38 <celie> So, what i am recommending is build 1.73 without revert-pr-114382.patch (and also ignore that patch for any subsequent pkgver/pkgrel), then try building 1.74.1
2024-03-12 10:13:34 <celie> I'm not sure if a 1.73.0 built with LLVM 16 can build 1.74.1 with LLVM 17, so if you try that and it doesn't work, then you'll probably need a 1.73.0-r1 built with LLVM 17
2024-03-12 10:14:19 <celie> or you can just continue using 1.74.1 with LLVM 16 if it works for you (i've never tried this)
2024-03-12 10:28:16 <mps> celie: I'm busy with $day_job now, will try later and inform you about progress and probably ask for advises. thank you
2024-03-12 10:43:37 <celie> You're welcome
2024-03-12 10:44:49 <celie> The main issue with that patch is, if you apply it, you can't go from 1.73.0 with patch to 1.74.1 with no patch, you need a 1.73.0-r1 in between
2024-03-12 10:45:27 <celie> and that patch was only for 32-bit ARM anyway, so for aarch64, it can be skipped, and you save all that trouble
2024-03-12 11:05:33 <celie> I guess the commit message we used for 1.73.0-r1 ("rebuild with llvm17") didn't convey exactly how important that step is when revert-pr-114382.patch is applied
2024-03-12 15:38:31 <mps> celie: following your advises I've got rust 1.74.1 built. thanks again
2024-03-12 15:38:58 <mps> now we have to think how to add it to aports
2024-03-12 15:50:43 <celie> You're welcome
2024-03-12 15:51:32 <celie> For aports, do you need it for any other arch besides aarch64?
2024-03-12 15:54:03 <mps> it depends, will we build some rust written drivers for kernels on other arches
2024-03-12 15:54:45 <mps> with 6.8 I don't we will need it, there is only one driver not related to asahi
2024-03-12 15:54:58 <mps> and I didn't looked at it yet
2024-03-12 15:55:32 <celie> Ok
2024-03-12 15:55:53 <mps> but for asahi we need it for aarch64
2024-03-12 15:56:51 <mps> you always can find in kernel major release which rust version is needed for it
2024-03-12 15:57:44 <mps> so, I fear we will need to keep a lot of them in future
2024-03-12 16:22:01 <celie> Yes, it doesn't help that it seems the upgrade can only go one way, and you can't build an older version with a newer one
2024-03-12 16:22:39 <ikke> You can only build the next version with the previous version, which leads to a very brittle situation
2024-03-12 16:23:00 <celie> I wonder if rust-nightly can build older versions
2024-03-12 17:10:23 <mps> ikke: that is what I did, starting with locally kept 1.70
2024-03-12 17:12:09 <celie> I'll be going AFK soon, but just want to link to something i found before i lose it again: https://github.com/msrd0/docker-abuild-arm
2024-03-12 17:19:03 <mps> I will upload all rust series I've built to my http server or to dev.a.o
2024-03-12 17:19:48 <mps> only aarch64 though
2024-03-13 12:31:49 <mps> algitbot: retry master
2024-03-14 09:29:36 <mps> algitbot: retry master
2024-03-14 11:46:21 <mps> I think #15866 should be closed because I doubt we should backport wireshark to previous stable
2024-03-14 11:55:01 <ncopa> done. thanks!
2024-03-14 19:09:23 <ikke> mps: I noticed linux-edge is using spaces for indentation for a part of the APKBUILD file, do you mind if I make it tabs consistently (which is the accepted codestyle).
2024-03-14 19:09:59 <ikke> unexpand -t2 --first-only community/linux-edge/APKBUILD
2024-03-14 19:17:09 <mps> ikke: np, though I think this should be done on next upgrade
2024-03-14 19:17:25 <ikke> I don't bump pkgrel
2024-03-14 19:17:47 <mps> you have to do same for 3.19-stable then
2024-03-14 19:17:58 <mps> by cherry-pick
2024-03-14 19:18:04 <ikke> understand
2024-03-14 19:18:21 <mps> ok then
2024-03-14 19:19:09 <mps> and thanks for saving my time :)
2024-03-14 20:59:56 <ikke> meh, there is sometimes something funky going, like a recalculation
2024-03-15 10:37:49 <nmeum> ikke: I just merged !61558 so it would now be possible to auto-assign issues to maintainers. do you think the code for doing that should be added to alpine-qa-bot or should we write a new bot since alpine-qa-bot only handles merge requests (AFAIK) right now?
2024-03-15 10:38:59 <ikke> nmeum: i think we can add that to the existing bot. Easier to maintain a single bot and its architecture is already modular 
2024-03-15 10:39:18 <nmeum> *nod*
2024-03-15 10:40:18 <nmeum> how would I best test alpine-qa-bot changes?
2024-03-15 11:19:28 <ikke> nmeum: either setup a local gitlab instance or create a personal project on gitlab.a.o 
2024-03-15 19:36:15 <mps> ikke: you didn't 'fixed' indentation of linux-edge?
2024-03-15 19:36:45 <ikke> mps: not yet, I have some merge requests ready
2024-03-15 19:36:57 <ikke> I mean, commits
2024-03-15 19:37:51 <mps> we need to upgrade linux-edge because some sec vuln, not serious though
2024-03-15 19:38:02 <mps> also linux-lts probably
2024-03-15 19:38:03 <ikke> I'm working on apkbuild-lint, and noticed that it also triggered on heredocs, so I was fixing that
2024-03-15 19:38:28 <mps> ok, we can leave it for tomorrow
2024-03-15 19:38:44 <ikke> Feel free to upgrade, I'll deal with it
2024-03-15 19:39:12 <ikke> I also saw the same issue with linux-starfive, I gather it was copied from -edge
2024-03-15 19:39:21 <mps> it will need some time for me because it is major version upgrade
2024-03-15 19:39:53 <mps> but maybe I can finish this evening
2024-03-15 19:40:50 <mps> yes, starfive also need upgrade and I hope patch for 6.7.x will work
2024-03-15 19:41:43 <mps> ok, then I will upgrade now and you can later fix 'niceties'. do you agree?
2024-03-15 19:41:49 <ikke> yes
2024-03-15 19:41:54 <mps> thanks
2024-03-15 20:35:55 <mps> ikke: I'm done. Your turn :)
2024-03-15 20:36:04 <ikke> mps: :)
2024-03-15 20:47:53 <mps> ikke: btw, starfive don't have this sec vuln fixed in new kernels. this vuln is only x86_64, some atom CPUs
2024-03-15 20:48:11 <ikke> mps: I was talking about the indentation
2024-03-15 20:48:24 <mps> hm, starfive doesn't have it at all
2024-03-15 20:48:38 <mps> ahm, ok. sorry
2024-03-16 14:16:05 <ikke> omni: o/
2024-03-16 14:16:19 <omni> ehlo
2024-03-16 16:57:11 <ikke> mps: I've pushed the whitespace fixes
2024-03-16 16:57:23 <ikke> backported linux-edge to 3.19
2024-03-16 17:31:52 <mps> ikke: thank you
2024-03-17 08:47:10 <mps> did rnalrd left alpine?
2024-03-17 08:48:02 <mps> ah no, new GL name is larena
2024-03-17 08:48:39 <mps> had to manually assign MR to him
2024-03-18 13:17:06 <qaqland> Hello(≧∇≦)ﾉ, these days I'm looking at pkgs.a.o, could we build the search with more features like typo&fuzzy, API, filter or just faster?
2024-03-18 13:21:26 <qaqland> hope I didn't disturb you all :)
2024-03-20 04:58:31 <KREYREN_oftc> mps, heads-up https://github.com/NixOS/nixpkgs/issues/297358
2024-03-21 10:38:47 <mps> Redis license changed https://lwn.net/Articles/966133/
2024-03-21 16:00:07 <qaqland> I would come back here next year to ask about search :) Bye
2024-03-22 11:35:16 <ncopa> Seems like build-3-19-ppc64le is stuck 
2024-03-22 11:39:21 <ikke> ncopa: killed the job
2024-03-22 12:05:15 <ncopa> thank you
2024-03-22 14:12:23 <ncopa> im cloning build-edge-riscv64 to new machine
2024-03-22 14:14:24 <ikke> 👍
2024-03-22 14:48:46 <ncopa> i moved it and started it up
2024-03-22 14:48:53 <ncopa> where do we set to not run the tests?
2024-03-22 14:49:10 <ncopa> or how do I re-enable running the tests on build-edge-riscv64
2024-03-22 15:03:31 <ikke> Try /etc/abuild.conf
2024-03-22 15:03:55 <ikke> ABUILD_BOOTSTRAP
2024-03-22 15:05:16 <ncopa> nothing there about ABUILD_BOOSTRAP
2024-03-22 15:06:05 <ncopa> maybe its enabled already
2024-03-22 15:07:54 <ikke> What about ~/.abuild/abuild.conf
2024-03-22 15:08:29 <ncopa> there it was
2024-03-22 15:08:32 <ncopa> thanks!
2024-03-22 15:13:40 <ikke> Are tests running in CI?
2024-03-22 15:13:48 <ncopa> yes, i think so?
2024-03-22 15:14:33 <ncopa> yes they are
2024-03-22 15:14:42 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1312226
2024-03-22 15:16:07 <ikke> 👍
2024-03-23 09:52:25 <mps> qemu 8.2.2 need glib linked with new alpine toolchain. is it ok to just rebuild glib? I tested this already and looks like all works fine. or I should create MR with glib and qemu?
2024-03-23 09:58:57 <mps> ok, created !62750
2024-03-26 10:21:03 <ncopa> hey! I need to use a machine with static ip as a ssh jump host to loongarch64. I was thinking of using dmvpn1 for this and have punched a hole in the firewall and enabled tcp forwarding. is this ok, or is there a better machine to use for this?
2024-03-26 10:32:42 <ikke> Maybe deu7, our wg hub?
2024-03-26 10:35:16 <ncopa> ok. will create a user account there then
2024-03-26 11:04:15 <clandmeter> cant we just run wg?
2024-03-26 11:56:06 <ncopa> i'd like to add dmvpn
2024-03-26 11:56:33 <ncopa> but that might be more difficult
2024-03-26 11:56:55 <ncopa> given he wants static ip address to puch hole in the firewall
2024-03-27 11:41:57 <ikke> probably to do with: "load average: 61.53, 54.74, 47.88"
2024-03-27 11:53:24 <ncopa> the machines are sweating
2024-03-27 18:38:14 <clandmeter> ikke: can we return the arm server to equinix?
2024-03-27 18:38:34 <ikke> Our CI runs on it
2024-03-27 18:40:43 <clandmeter> ikke: we just got an email from ed if we can return it
2024-03-27 18:41:20 <ikke> Yes, read it
2024-03-27 18:43:06 <ikke> Sent an e-mail to Nico
2024-03-27 18:43:27 <ikke> clandmeter: we also need to move the edge builders
2024-03-27 18:43:37 <ikke> Those I didn't move tyet
2024-03-27 18:43:39 <ikke> yet
2024-03-27 18:43:55 <ncopa> thats why it has been so stable lately. it all runs from equinix
2024-03-27 18:44:35 <ikke> yes
2024-03-27 18:45:01 <ikke> although the stable builders run on Nu's DC, and has also been stable
2024-03-27 19:16:01 <clandmeter> maybe we should move the other server as wel
2024-03-27 19:16:19 <clandmeter> uptime is lower than downtime...
2024-03-28 09:49:48 <telmich> salut
2024-03-28 09:50:05 <telmich> ikke: ping. I'm connected to vigir23 and checking out currently why/what's wrong
2024-03-28 09:52:01 <ikke> telmich: thanks
2024-03-28 09:52:30 <telmich> Hm
2024-03-28 09:52:40 <telmich> I can see that the vpn endpoint indeed last saw it long time ago: latest handshake: 58 days, 11 hours, 12 minutes, 39 seconds ago
2024-03-28 09:53:06 <telmich> You know what... if the server is really unreachable for you for so long
2024-03-28 09:53:43 <telmich> I'll kick the vpn setup, convert it to local routing, probably changing the address range on the way, but that should be significantly more reliable
2024-03-28 09:54:35 <telmich> Or... did you say for dmvpn you actually do need iPv4 anyway?
2024-03-28 09:54:49 <telmich> Trying to see how we can most reasonable simplify this setup to make it more stable/sustainable
2024-03-28 09:57:28 <ikke> dmvpn does require ipv4  but works via NAT
2024-03-28 09:58:02 <telmich> So are you saying if we give the server a private, natted IPv4 address you'll be more than happy in the end?
2024-03-28 10:02:28 <ikke> If that improves reliability, I'd say yes
2024-03-28 10:03:01 <ikke> I believe that's a similar setup as we have for the builder now
2024-03-28 10:06:38 <telmich> Ok, that is a rather simple change
2024-03-28 10:06:45 <telmich> One question remains
2024-03-28 10:07:04 <telmich> If I replug the upstream cable to private iPv4, you will clearly not be able to reconfigure the server
2024-03-28 10:07:22 <telmich> So I'll need to build at temporary bridge, potentially via vigir23
2024-03-28 10:07:32 <ikke> It will get a different ipv6 address as well?
2024-03-28 10:07:46 <telmich> In that case it would not get any IPv6 address
2024-03-28 10:08:36 <ikke> Oh ok, I didn't realize that
2024-03-28 10:10:20 <telmich> Maybe a bit background
2024-03-28 10:10:26 <telmich> Internally we run only IPv6
2024-03-28 10:10:40 <telmich> And IPv4 are always a bit special cases, usually only present on the edges
2024-03-28 10:11:38 <ikke> Yes, that was my understanding
2024-03-28 10:11:39 <telmich> So what is easy is a) providing native, IPv6 only routing b) providing nat'ed IPv4 only access
2024-03-28 10:14:34 <telmich> Ahh, and now I found the bug why vigir23 does not connect to the vpn gateway which is on another site
2024-03-28 10:15:22 <telmich> Note to myself: fiberstream based incorrect nat'ing in case I need to think about it again in the future
2024-03-28 12:55:29 <ikke> ncopa: any issue if I move the arm* builders?
2024-03-28 12:55:31 <ikke> edge
2024-03-28 13:09:06 <ikke> -
2024-03-28 16:03:59 <ncopa> ikke: no issues with that that i am aware of
2024-03-28 16:04:03 <ncopa> please go ahead
2024-03-28 16:06:17 <ikke> ncopa: alright
2024-03-28 16:19:37 <ncopa> i wonder if it would make sense to have more arm* runners
2024-03-28 16:19:50 <ncopa> reduce number of cpu cores for each runner and have more of them
2024-03-28 16:27:29 <ikke> ncopa: I guess more concurrent jobs on the same runner
2024-03-28 16:27:42 <ikke> why do you think that would help?
2024-03-28 16:31:14 <ncopa> the idea is to not block other jobs
2024-03-28 16:31:43 <ncopa> big jobs would take longer, but other runners would be availble for other, smaller jobs
2024-03-28 17:48:14 <ikke> ncopa: build-edge-aarch64 has moved
2024-03-28 18:59:40 <ncopa> thank you!
2024-03-28 19:00:54 <ikke> Working on armv7 and armhf
2024-03-28 19:02:29 <ikke> armv7 moved
2024-03-28 21:11:49 <ikke> armhf has been moved as well
2024-03-29 08:41:59 <ncopa> ikke: thank you for taking care of the arm builders!
2024-03-29 12:14:25 <clandmeter> ikke: all arm boxes back?
2024-03-29 12:16:53 <clandmeter> few more runners would increase the single thread performance.
2024-03-29 12:17:05 <clandmeter> but multithread will suffer
2024-03-29 12:17:19 <clandmeter> if you limit them by cores
2024-03-29 12:20:34 <clandmeter> ncopa, ikke, maybe apply the same logic to rv64
2024-03-29 12:20:53 <clandmeter> its numa aware
2024-03-29 12:32:36 <ikke> che-ci-1 is not back yet
2024-03-29 12:33:30 <ikke> Once that's back, we should be able to return usa-bld-1
2024-03-29 13:30:38 <mps> util-linux 2.40 now requires sqlite. should we add it for alpine or remove lastlog
2024-03-29 16:55:56 <mps> iiuc we are safe (at least for now) from this attack https://www.openwall.com/lists/oss-security/2024/03/29/4
2024-03-29 18:45:13 <ikke> mps: this was discussed in #alpine-devel
2024-03-29 18:46:18 <mps> ikke: thanks
2024-03-30 02:00:29 <celie> There have been some comments at !63132 about aarch64 not getting xz-5.6.1-r2
2024-03-30 06:39:27 <ikke> celie: thanks, I've fixed it now
2024-03-30 10:02:36 <ncopa> we should probably revert to 5.4, just in case
2024-03-30 10:04:15 <ncopa> but github removed the xz project so we cannot
2024-03-30 10:06:23 <mps> ncopa: debian archive?
2024-03-30 10:08:39 <celie> It's still on distfiles
2024-03-30 10:10:39 <celie> xz 5.4.4, 5.4.5, 5.4.6
2024-03-30 10:26:51 <ncopa> we have it in distfiles, in v3.19
2024-03-30 10:27:04 <ncopa> which why it is good that we have distfiles
2024-03-30 10:27:29 <ncopa> its just annoying that they removed it from github
2024-03-31 13:57:15 <ikke> ncopa: I've removed ^ from gitlab
2024-03-31 14:21:01 <omni> could http://build.alpinelinux.org redirect to https:// ? it loads javascripts after all