2022-07-01 03:05:39 psykose: Good morning, it seems x86 tcl-lib math tests pass on tcl 8.6.10, so something probably happened on x86 between 8.6.10 and 8.6.12, should I try 8.6.11, or jump to try the 8.7 pre-release instead? 2022-07-01 03:06:10 dunno 2022-07-01 03:06:17 not the pre release 2022-07-01 03:06:53 Ok, I'll try 8.6.11 then, I have a feeling it will start failing there 2022-07-01 03:17:38 Yes, the tests fail on 8.6.11 2022-07-01 03:22:56 looks like a bunch of rounding math stuff so have fun :) 2022-07-01 03:23:47 Yes, not fun, which is why I've been procrastinating for the past month 2022-07-01 05:46:04 psykose: re: mesa & old gpus... I guess you could just make the change and not add the amber stuff, and if anyone actually uses those older gpus w/ alpine and cares, they'll show up. and if no one shows up, then I guess no one cares. /shrug 2022-07-01 05:55:29 I don't really know the rules for invoking the alpine TSC... but is this maybe something that could give a definitive answer on this? 2022-07-01 05:57:20 you can open a tsc issue i think 2022-07-01 05:59:25 ok I can do that. if it's not the right thing to do, I trust someone will promptly close it :P 2022-07-01 06:04:33 my other secret is also that i just build the newest mesa myself for my own use /s 2022-07-01 06:09:41 Don't think the tsc needs to decide on this. 2022-07-01 06:11:48 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/51 2022-07-01 06:12:02 ah, just in time for ikke to NACK the idea of filing an issue there :D 2022-07-01 06:16:02 welp, I don't care who decides it, as long as some decision is made so Mesa can be updated. the current release branch packaged in aports right now was first out ~7 months ago 2022-07-01 06:28:00 why is alpinelinux.org behind cloudflare? 2022-07-01 06:35:18 is it? the ip address is just equinix 2022-07-01 06:47:59 Yeah, we don't use cloudflare 2022-07-01 06:48:23 psykose: I think I have the patch that makes tcl-lib math tests pass on x86 2022-07-01 06:48:47 fantastic 2022-07-01 07:00:07 ah, I was looking at older information 2022-07-01 07:00:14 good :) 2022-07-01 07:11:02 ...and the tcl-lib math tests now complete successfully on x86 2022-07-01 07:27:52 and now to run the full tcl and tcl-lib testsuit to see if anything else breaks 2022-07-01 08:29:17 I saw that Jakub added wolfssl, could it be an openssl replacement? 2022-07-01 10:04:33 the problem with openssl is not that there aren't any replacement (there are many, including *one* actually good SSL library (BearSSL). The problem is that OpenSSL has a very complex API that is used in a lot of projects, and these projects are captive to that API. There's no drop-in; porting projects out of OpenSSL requires ad-hoc work in every project. 2022-07-01 10:04:55 wolfssl does have a compatibility layer; i have no idea how good it is 2022-07-01 10:05:08 i only looked at it once to see if wolfssl could save me disk space compared to openssl, but at least with the layer, it didn't 2022-07-01 10:06:43 the reason for alpine going back with libressl was the porting work more that libressl itself? 2022-07-01 10:07:43 s/that/than 2022-07-01 10:07:43 donoban meant to say: the reason for alpine going back with libressl was the porting work more than libressl itself? 2022-07-01 10:22:05 Libressl was making breaking changes 2022-07-01 10:22:23 There is a thread on the mailing list about it 2022-07-01 10:24:52 ah I see, thanks 2022-07-01 10:55:01 There was discussion at TSC about ssl libraries. Do you want to review that decision? 2022-07-01 11:09:38 eschwartz: very mild speed up. lol 2022-07-01 11:19:26 Piraty: don't turn down free CPU cycles! 2022-07-01 11:20:06 but anyway, the main point is in fact to make grub actually work instead of *silently* failing to do the right thing when "which" isn't a runtime depend 2022-07-01 11:24:24 good luck on your which hunt 2022-07-01 11:43:43 eschwartz: "to make grub actually work instead of *silently* failing to do the right thing when "which" isn't a runtime depend" - busybox provides "which" so its always available (unless you're trying to run without busybox installed) 2022-07-01 13:04:13 minimal: grub the software, not grub the alpine package. 2022-07-01 13:05:49 (I do not actually use Alpine, my distro doesn't have which installed by default, and thus my motivations here actually cover good upstream architecture such as not relying on something that may not actually exist if you take the broader Linux ecosystem into consideration) 2022-07-01 13:08:16 most software relying on it actually does so because *Debian* has a which command :) (it's a custom Debian shellscript that is carefully packages as part of their essential packages, such stupendous effort to guarantee that a questionable thing always exists???) 2022-07-01 13:27:16 most uses of which can be replaced with type 2022-07-01 13:35:11 most uses of which can be replaced by just running the command 2022-07-01 13:36:13 do people use which when they need to actually run the command? 2022-07-01 13:40:49 crap.sh: PS=`which ps`; GREP=`which grep`; XARGS=`which xargs`; KILL=`which kill`; ${PS} -aux | ${GREP} garbage | ${XARGS} ${KILL} 2022-07-01 13:41:08 stick a -9 on the end 2022-07-01 13:52:14 in situations like that I would actually just use `command ps -aux`, there's actually a fairly good chance the goal of the script was to suppress functions/aliases 2022-07-01 13:53:03 for example that's the case with xdg-utils, it tries to run arbitrary commands from a desktop file and doesn't want to get clobbered by implementation details of the script 2022-07-01 13:54:39 they're relying on a side effect of `which` usually resolving to a disk name (at least in cases where you don't have a ~/.cshrc alias, since `which` on many systems will then print that instead) 2022-07-01 14:05:05 fwiw here is a portable pure shell solution to finding an executable file in the user's path... https://notabug.org/orbea/exists/src/master/exists.sh 2022-07-01 14:11:10 without -a, is this the same as command -v 2022-07-01 14:11:50 no, command -v can find other things like shell aliases and depending on the shell it may be of better or worse quality... 2022-07-01 14:12:02 you could also just vendor debian's `which` shellscript 2022-07-01 14:12:38 or convince the Austin group to standardize type -P 2022-07-01 14:14:13 its been a while since I looked, but I recall yash and zsh having the best command implementations 2022-07-01 14:14:38 maybe mksh too 2022-07-01 14:14:58 isn't this basically `type` 2022-07-01 14:16:14 type tells you what it is, not exclusively where it is and if it exists 2022-07-01 14:18:12 for example which won't find type where command -v print 'type' and type will tell me its "a semi-special buil-in" (in yash) 2022-07-01 14:18:23 built-in* 2022-07-01 14:20:03 type -P seems to *exclusively* tell you the path 2022-07-01 14:22:03 that is not in posix though 2022-07-01 14:22:41 https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/type.html 2022-07-01 14:26:28 /bin/sh -c 'command -v "$1"' --? 2022-07-01 14:27:10 hm, builtins. 2022-07-01 14:27:18 and aliases 2022-07-01 14:27:40 posix sucks 2022-07-01 14:28:09 https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/command.html 2022-07-01 14:28:23 well sh -c would avoid aliases 2022-07-01 14:30:10 its an annoying problem which is how I ended up with an overdesigned script and a bunch of tests... 2022-07-01 14:31:42 it is an annoying problem which is why I use fish and limit POSIX things to bare minimum 2022-07-01 14:38:44 in 90% of cases, command -v suffices because your script knows which aliases/functions it creates, and avoids collision. 2022-07-01 14:39:32 in 9% of cases, just use `command foo` and check if it fails; it suppresses alias/function lookup 2022-07-01 14:39:41 the problem is when you are using scripts that might be used on other systems 2022-07-01 14:39:56 in 1% of cases, use bash so you can actually disable builtins sanely when you don't want them 2022-07-01 14:40:13 this is not about which systems you use 2022-07-01 14:40:34 bash is the shell that tells your example script is wrong when you demonstrate an infinite loop in bash... 2022-07-01 14:40:40 using scripts on other systems won't magically cause new aliases/functions to appear in your script 2022-07-01 14:41:35 I wholeheartedly do not recommend using bash, ever 2022-07-01 14:41:50 ^ 2022-07-01 14:42:13 probably still not fixed, but I havent checked recently... https://termbin.com/eyfq 2022-07-01 14:42:14 and I will write completely POSIX script just to avoid bash(isms) 2022-07-01 14:42:21 same :P 2022-07-01 14:42:51 the remaining uses of `which` that don't fit into the 100% I described above, are actually interactive uses, in which case all shells that try to be a pleasant interactive experience have type -a, accept no substitutes, you actually do require seeing both aliases and PATH and nothing, not debian which, not orbea which, not command -v or anything else, does this 2022-07-01 14:44:41 gnu which actually does do this, but only by using a function wrapper that pipes the entirety of the shell state as stdin to `which` and throws in a `which` flag that runs a shell parser on the output, analyzes aliases and functions, and mixes it into the output of `which -a` 2022-07-01 14:45:57 i didn't want to replace which, just find executable files in the $PATH and print their full path 2022-07-01 14:46:37 yes but clearly that isn't the interactive use case 2022-07-01 14:47:00 and all non-interactive use cases other than avoiding builtins can be done with either command -v or command 2022-07-01 14:48:17 i do have -a in my script 2022-07-01 14:50:56 type -a, not which -a 2022-07-01 14:51:42 > you actually do require seeing both aliases and PATH and nothing, not [...] orbea which [...] does this 2022-07-01 14:53:08 type -a is not posix 2022-07-01 14:53:49 and the goal was to not see builtins or aliases, different usecase :) 2022-07-01 14:57:10 i am aware it is not posix 2022-07-01 14:57:36 I am simply stating that by definition, if your goal is to be interactive, then your goal is to see builtins, aliases, and functions 2022-07-01 14:58:04 and if your goal is to be scripted, then your goal is to *not* print more than one result... 2022-07-01 14:58:39 (unless you can think of some reason to use which -a in a shell script that I haven't thought of?) 2022-07-01 19:14:10 I'm building a go package, is there a standard way of fetching the dependencies in prepare() before building with `go build`? Currently my package gets all deps and builds in build(), whereas for rust packages I've done `cargo fetch` and `cargo build` separately 2022-07-01 19:36:22 currently no, because there isn't even a special phase for fetch source after default_prepare 2022-07-01 19:37:27 doesn't mean you cannot do it in the prepare phase 2022-07-01 19:37:36 though, it doesn't help with rootbld 2022-07-01 19:38:01 eddsalkield_: I haven't seen any packages do that yet for go 2022-07-01 19:38:13 no packages do that 2022-07-01 19:38:35 it was started in rust packages due to jirutka MR in abuild 2022-07-01 19:38:50 and I mentioned that it could be done for Go as well, but I forgot to push it 2022-07-01 19:39:00 yes, and I have been looking at that myself for go as well 2022-07-01 19:39:15 I have it already written on one of my machines, just need to find 2022-07-01 19:40:25 What command do you use to fetch just the modules? 2022-07-01 19:42:43 ikke: go mod download, eventually go get for non-module go packages 2022-07-01 19:42:55 right 2022-07-01 19:45:02 Sadly, there is no phase yet after unpackage that still has net in roobld 2022-07-01 19:46:29 wouldn't it be just running bwrap twice 2022-07-01 20:27:43 patching gitlab in a couple of minutes 2022-07-01 20:31:27 Oh no wonder it didn't work for me right now 2022-07-01 20:31:59 It's upgrading 2022-07-01 20:34:17 And it's back 2022-07-01 21:17:32 okay, I'll just push the package as it is right now 2022-07-01 21:18:19 panekj: if you get around to pushing those changes to support rootbld go packages, I'd be interested to hear about it 2022-07-01 21:20:50 rootbld would require changes to apkbuild 2022-07-01 21:21:05 but doesn't mean you can download the modules in the prepare() phase 2022-07-01 21:21:10 you cannot* 2022-07-01 21:23:25 so `go mod download` in prepare(), and `go build` in build()? 2022-07-01 21:23:44 what changes would need to be made to support building in rootbld? 2022-07-01 21:27:46 we need a new phase between prepare and build 2022-07-01 21:27:52 that fetches stuff again 2022-07-01 21:29:03 you can already have it in rootbld in prepare with default_prepare + go mod download, just need options="net" and it's not proper support but that's what we do for rust 2022-07-02 05:50:12 panekj: if only package building were an arbitrary pipeline :p 2022-07-02 11:41:33 mhmm (: 2022-07-02 15:51:38 Hmm, I might have found the solution for the errors we sometimes get when applying labels to issues 2022-07-02 15:58:48 what is it 2022-07-02 15:59:18 Apparently some poorly documented config file missing 2022-07-02 15:59:59 https://docs.gitlab.com/omnibus/settings/actioncable.html 2022-07-02 16:00:16 Added it in our test installation, and cannot trigger it anymore 2022-07-02 16:01:04 how is some worker pool size related to issue labels 2022-07-02 16:01:14 It's not the worker pool size 2022-07-02 16:01:44 It configures a backend for those 'cables' 2022-07-02 16:02:29 what i mean the only thing on that entire page is `actioncable['worker_pool_size']` 2022-07-02 16:02:38 yes, that's why I say poorly documented 2022-07-02 16:02:40 heh 2022-07-02 16:02:41 https://gitlab.com/gitlab-org/gitlab/-/blob/335007-fix-pipeline-status-stuck/config/cable.yml.example 2022-07-02 16:03:53 I just used that file and adopted it 2022-07-03 12:58:23 Upgrading gitlab and upgrading host to 3.16 2022-07-03 13:00:10 ~ 2022-07-03 13:00:41 does this finally come with those permission user ci rebase issue whatever fixes 2022-07-03 13:04:53 I suppose so 2022-07-03 13:06:27 ok, done, gitlab has been upgraded 2022-07-03 14:33:09 ncopa: nlplug-findfs: Skipping message due to size=18446744073709551615 2022-07-03 15:01:11 that's a u64 underflow 2022-07-03 15:02:13 right 2022-07-03 15:02:30 That's what's happening on usa7, preventing it to boot automatically 2022-07-03 15:41:48 psykose: is it kernel bug? 2022-07-03 15:43:07 It did start to happen after linux 5.10 2022-07-03 15:43:25 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325 2022-07-03 16:02:22 the code does size_t len = recvmsg(.. but recvmsg returns ssize_t 2022-07-03 16:02:51 so for it to wrap the %zu it has to have -1 returned on error 2022-07-03 16:03:33 is unsigned < 0 legal? :p 2022-07-03 16:03:52 evaluates to false 2022-07-03 16:04:02 relevant code https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs/nlplug-findfs.c#L1393 2022-07-03 16:05:35 gonna guess the real error is obscured as errno is not printed (warnx doesn't) 2022-07-03 16:06:17 and if you patch that size_t into ssize_t and %zu into %zd you'll get the real errno, but that won't fix the real reason 2022-07-03 20:42:51 How should a I package a project which just provides a .so? The library does not seem to have a soname 2022-07-03 20:42:58 And there is no install target 2022-07-03 20:45:43 generally you would need to add all of those yourself, i guess 2022-07-03 20:46:10 The symlinks? 2022-07-03 20:48:10 manually adding the -Wl soname, copying the .so to .so.1, symlinking it back 2022-07-03 20:48:21 but idk, you want to ask upstream, since you then become responsible for checking the abi yourself each time 2022-07-03 20:48:29 or well, i'm saying that, but most of the time nothing ends up using these anyway 2022-07-03 21:49:57 you also end up in the interesting situation of *disagreeing* about the ABI name, which is its own kettle of fish 2022-07-03 22:11:46 sounds like a lot of discussion has to happen with upstream 2022-07-03 22:44:01 is there a policy in place against packages like h1-cli? it literally downloads a random node.js executable from https://github.com/vercel/pkg-fetch/releases/ and packs the whole app source with node_modules 2022-07-03 22:46:57 it should be patched to use system node or whatever it uses but I believe it's not written down as some rule list 2022-07-03 22:48:58 the app itself doesn't depend on it, it's just node; the issue then is 500 dependencies, because it's a typical node project 2022-07-03 22:49:58 well, it also "builds" by running a bash script that creates linux, macos, Windows, and Alpine binaries. 2022-07-03 22:50:12 it still applies for build process, it should use system node 2022-07-03 22:50:16 which seems a bit ridiculous :p 2022-07-03 22:50:24 I'd just patch out that build.sh 2022-07-03 22:51:06 I'd say, remove it 2022-07-03 22:51:14 it has been in testing for 2 years 2022-07-03 22:51:29 clearly maintainer doesn't care about it 2022-07-03 22:51:34 that, and it doesn't build anymore with latest npm anyway 2022-07-03 22:51:46 just move it to unmaintained 2022-07-03 22:51:49 or at least i cannot get it to build, because they use some weird url scheme that's no longer supported 2022-07-03 22:53:10 last release was in 2020 2022-07-03 22:55:14 we should probably go through whole testing and kick everything that wasn't updated for a long time 2022-07-03 22:55:19 panekj: there was a "beta" released 3 days ago, that's why i even noticed this package 2022-07-03 22:56:36 right 2022-07-03 22:57:14 I'll help 10 individuals how to earn $20,000 in just 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message on telegraph by asking me HOW for more details https://t.me/+qs3JtJ8J3v9hMTM8 2022-07-03 22:57:31 great 2022-07-03 22:59:27 telegraph? did we go back in time? 2022-07-03 22:59:33 I'll help 10 individuals how to earn $20,000 in just 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message on telegraph by asking me HOW for more details https://t.me/+qs3JtJ8J3v9hMTM8 2022-07-03 23:00:48 I guess we're going +r again 2022-07-03 23:01:08 why, aren't you interested? 2022-07-03 23:01:21 this is such an incredible offer 2022-07-03 23:02:01 I don't know how to send a telegraph unfortunately 2022-07-03 23:03:06 i'd rather move to libera entirely if it's +r again 2022-07-03 23:07:17 has telegram the chat app now gone lo-tech for the nostalgia? 2022-07-03 23:07:25 fascinating 2022-07-03 23:11:19 I'll help 10 individuals how to earn $20,000 in just 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message on telegraph by asking me HOW for more details https://t.me/+qs3JtJ8J3v9hMTM8 2022-07-03 23:39:40 - . .-.. .-.. / -- . / -- --- .-. . 2022-07-04 07:37:44 morning! ikke: good catch! 2022-07-04 07:41:24 The added warning helped :-) 2022-07-04 07:41:57 You can reproduce it on usa7 2022-07-04 09:26:29 usa7-dev1 [~]# ./nlplug-findfs 2022-07-04 09:26:29 nlplug-findfs: recvmsg: No buffer space available 2022-07-04 09:46:18 ncopa: so the local buffer is too small? 2022-07-04 10:08:59 apparently so 2022-07-04 10:09:15 good morning all 2022-07-04 10:09:15 im increasing it 2022-07-04 10:09:32 Daaanct12: morning 2022-07-04 10:10:51 ikke: its the socket buffer. I believe the problem is that kernel generates uevent messages faster than our userspace manages to handle them 2022-07-04 10:11:20 we could also refactor it to a separate message queue in userspace in a separate thread 2022-07-04 10:11:44 eg a separate pthread that only reads the kernel messages and add them to a fifo queue 2022-07-04 10:12:10 and have a separate thread to get the messages from that queue and handle them 2022-07-04 10:12:20 i believe that is what udev does 2022-07-04 10:14:00 however, we could also just let the kernel queue them. we just need to tell kernel to use bigger socket buffer 2022-07-04 10:16:05 https://tpaste.us/qaJB 2022-07-04 10:16:15 might be an idea to have it configurable though 2022-07-04 10:16:26 so we dont need to recompile next time we hit the limit 2022-07-04 10:59:13 yeah, the size of the kernel buffer really depends on the machine's speed. I've had reports of failures with a 2 MB buffer on slow machines that generate a lot of events :( 2022-07-04 11:00:29 also I don't understand why but the uevents seem to require a buffer that's much bigger than the total size of the strings 2022-07-04 11:00:44 so the kernel-side storage looks pretty inefficient :/ 2022-07-04 11:26:32 how to debug if ash is actually reading $HOME/.profile ? Appears that it started to ignore his content (at least in edge) 2022-07-04 11:28:21 echo something at the start of your .profile? 2022-07-04 11:28:26 did it 2022-07-04 11:28:37 nothing printed? 2022-07-04 11:28:39 just a simple "export PROFILE=1" 2022-07-04 11:28:44 then env does not report anything 2022-07-04 11:29:07 or touch ~/test (: 2022-07-04 11:29:46 i mean if there's DEBUG=3 /bin/ash or something like that 2022-07-04 11:30:08 fcolista: are you sure you are using a login shell? 2022-07-04 11:30:20 It's only sourced for login shells. 2022-07-04 11:30:23 cat /etc/passwd returns /bin/ash 2022-07-04 11:30:28 for my user 2022-07-04 11:30:56 is that on your pc, ssh, or something else? 2022-07-04 11:31:01 my pc 2022-07-04 11:31:17 strace -e openat ash -l 2022-07-04 11:31:31 thx ike 2022-07-04 11:31:32 ikke, 2022-07-04 11:31:39 that's what I was looking for 2022-07-04 11:31:51 always the subtle solutions 2022-07-04 11:32:35 eheh 2022-07-04 13:08:24 Hi. Having an issue compiling Bluez from github repo (allows to get snapshot for a given commit) 2022-07-04 13:08:54 what issue 2022-07-04 13:09:18 ln: unrecognized option: t 2022-07-04 13:09:33 as per https://gitlab.alpinelinux.org/macmpi/aports/-/jobs/758911#L436 2022-07-04 13:10:17 needs coreutils 2022-07-04 13:11:03 my changes: https://gitlab.alpinelinux.org/macmpi/aports/-/merge_requests/9/diffs 2022-07-04 13:11:28 you need coreutils package in makedepends 2022-07-04 13:12:34 or patch whatever it does to not use -t 2022-07-04 13:13:20 just wondering why this does not happen with scm releases 2022-07-04 13:13:53 I have same issue trying to compile plain 5.64 release from github 2022-07-04 13:14:38 while recompiling 5.64 from scm works just fine 2022-07-04 13:17:04 probably something changed in build environment 2022-07-04 13:17:28 diff them and find out 2022-07-04 13:17:49 meant CI 2022-07-04 13:18:20 oh wait 2022-07-04 13:18:28 you replaced source from kernel with source from github 2022-07-04 13:18:49 they probably don't bother making scripts POSIX 2022-07-04 13:18:59 it's the same project 2022-07-04 13:19:12 tarball source is different 2022-07-04 13:19:39 ¯\_(ツ)_/¯ 2022-07-04 13:22:17 sources are same, I made diff. Adding coreutils did help a bit but failed again: it seems it's sth related to ell 2022-07-04 13:22:27 making a bit of progress thanks 2022-07-04 13:24:56 does it work locally? 2022-07-04 13:26:52 don't have a dev machine sety-up locally: just using gitlab build automation for now 2022-07-04 13:28:52 hum... seems like --enable-external-ell option did the trick (except on s390x) 2022-07-04 13:29:17 will test artifacts to be sure 2022-07-04 13:46:52 ncopa: you should also fix the size_t len to be ssize_t since that's the actual recvmsg return type 2022-07-04 13:52:18 anyone knows how to cleanup world packages ? I'd like to remove useless ones now that I learnt apk add --virtual .makedepends-things 2022-07-04 13:52:39 how to detect things that I can safely remove from world 2022-07-04 14:00:54 arf now I'm not even sure about .makedepends virtual package goal 2022-07-04 14:01:27 What is it that you want to achieve? 2022-07-04 14:01:27 tl;dr no easy way 2022-07-04 14:01:40 but generally you can comb through the list and remove anything you don't use 2022-07-04 14:01:51 most likely anything -dev 2022-07-04 14:01:57 anything that ends in -dev or whatever you don't need, etc 2022-07-04 14:03:20 ah okay, abuild -r use --virtual .makedepends-shit with all makedepends packages names 2022-07-04 14:03:34 so I cant just add --virtual .makedepends-shit 2022-07-04 14:03:54 but I now can name virtual package to uninstall everything when I drop this virtual package 2022-07-04 14:04:44 what's the goal? 2022-07-04 14:04:51 let's say I way to hack bemenu, I can `. community/bemenu/APKBUILD` `BBBdoas apk add --virtual .shit-bemenu $makedepends` 2022-07-04 14:04:52 do you want to clean packages after abuild -r? 2022-07-04 14:05:17 I'd like not to fill my world with shity dev packages I use only one times :D 2022-07-04 14:05:31 if you use abuild, it will clean them after though 2022-07-04 14:05:43 when I'm outside of the aport context 2022-07-04 14:06:18 I'm still confused 2022-07-04 14:06:22 apk info -R .shit-bemenu give me the list of packages I gave it 2022-07-04 14:06:39 yap I understood the -t --virtual apk add argument 2022-07-04 14:07:03 panekj: still confused ? 2022-07-04 14:08:17 so basically, you just want `abuild undeps` 2022-07-04 14:09:22 sometime I use aports recipes to know which deps I need to hack a software. So I was just apk adding every makedepends. But that cause rapidly a mess in my world list 2022-07-04 14:09:50 now I can group those deps under virtual packages to uninstall all of them just droping the virtual package 2022-07-04 14:12:36 panekj: thanks for your tidbit: helped-me to nail that ell config difference between github/scm. Not fully sure why it's needed only for github though... 2022-07-04 14:12:48 but "abuild deps" is also great to know. The nobrain way 2022-07-04 14:13:07 I assume the tarballs for kernel.org and github are made different 2022-07-04 14:14:37 since github is just autogenerating a repo snapshot and kernel.org source was pre-made tarball 2022-07-04 14:31:35 quick idea, could be good idea to inform the user when apk upgrades some security fix? Running edge you get constant upgrades and would be nice to know when some needs some care, e.g. linux-lts. is worth to reboot due "Upgrading linux-lts (5.15.51-r0 -> 5.15.52-r0)"? 2022-07-04 14:32:54 since the maintainer already has to add the CVE's to the APKBUILD, it doesn't imply more human work 2022-07-04 14:39:47 Atm, this information is not available to apk 2022-07-04 14:40:21 yeah I suppose, it should be generated by abuild 2022-07-04 15:11:23 psykose: ty for upgrading vkd3d to 1.4 2022-07-04 15:11:27 :) 2022-07-04 15:11:36 did you pushed the commit directly? I did not receive any mail 2022-07-04 15:11:49 lost 10 mins this morning doing the update :< 2022-07-04 15:13:54 along with wine yeah 2022-07-04 15:14:47 could you ping me next time pls 2022-07-04 15:15:48 sure 2022-07-04 15:18:30 ty 2022-07-04 17:24:16 Can somebody please move that issue for me? https://gitlab.alpinelinux.org/alpine/aports/-/issues/13266 2022-07-04 17:25:28 Also, I need some help with abuild/#112, because for some reason the check I implemented is correct at compile time, but fails at install time. https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/112 2022-07-04 17:25:46 (fails as in, does not give the same result as the test at compile time) 2022-07-04 19:53:22 Thermi: I replied to the first issue, does not seem to be an apk-tools issue 2022-07-04 20:03:15 is it only I who get: depmod: WARNING: could not open modules.builtin.modinfo at /tmp/mkinitfs.bz5yHC/lib/modules/5.15.52-0-lts: No such file or directory 2022-07-04 20:03:20 something with the latest kmod? 2022-07-04 20:03:26 got the same today 2022-07-04 20:03:27 Haven't seen it yet 2022-07-04 20:03:40 havent rebooted yet, mostly out of fear 2022-07-04 20:04:31 probably related to kmod as that was the latest change 2022-07-04 20:04:34 rebooting works 2022-07-04 20:04:56 bl4ckb0ne: me neither! :D 2022-07-04 20:05:17 even though I've got zfs snapshots 2022-07-04 20:05:21 so perhaps not fear then... 2022-07-04 20:11:42 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/106 fixes it, though i have no idea what the file even does :) 2022-07-04 20:14:34 omni: yes I noticed the same over the weekend 2022-07-04 20:16:00 psykose: "This file contains modinfo from all modules that are built into the kernel." https://www.kernel.org/doc/Documentation/kbuild/kbuild.txt 2022-07-04 20:16:29 makes sense, though i'm curious how depmod is using it in the invocation afterward if it seemingly doesn't matter and everything is still bootable 2022-07-04 20:16:33 (or i'm just lucky) 2022-07-04 20:17:04 I'm assuming that when a initramfs is created that this file is not present inside where the initramfs is prepped (i.e. /tmp/mkinitfs.bz5yHC) 2022-07-04 20:17:39 whereas it is already present in /boot/ where the linux-lts/linux-virt package places it 2022-07-04 20:19:02 depmod (run by mkinitfs) wants to read it and is warning it is not present 2022-07-04 21:06:21 psykose: looks like it is due to a change in the output_builtin_alias_bin function in kmod 30's depmod.c which now reads the modules.builtin.modinfo file 2022-07-04 21:06:59 makes sense 2022-07-04 21:10:02 psykose: iirc you're not gcc 12'd yet but it might break zfs (i doubt it's gcc's fault, but we'll see what happens) as a heads up 2022-07-04 21:10:12 -fno-tree-vectorize is a workaround (for the now-enabled-by-default vectoriser) 2022-07-04 21:10:12 https://github.com/openzfs/zfs/issues/13605 2022-07-04 21:13:53 interesting 2022-07-04 21:14:06 that other person also seems to not even do that and just change the -march and have it fixed lol 2022-07-04 21:52:05 ncopa: The main/dhcpcd --rundir should be /run/dhcpcd, not /run. That was done in 3154f2947885. 2022-07-04 22:16:03 psykose: someone in the archlinuxarm channel also mentioned that depmod warning lol 2022-07-05 01:27:04 ptrc: if you're the one making !35930, then LGTM 2022-07-05 01:29:32 is indeed 2022-07-05 01:31:38 now the question begs.. when will we get extreme tux racer 0.9 2022-07-05 01:31:43 https://sourceforge.net/p/extremetuxracer/code/796/tree/trunk/NEWS 2022-07-05 01:33:55 probably at '???' 2022-07-05 01:34:03 good time if you ask me 2022-07-05 01:54:33 it's this decade 2022-07-05 01:55:01 also on a date using th 2022-07-05 01:57:49 enjoy your date 2022-07-05 01:58:24 "th"? 2022-07-05 02:03:03 Newbyte: it says ??th, which means it's not e.g. "the 2nd", etc 2022-07-05 02:03:33 hmmm 2022-07-05 02:03:36 very interesting observation 2022-07-05 06:00:35 psykose: Thanks for the work on py3-setuptools. I’m assuming there are still some issues getting it above v60 since it’s currently at v59? 2022-07-05 06:04:15 Also, I was considering moving the Chromium patches into a separate repository (maybe even like how the alpine GCC patches are done, but that would involve a full chromium repo on the Alpine Gitlab servers from what I can tell, and that would be pretty massive, but would make rebasing patches a lot easier). Consolidating the patches would also help with the maintenance burden on all the other chromium derived projects 2022-07-05 06:04:16 (like the qtwebengines) and maybe even electron at some point in the future. 2022-07-05 06:08:39 I’ll have to see if I can get some time to work on such a change (busy with GSOC/LLVM currently), but would you/other people working/using chromium (PureTryOut) be interested in such a patch? 2022-07-05 06:17:30 humm: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28452 2022-07-05 10:18:15 ncopa: what about it? 2022-07-05 10:43:33 ikke: humm commented earlier 2022-07-05 10:43:51 oh lol 2022-07-05 10:44:21 Didn't interpret it as a username :D 2022-07-05 10:54:32 (= 2022-07-05 13:29:39 ncopa: thanks; should have searched for that 2022-07-05 14:59:13 HRio: XSA-403, XSA-405 & XSA-406 just went public! 2022-07-05 15:01:54 I'm on it for edge 2022-07-05 15:18:08 hmm... mostly linux patches but also a choice between patch #1 and patch #2 it seems https://xenbits.xen.org/xsa/advisory-403.html 2022-07-05 15:22:01 is there a typo there or is it me having a hard time piecing together what they mean? 2022-07-05 15:23:50 Don't you need to apply both? 2022-07-05 15:25:10 " 2022-07-05 15:25:12 Two different patches are provided for each Xen branch, but only the first 2022-07-05 15:25:14 patch will be applied to the official Xen repository for each branch." 2022-07-05 15:25:33 So sounds like the 2nd patch is optional and will not be used upstream 2022-07-05 15:25:46 I think I get it now... for xen-unstable patch #1 breaks ABI whereas #2 does not, for the stable branches #2 breaks ABI and #1 does not... 2022-07-05 15:26:11 aha, ok 2022-07-05 15:26:58 right? 2022-07-05 15:54:47 boomanaiden154: i had that idea myself, but actually working with the chromium repository is not 'just a repository to rebase patches on' (as it has like 200 subrepos) and it's a huge pain to actually use the gclient tools with and not any faster than the usual patching method 2022-07-05 15:54:53 maybe you have some better workflow than me though :) 2022-07-05 16:00:01 maybe if you have a workstation with 128 GB RAM and 9000 Mbps nvme drives 2022-07-05 16:01:25 totally forgot i can just get that 2022-07-05 16:01:37 thanks! CLOSED FIXED RESOLVED 2022-07-05 16:02:53 PRIVILEGED WONTFIX 2022-07-05 16:31:39 hello71: Can’t forget the 10gb/s internet connection. 2022-07-05 16:32:25 That you’ll probably never saturate because the chromium code servers can’t even saturate my 200mb/s connection. 2022-07-05 16:35:17 psykose: That’s true. I’ll look into it more and see if I can come with something. Just moving the patches to a separate repository to remove the duplication among all the alpine projects should still be feasible though and should be pretty useful. 2022-07-05 16:38:11 they saturate connections pretty good (because it's cloning like 15 things at once) but you actually get ratelimited at some point lol 2022-07-05 16:39:06 also, the current chromium release does not even have a tarball.. 2022-07-05 16:39:10 https://github.com/archlinux/svntogit-packages/commit/589563cec6ba9e23a67a1470c2da463ecc747e73 :) 2022-07-05 16:39:18 It only doesn’t saturate my connection when doing the main repo clone (doing this outside of alpine) rather than the stuff in the third party tree. 2022-07-05 16:39:29 and i do not want to snapshot this 2022-07-05 16:41:44 Hopefully they get it fixed soon. But if it’s low priority, maybe not. I’ve had a change request sitting on their code review site for a week unreviewed. 2022-07-05 16:53:05 sounds about right 2022-07-05 16:53:17 also hope i haven't broken anything with the chromium upgrades while you were busy :p 2022-07-05 16:54:12 there is #13970 but i can't reproduce it (and when i rebuilt with debugging i can segfault after 2 minutes on anything for some reason, lol) 2022-07-05 16:58:42 It would be really nice if things would just work. I’m sure you’ve been doing a good job with the chromium updates. 2022-07-05 16:59:31 seems to have been the only reported issue so far! haven't done much other than rebasing 2022-07-05 17:29:23 I'm trying to upgrade & fix a test error on electrum: QSqlDatabase: QSQLITE driver not loaded 2022-07-05 17:29:35 it seems that it doesn't have any available driver 2022-07-05 17:30:19 maybe just adding sqlite... 2022-07-05 17:31:45 qt5-qtbase-sqlite is needed probably 2022-07-05 17:31:57 or the qt6- version if it's qt6 2022-07-05 17:31:58 :) 2022-07-05 17:32:02 ok, I will try that 2022-07-05 17:32:18 it's never linked against and has to be manually added 2022-07-05 17:32:27 I don't see any specifyc to qt5/6, so probably it's 5 2022-07-05 17:34:50 >>> electrum: Signing the index... 2022-07-05 17:34:56 thanks psykose :) 2022-07-05 17:35:14 anytime 2022-07-05 17:36:06 raise RuntimeError(f'aiorpcX version {aiorpcx._version} does not match required: 0.22.0<=ver<0.23') , this lib was downgraded because electrum didn't support last version yet 2022-07-05 17:36:16 should I push both upgrades on same MR? 2022-07-05 17:36:49 sure 2022-07-05 17:36:54 ok 2022-07-05 17:42:53 uhmm, something is wrong here 2022-07-05 17:44:47 I think that it has a lot of vendeored libs/packages 2022-07-05 17:44:57 and it runs the tests of them 2022-07-05 17:45:14 so qt5-qtbase-sqlite it's a depednency for some qtpy tests, but don't for electrum 2022-07-05 17:45:30 sure, checkdepends 2022-07-05 17:45:43 this looks a way for running it directly from source without any system dep 2022-07-05 17:45:53 but abuild should only run the specifc electrum tests rigth? 2022-07-05 17:46:47 lol, there aren't tests 2022-07-05 17:46:49 :P 2022-07-05 18:04:25 ouch, the merge url fails 2022-07-05 18:04:50 remote: https://gitlab.alpinelinux.org/donoban/aports/-/merge_requests/new?merge_request%5Bsource_branch%5D=electrum-4.2.2 2022-07-05 18:05:00 shows "Page Not Found 2022-07-05 18:05:58 ops, probably is because i'm not logged 2022-07-05 18:07:42 works for me :) 2022-07-05 18:07:53 hehe 2022-07-05 18:10:42 all fine 2022-07-06 07:05:08 the new gitlab now also selects oneself as the default assignee on mr open unless you unselect it by clicking each time (via webui), fun 2022-07-06 07:29:38 That's pretty annoying and maintainers did not notifications as only bot can find maintainer 2022-07-06 07:45:14 Noice 2022-07-06 07:51:20 yep 2022-07-06 07:51:25 wonder if it can be toggled 2022-07-06 07:51:35 or, the bot could always override first selection, but that's not good either 2022-07-06 09:22:22 ncopa: openssl 1.1.1q had a secfix, technically (though quite low impact), so we should probably roll a release for new images 2022-07-06 09:29:48 boomanaiden154: also fwiw i've had setuptools 60.6 locally this whole time and it's been fine 2022-07-06 09:30:05 the next versions seem easy usage wise, the issue was they now started using the horrific jaraco.* stuff in setuptools 2022-07-06 09:30:16 and the unvendor/vendor of it is fucked, didn't spend much time on it 2022-07-06 09:30:19 i'll have a look at some point 2022-07-06 09:34:27 ncopa: also next openrc is ready !35190 2022-07-06 11:03:50 I'm wondering if a massive modification with grep/sed could be a good solution for #13508 2022-07-06 11:04:47 maybe replacing all "python3 setup.py check" with options="!check", or maybe just deleting the check func so the maintainer sees the warning about missing tests 2022-07-06 11:05:10 I manually revised 3 packages, and the 3 lack tests, so I think that going 1 per 1 is a waste of time 2022-07-06 11:06:57 do they actually lack tests or is it more pypi tarballs :p 2022-07-06 11:07:17 the three that I checked lack tests 2022-07-06 11:07:53 (the python people don't know what a build system is, so half the projects have a pypi tarball with no tests in it, and if you install from a tag instead it installs the tests too along with the package, which is amazing) 2022-07-06 11:08:35 uhM, do you mean that there are tests on the source repository but not in the distributed tarball? 2022-07-06 11:08:43 yes 2022-07-06 11:09:00 well, maybe that can be automated too 2022-07-06 11:09:05 if you see a pypi tarball and no tests it's about a ~70% chance they are in the repo instead 2022-07-06 11:09:17 most APKBUILD have a github or similar url 2022-07-06 11:09:33 I'm gonna check electrum :D 2022-07-06 11:09:56 https://github.com/spesmilo/electrum/tree/master/electrum/tests 2022-07-06 11:09:58 beh 2022-07-06 11:10:25 I'm gonna draft the upgrade MR 2022-07-06 11:10:44 thanks psykose :P 2022-07-06 11:13:59 anytime 2022-07-06 11:15:34 well, downloading it from github tag fixes it 2022-07-06 11:17:49 personally i always just use repo tags, unless upstream specifically says >>>>>>>>>>> releases here <<<<<<<<<<<<<< 2022-07-06 11:18:12 and if they do it's usually because it has the submodules or a special layout, and half the time it's in the same place as the tags 2022-07-06 11:20:48 they do "release here!", with pgp signatures etc.. 2022-07-06 11:21:02 but I think that they target multi-arch so prefer to package all dependecies 2022-07-06 11:26:45 looks good 2022-07-06 11:27:22 =============================================================================== 2 failed, 566 passed, 3 skipped, 503 warnings in 41.57s =============================================================================== 2022-07-06 11:27:24 yeah! 2022-07-06 11:28:20 beh, just test dependencies 2022-07-06 11:28:24 I think it will run fine now 2022-07-06 11:29:31 so I thought that it doesn't have any test and has near 600 :P 2022-07-06 11:30:19 >>> electrum: Signing the index... 2022-07-06 11:30:21 great! 2022-07-06 11:32:33 ouch, is not ammend ok for edit last commit message? 2022-07-06 11:33:12 lol, is --amend* :P 2022-07-06 11:33:24 If it's on a feature branch that has not been merged yet it's fine 2022-07-06 11:35:47 same as any history editing, perfectly okay 2022-07-06 11:36:01 the only branches where it would matter are protected and you can't anyway, even if you were a developer 2022-07-06 11:36:22 ikke: noticed at least all those permission denieds are entirely gone now, so that is a plus! 2022-07-06 11:39:18 Nice 2022-07-06 11:40:37 do you know if there's a way to disable the default-assign thing? where when you open an mr it always assigns you in the create screen 2022-07-06 11:40:42 i assume it's developers only but it's annoying 2022-07-06 11:41:20 !35985 Michal approved it :P 2022-07-06 11:44:15 psykose: not sure, need to look 2022-07-06 11:50:05 thanks psykose, I will think about the other issue, at least with a simple script I could discard all packages lacking tests 2022-07-06 11:55:24 i would not script it 2022-07-06 11:56:00 because the moment you tell me you scripted it i then have to go over it very finely and i will find you actually broke it in 20 places, because scripting this stuff never works :p 2022-07-06 12:03:02 :D 2022-07-06 12:07:12 Check out https://gitlab.alpinelinux.org/kdaudt/apkgquery 2022-07-06 12:15:27 in today's discoveries: busybox's management of utmp in inittab sucks 2022-07-06 12:15:32 (not a real discovery) 2022-07-06 12:16:50 "busybox […] sucks." 2022-07-06 12:17:36 ikke: do we have static builds of gcc? 2022-07-06 12:17:49 Don't think so 2022-07-06 12:17:50 I'm torn between spending time to figure out exactly how to fix it without rewriting half of busybox (it might take MORE time than actually rewriting half of busybox) and saying fuck it, nobody will notice, and the people who do can spend their own energy fixing it 2022-07-06 12:26:43 could you merge https://gitlab.alpinelinux.org/alpine/infra/build-server-status/-/merge_requests/4 2022-07-06 13:39:52 done 2022-07-06 13:44:16 thanks 2022-07-06 13:44:20 needs a rebuild too i think 2022-07-06 19:14:31 psykose: Makes sense. I remember discussing with Ikke the devendoring stuff, but I forgot it started in v60. I think we discussed some solution, but maybe that was just related to the circular dependencies those changes introduce. 2022-07-06 19:16:47 The latest version of py3-setuptools-rust wants py3-setuptools to be on v62 something for some reason. I could probably patch that out if necessary though. I’d like to have that up to date though when it’s moved to community as a dependency for py3-cryptography when rust gets bootstrapped for s390x. 2022-07-06 19:21:42 Starting from v60, setuptools starts requiring all sorts of dependencies, which make bootstrapping it a lot more difficult 2022-07-06 19:29:09 psykose: seems like chromium tarballs should be available soon. https://chromium.googlesource.com/chromium/tools/build/+/cba067232fe2237b85e4cfec7dd73edb2be6a17d 2022-07-06 19:32:15 ikke: Right, but now that we already have a setuptools stage 0, wouldn’t it just be building those dependencies with the stage 0 setuptools and then depending on them in the main setuptools package? 2022-07-06 20:37:37 I recently sent a patch to ~alpine/aports@lists.alpinelinux.org, but it doesn't look like a GitLab MR was created. Is there anything extra I need to do? 2022-07-06 20:38:09 which patch? 2022-07-06 20:40:43 https://lists.alpinelinux.org/~alpine/aports/patches/4118 2022-07-06 20:41:07 lattis: sadly, the bridge does not support follow-ups 2022-07-06 20:41:17 (v2, v3, etc) 2022-07-06 20:41:46 So you need to send them as seperate threads 2022-07-06 20:42:04 ah, I see 2022-07-06 20:42:33 I'm not seeing a MR for my v1 patch either though, is that to be expected? 2022-07-06 20:42:56 No 2022-07-06 20:45:09 lattis: Seems to be an issue, I need to investigate it 2022-07-06 20:46:14 I'll try re-sending my patch as a separate thread too 2022-07-06 20:47:36 For now that won't help 2022-07-06 20:47:52 Ok, I'll hold off then 2022-07-07 03:22:13 boomanaiden154: makes sense. i'll try to bump setuptools soon, but i'm travelling this week 2022-07-07 08:14:20 https://github.com/apache/trafficserver/issues/8887#issuecomment-1176806652 2022-07-07 10:50:10 I guess they are reffering to dlclose, if they want to be able to reload their plugins 2022-07-07 14:21:05 do we have everything we should in 3.16-stable for the 3.16.2 release? 2022-07-07 14:21:54 we should probably pick this one, even if there are no response from upstream 4ffd996b3f8298c7dd424b912c245864c816e354 2022-07-07 14:38:45 working on a couple utmp fixes atm but one of them may involve a busybox bugfix or patch, so probably don't wait for it for the release 2022-07-07 14:39:16 3.16.2? did .1 even come out? 2022-07-07 14:44:23 i meant 3.16.1 ofc 2022-07-07 14:55:44 ah, makes sense :) 2022-07-07 14:58:08 just go straight to .2 :) 2022-07-07 16:57:03 psykose: time machine 2022-07-07 17:36:45 http://ix.io/41RU any idea why fails to install py3-tox? 2022-07-07 17:37:00 other package has exact the same checkdepends="py3-tox" 2022-07-07 17:37:03 and works :\ 2022-07-07 17:37:46 lol, doesn't work. It has options="!check" 2022-07-07 17:38:12 I feel that rootbld doesn't load community repository 2022-07-07 17:42:48 you're in main 2022-07-07 17:42:57 you cannot use packages from community in main 2022-07-07 17:43:10 so yeah, rootbld is correct 2022-07-07 17:43:11 uhM, even for doing tests? 2022-07-07 17:43:49 for tests you can edit the aports/main/.rootbld-repositories file locally :p 2022-07-07 17:43:50 ncopa: 5.15.53 (and others) is out, with patches for XSA-403, -405 & -406 2022-07-07 17:47:09 ptrc: and won't be acceptable to, after doing prepare/build/etc.., and before calling check(), to add community to the repo and install $checkdepends? 2022-07-07 17:47:33 i really don't think so 2022-07-07 17:47:34 if you mean for check phase, alpine packages in main cannot use community packages, even for check 2022-07-07 17:47:50 either one must be moved to community or the other to main 2022-07-07 17:47:52 the alterantive is to move all check dependencies to main 2022-07-07 17:48:04 (or move everything to unmaintained :p) 2022-07-07 17:49:20 uhM, I don't feel that it's a logical policy 2022-07-07 17:49:31 it's like you can only use a debugger on main for debug main packages :S 2022-07-07 17:50:34 if you want to run checks but only run/build things on main, ignore them 2022-07-07 17:50:35 the policy is that packages in main have to be supported for 2 years, and if something depended on package from community, that package implicitly would have to be supported for 2 years 2022-07-07 17:50:43 but if there isn't a strong constraint for it 2022-07-07 17:51:08 yeah that's the question, is a checkdepends a dependency? 2022-07-07 17:51:15 no 2022-07-07 17:51:23 it's a dependency during build 2022-07-07 17:51:30 an optional depndency 2022-07-07 17:51:33 no 2022-07-07 17:51:36 It's also out of practical reasons 2022-07-07 17:51:41 you can skip checks 2022-07-07 17:51:46 or skip checks outside main dependencies 2022-07-07 17:51:51 The way to prevent depends / makedepends on community is to prevent any package from community to be installed 2022-07-07 17:52:03 you can skip checks for local debug purposes 2022-07-07 17:53:17 what do you mean ikke ? I don't see exactly what prevent 2022-07-07 17:53:47 donoban: The way abuild prevents packages from accidentally installing packages from community when building packages in main is to make sure community is not available 2022-07-07 17:55:06 You could probable juggle around with repositories to allow checkdepends from community, but it would add complexity 2022-07-07 17:55:16 ok I get, but in the case of gitlab CI... you push some APKBUILD changes, it tries to build it (without installing any outside community), it built fine, ok, whats the matter with installing now a package from community for running tests? 2022-07-07 17:55:39 All dependencies are installed before building anything 2022-07-07 17:56:17 installing the checkdepends before doing the checks doesn't seem problematic 2022-07-07 17:56:24 again, technically it could be possible to do install more dependencies in between, but that's again adding to complexity (especially with rootbld) 2022-07-07 17:56:25 or I am missing something? 2022-07-07 17:56:41 rootbld disables network by default (with bubblewrap) 2022-07-07 17:57:08 uhM yes 2022-07-07 17:57:17 so you cannot install more dependencies 2022-07-07 17:57:55 well, could be downloaded but not installed until reaching check phase 2022-07-07 17:58:16 adding more complexity 2022-07-07 17:58:43 adding more complexity vs disable tests vs move all to main 2022-07-07 17:59:03 tbh even the "specify repositories for checkdepends separately" thing sounds impractical 2022-07-07 17:59:06 downloaded and not installed doesn't work actually, most things with tests need them at build time to even build the tests 2022-07-07 18:00:07 so maybe the process of build should be full separated from the build+check 2022-07-07 18:00:26 and in the case of build+check let packages from community 2022-07-07 18:00:45 you mean, build stuff separately just for the checks? 2022-07-07 18:01:05 run it twice 2022-07-07 18:01:11 first only for build, only with main enabled 2022-07-07 18:01:11 yay, more build time 2022-07-07 18:01:13 all ok 2022-07-07 18:01:18 yeah that sounds pointless 2022-07-07 18:01:20 so now run with cheks enabled 2022-07-07 18:01:34 double the compute waste 2022-07-07 18:01:45 (: 2022-07-07 18:02:03 donoban: it's a tradeoff 2022-07-07 18:02:24 lot more complexity versus just saying packages in main can only depend on packages in main, even in checks 2022-07-07 18:02:37 the specific thing you are even trying to check doesn't need tox 2022-07-07 18:03:07 sphinxcontrib/? 2022-07-07 18:03:31 2022-07-07 18:03:33 To run the tests with the interpreter available as ``python``, use:: 2022-07-07 18:03:35 tox 2022-07-07 18:04:21 or, you look at `tox.ini` and just run pytest 2022-07-07 18:04:40 and if you look at the other sphinxcontribs there is a comment about a circular dep 2022-07-07 18:05:03 it's also very easy to make a circle here, because pytest needs a bunch of stuff, and a bunch of stuff needs pytest to check, hehe 2022-07-07 18:06:22 well.. 2022-07-07 18:07:21 if you want my advice, delete the check() and add !check i guess 2022-07-07 18:07:36 after bwrp finishes on rootbld 2022-07-07 18:08:06 abuild could reenable network, enable community, install checkpedens, and run again bwrap 2022-07-07 18:08:31 but if there are programs that depend on checkpends during build.. 2022-07-07 18:08:34 donoban: saying what it could do, and implementing it are 2 different things 2022-07-07 18:09:34 yeah, and implementing it and being accepted :P 2022-07-07 18:10:13 Don't forget the tests 2022-07-07 18:10:31 they depend on testing :P 2022-07-07 18:12:51 ddevault: apparently upgrade to 15.0 broke the mailing-list bot 2022-07-07 18:13:00 logs say the token is not accepted 2022-07-07 18:13:08 15.0 what? 2022-07-07 18:13:10 gitlab 2022-07-07 18:13:16 that is very very annoying 2022-07-07 18:13:18 yes 2022-07-07 18:13:23 I love it when other people make busy work for me 2022-07-07 18:13:27 I'll look into it 2022-07-07 18:13:28 I can try to fix it 2022-07-07 18:13:41 but I need to be reminded where we created / added the token 2022-07-07 18:13:49 the other people are gitlab for making breaking changes, to be clear, not anyone here 2022-07-07 18:14:01 not immediately sure what could be wrong, would have to dig 2022-07-07 18:14:13 added to my todo list 2022-07-07 18:16:21 http://ix.io/41S7 tests fails because it misses himself :\ 2022-07-07 18:18:22 you can add `PYTHONPATH="$PWD"` before the command 2022-07-07 18:18:51 (or "$PWD/build/lib" or whatever the correct directory is) 2022-07-07 18:21:22 hmm.. 2022-07-07 18:21:56 on "$PWD/build/lib" there is sphinxcontrib folder 2022-07-07 18:22:04 but it stills failing 2022-07-07 18:25:46 you could try virtualenv then: https://git.alpinelinux.org/aports/tree/main/py3-pytest/APKBUILD#n45 2022-07-07 18:26:55 uhm, does it need py3-virtualenv 2022-07-07 18:26:56 ? 2022-07-07 18:27:16 nope 2022-07-07 18:27:33 there it's been added to checkdepends by mistake 2022-07-07 18:28:43 same error :( 2022-07-07 18:29:30 did you mean something like this http://ix.io/41Sb? 2022-07-07 18:29:49 yup 2022-07-07 18:39:46 ddevault: I see the mailinglist-bot user, but it does not have any access token, nor is there any on the project 2022-07-07 18:40:48 ACTION sighs, pulls up the code 2022-07-07 18:41:48 try to log in as alpine on dispatch.alpinelinux.org 2022-07-07 18:41:53 delete the current hook for patches 2022-07-07 18:41:59 then re-add it, going through the authorization flow again 2022-07-07 18:42:05 ok, will do 2022-07-07 18:42:07 if it breaks, I'll drop the auth row from the database and we can try again 2022-07-07 18:42:15 if it still breaks, back to the todo list 2022-07-07 18:42:30 you'll have to be logged into gitlab as the mailinglist-bot user 2022-07-07 18:42:41 ah right, it was oauth it used 2022-07-07 18:44:49 what kind of token is it? before 15.0 they started mandatory experation of user tokens, i assume bots are different 2022-07-07 18:46:46 regular old oauth token 2022-07-07 18:46:51 goes through the normal oauth 2.0 flow 2022-07-07 18:47:48 ddevault: It says the aports mailing list is already configured 2022-07-07 18:48:04 "Choose a mailing list" 2022-07-07 18:48:15 hang on, delete it again and hang tight 2022-07-07 18:48:33 deleted 2022-07-07 18:48:50 try again now? 2022-07-07 18:49:36 Oh, maybe I misunderstood what happens. I guess you could potentially select multiple lists? 2022-07-07 18:49:50 maybe? not sure 2022-07-07 18:49:55 "Submits a merge request to 2022-07-07 18:49:56 I wrote this a while ago and haven't touched it since 2022-07-07 18:49:57 alpine / aports for every patchset received by the 2022-07-07 18:49:59 aports mailing list. " 2022-07-07 18:50:09 Basically after you select a mailing list, you get the same list again 2022-07-07 18:50:10 it looks like the task is re-configured 2022-07-07 18:50:14 shall I send a patch and see what happens? 2022-07-07 18:50:21 yes 2022-07-07 18:50:29 oh 2022-07-07 18:50:31 sent 2022-07-07 18:50:48 Michael Polansky just upgradded yggdrasil 2022-07-07 18:51:03 so it won't apply 2022-07-07 18:51:09 I'll send another 2022-07-07 18:51:48 done 2022-07-07 18:52:21 It's listed under 'applications' of the mailinglist-bot user ftr 2022-07-07 18:52:26 the oauth token 2022-07-07 18:52:38 the mail server is slow 2022-07-07 18:52:40 it will take a moment 2022-07-07 18:53:36 The token was still there (looking at a our test instance) 2022-07-07 18:53:56 https://i.imgur.com/J3xWiRA.png 2022-07-07 19:04:25 it is not working 2022-07-07 19:04:30 :( 2022-07-07 19:04:59 there is no webhook subscription in place 2022-07-07 19:05:03 Last message in dispatch.log was from an hour ago 2022-07-07 19:05:15 we may have had a sync error while I was deleting rows and you were making tasks 2022-07-07 19:05:20 can you delete and re-create the task again 2022-07-07 19:05:41 ok 2022-07-07 19:06:40 deleted 2022-07-07 19:06:46 do you still need to do something? 2022-07-07 19:06:51 no, you can re-create it now 2022-07-07 19:06:55 ok 2022-07-07 19:07:16 ok, done 2022-07-07 19:07:23 hrm 2022-07-07 19:07:25 there is still no webhook 2022-07-07 19:07:49 I officially give up 2022-07-07 19:07:53 will investigate more later 2022-07-07 19:08:01 I see a webhook in the project 2022-07-07 19:08:07 there is no lists.sr.ht webhook 2022-07-07 19:08:20 ok 2022-07-07 19:08:39 and that webhook in gitlab only gets 404s now 2022-07-07 19:08:42 probably expected 2022-07-07 19:09:02 reset to a ground state 2022-07-07 19:09:09 get rid of the webhook on gitlab and delete the dispatch task 2022-07-07 19:09:12 ok 2022-07-07 19:09:14 then I'll get back to you once I know why it's not working 2022-07-07 19:09:53 Ok, webhook and task deleted 2022-07-07 19:09:57 ty 2022-07-07 19:18:14 Is setting subpackages to empty here a mistake? 5f9ea92a3bc5c730daaebd393206558bfdc8256c 2022-07-07 19:20:04 Hmm, no, probably done on purpose 2022-07-07 19:20:07 they are set later 2022-07-07 19:21:53 not sure what x86 is left with, but eh 2022-07-07 19:22:06 all of that stuff is fucked because we have no noarch 2022-07-07 19:22:16 need to figure out how to use uefi with qemu 2022-07-07 19:22:59 on x86_64 for x86_64, add ovmf 2022-07-07 19:23:00 then uhh 2022-07-07 19:23:01 ikke: I can help 2022-07-07 19:23:03 yea 2022-07-07 19:23:08 big boss here can give you the steps 2022-07-07 19:23:26 I have a VM setup that works with bios, but the latest ed2k package only provides an efi image apparently 2022-07-07 19:23:34 -bios /usr/share/ovmf/bios.bin 2022-07-07 19:23:45 that's what I do now, but won't work 2022-07-07 19:24:05 there's no more bios in edk2? 2022-07-07 19:24:12 not for aarch64 2022-07-07 19:24:21 at least, not ovmf 2022-07-07 19:24:24 what I was using 2022-07-07 19:24:34 ah, you mean before that change 2022-07-07 19:24:39 yes 2022-07-07 19:24:41 3.15 2022-07-07 19:25:01 ikke: "bios" is misleading/confusing in this context as its UEFI. For aarch64 the naming is supposed to be AAVMF (OVMF is x86/x86_64 naming) 2022-07-07 19:25:11 ok 2022-07-07 19:25:31 so I can give it the path of the QEMU_EFI.fd file? 2022-07-07 19:25:54 so I use the following qemu-system-aarch64 options: 2022-07-07 19:26:01 "-drive if=pflash,format=raw,readonly,file=/usr/share/AAVMF/AAVMF_CODE.fd" 2022-07-07 19:26:16 "-drive if=pflash,format=raw,file=./AAVMF_VARS.fd" 2022-07-07 19:26:47 hmm, so that last one is per VM I suppose? 2022-07-07 19:27:02 now that's *not* on an Alpine system - that's on Debian. Alpine has the problem that the aarch64 stuff is built/packages on aarch64, not on x86/x86_64 2022-07-07 19:27:29 the 2nd file is for UEFI variables to be stored, so yes its per VM 2022-07-07 19:27:51 minimal: why is it an issue that the packages are built on aarch64? 2022-07-07 19:28:27 to build a aavmf efi you need an aarch64 toolchain 2022-07-07 19:28:52 we either need actual noarch, or a cross toolchain usable in apkbuilds 2022-07-07 19:28:53 so you'd need to get the AAVMF_CODE.fd and AAVMF_VARS.fd from somewhere to copy them onto your x86_64 machine (assuming you're running qemu-system-aarch86 on a x86_64 machine) 2022-07-07 19:29:15 minimal: no, this is qemu-system-aarch64 on an aarch64 host 2022-07-07 19:29:35 then you should be able to pass that fine, with `aavmf` installed 2022-07-07 19:29:42 yes, I installed aavmf 2022-07-07 19:29:44 ikke: ah, ok, then you need to install the aavmf package to get the files 2022-07-07 19:30:08 minimal: it comes with EFI_VARS.fd, should I copy that for each vm? 2022-07-07 19:30:18 sorry QEMU_VARS.fd 2022-07-07 19:31:11 so copy /usr/share/AAVMF/AAVMF_VARS.fd locally (for the specific VM) 2022-07-07 19:31:30 ok 2022-07-07 19:31:43 then pass "-drive if=pflash,format=raw,readonly,file=/usr/share/AAVMF/AAVMF_CODE.fd "-drive if=pflash,format=raw,file=./AAVMF_VARS.fd" 2022-07-07 19:31:50 to qemu-system-aarch86 2022-07-07 19:31:55 lol 2022-07-07 19:32:03 s/aarch86/aarch64/ 2022-07-07 19:32:03 minimal meant to say: to qemu-system-aarch64 2022-07-07 19:32:08 funny hybrid :D 2022-07-07 19:33:50 ikke: I assume you are also passing appropriate "-machine" and "-cpu" options 2022-07-07 19:34:06 -machine virt,accel=kvm,gic-version=3 2022-07-07 19:34:35 -cpu host 2022-07-07 19:34:46 (I use qemu-openrc) 2022-07-07 19:35:50 ikke: and perhaps "-display none -serial stdio"? 2022-07-07 19:39:10 -serial pty 2022-07-07 19:55:00 openrc-qemu uses -device ide-cd,drive=cdr0, but it complains that there is no ide bus? 2022-07-07 19:55:35 afaik it used to work 2022-07-07 19:57:04 qemu-system-aarch64: -device ide-cd,drive=cdr0: No 'IDE' bus found for device 'ide-cd' 2022-07-07 19:58:07 ikke: I haven't used ide-cd with qemu aarch86, i'm using scsi-cd 2022-07-07 19:58:30 ok, let me try that 2022-07-07 19:58:59 ok, seems to work 2022-07-07 20:00:13 indeed, it booted the iso now :) 2022-07-07 20:00:16 ikke: basically "-device virtio-scsi-device,id=scsi -drive file=filename.iso,if=scsi,format=raw,id=cd0, -device scsi-cd,drive=cd0 -drive file=disk.qcow2,if=scsi,format=qcow2,id=hd0 -device scsi-hd,drive=hd0" 2022-07-07 20:00:36 to give scsi cd and scsi hdd, both via virtio 2022-07-07 20:00:55 you could use virtio-blk instead of virtio-scsi for the disk 2022-07-07 20:01:52 qemu-openrc currently used scsi-hd 2022-07-07 20:20:30 psykose: what testing have you done for recent wine upgrades? it seems like starting any program (including cmd) fails if a valid DISPLAY is attached 2022-07-07 20:22:48 whadya mean by attached? wine cmd works fine for me 2022-07-07 20:24:55 (both wine64 cmd and wine64 display cmd) 2022-07-07 20:25:12 er, start 2022-07-07 20:25:29 does running anything in that cmd like `dir` works for you? it returns `Invalid function.` for me 2022-07-07 20:25:51 yes 2022-07-07 20:27:57 i mean, DISPLAY isn't unset or pointing to an inaccessible X server or something, i.e. winecfg or wine explorer or wine notepad pop up a usable window 2022-07-07 20:30:18 they all work yeah 2022-07-07 20:30:33 and if i unset DISPLAY then it fails with 'make sure ur X is running' 2022-07-07 20:31:38 but wine cmd keeps working? 2022-07-07 20:31:48 what kind of X are you running? 2022-07-07 20:32:54 with it unset nothing shows up, if i unset, start non-display cmd, and try open something you get the error and it keeps working yes 2022-07-07 20:32:55 xwayland 2022-07-07 20:33:24 hm... what kind of wayland? 2022-07-07 20:33:28 sway 2022-07-07 20:34:08 it works for me with alpine xvfb but not gentoo sway/xwayland. let me try alpine sway 2022-07-07 20:34:35 does gentoo sway imply gentoo wine? 2022-07-07 20:35:07 no, it's alpine wine :p 2022-07-07 20:35:32 i'm *pretty* sure gentoo wine works 2022-07-07 20:35:54 what kind of weird frankenstein experiment is this then 2022-07-07 20:36:37 smh i've travelled half the day and had to use gitlab from my phone and now you throw this at me 2022-07-07 20:36:40 :p 2022-07-07 20:37:04 chroot related 2022-07-07 20:39:40 ah, seems someone also reported a wine issue 2022-07-07 20:39:54 #13993 2022-07-07 20:40:16 '2nd party on similar setup' 2022-07-07 20:40:26 wonder who that is, definitely 2022-07-07 20:41:41 nah, i get wine: Unhandled page fault on read access to FFFFFFFFFFFFFFFF at address 00007F2DF57F4858 (thread 0128), starting debugger... and wine hangs 2022-07-07 20:54:24 u should try that in not some weird chroot stuff 2022-07-07 20:54:29 but yes, it's broken with root, hm 2022-07-07 20:54:30 no idea 2022-07-07 21:01:09 i bet it is related to that "Read access denied" 2022-07-07 21:04:01 why would it work as non-root then 2022-07-07 21:04:16 though it does look sussy 2022-07-07 21:08:11 works fine as root for me -.- 2022-07-07 21:09:34 maybe it works on tmpfs root 2022-07-08 08:06:53 was there a cli tool to create merge requests to gitlab? 2022-07-08 08:07:01 aports gitlab that is 2022-07-08 08:08:54 glab 2022-07-08 09:08:23 Yes, glab indeed 2022-07-08 09:59:07 I'm glab there is something 2022-07-08 10:05:57 there's also lab 2022-07-08 10:24:20 :) thanks! i was not able to configure glab properly so it only created an empty MR 2022-07-08 10:24:26 maybe will have a look at it later 2022-07-08 10:27:33 although I've had issues with `lab ci` commands with 0.24.0, perhaps that is solved in 0.25.1 !36097 2022-07-08 10:29:10 I've actually stayed on 0.23.0 to be able to do `lab ci status` and `lab ci trace build-x86_64` etc 2022-07-08 11:19:00 Glab sounds like something done by gnome :D 2022-07-08 15:40:02 bump https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/106 2022-07-08 23:13:45 psykose: Thanks for the work on electron. Being able to run electron apps on Alpine will be awesome. 2022-07-08 23:18:20 time to start counting days until it breaks 2022-07-08 23:21:05 I guess we’ll see. Anything based on Chromium now is actually in somewhat decent shape now that the musl tid caching issue is fixed. 2022-07-09 06:59:34 it actually works fine for vscode for the past month 2022-07-09 06:59:57 but that is the only thing i tried :p 2022-07-09 08:17:36 do any of you know how chromium normally creates a .xz? just a manual xz -e -9 is roughly 2x bigger than whatever they get (the final .tar is 10% larger for electron, but i would assume that does not translate to 2x the size in .xz form) 2022-07-09 08:33:15 I think their build/publish process is public somewhere. 2022-07-09 08:33:37 Are you planning on getting vscode merged into master too? 2022-07-09 08:38:39 https://chromium.googlesource.com/chromium/tools/build/+/refs/heads/main/recipes/recipe_modules/chromium/resources/export_tarball.py 2022-07-09 08:38:43 This is the script right here. 2022-07-09 08:39:30 Lines 219/222 are the relevant xz commands. 2022-07-09 08:39:35 They’re just calling xz -9 2022-07-09 08:40:21 They seem to be deleting some nonessential files/directories though. 2022-07-09 08:42:52 deleting dirs pre-compress would lead to smaller raw tar 2022-07-09 08:43:09 the issue is the tars are basically the same, but if i just compress it it's a whole G bigger 2022-07-09 08:43:17 unless that entire extra G was incompressible 2022-07-09 08:43:25 eh, guess it's fine 2022-07-09 08:44:09 i would add vscode but you can't have extensions 2022-07-09 08:44:16 breaks the licence 2022-07-09 08:44:45 and a vscode without extensions is not much of a package :) 2022-07-09 08:44:56 i have an illegal one on my own repo i guess 2022-07-09 08:45:34 That’s true. It’s annoying that they licensed it that way. 2022-07-09 08:45:43 aye, classic microsoft 2022-07-09 08:46:04 open core, but you need closed components to be actually useful 2022-07-09 08:46:54 I know there is an alternative package store from the official one that theia uses. I might have to dig into the license a little bit. 2022-07-09 08:47:18 that would work probably, assuming they actually have extensions 2022-07-09 08:47:40 They have quite a few (most?). Let me pull it up. Not sure how hard it would be to patch it in though. 2022-07-09 08:47:51 the normal store is 1 line in a json file 2022-07-09 08:48:09 Oh. 2022-07-09 08:48:12 Open VSX. 2022-07-09 08:48:14 https://open-vsx.org 2022-07-09 08:48:17 a few more than one but 2022-07-09 08:48:22 https://git.ddd.rip/ptrcnull/ptrcports/src/branch/master/code-oss/enable-extensions.patch 2022-07-09 08:50:12 the first thing i checked hasnt been updated in 7 months on vsx 2022-07-09 08:50:31 relative to the same extension 2022-07-09 08:50:35 clangd got updated two months ago. 2022-07-09 08:50:59 It’s on the same version as the official marketplace. 2022-07-09 08:51:34 yeah 2022-07-09 08:51:55 The python package is up to date as well. 2022-07-09 08:52:02 rust-analyzer is an eon behind 2022-07-09 08:52:04 wonder who updates those 2022-07-09 08:54:27 Not sure. OpenVSX is backed by eclipse, but I’m not sure if it’s individuals publishing their own packages or if they’re just taking most of the popular vscode extensions. 2022-07-09 08:54:31 well, i guess if they have the same paths that can be patched in, it would work 2022-07-09 08:55:11 There’s also VScodium that you should be able to check. 2022-07-09 08:55:20 I think they use OpenVSX by default. 2022-07-09 08:55:35 ah 2022-07-09 08:55:37 yep, works 2022-07-09 08:56:16 https://github.com/open-vsx/publish-extensions 2022-07-09 08:56:34 There’s this repo that automatically pushes extensions to OpenVSX. 2022-07-09 08:56:55 guess all i need to do is write it in then 2022-07-09 08:57:13 if only i was not on a bus for most of today 2022-07-09 08:57:51 Should be easier than packaging electron. 2022-07-09 08:58:00 Looks like VSCode is good to go then? 2022-07-09 09:00:14 Adding a new published extension is like a single line in a JSON file. Should be pretty simple. Not sure how it’d handle the conflict with the package already existing though. 2022-07-09 09:00:28 Seems like someone started to do it manually and then just let it bit rot. 2022-07-09 09:01:15 yep, seems to be the case 2022-07-09 09:19:34 actually was unrelated 2022-07-09 09:20:52 so yeah, almost fixed 2022-07-09 09:20:59 many months of back and forth, just the last step 2022-07-09 09:22:42 Oh wow. That is a long thread. 2022-07-09 09:22:49 massive indeed 2022-07-09 09:22:50 :3 2022-07-09 09:23:08 done with vscode too, just have to see if vsx works out of the box 2022-07-09 09:23:15 then once it builds, merged i guess 2022-07-09 09:23:56 Then maybe I’ll start actually using Alpine instead of just maintaining packages in docker containers. :p 2022-07-09 09:24:05 haha 2022-07-09 09:24:15 there's probably some rough edges 2022-07-09 09:25:16 Yeah. Can’t knock it until you try it though, and maybe I’ll even be able to contribute to smoothing some of those rough edges. 2022-07-09 09:25:28 you're certainly much better at fixing them than me 2022-07-09 09:25:44 Definitely not. 2022-07-09 09:26:16 The only real thing I’ve fixed was the chromium TID caching issue and someone else did all the debugging for that. 2022-07-09 09:26:30 still amazed it works 2022-07-09 09:27:56 It definitely is a janky patch. But it’s the same thing that was already there for glibc, just adapated for musl’s pthred struct. 2022-07-09 09:28:23 And I still can’t figure out how to make it less janky. 2022-07-09 09:29:21 i mean it works perfectly, can't complain 2022-07-09 09:29:32 the only outstanding random segfaults are ones i can't really reprodce 2022-07-09 09:29:35 reproduce* 2022-07-09 09:30:04 i did have a debug chromium but for some reason it then segfaults every 30 seconds, so that's not very useful 2022-07-09 09:30:18 Yeah. Always nicer to have it upstreamed though so we don’t have to keep rebasing patches. 2022-07-09 09:31:48 I’m going to the LLVM Bay Area meetup on Monday though, so maybe I can find someone there with guidance on attacking that problem from the libc front or someone who would have a better idea of syscalls/ordering. 2022-07-09 09:32:33 Debug chromium is definitely a pain. I haven’t come across any weird segfaults like that, but it’s extremely large and very slow. 2022-07-09 09:33:06 There’s also still the issue with getting CFI working with those clang segfaults. 2022-07-09 09:33:20 yep 2022-07-09 09:33:26 and i think only lto fails too without cfi 2022-07-09 09:33:55 also the issue with lto is usually i build chromium via distcc.. but it does not work for anything with lto in it 2022-07-09 09:34:02 so it's a million years to test that stuff 2022-07-09 09:34:12 but i'm much more fast at it now so i guess i'll give it a go at home 2022-07-09 09:35:04 a whole llvm meetup huh, sounds fun 2022-07-09 09:35:14 Yeah. I forgot we aren’t using ThinLTO. 2022-07-09 09:36:44 We also aren’t using PGO, but with all of the custom stuff we have, we’d probably have to generate the profile ourselves. 2022-07-09 09:37:05 that probably takes a thousand years 2022-07-09 09:37:11 And that means a two stage compile plus lots of tests/each marks in between. 2022-07-09 09:37:19 *benchmarks 2022-07-09 09:37:48 PGO is great though. I think the chromium team saw like double digit percentage performance improvements in some areas after enabling it. 2022-07-09 09:38:01 yep 2022-07-09 09:38:18 i was considering working on it for firefox but.. it's so much code and fragility to set up 2022-07-09 09:38:25 very complex into a build, and takes 50 years 2022-07-09 09:38:39 and if you have more than just two arches, you would probably not do it on half of them 2022-07-09 09:38:56 also there is the outstanding lto issue for firefox on x86_64 anyway which has to be fixed first 2022-07-09 09:39:57 only on x86_64 llvm 'runs out of memory' (while not using any of it), and i can't figure out why 2022-07-09 09:40:43 Interesting. Just straight up LTO does use a ton of memory though. 2022-07-09 09:41:04 it's thin, and passes on all the other arches 2022-07-09 09:41:16 i tried it on a machine with 256gb and even there it fails 2022-07-09 09:41:29 Oh. LLVM seems to have a couple outstanding problems. :pensivebread: 2022-07-09 09:41:39 pensivebread indeed 2022-07-09 09:42:03 but yeah that one would be nice to fix :3 2022-07-09 09:45:33 Definitely. Maybe if I get some time I’ll try and work on the CFI/LTO issues. Looking at how the chromium build failed deterministically, it seems like it would be easy to get a test case out of that. 2022-07-09 09:46:00 Then the low hanging fruit for that is just building LLVM/clang with debug symbols and going through the backtrack. 2022-07-09 09:46:44 Maybe it’ll magically reveal itself there and also be the thing causing the Firefox ThinLTO memory issues. :p 2022-07-09 09:47:08 could be! what is really strange is that it really is x86_64 only 2022-07-09 09:47:20 the opposite of how things normally fail 2022-07-09 11:31:57 Will the next alpine version ship with gcc 12? 2022-07-09 11:34:34 prolly 2022-07-09 11:34:50 cant believe i missed my bus just to package vscode 2022-07-09 11:34:55 lol 2022-07-09 11:34:55 curse of microsoft 2022-07-09 11:35:02 king 2022-07-09 11:36:01 the real reason was my clock was an hour behind because im a moron 2022-07-09 13:27:37 desc should say "with Open-VSX" 2022-07-09 14:38:19 i dont think anyone even reads that 2022-07-09 14:39:05 meet me in warsaw in 9 hours if u disagree 2022-07-09 14:39:14 ok 2022-07-09 14:58:21 psykose: warsaw in which country? ;-) 2022-07-09 15:02:19 the OG warsaw 2022-07-09 15:05:24 surely it's about one of the 10 villages named warsaw in the united states /s 2022-07-09 15:10:38 ptrc: don't call me Shirley ;-) 2022-07-09 15:13:44 the polish warsaw :p 2022-07-09 15:14:24 (before i get on a train and leave a few hours later) 2022-07-09 17:13:16 '[ -n "${APORTSDIR+x}" ] ' <- will that ever evaluate to false? 2022-07-09 17:13:28 -n checksi f the string is empty, but with the +x, it's never empty 2022-07-09 17:13:42 *is not empty 2022-07-09 17:14:06 *with +x the string is never empty 2022-07-09 17:14:33 no, it is empty if APORTSDIR is defined to empty string 2022-07-09 17:14:52 or something like that 2022-07-09 17:16:34 if APORTSDIR is unset 2022-07-09 17:17:37 This is weird and undocumented in the shell 2022-07-09 17:17:48 The shell documents {$FOO:+x} but not ${FOO:x} 2022-07-09 17:17:50 + vs :+? 2022-07-09 17:18:12 ${parameter:+word} 2022-07-09 17:18:12 tuted. 2022-07-09 17:18:12 Use Alternate Value. If parameter is null or unset, nothing is substituted, otherwise the expansion of word is substi‐ 2022-07-09 17:18:25 no occurence of +word 2022-07-09 17:18:30 the `${VAR+something}` syntax is returning `something` if VAR is set 2022-07-09 17:18:30 (in the whole man page) 2022-07-09 17:18:46 https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html mentions it for bash 2022-07-09 17:19:04 Yeah I got the man page open for bash 2022-07-09 17:19:04 so that syntax before evaluates to true if it's unset 2022-07-09 17:19:28 The man page only mentions the :+ notation, not the + only notation 2022-07-09 17:19:38 and it seems they act inverse to each other 2022-07-09 17:19:44 https://tldp.org/LDP/abs/html/parameter-substitution.html mentions it as well 2022-07-09 17:20:19 I'm not going crazy, am I? 2022-07-09 17:20:22 well one, this is probably busybox shell, not bash, but bash says "When not performing substring expansion, using the forms documented below (e.g., :-), bash tests for a parameter that is unset or null. Omitting the colon results in a test only for a parameter that is unset." 2022-07-09 17:20:33 "Both forms nearly equivalent. The : makes a difference only when parameter has been declared and is null, see below." 2022-07-09 17:20:33 Thermi: both of these expansions are posix and well documented here: https://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html#tag_02_06_02 2022-07-09 17:20:33 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html says "In the parameter expansions shown previously, use of the in the format shall result in a test for a parameter that is unset or null; omission of the shall result in a test for a parameter that is only unset." 2022-07-09 17:20:48 Thank you, it's in the paragraph above 2022-07-09 17:20:58 WHICH ONE OF COURSE DOESN'T FIND IF JUST SEARCHING FOR THE NOTATION 2022-07-09 17:21:01 Thank's man page writer :( 2022-07-09 17:21:02 now, in my opinion, this syntax is *terrible*, but it's what we're stuck with 2022-07-09 17:21:11 thank you for your help 2022-07-09 18:00:06 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36170 2022-07-09 18:00:19 I'd like to adopt this package ... 2022-07-09 18:00:45 ... as it is a dependency of synapse (a package I already maintain) 2022-07-09 18:01:15 As it does not have a maintainer atm, that should not be an issue 2022-07-09 18:04:25 oh Contributor must be there ... 2022-07-09 18:04:42 Not really :) 2022-07-09 18:04:58 `https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36170#note_246415` ... 2022-07-09 18:05:22 meh 2022-07-09 18:05:33 the contributor field is meaningless 2022-07-09 18:06:16 But some want it to be there 'in case some one else takes over maintenance' 2022-07-09 18:06:55 well added ... I just wasnt aware of the "must have" condition 2022-07-09 18:07:29 tbh that was just a small nitpick on my side, from what i've seen usually people don't care about this too much 2022-07-09 18:07:55 whatever ... it's ready to merge 2022-07-09 18:09:11 while going through python3 packages ... there are a lot of non-maintained ones :/ 2022-07-09 18:10:12 py3-canonicaljson, py3-bleach, py3-signedjson, ... 2022-07-09 18:20:13 Is having empty, but set build variables (CFLAGS="" for example) a valid use case? 2022-07-09 18:21:38 i would say it is, as it just unsets the stuff from abuild.conf 2022-07-09 18:23:00 I mean in in abuild, I'm sorry for being unclear about it 2022-07-09 18:23:20 If one wanted to remove CFLAGS, why not call unset on it 2022-07-09 18:23:22 unset CFLAGS 2022-07-09 18:23:23 done 2022-07-09 18:23:46 Some use unset, some assign an empty value 2022-07-09 18:23:48 I saw in a build script that they check if HOSTCC is set and then use that, even if it's empty 2022-07-09 18:23:57 That of course breaks if HOSTCC is empty. 2022-07-09 18:24:18 So I wonder having such empty variables is a valid use case for any build environment variable, or just for the flags 2022-07-09 18:24:40 Can't think of anything from the top of my head 2022-07-09 18:25:06 OK, I will presume that it's only OK for flags, but not for binaries, so I will adjust my tests accordingly 2022-07-09 19:20:37 Can somebody please review abuild/!112 and let me know if it's ok? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/112 2022-07-09 19:23:56 Thermi: I enabled the shared runners on your project (something you can do yourself as well), so that CI runs 2022-07-09 19:24:24 Thank you! Shouldn't that be the default? 2022-07-09 19:25:19 I think it takes over whatever the original project had set when you fork it 2022-07-09 19:25:57 I see, then it was just set that way from when I cloned it more than a year ago 2022-07-09 19:25:58 thank you! 2022-07-09 22:02:19 if only people would stop writing software, or at least doing releases, that merge request nuber could get closer to 0 2022-07-09 23:09:22 ^^ instead of saying how impressed I am at how low that number sometimes manage to reach 2022-07-09 23:09:54 not least since I usually have at least one page of stale MRs 2022-07-09 23:13:58 it used to be 530 or so 2022-07-09 23:14:25 ive put too much work into getting it to 330 :p 2022-07-09 23:14:48 the issue page on the other hand.. 2022-07-09 23:16:03 There are also some issues that have been fixed that just never got closed. 2022-07-09 23:16:25 yeah, went through like 40 the other day 2022-07-09 23:16:32 takes a while 2022-07-09 23:17:05 Like #11822, #11223, and #13579 should all be fixed now. 2022-07-09 23:17:06 it's tedious, I try to take a look at the old ones now and then 2022-07-09 23:17:29 I sometimes forget about things I have open 2022-07-09 23:18:15 I just saw an issue that I forgot I had open. 2022-07-09 23:19:25 again, everyone; don't hesitate to open an MR on an aport even when I have one open, not least it's been a few days or more 2022-07-09 23:20:18 closed 2022-07-09 23:20:19 psykose: I'm happy to see all the effort you put into this 2022-07-09 23:20:34 :) 2022-07-09 23:25:46 omni: i'm happy to see all of yours, too 2022-07-10 01:36:46 I'll show you my effort if you show me yours 2022-07-11 12:38:36 psykose: Hello, cpanminus actually works if you don't have perl-libwww installed. Is there a way to make cpanminus install perl-lwp-protocol-https if perl-libwww is installed? 2022-07-11 12:45:41 i guess install_if="perl-libww" on perl-lwp-protocol-https, but no idea 2022-07-11 12:47:19 Yes, I was hoping it could be done in cpanminus itself, without touching other aports 2022-07-11 12:47:47 maybe it could just depend on both? or is there a situation where that could cause issues 2022-07-11 12:50:12 cpanminus only interacts with CPAN, not Alpine's packaging. 2022-07-11 12:50:35 Probably it would make cpanminus have more dependencies, that's all 2022-07-11 12:51:49 Sheila: You're the perl-lwp-protocol-https maintainer, would it be alright if an install_if="perl-libwww cpanminus" was added to it? 2022-07-11 12:52:14 sounds reasonable. 2022-07-11 13:40:48 Sheila: Thanks for the approval. I've also backported the commit to 3.16 as the issue mentioned this being a regression from 3.15. 2022-07-11 13:41:02 reasonable. also approved. 2022-07-11 13:41:10 Thanks again :) 2022-07-11 13:41:15 np 2022-07-11 17:11:18 Ariadne: did you make any progress on debugging D issues with gcc 12.X? is there any other blocker for the gcc 12 upgrade? 2022-07-11 17:11:36 D is the only blocker, and no i have not had much time yet. 2022-07-11 17:12:42 do you have an APKBUILD for gcc 12 somewhere? I will add it to my long list of things to look into then :) 2022-07-11 17:15:01 yeah 2022-07-11 17:15:12 will shoot it over in a bit 2022-07-11 17:34:54 ty 2022-07-11 17:37:17 nmeum: https://tpaste.us/5k97 2022-07-11 18:32:05 asterisk mention gcc 12 fixes in their latet LTS release https://www.asterisk.org/asterisk-news/asterisk-18-13-0-now-available/ 2022-07-11 18:42:40 most of these are not gcc12 fixes but fixes to errors that were always there but are now caught by gcc 2022-07-11 18:48:22 !36266 2022-07-11 22:02:01 Good afternoon. How do I subscribe to a package? 2022-07-11 22:02:09 https://pastebin.com/Ui8Ugtne 2022-07-11 22:03:19 Sorry. Wrong group. 2022-07-11 22:22:11 ncopa: Hello, nicely looking, w/ https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17471 could you also (sub)package Mesa libd3dadapter9? 2022-07-11 22:22:32 s/nicely/👀/, s/looking,//, s/merge_requests/merge\_requests/ 2022-07-11 22:23:13 I would give a shot try some d3d9 game in box86 on pmOS then 😉 2022-07-11 22:24:50 i'm confused what the actual request is 2022-07-11 22:25:23 am I the only one having issues mounting vfat? 2022-07-11 22:25:53 ah, gallium-nine 2022-07-11 22:25:56 omni: what issues 2022-07-11 22:33:07 I don't know, I don't have this issue anymore 2022-07-11 22:33:12 I'm probably just tired 2022-07-11 22:33:25 ~ 2022-07-11 22:33:26 bedtime 2022-07-11 22:34:00 a command that failed a minute ago now doesnt! 2022-07-11 22:34:09 *sigh* 2022-07-11 22:34:49 psykose: yup, who though after so many years since DX9 release there will be people playing on aarch64 tablets and stuff games written for Windows XP :D 2022-07-11 22:35:46 and surprisingly on low-performance devices nine has still pretty low overhead compare to different translation layers 2022-07-11 22:37:16 afaict -Dgallium-nine=true builds without that commit, does it fail at runtime 2022-07-11 22:39:01 hmm, it should fail https://gitlab.freedesktop.org/mesa/mesa/-/issues/5176 2022-07-11 22:39:01 maybe architecture dependent? 2022-07-11 22:40:11 ah, that is 32-bit 2022-07-11 22:40:17 worked for me on x86_64 though 2022-07-11 22:40:18 lets see ci 2022-07-11 22:40:25 https://www.openwall.com/lists/musl/2021/08/03/5 2022-07-11 22:44:00 I loaded the vfat module, then I thought I had unloaded it but probably hadn't why it worked and I was surprised 2022-07-11 22:44:21 but I don't remember when last I had to load that module to mount a vfat fs 2022-07-11 22:51:56 DavidHeidelberg[m]: give !36286 a test if it has what you want, though it fails on aarch64 2022-07-11 22:56:56 though the failure was in some vulkan stuff, seems unrelated 2022-07-11 23:11:46 fixed that and now some other dep fails, feel free to figure it out :) 2022-07-11 23:14:25 "David Heidelberg: give !36286..." <- Thanks, I'm on a phone already (too late here), btw. distros usually calls the package libd3dadapter9 2022-07-12 07:46:31 rewriting the lists => gitlab thing has been on my todo list for some time 2022-07-12 07:46:35 just gonna do that instead of troubleshooting it 2022-07-12 07:48:36 gonna start with running upgrades on the host, so be prepared for a brief outage 2022-07-12 07:56:57 👍 2022-07-12 08:05:08 upgrades done 2022-07-12 08:37:34 ddevault: thank you! 2022-07-12 08:46:13 is there any interest in setting this up for more than just aports? 2022-07-12 08:46:28 I can rig it up to forward patches from ~alpine/devel to the appropriate project (e.g. [PATCH alpine-conf] goes to the right place) 2022-07-12 08:48:28 i think that would be nice, but I don't think it is a priority 2022-07-12 08:48:42 it should not require much additional effort 2022-07-12 08:48:59 my larger goal here is to deprecate dispatch.sr.ht entirely so I'm going to put a little bit more effort into generalizing the solution for this 2022-07-12 08:50:31 👍 2022-07-12 13:25:16 nmeum: did you have any luck yet with figuring out GDC :D 2022-07-12 13:52:24 Ariadne: no, I did not have the time yet to look into it 2022-07-12 14:06:09 btw, anybody know what the status is for rust on s390x? 2022-07-12 14:07:59 i guess they got it to build, but have not done anything else 2022-07-12 14:08:57 so we may be able to bootstrap it for our apk? 2022-07-12 14:13:43 nmeum and psykose say it should be possible to bootstrap it 2022-07-12 14:40:39 someone trusted just needs to run the script and fix the issue that appear along the way I suppose 2022-07-12 14:41:28 alternatively, we could also just use the boostrap package provided in the PR !34493 (not my prefered solution) 2022-07-12 14:56:49 I'll see if I can get bootstrap.sh going 2022-07-12 16:41:45 ddevault, something like git pw (git patchwork integration)? 2022-07-12 16:42:00 not totally familiar with git pw, but I doubt it 2022-07-12 16:42:21 the goal is to improve the system which copies aports patches from the mailing list to gitlab merge requests 2022-07-12 16:43:17 https://patchwork.readthedocs.io/en/latest/ 2022-07-12 16:43:44 https://github.com/getpatchwork/git-pw 2022-07-12 16:44:31 We don't have patchwork anymore 2022-07-12 16:44:36 We used to have it, but gave it up 2022-07-12 18:56:43 fyi, started bootstrap for s390x (rust) 2022-07-12 19:27:39 /usr/lib/gcc/s390x-alpine-linux-musl/11.2.1/../../../../s390x-alpine-linux-musl/bin/ld: /usr/lib/gcc/s390x-alpine-linux-musl/11.2.1/adalib/libgnat.a: error adding symbols: file in wrong format 2022-07-12 19:33:19 you can probably disable it for bootstrap, i don't think it's needed for anything in the path anyway 2022-07-12 19:33:37 (LANG_ADA=false abuild ..) 2022-07-12 19:33:43 though i don't know why specifically it would fail :) 2022-07-12 19:44:08 psykose: thanks, gcc at least built now 2022-07-12 19:44:12 ~ 2022-07-12 19:48:06 meson.build:1:0: ERROR: Could not invoke sanity test executable: [Errno 8] Exec format error: '/home/buildozer/aports/main/openrc/src/openrc-0.45.2/output/meson-private/sanitycheckc.exe'. 2022-07-12 19:48:08 meson 2022-07-12 19:50:48 Is cross compiler: False. 2022-07-12 19:51:13 So I suppose we need to fix meson cross-compiling? 2022-07-12 19:55:26 https://mesonbuild.com/Cross-compilation.html 2022-07-12 19:56:49 Should I just use qemu-s390x? 2022-07-12 20:02:49 for this i need to set up some stuff 2022-07-12 20:03:00 you should just skip openrc as it's not needed (and it's the only meson thing) 2022-07-12 20:03:23 tl;dr you need stuff from here https://github.com/void-linux/void-packages/blob/master/common/build-style/meson.sh#L43-L78 and to generate a cross file 2022-07-12 20:08:00 wjat 2022-07-12 20:08:12 what's the cross build detection? $CHOST != $CBUILD ? 2022-07-12 20:10:55 in bootstrap.sh? 2022-07-12 20:11:56 if [ "$CHOST" != "$CTARGET" ]; then 2022-07-12 20:11:58 in functions.sh 2022-07-12 20:12:25 There is also 2022-07-12 20:12:27 elif [ "$CBUILD" != "$CHOST" ]; then 2022-07-12 20:13:02 skipping openrc for nwo 2022-07-12 20:13:07 i mean they're all set, and when you are cross-building in abuild CBUILD will be current machine and CHOST will be the 'target' of the cross-compiler right :) 2022-07-12 20:13:29 so, in your case CBUILD is x86_64-.. and CHOST is s390x-.. 2022-07-12 20:13:47 (just to make this big ass if block in abuild-meson) 2022-07-12 20:13:53 then i can throw you a modified file to test for openrc 2022-07-12 20:15:23 bootstrap.sh sets CTARGET 2022-07-12 20:16:51 If I read it correctly, CHOST will be set to CBUILD 2022-07-12 20:17:10 and because CTARGET != CHOST, it will not do anything else 2022-07-12 20:17:34 yes, ctarget and chost should match (in this case), but chost and cbuild should not be the same 2022-07-12 20:17:46 unless there terms are not used correctly or i am confused somehow 2022-07-12 20:17:53 can you just echo all three 2022-07-12 20:22:18 not sure where to echo it, but I see bootstrap.sh sets CHOST manually for several abuild invocations 2022-07-12 20:23:10 openssh complains about autoconf/automake missing 2022-07-12 20:23:12 will skip it 2022-07-12 20:23:31 anywhere in an apkbuild 2022-07-12 20:23:35 hmm, something is pulling in openssh? 2022-07-12 20:23:43 libssh2? 2022-07-12 20:23:56 shouldn't normally 2022-07-12 20:24:26 https://tpaste.us/pnRE 2022-07-12 20:25:42 well, it needs host autoconf/automake and they're not part of bootstrap.sh 2022-07-12 20:26:12 can you just echo the 3 variables in any apkbuild part of the cross build process and show me them 2022-07-12 20:27:08 andypost[m]: if given choice for packaging swoole's, swoole or openswoole ? 2022-07-12 20:27:26 psykose: tryiung 2022-07-12 20:27:29 trying* 2022-07-12 20:27:50 but now it's skipping openssh 2022-07-12 20:28:04 oh, I already removed it apparently :D 2022-07-12 20:31:50 vkrishn: I decided to package swoole cos open one looks less maintained 2022-07-12 20:34:40 psykose: it's already at building go, waiting for the build to fail/finish 2022-07-12 20:34:47 oki 2022-07-12 20:35:42 maybe I'll cancel after go, it will build libffi and ghc 2022-07-12 20:36:49 andypost[m]: ok 2022-07-12 20:37:27 psykose: https://tpaste.us/WQMK 2022-07-12 20:37:34 so as expected 2022-07-12 20:37:40 as i thought then 2022-07-12 20:37:49 ok, do you mind testing an abuild-meson in a bit on openrc? 2022-07-12 20:37:56 with that cross config 2022-07-12 20:38:11 from void? 2022-07-12 20:39:15 i will send you an abuild-meson to just overwrite /usr/bin/abuild-meson with 2022-07-12 20:39:24 sure 2022-07-12 20:44:19 you have stuff like 's390x-alpine-linux-musl-gcc-ar' in the cross toolchain right 2022-07-12 20:44:53 Curl fails now without any error message 2022-07-12 20:45:31 here: https://img.ayaya.dev/kr9sGu55Pot6.sh no promises 2022-07-12 20:46:47 The buildroot is quite emptty 2022-07-12 20:47:11 the rest is probably just packages that get installed as dependencies 2022-07-12 20:51:06 Not sure what's going on with curl 2022-07-12 20:53:18 try add bash or something :) 2022-07-12 20:54:31 hmm, it's not make that is failing 2022-07-12 20:59:13 ah, probably [ -z "$BOOTSTRAP" ] && make -C scripts/ returning non-zero 2022-07-12 20:59:34 Adding a print statement after it fixed it :D 2022-07-12 21:02:18 ~ 2022-07-12 21:08:51 https://tpaste.us/gZR5 :( 2022-07-12 21:11:39 psykose: I've replaced abuild-meson with the contents of that script, but seem to get the same issue 2022-07-12 21:13:25 hmm 2022-07-12 21:13:38 hmm 2022-07-12 21:13:47 I think it gets overwritten? 2022-07-12 21:13:53 as it's gone now 2022-07-12 21:14:11 ah, yep, if you delete/reinstall meson it will get removed 2022-07-12 21:14:15 just add it to world 2022-07-12 21:14:18 then overwrite 2022-07-12 21:15:46 meson.build:1:0: ERROR: Unknown linker(s): [['s390x-alpine-linux-musl-gcc-ar']] 2022-07-12 21:17:38 what do you have in the cross root 2022-07-12 21:17:59 just a tree of the bin folders in it or whatnot 2022-07-12 21:18:20 no 2022-07-12 21:19:01 https://tpaste.us/en0B 2022-07-12 21:19:26 well that has nothing at all, so the actual compiler is somewhere else.. 2022-07-12 21:19:41 Those are installed when running bootstrap.sh as packages 2022-07-12 21:19:45 build-base-s390x 2022-07-12 21:19:54 then the contents of that with build-base--s390x 2022-07-12 21:22:13 trying to figure out how this gets installed 2022-07-12 21:22:55 you could tar -tvf the .apk of wherever those are 2022-07-12 21:23:27 alternatively.. i dunno, remove the ${CROSS_COMPILE} prefixes from all the things in abuild-meson 2022-07-12 21:23:35 Not sure whether this should be here or in #alipne-linux. Tell me to move if more appropriate. 2022-07-12 21:23:49 Anyone used pyusb under Alpine? When I try it, I get 'no backends available'. 2022-07-12 21:24:12 I've made a git repo with two containers, one based on Debian, the other on Alpine. The Debian one seems to work Ok, but the Alpine one doesn't. 2022-07-12 21:24:15 Appreciate any advice. 2022-07-12 21:24:16 s390x-alpine-linux-musl-gcc-ar 2022-07-12 21:24:28 so it is there 2022-07-12 21:24:30 psykose: 2022-07-12 21:24:34 this is part of gcc 2022-07-12 21:24:43 hmm 2022-07-12 21:24:48 why does it say it's a linker 2022-07-12 21:24:49 weird 2022-07-12 21:25:30 It's getting late for me 2022-07-12 21:25:45 ah, maybe $LD gets set to AR for something, try delete that 2022-07-12 21:25:50 or i guess i can try a bootstrap myself 2022-07-12 21:26:22 The git repo with the containers is here if anyone wants to try it: https://github.com/adhawkins/pyusbtest 2022-07-12 21:26:59 adhawkins: do you have libusb installed 2022-07-12 21:31:59 psykose: I installed it in the container, yes. Well, libusb-dev and libusb-compat-dev because I wasn't sure which it'd need. 2022-07-12 21:32:17 Actually, I assumed that those would pull in the actual library as well, is that true? 2022-07-12 21:36:40 yes, not sure why it works for me and not you (though that dependency is normally missing) 2022-07-12 21:36:53 This is the output I get: https://paste.debian.net/1247028/ 2022-07-12 21:37:32 ah 2022-07-12 21:37:34 you have no /dev 2022-07-12 21:37:37 just don't run this in a container :) 2022-07-12 21:37:55 Is there a way to make it work in a container? It does with the python container based on debian. 2022-07-12 21:38:10 I want to run it on a synology NAS, which also doesn't have libusb. 2022-07-12 21:38:32 i have no idea, but the issue is whatever containerisation as if i merely add -v /dev:/dev it works 2022-07-12 21:38:49 Oh ok, let me try that. 2022-07-12 21:39:08 (you should not actually do that and i don't think it even works correctly but i guess it fixes this specific issue) 2022-07-12 21:39:39 ah, try /dev/bus/usb only 2022-07-12 21:40:01 works for me 2022-07-12 21:41:20 Hmm, not here... 2022-07-12 21:41:32 My host OS is debian, not sure if that's a factor. 2022-07-12 21:45:46 /dev/bus/usb is in the container now. Odd. 2022-07-12 22:17:36 nmeum: i think i did it, i did a full bootstrap up to openrc with a custom abuild-meson, and it passes :) 2022-07-12 22:19:11 it's not very well tested, i think half the fields are wrong. but since we only need it for meson, that's okay 2022-07-12 22:22:27 tested on old-zstd with meson too, works there. only tested aarch64, but should be the same if the fields are right 2022-07-12 22:24:00 i still use the cheesy makefile for zstd because of their weird support thing 2022-07-12 22:24:06 everything but the makefiles are "contrib" 2022-07-12 22:31:19 the reason i swapped to meson initially was to make it build a bit faster (you know..) then to cmake so that it installs the .cmake files (some things actually want to detect zstd via cmake..) 2022-07-12 22:31:37 but iirc even the FindZSTD.cmake files are contrib? lol 2022-07-12 22:34:58 sam_: don't suppose you by chance know of a place where https://chromium.googlesource.com/chromium/tools/build/+/refs/heads/main/recipes/recipe_modules/chromium/resources/export_tarball.py would be part of a chromium source or how not to just vendor it? chromium doesn't make tarballs for anything but latest-version, so i realised i need to make my own for any release branch, and my .tar.xz's are like 2x as big so i want to improve that a bit 2022-07-12 22:34:58 (starting with their own official script), just wondering if there's a way to use this without needing to copy-paste it into a file myself 2022-07-12 22:52:47 ikke: also starting a s390x-rust bootstrap myself :) 2022-07-12 22:53:05 this bootstrap is easier than i thought it would be, at least for the aarch64 testing.. 'just worked' as the kids say 2022-07-13 00:51:56 everything with a community/ in bootstrap.sh seems to fail with any host dependency, seemingly it cannot find anything built for main/ 2022-07-13 01:05:22 ah, figured it out. of course it's the broken fucking APORTSDIR stuff, because my git remote origin had a trailing slash in it 2022-07-13 01:06:00 which makes repo_template $PWD/community/.rootbld_repositories instead of the actual path 2022-07-13 01:06:02 ghhh 2022-07-13 02:29:42 I'm confused why this aports CI job is failing: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/768572 2022-07-13 02:34:38 oh wow, there was a typo in the APKBUILD. but it passed linting, and there's like 0 info at all in the job output about it failing to parse or ??? 2022-07-13 02:37:58 do you not use an editor with syntax highlighting? are you also using notepad like Saijin_Naib 2022-07-13 02:38:54 Hello71: Ouch. I'm Alpine full-time as the host now, BTW, so I'm using Mousepad thank you very much 2022-07-13 02:39:00 😛 2022-07-13 02:39:08 Hello71: no need to be snarky about it, typos happen and it would be cool if CI actually showed when it fails because of one instead of printing absolutely nothing 2022-07-13 02:39:29 i actually have no idea what's wrong here 2022-07-13 02:40:06 unterminated string quote 2022-07-13 02:40:12 TBH, probably not using Notepad with my handwriting font with easily-distinguishable glyphs 2022-07-13 02:40:35 well i know what's wrong with the apkbuild 2022-07-13 02:40:43 i think the problem is https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L91 2022-07-13 02:41:14 abuild check_arch can exit non-zero if the arch is unsuitable, but also for other reasons, such as the APKBUILD being invalid 2022-07-13 02:42:57 hm, no, that's not right, because Changed aports in isn't printed 2022-07-13 02:44:35 i think the problem is https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/lib/functions.sh#L31 2022-07-13 02:45:07 ap builddirs can also exit non-zero, and with set -e -o pipefail the whole script aborts without explanation 2022-07-13 02:45:26 makes sense 2022-07-13 02:47:07 in bash i think instead of set -e it's usually better to do either set -ex or trap 'echo "$0: $BASH_COMMAND failed"; exit 1' ERR or something like that 2022-07-13 02:47:23 but i don't think busybox ash has BASH_COMMAND or similar, at least from skimming the source 2022-07-13 02:51:45 or better, "$0: $BASH_SOURCE:$BASH_LINENO: $FUNCNAME running $BASH_COMMAND failed" 2022-07-13 02:51:56 Hello71: vim, but I missed it somehow. also, please be nice. 2022-07-13 02:52:17 the notepad really is/was terrible though 2022-07-13 02:54:30 https://git.busybox.net/busybox/tree/shell/ash.c#n2163 says busybox ash has FUNCNAME and LINENO, and apparently LINENO is actually POSIX 2022-07-13 02:58:48 ACTION uploaded an image: (46KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ZInwysGNwGwvkkhLEfxSCSww/image.png > 2022-07-13 02:59:09 Hello71, much better now, right? 2022-07-13 03:00:27 the title and menu bar are unreadable on my admittedly-crappy lcd monitor 2022-07-13 03:00:40 amazing 2022-07-13 03:00:49 and it's very difficult to tell single and double quotes apart 2022-07-13 03:01:01 i mean '"'" just looks like ''''''''''''''' 2022-07-13 03:01:26 and also upper and lowercase letters 2022-07-13 03:01:31 other than that i think it's fine 2022-07-13 03:01:58 oh, and also -X GET is unnecessary and discouraged 2022-07-13 03:02:24 Oh, I have no idea what I'm doing, to nobody's surprise. I'm just trying to piecemeal this together from StackExchange answers 2022-07-13 03:02:28 and i think you're using ' where $( should be used 2022-07-13 03:02:39 or at least you mean $( or ` which maybe your font doesn't even have 2022-07-13 03:02:45 What's your hourly rate? 2022-07-13 03:03:55 if i have to use that font, at least $500 2022-07-13 03:04:42 if you set your whole system to that font then no wonder you can't tell ` from ' 2022-07-13 03:09:18 ACTION uploaded an image: (1704KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/vEzMufMxehTYJlsPtmWdRGMM/image.png > 2022-07-13 03:09:26 Nah, system is set to something reasonable 2022-07-13 03:09:34 🤣️ 2022-07-13 03:11:29 the biggest problem in the picture is the "Microsoft Bing" 2022-07-13 03:11:53 also the microsoft logo is just four squares now? 2022-07-13 03:12:14 Been such going on what, 7 years now? Launch of Windows 10 2022-07-13 03:12:39 Aight, I'm out. I have nothing to contribute here. Just saw the tag and had to defend myself 2022-07-13 03:14:18 i thought it was just the windows logo but apparently it's all of microsoft? 2022-07-13 03:15:16 i mean i think that font is fine, as long as you can distinguish all the letters. i can't read cyrillic but apart from the suspiciously-similar letterforms i don't think the slavic squiggles are inherently worse than the roman squiggles 2022-07-13 03:18:00 (e.g. ц and ч look basically the same at crap resolution without a baseline) 2022-07-13 03:18:26 Very off-topic, but it is an ancient glyph cypher I made when I was learning Traditional Chinese writing, using standard roman glyphs and moving, removing, or transposing one stroke per glyph. I don't use it for anything but binary clock widgets in Conky (since the numbers are all binary quads and look clean in that usage) 2022-07-13 03:18:57 But seriously, I'm fully Alpine all the time thanks to help from you, psykose, Ariadne, et al, so sincerely thanks, and sorry for the Notepad fiasco 2022-07-13 03:21:59 np :) 2022-07-13 03:22:44 it's good to have another troubleshooting diagnosis in the stash, even if it's rarely used. worst case scenario it's a funny story 2022-07-13 03:30:48 not sure how that ibm employee ever built this s390x bootstrap as i don't think the cross-rust build has worked for a while lmao 2022-07-13 03:31:30 psykose: re chromium, i don't know, but i have someone who might, i'll ask 2022-07-13 03:31:34 psykose: re bootstrap: lol i did that recently 2022-07-13 03:31:39 it was.. okay, but there's no real docs about it 2022-07-13 03:31:56 :) needs https://github.com/chimera-linux/cports/blob/master/main/rust/patches/0011-allow-specifying-native-sysroot-to-use-for-linkage.patch to work sanely afaik? idk how else it's going to find system llvm 2022-07-13 03:32:10 think it might work this pass, if not, more stuff to try 2022-07-13 03:32:19 i should also really convert this configure.py into the raw toml 2022-07-13 03:32:28 i spent more time than i want to admit getting really pissed off at the tuple mangling 2022-07-13 03:32:33 are you crossing from amd64 musl or s390x glibc? maybe ibm did the latter 2022-07-13 03:32:35 because it kept trying to coerce it into debian 2022-07-13 03:32:49 the latter sounds like it has a higher chance of "working" 2022-07-13 03:33:17 Hello71: ah, would the latter work with system llvm? without a sysroot it's only finding libLLVM.so in.. system, so i guess perhaps a glibc llvm still kinda works somehow 2022-07-13 03:33:35 or they never tried system llvm, if it builds in-rust-tree that would also work 2022-07-13 03:33:43 fuck if i know :) 2022-07-13 03:33:47 same :) 2022-07-13 03:35:23 i just did in-tree llvm because no pain thanks 2022-07-13 03:35:25 also because rust seems to break often enough with system llvm anyway 2022-07-13 03:35:45 i avoid working with firefox/chromium/llvm/rust/etc just because everything is so heavy and i don't have a 16 core i9 or whatever so the turnaround is long enough that i've forgotten what i was doing 2022-07-13 03:36:29 sam_: does it? i haven't seen anything in months with whatever llvm version 2022-07-13 03:36:58 Hello71: aye, fair. i stayed away for a while too, but i have a 3700x i got used now, so good enough 2022-07-13 03:37:22 the latest issue was uh 2022-07-13 03:37:26 https://github.com/rust-lang/llvm-project/commit/fe8a27acd716a42667f5a572f52f2b04636010ff and https://github.com/rust-lang/llvm-project/commit/67a290460c374d5e0d18a06c798896cac0b19e59 2022-07-13 03:37:28 (https://github.com/ogham/exa/issues/1068) 2022-07-13 03:37:32 but i don't know if it was system llvm that was broken or just the llvm rust shipped 2022-07-13 03:37:38 i was a bit pissed off they didn't do new binaries for it 2022-07-13 03:38:49 both of those commits seem to be patches onto vendored llvm, so i'm not sure how the system one compares 2022-07-13 03:40:06 right 2022-07-13 03:40:19 and i guess in this case using system llvm actually saved me anyway 2022-07-13 03:40:22 cause i could actually patch it 2022-07-13 03:41:02 i think i built exa with 1.61 fine so i suppose it was indeed their own llvm at fault 2022-07-13 03:41:41 ok i might change my mind then 2022-07-13 03:42:06 hey my memory isn't that great you should actually check! 2022-07-13 03:46:12 also a default sysroot of '/' is valid right (just sanity checking) 2022-07-13 08:55:47 morning! 2022-07-13 08:56:48 Morning 2022-07-13 08:57:06 Tried to bootstrap rust on s390x, but llvm13 failed 2022-07-13 08:57:13 i think linux-firmware is broken 2022-07-13 08:57:19 + install -pD /tmp/update-kernel.Mqhatr/root/lib/firmware/brcm/brcmfmac43455-sdio.AW-CM256SM.txt /tmp/update-kernel.Mqhatr/modloop/modules/firmware/brcm/brcmfmac43455-sdio.AW-CM256SM.txt 2022-07-13 08:57:19 install: cannot stat '/tmp/update-kernel.Mqhatr/root/lib/firmware/brcm/brcmfmac43455-sdio.AW-CM256SM.txt': No such file or directory 2022-07-13 08:57:57 what error did you get for llvm13? 2022-07-13 09:00:39 https://tpaste.us/gZR5 2022-07-13 09:14:32 psykose: nice work on the boostrap improvements, I will try to review it soonish :) 2022-07-13 09:42:15 problem with linux-firmware was upstream. i pushed a backport fix for it 2022-07-13 10:18:54 Anyone an idea how to fix llvm13? 2022-07-13 10:19:20 Tried searching for the error, but couldn't find anything 2022-07-13 10:22:27 ikke: no idea 2022-07-13 10:23:09 tmhoang: any idea how to fix crosscompile of llvm for s390x? https://tpaste.us/gZR5 ^^^ 2022-07-13 10:52:28 just for interest how are the riscv builds done? 2022-07-13 10:52:28 since you cant find cheep physical bords to buy 2022-07-13 10:58:14 qemu i think 2022-07-13 11:00:25 yes, qemu 2022-07-13 11:00:49 some devs also have boards (visionfive, hifive unmatched) but those aren't really suitable as a package build server 2022-07-13 11:03:14 qemu-user on a server, with the builds happening in a docker container atm 2022-07-13 11:32:09 im working on https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10518 but i dont have "Authentication suites: PSK SAE" in my neighborhood. Can anyone help me? 2022-07-13 11:33:34 run `iw wlan0 scan | grep Authentication` and if it shows "PSK SAE", can I then get the output of `iwlist wlan0 scanning | grep Authentication`? 2022-07-13 11:34:09 No PSK SAE here either 2022-07-13 11:34:10 I believe the problem is that current setup-interfaces script can only handle the case with "PSK" alone, and "PSK SAE" fails 2022-07-13 11:34:25 only PSK here :\ 2022-07-13 11:34:32 it would help with "PSK " 2022-07-13 11:34:48 thank you for trying though 2022-07-13 12:27:20 how did I not know about abump until today! 2022-07-13 12:27:26 it even generates a commit message 2022-07-13 12:36:49 Habbie: thank you for it 2022-07-13 15:19:17 Habbie: do you know `apkgrel -a .` as well? 2022-07-13 15:19:28 If you just need to bump the pkgrel for some reason 2022-07-13 15:19:49 oh, also neat 2022-07-13 15:19:57 usually i'd be editing then anyway, i guess 2022-07-13 15:20:00 how about we have a single command that can do both 2022-07-13 15:20:02 abump saves me many steps 2022-07-13 19:19:34 ikke: you don't need llvm13, and it's wrong 2022-07-13 19:19:50 rust needs 14 and that builds fine 2022-07-13 19:20:16 i got all the way to the end of the bootstrapping last night, was just trying random things to get rust itself to build 2022-07-13 19:20:35 made a few needed changes i think, but it fails anyway, and passes for other architectures via bootstrap, so i guess i have to try more things 2022-07-13 19:21:24 nmeum: aye, i felt bad i left the meson changes for so long, so i did an (almost) full bootstrap and fixed everything that was broken :) 2022-07-13 19:23:16 ikke: more specifically i think ghc might want 13 if you do actually build everything (so as usual the bootstrap is broken lol), but for this you should remove those 2022-07-13 19:23:29 ah, no, ghc is even 12 2022-07-13 19:23:44 but also disabled on s390x so doesn't matter 2022-07-13 19:26:57 So remove llvm13 and add llvm14? 2022-07-13 19:27:40 And ghc was indeed skipped 2022-07-13 19:42:24 yeah, i merged the change for it even 2022-07-13 19:42:37 ah, let met pull then 2022-07-13 19:42:53 only thing not fixed is openrc and openssh, the rest should work 2022-07-13 19:43:10 but once you get to rust you're gonna get uhh 2022-07-13 19:43:16 Did you also fix curl? 2022-07-13 19:43:25 not that it it matters now 2022-07-13 19:43:48 yep 2022-07-13 19:43:49 https://img.ayaya.dev/M9CVi0A11Dd6 2022-07-13 19:44:08 lots of undefined stuff 2022-07-13 19:44:15 not sure what causes that, initially i thought it was the llvm linking as it was paired with a warning that libLLVM.so from /usr was skipped 2022-07-13 19:44:21 i fixed all of that but it's the same undefined things 2022-07-13 19:44:31 note this exact same path works on, say, x86_64->aarch64 2022-07-13 19:44:40 also the merge request doesn't apply anymore, it needs rebasing 2022-07-13 19:44:43 i can push all my changes to it if you want 2022-07-13 19:46:13 I pulled the current changes and started to build again 2022-07-13 19:46:22 i mean the rust merge request specifically for those 2022-07-13 19:46:29 fine with me 2022-07-13 19:50:31 lemme try one more small hunch first.. 2022-07-13 19:59:41 mm, nope 2022-07-13 19:59:56 still building llvm14 here 2022-07-13 20:00:01 sigh, no idea really 2022-07-13 20:01:45 is ayakael on this chan? 2022-07-13 20:02:24 I told them to join once but I think it never happened 2022-07-13 20:02:39 I have a feeling openresolv is broken since recent 2022-07-13 20:02:44 in the sense that it's not activated 2022-07-13 20:02:57 resolvconf -c works 2022-07-13 20:03:09 bl4ckb0ne: what's the problem? 2022-07-13 20:03:12 But after a dhcp refresh it's reset again 2022-07-13 20:13:20 just more info about that jellyfin port 2022-07-13 20:13:28 the runtimes are a bloody mess 2022-07-13 20:13:47 there's the alpine-arch ones and the linux-musl-arch ones that looks like dupes 2022-07-13 20:14:24 unfortunately dotnet is mess 2022-07-13 20:15:12 thats jellyfin 2022-07-13 20:15:22 i really dont know why they have that 2022-07-13 20:15:26 which is made in dotnet 2022-07-13 20:15:39 I mean whole dotnet ecosystem 2022-07-13 20:16:07 there's libe_sqlite3.so that I think alpine ships 2022-07-13 20:16:17 and libSkiaSharp.so that we have to package 2022-07-13 20:16:28 if the runtime folder is not there, jellyfin will not start 2022-07-13 20:19:00 i think i also have a rpi taking the dust in a box somewhere but setting it up to run alpine would be a stretch 2022-07-13 20:20:27 psykose: hmm, for some reason it does not build rust 2022-07-13 20:20:33 it finished building the kernel 2022-07-13 20:20:39 ah 2022-07-13 20:20:45 rust is disabled still 2022-07-13 20:21:30 panekj: maybe a relevant thread https://github.com/jellyfin/jellyfin/issues/528 2022-07-13 20:21:47 im sure symlinking the runtimes first would be a decent workaround 2022-07-13 20:22:23 but idk if sqlite3 provides libe_sqlite3.so, 2022-07-13 20:29:35 i'm pretty sure it's the same thing renamed 2022-07-13 20:32:41 the compiler-builtins.rlib is indeed missing like all those symbols or whatnot 2022-07-13 20:33:06 How should udhcp know that it should yield to resolvconf? 2022-07-13 20:34:03 bl4ckb0ne sorry, currently out of time due to rust stuff, shoot an email to ayakael (and remind them to join IRC! >:() 2022-07-13 20:34:14 oh, I could just disable it from updating resolv.conf 2022-07-13 20:36:23 hmm 2022-07-13 20:36:29 what if i didn't use systemllvm for bootstrap 2022-07-13 20:36:47 Is that a specific llvm configuration? 2022-07-13 20:37:02 panekj: my bad, i thought you were ayakael 2022-07-13 20:46:12 ikke: the --llvm-root= and target.target.llvm-config values make it use the system llvm instead of the one vendored in-tree 2022-07-13 20:46:22 aha ok 2022-07-13 20:46:28 the compiler-builtin missing symbols normally come from llvm, i'm wondering if it's somehow miscompiled 2022-07-13 20:46:36 just a quick test 2022-07-13 20:46:38 ok 2022-07-13 20:47:04 i'll probably just keep working on this myself, you can do something else if you want in the meantime 2022-07-13 20:47:12 psykose: I suppose you arlready fixed https://tpaste.us/PjXy ? 2022-07-13 20:47:28 yeah, that needed a rebase of the thing 2022-07-13 20:47:28 sec 2022-07-13 20:47:32 psykose: sure, I'm multi-tasking all the time :) 2022-07-13 20:47:57 https://img.ayaya.dev/cXyl8LQyk60h 2022-07-13 20:47:57 here 2022-07-13 20:48:01 rebased version of the MR commit 2022-07-13 20:48:24 everything after that is my own hodgepodge of changes but i'm really not sure what is needed or not anymore so you can have your own adventure if you want 2022-07-13 20:48:32 that will get you to my failure above 2022-07-13 21:13:26 ikke: https://img.ayaya.dev/jqMFK826UVwR.png :) 2022-07-13 21:22:01 tip: don't full-lto llvm with 16 threads all doing lto at once 2022-07-13 21:22:13 You needheh 2022-07-13 21:22:17 hmm 2022-07-13 21:22:44 psykose: I'm now at the same point you are 2022-07-13 21:22:46 with rust 2022-07-13 21:22:57 yep 2022-07-13 21:23:11 gonna see how this goes after llvm finishes linking in.. maybe 10 years? 60G of swap seems like enough 2022-07-13 21:36:15 1GB of RAM per thread would make me nervous even just doing a standard release mode link for LLVM. 2022-07-13 21:36:40 I think I can only get away with 6 concurrent link jobs with 16gb of RAM in some instances. 2022-07-13 21:37:45 the issue was more actually the disk i/o, hah 2022-07-13 21:38:06 i don't know why llvm in main/ builds fine but all of these vendored ones run into this issue, because we don't define link jobs anywhere.. 2022-07-13 21:38:34 easy to override and set them to 2 i guess 2022-07-13 21:38:58 Issue was disk I/O in terms of swap space or just disk I/O in general? 2022-07-13 21:40:43 in general, each link job takes many seconds of 100MB/s to actually link whatever it's doing, so they sit there parked forever 2022-07-13 21:41:03 (and then the memory issue comes in, and then you add in swapping memory on top of that which uses the disk too.. ) 2022-07-13 21:41:26 with less link jobs you dodge all of that at once, yeah 2022-07-13 21:42:32 the current jobs are also 5G of ram per thread, so 2 seems like the lucky choice 2022-07-13 21:42:43 Ah. That makes sense. Perhaps the solution is just NVME RAID. :p 2022-07-13 21:44:29 what i don't understand is why it does lto at all 2022-07-13 21:44:44 nothing passes the LLVM_ENABLE_LTO anywhere.. 2022-07-13 21:45:01 The rust vendored LLVM? 2022-07-13 21:45:04 ye 2022-07-13 21:45:39 no sign of -flto in any generated build files 2022-07-13 21:46:08 cmakecache shows =OFF 2022-07-13 21:46:22 and yet.. ld -plugin /usr/libexec/gcc/x86_64-alpine-linux-musl/11.2.1/liblto_plugin.so -plugin-opt=/ .. 2022-07-13 21:48:13 unless that doesn't imply anything 2022-07-13 21:55:09 error: failed to build archive: invalid e_shentsize in ELF header: 16384 2022-07-13 21:55:11 okay, okay.. 2022-07-14 01:24:07 slowly losing my sanity after 2 days of this 2022-07-14 01:52:39 also there's a strange bug that i've had for a while where if i build rust myself with abuild all the rustlib files are not world-anything (o-a), but in rootbld it's fine 2022-07-14 01:52:42 wonder what causes that 2022-07-14 02:10:00 i'm sending positive vibes psykose 2022-07-14 02:10:16 i think i figured out the main issue, but it will probably fail different now 2022-07-14 02:10:42 it builds the vendored llvm compiler-rt stuff for the compiler-builtin things for.. something? idk 2022-07-14 02:10:56 except compiler-rt-builtins don't have anything for s390x 2022-07-14 02:11:06 or maybe i'm wrong for the 11th time in a row, that is more likely 2022-07-14 02:21:07 Is lists.alpinelinux.org broken right now? 2022-07-14 02:21:22 yes 2022-07-14 02:21:32 (for patches) 2022-07-14 02:21:40 for actual mailing, not sure, worked earlier today 2022-07-14 02:22:46 Will the patches that we've sent appear after it's fixed, or do I need to submit as gitlab MR? 2022-07-14 02:24:33 no idea :) also no idea when it will be fixed 2022-07-14 02:24:35 maybe in a few days 2022-07-14 02:24:38 it's being rewritten entirely 2022-07-14 02:24:51 interesting, thanks for the info! 2022-07-14 03:11:30 and nnope still broken the exact same way 2022-07-14 06:48:39 morning! 2022-07-14 06:49:06 looks dotnet is blocking the (32bit) arm builders 2022-07-14 07:04:24 ncopa: one thing we still should do is moving the edge builders to the new 4096-bits keys. Can we just do the switch and packages and the index would gradually use the new key? 2022-07-14 07:05:30 when was the new pubkeys added? 2022-07-14 07:06:48 yes, if we do the switch index would pick up the new key immediately 2022-07-14 07:06:55 packages will do it gradually 2022-07-14 07:13:13 i would like to do releases 2022-07-14 07:17:13 For 3.15 2022-07-14 07:17:33 So should be widespread now 2022-07-14 07:21:08 ok 2022-07-14 07:22:26 whatta... im trying to reproduce dotnet6-build error on my aarch64 laptop but it fails with weird errors. failed to download https://tarball 2022-07-14 07:22:38 cannot resolve host: tarball 2022-07-14 07:23:30 🤔 2022-07-14 07:24:59 seems like dotnet6-build pulls something from version .106 from microsofts servers, whichc responds with temproarily unavailable 2022-07-14 07:25:28 https://tpaste.us/9b84 2022-07-14 07:25:59 can we nuke dotnet? who uses it anyways? 2022-07-14 07:26:36 Someone did quite some effort to port it to Alpine 2022-07-14 07:27:12 seems like it requires quite some effort to maintain it as well. not even Microsoft has the resources to keep old versions available 2022-07-14 07:28:45 sorry. i should eat breakfast before i continue 2022-07-14 07:29:11 the reason it's frozen is because 4 of them are building at once on the same machine 2022-07-14 07:29:34 were they manually frozen? 2022-07-14 07:29:40 no 2022-07-14 07:29:54 can we manually freeze 3 of them? 2022-07-14 07:30:07 just have to kill the 3.16 ones 2022-07-14 07:30:20 or well, all 4, and restart master 2022-07-14 07:30:23 i dont want to kill it 2022-07-14 07:30:29 just freeze it 2022-07-14 07:31:11 not sure what the point of that would be 2022-07-14 07:31:37 give enough resources for the 4th to complete without restart? 2022-07-14 07:32:05 im gonna have breakfast now 2022-07-14 07:32:20 seems liek the cpu usage is not that bad on the arm machine 2022-07-14 07:32:36 and memory usage is not on the roof either 2022-07-14 07:34:17 but it does not explain why i cannot build it on my laptop 2022-07-14 07:38:17 the error was 'Network unreachable' 2022-07-14 07:38:52 which is not a 404 or anything usually related to the actual remote (i can build it fine) 2022-07-14 08:02:24 maybe it tried ipv6? i dunno 2022-07-14 08:02:47 so we reboot the 3.16 builders? 2022-07-14 08:03:02 how do we unblock the builders? 2022-07-14 08:08:00 you kill all the jobs and restart master only and wait i guess 2022-07-14 08:08:07 (or freeze, same thing) 2022-07-14 08:08:24 i don't actually know why it gets stuck, but it's not the first time, and only happens if all run at once 2022-07-14 08:09:00 there's other aports that do the same, but usually you get oom's instead of actual freezing 2022-07-14 09:09:30 ok. i killed build-{3-16,edge}-{aarch64,armv7} 2022-07-14 09:09:52 and restarted build-edge-armv7. I will reboot build-edge-aarch64 once armv7 is done 2022-07-14 09:10:38 i noticed late yesterday that my linux-rpi build ran out of diskspace. i wonder if that was the cause of dotnet6-build deadlock 2022-07-14 09:11:46 it's my best guess, not sure why it wouldn't self terminate from that 2022-07-14 09:12:40 if it was the `tar -xzf` in the unpacking artifacts section it would..? so probably not that, but i dunno 2022-07-14 09:22:55 I did make space again yesterday evening 2022-07-14 09:32:09 Are there any plans for enabling the kexec syscall for the kernel packaged as "linux-lts"? 2022-07-14 09:33:33 i find it funny how it's enabled for ppc64le only 2022-07-14 09:33:55 Wait does powerpc have kexec currently? linux-lts for 3.16? 2022-07-14 09:34:36 apparently, it's in the config 2022-07-14 09:34:39 Odd 2022-07-14 09:36:00 I dont know if you guys "do requests" per se, but we (the company I work at) could really use CONFIG_KEXEC=y. 2022-07-14 09:36:41 And unfortunately our embedded devices don't run ppc but x86_64 2022-07-14 09:45:33 the ppc config was done by a contributor from ibm (at that time) who didnt really sync it with our other kernels 2022-07-14 09:45:37 re kexec 2022-07-14 09:45:44 > kexec is a system call that is used to boot another kernel during runtime. This functionality can be abused to load a malicious kernel and gain arbitrary code execution in kernel mode, so this sysctl disables it. 2022-07-14 09:45:53 which is why we have not enabled it 2022-07-14 09:46:37 however, it seems that there are a sysctl knob for it? kernel.kexec_load_disabled=1 2022-07-14 09:47:15 i wouldnt mind having it built into the kernel if we have it disabled by default 2022-07-14 09:48:45 Having it available but disabled by default is a wonderful solution. If your attacker has root privs (to edit sysctl.conf) you've already lost the battle anyway. 2022-07-14 09:48:47 it's also disable-once which is nice 2022-07-14 09:49:21 Could we try it out on linux-lts@edge? 2022-07-14 09:56:23 so, im thinking that we could have it off by default at boot, unless enabled from cmdline 2022-07-14 09:56:59 but i wonder if we can enable it if its off by default 2022-07-14 09:57:11 as its disable-once thing 2022-07-14 09:58:40 i dont want disable it in our sysctl default config or in initramfs or in our cmdline 2022-07-14 09:58:46 (if possible to avoid) 2022-07-14 09:59:30 Why would you prefer to not have it in sysctl.conf? Just curious 2022-07-14 10:00:08 because then there is a window before sysctl is run where you can inject kernel backdoors 2022-07-14 10:00:37 and sysctl.conf "service" might be disabled (for whatever reason) 2022-07-14 10:00:57 i generally prefer locked down by default, and then open up as needed 2022-07-14 10:01:49 may also be custom or derivatives that uses our kernel, and they may not disable it in their configs 2022-07-14 10:02:36 Makes perfect sense, thanks for the explanation 2022-07-14 11:19:13 @ncopa have you read this? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7984754b99b6c89054edc405e9d9d35810a91d36 2022-07-14 11:20:37 It seems that once kexec has been disabled, it cant be re-enabled before next boot. 2022-07-14 11:23:21 yes, that's what they mean with disable once 2022-07-14 11:23:50 but the idea is that you cannot rely on sysctls, there is a moment between booting and sysctls being applied that you are vulnerable 2022-07-14 11:32:36 and relying on cmdline arguments (same thing but earlier) is also fragile as there's 500 places where those might be set or removed 2022-07-14 11:35:12 Unless it's to _enable_ it 2022-07-14 11:42:16 yep 2022-07-14 11:42:44 boomanaiden154: firefox lto now seems to have worked locally.. (after an lld segfault that was due to an error but unrelated to initial oom issues) 2022-07-14 11:42:45 so strange 2022-07-14 11:46:25 I cant really tell if alpine has the kernel.perf_event_paranoid=3 patch. Do you guys know? It restricts access to performance events to users with CAP_SYS_ADMIN 2022-07-14 11:52:34 boot option to allow kexec: https://tpaste.us/nVRv 2022-07-14 11:52:38 https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/linux-lts/linux-lts-5.15.54-r0.log contains the line "patching file include/linux/perf_event.h", so some patch has definitely been applied to the file, but I'm not sure if it's the right one. 2022-07-14 11:53:43 hcs: all the patches we use are found here: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/linux-lts 2022-07-14 11:58:17 ncopa: was there any downside to adding -none firmware to the makedeps for kernel? 2022-07-14 11:58:24 so it doesn't install all of those every time 2022-07-14 11:59:07 having `linux-firmware` already in world then adding -any or -none seems to be the same, same for really any existing firmware packages, so it would just save some network/build time 2022-07-14 11:59:14 ncopa: thank you for brewing up a patch for kexec so quickly. Having the kexec_load_disabled toggle on by default but tunable using the kernel commandline is a fine solution. Is there a compile job running in a pipeline somewhere? 2022-07-14 12:06:58 hcs: i havent pushed it anywhere. I created it for discussion 2022-07-14 12:07:19 hcs: maybe you can create an issue for kexec support in our bugtracker? 2022-07-14 12:07:25 so we can discuss it there 2022-07-14 12:08:55 other option is to have a `kexec_load_enable? boot option or similar 2022-07-14 12:09:16 or maybe even `kexec_load=0|1` 2022-07-14 12:09:41 but kexec_load_disable corresponds to the sysctl, which is nice 2022-07-14 12:14:36 https://gitlab.alpinelinux.org/alpine/aports/-/issues/8400 2022-07-14 12:17:36 psykose: adding linux-firmware-none to makedepends for kernel may cause problems for users who have linux-firewmare installed (all of them) and build kernel and reboot during kernel build 2022-07-14 12:17:39 I'll create an issue 2022-07-14 12:17:51 as it would uninstall all the firmware during build 2022-07-14 12:18:51 linux-firmware and linux-firmware-none at the same time has all the firmware installed 2022-07-14 12:19:27 Most users would not have linux-firmware installed explicitly 2022-07-14 12:38:03 ncopa: I've opened an issue (https://gitlab.alpinelinux.org/alpine/aports/-/issues/14017). I'm not sure what you want in there except what we've discussed just now 2022-07-14 12:58:00 hcs: thanks! 2022-07-14 12:58:57 psykose: I'm ok as long as it does not uninstall any firmware while building the kernel 2022-07-14 12:59:32 there is a case where it does- if people have no linux-firmware-anything/linux-firmware added, and the world deps have only -any, then -any+-none uninstalls things, so i guess it can't be done 2022-07-14 13:05:04 what i do in my containers is to install linux-firmware-none 2022-07-14 13:05:09 me too 2022-07-14 13:05:24 we could probably do so on the builders as well 2022-07-14 13:22:19 ncopa will the CI pipelines still run if i fork aports in order to make a MR? 2022-07-14 13:33:15 not sure. i think you may need to enable the shared runner and have your fork public 2022-07-14 13:46:22 That should work by default 2022-07-14 13:49:53 ncopa: so I'm going to switch the edge builders to the new key 2022-07-14 13:50:17 ncopa: what is the point of disabling kexec without disabling or signing modules 2022-07-14 13:50:53 "13:05 we could probably do so on the builders as well" i have suggested this in past, no comments received iirc 2022-07-14 13:51:22 actually i think i suggested doing this for alpine-gitlab-ci/build-base, but similar idea 2022-07-14 13:52:10 ncopa: should we make some anouncement somewhere about edge keys changing? 2022-07-14 14:16:17 ikke: i think that would be a good idea 2022-07-14 14:17:05 Hello71: adding linux-firmware-none to alpine-gitlab-ci/build-base sound slike an excellent idea 2022-07-14 14:20:29 i would have sent MR but i couldn't decide between alpine-gitlab-ci, build-base, and alpine 2022-07-14 14:22:32 I suppose build-base would make sense. Generally when you are building things in docker, you don't need linux firmware 2022-07-14 14:38:10 ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/48 2022-07-14 15:09:32 ikke: merged to master 2022-07-14 15:10:14 the dotnet6-build packages are now done on build-edge-a*, and build-3-16-aarch64. build-3-16-armv7 is in the queue 2022-07-14 15:27:31 ncopa: alright, we start setting the new signing keys then 2022-07-14 15:33:57 great! thanks! 2022-07-14 15:37:27 ncopa: done 2022-07-14 15:38:43 Pushing the anouncement to production now 2022-07-14 15:39:19 👍 2022-07-14 16:09:59 boomanaiden154: nvm, spoke too soon.. everything worked with pgo then back to the same oom trick 2022-07-14 16:09:59 gr 2022-07-14 17:23:44 hello 2022-07-14 17:23:44 has any one successfully installed either mit-scheme or reduce cas? 2022-07-14 17:24:03 It seems there is a problem with both of them 2022-07-15 05:50:21 i tagged an edge release 2022-07-15 06:24:00 something went wrong with aarch64 edge release 2022-07-15 06:24:57 the latest-releases.yaml didnt add minirootfs entry 2022-07-15 06:24:59 dont know why 2022-07-15 06:38:47 i know why 2022-07-15 06:39:08 release scripts are buggy 2022-07-15 15:53:05 original dl site? 2022-07-15 15:53:05 ncopa, nmeum: dropbear's main site (in Australia) as well as its mirror (dropbear.nl) are down on a regular basis. Until something like a year ago (when I last used dropbear), the .nl mirror was reliable, but it looks like it's not anymore. I'm currently patching the dropbear apkbuild to handle utmp correctly; permission to grab the dropbear tarball from github instead of the non-working 2022-07-15 15:56:28 i don't think the tarball would be the same 2022-07-15 15:56:48 if the only difference is needing to run autoreconf then i guess it would be alright 2022-07-15 15:56:54 australia one worked for me 2022-07-15 15:57:14 that is true, but against all odds the github mirror does provide a configure script even in the git head 2022-07-15 15:57:40 so it's one of the rare cases where the gh-provided tarball is usable 2022-07-15 15:58:40 how the heck is it working for you 2022-07-15 16:00:58 ah, got it, it only works with ipv6. But still provides an A record. -_- 2022-07-15 16:01:29 LMAO 2022-07-15 16:01:49 welcom to the future :) 2022-07-15 16:01:52 how the !@#$%^ am I supposed to test with my *&%$#^ ISP who still doesn't know that IPv6 is a thing 2022-07-15 16:02:09 mine doesn't either i'm using a HE tunnel 2022-07-15 16:02:59 guess I have nothing better to do on a Friday evening than set up a static route to matt.ucc.asn.au on my router via the alternate provider who has heard of ipv6 2022-07-15 16:03:14 ~ 2022-07-15 16:03:31 hm, it works over ipv4 though? 2022-07-15 16:03:48 it hasn't worked for me in over 5 years 2022-07-15 16:04:26 maybe your isp is blocked, some random US universities really like doing this kind of stuff and i have to use a proxy to download some sources for stuff in aports 2022-07-15 16:04:27 i think you got some weird geomeme routing then 2022-07-15 16:04:56 try a traceroute to it 2022-07-15 16:05:04 wait, but it's cloudflare 2022-07-15 16:05:19 and compare to v6; if only the last hop changes it would be some config on v4-only to block you for some reason 2022-07-15 16:05:55 i don't think it's possible to compare v4 traces to v6 :p 2022-07-15 16:06:07 by changes i mean breaks 2022-07-15 16:06:11 unless you look up every ASN on the way or something 2022-07-15 16:07:23 I tried v6 from another machine, not mine, since my default provider can't tell v6 if it bites it in the ass 2022-07-15 16:07:56 so maybe it's an ISP blockade, not a v4 blockade 2022-07-15 16:09:40 i don't think regular customers can drop traffic, so if cloudflare blocked your isp, condolences 2022-07-15 16:11:18 it can't be the only site I access that uses Cloudflare though 2022-07-15 16:11:48 can you give me another well-known Cloudflare customer domain, so I can test? 2022-07-15 16:14:12 19 130.95.13.1 (130.95.13.1) 293.073 ms !A 295.024 ms !A 294.612 ms !A 2022-07-15 16:14:20 that's interesting, man traceroute doesn't say what !A means 2022-07-15 16:14:39 "administratively prohibited" would be !X 2022-07-15 16:15:16 !A is too 2022-07-15 16:15:39 thanks, incomplete man 2022-07-15 16:15:51 aren't we all 2022-07-15 16:16:15 I should have thought of this one 2022-07-15 16:19:14 as for cf customers, fiverr.com and canva.com seem to be using similar ip blocks 2022-07-15 16:19:36 but as with any networking giant, ymmv 2022-07-15 16:20:07 thanks. I can access these two np. as well as ucc.asn.au. It's just matt who hates me. 2022-07-15 16:20:18 does it drop packets completely? 2022-07-15 16:20:45 I suppose, because a normal connection times out instead of telling me it's rejected 2022-07-15 16:20:50 only traceroute says !A 2022-07-15 16:20:54 ah, that's.. weird, matt.ucc.asn.au returns the same address for me as just ucc. 2022-07-15 16:21:11 even with v4? 2022-07-15 16:21:22 yeah, i mean specifically v4 addresses 2022-07-15 16:22:08 disagree: 2022-07-15 16:22:13 alpine:~$ s6-dnsip4 matt.ucc.asn.au 2022-07-15 16:22:13 alpine:~$ s6-dnsip4 ucc.asn.au 2022-07-15 16:22:13 130.95.13.18 2022-07-15 16:22:13 104.26.8.126 2022-07-15 16:22:13 172.67.72.143 2022-07-15 16:22:14 104.26.9.126 2022-07-15 16:23:16 hmmm, are you using your isp's dns? if so, can you check what 8.8.8.8 and 1.1.1.1 return for you? 2022-07-15 16:23:54 I'm using my own DNS resolver, tyvm 2022-07-15 16:24:16 the answers I gave are exactly the ones published by the DNS servers out there 2022-07-15 16:25:17 d.au seems to return fay.ns.cloudflare.com. and leland.ns.cloudflare.com. for ucc.asn.au 2022-07-15 16:25:32 https://img.ayaya.dev/W11kL5BjBVBY 2022-07-15 16:25:35 where does this 130 come from 2022-07-15 16:26:10 s/d.au/t.au/ 2022-07-15 16:26:10 ptrc meant to say: t.au seems to return fay.ns.cloudflare.com. and leland.ns.cloudflare.com. for ucc.asn.au 2022-07-15 16:26:39 psykose: okay, time for some serious DNS investigation. That I know how to do. 2022-07-15 16:26:46 ~ 2022-07-15 16:27:24 even more results for fun: https://dnschecker.org/#A/matt.ucc.asn.au 2022-07-15 16:36:31 okay, thank you both for your help, it's working, nothing to see here, move along 2022-07-15 16:36:49 what happened? :) 2022-07-15 16:37:05 what part of "move along" do you not understand 2022-07-15 16:37:17 ACTION moves alone 2022-07-15 16:37:17 :D 2022-07-15 16:37:20 along* 2022-07-15 16:37:21 gdi 2022-07-15 16:37:28 freudian slip 2022-07-15 16:37:31 nothing to see there either, move along :) 2022-07-15 16:37:54 I'll show you mine if you show me yours 2022-07-15 16:38:14 kinky 2022-07-15 16:47:37 neither openssh nor tinyssh nor dropbear has ever tested a build with utmpx, and dropbear even less than the other ones 2022-07-15 16:47:57 the other ones don't work ootb, but at least they *build* 2022-07-15 16:48:06 jfc 2022-07-15 17:58:45 it's always dns 2022-07-15 17:59:34 yeah, and sometimes it's the workarounds for DNS fuckery that you put in place ages ago, and *might* have forgotten to remove when they weren't relevant anymore 2022-07-15 18:03:18 ACTION looks up 2022-07-16 00:12:01 is there any way to get the old ncurses tarballs? this dumbass idiot project has no git or any old tarballs, and so the '6.3-2021..' tarballs don't exist anymore and the only thing i see is either the latest ones or a bunch of patches but they seem like they would need to add 30 patch urls to get it to the same version (6.3 -> 6.3-2022..) .. 2022-07-16 00:14:06 specifically, 6.3-20220416 fixes a random cve, the fix is in the patch ( https://github.com/mirror/ncurses/commit/4c9f63c460cb7134f142aa65f6866c175ed77605 ), but actually trying to backport this to <=3.15 is impossible because the source for the 20211120 tarball is gone (https://invisible-mirror.net/archives/ncurses/current/ keeps only the last 30 or so, and there doesn't seem to be a real archive) 2022-07-16 00:17:26 ah, seems the github mirror tarballs are actually identical.. 2022-07-16 00:18:18 so you found it? 2022-07-16 00:18:19 yep, aside from mtime they're completely the same 2022-07-16 00:18:22 indeed i did 2022-07-16 00:18:26 thanks random github mirror 2022-07-16 00:18:31 ah nice. I started looking too :P 2022-07-16 00:19:04 `diffoscope --exclude-directory-metadata=yes` is squeaky clean for latest 2022-07-16 00:22:01 does the sha512 match? 2022-07-16 00:22:50 no, due to the metadata difference 2022-07-16 00:22:58 ah ok 2022-07-16 11:04:10 Ariadne: re gcc 12.X: where can I find gphobos-ucontext.patch? contrary to all other patches from https://tpaste.us/5k97 it doesn't seem to be included in the alpine-gcc-patches repo 2022-07-16 11:32:31 it was just a local fix i was trying 2022-07-16 13:11:16 psnszsn: you should see the bullshit i came up with 2022-07-16 13:11:20 sorry psykose * 2022-07-16 13:12:05 the huge PATCH ARRAY 2022-07-16 13:12:07 i didn't realise he actually yanked the old rollup tarballs though 2022-07-16 16:01:48 boomanaiden154: I see that you created https://github.com/boomanaiden154/matplotlib-test-images 2022-07-16 16:01:55 is it possible to include rv64 as well? 2022-07-16 16:03:28 Yes. I should be able to do that. 2022-07-16 16:03:45 I was trying to test if it builds again on rv64 2022-07-16 16:04:02 Were you able to get it building? 2022-07-16 16:04:27 Not yet, I'll skip the prepare step that it's blocking on now 2022-07-16 16:13:39 It doesn't seem to fail on configure anymore at least, which is why I (apparently) disabled it 2022-07-16 16:13:44 waiting for the build to finish 2022-07-16 16:16:45 Okay. I’ll try and get a commit in this afternoon to enable test image generation on riscv. 2022-07-16 16:17:05 alright 2022-07-16 16:17:15 Doesn’t cost me anything since the GitHub CI does everything and all the artifacts are stored on GitHub. 2022-07-16 16:18:12 (This afternoon being in a couple hours for me.) I’ll see if I can start the CI earlier though. 2022-07-16 16:18:31 ptrc: hi, do you maintain the labwc package? 2022-07-16 16:21:51 boomanaiden154: ok, build succeeded 2022-07-16 16:39:42 boomanaiden154: still lots of test failures. I assume that's because it uses generic images not tailored to the arch? 2022-07-16 16:40:15 'images not close 2022-07-16 16:40:26 880 failed, 5897 passed, 1585 skipped, 13 xfailed 2022-07-16 16:41:58 I'll await your update :) 2022-07-16 16:43:20 ikke: yes. The test images are non arch specific and you get a bunch of misc test failures because of it. 2022-07-16 16:43:36 Still some with arch specific images (mostly on ppc64), but significantly less. 2022-07-16 16:43:44 ikke: https://github.com/boomanaiden154/matplotlib-test-images/actions/runs/2682510504 2022-07-16 16:43:55 Just out of curiosity, what causes these differences between arches? Different floating point handling? 2022-07-16 16:45:03 I started the CI with Riscv64 support and deleted the current release. If all goes smoothly, riscv64 images should be ready in a couple hours (QEMU emulation on dual core GitHub actions machines is slow). 2022-07-16 16:45:18 Great, thank you 2022-07-16 16:47:30 I haven’t done a ton of investigation into the root cause. Could definitely be floating point handling with matplotlib it doesn’t tie into any underlying graphics libraries. 2022-07-16 16:48:21 ok 2022-07-16 16:49:02 There also seem to be some architecture specific test failures with VTK, but that seems to be related to architectural differences in graphics library output, but I guess that could be floating point too. 2022-07-16 18:27:28 ikke: Riscv test images for matplotlib should be there. 2022-07-16 18:27:36 ok, let me check 2022-07-16 18:27:58 Hopefully they work well. 2022-07-16 18:29:06 checksums haven't changed 2022-07-16 18:29:16 oh, need to remove cache :P 2022-07-16 18:31:29 boomanaiden154: still don't see riscv64 in the archive 2022-07-16 18:32:07 curl -L https://github.com/boomanaiden154/matplotlib-test-images/releases/download/matplotlib-3.5.2/matplotlib-images.tar.gz | tar tz | grep riscv 2022-07-16 18:33:59 It’s not under riscv64? 2022-07-16 18:34:28 Oh. I probably forgot to change the script that copies the files over. 2022-07-16 18:35:11 $CARCH in an APKBUILD on riscv on Alpine just evaluates to riscv64, right? 2022-07-16 18:35:17 yes 2022-07-16 18:38:11 I’ll get the script reworked and hopefully recreate an archive with all the correct artifacts without running the pipeline again once I’m done with lunch. 2022-07-16 18:38:14 Sorry about that’s 2022-07-16 18:38:19 *that 2022-07-16 18:38:58 No worry, happens 2022-07-16 19:47:17 Hello, I want to create a package for a program which propose a test script that needs docker and docker compose 2022-07-16 19:47:46 The builders do not have docker running 2022-07-16 19:48:11 Is that something acceptable in a package to require docker compose as a test dependency ? 2022-07-16 19:49:07 There is no docker running, so those tests would fail 2022-07-16 19:49:36 tests should be skipped 2022-07-16 19:50:37 And if I add `checkdepends="py3-pytest"` 2022-07-16 19:50:49 Woops wrong paste 2022-07-16 19:51:15 `checkdepends="docker-compose"` 2022-07-16 19:51:31 That would not suddenly make docker available 2022-07-16 19:51:43 And docker won't run on the builders 2022-07-16 19:54:03 Ok 2022-07-16 20:43:33 Is there something to automagically fix scripts in sources with shebang python instead of python3, or do I have to write a patch for that ? 2022-07-16 20:46:12 https://pkgs.alpinelinux.org/package/edge/main/x86_64/pythonispython3 2022-07-16 20:46:50 I don't think there is a helper to automatically patch these scripts 2022-07-16 20:49:16 I see 2022-07-16 20:50:01 wasn't there supposed to be symlink by default since we dropped py2? 2022-07-16 20:51:29 Apparently there isn't 2022-07-16 20:51:43 that I already know 2022-07-16 20:56:13 I suppose it's still on someones todo list 2022-07-16 20:57:38 Why should there be such a symlink? The correct shebang for Python 3 arguably ends in python3. 2022-07-16 20:58:00 sam_: it's really a work of art lmao 2022-07-16 20:59:41 ikke: not really a todo list, but i can do it if you want 2022-07-16 21:01:48 raspbeguy: note the shebang doesn't matter if you can invoke whatever program yourself (python3 xyz.py), and shebangs also get rewritten by python installation (most of the time), so the only time you have to patch those is if some test is directly invoking them 2022-07-16 21:02:41 psykose: yes 2022-07-16 21:02:46 in this case, you should patch it 2022-07-16 21:03:32 Hum I fixed it by just adding pythonispython3 as a dependency 2022-07-16 21:04:22 that's not for anything to depend on :) 2022-07-16 21:04:31 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36468 2022-07-16 21:04:51 Why not? 2022-07-16 21:09:55 because it's the equivalent of just removing it and adding the symlink to main/python3 anyway 2022-07-16 21:10:08 i guess i added it as a convenience for some testsuites and for people to be able to pick it themselves 2022-07-16 21:32:39 psykose: ok so in this case you think it's better to patch? 2022-07-16 21:32:51 If so I'll do it later 2022-07-16 21:34:46 yes 2022-07-16 22:37:46 Ariadne: I believe I fixed the gcc 12 gdc issue and with some additional patches (and without gcc-go) it builds fine on x86_64 now but also needs some love on other architectures it seems (see !36469) 2022-07-16 23:35:36 ikke: Test images for riscv64 should hopefully be ready now. 2022-07-17 05:35:48 boomanaiden154: it indeed now contains the riscv64 directory. Running the test suite now 2022-07-17 05:35:54 boomanaiden154: thanks 2022-07-17 05:45:53 ikke: Did all the tests pass with the updated images? 2022-07-17 05:48:10 Still running, but everything seems geen (or skipped) so far 2022-07-17 05:50:25 6777 passed, 1585 skipped, 12 xfailed, 1 xpassed 2022-07-17 05:53:49 boomanaiden154: so yes, everythign passed 2022-07-17 05:55:01 Nice. Wasn’t that easy on some of the other architectures. 2022-07-17 05:55:09 I’m assuming I’ll see a PR soon to enable support? 2022-07-17 05:55:20 yes 2022-07-17 05:55:35 Thank you for your work on this. 2022-07-17 05:59:27 np 2022-07-17 06:00:06 boomanaiden154: FYI, on CI we don't have riscv64 yet, so we cannot verify there if it works 2022-07-17 06:01:25 !36472 2022-07-17 06:05:00 Right, but you've verified locally, so everything should be good. Is Alpine still running the riscv64 builder with the checks off? 2022-07-17 06:07:15 boomanaiden154: yes 2022-07-17 06:45:05 boomanaiden154: passed on the builder :) 2022-07-17 06:45:22 as well as the other package that was blocked by py3-matplotlib 2022-07-17 11:07:21 good day everyone 2022-07-17 11:08:56 telmich: o. 2022-07-17 11:08:59 o/ 2022-07-17 11:25:44 :) 2022-07-17 11:26:06 I'll need to setup a matrix<->irc bridge, probably using heisenbridge to be more present here 2022-07-17 14:39:35 hello 2022-07-17 14:40:28 I think asterisk 18 apk on Alpine 3.16 has a problem: it seems the pjsip module does not load any config item 2022-07-17 14:56:27 asterisk 18 apk is also missing macro module: 2022-07-17 14:56:30 mxqpro2*CLI> module load app_macro Unable to load module app_macro Command 'module load app_macro' failed. [2022-07-17 16:51:48] ERROR[2377]: loader.c:283 module_load_error: Error loading module 'app_macro': Error loading shared library /usr/lib/asterisk/modules/app_macro.so: No such file or directory 2022-07-17 14:56:54 it's hard to recompile it all on armv7 2022-07-17 14:57:38 Nothing seems to provide app_macro.so 2022-07-17 15:02:54 afaik is an option while compiling asterisk 2022-07-17 15:03:03 i.e. "macros" module 2022-07-17 15:03:19 on the select menu 2022-07-17 15:03:41 at least that's what usually is done in armbian compiles 2022-07-17 15:03:49 wyk72: I'd say open an issue on gitlab.alpinelinux.org/alpine/aports/-/issues 2022-07-17 15:03:56 https://gitlab.alpinelinux.org/alpine/aports/-/issues 2022-07-17 15:04:09 thanks I'll do that 2022-07-17 17:43:44 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920 2022-07-17 17:45:07 brb adding more patches 2022-07-17 17:45:12 was planning to do that anyway 2022-07-17 17:54:52 i was just about to link that lol 2022-07-17 17:55:04 beautiful 2022-07-17 17:58:35 first of all, the rust foundation is an entirely different entity 2022-07-17 18:00:02 (fwiw from what I can tell, I don't think he represents the RF) 2022-07-17 18:01:56 secondly, there is a porting clause that should be sufficient to allow distributions to do their work 2022-07-17 18:02:10 i do not think this is a big deal 2022-07-17 20:09:06 trademark is what the palemoon devs and users wield to bully openbsd and such, even if the current RF doesn't care, who knows what the future would hold... 2022-07-17 20:42:07 inb4 freight and erosion 2022-07-17 23:06:14 panekj: what's the progress on https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/136 ? it looks ready to me 2022-07-18 02:53:18 hey, how does one get the reporter role on gitlab? 2022-07-18 05:34:46 ptrc: is it? 2022-07-18 08:14:03 ptrc: there is no formal process for that atm 2022-07-18 08:14:21 My idea was to add all package maintainers as reporters 2022-07-18 08:14:28 what does reporter do 2022-07-18 08:14:40 Allows you to set labels on issues 2022-07-18 08:14:52 but, it also makes it easier to @ people 2022-07-18 08:15:32 mhm, you wanted to add *all* package maintainers to reporters? 2022-07-18 08:15:38 don't think that's a good idea :P 2022-07-18 15:34:01 im tagging 3.16.1 now 2022-07-18 17:24:13 panekj: why isn't that a good idae? 2022-07-18 17:24:17 s/idae/idea/ 2022-07-18 17:24:17 craftyguy meant to say: panekj: why isn't that a good idea? 2022-07-18 17:25:03 why giving access to create mess to random people is not a good idea? 2022-07-18 17:35:20 Oh, there is also a guest role 2022-07-18 17:37:29 Guest appears to be pretty harmless 2022-07-18 21:00:33 I don't think "reporters" can really do much? 2022-07-18 21:01:06 I mean, anyone who can register an account can create plenty of mess, filing issues, adding comments. heh. 2022-07-18 21:17:01 they get to close issues and label them 2022-07-18 21:17:10 and see 'confidential' issues though there isn't usually much happening there 2022-07-18 21:18:12 Hi, who can I annoy about updating https://hub.docker.com/r/alpinelinux/docker-abuild ? It's used by https://gitlab.alpinelinux.org/alpine/docker-abuild and was maintained by clandmeter but it seems not anymore. I'm actively using the tool so updated images would be nice so it runs faster. I'd be happy to help setup CI again or something, however it was built in the past. 2022-07-18 21:20:28 z3ntu: would be nice if somebody can help maintain it 2022-07-18 21:24:22 clandmeter: I'd be happy to. I see gitlab CI jobs are running but failing so I can look into that, I guess when they still succeeded they were updating the images on docker hub? 2022-07-18 21:27:30 z3ntu: tbh, i did not look at if for a while 2022-07-18 21:27:33 Actually gitlab is just queueing the jobs for 100 minutes and the error is "There has been a timeout failure or the job got stuck. Check your timeout limits or try again". I don't see anything in the .gitlab-ci.yml that pins the jobs to a specific runner that might have disappeared, so I guess it's in the repo admin settings something? 2022-07-18 21:27:51 https://gitlab.alpinelinux.org/alpine/docker-abuild/-/pipelines/128624/failures 2022-07-18 21:29:58 z3ntu: what is your username on gitlab? 2022-07-18 21:30:02 Last successful run was on 2021-07-25, from 2021-08-01 on it's this failure it seems 2022-07-18 21:30:09 also z3ntu: https://gitlab.alpinelinux.org/z3ntu 2022-07-18 21:36:45 z3ntu: i need to check how i can add you to the project without exposing secrets 2022-07-18 21:36:59 sure, no rush 2022-07-18 21:45:48 i guess the rules and the scheduling could block each other 2022-07-18 22:36:51 I've been updating docker-abuild images locally for myself 2022-07-18 22:37:03 and have patched dabuild for doas/sudo stuff 2022-07-19 03:06:22 is there a way to skip symlink tracing in abuild? i wanted to overwrite depends for -dev in !36590, but the main package still gets added 2022-07-19 03:42:39 rbq: i'm currently attempting a wxwidgets-3.2 upgrade, and i'm not sure if it's possible to make maitreya work with it 2022-07-19 04:24:42 ptrc: only way is adding !tracedeps to options 2022-07-19 04:24:47 but that obviously does more 2022-07-19 04:25:16 yeah, i wanted to avoid it 2022-07-19 04:26:20 would be a nice fix for the pipewire-jack/jack-dev conflict since jack-dev will be satisfied with either 2022-07-19 06:30:25 psykose: How did it go, and is that the only aport having problems with wxwidgets-3.2? 2022-07-19 06:30:35 nah, lots of failures 2022-07-19 06:31:02 the others may or may not be fixed at some point, but that one has an upstream dead for many years so i doubt it 2022-07-19 06:32:58 just talking about it :) gtk2 is gone entirely, half the gtk3 stuff fails 2022-07-19 06:35:10 When will gtk+2.0 be removed? 2022-07-19 06:35:54 From aports, I mean 2022-07-19 06:37:16 maybe in 20 years 2022-07-19 06:37:38 Gimp still depends on it afaik 2022-07-19 06:38:06 tons of stuff does 2022-07-19 08:32:28 Phew, this MR took a lot more work than it should have, but it’s finally ready: !36606 2022-07-19 08:36:30 at last 2022-07-19 09:23:44 ikke: you tried to bootstrap s390x rust? did you use scripts/bootstrap.sh? did you bump into error with libgnat.a? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12898 2022-07-19 09:37:49 we both used LANG_ADA=false 2022-07-19 09:38:03 every other issue should have been fixed by me 2022-07-19 09:38:57 i spent a few days on it, i posted the part i got stuck on in the merge request 2022-07-19 09:42:41 which merge request? 2022-07-19 09:42:49 im fixing the ada thingy 2022-07-19 09:43:31 https://tpaste.us/KekB 2022-07-19 09:47:51 Ariadne: gcc 12.X builds on all CI architectures now but it did require 8 additional patches for gcc-go, gnat, gdc, … I haven't tested it extensively yet but if you want to I believe we could merge it soonish. would love to ship 3.17 with gcc 12 2022-07-19 09:48:09 ncopa: !34493 2022-07-19 09:48:25 nmeum: can you send those patches to alpine-gcc-patches 2022-07-19 09:49:12 i have a couple of meetings but will rebase the snapshot and test it again 2022-07-19 09:49:36 Ariadne: yes, can do. though some existing patches also need to be removed, so the alpine/12.1 branch needs to be rebased 2022-07-19 09:50:00 sure, just send an MR with the new branch and i'll replace it 2022-07-19 09:50:21 ok! will do later today 2022-07-19 10:26:19 ncopa: https://tpaste.us/oO7L 2022-07-19 10:46:17 ikke: this is a fix for that: https://tpaste.us/jPoV 2022-07-19 11:23:55 i get this error when crosscompiling rust: https://tpaste.us/DBbl 2022-07-19 11:24:12 that happens with https://gitlab.alpinelinux.org/alpine/aports/merge_requests/34493 applied 2022-07-19 11:24:17 (and rebased) 2022-07-19 11:48:49 ncopa: yes psykose and I got stuck there as well 2022-07-19 11:49:09 FYI, I've created a container on nld5 for the bootstrapping 2022-07-19 12:24:24 i believe that the __divdi3 errors happens due to lack of linking to libgcc 2022-07-19 12:28:40 the majority of them are some compiler intrinsics stuff specific to the crate 2022-07-19 12:28:52 whats strange is the .rlib is basically empty 2022-07-19 12:29:14 if you look at a working compiler_builtins.rlib it has them 2022-07-19 12:29:48 during this cross process, both the s390x stage1 rlib and x86_64 are empty 2022-07-19 13:26:32 do we have another s390x vm where I can experiment tiwh thte gentto->alpine stuff for bootstrapping rust? 2022-07-19 13:28:31 We only have access to 2 servers 2022-07-19 13:28:43 One builder and a ci host 2022-07-19 13:29:15 ok 2022-07-19 13:29:36 yoink the builder if you want 2022-07-19 13:29:39 his script needs to run on a s390x machine 2022-07-19 13:30:44 We can u suppose run a VM on the ci host 2022-07-19 14:35:09 ok, i need an s390x machine with docker. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34493#note_248837 2022-07-19 14:41:23 ncopa: when will alpine 3.15.x 2022-07-19 14:41:27 er 2022-07-19 14:41:32 ncopa: when will alpine 3.15.x get an update for the busybox CVE 2022-07-19 14:42:25 ah, right 2022-07-19 14:43:19 i got distracted by rust for s390x today. will try get it out either later tonight or tomorrow 2022-07-19 14:43:24 clandmeter: maybe also someone else in Alpine team (that has gitlab admin) can look into it? 2022-07-19 14:43:45 z3ntu: i think i know what the problem is 2022-07-19 14:52:58 ncopa: s390x-ci.a.o has docker 2022-07-19 17:04:52 Quick question: is there a popularity threshold for adding a package? Asking as I may wan to submit an APKBUILD for my game, whose binary doesn't work on Alpine as is (due to glibc/musl) but is really easy to compile yourself (works out of the box from source). 2022-07-19 17:06:06 there isn't 2022-07-19 17:22:20 Thanks, then I might consider that. The game is rather stable now - I do still make updates about every two weeks but that is mainly to keep dependencies up to date. 2022-07-19 17:28:16 adding a package means the builders build it so it doesn't matter whether some binary works ootb or not 2022-07-19 17:29:04 the dependencies should be provided by alpine when possible 2022-07-19 17:29:39 also i made some random changes and rust +crt-static didn't segfault but was still dynamic 2022-07-19 17:29:43 maybe i can actually figure it out 2022-07-19 17:29:58 what did you do 2022-07-19 17:30:05 you know, random changes 2022-07-19 17:30:12 sureeeee 2022-07-19 17:30:17 cat /dev/urandom > src/rust , and so it goes 2022-07-19 17:30:34 ah, pseudo-random changes 2022-07-19 17:30:38 i ahve built this shit like 100 times in the past week 2022-07-19 17:31:06 want to help me figure out why my stuff doesn't built completely statically then? :P 2022-07-19 17:31:16 that is exactly what i'm doing 2022-07-19 17:31:23 you can't with the packaged toolchain 2022-07-19 17:31:39 iirc they all come out dynamic and segfault lol 2022-07-19 17:31:46 (well, I was using pre-built rustup toolchain actually) 2022-07-19 17:32:23 it's just that no matter the flags openssl still wouldn't link statically 2022-07-19 17:32:27 that one i have no idea aside from the default is +crt-static and so also segfaults but only with random crates 2022-07-19 17:32:28 Issue with dependencies is, the game is written in Go 2022-07-19 17:32:37 and IIRC Go libraries usually don't become Alpine packages 2022-07-19 17:32:40 oh well, then carry on 2022-07-19 17:32:48 but there is some vendoring mess going on 2022-07-19 17:32:48 oh no, more 400MB executables 2022-07-19 17:32:53 i love go! 2022-07-19 17:32:56 Haha 2022-07-19 17:32:59 Only 30M though ;) 2022-07-19 17:33:02 I don't care as long as it's not CGO 2022-07-19 17:33:15 Hm... _some_ cgo is included though, is that a problem? 2022-07-19 17:33:21 but some people made patches for go compiler to actually multi-thread 2022-07-19 17:33:29 as long as it doesn't use the cgo gtk4/3/whatever bindings 2022-07-19 17:33:30 panekj meant to say: but some people made patches for (c)go compiler to actually multi-thread 2022-07-19 17:33:30 s/go/(c)go 2022-07-19 17:33:33 It uses the Ebitengine library which uses glfw which uses cgo to use the C glfw 2022-07-19 17:33:44 sus 2022-07-19 17:33:48 it's just slow and painful 2022-07-19 17:33:53 but i'm mostly trolling, go package it 2022-07-19 17:33:56 hehe 2022-07-19 17:34:05 interestingly on Windows that engine doesn't use cgo 2022-07-19 17:34:05 psykose: "go" package it 2022-07-19 17:34:10 it uses something _worse_ 2022-07-19 17:34:16 it dumps a DLL to a temp folder and loads that :( 2022-07-19 17:34:16 the issue with these cgo memes is they don't even use 1 core, i don't understand how they can make a toolchain so terrible 2022-07-19 17:34:34 dlopen, that's good 2022-07-19 17:34:46 they just sleep forever on some deadlock and use 0.1 of a core to compile 'all of gtk4' and it takes forever 2022-07-19 17:34:58 embedding a dll in a single exe to dump it to temp and load from there is not good though - totally looks like a trojan ;) 2022-07-19 17:35:09 ah, that cgo issue, during compiling 2022-07-19 17:35:23 TBH I don't observe that, apparently the cgo amount is low enough to not be noticeable 2022-07-19 17:35:31 link to game 2022-07-19 17:35:40 https://divVerent.github.io/aaaaxy/ 2022-07-19 17:36:15 as said, the binaries there won't run on Alpine (they depend on glibc) - downloading the repo and "make" will work 2022-07-19 17:36:36 (after some C deps glfw needs that will be rather obvious from the error messages) 2022-07-19 17:36:43 well, usually anything pre-built without static linking doesn't run on different systems 2022-07-19 17:36:51 indeed 2022-07-19 17:37:10 I did also package for flatpak and snap, but of course, glibc madness too 2022-07-19 17:37:27 or even worse, "includes half an Ubuntu - get email every two weeks that I need to rebuild due to random vuln" 2022-07-19 17:37:33 like, snap is a great example of how not to do it 2022-07-19 17:37:42 Ariadne: Did you add -O2 to the gcc package to improve performance, or does that fix some other issue? While looking randomly at the gcc build logs I just realized that -O2 seems to be only used for .c files (CFLAGS) but not .cpp ones (CPPFLAGS/CXXFLAGS), not sure if that is intended 2022-07-19 17:38:39 AppImages be like: let's just build against the oldest possible OS version 2022-07-19 17:38:53 yeah 2022-07-19 17:39:03 kinda what I do for my raw binaries too - I build on Debian stale 2022-07-19 17:39:05 ;) 2022-07-19 17:39:15 ew 2022-07-19 17:39:23 like, anything older than that outright doesn't matter for games 2022-07-19 17:39:28 wowee it works 2022-07-19 17:39:45 static linking no segfault? 2022-07-19 17:39:49 nah the game 2022-07-19 17:39:54 eh 2022-07-19 17:39:58 lol you thought something i made works? haha get a load of this person 2022-07-19 17:40:08 static linking w/o package manager is evil though - which forces me to make new release frequently 2022-07-19 17:40:29 nah, I just thought that rust in alpine wasn't supposed to properly static link and you broke it to actually static link 2022-07-19 17:40:37 minecrell: pretty sure it was the former and was missed for the others 2022-07-19 17:40:38 without segfault 2022-07-19 17:41:01 like, Alpine can just rebuild automatically when a dep had a vuln, and does a rollout of the new apk, which solves the static-linking-is-bad issue 2022-07-19 17:41:03 i don't see why it shouldn't 2022-07-19 17:41:14 the current patches don't even make sense, they intentionally break it for no reason 2022-07-19 17:41:21 can't wait for gcc-rs 2022-07-19 17:42:14 hm... it does sound like a good idea to have a reimplementation of Rust 2022-07-19 17:44:17 it's already made 2022-07-19 17:44:23 and it's eh 2022-07-19 17:45:42 is there any rust reimplementation that's not "rust buth without borrow checker" 2022-07-19 17:45:48 s/buth/but/ 2022-07-19 17:45:48 ptrc meant to say: is there any rust reimplementation that's not "rust but without borrow checker" 2022-07-19 17:46:55 BTW, what are the current "guidelines" (or a positive-example APKBUILD) for Go stuff with dependencies? 2022-07-19 17:47:14 https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Go seems rather outdated (e.g. glide itself says one should just use go.mod/go.sum, and that already ensures reproducibility via checksums) 2022-07-19 17:47:39 but for Flatpak and Arch I had to use the vendor way (have a script that basically takes care of exporting the deps to nice tarball+checksum pairs, etc.) 2022-07-19 17:48:13 so I may as well do the same and have an APKBUILD that explicitly lists all deps with checksums the same way, rather than having Go do downloading 2022-07-19 17:48:25 most aports just run `go build` without any vendoring / fetching deps separately 2022-07-19 17:48:43 so it's ok to access network during build? Fine by me then ;) 2022-07-19 17:48:53 it'd still be reproducible as all deps are pinned 2022-07-19 17:49:25 well, i imagine it's not the perfect scenario, but that's the status quo for go aports 2022-07-19 17:49:33 currently we don't limit network in builds but that might change in future 2022-07-19 17:49:43 good, thanks 2022-07-19 17:50:55 other than that, I guess the usual guidelines apply to have nice hardened flags and not including stuff in binaries that changes (e.g. timestamps) 2022-07-19 17:51:48 we already have proper flags as default 2022-07-19 17:51:51 everything is (almost)already in goflags, unless you mean something specific 2022-07-19 17:54:23 divVerent: fwiw, we tried that in gentoo, and while it has advantages (it's nice to not need network access), you also end up with huuuuuge APKBUILDS in your case & manifests 2022-07-19 17:54:29 divVerent: so we've ended up mostly doing dep tarballs now 2022-07-19 17:55:07 yeah it's mostly a waste of time 2022-07-19 17:55:26 speaking of i started looking at setuptools 62 and i regret it 2022-07-19 17:55:57 they added another like 7 vendored deps??? 2022-07-19 17:56:07 F.U.N. 2022-07-19 17:56:12 *python* 2022-07-19 17:56:14 so the initial thought is 2022-07-19 17:56:18 'sure just leave some of them vendored' 2022-07-19 17:56:29 except then you have to be more precise with the patching and it's 1k lines 2022-07-19 17:57:14 so it's either 1k lines of patches, or leaving everything vendored, or figuring out bootstrappable builds for jaraco memes and moving 10 things to main 2022-07-19 17:57:15 great 2022-07-19 17:58:23 for what reason those deps are 2022-07-19 18:00:40 right when i figured out the entire pyproject mess they decided to make the setuptools circle of hell 2022-07-19 18:01:06 psykose: they wanne keep you busy 2022-07-19 18:01:15 :) 2022-07-19 18:01:52 inb4 stage0-stage1-stage2 levels of setuptools and things building with random versions in the middle 2022-07-19 18:02:04 sam_: yeah, I understand 2022-07-19 18:02:21 bootstrapping the bootstrap 2022-07-19 18:02:25 dep tarball is something I don't really _want_ to do, but I guess I could be convinced just packaging a "go vendor" directory on my github releases 2022-07-19 18:02:38 I don't _really_ like the idea of releasing someone else's source code as mine ;) 2022-07-19 18:02:42 yeah it's nasty 2022-07-19 18:02:44 i don't like it at all 2022-07-19 18:03:10 now the good news is, "go vendor" works out of the box in existing projects now 2022-07-19 18:03:11 I like Go people mentality of "oops, I forgot to push one thing and already tagged the repo, I'll just untag and retag it again" 2022-07-19 18:03:18 so at least anyone can build this tarball trivially 2022-07-19 18:03:20 One solution we're looking at (but requires some changes in abuild to really work), is to first download all the deps, and then build without network 2022-07-19 18:03:28 they still do that? 2022-07-19 18:03:31 but that breaks things :P 2022-07-19 18:03:39 Ebitengine has recently done something even more stupid 2022-07-19 18:03:40 I haven't seen any retagging in go 2022-07-19 18:03:40 well 2022-07-19 18:03:49 accidentally bumped minor rev on some package, then "unbumped" it 2022-07-19 18:03:49 I've seen few 2022-07-19 18:03:50 especially because the sumdb makes that painful 2022-07-19 18:03:55 as in, the git tag for the wrong minor rev was deleted 2022-07-19 18:04:04 but some existing code still points at it 2022-07-19 18:04:06 ikke: that's the point 2022-07-19 18:04:11 and Go's caching proxies still return it 2022-07-19 18:04:14 yes 2022-07-19 18:04:19 people tagged, untagged then tagged again and sumdb goes crazy 2022-07-19 18:04:22 panekj: yes, I understand 2022-07-19 18:04:24 that breaks my vendoring scripts 2022-07-19 18:04:33 which are really nasty as they try to get git URLs back out of a "go vendor" tree ;) 2022-07-19 18:04:37 and even worse hell when some another proxy takes new tag as correct one 2022-07-19 18:04:48 then each proxy says different thing 2022-07-19 18:04:56 yeah, I so hope the author will not reuse that tag name 2022-07-19 18:05:35 at least Go added "deprecated" option 2022-07-19 18:06:13 you mean retracted? 2022-07-19 18:06:22 yeah 2022-07-19 18:17:51 ikke: the problem is what I mentioned :( 2022-07-19 18:17:58 but it's doable depending on structure, yeah 2022-07-19 18:18:10 really I think it's the only proper way to proceed 2022-07-19 18:18:15 it's just awkward logistically 2022-07-19 18:18:49 sam_: note that it's not the goal to mention all deps in the APKBUILD 2022-07-19 18:18:58 which is not feasible 2022-07-19 18:19:37 The idea is to run go mod download before shutting of network access 2022-07-19 18:19:39 right 2022-07-19 18:19:41 ikke: what's the rough plan then? oh 2022-07-19 18:19:43 is it to have go do the download, but then cut it off? 2022-07-19 18:19:45 (network) 2022-07-19 18:19:49 exactly 2022-07-19 18:19:54 but no concrete plans for this yet 2022-07-19 18:20:44 Currently with rootbld, everything after fetch is done without networking 2022-07-19 18:21:03 But go mod download would need to happen after unpack 2022-07-19 18:23:35 (similar with rust) 2022-07-19 18:38:38 let me guess: and cabal, and npm, and virtually every other programming language with its own packaging? ;) 2022-07-19 18:40:22 C++20 modules when? ;) 2022-07-19 18:50:16 :D 2022-07-19 18:50:26 ikke: if you remember, please let me know what you end up doing. no big deal if you forget ofc 2022-07-19 18:50:31 just very interested in how folks handle it 2022-07-19 18:50:35 nod 2022-07-19 18:51:17 sam_: One step towards this for rust based packages: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/128 2022-07-19 18:51:28 it seems to be exactly as advertised so far minus the actual rootbld implementation, i don't think there will be any major issues 2022-07-19 18:51:41 the biggest positive is it makes it easy to catch things that vendor random deps 2022-07-19 18:51:54 psykose: what is as advertised? 2022-07-19 18:52:12 the fetch stuff in prepare for network modules 2022-07-19 18:52:21 right 2022-07-19 18:52:24 nobody has proposed anything else and it makes sense 2022-07-19 18:52:36 ikke: thanks! so one of the things (probably the biggest thing) i worry about with this, is that you can't then easily predict bandwidth requirements, but i think it's not a fatal flaw 2022-07-19 18:53:01 right, though that's not a major concern for us at the moment 2022-07-19 18:53:24 one of the biggest bandwidth issues with rootbld is there is no cache currently 2022-07-19 18:53:49 technically it's more ''correct'' to keep cache dirs inside the builddir and wipe it, but it's redownloading everything all the time for no real reason 2022-07-19 18:53:55 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/133? 2022-07-19 18:53:57 and redownloading the cargo index on every build is funny 2022-07-19 18:54:07 not for apk specifically, builds 2022-07-19 18:54:29 You mean distfiles? 2022-07-19 18:54:41 or distcc? 2022-07-19 18:54:42 no, the literal things being downloaded via `cargo --fetch` for instance 2022-07-19 18:54:47 right 2022-07-19 18:55:04 but that's not limited to rootbld, is it? 2022-07-19 18:55:17 well without rootbld it will just keep the cache in ~/.cargo 2022-07-19 18:55:35 right, at least with go, the tendency is to put those things in $srcdir 2022-07-19 18:55:52 the go one is a bit different as it also contains built objects iirc 2022-07-19 18:56:00 One thing I have to regularly do is to wipe things like ~/.cargo on the builders 2022-07-19 18:56:10 psykose: there are 2 directories 2022-07-19 18:56:15 ah 2022-07-19 18:56:20 ~/go is just the downloaded mod cache 2022-07-19 18:56:32 ~/.cache/go-build is the built objects 2022-07-19 18:56:43 interesting 2022-07-19 18:56:53 wonder why ~/go is like 3x the size of ~/.cargo for me then 2022-07-19 18:56:59 I only know it because that's what I have to wipe 2022-07-19 18:57:02 guess they just be writing a lot of code 2022-07-19 18:57:16 More go projects than rust projects 2022-07-19 18:57:33 ~/go/pkg is compiled objects 2022-07-19 18:57:51 ~/.cache/go-build is just build cache 2022-07-19 18:58:02 panekj: oh, my bad 2022-07-19 18:58:23 that's why we added -modcacherw 2022-07-19 18:58:40 because normally go protects that directory from deletion 2022-07-19 18:59:23 ~/go/pkg only seems to contain source code for me? 2022-07-19 19:00:19 forgot that it also contains sumdb 2022-07-19 19:00:39 I don't see any binaries / compiled objects there 2022-07-19 19:01:14 maybe they changed that, but pretty sure that was once a place for compiled objects 2022-07-19 19:01:36 I see them in ~/.cache/go-build 2022-07-19 19:01:41 00563f7dc7fea3460c1df3f8fcc6abb7e7f17dfd7f18b5ae46b4849a826ed68d-d: current ar archive 2022-07-19 19:03:05 ls -lah ~/go/pkg/mod/cache ? 2022-07-19 19:03:55 panekj: downloaded archives / repositories? 2022-07-19 19:07:02 idk, I might be wrong, I've been sitting with rust for too long :P 2022-07-19 19:07:12 seems like it's just git stuff that takes a lot of place 2022-07-19 19:07:34 yup 2022-07-19 19:07:43 And I see the occasinal zip archive as well 2022-07-19 19:07:47 occasional* 2022-07-19 20:37:29 OK to waste resources on check()? Like, spin up Xvfb and run the game for a minute against llvmpipe? Because I happen to have an existing test for that :) 2022-07-19 20:38:23 If it's just a minute it should not be an issue 2022-07-19 20:38:36 because it's the obvious thing I can run in check() 2022-07-19 20:38:59 basically replays inputs and verifies nothing changes - and runs "mostly headless" but sadly still uses the 3D graphics library 2022-07-19 20:39:41 on github actions I actually run a 100% run of the game (takes 1 hour realtime, 10 min on the testing platform), but for reasons I am not gonna share that demo file 2022-07-19 20:40:14 xvfb-run is perfectly fine 2022-07-19 20:40:21 the small one I use for benchmarking would still reveal if anything is egregiously wrong though 2022-07-19 20:40:41 now for the _hard_ part - how do I test that my APKBUILD actually declares all deps, like... any easy way to start on an empty chroot? 2022-07-19 20:41:20 oh, that's what abuild-rootbld is 2022-07-19 20:41:41 correct 2022-07-19 20:41:51 or docker-abuild 2022-07-19 20:42:02 that contains the d-word 2022-07-19 20:54:39 Hm... this is odd, xvfb-run inside rootbld doesn't support OpenGL, I must be missing something obvious in checkdepends, just what 2022-07-19 20:55:44 mesa-dri-gallium 2022-07-19 20:56:20 trying... was also checking other packages that use xvfb-run but they have nothing obvious there 2022-07-19 20:57:23 of course, I am kinda _assuming_ they currently pass... trying a randomly chosen one now 2022-07-19 20:58:52 thanks, that rather obviously fixed it... now I do wonder why other packages don't have this 2022-07-19 20:58:55 Most of them are desktop apps 2022-07-19 20:59:07 they might of course just pull that already in as transitive dep 2022-07-19 20:59:17 no, basically nothing does 2022-07-19 20:59:25 for the most part it's not needed 2022-07-19 20:59:38 or they all just skip the tests and i missed it :p 2022-07-19 20:59:47 then how come e.g. testing/mixxx passes check? 2022-07-19 20:59:56 (still compiling to see for myself, this one uses cmake) 2022-07-19 21:02:23 oh, it might just not use OpenGL, stupid me 2022-07-19 21:12:40 thanks, this actually worked extremely smoothly - going from the "kinda works" APKBUILD I had initially to one that seems to do things rather well - gonna keep this for a while to see if it's stable and all the weird stuff works (e.g. desktop icon), then submit 2022-07-19 21:13:45 Somewhat "sus": my game detects a "Synaptic" gamepad while under xvfb-run inside rootbld's bubblewrap sandbox 2022-07-19 21:13:56 i would not say you're wasting resources there :p 2022-07-19 21:13:58 didn't expect the sandbox to expose that info ;) 2022-07-19 21:14:10 sounds reasonable although possibly fragile, it's a call you can make 2022-07-19 21:15:05 (that it detects touchpads as "useless gamepads" is a problem I do not care about - Linux is weird regarding gamepads, hard to detect what is one and what is something else) 2022-07-19 21:15:10 dev is mounted into the root 2022-07-19 21:15:23 and apparently enough read permissions to get device names 2022-07-19 21:15:30 just doesn't sound "great" for reproducible builds, but ok 2022-07-19 21:15:36 that would be like the most basic level of read access 2022-07-19 21:15:36 builds shouldn't be reading there anyway 2022-07-19 21:15:44 I only do that from check which should be ok 2022-07-19 21:37:25 Ariadne: alpine 3.15.5 is out with busybox cve fix 2022-07-19 21:37:33 thx 2022-07-19 21:38:01 now to wait on dockerhub to actually publish it :D 2022-07-19 22:22:38 panekj: https://img.ayaya.dev/AjJuDgOxFEQ9.png 2022-07-19 22:22:48 at last 2022-07-19 22:23:06 attagirl 2022-07-19 22:23:34 but, there's a small issue 2022-07-19 22:23:45 i am not sure how it even works normally 2022-07-19 22:24:38 needs to pass gcc_eh like the patch from the s390x mr but actually specify kind = static 2022-07-19 22:24:56 issue is that.. only a static .a even exists for it, and it's in the gcc libdir which is not in the -L path 2022-07-19 22:25:03 so to even build this you need to pass RUSTFLAGS 2022-07-19 22:25:21 not sure how to correctly pass /usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/ in this rust garbage 2022-07-19 22:45:03 either it fixed itself or i broke everything again, fun 2022-07-20 02:04:25 Hm... is it correct style to depend on hicolor-icon-theme just so I can dump an icon in /usr/share/icons/hicolor/128x128/apps? 2022-07-20 02:04:41 I know on Arch that is required... but it feels wrong as I don't really _care_ which icon theme the user is using 2022-07-20 02:05:19 I see some APKBUILDS depend on this package just for that reason too, while some don't and dump icons there anyway 2022-07-20 02:30:19 ah, this package contains only one file anyway; meh, is OK to depend on that then. Even though I only need the _directory_ the file is in :) 2022-07-20 05:40:23 divVerent: you don't depend on package to create the directory, you create it the directory in your package in package() 2022-07-20 05:40:37 s/it the/the 2022-07-20 05:40:37 panekj meant to say: divVerent: you don't depend on package to create the directory, you create the directory in your package in package() 2022-07-20 07:15:47 psykose: can you boostrap (and fix) rustc for riscv64 next? 🥺👉👈 2022-07-20 09:05:18 i have rust-1.60 packages for s390x now 2022-07-20 09:05:32 but it cannot build 1.62 apaprently 2022-07-20 09:07:08 z3ntu: the problem is the ci runner needs to do multi arch, and that runner is gone now. not sure what the status of it is. 2022-07-20 09:23:05 I did remove some runners the other day that didnt contact gitlab in months 2022-07-20 09:26:04 ikke: The last successful run was on 2021-07-25, from 2021-08-01 on the runner seems to be gone 2022-07-20 09:26:33 Btw I think build.alpinelinux.org armhf builder is stuck, gcc hasn't been rebuilt for -r4 yet https://pkgs.alpinelinux.org/packages?name=gcc&branch=edge 2022-07-20 09:26:56 (ppc64le also but I don't really care about that one) 2022-07-20 09:48:04 It’s summertime, it’s a heat wave, the weather’s too hot to code, but it’s the perfect time to take a step back and discuss higher-level changes (or is it lower-level? :think:) 2022-07-20 09:48:29 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/52 2022-07-20 10:49:06 skarnet: i cherry-picked `main/eudev: delete setup-udev` 2022-07-20 10:49:14 can you please rebase? 2022-07-20 10:50:12 re mdev-conf, I was thinking to create a separate "upstream" gitlab project for it 2022-07-20 10:50:23 so we can have an APKBUILD that just fetches a tarball 2022-07-20 10:51:29 tbfh I don’t much like the idea, given my experience with alpine-conf and synchronizing it with aports 2022-07-20 10:52:06 when I wanted to add setup-devd it needed a simultaneous alpine-conf update and an apkbuild update in aports, and syncing was hard 2022-07-20 10:52:30 is there a specific reason why you’d rather have mdev-conf in a separate project rather than in aports? 2022-07-20 10:59:04 rebased 2022-07-20 11:01:41 I thought it would be cleaner. Then you dont need to pull entier aports tree to contribute to mdev-conf (eg https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32330) 2022-07-20 11:01:55 we can run separate unit test CI job 2022-07-20 11:02:05 i think its just generally cleaner 2022-07-20 11:02:42 I thought about it while converting the bats scripts to kyua 2022-07-20 11:03:07 it would make it a bit easier to work with 2022-07-20 11:03:09 it’s probably okay sync-wise, the alpine-conf sync need was a special case because there was a tool change 2022-07-20 11:03:33 it’s unlikely that a mdev-conf package would need a simultaneous aports change 2022-07-20 11:04:04 so okay I have no objection to a separate project 2022-07-20 11:10:18 (making mdev-conf a separate project is an orthogonal question to splitting busybox-initscripts and making a dev-initscripts virtual package though) 2022-07-20 11:19:26 "Btw I think build.alpinelinux...." <- ikke: ^ 2022-07-20 11:19:50 z3ntu: thanks for the reminder 2022-07-20 11:49:03 in other news.... 2022-07-20 11:49:06 >>> rust: Signing the index... 2022-07-20 11:49:06 ncopa-edge-s390x:~/aports/community/rust$ 2022-07-20 11:49:29 🥳 2022-07-20 11:49:40 So it worked in the docker container? 2022-07-20 11:49:46 yes 2022-07-20 11:49:57 i have now built rust 1.61 on s390x 2022-07-20 11:50:06 i will not try build rust 1.62 2022-07-20 11:50:16 which is current latest 2022-07-20 11:51:03 Why did that approach work? Did it build rust with rust from Gentoo? 2022-07-20 11:51:11 yes 2022-07-20 11:51:42 he built rust s390x musl using gentoo rust s390x glibc 2022-07-20 11:51:54 aha ok 2022-07-20 11:52:25 not sure why that worked better than crosscompile rust s390x musl using rust x86_64 musl 2022-07-20 11:57:15 s/i will not try build rust 1.62/i will now try build rust 1.62/ 2022-07-20 11:57:15 ncopa meant to say: i will now try build rust 1.62 2022-07-20 11:59:57 when that is done, I will copy the packages to build-edge-s390x, manually install them and then push the commit that enables s390x 2022-07-20 12:00:17 and when builder is done, i'll remove the manually installed packages from build-edge-s390x 2022-07-20 12:53:15 panekj: thanks; apparently other distros have packages owning directories so this would be a bad thing to do, but yeah, it looks like on Alpine it's OK to just not have that dep 2022-07-20 12:54:14 another thing I wonder - right now I do "go mod download" in prepare(), but that means I need to share GOFLAGS among both prepare and build - the lazy solution would be to download in build, but is that the part that may go away at some point? 2022-07-20 12:54:52 you can just export outside of functions and reference in both 2022-07-20 12:55:00 but why you need to share goflags at all? 2022-07-20 12:57:10 some flags may influence go mod download? 2022-07-20 12:57:22 -modcacherw e.g. sounds suspicious, although I don't _really_ know 2022-07-20 12:57:40 anyway, I found 5 APKBUILDs that do go mod download inside prepare, and 5 that do it inside build 2022-07-20 12:57:54 it should be in prepare() 2022-07-20 12:58:03 but what are YOU doing that you have to use GOFLAGS at all 2022-07-20 12:58:21 normally that part shouldn't bother you since it's just exported envvar 2022-07-20 12:58:37 right now I would pass -trimpath (needed for reproducible build), -mod=readonly -modcacherw (apparently generally recommended, but I don't care much about these ones) 2022-07-20 12:58:43 you don't do that 2022-07-20 12:58:50 we already have that as default 2022-07-20 12:58:52 Alpine already passes -buildmode=pie which is nice 2022-07-20 12:58:57 oh, ok, didn't see it when I ran env 2022-07-20 12:59:06 but OTOH it makes sense to share this stuff anyway 2022-07-20 12:59:33 I mean, it's probably not propagated to builders, but it's already part of abuild default config 2022-07-20 12:59:55 ah, I probably don't have it because I don't have everything on edge yet 2022-07-20 12:59:56 we don't require reproducible builds so it's not necessary to add those flags 2022-07-20 13:00:08 because if I put "env" in my APKBUILD I only see -buildmode=pie in GOFLAGS 2022-07-20 13:00:25 it's not released in abuild yet 2022-07-20 13:00:44 but anyway, yeah, so basically it's not my job to pass flags to get the build reproducible if they're just generally needed for Go and not project specific? 2022-07-20 13:00:57 Then I may as well ignore GOFLAGS indeed (I did make sure my code honors it) 2022-07-20 13:01:02 you only pass flags that you need for stuff to build properly 2022-07-20 13:01:11 if none required, you don't do any 2022-07-20 13:01:12 great 2022-07-20 13:01:18 another ugliness fixed :) 2022-07-20 13:01:32 (it seemed weird to export variables outside the functions... although permitted indeed) 2022-07-20 13:01:35 I should probably take care of that go mess 2022-07-20 13:02:09 and yeah, sorry for being a bit biased - I started off an Arch Linux PKGBUILD whose philosphy is that all the Go flags are duplicated into every single PKGBUILD rather than centrally managed 2022-07-20 13:02:25 while oddly C/C++ flags are shared properly 2022-07-20 13:02:59 My own Makefile adds additional flags but doesn't touch the GOFLAGS variable so that things keep working as they should 2022-07-20 13:03:54 as I clearly want to minimize distro-needed patches 2022-07-20 13:04:07 general guidelines for aports: remove self-updaters, remove all stuff that downloads deps after build or during build (if possible), remove all shenanigans inside source 2022-07-20 13:04:23 shenanigans? ;) 2022-07-20 13:04:46 one "odd" thing I BTW do: I have some files that take about 20 minutes to regenerate, so I rather prepared them in the source tree and have a command to rebuild them 2022-07-20 13:04:49 if possible, all deps should be separate aports (exclusions are go/rust/..) 2022-07-20 13:04:51 they're PNGs of lookup tables for the GPU 2022-07-20 13:05:05 currently I don't rebuild them - but I could 2022-07-20 13:05:41 while on github actions I actually rebuild and diff them on every commit to get notified if I forgot something :) 2022-07-20 13:05:45 unless you're going to make those PNG do malicious stuff, I don't see any objections 2022-07-20 13:05:55 worst they can do is cause black screen in the game 2022-07-20 13:06:00 although I'm probably thinking of JPEG 2022-07-20 13:06:17 well, both for PNG and JPEG I rather trust the Go image loader to not be able to do _too_ bad things 2022-07-20 13:06:35 like, sure, it could crash out of memory, or return nonsense image... but that should be it 2022-07-20 13:07:11 like, not aware of any code execution exploits there 2022-07-20 13:09:12 BTW, the one thing I really dislike about Alpine is how hard X11 is to get to work :( Wayland/Sway was trivial in comparison - every time I set up Alpine, it took me a bunch of trial and error (and rebooting into init=/bin/sh to disable lightdm again) to finally get keyboard to work 2022-07-20 13:09:28 of course, my fault for enabling lightdm service right away :) 2022-07-20 13:09:54 but kinda annoying that it is so easy to start an X server without any input devices, meaning even Ctrl-Alt-Fn doesn't work 2022-07-20 13:10:03 well, Alpine is not really meant as a desktop distro although (too) many people do use it that way 2022-07-20 13:10:12 yeah 2022-07-20 13:10:17 at least Wayland kinda fixes that 2022-07-20 13:10:23 before everything is configured right, Sway just won't start 2022-07-20 13:10:25 problem solved 2022-07-20 13:10:38 X11 is (bad word) (: 2022-07-20 13:11:18 also how come my X11-only game runs 10% to 20% faster in Wayland/Xwayland than on Xorg... this makes no sense either 2022-07-20 13:11:28 given X11 people like had decades to get OpenGL to work well... 2022-07-20 13:11:32 and Wayland does extra compositing, even 2022-07-20 13:12:03 but I get this effect with other games too... really, X11 was so bad, but only when Wayland came out one could really notice 2022-07-20 13:12:10 (after all, the same games on Windows perform even worse...) 2022-07-20 13:12:58 as for Alpine on desktop... well, boot could be faster, but OTOH openrc is way easier to debug 2022-07-20 13:13:10 it seems rather complete nowadays 2022-07-20 13:13:38 but of course, my desktop usage is limited to browser, terminal, gimp and krita ;) 2022-07-20 13:14:41 oh, and mpv, if that even counts ;) 2022-07-20 13:16:54 of course, I do have another desktop related question - for which archs do actually machines exist with accelerated 3D graphics? 2022-07-20 13:17:36 I am aware of the two x86 ones, and the ARM ones for all those chromebooks out there 2022-07-20 13:17:55 leaves ppc64le, s390x, riscv64 2022-07-20 13:18:04 as I don't really want to build for platforms where llvmpipe is all that exists 2022-07-20 13:18:47 i doubt anyone uses s390x as desktop computer 2022-07-20 13:19:21 mhm, I wonder how well it would work as remote desktop 2022-07-20 13:19:35 ppc64le also seems to primarily be IBM Power systems 2022-07-20 13:19:38 not e.g. PPC Macs 2022-07-20 13:19:53 even those would be rather old by now 2022-07-20 13:20:10 i think there are newer ppc64le workstations 2022-07-20 13:20:13 well, in _theory_ on a strong CPU you can turn settings down to minimum and play the game with llvmpipe 2022-07-20 13:20:27 like, 40fps that way on my Lenovo L440 laptop 2022-07-20 13:20:49 w/o turning them down still 20fps, actually impressive based on what the shaders all do 2022-07-20 13:21:02 but also not a great experience that way 2022-07-20 13:22:49 so I'd be rather tempted to restrict platforms to those where 3D acceleration is "likely" and put a comment to build elsewhere at your own risk ;) 2022-07-20 13:23:05 (at least every old laptop with Intel GPU will do) 2022-07-20 13:30:32 ncopa: it is not even possible to use s390x as desktop, there is no GPU :D 2022-07-20 13:35:05 Of course, _technically_ on any platform one could remote desktop + virgl it... ;) 2022-07-20 13:40:28 https://gitlab.alpinelinux.org/divVerent/aports/-/jobs/775262 - is this error in line 53 my fault? 2022-07-20 13:40:38 (fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address) 2022-07-20 13:40:51 your repo is private 2022-07-20 13:40:54 can't see 2022-07-20 13:41:12 oh, fixing that 2022-07-20 13:41:15 that may be the reason even 2022-07-20 13:46:11 Yeah, that fixed it. 2022-07-20 13:46:23 Thanks - nicer error message would be nice, but that explained it :) 2022-07-20 13:46:42 it's not intended for aports repo to be private 2022-07-20 13:47:54 arch should be "all" unless it doesn't build/run on all 2022-07-20 13:48:14 url should not use variables 2022-07-20 13:48:26 we don't use $pkgname in package() 2022-07-20 13:48:52 not a hard stop, but a general guideline (although some people do that) 2022-07-20 13:51:34 yeah, that was an accident when forking 2022-07-20 13:51:56 for some reason visibility defaults to public - until I select my namespace, then it jumps to private, I had missed that 2022-07-20 13:52:06 I have no idea how to use gitlab, so I'll say here: unnecessary backslash in depends 2022-07-20 13:52:16 if there are many deps, each goes on its own line 2022-07-20 13:52:23 good, will do 2022-07-20 13:53:02 source= doesn't fit on the punch card, but I guess for URLs that is OK 2022-07-20 13:54:00 generally we leave first part of URL as is so github.com/divVerent/aaaaxy, without $pkgname 2022-07-20 13:54:19 filename part stays as is 2022-07-20 13:54:24 even in source=? Fine. 2022-07-20 13:55:16 that's just minor thing, it can be left as is tbf 2022-07-20 13:56:20 well, it makes the line slightly shorter, so did that :) 2022-07-20 13:56:38 (also, I had initially sent the MR to the wrong repo - blaming gitlab too ;) but again, I could have noticed) 2022-07-20 13:57:10 sometimes gitlab does that 2022-07-20 13:57:21 it's usually when you have non-public repo 2022-07-20 13:57:33 and it does that even after changing visibility 2022-07-20 13:58:15 that comment above arch is unnecessary 2022-07-20 13:58:46 and the one in check is also unnecessary, imo 2022-07-20 13:58:51 ok 2022-07-20 13:59:06 as for the arch one - what I want to say there is that there is no requirement of the code or platform dependence there 2022-07-20 13:59:11 but you can leave it as see if someone from devs complains about it 2022-07-20 13:59:24 but I probably want to restrict archs and leave a comment for the next person seeing this as for why 2022-07-20 13:59:41 as it does build anywhere - just won't run well unless someone finally makes a nice riscv64 GPU ;) 2022-07-20 14:01:23 could shorten to archs="..." # Needs 3D accel. 2022-07-20 14:02:04 well, pushed the shortened comment now 2022-07-20 14:10:02 \o/ rust 1.62.0 built on s390x! 2022-07-20 14:12:45 yay 2022-07-20 14:14:45 now we need to figure out the rust trademark stuff :P 2022-07-20 14:27:56 rust s390x pushed to edge builders. lets hope 1.62.0 can build 1.62.0 2022-07-20 14:28:25 if this succeeds it means we can upgrade py3-cryptography 2022-07-20 14:28:39 and upgrade openssl3 2022-07-20 14:32:27 oh... what about riscv? 2022-07-20 14:33:04 do we have rust for riscv64? looks like we don't 2022-07-20 14:34:14 ncopa: I started working on it 2022-07-20 14:35:02 is it realistically doable? 2022-07-20 14:35:07 while boostrapping rust on riscv64 works with a few patches i did ran into ICEs with more complicated code and as such it wasn't possible to compile 1.62.0 with a boostrapped rustc 2022-07-20 14:35:22 https://github.com/rust-lang/rust/issues/96876 2022-07-20 14:35:49 patches needed for boostrapping are here https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34151 2022-07-20 14:36:41 but no idea how to fix the run-time compiler crashes, I don't think anyone is actively using or testing rustc on riscv64? 2022-07-20 14:37:15 rust on riscv64 sounds painful 2022-07-20 14:37:29 Ariadne: ^ did you post in rust's zulip about riscv64 musl support? 2022-07-20 14:37:30 it took a half day to compile rust on s390x 2022-07-20 14:38:13 can we drop anything that touches py3-cryptography on riscv64 for now? 2022-07-20 15:15:14 I guess we could drop py3-cryptography on riscv64, though I would prefer to fix rustc on riscv64 instead but I don't think this will happen anytime soon 2022-07-20 15:15:43 Can someone help with https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36626 ? I am adding a subpackge for unbound whith pythonmod enabled, but I am not APKBUILD expert. The build fails in its current form 2022-07-20 15:33:14 nmeum: 🥺👉👈 2022-07-20 15:41:49 :) 2022-07-20 15:48:20 $ ap recursive-revdeps py3-cryptography | xargs ap builddirs | wc -l 2022-07-20 15:48:20 373 2022-07-20 15:48:50 we will lose those packages: https://tpaste.us/Oq5o 2022-07-20 15:49:23 nmeum: i have not yet 2022-07-20 15:49:26 noooo, Plasma Desktop on riscv64 would be lovely 😢 2022-07-20 15:49:59 they are almost all py3-* so I'd say get rid of them 😊 2022-07-20 15:51:29 although >qemu >ceph >cloud-init 🤔 2022-07-20 15:52:05 docker-compose is replaced luckily by docker-compose-cli (go) 2022-07-20 15:52:47 Hmm, qemu 2022-07-20 15:52:51 that would be a problem 2022-07-20 15:53:08 would it? 2022-07-20 15:53:13 although, we run qemu on x86_64 2022-07-20 15:53:15 not on rv64 2022-07-20 15:53:18 :p 2022-07-20 15:53:46 The experience would probably be less then ideal when running qemu on rv64 2022-07-20 15:56:37 just to be absolutely clear, in case anybody *else* decides to raise the same bad faith argument regarding rust 2022-07-20 15:56:44 yes, the rust team is aware of our patches 2022-07-20 15:56:49 there is an MCP to harmonize them 2022-07-20 15:57:22 if you are unwilling to work on the MCP, great, but you are required by the CoC to assume good faith rather than assuming we have not abided by our obligations in the trademark policy 2022-07-20 15:58:07 Ariadne: fyi there is a >10% gcc speedup by adding the missing -O2 flags for CXX/CPP flags 2022-07-20 15:58:30 Ariadne: I suspect this was triggered by some debian thread around the same issue 2022-07-20 15:58:30 ok 2022-07-20 15:58:40 ikke: that debian thread is a troll 2022-07-20 15:58:44 yes 2022-07-20 15:58:48 i do not appreciate the troll propagating here 2022-07-20 16:00:24 currently seeing how many more % is lto for the compiler as well 2022-07-20 16:05:21 eh, just another few % 2022-07-20 16:05:29 the gcc thread is way worse too 2022-07-20 16:05:45 but the -O2 only is https://img.ayaya.dev/NfSlgZFISK0n 2022-07-20 16:06:02 sam_: what gcc thread 2022-07-20 16:06:41 Ariadne: the assho- concerned citizen posted the same shit from the debian bug onto the gcc ml, let me get it 2022-07-20 16:06:49 https://gcc.gnu.org/pipermail/gcc/2022-July/239110.html 2022-07-20 16:06:52 it's so bad faith 2022-07-20 16:08:37 >We’ll call it gust. 2022-07-20 16:08:39 lmao 2022-07-20 16:14:56 "Please do not approach users of the trademarks with a 2022-07-20 16:14:57 complaint. That should be left to the Rust Foundation and its 2022-07-20 16:14:59 representatives. Thanks!" 2022-07-20 16:16:57 https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/#helping-out 2022-07-20 16:16:59 god damn 2022-07-20 16:20:43 i like how we posted the same email 2022-07-20 16:39:25 nice answers. thanks! 2022-07-20 16:40:49 i was about to write something like: "lets remove rust packages. please ask a rust legal representative take contact with us so we can add them back" 2022-07-20 17:06:46 These are good answers indeed, but I feel labelling Wolf as a troll is a mischaracterization. They’re a regular Alpine user who saw the troll in Debian and wanted to make sure Alpine was covered. The original troll appears nowhere around here. 2022-07-20 17:09:18 indeed, not a troll at all 2022-07-20 17:55:15 skarnet: he propagated the troll is what i am saying 2022-07-20 17:55:33 a bit more trust in Alpine devs would suffice 2022-07-20 18:13:50 I think this was more about complaining "distros get special licenses but due to this can I still redistribute Alpine itself w/o my own trademark agreement over Rust" 2022-07-20 18:13:57 a question they probably should ask the Rust foundation 2022-07-20 18:14:21 (and I bet they'd be absolutely OK with that) 2022-07-20 18:16:58 that shouldn't concern them if they redistribute Alpine, since, well, they redistribute Alpine and not different thing 2022-07-20 18:24:00 "depends on how litigious the lawyers are" (and on the country), of course 2022-07-20 18:24:36 but anyway, not a problem in practice, we have already seen how Mozilla handled the Firefox stuff and NO users have been sued for running or even distributing a version someone else patched 2022-07-20 18:25:41 like, they're not using trademarks and C&D letters with fines on them as their main source of income, they're not Gravenreuths 2022-07-20 18:26:32 in fact, doing so would be ceding the market to Chrome, which would be a bad thing for everyone 2022-07-20 18:28:13 You know, creating a programming language, then seeing people reimplement/modify it, watching for years and finally suing them over having similar APIs, who would DO such a thing? ;) 2022-07-20 18:29:30 (ok, fine, I forgot the "have others create the language, then buy them" step) 2022-07-20 18:30:20 nobody would do such a 'orrible thing 2022-07-20 19:25:14 oh right, having rust on s390x now means the s390x rust ci takes 79 millenia 2022-07-20 19:25:26 what a miserable pointless architecture 2022-07-20 20:21:36 panekj: alright i merged the rust static fixes, feel free to tell me if it even works once it builds in 3 hours 2022-07-20 20:22:09 cool, I'm doign cursed things 2022-07-20 20:22:11 :) 2022-07-20 20:22:20 also note this never worked and won't for anything that uses proc-macro 2022-07-20 20:22:34 oh good luck then lol 2022-07-20 20:22:48 proc-macro itself just doesn't support +crt-static 2022-07-20 20:22:50 on any toolchain 2022-07-20 20:22:59 it does but you need to set target 2022-07-20 20:23:22 in what sense 2022-07-20 20:23:33 you have to tell cargo `--target` 2022-07-20 20:23:45 as in give me an example of it working 2022-07-20 20:23:51 code commands etc 2022-07-20 20:24:08 not gonna guess random targets and stuff to build for 30 minutes 2022-07-20 20:24:21 RUSTFLAGS="-C target-feature=+crt-static" cargo build --target 2022-07-20 20:25:12 what the fuck 2022-07-20 20:25:30 this is the dumbest shit i've ever seen 2022-07-20 20:25:38 specifying the exact same default target fixes it? who made this???? 2022-07-20 20:25:49 don't ask me 2022-07-20 20:25:52 thanks 2022-07-20 20:25:53 didn't know 2022-07-20 20:25:54 :D 2022-07-20 20:25:56 but also what the fuck 2022-07-20 20:26:29 I think it even tells you when you do that without --target 2022-07-20 20:26:34 but I don't remember 2022-07-20 20:27:06 nope 2022-07-20 20:27:24 error: cannot produce proc-macro for `abscissa_derive v0.6.0` as the target `x86_64-alpine-linux-musl` does not support these crate types` 2022-07-20 20:27:24 just says stuff like ` 2022-07-20 20:27:31 putting that exact same thing in --target fixes it 2022-07-20 20:27:33 mhmm 2022-07-20 20:27:34 although it fails to link 2022-07-20 20:27:37 so i guess more stuff to fix 2022-07-20 20:30:20 ld: deps/liblibgit2_sys-d56d5d6f57e58092.rlib: error adding symbols: file format not recognized 2022-07-20 20:30:20 hmmm 2022-07-20 20:30:32 liblibgit 2022-07-20 20:31:03 oh my, building anything basic needs so many deps 2022-07-20 20:31:15 `git clone liblibgit.li/liblibgit/liblibgit.git lib` 2022-07-20 20:31:29 ah, maybe i need system .a's of everything 2022-07-20 20:32:31 ah 2022-07-20 20:33:32 ah 2022-07-20 20:33:59 no idea actually, all of them are llvm ir 2022-07-20 20:34:18 what are you building 2022-07-20 20:34:27 ah 2022-07-20 20:34:31 llvm-nm is needed 2022-07-20 20:34:39 llvm-never-mind 2022-07-20 20:35:35 to even read some of them 2022-07-20 20:35:42 but i'm not sure how to pass any of these 2022-07-20 20:36:11 ah, easy fix, okay, works 2022-07-20 20:46:07 just no static vs system libs, so i have one more thing to try there 2022-07-20 20:46:22 have you tried full static? 2022-07-20 20:46:36 LIBGIT2_STATIC=1 etc. 2022-07-20 20:46:49 those would work since the sys crate would just build them static, yes 2022-07-20 20:47:23 but /i think/ pkgconf usage in the sys crates should also work perhaps? unless it always defaults to not static 2022-07-20 20:47:46 it's hit or miss, I'm not sure 2022-07-20 20:47:59 if something depends on libgit2 and it's not static, it will build not static 2022-07-20 20:49:16 yeah, but i'm wondering if it's meant to work at all 2022-07-20 20:51:12 heh 2022-07-20 21:05:33 don’t blame rust/llvm problems on s390x! 2022-07-20 21:05:56 there are none, the machines are just slow as fuck 2022-07-20 21:06:09 usually everything is disabled on s390x anyway so you never see it 2022-07-20 21:07:51 can’t see problems if you never run software :thinking guy: 2022-07-20 21:08:56 :) 2022-07-20 21:09:40 error: '_PATH_WTMP' undeclared here (not in a function) 2022-07-20 21:09:43 48 | WTMP_FILE; 2022-07-20 21:09:49 why 🤔 2022-07-20 21:09:57 what are you building 2022-07-20 21:10:02 busybox 2022-07-20 21:10:14 with the latest changes, or 2022-07-20 21:10:24 quite old 2022-07-20 21:10:38 but 3.16 2022-07-20 21:10:49 the new ones change that specific line 2022-07-20 21:13:51 and it builds without changes to whatever is on either, so what did you change 2022-07-20 21:15:19 I don't see any changes for that on 3.16 2022-07-20 21:15:26 also, man-made horrors 2022-07-20 21:17:37 yeah 2022-07-20 21:42:11 what i really hate is how there's no standard for these damn cargo features 2022-07-20 21:42:40 github issues are standard 2022-07-20 21:42:45 sometimes CARGO_FEATURE_x actually toggles something, sometimes it doesn't, sometimes things have a NAME_OF_THING_FEATURE, sometimes they expect the first one, 2022-07-20 21:43:08 rly fun needing to go read the build.rs of every single -sys crate every time to remember 2022-07-20 21:43:14 it depends if something is actually cargo or if it's passed to rustc 2022-07-20 21:43:50 yeah, the ecosystem where nothing works without cargo to begin with, depends on things outside of cargo 2022-07-20 21:43:50 a+ 2022-07-20 21:44:36 you could try PKG_CONFIG_ALL_STATIC=1 2022-07-20 21:44:48 god you poles are so smart 2022-07-20 21:45:19 nah, I just wasted too much time on building stuff in rust 2022-07-20 21:47:54 that env var doesn't exist in pkgconf itself 2022-07-20 21:47:55 hm 2022-07-20 21:49:56 i've gotten everything so far except openssl 2022-07-20 22:01:55 cargo-audit: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked 2022-07-20 22:01:57 at last 2022-07-20 22:02:30 the fix? OPENSSL_DIR="/usr" 2022-07-20 22:02:34 because of course it is 2022-07-20 22:04:41 lol 2022-07-20 22:04:53 wait 2022-07-20 22:12:35 oh i hit that too 2022-07-20 22:12:37 so stupid 2022-07-20 22:13:56 eyeglancing the scripts makes me guess the issue is it sees /lib/libssl and sets the dir to just / , when all the .a/.so files are in /usr/lib instead 2022-07-20 22:13:56 weh 2022-07-20 22:14:33 but the issue here is whoever came up with these 20 places to put things, there should only be a /lib in the first place 2022-07-20 22:14:42 curse you unix! 2022-07-20 22:15:01 you should merge ur usr 2022-07-20 22:15:03 ez 2022-07-20 22:15:05 i agree! 2022-07-20 22:15:10 do you think anyone else does though? 2022-07-20 22:15:10 do you actually 2022-07-20 22:15:15 cause i do 2022-07-20 22:15:31 yes, there is no point of these double paths that mean the same thing 2022-07-20 22:15:38 i still have no idea who came up with the split in the first place 2022-07-20 22:15:47 i think it's such a sensible idea and the only reason a lot of people oppose it nowadays is kneejerk 2022-07-20 22:16:34 it's so arbitrary and people don't get the split right anyway 2022-07-20 22:16:36 (like, what even is right?) 2022-07-20 22:16:58 same thing for the sbin folder, how useful is that?? wow, a path that is (sometimes) not in default PATH but people can call things in it anyway 2022-07-20 22:17:00 amazing folder 2022-07-20 22:27:58 it made more sense when there were small harddrives and /usr might not be mounted 2022-07-20 22:29:05 yeah, like 1.5MB small... 2022-07-20 22:30:01 it used to be common in install guides to have different partitions for everything 2022-07-20 22:30:30 still is if you're openbsd 2022-07-20 22:30:36 :P 2022-07-20 22:41:41 the /usr split is valid for historical reasons. Nowadays, less so. But it *should not matter either way*. 2022-07-20 22:41:58 it’s not like having a split /usr is problematic in any kind of way. 2022-07-20 22:42:05 sureeeeeeee 2022-07-20 22:42:36 if you’re talking about libraries, that’s two wrongs making kind of a right 2022-07-20 22:42:57 because .so’s and .a’s are two very different types of objects and should not be installed in the same place 2022-07-20 22:43:14 build-time and run-time linkers should not search the same paths 2022-07-20 22:43:35 it sucks, but using /usr/lib for the .a’s and /lib for the .so’s kinda works 2022-07-20 22:44:05 of course lots of software also install .so’s in /usr/lib, because nobody thinks about these things :shrug: 2022-07-20 22:44:11 one would think software is smart enough to look at file name 2022-07-20 22:44:35 lot of things follow FHS where libdir = $prefix/lib 2022-07-20 22:45:02 it’s not even the problem 2022-07-20 22:45:17 the problem is that libdir is the same for static and dynamic libraries 2022-07-20 22:45:27 you should have staticlibdir and dynlibdir instead 2022-07-20 22:46:02 would not be a terrible idea except there are like all of the build systems that would need to be modified :P 2022-07-20 22:46:14 if that fix works for my problem, psykose, you're getting a headpat 2022-07-20 22:46:41 sure maybe i'll be in poland again 2022-07-20 22:46:48 orbea: why do you think people hate their build systems and come up with new ones every year and keep flaming on which one is the best 2022-07-20 22:46:54 maybe even intentionally this time 2022-07-20 22:47:14 because no build system does things right and everybody’s frustrated 2022-07-20 22:47:35 sounds like typical software 2022-07-20 22:48:19 unfortunately yes 2022-07-20 22:48:51 even if new build systems are made no one is going to update every project to use a newer and "better" build system 2022-07-20 22:49:30 trying to build linux from scratch is pain 2022-07-20 22:50:16 orbea: you think so? look at all the effort people are making switching to CMake or meson or ninja or $buildsystemofthemonth 2022-07-20 22:50:24 and these are not optimal by any means 2022-07-20 22:50:55 well, for ninja we at least have samurai 2022-07-20 22:51:01 obviously if something comes up that’s really better, it won’t be popular and nobody will package it 2022-07-20 22:51:03 skarnet: and with all of that effort there are still countless legacy projects doing their own special things 2022-07-20 22:51:04 because that’s how these things go 2022-07-20 22:51:13 or projects like openssl doing other horrible things 2022-07-20 22:51:50 orbea: yes, and I’m one of these “legacy” project, doing my own special thing because nothing preexisting does what I want 2022-07-20 22:52:27 being part of the problem :P 2022-07-20 22:52:37 skarnet: what build system? 2022-07-20 22:52:55 orbea: configure-style + Makefile, but not autoconf 2022-07-20 22:52:55 it can't be as bad as dialog 2022-07-20 22:53:27 panekj: and yet my package files are cleaner than most, go figure 2022-07-20 22:53:55 skarnet: seriously that sounds fine if it works 2022-07-20 22:54:32 it does, and I spent months on it, and I hate that I had to do it 2022-07-20 22:55:00 some of the things I have found working on this are just ... https://bugs.gentoo.org/765709 2022-07-20 22:55:35 slibtool is a very cool idea 2022-07-20 22:55:59 libtool should be totally ditched in the first place tbh, but slibtool is probably the second best solution 2022-07-20 22:56:44 yea, i agree 2022-07-20 22:57:02 getting slibtool to work is much easier than ditching libtool 2022-07-20 22:57:04 maybe we should put slibtool into alpine 2022-07-20 22:57:19 iirc there was like one issue 2022-07-20 22:57:52 there are a handful of slibtool bugs, but most things are projects depending on GNU libtool bugs, like how it silently drops -no-undefined even where there are undefined references... 2022-07-20 23:13:53 wonderful, cargo just installed some other rust toolchain randomly during build of package 2022-07-20 23:17:00 build.rs is great innit 2022-07-20 23:19:19 it's not build.rs 2022-07-20 23:20:06 also it happened when using alpine's cargo 2022-07-20 23:20:25 cargo from rustup didn't do that 2022-07-20 23:21:02 what is it then 2022-07-20 23:21:26 how do I know 2022-07-20 23:22:08 what did you build and what did you see smh headass 2022-07-20 23:22:33 https://usercontent.irccloud-cdn.com/file/hIB8M0Og/image.png 2022-07-20 23:22:53 that message is from rustup 2022-07-20 23:23:32 +5 points for being perceptive 2022-07-20 23:24:59 I'm building https://github.com/lapce/lapce 2022-07-20 23:25:20 for some reason it stopped linking statically completely 2022-07-20 23:26:11 that thing is yet another editor with broken fontconfig 2022-07-20 23:26:13 it's hilarious 2022-07-20 23:26:19 i tried to use it once 2022-07-20 23:26:51 > that thing is yet another editor broken 2022-07-20 23:27:07 yep 2022-07-20 23:27:10 in this case idk why it is 2022-07-20 23:27:21 i straced it and it was calling open/close on the font 2022-07-20 23:27:26 maybe.. 2000 times a second? 2022-07-20 23:27:31 probably because of fount 2022-07-20 23:27:32 the ui was at 4 seconds per frame 2022-07-20 23:27:45 idk why it would open/close a font repeatedly but it sure was having fun 2022-07-20 23:27:56 (while actually rendering with the same font correctly) 2022-07-20 23:29:38 LIBZ_SYS_STATIC=1 LIBSSH2_STATIC=1 LIBGIT2_STATIC=1 PKG_CONFIG_ALL_STATIC=1 OPENSSL_STATIC=1 OPENSSL_NO_VENDOR=1 OPENSSL_DIR=/usr RUSTFLAGS="-C target-feature=+crt-static" cargo +stable build --bin lapce-proxy --target x86_64-unknown-linux-musl --release 2022-07-20 23:30:52 so elegant 2022-07-20 23:32:00 only 700+ crates 2022-07-20 23:32:01 weak 2022-07-20 23:32:24 i think even tidb was less than this, impressive 2022-07-20 23:33:49 well, compare that to vscode 2022-07-20 23:34:05 > Dependencies defined in yarn.lock 1,665 2022-07-20 23:34:52 and this is just main yarn.lock 2022-07-21 00:20:30 rbq: well, i got everything to work with wxwidgets-3.2 except for 4 things 2022-07-21 00:21:41 Ok 2022-07-21 00:21:59 codeblocks, filezilla, maitreya, and (funnily) wxpython 2022-07-21 00:23:04 So, when will wxwidgets-3.2 be merged? 2022-07-21 00:23:14 when i fix those 4 things 2022-07-21 00:23:40 funnily, everything using wxgtk (python2) actually built against 3 fine 2022-07-21 00:23:44 er, (gtk2) 2022-07-21 00:23:46 tired 2022-07-21 00:24:48 You should rest... 2022-07-21 00:25:18 Now I understand what you meant by "gtk2 is gone entirely" 2022-07-21 00:25:46 You were referring to wxgtk 2022-07-21 00:26:47 the new version doesn't have gtk2 bindings, that's all 2022-07-21 00:27:51 Ok 2022-07-21 00:28:04 ok, codeblocks has a PATCHARRAY to fix this 2022-07-21 00:28:07 onto the others 2022-07-21 00:29:14 Thanks for working on this :) 2022-07-21 00:29:35 how come 2022-07-21 00:30:42 Well you're trying to make those 4 aports compile with wxwidgets-3.2, which is nice... 2022-07-21 00:41:38 meh 2022-07-21 04:30:16 i was looking at the libexecinfo dogshit again, and the latest one from the freebsd source tree actually works 2022-07-21 04:30:28 or well, it's still quite useless, but you actually don't segfault instantly 2022-07-21 04:30:51 i guess that's what you get when it also needs -lelf 2022-07-21 04:32:55 maybe i should port the latest git version 2022-07-21 04:32:59 instead of whatever we have in aports 2022-07-21 05:25:50 done already, maybe not such a terrible idea 2022-07-21 06:56:44 psykose: where are the rust fixes!!! 2022-07-21 06:56:49 which ones 2022-07-21 06:56:50 it works 2022-07-21 06:57:26 rust build time is 8pm 2022-07-21 06:57:45 yeah that's the working one 2022-07-21 07:09:37 openssl linked statically 👀 hopefully crt will too 2022-07-21 07:12:41 error[E0463]: can't find crate for `core` 2022-07-21 07:12:55 note: the `x86_64-unknown-linux-musl` target may not be installed 2022-07-21 07:13:03 oops 2022-07-21 07:17:48 rust is a lot nicer when you don't have rustup installed at all 2022-07-21 07:18:11 it's also nicer when you specify correct target 2022-07-21 07:31:14 still linked to musl 2022-07-21 07:31:59 what does `file` say 2022-07-21 07:32:18 target/x86_64-alpine-linux-musl/release/lapce-proxy: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped 2022-07-21 07:32:22 yep, static 2022-07-21 07:32:26 good one panekj! 2022-07-21 07:32:40 ACTION is confuse 2022-07-21 07:32:50 is ldd wrong? 2022-07-21 07:32:52 yes 2022-07-21 07:32:56 oh lol 2022-07-21 07:32:59 copy it to glibc if you really want to make sure 2022-07-21 07:34:44 wow 2022-07-21 07:34:46 ok 2022-07-21 07:34:51 I love software 2022-07-21 07:37:33 psykose: congrats, you received a coupon for headpats, it's valid until end of year 2022-07-21 07:40:31 🥺 2022-07-21 07:43:38 ah, the classic trap of static pie not being displayed as static 2022-07-21 07:44:43 Hmmm, static pie 2022-07-21 07:44:50 Hmmm, pie 2022-07-21 07:44:59 ikke: so good it will shock you 2022-07-21 07:45:02 yummm, apple pie 2022-07-21 07:47:40 also file doesn't detect static-pie until like 5.38+ which is quite recent 2022-07-21 07:49:27 (if 3 years is recent to you. also i forgot the actual version) 2022-07-21 07:55:21 rust is so weird 2022-07-21 08:38:43 ikke: please check why ppc64le has diffent setting for queue size for #14041 2022-07-21 10:36:38 ugh. bootstrap.sh broke again: /home/ncopa/aports/main/busybox/src/busybox-1.35.0/include/libbb.h:110:13: fatal error: utmps/utmps.h: No such file or directory 2022-07-21 10:37:25 I suppose we could use some nightly bootstrap.sh run 2022-07-21 10:37:40 ah, yeah, utmps wasn't conditionalised to bootstrap 2022-07-21 10:38:18 i think you can just skip it for now though, busybox isn't used by anything after that i know of 2022-07-21 10:40:48 maybe i misunderstood something. i kinda thought that libutmps was a drop-in replacement? 2022-07-21 10:43:30 utmps fails to cross-compile: ./configure: error: target riscv64-alpine-linux-musl does not match the contents of /usr/lib/skalibs/sysdeps/target 2022-07-21 10:43:49 skarnet: ^ 2022-07-21 10:44:13 psykose: is there an easy way to replace distutils with setuptools 2022-07-21 10:44:24 (i hate python) 2022-07-21 10:44:59 pretty sure setuptools is worse 2022-07-21 10:45:57 idk, but it screams at me 2022-07-21 10:46:20 many such cases 2022-07-21 10:46:27 DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives 2022-07-21 10:46:36 oh, that you can ignore for now :P 2022-07-21 10:46:50 is there a setup.cfg? 2022-07-21 10:47:28 the alternative thing you want is pyproject with whatever backend 2022-07-21 10:47:30 flit-core is fine 2022-07-21 10:48:07 just apk add py3-flit and flit init 2022-07-21 10:49:20 ikke: ye 2022-07-21 10:50:24 psykose: can i get non-interactive type of it 2022-07-21 10:50:27 :P 2022-07-21 10:50:28 You could use py3-build + py3-installer 2022-07-21 10:50:36 in what sense 2022-07-21 10:50:49 that command just gives you the default 8 lines of config 2022-07-21 10:50:51 it asks me for stuff when i run it in abuild 2022-07-21 10:50:55 oh to build 2022-07-21 10:50:58 smh headass 2022-07-21 10:51:01 obviously 2022-07-21 10:51:03 just build whatever the project has 2022-07-21 10:51:05 or so I thought 2022-07-21 10:51:13 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/py3-executing/APKBUILD 2022-07-21 10:51:21 for pyproject.toml, use that 2022-07-21 10:51:51 for check you might want to install to test dir, https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/py3-matrix-common/APKBUILD 2022-07-21 10:52:04 i should move gpep517 to main and start using that instead of build 2022-07-21 10:52:17 is setting PYTHONPATH not enough? 2022-07-21 10:52:33 rust-lldb is broken on x86. it depends on lldb which is disabled on x86 2022-07-21 10:53:18 also if soemthing depends on rust-lldb, we have a build order resolver problem 2022-07-21 10:53:30 there is setup.cfg and setup.py only 2022-07-21 10:53:33 ikke: for some reason no 2022-07-21 10:53:38 panekj: then just setup.py build 2022-07-21 10:54:39 ncopa: yeah, but that's fine? nothign depends on rust-lldb 2022-07-21 10:55:13 from what I can see, lldp was never enabled on x86 2022-07-21 10:55:33 it was disabled in 2017 2022-07-21 10:56:05 i'll check the re-enable 2022-07-21 10:56:15 build failure on x86: /usr/bin/ld: /usr/lib/llvm14/lib/libLLVMSupport.a(CommandLine.cpp.o):CommandLine.cpp:(.text._ZN4llvm12function_refIFvNS_9StringRefEEE11callback_fnIZNS_2cl26TokenizeWindowsCommandLineES1_RNS_11StringSaverERNS_15SmallVectorImplIPKcEEbEUlS1_E_EEviS1_+0x8e): more undefined references to `__stack_chk_fail_local' follow 2022-07-21 10:56:34 50d30564ce2aae879a5afd925c9addfb158afade 2022-07-21 10:56:43 Similar as when it was disabled 2022-07-21 10:56:50 ncopa: seen the same when toggling ssp_nonshared linking for rust 2022-07-21 10:57:03 it comes from that 2022-07-21 10:58:18 idk why these errors are only on x86 2022-07-21 10:59:31 ikke: also the reason i wanted to move things to gpep517 is build depends on packaging, and a new setuptools dependency depends on pyproject.toml, but setuptools depends on packaging. so it would remove that and make any pyproject.toml project clean to build from nothing 2022-07-21 10:59:58 right 2022-07-21 11:00:07 less dependencies == lead headaches 2022-07-21 11:00:09 yep 2022-07-21 11:00:10 :D 2022-07-21 11:00:14 s/lead/less 2022-07-21 11:00:14 ikke meant to say: less dependencies == less headaches 2022-07-21 11:00:25 the cli is a bit stupid but it works fine, no issues 2022-07-21 11:07:37 ayy i ran the lldb configure on riscv and it only took 8 minutes!! 2022-07-21 11:13:45 Enough to have a tea 2022-07-21 11:19:07 love tea 2022-07-21 11:20:56 i love it too 2022-07-21 11:22:17 ValueError: Git tag '%(describe:tags=true)' doesn't correspond with version '0.180.0' specified in the source code 2022-07-21 11:22:28 why people need to do such terrible things 2022-07-21 11:22:32 lesigh 2022-07-21 11:23:18 I think we need to pass -lssp_nonshared to the linker. https://www.openwall.com/lists/musl/2018/09/11/2 2022-07-21 11:23:28 we have a clang patch that enables ssp by default 2022-07-21 11:23:40 so we should also pass -lssp_nonshared i think 2022-07-21 11:30:56 manually adding -lssp_nonshared into ldflags doesn't work since the order is wrong (it gets put before the llvm.a), so yeah 2022-07-21 11:31:24 i think this has to be added into some llvm config section, no? like pkgconf, but wherever it is 2022-07-21 11:31:44 for anything using libLLVMSupport.a 2022-07-21 11:34:28 is there are cmd:diffstat ? 2022-07-21 11:35:04 but like, not necessarily a cmd: 2022-07-21 11:36:39 LLVM_LDFLAGS in BuildVariables.inc seems to be the one 2022-07-21 11:43:04 i have a patch for it, will see if it does what is intended 2022-07-21 11:43:52 also testing a riscv build 2022-07-21 11:43:56 so you can go back to rust :) 2022-07-21 11:53:17 psykose: lol 2022-07-21 11:53:21 haha 2022-07-21 11:53:27 :) good timing 2022-07-21 11:53:59 (for reference: #14042) 2022-07-21 12:00:29 my god 2022-07-21 12:00:43 :D 2022-07-21 12:00:59 Well, daniel cannoy complain about lack of support 2022-07-21 12:01:02 cannot* 2022-07-21 12:01:15 we do provide refunds don't we 2022-07-21 12:01:22 Yup 2022-07-21 12:01:29 I'd like one 2022-07-21 12:01:40 Please bring your receipt 2022-07-21 12:01:55 Can you provide the template 2022-07-21 12:03:24 or can I use one from npp? https://notepad-plus-plus.org/news/v844-happy-users-edition/ 2022-07-21 12:03:55 (happy user only) 2022-07-21 12:04:08 https://tpaste.us/0W47 2022-07-21 12:04:19 :) 2022-07-21 12:04:24 (: 2022-07-21 12:06:13 ncopa: i think !36693 should fix it, will see 2022-07-21 12:06:42 $ llvm-config --ldflags 2022-07-21 12:06:43 -L/usr/lib/llvm14/lib -lssp_nonshared 2022-07-21 12:07:01 if the order is still wrong, then idk 2022-07-21 12:07:03 more stuff to check 2022-07-21 12:07:19 riscv64 failure is different, looking at that now 2022-07-21 12:07:58 this spicy food isn't spicy enough 2022-07-21 12:08:47 happy customer 2022-07-21 12:13:57 psykose: i was thinking, since the default ssp is enabled in clang, shouldn't we enable it in clang instead of llvm? 2022-07-21 12:14:46 that would perhaps make sense, i don't know where that is 2022-07-21 12:14:47 could check 2022-07-21 12:15:17 ncopa: two things 2022-07-21 12:15:28 three 2022-07-21 12:15:48 Who bids more? 2022-07-21 12:15:49 1. ISTR people didn’t want to build bootstrap with utmps, that’s why there are conditional statements everywhere in the apkbuilds 2022-07-21 12:15:59 community/clang/30-Enable-stack-protector-by-default-for-Alpine-Linux.patch 2022-07-21 12:16:16 if you want utmps to be used in bootstrap, it’s a possibility, but then a few changes will be necessary 2022-07-21 12:16:50 im fine either way, either fix crossomile of utmps or fix busybox build to build without utmps 2022-07-21 12:17:03 s/crossomile/crosscompile/ 2022-07-21 12:17:03 ncopa meant to say: im fine either way, either fix crosscompile of utmps or fix busybox build to build without utmps 2022-07-21 12:17:23 2. when cross-building, the sysdeps location for the target architecture (determined when building skalibs) needs to be provided to utmps 2022-07-21 12:18:04 if it’s the same APKBUILD that is used in cross-building then I can modify all the skaware APKBUILDs so they support cross 2022-07-21 12:18:17 yes, they use the regular APKBUILDs 2022-07-21 12:18:27 I haven’t done it so far because I had always been told they’d never be used for cross-compilation 2022-07-21 12:18:44 i think disabling utmps when bootstrapping busybox is fine 2022-07-21 12:18:59 it’s what’s currently happening in the bb apkbuild 2022-07-21 12:19:05 or should be, at least 2022-07-21 12:19:11 build fails 2022-07-21 12:19:46 will fix, can it wait for this evening? I have outside appointments this afternoon 2022-07-21 12:19:52 12:36 <@ncopa> ugh. bootstrap.sh broke again: /home/ncopa/aports/main/busybox/src/busybox-1.35.0/include/libbb.h:110:13: fatal error: utmps/utmps.h: No such file or directory 2022-07-21 12:20:08 sure, no worries 2022-07-21 12:21:23 for the future: is the gcc triplet available in an envvar in APKBUILDs? and is there a standard location to install arch-dependent target files (such as libs) when cross-building? 2022-07-21 12:21:47 $CHOST $CBUILD $CTARGET 2022-07-21 12:21:56 ref: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/functions.sh.in 2022-07-21 12:22:18 thanks 2022-07-21 12:22:43 ncopa: that doesn't say how to add -lssp_nonshared to the default link line for everything 2022-07-21 12:23:10 that i know. i tried this myslef but i dont think it works: 2022-07-21 12:23:25 https://tpaste.us/a0NN 2022-07-21 12:23:39 you want Linux.cpp not Gnu pretty sure 2022-07-21 12:24:07 unless i'm wrong which target we are using.. 2022-07-21 12:24:12 i searched for -lssp_nonshared in the sources and found it for things like MinGw 2022-07-21 12:24:29 we already touch Gnu.cpp for some reason. I dont know 2022-07-21 12:25:18 ah, if the triples are there then yes 2022-07-21 12:25:20 correct place 2022-07-21 12:25:39 can try without ssp first 2022-07-21 12:25:43 just nonshared 2022-07-21 12:27:45 (i don't think anything even provides `libssp` anyway) 2022-07-21 12:28:47 you also want to add `if(getToolChain().getArch() == llvm::Triple::x86) { ` before that 2022-07-21 12:29:05 yeah 2022-07-21 12:29:15 i mean without ssp first 2022-07-21 12:29:27 not sure about the llvm::Triple::x86 check 2022-07-21 12:29:34 it's not needed on any other platform 2022-07-21 12:30:01 https://www.openwall.com/lists/musl/2018/09/11/2 claims powerpc 2022-07-21 12:30:07 we don't even support that 2022-07-21 12:30:09 but its maybe 32 bit ppc 2022-07-21 12:30:11 yeah 2022-07-21 12:30:17 if it was the one we supported, it would fail like x86 2022-07-21 12:30:25 ok, sounds good then 2022-07-21 12:30:25 (but it builds this whole time, so) 2022-07-21 12:30:42 it also measn that clang is basically broken on x86 right now? 2022-07-21 12:31:01 no, stuff still builds in ci/builders (and this fails at build time) 2022-07-21 12:31:20 but for these cases, yeah 2022-07-21 12:31:26 well 2022-07-21 12:31:36 we don't actually use clang very widely, so maybe it's more common than i think it is 2022-07-21 12:31:40 so yeah, nice fix 2022-07-21 12:31:43 lots of fixes recently 2022-07-21 12:33:19 ~ $ ./hello 2022-07-21 12:33:19 Hello rust 2022-07-21 12:33:19 Linux ncopa-edge-riscv64 5.15.11-0-lts #1-Alpine SMP Thu, 23 Dec 2021 08:03:24 +0000 riscv64 Linu 2022-07-21 12:33:19 ~ $ uname -a 2022-07-21 12:33:32 build something bigger 2022-07-21 12:33:40 i will try the testcase 2022-07-21 12:33:41 like rust itself with the same compiler on riscv-native 2022-07-21 12:33:44 or that, yeah 2022-07-21 12:37:42 or static binary with proc-macro 2022-07-21 13:32:36 hmm, TIL go version -m 2022-07-21 13:33:50 what rust targets do we have 2022-07-21 13:34:20 oh huh, that's all the deps 2022-07-21 13:34:22 wow 2022-07-21 13:34:31 well, external 2022-07-21 13:34:34 so it's just as useless as before 2022-07-21 13:34:38 guess, I can just steal that from targets patch 2022-07-21 13:34:52 panekj: there's no cross 2022-07-21 13:34:59 the only targets are chost and wasm32 2022-07-21 13:35:11 ok? 2022-07-21 13:35:22 whadya mean 'ok' 2022-07-21 13:35:33 I still need the targets 2022-07-21 13:35:43 for what 2022-07-21 13:35:58 so I can build the goddamn proc-macro static bins 2022-07-21 13:36:14 i am not sure how this relates to targets at all 2022-07-21 13:36:20 it prints you the target when it fails and you use that 2022-07-21 13:36:31 and they're all arch-alpine-linux-musl 2022-07-21 13:37:05 sure, I'm just gonna magically know if arm is eabi or eabihf 2022-07-21 13:38:58 ikke: wow.. that go version -m thingy can be used to track security issues 2022-07-21 13:40:26 panekj: both our armhf and armv7 are hard-float 2022-07-21 13:40:42 i assume they are that for rust too, but I havent verified 2022-07-21 13:41:20 the rust testcase for riscv64 does not segfault with latest rust/llvm. 2022-07-21 13:41:37 yes, I already read the patch for rust 2022-07-21 13:43:31 armv7 rust is actually wrong 2022-07-21 13:43:37 i will fix it 2022-07-21 13:44:01 (: 2022-07-21 13:44:19 ncopa: rust on rv64 soon? 2022-07-21 13:44:24 it inherits armv7_unknown_linux_musleabihf 2022-07-21 13:44:33 which sets "+v7,+vfp3,-d32,+thumb2,-neon" 2022-07-21 13:44:40 but our v7 has +neon +thumb-mode 2022-07-21 13:44:46 so we can add more features 2022-07-21 13:45:43 ncopa: the issue is that that go output does not include internal go stuff 2022-07-21 13:45:54 so go compiler updates that fix stuff in the 'syscall' mod or whatever are not in that 2022-07-21 13:46:03 so it doesn't help with the 'compiler came out, lets rebuild everything' 2022-07-21 13:46:14 speaking of we're 2 weeks behind on a go cve patch 2022-07-21 13:47:38 panekj: depends on how long time it takes to build it, but yes. 2022-07-21 13:47:52 psykose: you want me to update go? 2022-07-21 13:48:00 there's an mr already and it works 2022-07-21 13:48:06 just needs the rev bump for everything 2022-07-21 13:48:08 and 3.16 2022-07-21 13:55:08 actually, no 2022-07-21 13:55:09 hm 2022-07-21 13:57:01 Ariadne: what is the armv7 baseline? we have --with-fpu=vfpv3-d16 which according to https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html is +vfpv3-fp16 which is VFPv3-only and no NEON (which would be +neon-fp16 i think) 2022-07-21 13:57:17 but we /do/ have neon enabled for most armv7 things where things have a toggle 2022-07-21 13:58:17 iirc it was neon supported, but i would assume the fpu would be the neon one then 2022-07-21 14:15:43 ncopa: yes, that's what I was thinking, but psykose is right that it's not useful for the standard library 2022-07-21 14:16:03 it's still quite good for 'random gomod had a cve' if we ever get around to that 2022-07-21 14:17:29 Yup 2022-07-21 14:19:42 pushed all go rebuilds 2022-07-21 14:19:52 arm will run out of space as always, have fun :) 2022-07-21 14:27:24 Yaaaay 2022-07-21 17:11:10 Ariadne: did you see https://gitlab.alpinelinux.org/ariadne/alpine-gcc-patches/-/merge_requests/12 ? I haven't noticed any gcc or gccgo issues locally on x86_64 so far with the patchset 2022-07-21 17:44:37 anybody here had some issue with the latest jellyfin update? 2022-07-21 17:44:49 I don't use jellyfin 2022-07-21 18:08:43 Now that we have Rust on s390x, do we want to enable GNOME packages on s390x? I'm not sure anyone actually would use GNOME on that platform anyway? 2022-07-21 18:08:52 i would rather not really 2022-07-21 18:09:36 Correct me if I'm wrong, but I understand s390x Alpine mostly is used for Docker purposes? 2022-07-21 18:10:21 That's at least one of the main usecases from what I understood 2022-07-21 18:11:24 But once rv64 rust is a thing, we can finally upgrade py3-cryptography 2022-07-21 18:11:34 Ariadne I understand you are at least somewhat involved with the s390x port, do you think GNOME is something someone would want to use on that platform? 2022-07-21 18:11:50 Newbyte: These mainframes don't have a graphics card 2022-07-21 18:12:09 Oh, I see then 2022-07-21 18:12:11 desktop is not a thing on s390x 2022-07-21 18:12:14 if someone wants s390x support for something you should ask them to pay you $300 an hour for it 2022-07-21 18:12:17 simple as 2022-07-21 18:12:24 :) 2022-07-21 18:12:28 So there's no s390x workstations? 2022-07-21 18:12:30 psykose: and that would probably be cheap 2022-07-21 18:12:32 Newbyte: no 2022-07-21 18:13:24 we could save almost 1 GB of space by disabling supertuxkart on s390x probably 2022-07-21 18:13:32 if storage space still is an issue 2022-07-21 18:13:42 fine with me to disable it 2022-07-21 18:13:51 we could save a lot of space by disabling half of aports on it lol 2022-07-21 18:14:12 a lot of kde is there too 2022-07-21 18:14:16 heh 2022-07-21 18:16:14 i wouldn't mind doing it 2022-07-21 18:19:59 Hello ! 2022-07-21 18:20:14 o/ 2022-07-21 18:20:50 how are you 2022-07-21 18:20:58 Doing quite alright 2022-07-21 18:21:09 just disable all graphics stuff 2022-07-21 18:25:02 actually, I guess someone could want to run a supertuxkart server on s390x? 2022-07-21 18:25:30 obviously the best use for an expensive IBM mainframe 2022-07-21 18:26:01 Newbyte: do you want to? 2022-07-21 18:28:44 panekj I'm good 2022-07-21 18:30:29 my s390x machine takes too much power 2022-07-21 18:30:39 done: !36710 2022-07-21 18:30:41 i am probably going to sell it :p 2022-07-21 18:31:06 where'd you get an s390x machine from anyway? 2022-07-21 18:31:35 three dead ones from govdeals.com equals one working one 2022-07-21 18:35:43 Ariadne: what if we took libexecinfo but ported it from the freebsd tree directly so it doesn't segfault at least (even though it's still useless and like 1 frame) 2022-07-21 18:35:45 bigbrain 2022-07-21 18:36:04 ACTION shrugs 2022-07-21 18:36:22 i already have a working packaged port but i'm wondering how bad of an idea it is 2022-07-21 18:36:32 it goes from unmaintained garbage to unmaintained garbage so it can't be that bad 2022-07-21 18:36:44 main downside is it needs libelf 2022-07-21 18:38:29 alternatively.. we could drop it, and patch out the 20 aports that use libexecinfo 2022-07-21 18:38:33 but the current state doesn't really make sense 2022-07-21 18:57:08 Ariadne: did you see my question about the armv7 baseline? 2022-07-21 18:59:15 psykose: i have no idea what baseline is for armv7, did not introduce it 2022-07-21 18:59:44 who would 2022-07-21 19:32:02 Stupid question, how much RAM does the s390x build machine have? 2022-07-21 19:32:34 Why is that a stupid question? 2022-07-21 19:33:03 32G 2022-07-21 19:33:22 Wow. Well, my heavy OpenGL based game test ran out of memory twice there, so I decided to exclude the arch for now. 2022-07-21 19:33:43 given the game works on laptops with 2G RAM... 2022-07-21 19:37:37 https://gitlab.alpinelinux.org/divVerent/aports/-/jobs/776074 - according to the backtrace (which mentiones an init() method), it failed before any application code even ran - feels a bit odd to fail that early, but fine by me, it's not like I insist on that arch :) 2022-07-21 19:38:21 could also be a Go/s390x problem maybe, or something really bad in the glfw cgo code 2022-07-21 19:38:25 The CI host didn't use more than 16G of ram over the last 12h 2022-07-21 19:38:32 I suspect that 2022-07-21 19:38:32 ok, that's good 2022-07-21 19:38:42 so at least I don't need to feel guilty about having potentially OOM'd the machine 2022-07-21 19:40:08 but just a per-container memory limit for my own build 2022-07-21 19:40:27 We don't have a per container memory limit 2022-07-21 19:40:36 So not sure why it says it ran out of memory 2022-07-21 19:43:23 Is that maybe a 32bit arch with some kind of PAE-ish extension? 2022-07-21 19:43:54 Like, x86/32bit works for me, even on Windows where the address space limit is 2G, but that may still differ across archs 2022-07-21 19:44:29 No, iirc it's 64-bits 2022-07-21 19:44:33 big-endian 2022-07-21 19:45:03 In any case, I don't suspect anyone wanting to / able to play these games on s390x 2022-07-21 19:45:15 It doesn't even have a desktop environment 2022-07-21 19:48:49 divVerent: yes, it's 64 bit 2022-07-21 19:49:02 So I suspect something else going on 2022-07-21 20:59:24 Great, thanks. On another note, it seems like there isn't yet very extensive documentation on how to use Gitlab... e.g. I find it somewhat weird that I can approve my own MR, which seems wrong (but also I suspect the button simply does nothing). 2022-07-21 21:00:23 yes, that's a gitlab thing 2022-07-21 21:00:24 It does nothing 2022-07-21 21:00:47 To have more control over it, you need to have premium features 2022-07-21 21:00:54 Like, I now removed the Draft: - I suspect this is all to put it in the review queue, or do we want for self-approval as an explicit "this is ready" (kinda how some projects use the git signoff feature)? 2022-07-21 21:01:02 We use it at most for maintainers approving MRs from others 2022-07-21 21:01:13 good then 2022-07-21 21:01:15 No, no need to approve it 2022-07-21 21:01:30 just to be clear, I don't expect an immediate review or anything - just don't want it to be stuck for my own fault of using gitlab wrong :) 2022-07-21 21:01:55 it was ready forever but you had it set to draft :) 2022-07-21 21:02:00 sure 2022-07-21 21:02:08 because I wanted to combine this with a release of the game... 2022-07-21 21:02:17 except... well, Ubuntu kinda forced me to do that release earlier 2022-07-21 21:02:29 (snap security hole notification for a dependency I didn't even want but had to take to get ALSA) 2022-07-21 21:03:02 like, the snap ALSA support pulls in half of GNOME just so it can show an error dialog 2022-07-21 21:03:37 something I am happy Alpine doesn't do... "df" looks so happy 2022-07-21 21:04:12 lol at that eturnal mail 2022-07-21 21:04:34 that doesn't sound related to alsa itself 2022-07-21 21:04:40 yeah, of course not 2022-07-21 21:04:44 which has give or take 0 deps lol 2022-07-21 21:05:07 panekj: which one 2022-07-21 21:05:26 I got only one 2022-07-21 21:05:29 somewhere in there, Pulseaudio is also involved ;) 2022-07-21 21:05:54 Dear Alpine team, please find attached a sprunge link containing our patch to include the... 2022-07-21 21:06:44 where is that 2022-07-21 21:06:49 aports 2022-07-21 21:06:50 ml 2022-07-21 21:06:59 btw. can spam be gone? https://lists.alpinelinux.org/~alpine/aports/%3C62B425A103E9085E%40mta-out-01.alice.it%3E%20%28added%20by%20postmaster%40alice.it%29 2022-07-21 21:07:15 ah 2022-07-21 21:07:25 gone 2022-07-21 21:07:34 i never check the aports ml 2022-07-21 21:07:37 what a miserable place 2022-07-21 21:07:42 I do 2022-07-21 21:07:45 from time to time 2022-07-21 21:08:16 I window shop it from time to time 2022-07-22 00:40:34 rbq: alright, i got literally everything to work with wx 3.2 except for maitreya 2022-07-22 00:40:40 hi, /etc/e2scrub.conf is packaged in e2fsprogs while /usr/sbin/e2scrub in e2fsprogs-extra 2022-07-22 00:40:44 wayland actually usable now 2022-07-22 00:40:46 hope this is ok ? 2022-07-22 00:42:04 installing extra installs the base package 2022-07-22 00:54:50 there you go: !36732. Sorry for the delay. 2022-07-22 00:59:21 gonna verify the bootstrap real quick 2022-07-22 01:11:43 psykose: Ok, when will wx 3.2 be merged? 2022-07-22 01:11:51 not until that is fixed 2022-07-22 01:11:58 i can't just merge things and break random things from installing 2022-07-22 01:12:53 From what you've seen so far, does it look like it is fixable? 2022-07-22 01:13:34 it's your package, you tell me :) 2022-07-22 01:13:39 if you want me to send you 3.2, i can 2022-07-22 01:19:10 I'm not sure I'll be able to do much, don't know C++ 2022-07-22 01:19:14 fwiw 3-4 of the things need a PATCHARRAY to work with 3.2 so it's fine if it takes longer. but the software is not very good in the first place, so the standard isn't very high there 2022-07-22 01:19:51 https://img.ayaya.dev/dpgGbior9LS9 apply onto aports and build community/wxwidgets and use wxwidgets-dev if you want to try 2022-07-22 01:22:43 but i've been awake for 35 hours and that's all for me for today 2022-07-22 01:22:54 Good night 2022-07-22 07:20:37 ncopa: nice to know that rustc 1.62.0 doesn't segfault on riscv64 musl anymore (maybe they fixed the ICEs since 1.60.0), did you try compiling rust itself with the boostrapped rustc? does it work? 2022-07-22 08:12:57 i tried compile rust with the crosscompiled binaries yes 2022-07-22 08:13:22 might have been a bug in rust or maybe in llvm. i dont know 2022-07-22 09:12:41 ncopa: but you didn't run into any issue yet when compiling rust with the cross-compiled binaries? because in that case there would be no blocker regarding rust support on riscv64 2022-07-22 10:43:33 correct. i was able to build rust with the crosscompiled binaries 2022-07-22 10:43:45 and i have pushed rust for riscv64 already 2022-07-22 10:44:14 so we now have rust on all our architectures 2022-07-22 10:44:30 well, as soon build-edge-riscv64 finishes 2022-07-22 12:46:50 that takes us one step closer to being the best distro for using rust on :) 2022-07-22 13:05:43 if there is such a thing 2022-07-22 13:42:46 skarnet: please consider adding 'provide dev' line to depends() in mdevd-init. 2022-07-22 13:44:23 hm, good idea, but then the eudev init script should as well 2022-07-22 13:44:47 working on it 2022-07-22 13:44:49 it has this line in udev-trigger 2022-07-22 13:50:13 Because acpid depends on dev and I ended up running mdevd and udevd 2022-07-22 13:51:16 wait, in git master mdevd already provides dev 2022-07-22 13:52:23 anyway once my MR+TSC proposal is accepted and merged all this will be moot since only one set of device manager init scripts will be installed at a time 2022-07-22 13:52:26 hint, hint 2022-07-22 13:52:55 but yeah for now udev needs to provide dev and mdevd already does in master 2022-07-22 14:07:17 !36741 2022-07-22 14:15:15 Please note that udev-trigger script also provides dev 2022-07-22 14:17:22 gah. Well that’s very silly. 2022-07-22 14:17:47 udev-trigger is the coldplug, not the device manager. 2022-07-22 14:18:28 Sigh. Fixing this. I’m not paid to fix gentoo shit though, and I’m not doing it on my free time either, so I won’t dive too deep into this. 2022-07-22 14:21:20 I think it's done so coldplug would be done even if it is not explicitly enabled 2022-07-22 14:21:58 maybe, but that’s very much the wrong way to ensure this 2022-07-22 14:22:04 setup-devd gets it right 2022-07-22 14:22:11 so it’s not needed 2022-07-22 14:22:22 (on Alpine) 2022-07-22 14:28:46 there, fixed. >.> 2022-07-22 15:06:19 time to re-enable all the rust aports on riscv64 and s390x :s 2022-07-22 15:18:01 Let me upgrade the host first :P 2022-07-22 15:49:58 Seems like rust is stuck 2022-07-22 15:50:30 https://tpaste.us/en5E 2022-07-22 15:50:35 One process Z, one process S 2022-07-22 15:50:38 no CPU usage 2022-07-22 15:52:04 FUTEX_WAIT, so I don't think anythign will happen 2022-07-22 15:54:02 upgrading the rv64 builder host 2022-07-22 16:04:20 hum 2022-07-22 16:04:45 i guess you can upgrade the host and reboot and wee what happens? 2022-07-22 16:05:16 ncopa: just did that 2022-07-22 16:05:21 host is up again 2022-07-22 16:42:47 hmm, no gitea seems to be stuck 🤨 2022-07-22 17:56:12 ncopa: the container was recreated 2022-07-22 17:56:29 so the packages you installed for bootstrapping rust are no longer there 2022-07-22 17:56:36 (I'm not sure why the container was gone) 2022-07-22 17:57:14 ncopa: are these the packages that you put there? 2022-07-22 17:57:16 /var/cache/distfiles/tmp/packages/community/riscv64 2022-07-22 18:11:07 installed cargo and rust from that repo 2022-07-22 18:41:33 ikke: yes, those are the packages 2022-07-22 18:41:37 thanks 2022-07-22 18:43:17 poor skarnet, who opened a box of worms that have been sleeping for over a decade (provides dev, mdev, coldplug, hwdrivers....) 2022-07-22 18:47:29 keeping an 👀 on the builder :) 2022-07-22 18:53:05 i have rebased my openssl3 branch from april 2022-07-22 18:53:12 had a zillion conflicts 2022-07-22 18:53:20 doing a rebuild now 2022-07-22 19:00:36 3 is looking slowly more promising in general, now that mariadb works 2022-07-22 19:01:24 rustls supports 3 too 2022-07-22 19:02:26 s/rustls/rust-openssl 2022-07-22 19:02:26 panekj meant to say: rust-openssl supports 3 too 2022-07-22 19:06:47 mariadb only works from next release, technically 2022-07-22 19:06:59 and anything rust only 'works' if they're not using the 5 year old crate 2022-07-22 19:07:05 (they're definitely using the 5 year old crate) 2022-07-22 19:17:05 oh right 2022-07-22 19:17:16 the rust thing is particularly painful bc some stuff has DEFINITELY made new releases but not updated the crate 2022-07-22 19:35:15 today in fun rust stuff- cargo-c generated libraries have no SONAME 2022-07-22 19:35:17 ??? 2022-07-22 19:36:00 And I'm wondering if rust is still making progress on rv64 2022-07-22 19:36:04 hm 2022-07-22 19:36:08 the arch one is correct 2022-07-22 19:36:12 ours isn't 2022-07-22 19:36:14 lets see.. 2022-07-22 19:37:02 I'll just be patient, at least one process is still 'doing' something 2022-07-22 19:37:13 the rust build is usually on one thread 2022-07-22 19:37:33 it's one per crate, and the largest/longest part of the compiler are the 30 crates in the middle 2022-07-22 19:37:42 yes 2022-07-22 19:38:02 but no thread / process is using any CPU atm 2022-07-22 19:38:05 before it was 2022-07-22 19:38:25 ah 2022-07-22 19:38:48 it's not so painful because most stuff did update dependencies, and rest will be easily patchable 2022-07-22 19:38:51 compiling rustc_interface 2022-07-22 19:42:51 psykose: not sure if it's related, but I see all these rustc_* crates having v0.0.0 as well, but that's maybe because it's sdlib? 2022-07-22 19:43:08 (in the build log) 2022-07-22 19:43:16 those are correct 2022-07-22 19:43:19 ok 2022-07-22 19:43:27 this cargo-c shit is broken on musl 2022-07-22 19:43:27 sigh 2022-07-22 19:43:54 without --library-type cdylib it defaults to static (doesn't on glibc), and it's always missing the SONAME for some reason 2022-07-22 19:44:19 https://github.com/lu-zero/cargo-c/issues/180 2022-07-22 19:44:20 nice meme 2022-07-22 19:44:36 >1 year old 2022-07-22 19:48:06 oh, fun, the old 'oh, musl, it must be static, right?' 2022-07-22 19:50:30 I feel like I'm watching paint dry, with the rust build atm 2022-07-22 19:51:39 yeah, linked the part of the code that does that 2022-07-22 19:51:48 in this case it's just a -type to fix so it doesn't matter too much 2022-07-22 19:51:51 https://github.com/lu-zero/cargo-c/issues/267 is the bigger issue 2022-07-22 19:52:51 why every time i get out of bed everything broken 2022-07-22 19:53:03 Because everythign is brokenb 2022-07-22 19:53:06 :) 2022-07-22 19:53:23 And I cannot type 2022-07-22 19:53:31 keyboard broke too, is ok 2022-07-22 19:57:46 there should perhaps really be a check for that 2022-07-22 19:57:59 a lint that checks if a .so.xyz file has an SONAME 2022-07-22 19:58:07 with a warning otherwise 2022-07-22 19:58:31 linting only does static checking 2022-07-22 19:58:42 more something like checkapk 2022-07-22 19:58:46 also the existing checkapk output isn't complete in CI because without `diffutils` it skips printing the sonames 2022-07-22 19:58:56 checkapk already prints soname with the real diff 2022-07-22 19:59:03 we just don't have the real diff 2022-07-22 19:59:20 psykose: oh, that's something new then 2022-07-22 19:59:22 it used to do that 2022-07-22 19:59:30 it does it if you `apk add diffutils` 2022-07-22 19:59:37 shall i perhaps find out why 2022-07-22 19:59:44 what project is this under anyway 2022-07-22 19:59:50 oh abuild 2022-07-22 19:59:52 nvm not fixing it 2022-07-22 20:11:39 can we have abuild but better 2022-07-22 20:29:31 it's fine i just wish there was any way of fixing anything in it that did not take 4 months of saying 'please look at this' 2022-07-22 20:29:40 even for the things that did, there hasn't been a release in 9 months to include them 2022-07-22 20:30:09 you don't have to tell me that (: 2022-07-22 20:35:05 I'm fearing for rust on rv64 2022-07-22 20:37:34 still stuck att rustc_interface 2022-07-22 20:43:40 it takes my decent cpu 10 minutes for some of those parts 2022-07-22 20:43:44 on rv it's probably 3 hours 2022-07-22 20:44:05 18x slower per thread.. maybe even more, so even more than that 2022-07-22 20:44:40 I just see a constant stream of FUTEX_WAIT + etimeout 2022-07-22 20:46:03 if there's really nothing else at all then i guess its fucked 2022-07-22 20:46:07 did you upgrade the host yet? 2022-07-22 20:46:26 yes 2022-07-22 20:46:29 mm 2022-07-22 20:47:15 maybe we should do some user vs system benchmarks? 2022-07-22 20:47:17 i wouldn't mind 2022-07-22 20:47:29 if it's not literally half the speed, i think it would work much better 2022-07-22 20:48:08 because then we also fix all the weird syscall stuff and whatever too 2022-07-22 20:48:17 only issue is that for system we need a kernel 2022-07-22 20:48:20 lts is not built for rv 2022-07-22 20:48:29 was there a reason for that? we can totally have an rv config 2022-07-22 20:48:33 multiple people have requested it 2022-07-22 20:48:37 No idea 2022-07-22 20:48:45 We do have one for the rv64 boards we received 2022-07-22 20:48:45 but -edge would also work fine, so eh 2022-07-22 20:48:55 but not in aports 2022-07-22 20:49:26 i guess i need to make an edge iso myself for rv and do some system benchmarks 2022-07-22 20:49:29 anything you want to see? 2022-07-22 20:49:45 I'd be curious 2022-07-22 20:49:50 hi; I noticed the extended x86_64 ISO doesn't boot on qemu (with -cdrom file.iso). 2022-07-22 20:49:52 i mean specific benchmarks 2022-07-22 20:50:12 ismael: let me check that real quick 2022-07-22 20:50:14 psykose: I suppose building something significant 2022-07-22 20:50:16 can you post the full cmdline 2022-07-22 20:50:24 ikke: i can do the usual compiler tests, but maybe there's something else 2022-07-22 20:50:33 Can't thing of anything else 2022-07-22 20:50:34 kcbench is pretty good for a build, though takes forever 2022-07-22 20:53:03 ismael: works for me with `qemu-system-x86_64 -m 2048 -enable-kvm -cdrom downloads/alpine-extended-3.16.1-x86_64.iso` and qemu-ui-gtk 2022-07-22 20:53:30 psykose: I was using qemu-system-x86_64 -enable-kvm -cdrom alpine-extended-3.16.1-x86_64.iso 2022-07-22 20:53:42 hmm, didn't seem like a too-little-ram error, but let me try 2022-07-22 20:54:05 fails without it for me 2022-07-22 20:54:15 ah, yes, it is 2022-07-22 20:54:24 is the initramfs that big? :( 2022-07-22 20:54:26 iirc by default the image goes into ram 2022-07-22 20:54:31 the extended is literally 1G so 2022-07-22 20:54:33 the whole thing? 2022-07-22 20:54:36 oh 2022-07-22 20:54:47 or well, 700 2022-07-22 20:54:48 hmm 2022-07-22 20:55:04 what is the default? 2022-07-22 20:55:06 -m 512 works 2022-07-22 20:55:24 I was just testing that 2022-07-22 20:55:27 -m 256 works 2022-07-22 20:55:32 I think the default is 128 2022-07-22 20:55:36 128 doesnt 2022-07-22 20:55:54 yeah, i guess extended just needs more ram for whatever is happening there 2022-07-22 20:55:54 no, it's only the initramfs. iirc it's just enough to successfully fail 2022-07-22 20:56:10 and indeed the initrd would be bigger 2022-07-22 20:56:16 hm, right. 2022-07-22 20:56:34 i found that with standard + virtio-vga + maximized window it would hang on black screen 2022-07-22 20:57:20 why is initramfs so bloated? :S 2022-07-22 20:57:44 "bloated" 2022-07-22 20:57:48 it has all of linux-firmware 2022-07-22 20:57:56 does it need all of it? 2022-07-22 20:57:57 so I can boot my fancy linux on weird hardware 2022-07-22 20:58:03 ismael: yes 2022-07-22 20:58:06 it's extended for a reason 2022-07-22 20:58:11 probably 99% of that is things that aren't needed for boot 2022-07-22 20:58:14 why are you using /extended/ in qemu? 2022-07-22 20:58:21 that is the part that makes no sense 2022-07-22 20:58:28 just testing it before runing in real metal 2022-07-22 20:58:42 ah 2022-07-22 20:59:03 well, real x86_64 metal has more than 128M of ram, so you'll be fine 2022-07-22 20:59:52 and if you care so much about "bloated" initramfs, don't use extended ISO 2022-07-22 20:59:55 if anything we need to add more things to extended, not less, the image is supposed to be special 2022-07-22 21:00:12 the main goal is to not need networking to function to get most of an install working 2022-07-22 21:00:33 so you can boot it on 'a router' (though funnily we have no extended for arm) and get stuff going without internet 2022-07-22 21:00:43 psykose: it worried me such a thing exists, but then again I was looking at some fedora initramfs not long ago and it was over 100MB :( 2022-07-22 21:00:58 (compressed) 2022-07-22 21:01:16 s/psykose/panekj/ 2022-07-22 21:01:16 ismael meant to say: panekj: it worried me such a thing exists, but then again I was looking at some fedora initramfs not long ago and it was over 100MB :( 2022-07-22 21:01:16 the generated initramfs after is not going to be very big 2022-07-22 21:01:40 the main issues with extended currently is it had some issues with actual wifi 2022-07-22 21:02:00 we should have all main installed in extended 2022-07-22 21:02:16 that would be like 30G 2022-07-22 21:02:30 nice joke panekj 2022-07-22 21:02:32 official alpine blurays distribution when? 2022-07-22 21:13:18 since when does initramfs have all firmwares 2022-07-22 21:13:29 the whole point of modloop is that it doesn't 2022-07-22 21:14:35 if everything was constantly loaded into ram then we could get rid of modloop and the persistent complaints about /lib/firmware operation not permitted 2022-07-22 21:17:58 i merely confused the two 2022-07-22 21:24:36 https://github.com/lu-zero/cargo-c/blob/f6d4984081eec30211af96c38d14844ce0fa222a/src/target.rs#L74-L81 2022-07-22 21:24:39 new hotness just dropped 2022-07-22 21:24:46 if you're on musl you don't have sonames on the platform right 2022-07-22 21:24:56 just not supported :( 2022-07-22 21:39:10 yaaay 2022-07-22 21:40:53 fixed https://github.com/lu-zero/cargo-c/pull/268 2022-07-22 21:48:19 ncopa: more precisely, the can of worms has been festering and accumulating tech debt for a decade and that’s why it needs to be broken :P 2022-07-22 21:48:25 I’ll try to answer everything tomorrow 2022-07-22 21:49:26 I’m very happy to provide the manpower to clean things up, I have like 20 years of tech janitorial experience 2022-07-22 21:49:54 but yeah we need to agree on what exactly should be done and I hope I’ll convince you :P 2022-07-23 04:05:39 psykose: it's actually 3.2GB with mesa-dbg, kyua-dbg and some other stuff 2022-07-23 04:06:02 what is 2022-07-23 04:06:16 ah, my buffer was scrolled up.. 2022-07-23 04:06:21 main edge 2022-07-23 04:17:03 though well, now i'm reading the list of packages in main and one of the largest ones is.. freeswitch-sounds-es-mx-maria-44100 ("Sounds for freeswitch Spanish") 2022-07-23 04:17:29 so i guess stuffing all of main onto a dvd is not the best idea after all 2022-07-23 05:04:09 rust is still stuck at rustc_interface, so I'd say it's stuck 2022-07-23 05:06:37 yup 2022-07-23 06:29:12 Good Morning. Can someone with access to the gitlab runnters please tpaste the error report from this build? https://gitlab.alpinelinux.org/bratkartoffel/aports/-/jobs/778329 - /builds/bratkartoffel/aports/community/openjdk11/src/jdk11u-jdk-11.0.16-ga/make/hs_err_pid63897.log 2022-07-23 06:30:24 Not sure that still exists, but I can try 2022-07-23 06:31:00 thanks ikke. don't know how to reproduce it on my machine and it looks like a stackoverflow thing 2022-07-23 06:33:19 I'll just try to build it in s390x 2022-07-23 06:43:20 bratkartoffel: is it only 3.16 that fails? I was applying it on edge now 2022-07-23 06:46:02 bratkartoffel: you mean https://img.ayaya.dev/6L2mG2JJxQpK ? 2022-07-23 06:46:21 strange it's s390x only 2022-07-23 06:46:37 __stack_chk_fail+0x2 breaking ssp_nonshared stuff 2022-07-23 06:46:43 that should be like an x86 issue 2022-07-23 06:46:48 maybe s390x is also special 2022-07-23 06:49:09 hmm, is there a reason we add 'musl' triples for clang, but only for arm/armv7/x86/x86_64 .. 2022-07-23 06:49:25 there is a ppc already there too, weird 2022-07-23 06:53:49 https://tpaste.us/wYme 2022-07-23 06:54:49 https://tpaste.us/JrPg 2022-07-23 06:54:52 bratkartoffel: ^ 2022-07-23 06:55:29 Size difference for qt6-qtbase-dbg: 773 MiB -> 113 MiB 2022-07-23 06:55:31 hehe 2022-07-23 06:55:37 nice 2022-07-23 06:56:25 Size difference for kwin-dbg: 400 MiB -> 48 MiB 2022-07-23 06:56:31 it is after all a serious reduction in debug info, but 2022-07-23 06:57:32 Yes, but I think that's acceptable for the intended usecase 2022-07-23 06:57:44 end-users being able to provide stacktraces 2022-07-23 06:59:34 yeah, just quite barren. granted, 90% of the time everything interesting is so 2022-07-23 06:59:46 nod 2022-07-23 06:59:58 but that has nothing to do with debug symbols, right? 2022-07-23 07:00:07 compiler optmizations 2022-07-23 07:00:15 never found a definitive answer 2022-07-23 07:00:44 You need to build everything with -O0 I guess? 2022-07-23 07:00:59 i've had half a stack trace be with -O0 -g3 -ggdb 2022-07-23 07:01:10 including libraries?> 2022-07-23 07:01:16 actual program 2022-07-23 07:01:16 dunno 2022-07-23 07:01:19 sometimes gdb just sucks 2022-07-23 07:01:44 i've also had gdb have like 2022-07-23 07:01:46 thing = value 2022-07-23 07:01:54 and in the code that thing is just passed between 3 places 2022-07-23 07:01:59 and in the 3rd one it's now 2022-07-23 07:02:03 heh 2022-07-23 07:02:04 but nothing even touches it 2022-07-23 07:02:31 it's both an impressive piece of software and a piece of shit at once, haha 2022-07-23 07:02:58 bratkartoffel: does that help? 2022-07-23 07:03:57 Hmm, seems like more and more stuff keeps getting stuck on rv64 2022-07-23 07:06:35 maybe the qemu update was bad 2022-07-23 07:06:37 but, also 2022-07-23 07:06:41 every time we do one of these uh 2022-07-23 07:06:44 huge go rebuilds 2022-07-23 07:06:47 there's quite a few go things that do 2022-07-23 07:06:49 nod 2022-07-23 07:06:55 flaky stucks, in a way 2022-07-23 07:07:10 yeah, rust now got stuck at a different point as before 2022-07-23 07:07:59 sigh 2022-07-23 07:08:06 i really should get the test image for system 2022-07-23 07:08:16 if it's only 20% or less (do you agree?) it would be worth a real shot 2022-07-23 07:08:44 if it prevents things getting stuck, I'd think it would be worth it rather quickly 2022-07-23 07:08:54 sure, let me bust out the mkimg 2022-07-23 07:09:03 i assume it just works with linux-edge instead, but maybe i'm wrong 2022-07-23 07:09:05 time for fun 2022-07-23 07:09:13 I'll probably obliterate the mirror on nld5 2022-07-23 07:09:19 good idea 2022-07-23 07:09:21 as it's not getting updated anyway 2022-07-23 07:09:27 also i had a question earlier in -infra about the dev.a.o server 2022-07-23 07:22:20 running mkimg for x86_64 works, for riscv64 it's edge/main mirror UNTRUSTED signature 2022-07-23 07:25:28 Not sure how it works exactly, but I suppose you need to add the rv64 key? 2022-07-23 07:25:51 ah 2022-07-23 07:25:56 sure, what do i add 2022-07-23 07:26:51 https://pkgs.alpinelinux.org/contents?branch=edge&name=alpine-keys&arch=x86_64&repo=main 2022-07-23 07:27:09 They're in /usr/share/apk/keys 2022-07-23 07:29:52 thanks! 2022-07-23 07:30:18 it go 2022-07-23 07:33:08 grub-mkimage: not found 2022-07-23 07:33:09 haha 2022-07-23 07:33:33 i think it runs it on the host 2022-07-23 07:33:36 need qemu-user 2022-07-23 07:35:17 new ffmpeg is out 2022-07-23 07:35:22 5.1, lts release 2022-07-23 07:36:14 nice 2022-07-23 07:36:16 will do that too then 2022-07-23 07:36:22 got the release notes 2022-07-23 07:36:26 * ? 2022-07-23 07:37:17 https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/5.1:/RELEASE_NOTES 2022-07-23 07:37:18 rather empty 2022-07-23 07:37:36 https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/5.1:/Changelog 2022-07-23 07:37:59 neat 2022-07-23 07:38:10 already the patch fails to reapply 2022-07-23 07:38:12 goooood start 2022-07-23 07:38:28 mm, no, grub-mkimage not found again 2022-07-23 07:39:19 oh, i literally don't have it 2022-07-23 07:39:23 silly me 2022-07-23 07:40:23 :D 2022-07-23 07:41:17 That's what you get when exec cannot find the interpreter gives the exact same error as the executable not being found 2022-07-23 07:42:19 tis a silly error indeed 2022-07-23 07:42:26 and then some people actually say it makes sense :) 2022-07-23 07:42:41 grub-mkimage: error: cannot open `/usr/lib/grub/riscv64-efi/moddep.lst': No such file or directory. 2022-07-23 07:42:48 now this i need to shim copy random shit for 2022-07-23 07:42:54 the lack of noarch sucks 2022-07-23 07:43:14 but thinking of it, how would it even be handled? making apk also check noarch as well as $arch of /etc/apk/repositories? 2022-07-23 07:43:30 That's the easy part 2022-07-23 07:44:04 What builder is responsible for noarch packages? 2022-07-23 07:48:07 hmm 2022-07-23 07:48:45 i would say 'any' and just taking latest uploaded, but also making a lot of packages not-noarch 2022-07-23 07:49:03 i don't think py3-* should be for instance 2022-07-23 07:49:04 or well, idk 2022-07-23 07:49:20 But you want things to be consistent, and the index needs to be signed 2022-07-23 07:49:27 right 2022-07-23 07:49:36 but to even do this, we have to split builder from mirror, right 2022-07-23 07:49:46 and at that point the sign gets reworked and comes from elsewhere 2022-07-23 07:49:55 it's 'separate' from this issue slightly 2022-07-23 07:49:59 yes 2022-07-23 07:50:56 the ffmpeg release has no soname change it seems 2022-07-23 07:51:10 nice 2022-07-23 07:52:08 chromium still starts and works 2022-07-23 07:52:13 and that had an entire patch in ffmpeg for 2022-07-23 07:52:14 neat 2022-07-23 07:52:49 /sbin/update-kernel: line 303: install: not found 2022-07-23 07:52:50 lol 2022-07-23 07:53:33 i do have qemu-user running.. 2022-07-23 08:07:44 still not sure why that happens 2022-07-23 08:20:22 ah, it's actually misassuming some stuff and missing files 2022-07-23 08:21:02 commented out random stuff 2022-07-23 08:23:33 mm, only opens the qemu monitor.. 2022-07-23 08:30:58 ah, cause it's secretly just at 100% cpu in the background 2022-07-23 08:31:05 not sure it's working, heh 2022-07-23 09:16:05 rv64 is making progress atm 2022-07-23 10:38:12 god i hate stack sizes 2022-07-23 10:45:53 s390x uses more stack than the other arches, so it will run out of stack space earlier when there are recursive calls etc 2022-07-23 10:46:28 it is also big-endian. could be buffer overflow that only affects big-endian? 2022-07-23 10:49:29 ncopa: I had to kill rust again :( 2022-07-23 10:49:47 had it running all night, but no progress 2022-07-23 10:51:56 what could a reason be that a thread has default stack size even with -z stack-size and not setting it in the program? 2022-07-23 13:35:01 /m @oftc-irc:matrix.org 2022-07-23 15:28:05 fwiw I recently published the Rust bindings for apk-tools to crates.io: https://crates.io/crates/apk-tools-sys 2022-07-23 15:28:08 It now just links against the shared version of libapk 2022-07-23 15:28:38 It’s pretty lowlevel currently, maybe I’ll add higher level safe APIs once apk-tools v3 happens 2022-07-23 15:47:36 How do I replace _ with . in a concise way in ash? 2022-07-23 15:48:47 ${var/_/.} ? 2022-07-23 15:51:09 looks good, thanks! 2022-07-23 15:53:33 Newbyte: fwiw the portable way is tr(1), but seems alpine ash has extra features :) 2022-07-23 15:54:25 thanks! in this case, I think it's fine to not be portable given that I'm writing an APKBUILD 2022-07-23 15:55:35 agreed, just putting the info out there in case its helpful in the future 2022-07-23 16:17:18 what's the preferred way to deal with a library that has a pkg-config version that pkgconf doesn't like? 2022-07-23 16:17:26 patch the thing that makes it or sed 2022-07-23 16:17:30 former is easiest 2022-07-23 16:17:45 or generate it yourself; 95% of pkgconfs is a .pc.in with a single @VERSION@ in it 2022-07-23 16:18:03 sed 's|@VERSION@..' .pc.in > "$pkgdir"/ .. 2022-07-23 16:34:38 I wonder if pkgconf could be patched to deal with e.g. 43.alpha and 43.beta versions instead 2022-07-23 16:44:13 nobody has defined the pkg-config version spec 2022-07-23 16:45:32 so understandably it sucks, the pkgconf implementation is probably gentoo-style or a bit less 2022-07-23 16:45:58 and pkg-config probably copypastes the rpm code which can have rand() output in the version i guess 2022-07-24 07:19:23 i recently added a qa check for a bunch of .pc stuff 2022-07-24 07:19:27 the amount of junk 2022-07-24 07:20:00 idk if it's still planned but https://lists.sr.ht/~kaniini/pkgconf/%3CCAAOiGNwYCx%3DDVmFRczCAW2HyGNTo2so-oj9%3DeSnTAaU%3D_o0f7Q%40mail.gmail.com%3E will be beautiful if it happens 2022-07-24 07:20:07 these cheesy things hardcoding prefixes 2022-07-24 07:20:11 wrong libdir is really common 2022-07-24 07:20:29 experimentally i've tried to compare pkg-config version with package version but it's too noisy I think 2022-07-24 16:36:06 rust hangs again, same point: rustc_interface 😔 2022-07-24 17:29:09 I'll let it continue 2022-07-24 19:10:33 ncopa: you backported the lld/llvm-libunwind support for s390x but it doesn't actually work if you try it 2022-07-24 19:10:40 ld.lld: error: unknown emulation: elf64_s390 2022-07-24 19:10:40 ld.lld: error: src/gn/gn_main.o: could not infer e_machine from bitcode target triple s390x-alpine-linux-musl 2022-07-24 19:26:13 and of course it fails hundreds of its unit tests 2022-07-24 19:26:15 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/779930 2022-07-24 19:26:18 all the other arches pass fine 2022-07-24 20:21:40 what's funny is even riscv64 passes all the tests 2022-07-25 04:22:12 rv64 looks dire 2022-07-25 06:40:47 good morning 2022-07-25 06:49:40 rv64 has run rust all weekend, right? 2022-07-25 06:50:01 and no progress? its stuck at Compiling rustc_interface v0.0.0..? 2022-07-25 06:51:25 let me try kill stuff 2022-07-25 06:54:04 I restarted it yesterday morning 2022-07-25 06:56:35 Then it was stuck in a zombie state 2022-07-25 06:57:03 But now and before it hangs at rustc_interface 2022-07-25 07:10:11 oh sorry... i killed it 2022-07-25 07:10:14 re-running now 2022-07-25 07:10:22 catching up on other stuff first 2022-07-25 07:10:52 when i built it in my dev env, it appeared to be stuck multiple times 2022-07-25 07:11:01 but it did progress, slowly 2022-07-25 07:11:14 it took 5-6 hours in total to build it 2022-07-25 07:17:44 ok her we go again 2022-07-25 09:54:44 ikke: sorry to bother you again. Any chance you can recheck the appstream MRs pending on infra? 2022-07-25 10:14:51 pabloyoyoista: oh, yes, I promised to look at that, sorry 2022-07-25 10:32:59 working on openssl3 upgrade now. community/fractal does not work. I might disable it til they have made a new release upstream 2022-07-25 10:36:33 hi, could someone take a look at https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/merge_requests/50? thanks! 2022-07-25 10:53:15 LGTM 2022-07-25 10:55:23 mergedf 2022-07-25 10:55:47 thanks again :) 2022-07-25 12:15:50 Thanks a lot ikke :) 2022-07-25 12:20:36 \o/ 2022-07-25 12:20:37 >>> rust: Updating the community/riscv64 repository index... 2022-07-25 12:20:37 >>> rust: Signing the index... 2022-07-25 12:29:03 Wow 2022-07-25 12:29:11 It happened! 2022-07-25 13:29:02 :> 2022-07-25 13:31:57 until the next release :P 2022-07-25 13:35:45 it was interesting that the only thing that I needed to do to make it pass was to watch the build log while it was building... :) 2022-07-25 13:36:19 I watched all weekend 😢 2022-07-25 13:37:28 you are not scary enough :) 2022-07-25 13:39:15 😑 2022-07-25 13:46:33 ncopa: I have a pending MR for alpine-conf, I know the tests are broken, been trying to figure it out (kyua is simple, they said...) and fix it but I need to go out. Will finish it asap and fix the MR. 2022-07-25 13:57:53 how to properly `abuild rootbld` ? `cd testing/mypackage && abuild rootbld` seems to craft the path wrong, as it complains about missing aports/testing/mypackage/testing/.rootbld-repositories 2022-07-25 13:58:12 did you clone the repo or create your own 2022-07-25 13:58:25 cloned aports, made a new package 2022-07-25 13:58:57 abuild rootbld should work 2022-07-25 14:03:12 repo_template ends up wrong? https://0x0.st/ojpN.txt 2022-07-25 14:03:59 👍 2022-07-25 14:04:18 setting APORTSDIR manually would fix it 2022-07-25 14:04:31 but aportsgit=${APORTSDIR:-${startdir}} is probably not right 2022-07-25 14:04:47 if it's intended to point to repo root 2022-07-25 14:13:02 am i holding it wrong? 2022-07-25 18:09:55 Piraty: can you show `git remote get-url origin`? looks like it's another case of https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10069 2022-07-25 20:32:36 bb is stuck again on 3.16 2022-07-25 20:32:53 I suppose we need to backport that fix from nmeum? 2022-07-25 20:33:45 but.. 2022-07-25 20:35:08 yes, it would make sense to backport it 2022-07-25 21:07:12 pabloyoyoista: I've deployed the latest changes, and removed the DB dir 2022-07-25 21:13:17 pabloyoyoista: one feature request. Would it be possible to start using https://alpinelinux.org/releases.json to find out what releases to generate? 2022-07-25 21:26:54 ikke: thanks a lot! 2022-07-25 21:27:38 I had no idea about that json. It should certainly be possible to regenerate the config on-the-fly every certain time 2022-07-25 21:29:34 And there is an "eol_date", which could be used to filter for non-supported versions 2022-07-25 21:30:10 You could open an issue and assign it to me so I don't forget, could look into it 2022-07-25 21:30:57 I already opened the issue :) 2022-07-25 21:31:02 I'll assign it 2022-07-25 21:43:03 Perfect, thank you! 2022-07-25 23:42:16 Any idea why clang -dbg package size nearly twice smaller? !36819 2022-07-25 23:43:41 magic 2022-07-25 23:43:49 don't think the info in there would be different 2022-07-25 23:44:10 maybe it using compressin out of box 2022-07-25 23:44:46 nope 2022-07-25 23:44:48 not without -gz 2022-07-25 23:47:24 you can compare locally if that was the case; double compression would end up about the same on the .apk 2022-07-25 23:47:43 the size diff in checkapk is the installed 'uncompressed' files, but the local .apk would be the same if it was compressed inside 2022-07-25 23:47:44 (more or less) 2022-07-25 23:48:06 it's just better, dunno 2022-07-25 23:48:16 tons of stuff just becomes 20% smaller with clang for no reason 2022-07-25 23:48:22 or sometimes bigger :) 2022-07-25 23:48:45 if you care about size of debug and don't care about more than getting a backtrace, pass `-g1` in the flags 2022-07-25 23:49:09 the default -g is `-g2`, 1 is anywhere from 50-90% smaller (but loses all the non-bt info) 2022-07-25 23:49:31 and default -dbg adds `-g` 2022-07-25 23:49:41 project might be overriding it anyway, but good to know 2022-07-25 23:50:32 it makes sense to apply to php8 and php81 as both are stable enough 2022-07-26 05:13:22 for whoever here uses chromium, i would appreciate it if you would test the latest artifacts from !36785 2022-07-26 05:29:11 installed it 2022-07-26 05:31:57 seems to work fine 2022-07-26 05:32:06 at least, initial tests 2022-07-26 05:32:29 yea 2022-07-26 05:32:32 which is pretty good 2022-07-26 05:32:40 aside from that seemed faster than usual, but i'm always biased 2022-07-26 05:34:21 memory footprint also looks a lot better with partition malloc at a glance 2022-07-26 05:34:30 (which is the main change i guess, as sketchy as it is) 2022-07-26 05:43:30 now that a small bug in alpine/go is fixed.. following today's awkward situation with another circular dependency, i made a simple tool to find them: https://gitlab.alpinelinux.org/ptrcnull/apkcircledep 2022-07-26 05:44:17 nice 2022-07-26 05:44:19 it's probably not perfect around some edge cases, but seems to find the obvious ones that block the builders 2022-07-26 05:45:56 also, wow, the go apkbuild parser is really nice :) 2022-07-26 05:46:04 thanks 2022-07-26 05:46:40 'another' 2022-07-26 05:46:42 there was like three 2022-07-26 05:46:46 at once. 2022-07-26 05:46:54 :D 2022-07-26 05:47:11 '>.> 2022-07-26 05:47:23 It would get meta once we have a circular dependency on circular dependency checkers 2022-07-26 05:47:49 ptrc: rewrite it in python so we can make it happen 2022-07-26 05:48:38 hey, the python one i made before is working too :p it's just really slow, because for every package it resorts to `. APKBUILD; echo $depends $makedepends` 2022-07-26 05:51:02 high quality ;/ 2022-07-26 05:51:10 speed was one of the reasons I made this, mdvdan.cc/sh being available another major contributor 2022-07-26 09:35:09 ptrc: the (only) git-remote isn't called 'origin' but 'upstream' 2022-07-26 09:35:25 foolish to assume everyone names it origin 2022-07-26 09:35:45 as usually, origin is *my* gitlab/github fork 2022-07-26 09:35:59 what is the context 2022-07-26 09:36:11 abuild rootbld not working because not found .rootbld-repositories 2022-07-26 09:36:15 ah 2022-07-26 09:36:18 because it didn't derive path properly 2022-07-26 09:47:38 Piraty: I don't have any remote called origin, but rootbld works for me 2022-07-26 09:48:44 it also checks if it's ~/aports 2022-07-26 09:48:46 ikke: is your aports repo at "$HOME/aports" by any chance? :p 2022-07-26 09:48:56 or APORTSDIR 2022-07-26 09:48:57 etc 2022-07-26 09:49:42 ptrc: yes 2022-07-26 09:49:59 lucked into the one hardcoded configuration then 2022-07-26 09:50:10 abolish abuild 2022-07-26 09:50:16 Like it ought to 2022-07-26 09:50:22 :-P 2022-07-26 09:52:24 ~/aports is akin to ~/.randomapplication 2022-07-26 09:52:29 nuked from orbit 2022-07-26 10:07:15 i'm surprised by the low amount of doc around abuild and the amount of hardcoded assumptions. do people usually maintain+use their wrappers or something? i guess i will 2022-07-26 10:08:06 for this you would want to.. hardcode APORTSDIR= in env to the path 2022-07-26 10:08:07 i guess 2022-07-26 10:08:10 aside from that, yea 2022-07-26 10:08:24 i have like 3 patches i manually go type into abuild every time i reinstall it by accident 2022-07-26 10:09:17 I'm rewriting abuild in different language so, I guess that counts as wrapper? 2022-07-26 10:36:00 uhM, panekj: it's your rewrite considering rootbld? I'm thinking since some time ago that rootbld will be better a different script/binary than abuild itself 2022-07-26 10:36:07 what language is? 2022-07-26 10:36:38 I'm rewriting whole abuild 2022-07-26 10:36:56 so with rootbld too 2022-07-26 10:37:51 it doesn't make sense to have it as a 'separate' thing, since most of the actual build is the same logic 2022-07-26 10:38:00 (separate files for things aside, of course) 2022-07-26 10:41:33 in my little experience trying to improve rootbld, I felt it pretty confusing, it also produces some kind of recursive dependency, I had to manual overwrite the sandboxed abuild in the middle of rootbld execution.. I think that it would be more simple if abuild and rootbld are different things 2022-07-26 10:47:50 I think it would be even more confusing 2022-07-26 10:47:56 psykose: the "same logic" it's just rootbld calling abuild 2022-07-26 10:48:09 that's what i mean 2022-07-26 10:48:15 the rootbld should only handle, bwrap, apk --init, etc... 2022-07-26 10:48:19 yeah 2022-07-26 10:49:11 and that's all it does 2022-07-26 10:49:25 it's not written super well, so it's confusing that there is a rootbld_actions() that does the same thing 2022-07-26 10:49:38 well, in a pretty unflexible way 2022-07-26 10:49:53 I had a local version without rootbld_actions() 2022-07-26 10:49:59 but that's because of the implicit default 'list of actions' when it's only `abuild`, and now it has to do the same for an argument 2022-07-26 10:50:08 it just passes the args of: abuild rootbld args.. 2022-07-26 10:50:12 to the abuild inside the container 2022-07-26 10:50:35 I wanted to replicate the exact behaviour of a plain abuild inside the sandbox 2022-07-26 10:51:15 but I needs a change on the mounpoints scheme so it can remove pkg/ src/ on cleanup 2022-07-26 10:51:21 it's an annoying problem and every time i think about it it just becomes irritating and i give up 2022-07-26 10:52:16 I can try to fix this version without the hardocded list 2022-07-26 10:52:27 but I don't know what to do with the mounpoints 2022-07-26 10:53:32 uhmm, I have to take a look 2022-07-26 10:53:45 but anyway, will be abuild replaced with another language? 2022-07-26 10:54:06 probably not anytime soon 2022-07-26 10:54:33 I need some months for a 2 lines merge 2022-07-26 10:54:39 needed* 2022-07-26 10:54:43 :) 2022-07-26 10:55:16 that's what i mean, it's frustrating to try and actually fix anything in it 2022-07-26 10:56:44 having a different code for just rootbld 2022-07-26 10:56:48 could help on it 2022-07-26 10:57:07 breaking something on rootbld couldn't not affect to abuild 2022-07-26 10:57:29 so rootbld could be improved fast and easily 2022-07-26 10:57:33 it's not about that; the issue is that making the changes feels pointless if they're not actually used 2022-07-26 10:57:43 sure, i can go write my own rootbld and come up with something workable 2022-07-26 10:58:05 and it will be used by.. me only, and not have parity with actual abuild, and so it's useless because perhaps they become out of sync to what the infra builders are actually doing 2022-07-26 10:58:26 it's fine for a 'personal project', but to be usable in the actual thing 'i' am working on (alpine), it has to be upstreamed 2022-07-26 10:58:35 and nothing gets upstreamed into abuild, so it's pointless to spend time on it 2022-07-26 10:58:38 uhM 2022-07-26 10:59:10 well I would maintain rootbld as part of abuild project 2022-07-26 10:59:12 in same repository 2022-07-26 10:59:24 it's not so much about the changes; i'm a terrible programmer and probably can't get anything changed anyway, but just the feeling that it's a waste of time to even try 2022-07-26 10:59:49 I started thinking on this when I saw the problem with python tests 2022-07-26 11:00:06 at least with python tests it's aports and i can just merge all the changes if i think they're good 2022-07-26 11:00:10 and the problem with community dependency for tests on main packages 2022-07-26 11:00:22 that one does not have a fix with the current infra 2022-07-26 11:00:28 unrelated to abuild 2022-07-26 11:01:23 current rootbld seems a limitation for having the possiblity of use community packages for test main packages 2022-07-26 11:01:35 probably is not the only one 2022-07-26 11:01:41 but I felt that i could be fixed 2022-07-26 11:03:57 s/i/it 2022-07-26 11:03:57 donoban meant to say: but I felt that it could be fixed 2022-07-26 11:04:55 fixing it would be useless for aports 2022-07-26 11:04:55 > but anyway, will be abuild replaced with another language? 2022-07-26 11:04:59 is there a need for that? 2022-07-26 11:05:16 it's actually a feature that it doesn't work, because it would not work on the builders either 2022-07-26 11:05:31 it's not an abuild issue that community/ things cannot be used in main/ 2022-07-26 11:05:59 it's by 'design', hacking rootbld to behave like vanilla abuild (without root) to work anyway isn't correct 2022-07-26 11:06:11 > current rootbld seems a limitation for having the possiblity of use community packages for test main packages 2022-07-26 11:06:22 correct behaviour, community should not leak into main 2022-07-26 11:06:43 indeed 2022-07-26 11:07:03 now, one could say 'okay it shouldnt leak at runtime but for tests we can make some exceptions' 2022-07-26 11:07:05 wasn't it also broken the other way though? 2022-07-26 11:07:06 and sure, that makes sense 2022-07-26 11:07:12 if something needs to depend on package from community, that package should be moved to main and properly supported 2022-07-26 11:07:19 well that design decision "leaks" a lot of packages into main for be able to run tests 2022-07-26 11:07:23 but it needs a redesign of the whole thing 2022-07-26 11:07:24 as in, you can't use locally built main/ packages when rootblding something from community 2022-07-26 11:07:35 that's a separate issue 2022-07-26 11:07:52 build and test are different things 2022-07-26 11:08:10 I understand that the current situation is to avoid too much complexity 2022-07-26 11:08:12 donoban: but that at least forces them to be supported for entirety of alpine version lifetime 2022-07-26 11:08:20 i don't agree that they are different things 2022-07-26 11:08:26 That's not limited to rootbld 2022-07-26 11:08:28 build and test are same things 2022-07-26 11:08:35 Ooh n/m 2022-07-26 11:08:47 well, the same the same.. 2022-07-26 11:08:55 Responding to an older message 2022-07-26 11:09:40 But you also need to think about bootstrapping 2022-07-26 11:10:02 does bootstrapping run some tests? 2022-07-26 11:11:03 It runs all the tests if they are enabled 2022-07-26 11:11:41 i don't remember bootstrap.sh running any tests 2022-07-26 11:11:55 but we have two kinds of bootstrapping, and the other one does 2022-07-26 11:12:29 well, I accept that main test dependencies should be on main too... 2022-07-26 11:12:53 for the most part most of the tests are not useful anyway 2022-07-26 11:13:02 but won't be rootbld better separated of abuild code? 2022-07-26 11:13:04 especially in python land 2022-07-26 11:13:23 separated in what sense? 'rootbld' just creates the root environment, and the rest is abuild functions 2022-07-26 11:14:29 yes, just do that outside abuild code 2022-07-26 11:14:47 and what would the benefit be 2022-07-26 11:15:17 it's the same thing.. in another file, used the same way, with the same dependencies, the same usage, the same code path, the same .. 2022-07-26 11:15:41 just instead of being at line 2000 in rootbld() it would be in a file 2022-07-26 11:15:42 cleanear abuild code, possiblity to modify or add features to rootbld 2022-07-26 11:16:16 there are few lines because the current rootbld freatures is very limited 2022-07-26 11:16:19 it's.. exactly the same though? 2022-07-26 11:16:19 you can add features to rootbld 2022-07-26 11:16:22 it even hardcodes the args pased to abuild 2022-07-26 11:16:32 and that has nothing to do with it being inside abuild 2022-07-26 11:16:40 I don't see why you won't be able to do certain things just because it's in abuild file??? 2022-07-26 11:16:51 being in the same file is not the limitation of any of thise 2022-07-26 11:17:04 the reason all of that is true is because it was made that way 2022-07-26 11:17:12 not 'whoops, its in the same file, guess it has to be that way' 2022-07-26 11:17:47 well, when you try to modify rootbld currently 2022-07-26 11:17:53 you are also affecting abuild 2022-07-26 11:18:06 no? 2022-07-26 11:18:16 and the sandboxed abuild will be different 2022-07-26 11:18:38 yes, but that's identical to doing it out of file 2022-07-26 11:18:40 it's not very difficult to "fix" 2022-07-26 11:18:42 no 2022-07-26 11:18:51 because if it's different and abuild is small/simple/etc.. 2022-07-26 11:18:55 you will modify the rootbld code 2022-07-26 11:19:00 and abuild will be unaffected 2022-07-26 11:19:09 abuild itself is unaffected though 2022-07-26 11:19:26 if you modify rootbld code, the only thing that changes is how abuild is called 2022-07-26 11:19:41 am i in one of those dreams where you try and like run but cant run fast enough and everything feels weird 2022-07-26 11:19:42 for some things it was affected 2022-07-26 11:19:45 and that's the same regardless if it's part of the same file or not 2022-07-26 11:20:14 I don't remember exactly but I had to overwrite the abuild after creating the chroot 2022-07-26 11:20:32 anyway I also see like just a better design 2022-07-26 11:20:42 thing of having a different sandbox solution 2022-07-26 11:20:52 instead running bwrap, use docker, qemu... 2022-07-26 11:21:14 ...qemu? 2022-07-26 11:21:33 do you want to spin up a whole another vm just to build one package 2022-07-26 11:21:34 qemu would be nice 2022-07-26 11:21:51 hehe 2022-07-26 11:21:52 ptrc: why not? 2022-07-26 11:22:14 seems like a massive waste of resources over little to no benefit 2022-07-26 11:22:16 security paranoid like that 2022-07-26 11:22:31 I see big benefit 2022-07-26 11:22:48 vms are for losers 2022-07-26 11:23:00 baremetal! 2022-07-26 11:39:32 *cough*tainers 2022-07-26 11:40:01 I'll implement microVMs in abuild 2022-07-26 11:50:56 donoban: bwrap is the best shot we got, next best shot would be containers and podman. screw docker. qemu only for "native crossbuids" if the performance penalty is worth saving the cross build troubles 2022-07-26 11:51:00 better do it apart ;) 2022-07-26 11:52:08 yeah I understand, I just feel that having it separated would give it a lot of flexiblity, probably not needed at this moment 2022-07-26 11:52:25 take a look at what xbps-src does in that regard if you want some inspiration 2022-07-26 11:52:29 what flexibility and where 2022-07-26 11:53:10 do whatever you want wherever :P 2022-07-26 11:53:28 so just like right now 2022-07-26 11:54:32 Piraty: what's this? I don't have experience with void-linux 2022-07-26 11:54:42 it's like the equivalent abuild? 2022-07-26 11:54:54 xbps-src builds packages from source 2022-07-26 11:55:38 it's not exact equivalent, it's more like apt-src 2022-07-26 11:55:49 xbps-src is the build tool bundled with the void-packages repo, yes it builds packages from source 2022-07-26 11:56:23 ok 2022-07-26 11:56:45 i understand that abuild, in addition to build packages from source, wraps some common maintenance stuff as well? 2022-07-26 11:58:31 uhm, what kind of 'common maintenance'? 2022-07-26 12:07:41 Piraty: it builds stuff and it makes index 2022-07-26 12:07:59 same does xbps-src 2022-07-26 12:08:29 or to be exact, it tells `apk` to make index 2022-07-26 12:09:02 so does xbps-src, telling xbps to make index ;) and calling xbps-* for the various package related stuffz 2022-07-26 12:10:12 anyway, https://github.com/void-linux/void-packages/#chroot-methods for what you talked about 2022-07-26 12:15:05 so the chroot implementations are outside xbps-src itself? 2022-07-26 12:20:27 this is interesting https://github.com/void-linux/void-packages/tree/master/common/chroot-style 2022-07-26 12:26:53 xbps-src is a big wrapper over ./common, and just like `abuild rootbld` it calls out to bwrap etc, so i don't know what you mean by 'outside' 2022-07-26 12:29:04 I just mean a different file 2022-07-26 12:29:35 I cloned it for take a look 2022-07-26 12:32:41 uhM 2022-07-26 12:33:09 uchroot.sh calls to exec xbps-uchroot..., but where is xbps-uchroot? 2022-07-26 12:35:13 ah, its https://github.com/void-linux/xbps/tree/master/bin/xbps-uchroot 2022-07-26 12:35:36 so yes, it's 'outside' :P 2022-07-26 12:37:22 I think that would be interesting to know what kind of sandbox/technologies are useful to have "integrated" into abuild 2022-07-26 12:37:54 for only have bwrap probably is better to just leave this way and fix the hard coded rootbld_actions() 2022-07-26 12:38:01 none 2022-07-26 12:38:15 better, abandon trying to modify abuild, build something better 2022-07-26 12:38:16 thats an option too 2022-07-26 12:38:18 null 2022-07-26 12:38:52 but panekj , what exactly do you think that writer another is better? 2022-07-26 12:39:08 I don't understand the question 2022-07-26 12:39:11 and anyway, the first question still relevant 2022-07-26 12:39:29 sorry, I mean that whats the problem with the current abuild 2022-07-26 12:39:38 that you think that will be fixed with a reimplementation 2022-07-26 12:40:01 it's broken, terribly, and it's a shell script, and upstream is barely doing anything in regards to that or contributions 2022-07-26 12:41:50 well, it's a critical piece, it needs careful review for changes 2022-07-26 12:42:13 but I don't feel it's broken 2022-07-26 12:42:22 there is this problem that it's used on Alpine builders, so no one wants to touch in case it breaks, but also, builders have their own locally modified version of abuild, but also, devs decide upon various behaviour in aports that wasn't implemented in abuild (because it waits for merge) 2022-07-26 12:42:56 I feel it's very broken 2022-07-26 12:42:57 uhm, like net option? 2022-07-26 12:43:01 no 2022-07-26 12:44:51 I got to go, see you guys 2022-07-26 12:48:53 How do I do it for a pipeline in gitlab not to build a package? 2022-07-26 12:49:05 Like, it's building it even if neither the pkgver or pkgrel are increased 2022-07-26 12:50:52 ncopa: you merged 663699e90bfc03a5aa8db9368577828ae45aea03 yesterday which broke every single python .so on 3.15 because the soabi patch was removed 2022-07-26 12:51:18 so python3 cannot load -musl.so anymore, which is all of them 2022-07-26 12:55:01 psykose: ouch! 2022-07-26 12:55:08 i'll fix it 2022-07-26 12:55:09 i will rebuild them all, don't worry 2022-07-26 12:55:11 already done with main 2022-07-26 12:55:30 discovered via #14056 already, haha 2022-07-26 12:56:05 also i figured out the clang ssp_nonshared patch, you had it right first try 2022-07-26 12:56:40 psykose: do you need me to do anything with python? 2022-07-26 12:56:44 nah, i got it 2022-07-26 12:57:07 we are reverting it? 2022-07-26 12:57:25 we cannot rebuild eerything 2022-07-26 12:57:29 i'd rather rebuilds because that is more clean and makes the pip musl wheels usable 2022-07-26 12:57:30 sure we can 2022-07-26 12:57:33 it's just a pkgrel bump 2022-07-26 12:57:40 we need be ABI compat 2022-07-26 12:57:45 with what 2022-07-26 12:58:05 peoples preiously built modules 2022-07-26 12:58:10 ah 2022-07-26 12:58:14 yes, in that case.. 2022-07-26 12:58:28 ok, then you have to put the patch back 2022-07-26 12:58:33 and i have to rebuild cffi one more time 2022-07-26 12:58:38 sure, works 2022-07-26 12:59:22 i removed it because i thought it was applied upsteram 2022-07-26 13:00:09 even if it was it would break the abi because of the naming 2022-07-26 13:00:26 but eh, i guess all the python modules will just be -gnu forever, haha 2022-07-26 13:06:45 i think i removed the -gnu, but we cannot do it within a stable branch 2022-07-26 13:09:14 edge is currently -gnu, and unless the upstream default python changes it (or supported configure flag) we shouldn't touch it 2022-07-26 13:09:26 and yeah, not in stable 2022-07-26 13:09:43 if they do change it at all it won't be before 3.11 which is after 3.17 2022-07-26 13:17:18 seems like one of the tests fails? 2022-07-26 13:17:23 in py3-cffi 2022-07-26 13:25:35 starting to rethink my plans of updating sr.ht boxen less frequently 2022-07-26 13:26:58 this shouldnt have happened. and it will not happen again. 2022-07-26 13:27:10 the py3-psycopg2 issue also 2022-07-26 13:27:25 the fact that community is unmaintained in old stable releases escaped my notice 2022-07-26 13:27:28 and probably rules it out 2022-07-26 13:32:37 ncopa: they are also skipped for that reason 2022-07-26 13:32:43 fwiw none of them actually fail on edge iirc 2022-07-26 13:32:57 skipped with || true * 2022-07-26 13:34:00 ncopa: we should really fix #14058 soon 2022-07-26 14:13:59 yeah, we should have a look at that 2022-07-26 14:29:57 panekj: yes, abuild is broken, but so is very package builder under the sun that is not designed from scratch to build stuff in isolated VM or at least containers. and that is very difficult, and there have been several attempts at this on Alpine (I’m thinking e.g. of buildlab) but I don’t know what came from it. 2022-07-26 14:30:31 even if it’s broken just like everyone else, a nice property of abuild is that it can be worked with 2022-07-26 14:30:40 s/everyone else/everything else/ 2022-07-26 14:30:40 skarnet meant to say: even if it’s broken just like everything else, a nice property of abuild is that it can be worked with 2022-07-26 14:30:58 s/very package builder/every package builder/ 2022-07-26 14:30:59 skarnet meant to say: panekj: yes, abuild is broken, but so is every package builder under the sun that is not designed from scratch to build stuff in isolated VM or at least containers. and that is very difficult, and there have been several attempts at this on Alpine (I’m thinking e.g. of buildlab) but I don’t know what came from it. 2022-07-26 14:31:21 nice, alpine-meetbot has a memory of more than one line per user \o/ 2022-07-26 14:31:47 but I already know that 2022-07-26 14:32:20 then you also know that complaining about the brokenness of abuild is useless because we don’t have anything better 2022-07-26 14:32:31 I'm complaining so it gets fixed 2022-07-26 14:32:51 just like you kept complaining to ncopa about stuff you wanted to get fixed/merged 2022-07-26 14:32:52 a non-broken package builder is a Holy Grail 2022-07-26 14:33:09 uh, not just like me, no 2022-07-26 14:33:22 and my complaining at some point worked, to some extent 2022-07-26 14:33:24 I spam devs to merge shit *I have worked on* 2022-07-26 14:33:38 very true 2022-07-26 14:33:38 you spam devs to fix shit without putting any effort yourself 2022-07-26 14:33:41 we are not the same 2022-07-26 14:33:46 look at you 2022-07-26 14:33:49 trying to start shit again 2022-07-26 14:33:51 i mean 2022-07-26 14:34:00 panekj had put in plenty of effort 2022-07-26 14:34:08 (for 0 response) 2022-07-26 14:34:10 and then gave up 2022-07-26 14:34:12 same as me 2022-07-26 14:34:21 it's not like there was 0 effort and just complaining 2022-07-26 14:34:22 into fixing abuild? 2022-07-26 14:34:30 at least a start into something, yes 2022-07-26 14:34:36 my bad then, I stand corrected 2022-07-26 14:34:37 I want to get abuild fixed properly, but I do not have mental capability for that now 2022-07-26 14:34:45 core changes? no 2022-07-26 14:34:55 but when you contribute a 2 line diff and it sits there for 6 months.. 2022-07-26 14:35:17 in that case yes, we are the same 2022-07-26 14:35:27 I have few changes that are opened, few that are left alone on my local PC 2022-07-26 14:35:42 it's just that trying to get something *into* abuild is painful 2022-07-26 14:35:47 as psykose said, left for months 2022-07-26 14:35:59 thus my complaining 2022-07-26 14:36:18 i wouldn't even care if they were all rejected 2022-07-26 14:36:31 but I also skimmed through abuild many times and I have acquired a dislike for it 2022-07-26 14:36:35 better than pending infinity 2022-07-26 14:36:58 honestly at this point it’s a lack of manpower, because I can totally understand the reluctance to modify something as core as abuild 2022-07-26 14:37:11 but yes there should be someone reviewing proposed changes 2022-07-26 14:37:19 schrodinger's MRs, when you don't look at gitlab, your MRs are both merged and not merged 2022-07-26 14:37:25 well yes, but it's self inflicted 2022-07-26 14:37:35 only one person can maintain and do anything to abuild 2022-07-26 14:38:05 a small bus factor is both a blessing and a curse 2022-07-26 14:38:28 it's a blessing when the bus is in operation 2022-07-26 14:38:30 theoretically there are people designated to merged changes in abuild 2022-07-26 14:38:59 practically it's "we don't know if this change is good enough for main maintainer's taste" 2022-07-26 14:39:09 communication and responsiveness and all that 2022-07-26 14:42:24 i'm sorry that i cannot keep up with everything. 2022-07-26 14:42:32 is it my turn to complain now? 2022-07-26 14:42:37 5c9f3ca3e307be53b45beeed2ce1626f38008625 2022-07-26 14:43:05 actually, its fb2496e8e08eec0708272fa1fd13bf0174250b95 2022-07-26 14:43:21 if you want to hear complaints about things 2022-07-26 14:43:30 the post-deinstall adds syslog service 2022-07-26 14:43:36 i can submit some of my own 2022-07-26 14:43:49 rc-update add syslog boot 2022-07-26 14:43:57 ncopa: I’m not blaming you at all - however, I think that if making the head of Alpine a triumvirate was not enough to discharge you and fluidify the contribution pipeline, maybe more people need to be integrated into the Alpine workflow 2022-07-26 14:44:26 so Alpine has enough manpower to shorten waiting queue and your busy schedule can finally stop being the limiting factor 2022-07-26 14:44:32 so when the build dependency is uninstalled, syslog is enabled next reboot, regardles if it was enabled/disabled before 2022-07-26 14:44:53 indeed looks like it should be removed 2022-07-26 14:45:14 maintainer scripts should not be manipulating openrc like that 2022-07-26 14:45:15 wtf 2022-07-26 14:45:21 exactly 2022-07-26 14:45:49 it's also from 8 years ago 2022-07-26 14:45:54 im not gonna check who was the committer - probably me anyway... :) - but this is bad 2022-07-26 14:45:56 yeah 2022-07-26 14:46:00 (you) 2022-07-26 14:46:22 sounds fine to just remove it 2022-07-26 14:46:25 yeah 2022-07-26 14:46:26 well 8 years ago the policies may not have been as well-defined as they are today 2022-07-26 14:46:31 that one was 2022-07-26 14:47:08 there is a bundled setup script but that one seems better 2022-07-26 14:47:35 if it even works 2022-07-26 14:48:57 okay, about this syslogd, could we talk about the why before talking about the how 2022-07-26 14:49:50 we may not. speaking is forbidden by the supreme council 2022-07-26 14:50:09 you may send your complaints to HR 2022-07-26 14:50:09 anyone want to have a look at inetutils-syslogd 2022-07-26 14:50:23 skarnet: i agree on that, inetutils-syslogd has an atrocious security record 2022-07-26 14:50:35 should just be yeeted imo 2022-07-26 14:50:36 my 'look' is remove from aports 2022-07-26 14:50:41 same 2022-07-26 14:50:43 I mean 2022-07-26 14:51:14 when the build script needs options like --disable-talk --disable-talkd --disable-rsh --disable-rshd --disable-rexec --disable-rexecd --disable-rcp 2022-07-26 14:51:20 that's because 2022-07-26 14:51:22 it's a mono-codebase 2022-07-26 14:51:25 with 10 things in it 2022-07-26 14:51:29 but split into 5 aports 2022-07-26 14:51:33 so they all pass different --disable-this 2022-07-26 14:51:35 and install one thing 2022-07-26 14:51:36 ah 2022-07-26 14:51:37 all of which having atrocious security records 2022-07-26 14:51:38 instead of subpackages 2022-07-26 14:51:44 this was packaged wrong in the first place 2022-07-26 14:51:46 :p 2022-07-26 14:51:56 no, this just shouldn't have been packaged in the first place 2022-07-26 14:52:03 yes, but by packaging methods 2022-07-26 14:52:08 ah yes it’s GNU inetutils 2022-07-26 14:52:11 and the remaining 5 or so tools just don't exist 2022-07-26 14:52:13 it's not like there's a shortage of syslogd implementations that have superior security record 2022-07-26 14:52:21 it does nothing that other software can’t do better 2022-07-26 14:52:28 skarnet: i am aware of me being bottle neck. the TSC was supposed to help with that (and i think it does), same with council 2022-07-26 14:52:34 i mean, basically *any* implementation has better security record than GNU inetutils :D 2022-07-26 14:52:41 :) 2022-07-26 14:53:20 ncopa: I am aware that you’re aware, what I’m saying is that if you’re *still* the bottleneck then additional measures might be a good idea :P 2022-07-26 14:53:34 my problem is with this situation is that from what I've been told, there are additional maintainers assigned to abuild, but in practice, all changes are waiting for you still, and it's not put blame on you ncopa but I would like to see a resolution to that, whether it's a) abuild maintainers agree that they review/merge stuff or b) abuild is maintained by you only, and we just have to deal with it or c) some other solution 2022-07-26 14:53:54 the problem is largely not that he is a bottleneck but that people do not feel empowered to use the authority that they were granted 2022-07-26 14:54:21 also a problem that I know the codebase best 2022-07-26 14:54:42 my code may be to ugly for other people want to touch it :) 2022-07-26 14:54:45 speaking of aports, it would be cool if we could have packages built with melange instead 2022-07-26 14:54:47 ACTION ducks 2022-07-26 14:55:03 ACTION throws a duck at Ariadne 2022-07-26 14:55:15 melange but in rust and in main 2022-07-26 14:55:18 ACTION hides 2022-07-26 14:55:35 it was originally written in rust 2022-07-26 14:56:04 Ariadne: if your thing can build correct apks in every situation in a totally isolated builder, with correct cross-builds, and understands existing APKBUILD syntax, etc. etc. then I don’t even care that it’s in Go 2022-07-26 14:56:32 having something *correct* would already be a superb start 2022-07-26 14:56:34 afaik, the "understands existing APKBUILD syntax" is not (yet?) there 2022-07-26 14:56:34 skarnet: the only blocker there is implementing an APKBUILD parser, but many APKBUILDs commit crimes that make it hard to use with anything other than shell 2022-07-26 14:57:02 yeah you can spawn a shell to interpret it, and collect the environment from the shell execution 2022-07-26 14:57:07 panekj: i know it is a problem. The current plan is to build a proper testsuite for abuild. will make anyone much more confident to merge things without my approval 2022-07-26 14:57:33 ncopa: is there any way to help make that happen 2022-07-26 14:58:20 panekj: also, im may not be very good at telling people that I do appreciate the patience and the willingness to help 2022-07-26 14:58:28 but it does mean alot to me, so thanks 2022-07-26 14:58:41 let me see what the current status is 2022-07-26 14:59:15 so, i think what would help would be to help improve test coverage 2022-07-26 14:59:28 looks like I already switched it to kyua 2022-07-26 14:59:37 before you do anything at all 2022-07-26 14:59:41 could you merge that rust change 2022-07-26 14:59:43 and make a quick release 2022-07-26 14:59:45 and then get to all this 2022-07-26 14:59:46 :) 2022-07-26 14:59:51 to at least put in the past 10 months of changes in 2022-07-26 14:59:52 ncopa: please understand my usual pushiness as a willingness to help on issues I think I’m competent on (e.g. package organization) ;) 2022-07-26 15:00:04 the URL? 2022-07-26 15:00:09 oh man.. i have a meeeting now 2022-07-26 15:00:23 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/135 2022-07-26 15:00:24 psykose: which? 2022-07-26 15:00:28 me too 2022-07-26 15:00:32 oh this 2022-07-26 15:00:35 my MR 2022-07-26 15:01:11 alternative version is to drop the panic=abort, but the rest of the changes are fine, and i tested it everywhere 2022-07-26 15:01:30 did you run every rust package? :P 2022-07-26 15:03:05 I could apply that change and rebuild whole aports aports, last time I did that I didn't have any issues apart from few packages with some unrelated borking 2022-07-26 15:03:19 s/whole aports aports/whole aports again 2022-07-26 15:03:19 panekj meant to say: I could apply that change and rebuild whole aports again, last time I did that I didn't have any issues apart from few packages with some unrelated borking 2022-07-26 15:04:24 ok, hungry time now, I'll try to deep dive into abuild+tests at some point and see with what I can help cc: ncopa 2022-07-26 15:07:34 more or less yes 2022-07-26 15:07:59 i also build a ton of things with clang and whatnot, and ran the -fstack-protector-strong -fno-plt flags for a while 2022-07-26 15:15:53 ddevault: it would nice thak 'apk update' warms about unmaintaned repositories 2022-07-26 15:17:33 indeed 2022-07-26 15:18:27 I wonder if it could be added to apkv3 2022-07-26 15:19:10 i think i have suggested this in past, also warning about incompatible repositories (e.g. alpine release + edge) 2022-07-26 15:20:51 does apkv3 have any idea of repo versions? 2022-07-26 15:21:26 otherwise that seems like very alpine-specific issue 2022-07-26 15:23:19 panekj: nope :) 2022-07-26 15:24:02 other way could be warning on mixing repository sources 2022-07-26 15:24:50 but that wouldn't solve specific issue of "user added edge/testing, because package X, but they didn't knew they had to switch to edge entirely" 2022-07-26 15:29:54 couldn't be the UNMAINTANED flag saved into APKINDEX? it seems the simplest solution for first case 2022-07-26 15:38:49 I was solely speaking about stable/edge mixing 2022-07-26 15:40:47 Repos do not really have an identity except by convention 2022-07-26 15:49:16 donoban, ddevault: a possibility could be to have an expiration date on the APKINDEX, after which apk can warn that the repo is stale 2022-07-26 15:49:49 sounds good 2022-07-26 15:49:57 something like `apk: the [...] repository ended support at [date]` 2022-07-26 15:50:37 but is really need to handle the date? 2022-07-26 15:50:54 with just a unmantained flag you could just set it true when a new release come 2022-07-26 15:51:06 the problem with an `UNMAINTAINED` flag is that it requires someone to actually go and set that flagh 2022-07-26 15:51:09 -h 2022-07-26 15:51:10 and the last apkindex upgrade just sets it 2022-07-26 15:51:21 while an expiration date can be set in advance 2022-07-26 15:51:27 ahh, I understand 2022-07-26 15:52:21 with apkv3 it is a lot simpler to do 2022-07-26 15:53:13 donoban: the other thing is, we can set a stale-date on `edge` of a few days 2022-07-26 15:53:25 so apk nags you to update more frequently :) 2022-07-26 15:53:36 another thing that I would like in apk, is that it notifies when a package ugprade contains secfixes 2022-07-26 15:53:46 that is coming to apk3 2022-07-26 15:53:51 apk list --upgradable --security 2022-07-26 15:53:55 great :D 2022-07-26 15:54:04 challenge is getting the secdb translated to ADB :) 2022-07-26 15:54:11 uhm 2022-07-26 15:54:29 (ADB is a database format used by apkv3) 2022-07-26 15:54:33 can't be the secfixes codes, added to the .apk itself? 2022-07-26 15:54:40 no 2022-07-26 15:54:51 we don't want to do it that way 2022-07-26 15:55:04 we want the APKINDEX to have a reference to the secfixes feed for that repo 2022-07-26 15:55:16 I see 2022-07-26 15:55:56 yeah otherwise you can't know that some upgade contains secfisex 2022-07-26 15:56:03 until you download it :\ 2022-07-26 15:56:04 at the moment, there is /etc/secfixes.d which is an ugly hack 2022-07-26 17:35:35 times like these i wish i had a rv64 devboard 2022-07-26 17:35:36 weh 2022-07-26 17:37:54 i think sifive are supposed to make a new one soon 2022-07-26 17:38:25 hifive unmatched is a few years old and more extensions got accepted in the spec 2022-07-26 17:38:29 that costs a million dollars 2022-07-26 17:39:14 was on mouser for less than a grand 2022-07-26 17:39:20 https://www.mouser.ca/ProductDetail/SiFive/HF105-000?qs=zW32dvEIR3vHEV%2FPYYkdMA%3D%3D stock's out tho 2022-07-26 17:41:16 indeed a million dollars 2022-07-26 17:42:01 almost 2022-07-26 17:46:23 hm 2022-07-26 17:46:28 seems the riscv textrels are fake 2022-07-26 17:46:34 they're all like this https://bugs.gentoo.org/713082 2022-07-26 17:46:49 https://img.ayaya.dev/K9DfLpfsY3hG 2022-07-26 17:46:56 just a weird binutils ld bug 2022-07-26 17:47:29 psykose: I had a suspicion it was something like that 2022-07-26 17:47:32 yep 2022-07-26 17:47:46 between cbindgen and nodejs, everything else for firefox on riscv is covered i think :) 2022-07-26 17:47:51 hehe 2022-07-26 18:52:10 using a different linker fixes the textrels 2022-07-26 18:52:26 and then breaks everything else, funnily 2022-07-26 18:52:29 /usr/bin/strip: ./usr/bin/stLiDJgo: not enough room for program headers, try linking with -N 2022-07-26 18:52:32 god i hate binutils 2022-07-26 22:36:56 Hi there, where can I request a generic downloadable cloud image to be created? I would love to use cloud-init, but that requires an generic image with it in mind, and the only ones I can find are on AWS EC2. 2022-07-26 22:41:16 https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/133 2022-07-26 22:43:44 but to answer your question, the correct place is usually either the aports repo on alpine gitlab (linked on the main page under "issues") or the infra issue tracker: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues 2022-07-26 23:11:56 Ah, somehow had missed that in Gitlab. Very easy to do though. :) 2022-07-27 05:38:22 is there a good reason why bison depends on itself for check? 2022-07-27 05:40:10 the commit introducing it is just 'add check', so it confuses me a bit 2022-07-27 05:41:57 Maybe it requires an installed bison for checks? 2022-07-27 05:42:02 not sure 2022-07-27 05:43:50 I see the test suite has a wrapper to use the non-installed bison 2022-07-27 08:41:11 community/vdr source url is broken https://projects.vdr-developer.org/ 2022-07-27 08:41:23 invalid cert for some reason 2022-07-27 08:41:51 self signed cert 2022-07-27 10:11:25 meh... community/wezterm testsuite fails 2022-07-27 10:20:20 uhM, I got many mandb warnings while upgrading 2022-07-27 10:20:41 tons of http://ix.io/45Om 2022-07-27 10:22:18 ncopa: mhmm? 2022-07-27 10:25:45 ptrc: it seems it builds fine without bison in checkdepends, so maybe it was needed before, but not at the moment? 2022-07-27 10:26:21 panekj: I first noticed it while rebuilding against openssl3, but it also seems to fail in current git master 2022-07-27 10:27:58 what it says 2022-07-27 10:29:47 ikke: ah, makes sense :) i guess that's not an issue, since it's usually bootstrapped anyway 2022-07-27 10:30:04 there is currently MR open by jirutka to rework whole package and it doesn't fail in CI 2022-07-27 10:40:00 failures: 2022-07-27 10:40:00 shapecache::test::ligatures_jetbrains 2022-07-27 10:40:11 test result: FAILED. 7 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 3.97s 2022-07-27 10:41:26 test shapecache::test::ligatures_jetbrains ... ok 2022-07-27 10:41:41 ncopa-desktop:~/aports/community/wezterm (master)$ abuild check 2>&1 | tpaste 2022-07-27 10:41:41 https://tpaste.us/5k1x 2022-07-27 10:42:03 what architecture you are building it on 2022-07-27 10:42:32 Expected string to match inline snapshot 2022-07-27 10:42:47 num_cells: 2 -> num_cells: 1 2022-07-27 10:42:51 x86_64 2022-07-27 10:51:44 wow, I reached the end of my openssl3 rebuilds for main and community 2022-07-27 11:31:32 php8 8.0.21 fails to build with openssl3. can we drop it in favor of php 8.1? 2022-07-27 11:35:32 andypost[m]: ^ 2022-07-27 11:40:50 ncopa: good question I hope yes 2022-07-27 11:41:21 Btw I recall a patch for compatibility 2022-07-27 11:41:34 How to deal with abuild rootbld when it comes to install the dependencies? It should read what is written in /etc/abuild.conf or $HOME/.abuild/abuild.conf $REPODEST var, right? 2022-07-27 11:44:24 I've built community/gvm-libs on 22.4 version. oepnvas-scanner 22.4.0 is expecting that version of gvm-libs, but it fails to find it 2022-07-27 11:45:04 did you add your paths to .rootbld-repositories? 2022-07-27 11:45:39 panekj, no 2022-07-27 11:45:52 But I never did that 2022-07-27 11:50:18 ncopa looks it will be easy to drop php8 as there's lots of patches and I'm not sure in stability, https://www.php.net/manual/en/openssl.requirements.php states>=8.1 2022-07-27 11:51:44 I hope to have only php81 and php82 before Dec in community 2022-07-27 11:51:52 php81 builds fine with openssl3 2022-07-27 11:52:14 ok. lest keep php8 with openssl1.1-compat for now then 2022-07-27 11:54:19 ++ as checking compatibility of all dependant could take a while 2022-07-27 12:02:45 hum.. php8 does not build with openssl1.1-compat. it gets in conflict 2022-07-27 12:03:28 conflict with some of the other dependencies that uses openssl3 2022-07-27 12:04:28 so, we either have to fix building it openssl3, or remove it together with openssl3 update or disable php8-openssl module 2022-07-27 12:15:14 I will dig it tonight, maybe we can patch it 2022-07-27 13:03:57 I'm trying to build mpd from aports on alpine 3.16, but for some reason I get an error meson.build:1:0: ERROR: Unknown compiler(s): [['gcc']]. All the dependencies are installed and with 3.15 all built without problems. Has something changed or is this my fault? 2022-07-27 13:08:50 ncopa: please try patches https://github.com/php/php-src/pull/7002 and https://github.com/php/php-src/pull/7337 2022-07-27 13:13:16 what is analogue of debian's pyqt5-dev-tools in alpine? Is it py3-qt5? 2022-07-27 13:14:21 Ermine: iirc we don't split pyqt packages in alpine, so yeah 2022-07-27 13:21:27 ptrc: thx 2022-07-27 14:31:54 andypost[m]: will try. Thanks! 2022-07-27 15:20:19 some tests fails, but not sure if its due to openssl 2022-07-27 15:24:21 hey there ! libxcb-doc man pages fails to be processed. It is known ? 2022-07-27 15:24:24 from a day or two 2022-07-27 15:24:45 every apk command I got thousand of warnings :D 2022-07-27 15:25:22 someone also mentioned it here 2022-07-27 15:25:49 but the libxcb-doc package wasn't touched since forever 2022-07-27 15:25:52 is it ok if package downloads its go dependenices? 2022-07-27 15:26:17 yeah, currently there's no other way for building go stuff 2022-07-27 15:27:07 ah, i guess i know what's with the docs 2022-07-27 15:27:20 489527ae4f added mandoc as an alternative provider 2022-07-27 15:28:09 or wait, no 2022-07-27 15:29:45 staceee: what's the result of `apk info --installed cmd:man` for you? 2022-07-27 15:30:09 man-db 2022-07-27 15:33:11 ah, so i guess the man-db trigger can't handle that specific package? 2022-07-27 15:33:31 i think man-db is not tested so much, probably most people use mandoc 2022-07-27 15:34:30 well, it's only a warning anyway 2022-07-27 15:34:52 I only got docs in world 2022-07-27 15:35:53 so if I install mandoc it should works ? 2022-07-27 15:35:56 yeah, but docs depends on cmd:man, which gets resolved to either mandoc or man-db (the latter in your case) 2022-07-27 15:36:40 added mandoc and so man-db leaved 2022-07-27 15:36:54 but I think some other people will come to warn :D 2022-07-27 17:28:03 ncopa: the was a bunch of commits to fix tests https://github.com/php/php-src/pull/7002#issuecomment-1126966284 2022-07-27 17:28:15 s/the/there 2022-07-27 17:28:15 andypost[m] meant to say: ncopa: there was a bunch of commits to fix tests https://github.com/php/php-src/pull/7002#issuecomment-1126966284 2022-07-27 17:29:02 easier to disable failed test 2022-07-27 18:30:37 Hello .  Is this a right channel to talk about CVEs ?  In specific, https://nvd.nist.gov/vuln/detail/CVE-2022-30065 2022-07-27 18:31:30 There is #alpine-security 2022-07-27 18:31:32 #alpine-security would be a better fit 2022-07-27 18:31:48 but fwiw, this is fixed in alpine: https://security.alpinelinux.org/vuln/CVE-2022-30065 2022-07-27 22:55:46 staceee: fixed 2022-07-28 06:21:40 Ariadne: did you have a chance yet to take a look at the gcc 12 upgrade? (: 2022-07-28 06:22:06 I hope I am not being annoying, just want to get it done as soon as possible for the 3.17 release cycle 2022-07-28 06:22:29 i will get to it today or tomorrow. also pkgconf 1.9 2022-07-28 06:58:23 nmeum: did you have a think about libexecinfo 2022-07-28 06:59:40 psykose: didn't have the time to look into it in detail yet, sorry. will try to find some time today 2022-07-28 07:00:17 note that it's equally easy for me to go patch it out in 18 places and rm -rf main/libexecinfo 2022-07-28 07:02:12 *nod* 2022-07-28 07:03:01 morning! what about libexecinfo? 2022-07-28 07:03:18 it's been broken and meaningless for years and just segfaults if you call it 2022-07-28 07:03:38 and doesn't really have any application use aside from 'print crash stacktrace', except well it doesn't even work for that, so 2022-07-28 07:03:52 sort of, yes 2022-07-28 07:04:19 have you tried it without -fomit-framepointer? 2022-07-28 07:04:25 so you end up with for example https://gitlab.alpinelinux.org/alpine/aports/-/issues/10896 2022-07-28 07:04:29 or have you tested it on aarch64? 2022-07-28 07:04:30 yeah, i've tried a thousand thing 2022-07-28 07:04:37 ok 2022-07-28 07:04:45 so then i looked at the 'upstream' 2022-07-28 07:04:52 https://www.freshports.org/devel/libexecinfo 2022-07-28 07:04:58 and noticed it was just merged into freebsd a millenium ago 2022-07-28 07:05:15 and so looking at the description 2022-07-28 07:05:16 > A quick-n-dirty BSD licensed clone of the GNU libc backtrace facility 2022-07-28 07:05:26 i noticed they just put it into the freebsd monorepo 2022-07-28 07:05:34 and so i recloned it from there and ported it again 2022-07-28 07:05:42 i had a look at it a few years ago 2022-07-28 07:05:45 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36722 2022-07-28 07:06:01 and this version (which also uses libelf), at least doesn't segfault 2022-07-28 07:06:02 and to my understanding it cannot work with -fomit-frampointer 2022-07-28 07:06:11 it doesn't work either way 2022-07-28 07:06:16 it only works at -O0 2022-07-28 07:06:21 (the new one) 2022-07-28 07:06:29 does it work with -g? 2022-07-28 07:06:33 the old one always segfaults, and sometimes, with -fno -O0 you may get something 2022-07-28 07:06:34 iirc no 2022-07-28 07:06:39 i mean i can test it all again if you want 2022-07-28 07:06:41 but my conclusion was 2022-07-28 07:06:44 'literally never works' 2022-07-28 07:06:49 yeah 2022-07-28 07:06:55 except like 2 scenarios involving -O0 or similar 2022-07-28 07:06:59 so generally, never in aports 2022-07-28 07:07:20 also, the usecase where it alsmost alwas is used is for printing backtraces on segfault 2022-07-28 07:07:25 this one still doesn't; with any non 0 -O you get 1 frame 2022-07-28 07:07:25 which is bad anyway 2022-07-28 07:07:28 but no segfault 2022-07-28 07:07:32 yeah, more or less 2022-07-28 07:07:38 so, i'm not attached to either solution 2022-07-28 07:07:47 but it's better than doing nothing, and rm -rf is also okay 2022-07-28 07:08:02 (i will take care of the dependents myself no issue) 2022-07-28 07:08:19 im ok with that 2022-07-28 07:08:51 i have known it for a while, but never bothered enough to actually do anything about it 2022-07-28 07:08:53 alright, so +1 on removal instead then? :) 2022-07-28 07:09:00 yup 2022-07-28 07:09:04 ack 2022-07-28 07:09:11 just check if there is any valid usecase 2022-07-28 07:09:33 ie. antying that uses is that is not for printing a backtrace in a segfault handler 2022-07-28 07:09:59 sometimes it was not a segfault handler but rather a c++ abort handler (and the program continues) 2022-07-28 07:10:16 or well, not abort but something similar to that 2022-07-28 07:11:49 hum.. those may be broken then 2022-07-28 07:12:17 there was also a patch for musl requested by fabled, to include some more debug info in musl 2022-07-28 07:12:32 which is requried for beinga ble toing any backtraces at all 2022-07-28 07:12:41 s/toing/doing/ 2022-07-28 07:12:41 ncopa meant to say: which is requried for beinga ble doing any backtraces at all 2022-07-28 07:13:05 which use some other data in elf to be able to do backtrace 2022-07-28 07:13:29 well, currently, if you build my forked one 2022-07-28 07:13:41 and use it on the sample backtrace program (it's in the repo) 2022-07-28 07:13:49 you get stacks with -O0 and don't otherwise 2022-07-28 07:13:57 if you want to experiment and make it always print stacks, go for it 2022-07-28 07:14:18 (i sadly know nothing of the libc-level requirements or whatnot for this ^^) 2022-07-28 07:14:47 there is also libunwind which to my understanding solves the same issue? 2022-07-28 07:15:18 in any case, stop using libexecinfo as crash handler is correct thing to do anyway 2022-07-28 07:15:23 maybe? i dunno 2022-07-28 07:15:26 there's like 50 tools for this 2022-07-28 07:15:43 but sadly backtrace() is in most libcs and things sometimes use it 2022-07-28 07:16:21 also, if you know anything about it, fortify-headers is a little broken with LTO 2022-07-28 07:18:21 iirc one of my gsoc students is poking at libexecinfo and modernising it 2022-07-28 07:18:35 the one from the freebsd tree? 2022-07-28 07:18:42 do other distros package libexecinfo? 2022-07-28 07:18:55 arch, for example, doesn't even seem to have in their repos 2022-07-28 07:18:57 other distros use glibc 2022-07-28 07:19:04 backtrace() is in glibc 2022-07-28 07:19:07 ahhh! 2022-07-28 07:19:21 i think this one originates from there 2022-07-28 07:19:23 nmeum: what psykose said 2022-07-28 07:19:27 it's useful for when you don't want to patch a million packages 2022-07-28 07:19:29 otherwise i'd not have it at all indeed :( 2022-07-28 07:19:45 well.. most of the patches are to link it if you do have it 2022-07-28 07:20:01 and usually 'figure out where in cmake to add -lexecinfo' is actually more effort than 'remove backtrace()' 2022-07-28 07:20:04 which is funny 2022-07-28 07:20:36 seriously 2022-07-28 07:20:53 there are some nicer programs that check whether to link, or ifdef the entire usage, or whatever, but for the most part.. eh 2022-07-28 07:21:05 void does have it but it hasn't been touched in ages and probably also doesn't work then 2022-07-28 07:21:13 the version we have is uh 2022-07-28 07:21:21 so bad 2022-07-28 07:21:32 random version from 2010 freebsd? 2022-07-28 07:21:34 or older 2022-07-28 07:21:41 I guess if using the libexecinfo version from the freebsd monorepo just changes it's state from broken to a different kind of broken then we might as well remove it 2022-07-28 07:21:43 it doesn't get touched much in freebsd either, but this latest one does work 2022-07-28 07:21:56 i didnt know about fortify-headers and LTO 2022-07-28 07:21:59 the difference in 'the whole stack is missing' is probably libc side 2022-07-28 07:22:10 ncopa: i was considering using it and then it triggered rich into explaining some aliasing problems in it 2022-07-28 07:22:12 and freebsd libc probably has it more filled with goodies, so it works fine there 2022-07-28 07:22:15 I think the fortify-headers LTO thing might be a gcc bug 2022-07-28 07:22:15 he said it'd be better off rewritten 2022-07-28 07:22:22 sam_: i was in the same discussion 2022-07-28 07:22:41 certainly could be better; no idea how to rewrite it sadly 2022-07-28 07:22:54 #13735 all i've found so far 2022-07-28 07:23:31 i can dig out the irc logs later, rich gave a few examples of how to fix it 2022-07-28 07:23:33 (i did think clang worked in that case but upon looking at the implementation they use gcc internal features so it wouldn't have worked anyway) 2022-07-28 07:23:35 (if you dont have it already) 2022-07-28 07:23:40 not read bu- 2022-07-28 07:23:43 (i always lose irc logs) 2022-07-28 07:24:04 fortify-headers doesn't work with clang because it uses gcc builtins that are presently not supported by clang 2022-07-28 07:24:08 yes 2022-07-28 07:24:19 i'll pm it because #musl logging policy but you were there anyway so w/e. i had to do it for blueness the other day too so i have it handy 2022-07-28 07:24:27 which is also something that we should address eventually because it would be cool to also have fortify-headers for clang 2022-07-28 07:24:41 i certainly use clang in a lot of places :) 2022-07-28 07:37:12 ah, okay, i fixed fortify headers 2022-07-28 07:37:15 (for gcc) 2022-07-28 07:37:55 and by fixed i mean i can go write a bunch of code to fix the rest of it 2022-07-28 07:37:58 does this even have an upstream 2022-07-28 07:38:17 this 'sin' person around or nah 2022-07-28 08:43:50 long time since I saw him 2022-07-28 10:05:11 ACTION found no benefits/regressions building php82 with clang, except striping 2022-07-28 10:05:50 what stripping 2022-07-28 10:05:51 ...and size of -dbg package 2022-07-28 10:06:26 if you're referring to before that had nothing to do with clang at all 2022-07-28 10:07:01 https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10072 yep iirc you found the cause psykose 2022-07-28 10:07:08 :) 2022-07-28 10:07:10 easy fix 2022-07-28 10:08:20 https://img.ayaya.dev/9Hbp7Z03Lmyh 2022-07-28 10:11:14 I did not check for fortify-headers but official docker is build with gcc https://github.com/docker-library/php/blob/master/8.1/alpine3.16/fpm/Dockerfile#L16 2022-07-28 10:13:46 otoh clang evolving faster so challenging to try get benefits 2022-07-28 10:14:38 at least for pre-release package 2022-07-28 12:31:28 nmeum: i think perhaps you have a point about it maybe being a gcc bug 2022-07-28 13:10:49 andypost[m]: You need to make sure packages depepend on concrete packages if they are required during build 2022-07-28 13:11:15 andypost[m]: re 27597b1945536b800985e31c25041bd91720efa5 2022-07-28 13:11:55 ok, n/m, for composer it doesn't matter, there is no build step 2022-07-28 13:12:04 although, for checkdepends it does matter 2022-07-28 13:12:31 algitbot: in summary, you should add php to makedepends 2022-07-28 13:12:35 or checkdepends in this case 2022-07-28 13:12:44 andypost[m]: * 2022-07-28 13:13:39 Otherwise it might be built before php and fail for new releases 2022-07-28 13:35:14 Yes, I just realized it and filed upgrade 2022-07-28 13:36:28 Checking other depending and gonna switch default to 81 2022-07-28 14:33:22 ncopa: i assume the musl patch was the eh-frame one, but it was removed on the 1.2.3 upgrade (and seems to not have been upstreamed either?), and we had it with --disable, and it seems to hint that it's only for debugging without musl-dbg 2022-07-28 14:54:53 psykose: thats the one 2022-07-28 14:55:05 ah, hm 2022-07-28 14:55:15 that indeed would not be loaded without gdb to load it in, normally 2022-07-28 14:55:21 (meaning stacktraces only in gdb) 2022-07-28 14:55:31 we tried to get it in upstream 2022-07-28 14:55:32 but yeah, it was removed, and it was disabled even while it was there 2022-07-28 14:55:33 weh 2022-07-28 14:55:42 but upstream didn't want it 2022-07-28 14:55:44 (and it only touched x86* code?) 2022-07-28 14:55:45 mhm 2022-07-28 14:56:00 i think arm already enables eh-frame by default 2022-07-28 14:56:10 makes sense 2022-07-28 14:56:41 which was an argument for why we should enable it on x86* as well 2022-07-28 14:56:59 do you have a link to the ML from the time? 2022-07-28 14:57:07 i mean, i can already guess the reasoning, but eh 2022-07-28 14:57:57 rich severely hates any form of runtime application stacktracing so i doubt it would go well from that alone :) 2022-07-28 14:58:50 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22958 2022-07-28 14:59:23 > runtime profiling 2022-07-28 14:59:35 what kind of profiling is this referring to? (via .eh_frame) 2022-07-28 15:00:04 https://www.openwall.com/lists/musl/2021/07/16/1 2022-07-28 15:01:31 i think it was for optimyze https://prodfiler.com/ 2022-07-28 15:02:12 ah, so not pgo-level things 2022-07-28 15:03:22 > explore the most expensive lines of code and functions across your entire fleet 2022-07-28 15:03:33 don't need that for this, i already know 40% of the time is in __unlock /j 2022-07-28 15:06:59 hm, seems it implies even libunwind needs this 2022-07-28 15:11:15 well, fuck it i guess, i will go patch the dependents 2022-07-28 19:02:11 ncopa: php81 is default now 3d38ed46b341 2022-07-29 00:15:57 hehe, fun https://sourceware.org/bugzilla/show_bug.cgi?id=28981 2022-07-29 00:16:03 why is it always binutils bugs all day long 2022-07-29 00:46:44 I seem to be having issues with Linux 5.15.57 and Xen (I think?), so I've pinned it at .56 for now 2022-07-29 00:52:57 somewhere during OpenRC boot 2022-07-29 00:53:28 been spending too many hours trying to fgure out what and where,, sorry that I cannot currently be more specific 2022-07-29 00:55:10 without logs it's hard to guess, strange.. 2022-07-29 08:37:21 omni: do you have a way to reproduce it? 2022-07-29 09:28:35 ncopa: this is with dom0=pv, with dom0=pvh Linux 5.15.57 works (I recently found out), but then I cannot PCI passthrough devices to DomUs (I think, perhaps something stubdom? they show up with 'xl pci-assignable-list', so xen-pciback manage to hide them) 2022-07-29 09:29:22 but now I just got myself another problem when 'apk -aU upgrade' purged 969 packages.. 2022-07-29 09:32:50 maybe I should add that zfsbootmenu aport after all and give up on syslinux 2022-07-29 11:05:31 tmhoang5: looks like upstream exempi wants to drop big-endian support (s390x). I dont know if anyone from IBM is willing to debug and provide a fix for the issue. https://gitlab.freedesktop.org/libopenraw/exempi/-/issues/23 2022-07-29 11:05:52 ncopa: I think it breaks when loading modules, in my /etc/modules I have: af_packet ipv6 tun raid1 zstd snd_seq 2022-07-29 11:07:43 omni: how much memory does your dom0 have? Have you tried to increase it a bit? 2022-07-29 11:09:34 dom0_mem=12288M (stupid web browsers) 2022-07-29 11:10:54 ok. its probably not running out of memory then 2022-07-29 11:15:00 no =) 2022-07-29 11:35:32 ok, i have done almost all of the openssl3 rebuilds 2022-07-29 11:36:38 there are a few that has broken tests (php 8.0, namecoin? etc), a few that has build error (rustup, ruby-eventmachine). I wonder if I should just push what I got so far and get the maintainers to help with the remaining issues? 2022-07-29 11:37:05 i have also not started with the testing repo, which will end up broken after the push. 2022-07-29 11:38:50 there are also a handful packages that still are on openssl1.1, but they shouldn't have mixed shared libs, so should be ok 2022-07-29 11:39:38 main/pound needs an update, which switch to mbedtls 2022-07-29 11:42:26 I'm too tired to tell if there are fixes for my issue in the Xen stable-4.16 branch that could go in with this !37023 2022-07-29 11:46:03 LGTM. is it still a draft? or can we merge it? 2022-07-29 13:30:54 ncopa: no, not if we're not gonna add anything 2022-07-29 13:30:59 sorry, had to take a nap 2022-07-29 14:34:07 ncopa: good news! Linux 5.15.57 seem to work fine with a PV and a HVM DomU (both on 3.16-stable) 2022-07-29 14:34:23 great! 2022-07-29 14:34:27 what is the difference? 2022-07-29 14:35:10 not Dom0 and less modules being loaded at boot, as far as I can tell so far 2022-07-29 14:35:35 ok 2022-07-29 14:35:49 so it might still be a regression for dom0 in .57 kernel 2022-07-29 14:36:33 yes, I'll try again later and see with less modules and one or two other ideas 2022-07-29 14:36:57 but I'm still awfully tired, despite the nap 2022-07-29 21:43:05 I tried without a /etc/modules and disabled various services that felt less important, but still the same issue during openrc boot 2022-07-29 21:44:07 either it will freeze or reboot without any message other than what was last seen in the boot process 2022-07-29 22:54:05 ncopa: if you don't feel like doing testing/ , open an MR with all your changes 2022-07-29 22:54:17 i'll do all of testing/ myself, then add it to it, then we can merge it at once 2022-07-29 22:54:27 a bit better than you merging what you have and me running after it afterward :p 2022-07-29 22:55:02 but you've done enough work as it is, i can continue it ^^ 2022-07-30 04:02:45 omni: Not sure if related, but I have a system that seems to randomly reboot as well 2022-07-30 04:02:51 no freezes though 2022-07-30 04:03:33 hmm, linux 5.15.52 though, not 57 2022-07-30 04:32:57 ikke: do you feel like giving ptrc the reporter role so she can clean up random issues 2022-07-30 04:33:03 (she basically just tells me every time) 2022-07-30 04:33:20 heh, I think that should be fine 2022-07-30 04:34:02 ✔️ 2022-07-30 04:34:10 thanks :3 2022-07-30 07:03:58 Ermine: are you sure this trafficserver thing even works? 2022-07-30 07:04:07 (i am currently patching out libexecinfo from everything) 2022-07-30 07:04:16 and this one is doing some weird shit with the symbols 2022-07-30 07:04:29 see include/tscore/Allocator.h:203 2022-07-30 07:06:10 i guess it's always a no-op and just skipped as it will be null on callstack[2] regardless of anything 2022-07-30 07:07:24 gcc-cross-embedded is brutal for rv64 2022-07-30 07:07:38 yep, always 2022-07-30 07:07:44 It's still chugging along 2022-07-30 07:07:56 iirc it builds 5 gcc's 2022-07-30 07:08:01 i am not sure why it's so much worse emulated 2022-07-30 07:08:09 me neither 2022-07-30 07:08:40 it's not really something that uses 1 core for long 2022-07-30 07:08:44 the rust things are worse for that 2022-07-30 07:08:52 doesn't have lto enabled or anything 2022-07-30 07:09:23 it's switching from multi-core thigns to single core things regularly 2022-07-30 07:09:42 yeah, but not in the sense of there being some very single threaded parts 2022-07-30 07:09:43 shrug 2022-07-30 07:10:14 psykose: re trafficserver: not sure 2022-07-30 07:10:38 if you want to test it, https://img.ayaya.dev/sCx5XgfFyYz4 2022-07-30 07:13:34 Will try later 2022-07-30 09:03:31 ikke: gcc-cross-embedded builds gcc for a lot of targets, hence it takes forever. I think we could also just disable it on riscv64 for now 2022-07-30 09:06:26 yeah, but the relative difference is much bigger compared to the others for some reason 2022-07-30 09:06:43 i.e. riscv is X slower, but for this specifically it's like 10X slower compared to the other builders 2022-07-30 09:06:51 which is strange :p but that's all 2022-07-30 09:19:46 right, I am just saying: if it blocks the riscv64 builder for too long I don't think it would be a problem to just disable it on riscv64 2022-07-30 09:19:54 yeah, agreed 2022-07-30 09:20:46 (also z3 fails tests on s390x) 2022-07-30 11:25:05 I see no issue was reported yet? 2022-07-30 11:25:14 Maybe a big-endian issue? 2022-07-30 11:28:08 always is 2022-07-30 11:28:47 ahuh 2022-07-30 11:56:18 I've done approx half of testing. I think I will rebase and push on Monday 2022-07-30 11:56:52 openssl 3.0? 2022-07-30 11:57:41 could do it now too 2022-07-30 11:57:42 :) 2022-07-30 14:27:03 psykose: apparently traffic server works 2022-07-30 14:28:11 I configured a basic forward proxy at least 2022-07-30 14:34:09 psykose: linting should be fixed now. Something something subshell 2022-07-30 14:34:23 subshell more like subhell 2022-07-30 14:34:25 Ermine: nice 2022-07-30 14:39:13 Anyway: 1) ATS has a feature that relies on dlclose (iiuc) actually working, 2) Upstream developera are not very talkative, 3) it would be good to have inputs from people administering Real World setups 2022-07-30 15:05:41 yeah, it doesn't work for 0-downtime module upgrade 2022-07-30 15:05:45 but works fine for normal restart 2022-07-30 15:27:26 ncopa: could you also make an abuild release 2022-07-30 16:14:41 Hi 2022-07-30 16:27:11 what's up 2022-07-30 16:41:02 Do you want me to look up? 2022-07-30 16:58:31 hello 2022-07-30 16:58:57 o/ 2022-07-30 16:59:03 i wanted to know what exactly an 'apkovl' is 2022-07-30 17:00:49 like from genapkovl-dhcp 2022-07-30 17:01:05 It's a mechanism that Alpine uses to persist data on a run-from-ram system 2022-07-30 17:01:40 It's generated generally by lbu (local backup) 2022-07-30 17:06:55 i am trying to make a custom iso. Is it possible to ship an ISO with Xorg and a desktop environment running? I managed to build an ISO with some packages preinstalled but I am not sure how can I configure files 2022-07-30 17:10:35 for example, if i want zsh to be the default shell i could change it in /etc/passwd. but the file is not yet created when the genapkovl script is running 2022-07-30 17:11:08 No experience with this myself, so no good idea how to achieve it 2022-07-30 17:46:42 https://www.irccloud.com/pastebin/PRfOKJDe 2022-07-30 17:47:02 a link to a link, nice 2022-07-30 17:51:28 comment out the code 2022-07-30 17:51:30 ah, the old alpine-a-roo 2022-07-30 17:51:53 i know exactly where that's from and you can just remove the if 2022-07-30 17:52:00 for the first one 2022-07-30 17:52:18 for the second, either it's the same or you have to cast something :) 2022-07-30 17:53:07 why is the whole question in bold and half of it in italic 2022-07-30 17:55:07 ah, yeah 2022-07-30 17:55:16 all 3 of the openssl locking functions in that if are no-ops 2022-07-30 17:56:02 (unless i really can't read the headers, i'm tired) 2022-07-30 18:26:12 openssl 1.1 changed the locking system, you used to have to provide your own mutex lock/unlock callbacks 2022-07-30 19:15:55 hi 2022-07-30 19:16:10 http://p4db5azdcwp66cq32w3wgdzhh3af2jtujdy6krf22osradgvmr2pshad.onion 2022-07-30 19:16:37 added: looks like spam 2022-07-30 19:16:50 any case most people will probably not be able to visit that 2022-07-30 19:29:05 it is 2022-07-30 19:29:14 seen this same spam lots of times now :) 2022-07-30 19:29:20 iirc it wasn't even anything good 2022-07-30 19:29:22 really benign 2022-07-30 19:29:29 not even hot single :( 2022-07-30 20:03:00 it also appeared in #chimera-linux 2022-07-30 21:13:25 i managed to make a custom alpine iso with lightdm and xfce. the lightdm screen shows, but i cannot move the mouse or type anything. i am using qemu x64 with gtk 2022-07-30 21:13:47 Guest6486: make sure your used is in the input group 2022-07-30 21:13:54 And there are some others you want to be in as well 2022-07-30 21:13:55 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36618 2022-07-30 21:13:56 gitea v1.17.0 released 🎉 2022-07-30 21:13:58 i installed everything from the setup-xorg-base script + xf86-video-modesetting 2022-07-30 21:14:00 s/used/user 2022-07-30 21:14:15 but i havent logged in yet, so lightdm must be a root process right? 2022-07-30 21:15:36 it's a service that's running 2022-07-31 02:54:01 i disabled lightdm and manually started an xfce4 session with startx, and the user is in the input group. mouse and keyboard are still not working in xorg with qemu 2022-07-31 02:56:15 the keyboard at least works while in tty, just not when i start the xorg session 2022-07-31 03:00:09 dbus and udevd are both running, if that makes any difference 2022-07-31 03:02:17 you have xf86-input-libinput installed, right? 2022-07-31 03:03:19 yes 2022-07-31 03:03:39 vim zsh xfce4 xfce4-terminal xfce4-screensaver lightdm lightdm-gtk-greeter dbus udev xorg-server xf86-input-libinput eudev mesa xf86-video-modesetting xf86-video-qxl xf86-input-evdev xf86-input-vmmouse 2022-07-31 03:03:44 this is what i have installed 2022-07-31 03:04:02 + alpine standard stuff 2022-07-31 03:09:23 vmmouse is for vmware 2022-07-31 03:10:17 i installed just in case, because i dont have any more ideas on how to make this work 2022-07-31 03:10:38 log in via ssh and check logs 2022-07-31 03:31:43 (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (Error loading shared library /usr/lib/xorg/modules/dri/swrast_dri.so: No such file or directory) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) If no devices become available, reconfigure udev or disable AutoAddDevices. 2022-07-31 03:31:51 these are the weird things from Xorg.log.0 2022-07-31 03:43:47 yes!!! i got it working 2022-07-31 03:44:00 i just needed to run setup-devd udev 2022-07-31 11:09:45 perhaps the setup-desktop script should install mesa-dri-gallium because there is no case where you don't want it lol 2022-07-31 13:44:37 hello again, now my alpine custom iso is working normally, but when i try installing it into a qcow2 image it says "No space left on device", even though I just created it, and it has 32GB 2022-07-31 13:44:41 How would you like to use it? ('sys', 'data', 'crypt', 'lvm' or '?' for help) [?] sys 2022-07-31 13:44:43 ERROR: Failed to create usr/share/syslinux/syslinux.exe: No space left on device 2022-07-31 13:44:45 ERROR: syslinux-6.04_pre1-r11: No space left on device 2022-07-31 13:46:11 This is the qemu command: qemu-system-x86_64 -enable-kvm -m 1024 -cdrom alpine-myprofile-edge-x86_64.iso -net user,hostfwd=tcp::2222-:22 -net nic -hda test.qcow2 2022-07-31 14:10:09 > syslinux.exe 2022-07-31 14:10:31 i think setup-alpine might not be installing it directly into the qcow2, but in the iso tmpfs first (?) and then copying to the hard drive. and thats why it says no space left. but then how could i reserve more space to the iso (?) so that it wont run out? 2022-07-31 14:11:09 It's using tmpfs, which is in memroy 2022-07-31 14:11:11 you are correct that it does not install it directly onto the storage 2022-07-31 14:11:12 memory 2022-07-31 14:11:38 If the files you want to install are larger then 1024M - used ram, you need to increase the memory 2022-07-31 14:12:10 i will try increasing to 2048M 2022-07-31 14:14:20 you may also want to apk add linux-firmware-none 2022-07-31 14:18:30 o/ 2022-07-31 14:18:56 it worked now! thanks everyone 2022-07-31 14:19:06 how do you all unpack the new apk format? the old one was .tar.xz but this one screws with the tar format 2022-07-31 14:19:48 it definitely wasn't tar.xz 2022-07-31 14:20:12 the v2 one is tar.gz 2022-07-31 14:20:17 the v3 one is custom 2022-07-31 14:20:41 idr tar.xz or gz, circa 2017 2022-07-31 14:21:05 currently we use tar.gz as apkv3 is not out yet 2022-07-31 14:21:56 is there some command bundled with apk-tools to unpack apks? I have one from third-party and I wanna verify its install hooks 2022-07-31 14:22:20 I believe I have a v2 apk yeah 2022-07-31 14:22:38 tar zxvf file.apk 2022-07-31 14:22:59 I tried `cat`ing the tar to an empty tar archive to restore the null records but that didn't work 2022-07-31 14:23:35 i'm pretty sure cat'ing a file into another file is just `cp` 2022-07-31 14:24:32 what 2022-07-31 14:24:37 cat a b > c 2022-07-31 14:25:06 that is very different from the previous sentence :) 2022-07-31 14:25:17 ikke: could i just change all the shellcheck rules 2022-07-31 14:25:21 omg the pedantry, i suppose the correct word is cat with 2022-07-31 14:25:25 :P 2022-07-31 14:25:58 anyway, believe it or not, `tar xzf the.apk` that's the first thing i tried 2022-07-31 14:26:08 psykose: What do you want to do? 2022-07-31 14:26:24 hazem: and what is the problem? 2022-07-31 14:26:24 see if it's possible to do the inverse of what it does now 2022-07-31 14:26:30 could we just remove shellcheck 2022-07-31 14:26:31 enable specific things 2022-07-31 14:26:39 because currently half the flags are useless 2022-07-31 14:27:10 panekj: tar: This does not look like a tar archive 2022-07-31 14:28:04 I remember I disabled some of the rules in aports because... 2022-07-31 14:28:10 i just ran `tar -xzf some.apk` and it worked 2022-07-31 14:28:11 (for my own git repo :P) 2022-07-31 14:28:29 hazem: apk is borked 2022-07-31 14:28:32 or it's not proper apk 2022-07-31 14:28:36 Many rules are context sensitive and it takes a brain to determine whether it applies or not 2022-07-31 14:28:49 stuff is still built with abuild so whatever apkv3 uses doesn't matter 2022-07-31 14:28:54 indeed 2022-07-31 14:28:56 curious, because apk itself can work with it fine 2022-07-31 14:29:08 can u run `file` on it 2022-07-31 14:29:14 (i just yolo'd and installed it) 2022-07-31 14:29:36 appropriate reaction to software of unknown origin 2022-07-31 14:30:26 psykose: the first layer is a proper gzip and the second layer: POSIX tar archive, file .PKGINFO, mode 0000644, uid 0000000, gid 0000000, size 00000000444, seconds 14200033201 2022-07-31 14:30:37 ikke: if you want my honesty i just found it funny it flags a very ordinary shell trick with 3 separate lints at once, haha 2022-07-31 14:30:47 hazem: wow, looks like tar -xzf would extract that just fine! 2022-07-31 14:31:02 wow but it doesn't! 2022-07-31 14:31:10 maybe borked tar 2022-07-31 14:31:22 can u take a smartphone screen recording of u running `tar -xzf that.apk` 2022-07-31 14:31:41 > assuming im on phone 2022-07-31 14:31:46 shell=/bin/ash 2022-07-31 14:31:48 the relevant file is this 2022-07-31 14:31:49 no, using the camera 2022-07-31 14:31:52 disable=SC2034,SC2154 2022-07-31 14:32:00 https://github.com/koka-lang/koka/releases/download/v2.4.0/koka-v2.4.0-alpine-x64.apk 2022-07-31 14:32:14 it's a pitty shellcheck does not have native ash support 2022-07-31 14:32:17 tbf it's from a "trusted" source 2022-07-31 14:32:18 so you need to teach ti 2022-07-31 14:32:24 so I didn't mind yoloing 2022-07-31 14:32:36 re "appropriate reaction" 2022-07-31 14:32:51 I didn't deep dived aports for finding more useless rules (: 2022-07-31 14:33:45 koka-v2.4.0-alpine-x64.apk: gzip compressed data, last modified: Sun Feb 6 20:58:42 2022, from Unix, original size modulo 2^32 161149952 2022-07-31 14:34:15 keep going.. 2022-07-31 14:34:29 the tar is broken 2022-07-31 14:34:35 you cant even run tar -xf on the .tar inside 2022-07-31 14:34:47 wild, i know 2022-07-31 14:35:03 seems like apk doesn't mind borked tarballs 2022-07-31 14:35:37 seems so, there's also talk in the wiki about how apk modifies the tar a little bit 2022-07-31 14:35:44 to allow concatenation 2022-07-31 14:35:58 no, if you apk fetch a random thing you can run tar -xzf on it 2022-07-31 14:36:01 so IDK if it's broken or an effect of that 2022-07-31 14:36:04 this specifically is just a broken tar 2022-07-31 14:36:35 would be nice to have `apk unpack` command for this in general (and the custom V3 format when it lands) 2022-07-31 14:37:01 Since when apkv3 is supposed to have custom format for .apk? 2022-07-31 14:37:18 echoing what's said earlier 2022-07-31 14:37:25 I'm asking psykose 2022-07-31 14:37:41 panekj: apkv3 2022-07-31 14:37:45 since always 2022-07-31 14:37:46 yes 2022-07-31 14:37:50 unless i jumped realities again 2022-07-31 14:37:51 ACTION thinks 2022-07-31 14:38:09 I wonder if maintainers are receptive to patches to apk-tools 2022-07-31 14:38:14 ikke: yes, the apkv3 will have apkv3 format 2022-07-31 14:38:26 ACTION the floor here is made out of the floor 2022-07-31 14:38:39 panekj: I mean, since apv3, it was the goal to have a custom format 2022-07-31 14:39:40 great 2022-07-31 14:39:49 Since that was the reason to bump to 3 rather than stay on v2 2022-07-31 14:40:19 btw. you don't want to know how koka builds package for alpine 2022-07-31 14:40:28 spoiler: ew 2022-07-31 14:40:35 hazem: they have been accepting merge requests: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests?scope=all&state=merged 2022-07-31 14:43:06 psykose: panekj it might make sense to reconsider the shellcheck rules, since shellcheck itself also changed quite a bit since we added it 2022-07-31 14:43:51 i dunno, i just think it's better if it enforces things that are consistently wrong 2022-07-31 14:44:05 I tried integrating it once in repo for building GitHub Actions runners and 99% of time, shellcheck is useless 2022-07-31 14:47:46 shell has lots of gotchas, and shellcheck at least makes you aware of them, even if they don't apply in that specific situation (because shellcheck cannot know whether it does or not) 2022-07-31 14:48:02 I know 2022-07-31 14:48:35 but, IMO, shellcheck is much more usefull if you disable all and whitelist specificc common mistakes 2022-07-31 14:48:44 To be effective, you kind of have to write with shellcheck in mind 2022-07-31 14:52:52 get rid of /bin/*sh*, shells are a mistake 2022-07-31 14:53:20 That's a different discussion :) 2022-07-31 14:53:28 one that is already taking place for years 2022-07-31 14:53:49 For now, that's what we have 2022-07-31 14:54:06 APKBUILD.lua? :P 2022-07-31 14:54:16 n please 2022-07-31 14:54:18 no please* 2022-07-31 14:56:32 >get rid of shells 2022-07-31 14:56:35 >likes melange 2022-07-31 14:56:40 >entire thing is just shell but in snippets 2022-07-31 14:56:41 hmmmmmmm 2022-07-31 14:56:55 you haven't seen my tweet where I praised YAML 2022-07-31 14:56:59 i have 2022-07-31 14:57:02 o 2022-07-31 14:57:05 (: 2022-07-31 14:57:51 I think Ariadne is waiting for cuelang to be considered production ready 2022-07-31 14:57:57 https://cuelang.org/ 2022-07-31 14:58:06 building things out of blocks is better than rewriting same things in all files 2022-07-31 14:58:19 panekj: yes and no 2022-07-31 14:58:38 sometimes yes, sometimes no 2022-07-31 14:58:47 it may and may not be 2022-07-31 14:59:13 i don't think it is realistic to convert alpine to use melange 2022-07-31 14:59:25 also, some of the melange pipelines are too inflexible 2022-07-31 14:59:26 re: cue, no rust bindings :( 2022-07-31 15:00:08 gentoo's eclasses come to mind 2022-07-31 15:00:14 the best part of pipelines is they expose the internals 2022-07-31 15:00:31 instead of relying on whatever abuild has defined and optionally overriding the function, it's just the pipeline 2022-07-31 15:00:32 melange pipelines are literally the opposite of eclasses 2022-07-31 15:00:33 aside from that, yeah 2022-07-31 15:01:27 eclasses: you import them and then ✨ stuff happens ✨ 2022-07-31 15:01:36 melange pipelines: you have to ask for them explicitly 2022-07-31 15:01:54 for instance default fetch also unpacks https://github.com/chainguard-dev/melange/blob/main/pipelines/fetch.yaml and it can't work on anything but .tar.gz, but this is obvious and you can write your own pipeline 2022-07-31 15:02:05 in abuild you have to override unpack() and guess where the directories are 2022-07-31 15:02:27 it's both shell and more or less the same, just composed differently 2022-07-31 15:02:43 (and nothing like eclasses) 2022-07-31 15:02:44 (improving the fetch pipeline is welcome of course) 2022-07-31 15:03:03 it can be improved to not be limited to tar.gz only :P 2022-07-31 15:03:30 (improvement 1: make it curl /s) 2022-07-31 15:03:48 technically with busybox tar, it supports anything busybox itself supports out of the box 2022-07-31 15:03:54 because its all libarchive under the hood :p 2022-07-31 15:04:08 I've dabbled into melange pipelines, but didn't have time to upstream 2022-07-31 15:04:15 `busybox tar -zxf` fails on .xz 2022-07-31 15:04:20 if you remove the -z it does though 2022-07-31 15:04:21 haha 2022-07-31 15:05:06 anyway there are pros and cons to both approaches 2022-07-31 15:05:10 personally never saw much point of needing the specific -z -J whatnot flags as both libarchive and gnu tar can do a lot of autodetection 2022-07-31 15:05:20 habit 2022-07-31 15:05:22 for me 2022-07-31 15:05:37 the gnu one works with zst too iirc, didn't test libarchive 2022-07-31 15:06:34 melange was also designed to integrate into a platform that is already pipeline-oriented 2022-07-31 15:06:44 e.g. tekton 2022-07-31 15:07:05 so having something that matched the mental model users were already used to was a primary goal 2022-07-31 15:09:09 how many melanges are out there these days 2022-07-31 15:09:20 there's the one for alpine 2022-07-31 15:09:28 there's the bucklescript fork 2022-07-31 15:10:15 there's the language workbench 2022-07-31 15:24:33 melange is not "for alpine" 2022-07-31 15:49:32 is there a reason why setup-alpine does this? 2022-07-31 15:49:34 $MOCK openrc boot 2022-07-31 15:49:35 $MOCK openrc default 2022-07-31 15:49:51 are these services not already started when i booted the iso? 2022-07-31 15:50:42 they add some extra ones before this line, but then why not start them individually without restarting the whole thing? 2022-07-31 15:51:13 it makes lightdm restart too in my case, stopping the setup if ran outside a tty 2022-07-31 18:47:55 i commented out these lines in setup-alpine and it still works, but now without restarting lightdm, which allows me to install from a terminal in the X session. 2022-07-31 18:47:57 # start up the services 2022-07-31 18:47:58 $MOCK openrc boot 2022-07-31 18:48:00 $MOCK openrc default 2022-07-31 18:49:01 is there a reason they're there? or can i get rid of them in my custom iso without worries 2022-07-31 18:54:22 could open an issue in alpine-conf 2022-07-31 18:55:58 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues 2022-07-31 18:57:18 also, what is this $MOCK thing anyways? i see it all around the script but it is undefined it seems 2022-07-31 18:57:43 maybe i could replace it with something like echo to ignore the openrc lines 2022-07-31 18:57:53 and without modifying the script 2022-07-31 18:57:53 user2: For testing purposes 2022-07-31 18:58:27 so overwriting it shouldnt be a problem 2022-07-31 18:59:23 the other scripts that get called after use MOCK for even more things 2022-07-31 18:59:40 you'll more or less install nothing if you call setup-alpine with MOCK=echo or whatever 2022-07-31 19:00:00 MOCK=checkifopenrc setup-alpine 2022-07-31 19:00:13 then i export a function that checks if next parameter is openrc ? 2022-07-31 19:00:19 patching two lines sounds much easier 2022-07-31 19:00:50 it seems that /sbin is not writeable from the genapkovl script, im still testing though 2022-07-31 19:16:17 it seems that /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin are not writeable from genapkovl script. i will try one more time just in case, but idk 2022-07-31 19:16:28 where else would i put my scripts 2022-07-31 20:30:19 hm, for some reason clang on riscv cannot use -flto 2022-07-31 20:30:30 no lto is fine, gcc is fine with any options 2022-07-31 20:31:38 error is quite meaningless, though it does point to things 2022-07-31 20:31:42 /usr/bin/ld: /tmp/lto-llvm-053b83.o: can't link soft-float modules with double-float modules 2022-07-31 20:32:05 save-temps'ing the object and reading it with readelf -h has the double-float ABI flag missing 2022-07-31 20:32:12 not sure why that would happen in lto mode only 2022-07-31 20:33:07 (every object everywhere has that flag with gcc or without lto at any phase of anything) 2022-07-31 20:35:01 not gcc 12 right 2022-07-31 20:35:24 11 2022-07-31 20:35:37 but i mean it works fine, clearly some weird clang bug 2022-07-31 20:35:46 strangely i can't find anything wrong reading any part of clang.. 2022-07-31 20:36:06 it must mean it doesn't use -mabi=lp64d with -flto and instead just lp64, but why 2022-07-31 20:36:16 oh ok, I asked b/c of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106129 2022-07-31 20:36:18 well, passing -mabi=lp64d actually doesn't fix it 2022-07-31 20:36:22 (options got dropped for LTO sometimes) 2022-07-31 20:36:37 oh wow, not even fixed in 12.1.1 2022-07-31 20:36:49 but yeah looks like unrelated breakage of mostly the same thing 2022-07-31 20:36:57 this is definitely clang/llvm specific 2022-07-31 20:37:25 i found this out because i am trying to build firefox on riscv, don't ask 2022-07-31 20:37:43 (all the dependencies are now satisfied) 2022-07-31 20:38:01 i can also try without lto i guess 2022-07-31 20:40:47 you have a riscv processor? 2022-07-31 20:41:00 nah, just emulation 2022-07-31 20:41:10 oh ok 2022-07-31 20:44:39 sam_: do you know how to even look into that fortify thing more, since it seems like more of a gcc bug now 2022-07-31 21:41:35 just found out about login.d 2022-07-31 21:41:38 that thing is a life saver 2022-07-31 21:41:51 now i can "bypass" all the restrictions from the genapkovl file 2022-07-31 23:52:59 oops i meant local.d