2024-06-03 15:33:26 Apparently some scraping being done 2024-06-03 15:39:12 I must say, goaccess is super nice to quickly find the culprits 2024-06-03 17:36:33 heya ikke - do we have directories in place for a 3.20 cloud images release? 2024-06-03 17:38:01 on dev.alpinelinux.org 2024-06-03 17:39:45 tomalok: now there ss 2024-06-03 17:39:47 is 2024-06-03 18:54:15 ikke: ty 2024-06-04 20:11:06 could we by any chance have some swap for the CI runner machine? 2024-06-04 20:11:53 they have way more concurrency than actual builders, and they keep running out of memory on projects like Firefox 2024-06-04 20:15:00 ptrc: can you specify which runners 2024-06-04 20:15:04 we have 2 sets now 2024-06-04 20:15:25 currently, aarch64 (usa-che-1 shared-runner) 2024-06-04 20:16:08 however let me find the other one, because i'm pretty sure some x86_64 runner had the same issue 2024-06-04 20:16:52 for x86_64 we only have one host 2024-06-04 20:16:59 https://gitlab.alpinelinux.org/sertonix/aports/-/jobs/1405676 2024-06-04 20:17:06 that's just x86_64.ci.alpinelinux.org 2024-06-04 20:17:20 yes 2024-06-04 20:59:58 666 MRs, now. Doomsday ;-) 2024-06-06 13:17:51 lesigh 2024-06-08 19:17:56 bleh 2024-06-08 19:18:49 ACTION feels lonely here 2024-06-08 19:24:56 \o 2024-06-08 19:27:39 mps: o/ 2024-06-08 19:28:19 ikke: you not alone now ;-) 2024-06-08 19:28:23 :) 2024-06-08 19:30:08 and algibot is chatty last two days :-) 2024-06-08 19:30:15 yup 2024-06-08 19:30:32 I've been tweaking things a bit to flap a little less 2024-06-08 19:31:11 this will be good improvement 2024-06-08 20:48:51 *Tweaking intensivies* 2024-06-08 20:49:49 <3 2024-06-09 13:01:37 x86 CI builder seems to be having issues 2024-06-09 13:05:54 what kind of issues? 2024-06-09 13:16:30 not running, like this https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1416543 2024-06-09 13:16:37 but it did then run 2024-06-09 13:17:49 and also failed a few times here https://gitlab.alpinelinux.org/maribu/aports/-/jobs/1416439 2024-06-09 13:18:18 that seem to have been disk space issues 2024-06-09 13:34:48 I did fix the disk space issues 2024-06-09 13:34:56 when you mentioned it about krita 2024-06-09 13:35:27 omni: and that's x86_64, not x86 :) 2024-06-09 13:46:05 omni: that jobs succeeds the 2nd time 2024-06-10 15:22:07 Hello, OVHcloud will officially host a alpinelinux mirror. We need a contact email in case sync breaks at some point. Can I use alpine-infra@lists.alpinelinux.org? Is it still monitored? 2024-06-10 15:32:46 alpine-mirrors@alpinelinux.org is a better address. Otherwise, infra@a.o, which is a forward address 2024-06-10 15:34:24 ok thanks 2024-06-11 11:51:25 ikke: i think something is a bit problematic with https://gitlab.alpinelinux.org/maribu/aports/-/jobs/1418151 but i can't tell what's the issue 2024-06-11 11:52:04 What do you think is problematic? 2024-06-11 11:52:36 biber2.19 is being built, but i don't see any changes to it in the MR 2024-06-11 11:53:04 and i also noticed that while doing the Perl rebuilds, that biber2.19 seemed to be built then too, even though i didn't bump its pkgrel 2024-06-11 11:56:20 Yes, just checked build.a.o, and the build log for biber2.19 has changed: archs that have it enabled have ">>> biber2.19: Package is up to date" and those where is is disabled have: "Package not available for the target architecture" 2024-06-11 11:57:01 At least, armv7 and armhf has that "not available" message 2024-06-11 12:01:50 cely: ap builddirs biber returns b oth 2024-06-11 12:01:57 I have no time to figure it out furtrher 2024-06-11 12:02:04 but there is something with those aports 2024-06-11 12:04:09 Yes, unfortunately :( 2024-06-11 12:04:27 If it is due to my involvement, i regret it 2024-06-11 12:30:14 I'll check later 2024-06-11 12:53:56 Thanks 2024-06-11 13:23:48 fcolista: Friendly ping regarding !67373, and the conversation here (regarding ap builddirs returning both biber and biber2.19, that contributor keeps @-mentioning me and pushing things, but i hesitate to assign that MR to you, as it will not be ready until the ap builddirs issue is sorted out) 2024-06-11 13:27:25 I drafted it before, and mentioned the biber2.19 issue needing investigation, but apparently, they don't see the seriousness of this, and have marked it as ready again 2024-06-11 13:28:36 hicely 2024-06-11 13:28:40 hi cely 2024-06-11 13:28:54 Hi 2024-06-11 13:29:34 I'm inclined to drop biber2.19 2024-06-11 13:29:46 and left the only latest version of biber working with biblatex 2024-06-11 13:30:30 Unfortunately, biber2.19 is under their maintenance, and was their idea 2024-06-11 13:30:44 which is why i said i regretted my involvement 2024-06-11 13:31:06 i don't think it's that good of an idea now 2024-06-11 13:31:53 but i did fix up a few things when it was blocking the builders 2024-06-11 13:34:02 bah. TBH I don't even see what I can do 2024-06-11 13:35:37 in this case we want to support two different versions of biber and biblatex 2024-06-11 13:35:46 which basically is not supported by apk 2024-06-11 13:36:23 I guess that was probably their intention 2024-06-11 13:37:04 i think that this bad hack is not maintainable in the long run 2024-06-11 13:37:26 and shouldn't have been merged.. 2024-06-11 13:37:59 i would drop this and move to unmaintained 2024-06-11 13:38:27 but it's just my own idea..perhaps someone else have different idea :) 2024-06-11 13:39:16 For reference, the MR that added biber2.19: !64930 2024-06-11 13:41:15 Probably we should've given it a more thorough review, but that didn't happen, and then pressure to merge was given through IRC 2024-06-11 13:55:59 Anyway, i'm bringing this up because !67373 modifies 2 of your aports, not asking you to solve any of this mess :) 2024-06-11 13:56:38 So, it's up to you whether you want to accept those changes (i would suggest caution, and not to bend under pressure from that contributor, who from what i see, can be very persistent in pushing things) 2024-06-11 15:36:25 cely: It's because biber2.19 provides biber. `ap builddirs` returns not only package with the specified package names, but also the packages that provide said package name 2024-06-11 15:37:10 not really expected 2024-06-11 15:39:14 https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/aports/db.lua?ref_type=heads#L152 2024-06-11 15:43:26 Ok 2024-06-11 15:44:43 https://gitlab.alpinelinux.org/alpine/lua-aports/-/commit/9e31086fa8f1f7cc8d72c962c6ac089b93a60a36 2024-06-11 15:45:21 I think that's an unintended consequence 2024-06-11 15:45:39 Thanks for looking into it, i guess it doesn't really matter as the aport is already in the index, so it won't be re-added which can cause checksum issues 2024-06-11 15:45:53 yup 2024-06-12 03:12:35 I think build-3-19-aarch64 is stuck on dotnet6-build, it's been at it for days 2024-06-12 06:48:09 thank you cely (sorry, back now to check irc :) ) 2024-06-12 06:48:37 You're welcome 2024-06-12 08:26:51 ikke: do we have some rules for merging such things !67580 2024-06-12 08:29:11 No, it's fine. Only the convention for the commit messages is 'main/*: ' 2024-06-12 08:29:58 ok, will merge it now 2024-06-12 08:30:45 Marian doing good things for alpine 2024-06-12 08:31:09 What do you think about his wanting to rename Perl man pages? 2024-06-12 08:31:38 cely: who 'you' 2024-06-12 08:31:58 I'm @Celeste 2024-06-12 08:32:28 cely: no, I mean whom you ask about rename Perl man pages 2024-06-12 08:32:40 That's my other account 2024-06-12 08:32:41 I know you are Celeste 2024-06-12 08:32:53 Marian 2024-06-12 08:33:07 I had a few hours long "discussion" about it with him 2024-06-12 08:33:14 ok, did you asked me about this 2024-06-12 08:33:16 and i regretted the time spent 2024-06-12 08:33:50 It was just 2 days ago 2024-06-12 08:33:59 after i merged the Perl 5.40 rebuild 2024-06-12 08:35:07 I'm personally not happy with perl man pages but I think we should not change it (at least for now, maybe in future) 2024-06-12 08:35:23 From what i know, our usual way of handling conflicting man pages (due to new CPAN modules being included in core Perl) is to delete them from the individual aports 2024-06-12 08:35:39 and i have spent a lot of time doing that 2024-06-12 08:36:04 yes, I agree this is right 'method' 2024-06-12 08:36:26 At first, he wanted to delete them from main/perl instead, thinking main/perl included the man pages but not the actual code (CPAN modules) 2024-06-12 08:36:51 Then i pointed out that the modules (Perl 5.40 included 2 new ones: Test2/Suite.pm and Term/Table.pm) are in main/perl 2024-06-12 08:37:11 long ago I proposed we should discuss this and try to find solution but now one 'take it to work on it' 2024-06-12 08:37:34 s/now/no/ 2024-06-12 08:37:57 good that you started 2024-06-12 08:38:42 (breakfast time) 2024-06-12 08:38:59 To track the events of the day, he started !67478 (sorry for rather harsh/annoyed tone in that MR, that was because i told him i was on it, and asked him to close the MR, but it didn't happen) 2024-06-12 08:39:31 That MR was before i made him aware that Perl 5.40 included Test2::Suite and Term::Table 2024-06-12 08:40:38 After that he started: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/297 2024-06-12 08:41:27 That he willing closed, and finally ended up sending an email to perl5 porters 2024-06-12 08:43:32 which is linked in that MR in abuild 2024-06-12 08:44:45 So, it turns out distros like Arch and Debian rename the man pages of Core Perl to .3perl instead of .3pm 2024-06-12 08:46:53 but they use man-db, whereas we prefer mandoc (at least it's the one in main/, while man-db is in community/) 2024-06-12 08:48:16 man-db is able override the section lookup order, so .3pm is preferred over .3perl, even though "pm" comes after "perl" in alphabetical order 2024-06-12 08:55:07 From what i see, mandoc doesn't do that, probably due to its roots in OpenBSD, where ports go into /usr/local, so there is no conflict between man pages of system Perl and CPAN modules from ports 2024-06-12 08:59:10 I actually consider this issue closed. Conflicting man pages were discovered between perl-doc and perl-test2-suite-doc/perl-term-table-doc, i delete man pages from the latter 2 leaving them in main/perl-doc 2024-06-12 09:00:00 I expect this has to be done at most once a year, when new major version of Perl is released 2024-06-12 09:01:32 but Marian had other thoughts and pulled me into an hours long discussion as if this was the most important bug discovered 2024-06-12 09:02:01 mps: so, now i'm asking your opinion, how far will you go? 2024-06-12 09:03:48 If a suitable extension that satisfies the lookup order of having main/perl man pages come after the other Perl/CPAN aports, i of course am willing to rename the extension of the man pages in main/perl 2024-06-12 09:04:44 but i do not think we should bring back the man pages that have already been deleted (for example, the ones in perl-term-table-doc) 2024-06-12 09:05:39 This extension-rename is to avoid future file conflicts, and what's been done in the past can be left alone 2024-06-12 09:08:22 but i've already spent too much time on this issue, and there are other more pressing things to attend to (i think new fortify-headers is about to break a lot of things) 2024-06-12 09:10:39 so in essence, what i am asking you is: do you think the man pages of Perl/CPAN aports that have already been deleted should be brought back? 2024-06-12 09:11:28 (i think there are about 15 that i worked on deleting starting a few months ago, there may be others) 2024-06-12 09:15:26 As far as i know, there should be no more conflicts, so even if main/perl man pages are renamed, i think what's done in the past (deleted man pages) can stay that way, as most of them are probably duplicates of what's already in main/perl-doc 2024-06-12 09:15:58 Alright, will go AFK too 2024-06-12 09:20:07 cely: first (not related to you) I don't like to see arguments of type 'other/big distro "do this in this way"'. for me such arguments are signs of not so good thinking. We should do what is best way/method for alpine and for our developers/maintainers 2024-06-12 09:21:11 Yes, i never looked at what Arch and Debian did to the man pages until Marian brought Arch up 2024-06-12 09:21:39 I just followed what we usually did, which is to delete man pages from the individual Perl/CPAN aports, not main/perl 2024-06-12 09:21:46 second, I always prefer to left "last word" to alpine developers then to maintainers. 2024-06-12 09:21:59 (if we deleted from main/perl, the list would be long) 2024-06-12 09:22:18 yes, I agree again with you 2024-06-12 09:23:36 third: people who do work on some pkg should be given more preferences in decisions 2024-06-12 09:23:51 who work for long time* 2024-06-12 09:24:19 TBH, I become lazy in last time 2024-06-12 09:25:00 Alright, thanks, so do we also agree that even if main/perl man pages have their extension renamed, it is not necessary to bring back deleted man pages? (at least, not all at once, maybe on a case by case basis where it is proven that the man pages provide extra value compared to those in main/perl) 2024-06-12 09:25:16 and one of reason is that I don't like to argue with newcomers and some stuppid^Wnot so smart ones 2024-06-12 09:26:10 cely: to me it looks like in transition period it would be better 'case by case' 2024-06-12 09:26:40 Alright 2024-06-12 09:27:36 We'd still need someone to have inspiration to come up with an extension that satisfies mandoc's lookup order, otherwise it's status quo :) 2024-06-12 09:27:49 anyway, perl have perldoc command and I don't see reason we have -doc subpackages in perl pkgs 2024-06-12 09:27:57 Hahaha 2024-06-12 09:28:04 My thought exactly! 2024-06-12 09:28:06 but this is my stubborn opinion only 2024-06-12 09:28:49 If people ever need something not provided by man pages, just use perldoc 2024-06-12 09:29:11 anyway, to finish this talk I have to say "I'm on your side" 2024-06-12 09:30:17 btw, Marian still do good things for alpine and I respect his work 2024-06-12 09:30:32 Sure 2024-06-12 18:43:53 ncopa: thanks for fixing qemu patch. I intended to do this tomorrow but you are fast 2024-06-12 18:44:32 which qemu patch? 2024-06-12 18:47:12 b267d36b5a152205973582279ed95cdc160aba61 2024-06-12 18:47:14 I guess 2024-06-12 18:48:59 mps: why is fix-strerrorname_np.patch needed now? 2024-06-12 18:49:33 this: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/qemu/fix-strerrorname_np.patch 2024-06-12 18:49:53 why dont we just remove the patch and use whatever comes from upstream? 2024-06-12 18:50:03 ncopa: I thought it is needed and because this refactored patch 2024-06-12 18:50:19 i dont think its needed anymore 2024-06-12 18:50:31 the problem was the user of the _np function 2024-06-12 18:50:32 I made mistake and not set 'Draft' MR 2024-06-12 18:50:45 no, its not any problem at all 2024-06-12 18:50:56 I wanted just to test on CIs will it pass 2024-06-12 18:51:12 and intended tomorrow to work more on it 2024-06-12 18:51:26 and i merged it without checking if it passed on riscv64 i assumed it timed out 2024-06-12 18:51:31 or maybe it actually timed out 2024-06-12 18:51:34 anyway, I will test if this patch is needed tomorrow 2024-06-12 18:51:59 it didn't pass CI for riscv64 2024-06-12 18:52:01 it shoudl not be needed 2024-06-12 18:52:09 i can test now 2024-06-12 18:52:21 ok, I will try now on riscv lxc 2024-06-12 18:53:31 (now I'm working on linux-asahi upgrade to 6.9.x series) 2024-06-12 19:08:31 nice, linux-asahi 6.9.3 can be built with rust 1.78 2024-06-12 19:52:35 do the devs lxc works on pioneer V 2024-06-12 19:53:25 your container is stopped, I can start it 2024-06-12 19:53:53 mps: You should be able to access it now 2024-06-12 19:55:37 ikke: thanks. though I don't have time now to use it, maybe I will set it tomorrow to use instead lxc on x86_64 2024-06-12 19:55:57 sure, no problem :) 2024-06-12 19:59:24 ncopa: we still need patch. build without it gives "kvm-cpu.c:(.text+0x538): undefined reference to `strerrorname_np'" 2024-06-12 19:59:35 but need to be fixed 2024-06-12 20:01:01 the patch needs to be fixed yes. https://build.alpinelinux.org/buildlogs/build-edge-riscv64/community/qemu/qemu-9.0.1-r0.log 2024-06-12 20:01:11 rv64 failed btw 2024-06-12 20:01:43 thats what we are talking about I suppose. the patch is supposed to fix build on riscv64 2024-06-12 20:01:57 yes 2024-06-12 20:02:48 I will try now but not sure will I finish it this night. If not I will tomorrow 2024-06-12 20:03:24 lxc container with qemu-user is slow 2024-06-12 20:06:59 anyway, pioneer lxc is faster 2024-06-12 20:07:09 i have pushed fix 2024-06-12 20:07:51 thanks 2024-06-12 20:58:33 ncopa: if qemu fails again on riscv64 this patch should work https://tpaste.us/YYOP (I think) 2024-06-12 21:00:12 I run it in lxc on pioneer but not sure I can wait to finish, have to go to sleep 2024-06-14 13:54:03 hello. ikke, to declare a new official mirror, I just have to set it on zabbix, right? 2024-06-14 13:56:19 No, it needs to be added to the mirror project 2024-06-17 11:26:47 ikke: i added contauro as sponsor 2024-06-17 11:26:52 fyi 2024-06-17 11:28:59 ,👍 2024-06-17 11:30:29 clandmeter: I've updated a bunch of infra to alpine 3.20 2024-06-17 11:30:54 nld-dev-1 not yet 2024-06-17 11:37:23 ikke: there are some commits in mksite, but not in production 2024-06-17 11:37:34 done by Patrycja Rosa 2024-06-17 11:37:49 I think ncopa pushed them 2024-06-17 11:41:15 Probably regarding irc? 2024-06-17 12:55:38 and also matrix 2024-06-17 12:56:06 I guess they need to go into production, but im not sure. 2024-06-17 12:57:27 Yeah, don't think that's a problem 2024-06-17 18:33:57 clandmeter: btw, rallly is broken atm, not sure why. It give a 54 2024-06-17 18:33:59 504 2024-06-17 18:34:33 uhm 2024-06-17 18:34:39 i didnt touch it 2024-06-17 18:36:11 I did upgrade the host 2024-06-17 18:36:38 i think its not using the override yml 2024-06-17 19:02:19 stupid issue 2024-06-17 19:06:17 im pulling a new version 2024-06-17 19:08:28 it was not listening to all interfaces 2024-06-17 19:08:35 and we have default and web... 2024-06-17 19:08:37 ah 2024-06-17 19:09:03 I wanted to check what it was listening on, but there was no ss / netstat in the container 2024-06-17 20:48:30 so, seems we have two small issues 2024-06-17 20:48:58 the CI runners are suddenly failing randomly 2024-06-17 20:49:07 and the 3.20 pkgs.a.o data is not getting updated 2024-06-17 20:49:21 the former is probably slightly more important.. 2024-06-17 20:50:04 https://gitlab.alpinelinux.org/fossdd/aports/-/pipelines/241916 2024-06-17 20:50:13 seems to be arm 32-bit, s390x and x86(_64) 2024-06-17 20:53:00 that's a first 2024-06-17 20:53:03 100% inode usage 2024-06-17 20:53:08 at least on x86_64 2024-06-17 20:54:06 yeah, on multiple runners 2024-06-17 20:57:11 !67791 2024-06-17 21:06:50 fossdd: !67791 2024-06-17 21:08:24 thx 2024-06-17 21:08:49 14 milion inodes 2024-06-17 21:08:55 a lot to clean up 2024-06-18 20:05:44 i wonder if we should move the riscv64 CI back to the milk-v boxes or keep them on scaleway 2024-06-18 20:09:56 right now, there are 4 runners active 2024-06-19 10:33:17 ^ lies 2024-06-19 14:15:45 mkdir: cannot create directory ‘/home/buildozer/aports/main/llvm18/src’: No space left on device 2024-06-19 14:16:23 on build-edge-x86 2024-06-19 14:57:15 ncopa: time to move ;-) 2024-06-19 15:13:47 yeah 2024-06-19 17:36:21 ikke: got most everything (i think) uploaded to dev.alpinelinux.org -- except for an .asc signature for one of the images -- logged in -- / is at 100% (also where /var/cache/distfiles is (presumably) bind mounted from) 2024-06-19 17:37:01 going to clean up my 3.16 dir on dev, should open up some space 2024-06-19 17:41:54 cleaned up some previous releases too. / is now at 95% 2024-06-19 18:29:15 im deleting .cache and .cargo on build-edge-x86 2024-06-19 18:29:29 I've been doing that regularly 2024-06-19 18:38:45 tomalok: yeah, that host is a bit oversubscribed, we're about to move things over to a new host though 2024-06-20 07:41:15 ikke: i have moved build-*-x86 to new host 2024-06-20 07:42:40 🎉 2024-06-20 07:43:09 I can take care of things like dev.a.o 2024-06-20 07:43:39 the lxc is named git, maybe we rename it while at it 2024-06-20 07:44:26 Right 2024-06-20 07:44:39 im moving wwwtest* now 2024-06-20 07:46:29 seems like we have some huge access.log and cgit.log files 2024-06-20 07:48:40 ikke: do you think we could reduce the DNS TTL of git-old.a.o? 2024-06-20 07:49:22 Yes, you can make an mr in the linode-tf project 2024-06-20 08:10:51 https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/merge_requests/83 2024-06-20 08:32:02 Ran the manual apply job now 2024-06-20 08:36:05 thanks 2024-06-20 13:01:55 we have moved dev.a.o to new host 2024-06-20 14:47:18 ncopa ikke - anything i should be aware of the new host before i release the new set of cloud images? 2024-06-20 14:47:45 i don't think so. it should be working as normal 2024-06-20 14:47:59 please let us know if you have any issues 2024-06-20 14:48:15 🤞 2024-06-20 14:48:32 we will probably move things around tomorrow, and restart it 2024-06-20 16:29:09 ikke: cloud image release links should be set for CDN injection 2024-06-20 16:29:49 tomalok: alrighty 2024-06-20 16:31:24 syncing now 2024-06-20 16:32:44 thx 2024-06-20 16:34:33 done 2024-06-20 17:16:53 ikke: missed the non-aws images -- will have those symlinks in place soon 2024-06-20 17:17:21 👍 2024-06-20 17:29:01 ok, all set 2024-06-20 17:30:54 running 2024-06-20 17:45:27 it's done 2024-06-20 17:49:13 thx. will sort out an update to mksite next 2024-06-20 19:08:10 ikke: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/79 2024-06-20 19:08:30 saw it 2024-06-20 19:09:30 i have some follow up items around docs/hints for various image specifics (i.e. "how do i use these?") but this MR should at least be functional (new "machine" dimension) 2024-06-20 19:18:10 tomalok: https://wwwtest.alpinelinux.org/cloud/ 2024-06-20 19:19:09 whats the difference between generic and nocloud? 2024-06-20 20:00:53 generic is for cloud-init -- it's not attached to any particular cloud so it might be able to work on the other clouds 2024-06-20 20:02:13 it leaves the "auto detect cloud" intact -- if the cloud doesn't have any special kernel boot cmdline parameters that need to be set up, might do just fine for the other clouds (or maybe some of the clouds we currently specialize for) 2024-06-20 20:04:00 ikke: wwwtest is working as expected for me 2024-06-20 20:04:14 I already pushed it to production :) 2024-06-20 20:05:21 👍 the page needs some more detailed docs somewhere -- i'm thinking maybe some kind of tab-select panels for various topics -- to answer questions like "wtf is 'generic'?" ;) 2024-06-20 20:08:33 oh nice! generic! 2024-06-20 20:10:09 ncopa: btw, I fixed the ip address references for wwwtest 2024-06-20 20:10:19 im working on auto-detect cloud provider for tiny-cloud: https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/merge_requests/109 2024-06-20 20:10:29 ikke: thank you! I forgot that 2024-06-20 20:12:29 ncopa: yep, saw that MR land, but haven't looked at it (or the other ones) 2024-06-20 20:13:10 and I intend to make a provider for incus/lxd 2024-06-20 20:13:37 someone did hetzner and one other, starts with 's' i think 2024-06-20 20:14:07 incus can read meta-data from unix socket /dev/{incus,lxd}/sock 2024-06-20 20:14:11 i saw 2024-06-20 20:14:39 tomalok: scaleway? 2024-06-20 20:14:40 does that require a kernel module being enabled? 2024-06-20 20:14:42 i should test out the hetzner. I hear hetzner provision their vms super fast 2024-06-20 20:14:52 no 2024-06-20 20:15:44 incus/lxd is system containers, so it is possible to spin up those in VMs, without doing nested vms 2024-06-20 20:15:49 which is nice for testing :) 2024-06-20 20:16:43 today i have experimented a bit with virt-install and libvirt 2024-06-20 20:17:15 using tiny-cloud for unattended installs with the vanilla iso 2024-06-21 12:08:52 ikke: https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/merge_requests/84 2024-06-21 12:26:58 im gonna restart the dev.a.o machine now to do some maintenence work 2024-06-21 12:33:17 job done 2024-06-21 12:39:47 🎉 2024-06-24 16:07:55 any idea why the ppc64le builder wouldn't be able to access /proc/self/statm? 2024-06-24 17:12:23 ptrc: no, I can read that as the buildozer user 2024-06-24 17:13:05 weird, that would mean that it reports 0 bytes of memory used when the scudo-malloc tests are running 2024-06-24 17:13:12 which is even worse somehow 2024-06-24 17:13:44 ptrc: which field is that? 2024-06-24 17:13:54 second one 2024-06-24 17:14:04 according to kernel docs and whatever scudo-malloc tries to do 2024-06-24 17:14:21 ( either 0 bytes or 0 pages, not sure ) 2024-06-24 17:17:52 yeah, it's 0 2024-06-25 18:27:34 Have some new graphs in Zabbix: https://snipboard.io/BiTkDO.jpg 2024-06-25 19:44:16 :o 2024-06-25 19:44:33 tbh the one i'd like the most is "RAM usage / CI runner" :P 2024-06-25 19:44:44 but those are really nice 2024-06-25 21:04:55 30 jobs pending now 2024-06-26 16:58:44 You are currently on version 17.0.1! We strongly recommend upgrading your GitLab installation to one of the following versions immediately: 17.1.1, 17.0.3. 2024-06-26 18:04:50 ncopa: yes, already pushed the update to gitlab 2024-06-26 18:53:28 fun fun fun, expiring tokens 2024-06-26 19:03:15 awsome :)))) 2024-06-27 10:23:10 ncopa: I'll try to move the x86_64 build containers to the new server today 2024-06-27 10:23:25 awsome! thanks! 2024-06-27 13:42:52 ncopa: for some reason, /var/cache/distfiles is owned by root:root with permissions set to 0700, even though on the host it's root:abuild and 0775, any idea what the cause of that may be? 2024-06-27 15:48:12 maybe its not mounted? 2024-06-27 15:48:17 or mounted wrong place 2024-06-27 15:51:48 I see a lost+found directory 2024-06-27 15:51:55 changing permissions does not do anything 2024-06-27 15:52:00 so _something_ is mounted 2024-06-27 15:52:35 lxc.mount.entry = /var/cache/distfiles var/cache/distfiles none bind,create=dir 0 0 2024-06-27 15:53:01 ls -ld /var/cache/distfiles/ 2024-06-27 15:53:03 drwxrwxr-x 3 root abuild 4096 Jun 27 10:37 /var/cache/distfiles/ 2024-06-27 16:04:43 where do you change permissions? 2024-06-27 16:04:51 try change them in lxc container 2024-06-27 16:05:50 That's where I tried it 2024-06-27 16:06:09 huh 2024-06-27 16:06:58 what happens if you restart the lxc container? 2024-06-27 16:07:19 i wonder if you created the container first and mounted /var/cache/distfiles on the host after lxc started? 2024-06-27 16:07:35 I did restart the container multiple times 2024-06-27 16:07:39 ok 2024-06-27 16:07:56 I have a tmux session on 185.15.220.14 2024-06-27 18:23:38 build-3-20-x86_64 is 'out to the lunch'? 2024-06-27 18:23:54 it's being moved 2024-06-27 18:29:27 ikke: thanks for info 2024-06-27 18:35:15 mps: it's back 2024-06-27 18:47:24 ikke: I see, thanks 2024-06-27 18:51:21 how can I elegantly downgrade telegram-desktop from 5.1.5 to 5.1.0? anyone can help me 2024-06-27 18:52:06 something like version=5.1.5_5.1.0? 2024-06-27 18:52:35 s/version/pkgver/ 2024-06-27 19:23:55 i guess the best would be to just pkgver=5.1.0 2024-06-27 19:24:54 fossdd: the problem is that apk will not downgrade the package 2024-06-27 19:24:57 fossdd: will not work in alpine 2024-06-27 19:25:09 (unless --available is provided) 2024-06-27 19:26:43 I don't expect that users will use "apk add telegram-desktop=5.1.0-r0" 2024-06-27 19:27:36 The should not, because that will pin it to that version unless they remove the pin again 2024-06-27 19:27:42 kinda expect users on edge to provide -ai 2024-06-27 19:28:35 I always use `apk upgrade -Ua` 2024-06-27 19:28:50 same 2024-06-27 21:22:14 ncopa: all builders have been moved to the new x86_64 host 2024-06-28 07:10:09 Hello, my MR adding new mirror has been merged 2 days ago, but it doesn't show on the mirror list https://gitlab.alpinelinux.org/alpine/infra/mirrors/-/merge_requests/10 2024-06-28 07:19:10 Ok, I'll take a look later 2024-06-28 07:37:02 ikke, actually is shows on the text file present on each mirror, but not on https://mirrors.alpinelinux.org/ 2024-06-28 08:31:25 raspbeguy: i guess container has issues 2024-06-28 08:34:14 hmm /usr/bin/lua5.3: attempt to index a nil value 2024-06-28 08:39:11 i think its missing country 2024-06-28 08:46:42 ikke: awesome! Thanks! 2024-06-28 09:55:15 ncopa: there's only a distfiles container left, but I don't think that's used anymore (distfiles is a dedicated server now) 2024-06-28 10:35:19 maybe move it over, but not start it? 2024-06-28 10:35:28 incase something breaks 2024-06-28 10:35:40 and delete it in a few weeks or so 2024-06-28 10:39:00 yup 2024-06-28 10:39:09 will do that 2024-06-28 10:53:03 Everything has been migrated now, then 2024-06-28 13:43:07 we have an build-edge-loongson64 up 2024-06-28 13:43:19 for now it uploads to dev.a.o/~loongson 2024-06-28 13:43:47 but its progress 2024-06-28 17:44:01 Do we still need a x86 builder? 2024-06-28 17:45:30 clandmeter: what do you mean? 2024-06-28 17:45:40 if we can drop x86? 2024-06-28 19:20:32 In general if we need x86_64 hardware 2024-06-28 19:21:11 We received 2 quite beefy machines for the x86_64 and x86 builders 2024-06-28 21:15:29 Ok I have one 128 core EPYC around 2024-06-29 14:03:30 clandmeter: something is preventing the 3.20/main/x86_64 packages from being updated in pkgs.a.o 2024-06-29 14:03:41 Last update was one week ago 2024-06-29 14:03:59 sorry, not just x86_64, any arch 2024-06-29 14:05:17 running it now with db debugging enabled, but I don't see any errors appearing 2024-06-29 14:06:41 Ok, not one week ago, longer ago, and I see the issue now 2024-06-29 14:44:14