2021-05-01 09:14:00 ddevault, mps: I fucked up yesterday. I now took the time to revert to the old packages and test updating to the new ones. The new trigger didn't help. For me, with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21024 I now reliably end up with working texlive - either updating or fresh install now works both for me. 2021-05-01 09:15:29 What's the idea behind "yes 2> /dev/null | updmap-sys --syncwithtrees > /dev/null 2>&1 > /dev/null"? 2021-05-01 09:16:31 I guess yes 2>/dev/null is just out of precaution? 2021-05-01 09:16:51 or does yes complain after the pipe is closed? 2021-05-01 09:47:05 in your sentence, "> /dev/null 2>&1 > /dev/null" doesn't seem to make much sense either, compared to "> /dev/null 2>&1" 2021-05-01 09:47:06 s/your sentence/that code fragment/ 2021-05-01 09:47:06 afontain_ meant to say: in that code fragment, "> /dev/null 2>&1 > /dev/null" doesn't seem to make much sense either, compared to "> /dev/null 2>&1" 2021-05-01 09:48:35 right, is redundant 2021-05-01 11:10:43 thanks for taking care of that, maribu[m], no worries 2021-05-01 12:05:10 Ikke: thanks for reporting the messages from aports-qa-bot 2021-05-01 12:06:00 np 2021-05-01 12:06:56 also it can also print pure json if it is useful, I just made it pretty-print by default 2021-05-01 12:07:10 Was thinking about pinging / assigning MRs from first time contributors to @team/mentors 2021-05-01 12:07:20 no, this is better 2021-05-01 12:07:47 I just tail the container output 2021-05-01 12:08:29 With zerolog, the output is very nice to read 2021-05-01 12:09:38 sounds good 2021-05-01 12:10:15 I'll make an issue 2021-05-01 15:10:11 o/ 2021-05-01 15:17:02 I heard that apk-tools v3.0 might switch apks to an alternative format - I'm currently building a tool that parses apks 2021-05-01 15:17:18 is there a branch or something to watch for? 2021-05-01 15:17:45 https://gitlab.alpinelinux.org/alpine/apk-tools/-/tree/v3.0-wip 2021-05-01 15:19:15 ty 2021-05-01 15:28:00 switched from an IRC client to the matrix bridge; not sure if its working >.< 2021-05-01 15:28:11 It's working 2021-05-01 15:28:30 yay, ty 2021-05-01 15:30:21 (Oxylibrium has been doing stuff to make immutable alpine distros with OSTree) 2021-05-01 15:31:41 Neat, rpm-ostree is pretty nice to use too 2021-05-01 16:08:30 any idea what could be happening here? 2021-05-01 16:08:54 it seems that it got stuck and finally was killed 2021-05-01 16:08:57 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/383510 2021-05-01 16:17:02 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/383539 2021-05-01 16:17:51 it builds fine on my x86_64 2021-05-01 16:32:42 I think the second one could be an OOM on the CI? 2021-05-01 16:33:20 uhM 2021-05-01 16:33:20 "Killed signal terminated program cc1plus" without any explanation usually only happens with an oom killer in my experience 2021-05-01 16:33:50 I could try to rebuild in my computer and monitor the memory usage 2021-05-01 16:36:18 donoban: note that the CI hosts has many cores, and $JOBS by default equals to nproc 2021-05-01 16:37:00 uhM 2021-05-01 16:38:38 should I add something like texlive/APKBUILD: export MAKEFLAGS="$MAKEFLAGS -j$((JOBS<16 ? JOBS : 16))" ? 2021-05-01 16:39:11 you could directly export JOBS 2021-05-01 16:39:17 export JOBS=... 2021-05-01 16:39:28 ok 2021-05-01 16:39:34 and it should be JOBS> 2021-05-01 16:39:34 16 is a good limit? 2021-05-01 16:39:37 JOBS>16 2021-05-01 16:41:36 First you have to determine if that's the actual issue 2021-05-01 16:42:16 I don't see any other APKBUILD using "export JOBS" except opendjk 2021-05-01 16:44:02 yes, generally it's not an issue 2021-05-01 16:44:09 uhM 2021-05-01 16:44:37 in this log https://gitlab.alpinelinux.org/donoban/aports/-/jobs/383509 , it has also g++: fatal error: Killed signal terminated program cc1plus 2021-05-01 16:44:45 but in tg_owt build instead 2021-05-01 16:45:06 I'd wager that's also an out-of-memory kill 2021-05-01 16:46:18 tg_owt is exactly the same, I only upgraded telegram-desktop 2021-05-01 16:47:05 what arches? 2021-05-01 16:47:26 x86_64, armv7 and aarch64 2021-05-01 16:47:30 the other are disabled 2021-05-01 19:31:51 ikke: are you around? I tested !21021 and run it locally. with "lxc.cap.drop = sys_admin" works 2021-05-01 19:32:03 mps: I'm here 2021-05-01 19:32:08 I think we can merge it 2021-05-01 19:32:40 agree? 2021-05-01 19:32:49 0yes 2021-05-01 19:32:56 ok 2021-05-01 19:34:24 done, thanks for review 2021-05-01 19:34:33 I already approved the MR :) 2021-05-01 19:34:47 I saw :) 2021-05-01 22:27:16 ikke: I retried some jobs for see if something different happens 2021-05-01 22:28:55 first aarc64 failed at 82%, and last at 86% 2021-05-01 22:29:41 so it seems not determistic problem 2021-05-02 06:59:04 is there a metapackage to pull in all the 'standard' php packages? 2021-05-02 07:05:55 What do you consider standard php packages? 2021-05-02 07:08:05 afaik there is no default set of extensions 2021-05-02 07:10:27 i'm not sure. :-p 2021-05-02 07:11:41 i dont think there is one, and lots of projects dont mention what they actually need to properly run 2021-05-02 07:11:42 at least cgi, json, xml, curl, mysqli, probably some others 2021-05-02 07:12:02 something like "what you need to run a typical wordpress site" 2021-05-02 07:19:41 dalias: you could take a look at drupal7 pkg 2021-05-02 07:26:39 dalias: as you probably know creating metapackage on alpine is easy 2021-05-02 07:27:20 i was just wondering if one existed 2021-05-02 07:41:13 clandmeter, apk info -R drupal7 is probably a good list :) 2021-05-02 07:41:53 nod 2021-05-02 07:42:22 dalias: probably want to talk about this with andypost[m], which maintains the php packages 2021-05-02 07:44:51 im not sure how other distros manage the main php7 pkg, and if they pull in a lot of default ones. andypost[m] probably knows best. 2021-05-02 08:02:58 dalias: there was intend to add php7-bundled but it was lost 2021-05-02 08:03:54 This set is changing https://www.php.net/manual/en/extensions.membership.php 2021-05-02 09:27:34 armhf builder is unstuck again 2021-05-02 09:36:09 Linus saying shared libraries are a bad idea: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/ 2021-05-02 09:41:13 I agree with him, especially since LTO is more effective when combined with static linking 2021-05-02 09:45:14 Security wise it's dynamic linking is preferred, though 2021-05-02 09:48:27 black and white POV 2021-05-02 10:33:35 You mean since you can upgrade them easier? 2021-05-02 10:34:19 yes 2021-05-02 10:43:49 so telegram guys are right :D 2021-05-02 10:44:54 They take it to the extreme though 2021-05-02 10:45:41 Newbyte: I don't know why CI fails while it buidls fine on my computer 2021-05-02 10:46:04 Telegram moment 2021-05-02 10:46:06 it seems some OOM problem 2021-05-02 10:46:15 Link? 2021-05-02 10:46:21 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/383575 2021-05-02 10:46:37 see [ 86%] Building C object CMakeFiles/tg_owt.dir/src/common_audio/vad/vad_gmm.c.o 2021-05-02 10:46:39 g++: fatal error: Killed signal terminated program cc1plus 2021-05-02 10:47:00 other try failed at 82%, and this is tg_owt which is not modified 2021-05-02 10:47:07 I only modified telegram_desktop 2021-05-02 10:47:38 aarch64 seems to fail on not finding some header? 2021-05-02 10:47:41 I don't see OOM messages on the aarch64 ci host 2021-05-02 10:47:46 o 2021-05-02 10:48:00 uhM thanks ikke 2021-05-02 10:48:01 x86_64 fails because it timed out 2021-05-02 10:48:38 but it had the "Killed signal" message long time before failing due timed out 2021-05-02 10:49:50 on x86: traps: lt-distance[39124] general protection fault ip:f7ee4756 sp:ffddded4 error:0 in ld-musl-i386.so.1[f7ed3000+4e000] 2021-05-02 10:49:55 not sure if that's related to telegram 2021-05-02 10:50:11 on x86 telegram is disabled 2021-05-02 10:50:16 ok 2021-05-02 10:50:33 it lacks some depedency 2021-05-02 10:51:34 No messages in dmesg 2021-05-02 10:51:51 on the ci hosts 2021-05-02 10:52:10 do you know other causes for g++: fatal error: Killed signal terminated program cc1plus ? 2021-05-02 10:52:46 CI timeout 2021-05-02 10:53:22 uhM, it happened at 9mins aprox with 1h limit 2021-05-02 10:54:11 on aarch64, it's a different error 2021-05-02 10:54:22 and after failing to build tg_owt, it tried to build telegram_desktop 2021-05-02 10:54:26 ../Telegram/ThirdParty/tgcalls/tgcalls/group/StreamingPart.cpp:378:13: error: 'RTC_FATAL' was not declared in this scope 2021-05-02 10:54:35 yeah, that happened because tg_owt failed 2021-05-02 10:54:39 ok 2021-05-02 10:54:40 and it installed an older tg_owt version 2021-05-02 10:55:32 I guess that if the timeout was triggered in some way, it wouldn't tried to build telegram 2021-05-02 10:56:08 no 2021-05-02 10:57:07 what could I try? limit the JOBS? 2021-05-02 10:57:58 I'm testing it manually inside docker on the host 2021-05-02 10:58:23 ok 2021-05-02 10:59:14 maybe CI contianers have some memory limit which doesn't reports OOM on dmesg? 2021-05-02 10:59:46 64G sounds quite limited, indeed 2021-05-02 10:59:53 lool 2021-05-02 11:00:06 yeah I built it with only 32 :) 2021-05-02 11:04:40 ../Telegram/ThirdParty/tgcalls/tgcalls/group/GroupNetworkManager.h:14:10: fatal error: pc/sctp_data_channel.h: No such file or directory 2021-05-02 11:04:56 on x86_64 2021-05-02 11:05:03 this sounds a wrong tg_owt 2021-05-02 11:05:12 ah, I first need to build that 2021-05-02 11:05:20 yes 2021-05-02 11:06:40 hmm, strange 2021-05-02 11:07:02 what happens? 2021-05-02 11:07:11 it builds :P 2021-05-02 11:07:17 hehe 2021-05-02 11:07:21 whole telegram-desktop? 2021-05-02 11:07:29 no 2021-05-02 11:07:34 first tg_owt 2021-05-02 11:07:53 well in x86_64 the tg_owt was successful 2021-05-02 11:08:57 building tg-desktop now 2021-05-02 11:09:03 :D 2021-05-02 11:09:14 are you using same host than gitlab CI? 2021-05-02 11:09:42 yes 2021-05-02 11:09:47 exact same hosts 2021-05-02 11:10:06 ok, let's see what happens 2021-05-02 11:10:26 in CI it got stuck at job [904/905] Building CXX object Telegram/CMakeFiles/Telegram.dir/Telegram_autogen/mocs_compilation.cpp.o 2021-05-02 11:10:33 ok 2021-05-02 11:11:05 doing the same one aarch64 2021-05-02 11:11:15 ok 2021-05-02 11:12:21 seems to be hanging now 2021-05-02 11:13:04 :\ 2021-05-02 11:14:12 and finisehd 2021-05-02 11:14:17 succcess? 2021-05-02 11:14:28 q>>> telegram-desktop: Signing the index... 2021-05-02 11:14:33 :| 2021-05-02 11:15:08 try to retry my failed job? 2021-05-02 11:15:52 rerunning it 2021-05-02 11:16:40 ok 2021-05-02 11:21:47 it reached the "problematic" point 2021-05-02 11:32:36 it seems totally stuck there :\ 2021-05-02 11:33:07 Ariadne: Do we have a deadline for AlpineConf talk video submissions? 2021-05-02 12:16:43 /run scriptassist 2021-05-02 12:17:46 oh looks like it accidentally posted the command dont mind sorry 2021-05-02 12:22:41 donoban: the entire host is frozen 2021-05-02 15:08:06 Cogitri: try to get it done by end of week :p 2021-05-02 15:14:47 Okie 👍 2021-05-02 15:20:20 andypost[m], thanks. 2021-05-02 15:20:31 andypost[m], is that still intended to happen at some point? 2021-05-02 16:02:19 dalias, I see no much reasons for it, most of dependent apps anyway needs own set of extensions 2021-05-02 18:04:09 uHM 2021-05-02 18:04:55 ikke: that sounds bad 2021-05-02 18:05:20 Might be a different issue 2021-05-02 18:05:35 It's responding 2021-05-02 18:06:19 the build failed with g++: fatal error: Killed signal terminated program cc1plus but in this case it could be just CI timeouting 2021-05-03 05:52:48 it sounds like oom 2021-05-03 05:53:31 no oom messages in dmesg though 2021-05-03 06:38:53 ikke: could the CI runners have a userspace oomd set up? 2021-05-03 06:39:02 No 2021-05-03 06:39:11 i know there's stuff like earlyoom/systemd-oomd 2021-05-03 06:39:18 ah, hmm - that's strange then 2021-05-03 06:39:24 We don't have that setup 2021-05-03 06:40:03 is there a way to set up the same versions of all packages as CI to run locally? 2021-05-03 06:40:10 admittedly I'm fairly new to alpine stuff 2021-05-03 06:41:51 alpinelinux/build-base, or alpinelinux/alpine-gitlab-ci docker images 2021-05-03 06:42:49 how much ram does the armv7 builder have, anyway? 2021-05-03 06:43:26 512GB I think 2021-05-03 08:44:53 !21068 <- Adds two upstream patches to main/file, maybe someone wants to take a look at the MR before I merge it 2021-05-03 13:11:05 just pushed new mainline stable kernel upgrade from 5.11 to 5.12, linux-edge, for those who need it or want to test it 2021-05-03 13:12:16 interesting new options are idmap mounting, preempt 'model' select on boot and some other 'new and shinny' things 2021-05-03 15:16:21 anyone who's interested, there's an #alpine-cloud channel now 2021-05-03 15:16:54 it's probably going to be pretty quiet since all the cloud maintainers are in PST but I'll be in there as often as possible 2021-05-03 16:22:45 http://linuxgizmos.com/risc-v-to-hand-out-1000-free-risc-v-dev-boards/ 👀 2021-05-03 16:24:33 interesting 2021-05-03 16:51:54 yes, interesting and I'm interested :) 2021-05-03 16:52:20 will they give retina display with them 2021-05-03 16:53:41 what's with my nick, net outage 2021-05-03 16:54:40 oh, and rejoined to all left channels :) 2021-05-03 17:01:27 maybe alpine should apply as an org 2021-05-03 17:01:39 maybe they will give you more than 1 board 2021-05-03 17:01:58 one for ci, one for repo builder 2021-05-03 17:04:31 That'd be nice 2021-05-03 17:06:06 I would buy one right now if I know where and how 2021-05-03 17:14:32 mps: https://www.sifive.com/boards/hifive-unmatched 2021-05-03 17:14:33 or ebay 2021-05-03 17:25:11 I can't buy it on on-line services 2021-05-03 18:21:54 what's a good example APKBUILD in aports for packaging a rust app? 2021-05-03 18:22:27 the APKBUILD example page on the wiki doesn't have anything for rust 2021-05-03 18:22:36 maybe have a look at ripgrep 2021-05-03 18:23:01 dunno if it is a good example, but it certainly is a rust app 2021-05-03 18:24:24 ah good idea, thanks 2021-05-03 18:24:33 bat as well 2021-05-03 18:24:52 ffsend is simple too 2021-05-03 18:24:54 Or use newapkbuild :) 2021-05-03 18:26:13 oh newapkbuild supports rust now? 2021-05-03 18:26:38 nice 2021-05-03 18:27:55 I added support for it some time ago, not sure what release it's in 2021-05-03 18:30:47 heh is this a typo in the -h for newapkbuild, or is 'crate' the verb for create a rust package: '-r Crate rust package' 2021-05-03 18:31:10 the previous options, e.g. for python, etc say "Create xzy package" 2021-05-03 18:32:40 Yeah, sounds like a type 2021-05-03 18:33:40 Whoops :D 2021-05-03 18:34:14 when all you have is rust, everything looks like a crate :P 2021-05-03 18:34:20 haha 2021-05-03 19:03:35 donoban: How's the progress with tdesktop going? 2021-05-03 19:56:26 donoban: Not sure if related, but I did get oom on the aarch64 ci host 2021-05-03 20:19:00 hi 2021-05-03 20:19:14 ikke: building tdesktop or other thing? 2021-05-03 20:19:42 don't know 2021-05-03 20:20:40 caskd: I upgraded it to 2.7.4 , disabled a weird gtk integration that upstream added, it builds fine on my computer but fails on an strange way on CI build 2021-05-03 20:21:20 hmm 2021-05-03 20:21:27 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/383575 2021-05-03 20:21:36 i have managed to make apk pull the 2.7.1 from the artifacts 2021-05-03 20:21:52 look line 1586 2021-05-03 20:22:15 tg_owt fails due "g++: fatal error: Killed signal terminated program cc1plus" 2021-05-03 20:22:22 that one works well enough and i think you should probably push this if it takes long to fix the 2.7.4 problem 2021-05-03 20:22:24 but it wasn't changed from last sucess build 2021-05-03 20:22:33 donoban: that is probably due to oom 2021-05-03 20:22:48 but ikke tried to manually build it, and it worked 2021-05-03 20:22:56 hmm 2021-05-03 20:23:02 I don't sure what he did different to the std CI build 2021-05-03 20:23:35 I can rever to 2.7.1 version to see if works 2021-05-03 20:23:57 i am using that right now and works fine 2021-05-03 20:23:57 caskd: did you build 2.7.1 on your computer? 2021-05-03 20:24:06 nah, used the CI artifacts 2021-05-03 20:24:13 so the build result of the CI 2021-05-03 20:24:16 could you try to build 2.7.4? 2021-05-03 20:24:23 sure 2021-05-03 20:25:19 I supposed that there was some problem with the CI builders unrelated to tdesktop, but I don't see other people complaiing about it 2021-05-03 20:26:30 that error is common when the CI runs out of resources 2021-05-03 20:26:51 that's usually the kernel or the OOM killer stopping the build process 2021-05-03 20:27:29 yeah, but ikke looked at it and he didn't found the exact problem 2021-05-03 20:27:34 i'm gonna have to build tg_owt as well 2021-05-03 20:27:49 caskd: didn't saw any oom message at the time 2021-05-03 20:27:51 yes first update tg_owt or tdesktop will fail due missing headers 2021-05-03 20:29:14 ey caskd how do you retry to build from the CI artefacts? 2021-05-03 20:29:37 you just go to the pipeline and click the check 2021-05-03 20:29:44 and then click the arrow loop 2021-05-03 20:29:48 that will retry it 2021-05-03 20:29:59 but if it runs out of resources, retrying won't help a lot 2021-05-03 20:30:14 uhM but did you change it to 2.7.1? 2021-05-03 20:30:45 oh wait, i misread 2021-05-03 20:30:53 i didn't rebuild 2021-05-03 20:30:59 the artifacts are the results of the build 2021-05-03 20:31:07 so the binary and shared object(s) 2021-05-03 20:32:31 ah I see 2021-05-03 20:37:14 Can I get eyes on this merge request next time someone gets the chance: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21023 2021-05-03 20:37:45 The maven unit tests are timing out on the armv7 and s390x pipelines because they take so long lol, not sure what to do about that 2021-05-03 20:42:49 Dadrophenia: I've increased the timeout to 2h 2021-05-03 20:43:19 Any idea why it's taking so long? 2021-05-03 20:45:43 donoban: oh my god, telegram uses so much memory it takes 12+GB on 2 jobs 2021-05-03 20:46:07 did you even manage to build it locally? 2021-05-03 20:46:23 ah nvm, forgot ninja ignores jobs 2021-05-03 20:46:28 damnit 2021-05-03 20:51:39 use samurai 2021-05-03 20:51:58 although, you still need SAMUFLAGS 2021-05-03 20:52:18 export SAMUFLAGS=-j$JOBS 2021-05-03 20:56:46 uhM 2021-05-03 20:57:23 maribu[m]: https://security.alpinelinux.org/vuln/CVE-2021-3420 2021-05-03 20:58:17 yes I built it locally before pushing 2021-05-03 20:58:56 export JOBS=1 2021-05-03 20:58:57 export SAMUFLAGS=-j$JOBS 2021-05-03 20:59:02 this? 2021-05-03 20:59:33 yes 2021-05-03 20:59:42 that's usually done in /etc/abuild.conf 2021-05-03 20:59:52 not in the APKBUILD 2021-05-03 21:00:48 uhM, but I'm trying to fix it on CI 2021-05-03 21:00:57 in my computer it worked at least last time I've tried 2021-05-03 21:01:25 localhost:~/aports/community/tg_owt$ apk info telegram-desktop 2021-05-03 21:01:27 telegram-desktop-2.7.4-r0 description: 2021-05-03 21:01:59 should I try to force JOBS=1 in gitlab? 2021-05-03 21:02:27 donoban: You can try to see if it fixes it 2021-05-03 21:02:54 donoban: it build successfully 2021-05-03 21:03:17 builds*, i can try a rootbld as well 2021-05-03 21:03:27 to see if there's any makedeps missing 2021-05-03 21:12:56 ok 2021-05-03 21:13:10 let's try 2021-05-03 21:22:02 it failed 2021-05-03 21:22:23 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/384857#L1563 2021-05-03 21:25:59 @ikke thank you. I'm not sure why the tests are really time consuming. I don't have much experience with maven so not sure how normal it is. It builds a lot quicker locally (less than 10 minutes I believe). 2021-05-03 21:27:08 donoban: it built fine with makedeps as well 2021-05-03 21:27:26 the only thing i can suspect making the build fail is resources at this point 2021-05-03 21:28:23 x86_64 btw in case if that's unclear 2021-05-03 21:30:31 I don't know if the JOBS limit worked, could you check it with the build log? 2021-05-03 21:31:49 the job is still pending 2021-05-03 21:32:19 also this is exactly the problem i had 2021-05-03 21:32:42 use the solution ikke recommended earlier 2021-05-03 21:32:43 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/384857#L1563 2021-05-03 21:32:45 this failed 2021-05-03 21:32:51 that's what I tried 2021-05-03 21:33:19 you used JOBS 2021-05-03 21:33:27 I used this: 2021-05-03 21:33:28 ninja doesn't use that variable 2021-05-03 21:33:37 22:58 export JOBS=1 2021-05-03 21:33:38 22:58 export SAMUFLAGS=-j$JOBS 2021-05-03 21:33:54 i don't see that in the commit though 2021-05-03 21:34:11 uhmm... 2021-05-03 21:34:17 https://gitlab.alpinelinux.org/donoban/aports/-/blob/eb257ad62cf9fa4091317bd53907052f2ac3f053/community/telegram-desktop/APKBUILD#L67 2021-05-03 21:34:50 LOL 2021-05-03 21:34:58 i did 2021-05-03 21:35:06 git commit --amend 2021-05-03 21:35:12 but without -a 2021-05-03 21:35:18 I commit nothing :\ 2021-05-03 21:35:23 classic 2021-05-03 21:35:37 :) 2021-05-03 21:35:47 we all mess up git sometime 2021-05-03 21:36:13 it's a big tool which takes a bit to get used to 2021-05-03 21:36:47 hehe I need an #alpinelinux-git :D 2021-05-03 21:41:03 it failed again 2021-05-03 21:41:13 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/384887#L1631 2021-05-03 21:41:21 90% this time 2021-05-03 21:41:26 maybe with JOBS=0 works :D 2021-05-03 21:42:04 wth. 2021-05-03 21:42:30 that got futher 2021-05-03 21:42:31 so yes 2021-05-03 21:42:38 probably resources as i mentioned 2021-05-03 21:44:26 see the end of the log https://gitlab.alpinelinux.org/donoban/aports/-/jobs/384887 2021-05-03 21:44:59 if some job failed, should it stop at that moment? 2021-05-03 21:45:31 I feel that it didn't limit them 2021-05-03 22:03:26 that is 2021-05-03 22:03:29 odd.... 2021-05-03 22:03:46 it's unlikely the build system kills the compiler 2021-05-03 22:04:14 but do you think that the job limit worked? 2021-05-03 22:05:31 if it got further then likely yes 2021-05-03 22:05:49 unless the progress cannot be replicated 2021-05-03 22:06:11 at which point not a lot can be done 2021-05-03 22:07:06 I don't undestand why are so many errors after first g++ killed 2021-05-03 22:07:23 those are the other jobs maybe?? 2021-05-03 22:07:32 is it a even count? 2021-05-03 22:07:39 uhM 2021-05-03 22:07:52 maybe 22 count 2021-05-03 22:07:58 maybe the limit didn't work then 2021-05-03 22:08:05 ^^' 2021-05-03 22:08:45 maybe adding MAKEFLAGS? 2021-05-03 22:09:05 only works with plain make 2021-05-03 22:09:36 together with cmake* 2021-05-03 22:10:41 ok 2021-05-03 22:13:39 https://www.scivision.dev/cmake-ninja-job-pool-limited-memory/ 2021-05-03 22:33:38 caskd: I think that export CMAKE_BUILD_PARALLEL_LEVEL=1 did the trick 2021-05-03 22:33:50 tg_owt doesn't use ninja really 2021-05-03 22:34:08 well I pushed again but I go to sleep, see you tomorrow 2021-05-03 22:55:11 ikke so the s390x pipeline finished just in time (only 10 minutes to spare) but the armv7 pipeline didn't even get to the tests... 2021-05-03 22:55:32 I think the build step takes a long-ish time because it has to download lots of artifacts from the maven repos 2021-05-03 22:55:57 the whole process only takes like 6 minutes on the x86_64 arch 2021-05-04 04:33:40 Dadrophenia: strange that it takes so long 2021-05-04 05:49:12 Ariadne: Thanks, I'll MR an upgrade as soon as possible 2021-05-04 06:06:34 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21086 2021-05-04 07:15:37 something is strange with new arm builder. it failed on tests for 'ell' upgrade last night while ell build pass on CIs and on my local machine 2021-05-04 07:15:58 but failed tests on builder and my lxcs there 2021-05-04 07:16:35 lxc setup there or kernel/hardware problem? 2021-05-04 07:48:26 the alpine boost packages source is now a 403 forbidden https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/boost1.76/APKBUILD 2021-05-04 07:49:21 ping ncopa I guess 2021-05-04 08:03:51 afontain_: they should be still on distfiles 2021-05-04 08:04:18 I don't really need it right now tbh 2021-05-04 08:04:24 just so you know 2021-05-04 08:26:42 hi 2021-05-04 08:40:13 morning 2021-05-04 09:56:34 hello 2021-05-04 09:59:33 o/ 2021-05-04 10:07:02 so there are problems with CI builers? My last attempt limitedo to 1 job failed due CI timeout but I don't see the g++ killed message 2021-05-04 10:07:35 s/limitedo/limited 2021-05-04 10:07:35 donoban meant to say: so there are problems with CI builers? My last attempt limited to 1 job failed due CI timeout but I don't see the g++ killed message 2021-05-04 10:49:11 ikke: caskd , with 8jobs limit x86_64 success, aarch64 builds tg_owt but fails tdesktop (exactly 8 g++: fatal error: Killed signal terminated program cc1plus messages) 2021-05-04 10:50:48 armv7 builds tg_owt but fails tdesktop due undefined symbols on linkage 2021-05-04 10:51:13 It's trange that I cannot reproduce it under nearly identical circumstances 2021-05-04 10:51:18 strange* 2021-05-04 10:52:30 do you use same container/image than CI builder? 2021-05-04 10:52:42 maybe there are some resources quota by user? 2021-05-04 10:53:08 or did you run it with the same user? 2021-05-04 10:55:09 the servers where they run on are pretty bare, no fancy limits or anything 2021-05-04 10:57:20 donoban: I used alpinelinux/build-base 2021-05-04 10:57:39 On CI, it uses alpinelinux/alpine-gitlab-ci, which uses build-base, and adds some scripts on top 2021-05-04 10:58:07 uhm 2021-05-04 10:58:35 could you try to reproduce with it? 2021-05-04 10:58:51 ikke: as I wrote above CIs and builders don't behave same 2021-05-04 10:59:13 mps: this is CI through gitlab-runner vs CS run manually 2021-05-04 10:59:20 s/CS/CI/ 2021-05-04 10:59:20 ikke meant to say: mps: this is CI through gitlab-runner vs CI run manually 2021-05-04 10:59:23 aha, ok 2021-05-04 11:01:15 it seems that there is some RAM limit hidden somwhere 2021-05-04 11:01:45 when I tried with JOBS=1 it failed due CI timeout and there were no killed signal messages 2021-05-04 11:03:10 32bit arches are 'limited' to 4GB ram by their addressing 2021-05-04 11:03:35 well it failed on all archs 2021-05-04 11:03:40 This is all 64 bits 2021-05-04 11:03:53 now with JOBS=8 it builds on x86_64 but fails on aarch64 2021-05-04 11:06:06 x86_64 ci host is now pretty hammered 2021-05-04 12:19:29 pretty irresponsible to get hammered when you have so much work to do 2021-05-04 12:20:09 Lol 2021-05-04 12:41:58 https://thephilbert.io/2021/05/03/gcc-rust-monthly-report-5-april-2021/ seems like gcc-rust is progressing nicely 2021-05-04 13:08:16 nice 2021-05-04 14:19:53 hey, can someone inform me what policy does alpine follow when it comes to repository signing key rotation 2021-05-04 15:16:06 jmercan: there are currently no policy when it comes to key rotation, but I think there are some work done to fix it, or at least make it possible to fix, with apk3 2021-05-04 15:16:39 current package signing and repository signing is very simple 2021-05-04 15:20:01 thank you 2021-05-04 16:31:29 !17066 2021-05-04 16:32:01 anyone knows whats with TBK? 2021-05-04 16:32:08 no idea 2021-05-04 16:33:41 I would merge this MR, is that ok? 2021-05-04 16:34:28 actually I made some time ago same apk and use it on my router 2021-05-04 16:35:03 but didn't merged it, didn't know is it interesting for wider 'audience' 2021-05-04 20:29:14 hi 2021-05-04 20:35:56 Ariadne: is there an ETA for Alpine 3.14? 2021-05-04 21:07:34 when its done 2021-05-04 21:07:45 right now our PPC64 builder is MIA 2021-05-04 21:07:47 sooooo 2021-05-04 21:07:52 that kinda is a blocker :P 2021-05-04 21:09:56 Oh yeah ouch lol 2021-05-05 03:56:49 Hello, Where is setup-alpine located inside the iso? 2021-05-05 04:35:11 CAPTCHA_REQUIRED: it's part of the alpine-conf package 2021-05-05 04:35:35 Thanks 2021-05-05 07:36:06 Why does Alpine ship with two bootloaders, isolinux for BIOS boot and grub2 for uefi? 2021-05-05 07:36:21 Both of those bootloaders seem capable of booting both uefi and bios 2021-05-05 07:40:31 syslinux is not quite good on some machines 2021-05-05 07:41:16 on some works fine in uefi mode but on some it is somewhat buggy/unstable 2021-05-05 07:55:52 Do you know which machines? 2021-05-05 07:55:56 Or is it random 2021-05-05 07:56:08 Is it syslinux's or buggy firmware's fault 2021-05-05 07:59:43 on my old macbook pro booting with syslinux is unstable, i.e. more times it hangs than it boots, while with grub it boots always 2021-05-05 08:00:43 Thanks 2021-05-05 08:01:50 I prefer syslinux but at this case I switched to grub (till I find time to try to find why syslinux fails) 2021-05-05 08:02:52 syslinux was also unstable on my x220 2021-05-05 08:03:56 Thankyou 2021-05-05 08:04:18 i wish there was an option for a saner bootloader because i personally don't like grub 2021-05-05 08:05:45 Alpine 3.14 is a bit too early for me, Plasma 5.22 is to be released soon but will just miss the boat/ Either that or Plasma is too late 😜 2021-05-05 08:16:13 I might just get it in after it's released. Would be a shame to miss it when the release dates are so close together, but just the wrong way round 2021-05-05 08:18:50 if alpine waits for 'new and shinny' important software releases or those 'nice to have new' then it will be never released 2021-05-05 08:19:00 I know 😉 2021-05-05 08:19:07 I wasn't saying Alpine should wait with it's release 2021-05-05 08:19:23 there is always edge :^) 2021-05-05 08:19:32 edge is always 'released' 2021-05-05 08:19:37 which is amazingly stable anyway 2021-05-05 08:19:37 heh, yes 2021-05-05 08:20:05 jmercan: except when it breaks 2021-05-05 08:20:55 running edge helps the stable people 2021-05-05 08:21:08 the more people run edge, the more bugs are found before stable 2021-05-05 08:21:18 if no one would run it then stable would have no meaning 2021-05-05 08:21:54 that and thanks to my luck i encounter more breakage over time when bumping releases than to use rolling systems 2021-05-05 08:22:28 yeah 2021-05-05 08:22:51 i have had more cases where i have broken my system myself rather than upstream doing it 2021-05-05 09:56:35 it annoys me that i am not able to reproduce the abuild fetch race 2021-05-05 09:57:24 Hmm anoying, indeed 2021-05-05 10:00:42 We concluded it was bacause of different namespaces, right? 2021-05-05 10:01:22 thats what i thought, but with the recent change, using flock() it should be bound to the inode, not the pid, so it should work across namespaces 2021-05-05 10:01:49 Is it still happening? 2021-05-05 10:01:55 yes 2021-05-05 10:02:00 it happened today 2021-05-05 10:02:01 with mutt 2021-05-05 10:02:11 abuild 3.8.0_rc1 2021-05-05 10:02:22 with the flock fix 2021-05-05 10:02:33 Hmm, ok.. 2021-05-05 10:07:21 im running it here in docker, and the locking appears to work as expected 2021-05-05 10:09:05 but something is weird. it tries to download from distfiles mirror, which returns 404, then downloads from upstream, using the .parts file - which indicates soemthing else is downloading at the same time, and then finally it tries to download from distfiles mirror again? 2021-05-05 10:09:08 https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10026#note_156476 2021-05-05 10:33:20 ikke: have we ever seen the problem on 64 bit lxcs? 2021-05-05 10:33:58 I think I've seen it on aarch64, but not sure 2021-05-05 10:36:24 ncopa: https://tpaste.us/Lw50 2021-05-05 11:10:28 linux-rpi on armv7 fails due to patches on applying 2021-05-05 11:13:54 Raspberry pis aren't real 2021-05-05 11:14:01 Problem solved 2021-05-05 11:25:01 hum. im ust have messed something up with rpi 2021-05-05 11:25:26 and i think i might have reproduced the abuild-fetch locking issue 2021-05-05 13:43:49 i know what the abuild-fetch locking problem is now 2021-05-05 13:47:54 \o/ 2021-05-05 13:48:46 Nice! 2021-05-05 13:49:12 Don't leave us hanging :-) 2021-05-05 13:49:32 its just me who is stupid :) 2021-05-05 13:49:35 \o/ 2021-05-05 13:49:38 \o/ 2021-05-05 13:51:12 so what happens is: 1) host A creates the lockfile and locks it 2021-05-05 13:51:24 2) host A downloads utl 2021-05-05 13:51:31 s/utl/url/ 2021-05-05 13:51:31 ncopa meant to say: 2) host A downloads url 2021-05-05 13:52:06 3) host B tries to lock the file but gets blocked 2021-05-05 13:52:20 (at that point the lockfile is open) 2021-05-05 13:53:18 4) host A gets 404 from distfiles mirrors, deletes the lockfile and exits 2021-05-05 13:53:40 5) host B gets the lock and downloads the url 2021-05-05 13:54:38 6) host A tries download same file from upstream, instead of distfiles mirror. but the lockfile was deleted in step 4, so it creates a new lockfile and gets the lock 2021-05-05 13:55:03 meanwhile host B holds the lock of the old, deleted lockfile 2021-05-05 13:55:12 so they both tries to download same file 2021-05-05 13:55:17 at the same time 2021-05-05 13:55:57 but should B not also get a 404? 2021-05-05 13:56:25 possibly, maybe it already got 404 and is on the retry on the upstream 2021-05-05 13:56:45 i was able to reproduce it my disabling distfiles mirror on one host 2021-05-05 13:59:49 the problem is that the lockfile is deleted by host A when host B has a lock 2021-05-05 14:00:08 it still has the fd open 2021-05-05 14:01:10 but once B has the lock, how can A obtain it? 2021-05-05 14:01:17 hmm, how host succeed in locking if host B already did it 2021-05-05 14:01:27 heh 2021-05-05 14:05:27 what text should I use for a mailmap update commit? 2021-05-05 14:09:03 mps: host A deletes the lockfile and releases the lock in step 4 2021-05-05 14:09:52 lock is associated with inode, not filename (as i understand) 2021-05-05 14:10:00 right 2021-05-05 14:10:10 that's 1, and 2 is you can delete a file while it's locked 2021-05-05 14:10:15 With an FD actually 2021-05-05 14:10:42 ikke: once B has the lock (step 5), host A deletes it. on the second try the lockfile host B holds is deleted and host A creats a new lockfile 2021-05-05 14:11:11 yes, I understand it now 2021-05-05 14:11:21 there are two ways to solve it 2021-05-05 14:11:39 well, i have two suggestions at least 2021-05-05 14:12:00 option 1) only delete the lockfile on successful download 2021-05-05 14:12:17 which means the lockfile remains on 404 2021-05-05 14:12:23 is not deleted 2021-05-05 14:14:00 option 2) instead of deleting the file before releasing the lock, first release the lock, then fence the file deletion with a new lock 2021-05-05 14:14:38 which means host A would get blocked when trying to delete the lockfile 2021-05-05 14:16:09 but um.. that might not be the bets option 2021-05-05 14:17:09 i think the way to go is: only delete lockfile if either successful download or there is nothing else locking it 2021-05-05 14:34:26 i think you need to hold the lock while deleting it 2021-05-05 14:34:50 you could also trylock, and if it fails, assume the other guy will delete it when they're done 2021-05-05 14:34:58 yeah 2021-05-05 14:36:15 Still possible race condition, but that would at most leave you with a partial file 2021-05-05 14:38:26 the option 2 woudl be: 1) open file, 2) accuire lock, 3) fetch file, 4) release lock (but keep file open), 5) accuire a new lock, 6) delete file, 7) close lockfile. 2021-05-05 14:39:53 on step 4 in that, host B would accuire the lock so the deletion of the file wouldnt happen until the lock is released 2021-05-05 14:40:05 but i still think its racy 2021-05-05 14:42:00 host B could still open file between 5 and 6 2021-05-05 14:42:23 so i think trylock is the way to go 2021-05-05 14:42:57 but first im gonna make a proper testcase in the testsuite 2021-05-05 14:43:54 what about not deleting lockfile at all 2021-05-05 14:44:05 just lock/unlock 2021-05-05 14:44:29 that was my option 1. only delete lockfile on successful download 2021-05-05 14:45:17 but it also means that we might end up with lockfile leftovers for things like misspelled urls and similar 2021-05-05 14:45:31 true 2021-05-05 14:46:05 so i think the poper way is: if (success || trylock(fd)) unlink(lockfile); 2021-05-05 14:46:17 some cron job to scan and delete leftowers after some time :) 2021-05-05 14:46:34 periodically 2021-05-05 14:47:10 yes, don't delete if can't get lock 2021-05-05 14:47:29 delete if successful or if no-one else has the lock 2021-05-05 14:47:30 is that on NFS fs 2021-05-05 14:47:56 i learned that there are 4 different ways to do file locking :) 2021-05-05 14:48:33 yes, and probably more of them around but we don't know about all of them 2021-05-05 14:49:32 bsd locks, (flock), posix lockf, posix record lock (fcntl), linux open file descriptor locks 2021-05-05 14:49:41 https://gavv.github.io/articles/file-locks/ 2021-05-05 14:49:46 but yes, your idea to not delete if can't get lock sounds good 2021-05-05 15:00:18 I like to use redis for contention problem, strange yes, but mostly works 2021-05-05 15:00:49 and there is something with so called 'raft' method 2021-05-05 15:01:03 mps: it's not nfs, btw 2021-05-05 15:06:57 but i want it to be nfs safe 2021-05-05 15:07:36 Nod 2021-05-05 15:08:36 ok, i think i have the testcase working now 2021-05-05 15:10:26 Testcase = good 2021-05-05 15:10:50 imho, its the only way to make sure that problem is actually fixed 2021-05-05 15:12:21 And not regress in the future 2021-05-05 15:16:12 exactly. otherwise its superscary to refactor it 2021-05-05 15:16:17 i intend to simplify it a bit 2021-05-05 15:17:13 I'll work on getting the pipeline setup 2021-05-05 16:27:55 drats... lockf does not work as expected 2021-05-05 17:07:22 https://lwn.net/Articles/853712/ fwiw 2021-05-05 17:08:12 subscription required 2021-05-05 17:11:11 iirc rustls uses ring for its crypto operations and ring is basically c/asm crypto extracted from boringssl 2021-05-05 17:11:24 currently musl has some woes with it 2021-05-05 17:16:32 i like the defaults and non-goals of it but supporting 3 tls backends might be *too* much 2021-05-05 17:20:26 (well the cost would be making a libtls interface for it but eh) 2021-05-05 17:27:07 Question: What is the release process for Alpine? How does the master branch get tested and compiled into a release version? 2021-05-05 17:27:42 Any articles or links would help; just point me in the right direction 2021-05-05 17:34:48 https://alpinelinux.org/releases/ 2021-05-05 17:45:13 ikke I'm more looking for the process behind releases. The empty developers handbook didn't really get me anywhere. 2021-05-05 17:45:32 look at the gitlab repo and how things have been done? 2021-05-05 17:49:37 I did check out the repo. It's not very clear. 2021-05-05 17:49:38 Like, I noticed that there are CI/CD steps for testing each main and community package, but they seem small in scope. 2021-05-05 17:50:28 Is there a "test every package" script before release? I'm trying to find that type of stuff. 2021-05-05 17:51:05 No, at some point, the maintainer (ncopa) makes pre-releases, which people can test 2021-05-05 17:51:25 But it's almost impossible to test _everything_ 2021-05-05 17:51:32 Or because every commit is tested, the master branch is considered relatively stable? 2021-05-05 17:51:57 I see, understood -- I knew testing everything could be daunting. 2021-05-05 18:02:14 So we rely on people testing the things they care for and giving feedback 2021-05-05 18:02:50 ikke: https://lwn.net/SubscriberLink/853712/dc7417be35526c6c/ 2021-05-05 18:03:00 Ariadne: thanks 2021-05-05 18:03:39 Makes sense. Thanks for the help, ikke. 2021-05-05 18:04:31 jmercan: i prefer bearssl because its written by an actual cryptographer :) 2021-05-05 18:06:28 (and it's also the most compact and cleanest implementation) 2021-05-05 18:07:46 i think we need multiple high quality TLS implementations 2021-05-05 18:07:57 and it doesn't have a very bad API (openssl) 2021-05-05 18:08:05 the larger reason why OpenSSL hurts us so bad is because we have all of our eggs in the OpenSSL basket 2021-05-05 18:08:08 and works on something other than arm and x86 (rustls) 2021-05-05 18:08:40 ericonr: the ring author says there are generic implementations 2021-05-05 18:09:04 i haven't really dug into rustls too much yet 2021-05-05 18:09:04 there notably aren't, we can't build packages using rustls for ppc* because ring fails to build 2021-05-05 18:09:38 the PR to add ppc to ring also had to add all the impls in a single PR, because otherwise tests couldn't be run 2021-05-05 18:09:50 unless it's changed *a lot* recently 2021-05-05 18:11:33 hmmm also how frequently do they catch up with boringssl codebase? 2021-05-05 18:12:11 dunno 2021-05-05 18:12:19 like i said bearssl is my preference 2021-05-05 18:12:26 +1 2021-05-05 18:12:34 Ariadne: also, ring's versioning policy is a fucking mess 2021-05-05 18:13:12 all hipsters langs are mess 2021-05-05 18:13:37 https://github.com/briansmith/ring/pull/1057 <-- *only* ppc64le and hasn't even been commented on yet 2021-05-05 18:13:55 oh speaking of bearssl, looks like its only available as a static library, considering its size would it be okay to just have the bearssl codebase it in the repo? 2021-05-05 18:14:23 what? 2021-05-05 18:18:05 in Alpine it's also available as a shared library 2021-05-05 18:18:47 (Thomas doesn't recommend it, but the 0.6 ABI has been stable for a long time and I don't see it changing soon) 2021-05-05 18:19:28 huh wait reinstalling fixed it for me neverming :p 2021-05-05 18:19:40 s/neverming/nevermind my bad/ 2021-05-05 18:19:40 jmercan meant to say: huh wait reinstalling fixed it for me nevermind my bad :p 2021-05-05 18:22:53 jmercan: my preference is to de-vendor the apk-tools tree 2021-05-05 18:26:29 Ariadne: i understand no worries 2021-05-05 18:26:46 the only reason why we haven't devendored libfetch is because the libfetch upstream is inappropriate 2021-05-05 18:27:02 maybe ericonr would like to collaborate on a fork :) 2021-05-05 18:32:59 idk how void folks feel about devendoring :P for better or for worse, we managed to make XBPS relatively "dependency free" 2021-05-05 18:34:39 and the last movement around it was updating to match what freebsd had: https://github.com/void-linux/xbps/pull/373 2021-05-05 18:34:52 (you can probably open an issue to discuss the situation, though) 2021-05-05 18:35:23 well i ported it to use libtls :) 2021-05-05 20:18:17 mps: do you know what enables the thunderbolt module? linux-edge has it, but linux-lts does not 2021-05-05 20:29:29 ikke: /drivers/thunderbolt/Kconfig 2021-05-05 20:30:42 USB4 2021-05-05 20:31:30 USB4 is the public specification based on the Thunderbolt 3 protocol. 2021-05-05 20:31:55 I have it but don't have cable to connect it to monitor 2021-05-05 20:32:29 right, thanks 2021-05-05 20:32:32 that's missing in -lts 2021-05-05 20:34:10 yes, but as wrote above I couldn't check if it works 2021-05-05 20:36:38 someone is trying it now 2021-05-05 20:36:41 so, builders and CIs will get displays? :) 2021-05-05 20:36:46 but cannot use -edge because they needs zfs 2021-05-05 21:09:05 while I'm updating APKBUILDs with my current info, would anyone object to me claiming mtxclient? 2021-05-05 21:40:05 is there a style guide for apkbuilds? 2021-05-05 21:41:50 e.g., this isn't caught by the linting stuff, and I've seen it done many different ways in aports. and it's kinda frustrating getting bikeshedded to death over it (and similar things) when there's no way for folks casual contributors to know what the current fads: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21126#note_156575 2021-05-05 21:42:14 I also can't imagine that the alpine maintainers like to point all of this out every time, all the time. but maybe I'm wrong, and y'all do like it :P 2021-05-05 21:42:43 so if there's some "here's the latest apkbuild fashion" guide somewhere, it might save everyone some time 2021-05-05 21:49:05 craftyguy: man APKBUILD and CODINGSTYLE.md in aports 2021-05-05 21:50:45 neither one document the style in that feedback I linked to 2021-05-05 23:06:08 I'm with craftyguy on this 2021-05-06 05:30:35 https://gitlab.alpinelinux.org/Aerdan1/aports/-/jobs/386277#L3984 wth. *all* I did was change Contributor and Maintainer and it doesn't want to link any more. 2021-05-06 05:52:34 that's gcc 10 -fcommon 2021-05-06 05:53:25 so do I add -fno-common to CFLAGS, then? 2021-05-06 05:55:36 it's basically dead upstream, unfortunately. 2021-05-06 05:59:13 i mean, that works 2021-05-06 05:59:24 you want -fcommon 2021-05-06 05:59:26 not -fno-common 2021-05-06 05:59:28 :p 2021-05-06 06:01:57 ohh 2021-05-06 08:12:38 I wonder why raspberry offers its own set of /opt/vc/lib/libbrcm*EGL.so instead of using native mesa 2021-05-06 08:12:56 this means I can't ship a generic retroarch optimized for ARM 2021-05-06 08:13:10 because for raspberry pi it has to be explicitly linked and built through that libs 2021-05-06 08:13:37 if every ARM platforms start to create their own libs we're not finished having dozen of dozen different builds 2021-05-06 09:01:05 Is there a way to specify that an APKBUILD depends on package between say version 0.8 and 0.9? So the dep being 0.8.3 or 0.8 would be alright, but not 0.9 or higher? 2021-05-06 09:13:28 Actually `package>~0.8.3` seems to do the job. Everything between 0.8.3 and 0.9 2021-05-06 11:15:18 maxice8: do you think you can rebase https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/24 ? 2021-05-06 11:17:23 it is I think 2021-05-06 11:18:06 "To merge this request, first rebase locally. " 2021-05-06 11:25:04 Anyone looked at this? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/93 2021-05-06 11:29:04 tomleb: thank you for reporting it and providign a fix. the 2>/dev/null needs to go with the `git` command, not the `true` 2021-05-06 11:29:25 I think we also should add a test case for it 2021-05-06 11:47:01 I think there is an issue with the aarch64 builder because c11plus got killed through 2021-05-06 11:47:09 https://gitlab.alpinelinux.org/markand/aports/-/jobs/386536/raw 2021-05-06 11:47:20 ^F "Killed signal" 2021-05-06 11:49:01 OOM? 2021-05-06 11:51:13 I had the same with a Qt6 MR, aarch64 killed 2021-05-06 11:52:07 Then again, same MR x86_64 on a different package as well 2021-05-06 11:52:11 I have same problem with tdesktop and also in other arch's 2021-05-06 14:38:31 can someone please help with the build errors for mips64? 2021-05-06 14:53:59 could I have a review on https://lists.alpinelinux.org/~alpine/aports/patches/3452 please? 2021-05-06 15:07:57 For the time being, getting reviews is probably easier on Gitlab. 2021-05-06 15:30:58 ncopa: I can take a look 2021-05-06 15:35:49 didn't Ariadne already tell you that we won't add packages that are just binary dumps 2021-05-06 15:36:07 I responded 2021-05-06 15:36:12 not them, but somebody else 2021-05-06 15:36:24 anyway, we won't accept binary dumps from microsoft :p 2021-05-06 15:36:46 (or anyone else) 2021-05-06 15:37:06 it does make sense 2021-05-06 15:37:13 iirc there's a way to build them but >M$< 2021-05-06 15:37:24 yes, and they're working on it. 2021-05-06 15:37:30 i think, uh... somebody is doing it 2021-05-06 15:37:34 good to know 2021-05-06 15:38:02 maybe we can make a #alpine-dotnet or something 2021-05-06 15:38:18 I know it's frustrating that it's a huge pain in the arse that dotnet isn't readily built from source—I share it as I've been wanting to package it for AdĂ©lie for a while—but your patience will be rewarded. 2021-05-06 15:38:27 i don't think we need to call it an Alpine Working Group or such 2021-05-06 15:38:55 mps will have an aneurysm :p 2021-05-06 15:39:11 I've /heard/ there's a twitter group DM about it, but if so I'm not privy to it. 2021-05-06 15:42:36 the main delay is waiting for microsoft to finish arcade 2021-05-06 15:43:28 most likely we will use microsoft's build one time to bootstrap our own dotnet builds 2021-05-06 15:43:32 like fedora did 2021-05-06 15:44:24 iirc i had issues building their stuff with mono 2021-05-06 15:44:30 thats why i went with the binaries 2021-05-06 15:44:33 yes mono is too old 2021-05-06 15:44:39 to build dotnet 2021-05-06 15:44:58 there's also some issues with msbuild 2021-05-06 15:45:13 i dont recall what it was, i think mono cant build it and dotnet uses the new msbuild stuff 2021-05-06 15:45:59 anyway wait for rootwyrm to drop in i guess 2021-05-06 15:46:03 he's working on it 2021-05-06 15:46:07 nice 2021-05-06 15:46:49 anyway its not a blocker for me 2021-05-06 16:30:09 i made a significant effort to get dotnet core built on alpine a while back, but i abandoned it because i had to implement too many ugly hacks 2021-05-06 16:30:20 would be nice if microsoft could get the ball rolling 2021-05-06 16:47:18 hm, the current default abuild LDFLAGS value is broken. right? the comma in -Wl is used to pass arguments to option. it can't be used to pass separate options 2021-05-06 16:49:03 rust 1.52 test builds underway 2021-05-06 16:53:48 ah nevermind 2021-05-06 17:12:42 the new $LDFLAGS actually triggers a funny edge case in vim https://github.com/vim/vim/issues/8181 2021-05-06 17:15:40 nmeum: I don't understand the purpose of that line... 2021-05-06 17:15:46 neither do I 2021-05-06 17:15:51 they remove as needed and add it back?? 2021-05-06 17:15:57 they add it back to the end 2021-05-06 17:16:02 that seems to be relevant for some reason 2021-05-06 17:16:15 ah, I guess that's possible 2021-05-06 17:16:30 otherwise it doesn't make any sense 2021-05-06 17:17:23 yeah 2021-05-06 17:18:12 https://github.com/vim/vim/commit/a6cc03101e30d55d4039d539ed732bc02ffd909b 2021-05-06 17:25:51 but they already appended it to the end before that commit. in fact, that commit only adds the sed expression to make sure the flag is removed if $LDFLAGS already contains it 2021-05-06 17:26:33 workaround in !21180 though --as-needed is no longer the last linker flag with that workaround so idk 2021-05-06 17:59:49 Hello71: what is 'aneurysm' 2021-05-06 18:00:00 bleeding in the brain 2021-05-06 18:00:34 hah, no. war veterans are immune to such things :) 2021-05-06 18:00:49 yes mps comes from debian 2021-05-06 18:01:20 once you've stared at a debian/rules file and found it staring back at you, there is nothing further which can harm you 2021-05-06 18:02:01 :D 2021-05-06 18:02:11 https://git.archlinux.org/svntogit/packages.git/tree/trunk/makepkg.conf?h=packages/pacman already jams -Wl together 2021-05-06 18:02:13 and, yes, I don't like much Working Groups or Committees 2021-05-06 18:02:16 but seems it doesn't hit this particular broken code 2021-05-06 18:03:48 only what I don't understand is why people trying to package MS software for linux 2021-05-06 18:04:04 Hello71: it only hits it if LDFLAGS starts with -Wl,as-needed the arch linux variant doesn't 2021-05-06 18:04:10 yes 2021-05-06 18:05:13 testbuilds for rust almost done 2021-05-06 18:05:21 aarch64 is done 2021-05-06 18:05:26 x86_64 almost done 2021-05-06 18:05:36 ppc64le on my blackbird will be done sometime this century 2021-05-06 18:06:17 So quickly? 2021-05-06 18:06:28 :D 2021-05-06 18:10:00 mps: well if *someone* hadn't steered dotGNU in to an iceberg at speed... 2021-05-06 18:10:15 (no I will never stop being angry about that.) 2021-05-06 18:15:32 shocking: blackbird is really slow compared to 22-core power9 server 2021-05-06 18:16:00 power seems like an interesting architecture; haven't looked into it too deeply yet 2021-05-06 18:16:15 dalias: what is your opinion on 64KB PAGE_SIZE 2021-05-06 18:16:32 i'm thinking about switching alpine ppc64le to use 4KB pages period 2021-05-06 18:17:11 halosghost: it's neat, but it's kinda $$$ 2021-05-06 18:17:20 'kinda' 2021-05-06 18:17:29 lol 2021-05-06 18:17:40 yeah, that's part of the reason I've not looked into it 2021-05-06 18:18:00 I'm very much headed in the direction of spending less on computing (hence why I'm working on getting a pinebook pro to be my daily-driver) 2021-05-06 18:18:05 given that I'm not made of money I'd rather do ARM, tbh 2021-05-06 18:18:08 "why doesn't alpine have ppc64 big-endian too" 2021-05-06 18:18:22 mostly because nobody has gotten around to it yet 2021-05-06 18:18:45 however this 64KB PAGE_SIZE i think has been the result of a lot of weirdness i've experienced on alpine ppc64le 2021-05-06 18:20:08 halosghost: I'm seriously considering apple M1 macbook. tested it somewhat and I'm 'impressed' 2021-05-06 18:20:28 mps: I hope it works well for you 2021-05-06 18:20:50 I'm afriad I've not hard particularly good luck with apple hardware 2021-05-06 18:21:10 Does mode 4710 make sense? specifically, just g+x? 2021-05-06 18:21:11 no, didn't yet bought it, but my son uses it from november 2021-05-06 18:21:42 and I managed to boot alpine on it from external usb disk 2021-05-06 18:21:44 I have one and it's great except for the part where I can't use laptops as a daily driver. 2021-05-06 18:22:26 and now M1 is added to linux 5.13 2021-05-06 18:22:28 (I mean, I *can*, but it's bad for my wrists.) 2021-05-06 18:23:05 so, in few months things will be a lot better, I think 2021-05-06 18:23:52 execve("/usr/bin/../lib/qemu/qemu-bridge-helper", ["/usr/bin/../lib/qemu/qemu-bridge"..., "--use-vnet", "--fd=19", "--br=lxcbr0"], 0xffffd55b5940 /* 14 vars */) = -1 EACCES (Permission denied) 2021-05-06 18:24:31 -rwsr-x--- 1 root qemu 258440 Dec 22 10:39 /usr/lib/qemu/qemu-bridge-helper 2021-05-06 18:26:58 qemu group? 2021-05-06 18:27:06 yes 2021-05-06 18:27:13 The service runs as qemu user/group 2021-05-06 18:27:35 hmm, and still (Permission denied)? 2021-05-06 18:28:20 yes 2021-05-06 18:29:07 huh, yes 2021-05-06 18:29:57 you can reproduce? 2021-05-06 18:31:37 yes, because I'm not in qemu group :) when I switch it to kvm group (where I'm) it works 2021-05-06 18:31:47 hmm 2021-05-06 18:31:48 bump https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20302 2021-05-06 18:32:06 mps: qemu is in kvm group 2021-05-06 18:32:17 so, that might be the issue 2021-05-06 18:32:31 aren't we removed qemu user some time ago? 2021-05-06 18:32:56 no idea 2021-05-06 18:33:06 also I forgot 2021-05-06 18:33:27 Ariadne: I assume you are aware Void forces 4KB pages 2021-05-06 18:33:31 mps: qemu still exists 2021-05-06 18:33:41 but it works if it user in proper group 2021-05-06 18:34:01 so, user must be put in qemu group 2021-05-06 18:35:03 "failed to create tun device: Operation not permitted" 2021-05-06 18:35:04 :/ 2021-05-06 18:36:19 hmm, sticky bit gone 2021-05-06 18:36:35 with chgrp 2021-05-06 18:36:39 yeah 2021-05-06 18:36:50 you have to set it again 2021-05-06 18:37:00 still 2021-05-06 18:37:05 don't know is that bug or not but this happens 2021-05-06 18:37:59 chgrp xxx /usr/lib/qemu/qemu-bridge-helper 2021-05-06 18:38:20 chmod u+s /usr/lib/qemu/qemu-bridge-helper 2021-05-06 18:38:41 chmod g+r /usr/lib/qemu/qemu-bridge-helperJ 2021-05-06 18:38:46 chmod g+r /usr/lib/qemu/qemu-bridge-helper 2021-05-06 18:38:50 -rws--x--- 1 root qemu 258440 Dec 22 10:39 /usr/lib/qemu/qemu-bridge-helper 2021-05-06 18:39:18 -rwsr-x--- 1 root qemu 258488 Mar 27 22:43 /usr/lib/qemu/qemu-bridge-helper 2021-05-06 18:39:40 changed it to 4750, but still, it cannot create the tun device 2021-05-06 18:40:10 with another error or previous one 2021-05-06 18:40:14 oh, wait 2021-05-06 18:40:28 strace breaks suid 2021-05-06 18:41:05 finally 2021-05-06 18:41:15 that took way to long 2021-05-06 18:41:26 mps: thanks 2021-05-06 18:41:29 and solution is? 2021-05-06 18:41:37 adduser qemu qemu 2021-05-06 18:41:50 aha, thought so, thanks 2021-05-06 18:42:58 hmm, but no networking yet 2021-05-06 18:43:11 Need to do it manually 2021-05-06 18:43:30 hmm, /etc/networkin/interfaces is missing 2021-05-06 18:43:48 seems something wrong with it, more users mentioned it not existing 2021-05-06 18:45:08 modern time ;p 2021-05-06 18:45:17 no config files 2021-05-06 18:45:21 no network 2021-05-06 18:46:25 did you (by chance) looked my old qemu armv7 scripts 2021-05-06 18:46:31 no 2021-05-06 18:46:47 I used qemu-openrc from jirutka 2021-05-06 18:46:47 huh, I have to search them then 2021-05-06 18:47:03 aha, never looked at it 2021-05-06 19:04:44 euhm, 2021-05-06 19:04:56 what package should have /etc/network/interfaces? 2021-05-06 19:06:14 oh, setup-interfaces should create it ofcourse 2021-05-06 19:13:21 yep 2021-05-06 20:08:12 gitlab says 'Fast-forward merge is not possible. To merge this request, first rebase locally.' 2021-05-06 20:08:22 that means there are conflicts 2021-05-06 20:08:27 which you need to resolve locally 2021-05-06 20:08:59 ah yes, fcolista made a mess 2021-05-06 20:09:16 :) 2021-05-06 20:21:52 Is it possible to sign APK packages with a GPG key? 2021-05-06 20:22:16 not in a way that apk-tools supports 2021-05-06 21:10:10 is there a way to specify a timeout for openrc on shutdown, for the amount of time to wait for a service to quit after sending SIGTERM, before killing it? 2021-05-06 21:10:21 (manpages had nothing obvious..) 2021-05-06 21:12:05 it's started with command= and command_background=true... so maybe not doing that and just defining a start()/stop() would make it wait. hmm. 2021-05-06 21:12:05 qemu-openrc has something like that for shutting down vms 2021-05-06 21:13:07 oh ok, I'll look at that for inspiration 2021-05-06 21:16:02 ikke: I only see 1 init script in that package source, which seems related to just guests: https://git.alpinelinux.org/aports/tree/community/qemu/qemu-guest-agent.initd 2021-05-06 21:16:26 oh oops, it's separate package altogether, not a subpackage 2021-05-06 21:19:15 I guess the key part of that is this: start_stop_daemon_args="--wait=100" 2021-05-06 21:57:10 ariadne, i hate 64k (all >4k) pagesize 2021-05-06 22:57:56 #12629 !21183 but not just ocaml that need to be bumped, right? 2021-05-06 22:59:51 bpftrace and cloudi too? 2021-05-07 00:46:51 rng =( 'curl -s https://chromium.googlesource.com/chromiumos/third_party/tlsdate/+archive/5fb1b3b57380ef8a9782bb316d6363f9a4e6c29e.tar.gz | sha256sum' 2021-05-07 00:49:39 if we're sharing our favorite ways of getting random data, this is mine: https://0x0.st/-BMs.sh 2021-05-07 00:50:09 it's a not-particularly-well-vetted way to get a ton of hypothetically-secure random data 2021-05-07 00:50:11 â˜ș 2021-05-07 01:05:17 you probably do not need pbkdf since that is meant to derive high entropy from a low entropy password, you however get the password from /dev/urandom which is already high entropy. also openssl rand is a thing that might be competitive with your approach 2021-05-07 01:05:20 yeah, no, I just wanted to package tlsdata but am not sure what to do when the archive isn't consistent enough between downloads 2021-05-07 01:08:16 wdtTP2O82Kft: đŸ€· 2021-05-07 01:08:40 wdtTP2O82Kft: like I said; I haven't vetted it terribly well. All I know is that this solution offers probably-pretty-secure random data very fast 2021-05-07 01:09:52 in Perl? Math::Random::MT::Auto
hence that module being in Alpine's community/. :) 2021-05-07 01:10:23 Sheila: when given the option, I don't have perl installed, but fair 2021-05-07 01:12:02 ACTION finds Perl easier for her to work with than Python, in recent years. though that's in part because PyPI's a joke. 2021-05-07 01:12:54 what about http://phoeagon.github.io/dev-random-as-a-service/ 2021-05-07 02:54:42 Sheila: yeah; I definitely here that. I also choose to not have python installed 2021-05-07 02:55:48 omni: seems reasonablee 2021-05-07 02:55:51 s/e$// 2021-05-07 03:53:31 https://github.com/1bardesign/batteries 2021-05-07 03:53:42 sorry, that was a mispost 2021-05-07 06:38:12 mps, what are you talking about? 2021-05-07 06:40:30 fcolista: buon giorno :) 2021-05-07 06:40:52 I created !21168 which is auto assigned to you 2021-05-07 06:41:13 and you pushed same change directly 2021-05-07 06:41:19 I have already pushed that change 2021-05-07 06:41:20 commit 87bd9298c3d4030ed20532d2b314a87a5794cb6a 2021-05-07 06:41:28 Date: Thu May 6 07:29:43 2021 +0000 2021-05-07 06:41:32 yes 2021-05-07 06:41:36 before that merge 2021-05-07 06:42:08 aha, so I didn't noticed 2021-05-07 06:42:14 sorry then 2021-05-07 06:42:25 np.. 2021-05-07 07:03:26 algitbot: retry master 2021-05-07 07:07:00 algitbot: retry master 2021-05-07 07:14:40 algitbot: retry master 2021-05-07 07:14:42 Damn it 2021-05-07 07:26:39 PureTryOut[m]2: btw, re pmOS 1084 and 1073, nheko was promoted to community/ 2021-05-07 07:26:49 Oh nice, thanks! 2021-05-07 07:26:54 np 2021-05-07 07:45:37 There we go. Conclusion, GNU Make is shit, use Ninja/Samurai 2021-05-07 07:53:19 mps: I wonder why mips-softfloat.patch was removed in 0ed4cab8ff254b5912691f849389c898d2bd2817? 2021-05-07 08:14:19 ncopa: also I wondered and couldn't find answer 2021-05-07 08:14:47 patch date is from 2015 year 2021-05-07 08:15:21 if I have mips machine where I can test it I would, but I don't have one 2021-05-07 08:15:38 s/can/would/ 2021-05-07 08:15:38 mps meant to say: if I have mips machine where I would test it I would, but I don't have one 2021-05-07 08:15:57 uhh, previous sentence is proper 2021-05-07 08:17:55 ohm, maybe I wasn't tried harder to fix this 2021-05-07 08:18:09 sorry 2021-05-07 08:20:12 np. i was mostly wondering if i would create any problems if i added it back 2021-05-07 08:23:34 I think and hope not. we will see if someone report bug 2021-05-07 08:26:17 this reminds me to this 'The moral of all of this is that sometimes history works out such that you write some software that a huge number of people run without any idea of who you are, and also that this can happen without you having any fucking idea what you're doing. 2021-05-07 08:26:28 https://mjg59.dreamwidth.org/56663.html 2021-05-07 09:29:30 hey there 2021-05-07 09:29:48 ncopa, do you know if kodi has to be built with specific flags to be ran directly in KMS's framebuffer? (for raspberry pi) 2021-05-07 10:34:09 markand: no idea 2021-05-07 10:37:23 Should I be able to use mdev to set permissions on /dev/mapper/ devices? 2021-05-07 10:40:37 depends on whether the kernel sends uevents when creating/removing volumes 2021-05-07 10:41:35 (I don't know whether it does, I don't use LVM) 2021-05-07 10:42:20 if it does then you need to figure out the pattern of the DEVNAME it uses and add a relevant line to /etc/mdev.conf to create the /dev/mapper/foo link with the correct permissions 2021-05-07 10:42:29 and then it should work 2021-05-07 10:42:34 right 2021-05-07 10:54:35 ncopa, it's kodi-gbm, problem solved! 2021-05-07 10:54:37 !next 2021-05-07 10:55:51 hi 2021-05-07 10:56:41 are there some news regardlless build killed problem? 2021-05-07 10:58:23 I cannot reproduce it 2021-05-07 11:01:37 but are there more people having similar problems? 2021-05-07 11:06:54 ikke: what about limiting JOBS and expanding CI timeout? 2021-05-07 11:07:10 ikke: yes i think mdev should be able to set it 2021-05-07 11:07:47 ncopa: ok, hope it works then 2021-05-07 11:08:02 Is there any way to test it without rebooting? 2021-05-07 11:08:11 mdev -s? 2021-05-07 11:08:18 tried it, didn't seem to set it 2021-05-07 11:08:58 it's on usa9 2021-05-07 11:09:14 if you know the device you can do echo add > /sys/..../uevent 2021-05-07 11:09:27 which will trigger the "hotplug" event 2021-05-07 11:09:30 ok 2021-05-07 11:12:20 permissions are still the same 2021-05-07 11:13:06 mdev-like-a-boss have some samples, iirc 2021-05-07 11:13:07 mapper/vg0-gitlab--runner.* qemu:kvm 0660 2021-05-07 11:13:54 yeah mdev-like-a-boss is great, it was my reference testing point for mdevd :D 2021-05-07 11:15:07 I didn't tested mapper with it, probably will have to do that in next few days 2021-05-07 11:18:53 can I change the CI timeout? 2021-05-07 11:19:35 yes, in your project settings 2021-05-07 11:20:04 ok thanks 2021-05-07 11:25:50 I don't found it :\ 2021-05-07 11:26:42 https://gitlab.alpinelinux.org/donoban/aports/-/settings/ci_cd 2021-05-07 11:26:45 under general pipelines 2021-05-07 11:27:17 oh great thanks :) 2021-05-07 19:09:51 perdition:~$ rustc --print cfg 2021-05-07 19:09:51 debug_assertions 2021-05-07 19:09:51 target_arch="s390x" 2021-05-07 19:09:59 i'm uhh 2021-05-07 19:10:03 kicking the tires of this rustc 2021-05-07 19:10:11 but so far seems to work 2021-05-07 19:12:31 nice 2021-05-07 19:37:12 whats.the.deal.w()rust() 2021-05-07 21:07:56 could someone hold my hand just a tiny little bit? I'm trying to rebuild the kernel for the raspberry pi image. I've followed this guide: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package and have a git clone of aports ready to go now. where do I get the raspberry-pi specific configuration? 2021-05-07 21:08:48 I tried looking into https://github.com/bboehmke/raspi-alpine-builder/tree/master/resources for inspiration but I'm lost 2021-05-07 21:09:37 https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/linux-rpi 2021-05-07 21:14:45 thanks 2021-05-07 22:54:21 how do i specify numthreads for abuild? 2021-05-07 22:58:13 » target_arch="s390x" 2021-05-07 22:58:13 who are you and what does your computer look like? 2021-05-07 22:59:20 CAPTCHA_REQUIRED: it depends on the computer 2021-05-07 22:59:33 some computers are smol, some are very large 2021-05-07 23:00:18 ok, this looks like it did the job: MAKEFLAGS=$MAKEFLAGS:-j9 2021-05-07 23:00:57 What does the one that's arch is s390x look like? 2021-05-07 23:01:07 very chonky 2021-05-07 23:01:13 it's a phone, obviously 2021-05-07 23:01:17 Do you have a pic? 2021-05-07 23:01:21 but it doesn't quite fit in a pocket 2021-05-07 23:01:21 ya obviously 2021-05-07 23:01:26 i make a lot of phone calls on it 2021-05-07 23:01:34 has 12 megapixel camera 2021-05-07 23:01:35 or is *adding* this to MAKEFLAGS redundant and it should just be MAKEFLAGS=j9 2021-05-07 23:01:37 ? 2021-05-07 23:01:46 x0n^: there is export JOBS=2 or whatever in abuild.conf 2021-05-07 23:01:56 I've never seen a s390x machine 2021-05-07 23:02:07 Ariadne: thanks 2021-05-07 23:02:10 don't manually tamper with MAKEFLAGS or something will bite you in the ass 2021-05-07 23:02:28 I don't know what, but some of those things have pointy teeth 2021-05-07 23:02:31 CAPTCHA_REQUIRED: https://en.wikipedia.org/wiki/IBM_Z#/media/File:IBM_z13_and_LinuxONE_Rockhopper.jpg 2021-05-07 23:02:31 [WIKIPEDIA] IBM Z#/media/File:IBM z13 and LinuxONE Rockhopper.jpg | "IBM Z is a family name used by IBM for all of its z/Architecture mainframe computers from the z900 on.In July 2017, with another generation of products, the official family was changed to IBM Z from IBM z Systems; the IBM Z family now includes the newest model the IBM z15, as well as the z14 and the..." 2021-05-07 23:02:38 CAPTCHA_REQUIRED: mine looks like the one in orange 2021-05-07 23:02:43 CAPTCHA_REQUIRED: except mine is less... pristine 2021-05-07 23:03:22 Huh 2021-05-07 23:03:47 Is there any reason you'd buy this over an aarch64 or x86_64 cluster? 2021-05-07 23:04:10 yes: for testing alpine builds on s390x 2021-05-07 23:04:12 Especially if your installing Linux on it, it doesn't seem like your stuck with legacy proprietary mainframe applications 2021-05-07 23:04:27 mine can't even *run* legacy applications 2021-05-07 23:04:44 (well, it could, but we're not going to talk about defeating the IPL license check here) 2021-05-07 23:05:15 Why would you buy a s390x over the other arches? 2021-05-07 23:05:37 Is there some special workload where they excel at? 2021-05-07 23:05:48 i'm literally doing a talk at alpineconf about this 2021-05-07 23:05:59 I can't possibly imagine why a distribution would need a wide array of different architectures 2021-05-07 23:06:25 people want Alpine on s390x, which means Alpine needs access to s390x hardware. 2021-05-07 23:06:54 but in my case, i bought 6 dead mainframes and with the help of some HMC software image that fell off a truck, got 1 working mainframe last september 2021-05-07 23:07:26 the remaining parts are in a friend's garage, i should probably do something about that at some point 2021-05-07 23:07:35 I'm curious why though, as I've never seen anyone purchase a IBM mainframe except an insurance company because they are forced to run a legacy application that's not portable, or a super rich kid who bought one for fun 2021-05-07 23:08:04 well, i am only $6300 in on the thing in total (minus some upgrades) 2021-05-07 23:08:16 and i'm hardly rich or a child 2021-05-07 23:08:44 they're talking about Connor Krukosky 2021-05-07 23:08:56 he didn't spend much on his either 2021-05-07 23:09:00 like 800 bux 2021-05-07 23:09:09 right, he's not "super rich", just super dedicated 2021-05-07 23:09:11 of course he had to disassemble it one at a time 2021-05-07 23:09:16 one part at a time* 2021-05-07 23:09:47 best way to learn 2021-05-07 23:10:08 CAPTCHA_REQUIRED: https://www.ibm.com/support/pages/alpine-linux-officially-power-and-z 2021-05-07 23:10:31 IBM even sent a guy here to help alpine with s390x, he is online right now 2021-05-07 23:11:05 as for *why*, in my case, largely because it was something to do 2021-05-07 23:11:28 having 288 PUs running at 5.5ghz is also nice 2021-05-07 23:11:38 not having to deal with NUMA is nice 2021-05-07 23:11:59 it is the fastest machine i have by far (when running properly optimized code) 2021-05-07 23:14:10 I'm not criticizing or anything, i'm genuinely curious 2021-05-07 23:14:22 Especially when people are playing with uncommon cpu arches 2021-05-07 23:14:27 as far as what people are doing with alpine on s390x 2021-05-07 23:14:33 it's largely scientific computing 2021-05-07 23:14:51 you can cluster multiple frames into a single s390x system 2021-05-07 23:15:40 Oh like an RDMA bus? 2021-05-07 23:15:43 yeah 2021-05-07 23:15:52 all of this is handled for you at hardware level with s390x 2021-05-07 23:16:27 so people do stuff outside of just COBOL-type stuff with these 2021-05-07 23:16:50 the NWS uses a Linux s390x system to produce its weather forecast products 2021-05-07 23:16:56 How does it compare to RDMA or SAS expanders? 2021-05-07 23:17:07 not really comparabl 2021-05-07 23:17:08 e 2021-05-07 23:17:14 that is apples vs oranges 2021-05-07 23:17:34 you can have frames that are 100% full of PUs and RAM for example 2021-05-07 23:17:40 and its all on a coherent bus 2021-05-07 23:17:53 for storage, they literally just use RDMA 2021-05-07 23:18:33 although PR/SM (and also KVM) can emulate DASD devices from RDMA targets, which happens at least for the boot image 2021-05-07 23:19:42 anyway if you don't mind spending a little money, you can score these machines (and with a little bit of work, get them up and running) for not too much. less than $10k for a complete system is quite doable 2021-05-07 23:20:22 with the US government forcing a lot of workloads onto cloud providers, they're being auctioned off frequently 2021-05-07 23:20:55 it really helps to know the SKUs 2021-05-07 23:20:57 that sounds quite a good performance/bucks ratio compared to raptorcs 2021-05-07 23:21:22 yes but you can run raptorcs at home without needing to call in an electrician 2021-05-07 23:21:34 yeah thats why the only raptor board i have is a blackbird that i got second hand off somebody who didn't want it anymore 2021-05-07 23:21:47 Sheila: you can run a Z system at home too 2021-05-07 23:21:59 it has a standard 240v twist lock cable 2021-05-07 23:22:13 (two in fact) 2021-05-07 23:22:15 if you need 15A and triphase power that's a different thing 2021-05-07 23:22:28 don't need triphase 2021-05-07 23:22:39 240V is fine, but how much wattage does it suck 2021-05-07 23:22:43 mine at least will run on single phase 220 or triphase 208 2021-05-07 23:22:59 as for power consumption... 2021-05-07 23:23:02 ACTION logs into librenms 2021-05-07 23:23:05 will it cause a power cut in the whole neighborhood when I turn it on 2021-05-07 23:23:18 if not, it's not even worth it 2021-05-07 23:24:30 You say you don't need to worry about NUMA, but surely there's a bandwidth and latency cost to accessing a box of DRAM over a long cable instead of mere centimeters from your application processors? 2021-05-07 23:24:48 ~1410W 2021-05-07 23:25:02 eh, that's not so bad 2021-05-07 23:25:06 meh 2021-05-07 23:25:10 oh. that's not too bad, that's like 2-3 desktops 2021-05-07 23:25:13 it's like 3 of my PCs 2021-05-07 23:25:15 yeah 2021-05-07 23:25:29 CAPTCHA_REQUIRED: yes, but PR/SM schedules VMs to be close to their RAM 2021-05-07 23:25:36 obviously if you say 2021-05-07 23:25:38 I've similar power usage in my room ATM probably so.. easy :D 2021-05-07 23:25:50 i want a single VM with all RAM 2021-05-07 23:25:55 your performance is going to suck :p 2021-05-07 23:26:19 » I've similar power usage in my room ATM probably so.. easy :D 2021-05-07 23:26:19 you must live in a cool climate 2021-05-07 23:26:20 when i say "you don't need to worry about NUMA", i mean NUMA itself is not a concept these systems have 2021-05-07 23:26:39 I want to arrange my cellar and install a power line and fiber there 2021-05-07 23:26:40 Can't say I haven't used servers and compile jobs to heat my home during the winter 2021-05-07 23:26:57 so I can move my rack bay in the cellar and get noisy machines that run 24/7 2021-05-07 23:28:53 CAPTCHA_REQUIRED: saying "my country is cool enough" is nationalism? 2021-05-07 23:29:02 Lol 2021-05-07 23:29:22 skarnet: maximum consumption is up to 5000W per cabinet, but you can configure the system to limit power consumption 2021-05-07 23:29:51 5kW is starting to be a lil much 2021-05-07 23:30:03 1410 is the peak consumption 2021-05-07 23:30:05 for me 2021-05-07 23:30:16 like right now i am compiling rust 2021-05-07 23:30:43 with the cross compiler 2021-05-07 23:30:57 there's something funky going on 2021-05-07 23:31:11 - cross-compiling 2021-05-07 23:31:12 -rust 2021-05-07 23:31:14 cross compiler can compile rust programs fine 2021-05-07 23:31:15 - s390x 2021-05-07 23:31:22 but it cannot compile a rustc fine 2021-05-07 23:31:57 i was hoping to get rust on s390x as a nice lil bookend to 3.14 release 2021-05-07 23:31:59 we will see :) 2021-05-07 23:32:08 well mcm has trouble native compiling gcc-11 so... >.> 2021-05-07 23:32:33 something to do with the new C++ support 2021-05-07 23:32:39 » 1410 is the peak consumption 2021-05-07 23:32:39 that number is oddly specific. It's also the maximum draw per power supply on a poweredge r710 2021-05-07 23:33:15 CAPTCHA_REQUIRED: i have an electrical panel which can measure in watts per circuit :) 2021-05-07 23:33:45 CAPTCHA_REQUIRED: are you suggesting the machine is refusing to use more bcs of power supply/power installation? 2021-05-07 23:34:09 Well the power supplies have their own firmware which talks to the BMC 2021-05-07 23:34:25 You can set a max current draw of each server through the BMC 2021-05-07 23:34:40 There's a critical and a cap set in the firmware 2021-05-07 23:34:54 "System Level" via ipmi 2021-05-07 23:35:30 yes, the power supplies are managed by the HMC on a s390x machine the same way 2021-05-07 23:35:56 there are 8 power supplies total inside the frame 2021-05-07 23:36:07 dunno what the max for each one is, it load balances between them 2021-05-07 23:36:13 If you set a power budget in the BMC it does things like slow down the other componets to meet that budget 2021-05-07 23:36:35 yep 2021-05-07 23:36:41 same on this system 2021-05-07 23:36:44 You may be able to query what the max is via ipmitool 2021-05-07 23:36:54 these systems dont have ipmi :D 2021-05-07 23:37:06 Is there a proprietary equivalent? 2021-05-07 23:37:12 these systems have an x86 server inside them 2021-05-07 23:37:19 which exists to boot the rest of it up 2021-05-07 23:37:25 (that's the HMC) 2021-05-07 23:37:29 Oh! 2021-05-07 23:37:35 CAPTCHA_REQUIRED: ipmi isnt proprietary anyway? 2021-05-07 23:37:43 nomally, this is a lenovo thinkserver 2021-05-07 23:37:53 Ariadne: lol what? 2021-05-07 23:37:56 It's an open standard with proprietary implementations 2021-05-07 23:38:00 in my case, it's a supermicro i got for 200 bucks 2021-05-07 23:38:00 There is OpenBMC though 2021-05-07 23:38:05 I think the talos supports it 2021-05-07 23:38:13 with a copy of the HMC software that fell off a truck 2021-05-07 23:38:15 An open implementation 2021-05-07 23:38:42 there is an internal ethernet switch that all the components are on for control plane purposes 2021-05-07 23:38:45 Do a lot of things like that fall of trucks in california? 2021-05-07 23:38:51 *off 2021-05-07 23:39:06 yeah you know sometimes you just go out for a stroll 2021-05-07 23:39:16 and then the blurry enterprise typeface comes into focus, and you see IBM 2021-05-07 23:39:24 or Cellebrite 2021-05-07 23:39:39 gosh i hate when that happens 2021-05-07 23:40:00 I can't tell if your serious or not 2021-05-07 23:40:20 i mean the location doesn't have much to do with it 2021-05-07 23:40:31 but yes, things do tend to fall off trucks if you know where the trucks are located 2021-05-07 23:40:34 if that makes sense :) 2021-05-07 23:41:24 skarnet: correction: power draw is now 1950W 2021-05-07 23:41:38 rustc sure does like to consume a lot of power 2021-05-07 23:42:22 Rust is not environmentally conscious 2021-05-07 23:42:47 My first real laptop 2021-05-07 23:43:05 It was actually from a dumpster of a steel plant 2021-05-07 23:43:05 my laptop is a POS dell with shattered webcam 2021-05-07 23:43:42 I still have it, and used it till it's very end when the SMD caps went bad 2021-05-07 23:44:02 anyway, what am i doing with my mainframe? 2021-05-07 23:44:03 As you know, SMD caps are generally considered the most reliable and long-lasting type of cap 2021-05-07 23:44:07 absolutely nothing of use 2021-05-07 23:44:12 it hosts my quasselcore 2021-05-07 23:44:17 I still have it 2021-05-07 23:44:19 spilled coffee on my pinebookpro last week :[ 2021-05-07 23:44:29 other than that, just the occasional build 2021-05-07 23:44:34 oh, it also hosts my email 2021-05-07 23:44:57 and a handful of other things that don't actually need a mainframe 2021-05-07 23:44:59 eyeRseer: i dropped my thinkpad from 1.5m last week 2021-05-07 23:45:02 ..nothing happened 2021-05-07 23:45:05 One more question about your mainframe Ariadne, can you do hardware partitioning and run more than one operating system on it at the same time like SPARC hardware partitions? 2021-05-07 23:45:13 Hardware-level containers 2021-05-07 23:45:17 CAPTCHA_REQUIRED: yes, PR/SM provides the hardware partitioning 2021-05-07 23:45:23 Not-quite virtualization 2021-05-07 23:45:26 Oh neat 2021-05-07 23:45:41 and then there is DPM which is a nice control panel for PR/SM 2021-05-07 23:45:45 I still have it 2021-05-07 23:45:47 My T60 2021-05-07 23:45:53 i am planning to give others access to my mainframe to run jobs on 2021-05-07 23:46:00 i just want to uhh 2021-05-07 23:46:07 figure out if DPM is actually secure first 2021-05-07 23:46:10 and uhh 2021-05-07 23:46:14 I keep it around for the day i'm able to either obtain or design my own aarch64 replacement mainboard and fit it inside 2021-05-07 23:46:19 come up with a plan for dealing with cryptocurrency assholes 2021-05-07 23:46:33 The chassis and keyboard and screen construction is incredible 2021-05-07 23:46:37 since apparently that's a thing now 2021-05-07 23:46:50 (people abusing public computing services for mining) 2021-05-07 23:47:20 Ariadne: when you do that would you let me know? I'd really like to check out for myself the things you described 2021-05-07 23:47:54 I promise I won't use it for mining currency on other people's volunteer hosted infra 2021-05-07 23:48:21 Though i might use it for porting some of my projects and large C++ code to s390x musl, if that's alright with you 2021-05-07 23:48:43 you can also run s390x in simulation with qemu or hercules 2021-05-07 23:49:07 CAPTCHA_REQUIRED: put some phone with MHL + OTG + USB HUB inside and mod keyboard and trackpoint to usb 2021-05-07 23:49:35 theres a lot of weirdness with s390x 2021-05-07 23:49:43 for example, s390x does not have a program counter 2021-05-07 23:49:55 there is the processor status word, but its not quite the same thing 2021-05-07 23:49:58 What!? 2021-05-07 23:50:20 hell what? 2021-05-07 23:50:39 this makes the libucontext support quite interesting 2021-05-07 23:51:28 https://cdn.nuegia.net/9b321adf-d308-4651-b68f-79be5fc5492b/sat.jpg 2021-05-07 23:53:23 instead of capturing the program counter in a context, you have to use a trampoline, which runs the function and then returns back to the trampoline 2021-05-08 05:15:22 Can someone look at my MR when they get the chance: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21023 2021-05-08 07:28:46 hmm: ERROR: gettext-tiny-dev-0.3.2-r0: trying to overwrite usr/include/libintl.h owned by musl-libintl-1.2.2-r2. 2021-05-08 07:33:33 second time I see such 'thing' 2021-05-08 07:33:53 ncopa: would you accept a change to the curl/libcurl apkbuild to enable the c-ares dns resolver backend? (c-ares is by the same folks as curl) 2021-05-08 07:34:33 and don't see point to have gettext-tiny in alpine now when we becoming 'big distro' ;P 2021-05-08 07:35:12 ncopa: there are options in libcurl for controlling how DNS is resolved (e.g. binding requests to specific interfaces, etc), that only work with the c-ares resolver backend 2021-05-08 07:35:48 mps: it helps to see alpine as not wanting to become big, but that there are forces at play that sometimes go in one direction and then reactions happen in the other direction 2021-05-08 07:36:43 yes, pendulum effect is inevitable :) 2021-05-08 07:37:40 ugh I guess my question just now is kinda 'case in point' to that comment.. if it helps, the package I'm suggesting that curl depend on is like 96KB, so hopefully that's not too 'big distro' :P 2021-05-08 07:38:43 craftyguy: to late, we have to delete 'small' from home page 2021-05-08 07:38:52 and simple, ofc 2021-05-08 07:39:36 actually, we should rename it to pmOS :P 2021-05-08 07:40:54 they say imitation is the sincerest form of flattery 2021-05-08 07:42:20 hehe 2021-05-08 07:42:30 true 2021-05-08 07:57:23 ikke: for hypnotix fix is simple, replace gettext-tiny-dev with gettext-dev 2021-05-08 08:15:15 the gettext-tiny package in community is weird 2021-05-08 08:15:41 mine does not include a libintl.h as it just uses the musl one :P 2021-05-08 08:23:01 so just remove gettext-tiny-dev? 2021-05-08 08:44:16 if the Ariadnes one is better why not replace this old one with it? 2021-05-08 08:48:05 I think that's the goal 2021-05-08 09:36:54 could someone check if the new LDFLAGS value is already deployed on all builders? 2021-05-08 09:37:31 last time I modified /etc/abuild.conf, the change had to be manually propagated to many builders since some of them used modified /etc/abuild.conf files back then 2021-05-08 09:38:16 yes 2021-05-08 09:38:22 it's not deployed yet 2021-05-08 09:39:09 so we switch to -O1 instead of -Os? 2021-05-08 09:39:25 nah, that's a linker flag 2021-05-08 09:39:28 not a compiler flag 2021-05-08 09:39:30 right 2021-05-08 09:39:58 it's described in ld(1) 2021-05-08 09:40:31 is that LTO? 2021-05-08 09:41:01 it would be nice to sync /etc/abuild.conf on the builders with the stuff provided by the abuild package to ensure that we notice LDFLAGS-related issues early on 2021-05-08 09:41:31 no, it's not the same as LTO afaik 2021-05-08 09:41:55 oh, ok 2021-05-08 09:42:32 why do the builders not use the standard unmodified /etc/abuild.conf as provided by the abuild package? 2021-05-08 09:44:04 It sets for example DISTFILES_MIRROR 2021-05-08 09:45:16 can this not be done from /etc/profile.d to avoid changes to abuild.conf? 2021-05-08 09:47:30 I guess for transparency, but it indeed makes changes more challenging 2021-05-08 09:48:51 should I open an infra issue so we don't forget about this? 2021-05-08 09:48:57 not the first time we run into this after all :D 2021-05-08 09:57:25 to fix #12658 not only linux-lts must be upgraded but also all external drivers 2021-05-08 09:58:19 I would fix this and some other things in kernel but not sure about these 'add-ons' 2021-05-08 09:59:58 bumping _krel on those? 2021-05-08 10:00:20 only that? 2021-05-08 10:00:52 yes, looks like this is enough 2021-05-08 10:04:36 eh good, after two years ncopa followed my advice to remove external drbd kernel driver :) 2021-05-08 10:05:01 next is community/rtl8821ce-lts 2021-05-08 10:05:28 I'm fine with that :) 2021-05-08 10:05:50 thank you :) 2021-05-08 10:05:52 Wasn't that driver included now, or was that a different one 2021-05-08 10:06:32 both have bugs, so user can choose which bugs they prefer ;) 2021-05-08 10:11:02 We should have some dkms like system in alpine 2021-05-08 10:11:24 will be nice 2021-05-08 10:11:29 would* 2021-05-08 10:12:15 question is: is it ok to port it from Arch linux 2021-05-08 10:12:47 or we have to invent our 2021-05-08 10:13:33 akms - alpine kernel module system 2021-05-08 10:14:17 dkms is a generic system, right? 2021-05-08 10:14:21 ubuntu uses it too 2021-05-08 10:14:47 debian invent, so debian kernel module system (not sure for last word) 2021-05-08 10:15:05 makes sense 2021-05-08 10:15:09 software maybe, or something else 2021-05-08 10:15:22 support 2021-05-08 10:15:27 Dynamic Kernel Module Support 2021-05-08 10:15:38 so not even debian 2021-05-08 10:15:46 I knew but I forgot meaning 2021-05-08 10:16:35 Description: Dynamic Kernel Module Support Framework 2021-05-08 10:17:17 DRAM^WBrain refresh is lagged 2021-05-08 10:18:01 but word 'Dynamic' is misleading obviously 2021-05-08 10:18:38 How so? 2021-05-08 10:20:28 what is 'dynamic' there 2021-05-08 10:21:05 dkms is specifically for building modules out-of-tree 2021-05-08 10:21:22 so 'dynamic' refers to the part where you're doing it on-install, as it were. 2021-05-08 10:21:43 no, that doesn't sound with sense 2021-05-08 10:22:32 sure it does, otherwise you'd be building it with every kernel provided by distro instead of just the one being used. 2021-05-08 10:23:00 but in software there are a lot misleading terms and names, so one more is not important 2021-05-08 10:23:53 so, there is also 'Static Kernel Module Support Framework' :) 2021-05-08 10:25:25 though I would name it 'Buggy Kernel Module Support Framework' 2021-05-08 10:25:42 that's what we have now :P 2021-05-08 10:25:49 static 2021-05-08 10:26:05 hehe, 'Nomen est Omen' 2021-05-08 10:26:58 name is a name? 2021-05-08 10:27:39 hard to translate literally 2021-05-08 10:28:28 the name is sign 2021-05-08 10:29:31 Plautus in his comedy 'Persa' 2021-05-08 10:30:28 ikke: https://www.wordsense.eu/nomen_est_omen/ 2021-05-08 10:31:52 aha 2021-05-08 11:24:05 uh, better would be to simply copy kernel armv7 config for linux-virt from linux-edge than change current in linux-lts 2021-05-08 11:27:55 actually some kind of two way merge is needed 2021-05-08 13:45:35 Dadrophenia: airsonic is failing on a number of arches 2021-05-08 14:34:08 ikke: linux-lts needs more care than simply add this in #12658 2021-05-08 14:34:16 mps: oh, ok 2021-05-08 14:34:45 this one is ok for problem you had few days ago 2021-05-08 14:35:26 I looked more at it noticed that there are some more things which should be enabled and/or changed 2021-05-08 14:35:41 BTI, MTE and some other 2021-05-08 14:35:52 I'm talking about aarc64 one 2021-05-08 14:36:10 armv7 require a looooot more changes 2021-05-08 14:36:52 I'm not sure how would BDFL 'accept' things which I would like to add/change 2021-05-08 14:36:59 yeah, I'm using the aarch64 kernel for all arches now 2021-05-08 14:37:05 so, I'll step back for now 2021-05-08 14:37:34 I will ask him on monday about all these things 2021-05-08 14:38:08 actually, I'm tempted to ask for maintainership 2021-05-08 14:38:19 though not sure 2021-05-08 14:39:44 for now, you can use linux-edge and ask for whatever you want/need/like to have 2021-05-09 09:55:08 Hmm, ruby seems to fail build with the latest autoconf 2021-05-09 09:55:16 ./configure: line 4103: syntax error: unexpected "fi" (expecting "then") 2021-05-09 10:12:09 https://tpaste.us/ejRE This part is improperly rendered 2021-05-09 11:21:07 apk info by default does not list version while apk search does 2021-05-09 11:21:12 don't you think we should uniform that? 2021-05-09 14:42:44 as a semi-external observer, if apk had its output format well-specified across all commands, that sounds really nice (since it'd allow for wrappers to parse output pretty well). And, one of the easiest steps towards that is to unify output that is like 2021-05-09 14:42:54 so, if it's a voting matter, I'm in-favor â˜ș 2021-05-09 14:43:05 though, I suspect this falls into the realm of “patches welcome” 2021-05-09 14:45:04 In that case, I guess it would be better to just provide json output 2021-05-09 14:45:32 ikke: I mean, having a --json global flag to get the output in machine-readable format sounds awesome 2021-05-09 14:47:33 good news for ncopa, kernel 5.10 -LTS time is extended to 2026 https://www.kernel.org/category/releases.html 2021-05-09 15:07:51 better 2021-05-09 15:12:37 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/388835 2021-05-09 15:16:41 (ignore the build failure, there is something else noteworthy) 2021-05-09 15:20:21 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/388835#L122 2021-05-09 15:20:27 maybe this 2021-05-09 15:21:02 Check the arch 2021-05-09 15:21:34 ah 2021-05-09 15:31:43 I can patch out the part that is causing this issue 2021-05-09 15:31:54 It's just for macos 2021-05-09 15:40:28 sound good idea, abuild is not planed to be ported to macos, afaik ;) 2021-05-09 16:08:43 all green :) 2021-05-09 18:51:21 hg clone 2021-05-09 18:51:23 :)0 2021-05-09 19:57:09 where is the use case of CARCH and friends documented 2021-05-09 19:57:30 I see in several APKBUILD but no mentions of it in APKBUILD(5) nor the wiki page for creating package 2021-05-09 20:05:46 Good question 2021-05-09 20:05:51 I don't think it' 2021-05-09 20:05:55 it's documented 2021-05-09 20:06:13 It's defined in https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/functions.sh.in 2021-05-09 20:55:55 those days you can even not make reproducible builds 2021-05-09 20:56:22 some software includes extra optimizations if the current system is running Raspberry Pi 2021-05-09 20:56:50 at some point we well end up in repositories like -rpi/-beaglebone/-odroid and such 2021-05-09 20:56:55 rather than -aarch64/-armv7 2021-05-10 08:43:34 FYI: We now have CI for armhf 2021-05-10 08:45:55 \o/ 2021-05-10 08:52:29 Oh nice, good job! 2021-05-10 08:52:43 Now mips64 too please 😛 And RISC-V once we start supporting that 2021-05-10 09:05:56 Is by the way anyone using wayland and QT5 applications on top of it? If so, does it work for you, or are you using Xwayland? 2021-05-10 09:06:22 PureTryOut[m]2: we need hw for mips 2021-05-10 09:06:30 Works for me yes, but I only sometimes run Wayland to test things and go back to X11 quickly becacuse Plasma is awfully buggy on it for me 2021-05-10 09:06:53 ikke: I suppose the builder can't be used for CI as well? 2021-05-10 09:12:28 ACTION just noticed armhf in CI and came here 2021-05-10 09:12:31 \o/ 2021-05-10 09:22:23 PureTryOut[m]2: the resources are limited 2021-05-10 09:22:52 Yeah I thought so already... 😱 2021-05-10 09:25:27 Ariadne did have plans for it, so I'm waiting for that 2021-05-10 09:27:33 what's the status on replacing the ppc64le builder? 2021-05-10 09:29:26 We're waiting for updates still 2021-05-10 09:37:11 morning 2021-05-10 09:37:14 or good day 2021-05-10 09:40:32 moin! 2021-05-10 09:42:28 ikke: ok, I was curious because of !21191 2021-05-10 09:44:19 I don't want to disable cloudi on ppc64le just because the updated ocaml package isn't built yet 2021-05-10 09:50:19 If it's just ppc64le failing because of outdated binary repo, then you can just merge it for now. You can't block the builder with a failing package anyway 😜 2021-05-10 09:55:01 our CI has been red since ppc64le went down? 2021-05-10 09:56:06 The CI builder still works 2021-05-10 09:56:20 oh ok 2021-05-10 09:56:31 But as the repo starts lagging, more jobs will fail 2021-05-10 09:58:01 ok. i thikn its time to disable the ppc64le from the CI then 2021-05-10 09:58:42 I'll do that in a bit 2021-05-10 09:59:08 rm -rf redhat^Wibm ;> 2021-05-10 09:59:47 mps: seems like that is the way its going 2021-05-10 10:02:03 heh, and I just wanted to make 'bad' joke 2021-05-10 10:14:53 ncopa: in case you didn't read backlog here, kernel 5.10 -LTS time is extended to 2026 https://www.kernel.org/category/releases.html 2021-05-10 10:36:33 I have been going through the aports issue list a bit yesterday 2021-05-10 10:36:41 Would be nice if we could recude the amount of open issues a bit 2021-05-10 10:37:39 imo, two thirds of them are 'non issue' 2021-05-10 10:38:08 lots of package requests that no one touches 2021-05-10 12:14:09 what license must you use if your package has full custom one? 2021-05-10 12:45:30 Honestly I don't want to be mean or rude at all but I think there are numerous issues regarding our development of aports. 2021-05-10 12:45:44 On a previous merge request I've been told to use abuild-meson rather than "raw" meson but I have no idea where/when this was discussed or validated. I'm also not able to find anywhere where it is said to use abuild-meson (newapkbuild -m still not use abuild-meson even in Git). 2021-05-10 12:46:09 There are corners that are left unspecified/undocumented in many places (like my question of CARCH earlier and license field) and that really need to be fixed. 2021-05-10 12:46:27 I don't think we need a 100 pages book to write a package like Debian do, APKBUILD syntax is definitely small and clean, but Alpine in overall terribly lacks good documentation and I'd be glad to improve it. 2021-05-10 12:46:48 I'd go editing the Creating_an_Alpine_package to update those topics and submit enhancement to APKBUILD but first we need to get much better things setup and official "references". 2021-05-10 12:51:59 markand: we need to write the developers handbook 2021-05-10 12:52:16 as wiki or other format? 2021-05-10 12:53:39 docs.alpinelinux.org 2021-05-10 12:54:56 this is so nice looking 2021-05-10 12:56:42 I've been tinkering with mkdocs, I like the fact that it's pure markdown but antora looks not complicated 2021-05-10 13:00:29 my next weekend is already planned I think ;p 2021-05-10 13:02:42 Coincidentally, mine as well 2021-05-10 13:07:18 oh noes antora is in npm D: 2021-05-10 13:07:35 :D 2021-05-10 13:08:19 FYI, there is #alpine-docs 2021-05-10 13:08:53 text/plain, please 2021-05-10 13:14:27 yes joined it 2021-05-10 13:32:08 markand: newapkbuild support is just waiting for someone to press the magic button though: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/60 2021-05-10 17:16:00 mps: i think it ultimately comes down to whether IBM wishes to support alpine ppc64le or not, considering the technical decisions they made with the port 2021-05-10 17:16:26 if it becomes a "community" port, then i want to basically redo the entire port 2021-05-10 17:16:34 so that we can drop the 64KB page size nonsense 2021-05-10 17:17:25 right now i recommend void to people who want to run ppc64le on stuff like talos, because it just works 2021-05-10 17:17:36 desktop alpine on ppc64le is totally broken 2021-05-10 17:43:16 hah, it has 64KB page size. strange 2021-05-10 17:43:38 they wanted that. 2021-05-10 17:44:14 why 'we' (alpine) can't change this? 2021-05-10 17:44:50 IBM provided the original material, aiui 2021-05-10 17:45:10 it would be nice if it were a community project though. 2021-05-10 17:45:37 alpine _is_ a community project 2021-05-10 17:50:56 ^ 2021-05-10 17:51:06 indeed 2021-05-10 17:51:13 mps: we can change it, but not sure if IBM will stick around if we do 2021-05-10 17:51:43 also we would have to rebuild the entire arch to change it 2021-05-10 17:52:02 why exactly do they want to use 64kb pages to be exact 2021-05-10 17:52:16 server shit, aiui 2021-05-10 17:54:30 oh why do we still use servers 2021-05-10 17:56:04 I dislike idea that any commercial entity dictates our technical reasons, be they good or bad doesn't matter to me 2021-05-10 17:56:25 s/reasons/decisions/ 2021-05-10 17:56:26 mps meant to say: I dislike idea that any commercial entity dictates our technical decisions, be they good or bad doesn't matter to me 2021-05-10 17:57:36 insep_: in contrast to popular believe, serverless isn't 2021-05-10 18:00:18 isn't cool? 2021-05-10 18:00:31 serverless isn't serverless 2021-05-10 18:06:39 Ariadne: page size should be runtime property, userspace is unaware 2021-05-10 18:06:53 afaik only the kernel needs to be recompiled for it 2021-05-10 18:07:24 also IBM is very particular about ppc, idk if they even officially approve the ABI used by ppc64 (be) on musl 2021-05-10 18:13:01 ericonr: yes, '# CONFIG_PPC_4K_PAGES is not set' and 'CONFIG_PPC_64K_PAGES=y' 2021-05-10 18:13:34 ericonr: oh ok 2021-05-10 18:13:50 ericonr: well, i do not really care about ppc64le 2021-05-10 18:14:04 there's nothing there for me 2021-05-10 18:14:16 the servers are... okay i guess 2021-05-10 18:14:20 while 'CONFIG_ARM64_4K_PAGES=y' 2021-05-10 18:14:21 but AMD EPYC has caught up 2021-05-10 18:14:50 ppc64le is also ridiculously expensive to play with 2021-05-10 18:14:56 even raptor stuff is expensive 2021-05-10 18:15:15 this PAGE_SIZE is one option change in kernel 2021-05-10 18:16:07 well either way 2021-05-10 18:16:38 it is kind of moot because IBM needs to fix the builder 2021-05-10 18:18:50 also I don't care for IBM, at the end 2021-05-10 18:19:35 except when these two arches puts burden on us to fix some things 2021-05-10 18:19:59 i think s390x has the larger value there 2021-05-10 18:20:11 at this point, ppc64le is basically x86 but RISC 2021-05-10 18:20:18 in terms of memory model, in terms of endianness, etc 2021-05-10 18:23:19 it comes down to IBM and IBM alone to determine if ppc64le is still wanted in alpine community 2021-05-10 18:24:19 Ariadne, IBM has provided you with VMs for both ppc64le and s390x? 2021-05-10 18:25:01 oh, i read a bit more now, they make technical decisions about the alpine ppc64le port? 2021-05-10 18:25:04 Habbie: IBM has provided alpine with physical machine for ppc64le and who knows what for s390x (i have my own s390x machine) 2021-05-10 18:25:30 i also have a few ppc64le machines, but there's nothing interesting about them 2021-05-10 18:26:32 hmm, my ibm ppc vm has a readonly filesystem 2021-05-10 18:47:44 :D 2021-05-10 18:47:50 reboot fixed it 2021-05-10 18:47:55 'ibm_power-lpar_shared' 2021-05-10 18:52:33 i have updated all edge builders to do LDFLAGS="-Wl,--as-needed,-O1,--sort-common" 2021-05-10 18:52:41 just FYI 2021-05-10 18:52:49 👍 2021-05-10 18:53:50 what is -O1 for linker? 2021-05-10 18:54:03 and is --as-needed a good idea? 2021-05-10 18:54:17 --as-needed was already there 2021-05-10 18:55:11 yeah, the change was the -O1,--sort-common 2021-05-10 18:55:13 https://gitlab.alpinelinux.org/alpine/abuild/-/commit/4e548b722b55714dc1888f1df3a549bca0782081 2021-05-10 18:55:34 tbh, i haven't really investigating exactly what it does 2021-05-10 18:57:00 > Hello71 2021-05-10 18:57:22 ncopa: one thing that nmeum brought up: because we modify /etc/apkbuild.conf, we always have to make these kinds of changes manually and it's not really transparant 2021-05-10 18:57:25 how did i know it would be him :D 2021-05-10 18:57:44 Hello71: ok what does -O1 --sort-common do 2021-05-10 18:57:55 i only know what it says in the man page 2021-05-10 18:58:15 :D 2021-05-10 18:58:26 well, as long as it doesn't break anything who cares 2021-05-10 18:58:28 and i guess that arch uses it 2021-05-10 18:59:47 i mean arch using something is not necessarily a great selling point :p 2021-05-10 19:00:10 i mean it's probably not totally broken 2021-05-10 19:00:14 aiui arch is move fast break things 2021-05-10 19:00:15 i also found when googling that vapier recommended -O1 for gentoo at some point, but still cannot find exactly what it does 2021-05-10 19:00:33 i think gentoo also do -O1 2021-05-10 19:00:42 that is an even worse selling point :D 2021-05-10 19:01:11 do we have to break out https://www.shlomifish.org/humour/by-others/funroll-loops/Gentoo-is-Rice.html 2021-05-10 19:01:21 im just telling what my googling found 2021-05-10 19:01:27 use -O2 2021-05-10 19:01:41 its probably fine 2021-05-10 19:01:52 well, the defaults in gentoo was kinda moderate. the gentoo users was the once doing the ricing bits 2021-05-10 19:02:02 -O1 is a somewhat document in ld(1) 2021-05-10 19:02:26 ok, the man pages doesn't exactly state what kind of optimization are performed though 2021-05-10 19:02:32 Optimize output file 2021-05-10 19:02:45 aiui "linker" and "well documented" don't really go together 2021-05-10 19:02:49 haha 2021-05-10 19:02:52 lol 2021-05-10 19:02:54 ncopa, thanks, very helpful! 2021-05-10 19:03:38 well, its enabled on all the edge builders now anyway. lets see what blows up... 2021-05-10 19:03:43 the only thing I noticed so far is that the vim build broke, but that's related to some shenanigans in vim build script 2021-05-10 19:04:11 i need to go. have a nice evening everyone 2021-05-10 19:04:33 night :) 2021-05-10 19:08:55 has anyone actually tested if binaries become smaller when linked with the new LDFLAGS? đŸ€” 2021-05-10 19:11:00 --sort-common isn't about filesize, but sorting symbols by size to minimize alignment issues. 2021-05-10 19:11:57 minimize space wasted on alignment, right? 2021-05-10 19:14:20 i think it will save maybe a KB or two at most 2021-05-10 19:14:22 oh well 2021-05-10 19:14:23 :) 2021-05-10 19:14:33 only as a side-effect, and it won't be a lot relative to everything else. 2021-05-10 19:14:46 well the corresponding commit in aports claims that these flags “slightly reduce binary size” 2021-05-10 19:14:51 except sometimes things suddenly add up 2021-05-10 19:14:53 nmeum, makes sense to me 2021-05-10 19:14:58 not sure about -O1 though 2021-05-10 19:15:19 my ld man page indeed also does not explain what the -O optimisations are at all 2021-05-10 19:15:45 i hate qmail btw 2021-05-10 19:15:56 qmail checks that forward DNS = reverse DNS 2021-05-10 19:16:03 how annoying 2021-05-10 19:16:41 that's configurable, like in most mail servers 2021-05-10 19:17:21 and i thought many others also did it today, either by default or in common configurations 2021-05-10 19:18:23 yeah unfortunately asking the internet to configure it when i can just fix the typo :P 2021-05-10 19:18:38 other people's mail servers are the worst ;) 2021-05-10 19:19:15 uh, no it doesn't 2021-05-10 19:19:20 it's only when configured to do so 2021-05-10 19:19:27 and most people do so because it cuts 90% of the spam 2021-05-10 19:19:40 (it's tcpserver, not qmail itself) 2021-05-10 19:19:53 uhg 2021-05-10 19:20:03 yeah I hate it too 2021-05-10 19:20:33 looking at it some closer, neither tcpserver nor qmail actually appear to have a button to -reject- connections in that case? 2021-05-10 19:20:57 tcpserver -p 2021-05-10 19:21:12 'unsets TCPREMOTEHOST if there is no match' 2021-05-10 19:21:21 and qmail then puts 'unknown' in your headers 2021-05-10 19:21:33 wait let me look at my config 2021-05-10 19:21:42 you might be running with some patches 2021-05-10 19:22:06 my sources, to be clear: 'man tcpserver' from the Debian 10 ucspi-tcp package, and the plain qmail-1.03 sources 2021-05-10 19:23:17 ah, you're right, tcpserver doesn't drop the connection 2021-05-10 19:23:25 s6-tcpserver, which I use, does 2021-05-10 19:23:32 ah yes 2021-05-10 19:23:32 https://skarnet.org/software/s6-networking/s6-tcpserver-access.html 2021-05-10 19:23:35 I see how you might get confused :D 2021-05-10 19:24:07 well excuse me for finding ucspi-tcp insufficient and rewriting it :P 2021-05-10 19:24:26 oh, you'll get no blame from me :) 2021-05-10 19:24:34 like you i enjoy the composition of all these tools 2021-05-10 19:24:44 and like you i have also found parts lacking sometimes 2021-05-10 19:25:26 i in fact vaguely recall putting small wrappers in between that checked if TCPREMOTEHOST was set, for some situations 2021-05-10 19:25:49 makes sense 2021-05-10 19:26:39 well either way 2021-05-10 19:26:50 mx1.mailbuun.net is not mx1.mailbun.net 2021-05-10 19:26:53 :p 2021-05-10 19:27:12 hire me as a sysadmin i am very good at this 2021-05-10 19:35:03 just run all your hostnames through `uniq` 2021-05-10 19:37:25 mailbun mailbuun mailbuuuuuuuuuuuun 2021-05-10 23:35:21 where do I find default number of jobs for various archs? (CI builders) 2021-05-11 01:05:27 should a package like qt5-qtwebengine, that build and package qtwebengine-chromium, list secfixes? (chroium CVEs) 2021-05-11 04:34:35 omni: sorry, what do you mean with the default number of jobs? 2021-05-11 04:34:45 you mean for make? 2021-05-11 04:35:03 we use JOBS=$(nproc) 2021-05-11 04:57:18 omni: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L134 2021-05-11 05:10:28 maxice8: dssim fails on armv7/hf 2021-05-11 09:43:10 weird vim does not build with the updated LDFLAGS. but it builds if I re-order it 2021-05-11 09:43:23 LDFLAGS="-Wl,-O1,--as-needed,--sort-common" works 2021-05-11 09:44:17 Didn't someone mention here they do some weird persing? 2021-05-11 09:44:48 I think there even was a bug report 2021-05-11 09:46:46 good to change these just before release ;) 2021-05-11 09:47:03 Only on edge 2021-05-11 09:47:35 but we use edge to test before 'merging' 2021-05-11 09:55:35 LDFLAGS=`echo "$LDFLAGS" | sed -e 's/ *-Wl,--as-needed//g' | sed -e 's/$/ -Wl,--as-needed/'` 2021-05-11 09:55:46 looks like the offender 2021-05-11 09:56:12 ikke: ah, yes, thanks! 2021-05-11 10:41:50 ACTION >Rebuilding will cause it to re-download which in some cases may fix the problem. 2021-05-11 19:14:37 this seems like a bad idea 2021-05-11 19:15:48 clarification: showing a message like this seems like a bad idea 2021-05-11 19:15:56 ddevault: context? 2021-05-11 19:16:06 it was printed by abuild 2021-05-11 19:16:16 when I had a file that didn't match its checksum 2021-05-11 19:16:42 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L351 2021-05-11 19:16:46 in this case, redownloading it is the correct solution, but it should probably not be suggested since it's indistinguishable from a MITM attack if you don't grok it 2021-05-11 19:17:27 but if it's a mitm, shouldn't the verification fail the 2nd time as well? 2021-05-11 19:17:36 not necessarily? 2021-05-11 19:18:06 oh, I misunderstood this error 2021-05-11 19:18:14 it's written on the assumption that it's a transient network failure 2021-05-11 19:18:18 yes 2021-05-11 19:18:24 kind of weird anyway 2021-05-11 19:18:27 ACTION shrugs 2021-05-11 19:18:30 it does not tell you to regenerate the checksums 2021-05-11 19:18:53 which would indeed be bad advise 2021-05-11 19:20:04 on that note, i found it surprising and slightly unclear that 'make checksum' does do that 2021-05-11 19:20:24 abuild checksum, you mean? 2021-05-11 19:20:27 ah, yes 2021-05-11 19:20:35 was just going to say that my recollection might be hazy, from a few weeks ago 2021-05-11 19:20:48 i think freebsd ports call it 'make makesum'? 2021-05-11 19:20:55 dunno 2021-05-11 19:21:04 but abuild checksum != abuild verify 2021-05-11 19:21:08 right 2021-05-11 19:21:11 i know that now :) 2021-05-11 19:22:03 and abuild fetch runs verify 2021-05-11 19:24:19 ddevault: fyi, the commit that introduced that message: https://gitlab.alpinelinux.org/alpine/abuild/-/commit/a632d08fd2e87bb4951a99d208684bd6180cf41d 2021-05-11 19:25:40 thanks ikke 2021-05-11 19:28:27 Habbie: if you read abuild -h, it should be pretty clear :) 2021-05-11 19:28:37 'checksum Generate checksum to be included in APKBUILD' 2021-05-11 19:28:45 ikke, i didn't, i was following a manual on the wiki ;) 2021-05-11 19:29:56 It's enlightening 2021-05-11 19:31:55 yes, i did read it later :) 2021-05-11 20:32:18 Ariadne: curious if cve tracker picked up CVE-2021-3490 2021-05-11 20:47:29 c705: if it is not there, it's not there. we consume NVD feed, so it will only show up there once it shows up in NVD feed 2021-05-11 20:51:43 This one is there": https://nvd.nist.gov/vuln/detail/CVE-2021-2035 2021-05-11 20:52:23 nevermind 2021-05-11 20:55:00 yeah ok, so https://nvd.nist.gov/vuln/detail/CVE-2021-23133 is there, and affects linux <5.12, but I don't see an updated kernel for 3.13 2021-05-11 22:06:49 c705: we don't presently track CVEs for the kernel 2021-05-11 22:07:33 why? 2021-05-11 22:08:14 there is too many :D 2021-05-11 22:08:24 the APKBUILD would be 100MB 2021-05-11 22:09:13 I don't understand. the only thing that would need to change is the kernel version? 2021-05-11 22:10:10 we record what alpine version fixes what CVE 2021-05-11 22:10:41 because that does not necessarily match upstream version (we do fix things sooner) 2021-05-11 22:10:46 c705: secfixes are recorded directly in the APKBUILD for every package except kernels 2021-05-11 22:11:04 particularly since many fixes are issued out-of-band as well as in point releases 2021-05-11 22:11:29 seems like something that could be resolved. I just want my outdated kernel under 3.13 that is vulnerable to be patched 2021-05-11 22:11:47 I could start writing my own APK files, but everyone would benefit from this change 2021-05-11 22:12:08 it will be patched in the next -stable release 2021-05-11 22:12:30 rebuilding the kernel requires bumping a ton of packages (third party drivers) 2021-05-11 22:12:31 which is when? every year? 2021-05-11 22:12:46 by -stable i mean 5.10.x kernel 2021-05-11 22:13:16 stable is now on 5.12.x 2021-05-11 22:15:25 not LTS 2021-05-11 22:15:48 lts is on 5.10.36 2021-05-11 22:15:52 ok 2021-05-11 22:15:52 I have 29 2021-05-11 22:15:57 then apk upgrade -a 2021-05-11 22:15:59 wow 2021-05-11 22:16:30 oh huh 2021-05-11 22:16:35 ah there we go 2021-05-11 22:16:36 3.13 is still on 5.10.29 2021-05-11 22:16:41 yes, that is my point 2021-05-11 22:17:09 open a bug, we'll bump it in 3.13 2021-05-11 22:17:42 right, I do this every time a cve that looks bad enough comes in. i was hoping the cve tracker would be flagging those releases as EOL when lts gets bumped 2021-05-11 22:19:01 not yet 2021-05-11 22:19:04 eventually 2021-05-11 22:19:40 okay, nice to know it's in the pipeline though, thanks 2021-05-11 22:20:53 Ariadne: 2021-05-11 22:20:53 #12667 2021-05-11 22:21:18 please list the CVEs in the bug 2021-05-11 22:22:33 too many 2021-05-12 06:51:06 morning all. Re: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12657 what do you think is best, merge the security patches, or git mv thttpd sthttpd and update the APKBUILD ? Or create sthttpd package and update thttpd with a trigger stating that is going to be subsituted to sthttpd ? 2021-05-12 06:51:46 https://github.com/blueness/sthttpd states that the codebase is the same 2021-05-12 06:52:17 but with bugs and security/updates fixed 2021-05-12 06:52:28 *original codebase 2021-05-12 06:54:10 if the codebase is forked i think a separate package that provides the same package name with a higher priority would be better 2021-05-12 06:55:13 so separate sthttpd package with provides="thttpd" 2021-05-12 06:55:18 yeah 2021-05-12 06:57:44 iiuc, old one should be removed? 2021-05-12 07:00:18 is gitlab user macmpi here? 2021-05-12 07:20:10 Ariadne: who would I need to talk to to get @aerdan merged with @aerdan1 on gitlab 2021-05-12 07:22:06 morning? 2021-05-12 07:22:46 sthttpd and thttpd are two different projects, right? can we keep both so users can choose which they want use? 2021-05-12 07:25:47 ncopa, yes 2021-05-12 07:25:52 Sheila: apparently there are open gitlab feature requests to support this 2021-05-12 07:26:05 looks that thttpd is old and bugged 2021-05-12 07:26:38 but for sure that one would be the easiest and most flexible solution 2021-05-12 07:27:21 so not yet supported. Damn. Got an email on my old gmail re !21327 2021-05-12 07:27:52 unfortunately I don’t remember what email exactly I used 2021-05-12 07:28:59 Sheila: I can help you with that later 2021-05-12 07:29:17 Okay 2021-05-12 07:42:07 I've noticed the networking service deletion happened again 2021-05-12 07:42:11 on one of my servers 2021-05-12 07:42:16 this is really weird 2021-05-12 07:43:18 It happened when i tried to downgrade to latest-stable from edge 2021-05-12 07:46:37 There is just one package that owns that file 2021-05-12 07:47:04 Do you still have the apk output? 2021-05-12 07:47:09 sadly not 2021-05-12 07:47:17 i'm going to try to recreate it later 2021-05-12 08:01:27 skarnet & Ariadne: re https://skarnet.com/projects/service-manager.html and https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/. Do you also want to add support for user services, like systemd's `systemctl --user`? That is one thing I'm dearly missing from OpenRC atm and I have to work around it with hacky things like XDG autostart 2021-05-12 08:02:50 eventually 2021-05-12 08:03:08 Good, I just needed to know if it was in the planning 😉 Thanks! 2021-05-12 08:50:30 PureTryOut[m]2: when do you want to give your talk? each day is 10:00 CEST through 20:00 CEST 2021-05-12 08:50:35 Cogitri: ^ for both talks 2021-05-12 08:52:41 Well, "doing the talk", it's mainly just "when do I want my video to be shown" right? 😜 2021-05-12 08:56:47 yes 2021-05-12 08:58:51 PureTryOut[m]2: well also Q&A part 2021-05-12 08:58:55 Well since it's friday, preferably somewhere after 12:00 as I have meetings in the morning. Before 18:00 would be great as well. In between those times I don't care 2021-05-12 08:59:08 its not friday, its saturday or sunday :p 2021-05-12 08:59:14 Oh woops 2021-05-12 08:59:21 Of course, not sure where I got that from lol 2021-05-12 08:59:36 So then saturday somewhere after 12:00 as well, but otherwise no preference 2021-05-12 09:00:22 12:00 through 14:30 are open 2021-05-12 09:01:16 PureTryOut[m]2: does 13:00 sound good? 2021-05-12 09:01:27 Sure 2021-05-12 09:01:42 I'm fine with sunday as well btw 2021-05-12 09:02:11 sunday: 12:00 through 15:30 2021-05-12 09:02:51 how about 14:30 on sunday? 2021-05-12 09:03:02 Either way is fine by me 2021-05-12 09:03:19 there is also 17:00/17:30 that are open 2021-05-12 09:03:30 but i kind of want to keep that as a break period 2021-05-12 09:03:46 if we can 2021-05-12 09:04:14 i'll just go with 14:30 2021-05-12 09:07:09 Ariadne: +1 for before 18:00 2021-05-12 09:07:18 Also, where do I upload my stuff? 2021-05-12 09:07:26 wherever you want 2021-05-12 09:07:41 bigbluebutton will stream it from youtube or whatever 2021-05-12 09:08:02 Cogitri: you have two talks. do you want me to split them across days? 2021-05-12 09:08:30 Oh, somehow I figured I'd have to upload it to Alpine Infra somehow 2021-05-12 09:08:47 i am pretty sure alpine infra would prefer you not do that 2021-05-12 09:09:08 the way bigbluebutton embeds videos is by telling the streamer to play the video themselves 2021-05-12 09:09:21 so :p 2021-05-12 09:10:08 the way it works is that there is a button, and we paste in the URL to your talk, either youtube, vimeo, dailymotion or a URL to an MP4 2021-05-12 09:10:12 'bigbabblebutton' :) interesting and it is free 2021-05-12 09:10:28 mps: yes, alpineconf is powered 100% by free softare 2021-05-12 09:10:31 software* 2021-05-12 09:10:31 Oh, I had expected BBB would stream the file by itself 2021-05-12 09:10:45 yes i did too 2021-05-12 09:10:49 but turns out not 2021-05-12 09:11:48 so, I can set some video on my server and BBB will stream it? 2021-05-12 09:12:10 i think what will happen is that each viewer will stream it from your server 2021-05-12 09:12:11 :p 2021-05-12 09:12:11 Anyway, about the talk timing: It'd be nice if I had both talks on Saturday, but I don't mind if they're on different time slots 2021-05-12 09:12:25 oh my 2021-05-12 09:12:47 hmm idea: put them on dl-cdn.a.o somehow 2021-05-12 09:12:49 :) 2021-05-12 09:13:05 and as plain video file? 2021-05-12 09:13:09 yes 2021-05-12 09:13:17 that's good 2021-05-12 09:13:37 i'm sure it would be possible to do it 2021-05-12 09:13:57 ikke: what do you think about putting some alpineconf videos on dl-cdn.a.o somehow? 2021-05-12 09:15:04 (for those who don't want to deal with youtube or whatever) 2021-05-12 09:17:31 Cogitri: 14:00/14:30 ? 2021-05-12 09:17:35 Cogitri: on saturday 2021-05-12 09:18:22 We can host them somewhere 2021-05-12 09:24:06 Ariadne: Sounds good 2021-05-12 09:26:39 ikke: 2021-05-12 09:26:51 this gets struck at analyzing dependencies 2021-05-12 09:26:52 CTARGET=aarch64 BOOTSTRAP=nobase APKBUILD=/root/aports/main/binutils/APKBUILD abuild -r -F 2021-05-12 09:26:55 any idea why? 2021-05-12 09:27:12 while running on x86_64 2021-05-12 09:33:48 proycon: which day would you prefer to give your talk on? 2021-05-12 09:33:57 okie manually installing the required dependencies clears the error 2021-05-12 09:33:58 thank you 2021-05-12 09:38:49 Ariadne: ah! let me check whether my co-maintainer has a preference 2021-05-12 09:41:12 i'm trying to keep earlier timeslots for european speakers so that US speakers do not have to do their talks at 3 AM unless they are nightowls :) 2021-05-12 09:41:28 Ariadne: I guess he's asleep, but I don't think we have a strong preference either way .. only preference i have is not too early :) 2021-05-12 09:42:05 proycon: 13:30 CEST on sunday? 2021-05-12 09:43:12 my co-maintainer is in Toronto actually (we'll be doing it together anyway), so that may be a bit early for him 2021-05-12 09:43:43 16:30 CEST on saturday? 2021-05-12 09:43:59 that is probably better yes, let me do the math :) 2021-05-12 09:44:22 10:30 2021-05-12 09:44:27 :) 2021-05-12 09:44:58 that will work I think yes :) 2021-05-12 09:45:10 I'll double-check when he's awake again 2021-05-12 09:51:35 okay 2021-05-12 09:52:11 i have a later slot on saturday and sunday but they are blocked out right now as one of those is going to become a 1-hour talk 2021-05-12 09:52:33 for somebody who is pacific time zone :p 2021-05-12 10:18:23 MartijnBraam: when would you like to do the postmarketOS demo? there are 11:00, 11:30, 13:00, 13:30, 16:00 slots on may 15, or 10:30, 11:00, 11:30, 13:00, 13:30, 15:00, 17:00 slots on may 16 2021-05-12 10:21:08 What time zone is that? :P 2021-05-12 10:21:16 MartijnBraam: CEST 2021-05-12 10:22:22 I guess the 16:00 slot on the 15th 2021-05-12 10:22:50 okay done 2021-05-12 10:26:58 https://docs.google.com/spreadsheets/d/1NQ-qADgsh0ixKITch4ennMma3buMkaBlo6zjKpI0uSY/edit#gid=0 is the preliminary schedule 2021-05-12 10:27:08 i am still waiting on ollieparanoid[m] to get back to me :) 2021-05-12 10:28:14 that sounds nice, then the postmarketOS demo is before the sxmo talk, which makes sense :) 2021-05-12 10:29:47 I'm assuming MartijnBraam won't show off sxmo in his talk? 😜 2021-05-12 10:29:56 nice "Lunch" talk :P 2021-05-12 10:33:48 did you know your refrigerator is filled with snacks? 2021-05-12 10:34:06 I eeeh, do show sxmo a bit 2021-05-12 10:34:35 yoloooooo 2021-05-12 10:34:38 :) 2021-05-12 10:35:29 well 15 years ago i wouldn't have ever thought we would be having this 2021-05-12 10:35:32 sooooo :) 2021-05-12 10:35:40 is https://bbb.dereferenced.org/b/adm-ec4-bx7-ypm the official URL for follow the conference? 2021-05-12 10:35:45 yes 2021-05-12 10:35:47 MartijnBraam: I guess keep it short if you can. And discuss with proycon what exactly you're going to show 2021-05-12 10:35:51 ok 2021-05-12 10:35:55 next time it will be on alpinelinux.org URL 2021-05-12 10:36:09 I think I can still create a redirect 2021-05-12 10:36:16 this time i had to pull a solution out of thin air at last minute 2021-05-12 10:36:20 because well 2021-05-12 10:36:21 I show it for like a minute, showing me tiling, a terminal and launching firefox 2021-05-12 10:36:23 that is how i do things 2021-05-12 10:36:28 sink or swim etc 2021-05-12 10:36:44 it's not a great way of doing things, but it works for me 2021-05-12 10:37:00 it seems great Ariadne , I just asked to know if there we other url :P 2021-05-12 10:37:17 oh no, cookies ;> 2021-05-12 10:37:17 MartijnBraam: cool :) 2021-05-12 10:37:26 anyway if anyone else ants to do a talk at the last minute 2021-05-12 10:37:27 can't it at least be a redirect from alpinelinux.org? 2021-05-12 10:37:31 MartijnBraam: yes 2021-05-12 10:37:44 > next time it will be on alpinelinux.org URL 2021-05-12 10:37:44 A quick workaround could be a redirect ? 2021-05-12 10:37:50 yes 2021-05-12 10:37:51 we are already planning to do another one in fall 2021-05-12 10:37:53 I suggested that 2021-05-12 10:37:57 Ah MartijnBraam was just before me :D 2021-05-12 10:37:58 ikke: make it soooooooo 2021-05-12 10:38:52 let us also not discuss that the server we are using is powered by not alpine 2021-05-12 10:39:02 omg 2021-05-12 10:39:05 when the conf 2021-05-12 10:39:06 although it could have been powered by alpine in retrospect 2021-05-12 10:39:09 date? 2021-05-12 10:39:16 may 15 and 16 2021-05-12 10:39:28 time? 2021-05-12 10:39:36 i will join in thank you!!! 2021-05-12 10:39:38 10:00 CEST 2021-05-12 10:39:42 until whenever 2021-05-12 10:39:50 we might extend the 15th by an hour or two 2021-05-12 10:39:55 to allow for uhh 2021-05-12 10:39:56 more time 2021-05-12 10:40:02 for US/Pacific speakers 2021-05-12 10:40:17 hmmmm 2021-05-12 10:40:53 https://alpinelinux.org/conf/ 2021-05-12 10:44:45 ikke: is there any chance for that OOM/KILL problems have dissapeared? or better try with limited JOBS? 2021-05-12 11:05:45 PureTryOut[m]2: user services open a whole category of problems to solve that are absent from 'booting' services, in particular security problems and *a lot* of policy questions 2021-05-12 11:06:08 sure, they can be added, but it will have to be as a second part 2021-05-12 11:06:58 hince 'eventually' 2021-05-12 11:07:00 :P 2021-05-12 11:07:01 Hmm, that's fine I guess. But the lack of user services is definitely a pain point in OpenRC for me. I mainly want to have it on the roadmap, we'll see when it actually gets implemented 2021-05-12 11:07:03 yeah 2021-05-12 11:07:30 one example of policy question is 2021-05-12 11:07:55 do you want a user service to run: always? or when a user logs in? both possibilities? 2021-05-12 11:08:21 problem is 'when a user logs in' is not clearly defined: console? VT? xdm? remote? 2021-05-12 11:08:40 part of why systemd is so big is that it attempts to answer all of this and it's not trivial at all 2021-05-12 11:08:54 we shouldn't make the same mistake 2021-05-12 11:10:07 ideally you want maximum flexibility (allow a user to define stuff that runs always/when logging in via ssh/when logging in on a display manager/...) but you have to balance it against simplicity and usability as well 2021-05-12 11:10:28 Not sure what systemd does. I guess on logging in, either in console or graphical session, and quits it when all sessions are logged out. But I have no clue 2021-05-12 11:10:52 so you're asking for a feature and you're not sure what exactly the feature is? :P 2021-05-12 11:11:22 I'm not sure what systemd does. I just know I want services to run on user login, things like Pipewire with it's several daemons, in the user context 2021-05-12 11:12:12 yeah, running things on user login is a very different set of problems than running things at boot time and is mostly policy questions 2021-05-12 11:12:19 That I understand 2021-05-12 11:12:30 it will be possible eventually, as Ariadne says 2021-05-12 11:12:41 Yeah I got that, that's fine 😉 2021-05-12 11:13:01 Let's first have it as a proper OpenRC replacement before slapping on more features 2021-05-12 11:13:16 yup 2021-05-12 11:17:16 skarnet: im curious what you think about finit? 2021-05-12 11:20:10 never tried it myself 2021-05-12 11:20:37 at first glance it looks like a regular traditional sequential service manager with some process supervision added 2021-05-12 11:20:55 so, feature-wise, exactly equivalent to openrc 2021-05-12 11:21:10 the implementation may be better 2021-05-12 11:27:47 i havent used it either, but i think it looks nice 2021-05-12 11:31:40 it does. 2021-05-12 11:32:07 ^ url: https://troglobit.com/projects/finit/ 2021-05-12 11:32:56 with a PoC for Alpine: https://github.com/troglobit/finit/tree/master/contrib/alpine 2021-05-12 11:54:30 i wonder why he build libuev insteado just use libev 2021-05-12 12:01:54 even libev wouldn't be good 2021-05-12 12:02:15 event management frameworks are a complete red herring unless you're doing high-perf c10k 2021-05-12 12:02:30 (spoiler: in a service manager, you don't) 2021-05-12 12:03:55 in 98% of cases poll() is all you need, and attempts to leverage non-portable event functions such as epoll() or kqueue() is both needless complexity and a waste of programmer time 2021-05-12 12:08:33 that is why runit is so good :) 2021-05-12 12:08:48 I think s6 also 2021-05-12 12:10:23 if we have to switch from openrc s6 is option (or runit) 2021-05-12 12:12:38 https://gitlab.alpinelinux.org/donoban/aports/-/jobs/390337 killed :( 2021-05-12 12:14:50 I'm waiting one nice morning when the gitlab will be killed ;) 2021-05-12 12:16:16 I think that last time it worked for x86_64 2021-05-12 12:17:17 it seems that it ignored the JOBS limit, there are 43 killed messages, well, it's time for have lunch, see you 2021-05-12 12:19:24 Ariadne: what's the general format for a 25min slot? 20 min talk, 5 min questions? or more like 15:10? 2021-05-12 12:26:03 mps: why? 2021-05-12 12:36:34 jvoisin: what? 2021-05-12 12:43:20 whats wrong with openr 2021-05-12 12:43:22 whats wrong with openrc 2021-05-12 12:43:47 It's limited 2021-05-12 12:44:15 how about System V 2021-05-12 12:45:25 openrc is not limited but people want systemd on alpine :P 2021-05-12 12:45:56 mps: why do you want the gitlab to get killed :/ 2021-05-12 12:46:17 jvoisin: it is horrible 2021-05-12 12:46:57 says someone who advocated switching alpine to gitlab from patchwork :) 2021-05-12 12:47:31 insider from my company: gitlab isnt less shitty even with premium support 2021-05-12 12:48:01 still better than everything else 2021-05-12 12:48:20 it sucks for the people having to keep it running 2021-05-12 12:48:28 only CI part is useful 2021-05-12 12:49:10 issues and MR as well 2021-05-12 12:49:12 monolithic systems are bad 2021-05-12 12:49:17 btw, the gitlab omnibus install uses systemd to launch a own runit instance 2021-05-12 12:49:51 patchwork is the best 2021-05-12 12:50:54 gitlab is pretty low maintenance for us 2021-05-12 12:51:20 and it's newbies-friendly 2021-05-12 12:51:38 jvoisin: this is worst part in it 2021-05-12 12:53:15 because of 'newbies-friendly' alpine starting to looks like 'trashcan' 2021-05-12 12:54:39 Alpine should only for the elite, ofcourse 2021-05-12 12:55:48 ikke: +1 2021-05-12 12:55:49 full of arcane awkward/backward processes because "we always did it like this and it works" 2021-05-12 12:56:10 same way like only the "elites" should set up house electrics or build bridges 2021-05-12 12:56:35 IT seems to be only field of engineering where having no experience is not seen as a barrier 2021-05-12 12:57:00 ikke: you want mission critical OS where all trash can be put? 2021-05-12 13:25:14 Ariadne: would be good if AlpineConf videos could be hosted elsewhere than the likes of YouTube (which doesn't work if you happen to block doubleclick.net for example) 2021-05-12 13:28:49 youtube definitely doesn't require doubleclick.net, at least with ublock origin 2021-05-12 13:29:41 Hello71: it does when you get the "consent to cookies" page and customise cookies - it "silently" redirects via doubleclick.net 2021-05-12 13:30:22 use `mpv` to watch the video? 2021-05-12 13:31:31 ^ if ones youtube-dl version isnt recent enough, i use manually updated youtube-dl with alpines mpv and it works to my satisfaction 2021-05-12 13:32:40 i mean i agree with avoiding youtube 2021-05-12 13:33:10 but reducing the load on the organizers is also important :) 2021-05-12 13:48:30 synapse fails on builders with 'ERROR:root:Needed cryptography>=3.4.7, got cryptography==3.3.2' 2021-05-12 14:26:36 spotted a behaviour with the Ec2 data source which could be argued whether or not its a bug - basically if you boot a c-i enabled image on KVM/Qemu where the Ec2 DataSource happens to be enabled then a dmi-related warning appears in the cloud-init.log but also on the console during boot. Basically with KVM/QEMU /sys/class/dmi/id/systemuuid doesn't exist and if you don't have "dmidecode" installed then the Warning is triggered 2021-05-12 14:27:29 only the Ec2 DataSource triggers this 2021-05-12 14:27:43 oops, wrong channel. doh! 2021-05-12 14:40:54 Ariadne: could probably advertise alpineconf in news (so it appears in https://alpinelinux.org/)? otherwise people looking for it might have a hard time finding it 2021-05-12 15:05:50 friends 2021-05-12 15:06:02 can anyone tell me how does lbu work 2021-05-12 15:06:13 especially in an embedded device like rpi 2021-05-12 15:06:33 where the filesystem is in tmpfs 2021-05-12 15:07:29 lbu commit will use apk to detect which files in /etc/ has been modified and generate a tarball of those files 2021-05-12 15:07:45 and store the apkovl tarball on the configured media 2021-05-12 15:07:51 (eg on the SD card) 2021-05-12 15:07:53 for example when i run "apk add make" for in-memory alpine, how does lbu commit ensure that "make" is retained for the nextbook 2021-05-12 15:08:05 next boot* 2021-05-12 15:08:29 lbu commit will detect that /etc/apk/world was changed and include it in the apkovl file 2021-05-12 15:08:43 ooh! 2021-05-12 15:08:57 during boot the initramfs will look for *.apkovl* and try to restore the system if found 2021-05-12 15:09:16 along with installing any apks that were found in world right? 2021-05-12 15:09:24 correct 2021-05-12 15:09:58 this is a fantastic thought, gives a snapshot like ability which is harder to replicate even in zfs and btrfs 2021-05-12 15:10:10 hats of to you ncopa 2021-05-12 15:10:51 :) 2021-05-12 15:10:53 one last question though how does lbu commit know to save the downloaded apks cache 2021-05-12 15:10:59 like make.apk 2021-05-12 15:11:17 it actually doesnt know about it 2021-05-12 15:11:18 how are they saved to disk during an in-memory operation 2021-05-12 15:11:45 but normally an apk cache is configured with setup-alpine 2021-05-12 15:11:50 aha 2021-05-12 15:12:00 so if the cache is configured they are saved 2021-05-12 15:12:05 its just a /etc/apk/cache symlink that points to the cache 2021-05-12 15:12:08 yes 2021-05-12 15:12:24 the /etc/apk/cache symlink gets included in the apkovl tarball 2021-05-12 15:12:34 thanks ncopa: 2021-05-12 15:13:53 np 2021-05-12 15:46:36 ddevault: are there any download tarball of scdoc available that has consistent checksum? 2021-05-12 15:47:44 scdoc-1.11.1.tar.gz: FAILED 2021-05-12 15:47:44 sha512sum: WARNING: 1 of 1 computed checksums did NOT match 2021-05-12 15:47:44 Rebuilding will cause it to re-download which in some cases may fix the problem. 2021-05-12 15:47:44 Because the remote file above failed the sha512sum check it will be renamed. 2021-05-12 15:47:44 Renaming: scdoc-1.11.1.tar.gz to scdoc-1.11.1.tar.gz.28b676a2 2021-05-12 15:47:57 I thought they fixed that on sr.ht 2021-05-12 15:48:51 they proabaly did, but the checksum is different now than when we downloaded it to our distfiles 2021-05-12 15:49:32 they changed compression level iirc 2021-05-12 16:24:19 ncopa: the checksum you see now should be consistent 2021-05-12 16:24:28 we fixed it several months ago 2021-05-12 16:24:41 (made consistent with GNU gzip, rather than changed the compression level) 2021-05-12 16:25:25 arch linux has it as cd6ac88fc9db48efaae0df0f6472a18e28f92fc2735fee18c07516fd358e9c0921eae9d944020eacd08285bbf59fbcc1d389a6565cef29fc50ad511ee5e7fa9f 2021-05-12 16:25:56 this is also what I see 2021-05-12 16:26:23 maybe a transient network issue? 2021-05-12 16:28:04 Hmm, the hash in the APKBUILD is 28b676a2ba69a101034c47378c4b66c94bfb9903d680a1871020fd8772d0990a4c91678738f71d37bfca06e27991ef782047c6503d375ce69df744caf6b459de 2021-05-12 16:29:04 hm, actually, that is what it had before, and arch changed it on march 20th 2021-05-12 16:29:13 lemme see if that corresponds to any git.sr.ht changes 2021-05-12 16:29:15 https://distfiles.alpinelinux.org/distfiles/scdoc-1.11.1.tar.gz 2021-05-12 16:29:24 that's the file on distfiles 2021-05-12 16:30:15 there was a change in how UTF-8 ref names are handled, but I would not have expected that to cause a change in the checksums 2021-05-12 16:30:42 I'll investigate further when I get back from vacation 2021-05-12 16:30:47 enjoy 2021-05-12 16:30:58 it looks like the new checksum has been valid for at least a couple of months so we shouldn't expect another sudden change 2021-05-12 16:40:58 i have seen on-the-fly generated tarballs from git change when cgit was updated, even if there was no timestamp in gz header 2021-05-12 16:41:21 what i did was to have a git hook on server that would git archive it and upload the file to some place 2021-05-12 16:41:51 that way it no longer depend on the auto-generation be identical 2021-05-12 16:49:46 diffoscope reports this change: https://tpaste.us/nW8r 2021-05-12 16:50:05 so its the compression level that differs 2021-05-12 16:52:12 So it's that one time change 2021-05-12 16:53:18 i guess we'll just have to update the checksum til next one-time-change happens 2021-05-12 16:54:37 same with github (barring releases) and gitlab 2021-05-12 16:54:46 yeah 2021-05-12 16:55:25 i wonder if we could have some git hook for our gitlab to download the tarballs to some file server when we tag releases 2021-05-12 16:55:59 ncopa: gitlab has support for this now 2021-05-12 16:56:06 Just need to look into how to set the pipelines up for it 2021-05-12 16:56:10 cool 2021-05-12 16:56:25 https://gitlab.com/gitlab-org/release-cli 2021-05-12 16:56:35 woudl be great for hosted projects like apk-tools, abuild etc 2021-05-12 16:56:46 yes 2021-05-12 16:56:59 I was looking into it also for apk-tools-static 2021-05-12 16:57:06 but didn't get to actually implementing it yet 2021-05-12 18:27:41 I packaged a fork of mmsd, called mmsd, but now that fork is being renamed. do folks recommend I remove the old package and push a new one with the new name, or keep the old name for the package, or ?? 2021-05-12 18:28:17 or use provides=mmsd in the new package so that it can still be pulled in by anything that depends on mmsd? 2021-05-12 18:28:26 I'm just unsure of the 'recommended' way to handle that 2021-05-12 18:45:04 craftyguy: replaces=mmsd 2021-05-12 18:45:20 provides + replaces 2021-05-12 18:45:51 yes, both are ok, but replaces is 'first' 2021-05-12 18:46:10 the role of replaces is very limited actually 2021-05-12 18:46:49 man APKBUILD says 'This is typically used for packages renamed by upstream.' 2021-05-12 18:47:36 provides is more about two packages which provides same 'utility' 2021-05-12 18:59:22 I'm new to alpine; looking at the wiki and package policies page, and I have some questions about versions 2021-05-12 19:00:55 For example, it says "Package versions are similar to gentoo" but gentoo doesn't seem to say much about versions.    Are there some expectations not yet documented? 2021-05-12 19:05:26 Yes, there are some expectations 2021-05-12 19:09:59 bitminer: apk version --check will return invalid versions 2021-05-12 19:13:43 So, for example, software follows semantic versioning (semvers.org) or dates (e.g. hwids is 20201207); how about subsequent patches, like fixes or security patches? 2021-05-12 19:14:33 the basic form is 1.2.3-r0 2021-05-12 19:14:45 where 1.2.3 is pkgver and r0 means revision 0 (from pkver) 2021-05-12 19:15:19 openssl uses letters for patches, so they are supported 2021-05-12 19:15:21 1.2.3a 2021-05-12 19:15:55 there are certain suffixes that indicate the version should be considered before (alpha / beta) or after (git) 2021-05-12 19:16:38 so 1.2.3_alpha1 or 0_git123123 2021-05-12 19:32:22 OK, cool.  I'll update wiki with this. 2021-05-12 19:33:21 https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/version.c#L73 2021-05-12 19:33:33 there you see the post_suffixes and pre_suffixes 2021-05-12 20:51:55 hey, all! 2021-05-12 20:52:09 Ariadne: I'll take May 15th 11:00, then there's not such a huge gap :) 2021-05-12 20:52:33 okay 2021-05-12 20:52:34 cool 2021-05-12 20:54:12 I think !21145 should be good to go now 2021-05-12 21:45:07 mps, ikke: sorry I'm a little unclear, you're suggesting I use both provides and replaces? 2021-05-12 21:46:38 craftyguy: yes 2021-05-12 21:47:18 ok thanks :) 2021-05-12 21:59:13 Ariadne: not sure if this was discussed before, but will everything in the main room be recorded? then we'd have the talks + following Q&A sessions etc 2021-05-12 22:01:59 and while at it: folks are wondering if the 50 / 25 min times include the time for the Q&A or not. I assume not, but would be good if you could clarify 2021-05-12 22:07:23 ollieparanoid[m]: the idea is that 25 minutes is actually 30 minutes, and 50 minutes is actually 60 minutes 2021-05-12 22:07:35 so, ideally, 25 minutes talk, 5 minutes QA 2021-05-12 22:07:41 50 minutes talk, 10 minutes QA 2021-05-12 22:07:50 bluntly, i don't really care so much how the timeslot is used :) 2021-05-12 22:08:13 okay :) 2021-05-12 22:08:16 proycon ^ 2021-05-12 22:08:17 if you want to have 5 minutes talk, 25 minutes QA, or 10 minutes talk, 10 minutes demo, 10 minutes QA, or whatever 2021-05-12 22:08:22 it doesn't matter to me 2021-05-12 22:08:48 note that we would want to wrap up a minute or two early 2021-05-12 22:08:48 oh!! right, thanks! :) 2021-05-12 22:08:54 so lets say 2021-05-12 22:09:01 25 minute talk is really 28 minutes or so 2021-05-12 22:09:10 and 50 minute talk is really 58 minutes 2021-05-12 22:09:11 and so on 2021-05-12 22:09:23 got it 2021-05-12 22:09:25 you can partition it however you want 2021-05-12 22:09:30 I'm editing our video now, we're trying to be pretty concise and quick, but perhaps we can add some more even 2021-05-12 22:09:33 just try not to go over 30 minutes :) 2021-05-12 22:09:49 (or 60 minutes) 2021-05-12 22:10:17 Ariadne: will talks and q&a get recorded and uploaded somewhere, so it's all in one place etc? 2021-05-12 22:10:18 for those wanting something else to watch after an exciting day of alpine talks, there will be the outline demo party going on in parallel :) 2021-05-12 22:10:22 I doubt my talk will be full 25 minutes though 2021-05-12 22:10:38 Currently all clips recorded and cut but no commentary yet is ~15 minutes for me 2021-05-12 22:10:40 PureTryOut[m]2: cool, you can split it up into however you want :) 2021-05-12 22:11:01 basically you get ~30 minutes :) 2021-05-12 22:11:17 do with it whatever you want, as long as it's appropriate 2021-05-12 22:11:25 so, like, no streaming goatse 2021-05-12 22:11:29 or whatever :p 2021-05-12 22:11:45 lol 2021-05-12 22:12:35 also there's a few slots open still for anything anyone wants to do 2021-05-12 22:13:28 ollieparanoid[m]: regarding recording, yes, bigbluebutton has the ability to record the Q&A part 2021-05-12 22:13:42 we will combine the Q&A part with any prerecorded part 2021-05-12 22:13:47 and publish it :) 2021-05-12 22:13:54 awesome :) 2021-05-12 22:14:46 that may take a few days :) 2021-05-12 22:14:51 ACTION uses his other 15 minutes to shil Windows 2021-05-12 22:14:59 :D 2021-05-12 22:15:22 well they /are/ bringing us the year of the linux desktop 2021-05-12 22:15:48 every time I hear that phrase I'm concerned my eyes are gonna pop out due to how hard I'm rolling them. 2021-05-12 22:17:31 i hope the blade i installed the BBB server on has enough storage for video though 2021-05-12 22:17:39 it only has 2x256GB SSDs 2021-05-12 22:17:41 in raid1 2021-05-12 22:18:19 (my x86 blade system is designed for HPC stuff using kubernetes, not for this) 2021-05-12 22:19:43 Ariadne: would it be possible to get a test room url for bbb? 2021-05-12 22:22:00 sandbox room: https://bbb.dereferenced.org/b/ari-juu-ka4-emx 2021-05-12 22:22:05 anyone should be able to start it 2021-05-12 22:22:15 it should also make you a moderator 2021-05-12 22:23:26 works :-) 2021-05-12 22:25:18 what i don't understand is 2021-05-12 22:25:23 i installed ubuntu on that machine 2021-05-12 22:25:31 just to have it go and install a bunch of alpine containers 2021-05-12 22:25:47 i don't get why bigbluebutton doesn't just say "install alpine" 2021-05-12 22:25:48 haha 2021-05-12 22:27:36 `"but alpine is for containers.." 2021-05-12 22:28:29 did you consider tweaking the stun/turn settings? 2021-05-12 22:29:33 regarding storage, I suggest keeping an eye on it during the conference and if necessary, move the already recorded files to another server (maybe during a break or something) 2021-05-12 22:29:34 liske: i haven't. they just use the google ones 2021-05-12 22:29:59 if you can send me a mail walking me through what to do, i can change it to better ones 2021-05-12 22:32:43 I did not yet got a deeper look on bbb 2.3 but have much experiences with bbb 2.2... but 2021-05-12 22:33:53 all i know is 2021-05-12 22:33:57 bbb-install.sh 2021-05-12 22:33:58 is basically 2021-05-12 22:34:01 apt install docker 2021-05-12 22:34:06 then a bunch of docker shit 2021-05-12 22:35:09 one need a dedicated host, latest coturn (debian bpo or ubuntu 20.04) and a non LE certificate (for the apple guys) 2021-05-12 22:35:47 and a sensible turnserver.conf 2021-05-12 22:36:00 sounds like a lot of work :D 2021-05-12 22:36:09 we will do it next time around :P 2021-05-12 22:37:04 https://docs.bigbluebutton.org/2.2/setup-turn-server.html 2021-05-12 22:38:39 the turnserver.conf is valid but the LE cert is not working for apple devices 2021-05-12 22:38:58 yeah unfortunately my budget for SSL certificates is $0 :p 2021-05-12 22:53:29 what?? 2021-05-12 22:58:28 ? 2021-05-12 22:58:56 dalias: which scandalous thing are you reacting to 2021-05-12 22:59:06 - the fact that i installed ubuntu on something 2021-05-12 22:59:16 - the fact that bbb-install just installs docker anyway 2021-05-12 22:59:33 - apple devices don't accept lets encrypt certs for WebRTC 2021-05-12 23:05:13 the third 2021-05-12 23:08:26 https://bugs.webkit.org/show_bug.cgi?id=219274 2021-05-12 23:10:21 has been fixed months ago but I did observe the problem in the wild two weeks ago (with sleepless debugging nights) 2021-05-12 23:11:01 eeew they used some google library where google hard-coded the list of CAs that google uses ?!? 2021-05-12 23:12:14 i think we should keep the default servers this time then 2021-05-12 23:12:32 maybe for mini alpineconf in the fall, that bug will have a fix fully deployed 2021-05-12 23:18:02 without turn people behind weird CGN or being required to use a proxy will fail with WebRTC: listen only, no webcams, no screen sharing 2021-05-12 23:50:54 hmm, i am being CGN and screenshare worked for me 2021-05-12 23:50:58 behind* 2021-05-12 23:51:49 though i do have ipv6 2021-05-12 23:53:14 ipv6 helps a lot 2021-05-12 23:57:47 ok well i will set up coturn tomorrow :P 2021-05-12 23:58:18 i think i will take that opportunity to attach a 1TB SAN volume to where bigbluebutton stores its recordings 2021-05-13 00:02:09 did I mention that a coturn server with LE cert will kill safari's webrtc also in cases where webrtc without turn would work? 2021-05-13 00:04:06 what I'm hearing here is Apple's shit is fucked. 2021-05-13 00:35:11 sounds like it ... 2021-05-13 05:16:32 is modloop the trick to keep the memory usage from exploding in alpine-from-memory system? 2021-05-13 05:16:44 i believe it is not mounted onto the main tmpfs filesystem? 2021-05-13 05:16:59 just symbol linked? 2021-05-13 05:17:03 am i correct? 2021-05-13 05:17:13 oneinsect: yes, it *is* mounted though 2021-05-13 05:17:31 if its mounted then its going to eat lots of ram right? 2021-05-13 05:17:48 no 2021-05-13 05:18:14 hmmmm 2021-05-13 05:18:18 being mounted does not mean it takes space from that filesystem 2021-05-13 05:18:33 so its not on tmpfs if thats what you mean? 2021-05-13 05:18:39 correct 2021-05-13 05:18:55 it's mounted as a loop device 2021-05-13 05:19:22 man there is some clever engineering that was done by you folks to squeeze alpine into memory constrained spaces 2021-05-13 05:19:48 generally debian kernel with all modules goes to like 180MB easily 2021-05-13 05:38:19 oneinsect: no worries, our kernels also grows. they are not big as debian ones because not yet grown up 2021-05-13 05:38:41 and, namaste namaste :) 2021-05-13 05:38:53 lol namaste mps: 2021-05-13 05:41:01 modlopp contains only kernel modules and can be unmounted after boot 2021-05-13 05:41:40 unless you need new kernel modules 2021-05-13 05:41:46 like when attaching usb devices 2021-05-13 05:41:47 right 2021-05-13 05:42:05 or setting up tunnels 2021-05-13 05:42:13 I say 'can be' 2021-05-13 05:42:22 not must be ;) 2021-05-13 05:43:22 if one knows that the modules are not needed after boot (I should write above) 2021-05-13 05:43:45 or, umnount and mount again if you need them 2021-05-13 05:44:50 but there are use cases where modules are not needed after boot 2021-05-13 05:45:52 so mps say for rpi zero which has just 512MB this ideology works perfectly, i am really pleased 2021-05-13 05:46:24 the fact that it is not being loaded into tmpfs saves a lot of memory 2021-05-13 05:47:46 docker itself requires iptables, not? 2021-05-13 05:49:42 oneinsect: I test alpine releases on rpi zero w, which have only 256MB 2021-05-13 05:50:12 indeed 2021-05-13 05:50:17 and one old nokia n900 phone, also 256MB iirc 2021-05-13 05:50:46 for some tests I use qemu with 128MB RAM 2021-05-13 05:54:48 ummmm 2021-05-13 09:30:41 looks like we have a problem with binutils on mips64 2021-05-13 09:30:46 generated_.._test-build-pedantic-unstable_xdg_decoration_xdg_decoration_unstable_v1_xml.c.o tests/test-build-pedantic-unstable_xdg_decoration_xdg_decoration_unstable_v1_xml.p/meson-generated_.._xdg-decoration-unstable-v1-code.c.o -Wl,--as-needed -Wl,--no-undefined -pie -Wl,--as-needed,-O1,--sort-common -Os -Os -Wl,--unresolved-symbols=ignore-all 2021-05-13 09:30:46 -Wl,--start-group -lwayland-client -lwayland-server -Wl,--end-group 2021-05-13 09:30:54 /usr/lib/gcc/mips64-alpine-linux-musl/10.3.1/../../../../mips64-alpine-linux-musl/bin/ld: BFD (GNU Binutils) 2.35.2 assertion fail elfxx-mips.c:6747 2021-05-13 09:32:57 :D 2021-05-13 09:33:03 probably due to -O1,--sort-common 2021-05-13 09:33:05 :P 2021-05-13 09:50:51 happens without those too 2021-05-13 09:51:53 can someone help follow that up? 2021-05-13 09:54:45 i can dig into it today 2021-05-13 10:02:20 thanks 2021-05-13 10:02:42 im bootstrapping the 3.14 servers (except ppc64le for now) 2021-05-13 10:06:43 !18096 2021-05-13 10:16:35 :D 2021-05-13 10:27:04 is anyone else having issues with 'cargo build' packages? I have one that download a bunch of crates and then just hang there until ci timeout 2021-05-13 10:27:57 does it build locally ? 2021-05-13 10:28:20 unfortunately, cargo is not a very talkative build systeem 2021-05-13 10:28:43 yes, it does, also downloading fewer crates 2021-05-13 10:29:11 !20973 2021-05-13 10:30:22 idk 2021-05-13 10:30:27 I first thought, ~a week ago, that it was temporary and re-triggered runs a couple of times 2021-05-13 10:31:42 but today I also tried the beta-release, adding makedependencies, reverting to the version I'm trying to upgrade from and just bumping pkgrel, with the same "outcome" 2021-05-13 10:36:16 strange :) 2021-05-13 10:39:01 I blame corroded pipelines 2021-05-13 10:52:27 curl and cmake has circular deps 2021-05-13 11:21:20 https://www.alpinelinux.org/conf/ 2021-05-13 11:22:57 ikke: maybe add an explaination for the colour-code? 2021-05-13 11:23:21 jvoisin: right, was meant to, but forgot 2021-05-13 11:23:25 thanks 2021-05-13 11:24:49 ♄ 2021-05-13 11:25:13 looks like as useless babbling :) 2021-05-13 11:28:57 jvoisin: something like this? https://i.imgur.com/1s5m10S.png 2021-05-13 11:33:08 CEST la vie 2021-05-13 11:35:42 !20973 looks ok to merge 2021-05-13 11:35:48 uh no 2021-05-13 11:36:24 this one !19793 2021-05-13 11:40:02 ikke: perfect 2021-05-13 12:12:37 ugh... it was me who broke curl->brotli->cmake->curl circular dep in b0b18e719e8ab707203e5f76826d0a4fa6348feb 2021-05-13 12:28:01 ncopa: I know you are busy (who is not) but could you give a hint where in scripts to look for creating armv7 iso 2021-05-13 12:28:36 I'm lost in shell scripting 2021-05-13 12:37:49 ACTION feels alone in this cruel world :) 2021-05-13 13:14:17 scripts/mkimg.arm.sh 2021-05-13 13:14:34 look how mkimg.base.sh does it 2021-05-13 13:22:25 looking 2021-05-13 13:39:46 setting CARGO_BUILD_JOBS=1 seem to work... 2021-05-13 13:40:04 https://gitlab.alpinelinux.org/alpine/abuild/-/commit/69aea2246288c37b7f2961d7a31983465eb925a5 2021-05-13 13:40:52 Ariadne: when I said it build locally, I don't run abuild 2021-05-13 13:41:18 does this work on the package builders but not the CI builders or neither? 2021-05-13 13:43:53 it probably shouldn't be 1 either, but I wanted to start low 2021-05-13 13:55:14 'unset CARGO_BUILD_JOBS' work too 2021-05-13 13:55:24 https://doc.rust-lang.org/stable/cargo/reference/config.html#buildjobs 2021-05-13 14:15:32 anyone with access to the arm mahine: can you please help with zstd build error? 2021-05-13 14:15:35 Note: 160 physical core(s) detected 2021-05-13 14:15:35 zstd: error 11 : Allocation error : not enough memory 2021-05-13 14:15:55 i thikn it does somethign stupid based on available memory or number of cores 2021-05-13 14:16:08 might even have an upstream issue 2021-05-13 14:16:23 its not build error, its when running tests 2021-05-13 14:16:31 worst case, disable tests on 32bit machines 2021-05-13 14:16:41 its a blocker for the bootstrap of 3.14 builders 2021-05-13 14:22:01 build-edge-ppc64le is up 2021-05-13 14:22:18 but it can not upload to anywhere i think 2021-05-13 14:22:28 at least it builds 2021-05-13 14:36:53 zstd -22 --ultra -c f.zst allocates iirc 1.5 GB, but doesn't write to it unless f is large 2021-05-13 14:37:11 you can work around by doing zstd -22 --ultra -c f -o f.zst, then it will stat f 2021-05-13 14:37:32 wait, actually i think i have some dejavu here 2021-05-13 14:44:35 might be there is a fix or similar in the git log or in upstream bug report 2021-05-13 14:44:58 i've set up a new build-edge-ppc64le 2021-05-13 14:45:20 kewl 2021-05-13 14:46:10 you can also work around it by sysctl vm.overcommit_memory or adding more swap 2021-05-13 14:48:39 i dont think lack of memory is the problem here 2021-05-13 14:48:46 its has 512G ram 2021-05-13 14:49:06 I suppose it tries to alloc more than 4G per process? 2021-05-13 14:49:18 i thinnk that might be the problem yes 2021-05-13 14:49:26 i think i have looked at this in the past 2021-05-13 14:56:14 Sounds familiar to me as well 2021-05-13 14:57:13 i think there was some buffer calculation based on number of cpus / memory or something, that did some shift (left or right - dont remember) 2021-05-13 14:57:29 so it ended up with trying to allocate way too much memory 2021-05-13 14:57:51 Was it some kind of div operator? 2021-05-13 14:58:28 dont remember 2021-05-13 14:58:36 might have been other compressor as well 2021-05-13 14:58:47 sounds like xz -T0 2021-05-13 15:03:04 https://github.com/facebook/zstd/issues/2528 2021-05-13 15:04:26 maybe this fixes it? https://github.com/facebook/zstd/pull/2606/commits/2e4fca38d8585e0cecb584ad5279306640897b4a 2021-05-13 15:07:36 is this zstd in aports 2021-05-13 15:08:18 pkgver=1.4.9 2021-05-13 15:18:23 this one passed on my dev lxc armv7 2021-05-13 15:39:39 it failed in my dev lxc 2021-05-13 15:40:05 I have JOBS=32 2021-05-13 15:45:38 jvoisin: I've done it a bit different: https://www.alpinelinux.org/conf/ 2021-05-13 18:58:47 Hi guys, so Im just wondering if there was a mistake in the timezone info on the website? It says CEST. But if I run: date --date='TZ="CEST" 16:30 this Sat' - it returns 'Sat May 15 12:30:00 PM EDT 2021'. date --date='TZ="CET" 16:30 this Sat' gives the correct result: Sat May 15 10:30:00 AM EDT 2021. I know Im supposed to get 10:30 am for my timezone as per kaniini's post here: 2021-05-13 18:58:47 https://gitlab.alpinelinux.org/alpine/alpineconf-cfp/-/issues/17 2021-05-13 18:59:04 Or did kaniini make a mistake in the time conversion? 2021-05-13 18:59:24 anjan: let me check 2021-05-13 19:00:36 What is your talk? 2021-05-13 19:01:09 https://alpinelinux.org/conf/ 2021-05-13 19:01:16 Sxmo 2021-05-13 19:01:18 yes, but I mean, which talk is yours 2021-05-13 19:01:19 ok 2021-05-13 19:01:21 on Saturday 2021-05-13 19:01:22 (I've created that page ;-) 2021-05-13 19:01:27 oh alright lol 2021-05-13 19:01:59 according to https://www.worldtimebuddy.com/, 16:30 CEST corresponds to 10.30 PDT 2021-05-13 19:02:15 Which makes sense, there should be 6 hours difference 2021-05-13 19:02:55 Ya, so I also ran date --date='TZ="US/Central " 16:30 this Sat' and it seems that TZ=CEST means US central time in the date tool 2021-05-13 19:03:10 Not central european summer time 2021-05-13 19:03:56 I think that abbreviation is a bit ambiguous. 2021-05-13 19:04:21 anjan: you might add -R to the date command to show the tz offset 2021-05-13 19:04:59 https://www.timeanddate.com/time/zones/cest 2021-05-13 19:05:14 I got -0400 for CEST and US/Central 2021-05-13 19:05:33 strange 2021-05-13 19:05:35 ikke: ya, I saw that too. I wonder if there's an iso standard or something 2021-05-13 19:05:39 https://www.timeanddate.com/time/zones/ 2021-05-13 19:05:48 That only shows european time for CEST 2021-05-13 19:05:59 and maybe one abbreviation is deprecated 2021-05-13 19:06:15 I could add a timezone offset 2021-05-13 19:06:17 ok, I have to go to a meeting. I will be back in like an hour 2021-05-13 19:06:22 Yes, that would be helpful 2021-05-13 19:06:35 Maybe spell out Central European Summer Time? 2021-05-13 19:06:40 Will there be a AlpineConf 2022? I might want to do something for next year 2021-05-13 19:06:47 kurko246: Likely 2021-05-13 19:07:02 Okay thanks 2021-05-13 19:07:10 The gnu project just says 'to see what that time is in your timezone, run this command on your machine' 2021-05-13 19:07:19 and then gives the date command. I really like that approach 2021-05-13 19:07:33 ACTION shrug 2021-05-13 19:07:44 kurko246: There are still slots avaialble, so if you could arrange something before, we might still be able to put you in 2021-05-13 19:07:47 let's join the flat earth society and get rid of this complexity... 2021-05-13 19:08:16 ya....Dates are a whole mess 2021-05-13 19:08:18 Thu May 13 21:06:46 CEST 2021 == Thu, 13 May 2021 21:06:57 +0200 running myself on Europe/Berlin 2021-05-13 19:08:26 date vs. date -R 2021-05-13 19:08:44 https://qntm.org/abolish 2021-05-13 19:08:47 Nah I have some general ideas but nothing very specific yet ikke 2021-05-13 19:08:53 kurko246: alright 2021-05-13 19:09:19 ikke: but consider how minimal our code would be without time zones 2021-05-13 19:09:40 anjan: I bet the complexity would remian 2021-05-13 19:09:42 remain 2021-05-13 19:09:43 just replace everything with epoch timestamps? 2021-05-13 19:09:55 :) 2021-05-13 19:10:04 You still have to map things to the local circumstances 2021-05-13 19:10:09 like business opening times 2021-05-13 19:10:54 Imagine having to program for code that will be run on multiple planets 2021-05-13 19:10:57 yikes 2021-05-13 19:11:07 even Star Trek's stardates are a mess 2021-05-13 19:11:24 anjan: what about relativistic differences :D 2021-05-13 19:11:27 :) 2021-05-13 19:11:59 =D 2021-05-13 19:12:26 anjan: good luck finding an universal time reference 2021-05-13 19:13:03 ya definitely, I had this bug on the pinephone and pmOS re: the time keeping. The time would jump to the year 2116 2021-05-13 19:13:17 It was the worst thing I debugged in my life 2021-05-13 19:22:04 anjan: I've made CEST an abbrevation 2021-05-13 19:22:07 https://www.alpinelinux.org/conf/ 2021-05-13 19:23:10 Looks good! 2021-05-13 19:23:33 this was all good to know tho. Id hate to miss something cause of time zone abbreviations lOL 2021-05-13 19:23:50 yeah, that would be sad 2021-05-13 19:24:28 If I had more time, I'd probably add something to convert timezones or something 2021-05-13 19:24:53 ya, no worries. =) 2021-05-13 19:24:56 It looks great 2021-05-13 19:25:08 Thanks :) 2021-05-13 20:19:24 Ikke: atools-20.0.9 can recognize GitHub Security Lab (GHSA) advisories 2021-05-13 20:24:08 `ok, nice 2021-05-13 20:33:37 is there a way to override abuild-meson's setting of -Dbuildtype in an APKBUILD? (for debug purposes) 2021-05-13 20:34:08 in the past I've just copied the entire thing that abuild-meson expands to but that's kinda annoying :P 2021-05-13 20:37:07 Cogitri: ^ 2021-05-13 20:37:51 craftyguy: You mean --buildtype? 2021-05-13 20:38:34 I'd expect `abuild-meson --buildtype=debug` to work 2021-05-13 20:41:49 Cogitri: yeah. ok cool, thanks 2021-05-13 20:42:41 Cogitri: since I have you (and you're the gnome-calls maintainer), have you seen this? https://gitlab.com/postmarketOS/pmaports/-/issues/1089 2021-05-13 20:43:29 I'm building that with symbols to poke around more 2021-05-13 20:43:57 Ah no, I don't really follow pmaports issues unless I'm pinged in them 2021-05-13 20:44:12 err, maybe not the pmaports issue, just that behavior :P 2021-05-13 20:47:08 Oh, no, I haven't seen that issue but I don't use my PinePhone much lately 2021-05-13 22:50:12 is there an agenda/list of topics for "Alpine and the larger musl ecosystem" roundtable? should we prepare anything? 2021-05-13 22:55:30 yeah i'm just yoloing 2021-05-13 22:55:31 that shit 2021-05-13 22:55:32 :) 2021-05-13 22:56:00 the point of that talk was to discuss ways we can work better together though :) 2021-05-13 23:00:52 ok great; that's a huge TODO for us. written down as "establish positive relationships with Alpine" :) 2021-05-13 23:11:25 in general we are working to make it easier for developers of other distributions similar to alpine to become alpine devs 2021-05-13 23:12:23 https://alpinelinux.org/conf/ Cogitri: I think `alpine-qa-bot` is meant to be `aports-qa-bot` 2021-05-13 23:14:42 I see; what's in it for other distros? 2021-05-13 23:18:52 cross-pollination 2021-05-13 23:19:25 a maintainer can maintain his package in numerous distros without having to do much work 2021-05-14 00:49:37 how would i craft an APK package by hand? 2021-05-14 00:53:10 Cadey: newapkbuild does most of the work already, there's no real reason to not use it. 2021-05-14 00:54:26 let's say i have extenuating circumstances that make it difficult to run this exact thing from an alpine system 2021-05-14 00:55:03 and let's also say i have something that poops out static binaries 2021-05-14 01:03:16 I mean, you could just run it once for the standard output and plug a generator that emits similar in to your toolchain? 2021-05-14 06:40:46 would it be possible to watch presentations for alpineconf from alpine 'desktop', i.e. what software is needed 2021-05-14 06:41:53 ( my association for 'alpineconf' is always 'alpine configuration) 2021-05-14 07:00:46 do you mean a windows-like desktop or more like a usable gui in general? 2021-05-14 07:01:17 mps: you can use any webbrowser which supports WebRTC, so for example Firefox or Chromium 2021-05-14 07:03:42 liwakura: I mean my desktop (alpine), which is awesome wm only, not these full featured (bloated) 'desktops' 2021-05-14 07:03:56 PureTryOut[m]2: thanks, I use firefox 2021-05-14 07:04:21 Then you'll be fine 2021-05-14 07:05:09 iiuc, I can only watch it with, but could not 'be part of discussions or Q/A' with FF 2021-05-14 07:13:40 Afaik you can. As I said, as long as your browser supports WebRTC you'll be fine. Firefox supports that. The conference uses BigBlueButton and I'm pretty damn sure I've used it to be part of discussions last KDE Akademy with Firefox 2021-05-14 07:15:03 aha, thanks. 2021-05-14 07:15:09 BBB even recommends Firefox and Chrom(ium) in their FAQ 2021-05-14 07:15:23 will look if I can find how to enable/set in FF 2021-05-14 07:16:03 You can try it on https://test.bigbluebutton.org/ it seems 2021-05-14 07:16:21 thanks again 2021-05-14 07:16:31 (just tested, works for me) 2021-05-14 07:16:33 Np! 2021-05-14 07:21:48 ah, there is 'chat' option, very good. I prefer this than talk because my spoken english is a lot worse than written 2021-05-14 07:22:20 đŸ‘ïž 2021-05-14 07:22:38 It would be a good practice for you to speak though then 😉 2021-05-14 07:23:30 long ago I gave up on this :) 2021-05-14 07:24:20 I can speak english only in pubs ;) 2021-05-14 07:24:26 But then you'll never learn haha 2021-05-14 07:24:43 Ah well if you need alcohol, then you can prepare your fridge 😛 2021-05-14 07:26:59 alcohol for public speach? No, I will not, especially about alpine, because I could say a lot of 'nice words' :D 2021-05-14 07:29:55 ncopa 2021-05-14 07:30:08 why cant the filesystem itself be squashfs 2021-05-14 07:30:13 just like modloop 2021-05-14 07:30:23 and mounted as loop back 2021-05-14 07:30:33 cant that save memory further 2021-05-14 07:30:41 instead of using tmpfs 2021-05-14 07:31:29 only challenge would be where will it be looped back without tmpfs 2021-05-14 07:31:29 oneinsect: squashfs is 'intended' to read-only mostly 2021-05-14 07:31:52 but tmpfs is also read only during say in memory operations of alpine 2021-05-14 07:32:00 it is not good for 'working' FS 2021-05-14 07:32:08 ofcourse unless we use lbu commit 2021-05-14 07:32:15 no, tmpfs is RW 2021-05-14 07:32:22 ooh 2021-05-14 07:32:27 RW to fat32? 2021-05-14 07:32:49 or RW as into the memory which is lost during power loss 2021-05-14 07:32:55 ah, you mean FS on media, not working one 2021-05-14 07:33:10 yes 2021-05-14 07:33:27 when we are not touching media anyway 2021-05-14 07:33:47 you could in theory have squashfs for rootfs also 2021-05-14 07:33:52 hmm, never thought about this idea 2021-05-14 07:34:11 i mean i save memory for boards which have 64MB ram or 32MB ram 2021-05-14 07:34:13 in theory you can have any theory :) 2021-05-14 07:34:17 lol 2021-05-14 07:34:31 if you know what i mean 2021-05-14 07:34:54 i dont consume too much ram 2021-05-14 07:35:01 I think I got idea, but don't have opinion about it, yet 2021-05-14 07:35:01 is it possible to do? 2021-05-14 07:35:06 hmmmm 2021-05-14 07:36:09 but, you can use compressed f2fs if you are 'brave enough' 2021-05-14 07:36:47 and encrypted as a bonus 2021-05-14 07:41:09 oneinsect: looking on openwert, '/dev/root /rom squashfs ro,relatime 0 0' 2021-05-14 07:41:16 interesting 2021-05-14 07:42:16 openwrt* 2021-05-14 07:42:25 i dont think you can have root ro, except with some changes 2021-05-14 07:43:28 I made 20 years ago debian router with rootfs ro, just had to patch a little runit 2021-05-14 07:44:11 sure, but how useable is it for most general use cases? 2021-05-14 07:44:37 right, not for general usage 2021-05-14 07:45:13 I understand oneinsect wants to make something 'specific' 2021-05-14 07:47:41 the way our init works will need some hacking to make that work. 2021-05-14 07:48:59 yes 2021-05-14 07:49:06 Cadey: you could use nfpm to create apks 2021-05-14 07:49:29 you could use squashfs base image and mount it with overlayfs/tmpfs to make it writable, this way you can limit tmpfs usage on boot. 2021-05-14 07:49:32 and I think we should keep it for 'general use cases' not specific ones 2021-05-14 07:50:29 clandmeter: looks like openwrt does this 2021-05-14 07:52:00 i mean my interest lies in maximizing memory for low end devices 2021-05-14 07:52:15 but will be useful for higher mem devices anyways 2021-05-14 07:52:25 oneinsect: 'use openwrt, Luke' :) 2021-05-14 07:52:33 lol 2021-05-14 07:52:42 i will miss lbu 2021-05-14 07:53:32 overlayfs is not in mainline yet i guess? may be thats why ncopa doesnt want to use it 2021-05-14 07:53:48 i think it is 2021-05-14 07:53:51 oooh 2021-05-14 07:53:54 my bad 2021-05-14 07:54:07 well, we always finish in "buridan's donkey" dilemma 2021-05-14 07:54:27 there are other considerations for this type of setup 2021-05-14 07:55:06 overlayfs is long time in mainline kernels (even I forgot when it is merged) 2021-05-14 07:55:28 then why stopping us to go via this route? 2021-05-14 07:55:47 mps: i thought you remembered all merges into mainline? ;-) 2021-05-14 07:55:49 the init can be generalized for both ideas 2021-05-14 07:56:41 clandmeter: :) 2021-05-14 07:57:31 oneinsect: yes, but alpine is 'base' system, all other tweaks should/are be left to users/admins 2021-05-14 07:57:41 hmmmm 2021-05-14 07:58:21 I'm not sure tweaking alpine for 'one true' use case is good idea 2021-05-14 07:59:38 i was just pondering on how to save memory for devices like rpi zero 2021-05-14 07:59:58 so yes I will try that squashfs route 2021-05-14 08:00:15 as a loop-back device in tmpfs filesystem 2021-05-14 08:51:07 what is 'Offtopic stream' on https://www.alpinelinux.org/conf/ 2021-05-14 09:42:42 #alpine-offtopic meets video 2021-05-14 09:46:56 aha, understand. unofficial babbling 2021-05-14 09:48:48 on 'AlpineConf Main' 'enter your name' is arbitrary string? 2021-05-14 09:51:34 yes 2021-05-14 09:51:41 whatever you want it to be 2021-05-14 09:52:00 ok, thanks. will user random one, mps :) 2021-05-14 09:53:10 we still need some people to help push buttons 2021-05-14 09:53:20 donoban i think mentioned interest in that by email 2021-05-14 10:01:01 hi 2021-05-14 10:02:24 Where can I see default compiler flags Alpine uses for building packages? 2021-05-14 10:05:49 what do you need Ariadne ? 2021-05-14 10:06:07 ilya-fedin: /etc/abuild.conf 2021-05-14 10:07:42 donoban: a couple of people to assist with ensuring the right people have moderator rights at the right time 2021-05-14 10:08:46 Ariadne: can I see it somewhere on the web. e.g. on Alpine gitlab? 2021-05-14 10:09:50 ah yeah I could help, I expect to be ~100% of the time tomorrow but I don't know the Sunday 2021-05-14 10:11:03 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.conf 2021-05-14 10:11:17 ilya-fedin: ^ 2021-05-14 10:12:16 ncopa: the locking test fails on s390x for abuild 2021-05-14 10:15:33 ikke: thx 2021-05-14 10:39:07 Can someone point me to the web page that details how commit message should be formatted? Seem to have closed it and can't find it for some reason! 2021-05-14 10:40:38 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md 2021-05-14 10:42:55 Perfect, thanks ikke. I'll be sure to keep it open in future :) 2021-05-14 10:43:10 it's in the root of the aports repo 2021-05-14 10:45:17 Wow. Now I feel dumb. Didn't think to look there. I thought it was in the Wiki somewhere. That explains why I couldn't find it! 2021-05-14 10:47:18 Odd. Trying to create a merge request using the URL I get when I push a commit. Getting a 404. 2021-05-14 10:47:24 URL given is: https://gitlab.alpinelinux.org/adhawkins/aports/-/merge_requests/new?merge_request%5Bsource_branch%5D=braceexpand-0.1.7 2021-05-14 10:47:42 works for me.. 2021-05-14 10:48:34 How bizarre. Tried multiple browser (Chrome and Firefox). 2021-05-14 10:49:31 Doh. Not signed in. Would be nice if the message were a little helpful :) 2021-05-14 10:49:40 ah, explains, yea 2021-05-14 10:49:56 but they do not want to disclose the existence of repositories 2021-05-14 10:49:59 if they are private 2021-05-14 10:50:11 hmm, yours is public 2021-05-14 10:50:38 Well, it worked after I logged in. I could navigate to the repo, but obviously couldn't create a MR when not logged in. 2021-05-14 10:50:50 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21396 2021-05-14 10:51:10 Oh well, learned something today at least! First MR since replacing my PC. 2021-05-14 10:51:47 adhawkins: The source branch is 5538 commits behind the target branch 2021-05-14 10:51:50 there are conflicts 2021-05-14 10:52:08 Odd, I thought I updated my local repo. Will fix that. 2021-05-14 10:52:57 Make sure you fetch from alpine/aports to get the latest version 2021-05-14 10:53:18 Yep, thought I had. Obviously not! 2021-05-14 10:55:03 That better ikke? 2021-05-14 10:55:21 yes 2021-05-14 10:55:28 Ohg 2021-05-14 10:55:32 You committed conflicts 2021-05-14 10:55:44 Grrr...one sec 2021-05-14 10:57:15 Ok, better? 2021-05-14 10:57:35 Yes, looks good now. 2021-05-14 10:58:08 Thanks. Been a while since I did one of these! Apologies for the cock-ups! 2021-05-14 10:59:32 no problem, can happen 2021-05-14 11:03:51 ikke: yeah i noticed. i think i'll just disable that specific test on s390x. there is actually no guarantee that the sleep(0) trick will actually work 2021-05-14 11:04:01 nod 2021-05-14 11:35:31 seems like libxml2 update broke libxslt test suite 2021-05-14 11:36:37 ikke: when you have a moment can you apk upgrade -a on the mips64 builderf 2021-05-14 11:36:39 -f 2021-05-14 11:48:01 host? 2021-05-14 11:48:06 or edge builder?' 2021-05-14 12:02:39 apk upgrade -a -f? 2021-05-14 12:05:37 im running it on build-edge-mips64 now 2021-05-14 12:06:07 it updated binutils 2021-05-14 12:55:12 Error relocating /home/buildozer/aports/main/wayland-protocols/src/wayland-protocols-1.21/output/tests/test-build-pedantic-unstable_xdg_decoration_xdg_decoration_unstable_v1_xml: xdg_toplevel_interface: symbol not found 2021-05-14 12:55:18 anyone have idea what that is about? 2021-05-14 13:25:51 maybe something to do with wayland-scanner? 2021-05-14 13:26:00 ddevault: ^ 2021-05-14 14:30:13 only happens on ppc64le and i have not had time to set up a dev box yet 2021-05-14 16:14:55 3.14 builders are up 2021-05-14 16:55:34 this auto-assign MRs feature is somewhat strange, now I hesitate to merge fine MRs 2021-05-14 16:56:17 it can be helpful 2021-05-14 16:58:12 it 'blocks' me to merge some MRs 2021-05-14 17:04:19 mps: hince why i would like metadata on which maintainers are friendly to having their packages changed quickly 2021-05-14 17:07:54 nod 2021-05-14 17:08:54 for now I merge from previous experience and 'feeling', so mostly BDFL pkgs and people I 'know' their 'position on this' 2021-05-14 17:09:10 and ofc, important MRs 2021-05-14 17:09:12 MRs from package maintainers 2021-05-14 17:09:42 ikke: I mean, assigned to maintainers 2021-05-14 17:10:59 but also MRs from pkg maintainers if they are in 'good shape' and maintainer doesn't have MR rights 2021-05-14 17:12:24 but all this is 'from head' and feeling 2021-05-14 19:14:24 https://build.alpinelinux.org/buildlogs/build-3-13-ppc64le/main/python3/python3-3.8.10-r0.log 2021-05-14 19:14:48 yes 2021-05-14 19:14:56 I just set those containers up 2021-05-14 19:15:02 but ncopa needs to restore the keyus 2021-05-14 19:15:27 https://github.com/facebook/zstd/releases/tag/v1.5.0 2021-05-14 19:15:40 is it good idea to upgrade it now (freeze) for 3.14 2021-05-14 19:21:51 API changes sound bad 2021-05-14 19:21:52 lets wait 2021-05-14 19:21:53 :) 2021-05-14 19:22:22 yes, this is what I think 2021-05-14 19:22:35 lots of checksums changed 2021-05-14 19:23:27 where? 2021-05-14 19:24:11 anyway, I'm testing build of new zstd on x86_64 and armv7 2021-05-14 19:27:02 macifrename 2021-05-14 19:27:12 what is the source? 2021-05-14 19:29:14 sourcehut 2021-05-14 19:30:01 there is one expected change from source hut 2021-05-14 19:30:04 sourcehut 2021-05-14 19:30:23 so if it has not been updated since the last 3 months or so, it's expected 2021-05-14 19:30:37 I'm not sure why the checksums changed, I'll investigate next week (though I won't change them back) 2021-05-14 19:30:49 the macifrename one is quite old 2021-05-14 19:30:54 from 2 years ago :) 2021-05-14 19:31:04 ddevault: one change ncopa saw was that it changed to max compression 2021-05-14 19:31:05 probably changed when busybox updated on May 3rd 2021-05-14 19:31:25 we just use alpine's stock gzip 2021-05-14 19:53:43 hah, j0wi is faster than me, already created zstd 1.5.0 MR few minutes before me :) 2021-05-14 19:53:58 I changed milestone to 3.15.0 2021-05-14 20:02:01 buildlogs for ppc64le should be available now as well 2021-05-14 20:03:52 okay well 2021-05-14 20:03:56 i am going to take a nap 2021-05-14 20:04:59 o. 2021-05-14 20:05:00 o/ 2021-05-14 20:05:39 how I can delete pushed MR to gitlab before I create new MR 2021-05-14 20:05:47 via web iface 2021-05-14 20:06:05 MR or branch? 2021-05-14 20:06:40 branch 2021-05-14 20:06:52 MR is not yet created 2021-05-14 20:07:10 https://gitlab.alpinelinux.org/mps/aports/-/branches 2021-05-14 20:07:15 there is a delete button there 2021-05-14 20:07:46 ah, thanks 2021-05-14 20:07:54 why I'm so blind 2021-05-14 20:08:15 (and they call web iface intuitive :) ) 2021-05-14 22:03:44 I might be missing something, but is there info on how to deliver the videos to alpineconf? 2021-05-14 22:05:57 MartijnBraam: https://lists.alpinelinux.org/~alpine/devel/%3C9637f9fa-7efc-6fed-6635-a66c1cefca8%40dereferenced.org%3E 2021-05-14 22:06:14 ah, thanks :) 2021-05-14 23:08:33 aren't we glad we CONFIG_SECURITY_DMESG_RESTRICT=y 2021-05-15 00:05:08 oh.. 2021-05-15 05:57:16 is there some way I can generate an 'alpine-uboot' image like the ones here, but based on current edge? https://dl-cdn.alpinelinux.org/alpine/edge/releases/aarch64/ 2021-05-15 05:58:40 craftyguy: the scripts to generate these live in aports scripts/ 2021-05-15 05:59:04 ah nice, thanks 2021-05-15 07:42:06 good morning 2021-05-15 07:52:28 morning 2021-05-15 07:52:31 10 mins for AlpineConf? 2021-05-15 07:52:41 yes 2021-05-15 07:52:50 uh so bbb says 404 not found for me 2021-05-15 07:53:02 Ariadne: ^ 2021-05-15 07:53:13 yes 2021-05-15 07:53:16 i am working on it 2021-05-15 07:53:21 ah now it works apparently. 2021-05-15 07:53:23 thanks 2021-05-15 07:53:43 i had to reboot the system because systemd 2021-05-15 07:54:00 i have attached a 4TB SAN volume for the recordings 2021-05-15 07:54:07 ah nice 2021-05-15 07:54:27 (I'm trying to join offtopic to test mic and video, and it says "the meeting hasn't started yet") 2021-05-15 07:54:35 ollieparanoid[m]: there is a sandbox room 2021-05-15 07:54:49 right 2021-05-15 07:54:59 sent you the link 2021-05-15 07:55:23 can i join 2021-05-15 07:55:52 Watch online 2021-05-15 07:55:52 Offtopic stream 2021-05-15 07:56:03 both or only one? 2021-05-15 07:56:10 root@bbb:~# mount /dev/sdb /var/bigbluebutton/recording 2021-05-15 07:56:10 root@bbb:~# bbb-conf --restart 2021-05-15 07:56:18 the miracle of having a 160TB SAN :) 2021-05-15 07:56:21 and iSCSI 2021-05-15 07:56:47 wow 2021-05-15 07:56:57 fyi, there is #alpine-conf 2021-05-15 07:57:08 okay, we're going live in a moment 2021-05-15 07:57:19 The meeting hasn't started yet. 2021-05-15 07:57:19 You will automatically join when the meeting starts. 2021-05-15 08:11:39 well it hasn't exploded yet 2021-05-15 08:11:42 thats good 2021-05-15 09:45:51 Ariadne: so it seems ollieparanoid and I didn't communicate properly, and my talk seems to be largely a duplicate of his talk. However, his talk is more verbose and better than mine haha. Could I still cancel my talk tomorrow? 2021-05-15 09:46:12 i mean if you want to :p 2021-05-15 09:46:26 but reinforcement is not the worst thing 2021-05-15 09:47:14 Nah I rather cancel it. I wasn't too happy about my video anyway 2021-05-15 09:47:32 fair 'nuff 2021-05-15 09:47:38 Thanks! 2021-05-15 09:52:30 I'll remove it from the schedule 2021-05-15 09:52:53 Thanks! 2021-05-15 09:53:57 p00f 2021-05-15 09:54:12 Magic 🌈 2021-05-15 09:55:18 PureTryOut (matrix.org): will you still release your video? 2021-05-15 09:55:27 No 😛 2021-05-15 09:55:41 As I said, I'm not that happy with the quality of it and it's largely a duplicate of ollieparanoid's talk anyway 2021-05-15 09:57:58 ok 2021-05-15 10:09:55 I have planned RL stuff today, sorry I can't attend the conf, hopefully I'll be back in time for later talks. 2021-05-15 10:12:04 You better join the systemd talk 😜 2021-05-15 10:13:46 hm, will links to talk be released? i can't join conf rn too 2021-05-15 10:20:41 yes 2021-05-15 10:20:58 for the ones where we have URLs, we will post the links today 2021-05-15 12:17:25 PureTryOut[m]2: i still can't believe i managed to get away with doing a systemd talk at alpineconf lol 2021-05-15 12:17:42 Haha it really depends how you frame it 😂 2021-05-15 12:18:05 If it were titled "systemd is awesome and here is why we should have it on Alpine Linux", then you'd get more pushback I'm guessing 2021-05-15 12:18:42 i tried to do it in more of a "hi yes this exists and here's a tiny fraction of what it does and how it makes people sleep easier at night" type of style 2021-05-15 12:22:21 I hate with passions those software who bundle dependencies using git modules and provide broken tarballs 2021-05-15 12:22:35 do anyone has an APKBUILD that cover this situation as an starter template? 2021-05-15 12:23:52 markand: typically download each module as a separate source file 2021-05-15 12:23:53 Telegram I think (?) 2021-05-15 12:24:03 but it means you need to keep track of the commits / versions for each module 2021-05-15 12:24:10 ikke, yes but I mean the logic to unpack them in prepare() 2021-05-15 12:24:31 they should already be unpacked if they are archives 2021-05-15 12:24:36 you then just have to move them in place 2021-05-15 12:24:40 yes this 2021-05-15 12:24:53 let's try that 2021-05-15 12:31:50 PureTryOut (matrix.org): nah, it would act as a clickbait of sorts 2021-05-15 12:47:47 they started releasing a -all tarball thankfully 2021-05-15 12:56:22 Neat 2021-05-15 13:07:54 isn't the appropriate syntax arch="all !mips64" to build on all but mips64? 2021-05-15 13:08:05 yes 2021-05-15 13:08:14 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12675 2021-05-15 13:08:20 so I don't understand this issue 2021-05-15 13:09:17 algitbot: retry master 2021-05-15 13:09:36 markand: I think the build error was from before Leo disabled it 2021-05-15 13:09:46 00b626b408bbfaf255d4841b7b29f43b5f68c98c 2021-05-15 13:10:54 ok 2021-05-15 13:11:00 so closing as the software does not run on it 2021-05-15 13:38:16 Oh the 3.14 builders are up? Should we start backporting patch releases of packages to it already? Or is it still building the edge branch for now? 2021-05-15 13:38:43 yes, they are 2021-05-15 13:38:55 they still track master 2021-05-15 13:39:04 the 3.14 branch is created on release 2021-05-15 13:39:31 Ah cool, so I don't have to do anything yet. That's always good 😃 2021-05-15 13:39:42 Fix packages that don't build :P 2021-05-15 13:40:02 Well yeah ofc but I don't have to do anything extra besides pushing it to master 2021-05-15 13:40:09 will be interesting to see if anything fails due to new ldflags 2021-05-15 13:44:47 are we upgrading to gcc 11 before or after 3.14? đŸ€” 2021-05-15 13:45:02 nmeum: no 2021-05-15 13:45:33 no as in: after? 2021-05-15 13:46:21 ah, after 2021-05-15 13:46:27 I read it as a yes or no question 2021-05-15 14:22:30 when will 3.14 be released? I'd like to make some package version renaming before 2021-05-15 14:23:28 markand: shortly after all packages have been built 2021-05-15 14:23:37 so I must be very fast 2021-05-15 14:28:03 Ariadne: can people just join audio with mic for the roundtable? 2021-05-15 14:28:15 yes 2021-05-15 14:28:19 neat, thanks 2021-05-15 14:28:24 I shall be attending :D 2021-05-15 14:28:45 same, I made it back in time 2021-05-15 14:53:54 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21454/diffs#aad2f6b1c25fab5b8d0c64993a9a1ac4f83ce522 2021-05-15 14:53:58 that was a pretty big beast 2021-05-15 15:01:14 the famous git submodule one 2021-05-15 17:17:02 Is there a package with artwork somewhere? Mainly I need a package with an Alpine Linux icon in it 2021-05-15 17:18:39 Only aware of the alpine-mksite repo 2021-05-15 17:37:16 no chances for me to join conf from any one of the 3 of my 'notebooks' 2021-05-15 17:37:31 site is to heavy for firefox 2021-05-15 17:48:16 firefox can handle it, just have very long loading time 2021-05-15 17:50:29 it worked on morning session but not afternoon 2021-05-15 17:50:47 i.e. after 19:00 2021-05-15 17:52:25 i think more people joined :p 2021-05-15 17:53:24 hello! i've created a merge request to update the community/domoticz package to the latest version and the merge request pipeline for s390x fails. for some reason the compiler process seems to get killed. is it running out of memory? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21208 2021-05-15 17:53:52 could someone take a look maybe? all other targets build fine 2021-05-15 17:55:18 Hello71: nr. of people shouldn't 'load' my browser 2021-05-15 17:55:45 but who knooooows with all this 'tooons' of JS 2021-05-15 17:55:58 wej: could be OOM 2021-05-15 17:56:15 it would be odd for oom to kill 8 procs at same time though 2021-05-15 17:56:25 Out of memory: Killed process 52587 (cc1plus) total-vm:998984kB, anon-rss:865048kB, file-rss:72kB, shmem-rss:0kB, UID:1000 pgtables:1830kB oom_score_adj:0 2021-05-15 17:56:45 hm. is our s390x using a modern kernel? 2021-05-15 17:56:59 5.4 2021-05-15 17:57:09 for the CI host 2021-05-15 17:57:11 iirc 5.0 or somesuch added feature to synchronously reap oom procs 2021-05-15 17:57:29 to reduce chances of unnecessary chain oomkill 2021-05-15 18:00:17 hm, it would be nice if waitid could pass up a flag to indicate that the SIGKILL was synthetic 2021-05-15 18:05:33 i think there actually is exactly 4 bytes of extra room in _sigchld 2021-05-15 18:07:38 hm... actually you could put it in si_uid, except i think -1 might be occupied? 2021-05-15 18:08:55 er, i mean there are no sentinel uids for the kernel to use 2021-05-15 18:19:57 so, nothing with the package itself, that's good to know 2021-05-15 19:29:00 quick question 2021-05-15 19:29:17 quick answer 2021-05-15 19:29:17 when i setup lbu-cache in memory-only alpine 2021-05-15 19:29:44 lol do i need to do lbu commit for it to save packages to disk 2021-05-15 19:29:49 no 2021-05-15 19:30:07 it creates a symlink at /etc/apk/cache 2021-05-15 19:30:22 to the USB right? 2021-05-15 19:30:26 yes 2021-05-15 19:30:34 so the packages are immediately stored 2021-05-15 19:30:37 but now the USB is mounted in ro mode 2021-05-15 19:30:44 openldap failing possibly because of autoconf-2.71 2021-05-15 19:30:53 does apk remount it in rw mode 2021-05-15 19:31:12 save files to the USB and then mount it back to ro 2021-05-15 19:31:15 I don't think apk will do that 2021-05-15 19:31:25 then how does it happen? 2021-05-15 19:31:39 because USB is always in ro mode 2021-05-15 19:32:54 I think it expects that the cache location is writable 2021-05-15 19:34:07 which means the usb is always in rw state 2021-05-15 19:34:15 or the sdcard for that matter 2021-05-15 19:34:31 which is against the whole of idea of being crash proof 2021-05-15 19:34:35 or in-memory 2021-05-15 19:36:04 https://github.com/alpinelinux/alpine-conf/blob/master/setup-apkcache.in 2021-05-15 19:44:58 strange setup-apkcache puts it back ro mode 2021-05-15 19:45:30 if apk add doesnt put it in rw mode, then what package does? 2021-05-15 19:55:04 any thoughts folks? 2021-05-15 20:28:52 huh, py-provides is not acting in an expected way 2021-05-15 20:36:32 ok found the bug 2021-05-15 20:42:13 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/98 2021-05-15 20:42:31 using `-print0` at the start makes all the expressions return true, only -maxdepth 1 and -mindepth 1 apply 2021-05-15 20:42:47 ignores the '-type f -iname '*.py' -o -type d' expression 2021-05-15 21:09:14 The order of parameters for find matter 2021-05-15 21:22:41 is build-3-13-ppc64le stuck? 2021-05-15 21:23:08 oh, no, sorry 2021-05-15 21:23:16 misinterpreted 2021-05-15 21:24:16 but last error https://build.alpinelinux.org/buildlogs//build-3-13-ppc64le/main/python3/python3-3.8.10-r0.log 2021-05-15 21:25:11 but is it stuck then? it isn't "idle" 2021-05-15 22:14:00 are there plans to make a generic cloud qcow2 image for use in libvirtd/openstack? 2021-05-15 22:14:45 possibly for 3.15 2021-05-15 22:15:04 how are the AWS images made? 2021-05-15 22:15:22 uh... i think mcrute makes them 2021-05-15 22:17:35 ikke: uh seems something is wrong with artifacts on the CI. I have jobs succeeding but the artifact zip containing only empty folders and logs. No build key or packages included 2021-05-15 22:17:47 Example build job https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/393124 2021-05-15 22:23:43 Cadey: yeah the're made by the cloud team, of which I am a member 2021-05-15 22:26:20 ah i see 2021-05-15 22:26:50 if i make an image that includes cloud-init-openrc will that be about equivalent to what you'd get with a proper cloud image? 2021-05-15 22:27:20 Cadey: we've got a cloud-init branch that just needs some testing... https://github.com/mcrute/alpine-ec2-ami/tree/cloud-init 2021-05-15 22:27:42 the initial testing so far suggests that they work pretty well but still a few bugs 2021-05-15 22:28:09 but if you want to roll your own images you can use our scripts, I would suggest starting with that branch 2021-05-15 22:29:00 PureTryOut[m]2: https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/393124#L8179 i reckon there's your problem 2021-05-15 22:30:46 Oh, ugh. 2021-05-15 22:30:58 That's way too high up and doesn't stand out enough 😛 2021-05-15 22:31:09 Also screw that, it's so close! 2021-05-15 22:35:19 Well in that case, is there a way to build all packages that have been updated in a branch? 2021-05-15 22:36:59 what do you mean? 2021-05-15 22:37:40 Well if I can't download the artifacts, then I want to build all the packages myself instead 2021-05-15 22:37:55 So how do I build everything updated in that particular branch? 2021-05-15 22:39:12 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L123? 2021-05-15 22:39:40 i think we could probably increase the threshold 2021-05-15 22:41:32 Well probably but then again you probably don't want to do that to have people try to get huge artifacts on purpose and clog up the cI 2021-05-15 22:50:11 Thanks for the link to that source, that seems to work nicely 2021-05-15 22:50:21 Now I'll let my laptop build all night 😛 2021-05-15 23:05:57 what would i need to do to get a package bumped from testing to community? 2021-05-15 23:07:02 Cadey: are you the maintainer? 2021-05-15 23:07:31 if it's been sufficiently tested, and you're comfortable maintaining it in community, open an MR to move it 2021-05-15 23:08:19 i am not the maintainer, however i could take over the package if that is needed 2021-05-15 23:08:40 what package is this 2021-05-15 23:10:14 tailscale, i am an employee of tailscale and we are adding alpine to our testing jungle 2021-05-15 23:15:37 imo it would be good to fix it for those disabled archs 2021-05-15 23:17:42 in general i think in such non-urgent cases, it is good to contact current maintainer to ask their thoughts. it is probably fine to open MR and mention them though 2021-05-15 23:25:43 Cadey: I'm working on a script to build cloud-init enabled disk images. Just created the repo (https://github.com/dermotbradley/create-alpine-disk-image)) a couple of hours ago but probably won't upload an early version of the script for a few days as its still a work-in-progress 2021-05-15 23:26:16 minimal: i managed to hack one up for my needs: https://github.com/Xe/alpine-image 2021-05-15 23:26:18 I'll upload an initial README to the repo shortly 2021-05-15 23:28:36 Cadey: yeah my script is derived from an Ansible playbook I've been using for over 1 year but will just be a simple shell script 2021-05-15 23:31:08 hmm... my personal notes on how to install alpine on btrfs on rpi3 doesn't seem to work with current setup-disk... 2021-05-15 23:38:09 Cadey: you don't need to "apk add" things like shadow and sudo as they are deps for the cloud-init package so they will be pulled in automatically 2021-05-15 23:38:47 i did say hack lol 2021-05-15 23:39:15 also you don't need the "rc-update add cloud-init" - simply run the "setup-cloud-init" script which takes care of that and other dependant stuff (all mentioned in the cloud-init package's README. I'm the Alpine package maintainer for cloud-init :-) 2021-05-15 23:40:59 fair 2021-05-15 23:41:05 i'll go edit my thing to do that 2021-05-15 23:41:07 thanks! 2021-05-15 23:41:20 Caddy: as there are *4* init scripts for cloud-init that are all needed 2021-05-15 23:41:33 yeah i getcha 2021-05-15 23:42:13 I've uploaded a README now to my script repo, the script will likely follow in a couple of days. There's a lot more to cloud-init config that what you've got in your script currently 2021-05-15 23:42:28 s/that/than/ 2021-05-15 23:42:29 minimal meant to say: I've uploaded a README now to my script repo, the script will likely follow in a couple of days. There's a lot more to cloud-init config than what you've got in your script currently 2021-05-15 23:42:50 was tailscale made by furries ? 2021-05-15 23:42:53 i'm changing it to use setup-cloud-init 2021-05-15 23:42:55 i am just asking 2021-05-15 23:43:03 because it is literally called tailscale 2021-05-15 23:43:06 Ariadne: as far as i can tell i am the only furry there that is open about it 2021-05-15 23:43:12 it's weird to me too 2021-05-15 23:43:29 haha 2021-05-15 23:43:30 Cadey: I mean there's more to do after running "setup-cloud-init" 2021-05-15 23:43:34 oh 2021-05-15 23:43:50 remember that time i clicked 'make presenter' instead of 'make moderator' and nuked ollieparanoid[m]'s talk halfway through 2021-05-15 23:44:11 Cadey: is there something the offical AMIs don't do that you need them to do? we're trying to make them really general purpose to avoid forcing others to build their own 2021-05-15 23:44:13 Ariadne: this is why i'm submitting a prerecorded video lol 2021-05-15 23:44:20 mcrute: run on libvirtd 2021-05-15 23:44:31 Cadey: it was prerecorded 2021-05-15 23:44:40 lol 2021-05-15 23:44:52 Cadey: using an ISO for the user-data? 2021-05-15 23:44:55 i feel like BBB needs to tweak that part of the UI though 2021-05-15 23:44:59 minimal: mmhmm 2021-05-15 23:45:03 ahh, that's high on my wish list :-) 2021-05-15 23:45:21 Ariadne: might want to advertise that disabling browser privacy extensions can be necessary as well 2021-05-15 23:45:24 i would be more than happy to inflict my hack upon you all 2021-05-15 23:45:26 I had to kill privacybadger 2021-05-15 23:45:32 mcrute: I'm sure you'll be interested to see my script when its uploaded 2021-05-15 23:46:00 ericonr: we did not know until today about such edge cases :D 2021-05-15 23:46:05 Cadey: any contributions that you're willing to make to that end would be really appreciated! 2021-05-15 23:46:14 but yes, will add some debug FAQ text 2021-05-15 23:46:31 minimal: indeed 2021-05-15 23:47:09 mcrute: i'm just out of the "make it work" phase 2021-05-15 23:47:39 weird, I have privacy badger on my desktop and was able to at least *chat* 2021-05-15 23:47:49 Cadey: libvirtd doesn't support cloud-init (not natively, think I saw a 3rd party "hack" to try and add a metadata server to it), so then typically with cloud-init the other option is an ISO containing the user-data/network-config 2021-05-15 23:47:59 yes 2021-05-15 23:48:03 that's what i've been doing 2021-05-15 23:48:34 Cadey: me too :-) 2021-05-15 23:48:36 Sheila: might have been necessary only for youtube access 2021-05-15 23:48:44 Cadey: gotcha. I've been hoping to use packer to run out current builder scripts on the qemu target. it's proved not simple so far. happy to collaborate to make any hacks work though 2021-05-15 23:48:49 idk, I was getting videos fine too 2021-05-15 23:49:05 youtube for me was just spinning 2021-05-15 23:49:10 libvirt does if you use the CD data provider. that's how we run it in house 2021-05-15 23:49:21 I can check in the morning tho, maybe I twiddled something for youtube embeds already a while back. 2021-05-15 23:49:36 Youtube worked find for me despite uMatrix blocking cookies 2021-05-15 23:50:02 ACTION hates that one needs so many add-ons for reasonable browsing 2021-05-15 23:50:42 same. and tbh I hate browsing in general. 2021-05-15 23:50:48 mcrute: keep an eye on https://github.com/dermotbradley/create-alpine-disk-image over the next week 2021-05-15 23:50:59 unfortunately, too many SPAs with no good desktop equivalent. :( 2021-05-15 23:51:41 minimal: Cadey: firecracker does it but they actually do packet filtering in their virtio-nic driver and redirect packets to a built in metadata server, it's ugly as hell 2021-05-15 23:52:00 jesus 2021-05-15 23:52:06 I had a hack at one point to do it with ebtables tricks but that was even ulgier IMO 2021-05-15 23:52:12 i guess that's one way to do it lol 2021-05-15 23:52:24 https://github.com/mcrute/mmds 2021-05-15 23:52:43 that's an AWS compatible metadata server, if you do the right hacks it does indeed bootstrap an instance 2021-05-15 23:52:49 mcrute: yeah I'd noticed that in firecracker. Nothing wrong with ISOs. Other option with NoCloud datasource is to use seeding URLs 2021-05-15 23:52:51 i'm just going with the "giant folder of yaml files and ISO generation script" approach 2021-05-15 23:52:52 easiest way to do it is with a second nic IMO 2021-05-15 23:53:13 Cadey: mind a pm? 2021-05-15 23:53:19 feel free 2021-05-15 23:57:30 if youtube gets to spinning point, you should be able to right click and copy video url then use mpv with built-in youtube-dl 2021-05-15 23:59:10 mcrute: noticed some patches were submitted to the Grub mailing a couple of months ago for AWS serial console support - but they're not going to make the GRUB 2.06 release 2021-05-16 00:01:23 Cadey: is there's anything you think is missing from the cloud-init packages's README.Alpine let me know 2021-05-16 00:02:12 minimal: i can't see anything, but my needs so far are running an edited form of this cloud init script: https://github.com/tailscale/tailscale/issues/1936 2021-05-16 00:02:21 minimal: does any feature make a GRUB release? :/ 2021-05-16 00:04:25 ericonr: 2.06 has been delayed so many times :-( 2021-05-16 00:05:39 Cadey: why the cloud_config_modules and cloud_final_modules parts? The rest (assuming you replace "systemctl" with "service") looks ok 2021-05-16 00:09:10 minimal: i adapted this from one for ubuntu which was adapted from one for fedora which was adapted from one for centos which was adapted from one for amazon linux lol 2021-05-16 00:10:22 https://gist.github.com/Xe/b61563b5c11ac61e1a198a9e4fcc6f97 this is my cloud config for alpine 2021-05-16 00:16:42 Cadey: you don't need the 1st section - runcmd is already defined in /etc/cloud/cloud.cfg 2021-05-16 00:16:57 runcmd was needed in centos 7 2021-05-16 00:17:28 likewise for user-groups 2021-05-16 00:17:46 i want to keep the cloud-configs as homogenous as possible across all 22 configs :) 2021-05-16 00:17:55 Cadey: I've talking about in the file as supplied with the Alpine package 2021-05-16 00:18:45 well if you're supporting multi-dists with multi-versions of cloud-init then you might find differences in behaviour 2021-05-16 00:19:09 well yes 2021-05-16 00:19:16 but this works enough to do what i need 2021-05-16 00:19:33 i'm not looking for perfect here minimal, if i wanted that i'd just use NixOS lol 2021-05-16 00:20:06 Cadey: I think the exit door is over to the right ;-) 2021-05-16 00:20:18 :P 2021-05-16 03:14:04 anyone here 2021-05-16 03:14:30 i am still struggling to understand how the cache is put in rw mode and back into in ro 2021-05-16 03:14:36 i mean which program does that? 2021-05-16 03:14:39 any ideas? 2021-05-16 03:17:32 apparently clandmeter said in history that "cache and lbu media is mounted ro, so each run of apk/lbu will remount it rw (and back) so cache and overlay can be writen." 2021-05-16 03:20:07 any chance the aarch64 uboot release image for 3.13.5 could get regenerated? the most recent linux-lts upgrade in the 3.13 branch fixes a problem where the SD card on some allwinner platforms was not being detected (it was a kernel regression in <5.10.32..) 2021-05-16 03:21:27 I've spent some time over the last day trying to generate an image myself using the aports/scripts/mkimage.sh but haven't had luck with that yet (I'm still trying to figure out what's going on there) 2021-05-16 03:21:31 we would just do a 3.13.6 for that 2021-05-16 03:21:38 i am sure it can be done on monday 2021-05-16 03:22:56 ah ok 2021-05-16 03:31:59 oneinsect: https://gitlab.alpinelinux.org/search?search=mount&group_id=2&project_id=5 2021-05-16 03:32:44 thanks Hello71: 2021-05-16 03:32:48 i will dig in now 2021-05-16 03:40:54 okie apparently apk takes care of mounting it in rw and back to ro 2021-05-16 03:41:29 part of apk-tools 2021-05-16 05:06:37 is gitlab CI or some other automation used to generate the release images for alpine? 2021-05-16 05:07:40 there was a talk about that :D 2021-05-16 05:08:04 yeah I haven't made it through all the talks. alpineconf runs from 1am my time until ~6am 2021-05-16 05:08:14 (west coast US..) 2021-05-16 05:08:45 is the recording available? 2021-05-16 05:08:53 for that talk you mentioned :P 2021-05-16 05:09:28 it was one of the live ones 2021-05-16 05:09:55 oh, those weren't recorded? 2021-05-16 05:10:14 ah, just saw your comment in #alpine-conf 2021-05-16 05:11:10 for some reason mkimage.sh seems to completely omit making a /boot in the image (using `--arch aarch64 --profile uboot`) 2021-05-16 05:11:25 so no kernel/initramfs is included 2021-05-16 05:13:01 craftyguy: https://bbb.dereferenced.org/playback/presentation/2.3/75a49eebcb63d6fee8c55417ea7cc51768d86f3d-1621065511930 2021-05-16 05:13:06 craftyguy: seek to 1:16:30 or so 2021-05-16 05:13:26 Ariadne: thank you :) 2021-05-16 05:39:33 ah my problem was missing squashfs-tools. I'm following the wiki page and somehow missed that step. oops 2021-05-16 05:42:44 craftyguy: 6am? it ran all the way until 10:30 am PST :D 2021-05-16 05:42:49 but yes 2021-05-16 05:42:52 F for the PSTers 2021-05-16 05:43:31 ah, so I could have joined in right at the end when I woke up :P 2021-05-16 05:43:48 I did catch the first two talks before I faded out 2021-05-16 05:44:21 the brony one and the one where i accidentally 86'd ollieparanoid[m]'s video stream? 2021-05-16 05:44:22 :p 2021-05-16 05:45:58 heh 2021-05-16 05:47:45 hmm, so squashfs-tools wasn't all I'm missing I guess. I still get an image that's ~12MB with no /boot 2021-05-16 05:48:53 I think it's because I'm using a system running pmOS to do this, and the mkinitfs thing is different. yeah, that's probably it 2021-05-16 06:05:40 PureTryOut[m]2: >>> Artifact size 301056000 larger than max (300000000), skipping uploading them 2021-05-16 06:07:51 PureTryOut[m]2: so it didn't upload them because it would have otherwise failed 2021-05-16 09:29:17 Yeah that got pointed out by Hello71 already 😉 2021-05-16 09:29:30 A bit annoying that it's so close 😅 2021-05-16 09:29:37 I've built it all locally overnight for now 2021-05-16 09:30:07 yeah, it was just barely over the limit :D 2021-05-16 10:05:21 hello 2021-05-16 10:06:04 could somebody take a look to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20855 ? 2021-05-16 10:06:21 I limited jobs to 4 for all archs and 2 for armv7 and avoided OOM problems 2021-05-16 10:11:01 are the package builders having oom issues as well or is it only CI builders that are overcommitting (as would seem reasonable for that environment, I guess)? 2021-05-16 10:12:09 IDK 2021-05-16 10:12:18 I mean, if limiting jobs is only needed for CI it could be good to while in "WIP:" but should be avoided for merge 2021-05-16 10:12:53 uhM, ikke are you there? 2021-05-16 10:13:58 CI OOM's way earlier than the builders do 2021-05-16 10:14:00 I experienced a problem with a host due ulimits when running a lot of containers with same user, maybe could it the problem with ci? 2021-05-16 10:14:15 For example qt5-qtwebengine almost always OOM's on CI, but once merged builds fine first time on all builders 2021-05-16 10:14:24 I wouldn't limit the builders because of CI personally 2021-05-16 10:14:26 the problem is that ikke tried to reproduce the OOM's on CI and it builded my package well with max JOBS 2021-05-16 10:14:34 is not clear that its really a OOM problem 2021-05-16 10:21:09 I'm here now 2021-05-16 10:21:18 hi 2021-05-16 10:54:38 What should we do with `tree`, for some reason, our builders always get timeouts from the source 2021-05-16 10:54:58 http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz 2021-05-16 10:57:22 back up the source i guess 2021-05-16 10:58:00 I've been copying the distfiles to the release dir before 2021-05-16 11:01:45 beh, forget ulimit "theory" 2021-05-16 11:11:31 is there some ENV var for difference CI from builders? 2021-05-16 11:12:05 CI, but we do not encourage to use that in APKBUILDs 2021-05-16 11:12:22 so once it builded fine with limited jobs could I just push again removing the limit? 2021-05-16 11:59:54 wlan doesn't work with latest linux-firmware-brcm (@edge) on my rpi3 2021-05-16 15:31:37 mcrute: ping 2021-05-16 18:37:27 great, quagga source is awol 2021-05-16 18:42:35 ikke: https://github.com/Quagga/quagga/releases/tag/quagga-1.2.4 2021-05-16 18:42:48 minimal: aha, thanks 2021-05-16 18:43:02 The link on their site is broken 2021-05-16 19:07:51 ikke: their main repo is also missing: https://git.savannah.gnu.org/cgit/quagga.git 2021-05-16 19:08:00 yes 2021-05-16 19:32:56 minimal: can you ping me if you discover something on that case? 2021-05-16 19:53:00 what are the specs for buildozers? it's incredible the build times O_O 2021-05-16 19:53:26 1 minute to completely build libretro-ppsspp 2021-05-16 19:53:37 markand: plenty of cores, pleny of ram 2021-05-16 19:53:41 :D 2021-05-16 19:53:54 pure awesomesauce 2021-05-16 19:54:03 You don't wnat to know what our arm builder has 2021-05-16 19:54:16 and about those archs, are they emulated? 2021-05-16 19:54:21 no, native 2021-05-16 19:54:23 all native 2021-05-16 19:54:32 gorgeous 2021-05-16 19:54:53 but, I've never met a mips64 machine anywhere, so you can order dedicated servers in those arch? 2021-05-16 19:54:55 only thing is that our 32-bits arches are run on 64-bit hardware 2021-05-16 19:55:04 riscv64 won't be, unfortunately 2021-05-16 19:55:09 yeahg 2021-05-16 19:55:11 (I know, I'm disappointed too.) 2021-05-16 19:55:14 that's going to be the exception 2021-05-16 19:55:27 mips64 is a router 2021-05-16 19:55:48 I've been told that powerful ARM machines are either utterly expensive or rare 2021-05-16 19:56:16 ARM sponsors us 2021-05-16 19:56:20 so nice 2021-05-16 19:58:01 unfortunately most ARM server options are aimed at large companies. however, you could get e.g. a Honeycomb from Solid-Run and a suitable chassis and rack that, I think. 2021-05-16 19:58:36 there are also programs like fosshost and WorksOnArm for FOSS developers. 2021-05-16 19:59:37 I wonder if ARM could come to "standard" motherboards such as ATX and such, but to my understanding it's not the case because of non standard sockets at the moment 2021-05-16 20:05:38 it's more that nobody wants to spend the money on it because the popular perception is still that ARM is crap for desktop workloads. 2021-05-16 20:33:29 Apple might change that 2021-05-16 20:45:33 I hope so, yeah. 2021-05-16 21:39:31 i dont get the point of "standard motherboards" for x86 anymore anyway 2021-05-16 21:39:40 it's not like you can put a gen N+k cpu in a gen N motherboard anyway 2021-05-16 21:39:57 having the cpu be swappable doesn't seem useful 2021-05-16 21:40:12 (even if you could it would perform like a gen N cpu there..) 2021-05-16 21:45:32 it was really only interesting for AMD, and then only if you had an an AMD3+ socket mobo but had to use an AMD3 processor, etc. 2021-05-16 21:45:48 (with a view toward upgrading when you could afford it) 2021-05-16 21:46:04 but yeah, really not helpful. 2021-05-16 21:55:50 even with AM4 you could use cpus from multiple generations on one motherboard 2021-05-16 21:56:23 but even upgrading withing the same generation could make sense, for instance upgrading from a 4 core part to a 16 core part on the some motherboard 2021-05-16 22:28:19 i dont really understand the idea of upgrading a pc 2021-05-16 22:28:27 i mean i understand the theoretical appeal 2021-05-16 22:28:46 when i was a teenager i always wanted to get boards i could upgrade 2021-05-16 22:28:57 and never, not once, was the capability actually useful 2021-05-16 22:29:07 by the time there was something new interesting to upgrade to 2021-05-16 22:29:17 it would be like 10% faster to do the upgrade on the board i had 2021-05-16 22:29:25 or if i wanted a real upgrade it would need a whole new board 2021-05-16 22:30:05 it's the ultimate in yagni engineering :( 2021-05-16 22:30:48 but it is not like that on AM4, going from the slowest to the fastest cpu on that socket is like more than 10 times as fast 2021-05-16 22:48:39 dalias: (bloated apps) ram requirements have gone up faster than cpu 2021-05-16 22:49:10 also historically oems have cheaped out on ram and sold systems based on "i5" or "i7" 2021-05-16 23:19:32 upgradable ram makes sense 2021-05-16 23:19:50 upgradable cpus doesn't really unless it's just ability to add more cores for smp 2021-05-16 23:31:59 could add other functionality, if the software and firmware support it, not just more cores. 2021-05-17 00:34:35 Ariadne: I took a look at the proposition of sending a banner message vor AGPLv3 compliance but there's no such thing in the MAPI over HTTP spec. And the version strings have to be formatted in a certain way, so we can't add anything in there either 2021-05-17 00:35:17 Do you have any specific term I can look for? 2021-05-17 02:07:21 Thermi: no clue, sorry. we can live with the current situation i guess. 2021-05-17 04:02:49 what's the reason for having alpineconf again 1/2 year from now? most conferences for a particular thing are annual :P 2021-05-17 04:04:07 also, congrats on the successful 1st alpineconf!! the talks have been great (I'm still working my way through the ones from the 2nd day) 2021-05-17 04:46:16 craftyguy: mainly to give opportunities for people who weren't able to participate actively this time, I think 2021-05-17 04:48:23 I know there's interest in holding at least one virtually every year as it gives people like me (I'm deaf-blind) an opportunity to participate. 2021-05-17 06:11:35 craftyguy: the mini alpineconf is technical-oriented 2021-05-17 06:11:47 craftyguy: the main alpineconf is supposed to be more 10000' foot view of everything 2021-05-17 06:11:59 ah, I see 2021-05-17 06:12:12 so mini alpineconf in november is basically 2021-05-17 06:12:19 lets talk about apk-tools internals for 2 hours 2021-05-17 06:12:33 while alpineconf is lets talk about alpine on windmills 2021-05-17 06:12:38 and phones 2021-05-17 06:12:39 :) 2021-05-17 06:14:59 nice 2021-05-17 06:15:47 Ariadne: are slides public? 2021-05-17 06:15:59 they areon the replay 2021-05-17 07:19:20 good morning 2021-05-17 07:20:03 Good morning 2021-05-17 07:38:10 Hi 2021-05-17 07:40:27 _0/ 2021-05-17 07:47:20 ncopa: I see you are orphaning some pkgs. should we take some of them (most maybe) or move to unmaintained 2021-05-17 09:42:10 possibly yes 2021-05-17 09:46:17 oh, I see these are not your pkgs but someone else who is not active anymore 2021-05-17 09:47:49 motif and heirlom-mailx deserves care 2021-05-17 10:08:54 https://github.com/AkihiroSuda/lima/tree/master, lima - linux on mac, like wsl 2021-05-17 10:09:23 there is even example to run nginx on alpine 2021-05-17 10:49:57 anyone knows what's going on with openldap? Seems libtool is acting up? 2021-05-17 10:50:21 ../../libtool: line 1: X--mode=compile: not found 2021-05-17 10:54:06 yes, maybe is related to new autoconf 2021-05-17 10:57:19 hmm, builds locally 2021-05-17 10:58:32 well, it fails, but for a different reason 2021-05-17 13:00:01 botan test suite fails on aarch64 for some reason 2021-05-17 23:12:20 mps: how should I make patches to aports to change kernel config for linux-edge? 2021-05-17 23:13:02 I tried the obvious way, just patch the bundled config directly, but I'm not sure if you'd prefer some other way or ?? 2021-05-18 00:08:38 CI getting ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: network error (check Internet connection and firewall) and fatal: unable to access 'https://gitlab.alpinelinux.org/alpine/aports/': Failed to connect to gitlab.alpinelinux.org port 443: Operation timed out at random 2021-05-18 00:09:10 yeah I saw that too a few minutes ago 2021-05-18 00:09:19 a retry worked for my 2021-05-18 00:09:29 but intermittent connection problems to itself is.. weird 2021-05-18 00:10:18 (ok maybe not to itself, but it was gitlab.alpinelinux.org CI failing to fetch from a gitlab.alplinelinux.org repo in my case) 2021-05-18 00:21:33 hmm still happening: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/395094 2021-05-18 02:04:10 Yep, happening to me too 2021-05-18 02:31:11 can I get review on this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21484 2021-05-18 04:42:27 How would I go about getting an archive into https://dev.alpinelinux.org/archive ? 2021-05-18 06:04:39 Dadrophenia: ask someone to upload it :) 2021-05-18 06:45:24 Adran sweet! I'm making a snapshot() function for the first time because the package ardour requires a git clone of the repo to get a non volatile source. So I was wondering if someone with access could run the snapshot function to get the archive on the dev site: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21517 2021-05-18 06:45:40 Oops I @'d the wrong person, my bad 2021-05-18 06:51:05 craftyguy: I prefer to not have MRs for linux-edge (or linux-lts) but talking/requesting changes on IRC or creating bug/wish requests at gitlab.a.o 2021-05-18 06:52:07 it is not so easy (for me) to update/fix MRs or test them 2021-05-18 06:53:07 mail to alpine-devel ML or directly to me is also ok 2021-05-18 06:54:18 ofc, if the required changes are urgent then MR is ok, especially if I'm not 'online' so someone can merge 2021-05-18 06:56:05 craftyguy: anyway, your MR looks ok, will add these changes to next linux-edge upgrade. if it is not urgent right now? 2021-05-18 09:44:02 Ariadne: some comments from one big firejail collaborator: https://github.com/netblue30/firejail/issues/4210#issuecomment-841882340 he says "I follow the development of bubblejail since I discovered it and it is the best alternative to firejail I know." hehe 2021-05-18 10:40:46 donoban: :) 2021-05-18 10:41:01 donoban: i largely think that person is in denial about how bad the situation is with firejail but :) 2021-05-18 11:52:32 Cadey: in order to use Busybox's mount you may need to add a workaround: create the file /etc/filesystems with a single line "iso9660" and retry 2021-05-18 11:52:59 Cadey: I hit this problem when using cloud-init and added a note to that package's README.Alpine to mention the issue 2021-05-18 11:53:02 minimal: ah 2021-05-18 11:53:13 is there any reason why accounts are locked by default? 2021-05-18 11:53:18 or is that just an alpine broken 2021-05-18 11:53:23 Cadey: with cloud-init you mean? 2021-05-18 11:53:29 yes 2021-05-18 11:54:13 Cadey: because that's the default :-) you can tailor it however you want however though 2021-05-18 11:54:46 for cloud-init you should have a look at README.Alpine as its where I add any important notes in general 2021-05-18 11:55:00 okay so from the point where i'm making images in packer 2021-05-18 11:55:17 how do i make it so that the dumb thing that cloud-init does is the correct thing that doesn't break accounts upon creation? 2021-05-18 11:55:22 Cadey: package cloud-init-doc, file /usr/share/doc/cloud-init/README.Alpine 2021-05-18 11:56:01 Cadey: dumb? break? what are you trying to achieve? 2021-05-18 11:57:31 minimal: https://github.com/Xe/mkvm/blob/main/var/xe-base.yaml#L11-L18 this to work (assume the VM image contains bash already) 2021-05-18 11:58:05 also rather than using genisoimage I'd recommend using "cloud-localds" from the cloud-utils package 2021-05-18 11:59:29 i'll look into that, how do i make the user account work though? 2021-05-18 12:01:00 like without having to manually usermod my user 2021-05-18 12:01:34 Cadey: should we take this to the #alpine-cloud channel as its a cloud-specific issue? 2021-05-18 12:15:51 Why edge-armv7 builder is missing? 2021-05-18 16:23:38 mps: ok thanks, yeah I know how annoying it is trying to maintain kernel config like that.. when changes come in either from requests or from new options in the mainline kernel, etc 2021-05-18 16:38:24 craftyguy: technically it is not big problem, but keeping it in 'good shape' between major versions is a somewhat complicated from user point of views 2021-05-18 16:39:16 for example, deprecated options/drivers/features, or interdependencies of drivers/options 2021-05-18 16:39:55 right 2021-05-18 16:40:39 because this I prefer to test build on every upgrade on all 3 arches before pushing to builders 2021-05-18 16:40:45 anyways, thanks for being open to accepting that patch. it seems like this driver was disabled at one point, IIRC PureTryOut[m]2 had this platform booting alpine a while back 2021-05-18 16:41:38 craftyguy: if it urgent to you i will do make it and push this evening 2021-05-18 16:42:06 it is* 2021-05-18 16:42:55 mps: sure if you have time. I'd like to get this platform working so I can use it, but I understand if you've got other priorities. it could wait for 5.12.5 too, since that'll be in a few days I guess 2021-05-18 16:43:05 ACTION /nick craftsmen :) 2021-05-18 16:43:40 ok, will try this evening 2021-05-18 16:48:52 mps: cool, thank you :) 2021-05-18 16:49:33 np 2021-05-18 16:50:46 I hope you will write what SBC it is when you test it so we can add one more on 'works' list (which exists only in our heads :) ) 2021-05-18 17:00:59 ah sure, I thought I had mentioned it in the commit message, but it's a Pine64 A64-LTS SBC (I can add that somewhere after I get it working again) 2021-05-18 17:53:26 craftyguy: lets see how git push works with pushing two commits in one branch :) 2021-05-18 17:56:49 omg, aarch64 builder is blocked by sn0int 2021-05-18 17:58:46 error[E0432]: unresolved import `libc::HWCAP_AES`, anyone knows something about it 2021-05-18 18:02:45 yet another useless pkg in alpine 2021-05-18 18:04:15 Theres no HWCAP_AES in aarch64 i think 2021-05-18 18:04:52 it's fixed in 0.21.1 2021-05-18 18:04:59 Its AESNI 2021-05-18 18:04:59 see !21533 2021-05-18 18:06:08 aha 2021-05-18 18:06:22 did already look briefly into that 2021-05-18 18:06:47 I reported it to upstream yesterday :D 2021-05-18 18:07:11 would you merge it or ... (I'm tempted) 2021-05-18 18:07:12 Nice work 2021-05-18 18:07:42 mps: just wait until it passes on ci 2021-05-18 18:08:11 ok, will increase my patience threshold :) 2021-05-18 18:08:40 hehe :) 2021-05-18 18:08:53 Lots of upstream developers forget that ARM exists 2021-05-18 18:09:06 Or just don't have machines to test on 2021-05-18 18:09:23 hehe, we will wait a lot, download of some things looks stuck 2021-05-18 18:09:39 You could setup termux on Android and compile it there 2021-05-18 18:10:55 mps: ufff 2021-05-18 18:11:06 kurko24695: Some folks only have an iPhone 2021-05-18 18:11:09 we definitely need one extra repo for such things 2021-05-18 18:11:20 mps: downside of letting cargo do dependency handling for us I guess :/ 2021-05-18 18:11:34 nmeum: also I think so 2021-05-18 18:11:51 I will just merge it 2021-05-18 18:11:55 it just a minor release after all 2021-05-18 18:11:57 But either way, not all devs have all arches available or have the time to set CI up for all different combinations of OS x Arch, so I suppose we'll just have to live with !x86_64 to fail at time 2021-05-18 18:11:59 ok 2021-05-18 18:12:06 Maybe CPUs like the M1 will change this soon though :D 2021-05-18 18:12:45 Qemu exists, but its painfully slow for compilation 2021-05-18 18:12:47 well you can virtualize most arches with qemu this day 2021-05-18 18:13:02 yeah, if it's a big software it's kind of annoying 2021-05-18 18:13:03 Yup, but I doubt many devs have the know-how to set this up 2021-05-18 18:13:05 nmeum: ah, you fixed it, very good 2021-05-18 18:13:21 b9347e7e378544569003d36d3ab7cc0cf2afd95f 2021-05-18 18:13:23 or nice* 2021-05-18 18:13:41 never will remember these things in english 2021-05-18 18:13:44 should unblock aarch64 (hopefully) 2021-05-18 18:14:13 It took me one entire day (24 hours) just to compile and test a library on qemu ;( 2021-05-18 18:14:25 oof 2021-05-18 18:14:40 kurko24695: qt* ;) 2021-05-18 18:15:48 Well I may have configured it incorrectly since I am not a qemu pro but still 2021-05-18 18:16:16 KVM is awesome but only when its available 2021-05-18 18:16:46 apparently qemu-user works better 2021-05-18 18:17:24 doesn't dabuild support cross compilation with qemu-user? 2021-05-18 18:17:56 I remember that I built some not small things (but also not too big) for armhf/armv7 in qemu (not qemu-user) on i7 cpu 2021-05-18 18:21:37 Yes I was aware not emulating the whole system would be faster, but I was too noob at that time 2021-05-18 18:23:30 I'm newbie always ;) 2021-05-18 18:26:20 I'm using qemu for years, (from first beta versions) and just 9-12 months found how to run it efficiently on big.little cpu machines 2021-05-18 18:48:08 craftyguy: we have to wait when aarch64 builder get linux-edge from queue and to upload. I fear it will not be soon 2021-05-18 18:58:34 What can I do with this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21105 The maintainer isn't responding 2021-05-18 18:59:10 mps: ah, well, you tried :P 2021-05-18 18:59:33 z3ntu: did you try sending an e-mail directly to the maintainer? 2021-05-18 19:00:16 ikke: Not yet, I'll do that now 2021-05-18 19:00:32 If they don't respond to that, you'll probably have to adopt the package and then move it to community 2021-05-18 19:00:37 nod 2021-05-18 19:02:52 > Unfortunately, messages from [$my_server_ip] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3140). 2021-05-18 19:02:53 nice... 2021-05-18 19:02:56 thanks microsoft 2021-05-18 19:06:44 anyone knows why gtk+3.0 cannot find gdk.h? 2021-05-18 19:07:02 gdk.h is from gtk+3.0 itself đŸ€” 2021-05-18 19:07:17 yes 2021-05-18 19:07:49 Ah, maybe the documentation stuff broke for some mysterious reason (new meson, new gtk-doc)? 2021-05-18 19:07:59 I suppose we could just disable the documentation for now to unblock the builders 2021-05-18 19:08:01 Let me do that right now 2021-05-18 19:08:14 I doubt many people use our docs anyway when upstream publishes them too 2021-05-18 19:10:41 Done 2021-05-18 20:45:14 Any good, already existing www/php cgi script user? 2021-05-18 20:48:43 Hmmmh. Should be different per webapp anyway. 2021-05-18 20:48:46 I'll make and use my own. 2021-05-19 03:39:45 Cogitri: when you have time, could you take a look at this one again? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21414 2021-05-19 03:39:50 (squeekboard upgrade) 2021-05-19 06:54:54 Ah sure, thanks for the reminder 2021-05-19 06:57:28 Cogitri: I think I found the issue 2021-05-19 06:57:32 with rust on CI 2021-05-19 06:58:05 Oh :o 2021-05-19 06:58:38 I guess CARGO_BUID_JOBS was recently added to abuild.conf? 2021-05-19 07:00:59 yes 2021-05-19 07:01:02 good morning 2021-05-19 07:01:20 Morning 2021-05-19 07:01:27 our build.sh script mangles it to set JOBS=$(nproc) 2021-05-19 07:02:51 so it would become CARGO_BUILD_JOBS=$(nproc)$JOBS 2021-05-19 09:55:24 FYI: the alpine council & technical committee have observed the freenode staff mass-kill and canary notice left a few hours ago. we are discussing options to move the IRC channels off freenode. 2021-05-19 09:55:46 please stay tuned, we should have a conclusion and ETA within a few hours. 2021-05-19 09:56:19 :\ 2021-05-19 09:56:53 that is unfortunately, all I have at the moment. thanks for your patience :) 2021-05-19 09:57:03 thanks for being so reactive ♄ 2021-05-19 09:57:58 speaking in personal capacity, it is ridiculous that we have to waste our time on this 2021-05-19 09:58:09 i plan to send this new freenode CEO an invoice for my time 2021-05-19 09:58:11 :) 2021-05-19 09:59:00 it is not fair to my sponsors that they should have to pay for the fallout caused by one man's megalomaniacal desires to control the entirety of IRC 2021-05-19 10:04:50 human nature, when have much wants more, (power, money, knowledge, control, girls in harem .... whatever) 2021-05-19 10:05:21 Ariadne: where is that canary note? 2021-05-19 10:10:04 btw, what is 'alpine technical committee' 2021-05-19 10:11:02 mps: the core team was split into alpine council and TSC 2021-05-19 10:11:29 this was the last thing announced at alpineconf :) 2021-05-19 10:11:58 I thought that was just idea and not finalized 2021-05-19 10:13:03 it's been in the works for a while 2021-05-19 10:14:42 I'm not sure is good idea for me to 'stay' with cathedral model distro 2021-05-19 10:18:53 not sure I'd characterise the new leadership as being that, since the day-to-day stuff hasn't changed. 2021-05-19 10:20:21 we will see, but looks that is 'selected' path. 2021-05-19 10:21:13 and no, I will not object to this, just say that doesn't fit my 'work habits' 2021-05-19 10:23:55 mps: the intention is for both the technical committee and the council to stay out of the way 2021-05-19 10:24:12 i am certainly not interested in telling people what to do 2021-05-19 10:26:12 could someone explain what happens with freenode? 2021-05-19 10:26:27 donoban: power struggle 2021-05-19 10:26:32 check their page and twitter and I didn't see nothing relevant 2021-05-19 10:27:04 https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 2021-05-19 10:27:30 thanks ikke 2021-05-19 10:28:05 Also https://fuchsnet.ch/freenode-resign-letter.txt 2021-05-19 10:28:19 Ariadne: I hope that will work, but again 'lets see' 2021-05-19 10:28:23 ty 2021-05-19 10:28:57 we also discussed the situation at alpineconf 2021-05-19 10:29:00 ;) 2021-05-19 10:29:53 the freenode situation? the 2Âș alpineconf day? 2021-05-19 10:30:01 yes 2021-05-19 10:30:20 I haven't see anything from that day :( 2021-05-19 10:30:26 I hope to do it this weekend 2021-05-19 10:38:15 interesting. was able to make MRs to Alpine/aports from @Aerdan1, but am not from @Aerdan. 2021-05-19 10:38:38 Sheila: do you get an error? 2021-05-19 10:39:08 it outright refuses to let me pick Alpine/aports as a target when I click 'change branches' 2021-05-19 10:39:43 I guess it's not a fork of alpine/aports? 2021-05-19 10:41:04 it should be, but appears gitlab doesn't think so. will do some poking. 2021-05-19 10:41:33 It's a stand-alone project 2021-05-19 10:41:53 easiest would be to delete it and then for it from alpine/aports 2021-05-19 10:42:09 I removed JOBS limitations after confirm that it builds fine with it on CI 2021-05-19 10:42:21 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20855 2021-05-19 10:42:58 donoban: I fixed one issue with our CI which might be related to what you've been seeing 2021-05-19 10:43:13 oh, so let's try again 2021-05-19 10:43:20 yep, doing that. 2021-05-19 10:45:30 donoban: https://twitter.com/shadowcat_mst/status/1394941192874364928 more on the shitshow, if you're curious. 2021-05-19 10:48:03 :) 2021-05-19 10:49:32 this is really sad, I hope there is some chance to continue as it is 2021-05-19 10:50:03 from what I've seen, I really doubt it. 2021-05-19 10:50:41 They did announce libera.chat, but it's still locked 2021-05-19 10:52:15 but Andrew Lee would realise that he will get an near dead network? 2021-05-19 10:52:33 nah, people are too lazy to move 2021-05-19 10:53:00 well this is not github hehe 2021-05-19 10:53:11 very simple migration 2021-05-19 10:53:16 not really. 2021-05-19 10:54:43 1. new location needs to be found, whether on another IRC network or on own-hosted resources or Discord or
 2. new location needs set up and configuration. 3. tombstone needs to be left directing people to the new location 4. hold your breath and hope enough people uptake that you can remove the old location entirely. 2021-05-19 10:54:54 oftc? 2021-05-19 10:55:13 the TSC has been considering how they want to proceed 2021-05-19 10:55:30 yes, it is OFTC 2021-05-19 10:55:39 we have taken some preliminary steps to secure the channels on OFTC 2021-05-19 10:55:43 so you can feel free to join over there. 2021-05-19 10:57:29 ikke: it builded fine on x86_64! let's try the rest of archs 2021-05-19 11:17:58 donoban: aarch64 passed as well! 2021-05-19 11:18:31 all is green 2021-05-19 11:19:09 i also recommend that if you are only on freenode for alpine, that you delete your data on the way out the door 2021-05-19 11:19:22 who knows what this andrew lee fellow is going to do with it 2021-05-19 11:19:24 ttps://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/commit/99cdded87bd3efdaa47a0997abad938d37e31ff6 2021-05-19 11:20:39 Ariadne: good advice 2021-05-19 11:20:57 Is that data not already compromised? 2021-05-19 11:21:10 not sure if deleting will help a lot 2021-05-19 11:21:24 anyone knows for guide/howto about deleting them (data) 2021-05-19 11:21:47 ikke: who knows :) 2021-05-19 11:21:54 mps: /msg nickserv help drop 2021-05-19 11:22:20 But it at least reflects in their numbers 2021-05-19 11:22:27 if they see a drop in registered users 2021-05-19 11:23:10 even without freenode action, chat logs are for sure 'secured' in TLA premises 2021-05-19 11:26:05 huh that means that i might be able to live forever through the chat logs that the NSA has backups of for me 2021-05-19 11:27:20 so you'll be as immortal as the NSA 2021-05-19 11:27:23 yes, and not only NSA, there are more 2021-05-19 11:28:00 oh damn my yayposts are replicated globally 2021-05-19 11:33:22 ikke: yeah nice, what was the problem? 2021-05-19 11:38:34 See that link 2021-05-19 11:45:15 I see, great 2021-05-19 12:04:59 ikke, done 2021-05-19 12:23:49 libera.chat 2021-05-19 12:25:08 yes, this looks promising but it is not operational yet 2021-05-19 12:25:30 it is now 2021-05-19 12:25:38 https://www.oftc.net/ ♄ 2021-05-19 12:25:48 really!? move there :) 2021-05-19 12:26:08 we already concluded OFTC was a better choice because people were already there 2021-05-19 12:26:10 :p 2021-05-19 12:26:20 but we can have an outpost on liberachat too :) 2021-05-19 12:26:30 I joined the channels there 2021-05-19 12:26:32 besides, andrew lee is probably going to sue them into the ground 2021-05-19 12:27:29 after all this something on alpine infra is proper solution, imo 2021-05-19 12:27:54 -NickServ- The account fcolista has been dropped. 2021-05-19 12:27:56 bye 2021-05-19 12:28:07 now I will start to advocate matrix 2021-05-19 12:28:15 :D 2021-05-19 12:28:36 hopefully that advocacy comes with substantive performance improvements... 2021-05-19 12:29:25 and reliability 2021-05-19 12:29:46 I'll wait dropping my accounts until we have everything set 2021-05-19 12:30:00 that's my plan as well 2021-05-19 12:30:05 yeah i dropped now because i don't have any access to anything that isn't already covered 2021-05-19 12:30:07 :) 2021-05-19 12:30:41 Also if you as channel founder drop your account, some random other person will get founder status it seems 2021-05-19 12:30:48 its not random 2021-05-19 12:30:56 it chooses the oldest account with the most permission bits set 2021-05-19 12:31:05 somebody wrote their thesis on that code! 2021-05-19 12:31:35 an algorithm for lines of succession... could have been useful in medieval times 2021-05-19 12:31:37 So we have the same channels as we do now, but on OFTC? 2021-05-19 12:31:42 correct 2021-05-19 12:31:48 yup 2021-05-19 12:32:02 Okie, time to join those then, thanks 2021-05-19 12:32:15 Ah they exist already? 2021-05-19 12:32:18 yes 2021-05-19 12:32:22 everything is ready to go :) 2021-05-19 12:32:23 Cool, moving 2021-05-19 12:32:34 We could set that as room motto then 2021-05-19 12:32:35 postmarketOS has not moved yet 2021-05-19 12:32:42 hopefully soon :) 2021-05-19 12:32:57 We'll move soon, and imo to OFTC as well, but we haven't discussed it yet 2021-05-19 12:33:08 Anyways, leaving here so see ya at OFTC 👋 2021-05-19 12:33:12 yes would be ideal to keep it all in the same place :) 2021-05-19 12:48:12 everyone quit 2021-05-19 12:48:15 hmmmm 2021-05-19 12:48:27 I've over there on #alpine-devel and #alpine-linux (well, technically #oftc#alpine-devel:matrix.org and #oftc#alpine-linux:matrix.org) too 2021-05-19 13:11:13 Ariadne: for #-channels it's always freenode-staff 2021-05-19 13:11:18 i think this changed some time in the last decade 2021-05-19 13:11:26 mis tab? 2021-05-19 13:11:44 no 2021-05-19 13:12:06 o 2021-05-19 13:12:08 i see 2021-05-19 13:12:10 weird :) 2021-05-19 13:13:15 even +S doesn't do anything afaik 2021-05-19 16:30:26 anyone else using main/less? does horizontal scrolling also crash less for you? 2021-05-19 16:31:29 yes, I can reproduce that 2021-05-19 16:32:12 also turning line wrapping of does crash it 2021-05-19 16:32:12 did you try LC_ALL=C 2021-05-19 16:32:45 Hello71: does not fix it for me 2021-05-19 16:32:53 hm. 2021-05-19 16:32:59 it crashes with SIGILL 2021-05-19 16:33:09 what arch? 2021-05-19 16:33:18 x86_64 2021-05-19 16:33:31 also crashes on aarch64 2021-05-19 16:33:41 SIGILL is an odd crash.. 2021-05-19 16:53:34 \o/ 2021-05-19 16:55:35 whooo 2021-05-19 16:55:40 !21477 2021-05-19 16:55:45 it works again, nice 2021-05-19 16:55:58 made a typo 2021-05-19 16:56:33 \o/ 2021-05-19 16:57:07 well, alpine and debian on the same irc network, and there is not a giant black hole yet 2021-05-19 16:57:09 ;) 2021-05-19 16:57:14 heeeyo 2021-05-19 16:58:34 :> thats good 2021-05-19 16:59:35 nmeum: less crash also on armv7 here 2021-05-19 17:17:26 o7 2021-05-19 17:17:33 hai 2021-05-19 18:00:47 also, as alpine and debian are now on the same irc network, we moved #ifupdown-ng too :) 2021-05-19 18:16:05 Is it possible to restrict the privileges of OpenRC services like you can with systemd? 2021-05-19 18:43:36 Can I get a review on this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21493 2021-05-19 18:49:56 Newbyte[m]: traditionally services are restricted by creating and using a new user, and adding chroot if you want more security 2021-05-19 18:50:34 last i checked, openrc doesn't really support linux-specific sandboxing apis like seccomp 2021-05-19 18:51:04 ok I think I completely switched to oftc 2021-05-19 19:02:11 Hello71: yes, but can I declare that the service will do this in its service file? 2021-05-19 19:02:48 well if the service doesn't need root for anything then just, put, uh... depends if you are using start-stop-daemon or supervise-daemon 2021-05-19 19:03:11 but often service needs to listen on privileged ports, etc 2021-05-19 19:05:05 yes, but with systemd you can do cool stuff like this without much effort: https://gitlab.com/mobian1/devices/eg25-manager/-/merge_requests/16/diffs 2021-05-19 19:05:21 is there an equivalent for OpenRC? 2021-05-19 19:05:32 or like, something similar 2021-05-19 19:05:32 no 2021-05-19 19:05:41 as i said, those are all linux-specific 2021-05-19 19:05:56 oh, I see 2021-05-19 19:06:01 Thank you anyway 2021-05-19 19:06:07 i think someone could make a general service sandboxing mechanism 2021-05-19 19:06:12 maybe extend execline? 2021-05-19 19:06:52 also most of those are redundant with NoNewPrivileges and User!=root 2021-05-19 19:07:37 it would be nice because there's really no reason for e.g. eg25-manager to run as root with full privileges in Alpine, but I'm not sure how it would be done better 2021-05-19 19:08:05 but, interesting idea of a general service sandboxing mechanism 2021-05-19 23:14:53 I can see that the php module packages contain ini files to load them by default. Should I still ship ini files for the web application that loads these modules? They'd also go into /etc/php$digit/conf.d 2021-05-19 23:14:59 . 2021-05-20 00:52:15 hi all 2021-05-20 04:59:34 mps: clamav has been moved to community, but acf-clamav in main depends on it 2021-05-20 05:47:59 ikke: wonder how did i missed that. I think I checked with 'ap revdep clamav' before move 2021-05-20 05:48:37 is it ok move acf-clamav also to community? 2021-05-20 05:50:16 !21583 2021-05-20 05:51:17 I would merge it right now, and not wait for maintainer 2021-05-20 05:51:44 haven't seen Ted active for some time 2021-05-20 05:52:38 i think so 2021-05-20 05:53:16 Ted is responsive 2021-05-20 05:53:23 yes, ping his email 2021-05-20 05:53:48 he responds to notifications from gitlab 2021-05-20 05:54:29 I based my thinking on git log 2021-05-20 05:55:01 and looks like this is not good idea 2021-05-20 05:55:04 ACF is mostly a finished product, it does not need much development these days 2021-05-20 08:56:50 hey there 2021-05-20 08:57:22 I'm trying to find example of packages that "protect" files (like configuration or files in /var/db) that you should not remove on package removal 2021-05-20 08:57:29 how is this handled in APKBUILDs? 2021-05-20 08:58:01 a post-install script that install a file by default only if not present? 2021-05-20 09:07:58 configuration files are removed on uninstall, stuff like specific users etc. are not removed on uninstall and created by post-install script. some daemons also create files in /var via checkpath (described in openrc-run(8)) from openrc services 2021-05-20 09:08:20 what specific file are you thinking of? 2021-05-20 09:46:53 we're creating a file that contains admin RFID tags and it must not be removed upon deinstall but I think I'll just make it completely independant from the package 2021-05-20 09:47:06 like : it should be created by hand 2021-05-20 09:48:32 hmmm now I remember, it's the install target of our software that create those files, that's why they are tracked by apk and removed on deinstall 2021-05-20 09:49:12 there are definitely no equivalent to Arch Linux's backup variable? 2021-05-20 10:06:00 considering this is the first i've ever heard of it, i would say no 2021-05-20 10:07:31 markand: can they be autogenerated in a post-install trigger a la SSH keys? or is that what you're trying to do? 2021-05-20 10:08:08 afaik apk won't remove files introduced by the package's `.post-install` 2021-05-20 10:08:26 It won't 2021-05-20 10:08:37 it only manages files that came with the package 2021-05-20 10:11:18 though apk does not remove modified configuration files unless --purge is specified 2021-05-20 10:12:20 yes, but only for /etc 2021-05-20 10:13:14 yeah, but I guess that's our approach for solving the problem arch attempts to solve using the pkgbuild backup variable 2021-05-20 16:03:53 notice: I will be running updates on the alpine linux mailing lists shortly, there will be some brief downtime 2021-05-20 16:11:34 done 2021-05-20 16:27:22 o/ 2021-05-20 16:27:39 huhu 2021-05-20 16:28:32 very important question, what's my nick 2021-05-20 16:28:57 insep 2021-05-20 16:29:18 it works yay 2021-05-20 16:29:21 ty 2021-05-20 17:38:07 is there a straight forward way to add 'features' (modules) to an image made with aports/scripts/mkimage.sh? 2021-05-20 17:40:56 15 2021-05-20 17:40:59 oops 2021-05-20 17:41:30 Time to change your password :P 2021-05-20 17:41:40 lol 2021-05-20 19:35:30 Somebody please look at !8569 2021-05-20 19:35:36 The packages are finalized 2021-05-20 22:35:12 mps: yes, I'm here 2021-05-20 22:35:34 thank you for moving acf-clamav 2021-05-20 22:35:38 no objection here 2021-05-20 22:56:05 tdtrask: ikke made MR to move it, not I 2021-05-20 22:56:42 I moved clamav but missed somehow acf-clamav 2021-05-20 22:57:10 and nice you are here :) 2021-05-20 23:54:36 well, thanks to ikke too :D 2021-05-21 05:38:45 /msg NickServ IDENTIFY oneinsect gamegirl 2021-05-21 05:38:53 oops 2021-05-21 05:38:57 oops 2021-05-21 05:38:58 sorry 2021-05-21 05:39:07 oops 2021-05-21 05:39:28 can you guys delete it? 2021-05-21 05:39:54 no 2021-05-21 05:40:01 never mind 2021-05-21 06:15:21 don't worry, I only saw ********** 2021-05-21 06:15:48 lol 2021-05-21 06:17:06 btw a quick question, once I have bootstrap compiled apks consisting of gcc, binutils etc with some tools apparently with sysroot hardcode, I then chroot into it and rebuild everything again from scratch 2021-05-21 06:17:08 isnt it? 2021-05-21 06:17:52 oneinsect: correct 2021-05-21 06:18:02 thanks! Sheila: 2021-05-21 06:26:00 all this wayland-protocols dependent stuff is failing to build 2021-05-21 07:18:35 mkfs.ext4 is in /sbin while mkfs.fat is in /usr/sbin 2021-05-21 07:18:42 shouldn't we uniform that? 2021-05-21 07:19:38 seems reasonable 2021-05-21 07:19:40 open a bug :P 2021-05-21 08:24:25 okay, it seems the issue with xdg-client-shell-protocol in gst is that the headers are never generated 2021-05-21 08:24:27 so this is a gst issue 2021-05-21 08:35:45 is it possible to disable fortify_headers with some gcc options, to add it to CFLAGS 2021-05-21 08:38:38 -D_FORTIFY_SOURCE=0 2021-05-21 08:38:46 or -U_FORTIFY_SOURCE 2021-05-21 08:38:49 -U_FORTIFY_SOURCE 2021-05-21 08:38:53 Oh, beat me to it 2021-05-21 08:39:29 but you usually don't want that 2021-05-21 08:39:33 huhm, I tried -U_FORTIFY_SOURCE but didn't worked, will look again 2021-05-21 08:39:35 it is better to fix the actual problems 2021-05-21 08:40:34 Ariadne: yes I know, but I just testing build some new pkg and want to see does it work at all 2021-05-21 08:42:00 thank you both for help 2021-05-21 09:11:16 the gstreamer issue seems to be related to gstreamer 2021-05-21 09:11:26 it does not generate the wayland-protocols data 2021-05-21 09:11:39 but its supposed to now 2021-05-21 10:50:05 is there such a thing as co-maintainership of a package? 2021-05-21 10:51:12 Xe: not really. The goal is the make sure there is someone that is ultimately responsible for the package 2021-05-21 10:56:17 only for systemd, yes :) 2021-05-21 12:43:25 so we are shifting to systemd? 2021-05-21 12:43:29 is that the plan? 2021-05-21 12:43:40 excuse me? 2021-05-21 12:43:43 :-D 2021-05-21 12:44:22 as far as i know my covid19 5G chip only supports systemd 2021-05-21 12:45:00 but i don't care so much anymore since they also crispered in some lizard dna 2021-05-21 12:45:06 you are now banned (from twitter) 2021-05-21 12:46:02 not a big deal, i was just a sockpuppet anyway, they can turn on any of the others and replace me... 2021-05-21 14:43:42 switching to s*d will not even be considered til they support POSIX (or musl libc) or til we switch to glibc (which we ofc will not do) 2021-05-21 14:54:06 ddevault: do you know about any changes to wayland-protocols that may have caused gstreamer to stop building? 2021-05-21 14:54:16 I'm not involved in wayland anymore 2021-05-21 14:54:41 that comes as a surprise but ok 2021-05-21 14:55:28 well, I still use it and sponsor development on it 2021-05-21 14:55:32 I'm just not personally involved 2021-05-21 14:56:19 Ariadne: which version of each package? 2021-05-21 14:56:36 wayland-protocols 0.20 and gst-plugins-base 1.18.4 2021-05-21 14:56:52 it fails to find xdg-shell-desktop-protocol.h or so 2021-05-21 14:56:58 i think it is supposed to generate it itself now 2021-05-21 14:58:20 do you mean wayland-protocols 1.20? 2021-05-21 14:58:39 though void is in 1.21 already 2021-05-21 14:59:45 yes, 1.20 2021-05-21 14:59:46 sorry 2021-05-21 15:00:39 ok, I can't reproduce it here 2021-05-21 15:00:56 it could be a missing dependency in meson 2021-05-21 15:01:05 a lot of projects forget that sort of stuff :/ 2021-05-21 15:03:02 sorry, xdg-shell-client-protocol.h 2021-05-21 15:04:28 https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/gl/meson.build#L589 2021-05-21 15:04:33 hmm, i wonder which of these are missing 2021-05-21 15:11:12 [101/805] Generating xdg-shell-client-header with a custom command 2021-05-21 15:11:12 [102/805] Generating xdg-shell-client-code with a custom command 2021-05-21 15:11:13 hmmm 2021-05-21 15:11:33 so it does something 2021-05-21 15:12:38 nanabozho:~/aports/main/gst-plugins-base$ find src/gst-plugins-base-1.18.4/output/ | grep xdg-shell 2021-05-21 15:12:38 src/gst-plugins-base-1.18.4/output/gst-libs/gst/gl/xdg-shell-client-protocol.c 2021-05-21 15:12:38 src/gst-plugins-base-1.18.4/output/gst-libs/gst/gl/xdg-shell-client-protocol.h 2021-05-21 15:12:46 interesting 2021-05-21 15:12:57 but yet, it cannot find it 2021-05-21 15:13:59 aha 2021-05-21 15:14:06 this is a meson thing 2021-05-21 15:14:15 ericonr: what meson version are you on? 2021-05-21 15:15:48 0.56.2 2021-05-21 15:22:57 we're on 0.58 2021-05-21 15:22:58 grrrrrr 2021-05-21 15:23:05 am i really going to have to go back to freenode 2021-05-21 15:23:10 or have the meson guys moved 2021-05-21 15:23:12 is their channel still there? 2021-05-21 15:23:14 idk 2021-05-21 15:23:24 could always open an issue on GH :P 2021-05-21 15:25:35 i think the gst meson is wrong 2021-05-21 15:25:54 there needs to be an include_directories() for src/gst-plugins-base-1.18.4/output/gst-libs/gst/gl 2021-05-21 15:26:05 but i only see one for 2021-05-21 15:26:11 src/gst-plugins-base-1.18.4/output/gst-libs 2021-05-21 15:26:36 i wonder if there is a fix in gst for this already 2021-05-21 15:27:03 yes 2021-05-21 15:27:04 https://github.com/GStreamer/gst-plugins-base/commit/4ef5c91697a141fea7317aff7f0f28e5a861db99#diff-17f06cf38e0ac3fa4a91b71556e213b7387b000c9bfbd4c0a5db5f9585659d82 2021-05-21 15:28:37 they added implicit_include_directories: false but relied on it being true? lol 2021-05-21 15:47:15 v3.14 rebuild status: s390x, armv7 have both finished with main 2021-05-21 15:54:22 clandmeter, could you perhaps take a look at merge request !21208 ? it would be awesome to have a working and up-to-date package again 2021-05-21 15:54:54 x86_64 and armhf now on community too 2021-05-21 15:55:17 mips64! 2021-05-21 15:55:52 ikke: can you kick build-3-14-aarch64 and build-3-14-x86 2021-05-21 15:55:59 they've been stuck for like an hour 2021-05-21 16:09:26 Ariadne: done 2021-05-21 16:11:33 Ariadne, a simple vlan config for ifupdown-ng like this would work?> 2021-05-21 16:11:34 https://tpaste.us/BEpR 2021-05-21 16:25:33 wej: thx, not sure i have time today. tbh i dont use domoticz anymore (sorry ha user here). 2021-05-21 16:25:59 if you like be my guest and take maintainership. 2021-05-21 16:27:14 clandmeter: i guess i could do that. anything i should be aware of? i haven't maintained a package before 2021-05-21 16:27:37 i dont think so, just what you did with this pr :) 2021-05-21 16:27:43 err MR 2021-05-21 16:27:47 old habbits 2021-05-21 16:28:09 from first glance it looks good 2021-05-21 16:28:14 Yeah, anyone can basically maintain a package 2021-05-21 16:28:40 sounds good 2021-05-21 16:29:26 wej: you do need to update the maintainer line :) 2021-05-21 16:29:33 We are working on expanding documentation for this 2021-05-21 16:29:50 clandmeter: okay, i'll do that 2021-05-21 16:29:55 but maybe read the commit and coding style documents 2021-05-21 16:29:58 ikke: that would be very useful :) 2021-05-21 16:30:06 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/CODINGSTYLE.md 2021-05-21 16:30:10 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/COMMITSTYLE.md 2021-05-21 16:32:45 yep, i also ran the atools linter on the package 2021-05-21 16:33:44 I think s390x was a CI issue, I retriggered it 2021-05-21 16:34:02 yeah, it looks like it, the compiler was killed 2021-05-21 16:34:28 I fixed an issue earlier this week that was most likely the culprit 2021-05-21 16:34:36 nice 2021-05-21 16:34:36 It basically spawned too many jobs 2021-05-21 16:57:14 I'm trying to build `mutter` on my Alpine desktop, but for some reason `abuild -r` has issues with installing dependencies... 2021-05-21 16:57:14 https://paste.ubuntu.com/p/w3Bb7nP2Cf/ 2021-05-21 16:57:14 Any idea how I can solve this dependency problem with apk? 2021-05-21 16:57:38 clandmeter: maintainer line is updated now 2021-05-21 16:59:32 DylanVanAssche: can you share the APKBUILD file? 2021-05-21 17:03:59 Ah yes, I think it doesn't like polling in polkit-dev when polkit-elogind is installed 2021-05-21 17:04:12 You can replace polkit-dev with polkit-elogind-dev, then it'll work 2021-05-21 17:07:37 Cogitri: no polkit dep is mentioned in the makedepends... 2021-05-21 17:07:37 ikke https://git.alpinelinux.org/aports/tree/community/mutter/APKBUILD 2021-05-21 17:13:25 Oh, I guess something else pulls it in then :/ 2021-05-21 17:14:21 SUDO_APK="abuild-apk -vvvvv" abuild -r, see what it's trying to do. 2021-05-21 17:16:11 Sheila: https://paste.ubuntu.com/p/hFxqD2m6Sq/ 2021-05-21 17:16:11 Not much more information 2021-05-21 17:18:06 ftr, do you have something like polkit installed? 2021-05-21 17:19:12 Yes, `polkit-gnome`, `polkit-elogind`, `polkit-elogind-openrc` 2021-05-21 17:21:26 like Cogitri said, it pulls in polkit(-dev), which is conflicting 2021-05-21 17:21:54 Cogitri: would it somehow make sense if polkit-elogind(-dev) provides polkit(-dev)? 2021-05-21 17:22:27 clandmeter: all builds ran successfully, it should be safe to merge 2021-05-21 17:22:30 <[[sroracle]]> Sheila: we haven't upstreamed that yet 2021-05-21 17:22:42 [[sroracle]]: ah. 2021-05-21 17:26:49 gnome-settings-daemon-dev pulls in polkit 2021-05-21 17:27:09 very crude: sh -c '. ./APKBUILD; for pkg in $makedepends; do abuild-apk add $pkg >$pkg.deps && abuild-apk del -q $pkg; done' 2021-05-21 17:29:43 ikke: Yup, would make sense 2021-05-21 17:29:51 Same thing for nm-elogind 2021-05-21 17:32:08 ikke: hmmmm that cmd hides a lot of the magic, and fails again with: https://paste.ubuntu.com/p/fkyKSsrB6N/ 2021-05-21 17:32:43 It writes the output to .deps files 2021-05-21 17:34:59 Ah yes indeed, it shows that gnome-settings-daemon-dev pulls in polkit 2021-05-21 17:41:21 DylanVanAssche: maybe you should use something like dabuild to build in a clean environment 2021-05-21 17:42:34 Hmmmm that may help indeed... 2021-05-21 17:42:46 Thanks for the help already! 2021-05-21 18:20:19 is it late for perl 5.34 for 3.14 2021-05-21 18:20:36 yes 2021-05-21 18:23:30 late? 2021-05-21 18:24:16 there is alreayd a feature freeze 2021-05-21 18:24:32 builders have alreay built most of main 2021-05-21 18:26:00 ok 2021-05-21 19:18:46 so, this is probably a stupid question, but is there an easy way to rebuild all alpine packages w/ abuild? 2021-05-21 19:18:59 Specifically for the purpose of bootstrapping a new architecture or using special GCC flags? 2021-05-21 19:19:00 NCommander: there is buildrepo 2021-05-21 19:19:07 which automates that 2021-05-21 19:19:13 which is also what the official builders use 2021-05-21 19:20:07 Can this recursively handling dependencies? I've been having an idea for a stupid project, and I've been tempted to rebootstrap alpine to run on a 486, which requires futzing with GCC 2021-05-21 19:20:14 yes, it can 2021-05-21 19:20:36 it relies on lua-aports to determine the buildorder 2021-05-21 19:20:51 yay 486 :)) 2021-05-21 19:21:23 is there a handy step by step on how to set up an alpine builder? I'm mostly figuring out if this is what my weekend will be 2021-05-21 19:22:02 dalias, well, I considered rebuilding Ubuntu from scratch which admitely is not that hard since ... far too much time was spent deving it for me, but Ubuntu's debootstrap is going to have indigestion in 32 MiB of RAM. 2021-05-21 19:22:30 I'd like to think alpine would be less filling ... or at least less abusive to the swap partition 2021-05-21 19:23:24 My other thought was m68k, but I'm not even sure if NTPL problems with glibc *ever* got resolved. That was a massive problem with Debian/m68k in the late 2000s, and no one really wanted to deal with defining TLS on a dead architecture 2021-05-21 19:23:44 granted, musl would require porting it in the first place 2021-05-21 19:23:48 so maybe a moot argument :) 2021-05-21 19:25:22 I'll look into buildroot. Who knows, maybe some madman beside me can find a usecase for Alpine on 486 2021-05-21 19:25:38 buildrepo? 2021-05-21 19:25:49 *buildrepo 2021-05-21 19:26:18 apk install caffeine plz 2021-05-21 19:26:22 *apk add 2021-05-21 19:26:29 yeah, ok, brain is effectively dead 2021-05-21 19:27:07 NCommander: fwiw, i think the easiest first step to make it 486-compatible is adding a triplet to abuild.n 2021-05-21 19:27:13 i'd love to have alpine on a 486 2021-05-21 19:27:14 abuild.in * 2021-05-21 19:27:19 originally alpine worked on 486 2021-05-21 19:27:22 but we went to 586 2021-05-21 19:27:25 yay, alpine on 486 \o/ 2021-05-21 19:27:25 Are these GNU triplex or alpine specific ones? 2021-05-21 19:27:34 i think debian is on 686 now 2021-05-21 19:27:44 might be wrong on that though 2021-05-21 19:27:46 NCommander: https://git.alpinelinux.org/abuild/tree/functions.sh.in#n6 2021-05-21 19:27:58 standard gcc triplets with alpine arch short-hands for them 2021-05-21 19:28:09 I actually *did* try my hand at Ubuntu on a 486. I determined I'd have to change gcc, and the kernel config files, and then it went downhill from there because Ubuntu's obxious about architectures 2021-05-21 19:28:48 also at the very least i feel like musl would not be terribly hard to port to m68k 2021-05-21 19:28:51 at least for an initial prototype 2021-05-21 19:28:54 (happy to be proven wrong) 2021-05-21 19:28:56 Technically, i486-alpine-linux-musl* would be considered a 486 specific triplex. Autotools has specific logic for 386/486/586/etc, but for all I know, thats bitrotted ti hell. 2021-05-21 19:29:04 musl itself already is on m68k 2021-05-21 19:29:21 i want to shake out the qemu building with riscv tho 2021-05-21 19:29:23 NCommander: i think it's fine to add a triplet that's that, yes 2021-05-21 19:29:29 Ariadne, I think it's 586 due to one of the embedded SoCs being only a Pentium in practice. 2021-05-21 19:29:32 maybe call it x86-486 :p 2021-05-21 19:29:50 goddamn it, this feels like a horrid idea I'm *actually* going to do 2021-05-21 19:29:53 NCommander: if you mean the Quark, that's a modified 486 2021-05-21 19:30:06 486 at its core with some instructions & additions from pentium 2021-05-21 19:30:10 and then make a YouTube video on it >.<; 2021-05-21 19:30:15 Ariadne: hm, it isn't mentioned in README 2021-05-21 19:30:21 that should probably be fixed 2021-05-21 19:30:27 I still have to fix the kernel to work with the SCSI controller in my 486 2021-05-21 19:30:27 s/README/INSTALL/ 2021-05-21 19:30:30 or install an IDE HDD 2021-05-21 19:30:50 (it would seem the meeting bot isn't here (yet?)) 2021-05-21 19:31:02 Because Intel (who made the workstation in question) managed to wire the SCSI controller directly the the processor bus, and bypassed the perfectly good EISA bus :( 2021-05-21 19:31:04 ericonr: yeah, still need to do that 2021-05-21 19:31:32 i think the infra team only migrated the essential services 2021-05-21 19:31:38 because again 2021-05-21 19:31:43 3.14 release imminent 2021-05-21 19:31:44 :p 2021-05-21 19:32:00 we always release fashionably late 2021-05-21 19:32:09 We're all escaping Freenode. Although I spent the better part of an hour playing "guess the password" with OTFC 2021-05-21 19:32:20 alpine 3.14, putting the pi in alpine 2021-05-21 19:32:24 Ariadne, just don't be Duke Nukem Forever late. 2021-05-21 19:33:02 ugh that was a bad game 2021-05-21 19:33:42 It was the Itanium of games. Overpriced, overhyped, and underdelievered :) 2021-05-21 19:33:56 i used to have an itanic server 2021-05-21 19:34:05 the damn thing caught fire in the colo 2021-05-21 19:34:08 hahahahaha 2021-05-21 19:34:20 Ariadne, I have one leaning against the wall in my apartment. The wiring in my apartment can't take it. We also blew a circuit bus out at Hotel Penn at HOPE in 2018 2021-05-21 19:34:42 Ariadne, now the programming manual says that halt, catch, and fire should never be used the same bundle ;) 2021-05-21 19:35:41 Ariadne: i thought you said alpine works on 486 2021-05-21 19:36:55 Ariadne: seems par for the course 2021-05-21 19:37:00 https://git.alpinelinux.org/aports/tree/main/gcc/APKBUILD - L258, appartantly someone already made 486 support a thing in GCC with the correct arch flag. 2021-05-21 19:37:19 NCommander: i think it's a remnant of when we supported 486 2021-05-21 19:37:44 Although technically, this needs a 486DX. I don't even know if the kernel can softfloat on x86 anymore 2021-05-21 19:37:47 Hello71: we moved to pentium at some point 2021-05-21 19:37:53 Hello71: unfortunately :( 2021-05-21 19:38:10 /still need to do that/have done that now/ 2021-05-21 19:38:10 huh. march or kernel? 2021-05-21 19:38:17 Hello71: when it comes to architectures i don't care about, my information might be dated :) 2021-05-21 19:38:20 i guess it could be bth 2021-05-21 19:38:29 NCommander: i think that's still possible, because there are some embedded x86 cpus without a fpu like some of the vortex86 2021-05-21 19:38:33 you can't really get me excited for x86 :P 2021-05-21 19:38:40 8087 support should still be in the box though. 2021-05-21 19:38:43 .uptime 2021-05-21 19:38:43 I've been sitting here for 0:01:59 and I keep going! 2021-05-21 19:38:51 ericonr: ^ 2021-05-21 19:38:57 Ariadne: i thought you were excited about your 486 2021-05-21 19:39:24 I'm mostly looking at 486 before I do something crazy like m68k or worse. 2021-05-21 19:39:33 Hello71: i don't think i have any 486s, only geode 2021-05-21 19:40:26 oh 2021-05-21 19:40:29 i do have one 486 2021-05-21 19:40:34 i use it as a firewall 2021-05-21 19:40:42 but it is running alpine 2.x 2021-05-21 19:40:43 :D 2021-05-21 19:40:58 ... goddamn it, you made me think of a stupid idea 2021-05-21 19:42:06 No, IPX got removed in 2018, ok, that idea has been shelved 2021-05-21 19:42:11 NCommander: i want to do m68k port for my amiga (though i am going to have to take out the vampire cpu upgrade board to boot linux) 2021-05-21 19:42:26 Ariadne, I actually might have a toaster sitting in a box behind me. 2021-05-21 19:42:44 It needs a recap, but I got it in "gets to "insert workbench disk" condition 2021-05-21 19:44:45 nice 2021-05-21 20:45:10 https://alpinelinux.org/posts/Switching-to-OFTC.html has an unnecessary backslash in channel names \#alpine-devel 2021-05-21 20:45:26 hash inside code blocks don't need to be escaped 2021-05-21 20:47:20 ericonr: would you care making an MR against https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite? 2021-05-21 20:48:30 lol can do later, it's only fair 2021-05-21 20:48:42 I was cribbing from your announcement to write void's 2021-05-21 20:55:51 ikke: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/26/diffs 2021-05-21 20:56:17 thanks 2021-05-21 20:56:33 np 2021-05-22 07:46:05 anyone with ppc64le could test !21619 2021-05-22 07:46:28 it fails because of one test timeouts 2021-05-22 07:47:17 not sure if we should disable this or it will maybe will be ok on builder 2021-05-22 08:06:35 mps: please mark that MR WIP so it doesn't get merged while we're cutting the 3.14 release :) 2021-05-22 08:15:31 Ariadne: I added milestone to 3.15.0 thinking it is enough. is it? 2021-05-22 08:15:45 some people get very enthusiastic about clicking merge 2021-05-22 08:15:46 ;) 2021-05-22 08:15:52 hehe 2021-05-22 08:15:52 can never be too safe 2021-05-22 08:16:04 ok, will do 2021-05-22 08:16:11 i already took care of it 2021-05-22 08:16:46 ah, I see 2021-05-22 08:16:54 ok 2021-05-22 08:17:46 I dislike 'Draft' word and prefer 'WIP', but ok now, we will keep it in 'Draft' stage 2021-05-22 08:18:21 there's a button that marks WIPs as such, I presume it prepends `Draft: ` automatically. 2021-05-22 08:18:34 yes 2021-05-22 08:18:36 yes 2021-05-22 08:18:52 and I always change to WIP 2021-05-22 08:19:33 i think it can go in right after 3.14 release fwiw 2021-05-22 08:20:16 I hope so 2021-05-22 08:21:17 now I'm fixing linux-elm to upgrade to 5.12.5 2021-05-22 08:26:17 heh, fixed it by removing patch for display I added for previous version when it is needed, now it is fixed upstream 2021-05-22 08:49:37 can we replace `-Wl,--as-needed,-O1,--sort-common` with `-Wl,--as-needed -Wl,-O1 -Wl,--sort-common`? would seem to avoid the issues where upstreams do stupid things to reorder `-Wl,--as-needed` that break if more than one flag is passed. 2021-05-22 08:54:51 yes, it should work 2021-05-22 08:55:05 i think that would fix the vim issue too (if you're noticing it on #alpine-commits) 2021-05-22 08:55:19 that's what brought it to mind, actually 2021-05-22 08:55:19 ikke: can you change it on the builders? 2021-05-22 08:59:26 the vim issue should have been fixed by vim upstream 2021-05-22 09:00:00 https://github.com/vim/vim/commit/761ead497feff5fd259c9f6ca76d184bb8755373 2021-05-22 09:00:03 I will just backport that 2021-05-22 09:00:52 okay 2021-05-22 09:01:19 but yeah, if other packages also have similar hacks we should consider reordering ldflags 2021-05-22 09:07:29 Ariadne: did you already start working on riscv alpine qemu images? 2021-05-22 09:07:38 I would be interested in debugging some of the test failures in !21629 2021-05-22 09:07:53 not yet 2021-05-22 09:08:03 we're still working on getting build infrastructure up 2021-05-22 09:08:13 i think there is a minirootfs that roman linked on alpine-devel tho 2021-05-22 09:08:19 debian offers qemu images for many architectures for this purpose https://people.debian.org/~gio/dqib/ 2021-05-22 09:08:26 something like that would be nice to have for alpine too 2021-05-22 09:08:31 yes, i know, i intend to work on it soon 2021-05-22 09:08:41 last time I wanted to do something with riscv on alpine I just used that debian images and created an alpine chroot in it :D 2021-05-22 09:08:48 right now i am trying to catch up our release engineering work since we had to drop everything and deal with the whole freenode shitshow 2021-05-22 09:09:06 / 2021-05-22 09:09:18 but qemu is high on the list of things to do 2021-05-22 09:09:22 sweet 2021-05-22 09:10:28 decided to upgrade vim to not deal with the automake shenanigans involed in regenerating configure from configure.ac, ldflags build failure should be fixed now 2021-05-22 09:10:49 upgrade vim is fine 2021-05-22 09:10:53 upgrade perl is not fine :P 2021-05-22 09:11:39 ) 2021-05-22 09:16:08 regarding the qemu thingy: would be neat if we could also build images for other less widely available architecture like ppc64le, s390x, 
 to ease debugging build/test failures on these architecture 2021-05-22 09:23:14 qemu images is good to have, I proposed that some time ago but ....... 2021-05-22 09:26:01 it has its limits too though, at least on my somewhat ancient hardware it takes forever to compile somewhat complex software in an emulated risc-v qemu vm 2021-05-22 09:28:45 everything have some limits, but these images could be useful for people who don't like/want/know to install alpine under qemu for different arches 2021-05-22 09:29:02 yep 2021-05-22 11:11:28 I've changed !20124 to build pypy in two steps - build python2 first (no more python2 makedepend) and use the result to bootstrap pypy 2021-05-22 11:12:00 would that be an acceptable way to build pypy? 2021-05-22 11:18:26 I would really like to remove python2 from aports entirely, the only think keeping me from doing that is basically chromium/blink atm 2021-05-22 11:18:47 as such I am personally not a huge fan of adding any new packages which depend on python2 2021-05-22 11:18:59 does pypy upstream not have any plans to switch to python3? 2021-05-22 11:31:57 it supports python 3.7.9 partially apparently 2021-05-22 11:32:00 https://www.pypy.org/compat.html 2021-05-22 11:32:42 "PyPy3 implements the Python language version 3.7.9. It has been released, but Python is a large language and it is quite possible that a few things are missing" 2021-05-22 11:39:59 in that case, i would suggesting waiting with packaging pypy until upstream no longer requires python2 I really think we should stop packaging an EOL version of python2 as soon as possible and adding more python2 packages just delays that 2021-05-22 11:40:33 no, pypy3 requires pypy for build and pypy can be build using python2 or pypy 2021-05-22 11:41:06 this is due to the rpython stuff, the pypy guys are going to take care of python2 if required 2021-05-22 11:41:52 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2 2021-05-22 11:43:18 I dropped the makedepend on python2 and replaced it with a local build so it does not block dropping python2 from alpine 2021-05-22 11:45:17 so pypy is self-hosting, and just needs to be bootstrapped? 2021-05-22 11:46:22 or does that only count for pypy3?> 2021-05-22 11:46:33 yes and using pypy to build pypy would be *much* faster than using python2 2021-05-22 11:47:39 pypy3 is the easy part, building using pypy once it is available 2021-05-22 11:48:02 liske: so once pypy is in the repositories, we could switch it to pypy (it should then provide pypy-bootstrap virtual package), and it should work? 2021-05-22 11:48:24 ah! that changes things 2021-05-22 11:48:32 exactly 2021-05-22 11:49:21 is it valid to have a makedepend on it self? 2021-05-22 11:49:28 no, that's where the virtual package comes in 2021-05-22 11:50:15 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/go/APKBUILD#L63 2021-05-22 11:50:26 you can have multiple packages provide a virtual package 2021-05-22 11:50:54 for instance community/go-bootstrap provides go-bootstrap based on the old C version of the go compiler but community/go also provides go-bootstrap 2021-05-22 11:51:00 nmeum: No 2021-05-22 11:51:03 no? 2021-05-22 11:51:30 oh, maybe for go that is still the case 2021-05-22 11:51:36 others just provide it itself 2021-05-22 11:51:48 ah 2021-05-22 11:52:04 not sure if it's still being used 2021-05-22 11:52:16 no, it's old 2021-05-22 11:52:19 so rust provides rust-bootstrap and needs to be boostraped manually once? 2021-05-22 11:52:27 yes 2021-05-22 11:52:31 I see 2021-05-22 11:52:37 go is now also providing go-bootstrap itself 2021-05-22 11:52:45 the go-bootstrap in the repositories is old 2021-05-22 11:53:17 so, while it's technically still there, it's not being used 2021-05-22 11:54:01 be able to use pypy to build pypy would be nice, using python2 CI/CD takes about 2-3h 2021-05-22 11:54:05 nmeum: so what I do on the builders when they need to be built is manually install the *-bootstrap package 2021-05-22 11:54:25 from edge 2021-05-22 11:54:26 hm, right 2021-05-22 11:54:48 the beauty of the old community/go-bootstrap approach was that it didn't require any manuell intervention though 2021-05-22 11:54:53 should we romve community/go-bootstrap then? 2021-05-22 11:54:57 *remove 2021-05-22 11:55:14 nmeum: true, but that's becomming less and less feasible 2021-05-22 11:55:20 indeed 2021-05-22 11:55:28 I still think it requires intervention 2021-05-22 11:55:31 it needs to come from somewhere 2021-05-22 11:55:35 community/go-bootstrap does also not support various architectures etc 2021-05-22 11:55:40 nod 2021-05-22 11:55:41 I noticed 2021-05-22 11:55:52 no, community/go-bootstrap is the version written in C 2021-05-22 11:55:57 so it just requires a C compiler for bootstraping 2021-05-22 11:56:05 oh, right, yes 2021-05-22 11:56:11 if a C compiler is available no manuell intervention is required 2021-05-22 11:56:15 nod 2021-05-22 11:56:40 for rust, this is not possible, for java, you need gcc6 2021-05-22 11:56:44 haskell, I don't know 2021-05-22 11:56:50 yep 2021-05-22 11:57:02 haskell also needs to be bootstraped from an existing ghc version 2021-05-22 11:57:06 right 2021-05-22 11:58:09 liske: yes, that should be possible 2021-05-22 11:58:19 I don't know if my approach of using a two-step build with abuild is good, doesn't seem to be inherently supported 2021-05-22 11:58:50 liske: well, if you just need to bootstrap it, you might as well just use the available python2 2021-05-22 11:59:24 Just make it clear that it's temporarily for bootstrapping purposes 2021-05-22 11:59:31 why can't we use the virtual bootstraping approach for pypy though? 2021-05-22 11:59:38 we can 2021-05-22 11:59:42 bootstrap it once via python2 and then use a virtual package 2021-05-22 11:59:45 but you need to have a starting pont 2021-05-22 11:59:48 that's what I suggest 2021-05-22 11:59:54 yeah, ok 2021-05-22 11:59:58 sounds reasonable 2021-05-22 12:00:20 ikke: !21659 MR for removing the old community/go-bootstrap package 2021-05-22 12:01:02 liske: so you should add a provides="$pkgname-bootstrap=$pkgver-r$pkgrel" 2021-05-22 12:01:44 ACTION loves the gitlab MR history 2021-05-22 12:01:52 (: 2021-05-22 12:02:48 liske: your local reflog should still have it as well 2021-05-22 12:04:18 ugh, s390x seems to have network issues 2021-05-22 12:04:55 ah yes, but it was faster for me to grab the commit id from gitlab ;-) 2021-05-22 12:05:06 whatever works :) 2021-05-22 12:08:15 thanks, I've added the provides var and pushed 2021-05-22 12:23:23 https://build.alpinelinux.org/buildlogs/build-3-14-aarch64/community/go/go-1.16.4-r0.log 2021-05-22 12:23:27 bootstrapping go :) 2021-05-22 12:39:53 just for understanding the setting up build hosts for 3.14: are all package are required to be build from scratch or did they use the packages from edge whenever required 2021-05-22 12:40:26 Hi, Algibot still points to freenode in " You can also ask on IRC on #alpine-devel on Freenode.net. " (from 14h ago). 2021-05-22 12:40:40 (is it the same like bootstrapping a new ARCH to alpine?) 2021-05-22 12:41:48 liske: everything is built from source 2021-05-22 12:42:24 I guess bootstrapping a new arch is a bit more involved, but the general process should be the same 2021-05-22 12:43:01 hmm, where? 2021-05-22 12:43:13 Misthios: 2021-05-22 12:43:30 can be seen here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20264 2021-05-22 12:43:47 ah, the gitlab bot 2021-05-22 12:46:24 Misthios: thanks for reporting, I've updated it now 2021-05-22 12:48:46 np, might as well make myself usefull when checking some stuff 2021-05-22 16:04:09 Cogitri: if you're online, could you review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21590? 2021-05-22 18:25:38 Ah, not really sure how that providers stuff works 2021-05-22 18:42:41 Well it should work according to fabled so I personally trust it, but you're the maintainer 😉 2021-05-22 20:17:22 Fair, but I think you're the main consumer of pipewire 2021-05-22 21:25:08 Hi there! Roman here (RISCV guy). There seems to be a consensus on the fact that it would be useful for Alpine 3.15 to have riscv64 support and I'd like to start making progress towards that. 2021-05-22 21:26:26 My preliminary builds of aports produced 10Gb of riscv64 binaries with 50% of testing/community and 90% of mains buildable (with a few patches I'm upstreaming now) 2021-05-22 21:27:02 The next question is: how can I start making incremental progress towards making sure that we can officially build all the same packages when it comes time for 3.15. 2021-05-22 21:28:00 Ariadne suggeted that the first step towards that would be setting up a riscv64 builder -- I'd love to help with that (since I have one for my private needs anyway) but I 2021-05-22 21:28:21 would appreciate knowing who should I start working with to make it happen officially (as part of Alpine infrastructure) 2021-05-22 21:31:08 I am still pretty new to Alpine -- hence trying to figure out what's the best way for me to volunteer and pitch in when it comes to basic infrastructure (as opposed to just sending Merge Requests) 2021-05-22 21:31:41 rhatr: you can join #alpine-infra team on oftc 2021-05-22 21:31:56 Hm, for setting up builders it'd probably be best to join #alpine-infra 2021-05-22 21:32:00 Ah mps was faster :) 2021-05-22 21:32:14 10x! Let me move this to over there 2021-05-22 21:32:37 Hi there! Roman here (RISCV guy). There seems to be a consensus on the fact that it would be useful for Alpine 3.15 to have riscv64 support and I'd like to start making progress towards that. 2021-05-22 21:32:41 My preliminary builds of aports produced 10Gb of riscv64 binaries with 50% of testing/community and 90% of mains buildable (with a few patches I'm upstreaming now) 2021-05-22 21:32:51 rhatr: do you build it on native platform or with qemu 2021-05-22 21:32:52 As for MRs, just post those and someone will look at them eventually (we really have to clean up our MR queue though, I'll try to get through some MRs tomorrow) 2021-05-22 21:33:00 I think you forgot to change channels 2021-05-22 21:33:12 :) 2021-05-22 21:33:16 We are still better off doing it via qemu -- the servers will be hitting the shelves in 2022 2021-05-22 21:34:02 mips64 port is built on some 'poor' hardware, afaik 2021-05-22 21:34:21 Yeah -- not forgetting to change channels is important ;-) as for the MRs -- I'm actually more concerned making sure stuff doesn't bitrot -- hence the convo around infra 2021-05-22 21:34:47 Ah yes, without CI it's hard to actually prove that MRs are fine 2021-05-22 21:35:08 I'm member of infra team, but usually I do most upgrade/fixes/etc using MRs 2021-05-22 21:35:32 as Cogitri says, CI is very usefull 2021-05-22 21:36:19 At this point the two biggest bulk changes are already submitted e.g. https://gitlab.alpinelinux.org/rvs/aports/-/pipelines/82485 2021-05-22 21:36:28 especially because it is 'linked' with issue/bug report system 2021-05-22 21:36:48 I am still battling random test fails in places that had nothing to do with my changes tho :-( -- but I should be done isolating those over the weekend 2021-05-22 21:37:09 rhatr: yes, I noticed and looked at these MRs, looks promising 2021-05-22 21:46:33 will need to wait with merging those anyhow a bit because 3.14 is not branched of yet 2021-05-22 21:46:41 rhatr: BTW, do you have the instructions for setting up an Alpine RISCV Qemu VM around? I don't have a RISCV board (yet) but it'd be fun working on it 2021-05-22 21:46:51 A blogpost would be neat :) 2021-05-22 21:48:29 oh, btw should these MRs be marked for 3.15.0 milestone, just in case 2021-05-22 21:50:11 yep 2021-05-22 21:53:42 rhatr: the other thing about having an official builder running is that the packages live on the normal alpine mirror network instead of a linux foundation s3 bucket ;) 2021-05-22 21:55:05 which, if the riscv port is popular, may become problematic ;) 2021-05-22 22:00:33 When it comes to setting it -- the easiest is actually docker/runc with qemu-user-static. Here's how you can do it on Docker @Cogitiri docker build -t riscv64 https://raw.githubusercontent.com/lf-edge/eve/master/build-tools/src/scripts/Dockerfile.alpine.bootstrap 2021-05-22 22:00:47 docker run -it --rm riscv64 sh 2021-05-22 22:01:11 and you're in the environment that's been pre-set to build aports (it points at my own fork of aports -- since that contains required tweaks) 2021-05-22 22:01:47 > which, if the riscv port is popular, may become problematic ;) 2021-05-22 22:01:51 LOL -- tru dat! 2021-05-22 22:02:02 thats gonna get shut down quickly ;p 2021-05-22 22:02:45 But the good news is that SBCs are coming out of the woodworks -- with 2 shipping 1H 2021 and 4 more 2H 2021 2021-05-22 22:04:33 don't really care about SBCs, personally. 2021-05-22 22:05:35 what I do care about: actual server-grade hardware and decent laptops & desktops 2021-05-22 22:06:11 (don't get me wrong, the SBCs are cool, and a good way to get hardware in to service on the cheap.) 2021-05-22 22:06:32 but it would be really nice to not have to rely on appliances for my daily computing needs. 2021-05-22 22:07:57 Sheila: What about a 24 core ARM server, like the Synquacer Developerbox? Or a 16 core ARM Honeycomb? :) 2021-05-22 22:08:01 rhatr: Ah thanks, I'll fice that a go :) 2021-05-22 22:08:44 senzilla: the other part of the equation for me is a desktop environment I can actually use without squinting through configuration. :) 2021-05-22 22:09:46 Sheila: Yeah, desktop is... lets say interesting :P Both options I listed there would be more like servers or workstations 2021-05-22 22:09:49 (I'm deaf-blind, and my vision isn't stable. so, 24pt fonts + fullscreen zoom.) 2021-05-22 22:11:00 well yes. and Ariadne has a Honeycomb. I haven't tried it out yet, and until the software situation improves, I'm not going to bother asking. 2021-05-22 22:13:43 fair enough 2021-05-22 22:16:00 it is very ok 2021-05-22 22:16:12 (I have a T500 I got specifically for on-the-go cleanroom purposes, e.g. building ghc 5.whatever from bootstrappable C.) 2021-05-22 22:16:21 M1 knocks the pants off it tho 2021-05-22 22:17:24 like you gotta remember 2021-05-22 22:17:31 eyah honeycomb is 16 cores 2021-05-22 22:17:33 (unfortunately my screen-size needs are such that people used to comment about how sticking my head that close to displays was unhealthy when I was younger. :D) 2021-05-22 22:17:37 but its 16x cortex-a72 2021-05-22 22:17:50 (I have zero association with any of those people these days, as an aside. :D) 2021-05-22 22:18:25 16x neoverse would be cool 2021-05-22 22:18:38 i hear its coming in 2022 2021-05-22 22:18:41 :) 2021-05-22 22:19:27 zzz 2021-05-22 23:29:16 Can I get a review on this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21635 2021-05-22 23:32:51 kevint: is it needed for something? i think we don't really want to add libraries without revdeps to test 2021-05-22 23:32:59 especially if the tests are (allegedly) flaky 2021-05-22 23:35:07 It's for ardour, a digital audio workstation. I was packaging it so I could use the "--use-external-libs", which I figured was preferable. I'm fine just using the vendor version though, because yeah the tests are being strange on libltc. 2021-05-22 23:42:44 Speaking of ardour, I was wondering if I could get some help getting an archive made from the snapshot() function I made for ardour onto https://dev.alpinelinux.org/archive/ardour/ ? This is the relevant MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21517 2021-05-23 03:53:39 kevint: what i would recommend is packaging everything in the same MR, that way it's obvious what the end goal is. 2021-05-23 03:56:05 Sheila good point, I can do that 2021-05-23 08:20:51 kevint: sorry for the delays, we're currently focussing on getting 3.14 out the door 2021-05-23 08:23:04 no problem, that makes sense 2021-05-23 09:07:41 PureTryOut: qt5-qtwebkit fails with NameError: name 'bytecodeSections' is not defined 2021-05-23 09:12:43 Uh... Could you make an issue for it and copy the build failure to it? 2021-05-23 09:14:00 https://build.alpinelinux.org/buildlogs/build-3-14-x86_64/community/qt5-qtwebkit/qt5-qtwebkit-5.212.0_alpha4-r14.log 2021-05-23 09:15:37 As I said, please make an issue for it (and assign me to it), I can't look into it right now 2021-05-23 09:15:46 will do it 2021-05-23 09:15:47 no problem 2021-05-23 09:18:53 Thanks! 2021-05-23 09:19:37 !12695 2021-05-23 09:19:47 #12695 2021-05-23 09:38:56 Any idea why alpine-commits is not available via matrix? 2021-05-23 09:39:45 andypost[m]: hmm, no 2021-05-23 09:39:51 It is 2021-05-23 09:39:53 #_oftc_#alpine-commits:matrix.org 2021-05-23 09:40:00 I'm in there, I see the bot talking 2021-05-23 09:41:14 I can't join and browse it 2021-05-23 09:41:45 andypost[m]: are you registered and verified here? 2021-05-23 09:41:49 (on oftc) 2021-05-23 09:42:36 Not yet, that explains, thank you 2021-05-23 09:42:44 yeah, we had to deal with spam 2021-05-23 09:42:51 so we set +R on the channels for the time being 2021-05-23 10:05:46 I think my MR for moving a package to community should be good now I've adopted the package now due to the current maintainer not being responsive. Should be good to merge now. 2021-05-23 11:23:37 ikke: About grilo: Seems like new meson breaks gtk-doc 2021-05-23 11:23:51 Could you just disable gtk-doc for now? I'm not at a desktop rn 2021-05-23 11:26:27 ok 2021-05-23 11:26:36 I tried fixing it with include_directories, but that didnt' help 2021-05-23 11:27:14 Yeah, I guess meson somehow assumes that the right dirs are included already when they aren't in the new version 2021-05-23 11:32:05 -Dgtk_doc=false does not work 2021-05-23 11:33:21 there is an option 2021-05-23 11:34:27 -Denable-gtk-doc=false 2021-05-23 11:57:48 https://gitlab.gnome.org/GNOME/gtk/-/issues/3927#note_1101367 2021-05-23 11:57:53 > 2021-05-23 11:57:53 The meson build in gtk3 is 'use at your own risk'. The releases are made using autotools. 2021-05-23 11:57:59 meh 2021-05-23 12:13:25 meson in general seems to be 'use at your own risk' 2021-05-23 12:18:47 autotools is not necessarily better though ':D 2021-05-23 12:19:29 but suprising that meson actually breaks/changes their api on minor version updates 2021-05-23 12:22:50 well, to be fair, it's still <1.0 2021-05-23 12:28:29 motif on x86, /home/buildozer/aports/main/musl/src/v1.2.2/crt/crt1.c:18: undefined reference to `main' 2021-05-23 12:28:34 yes 2021-05-23 12:28:49 is it for mwm or libs 2021-05-23 12:29:44 anyone nowadays use 'mwm'? 2021-05-23 12:31:34 not mwm but '-o wmluiltok' 2021-05-23 12:31:42 why is there main/musl/ in therE? 2021-05-23 12:32:32 yes, why 2021-05-23 12:33:37 does it fails on all arches or x86 only? 2021-05-23 12:33:57 other arches as well 2021-05-23 12:34:22 #alpine-commits is like christmas tree :) 2021-05-23 12:35:29 could be some 'tweaks' on 3.14 builders 2021-05-23 12:35:53 lets try on x86_64 edge 2021-05-23 12:36:17 'nein', same error 2021-05-23 12:36:58 new autoconf 'on the work' 2021-05-23 12:49:55 what is with these changes ' -Wl,-O1 -Wl,--sort-common' and --as-needed 2021-05-23 12:50:51 does '--as-needed' must go at the end? 2021-05-23 12:54:44 no, some buildsystems are just poorly-written. 2021-05-23 12:55:17 separating out the linker flags is intended to cut down on breakage due to such buildsystems. 2021-05-24 07:20:19 ncopa: should we do something about #12418 before release 2021-05-24 07:22:32 afontain[m]: should we close #11399 2021-05-24 08:55:03 mps: upstream should have fixed this now 2021-05-24 08:55:18 I haven't tested though 2021-05-24 08:57:05 also i didn't tested again 2021-05-24 09:44:58 mps: there was a discussion about enabling serial console by default which was rejected since it could have unexpected effects if devices are attached to a serial port 2021-05-24 09:49:29 if running a (x86*) system with console-to-serial BIOS redirection one can add a console=ttyS0 at syslinux promt, after setup-(alpine|bootable) the syslinux.cfg needs to be tweaked 2021-05-24 09:53:53 liske: long time I had serial and tty in cmdline without any problem 2021-05-24 09:54:59 nowadays I have mostly notebooks and VMs, so not sure about current status 2021-05-24 09:57:00 in 'old times' boot loaders were smart to show boot menu on both and if any key is pressed on one they continue to use that one as default 2021-05-24 10:05:18 liske: and how you would add 'console=ttyS0' at syslinux promt if syslinux doesn't put anything on serial port and don't 'listen' on it 2021-05-24 10:05:28 I'm using mostly Lanner boxes w/o graphic adapter and the BIOS has a built-in console redirection - I think this is why the syslinux prompt is visible on ttyS0 (I don't know if syslinux could have built-in serial support like ilo or grub(2)) 2021-05-24 10:06:03 liske: yes, syslinux have it 2021-05-24 10:06:56 and a lot of people use alpine on old hardware where this is 'good to have' 2021-05-24 10:13:07 ah, there is the syslinux_serial option in mkimage.sh 2021-05-24 10:13:28 I'm using this profile for myself: https://pastebin.com/xhijrtVY 2021-05-24 10:18:18 mps: I've to slightly correct you here: serial is nothing only found on old devices. We actually deploy alpine almost daily on *new* hardware that we access via serial console 2021-05-24 10:20:01 plenty of stuff uses serial ports still as it's safer* than USB (thanks to cool features like DMA, etc. in USB that aren't generally implemented on serial) 2021-05-24 10:21:09 Serial is also nice for things like routers (I installed OPNSense on my APU4D4 with serial) 2021-05-24 10:22:21 man, I really don't miss my high school CCNA class. was cool at the time, but ultimately I'd have been better off taking carpentry or so. 2021-05-24 10:34:07 on arm SBCs I have only this 'console=${console}' and it automagically detect console 2021-05-24 10:34:46 that is, u-boot loader 2021-05-24 10:37:38 and I used serial consoles on servers and similar things for more than 25 years 2021-05-24 12:37:16 usb doesn't have dma until 4? 2021-05-24 13:01:13 https://www.kernel.org/doc/html/latest/driver-api/usb/dma.html 2021-05-24 13:29:31 i mean any driver may use dma 2021-05-24 13:30:00 ethernet is insecure because driver uses dma? 2021-05-24 13:30:22 maybe it is insecure, but unrelated to dma 2021-05-24 13:31:41 actual thing is, USB devices can do things on-connect at the firmware level, regardless of baremetal OS. only safeguard against that is epoxying the USB ports so they can't be used. 2021-05-24 16:56:20 git-clang-format in clang-extra-tools uses python instead of python3, anyone want to create a patch for that or should i create an issue? 2021-05-24 17:30:07 Ariadne: just an fyi, unless you're still on freenode, I believe you're name is being used 2021-05-24 17:30:56 c705: no, i came back 2021-05-24 17:31:01 and then i left again 2021-05-24 17:31:14 are you a freenode operator? 2021-05-24 17:31:17 nope 2021-05-24 17:31:31 though i was for a few hours 2021-05-24 17:31:43 yeah, so someone with your name is now a freenode operator. I know there's nothing you can do, but figured i'd pass that on 2021-05-24 17:31:43 i looked behind the curtain 2021-05-24 17:31:48 it was a pretty major shitshow 2021-05-24 17:32:06 c705: nope, i came, they gave me an o:line, i went 2021-05-24 17:32:13 ah, okay 2021-05-24 17:43:06 lordy andrew lee's freenode is turbo fucked 2021-05-24 17:46:34 i imagine, i'd prefer not to think about it as much as possible 2021-05-24 17:55:02 I'm hoping the dust settles soon 2021-05-24 17:55:16 I stopped seeing spambots over here, maybe I'll check out libera in another week :p 2021-05-24 18:02:46 I just finished (AFAICT) on MR 8569 2021-05-24 18:02:48 !8569 2021-05-24 18:03:40 Somebody please take a look (Ariadne maybe?) 2021-05-24 18:04:01 we are presently working on 3.14 release 2021-05-24 18:04:05 Alright 2021-05-24 18:04:10 Have fun I guess. :P 2021-05-24 18:22:31 https://blog.antoyo.xyz/rustc_codegen_gcc-run-core-tests 2021-05-24 18:27:49 mps: do you recall how to fix this one: types.h:13:10: fatal error: asm/types.h: No such file or directory (when compiling the linux kernel) 2021-05-24 18:28:32 nico[m]: do you have musl-dev? might need another library 2021-05-24 18:29:07 I got musl-dev and alpine-sdk 2021-05-24 18:30:26 nico[m]: add dev86? 2021-05-24 18:30:31 https://pkgs.alpinelinux.org/contents?file=types.h&path=&name=&branch=edge 2021-05-24 18:34:20 c705: also did not fix the problem 2021-05-24 18:37:05 mps: if you can test that zog thing, I'd appreciate it, because I'm really busy these days and I don't have an alpine install with an X server at reach 2021-05-24 18:37:31 asm/types.h is kernel header 2021-05-24 18:38:09 there is a reproducer included, if you need that 2021-05-24 18:40:45 afontain[m]: also I'm to busy with $day_job 2021-05-24 18:40:52 too* 2021-05-24 18:41:52 maybe I can boot my machine where I have zig installed, around midnight 2021-05-24 19:15:29 btw, `apk add sed installkernel bc linux-headers linux-firmware-any openssl-dev` as specifie d in the kernel APKBUILD makes it compile - 2021-05-24 19:22:44 no 2021-05-24 19:22:56 abuild -r 2021-05-24 19:48:56 Ariadne: libgit2 keeps hanging on ppc64le 2021-05-24 19:49:15 lets just disable the tests for it 2021-05-24 19:49:15 i guess 2021-05-24 20:06:09 I disabled that specific test on ppc64le 2021-05-24 20:07:13 ACTION was a bit scared last he looked at libgit2's lockless code 2021-05-24 20:14:44 hmm, git manpages are formatted strangely (extra whitespace) 2021-05-24 21:07:24 afontain[m]: I tested #11399, it builds fine and it starts and works without error, but it doesn't show image (only empty window for it) 2021-05-24 21:07:44 huh oh 2021-05-24 21:07:47 and gcc works? 2021-05-24 21:07:51 and I don't know much about sdl so can't help on this 2021-05-24 21:08:06 only tried with zig 2021-05-24 21:08:30 this is actually a C rewrite of the original zig code, for this very reason 2021-05-24 21:09:15 I have no idea about this sdl using 2021-05-24 21:09:33 usage* 2021-05-24 21:13:04 gcc sdl.c $(pkg-config SDL2_image --cflags --libs) && ./a.out 2021-05-24 21:13:56 if i didn't shutdown machine 2021-05-24 21:14:09 give me few minutes 2021-05-24 21:20:35 afontain[m]: it is same with gcc 2021-05-24 21:20:54 did you download the bitmap file too? 2021-05-24 21:21:03 just transparent window with borders are shown 2021-05-24 21:21:13 yes, sure 2021-05-24 21:22:34 it will say if I didn't 'printf("Could not load image. SDL Error: %s\n", SDL_GetError())' 2021-05-24 21:23:37 weird 2021-05-24 21:24:19 but we know that zig works now 2021-05-24 21:25:04 at least same as gcc 2021-05-24 21:27:10 well, I would rather say GCC went down to the level of Zig 0.5 D: 2021-05-24 21:27:50 :) 2021-05-24 21:28:19 maybe we can try comparing statically and dynamically linked SDL? 2021-05-24 21:28:52 might be worth testing with clang, to 2021-05-24 21:28:54 *too 2021-05-24 21:28:58 I don't have any knowledge about sdl 2021-05-24 21:29:30 I don't have much either 2021-05-24 21:29:37 and, I'm not hipster^Wfan of clang 2021-05-24 21:30:21 and this could be about weak symbols or another linker elaborate bug 2021-05-24 21:30:50 or simply not 'finished' source 2021-05-24 21:31:08 but I don't know 2021-05-24 21:31:52 but I know that is time for sleep 2021-05-24 21:32:36 let me test on another distro 2021-05-24 21:33:36 ACTION uploaded an image: (12KiB) < https://matrix.org/_matrix/media/r0/download/gnugen.ch/XGDtMlDkEHxCYchKRqYoqEZC/Screenshot%20from%202021-05-24%2023-33-23.png > 2021-05-24 21:33:40 source confirmed working 2021-05-24 21:33:44 (NixOS) 2021-05-24 21:33:59 good night :) 2021-05-24 21:34:15 good night :) 2021-05-24 21:34:26 works with zig cc too 2021-05-24 21:35:08 hmm, I'm using awesome wm and don't see also window title 2021-05-24 21:35:46 this could be issue on my side 2021-05-24 21:36:26 but now really, good night :) 2021-05-24 22:56:20 remind me how do you mention CVE fixes in APKBUILD? 2021-05-24 23:31:25 nevermind - think I found it 2021-05-25 06:14:31 ncurses bugfix upgrade is released but with same version, ncurses-6.2-20210522 2021-05-25 06:15:27 is pkgrel bump only is ok in this case? 2021-05-25 06:29:51 morning 2021-05-25 06:30:02 mps: should be 2021-05-25 06:30:50 but it sounds bad for such project. 2021-05-25 06:32:55 good morning 2021-05-25 06:33:54 yes, it is 'not good' (trying to be politically correct :) ) but I don't have better idea, because that I ask 2021-05-25 06:34:29 my 'fear' is that the builders will use old version from distfiles cache 2021-05-25 06:34:56 yes they would 2021-05-25 06:35:07 but the checksum would fail and the src would get deleted 2021-05-25 06:35:46 and builders will download (refresh) with new release? 2021-05-25 06:37:27 that is my understanding 2021-05-25 06:37:42 but im a bit rusty 2021-05-25 06:40:12 ok, thanks. will see and test on lxc 2021-05-25 06:41:10 most important is that you update pkgrel so that users pull in the new pkg. 2021-05-25 06:42:08 but its a bummer they have to check gitlog to know it is actually with the bugfix or not 2021-05-25 06:52:11 x86_64 is the source for distfiles 2021-05-25 06:52:28 maybe is better idea to wait for next sunday when I think new real release with new version number will be released 2021-05-25 06:53:04 ncurses is usually released every week, and on sunday 2021-05-25 06:53:12 sundays* 2021-05-25 07:18:08 morning 2021-05-25 07:49:59 morning danieli 2021-05-25 07:50:42 i was between meetings and thought this was #alpine-infra for a moment, but the 'good morning' still stands :) 2021-05-25 07:51:36 not sure chanserv supports moving of messages :) 2021-05-25 10:36:12 have we reached a decision on the time to wait for mantainer review for security fixes, where the fix is a simple minor bump in a upstream LTS branch? 2021-05-25 10:57:34 Any clue about configure:6979: error: possibly undefined macro: _AC_PROG_CC_C99? 2021-05-25 10:57:52 autoreconf -fi on ghc fails with that error 2021-05-25 10:58:18 HRio: We're currently focussing on getting 3.14 out. Once it's released we can focus on those kinds of things 2021-05-25 10:59:06 HRio: i dont think we have any decision for that, but I guess we need something reasonable. if its a critical issue we can probably just push it 2021-05-25 10:59:22 ikke: probably due to updated autoconf 2021-05-25 10:59:37 ncopa: yes, most likely 2021-05-25 11:00:23 https://gitlab.haskell.org/ghc/ghc/-/issues/19655 2021-05-25 11:00:25 ncopa: what is your strategy for bootstrapped packages? 2021-05-25 11:00:37 bootstrapped packages? 2021-05-25 11:00:46 like rust, go, ghc 2021-05-25 11:01:34 i have manually added them from edge, build the package un deleted the dependency from edge 2021-05-25 11:01:41 so manual handling 2021-05-25 11:01:45 ok, that's what I'm doing now 2021-05-25 11:01:53 i dont know how to do it in automatic way 2021-05-25 11:02:06 just make sure that you delete the bootstrap package once its built 2021-05-25 11:02:07 I was trying to think of a good solution 2021-05-25 11:02:11 yes, I do 2021-05-25 11:04:46 ikke: the leading underscore seems suspicious 2021-05-25 11:05:00 Hello71: yeah, the fix is to remove it 2021-05-25 11:05:06 https://gitlab.haskell.org/ghc/ghc/-/commit/ad2ef3a13f1eb000eab8e3d64592373b91a52806 2021-05-25 11:05:08 ah, missed the link 2021-05-25 11:11:21 ncopa: diffoscope is nice btw 2021-05-25 11:12:42 indeed 2021-05-25 12:19:37 PureTryOut: do you have time to look at py3-lmdb? it has a test failure 2021-05-25 12:19:49 got a link? 2021-05-25 12:19:58 oh the ppc64le build 2021-05-25 12:20:23 yeah, it seems only on ppc64le edge atm 2021-05-25 12:21:24 Seems to be fixed upstream, but no commit got linked which is fun... https://github.com/jnwatson/py-lmdb/issues/295#issuecomment-829277835 2021-05-25 12:21:27 ACTION looks for it 2021-05-25 12:25:29 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21731 should fix it 2021-05-25 12:26:15 yes 2021-05-25 12:26:17 looks legit 2021-05-25 12:26:19 thank you 2021-05-25 12:26:26 I would at least wait with merging till the CI had passed but ok 😅 2021-05-25 12:26:45 i reviewed it 2021-05-25 12:47:11 ncopa & ikke OK, I think we should merge !21702 !21701, the CVE is about that auth tokens does not expire 2021-05-25 13:59:48 did we have a way to get the origin of a apk? 2021-05-25 14:00:51 no 2021-05-25 14:01:38 that really sucks 2021-05-25 14:02:00 Ariadne: can i request this feature? 2021-05-25 14:02:34 fyi, i know i can :) 2021-05-25 14:02:48 You mean something like 3.13-stable/community? 2021-05-25 14:03:06 no the origin field 2021-05-25 14:03:17 ok 2021-05-25 14:03:29 like apk-tools-doc is a subpkg of apk-tools 2021-05-25 14:03:34 yes 2021-05-25 14:03:48 clandmeter: get the origin of an apk in what? 2021-05-25 14:04:08 the origin of apk a 2021-05-25 14:04:19 the `apk info` redesign will have it 2021-05-25 14:04:27 if thats what youre asking about 2021-05-25 14:04:34 i dont know 2021-05-25 14:04:41 i just want to know the origin of a package 2021-05-25 14:04:57 in what context though 2021-05-25 14:05:01 like with `apk info`? 2021-05-25 14:05:05 apk info --origin musl-doc.apk 2021-05-25 14:05:09 or similar 2021-05-25 14:07:22 this should result in musl as this is the origin mentioned in .PKGINFO 2021-05-25 14:15:58 yeah 2021-05-25 14:16:01 thats coming to apk3 :) 2021-05-25 14:16:03 the origin as in "what package, if any, is that apk a subapk for?" ? 2021-05-25 14:16:42 yes that 2021-05-25 14:17:13 metadata already has this info, so i have no clue w hy we cannot query it. 2021-05-25 14:18:59 In the wiki page https://wiki.alpinelinux.org/wiki/PXE_boot. There is mention of the following parameters: ovl_dev and alpine_dev. Although they are listed in the parameter list in the code: https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in#L346, they are unused. Is it the intention to use them in the future? Or where they required in the past before nlplug-findfs? 2021-05-25 14:19:25 clandmeter: tar xzf apk-tools-doc-2.12.5-r1.apk -O .PKGINFO | awk '/^origin/ { print $3 }' 2021-05-25 14:19:27 :P 2021-05-25 14:19:43 yes i know that trick :) 2021-05-25 14:28:02 I wrote TUI skeleton to parse APKINDEX, browse names and show fields 2021-05-25 14:28:12 perl and ncurses 2021-05-25 14:28:51 not finished because I don't which APKINDEX files to use 2021-05-25 14:29:15 don't know* 2021-05-25 14:29:39 maybe I will find time one day to finish this 2021-05-25 14:52:49 clandmeter: apk policy should tell which repo the package came from 2021-05-25 14:53:22 sorry. i didnt read the full log before commenting 2021-05-25 14:53:27 ncopa: i want to know the origins field :) 2021-05-25 14:53:36 apk search --exact --origin pkg 2021-05-25 14:54:07 $ apk search --exact --origin apk-tools-doc 2021-05-25 14:54:14 apk-tools-2.12.5-r1 2021-05-25 14:57:22 ok but thats for pkgs in the index, not on disk. 2021-05-25 15:10:46 i think we should add an `apk info --origin` and also add origin to `apk info --all` 2021-05-25 15:22:51 as a reminder, please don't upgrade erlang to X.0 releases 2021-05-25 15:22:59 the rest of the ecosystem has to catch up 2021-05-25 15:23:41 Maybe we should add a comment in the APKBUILD 2021-05-25 15:27:13 indeed 2021-05-25 15:53:27 abuild test fail when no proper git user is set? 2021-05-25 15:58:52 i think so 2021-05-25 15:59:23 sounds like a bug 2021-05-25 16:06:12 ah its already fixed in abuild 2021-05-25 16:34:59 py3-rasterio anoys me 2021-05-25 16:35:13 I have loosened the constraints for click, but it still keeps looking for click<8 2021-05-25 16:48:12 seriously... 2021-05-25 17:04:03 maxice8: any clue how I can prevent setuptools from trying to install click even if I remove all traces of click in requirements and setup.py? 2021-05-25 18:01:18 cligj has also click dependency? 2021-05-25 18:03:27 oh 2021-05-25 18:12:22 artok: thanks :) 2021-05-25 18:21:00 hot tip: python3 -m venv venv ; ./venv/bin/python3 -m pip install pipdeptree ; ./venv/bin/pipdeptree 2021-05-25 18:21:03 =) 2021-05-25 18:21:21 nice 2021-05-25 19:39:55 ikke: chained dependencies rasterio => cligj => click 2021-05-25 19:40:11 liske: yes, thanks 2021-05-25 19:40:12 oops, scroll was locked 2021-05-25 19:40:15 ^^ 2021-05-25 19:40:17 heh 2021-05-25 19:40:41 or I had a clock skew 2021-05-25 19:42:55 I have to say that solving problems with oneliner is most satisfying =) 2021-05-25 19:43:29 ahuh 2021-05-25 19:43:40 back in 2000 when I was sysop on IT company, we had "day's oneliner", and usually it was perl 2021-05-25 19:46:04 java coders didn't understand the beauty =) 2021-05-25 20:02:09 artok: well told :) 2021-05-25 20:10:12 can a maintaner merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21484 please? 2021-05-25 20:10:40 looking 2021-05-25 20:15:00 Xe: Is Robert GĂŒnzler aware of this move? 2021-05-25 20:17:26 ikke: they approved it 1 day ago: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21484#note_159367 2021-05-25 20:17:41 ah, sorry, I missed that 2021-05-25 20:45:03 afontain[m]: I tested sdl.c with xfce and it works fine, zig and gcc compiled 2021-05-25 20:45:27 interesting is it doesn't work with awesomewm 2021-05-25 20:45:38 so, issue can be closed 2021-05-25 21:05:53 I patched perl-convert-asn1 for CVE-2013-7488 in edge that should probably go to 3.11-3.13 too I guess 2021-05-25 21:09:28 timlegge: I think your guess is correct 2021-05-25 21:11:04 mps: In the MR I modernized and upgraded in two commits. any thought as to whether I should bother with the modernize in those builds? 2021-05-25 21:12:42 however you like, I would say 2021-05-25 21:13:21 cosmetic is not important but correctness, imo 2021-05-25 22:48:31 agreed, let's close the issue 2021-05-25 22:48:38 mps: ^ 2021-05-25 22:48:52 'night for me though 2021-05-26 00:29:40 I'm trying to statically link to libgssapi_krb5 but Alpine doesn't provide libgssapi_krb5.a in krb5-dev. How can I fix this? 2021-05-26 00:59:16 RIP, I thought it would be --disable-shared and --enable-static but it fails on https://github.com/cockroachdb/cockroach/issues/49734#issuecomment-758389602 so I added `-fcommon` to build() but now it fails with `No rule to make target '../../../lib/libk5crypto.so-nobuild'` so I'm stuck 2021-05-26 00:59:48 plus it would build ONLY static files whereas we'd like to have dynamic libs as well, I'm not sure how to handle this 2021-05-26 01:01:14 ncopa: I see you're maintainer of krb5, if you have time to help me out here then I'd appreciate it 2021-05-26 05:48:49 on ppc64le I get this error in the CI: 2021-05-26 05:48:49 ERROR: wayland-libs-server-1.19.0-r0: BAD signature 2021-05-26 05:49:30 https://gitlab.alpinelinux.org/maribu/aports/-/jobs/400835 2021-05-26 05:51:05 hmm, cannot reproduce 2021-05-26 05:51:15 oh, wiat 2021-05-26 05:51:40 yes, I can reproduce 2021-05-26 05:57:34 that one should be fixed now, but there could be more 2021-05-26 06:17:48 Thanks. The next that popped up is wayland-dev 2021-05-26 06:54:41 ikke: oh in that case, there are quite a lot of wayland related packages with BAD signatures 2021-05-26 06:56:00 I think we should purge main for ppc64le 2021-05-26 09:47:17 ikke: any status regarding the issues with ppc64le? The CI no reports bad signatures for wayland-libs-client, wayland-libs-cursor, and wayland-libs-egl 2021-05-26 09:58:06 maribu[m]: sorry I didn't have time to look further at it yet 2021-05-26 09:58:13 will try to resolve it soon(tm) 2021-05-26 10:03:22 Thanks :-) 2021-05-26 10:19:58 we should build bpf from kernel source, not external one 2021-05-26 10:20:24 btw, why not shorten channel name to alpine-dev 2021-05-26 10:21:23 not *everything* needs to be shortened 2021-05-26 10:21:46 evrtng 2021-05-26 10:22:36 i rly dnt lk x.s.iv shrthnd 2021-05-26 10:22:57 vowels are cruft in langs 2021-05-26 10:23:08 f y s s. 2021-05-26 10:24:05 prl, pthn, rst ? 2021-05-26 10:24:08 mtng thm mks vrthng s mch hrdr t rd. bt mb thts jst m. 2021-05-26 10:24:32 wh dsmvwld m 2021-05-26 10:24:45 okay, I think I've made my point. 2021-05-26 10:24:47 Sheila: 'f y s s.' looks rude 2021-05-26 10:25:27 I was going to make the point differently, but maybe the channel is PG-13 or something 2021-05-26 10:25:55 yes, that is part of why excessive shorthand is bad. 2021-05-26 10:26:38 shorting words is not bad but being rude is bad 2021-05-26 10:27:11 if you say so. 2021-05-26 10:27:22 yes, I say so 2021-05-26 10:27:49 im looking into bcc build failure 2021-05-26 10:28:00 i think i understand whats going on 2021-05-26 10:28:00 lets just talk dev/devel here pls thx 2021-05-26 10:29:29 where is fail log of bcc 2021-05-26 10:29:41 ahm I see 2021-05-26 10:30:47 error: 'BTF_KIND_FLOAT' was not declared in this scope; did you mean 'BTF_KIND_INT'? 2021-05-26 10:30:54 yes 2021-05-26 10:31:24 patch to use BTF_KIND_INT? 2021-05-26 10:31:39 libbpf 0.4.0 already started using it 2021-05-26 10:31:57 but it has been introduced in a not yet released kernel 2021-05-26 10:34:19 include/uapi/linux/btf.h:#define BTF_KIND_FLOAT 16 /* Floating point */ 2021-05-26 10:34:46 yes, exactly 2021-05-26 10:36:14 kernel commit 8fd886911a6a99acf4a8facf619a2e7b5225be78 2021-05-26 10:36:28 Date: Fri Feb 26 21:22:47 2021 +0100 2021-05-26 10:37:28 https://www.kernel.org/doc/html/v5.12/bpf/btf.html 2021-05-26 10:37:31 does not mention it 2021-05-26 10:37:40 https://www.kernel.org/doc/html/v5.13-rc1/bpf/btf.html does mention it 2021-05-26 10:40:09 5.13-rc3 2021-05-26 10:40:33 maybe in -rc2 2021-05-26 10:42:33 it is in 5.13-rc1 2021-05-26 10:42:54 Kind of what I mentioned already :) 2021-05-26 10:43:14 but 5.13 and up 2021-05-26 10:43:16 yes 2021-05-26 10:43:48 downgrade bcc? 2021-05-26 10:44:45 download libbpf? 2021-05-26 10:44:48 downgrade* 2021-05-26 10:44:50 or add this https://tpaste.us/6P7B 2021-05-26 10:45:01 yes, libbpf, sorry 2021-05-26 10:46:12 as Ariadne told few days ago 'some are enthusiastic ...' 2021-05-26 11:19:01 ping Ikke 2021-05-26 11:19:21 pong 2021-05-26 11:19:41 I'm writing the sudo-ish daemon that will have an admin token and will do only the calls that absolutely need to be done by an admin for aports-qa-bot 2021-05-26 11:19:46 will they be running in the same machine ? 2021-05-26 11:20:20 most likely, but it would be best if it did not assume so 2021-05-26 11:20:54 they run in separate docker projects, so there is no direct connection 2021-05-26 11:21:59 ok 2021-05-26 11:23:44 mps: the libbpf-dev package ships the updated linux kernel uapi 2021-05-26 11:23:48 maribu[m]: it takes a little longer still. In the mean time, you can run curl -X PURGE to purge specific packages 2021-05-26 11:23:55 yes 2021-05-26 11:23:56 but bcc does not find it 2021-05-26 11:24:07 it uses the linux-headers version I guess 2021-05-26 11:24:21 it ends up using the header from linux-headers which is 5.10 2021-05-26 11:24:29 yes 2021-05-26 11:24:48 because that I posted patch to tpaste 2021-05-26 11:25:03 maybe add it to linux-headers 5.10 2021-05-26 11:25:35 should not be necessary to patch our linux-headers, since libbpf bundles the needed headers 2021-05-26 11:25:37 or upgrade linux-headers to 5.13-rc3 :) 2021-05-26 11:26:13 then you need to patch bcc to use libbpf header file 2021-05-26 11:26:25 (include proper file) 2021-05-26 11:26:43 $ apk info -L libbpf-dev | grep uapi | tpaste 2021-05-26 11:26:43 https://tpaste.us/manR 2021-05-26 11:27:20 will it conflict with linux-headers 2021-05-26 11:27:30 hmm no 2021-05-26 11:27:39 the libbpf installs it as usr/include/uapi/linux/bpf.h 2021-05-26 11:27:49 yes, just saw 2021-05-26 11:28:00 while linux headers installs it as usr/include/linux/bpf.h 2021-05-26 11:28:08 which is why it does not conflict 2021-05-26 11:28:15 but then patching bcc is needed? 2021-05-26 11:28:37 i think we should patch libbpf, as it does not work as expected 2021-05-26 11:29:13 the libbpf simply manually copy the uapi/linux/*.h files 2021-05-26 11:29:18 hmm, I knew these two libbpf will start to make mess one day 2021-05-26 11:29:35 are there two of them? 2021-05-26 11:29:52 it is community/libbpf that is a bit messy 2021-05-26 11:29:55 i had a look at the makefile 2021-05-26 11:30:08 not sure but I think building libbpf should be done from kernel source and not external one 2021-05-26 11:30:54 ok? 2021-05-26 11:31:12 how is the libbpf from kernel source better? 2021-05-26 11:31:13 but not now, maybe after 3.14 release 2021-05-26 11:31:21 https://github.com/libbpf/libbpf/blob/master/src/Makefile#L144 2021-05-26 11:31:37 there is a make install_uapi_headers 2021-05-26 11:32:03 yes 2021-05-26 11:32:17 which i think will install them same location as linux-headers by default, which wil create a conflict 2021-05-26 11:32:20 and it shouldn't do that imo 2021-05-26 11:32:54 i think it can do that, but it should not install it anywhere it can conflict with linux-headers 2021-05-26 11:33:12 yes, this is also ok 2021-05-26 11:33:27 and /usr/include/uapi is probably wrong too 2021-05-26 11:33:36 but some software except header files in different location 2021-05-26 11:33:53 i think it should install them to /usr/include/bpf 2021-05-26 11:34:10 and in pkg-config it should add -I /usr/include/bpf 2021-05-26 11:34:16 so the headers are found 2021-05-26 11:34:42 cd .. 2021-05-26 11:34:45 not sure do all software use pkg-config 2021-05-26 11:34:54 they dont 2021-05-26 11:34:56 i mean 2021-05-26 11:35:05 there is no guarantee they use pkg-config 2021-05-26 11:35:11 yes 2021-05-26 11:35:19 but pkg-config is the standard way to tell packages where to find headers 2021-05-26 11:35:55 yes, but as you know world like differences ;) 2021-05-26 11:36:27 imo, now is good your proposal 2021-05-26 11:36:29 are there any other standard way to tell where the headers are? 2021-05-26 11:36:44 in old days they use things like *-config --cflags 2021-05-26 11:36:50 like mysql-config --cflags 2021-05-26 11:36:55 but we should look what to do in future with libbpf 2021-05-26 11:37:37 in general, software should either install to the standard locations or setup a pkg-config when it's nonstandard 2021-05-26 11:37:59 and in this case we cannot use the standard location because it will conflict with linux-headers 2021-05-26 11:38:07 I wanted to make libbpf in linux-tools package but didn't wanted to make yet another flame 2021-05-26 11:39:15 whats wrong with https://github.com/libbpf/libbpf? 2021-05-26 11:40:03 nothing, but using one from kernel is/will be relief for distros 2021-05-26 11:41:05 I guess you can discuss it with the maintainer, Adam Jensen 2021-05-26 11:41:40 :) 2021-05-26 11:42:59 scripts/get_maintainer.pl tools/bpf/ | tpaste => https://tpaste.us/R45v 2021-05-26 12:01:34 ikke: Thanks for the info regarding curl -X PURGE, the CI now successfully installed all dependencies and the build process started :-) 2021-05-26 12:21:29 Where should I request static build of krb5-dev? 2021-05-26 12:40:02 eh, I made another attempt but I'm stuck on some make rules http://sprunge.us/hgDtFd 2021-05-26 15:12:53 how to handle faulty flagged issues on xen (https://security.alpinelinux.org/branch/3.13-main) the two CVEs on that list are issues in the xen code in the linux kernel 2021-05-26 15:43:32 HRio: I guess either ping Ariadne in #alpine-security or create an issue for it 2021-05-26 15:44:09 HRio: i'm aware of the XSA mapping issues, i haven't come up with a good answer quite yet 2021-05-26 15:44:09 if the CVE is not revelant, 'fix' it in version 0 2021-05-26 15:44:13 ^ 2021-05-26 15:44:35 its as if we had a manchild take over the IRC network we were using 2021-05-26 15:44:40 in the middle of doing a release 2021-05-26 15:44:54 so we are playing catchup :) 2021-05-26 15:46:39 i'd prefer to avoid add workaround to the secfixes for bugs in the sec tracker, but thats an option if the false positive is difficult to fix by other means 2021-05-26 15:47:04 like if the cve only affects a specific compile time configure option that we have disabled or similar 2021-05-26 15:47:30 If it's a categorical issue, it's better to fix it structurally 2021-05-26 15:47:35 yeah 2021-05-26 15:48:00 but for now its ok to do a work-around, so we can focus on the release 2021-05-26 15:48:21 >as if 2021-05-26 15:59:15 yeah i have some ideas 2021-05-26 15:59:23 i just want to focus on 3.14 release atm :p 2021-05-26 15:59:33 sounds like a good idea 2021-05-26 15:59:47 my plan is to enable login via gitlab, to allow maintainers to just reject the CVEs in their packages that way 2021-05-26 15:59:50 https://build.alpinelinux.org/buildlogs/build-3-14-x86/community/ruby-nokogiri/ruby-nokogiri-1.10.10-r0.log 2021-05-26 16:30:36 maribu[m]: fyi, I've now purged all of ppc64le/main 2021-05-26 16:41:45 ncopa: sneaky topic change on FN ;) 2021-05-26 17:32:05 why not make topic changeable by everyone, seems like a perfect solution to that problem :^) 2021-05-26 17:32:28 chat via topic :D 2021-05-26 17:36:56 Ikke: https://gitlab.alpinelinux.org/Cogitri/aports-qa-bot/-/merge_requests/25 2021-05-26 18:43:51 OK, lets wait with the XEN XSA mapping issue in v3.13 for now. Its not a problem in edge at the moment 2021-05-26 20:09:41 What is needed to move a package from testing to community? I maintain a package and have been using if for a few months with no problems. Is that enough? 2021-05-26 20:10:14 xordspar0: yes 2021-05-26 20:10:47 if you have verified that it's working, and you are willing to maintain it the package for 6 months (the last release) 2021-05-26 20:13:42 Ok, that sounds good to me. Thanks. :) 2021-05-26 20:38:03 and it's merged 2021-05-26 21:08:56 could someone please merge !20124 ? it was on auto-merge but CI/CD was aborted due to timeout, the pipeline was fine before rebase (#82537) 2021-05-26 21:11:02 !20124 2021-05-26 21:16:00 it will fail again with these 2h timeouts of alpine/aports; aarch64 ~4h, x86 ~3h 2021-05-26 21:16:39 you can increase the timeouts 2021-05-26 21:17:22 i have, but it looks like gitlab does only use the timers from liske/aports if I trigger CI/CD 2021-05-26 21:19:54 hmm, yeah, you are right. If we rebase it, the pipeline runs in the context alpine/aports 2021-05-26 21:21:46 liske: I've increased the timeout now 2021-05-26 21:22:05 thanks :-) 2021-05-26 21:23:18 This changed relatively recently, but I was not aware this also affected the pipeline timeouts 2021-05-26 21:25:44 will merging changes on master in the meantime kill auto-merge as Ariadne did before? No merges for 4h on master sounds challenging oO 2021-05-26 21:26:10 s/did/triggered/ 2021-05-26 21:26:10 liske meant to say: will merging changes on master in the meantime kill auto-merge as Ariadne triggered before? No merges for 4h on master sounds challenging oO 2021-05-26 21:26:24 once it's green, we can just directly merge it 2021-05-26 21:29:25 ok & ty :-) 2021-05-26 22:04:47 824f09718cfc194f1a27546ce34028aeaebdc929 introduces circle dep tiff <-> libwebp 2021-05-26 22:13:30 I have a couple MRs that I'd appreciate if someone could look at when they get the chance. !20999 !21493 2021-05-26 23:20:19 is there a particular reason we stop bumping versions of vulnerable packages at a certain point on the stable branches and start backporting individual commits instead? 2021-05-26 23:23:57 the example i had in mind was curl (e.g. https://gitlab.alpinelinux.org/alpine/aports/-/commits/3.11-stable/main/curl/APKBUILD) 2021-05-26 23:36:52 How do I specify a git repository for a abuild's source? 2021-05-26 23:41:57 agris: You can't, but (almost) all git hosters have a way to download a tarball of a specific commit 2021-05-26 23:43:02 Cogitri: that's not a solution to my problem. The software I'm trying to port is a git superproject 2021-05-26 23:43:29 that is, the project is large and so each componet of it is split and managed in it's own git submodule repository 2021-05-26 23:44:12 to bootstrap the software, you clone the superproject, then run git submodule init git submodule update, and the git superproject managed which fingerprint to checkout all the submodules at 2021-05-26 23:44:27 How do I package such software in Alpine? 2021-05-26 23:45:50 If I just downloaded a git tag tarball, it'd only contain the superproject and all the submodules would be missing, and it'd be too much work to go look at which fingerprint to checkout for every single release of the software 2021-05-26 23:49:16 Cogitri? 2021-05-27 00:51:15 csn: it's on a case by case basis 2021-05-27 00:51:38 in that case, upstream didn't backport to 7.67, and we were worried about regressions 2021-05-27 00:52:01 hm, actually i might be thinking of another case 2021-05-27 00:52:12 but anyways, that's usually the reason 2021-05-27 00:52:35 we often reference backports by other distros to check our work 2021-05-27 01:46:39 agris I'm currently trying to package a similar package that also requires a git clone. I'm attempting to make use of the snapshot function, and getting the resulting archive on the alpine linux dev server to use: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21517 2021-05-27 03:14:12 Thankyou 2021-05-27 03:14:30 Is there any reason that Alpine's packaging system doesn't make use of libzstd 2021-05-27 03:14:39 Considering a library for it's on the inso 2021-05-27 03:14:41 Iso 2021-05-27 03:14:52 Why is only gzip supported? 2021-05-27 04:37:51 liske: x86_64 failed :( 2021-05-27 05:53:04 ikke: there is a 'killed' in https://gitlab.alpinelinux.org/alpine/aports/-/jobs/401282#L1727 2021-05-27 05:53:40 could this be OOM? I did increase jobs from 8 to $nproc ... 2021-05-27 05:54:02 which seems to be 48 on x86_64 2021-05-27 05:57:00 liske: seems so 2021-05-27 05:57:14 Out of memory: Killed process 26485 (python2) total-vm:6587268kB, anon-rss:3137384kB, file-rss:4kB, shmem-rss:0kB, UID:1000 pgtables:12940kB oom_score_adj:0 2021-05-27 06:03:00 uh, what could I do? Change jobs to something like $(( nproc > 16 ? 16 : nproc )) ? 2021-05-27 06:12:15 morning 2021-05-27 06:18:18 ncopa: morning 2021-05-27 06:20:27 ncopa: good morning 2021-05-27 06:37:39 very good morning 2021-05-27 06:45:09 namaste namaste 2021-05-27 06:47:29 what about to remove bridge-utils from alpine 2021-05-27 06:48:56 iproute2 support managing bridges for long time 2021-05-27 06:48:58 +1 (/me prefers the iproute2 stack, but I don't know if any packages uses those legacy commands) 2021-05-27 06:49:51 not sure does busybox ip support bridge commands 2021-05-27 06:50:50 busybox also provides this legacy ifconfig command :-( 2021-05-27 06:52:03 busybox iplink 2021-05-27 07:11:23 agris: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/4984#note_45862 2021-05-27 11:06:27 mps: I am hitting a bit of a problem with tiger lake/sound support in 5.12.7 atm and discussing the issue on the alsa-devel-ML; I notice that we "disable" (or not enable) quite some chipsets in the sound section. Is this intentional or should we update .config to enable "most" chipsets by default? 2021-05-27 11:10:31 Two of them being CONFIG_SND_SOC_INTEL_SKL_HDA_DSP_GENERIC_MACH and CONFIG_SND_SOC_SOF_TIGERLAKE, but I see many more missing in "intel machine drivers", which could be selected as modules 2021-05-27 11:10:42 I think with zstd 1.5.0 out we should consider it for 3.15 2021-05-27 11:11:03 I found significant compression benefits on kernel and initramfs 2021-05-27 11:11:51 nico[m]: we usually enable drivers in kernels on users (or devs) requests, to not bloat kernel too much 2021-05-27 11:12:52 (though nowadays bloating looks like a preference) 2021-05-27 11:13:16 Hello71: I marked zstd to 3.15.0 milestone 2021-05-27 11:13:44 I mean actually using it, not just bump 2021-05-27 11:14:04 yes, I agree 2021-05-27 11:14:54 nico[m]: you can open issue/wish request or write mail 2021-05-27 11:14:57 regarding kernels, I want to suggest again subpackages for kernel modules 2021-05-27 11:15:23 oh no :) 2021-05-27 11:16:06 mps: will do. I will probably split it into 2 patches: 1 that fixes my system and 1 that I think should be enabled additionally to prevent future desktop users running into easy-to-avoid problems 2021-05-27 11:16:29 nico[m]: I will note your msg above for next upgrade of linux-edge, so you don't need to do anything 2021-05-27 11:16:56 please do not predict future, just those you need now 2021-05-27 11:17:38 ack, thanks. Be aware, they are rather deeply nested, depend on other config options (in case of CONFIG_SND_SOC_SOF_TIGERLAKE) 2021-05-27 11:17:41 To be able to use zstd, we need to make sure all our tools support it 2021-05-27 11:17:50 mainly apk-tools and abuild 2021-05-27 11:18:12 as I told we usually enable drivers/features only on request, though not always 2021-05-27 11:18:17 But, apk-tools 3.0 already comes with a different format for packages 2021-05-27 11:45:36 turns out that the firmware from https://github.com/thesofproject/sof-bin/ is also needed for getting the sound card running again. What's the typical procedure for getting firmware included? I assume we mostly rely on linux-firmware, which does not yet have those blobs included 2021-05-27 11:47:54 nico[m]: make separate pkg till it is not upstreamed 2021-05-27 11:56:57 is there any way to match up the ><$hash dependencies in /etc/apk/world to files in the package cache? 2021-05-27 12:04:16 hmm it doesn't even seem to be valid base64 2021-05-27 12:06:58 its truncated 2021-05-27 12:07:40 what hash is it? sha1(apk file)? 2021-05-27 12:12:25 yes think so 2021-05-27 12:18:19 hmm not matching up 2021-05-27 13:16:22 ikke: i've limited the max jobs in !20124 and CI/CD now seems to be fine :-) 2021-05-27 15:19:47 it doesn't feel right to limit jobs just to make CI pass if it isn't needed on the builders.. (not directed at you, liske) 2021-05-27 15:21:27 would it be possible to limit some limits to the limited CI builders? 2021-05-27 15:34:55 lxc fakes the value of nproc. Maybe the CI jobs could do the same 2021-05-27 15:39:25 something like taskset -c "$(( $RANDOM % $(nproc) ))" nproc to spawn the CI jobs should be enough (a little more sophisticated for more than one core of course) 2021-05-27 16:11:45 The problem is the amount of memory each job take 2021-05-27 16:11:48 takes 2021-05-27 16:12:11 generally, $(nproc) is not an issue, we build almost anything with it 2021-05-27 16:12:39 but some programs use more then $memory/$cores per job 2021-05-27 16:13:02 in those cases, we need to limit the amount of jobs 2021-05-27 16:17:58 some projects need upwards of 8GB/job. 2021-05-27 17:30:09 stripbbin fails for aisleriot, it has shared go binaries, but strip does not like them 2021-05-27 17:35:06 anything against adding !strip for it? 2021-05-27 17:35:15 There are 2 smallish non-go binaries 2021-05-27 17:37:48 .go there is actually probably guile 2021-05-27 17:38:01 and !strip is fine 2021-05-27 17:43:27 fwiw void's strip hook skips guile stuff 2021-05-27 17:43:40 because it's all kinds of weird 2021-05-27 17:45:46 Ariadne: yeah, would be guile then 2021-05-27 22:58:09 Hello71: thanks for the info :) 2021-05-28 01:23:08 mps: subpackages seems better than totally missing or having to ask every time 2021-05-28 01:23:50 how many people wanted to use alpine but had disabled modules and either assumed it was unfixable or didn't bother to ask 2021-05-28 01:24:33 obviously one package per module is too much, but i feel like there should be some middle ground here 2021-05-28 01:25:47 it's not like the build time on servers for some extra modules is a problem 2021-05-28 01:26:11 maybe we can even drop linux-virt 2021-05-28 01:31:37 why would you drop linux-virt when virtual machines are a couple orders of magnitude more common than real machines? 2021-05-28 01:43:03 what value does it add over a linux-baremetal subpackage 2021-05-28 01:43:41 assuming we decide to use subpackages for kernel modules 2021-05-28 01:55:36 if we also fix modloop problem (mount /lib/modules overlayfs?) then we can e.g. not ship sound support on iso, since afaik we don't ship any sound programs either, so you need to connect to internet and download stuff anyways 2021-05-28 03:21:59 one reason not to get rid of linux-virt is that a kernel with PARAVIRT_GUEST that isn't actually running as a VM is slower (at least theoretically according to kernel docs... can't find anything that actually tests it) 2021-05-28 03:22:18 that said, the default kernel config includes that option 2021-05-28 06:57:31 Hello71: make allyesconfing, you mean 2021-05-28 06:58:16 or more 'relaxed' allmodconfig 2021-05-28 07:00:03 imo, alpine users should build their kernels tailored and optimized for their specific use cases 2021-05-28 07:01:01 alpine should provide just base kernel which should be used for installation and maybe rescue 2021-05-28 07:03:21 about -virt flavour, yes it is used a lot nowadays 2021-05-28 07:05:22 imagine using kernel with all options/drivers/features enabled on small arm32 SBCs 2021-05-28 07:05:51 I doubt that anyone will use it 2021-05-28 07:07:47 is there tooling to support subpackaging of kernel modules? 2021-05-28 07:07:58 when is 3.14 release expected? what crystal ball says? 2021-05-28 07:08:26 clandmeter: I don't know any distro which do this 2021-05-28 07:08:43 thats why im asking :) 2021-05-28 07:08:51 hehe 2021-05-28 07:08:58 you are my kernel guru 2021-05-28 07:09:19 and i cant find my crystal ball 2021-05-28 07:09:22 again, hehe 2021-05-28 07:10:19 I prepared !21725 and think it would be good to be merged for 3.14 2021-05-28 07:10:46 few years of accumulated fixes, changes in it 2021-05-28 07:11:10 also !21728 2021-05-28 07:12:41 re: kernel, good thing would be to add dkms and we should look at this after 3.14 is released 2021-05-28 07:15:11 is dkms going to be your alpine summer of code project this year? 2021-05-28 07:15:53 :D 2021-05-28 07:16:43 weather in last two month show me that this year summer will be 'skipped' 2021-05-28 07:18:12 but yeas, I already looked at dkms and probably will try something after 3.14 2021-05-28 08:42:25 re pipewire, as i understand, its normally started by socket activation by systemd. Any suggestion how those process should be started in alpine? 2021-05-28 08:45:08 currently you can start pipwire process itself by /etc/xdg/autostart/pipewire.desktop but pipewire-media-session and pipwire-pulse is not autostarted 2021-05-28 08:45:59 port systemd to musl ;p 2021-05-28 08:46:38 there are a few ppl who has tried that, but i think its meaningless as long as upstream systemd explicitly does not support anything but glibc 2021-05-28 08:47:03 yes, I know, jk 2021-05-28 08:47:34 im thinking that maybe a tiny user supervisor could be started via /etc/xdg/autostart/something.desktop 2021-05-28 08:47:50 and idea to have autostart anything is bad, imo (no need to comment my opinion) 2021-05-28 08:48:16 well, all autostart is not bad. kinda need to autostart sshd 2021-05-28 08:48:36 and would be nice to autostart whatever daemon needed for sound to be available 2021-05-28 08:48:37 rc-update add sshd 2021-05-28 08:49:42 $ apk info --who-owns /etc/xdg/autostart/* | tpaste 2021-05-28 08:49:42 https://tpaste.us/LwZV 2021-05-28 08:50:34 s6 as pid1 2021-05-28 08:51:02 the idea is to have a supervisor for those non-root services 2021-05-28 08:51:09 that you need when you log in 2021-05-28 08:51:57 maybe this is possible with s6 2021-05-28 08:52:05 possibly 2021-05-28 08:52:23 if not you can ask skarnet to add it 2021-05-28 08:52:29 but i think s6 is designed to run as root, and manage system services 2021-05-28 08:53:01 and tbh, i kinda like the idea of socket activation 2021-05-28 08:53:32 I remember that I had user services start with DJB daemontools long ago, but I forgot how I did it 2021-05-28 08:53:50 im no fan of DJB style 2021-05-28 08:55:20 also I'm not 2021-05-28 08:57:41 there were upstart daemon which I used for some time 2021-05-28 09:10:58 user services is a lot more complex to do than root services, but I have some support in s6 for it 2021-05-28 09:11:06 and I plan to add more support with time 2021-05-28 09:11:48 the problem is that implementing user services implies answering a lot of policy questions that you don't have with root (boot-time) services 2021-05-28 09:12:38 s6 hardcodes mechanism, not policy, so I don't want to hardcode answers to those policy questions, but in the context of a distribution it totally makes sense 2021-05-28 09:14:11 also, get on with the times, "djb style" was a thing 20 years ago, nowadays it doesn't mean anything :P if you have specific criticism please make it explicit and accurate 2021-05-28 09:17:23 it feels weird/different. and its mostly a question of taste 2021-05-28 09:21:50 other things i remember from 20 years ago was that each config knob was in its own file. handy for scripts, but was a bit difficult to get the overview of the system configs 2021-05-28 09:25:45 i also had a feeling it was all-or-nothing. to make it work you'd need all the small helper tools around it. it wasn't so easy to just take a few parts and only use them. same thing i dislike with systemd nowdays 2021-05-28 09:26:07 s*d is worse in that regard ofc 2021-05-28 09:32:30 weird that you get that all-or-nothing feeling since the design intent is the exact opposite, but it's true that in an ecosystem where not many tools use the chainloading design, you can feel a little starved for external tools that fit with the system 2021-05-28 09:32:38 it's a lot better nowadays 2021-05-28 09:34:11 re: config files/directories, yeah, I totally get you - it's a design that I like and use because it makes parsing a lot easier and less error-prone, but everyone agrees it's not very comfortable for humans (which is why I'll be working on a user-friendly interface) 2021-05-28 09:36:52 to me runit/s6 'config' is good thing 2021-05-28 09:38:07 and I hope that I will find time in next few months to install s6 as pid 1 2021-05-28 09:38:34 cool :) 2021-05-28 09:38:47 I definitely have multiple packages that rely on being started automatically as a user service, and for now I'm using the XDG autostart method. But having something proper to replace that in the long run would definitely be nice 2021-05-28 09:39:39 and as ncopa said, pipewire is one of them 2021-05-28 09:40:17 I'm really looking forward to an s6 future. :) 2021-05-28 09:40:32 just wish the funding'd materialize already. 2021-05-28 09:40:33 would be nice to find url which explains in short difference between runit and s6 run scripts and config 2021-05-28 09:40:34 ncopa: for now we require users to manually edit the pipewire config so it itself launches -pulse and -media-session. Upstream made this possible but they themselves indeed use systemd to do it instead 2021-05-28 09:41:11 but I will try do that by reading s6 docs 2021-05-28 09:41:41 Sheila: stay tuned :) 2021-05-28 09:42:58 mps: https://skarnet.org/software/s6-linux-init/quickstart.html has some information, as well as a pointer to a very nice explanation by heliocat 2021-05-28 09:45:49 skarnet: ah, very good, thanks 2021-05-28 09:46:00 will put in todo 2021-05-28 09:46:18 my read todo, I mean 2021-05-28 09:46:40 i agree that user services are also best services by a system supervisor 2021-05-28 09:46:47 (one thing systemd does also do nicely) 2021-05-28 09:46:56 (for the extent that systemd does things nicely) 2021-05-28 10:03:50 skarnet: there are things i do like with s6. for example i like the idea of exec'ing pid 1 depending on the stage (boot, run shutdown), which IIRC i read somewhere on the s6 pages 2021-05-28 10:34:43 ncopa: you know we could have this in Alpine *right now*, without changing anything to the OpenRC sequence ;) 2021-05-28 10:36:22 do I remember correctly that we do that in AdĂ©lie? cos I know we install s6 unconditionally rn
 2021-05-28 10:38:01 it's exactly what we do in AdĂ©lie, yes (but there's still the option for sysvinit) 2021-05-28 11:03:39 right, because s6-linux-init is separate. :) 2021-05-28 12:40:14 iggy: https://git.alpinelinux.org/aports/tree/main/linux-lts/config-lts.x86_64#n334 2021-05-28 12:40:26 https://cateee.net/lkddb/web-lkddb/PARAVIRT_GUEST.html is obsolete and also doesn't say anything of the sort 2021-05-28 12:41:40 config per file was fine for me after i learned about grep . * 2021-05-28 12:41:53 see also: head -n -0 * 2021-05-28 15:08:39 ncopa (or someone else with commit access to main): any chance you can merge !20753? 2021-05-28 15:17:11 PureTryOut: looks ok 2021-05-28 15:17:42 Thank you! 2021-05-28 15:18:19 merged! and thank you for removal systemd 'artefacts' 2021-05-28 15:18:31 Np đŸ‘ïž 2021-05-28 15:19:10 linux-pam was the only package in main doing it at least, but there are multiple still installing those files in community and testing 2021-05-28 15:19:33 Cogitri: mostly gnome stuff it seems https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Flib%2Fsystemd*&name=&branch=edge&repo=community&arch=x86_64 2021-05-28 15:20:05 hmm, I think I have something to do about this in iwd, will look later 2021-05-28 15:34:45 Maybe a warm thingie in abuild for that would be nice 2021-05-28 15:35:53 does dbus expect some files in /usr/share/dbus-1/system.d 2021-05-28 15:36:02 I'm not sure about this 2021-05-28 15:38:36 https://gitlab.alpinelinux.org/alpine/mkinitfs lacks license information :P 2021-05-28 15:39:29 I like software without licenses 2021-05-28 15:43:37 i'm trying to package a go app for the first time !21666 - how should that go dependencies be handled? 2021-05-28 15:44:13 is it ok that they are be pulled during build? 2021-05-28 15:46:18 Not for me, but in general sadly yes. Make sure you set `options="net"` though, most people forget that 2021-05-28 15:51:31 PureTryOut: ty, didn't know options= before 2021-05-28 15:53:13 I personally really think the build should fail when the network is accessed while building and `options="net"` isn't set. This happens already when using `abuild rootbld` but most people don't seem to use that 2021-05-28 16:00:52 *nod* 2021-05-28 16:01:10 couldnt you just unshare -n to do that? :) 2021-05-28 16:01:24 if CI/CD doesn't throw any errors I think everything should be fine for the "black box" making the package available in alpine :-( 2021-05-28 16:01:58 <[[sroracle]]> it's not a black box. everything the builders do is publicly available (though not documented well) 2021-05-28 16:02:16 black box == thinks I'm not aware of it ;) 2021-05-28 16:02:19 <[[sroracle]]> the problem is that CI doesn't use the same process as the builders (because it is more recent) 2021-05-28 16:03:14 s/thinks/things/ 2021-05-28 16:03:14 liske meant to say: black box == things I'm not aware of it ;) 2021-05-28 16:06:02 i dont think ci is using rootbld? 2021-05-28 16:06:42 no 2021-05-28 16:06:55 so setting options=net doesnt make a diff now 2021-05-28 16:07:09 except if we would switch our builders to rootbld 2021-05-28 16:07:19 rootbld for CI does not make sense, except for the networking part 2021-05-28 16:07:29 correct 2021-05-28 16:08:05 the only noticeable difference is tty availability afaik 2021-05-28 16:22:20 it doesn't make a difference for the CI or the builders, but it does make a difference for people using rootbld. Also it's easier to find packages using the network when that is set as you can just recursive grep through the aports 2021-05-28 16:33:44 Anyone got an opinion on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21824 2021-05-28 16:34:39 specifically, the way they prefer to package go projects, where they provide a apk.go file which just imports the actual project, provide separate go.{mod,sum} files, and no actual source in the sources list 2021-05-28 16:45:29 Oh that looks ugly 2021-05-28 16:45:46 If you can't just add a patch next to the APKBUILD which modifies the upstream source, then it's wrong imo 2021-05-28 16:51:31 imo the only thing that needs net access is fetch. build should be able to run without 2021-05-28 16:52:44 (but I know, it is a losing battle. go, rust, ...) 2021-05-28 16:53:20 Right, though I think you can still explicitly fetch the modules before the build phase 2021-05-28 16:53:22 at least for go 2021-05-28 16:59:34 ikke: the original code looks pretty ugly to me, your changes makes sense though 2021-05-28 17:14:22 mercenary: I do agree with you 2021-05-28 17:19:57 https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ 2021-05-28 17:20:37 that is, all these modern hipsters^Wdev langs 2021-05-28 17:22:01 I blame perl and cpan for starting that trend 2021-05-28 17:22:49 yes, but perl is really easy compared to go, rust, crystal ... 2021-05-28 17:24:11 You mean, you can just mash on your keyboard, and have a valid perl program? :P 2021-05-28 17:24:54 ikke: well, I can do for most of them ;) 2021-05-28 17:25:00 not all, ofc 2021-05-28 17:41:29 mashing keyboard is out of fashion 2021-05-28 17:41:44 nowadays you just mash ^C, alt+tab, and ^V with stack overflow open 2021-05-28 17:42:06 :) 2021-05-28 18:05:52 dalias: like this, right? https://stackoverflow.blog/2021/03/31/the-key-copy-paste/ 2021-05-28 19:14:12 just had a weird failure on gitlab CI 2021-05-28 19:14:33 https://gitlab.alpinelinux.org/Leo/aports-proxy-bot/-/jobs/402999 2021-05-28 19:15:27 go 1.15 is one attempt and 1.16 in the next attempt (error is due to usage of io.ReadAll that is 1.16 only) 2021-05-28 19:17:05 different runners, I guess with different cached images 2021-05-28 19:17:33 since the new docker policy, we sadly cannot pull the latest version for each CI job anymore 2021-05-28 19:19:03 alpinelinux/golang latest 0f9d4110127a 5 days ago 2021-05-28 19:19:30 hmm 2021-05-28 19:21:43 the ppc64le ci host was not setup to automatically clean up, so it would never pull new images 2021-05-29 10:25:55 ty 2021-05-29 12:26:27 Cogitri: apk-tools-d depends on openssl-d, which has been moved to unmaintained 2021-05-29 12:33:50 Cogitri: http://dup.pw/alpine/aports/b652e10f1725 2021-05-29 12:44:57 Ah whops, I suppose we can move apk-tools-d too 2021-05-29 14:52:44 /!\ THIS CHANNEL HAS MOVED TO IRC.LIBERA.CHAT #HAMRADIO /!\ 2021-05-29 14:52:46 /!\ THE JEWS HAVE TAKEN OVER FREENODE, CHATS HAVE MOVED TO IRC.LIBERA.CHAT /!\ 2021-05-29 14:52:46 /!\ JOIN #HAMRADIO TODAY. THIS CHANNEL HAS MOVED TO IRC.LIBERA.CHAT #HAMRADIO /!\ 2021-05-29 14:52:47 THIS OFFICIALLY ENDORSED MESSAGE WAS BROUGHT TO YOU BY LIBERA.CHAT STAFF 2021-05-29 15:04:47 and here I though OFTC would be more or less immune to that shit 2021-05-29 15:14:19 spam comes to all networks. 2021-05-29 15:20:13 at least it is slowing down as time passes 2021-05-29 15:20:18 eventually they'll get bored of it 2021-05-29 15:32:45 +S (TLS only) often works too funnily. The bots could at least connect securely :( 2021-05-29 16:04:37 skarnet: they're spamming all irc networks they find on shodan 2021-05-29 16:04:55 even my testing irc server 2021-05-29 16:04:57 got spammed 2021-05-29 16:05:00 why would irc networks be on shodan 2021-05-29 16:05:00 and its not even public 2021-05-29 16:05:21 shodan scans everything ports 0 through 65535 2021-05-29 16:05:27 so if you search for 6667 2021-05-29 16:05:32 you will find all the irc networks 2021-05-29 16:05:34 :) 2021-05-29 16:06:52 opinion of tactical nukes rising 2021-05-29 16:17:01 Now I wonder if a curated IP list of shodan scanners exists (Blocking all at firewall level might be a good idea). 2021-05-29 17:21:28 that's not really a solution, just a workaround - they're still exposed on the internet, and other scanners exist 2021-05-29 17:21:32 but i digress 2021-05-29 17:24:42 security by obscurity etc 2021-05-29 18:10:03 gotta deploy that meltwall 2021-05-29 18:10:22 also TIL about shodan scanning IRC ports 2021-05-29 20:53:51 #join #alpine-commits 2021-05-29 20:54:43 :-) 2021-05-29 20:57:03 HRio: good suggestion ;-) 2021-05-29 20:57:52 good it was not on that other network, then we would have lost this channel due to the "spam" 2021-05-29 20:59:09 https://developers.slashdot.org/story/21/05/29/0224246/freenode-apologizes-as-prominent-open-source-projects-switch-to-libera-chat 2021-05-30 06:05:01 why is there a glibmm package and a glibmm2.68 package in community that provide the same things? 2021-05-30 06:05:20 I noticed that glibmm-2.4 was removed (maybe from this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21637/diffs) 2021-05-30 06:05:36 which breaks atkmm, gtkmm, and a few other things that depend on glibmm-2.4 2021-05-30 06:06:15 e.g. when trying to build atkmm: configure: error: Package requirements (atk >= 1.18 glibmm-2.4 >= 2.46.2) were not met 2021-05-30 06:06:39 glibmm2.68 is the ABI breaking one 2021-05-30 06:07:00 seems like maybe the glibmm package used to provide glibmm-2.4 stuff 2021-05-30 06:07:43 makes sense, that's the previous ABI 2021-05-30 06:07:52 the new one is glibmm-2.68 ABI series. 2021-05-30 06:08:15 from https://gitlab.gnome.org/GNOME/glibmm/-/blob/master/NEWS they can be installed side by side 2021-05-30 06:08:45 ah, so the glibmm package in alpine probably shouldn't have been upgraded to 2.68 then? 2021-05-30 06:08:51 this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/21637/diffs 2021-05-30 06:09:27 since that dropped the 2.4 stuff, effectively making glibmm and glibmm2.68 the same package in alpine 2021-05-30 06:11:30 or the packages depending on glibmm should all have been rebuilt? idk if everything just works with new glibmm 2021-05-30 06:12:03 well atkmm requires patching the makefile I guess to use the newer version... 2021-05-30 06:12:08 that would have included updating atkmm and others 2021-05-30 06:12:19 and 'abi break' tends to make me thing it may not be as simple as changing version strings in makefiles :P 2021-05-30 06:12:21 there's a proper atkmm release with support for the new ABI 2021-05-30 06:12:34 also gtkmm 2021-05-30 06:13:30 and pangomm it seems 2021-05-30 06:13:45 just looking at the 'required by' here; https://pkgs.alpinelinux.org/package/edge/community/x86_64/glibmm 2021-05-30 06:14:57 those seem to be older versions (e.g. pangomm2.48).. so if glibmm-2.4 is out, then those should be dropped? 2021-05-30 06:15:12 I'm not sure how to handle this 2021-05-30 06:15:31 I think pangomm 2.46 is the old one, 2.48 is the new ABI 2021-05-30 06:17:25 confirmed This is the first stable release in the pangomm-2.48 ABI series. 2021-05-30 06:17:30 from https://gitlab.gnome.org/GNOME/pangomm/-/blob/master/NEWS 2021-05-30 06:18:17 ok so the pangomm, atkmm, and gtkmm packages, which seem to be older versions, no longer work with glibmm since it packaged 2.68 2021-05-30 06:18:29 e.g. https://pkgs.alpinelinux.org/package/edge/community/x86_64/pangomm 2021-05-30 06:18:39 which is 2.42.2 2021-05-30 07:55:06 how we fix PATH_MAX missing on ppc64le? by patching source or something else? 2021-05-30 07:55:22 You need to include something 2021-05-30 07:55:34 limits.h 2021-05-30 07:55:49 so yes, patching source iirc 2021-05-30 07:56:25 yes, that is all I can see 2021-05-30 07:56:43 I had a hope for something more general 2021-05-30 07:57:22 ikke: thanks :) 2021-05-30 07:57:25 like, rm -rf ppc64le ;> 2021-05-30 07:57:43 liske: you're welcome 2021-05-30 07:58:05 wasn't there talk a while back about keeping one or two old kernels installed with a kernel upgrade? 2021-05-30 07:58:55 https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E#%3C20210120102309.32fed780@ncopa-desktop.lan%3E 2021-05-30 08:02:25 that yes. sounds like it is on the 'maybe we'll look into that when there is spare time' list? 2021-05-30 08:03:58 (it bit me nicely yesterday. for $reasons, /boot was not properly mounted, and after apk upgrade -a && reboot the box disappeared off the network....) 2021-05-30 08:09:19 At least the way the kernel is now installed, it's not trivial to leave a copy behind 2021-05-30 08:13:25 yeah. more state to keep track off. And I guess bluntly removing 'any kernel except current and previous' will irk some people who have reasons to keep 5 different kernels installed for testing 2021-05-30 08:13:51 archlinux has the same issue 2021-05-30 08:14:18 I regularly extract the modules from the running kernel after upgrades 2021-05-30 08:14:27 s/from/for/ 2021-05-30 08:14:27 ikke meant to say: I regularly extract the modules for the running kernel after upgrades 2021-05-30 08:15:01 add linux-edge on supported arches as rescue kernel 2021-05-30 08:15:58 or if use linux-edge as main kernel add linux-lts as rescue 2021-05-30 08:17:16 mps: they can still run in the same issue when /boot is not mounted 2021-05-30 08:17:51 yes, but do this when the boot mounted 2021-05-30 08:17:53 That might actually be feasible without too much effort. But indeed it runs into the same problems when e.g. both get upgraded in the same run 2021-05-30 08:19:19 leaving the previous kernel would still fail though if there was more then one upgrade between reboots 2021-05-30 08:20:33 leave 'currently running kernel' then? 2021-05-30 08:20:35 mercenary: as I understand it, this is mostly about the modules, right? 2021-05-30 08:21:08 ikke: yes. it boots in old kernel, NIC driver isn't there 2021-05-30 08:21:33 it is probably new modules and old kernel/initramfs 2021-05-30 08:21:39 yes 2021-05-30 08:21:55 so /lib/modules/$(uname -r)/ does not exist 2021-05-30 08:22:18 (and for reasons unknown, it also didn't have lib/modules/$newkernel, tarfiles over 115200 serial are slower than I remember) 2021-05-30 08:23:29 mps: it boots from the proper /boot, $oldkernel. But the modules for $oldkernel are now missing 2021-05-30 08:23:49 yes, I know 2021-05-30 08:24:14 that happens too often for some users 2021-05-30 08:25:00 solution is to have rescue kernel 2021-05-30 08:27:10 cp kernel%(uname -r) kernel-rescue 2021-05-30 08:27:58 but that does not help if the kernel does not look there for modules 2021-05-30 08:28:11 it would require manual intervention 2021-05-30 08:28:29 sure 2021-05-30 08:29:27 (if someone want easy and 'not need to think' OS my advice is macos or windows) 2021-05-30 08:30:24 or cromeos, and be proud to using linux :) 2021-05-30 08:31:03 let's just do the void thing: install versioned kernels, never remove them. Disk space is the user's problem 2021-05-30 08:31:51 this doesn't look to me as good idea 2021-05-30 08:32:51 for 'maintained' systems it works surprisingly well. vkpurge once in a while, done 2021-05-30 08:33:18 for systems on auto-pilot that run upgrade from crontab, it leads to problems 2021-05-30 13:26:45 are subpackage functions run in the order they're mentioned at subpackages= ? 2021-05-30 13:27:43 I guess the real question is this >>> WARNING: bpftrace*: Found /usr/share/man but package name doesn't end with -doc 2021-05-30 13:28:09 it's an empty dir for the bpftrace package and I want to know where it's safe to remove it 2021-05-30 13:29:17 omni: yes, they are run in order 2021-05-30 13:31:10 ok, but in what order? :D 2021-05-30 13:31:15 the one I assumed? 2021-05-30 13:31:39 yes 2021-05-30 13:31:40 (and not alphabetically or the order they're presented in the APKBUILD) 2021-05-30 13:31:44 ok, thanks! 2021-05-30 13:32:27 when I look at it the last mv in tools_doc() doesen't look right anyway.. 2021-05-30 13:39:54 but then I read the comments above... 2021-05-30 13:40:22 tools_doc? 2021-05-30 13:40:27 custom function? 2021-05-30 13:41:23 community/bpftrace/APKBUILD 2021-05-30 13:43:55 I guess the idea is that doc first moves man8/bpftrace.8.gz, and then the tools_doc function takes everything else 2021-05-30 13:44:28 yeah, and that leaves empty dirs for the main package 2021-05-30 14:04:54 omni: apkbuild are "regular" shell scripts which get sourced. same logic applies. 2021-05-30 15:21:11 hm, looks like there was a syntax change in logrotate and we need to update a few logrotate files :/ 2021-05-30 15:34:55 !21878 seems to only affect two packages 2021-05-30 18:16:11 I've just moved #alpine-reproducible from freenode to oftc too, I'm not sure if I'm the right person to own the channel, I'll gladely transfer it to somebody else 2021-05-30 18:24:22 nice 2021-05-30 18:24:39 i was hoping to already be deep into upstreaming that stuff 2021-05-30 18:25:01 unfortunately this freenode debacle and alpine 3.14 release have consumed non-trivial parts of my time :D 2021-05-30 18:29:39 how close is the release looking? 2021-05-30 18:30:13 https://build.alpinelinux.org/ 2021-05-30 18:31:22 very nice... thanks for showing me that, did not know it existed until now 2021-05-30 18:40:02 it seems that armv7 and mips64 finished 2021-05-30 18:40:12 other arches still have some packages that fail to build 2021-05-30 18:49:51 omni: haxe fails to build now for 3.14 2021-05-30 18:50:01 I see that you have an MR open that tries to upgrade which is failing as well 2021-05-30 19:11:41 hm, i think i was hoping for containerd to be bumped before 3.14 release 2021-05-30 19:17:39 fcolista: mingw-64-crt fails to build, has no maintainer, but I see openvas depends on it 2021-05-30 20:20:26 so about the latest glibmm package upgrade breaking abi with 2.4... any ideas how to proceed? 2021-05-30 20:25:58 What's there to do? 2021-05-30 20:26:24 If something needs the older glibmm keep using that, once they adapt to the API change, change it to glibmm2.68 2021-05-30 20:41:34 Cogitri: can't use the older glibmm, it was removed when glibmm was upgraded to 2.68 2021-05-30 20:41:55 so the glibmm and glibmm2.68 packages are basically the same thing now on edge 2021-05-30 20:42:35 glibmm is 2.68, so glibmm-2.4 is no longer available. i think the glibmm package needs to be rolled back 2021-05-30 20:52:13 imo introduce glibmm-2.4 2021-05-30 20:58:07 Oh, didn't I split the packages? I thought I did 2021-05-30 21:06:26 Oh, I did do that 2021-05-30 21:07:11 But 28ece6a5025e0b3fc78675c1c84baee3167de0ca undid it 2021-05-30 21:07:47 So I suppose we can just revert that and it'll be alright again 2021-05-30 21:09:44 Derp on my part merging the MR for glibmm, somehow I didn't notice that the MR touched glibmm and not glibmm2.68, my bad 2021-05-30 21:09:54 Thanks for the ping, should be fixed now 2021-05-30 21:23:31 Cogitri: ah, thanks! yeah maybe an explicit glibmm2.4 package would help prevent it from (unintentionally) disappearing again in the future 2021-05-30 21:52:16 I'd rather not change the package name when it has been that way for the last few years already 2021-05-30 21:53:11 We could add a note to the APKBUILD 2021-05-30 22:41:45 ikke: I'll see what I can do, been a bit busy with other things lately 2021-05-30 22:44:51 Cogitri: well there is a problem really 2021-05-30 22:44:58 Cogitri: 3.14 built with glibmm-2.68.1 2021-05-30 22:45:12 Cogitri: so if you did a downgrade we need to rebuild the dependencies i think? 2021-05-30 22:45:14 or maybe not 2021-05-31 07:04:12 Ariadne: No, the new glibmm changed the pkgconfig file name, so everything that expects glibmm2.4 should fail to build with the wrongly upgraded version 2021-05-31 08:14:21 ^^ yep, which is how I realized something was amiss (was building some things that required glibmm2.4, they failed) 2021-05-31 08:40:59 clandmeter: good morning. I think that dkms in alpine could be 'can of worms' 2021-05-31 08:42:23 we can package dkms program (I made apk when we talked about) apk and put it in aports, but left rest to users/admins 2021-05-31 08:43:08 imo, we should not make dkms files for particular drivers 2021-05-31 08:44:26 making all triggers, hooks, confs etc could become nightmare to maintain 2021-05-31 08:45:06 at the end, dkms is intended for 'end-users', not distro packagers 2021-05-31 08:45:10 I think we need automation to make dkms accessible, and without that there's no real point because most people (e.g. myself) don't have the time or inclination to learn how to make dkms go themselves. 2021-05-31 08:46:45 (the last time I built a kernel driver was back in the early 2000s, and it was because my wifi chipset needed one that wasn't mainlined yet.) 2021-05-31 08:53:14 Yup, if we want dkms we need triggers so that when a DKMS package is installed/updated via apk its automatically rebuilt 2021-05-31 08:57:05 Cogitri: and also triggers/hooks etc on kernel upgrade/install 2021-05-31 08:57:26 Yup 2021-05-31 08:57:45 too much hassles for not much benefit for distro 2021-05-31 08:59:15 imagine upgrading kernel on zfs root fs and then need to reboot and after reboot trigger build of zfs-dkms 2021-05-31 08:59:32 it is a huge benefit to users to do that because it means they don't have to remember to install the correct kernel/driver combinations. 2021-05-31 08:59:45 and at the end of the day, is a distro not about its service to users? 2021-05-31 09:00:13 no, it is a distro for developers 2021-05-31 09:00:31 
'developer' is just a particular kind of user. 2021-05-31 09:00:46 yes, and I'm user 2021-05-31 09:01:26 if I'm developing on Alpine, I want Alpine to take care of things that aren't explicitly related to what I'm doing. 2021-05-31 09:01:36 we should keep alpine for users who understand OS and/or willing to learn/hack 2021-05-31 09:01:57 Sheila: thats how debian did it, and thats part of how alpine got its users 2021-05-31 09:02:07 not for lazy ones 2021-05-31 09:02:59 for 'normal' users there are a lot better distros around, ubuntu, mint .... 2021-05-31 09:03:44 1. there are no lazy users. 2. this attitude is not one I want to be associated with because it's a form of elitism. 2021-05-31 09:04:22 The benefit of DKMS for the distro is that we do not have to maintain so many modules in lockstep with the kerngroep 2021-05-31 09:04:28 Kernel 2021-05-31 09:04:29 about 25 years I listen that linux is bad desktop OS and I use it for more than 25 years exclusively as my desktop os 2021-05-31 09:05:25 reality shows clearly that elite exists, but blind deny to see that 2021-05-31 09:05:47 I want to be very clear about this because, as a deaf-blind person, this attitude of "this distro shouldn't be for end-users" means accessibility tends to get left on the floor, and without accessibility *I cannot contribute*. 2021-05-31 09:06:43 Sheila: are you the brltty user? 2021-05-31 09:07:06 nero: no. can't use Braille; fingers aren't sensitive enough. 2021-05-31 09:07:29 nero: there are phones with brltty terminals ? (: 2021-05-31 09:08:04 Sheila: can you recommend something that works to screenread terminals? 2021-05-31 09:08:35 
probably, yes. VoiceOver and e.g. Terminal.app ;) 2021-05-31 09:09:03 (it's disappointing that Linux isn't a leader here, because it darn well should be.) 2021-05-31 09:09:07 apple :/ 2021-05-31 09:09:47 I'm not a huge fan of having appliances for computing, but until the free software ecosystem gets around to implementing the services I need
 2021-05-31 09:10:29 Sheila: when I wrote blind I used term figuratively, not real blind people 2021-05-31 09:11:05 nero: fwiw, my hearing is stable and I use hearing aids; my vision isn't, but still able to see well enough to not use a screen reader. 2021-05-31 09:11:39 
it just involves 24pt fonts and full-screen zoom because even Apple has forgotten the value of large unmissable targets for people to interact with. 2021-05-31 09:12:17 I think I enabled speech console driver in linux-edge 2021-05-31 09:12:54 Sheila: 24pt at 96dpi ? 2021-05-31 09:12:56 mps: I mean, I wasn't talking about my specific disabilities when I wrote my mini-rant earlier, I'm just a case in point. :) 2021-05-31 09:13:23 my work laptop has like, 200 dpi and i need 24th for normal vision, already 2021-05-31 09:13:31 * 24pt 2021-05-31 09:13:40 nero: not sure, all my displays are Retina Macs (M1 MacBook Air, 27" iMac) 2021-05-31 09:14:03 on my 165 dpi, I use 9 pt fonts 2021-05-31 09:14:56 and I can read 7 pt text quite fine 2021-05-31 09:14:59 default on the MBA is 'like' 1440x900, not on my iMac rn so can't look 2021-05-31 09:19:28 ok, to conclude, I can push dkms and let other interested to make particular dkms files 2021-05-31 09:19:49 and triggers/hooks etc 2021-05-31 09:20:12 sure. I don't expect you specifically to do all the work that needs to be done to integrate dkms 2021-05-31 09:22:47 i really dislike DKMS because it requires compiler and development tools 2021-05-31 09:23:21 its not noticable if you have a beefy machine, but very unfortunate if you dont 2021-05-31 09:23:24 yes, alpine-sdk complete 2021-05-31 09:24:09 there arent many distros left that can run from a 512 MB CompactFlash card 2021-05-31 09:25:14 yeah, I don't like that, but without some stable API that is guaranteed not to change between major releases I don't see how to avoid it. 2021-05-31 09:34:01 anyone knows why is python needed for libevent-dev? 2021-05-31 09:37:16 mps: event_rpcgen.py is part of that package 2021-05-31 09:39:12 yes, I see 2021-05-31 09:41:19 in particular, that tool is required to make use of libevent's RPC feature. 2021-05-31 09:42:40 this should be split to subpkg 2021-05-31 09:43:17 it's pity we don't have optdepends 2021-05-31 10:02:03 expected: "localhost" 2021-05-31 10:02:05 actual : "build-3-14-aarch64.local." 2021-05-31 10:02:12 tests that test the environment rather than the program :-/ 2021-05-31 11:37:09 i'm ootl here, why should we add dkms? it seems that we only have 6 out-of-tree module packages: https://pkgs.alpinelinux.org/packages?name=*lts&branch=edge&arch=x86_64 2021-05-31 11:41:16 Adding dkms would allow that number to grow and reduce the maintenance burden they impose 2021-05-31 11:42:34 There 'only' 6 because it increases the amount of work for ncopa maintaining the kernels 2021-05-31 11:43:02 So we are hesitant in adding more 2021-05-31 11:53:46 but how many do people actually want 2021-05-31 11:54:48 seems like arch only has 9 dkms packages: https://archlinux.org/packages/?q=dkms, and that's including nvidia-dkms 2021-05-31 11:55:03 Out of tree network drivers 2021-05-31 11:55:31 12 regular out-of-tree modules: https://archlinux.org/packages/core/x86_64/linux/ 2021-05-31 11:55:51 VirtualBox modules if the in-kernel ones do not suffice 2021-05-31 11:56:12 including vbox host and guest, and i think our vbox host package is still broken? 2021-05-31 11:57:33 i mean i don't really have an opinion on dkms either way but it seems to me like "there are too many modules to build" seems inaccurate. if the issue is "kernels are too hard to test", i feel we could target that issue more directly 2021-05-31 12:02:12 Hello71: right 2021-05-31 12:02:47 and I think it would be easier (and better) to keep current status 2021-05-31 12:04:22 and building out-of-tree modules is usually easy with just few 'make ; doas make install' commands, or simple shell scripts 2021-05-31 12:05:29 later I can post example for one such module 2021-05-31 12:05:51 macbook pro is out of battery 2021-05-31 12:07:21 But you need to remember to rebuild it when the kernel is upgraded 2021-05-31 12:08:13 ikke: thanks for reminding me (am I senile :D ) 2021-05-31 12:09:10 yes, ppl have to remember and understand what they are doing 2021-05-31 12:09:28 not blindly click, click ....... 2021-05-31 12:09:56 It's not just that 2021-05-31 12:10:25 ok, if you say so I will agree 2021-05-31 12:10:34 It's also about not having to deal with these things while you are trying to do other things 2021-05-31 12:13:31 I think you need to remember that, for most people, including most developers, the computer is an appliance. They don’t need or want to know the intimate details of how their operating system works, because the vendor that supplied it (that’s us distros, ultimately) do that work. 2021-05-31 12:15:14 Yup, it's nice when things just work 2021-05-31 12:15:17 I think it’s cool that we have the option of delving in to those details, and I think it’s necessary that people are able to do that, but it shouldn’t be mandatory to use the computer. 2021-05-31 12:15:42 It shouldn't be "magic" (as in hard to understand), but it shouldn't require the user to read the LFS manual to install ZFS :D 2021-05-31 12:20:51 And, again, I don’t appreciate the attitude that Alpine should only be for “hackers”, because that excludes *future* hackers. We want to encourage new people to contribute, and that means they need to be able to learn. “Oh they can just learn on Ubuntu”—how do you get them to Alpine from there? 2021-05-31 12:21:23 if the expectation is "should just work as the vendor supplied it", you should sek out debian, or better, redhat-based distros 2021-05-31 12:21:46 alpine is successful because it does not have all bells and whistles 2021-05-31 12:22:01 and i would assume this is also why its very popular in docker containers 2021-05-31 12:22:59 It’s successful because it’s easy to minimize, but many of the bells and whistles are there for people who want or need them. 2021-05-31 12:24:17 there are distros for people who want bells and whistles, and there are distros for people who do not 2021-05-31 12:24:29 if every distro becomes the same there is no point having multiple distros 2021-05-31 12:24:29 alpine is definitely the latter 2021-05-31 12:24:46 there is nothing wrong with having a niche distro with a clear mission statement 2021-05-31 12:24:57 I came here from Debian because I wanted minimalism 2021-05-31 12:26:03 these "future hackers" can cut their teeth on easier distros first 2021-05-31 12:26:23 I mean, I came here back in the day (some 10-12 years ago) because apt fucked me over and I didn't want to use fedora-based in a server environment. 2021-05-31 12:27:16 I think Alpine provides a solid foundation for many use-cases, and I think that we want to keep that going. 2021-05-31 12:27:25 there is nothing preventing a patchset or respin of Alpine to make it more user friendly 2021-05-31 12:30:20 anyway, this is a bit far afield of the original discussion, which was regarding dkms and that making use of it would make it easier to ship modules. 2021-05-31 12:31:39 the problem I have with 'all bells and whistles' distros is that the machinery to make all those bells and whistles work together makes it more difficult for the occasional hacker to customize 2021-05-31 12:32:10 keep things simple. 2021-05-31 12:32:16 agree. i hated ubuntu for the fact that i have to dig through the system to stop it from doing things i dont want 2021-05-31 12:32:31 "Small. Simple. Secure." 2021-05-31 12:33:09 In practice it means just having the bells and whistles that particular person cares about 2021-05-31 12:35:07 an Alpine respin for a specific user-oriented purpose is on my list of projects, so I'll eventually prove that such a thing is possible ;) 2021-05-31 12:35:25 there have been alpine respins before iirc 2021-05-31 12:37:39 AdĂ©lie for example 2021-05-31 12:38:51 AdĂ©lie isn't so much a respin as a parallel initiative with similar ideas 2021-05-31 12:47:36 bells and whistles doesn't go well with small and simple 2021-05-31 12:48:38 and that is what irritates me most about alpine, we don't know what is our goal 2021-05-31 12:49:39 and to add, I have all bells and whistles on my desktops with awesome wm 2021-05-31 12:49:54 I think the answer is layering 2021-05-31 12:50:26 so you can stick with the small and simple stuff if you want, but if you want bells and whistles, you can install them on top 2021-05-31 12:50:53 of course it requires a lot of discipline to keep the layers well-separated 2021-05-31 12:51:27 Yes, leaky abstractions and all 2021-05-31 12:51:40 that is something in line with my thinking 2021-05-31 12:52:34 some kind of simple and small, and add overlays for those who want to work on them 2021-05-31 15:36:36 Cogitri: ok great 2021-05-31 16:05:32 Cogitri: LFS manual is fine piece of manual fyi 2021-05-31 16:13:35 Piraty: that's as may be, but most people just want their shiny new computer to do what they tell it to. :) 2021-05-31 16:14:50 I'm destroying third keyboard repeating that these people should buy apple :) 2021-05-31 16:15:51 iphone have just one button because users can't learn to use two 2021-05-31 16:15:53 ah yes, people who want `apk add zfs` to DTRT should definitely use a different operating system. 2021-05-31 16:17:13 what next? shall we tell users who want to use rtl8821ce to use an OS that doesn't make them care about what kernel they're using? 2021-05-31 16:17:18 I'm sure you know that 'apk add zfs` is not enough to have zfs running and having FS ready, with no any action more 2021-05-31 16:17:50 and I'm sure that nitpicking the details is definitely a productive use of everyone's time. 2021-05-31 16:17:53 I think we have rtl8821ce in kernel 2021-05-31 16:17:58 if I want zfs, I install freebsd :p 2021-05-31 16:18:47 this 2021-05-31 16:19:03 there is old computer saying 'make os which idiot can use and only idiot will use it' 2021-05-31 16:19:42 there are also old computer people who want to keep the toys to themselves. should we appease them too? 2021-05-31 16:20:14 /o\ 2021-05-31 16:20:50 and can we please not imply that people who want to have kernel modules work without having to make sure the specific module they're installing is compatible with the kernel they're looking to use are idiots? because really
 2021-05-31 16:24:56 Even as an 'expert', it should be too much to ask to have something that just works 2021-05-31 16:25:15 not be* 2021-05-31 16:25:24 Let me put it this way. If I buy something with a chipset that has just come out of 'samples are available to systems builders', I know that I have to run windows on it, or suffer with experimental drivers. 2021-05-31 16:25:52 That is how the ecosystem works. Generally, after a year or so, a normal kernel works fine on it 2021-05-31 16:26:38 I think most of us are aware of that 2021-05-31 16:27:51 Having something like dkms allows experienced persons to share their solutions with others 2021-05-31 16:27:59 instead of everyone having to reinvent the wheel 2021-05-31 16:28:00 life is hard and require using brain, at least to some degree 2021-05-31 16:29:14 
 could we seriously knock it off with that shit? 2021-05-31 16:29:26 ikke: I mostly agree with you, but I think we should try to solve problems which we can solve in reasonable time and effort, not every problem 2021-05-31 16:30:08 mps: Isn't something like dkms doing just that? You provide a generic framework, that others can use to solve their problems? 2021-05-31 16:30:29 and potentially share 2021-05-31 16:30:39 ikke: yes, and because that I made dkms apk 2021-05-31 16:31:32 but I want to add that is not 'silver bullet' and it could become a 'can of worm' if we do not 'handle' this carefully 2021-05-31 16:32:22 yes, it's not perfect 2021-05-31 17:01:33 i don't really have any opinion on dkms, but note that dkms comes at the cost of having build-base and linux-lts-dev installed 2021-05-31 17:03:25 yes 2021-05-31 17:04:16 But if you have to compile these modules yourself, you have to have that as well 2021-05-31 17:33:48 Ariadne: yes, that is why I say dkms is not silver bullet for solving problem of the missing drivers 2021-05-31 20:59:39 ddevault: !21786 2021-05-31 21:00:20 omni: not signed in, but +1 2021-05-31 21:00:24 omni: are you interested in adopting that package? 2021-05-31 21:58:56 ddevault: I might. spontaneously yes, but I have some changes in life comning up so let me get back to you on that soon-ish 2021-05-31 22:03:06 ack 2021-05-31 22:37:44 WRT to dkms debate: Please do not paint distinctive features of the distribution as "elitism". It is perfectly normal to be different. This is the whole idea of freedom. I think that best solution to dkms debate is something of suckless/dwm nature: It should be relatively easy for those who want dkms to add it to their own installations, but this is not something that a distro should own/maintain. 2021-05-31 22:51:00 Can someone make this repository public ? https://gitlab.alpinelinux.org/kasperk81/aports 2021-05-31 23:51:07 ngortheone: agreed, and as noted, the pre-built modules are useful because you don't have to install hundreds of MB of stuff to get them. so, in practice, we will always have those kinds of modules anyway, but maybe dkms can be used to support less common ones. 2021-05-31 23:51:56 i would say something about nvidia-dkms here, but it does not seem relevant since alpine cannot use nvidia drivers anyway :)