2024-10-01 07:46:37 <clandmeter> ptrc: main as default?
2024-10-01 07:51:42 <ikke> https://pkgs.alpinelinux.org/contents
2024-10-01 07:51:53 <ikke> The main repo is already selected 
2024-10-01 08:23:01 <clandmeter> ah
2024-10-01 08:23:24 <clandmeter> need to update that part as well 
2024-10-02 18:31:49 <clandmeter> i dont think every maintainer got an email from pkgs.a.o. seems i didnt handle the exceptions correctly
2024-10-02 18:32:30 <ikke> clandmeter: did you see the issue created today?
2024-10-02 18:32:52 <clandmeter> yes it was created after the fix :)
2024-10-02 18:33:11 <ikke> ah ok, because I received a similar e-mail after the issue was created
2024-10-02 18:33:39 <clandmeter> similar email?
2024-10-02 18:33:41 <clandmeter> from pkgs?
2024-10-02 18:33:45 <ikke> yes
2024-10-02 18:33:53 <clandmeter> the email should be before
2024-10-02 18:34:03 <clandmeter> else i dont know how this user could have known
2024-10-02 18:34:05 <ikke> Let me check
2024-10-02 18:34:34 <ikke> right, 6 minutes before
2024-10-02 18:35:24 <clandmeter> oh the issue was first :)
2024-10-02 18:35:33 <clandmeter> but i did fix it already locally
2024-10-02 18:35:42 <clandmeter> i saw the mail coming in and noticed the error
2024-10-02 18:36:03 <ikke> ok :)
2024-10-02 22:03:54 <clandmeter> ikke: the update failed kind of, looks like python oomed 
2024-10-02 22:04:18 <clandmeter> so i set init = true which will always process all indexes
2024-10-02 23:41:45 <mio> not sure if it's already been reported, but the gitlab history button returns 500 error on some aports directories. noticed it recently due to new apkbrowser's "Git repository" link now points to gitlab.a.o instead of git.a.o
2024-10-02 23:42:10 <mio> e.g. https://gitlab.alpinelinux.org/alpine/aports/-/commits/master/community/libwacom compared to https://git.alpinelinux.org/aports/log/community/libwacom
2024-10-03 06:53:26 <HRio> there seem to be an issue with Anitya and version numbers for getmail6, upstream releases are of this format 6.19.04, but Anitya thinks this == 6.19.4 and therefor nags that the package it not latest versio
2024-10-03 06:54:33 <HRio> https://github.com/getmail6/getmail6/tags
2024-10-03 06:56:29 <cely> You just upgraded it to 6.19.05 though
2024-10-03 06:58:11 <HRio> yes, but guess it will nag in a few hours again
2024-10-03 06:58:22 <cely> Ok
2024-10-03 06:58:46 <cely> Maybe more than a few hours, depending on how quickly fortify-headers is fixed
2024-10-03 07:00:09 <HRio> "getmail6 current: 6.19.04-r0 new: 6.19.4"
2024-10-03 07:00:16 <HRio> was the last nag
2024-10-03 07:00:16 <cely> (fortify issues are preventing 5 archs from proceeding to testing/)
2024-10-03 07:00:18 <cely> Ok
2024-10-03 07:03:02 <cely> As for me, Anitya nags me to upgrade Perl to an odd-numbered dev version, but not sure how you would solve that without a special exception for Perl that ignores dev versions
2024-10-03 07:06:19 <HRio> ah thats also anoying, I guess I will only get one nag per release, but you will get it everytime they do a new dev release?
2024-10-03 07:07:08 <cely> Thankfully Perl dev releases are not made that often
2024-10-03 08:37:57 <clandmeter> HRio: yes i noticed some version issues
2024-10-03 08:38:12 <clandmeter> I am just using apk version comparison logic
2024-10-03 08:44:43 <clandmeter> i am wondering how often we need to send these emails
2024-10-03 08:44:47 <clandmeter> every day, every week?
2024-10-03 08:46:26 <ikke> If it's going to keep sending emails for all outdated packages, at most once a week 
2024-10-03 08:48:17 <ikke> Previously it would just send one email per version
2024-10-03 09:39:21 <clandmeter> it will only send email when a pkg is flagged
2024-10-03 09:39:37 <clandmeter> so when pkg is updated the flag is reset
2024-10-03 09:42:51 <clandmeter> it could be an option to include the previous flagged packages, but only send on new.
2024-10-03 09:43:04 <clandmeter> previously it would send one email per pkg
2024-10-03 13:37:30 <cely> I think the fortify upgrade is causing Go test to fail: https://gitlab.alpinelinux.org/fabricionaweb/aports/-/jobs/1542801
2024-10-03 13:40:51 <ikke> better for #-devel?
2024-10-03 13:42:47 <cely> Not in there for the time being, there will probably be others that fail on the same thing
2024-10-03 13:43:12 <cely> 
ACTION remembers yyjson, goes to try a rebuild

2024-10-03 13:50:25 <cely> yyjson already has -Wno-stringop-overflow from the last time a fortify upgrade was attempted
2024-10-03 14:08:32 <cely> Anyway, it seems this has been reported: https://github.com/jvoisin/fortify-headers/issues/68
2024-10-03 14:11:12 <cely> Hehe, as usual, ppc64le is not affected (looking at the Go MR)
2024-10-03 14:53:03 <ncopa> same issue as https://github.com/jvoisin/fortify-headers/issues/68
2024-10-03 14:54:11 <ncopa> do we have smaller testcases?
2024-10-03 14:59:38 <cely> Are you asking for other aports that fail with the strongop-overflow error?
2024-10-03 14:59:44 <cely> Aports simpler than Go and the kernel
2024-10-03 15:00:07 <ikke> Probably an isolated test case?
2024-10-03 15:00:39 <cely> If so, then yyjson, after removing -DCMAKE_C_FLAGS and -DCMAKE_CXX_FLAGS
2024-10-03 15:01:15 <cely> That was a reply to simpler aports, not isolated test cases
2024-10-03 15:03:25 <cely> I think even libindi (!72922) has -Wstringop-overflow, but it's not treated as an error
2024-10-04 06:33:14 <qaqland> 
ACTION found that several previous problems in new pkgs.a.o have been fixed \o/

2024-10-04 08:37:17 <PureTryOut> Oh I see pkgs.a.o has been switched to apkbrowser. Nice!
2024-10-04 08:52:24 <ikke> Yes
2024-10-04 09:01:54 <mps> huh, abuuld segfaults https://tpaste.us/qYMw
2024-10-04 09:02:02 <mps> abuild*
2024-10-04 09:03:11 <ikke> It's not abuild that segfaults
2024-10-04 09:04:02 <ikke> It's modpost that is segfaulting 
2024-10-04 09:07:55 <mps> right
2024-10-04 09:08:37 <mps> but first time see segfaults when building kernel, i.e. more than 30 years
2024-10-04 09:16:13 <mps> first time ofc if my memory still work :)
2024-10-04 09:18:18 <mps> looks like fortify-headers are buggy
2024-10-04 09:29:26 <mps> as expected, downgrading fortify-headers fixes this problem
2024-10-04 09:31:02 <mps> ah, looks like ncopa did something about this
2024-10-04 09:35:14 <mps> looks like I have to add cron task to do `apk upgrade` every 5 minutes ;)
2024-10-04 10:24:18 <ncopa> apk add apk-cron
2024-10-04 10:24:26 <ncopa> but will only do it daily iirc
2024-10-04 10:28:34 <mps> this was joke, I prefer manual upgrade
2024-10-04 16:29:05 <PureTryOut> Oh I see apkbrowser for Alpine is maintained on https://gitlab.alpinelinux.org. Why a fork, why not take upstream and help out improving that?
2024-10-04 16:29:13 <PureTryOut> CC carlolandmeter, idk if he is in the channel here
2024-10-04 16:36:34 <ptrc> clandmeter: ^
2024-10-04 16:36:42 <ptrc> also the footer sounds very much wrong
2024-10-04 16:36:49 <ptrc> all rights reserved for Alpine Linux?
2024-10-04 16:37:11 <ptrc> and the original licence has Martijn Braam on it
2024-10-04 16:37:19 <ptrc> i really don't think we can do that
2024-10-04 16:58:25 <mps> what is apkbrowser
2024-10-04 16:58:35 <ikke> pkgs.a.o
2024-10-04 16:58:46 <mps> ah, web app
2024-10-04 16:59:31 <mps> to my eyes I don't see diffs with old
2024-10-04 16:59:56 <cely> Old one is now at pkgs-old.a.o
2024-10-04 17:01:15 <mps> hm, what is different, I wonder
2024-10-04 17:02:27 <cely> New one is written in Python, and iirc, also used by pmOS, Chimera, and OpenWrt
2024-10-04 17:03:12 <cely> No more manual flagging: https://pkgs.alpinelinux.org/flagging
2024-10-04 17:05:54 <mps> written in python? what a degradation :)
2024-10-04 17:06:44 <cely> Old one was in Lua, i think the reasoning is, maybe it is easier to get contributors for Python
2024-10-04 17:09:23 <mps> not easier but maybe more new programmers who know only python. I don't think that means  better quality
2024-10-04 17:09:47 <cely> Hopefully no one rewrites it in Rust
2024-10-04 17:10:02 <mps> heh, I agree here
2024-10-04 17:10:53 <mps> maybe rewrite in dart/flutter ;)
2024-10-04 18:16:36 <PureTryOut> celeste: OpenWRT? Really? Got a link?
2024-10-05 02:07:42 <celie> https://forum.openwrt.org/t/183206 https://lists.openwrt.org/pipermail/openwrt-devel/2024-January/041989.html
2024-10-05 10:15:02 <clandmeter> ptrc: originally it was created by alpine, pmos converted it and reused lots the code like templates and other parts. but in any case i just removed the copyright stuff as it has no function anyways.
2024-10-05 10:16:22 <clandmeter> PureTryOut: there are now 3-4 copies of the original design, all following its own path. i dont see a problem with that. 
2024-10-05 10:18:12 <clandmeter> chimera has a lot of changes as well, like using the new binary db.
2024-10-05 10:20:34 <clandmeter> and the reason the switch to python is that lua-turbo has issues and not that easy to fix. I assume that is the reason pmos converted it into python.
2024-10-05 10:58:52 <PureTryOut> I'd have preferred we all collaborated on the original tbh. Now we're all individually making the same fixes and changes besides the few distro specific ones.
2024-10-05 10:58:52 <PureTryOut> I guess we'll consider the Alpine one the new upstream then and submit changes there to make it usable for pmOS out-of-the-box as well
2024-10-05 11:23:35 <clandmeter> I can add one of you to the project if you like
2024-10-06 13:39:51 <PureTryOut> I don't need merge rights persé if that's what you mean, just someone to merge PR's we might shoot in 😉
2024-10-06 16:36:47 <mps> ikke: what is the reason you marked as Draft !73075
2024-10-06 16:37:19 <ikke> CI failure
2024-10-06 16:37:51 <mps> aha, now it is passed. I will merge it if you are ok with this
2024-10-06 16:37:58 <ikke> yes
2024-10-06 16:38:04 <mps> thanks
2024-10-06 16:38:43 <ikke> It helps with hiding these MRs from the list of open MRs to review
2024-10-06 16:39:00 <ikke> so once the failure is solved, MR authos can mark the MRs as ready
2024-10-06 16:39:05 <ikke> authors*
2024-10-06 16:39:44 <mps> merged. lets pray
2024-10-07 07:42:23 <mps> https://lwn.net/Articles/993083/ food for thought. this is some of reasons I don't like dependencies in packages
2024-10-07 07:42:51 <mps> and I fear alpine going to this path
2024-10-07 09:43:00 <mps> what we do if we don't want to fulfill users request in pkg? simply ignore or answer and risk to be harassed and waste time
2024-10-07 09:45:05 <mps> when I answer with simple reasoning I usually got more question and what not
2024-10-07 11:18:31 <ncopa> sounds like a discussion for #alpine-security instead of infra
2024-10-07 11:19:24 <ncopa> but in general, this is why alpine does not automatically start services just because the package was installed, like debian and ubuntu does
2024-10-07 11:26:07 <ncopa> i am fairly confident that very few of those linux servers are Alpine
2024-10-07 11:53:14 <ptrc> we don't even have a service for cups-browsed
2024-10-07 11:53:24 <ptrc> people would have to set it up manually
2024-10-07 12:03:05 <mps> yes, you both are right. I'm just told my feeling loudly
2024-10-07 20:14:56 <ikke> Receiving a lot of spam user registrations on gitlab the last couple of days, mostly unconfirmed users with semi-random domains
2024-10-07 20:24:01 <mps> "registration only via postcard" :)
2024-10-08 08:51:50 <ncopa> i think we can upgrade loongarch64 machine to use dl-cdn now, and upgrade to latest kernel?
2024-10-08 08:52:09 <ncopa> it still uses dev.a.o
2024-10-08 08:52:57 <ncopa> clandmeter: do you think we can reboot che-bld-2?
2024-10-08 08:53:15 <ncopa> hum, maybe after qt5 is built
2024-10-08 09:10:09 <ncopa> what machine is running the CI for loongarch64?
2024-10-08 10:02:54 <ikke> ncopa: 172.16.24.5/24
2024-10-08 10:03:56 <ncopa> root@172.16.24.5's password: 
2024-10-08 10:04:03 <ncopa> my ssh key is not there
2024-10-08 10:04:11 <ncopa> maybe we coudl upgrade the kernel and reboot it?
2024-10-08 10:09:38 <ikke> will do in a bit
2024-10-08 10:21:09 <ikke> rebooting che-ci-3 now
2024-10-08 10:30:12 <ikke> There's also che-ci-2, on 172.16.24.4
2024-10-08 10:40:40 <ncopa> i think we may have performance issues with shared runner on x86_64
2024-10-08 10:41:00 <ikke> I noticed the host responding slowly
2024-10-08 10:41:03 <ncopa> https://gitlab.alpinelinux.org/admin/runners/145#/jobs
2024-10-08 10:41:07 <ncopa> getting time outs
2024-10-08 10:41:38 <ncopa> maybe someone is borrowing it to mine bitcoins
2024-10-08 10:42:29 <ikke> Nothingn I can see at least
2024-10-08 10:53:39 <ncopa> then its probably just a tiny rootkit :)
2024-10-08 10:56:43 <cely> Speaking of the CI runner
2024-10-08 10:57:12 <cely> The new 10-core aarch64 one builds Rust in half the time the 24-core one took
2024-10-08 10:57:58 <ikke> That's ncopa's macbook
2024-10-08 10:58:44 <cely> Ok, quite surprising (to me) that a Macbook is able to build Rust faster than a server
2024-10-08 10:58:51 <ikke> ncopa: fyi, it;s building scudo_malloc now
2024-10-08 10:59:12 <ikke> the server has many cores, but each core is not that fast
2024-10-08 11:00:02 <ncopa> cely: thats Apples M3 cpu in a VM
2024-10-08 11:00:26 <cely> Ok
2024-10-08 11:00:43 <ncopa> cool that is is so fast
2024-10-08 11:01:08 <ncopa> i have seen M1 do crazy fast things under certain workloads
2024-10-08 11:01:15 <ncopa> i think it was some perl related tests
2024-10-08 11:01:20 <cely> Maybe that's why i've heard of people building GHC on riscv64 emulated on Apple's CPUs
2024-10-08 11:01:39 <ncopa> could be
2024-10-08 11:04:38 <mps> ncopa: oh, you got M3?
2024-10-08 11:05:12 <ncopa> yup, for my k0s work
2024-10-08 11:05:39 <mps> please employ me there :D
2024-10-08 11:05:53 <mps> JK
2024-10-08 11:06:00 <ncopa> https://www.mirantis.com/careers/
2024-10-08 11:18:59 <mps> cely: apple silicon is really fast but in my tests two years ago emulation of riscv64 on it is not so fast as I expected
2024-10-08 11:19:19 <mps> maybe I should try again
2024-10-08 11:19:55 <mps> emulating under linux, not macos I mean
2024-10-08 11:20:48 <cely> Ok
2024-10-09 17:33:06 <ncopa> the CI machines are busy
2024-10-09 17:33:16 <ikke> yup
2024-10-09 17:33:36 <ikke> https://imgur.com/a/HAoRMFK
2024-10-09 17:33:45 <ncopa> chromium, donet8, donet6, rebuild of stuff (32 packages)  against py-numpy
2024-10-09 17:33:49 <ncopa> and my llvm19 work
2024-10-09 17:33:59 <ikke> What can we do about it except sit and wait?
2024-10-09 17:34:38 <ikke> The queue is decreasing already, used to be 61 pending
2024-10-09 17:49:29 <ncopa> yeah
2024-10-09 17:49:32 <ncopa> nothing we can do
2024-10-09 18:20:16 <ikke> back to 40 jobs in the queue
2024-10-09 20:50:49 <ikke> Fun, another gitlab critical CVE
2024-10-10 07:17:20 <ncopa> thank you for taking care of that ikke <3
2024-10-10 07:19:33 <ncopa> stupid idea for this problem: I am working on llvm19, which includes rebuild clang19 and lots other stuff. For some arches, the llvm19 passes, for some it fails. very time i try to push a fix for something, it will rebuild stuf that already works. is there something we can do to avoid needless rebuilds?
2024-10-10 07:20:21 <ncopa> we could do some reproducible builds magic
2024-10-10 07:21:43 <ikke> ncopa: would be nice, but also sounds very tricky to get right 
2024-10-10 07:21:52 <ncopa> maybe we can create a hash of the APKBUILD+dependency chain. after the build is done, we store the artifacts in a cache storage
2024-10-10 07:21:58 <ncopa> key/value storage
2024-10-10 07:22:13 <ncopa> where the hash of the is the key
2024-10-10 07:22:32 <ncopa> and the artifact is stored for a limited time
2024-10-10 07:22:36 <ncopa> lets say 24 hours
2024-10-10 07:23:00 <ikke> cache is per ci-host
2024-10-10 07:23:06 <ikke> Artifacts per pipeline 
2024-10-10 07:23:29 <ncopa> before the CI starts the build, it calculate the has from APKBUILD+deps, it irst tries to fetch from the key/value storage cache
2024-10-10 07:23:38 <ncopa> if its missing it builds it all
2024-10-10 07:23:44 <ncopa> if its there its skipped
2024-10-10 07:23:49 <ikke> Right
2024-10-10 07:24:01 <ikke> But wouldn't it also need the actual packages?
2024-10-10 07:24:19 <ncopa> that is what i call the "artifacts"
2024-10-10 07:24:25 <ikke> Ok
2024-10-10 07:24:29 <ncopa> you store the actual packages in the cache
2024-10-10 07:24:52 <ncopa> the tricky part is how to calculate the hash
2024-10-10 07:25:01 <ikke> We have storage on our mirror infra we could use
2024-10-10 07:25:32 <ikke> Maybe some object storage fronted 
2024-10-10 07:25:40 <ncopa> yes
2024-10-10 07:26:07 <ncopa> that is just an idea at this point
2024-10-10 07:26:49 <ncopa> we need to be able to calculate the hash so that if anything changes, that would result in different binary, we need to get different hash
2024-10-10 07:27:11 <ncopa> so it needs to include the dependency chain
2024-10-10 07:27:49 <ncopa> for example
2024-10-10 07:28:27 <ncopa> we could install the makedepends, trace the depenency chain and get the hash for each package in dependency chain
2024-10-10 07:28:33 <ncopa> and has the APKBUILD
2024-10-10 07:29:22 <ncopa> so that if nothing changes in APKBUILD, nor anything else in the dependency chain, we get the exact same hash, and gan fetch the packages from object storage
2024-10-10 08:32:36 <cely> Before you removed the other aports, leaving only llvm19, the artifacts weren't uploaded, as they exceeded the max size
2024-10-10 21:55:47 <iggy> sounds vaguely like ccache with a shared cache?
2024-10-11 07:54:39 <ncopa> shared ccache sounds like a relatively easy way to solve this. we already support ccache in abuild, so I suppose we could just set up shared storage for sccache and plug that in
2024-10-11 07:55:06 <ncopa> should offload the CI machines on rebuilds
2024-10-11 15:48:01 <ncopa> seems like nld-bld-3 (aka nld8-dev1.alpinelinux.org) does not have dmvpn running?
2024-10-11 15:49:05 <ikke> It's running, but not working
2024-10-11 15:51:23 <ncopa> ok. its weekend for me now. have a nice weekend!
2024-10-11 15:51:53 <ikke> o/
2024-10-11 16:25:32 <ikke> gitlab sometimes cannot make up its mind about how many users there are
2024-10-14 10:36:07 <ncopa> im reconfiguring build-edge-loongarch64. it now gets ip via dhcp, and configured it to be .10 in dnsmasq
2024-10-14 10:37:09 <ncopa> i suppose we want the build-3-21-loongarch64 to run on same as the build-edge-loongarch64 lxc host?
2024-10-14 10:37:17 <ncopa> on che-bld-2
2024-10-14 10:39:12 <ikke> We have only one host designated as builder, so I suppose so
2024-10-14 10:39:24 <ikke> 1 builder, 1 dev, 2 ci
2024-10-14 11:08:19 <ncopa> im bootstrapping aports on the 3.21 builders now
2024-10-14 21:21:09 <ptrc> huh, what's happening with pkgs.a.o
2024-10-14 21:21:13 <ptrc> it's constantly out of date
2024-10-14 21:21:32 <ptrc> today it's wasi-compiler-rt: https://pkgs.alpinelinux.org/package/edge/main/x86_64/wasi-compiler-rt
2024-10-14 21:21:43 <ptrc> 18.1.8 on pkgs.a.o, in reality 19.x
2024-10-15 12:44:29 <ncopa> seems like ci runners are busy again
2024-10-15 12:51:38 <ikke> 32 pending jobs
2024-10-15 13:20:57 <ncopa> i can start up the 3.21 builders now, right?
2024-10-15 13:24:59 <ikke> I think so
2024-10-15 13:25:06 <ikke> Is there enough space?
2024-10-15 13:29:18 <ncopa> i hope so
2024-10-15 13:29:20 <ncopa> :)
2024-10-15 13:29:27 <ncopa> i can check
2024-10-15 13:29:41 <ncopa> for riscv64, yes. 700+G
2024-10-15 13:30:03 <ncopa> but it seems like the riscv64 builders does not mount /tmp as tmpfs
2024-10-15 13:30:18 <ncopa> maybe that would help with performance
2024-10-15 13:31:40 <ncopa> so we want mount /tmp via /etc/fstab in container or via lxc config?
2024-10-15 13:47:36 <ikke> Usually lxc config 
2024-10-15 13:47:49 <ikke> But don't have a strong opinion 
2024-10-15 14:10:46 <ncopa> we have disk space problem for s390x
2024-10-15 14:11:11 <ncopa> on 50G free
2024-10-15 14:15:35 <ikke> Deleting caches on the various builders should help a bit, but it becomes tighter and tighter 
2024-10-15 15:12:50 <ncopa> we have 222G on x86_64 builder
2024-10-15 15:13:05 <ikke> We can expand the lvs there
2024-10-15 15:13:09 <ikke> lv*
2024-10-15 15:14:01 <ncopa> 👍
2024-10-15 15:14:47 <ikke> vg0   1   4   0 wz--n- <6.55t 5.45t
2024-10-15 15:15:49 <ikke> on arm, we have 232.6G for 3 builders
2024-10-15 15:16:27 <ikke> I can clean it up a bit
2024-10-15 15:32:12 <ncopa> s390x is the most problematic machine at the moment
2024-10-15 15:33:23 <ikke> 330G on arm after clean
2024-10-15 15:33:25 <ikke> that's also alarming
2024-10-15 15:33:30 <ikke> 110G per builder is challenging