2024-05-01 21:05:20 <omni> is build-3-20-x86_64 stuck?
2024-05-01 21:09:19 <ikke> no, it was bootstrapping openjdk17 and I forgot to start it again
2024-05-01 21:18:35 <omni> ah
2024-05-03 11:37:35 <mps> !65292
2024-05-03 11:38:04 <mps> looks like this is last ncurses release in 6.4 series
2024-05-03 11:38:25 <mps> I see 6.5 in archive
2024-05-03 23:58:51 <celie> I wonder if build-3-20-x86, build-3-20-x86_64, and build 3-20-riscv64 may all be stuck
2024-05-04 00:00:35 <celie> For build-3-20-x86 in particular, py3-tqdm has a test that fails due to it having a 30-second timeout. The tests was originally disabled, but i enabled while doing an upgrade yesterday, as it passed on the CI.
2024-05-04 00:00:48 <celie> enabled it*
2024-05-04 00:02:47 <celie> It has also passed on edge, but it seems now it's running into problems on the 3.20 builders, and i've already pushed a commit re-disabling that test.
2024-05-05 00:46:54 <celie> I think both build-edge-ppc64le and build-3-20-riscv64 are stuck on community/black
2024-05-06 09:11:10 <ikke> ncopa: i just cleaned up ^ this weekend, and it's full again 
2024-05-06 09:28:09 <ncopa> alright. maybe we need to delete some old builders
2024-05-06 11:43:45 <ncopa> I have deleted various aports/*/*/src directories
2024-05-06 11:43:54 <ncopa> on nld9-dev1
2024-05-06 12:04:08 <ikke> Good, I did that as well for 3-20 earlier
2024-05-06 19:10:31 <ikke> A failed disk in our ppc64le machine. It's a raid disk so it should be able to be swapped online
2024-05-07 05:52:51 <ikke> Upgraded netbox to 4.0, whic has a new interface
2024-05-07 06:39:12 <clandmeter> nice
2024-05-07 11:13:31 <ncopa> I wonder if I can shut down the scaleway CI now? or I need to change it to a monthly plan if its gonna be permanent
2024-05-07 11:31:48 <ncopa> seems like I can not change it to monthly without recreating the instances
2024-05-07 11:33:40 <ikke> The other runners were paused
2024-05-07 11:33:53 <ikke> I've enabled them again
2024-05-07 11:34:05 <ikke> And paused the scaleway runners
2024-05-07 11:34:20 <ikke> https://gitlab.alpinelinux.org/admin/runners?tag[]=riscv64&tag[]=ci-build
2024-05-07 11:35:18 <ncopa> ok. I can delete them?
2024-05-07 11:35:53 <ncopa> maybe I should re-create them with monthly billing. they are nice to have
2024-05-07 11:36:16 <ikke> https://gitlab.alpinelinux.org/-/snippets/1152
2024-05-07 11:36:20 <ikke> Here is the script I used
2024-05-07 11:40:12 <ncopa> can I reuse the old GITLAB_RUNNER_TOKEN?
2024-05-07 11:40:44 <ikke> I think so
2024-05-07 11:40:51 <ikke> But each one needs to be unique
2024-05-07 11:42:10 <ikke> ncopa: would it be possible to plug that script into something like cloud-init?
2024-05-07 11:45:19 <ncopa> i would guess so, but I cannot find out how
2024-05-07 11:45:32 <ncopa> where do I find the GITLAB_RUNNER_TOKEN?
2024-05-07 11:45:47 <ikke> If you haven't saved it, you have to generate a new one
2024-05-07 11:46:03 <ikke> https://gitlab.alpinelinux.org/admin/runners top right
2024-05-07 11:46:23 <ikke> [new instance runner]
2024-05-07 11:46:58 <ikke> tags riscv64,ci-build 
2024-05-07 11:47:03 <ikke> Rest is default
2024-05-07 12:29:24 <ncopa> the runners are re-created with monthly billing
2024-05-07 12:32:13 <ncopa> seems like armhf runner is broken
2024-05-07 12:46:03 <ikke> How?
2024-05-07 13:37:26 <ncopa> pulling the docker image appears to take an hour so the job times out https://gitlab.alpinelinux.org/timothysteward-wk/aports/-/jobs/1376491
2024-05-07 13:38:25 <ncopa> same here: https://gitlab.alpinelinux.org/chereskata/aports/-/jobs/1376657
2024-05-07 14:08:55 <ikke> right, network issues still on che-ci-
2024-05-07 14:09:03 <ikke> che-ci-1
2024-05-07 14:09:16 <ikke> ncopa: you can pause those runners 
2024-05-07 19:03:25 <omni> mps: has anyone suggested renaming linux-edge to linux-stable? since linux stable is what is being tracked
2024-05-07 19:03:56 <omni> my first thought, if not knowing, would be that linux-edge was tracking linux mainline
2024-05-07 19:04:34 <mps> omni: we discussed renaming few times, but always ended with current name
2024-05-07 19:04:59 <omni> ok
2024-05-07 19:05:27 <omni> !65162 made me think of it
2024-05-07 19:05:30 <mps> it is edge in alpine sense, i.e. not stable as it can break from time to time
2024-05-07 19:06:10 <omni> it is also about tryng out various configuration options?
2024-05-07 19:07:10 <mps> no, it is 'what mps thinks and likes about kernel' ;-
2024-05-07 19:07:21 <mps> )
2024-05-07 19:08:20 <mps> omni: if you want to take it please just tell, I don't use it anywhere for months and TBH don't test it often
2024-05-07 19:08:39 <mps> or maybe we can 'co-maintain' it
2024-05-07 19:08:51 <omni> I wonder if it would be an idea to additionally package linux stable as community/linux-stable, with with configuration similar to that of linux-lts
2024-05-07 19:09:09 <omni> you also earlier brought up moving linux-edge to testing/
2024-05-07 19:09:13 <ikke> Wouldn't stable be confusing in relationship with lts?
2024-05-07 19:09:26 <omni> but I think some peopple rely on it in stable releases
2024-05-07 19:09:32 <mps> I think it will not be good idea to have linux-stable
2024-05-07 19:09:58 <omni> I think it would be less confusing as that is what upstream calls it https://kernel.org/
2024-05-07 19:09:58 <mps> alpine stable and maintained kernel is linux-lts
2024-05-07 19:10:06 <omni> lts is longterm support
2024-05-07 19:10:33 <ikke> What about linux-mainline?
2024-05-07 19:10:36 <mps> oh, if this is only confusion in Alpine we will be really happy people
2024-05-07 19:10:42 <ikke> But not sure if we want yet another generic kernel
2024-05-07 19:10:53 <mps> ikke: I agree
2024-05-07 19:11:20 <ikke> But there is a need for a kernel with similar options as linux-lts that tracks mainline
2024-05-07 19:11:48 <ikke> another option is just 'linux'
2024-05-07 19:11:57 <omni> myself, I'm more interested in a hardened kernel, but that I figure would be an additional subpackage of linux-lts with separate config
2024-05-07 19:12:14 <mps> ikke: if someone want to do task I think s/he should just linux-edge
2024-05-07 19:12:30 <mps> because in that case we don't need linux-edge
2024-05-07 19:13:39 <mps> I can't maintain good all arches alpine support
2024-05-07 19:14:46 <mps> and whatever serious alpine devs decide about this I will agree
2024-05-07 19:15:13 <omni> maybe ask EvTheFuture/Magnus Sandin in !65162 if they are interested in adopting or co-maintaining linux-edge?
2024-05-07 19:15:59 <mps> hm, is he new in alpine?
2024-05-07 19:16:11 <mps> I can't remember name
2024-05-07 19:17:16 <ikke> already a member for 3 years
2024-05-07 19:17:25 <ikke> But a bit more active lately
2024-05-07 19:17:30 <mps> ah, how I missed this
2024-05-07 19:18:55 <mps> I don't know much about him and I would like if kernel maintain someone who have alpine principle attitude at first
2024-05-07 19:19:29 <mps> but at the I can simply "don't care"
2024-05-07 19:19:41 <mps> at the end*
2024-05-08 06:32:42 <ncopa> I wonder how we deal with https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/issues/14#note_302721
2024-05-08 06:33:13 <ncopa> do we want to integrate it with the scripts/mkimg.sh or do we want have a hook on git commit that runs from different place
2024-05-08 06:33:32 <ncopa> i think maybe we should do the latter
2024-05-08 06:51:26 <ikke> A CI job would be preferred 
2024-05-08 07:36:28 <ncopa> agree. Do we set up a separate repo for that? how do connect a trigger to it? I think we need run it after all the images are uploaded
2024-05-08 07:38:41 <ikke> clandmeter has set up something similar
2024-05-08 07:39:02 <ikke> But not sure how to make sure all images are uploaded 
2024-05-08 07:44:51 <ncopa> i think we can use the images from the current release script. we already build rpi disk images
2024-05-08 07:45:17 <ncopa> https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/aarch64/ there are *.img.gz
2024-05-08 07:45:43 <ikke> Where will / should the generated json be stored?
2024-05-08 07:45:54 <ncopa> we only need a CI job that runs after all aarch64 adn arm* uploads and generates the index
2024-05-08 07:46:07 <ncopa> where we store it? that is my question here
2024-05-08 07:46:35 <ncopa> can we do a release artifact in gitlab? do we want that?
2024-05-08 07:47:20 <ncopa> do we upload it to https://alpinelinux.org/downloads ?
2024-05-08 07:48:45 <ncopa> we upload the cloud image indexes to alpinelinux.org, dont we?
2024-05-08 07:49:35 <ncopa> I also wonder if we should ship disk images in addition to .iso?
2024-05-08 07:49:53 <ncopa> i think it makes more sense with disk images in 2024 than iso images?
2024-05-08 08:05:47 <ncopa> does the armhf runner still have issues?
2024-05-08 08:07:07 <ncopa> seems like it is ok now
2024-05-08 08:20:12 <ikke> Did you pause the che-ci-runner?
2024-05-08 08:20:17 <ikke> There are 2 hosts 
2024-05-08 08:22:55 <ncopa> no, i didnt
2024-05-08 08:23:44 <ikke> Ok, can see at the start of the job what runner picked it up 
2024-05-08 09:11:40 <ncopa> can we prevet merge commits in stable branches? https://gitlab.alpinelinux.org/alpine/aports/-/commit/e8d17fccc0c8bbb9c2d6fe9d60637be71e1682bc
2024-05-08 09:45:46 <ikke> A pre-receive hook
2024-05-08 15:55:56 <ikke> ppc64le disk has been replaced and the RAID is healthy again
2024-05-08 18:56:13 <mps> do 'we' know when 3.20 will be released? util-linux have bugfix release 2.40.1 version and I prepared MR but didn't posted to CI because one test fails and I'm waiting answer on their IRC channel
2024-05-08 18:56:28 <ikke> mps: not yet, the builders are still working
2024-05-08 18:56:48 <ikke> x86_64 still has >500 packages to build
2024-05-08 18:56:54 <mps> aha ok
2024-05-08 18:57:02 <ikke> rv64 >1600
2024-05-08 18:57:12 <mps> I just posted mesa bugfix upgrade to CI
2024-05-08 18:57:55 <mps> hm, maybe I should post util-linux to CI
2024-05-08 18:58:27 <mps> and wait if upstream answer my question
2024-05-09 05:29:31 <ikke> running rdfind ^
2024-05-09 05:49:15 <mps> perl 5.40 could be released in 10 days https://github.com/Perl/perl5/blob/5fdf6e90221900a85cd3091bd2755e41fc230d4d/Porting/release_schedule.pod?plain=1#L54
2024-05-09 05:49:32 <mps> but I guess to late for alpine 3.20
2024-05-09 06:00:34 <ncopa> yeah. too late
2024-05-09 06:02:55 <mps> pity, it got finally solid OOP features
2024-05-09 06:03:47 <mps> but ok, it will be nice new year gift in alpine 3.21
2024-05-09 10:37:45 <mps> could I take telegram-desktop maintainership. I'm building it locally for long time
2024-05-09 10:38:02 <ikke> sure
2024-05-09 10:38:05 <ikke> It's up for grabs
2024-05-09 10:38:09 <mps> ok
2024-05-09 10:50:13 <ncopa> thank you!
2024-05-09 11:18:09 <mps> ncopa: np
2024-05-09 14:06:34 <mps> armhf CI have issue in fetching some things, https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1379528#L30
2024-05-09 14:55:07 <ikke> mps: I've paused this runner now, it's known to have network issues
2024-05-09 14:57:10 <mps> ikke: aha, ok
2024-05-10 14:46:51 <omni> ikke: I liked the idea of calling a kernel aport tracking linux stable just "linux"
2024-05-10 14:47:10 <omni> having it in community/ and aimed at desktop and mobile
2024-05-10 14:49:49 <omni> if it should complement linux-edge or replace it
2024-05-10 14:50:20 <omni> I'm not sure if I'm up for maintaining such an aport myself
2024-05-10 14:50:39 <omni> if mps wants to hand over maintainership of linux-edge
2024-05-10 17:21:37 <mps> omni: I don't think that is good idea to rename main kernel in Alpine, it is well known by alpine users so I vote to stay linux-lts
2024-05-10 17:22:02 <mps> forget about other distro naming, 'we' are Alpine
2024-05-10 17:22:10 <ikke> mps: he means linux-edge to linux
2024-05-10 17:22:36 <mps> ikke: ah. this will make more confusion imo
2024-05-10 17:25:46 <mps> and yes, I'm ready to hand over it if someone are ready to maintain it for all arches and maintain it in timely manner and follow basic alpine policy
2024-05-10 17:26:41 <mps> but don't ready to hand over it to those 'super smart' newcomers from other distros
2024-05-10 17:26:54 <mps> s/don't/not/
2024-05-10 18:41:36 <omni> I just thought that linux is the kernel and it could be called just that
2024-05-10 18:43:05 <mps> what is then linux-lts for newcomers to alpine
2024-05-10 18:43:07 <omni> "linux-edge" is confusing both because we call our rolling release "edge" and because the upstream kernel project does not call anything "edge"
2024-05-10 18:43:58 <omni> linux-lts is LongTerm Support and upstream call those releases "longterm" so it is not as far fetched
2024-05-10 18:44:02 <mps> then it could be linux-ls (Last Stable) maybe
2024-05-10 18:44:18 <omni> or linux-stable :p
2024-05-10 18:44:34 <omni> as I first suggested
2024-05-10 18:44:51 <omni> but I thought the suggestion of just "linux" was good too
2024-05-10 18:45:07 <mps> linux-stable could then imply that linux-lts is not stable
2024-05-10 18:46:16 <mps> linux-edge is best option to which we come few years ago, after that I still not find better name
2024-05-10 18:46:40 <mps> and most current users and devs knows well what it is
2024-05-10 18:47:23 <mps> one option could be linux-latest-stable
2024-05-10 18:48:19 <mps> but we already have some number with strange and/or ambiguous names
2024-05-10 18:48:36 <mps> number of packages*
2024-05-10 20:11:12 <mps> algitbot: retry 3.20-stable
2024-05-10 20:18:24 <mps> algitbot: retry 3.20-stable
2024-05-11 00:16:49 <panekj> git.ao seems to be in pain
2024-05-11 00:31:30 <ptrc> as in, cgit? seems to be alright now
2024-05-11 01:07:53 <panekj> ofc, now it works fine..
2024-05-11 09:36:52 <ikke> Rebooting gbr2-dev1 (which hosts several service) for system upgrades
2024-05-12 07:17:07 <mps> we don't have unmaintained repo anymore? so we simply remove aports which we don't need?
2024-05-12 07:17:13 <ikke> yes
2024-05-12 07:17:48 <mps> aha, I will remove dosbox and move dosbox-staging from testing to community
2024-05-12 07:27:35 <ikke> mps: dosbox-staging failed to build because iir1 needs to be moved as well
2024-05-12 07:27:55 <mps> oh yes, I forgot
2024-05-12 07:28:27 <mps> nvm, I will move it and at the same time upgrade dosbox-staging to new release
2024-05-12 07:30:20 <mps> algitbot: retry master
2024-05-12 07:32:05 <mps> algitbot: retry 3.20-stable
2024-05-12 07:33:38 <ikke> 3.20-stable does not exist yet
2024-05-12 07:33:41 <ikke> everything is still tracking master
2024-05-12 07:34:32 <mps> so we cannot retry it when something fails
2024-05-12 07:34:49 <ikke> You can, just retrying master is enough
2024-05-12 07:35:13 <ikke> You target the git branch you push to, not the builder names
2024-05-12 07:45:55 <mps> iiuc we still don't have 3.20-stable branch
2024-05-12 07:46:32 <ikke> Correct, so you push to master, and the 3.20 builders follow that
2024-05-12 07:46:46 <mps> ikke: thanks
2024-05-12 07:46:46 <ikke> at release, the 3.20-stable branch is created
2024-05-12 07:50:18 <mps> ikke: can we simply delete branch from gitlab?
2024-05-12 07:50:34 <mps> I would like to delete https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65794
2024-05-12 07:50:52 <ikke> Yes, you can safely delete that branch from your fork
2024-05-12 07:51:06 <ikke> There is even a link "Delete source branch" that does that
2024-05-12 07:51:51 <mps> yes, I noticed it after posting question. thank for confirmation
2024-05-12 07:52:40 <mps> ok, enough work of me for alpine today 
2024-05-12 09:39:44 <nmeum> re #16103 : can we grep all 3.20 buildlogs for '-Wimplicit-function-declaration' to find packages which declare basename(3) implicitly?
2024-05-12 09:46:10 <ikke> huge list
2024-05-12 09:47:34 <ikke> nmeum: https://tpaste.us/QRYl
2024-05-12 09:47:45 <nmeum> hm that ain't good :D
2024-05-12 09:48:42 <nmeum> 242 entries for x86_64
2024-05-12 09:50:03 <nmeum> ok but some of those are just checking if the compiler supports -Wimplicit-function-declaration (e.g. pango)
2024-05-12 09:51:14 <nmeum> ikke: could you check which of those contain the word "basename" as well? maybe that's a good heuristic to reduce the set of packages
2024-05-12 09:52:13 <nmeum> or maybe it's easier to grep for "warning: implicit declaration of function" 🤔
2024-05-12 09:53:21 <ikke> yes, did that
2024-05-12 09:53:23 <ikke> https://tpaste.us/KELY
2024-05-12 09:54:23 <nmeum> 144 entries for x86_64
2024-05-12 09:55:01 <ikke> https://tpaste.us/j4mm this one is filtered for basename
2024-05-12 10:05:10 <nmeum> ok so 44 packages
2024-05-12 10:05:14 <nmeum> I think that should be fixable for 3.20
2024-05-12 10:27:35 <nmeum> #16106
2024-05-12 19:36:13 <ikke> ncopa: dl-masters disk is getting full as well again
2024-05-13 06:23:14 <ncopa> good morning. what are our options for disk full problem of dl-master?
2024-05-13 06:26:13 <ncopa> build-edge-armhf is not running?
2024-05-13 06:27:27 <ikke> ncopa: i stopped them because the builder hang for >24h trying to build 6 copies of webkit2gtk 
2024-05-13 06:27:44 <ikke> I started aarch64 and armv7 this morning 
2024-05-13 07:03:20 <ncopa> 👍
2024-05-13 07:03:25 <ncopa> thank you for taking care of ir
2024-05-13 07:03:28 <ncopa> it*
2024-05-13 07:06:02 <ncopa> I deleted some releases/*/*_rc* from dl-master
2024-05-13 07:06:27 <mps> ikke cares for everything
2024-05-13 07:06:47 <ncopa> he certainly does
2024-05-13 07:07:33 <mps> he deserves medal for his herculean works for alpine
2024-05-13 07:15:26 <ncopa> :)
2024-05-13 07:32:13 <ikke> ncopa: last time jakub took care of it
2024-05-13 07:54:55 <ncopa> ikke: do you want me to send him an email?
2024-05-13 09:58:53 <ncopa> seems like dotnet is broken https://build.alpinelinux.org/buildlogs/build-3-20-armv7/community/jellyfin/jellyfin-10.8.13-r0.log
2024-05-13 10:24:36 <ikke> ncopa: fyi, numono will restart the arm builder this afternoon to tweak some bios settings. I'll stop the builders now because they are stuck anyway
2024-05-13 11:28:08 <ncopa> ok
2024-05-13 19:25:06 <ncopa> how is it going with the arm builder?
2024-05-13 19:39:32 <ikke> I had started the builders because numono was not available. He will reboot the server now
2024-05-13 20:15:17 <numono> im also working on the mgmt port access
2024-05-13 20:15:45 <numono> it takes router advertisements! \o/ 
2024-05-13 20:15:54 <numono> nice mgmt board
2024-05-13 20:22:18 <ncopa> awesome!
2024-05-14 12:38:38 <nu_> sry, a switch froze, fixing it
2024-05-14 12:56:41 <ikke> ncopa: seems like our dl-master disk issue has been solved :-)
2024-05-14 13:46:59 <ncopa> we got another TB! wow!
2024-05-14 17:16:01 <nu_> server maid just unplugged both cables of the arm builder, its rebooting, sry
2024-05-15 09:07:46 <clandmeter> ikke: see the ip email vpsfree 
2024-05-15 09:12:59 <ikke> Yes, iirc this is just the finalization. Jirutka already handled when we received the first email 
2024-05-15 19:30:10 <ikke> nu_: Something happening with the network again? I cannot seem to ping our builder
2024-05-15 19:31:34 <ikke> It's curious, because the zabbix agent on the builder is still able to send data
2024-05-15 19:36:19 <ikke> dmvpn does not seem to work either
2024-05-15 19:45:26 <nu_> hmm i can ping it. i've upgraded the network, and the router is new too. ill check in a sec
2024-05-15 21:44:16 <nu_> should it be pingable from anywhere?
2024-05-15 21:45:08 <nu_> have u set up any static network config? the default gw ip have changed
2024-05-15 21:53:29 <nu_> nvm, v4 gw ip was missing on the iface, dmvpn should work now
2024-05-16 04:49:44 <ikke> nu_: I was pinging the ipv6 address, which is still not reachable. I cannot ssh into the host either using that address. Loging in via the dmvpn address at least works now
2024-05-16 05:10:27 <ikke> nu_: the containers cannot access anything over ipv6 either
2024-05-16 05:47:30 <ikke> effectively the builders are idle now because the cannot connect to msg.a.o
2024-05-16 06:40:34 <nu_> could you try to reboot it? i have a host in the network and it can access msg.a.o (both ping and curl)
2024-05-16 06:40:50 <nu_> (or restart the network iface)
2024-05-16 07:13:26 <ikke> nu_: reboot did not help
2024-05-16 07:14:36 <ikke> nu_: from the host, I can ping msg.a.o over ipv6
2024-05-16 08:09:39 <ncopa> good morning! so arm builders have been on vacation for a while?
2024-05-16 08:32:38 <nu_> builders are back, only ssh is hanging
2024-05-16 08:34:51 <nu_> algibot doesnt agree
2024-05-16 08:40:36 <nu_> \o/
2024-05-16 08:51:34 <nu_> really sorry, i moved the hw very carefully but somehow the router's nvme's firmware got corrupted, and froze the system. some routing/fw changes were discarded because it's a netbooted alpine, and i was postponing to add it into my automation
2024-05-16 14:40:01 <ikke> hmm, gitlab 17 released
2024-05-17 07:15:57 <ikke> Need to look at ^
2024-05-17 11:03:22 <ncopa> would be nice to have a CI for alpine-conf on s390x and ppc64le
2024-05-17 11:16:29 <ikke> We have generic instance runners, so would be a matter of setting up ci to use it
2024-05-17 11:16:54 <ikke> But i feel the failing tests are due to what's available on the host?
2024-05-17 11:21:16 <ncopa> code path si special on s390x i think
2024-05-17 11:21:19 <ncopa> is*
2024-05-17 11:21:52 <ncopa> there are some if [ $ARCH = "ppc64" ] ... and if [ "$ARCH" = s390x ]
2024-05-17 11:21:57 <ncopa> typical IBM code...
2024-05-17 11:22:55 <ncopa> but those code paths are currently not triggered in CI, and not on my dev machines. So things only pops up after I have pushed new apk
2024-05-17 11:23:20 <ncopa> I dont think the other architectures has something similar. maybe except rpi
2024-05-17 11:27:25 <ikke> Check the apk-tools project, ut runs ci on all of our arches 
2024-05-17 11:38:45 <ncopa> 👍
2024-05-20 17:11:28 <ikke> cleaning up distfiles, and made sure all builders use the per version distfiles folder
2024-05-20 17:34:42 <ikke> I don't get it. I run rdfind to make hardlinks of duplicate files. It manages to reduce 30G. The next instant, the disk usage is back the the previous level again
2024-05-20 17:34:45 <ikke> now happened twice in a row
2024-05-20 17:34:54 <ikke> Something to do with zfs?
2024-05-20 20:08:09 <ncopa> we are strugling with full disks
2024-05-20 20:08:22 <ikke> yes
2024-05-20 20:09:03 <ikke> maybe before 3.21 we should really look into changing the architecture
2024-05-20 20:13:29 <ncopa> yeah, i think we have no other choice
2024-05-22 04:12:17 <ikke> Uhoh
2024-05-22 09:35:47 <ncopa> whats up with the x86_64 runner?
2024-05-22 09:36:16 <ncopa> looks like nothing is running https://gitlab.alpinelinux.org/fossdd/aports/-/jobs?statuses=RUNNING
2024-05-22 09:36:39 <ncopa> wrong url. sorry
2024-05-22 11:49:48 <ncopa> https://wwwtest.alpinelinux.org/ gives bad gateway
2024-05-22 11:50:02 <ncopa> maybe we dont need wwwtest anymore
2024-05-22 11:57:47 <ikke> Hmm
2024-05-22 12:11:06 <ncopa> what do I need to do to get 3.20 listed: https://pkgs.alpinelinux.org/packages
2024-05-22 12:13:24 <ncopa> ikke: can you please take care of invalidating the fastly cache for latest-stable, post a toot and pkgs.a.o? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16119
2024-05-22 12:50:04 <ikke> https://fosstodon.org/@alpinelinux/112484819175489604
2024-05-22 12:56:32 <mps> edge could be announced every day :-)
2024-05-22 15:32:12 <ikke> started importing 3.20 in pkgs.a.o
2024-05-23 15:20:56 <danieli> the ftp.acc.umu.se mirror is moving to mirror.accum.se, and its contact changes too - myself and ncopa got a notification because they failed to find an other contact point
2024-05-23 15:22:40 <danieli> forwarded it to ikke and clandmeter 
2024-05-23 15:23:09 <ikke> danieli: thanks
2024-05-23 15:37:42 <ikke> danieli: nice to see you again :)
2024-05-23 15:40:32 <danieli> ikke: you as well, doing alright?
2024-05-23 15:40:46 <ikke> Yes, doing fine
2024-05-23 15:40:56 <danieli> for what it's worth I've been around, keeping an occasional eye on things :)
2024-05-23 15:46:44 <ikke> :)
2024-05-23 19:34:13 <ncopa> hey danieli! thank you for sharing!
2024-05-23 21:36:25 <ikke> clandmeter: ncopa the riscv64 builders are having network issues 
2024-05-23 21:37:34 <ikke> The hosts seem to have restarted yesterday
2024-05-23 21:37:42 <ikke> both builder containers were stopped
2024-05-23 21:38:05 <ikke> one does not get an ip, the other does get an ip, but no further network connectivity
2024-05-24 05:42:31 <ncopa> ikke: it is iptables. Set forward policy to accept
2024-05-24 05:44:40 <ikke> thanks, that fixes it
2024-05-24 05:44:50 <ikke> I will look later to make it work with awall
2024-05-30 08:40:57 <clandmeter> ikke: we are planning to move the ci arm server today
2024-05-30 08:44:28 <clandmeter> hi midasi 
2024-05-30 08:44:32 <clandmeter> welcome :)
2024-05-30 08:45:14 <midasi> hi everybody. thanks :)
2024-05-30 08:45:50 <ikke> Thanks for the heads-up 
2024-05-30 08:46:17 <clandmeter> so there will be an expected down time
2024-05-30 08:47:14 <clandmeter> 1200 - 1800 CET
2024-05-30 09:47:16 <ikke> I've put the hosts in maintenance 
2024-05-30 16:39:09 <clandmeter> ikke: host should be up
2024-05-30 16:39:17 <ikke> What's the new IP?
2024-05-30 16:40:05 <midasi> eth0 is 157.143.104.190
2024-05-30 16:40:15 <midasi> bmc is 157.143.104.189
2024-05-30 16:40:33 <ikke> thanks, I can confirm I can login
2024-05-30 16:40:42 <ikke> (on eth0)
2024-05-30 16:40:51 <midasi> bmc seems not to work yet... did it work before? it looks like it wasn't configured
2024-05-30 16:41:08 <ikke> It used to work, but it's been a while since we connected to it
2024-05-30 16:41:31 <ikke>  192.168.1.190/24
2024-05-30 16:41:36 <ikke> That was the IP address
2024-05-30 16:42:01 <clandmeter> Please don’t put the BMC on the public ip
2024-05-30 16:42:28 <clandmeter> We will ask to connect if it’s needed
2024-05-30 16:42:39 <ikke> Yeah, it's bad practice to make it publically accessible
2024-05-30 16:42:45 <clandmeter>  but it’s nice if it works
2024-05-30 16:43:10 <midasi> agreed re. the bad practice
2024-05-30 16:43:36 <midasi> but I still don't get it... how would you like to connect to bmc? e.g. if the server is down
2024-05-30 16:44:12 <ikke> Depends on what options there are, some vpn like connection perhaps?
2024-05-30 16:44:44 <ikke> We can manage if that's not possible right now
2024-05-30 16:45:32 <midasi> ok that's fine. We will set this up with a VPN...
2024-05-30 16:47:15 <midasi> it might take 1-2 days though to set it up
2024-05-30 16:47:37 <ikke> sure, that's not an issue
2024-05-30 16:48:35 <midasi> we will reboot it once again to re-configure the bmc nic to 192.168.1.190/24 as requested. Is that ok for you?
2024-05-30 16:49:28 <ikke> That's fine. The specific IP does not matter that much to us, but that used to be the IP address
2024-05-30 16:49:48 <midasi> understood
2024-05-30 16:52:06 <ikke> midasi: I'd also like to upgrade the host, do you have time to check if it does not come back?
2024-05-30 17:00:34 <midasi> yes sure, we are still around for the next 2-3 hours
2024-05-30 17:00:40 <ikke> Alright
2024-05-30 17:00:45 <midasi> it should be up and running now
2024-05-30 17:00:53 <ikke> Yes, I'm in again
2024-05-30 17:09:14 <ikke> rebooting now
2024-05-30 17:13:30 <ikke> midasi: ok, it's back :)
2024-05-30 17:13:43 <ikke> Running alpine 3.20
2024-05-30 17:14:06 <ikke> clandmeter: che-ci-1.a.o now points to that address
2024-05-30 17:18:09 <midasi> great!
2024-05-30 17:37:48 <clandmeter> Thanks guys!