2025-05-01 05:12:58 <cely> Hello, could i be added to the alpinedev group for uploading to dev.a.o/archive? (i gather this is the preferred way of fixing source files not file issues, instead of pointing the source to distfiles.a.o)
2025-05-01 08:35:48 <ncopa> cely: I added you there
2025-05-01 08:55:04 <cely> Thanks :)
2025-05-01 10:42:48 <ncopa> usa-che-1 shared runner is out of disk space https://gitlab.alpinelinux.org/haesbaert/aports/-/jobs/1830933
2025-05-01 10:46:33 <ikke> checkiung
2025-05-01 10:46:35 <ikke> checking
2025-05-01 10:51:05 <ikke> hmm, there is 63G available atm
2025-05-01 12:50:03 <ikke> bootstrapping jdk8 on armhf and aarch64
2025-05-01 12:59:56 <HRio> cc1plus: out of memory allocating... https://build.alpinelinux.org/buildlogs/build-edge-armv7/community/neochat/neochat-25.04.0-r0.log
2025-05-01 13:02:07 <ikke> 32-bits, means it may also have run out of address space
2025-05-01 13:02:22 <HRio> ah OK
2025-05-01 13:03:23 <ikke> The builder has >250G memory
2025-05-01 13:03:27 <HRio> looks like that successful build of nats-server at the same time was not uploaded?
2025-05-01 13:03:41 <ikke> It only uploads once the entire repo finished
2025-05-01 13:03:42 <HRio> https://pkgs.alpinelinux.org/packages?name=nats-server&branch=edge&repo=&arch=&origin=&flagged=&maintainer=
2025-05-01 13:03:51 <HRio> ah explains
2025-05-01 13:04:28 <HRio> do you know why armhf is listed two times in the link?
2025-05-01 13:04:55 <HRio> and with different versions
2025-05-01 13:07:16 <ikke> There were some storage issues, I had to recreate the index. Probably both the old and the new version are in the package repo
2025-05-01 13:07:38 <HRio> ah
2025-05-01 14:19:25 <ikke> bootstrapping openjdk11 on loongarch64
2025-05-01 14:40:45 <cely> Oh wait, i think for openjdk11 you have to bootstrap openjdk11-loongarch
2025-05-01 14:42:00 <cely> Or at least if you didn't bootstrap that, you'll have to bootstrap it also, iirc openjdk11-loongarch is able to build openjdk11 but not vice versa
2025-05-01 14:46:00 <ikke> I suppose we would not get the server variant otherwise:?
2025-05-01 14:46:25 <ikke> It did manage to get built quite quickly
2025-05-01 14:46:56 <cely> I think openjdk11 will just fail to build openjdk11-loongarch, as it lacks some feature
2025-05-01 14:47:18 <ikke> And why is/was openjdk11-loongarch necessary again?
2025-05-01 14:48:19 <cely> Oracle doesn't want to accept the Loongarch patches for the Server variant, and relying on just the Zero variant is very slow
2025-05-01 14:48:53 <ikke> right, what I mentioned above
2025-05-01 14:48:57 <cely> From what i remember, using community/abcl, the difference was between half an hour vs half a day
2025-05-01 14:49:11 <cely> s/using/building/
2025-05-01 14:50:32 <ikke> and would I install -loongarch from edge then instead of -bootstrap
2025-05-01 14:50:34 <ikke> ?
2025-05-01 14:51:43 <cely> Yes, that should do it
2025-05-01 14:51:46 <ikke> ack
2025-05-01 14:52:03 <cely> Thanks
2025-05-01 14:52:39 <cely> Only jdk11 has this issue, others you can bootstrap whichever is convenient, but bootstrapping -loongarch should be faster
2025-05-01 14:57:21 <ikke> Finished
2025-05-01 15:06:59 <cely> Speaking of OpenJDK, could you have a look at the openjdk8-jre-base .apk built for 3.22 x86_64? I'm specifically thinking about the /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/server/libjvm.so file (this is the path it has in the edge .apk)
2025-05-01 15:08:23 <cely> There's a "libjvm.so: No such file or directory" error in 3.22 Octave build log, that's why i'm asking
2025-05-01 15:10:50 <ikke> file usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/server/libjvm.so
2025-05-01 15:10:55 <ikke> usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/server/libjvm.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=fee12924f7c5dccef1515b2ea70412c94fa4e22b, stripped
2025-05-01 15:12:04 <cely> Hmm, ok, not sure why Octave couldn't find it
2025-05-01 15:12:42 <cely> I guess i'll wait for the next retry and see if it still happens
2025-05-01 15:27:55 <cely> Can't reproduce the libjvm.so not found error in edge on the CI
2025-05-01 15:29:00 <cely> and i see the octave APKBUILD has !check for x86 for due to: "x86 libjava.so cannot find libjvm.so"
2025-05-01 15:30:10 <cely> Now i'm wondering if it could be caused by /usr/lib/jvm/default-jvm on the builder pointing to some other version (not java-1.8-openjdk)
2025-05-01 15:31:56 <cely> which could be the case if a higher jdk version was also installed (java-common.trigger just sorts the dirs, and symlinks the highest version available to default-jvm)
2025-05-01 15:37:20 <cely> Hmm, never mind, maybe it will be fine after jdk's higher than 8 are bootstrapped on x86_64
2025-05-01 15:37:50 <ikke> /usr/lib/jvm/default-jvm -> java-8-openjdk
2025-05-01 15:40:22 <cely> Yeah, thanks for looking into it, i'll check Octave again after jdk>8 are available for it to use, i think there's a possibility it will build fine then
2025-05-02 14:30:16 <ikke> Seems like the excessive requests to cgit have finally stopped
2025-05-02 14:32:15 <f_> awesome
2025-05-02 14:33:29 <ikke> I switched from drop (502) to block (403)
2025-05-02 14:44:24 <f_> ikke: yeah generally when those scrapers scrap and then see a 502 they'll just try again later
2025-05-02 14:44:49 <f_> I've heard some AI bots try again when the return code isn't 200
2025-05-02 14:53:36 <invoked> it's interesting to me that none of the countries have prosecuted this (where dos attacks have been litigated)
2025-05-02 15:22:07 <f_> that's because it's AI and AI gets to be immune in the eyes of the law™
2025-05-02 19:12:29 <ikke> bootstrapping ghc on aarch64
2025-05-03 10:57:34 <ikke> bootstrapping openjdk21 on x86_64
2025-05-03 13:44:33 <ptrc> uh, dev.a.o is out of space?
2025-05-03 13:44:45 <ptrc> like, 100% used 0 bytes left
2025-05-03 13:51:20 <ikke> Now there should be plenty of space left
2025-05-03 14:18:40 <ptrc> thanks!
2025-05-05 07:16:13 <mio> ikke: py3-loky might need releasing from edge ppc64le, sorry about that. the package had already rebuilt on other arches, but the tests may be a little fragile
2025-05-05 11:40:56 <ikke> mio: I've killed the build 
2025-05-05 13:59:13 <mio> ikke: thanks!
2025-05-06 13:51:02 <ncopa> im gonna bootstrap openjdk17 on build-3-22-x86_64 now
2025-05-06 15:26:46 <ncopa> someone is sending spam via alpine-devel list https://lists.alpinelinux.org/~alpine/devel/%3C2349dc138a0c4f7cbd8f53ef3aa65ccc%40semperincolumem.com%3E
2025-05-06 15:27:40 <ikke> Yes
2025-05-06 15:28:16 <ncopa> i got a warning from linode that they will block something
2025-05-06 15:34:05 <ikke> Yup, they already have
2025-05-06 15:34:10 <ikke> I need to respond
2025-05-06 16:13:48 <ikke> I responded to them
2025-05-06 16:22:22 <mio> hello, is openjdk21 still bootstrapping on loongarch64?
2025-05-06 16:22:27 <mio> (3.22)
2025-05-06 16:22:44 <ikke> sorry, no
2025-05-06 16:22:52 <ikke> started the builder again
2025-05-06 16:23:10 <mio> great, thanks :)
2025-05-06 20:23:25 <clandmeter> blaboon: ping
2025-05-06 20:23:49 <clandmeter> We have an issue with one of our vps 
2025-05-06 20:24:01 <clandmeter> Port 25 is blocked
2025-05-06 20:24:18 <clandmeter> 24913954
2025-05-06 20:24:26 <clandmeter> Ticket 
2025-05-06 20:45:39 <blaboon> i just removed the outbound block from that instance
2025-05-06 20:46:05 <blaboon> i informed our support staff too, so you'll probably see some followup in the support ticket at some point
2025-05-06 21:17:39 <clandmeter> Thanks
2025-05-07 07:12:48 <ncopa> im bootstrapping openjdk21 on buid-3-22-aarch64
2025-05-08 09:54:20 <fossdd|m> loongarch64 and riscv64 CI fail to resolve x.org: https://gitlab.alpinelinux.org/fossdd/aports/-/pipelines/321644
2025-05-08 10:38:09 <ncopa> on loongarch64:
2025-05-08 10:38:09 <ncopa> >>> pixman: Fetching https://www.x.org/releases/individual/lib/pixman-0.46.0.tar.xz
2025-05-08 10:38:09 <ncopa> wget: bad address 'www.x.org'
2025-05-08 10:50:10 <omni> when, really, x.com is the bad address
2025-05-08 17:05:44 <iggy> ipv4 vs ipv6 thing? www.x.org doesn't have a AAAA record
2025-05-08 17:07:29 <f_> x.com doesn't (need to) exist
2025-05-09 15:12:07 <mio> 3.20 x86_64 ran out of space, `fatal error: error writing to /tmp/ccmmFlpj.s: No space left on device` while building linux-lts
2025-05-09 15:15:33 <mio> build-3-20-x86_64 builder that is
2025-05-09 15:16:27 <mio> ncopa: ^ (sorry, not sure who to notify)
2025-05-09 16:37:37 <ikke> Strange, I've recently expanded the volume 
2025-05-09 16:46:06 <mio> no idea, just reporting the sights ... gcc failing on 3.22 x86_64 with a similar error
2025-05-09 18:21:21 <ncopa> thanks for notifying. i supose it is /tmp on tmpfs
2025-05-09 18:24:17 <ncopa> no. it's not
2025-05-09 18:26:55 <ncopa> ikke: im expanding it
2025-05-09 18:31:15 <ikke> Thanks 
2025-05-09 19:27:16 <mio> ncopa: thanks!
2025-05-09 22:22:50 <sertonix[m]> Is the ppc64le CI down? https://gitlab.alpinelinux.org/sertonix/aports/-/jobs/1845156
2025-05-10 07:48:08 <ncopa> looks like ppc64le CI is down indeed
2025-05-10 08:50:40 <ncopa> im bootstrapping openjdk17 on build-3-22-aarch64
2025-05-10 19:07:12 <ikke> bootstrapping openjdk8 on build-3-22-x86
2025-05-10 19:23:29 <ikke> bootstrapping openjdk21 on build-3-22-s39x
2025-05-11 15:43:18 <ikke> bootstrapping ghc on build-3-22-x86_64
2025-05-11 16:34:45 <ikke> bootstrapping openjdk8 on build-3-22-s90x
2025-05-11 16:42:53 <ikke> bootstrapping openjdk8 on build-3-22-loongarch64
2025-05-11 18:34:03 <ikke> bootstrapping openjdk21 on build-3-22-loongarch64
2025-05-11 18:34:44 <ikke> bootstrapping openjdk11 on build-3-22-aarch64
2025-05-12 05:39:31 <ikke> bootstrappking openjdk17 on build-3-22-s390x
2025-05-12 05:39:40 <ikke> ncopa: can you start ^ again when finished?
2025-05-12 05:47:21 <ikke> n/m, it already finished
2025-05-12 07:30:29 <ncopa> we need to get the ppc64le back online. any idea how? who do we contact?
2025-05-12 09:56:30 <ikke> ncopa: I can open a ticket on the osuosl support page 
2025-05-12 10:18:40 <ncopa> would be great. thanks!
2025-05-12 10:23:55 <ikke> Sent an email to the support addrress
2025-05-12 17:49:42 <ikke> It's back :-)
2025-05-12 17:53:00 <f_> :-)
2025-05-12 18:02:06 <mio> could someone also prod the 3.22 armv7 builder please? thanks
2025-05-12 18:03:50 <ikke> done
2025-05-12 18:04:05 <mio> thanks!
2025-05-13 10:01:05 <Kladky> Repology seems to be failing to update after go-away was deployed on cigt: https://repology.org/repository/alpine_edge
2025-05-13 10:02:03 <Kladky> Also see https://github.com/repology/repology-updater/issues/1495
2025-05-13 10:28:12 <ptrc> armhf/aarch64 edge builders are stuck
2025-05-13 10:29:38 <ncopa> i'll have a look
2025-05-13 10:34:12 <ncopa> re repology and go-away. I wonder if it would make sense to have a static website with the aports tree, that is automatically `git pull`ed from on git push events
2025-05-13 10:34:44 <ncopa> that way we dont waste cgit cpu time to generate the aports tree
2025-05-13 11:12:46 <Kladky> Yeah, that sounds sensible
2025-05-13 13:08:03 <ptrc> we could just set up a small script that listens on mqtt and `wget --mirror`s the actual cgit page, i guess?
2025-05-13 13:10:51 <ncopa> i was thinking a mqtt listener that simply do if [ -d aports ]; then git -C aports pull; else git clone ...; fi
2025-05-13 13:11:11 <ptrc> ah, do they expect just the plaintext files?
2025-05-13 13:11:17 <ncopa> i think so
2025-05-13 13:11:49 <ncopa> https://github.com/repology/repology-updater/blob/master/repos.d/alpine/alpine.yaml#L63
2025-05-13 13:27:37 <ptrc> actually, does repology use a specific user agent?
2025-05-13 13:27:40 <ptrc> we could just whitelist that
2025-05-13 13:27:59 <ptrc> https://github.com/repology/repology-updater/blob/c93777454f35b591822c6cb1161a90a9461ca537/repology/fetchers/http.py#L36
2025-05-13 13:28:00 <ptrc> yeah
2025-05-13 13:28:05 <ptrc> that sounds waaaaay simpler
2025-05-13 13:36:22 <ikke> Nod
2025-05-13 14:17:23 <ncopa> good idea
2025-05-13 14:18:21 <ncopa> ikke: how do we add the user agent to the allowlist?
2025-05-13 14:25:06 <ikke> It's defined in /srv/compose/cgit/config/go-away on deu1-dev1
2025-05-13 14:25:30 <ikke> You could copy and adjust one of the existing desired crawlers / bots
2025-05-13 14:25:43 <ikke> But I can do that in a bit as well 
2025-05-13 14:50:43 <ncopa> I added - 'userAgent.contains("repology-fetcher/0 ")'
2025-05-13 14:51:11 <ncopa> do I need to rebuild or restart the container?
2025-05-13 14:52:04 <clandmeter> why dont they use github repo?
2025-05-13 14:52:47 <ikke> ncopa: you can restart the go-away container 
2025-05-13 14:53:26 <ncopa> clandmeter: excellent question
2025-05-13 14:56:23 <ikke> From the Github issue, it's the link checker that's affected? 
2025-05-13 14:56:30 <ikke> > It's not the updater, it's linkchecker
2025-05-13 15:09:09 <ikke> Apparently there is a different user agent for that
2025-05-13 19:09:04 <ncopa> ikke: I assume you cleaned up the go-away config. Thank you!
2025-05-13 19:10:42 <ikke> ncopa: yes, the link checker was still blocked 
2025-05-13 19:21:22 <ncopa> it works now. https://github.com/repology/repology-updater/issues/1495#issuecomment-2877638457
2025-05-13 20:11:00 <ikke> Great
2025-05-13 20:29:37 <ikke> bootstrappking openjdk11 on build-3-22-x86_64
2025-05-14 05:04:26 <ikke> ncopa: fyi, I've requested an extra ppc64le VM from osuosl which was approved. It can act as a CI host
2025-05-14 05:10:32 <ikke> bootstrappking openjdk11 on build-3-22-s390x
2025-05-14 18:19:51 <ikke> durrendal: We have one server available to setup as a mirror, maybe we can work together on it to automate the process?
2025-05-14 18:56:47 <ikke> bootstrappking openjdk17 on build-3-22-loongarch64
2025-05-14 20:33:47 <ikke> bootstrappking openjdk17 on build-3-22-ppc64le
2025-05-14 22:13:40 <durrendal> ikke: slow reply, hectic day today. I would love to help out though! Do you have a deadline, or specific time you want the server up by?
2025-05-15 16:31:27 <mio> would it be possible to have the tarballs of paper-gtk-theme-2.1.0-r2 and pcc-libs-20230603-r0 copied over to 3.22 distfiles or someplace where the 3.22 builders can access them? the upstream source has been returning 404 for more than 2 weeks, and in the case of paper-gtk-theme the github repo no longer exists
2025-05-15 16:33:47 <ikke> ack
2025-05-15 16:34:06 <ikke> could you give the filenames?
2025-05-15 16:34:30 <mio> https://distfiles.alpinelinux.org/distfiles/v3.21/paper-gtk-theme-2.1.0.tar.gz
2025-05-15 16:34:38 <mio> https://distfiles.alpinelinux.org/distfiles/v3.21/pcc-libs-20230603.tgz
2025-05-15 16:34:45 <mio> thanks!
2025-05-15 16:35:25 <ikke> done
2025-05-15 16:36:04 <mio> thanks, appreciated :)
2025-05-15 17:00:35 <mio> sorry, could you also add pcc as well? just unlocked after pcc-libs rebuilt https://distfiles.alpinelinux.org/distfiles/v3.21/pcc-libs-20230603.tgz
2025-05-15 17:01:00 <mio> from the same upstream as pcc-libs
2025-05-15 17:01:30 <ikke> done
2025-05-15 17:01:52 <mio> thanks!
2025-05-15 17:02:31 <ikke> Maybe would be good to open issues for those packages if upstream is gone
2025-05-15 17:03:34 <mio> sure, on it
2025-05-15 17:15:12 <ikke> durrendal: there is no hard deadline that we know of
2025-05-16 00:17:02 <durrendal> ikke: okay great! Do we have any references on how the existing mirror servers are setup? Would love to read through what we have currently.
2025-05-16 00:18:28 <durrendal> Also let me know what time generally is most convenient for you, I'll try and bend my schedule around it if I can :)
2025-05-16 05:11:12 <ikke> durrendal: https://gitlab.alpinelinux.org/alpine/infra/compose/alpine-mirror-sync is the meat of it, combined with traefik in front
2025-05-16 13:08:03 <durrendal> ikke: thanks a ton! I'll dig through this as soon as I've got some time today. My initial thought just glancing at the compose file is that it should be fairly straight forward to come up with a generic deployment mechanism for anything using docker compose.
2025-05-16 13:08:39 <durrendal> secrets could be handled through ansible-vault initially, though it'd be better to use something like openbao to source those
2025-05-16 13:09:20 <durrendal> I'm certain there's more to the deployment than just pulling in the compose file though
2025-05-16 15:08:28 <ikke> yeah, but just slightly
2025-05-17 21:56:31 <ptrc> > Aparently the production builders have lua-term pre-installed, but its files are either incomplete or in a non-default location. In this way luarocks skips the installation and the compiler doesn't find the files later.
2025-05-17 21:57:16 <ptrc> any idea what could need lua-term on the builders?
2025-05-17 21:57:32 <ptrc> in the dependency graph there's just lua-busted
2025-05-17 21:57:47 <ptrc> but lua-aports doesn't touch either
2025-05-18 03:02:45 <ikke> ptrc: it's not pre-installed
2025-05-18 14:26:16 <ikke> Working on deploying renovate-bot on a kubernetes cluster: https://gitlab.alpinelinux.org/alpine/infra/k8s/cluster-nld12/-/tree/master/deployments/apps/renovate-bot
2025-05-18 14:26:32 <ikke> But deploying it through CI/CD, not manually
2025-05-18 14:27:21 <ikke> And it has been deployed here: https://gitlab.alpinelinux.org/alpine/infra/k8s/cluster-nld12/-/jobs/1857474
2025-05-18 15:51:49 <ncopa> awesome!
2025-05-19 11:54:42 <ncopa> LSP cmd connects to lsp server via rpc.connect using hostname
2025-05-19 11:54:42 <ncopa> test/functional/plugin/lsp_spec.lua:5445: test/functional/plugin/lsp_spec.lua:5452: server must receive `initialize` request
2025-05-19 11:55:09 <ncopa> that error on build-3-22-x86_64 when building neovim happens due to ::1 is missing in /etc/hosts. I have fixed it now
2025-05-19 12:57:36 <ncopa> looks like loongarch64 CI cannot lookup www.x.org? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1858905#L137
2025-05-19 14:00:17 <ncopa> I'm bootstrapping openjdk11 on build-3-22-ppc64le
2025-05-20 16:41:06 <ikke> Yo dawg, I heard you liked kubernetes and renovate, so I put renovate in kubernetes, so that renovate can update renovate running in kubernetes
2025-05-20 16:49:09 <f_|DSR> hah
2025-05-21 13:27:26 <ncopa> OSError: [Errno 28] No space left on device
2025-05-21 13:27:36 <ncopa> How can i clean up the x86_64 ci?
2025-05-21 13:44:13 <ikke> Which runner?
2025-05-21 13:54:30 <ncopa> https://gitlab.alpinelinux.org/admin/runners/235
2025-05-21 13:55:06 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1861967
2025-05-21 14:08:41 <ikke> You can ssh into x86-64.ci.alpinelinux.org
2025-05-21 14:08:53 <ikke> And then run docker system prune -af
2025-05-21 14:23:54 <ncopa> ssh: Could not resolve hostname x86-64.ci.alpinelinux.org: Name does not resolve
2025-05-21 15:09:00 <ikke> sorry, it's with an _
2025-05-21 15:09:04 <ikke> root@x86_64.ci.alpinelinux.org
2025-05-22 04:58:38 <ikke> cz.a.o has 275GB of space left
2025-05-22 14:12:41 <fossdd|m> uh so gitlab is down
2025-05-22 14:16:52 <ikke> oof, checking
2025-05-22 14:17:46 <ikke> apparently it's up again
2025-05-22 14:19:47 <fossdd|m> ah yeah
2025-05-22 14:26:34 <ikke> something caused heavy load
2025-05-22 15:08:40 <iggy> you aren't supposed to use _'s in hostnames
2025-05-22 15:08:52 <ikke> ahuh