2024-07-01 00:35:06 (nvm, left a MR mention, feel free to close if it's not okay ^^") 2024-07-01 06:08:37 for abuild, could i make .rootbld-repositories as a part of my abuild.conf 2024-07-01 06:09:47 i want to place APKBUILD outside ~/aports 2024-07-01 06:37:26 here is my issue: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10146 2024-07-01 09:13:07 sof-firmware ships open source binaries and currently simply repackages upstream binaries (it was this way when I adopted it) 2024-07-01 09:13:19 Is this against distro policy? Should the package build firmware from source? 2024-07-01 09:14:44 Yes, it should 2024-07-01 09:14:55 There are only few exceptions 2024-07-01 09:33:43 have fun building sof from source, it's not a good time 2024-07-01 09:33:56 requires some very cursed tooling 2024-07-01 10:58:51 do we know if musl is unaffected by CVE-2024-6387? 2024-07-01 10:59:18 at least it seems musl's syslog implementation does not call malloc like glibc 2024-07-01 11:06:19 The report only mentions glibc being vulnerable, but they did not rule out musl 2024-07-01 12:05:59 Good day! I wanted to ask if someone with push access has the time to take a look at the Nushell MR 2024-07-01 12:06:21 It seems that the MR is done, and everything is working now (well, barring the disabled plugin) 2024-07-01 14:56:04 Musl confirmed that sshd on musl based systems is not vulnerable to regreSSHion: https://fosstodon.org/@musl/112711796005712271 2024-07-01 15:03:59 wow 2024-07-01 15:37:44 Anyone else noticed that some tools stopped providing colored / rich terminal output? 2024-07-01 15:37:55 I first noticed it with docker compose, but now also with abuild 2024-07-01 15:38:06 (on 2 separate systems each) 2024-07-01 15:39:50 that would point to failing isatty() tests 2024-07-01 15:40:58 if [ -t 1 ]; then echo isatty; else echo isnotatty; fi prints isatty 2024-07-01 15:41:01 (which is what abuild uses) 2024-07-01 15:41:27 I would consider this a feature :p 2024-07-01 15:44:32 then idk, wrong terminfo definition? there are so many things that can go wrong, especially if you're using a GUI 2024-07-01 15:46:30 For abuild it seems to be the USE_COLORS variable which is not set 2024-07-01 18:34:46 someone with docker-alpine permissions could maybe take a look at https://github.com/alpinelinux/docker-alpine/pull/391? 2024-07-02 04:09:16 Hi. Does anyone have time to look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66494 Thanks! 2024-07-02 13:08:44 ikke: I responded; the first comment is waiting to be pushed. The second, I clarified my intent. 2024-07-02 13:09:53 ser1: context? 2024-07-02 13:10:07 If that makes sense to you, and it does what I think it's doing, then I'd like to leave it as is. Those scripts are due for a refactor and their own packages, but they're just utility scripts and not core to the functionality of the package. 2024-07-02 13:10:18 ikke: Sorry, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63562 2024-07-02 13:11:01 Hm. Can I just say #63562 ? or !63562 ? Is there a link bot? 2024-07-02 13:11:12 Guess not. 2024-07-02 13:30:03 hi all. I'm banging my head against this problem: https://tpaste.us/8MyR 2024-07-02 13:30:19 I'm trying to update obs-studio to the latest version 2024-07-02 13:30:21 30.1.2 2024-07-02 13:30:37 dependencies are met 2024-07-02 13:31:08 (mesa-dev), but I added also glu-dev 2024-07-02 13:41:02 ser1: MRs start with an ! 2024-07-02 13:41:13 !63562 2024-07-02 14:13:24 fcolista: I usually look at what the CMakefile does to find it 2024-07-02 14:13:45 i installed cmake and looked at the .h files he checks for 2024-07-02 14:14:04 the packages I've in the makedepends contains all that .h files :/ 2024-07-02 14:14:05 does it look for specific headers? or pkg-config? 2024-07-02 14:14:40 The CMAkeLists.txt you mean? 2024-07-02 14:14:44 let me check 2024-07-02 14:14:46 yes 2024-07-02 14:14:58 it sounds like bug in the cmakelists.txt file 2024-07-02 14:16:29 that's what I gues tto 2024-07-02 14:16:30 too 2024-07-02 14:16:49 https://tpaste.us/rjwE 2024-07-02 14:17:40 I don't understand Cmake.. 2024-07-02 14:58:46 the dirty secrets is that the CMake developers don't either 2024-07-02 14:58:51 secret* 2024-07-02 15:10:17 fcolista: pass -DOPENGL_opengl_LIBRARY=/usr/lib/libGL.so 2024-07-02 20:31:27 ikke: I think it looks good. https://wwwtest.alpinelinux.org/posts/2024-07-02-openssh-upgrade-edge.html 2024-07-02 20:31:39 I don't think it supports the 3 backticks 2024-07-02 20:31:49 There's an extra backtick in the output 2024-07-02 20:33:00 hum 2024-07-02 20:33:09 let me try with indent 2024-07-02 20:33:30 Was just working on that 2024-07-02 20:33:43 pushed 2024-07-02 20:33:44 ok, 2024-07-02 20:33:50 yeah, that's better 2024-07-02 20:34:23 but meh... it could look better 2024-07-02 20:34:27 I'll merge it anyway 2024-07-02 20:34:40 For another day 2024-07-02 20:34:49 i have been thinking of migrating the site to hugo 2024-07-02 20:34:55 but yeah, not today 2024-07-02 20:35:30 ack to push it from me 2024-07-02 20:35:34 pushed 2024-07-02 20:37:15 https://fosstodon.org/@alpinelinux/112718814916364554 2024-07-02 23:49:58 I fear people will be locked out and that maybe we should do a post-upgrade restart, if sshd is started, on upgrade from earlier versions 2024-07-02 23:51:25 s,people,more people, 2024-07-02 23:54:14 s,maybe,, 2024-07-03 00:51:14 !68589 2024-07-03 11:37:59 alice, it worked. Thank you! 2024-07-03 11:38:05 np 2024-07-03 11:48:40 Hi I have a few question regarding versioning of alpine. 2024-07-03 11:48:40 Fetch install packages ONLY from that snapshot (I guess the reverse of no-cache) 2024-07-03 11:48:40 First of all here is what I want to have (reasoning follows later): 2024-07-03 11:48:40 And most importantly to me, find the corresponding commit in the aports sourcetree since I apply patches to a few packages. 2024-07-03 11:48:40 For building a Docker image I want to get a snapshot of an alpine package index. 2024-07-03 11:48:41 I have run into trouble with this with the current openssh fiasco (since I apply patches to SSH). 2024-07-03 11:48:41 I have used the version of alpine reported in os_version to fetch the git tag. I didn't know this would not included hotfixes... 2024-07-03 11:48:43 I have already looked into the description file of the INDEX but I cannot find any reference for that hash in git :( 2024-07-03 13:43:44 Herdinger2: APKINDEX.tar.gz follows aports.git and commit hash of package would update 2024-07-03 15:18:22 Hello, has anyone been able to sign apks lately? I've been trying to sign one for the last week but haven't been able to due to something going wrong either during sig verification (with apk verify) or during signing (with abuild-sign) 2024-07-03 15:19:13 I suspect the issue might be with verification since I can't even build indexes for apks that aren't signed anymore 2024-07-03 15:19:58 RabidHeron: the builders are constantly signing packages, as is anyone who runs abuild -r 2024-07-03 15:26:04 ikke: then it's definitely something I'm doing wrong. Would it be alright if I post a link to a pastebin with a minimal example showing what's going wrong on my end in this chat? 2024-07-03 15:26:24 Sure 2024-07-03 15:40:08 #ikke: sorry it took so long, I wanted to be sure this doesn't work and had a lot to redact :D -> https://paste.centos.org/view/9641144d 2024-07-03 15:41:05 RabidHeron: does the filename of the key in /etc/apk/keys match the name as in the apk? 2024-07-03 15:42:08 It doesn't! I'll try that out 2024-07-03 15:43:24 I mean, the .pub extension is fine 2024-07-03 15:43:44 I see it's abuild.rsa and abuild.rsa.pub? 2024-07-03 15:46:24 Yeah! 2024-07-03 15:46:52 I've just tried it swapping "abuild" for "myapp" but that still results in the error 2024-07-03 15:47:16 what does tar tf myapp.apk return? 2024-07-03 15:48:02 .SIGN.RSA.myapp.rsa.pub \n .PKGINFO \n usr/ \n usr/bin/ \n usr/bin/otc-auth 2024-07-03 15:48:14 Sorry, I can't seem to do multiline here 2024-07-03 15:48:17 np 2024-07-03 15:48:25 the key should at least be called myapp.rsa.pub 2024-07-03 15:48:37 in /etc/apk/keys 2024-07-03 15:48:44 It is, I've checked 2024-07-03 15:49:38 Ah, I've leaked the program name xD 2024-07-03 15:50:02 I won't tell anyone, I promise 2024-07-03 15:50:23 Thanks, I appreciate it :D 2024-07-03 15:50:48 RabidHeron: maybe as a test, could you try to use abuild-keygen to generate a keypair and test with that? 2024-07-03 15:51:42 Sure! The docker image alpine:latest doesn't come with doas though, which seems to be required for the -i flag of abuild-keygen which shouldn't need it if you're root, by the way :D 2024-07-03 15:51:53 yeah 2024-07-03 15:52:00 you could use alpinelinux:build-base 2024-07-03 15:52:07 which both has a non-root user and has doas :) 2024-07-03 15:52:16 alpinelinux/build-base* 2024-07-03 15:52:56 https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/blob/master/overlay/usr/local/bin/setup.sh 2024-07-03 15:53:19 Awesome, thanks, I'll give that a shot! 2024-07-03 15:53:54 fyi, that's what our CI uses as well (with a thin layer on top for automation) 2024-07-03 16:06:09 Using that image I seem to have an issue finding the APKBUILD folder (sic: >>> ERROR: : Could not find ./APKBUILD (PWD=/home/buildozer)). Creating it in the home directory doesn't seem to help 2024-07-03 16:06:29 I think I'll switch back to the previous image to avoid troubleshooting something unrelated :D 2024-07-03 16:11:58 ikke: testing with the cert generated by keygen -a results in the same issue unfortunately 2024-07-03 16:14:19 Ah, it's the control.tar.gz that is signed 2024-07-03 16:14:38 (I'm not following 2024-07-03 16:14:42 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1860-1870 2024-07-03 16:16:32 The -q flag doesn't seem to be documented here https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers. Am I right in assuming that that sets the name of an output file? 2024-07-03 16:16:34 So what happens is that apk creates a control.tar.gz, signs that, then creates the actual apk 2024-07-03 16:17:20 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-sign.in#L88 2024-07-03 16:18:01 Ah right, sorry, it's been a long day :) 2024-07-03 16:20:04 Is there a specific reason you are separately signing the apk file? 2024-07-03 16:20:11 Correct me if I'm wrong but is that function not used when using abuild to create an apk? And not during the signing process? 2024-07-03 16:20:21 Yeah, the apk is built with another tool (goreleaser) 2024-07-03 16:22:08 if you use goreleaser, you must also know nfpm? 2024-07-03 16:22:33 Vaguely! goreleaser should use that under the hood if I remember correctly 2024-07-03 16:22:53 Yeah, probably 2024-07-03 16:23:00 it supports specifying a signing key 2024-07-03 16:23:11 https://nfpm.goreleaser.com/configuration/?h=sign 2024-07-03 16:26:19 Right! My end goal is to have a package of apks built and signed though. As far as I can see, goreleaser can sign apks but not packages, which would necessitate running another abuild-sign step anyway :) 2024-07-03 16:26:36 what's the differences between apks and packages? 2024-07-03 16:27:02 Sorry "package" was wrong, "index" is probably better 2024-07-03 16:27:31 I'm referring to the output of: apk index -o APKINDEX.tar.gz *.apk 2024-07-03 16:27:36 yes, index indeed 2024-07-03 16:27:48 Thanks for the correction 2024-07-03 16:28:30 Here you see how the index is created: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1933-1936 2024-07-03 16:28:54 And there you see abuild-sign is directly used 2024-07-03 16:29:02 on the index, I mean 2024-07-03 16:29:44 The --rewrite-arch is important if you have packages with noarch 2024-07-03 16:29:52 Right! 2024-07-03 16:30:20 But with regards to my current approach, can you see anything wrong with it? 2024-07-03 16:30:56 Like I said, you must sign the control.tar.gz file, not the apkfile itself 2024-07-03 16:31:07 and then use abuild-tar to create the archive again 2024-07-03 16:31:18 (The format is a bit bespoke) 2024-07-03 16:31:52 Alright, thanks, I'm not very familiar with this process so I've got some reading to do :D 2024-07-03 16:32:14 Thank you for your help so far! Do you have an online tip jar somewhere? 2024-07-03 16:32:22 So thats why I suggested making sure the apk was already signed when creating it 2024-07-03 16:33:00 For interest's sake, do apks now need to be signed for indexes to be made for them? I remember that not being the case previously 2024-07-03 16:33:55 Don't think anything changed regarding that recently 2024-07-03 16:37:14 Weird, I've got a CI run from 6 months ago where apk index worked fine on a collection of unsigned apks, but doesn't afterwards. I'll look into this and let you know if I find anything 2024-07-03 16:37:57 Either way, thanks for your time! 2024-07-03 16:38:11 np 2024-07-03 21:00:10 Any specific reason why mesa is build with debug + O2 instead of release profile (no debug + O3)? 2024-07-03 21:02:08 oh I see.. it is switched to plain mode.. anyway, by default mesa is build with O3, so I would recommend to following this default 2024-07-04 03:42:43 for some time I think it was compiled with -Os, lol 2024-07-04 03:43:57 it crashes enough that it's worth keeping debug symbols around. does O3 actually help mesa performance? I feel it should be not very vectorizable, and full of indirect/cross-TU calls which can't be inlined anyways 2024-07-04 03:58:32 maybe its not the case anymore, but my feeling is the most complier optimizations you use for mesa the more likely you run into bugs only one person can reproduce 2024-07-04 03:58:43 -O2 is generally safe 2024-07-04 04:00:29 DavidHeidelberg: many distros want debug info so they can create debug info packages for their users 2024-07-04 06:27:57 do we hav any abuild helper tu split -doc subpackages into smaller -doc subpackages? 2024-07-04 06:35:29 No, except amove 2024-07-04 06:40:46 ncopa, ikke, what is the status of CVE-2024-6387 aka OpenSSH race condition in Alpine? I don't see patches in aports tree. 2024-07-04 06:41:07 ok, thx ikke 2024-07-04 06:41:34 I know that RCE is not demostrated against non-glibc systems, but I guess we want to have it fixed anyway 2024-07-04 06:42:10 debian/ubuntu have patches: https://git.launchpad.net/ubuntu/+source/openssh/tree/debian/patches/CVE-2024-6387.patch?h=ubuntu/jammy-updates 2024-07-04 06:43:24 ok just finished reading backlog, saw ikke comments on musl 2024-07-04 06:44:28 rnalrd: https://security.alpinelinux.org/vuln/CVE-2024-6387 2024-07-04 06:50:38 great, tnx 2024-07-04 06:54:10 rnalrd: stable branches do have patches 2024-07-04 06:54:19 Edge was upgraded to latest release 2024-07-04 06:58:25 yes, sorry for noise, i was looking at an out of sync local tree :') 2024-07-04 06:59:51 Aha 2024-07-04 08:05:57 Looks apache2 also needs new fix for CVE-2024-39884 2024-07-04 09:23:00 im on it 2024-07-04 09:33:38 somehow elastic-beats fails only on builder as upgrade passed in CI, maybe disable it to upload golang updates? 2024-07-04 13:07:15 Would someone mind looking at !66890? Thanks! 2024-07-04 13:12:48 Kladky: > Assignee @mpolanski, and he's not fond of merging MRs to packages he maintains without approval 2024-07-04 13:13:19 Ah ok, that makes sense. 2024-07-04 14:06:40 I wonder what we should do with !62487 vs !66756 2024-07-04 17:45:01 Is it okay to introduce a new aport (community/hyperlink) into 3.20? 2024-07-04 17:45:37 (I mostly want to use it in downstream pipelines that use 3.20) 2024-07-04 18:06:17 Hey ikke, thought I'd swing by to say thanks! I re-read our chat yesterday and your suggestion to use nfpm to just sign the apks first was spot on! 2024-07-04 18:07:07 RabidHeron: nice 2024-07-04 20:28:58 Any suggestions on getting movement to resolve Issue https://gitlab.alpinelinux.org/alpine/aports/-/issues/16261 ? The package maintainer has been unresponsive, so is there another community member that can approve these package upgrades? 2024-07-04 20:41:25 For context, a new synapse version is released every 3-4 weeks and the last version in Alpine is from April 2024 & the latest version was released yesterday/ 2024-07-04 21:08:00 ptrc: i think wasi-sdk 22 should target clang18? (i.e. bump _llvmver to 18). but likely it just needs to depend on clang18 2024-07-04 21:09:30 or if it is determined that it works with both, then i guess both toolchain config files need to be included. 2024-07-04 22:10:19 ouh, no, it should be the default llvm 2024-07-04 22:10:24 ovf: thanks for noticing this! 2024-07-04 22:14:31 ptrc: thanks! i still can't make up my mind whether wasi-sdk should depend on clang. it does have some very marginal utility without it, but if you treat it as the metapackage that installs whatever is required to build for wasi, it probably does need to pull in clang... 2024-07-04 22:18:15 ptrc: but much more pertinent wasi-sdk 22 brings in wasi-libc 9e8c542 2024.04.12 2024-07-04 22:18:28 currently we call it '22' but it isn't 2024-07-04 22:20:15 yeah that commit is wrong 2024-07-04 22:21:37 yeeah i now realize that i didn't quite think it through 2024-07-04 22:22:06 alice: should all wasi- stuff be put in a single package? it's not like they're usable separately and evidently currently there are too many moving parts 2024-07-04 22:22:43 i dunno, they all build separately so it seems fine as is 2024-07-04 22:22:46 and -sdk installs them all anyway 2024-07-05 08:48:04 Has pythonhosted stopped providing package archives via "https://files.pythonhosted.org/packages/source/${_pyname:0:1}/$_pyname/$_pyname-$pkgver.tar.gz"? 2024-07-05 08:56:23 does the package have - or _ in its name? if so try s/-/_/ or s/_/-/ 2024-07-05 08:59:46 Yes, sphinx-click. I'll try that. 2024-07-05 09:12:15 Worked. Thanks! 2024-07-05 10:25:16 Anyone else using dabuild for python packages finding it's failing with unmet dependencies? 2024-07-05 10:26:10 https://paste.debian.net/1322393/ 2024-07-05 10:26:20 The same package builds just fine with the CI containers. 2024-07-05 10:27:16 The container it's using is 'registry.alpinelinux.org/alpine/docker-abuild:edge' 2024-07-05 10:27:27 Sorry, that's the container dabuild is using. 2024-07-05 10:29:31 "WARNING: opening from cache http://dl-cdn.alpinelinux.org/alpine/edge/main: No such file or directory" 2024-07-05 10:29:45 I'm not using dabuild, though 2024-07-05 10:31:45 Last commit to the dabuild git repo was over a year ago. 2024-07-05 10:34:27 The image is regularly rebuilt, though 2024-07-05 10:37:47 It hasn't worked for me for my packages for a couple of months I think. 2024-07-05 10:47:18 adhawkins: do you have DABUILD_DISTFILES set? 2024-07-06 14:32:42 Did newest qemu upstream disable io_uring? libvirt reports the newest version doesn't support io_uring 2024-07-06 14:36:54 If yes, wouldn't it be good to re-enable it? Kinda surprised a feature i used just, disappeared... 2024-07-06 14:37:54 may be equivalent to https://github.com/chimera-linux/cports/commit/c5d29e34a6bdd4a320508a8cb092a7444a0fe466 2024-07-06 14:57:14 it's a new liburing issue 2024-07-06 14:57:29 in the sense of including the header without -D_GNU_SOURCE will fail 2024-07-06 14:57:35 im not sure what the correct fix is 2024-07-06 14:58:01 i guess if they put -D_GNU_SOURCE in liburing.pc it would fix it 2024-07-06 14:58:16 but i'm not sure if projects normally do that 2024-07-06 14:58:25 yeah... 2024-07-06 14:58:33 seems they dont 2024-07-06 14:58:41 and on glibc default_source pulls it i think, so.. 2024-07-06 15:34:58 hmm, so what version can i rollback to that doesn't have that issue? 2024-07-06 15:44:34 should just apply that patch and fix the issue 2024-07-06 15:44:44 ptrc: quick fix for u ^ 2024-07-06 15:44:48 think it's 3.20 too 2024-07-06 15:45:10 👀 2024-07-06 23:30:50 i've seen instances of BOOTSTRAP, APORTS_BOOTSTRAP, and ABUILD_BOOTSTRAP in some APKBUILDS. trying to understand the differences and also noting that where BOOTSTRAP is used in an APKBUILD, it does not seem to be doing what the APKBUILD author expected. the idiom `[ -n "$BOOTSTRAP" ] && options="!check"` does not get applied from what I can tell. 2024-07-06 23:32:16 ABUILD_BOOTSTRAP is checked by want_check(), so that much seems understandable so far. 2024-07-06 23:34:34 what seems weird to me is that if I add a statement like `[ -n "$BOOTSTRAP" ] && something`, something never runs even if i export BOOTSTRAP set to something, where as APORTS_BOOTSTRAP works as expected. 2024-07-07 00:34:39 weird 2024-07-07 01:42:05 ok, sorry for the noise, didn't think to check in ~/.abuild/abuild.conf 2024-07-08 13:54:30 Are there any plans to integrate repology into the outdated package marking for the repo? It seems to have more projects than the fedora package stream so it might notify earlier. 2024-07-08 13:55:00 Alternatively, how do fellow package maintainers stay up to date with releases without going through every mailing list/git repo? 2024-07-08 13:55:19 I can't afford to keep an eye on every package i mantain just to see if it's the newest 2024-07-08 14:03:51 caskd: I personally use a homebrewed little shell script that scrape my locally git cloned aports for APKBUILDs where I'm listed as the maintainer/contributor and then fetches the RSS feed using from where ever we have the source pointed to. 2024-07-08 14:04:19 It's by no means a perfect system, but out of about 120 packages it massively reduces the amount of work I have to do manually checking things 2024-07-08 14:05:11 https://lambdacreate.com/posts/55 <- there's an early example of that script here, it's grown a bit since I wrote this post 2024-07-08 14:37:17 The rss feed idea is great 2024-07-08 14:37:32 considering i can just mirror stuff to my git instance and get a feed of the tags there 2024-07-08 14:37:42 thanks 2024-07-08 15:12:24 caskd: repology has a lot of false-positives, and i personally wouldn't want to carry those into alpine as well 2024-07-08 15:12:47 especially since with fedora, i can just ping the right person on IRC or change it myself, but with repology i have to argue with one guy who's very stubborn about certain things 2024-07-08 15:13:17 https://ptrc.gay/gUgDMLpr 2024-07-08 15:19:07 oh, didn't know that 2024-07-08 15:19:18 thanks for letting us know 2024-07-08 15:26:31 just a low-tech method here, rss reader + repo feeds 2024-07-08 15:27:35 yeah i just set up that 2024-07-08 15:27:45 seems to be most painless out of them all and uniform 2024-07-08 15:42:21 second what ptrc says with repology. It's a nice tool, but it doesn't really cut it in my experience 2024-07-08 18:54:03 I'm trying to force sddm to use utmps. So far I'm failing to make it to link with libutmps and libskarnet because cmake puts contents of LDFLAGS environment variable, which contains -lutmps -lskarnet, too early, so linker doesn't pick up functions from these libraries. Does cmake have another environment variable that could solve this problem? 2024-07-08 18:57:04 no, you have to use target_link_libraries in cmake 2024-07-08 18:58:38 sadge 2024-07-08 19:15:49 sigh, as with every single Firefox release, someone again flagged the Firefox version with a not-yet-released one 2024-07-08 19:25:12 is released 2024-07-08 19:25:29 where 2024-07-08 19:25:34 tarball exiss 2024-07-08 19:25:44 same way thunderbird 127 is released then 2024-07-08 19:25:48 ( not ) 2024-07-08 19:25:49 fo sho 2024-07-08 19:25:55 pls update 2024-07-09 06:18:04 What are the main blockers from having apk3 in Alpine? 2024-07-09 06:23:03 I wonder if something like Argus ( https://release-argus.io ) could be of use for tracking versions 2024-07-09 06:42:28 PureTryOut: its on the roadmap for 3.21 but no details yet 2024-07-09 06:42:55 Hmm ok, looking forward to it 2024-07-09 06:43:59 iggy: we have a bot connected to Anitya (https://release-monitoring.org) which will send an email when a new version of a package you maintain is detected. It does require mapping of the package to the Alpine name but that's fairly easy to do 2024-07-09 06:44:12 we discussed it last week on the tsc 2024-07-09 06:44:45 Good to hear! 2024-07-09 06:46:35 it would be nice if we would have an alternative for anitya, or at least an alternative implemention away from pkgs.a.o 2024-07-09 06:47:22 its also one of the show stoppers for apkv3 2024-07-09 06:49:09 it would be nice to switch to the python version of the package browser and have a seperate program to track versions. it can use the same db if needed. 2024-07-09 07:08:44 the Python version the one being Martijn made and postmarketOS and Chimera use? Agreed, that would be nice 2024-07-09 07:09:09 we have an implementation of Anitya in pmbootstrap which Luca Weiss made, we could probably write something separate from it 2024-07-09 07:13:37 the chimera is already v3 compatiable iiuc 2024-07-09 07:13:57 They use apk3 so yes 2024-07-09 07:14:43 PureTryOut: can you point me to the anitya implementation you use? 2024-07-09 07:15:09 btw this is also useful :D https://github.com/z3ntu/dotfiles/blob/master/scripts/usr/local/bin/check-alpine-packages-on-anitya 2024-07-09 07:16:02 this is the implementation in pmbootstrap: https://gitlab.com/postmarketOS/pmbootstrap/-/blob/master/pmb/helpers/aportupgrade.py#L182 2024-07-09 07:16:41 nothing too interesting really, but it also handles packages without a direct mapping on anitya, so just matching based on pkgname since when I wrote this basically no package had a mapping and adding them if the name is the same is quite tedious 2024-07-09 08:44:02 z3ntu: how does it handle version comparison? 2024-07-09 08:44:11 we use gentoo style versioning 2024-07-09 08:45:09 just simple equals.. works well enough for the use case I had back when I wrote this 2024-07-09 08:45:12 ACTION sent a code block: https://matrix.org/_matrix/media/v3/download/matrix.org/KVPJmHtUZLBoZNlONeWwhLjs 2024-07-09 11:14:32 z3ntu: thats not version comparison but string comparison 2024-07-09 12:20:51 which is a very barebones version comparison yes 2024-07-09 17:59:55 I haven't followed it closely yet but what is the current status of the loongarch64 port? we have a builder already, right? but the packages are not yet uploaded to the mirrors? 2024-07-09 18:00:09 correct 2024-07-09 18:00:25 They are uploaded to dev.a.o/edge for now 2024-07-09 18:00:40 They are going to ship servers to the EU 2024-07-09 18:02:10 cool! where do I find the signing key? 2024-07-09 18:02:31 I want to debug a check() failure on loongarch64 via rootbld 2024-07-09 18:11:26 I believe https://dev.alpinelinux.org/~loongarch/edge/main/loongarch64/alpine-keys-2.5-r0.apk contains them 2024-07-09 18:16:40 is there a reason why we don't ship them in the standard alpine-keys package yet? unless they are in /etc/apk/keys they are not used for signature verification anyhow, right? 2024-07-09 20:52:02 MR !67090 went stale today. Could someone take a look at it see if there is anything else I need to do? 2024-07-09 20:54:57 also !67559 still has the mr-changes-requested flag, though the issue was resolved, though perhaps there was something else 2024-07-09 22:01:18 Where the default set of openrc services is defined? 2024-07-09 22:11:49 I propose adding klogd to that set 2024-07-10 01:45:31 fcolista: Hi fcolista, can you help review this !68984? gsa has blocked the loongarch64 builder 2024-07-10 01:45:43 tomalok: containerd also blocks loongarch64 builder !67125 2024-07-10 01:45:47 Thanks 2024-07-10 06:40:48 fcolista: hi, could you please review this MR !69014? thanks 2024-07-10 06:56:54 tomalok: I just updated !67125, please help check it again 2024-07-10 06:57:05 Thanks 2024-07-10 08:02:57 fcolista: Can you also help check this MR !68548 ? 2024-07-10 08:14:23 fcolista:Oh,sorry,py3-oscrypto is assigned to @nmeum 2024-07-10 08:14:48 I can take a look later today :) 2024-07-10 08:15:10 Ok,thnak you 2024-07-10 08:15:36 would be cool to figure out why check() is failing, wanted to setup a qemu loongarch vm anyhow to debug some other check() failures so if you don't have the time I might be able to look into it as well 2024-07-10 08:35:44 If you have time to look into it, that would be great, I really haven't had time to look into it recently 2024-07-10 08:35:48 but I think it's not just failing on loongarch64, other architectures are also reporting errors, but CI doesn't prevent it 2024-07-10 08:36:50 nmeum:see https://gitlab.alpinelinux.org/huajingyun01/aports/-/jobs/1448669 2024-07-10 08:40:40 oh, that's not good. I will look into fixing it, thanks! 2024-07-10 08:42:38 Yes,thanks! 2024-07-10 09:09:45 ikke: I'm wondering about spam in https://gitlab.alpinelinux.org/Cogitri/apk-polkit-rs/-/issues/19 Is there some repo where we can denylist users? 2024-07-10 09:09:52 Or just ignore it? 2024-07-10 09:36:38 PabloCorreaGomez[m]: we delete spam-only accounts including content 2024-07-10 09:37:02 I also have a spam filter, but I need to look into that 2024-07-10 09:57:44 Ok, thanks! 2024-07-10 16:31:52 Hi people, I'm trying to fix https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68499 and wondering if 'abuild-meson' sets the optimization level to 0 by default (or if it generates pyc files) it fails creaint -pyc subpackage 2024-07-10 16:32:15 according to 'abuild-meson --help' says "Whether to compile bytecode (default: (-1, 2, 0))." 2024-07-10 16:32:35 No idea about how to interpret that default 2024-07-10 16:35:36 hmm.. https://tpaste.us/Z5l6 2024-07-10 16:35:45 python.bytecompile: 0 2024-07-10 16:35:51 but I can't find any pyc file 2024-07-11 12:35:13 hi all, how are generated new docker images? 2024-07-11 12:37:41 actually how are generated alpine-minirootfs archives 2024-07-11 12:39:02 using this - https://github.com/alpinelinux/alpine-make-rootfs/blob/master/alpine-make-rootfs ? 2024-07-11 13:00:20 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.minirootfs.sh?ref_type=heads 2024-07-11 13:34:39 ikke, thanks 2024-07-11 18:15:49 PureTryOut: now that sddm supports utmps upstream, should I backport it? 2024-07-11 18:40:05 If you need the support, sure. Tbh I'm not sure what it utmps does 2024-07-11 19:16:55 it provides utmp api for accounting logged in users. musl itself doesn't implement it 2024-07-12 06:20:51 I thought it was obvious that I don't know what utmp is 🙈 2024-07-12 06:41:21 PureTryOut: it keeps track of who is logged in on a system 2024-07-12 06:49:51 it is what the command `who` uses to list who is currently logged in 2024-07-12 11:04:13 Interesting, thanks! 2024-07-12 11:37:50 if someone has time, !67468 has gone stale, but has the maintainer's ok 2024-07-12 12:56:53 Good day. If a community package is outdated, is it just a case of flagging? I'd like to contribute - update the package - if a maintainer needs assistance. Is there a protocol? 2024-07-12 13:19:01 If it's a simple package, setting up abuild and running abump packagename-X.y.z then submitting a pull request with those changes should be enough, otherwise it might require some technical changes. 2024-07-12 13:20:30 The repository where you can submit the requests is https://gitlab.alpinelinux.org/alpine/aports and this wiki page contains additional info https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers#Bumping_a_package_version 2024-07-12 13:28:01 Thanks, that's exactly the pages I'm following, so I'm on track. It's a simple revision bump - hopefully :D (famous last words). I'll do some noodling with the tools, and hopefully a pull request will pop out the other end :) 2024-07-12 14:55:00 Ok, that was genuinely more pleasant experience than I expected! https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69153 2024-07-12 19:26:39 caskd: re version tracking: im using nvchecker (https://github.com/lilydjwg/nvchecker), it manually checks git tags, or versions at pypi/npm 2024-07-13 05:47:34 fossdd: thanks! 2024-07-13 16:56:50 Pytest plugin to check importability of modules: https://github.com/mgorny/pytest-import-check 2024-07-13 16:57:05 Usecase is to test python packages that don't have an extensive test suite 2024-07-13 17:11:32 So one needs to add it to checkdepends and run pytest --import-check? 2024-07-13 17:17:57 https://social.treehouse.systems/@mgorny/112780214884335980 2024-07-13 18:23:22 thats really cool 2024-07-14 01:38:32 If I want to make an aport foo whose installed files are all moved to subpackages foo-bar or foo-baz, can I convince abuild to only generate foo-bar.apk and foo-baz.apk and not generate an empty foo.apk ? 2024-07-14 01:40:50 Specifically, I'm trying to split community/callaudiod into callaudiod-daemon and callaudiocli packages via this APKBUILD https://paste.rs/FeN70 which generates those two subpackages fine, but also generates an empty callaudiod-0.1.9-r1.apk that has no files 2024-07-14 02:32:31 Okay, I found community/docker has the same situation and it too generates an empty docker.apk, so I guess it doesn't matter 2024-07-14 03:50:50 Arnavion: the $pkgname package should then depend on both subpackages, that they're still installed by apk add $pkgname 2024-07-14 03:55:58 I just merged -daemon back into the main package because that works just as well wrt my original goal (being able to replace callaudiod with a different package that provides=callaudiod while still keeping callaudiocli) 2024-07-14 15:15:37 fcolista: can you please have a look at the mate MR when you have a moment and let me know if you require anything for the MR to proceed? thanks https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68751#note_418931 2024-07-15 00:56:32 Hi, would someone please take a look at this MR for wmenu? Corresponding version update has already been merged in master. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/67572 2024-07-16 03:16:54 there are patches in aports, why some of them appear in distfiles.a.o 2024-07-16 03:18:11 e.g 0001-Make-use-of-libusb-package-optional.patch 2024-07-16 03:20:01 oh i see, only remote patch here, local patch are old caches :) 2024-07-16 05:02:53 Yesterday we were MR neutral :) 2024-07-16 07:30:22 congrats! 2024-07-16 07:30:30 \o/ 2024-07-16 07:30:49 i want to thank all the people who take time to review and manage aports and submit packages :) 2024-07-16 07:30:59 you're the real unsung heroes 2024-07-16 07:32:45 indeed. thank you all! 2024-07-16 07:45:09 FTR, recently we merge more MRs then are opened, but yesterday the amount was exactly the same 🙂 2024-07-16 07:51:56 how does apk decide whether a config file is "potentially edited", and write a .apk-new? 2024-07-16 07:57:40 Apk keeps track of the hash/signature of each installed file 2024-07-16 07:58:01 /lib/apk/db/installed 2024-07-16 08:00:44 hash, great, thanks 2024-07-16 08:00:46 that's what i hoped 2024-07-16 09:11:38 gitlab unhappy? 2024-07-16 09:11:46 or just the github oauth integration? 2024-07-16 09:13:46 ok, it's not github oauth, but /merge_requests/new/ is unhappy about something 2024-07-16 09:33:51 Do you receive a 500 response? 2024-07-16 09:34:03 yes 2024-07-16 09:34:08 after quite a while 2024-07-16 09:34:23 You pushed to 2024-07-16 09:34:25 pdns-recursor-5.1.0 2024-07-16 09:34:27 at Peter van Dijk / aports 55 minutes ago 2024-07-16 09:34:33 clicking [Create merge request] causes the 500 2024-07-16 09:34:45 (as did the MR URL gitlab gave me in my terminal when i git pushed the branch) 2024-07-16 09:35:45 Trying to make an mr against a stable branch? 2024-07-16 09:35:51 no, master 2024-07-16 09:35:52 it works now 2024-07-16 09:35:55 after i synced master on my fork 2024-07-16 09:36:02 not sure why that helped 2024-07-16 09:36:25 MR made 2024-07-16 09:36:29 Gitaly timing out for some reason if there is a lot of commits in between 2024-07-16 09:36:48 my master was 436 commits behind 2024-07-16 10:32:58 my second MR of the day went better 2024-07-16 11:01:20 https://www.hashicorp.com/blog/installing-hashicorp-tools-in-alpine-linux-containers 2024-07-16 11:01:22 lmao 2024-07-16 11:01:27 > Learn the installation and verification workflow for any Linux distribution that does not include HashiCorp software in its package repository. 2024-07-16 11:02:00 they conveniently leave out *why* Alpine doesn't include HashiCorp software in the package repository 2024-07-16 11:04:26 they could provide a repo, right? 2024-07-16 12:56:05 ptrc: i see in the forgejo templtae that the frontend is built in addition to the frontend, what's the point of that? 2024-07-16 12:56:40 if i'm understanding this correctly, it's only the go binary and a couple other files from alpine that are installed 2024-07-16 13:39:00 Maybe we should merge virtualbox and virtualbox-guest-additions packages 2024-07-16 14:00:43 > frontend is built in addition to the frontend 2024-07-16 14:00:46 triallax: what do you mena 2024-07-16 14:00:47 mean* 2024-07-16 14:24:35 I meant frontend in addition to the backend, ie the actual forgejo binary 2024-07-16 14:24:43 the former being the node stuff 2024-07-16 15:57:21 it's embedded into the binary 2024-07-16 16:01:26 where do you even see it being built 2024-07-16 16:01:34 npm ci isn't a build command 2024-07-16 16:02:18 (though build does build the frontend with npm stuff) 2024-07-16 16:03:43 I did notice some directories being created in the package() function that do not end up in the package 2024-07-16 18:34:56 alice: I wasn't talking about npm ci 2024-07-16 18:35:11 if you check the makefile it's the frontend target 2024-07-16 18:35:31 like you mention I guess 2024-07-16 18:35:34 yea 2024-07-16 18:36:08 well you can technically build backend only and load it later separately, but it's more convienent to just goflags+=bindata and have it embedded 2024-07-16 18:36:30 also trivial to build so whatever 2024-07-16 18:36:59 yea 2024-07-16 18:39:21 OK thanks for the answer 2024-07-16 18:54:30 if you're bored: apk add linux-openpax@testing; please report any packages which are missing PaX markings to the tracker. add missing PaX markings with paxmark(1); apk add paxmark 2024-07-16 19:07:29 > WARNING: The repository tag for world dependency 'linux-openpax@testing' does not exist 2024-07-16 19:09:52 assumes you added edge/testing as pinned repo 2024-07-16 19:31:48 Ah, so that's how tags work 2024-07-16 20:09:59 !69311 fixes issues arising from pyqt as an fyi. Required bump to work with the Qt update. 2024-07-17 11:15:10 i'm working on lua-aports, fixing the weird behavior where it tries to build things it shouldnt 2024-07-17 11:15:25 are there other know bugs or issues with lua-aports? 2024-07-17 13:21:00 Maybe related, but we noticed that builddirs returns any package that provides the specified name 2024-07-17 13:21:21 yeah, im fixing tht 2024-07-17 13:25:48 more important: im adding enough tests that im confident enough to update to lua 5.4 :) 2024-07-17 16:46:37 heads up! i'm pushing lua-aports update now, with lua 5.4 2024-07-17 17:17:36 Does somebody know if there's anything which could compute a checksum/fingerprint of a elf object ABI? If yes, are there any plans to try to implement something like that in abuild/apk? 2024-07-17 17:18:03 It would seem like a difficult yet really useful problem to solve 2024-07-17 17:22:30 Not aware of anything 2024-07-17 17:22:42 closest is https://abi-laboratory.pro/, but that seems to be down atm 2024-07-17 17:22:53 It's not checksum based though 2024-07-17 17:23:52 Yeah, i had some very interesting stuff that forced me to rollback to stable after mixing edge and stable, so i was wondering if it would be possible to pin deps not only based on so version but also on a ABI "fingerprint" 2024-07-17 17:39:02 ilbabigail can do it too, I think 2024-07-17 17:39:04 *lib 2024-07-17 17:40:28 if you upgrade to my premium plan 2024-07-19 07:15:06 I'm likely asking a noob question: Is there a link for the timeline for the next release? Context: I wonder if backporting !67391 is still needed, or if waiting for the next release to ship the fix is acceptable. 2024-07-19 07:19:35 maribu: releases are always around May and November 2024-07-19 07:22:26 OK, a backport it is then, I guess :) Thx for info! 2024-07-19 09:41:40 What do you use to track CVEs? 2024-07-19 09:50:12 Hello, I was just wondering whether there's a way to specify the location of the "chroots" for bubblewrap when using rootbld? 2024-07-19 09:55:25 Ermine: https://security.alpinelinux.org/ 2024-07-19 10:01:33 no games on sortix? 2024-07-19 10:04:47 oops, ECHAB 2024-07-19 10:04:50 ECHAN 2024-07-19 10:10:09 ikke: I think I'm looking for something that could mail me something like "Here's a new CVE on a package you're following". I'm not sure that security.a.o is something I look for 2024-07-19 10:16:42 Ermine: If there would be any system like that, it would be security.a.o, but it has no notifications (yet) 2024-07-19 11:59:03 how to deal with broadcom wifi bcm43228 ? 2024-07-19 12:00:56 i was thinking if modloop had an empty folder /lib/firmware/b43 , then i could mount in theory external firmwares onto it without having to redo sfs file 2024-07-19 12:17:29 currently my knoppix handles it via "wl" module 2024-07-19 14:00:58 Is that the thing that requires the fwcutter? 2024-07-19 14:21:36 yes 2024-07-19 16:20:40 Maybe it's worth including /etc/mactab support in default mdev.conf? 2024-07-19 16:20:49 Seems usefull enough 2024-07-19 17:19:47 redoing modloop with added b43 folder works (wifi on), will try to get suggest again on monday 2024-07-19 19:21:56 If anyone is interested, here's the answer/solution to my question: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/302 2024-07-20 08:57:27 linux-lts kernel defaults to 'powersave' governor which is odd. Is that to be expected? 2024-07-20 09:13:25 yes, that's what intel_pstate does 2024-07-20 09:15:51 It can be configured via Kconfig options 2024-07-20 09:16:05 What I mean is that other distros tend to default to performance or schedutils 2024-07-20 09:16:22 Because it have a great impact on, well, performance 2024-07-20 09:16:44 Given that linux-lts is general kernel for desktop/servers I think it makes sense to do that too 2024-07-20 09:16:55 Or am I mistaken and it's not the main goal here? 2024-07-20 09:17:22 other distros do powersave too 2024-07-20 09:17:49 because it gives good balance between power consumption and performance 2024-07-20 09:18:11 and you're free to change the governor at runtime 2024-07-20 09:21:44 RHEL goes with CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y 2024-07-20 09:23:09 Arch goes with CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y 2024-07-20 09:23:10 Dunno about void 2024-07-20 09:28:42 opensuse does powersave 2024-07-20 09:28:45 Chimera also goes with CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y 2024-07-20 09:28:58 Yeah, suse is basically the only one I know 2024-07-20 09:29:14 I've been bitten by that once 2024-07-20 09:31:33 My point is that powersave cripples most workloads by default, so perhaps it's worth switching to a more balanced schedutil if there is no reason except for powersave being the default 2024-07-20 09:47:46 It works against global warming by default, if that doesn't fit your consumption model, it's easy to deactivate 2024-07-20 09:48:50 both schedutil (and actually performance) both lower the frequencies 2024-07-20 09:49:09 so I'm not sure about the total gain here 2024-07-20 09:49:17 It could be better documented though, maybe 2024-07-20 09:52:19 Hummm, I have schedutil by default 2024-07-20 09:52:49 Are you about your statement “linux-lts kernel defaults to 'powersave' governor”? 2024-07-20 09:53:23 $ grep 'CPU_FREQ_DEFAULT_GOV.*=y' /boot/config-6.6.41-0-lts 2024-07-20 09:53:23 CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y 2024-07-20 09:53:47 huh 2024-07-20 09:53:51 I have an older kernel 2024-07-20 09:53:58 $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_governor 2024-07-20 09:53:58 schedutil 2024-07-20 09:54:01 yeah 2024-07-20 09:54:06 probably they've switched the default 2024-07-20 09:54:19 Problem solved :D 2024-07-20 09:54:23 hmm 2024-07-20 09:54:42 weird 2024-07-20 09:54:42 :DD 2024-07-20 09:54:50 same thing as with SLUB xD 2024-07-20 09:55:16 The day I've brought the patch to alpine it becomes the default 2024-07-20 09:57:05 hmm 2024-07-20 09:57:06 actually no 2024-07-20 09:57:27 still powersave for me 2024-07-20 09:57:28 Hummm, it seems that the amd64 linux config doesn't set the default gov 2024-07-20 09:57:33 So that would be from upstream directly? 2024-07-20 09:57:38 yeah 2024-07-20 09:58:14 It does set ondemand by default for other archs though 2024-07-20 09:58:24 I suspect you're running an arm device? 2024-07-20 09:58:36 nah 2024-07-20 09:58:36 x86 2024-07-20 09:59:04 Intel(R) Xeon(R) Gold 6326 CPU @ 2.90GHz 2024-07-20 09:59:15 2024-07-20 10:02:19 meh, local.d it is 2024-07-20 10:02:27 don't wanna debug on saturday 2024-07-20 10:02:54 Yeah, set your system, go take some sun :D 2024-07-20 10:28:50 hey, I'm trying to use abuild locally for the first time and am getting a /usr/bin/abuild: line 718: APKBUILD: not found error. 2024-07-20 10:30:13 I used this wiki guide to install apk packages, generate my key, put it in etc apk keys, and create an APKBUILD template. 2024-07-20 10:30:14 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2024-07-20 10:30:58 abuild checksum spits out that error just like -r but can definitely modify my file to add checksums. 2024-07-20 10:32:28 Try running it with the DEBUG environment variable set 2024-07-20 10:34:58 checksum shows the download of the tarball and the sha512sum update, but it spits out the same error. 2024-07-20 10:35:08 -r is identical. 2024-07-20 10:40:09 What about with the DEBUG variable? 2024-07-20 10:41:41 Hummm, that's weird, DEBUG serves two purposes, to debug the build, but *also* to generate a debug package 2024-07-20 10:42:03 sorry, that's what I was running: DEBUG=1 abuild checksum APKBUILD 2024-07-20 10:42:20 and -r 2024-07-20 10:42:24 Does it show that $part that's the cause of the error? 2024-07-20 10:43:52 I don't think so: https://bin.gy/omeneconsh 2024-07-20 10:44:32 I feel like I'm just missing a package somehow. 2024-07-20 10:44:35 you're not supposed to pass `APKBUILD` at the end 2024-07-20 10:44:40 it tries to run that as a part command 2024-07-20 10:44:44 after it runs checksum 2024-07-20 10:44:47 and then well fails on running it 2024-07-20 10:45:30 ah makes so much sense. 2024-07-20 10:45:43 laptop is building now. 2024-07-20 10:45:45 thanks. 2024-07-20 10:45:45 It's weird that it doesn't print part though 2024-07-20 10:46:06 it does 2024-07-20 10:46:13 Ah, the “>>> wlock: APKBUILD”? 2024-07-20 10:46:16 yea 2024-07-20 10:46:24 right, thanks 2024-07-20 11:25:33 I keep getting this double slash warning with abuilding any APK file WARNING: opening /home/angel/packages//main: No such file or directory 2024-07-20 11:26:52 ang1e: '//' normalizes to '/' 2024-07-20 11:27:00 The double slash is innocent 2024-07-20 11:27:27 And as you see, it's just a warning. It means you have enabled a repo that does not have any packages yet 2024-07-20 11:28:22 thanks good to know. 2024-07-20 18:30:22 join #tor-relays 2024-07-21 12:35:22 Is anybody willing to look at 2024-07-21 12:35:22 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68731 and recommend what to do? 2024-07-21 12:35:27 Seems maintainer is not in gitlab 2024-07-21 12:36:17 @Saijin-Najib 2024-07-21 17:06:26 hii 2024-07-22 04:31:29 Thanks, ikke. I dont get notifications from my gitlab, here apparently, nor from pkgs.alpinelinux 2024-07-22 04:40:14 Saijin_Naib[m]: cc-ed you for feedback on !69539, not sure if you got a notification 2024-07-22 04:41:04 mio: Nope 😬 2024-07-22 04:42:15 okay, good thing you mentioned about notifications ^^ 2024-07-22 04:42:25 Looks great. Do you want to take it over? 2024-07-22 04:42:54 could do so, but only if you really want to let it go ^^ 2024-07-22 04:43:08 I just nabbed a ton of stuff that was going to be nuked.I am beyond my skill 2024-07-22 04:43:46 These are things I like/use/think are important, but not necessarily that I have the skill to fixup 2024-07-22 04:43:59 See the Gnome Latex debacle 😑 2024-07-22 04:45:39 skill can be learned ^^ though understandably if time is an issue ... as mentioned, only if you're sure. don't mind helping with bumping here and there ^^" 2024-07-22 04:46:13 Yeah, time is less and less. Have a creature haha 2024-07-22 04:46:16 gnome-latex was blocked on multiple packages, not your fault 2024-07-22 04:46:24 ah ^^ 2024-07-22 04:46:42 It also needs help, so I have less than I even anticipated 2024-07-22 04:48:45 your call ^^ ... if you're really sure then could maybe leave a comment in the MR about it, could update it to transfer 2024-07-22 04:51:11 mio: Yeah, I think it best. I need to focus on what I can fix and maintain and get them into Community 2024-07-22 04:53:06 okay ^^ let me know if you change your mind later, cheers 2024-07-22 04:53:18 thanks for saving them from purge 2024-07-22 05:07:58 "thanks for saving them from..." <- Thanks for stepping up and actually carrying them forward! 2024-07-22 05:34:05 you're welcome, gl with your other projects ^^ 2024-07-22 08:38:52 ncopa: i have broadcom wifi bcm43228, would it make sense to have an empty b43/ folder in /lib/firmware/ ? 2024-07-22 08:39:55 then i can mount b43 firmware onto it 2024-07-22 08:50:18 also missing is "Dell laptop SMM BIOS hwmon driver", can be enabled with CONFIG_SENSORS_DELL_SMM=m 2024-07-22 08:51:22 https://tpaste.us/BJrk 2024-07-22 09:27:25 b43 firmware is non-free right? 2024-07-22 09:27:34 i think an empty dir is a good idea 2024-07-22 09:34:12 yes, non-free 2024-07-22 09:37:07 currently i do , rmmod b43; rmmod bcma; mount b43 firmwares, modprobe bcma, and i get my wlan0 2024-07-22 09:37:12 seems to work 2024-07-22 09:43:08 CONFIG_SENSORS_DELL_SMM=m is only needed for x86_64 right? 2024-07-22 09:43:22 could you please create an issue on gitlab, so I dont forget it 2024-07-22 09:43:32 with label kernel 2024-07-22 10:04:03 there is also open-b43 project , can't seems to find those links 2024-07-22 12:53:39 ncopa: let me know what you think re https://github.com/mesonbuild/meson/pull/11502#issuecomment-2242885069 2024-07-22 12:53:55 i don't mind either way, i have a weak preference not to do it, but if you're not able to atm, let me know and i can crac kon 2024-07-22 12:55:59 sam_: thank you for following that up. I will not have time this week at least 2024-07-22 12:57:49 ncopa: np, let me take a look and see where we end up 2024-07-22 12:58:05 thanks for the quick answer! 2024-07-22 15:32:05 ldd /usr/lib/libarrow.so: https://tpaste.us/pa9x 2024-07-22 15:41:14 There's no announcement at a.o 2024-07-22 15:44:59 https://alpinelinux.org/posts/Alpine-3.20.2-released.html 2024-07-22 15:45:01 ther eis now 2024-07-22 16:32:40 grats! 2024-07-22 16:55:41 noice :) 2024-07-22 17:14:30 Any clue why libarrow cannot find those protobuf symbols? A simple rebuild does not fix it. This is related to ceph17/18 failing on the builders 2024-07-22 18:22:35 cely found out that apache-orc had to be rebuilt, but it's stil a mistery why 2024-07-22 19:09:07 ikke can you help with toot for https://gitlab.alpinelinux.org/alpine/aports/-/issues/16306 and https://gitlab.alpinelinux.org/alpine/aports/-/issues/16304 2024-07-22 19:13:46 congrats on the releases :) 2024-07-22 19:16:36 ncopa: I already made one for the 3.20 release 2024-07-22 22:16:45 Can someone please merge the latest synapse MR into 3.20-stable? The package maintainer has been unresponsive & a different dev merged MR 69406 into Edge, which is the same upgrade. 2024-07-22 22:16:45 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69405 2024-07-23 01:30:54 hi, if anyone happens to have been watching #openrc today there has been some interesting news. The perennially very-hard-to-get-in-touch-with openrc maintainer has just added a gentoo user as a maintainer. navi has been working on user services -- it is currently packaged for testing on gentoo: https://packages.gentoo.org/packages/sys-apps/openrc-navi 2024-07-23 01:31:33 my understanding is there has been some discontent in alpine with the development pace of openrc and hopefully this is going to mark a very big change :) 2024-07-23 03:56:41 i dunno, openrc has had plenty of release tags. but sure, user services would be nice 2024-07-23 09:49:37 ptrc: I notice that on my installations, ppa is enabled for Firefox 128. I thought you disabled that by default 2024-07-23 10:06:29 oh. it might not be configurable via vendor prefs..? 2024-07-23 10:08:05 no, wait 2024-07-23 10:08:13 /usr/lib/firefox/browser/defaults/preferences/vendor.js doesn't have the pref 2024-07-23 10:08:14 weird 2024-07-23 10:08:31 i.. didn't rebuild it. 2024-07-23 10:45:01 hi friends! I'm interested in tagging a new edge snapshot. would be nice if we could get the edge builders complete build 2024-07-23 10:45:25 the ceph issue was fixed yesterdau 2024-07-23 10:45:30 now there are some kde related packages left 2024-07-23 18:42:12 any idea what could be causing this? https://gitlab.alpinelinux.org/kpcyrd/aports/-/jobs/1461744 it builds locally with no problems 2024-07-23 18:42:24 the files that I suspect to be missing are e.g. internal/resolution/datasource/__snapshots__/npmrc_test.snap 2024-07-23 18:42:35 but I could not find that specific error messages in the code base 2024-07-23 19:18:10 kpcyrd: can you replicate it if you use alpinelinux/build-base as docker image? 2024-07-23 20:14:47 ikke: abuild passes on the alpinelinux/build-base image 2024-07-24 06:24:17 does it need network? maybe ipv6 connectivity is broken? 2024-07-24 06:45:58 hi all, is there way to say apk to prefer some package from another repo? let say i install linux-edge@edge, as i have all edge repositories tagged, next time apk upgrade will not install newer version because of tag, right? 2024-07-24 06:47:54 i see in /etc/apk/world linux-edge@edge 2024-07-24 06:53:10 does it imply that next time linux-edge will be updated once new package lands in edge repo? 2024-07-24 07:47:01 indy: yes 2024-07-24 08:27:27 could somebody have a look at aports!67773 ? 2024-07-24 08:28:01 It's been laying there for a while, and I took over maintainership of pulseaudio, I really hope it's fine 2024-07-24 08:58:09 PabloCorreaGomez[m]: I'm a bit surprised it's even necessary. With a .d directory setup like that I would expect files with a higher number to override lower ones. 2024-07-24 09:25:15 ikke: the problem is that in the initial patch the numbers are the same, and then they conflict on update 2024-07-24 09:25:37 It was an initial mistake on my side 2024-07-24 17:14:12 hello, as a new upstream maintainer for openrc, i'm implementing user services for it, and also going through the prs and issues 2024-07-24 17:14:14 then i decided to ask distros that ship openrc what would you like to see improved/fixed on the project, any new/old bugs that require attention, or similar things 2024-07-24 17:18:18 hiya! we've had some discussions lately about enabling rc_parallel by default; personally don't remember anything else for now 2024-07-24 17:22:29 navi: Nice to see you here 2024-07-24 17:24:43 indeed nice! 2024-07-24 17:30:04 it's nice to be here, hoping to help improve openrc and all that 2024-07-24 17:31:34 for rc_parallel, i'm looking into the issue with mangled input that was reported, and there's a few other things to fix on it too 2024-07-24 17:34:32 Ariadne: do you have any ideas of bugs or issues that we run into with openrc? 2024-07-24 17:44:59 is the future scope just user services + bugfixes, or is there more planned? 2024-07-24 17:47:17 i'm studing fd-holding/socket activation, and linux namespacing for the services 2024-07-24 17:48:13 those are pretty big. good luck :) 2024-07-24 17:48:19 i want to improve openrc in general, that means fixing stuff, and studying which features would be good in a modern init system 2024-07-24 17:48:21 thank you! 2024-07-24 18:10:10 hey navi! welcome \o/ 2024-07-24 18:11:21 navi: i think the ready fd (or what it is called) would be nice. That serivces can notify the supervisor that service is ready to accept connections 2024-07-24 18:11:54 readiness notification or smth, iirc there's two "standards" for it, systemd's and s6's 2024-07-24 18:12:10 implementing at least one of those would be nice 2024-07-24 18:12:25 and a better check for starting the services indeed 2024-07-24 18:12:44 i'll look into that too 2024-07-24 19:09:37 navi: note that if you implement s6's readiness notification (which is simpler), you also get systemd's for free because there's a wrapper for it: https://skarnet.org/software/misc/sdnotify-wrapper.c 2024-07-24 19:25:39 skarnet: this seem to a way to run s6-style readiness under systemd-style supervisor, but openrc is the supervisor, not the daemon, so does the oposite of what i'd need here i think? 2024-07-24 19:26:37 openrc does not support readiness notification anywa 2024-07-24 19:26:38 y 2024-07-24 19:26:45 so you can ignore openrc 2024-07-24 19:27:41 skarnet: the goal is to add it to openrc 2024-07-24 19:28:51 sorry, busy atm, I'll be more focused in a moment 2024-07-24 20:02:40 ok, got it. So, the point is to add readiness notification to openrc, which is great! the question is, what program would manage the readiness? because you can have openrc acting as a global server for all the readiness notification clients, or you can have supervise-daemon manage its own supervised process' readiness 2024-07-24 20:03:46 my point of view is that it's cleaner and simpler for the individual supervisor to manage readiness for its own process, which allows the notification to be a super simple protocol like what I did in s6 2024-07-24 20:04:30 but of course the utility of readiness notification is that it then informs the service manager that it can start dependent services 2024-07-24 20:05:55 openrc has no global daemon, so it would be supervise-daemon aka the individual supervisors 2024-07-24 20:06:51 that's all good, but then the question is, how would openrc use the readiness information to decide when it can start the next service 2024-07-24 20:07:15 in the purely sequential model, it's "when the current child dies, I can spawn the next child" 2024-07-24 20:07:42 and for long-running processes, without supervise-daemon, "the current child" is typically start-stop-daemon 2024-07-24 20:08:18 switching to a model with supervisors requires changing the way openrc sequences its operations entirely 2024-07-24 20:09:40 what you could do, I suppose, is have supervise-daemon store a state, and have openrc poll the state when it runs 2024-07-24 20:10:15 that's already a thing with /run/openrc/{started,starting} 2024-07-24 20:10:39 if supervise-daemon can talk back to the instance of openrc-run that started it, easy to use that 2024-07-24 20:11:07 yeah, if supervise-daemon can write the current state of its process somewhere openrc can read it, it works 2024-07-24 20:12:07 then I fully suggest using the s6 protocol: the daemon notifies readiness by writing (something ending with) a newline to a file descriptor, and that's it 2024-07-24 20:12:34 so in supervise-daemon you just have to read a pipe until a newline, then you can close it and forget about it 2024-07-24 20:13:03 the sd_notify protocol requires keeping a socket alive for the whole lifetime of a daemon 2024-07-24 20:13:25 i guess they notify more than just readiness? 2024-07-24 20:13:37 either way, after user services i'll look at either readiness or fd-holding 2024-07-24 20:13:55 sd_notify doesn't know what it wants to be, between a simple readiness notification protocol or a full-fledged monitoring protocol 2024-07-24 20:14:10 typical systemd half-thought design 2024-07-24 20:15:05 fd-holding is another world yeah 2024-07-24 20:16:03 but tbh at this point I'm really wondering, why reimplement so many s6 features in openrc instead of making the integration better? 2024-07-24 20:16:23 start-stop-daemon (the non-supervised model) can also use readiness actually, it already has a flag to wait Xms to check if the daemon is still alive, we can also have it wait for readiness 2024-07-24 20:16:37 yeah that's polling lol 2024-07-24 20:16:37 altho i'm more in favor of phasing out ssd in favor of supervised models 2024-07-24 20:16:49 (hard to do without breaking stuff tho) 2024-07-24 20:16:59 yeah I agree 2024-07-24 20:17:22 ssd is a pile of hacks to compensate for the lack of supervisors 2024-07-24 20:17:33 including polling instead of waiting for notification 2024-07-24 20:18:20 readiness solves the polling because we can `poll(2)` (ironic) the fd, but there's many other design issues anyway 2024-07-24 20:18:38 yeah 2024-07-24 20:19:15 . o O (s6-sysv: a wrapper around rc scripts for s6) 2024-07-24 20:19:32 i don't think that would work well 2024-07-24 20:19:45 or whether it would be possible at all? 2024-07-24 20:20:18 Is that something cgroups could do on Linux? 2024-07-24 20:20:25 honestly I've always said, for decades now, that I was willing to help openrc add support for s6 if they wanted to add supervision features 2024-07-24 20:20:52 at some point someone added support for s6-supervise in openrc scripts 2024-07-24 20:21:00 then it became half-deprecated 2024-07-24 20:21:07 then someone implemented supervise-daemon 2024-07-24 20:21:25 and at no point in any of this did anyone from openrc contact me, which was a little disappointing 2024-07-24 20:22:13 so if now there's someone who's willing to take up openrc maintainership and add supervision features, I'm reiterating my offer 2024-07-24 20:22:30 because the work has already been done so why duplicate it 2024-07-24 20:22:54 openrc can easily have the supervisors be modular/interchangeable, by just changing a few lines of sh and sorcing them dynamically, which i thought about for a bit 2024-07-24 20:24:00 sure 2024-07-24 20:24:34 but if you want fd-holding, s6 has it. if you want to add some logging infrastructure, s6 has it. etc. 2024-07-24 20:25:56 the only thing s6 doesn't have is a dynamic service manager because it's *hard*, as proven by how much work openrc needs :D 2024-07-24 20:27:16 sounds almost like a perfect match. s6 for the static part, openrc for the dynamic part 2024-07-24 20:28:49 more like openrc for service management, s6 for the infrastructure - openrc isn't really dynamic either (doesn't have a network manager and that kind of thing) but it's more flexible than s6-rc v0 2024-07-24 20:28:56 it has the flexibility a distro needs 2024-07-24 20:29:37 anyway I need to go, but I'm *really* interested in working with openrc if it's giving signs of life 2024-07-24 20:30:12 I'm here, we also have a community in #s6, and I'll join an openrc channel if you want to have a discussion there 2024-07-24 20:30:21 hope to see you around. 2024-07-24 22:32:57 ikke: i think openrc has been mostly stable for the past few years. but we obviously want reactive features like systemd has. 2024-07-24 22:34:51 i'll be working on those were it makes sense, if there's anything to add to the list already discussed, just lmk 2024-07-24 23:15:06 I'm rather glad it doesn't have some of those dynamic features. 2024-07-25 00:39:54 xulfer: to be clear, the specific features i have in mind are things like "defer starting network-facing services until network is actually up" 2024-07-25 00:40:03 (without blocking boot) 2024-07-25 00:40:31 not interested in auto-generated service definitions and other systemd features like that 2024-07-25 00:41:45 navi: the other problem with openrc that led alpine to start looking elsewhere for a replacement is the fact that, at least, until now, the only people maintaining it are gentoo devs, and for the most part, they only have cared about issues with openrc on gentoo, despite alpine having a sizable openrc install footprint (most likely larger than gentoo) 2024-07-25 00:42:30 we would like to see a better governance story than that 2024-07-25 00:43:07 Ariadne: Yeah sounds reasonable. 2024-07-25 00:45:53 keep in mind that in general we want to decouple the init system from policy in the distribution. some of the experimentation with systemd in pmOS is something we want to enable more widely in alpine 2024-07-25 00:46:03 Most of what I have issues with are things that target pretty specific use cases. Like desktop, and so on. Waiting for targets that will never come to start things like audio. 2024-07-25 00:46:44 That's great :) 2024-07-25 00:47:53 for example, i plan to introduce init-system virtual soon which openrc will be the default provider of. 2024-07-25 00:48:08 sounds like a bad idea 2024-07-25 00:48:17 it’s fine 2024-07-25 00:49:18 If it can be managed (which imo is kind of a big if) seems logical. 2024-07-25 00:49:24 there are some other things we want, like moving away from shell scripts for service definitions (yes, even the declarative ones are still scripts under the hood), which can be translated to fit the needs of an underlying init system 2024-07-25 00:49:54 the unit file syntax of systemd seems reasonable to adopt as a service definition format 2024-07-25 00:49:56 i've been hearing that for a very long time :P 2024-07-25 00:50:25 well, now i have more time to work on these things. 2024-07-25 00:50:51 Hmm are we talking like an intermediate DSL here? Sorry if I'm being slow heh. 2024-07-25 00:50:57 yes 2024-07-25 00:51:16 That's quite interesting. 2024-07-25 00:52:34 Could probably look at guix stuff for some of that mayhaps 2024-07-25 00:52:52 though, right now, my focus is getting PaX back into alpine 2024-07-25 00:54:27 after that, GCC 14 2024-07-25 01:00:30 the unit file syntax is far from reasonable, there's a lot of hidden complexity if only in special characters of the ExecStart= line 2024-07-25 01:01:27 and that's only one of many problems, the overarching one being that unit files are a holistic system that cannot be parsed in a reductionist way 2024-07-25 01:02:03 if you want to generate services for various backends, you'll have to settle on a very reduced subset of the unit file syntax 2024-07-25 01:02:34 at which point, you aren't compatible anyway so why choose this format 2024-07-25 01:03:15 Oh you mean making backends compatible with the unit syntax? 2024-07-25 01:03:37 I was under the impression that it would be a dsl that would translate to unit files, and whatever else as needed. 2024-07-25 01:04:08 my understanding of this: the unit file syntax of systemd seems reasonable to adopt as a service definition format 2024-07-25 01:04:19 was that the unit file syntax would be the frontend 2024-07-25 01:04:25 Oh sorry I skipped over that somehow 2024-07-25 01:04:47 a DSL with systemd unit files as one of the backends is an entirely reasonable goal 2024-07-25 01:04:58 unit files as the frontend is not 2024-07-25 01:05:06 i’m not prescribing unit files as the frontend 2024-07-25 01:05:11 Yeah because then we could be as descriptive as we need to be for whatever backend 2024-07-25 01:05:12 just something like them 2024-07-25 01:05:16 oh ok 2024-07-25 01:05:26 so that they have a feeling of familiarity 2024-07-25 01:05:59 to be clear i do not want to codify support of all of the ebpf “security” features of systemd into a baseline service definition 2024-07-25 01:06:20 obviously 2024-07-25 01:06:21 ebpf is not appropriate for security features anyway 2024-07-25 01:06:47 the thing is, language molds the mind 2024-07-25 01:07:19 be careful when reusing systemd syntax, it's easy to accept systemd concepts as something entirely legit and well thought-out 2024-07-25 01:07:21 sometimes they are 2024-07-25 01:07:28 other times, they are not 2024-07-25 01:08:00 Erroneous expectations and the like 2024-07-25 01:09:08 I was thinking scheme, but I don't want to be booed out of the room 2024-07-25 01:09:47 as one of many examples, User= can mean two very different things 2024-07-25 01:10:08 lookup User= in https://skarnet.org/software/s6/unit-conversion.html 2024-07-25 01:10:38 that's the kind of stuff you really don't want in your frontend 2024-07-25 01:16:10 i mostly just mean the “it looks like an INI file” part 2024-07-25 01:16:52 that alpine is valuable, because people already know how to reason about INI files 2024-07-25 01:17:02 that part* 2024-07-25 01:17:23 yeah that part is simple 2024-07-25 01:17:58 it’s the user experience that i care about. how do users interact with service management, etc. 2024-07-25 01:18:45 it is the user experience why openrc has survived in alpine for so long, despite the maintenance situation upstream being less than preferable for alpine 2024-07-25 01:18:50 true 2024-07-25 01:19:09 openrc’s user experience verses LSB sysvinit was much more pleasant and still is 2024-07-25 01:19:25 I, for one, fully support using s-expressions :3 2024-07-25 01:19:57 s-expressions will never fly as an interface in alpine 2024-07-25 01:21:28 the baseline for alpine UX really is the poor bastard who has to fix some IoT device in some closet somewhere and has only basic knowledge 2024-07-25 01:21:47 you start throwing s-expressions at them and they are going to be angry 2024-07-25 01:21:58 Any format could be great. Including ini. Just whatever can be very descriptive without being tedious. 2024-07-25 01:22:13 s-expressions are quite divisive :( 2024-07-25 01:22:30 in other words, interfaces need to be accessible to not just power users but the people who have to fix the machine when the guru is asleep 2024-07-25 01:22:35 ack :/ 2024-07-25 01:22:44 this is something alpine has always excelled at 2024-07-25 01:25:29 (well, excelled may be too strong. we have some areas where we need to improve. apk package conflict reporting being a major painpoint still.) 2024-07-25 01:26:07 but -- how people will interact with the system to accomplish their goal, it's the most important part of any design relating to init 2024-07-25 01:32:34 I'd say "the service manager" more than "init", because how the average guy should interact with init is "don't" 2024-07-25 01:33:32 sure 2024-07-25 01:33:33 what we mean when we say "init" is generally a big bag with a lot of moving parts, but the important parts that need to be interacted with can be fully decoupled from "init" 2024-07-25 01:36:11 anyway this is why openrc persists 2024-07-25 01:36:32 you can put openrc in front of somebody and they can figure it out in a few minutes 2024-07-25 04:22:01 Ariadne: (note that the openrc devs are not "only cared about issues with openrc on gentoo", as evidenced by the fact that gentoo devs have tons of gripes with openrc and historically could not get the lone openrc dev to care about those either.) 2024-07-25 04:23:03 (this is in fact exactly why the gentoo devs that use openrc are so thrilled to see navi step up) 2024-07-25 04:37:06 yeah it’s probably good in general 2024-07-25 07:16:48 The armv7 builder seems to be stuck on plasma-desktop-6.1.3. It seems to build a package then tries this one, fails, struggling for a day, then builds another one then struggles with plasma-desktop for a day, and so on... 2024-07-25 07:17:30 ... just wondering, if anyone else has noticed. 2024-07-25 07:17:50 Also, if anyone knows how to fix it. 2024-07-25 07:19:07 fancsali[m]: #16313 2024-07-25 07:19:28 Yes, we have noticed 2024-07-25 07:27:21 Well, okay, bad choice of words - sorry. 🥺 2024-07-25 09:30:21 ugh... latest chromium update. it tabs hangs and craches often :-/ 2024-07-25 11:22:16 Ariadne: i'm a gentoo user and wannabe-dev, but i'm looking out for other distros as well (which is why i came here in the first place) 2024-07-25 11:22:27 i'll note that about the interfaces thing 2024-07-25 11:23:16 (tho i do agree the "fully declarative" formats just hide the complexity under the hood) 2024-07-25 11:23:36 navi: It's much appreciated that you are looking for feedback 2024-07-25 11:46:56 dinit ftw 2024-07-25 11:49:07 it's like what openrc should've been 2024-07-25 12:31:09 !69311 Just a gentle reminder that pyqt6, qutebrowser, and whatever else depends on it are broken on edge. 2024-07-25 12:33:52 the maintainer seems to be active atm, so I pinged them 2024-07-25 12:35:34 Alrighty. Not sure what the policy is on stuff like that if it's a failing package. 2024-07-25 12:36:16 Not due to them just Qt update shenanigans I should say. 2024-07-25 15:38:32 ncopa: If it's the same backtrace(s) as https://bugzilla.opensuse.org/show_bug.cgi?id=1227739 , then see comment 3 2024-07-25 18:43:55 xulfer: are you the author of that MR? 2024-07-25 19:05:22 Yes 2024-07-25 19:07:32 I can look at the riscv stuff as well 2024-07-25 19:08:01 So I guess if you include disabling those dependencies (with a comment why) in the MR, I'll merge it 2024-07-25 19:08:42 alrighty 2024-07-25 19:09:07 ftr, not all of these are enabled on rv64, but here's a list: https://tpaste.us/rjzE 2024-07-25 19:09:44 How did you come up with that list if you don't mind me asking? Might be helpful in the future. 2024-07-25 19:09:44 You can also check the required by section here: https://pkgs.alpinelinux.org/package/edge/community/riscv64/py3-qt6 2024-07-25 19:10:12 xulfer: if you have `lua-aports` installed, you can do ap revdep py3-qt6 in each repo directory (main / community / testing) 2024-07-25 19:10:12 Ah fast answer :) 2024-07-25 19:19:06 Thanks 2024-07-25 20:39:09 I'm currently doing some silly bootstrap shenanigans and noticed that fortify-headers can not be downloaded by busybox wget (because it doesn't fall back to ipv4) but can be downloaded with "normal" wget, I assume that this is an intermittent issue, and not something I need to file a bug for? 2024-07-25 20:49:11 with GNU wget, do you get the download over IPv6 or over IPv4? 2024-07-25 20:50:14 I assume the issue is that the server has an IPv6 address but doesn't talk over IPv6? in which case that's what would need fixing, whether it's permanent or temporary 2024-07-25 20:51:01 (but it's true that -4 would be nice to have in bb wget) 2024-07-25 20:57:48 -4 or -6 2024-07-25 21:07:10 skarnet: that seems to be the issue indeed, gnu wget gets "no route to host" and then falls back to v4 2024-07-25 21:08:47 if that's your network that doesn't have ipv6 connectivity then you need to blackhole every AAAA query because lots of software will prioritize v6 over v4 2024-07-25 21:10:20 i have v6, can "ping -6" everyones least favourite search engine just fine 2024-07-25 21:10:57 well something's going wrong between your machine and the fortify-headers server 2024-07-25 21:11:20 "no route to host" is different from a http query failing 2024-07-25 21:12:22 i'm no network guru, but that seems like the adress in the AAAA record is just wrong/not actually configured on their side 2024-07-25 21:12:50 :/ 2024-07-25 21:13:12 so that's something they need to fix, either by getting it working or by removing the AAAA record 2024-07-25 21:13:31 your easiest workaround is to use GNU wget with -4 2024-07-25 21:13:40 but that's obviously not ideal for bootstrapping 2024-07-25 21:13:42 yea, 2001:19f0:6c01:2782:5400:3ff:fe0f:6f7f is unreachable 2024-07-25 21:14:03 gnu wget just falls back automatically, that's the advantage 2024-07-25 21:14:10 but it can take time 2024-07-26 07:13:55 hi, I would be grateful if anyone would be able to build an apk for postmarket os of my game which is mobile friendly and currently working on other mobile systems such as sailfish os and android: https://glitchapp.codeberg.page/_boxclip/ 2024-07-26 07:14:28 unfortunately I don't have the skills to do it myself, I'm not familiar with alpine, I only use it on a mobile which is not the main one I use 2024-07-26 08:38:15 glitchapp: you can raise a package request here: https://gitlab.alpinelinux.org/alpine/aports/-/issues 2024-07-26 09:38:51 thanks fossdd, I will do that 2024-07-26 09:47:05 done fossdd, thanks for the help and advise: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16317 2024-07-26 09:50:34 by the way in the meanwhile if anyone want to play the game on alpine, just in case you don't know, you don't need an apk, all you need is to install love2d. 2024-07-26 14:41:19 I'm having a problem with the bootstrap script from the aports repo, output: https://termbin.com/rgh7 . And here is the output after i patched a "-v" onto the call to "abuild -r" at line 137 of bootstrap.sh https://termbin.com/24uz 2024-07-26 14:45:36 it usually breaks quite frequently and needs small adjustments (in this case, util-linux 2.40 added bash/sqlite makedeps so they have to be added to the bootstrap list) 2024-07-26 14:47:31 just putting them directly before util-linux should work i guess? 2024-07-26 14:48:40 assuming they build in cross 2024-07-26 14:53:45 we shall see in a bit, for now it took adding "chrpath readline bash sqlite" and it hasn't fallen over immediately again 2024-07-26 14:54:11 aaaand i jinxed it 2024-07-26 14:55:05 maybe I mis-typed something 2024-07-26 15:06:08 https://termbin.com/f9bx this was solved by installing chrpath on the host machine 2024-07-26 15:26:37 https://termbin.com/rrss I'm getting screwed over by documentation, oh sweet irony 2024-07-26 19:06:35 its possible to do a variant of ram-based install that early mounts a writable image disk on /usr 2024-07-26 19:07:14 A data install would mount a disk on /var 2024-07-26 19:07:18 i have been using this method for a while, kinda hybrid between sys install and ram install 2024-07-26 19:07:18 why /usr? 2024-07-26 19:08:06 well whole root is possible 2024-07-26 19:08:22 or have another image disk for /var 2024-07-26 19:08:38 I mean, /var is generally more usefull than /usr, since /var is where things write data that you genrally want to persist 2024-07-26 19:08:47 while everything in /usr comes from the package manager 2024-07-26 19:09:03 var is more dynamic and would like to keep it full ram based 2024-07-26 19:09:16 kinda lessens wear and tear 2024-07-26 19:09:39 disk life vs ram 2024-07-26 19:10:28 2gb to 8gb ram is sufficient to play with 2024-07-26 19:12:16 i currently don't do installs that needs /var data 2024-07-26 19:12:49 this method just saves some ram from beeing occupied 2024-07-26 19:15:15 idea is to keep similar to ram-based install method 2024-07-26 19:18:00 maybe call it ram-swap method 2024-07-26 19:19:05 i also use this method on all my alpine pkgs install on mobiles :) 2024-07-26 19:23:34 intesting to note would be working installation of "texlive" on mobile with 2Gb ram 2024-07-26 19:24:07 only issue was 4Gb usr image 2024-07-26 19:28:33 was wanting to suggest/request this as a boot option in syslinux.cfg 2024-07-26 19:34:17 today i did a setup of a ram based PV-DOMU(alpine linux) 2024-07-26 19:35:02 kinda cool :) 2024-07-26 19:38:33 one mobile running alpine pkgs is approaching 700days 2024-07-26 21:42:36 Hi all :-) 2024-07-26 21:43:55 I'm trying to use aports/script/bootstrap.sh but it fails on openssl (host: x86_64, guest: armv7) 2024-07-26 21:45:49 I get "cannot find -latomic". I tried to modify the script to force installation (by setting NEEDS_LIBATOMIC="yes") 2024-07-26 21:45:52 Any idea ? 2024-07-27 01:33:17 Hm any tips on how to emulate the build servers environment? I've just been tediously setting up cross chroots by hand, but kind of tedious. 2024-07-27 01:56:24 and I'm getting a build that works on my chroot using the same arch that failed on the build system atm. 2024-07-27 03:27:56 was looking for a way to play around with pam_cap without messing with the libcap aport, came up https://tpaste.us/mgVj 2024-07-27 05:57:14 Hi installed alpine on a virtual machine and I'm trying for the first time to install alpine-sdk, I become the error "unable to select packages: alpine-sdk (no such package)", any idea on how to proceed? 2024-07-27 06:01:59 glitchapp: did you `apk update` first? 2024-07-27 06:37:25 this was answered in #alpine-linux 2024-07-27 06:41:01 that's good I guess 2024-07-27 07:17:25 I'm stucked now in the abuild process, I become the error: rootbld: mapath ../.roobld-repositories does not exist" and sh: aportsdir: not found 2024-07-27 07:17:46 iggy I solved that problem, I'm already trying to build an apk 2024-07-27 07:18:54 rootbld-repositories does not exist says the error 2024-07-27 07:19:46 ok I solved that problem 2024-07-27 07:24:23 now I'm stucked here: https://pasteboard.co/yNxH8IUNLTDu.png 2024-07-27 07:26:01 the recipe I'm using is this: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16317#note_423895 2024-07-27 07:29:03 What did you put in .rootbld-repositories? 2024-07-27 07:29:22 nothing... 2024-07-27 07:29:36 It should be something like https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/.rootbld-repositories 2024-07-27 07:30:09 ah right, let me try 2024-07-27 07:30:24 Or this, if you need community as well: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/.rootbld-repositories 2024-07-27 07:32:18 good, adding that content to .rootbld-repositories changed the errors, now the complain is unable to select packages: "love (no such packages" 2024-07-27 07:32:25 I guess I need to install love now, let's try... 2024-07-27 07:33:54 no... love is installed but it still complains that there is no sucj package 2024-07-27 07:43:37 love is in community, so you need to make sure you have community there as well 2024-07-27 07:59:32 I managed to get an apk, however I can not compile anymore because it says untrusted signature 2024-07-27 08:00:01 I will upload that apk and ask for feedback, I have not postmarket os to test right now and did not managed to get a gui working 2024-07-27 08:00:06 thanks for the help! 2024-07-27 08:08:32 just in case anyone to test the build I uploaded here: https://codeberg.org/glitchapp/boxclip-mobile/releases 2024-07-27 09:16:28 glitchapp: ah yeah thats nice. i works but i noticed that the game doesnt scale well on a mobile device 2024-07-27 09:17:13 and you could open a MR and add the APKBUILD to aports, so people can install it rightaway with the repository 2024-07-27 09:18:10 probably sure, my problem is that I only have basically two mobiles to test with very specific resolutions, my daily mobile system is also sailfish os which has specific requirements that may not apply to other systems, the project is however open source and any hint and ammendement for any systems are welcome 2024-07-27 09:20:19 oh yeah i used a 1280x720 screen 2024-07-27 09:20:46 maybe i can take a look at the source in the next days 2024-07-27 09:20:52 codeberg, nice! 2024-07-27 09:21:37 I have one trick that I need to explain and create a faq for screens with low resolutions: you can adjust the camera zoom at any time, all you need to do is to connect a gamepad via usb or bluetooth and then move the right thumbstick up or down 2024-07-27 09:21:55 lol 2024-07-27 09:22:48 sure fossdd, feel free to fork the project, and if you find the project interesting feel free to join the loomio group I created for contributors: https://groups.f-hub.org/boxclip/ 2024-07-27 09:23:35 it is not necessary to contribute, just in case is useful, but you can send your push request or add your ideas to issues in the repository or use any channel like irc to provide feedback 2024-07-27 09:25:45 I've just cloned aports, will see if I can send the package, I'm learning and not familiar with alpine but I guess I will manage 2024-07-27 09:59:24 merge request submitted: https://gitlab.alpinelinux.org/fossapps/aports/-/compare/master...fossapps-master-patch-05334?from_project_id=1 2024-07-27 10:00:38 This is the MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69804 2024-07-27 10:03:24 looks good, it seems that automatic verification has been successfull for all arquitectures 2024-07-27 10:05:38 Oh, I just noticed it didn't try to build it at all 2024-07-27 10:06:05 actually there's nothing to build because is all scripted 2024-07-27 10:14:11 so is something went wrong I have no idea because it buils on my alpine virtual machine 2024-07-27 10:14:18 with the same recipe 2024-07-27 15:11:31 what is the intention of having both llvm14 (which is not in aports anymore) and llvm17 in bootstrap? 2024-07-27 15:28:46 none, it just hasn't 2024-07-27 15:28:50 been updated in a while 2024-07-27 15:30:52 ok, that explains llvm14, but why two seperate versions? 2024-07-27 15:33:04 different things use different versions 2024-07-27 15:34:47 oh, ghc needs it, i missed the llvmver when looking at it 2024-07-27 15:36:54 wow, setup-alpine is improved (al v3.20.x), columunized options/input and more 2024-07-27 18:32:23 seems doing "setup-desktop xfce" booting with x86 iso does not work on bare metal (2nd gen intel), retrying 2024-07-27 18:33:33 this is v3.20.2 2024-07-27 19:08:16 will try with ealier versions later 2024-07-27 19:15:57 vkrishn: x86 32-bit? 2024-07-27 19:58:13 "seems doing "setup-desktop xfce"..." <- What exactly does not work? Doing so results in a freezed mouse and keyboard, as of a permission error. I first need to setup Xwrapper.conf. 2024-07-27 20:25:55 ptrc: x86, yes, i was hoping to setup wine in it and see if win95/win98 games ran on them 2024-07-27 20:26:26 fx[m]: will try, did not have to do in v3.18.6_x86_64 xfce setup 2024-07-27 20:26:54 thanks for help 2024-07-27 21:11:47 they might just run in normal wine 2024-07-27 21:15:02 What is the recommend way to have an APKBUILD activate a kernel module? 2024-07-27 21:15:02 moving a file there? 2024-07-27 21:15:02 with: echo uinput | install -D -m644 /dev/stdin "$pkgdir"/usr/lib/modules-load.d/$pkgname.conf 2024-07-27 21:16:48 Am I correct that this should be added into bluez? 2024-07-27 21:16:48 I am asking since, my bluetooth keyboard and headphones required uinput to be running. 2024-07-27 21:25:26 Feedback is appreciated: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69825 2024-07-27 21:44:40 bluetooth keyboard definitely does not need uinput 2024-07-27 21:45:54 ok, then that was another weird bug. I then close the bluez PR 2024-07-27 22:36:49 getting this error while trying to run wine, https://tpaste.us/lg6L 2024-07-27 22:37:13 this is in al 3.18.6 x86_64 2024-07-27 22:37:58 how bout you try edge 2024-07-27 22:38:15 which has the new version and not the old one 2024-07-27 22:38:27 back in that old one windows pinball doesn't work 2024-07-27 22:38:31 does in the new one 2024-07-27 22:45:04 ok 2024-07-27 22:51:14 did apk del wine in current setup, the add edge repo, got this https://tpaste.us/d1ew 2024-07-27 22:51:30 then added ^ 2024-07-27 22:52:32 but dosbox-x.exe runs 2024-07-27 22:59:48 wine -> dosbox-x.exe -> booting guest os (win98) is ok 2024-07-27 23:00:47 i think if dosbox-x got pkg'ed in al, that would be nice 2024-07-27 23:17:38 alice in 3.18.x winecfg lowest win ver is "xp" 2024-07-27 23:45:45 anyone noticed that module 'coretemp' conflicts with xen kernel ? 2024-07-28 00:07:04 intel-ucode is no loger needed while booting xen kernel ? 2024-07-28 05:45:40 What facilities does ACF have for IPC? I am thinking of writing a service/daemon to manage a game server, and I am thinking of doing it in Lua since ACF uses Lua already, so passing information between the Lua interpreter/state running my daemon and the one running ACF/my ACF module should be simpler 2024-07-28 05:47:50 Hmmm. Maybe I could borrow/steal mvc.lua from ACF for that. I think I would still want separation from the daemon and the ACF module that talks to it, but I can reuse the MVC library there to make my life easier 2024-07-28 05:50:01 i feel like all i am doing here is looking at wikipedia articles on programming paradigms but that is kind of par for the course for nearly 2am 2024-07-28 09:42:31 Hello everyone, can someone please check my PR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69811 2024-07-28 13:54:14 community/ghc is giving me a headache with bootstrap.sh https://termbin.com/xscc i tried adding a "--host" here https://git.alpinelinux.org/aports/tree/community/ghc/APKBUILD#n124 but that only lead to failure to find "ar" a bit later https://termbin.com/j3os 2024-07-28 13:57:06 If you don't need ghc, you could probably just skip it 2024-07-28 13:58:56 i thought if i go through the trouble of fixing up bootstrap.sh i might as well do it properly 2024-07-28 13:59:31 right, but ghc is not an easy one 2024-07-28 14:00:07 i noticed :D 2024-07-28 14:03:03 then i'll take it out, and see if rust causes me just as much pain 2024-07-28 18:23:29 Does `abuild` have shell completion paths hard-coded? 2024-07-28 18:24:04 I see that the completion packages are declared, but the completions themselves are installed inside `package()` 2024-07-28 18:24:59 kaathewise: there are default split functions indeed that automatically move the completions to the expected paths 2024-07-28 18:25:33 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2168 2024-07-28 18:32:42 got it, thanks 2024-07-28 23:32:59 "No space left on device" on usa-bld-1 shared-runner (armv7) 2024-07-29 12:46:51 can someone take a look at !67559 and !67468? both have been reviewed and have maintainer approval 2024-07-29 14:17:34 Is there a requirement for use of a "real name" to contribute to alpine, or is gitlab just asking for first and last name because that's just what gitlab does? 2024-07-29 14:23:18 it's a gitlab thing on signup 2024-07-29 14:23:30 you can put in `xyz .` and then after signup just delete the . 2024-07-29 14:23:45 i think i saw one instance out there that didn't have it, they probably patched the signup form 2024-07-29 14:24:24 I'll just split my username :D 2024-07-29 14:24:50 or use it as the first name, might make more sense actually 2024-07-29 14:26:04 i mean you can literally do first:socksinspace last:. and then go delete the value 2 seconds later :P 2024-07-29 14:26:06 it does not break anything 2024-07-29 14:26:08 i did that 2024-07-29 14:26:14 (in every instance) 2024-07-29 14:27:03 yes, but some projects require use of a real name to contribute, so i wanted to make sure :) 2024-07-29 14:27:07 yea not this one 2024-07-29 14:27:26 good on ya 2024-07-29 16:02:16 I'm trying run my patched bootstrap.sh in a alpine chroot on my desktop, (to get some faster speeds than my alpine machine is capable of) but i seem to have missed something in the setup https://paste.tchncs.de/upload/mouse-gecko-panda 2024-07-29 16:19:44 (the chroot is made from the minirootfs) 2024-07-29 17:14:08 socksinspace: seems like apk was not initialized in the chroot 2024-07-29 17:19:59 wouldn't that have prevented me from installing alpine-sdk? 2024-07-29 17:26:58 I seem to be unable to create an MR – the browser always ends up on my fork, and wants to create the MR there... 2024-07-29 17:28:00 Is it actually a fork of aports? 2024-07-29 17:29:09 Your project is private, I think that causes it to choose your project 2024-07-29 17:30:06 Hm... 2024-07-29 17:30:12 Also https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/new seems to 404... 2024-07-29 17:30:48 ikke: It is, I am fairly positive, let me see that private stuff... 2024-07-29 17:30:57 Yeah, I see that it's a fork 2024-07-29 17:34:16 Well, setting it to public didn't help... 😞 2024-07-29 18:04:53 It was the issue that is mentioned in the sysroot setup part with the key being both in .abuild/ and /etc/apk/key 2024-07-29 18:06:32 fancsali[m]: The URL will be under your fork but the target branch will be alpine/aports:master 2024-07-29 18:06:47 eg for me it's https://gitlab.alpinelinux.org/Arnavion/aports/-/merge_requests/new 2024-07-29 18:17:24 I see – but that seems to be timing our if I click 'Compare branches and continue'; that's how I got down to investigating the URLs... 2024-07-29 20:56:00 If I go – create MR, and then 'Change branches', it seems to work. The 'Compare and continue' button still makes me wait rather long, though... 2024-07-30 00:00:25 is anyone able to restart the CI pipeline here / move this towards merging? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69878#note_424446 2024-07-30 00:02:24 the pmOS build system is cratered until this is fixed/merged, but I suspect probably most folks who can help are asleep now :P 2024-07-30 04:45:37 ftr, this was merged by celeste ~1h ago 2024-07-30 07:18:31 I'm running into failures building openssl within bootstrap.sh for armhf and armv7. It seems like it may be related to the thing mentioned about riscv64 and -latomic but just replacing the riscv64 in the if statement with armv7 didn't solve the issue, so i'm not sure https://0x0.st/XfhQ.txt 2024-07-30 08:35:48 is there any chance that !69889 would build on the riscv64 package builder? 2024-07-30 08:37:41 I wouldn't like to disable py3-qt6 on riscv64, but I would like to unbreak things by upgrading it to 6.7.x where possible 2024-07-30 08:56:43 omni: im getting this on the pioneer https://tpaste.us/EJVe 2024-07-30 08:56:53 not sure its related to your rv build issue 2024-07-30 09:00:26 this is acually on the builder 2024-07-30 09:00:39 but it seems CI box has similar isuses 2024-07-30 09:04:26 it is qt6-qtbase qmake that has issues on riscv64, right? 2024-07-30 09:06:30 i dunno, just saw this passing by on dmesg 2024-07-30 09:06:42 so i added the time for reference 2024-07-30 09:06:46 i can do the same for CI if you like 2024-07-30 10:21:57 Is there a process to follow when a package maintainer is not responsive to emails or MRs regarding updates to packages they maintain? 2024-07-30 10:27:28 jahway603[m]: there's no proper formal process yet, but in general MRs are often merged even if the package maintainer doesn't approve them explicitly; in case of longer inactivity feel free to submit a MR taking over the package 2024-07-30 11:38:56 ... but it works now, that's the bottom line! 😉 2024-07-30 11:41:05 what do we do with qt6 webengine? upstream dropped 32 bit support 2024-07-30 11:45:30 I guess verify if anything from pmos depends on it? 2024-07-30 14:18:50 i'd expect that users depends on 32 bit qt6 webengine, but the question is if we have resources to maintain it if upstream does not? 2024-07-30 15:03:13 i have found a potential fix for deadlock on 32bit 2024-07-30 15:12:11 is the 0x0 link i pasted earlier still available, https://0x0.st/XfhQ.txt when i try to open it i get "suspected malware client, rejecting traffic" which would not be useful to include in an issue :D 2024-07-30 16:22:25 omni: py3-qt6 build again correctly 2024-07-30 17:43:22 ikke: it looks like something is different between rv64 ci vs builder 2024-07-30 18:25:44 clandmeter: it does? 2024-07-30 18:28:56 ncopa: not sure if it helps, but seems like 32b arm & x86 is still supported for Android® https://doc.qt.io/qt-6/supported-platforms.html 2024-07-30 18:31:32 wouldn't also Debian be interested in Qt6 qtwebengine on 32b architectures? 2024-07-30 18:31:44 they don't seem to be at 6.7.x yet though 2024-07-31 02:29:29 experiencing a weird issue while bumping perl-mozilla-ca where it's apparently ignoring `INSTALLDIRS=vendor` for some reason. I'm hesitant to commit, push, and MR because it shouldn't be installing to `/home/$USER/lib/perl5`. 2024-07-31 02:30:50 (I'm on `edge`, perl 5.40.0) 2024-07-31 02:44:02 …or someone else can take care of it, lol. 2024-07-31 13:49:40 > MC[AL31]:APKBUILD:54:3:variable CMAKE_CROSSOPTS must not have capital letters 2024-07-31 13:49:47 is that recent? ive seen this twice already 2024-07-31 23:06:47 > I find rust  1.80.0-r0 for riscv64 does not exist. 2024-07-31 23:06:49 from the ML 2024-07-31 23:06:59 and yeah, riscv64 builder is idle but rust isn't there 2024-07-31 23:07:03 am i missing something?