2022-07-01 03:05:39 <rbq> 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 <psykose> dunno
2022-07-01 03:06:17 <psykose> not the pre release
2022-07-01 03:06:53 <rbq> Ok, I'll try 8.6.11 then, I have a feeling it will start failing there
2022-07-01 03:17:38 <rbq> Yes, the tests fail on 8.6.11
2022-07-01 03:22:56 <psykose> looks like a bunch of rounding math stuff so have fun :)
2022-07-01 03:23:47 <rbq> Yes, not fun, which is why I've been procrastinating for the past month
2022-07-01 05:46:04 <craftyguy> 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 <craftyguy> 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 <psykose> you can open a tsc issue i think
2022-07-01 05:59:25 <craftyguy> 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 <psykose> my other secret is also that i just build the newest mesa myself for my own use /s
2022-07-01 06:09:41 <ikke> Don't think the tsc needs to decide on this. 
2022-07-01 06:11:48 <craftyguy> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/51
2022-07-01 06:12:02 <craftyguy> ah, just in time for ikke to NACK the idea of filing an issue there :D
2022-07-01 06:16:02 <craftyguy> 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 <ddevault> why is alpinelinux.org behind cloudflare?
2022-07-01 06:35:18 <psykose> is it? the ip address is just equinix
2022-07-01 06:47:59 <ikke> Yeah, we don't use cloudflare 
2022-07-01 06:48:23 <rbq> psykose: I think I have the patch that makes tcl-lib math tests pass on x86
2022-07-01 06:48:47 <psykose> fantastic
2022-07-01 07:00:07 <ddevault> ah, I was looking at older information
2022-07-01 07:00:14 <ddevault> good :)
2022-07-01 07:11:02 <rbq> ...and the tcl-lib math tests now complete successfully on x86
2022-07-01 07:27:52 <rbq> and now to run the full tcl and tcl-lib testsuit to see if anything else breaks
2022-07-01 08:29:17 <donoban> I saw that Jakub added wolfssl, could it be an openssl replacement?
2022-07-01 10:04:33 <skarnet> 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 <Habbie> wolfssl does have a compatibility layer; i have no idea how good it is
2022-07-01 10:05:08 <Habbie> 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 <donoban> the reason for alpine going back with libressl was the porting work more that libressl itself?
2022-07-01 10:07:43 <donoban> s/that/than
2022-07-01 10:07:43 <alpine-meetbot> 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 <ikke> Libressl was making breaking changes 
2022-07-01 10:22:23 <ikke> There is a thread on the mailing list about it 
2022-07-01 10:24:52 <donoban> ah I see, thanks
2022-07-01 10:55:01 <Ermine> There was discussion at TSC about ssl libraries. Do you want to review that decision?
2022-07-01 11:09:38 <Piraty> eschwartz: very mild speed up. lol
2022-07-01 11:19:26 <eschwartz> Piraty: don't turn down free CPU cycles!
2022-07-01 11:20:06 <eschwartz> 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 <Piraty> good luck on your which hunt
2022-07-01 11:43:43 <minimal> 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 <elibrokeit> minimal: grub the software, not grub the alpine package.
2022-07-01 13:05:49 <elibrokeit> (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 <elibrokeit> 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 <skarnet> most uses of which can be replaced with type
2022-07-01 13:35:11 <Hello71> most uses of which can be replaced by just running the command
2022-07-01 13:36:13 <skarnet> do people use which when they need to actually run the command?
2022-07-01 13:40:49 <Hello71> 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 <Hello71> stick a -9 on the end
2022-07-01 13:52:14 <elibrokeit> 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 <elibrokeit> 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 <elibrokeit> 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 <orbea> 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 <Hello71> without -a, is this the same as command -v
2022-07-01 14:11:50 <orbea> 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 <elibrokeit> you could also just vendor debian's `which` shellscript
2022-07-01 14:12:38 <elibrokeit> or convince the Austin group to standardize type -P
2022-07-01 14:14:13 <orbea> its been a while since I looked, but I recall yash and zsh having the best command implementations
2022-07-01 14:14:38 <orbea> maybe mksh too
2022-07-01 14:14:58 <panekj> isn't this basically `type`
2022-07-01 14:16:14 <orbea> type tells you what it is, not exclusively where it is and if it exists
2022-07-01 14:18:12 <orbea> 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 <orbea> built-in*
2022-07-01 14:20:03 <panekj> type -P seems to *exclusively* tell you the path
2022-07-01 14:22:03 <orbea> that is not in posix though
2022-07-01 14:22:41 <orbea> https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/type.html
2022-07-01 14:26:28 <Hello71> /bin/sh -c 'command -v "$1"' --?
2022-07-01 14:27:10 <Hello71> hm, builtins.
2022-07-01 14:27:18 <orbea> and aliases
2022-07-01 14:27:40 <panekj> posix sucks
2022-07-01 14:28:09 <orbea> https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/command.html
2022-07-01 14:28:23 <Hello71> well sh -c would avoid aliases
2022-07-01 14:30:10 <orbea> 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 <panekj> it is an annoying problem which is why I use fish and limit POSIX things to bare minimum
2022-07-01 14:38:44 <elibrokeit> 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 <elibrokeit> in 9% of cases, just use `command foo` and check if it fails; it suppresses alias/function lookup
2022-07-01 14:39:41 <orbea> the problem is when you are using scripts that might be used on other systems
2022-07-01 14:39:56 <elibrokeit> 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 <elibrokeit> this is not about which systems you use
2022-07-01 14:40:34 <orbea> 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 <elibrokeit> using scripts on other systems won't magically cause new aliases/functions to appear in your script 
2022-07-01 14:41:35 <panekj> I wholeheartedly do not recommend using bash, ever
2022-07-01 14:41:50 <orbea> ^
2022-07-01 14:42:13 <orbea> probably still not fixed, but I havent checked recently... https://termbin.com/eyfq
2022-07-01 14:42:14 <panekj> and I will write completely POSIX script just to avoid bash(isms)
2022-07-01 14:42:21 <orbea> same :P
2022-07-01 14:42:51 <elibrokeit> 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 <elibrokeit> 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 <orbea> 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 <elibrokeit> yes but clearly that isn't the interactive use case
2022-07-01 14:47:00 <elibrokeit> 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 <orbea> i do have -a in my script
2022-07-01 14:50:56 <elibrokeit> type -a, not which -a
2022-07-01 14:51:42 <elibrokeit> > you actually do require seeing both aliases and PATH and nothing, not [...] orbea which [...] does this
2022-07-01 14:53:08 <orbea> type -a is not posix
2022-07-01 14:53:49 <orbea> and the goal was to not see builtins or aliases, different usecase :)
2022-07-01 14:57:10 <elibrokeit> i am aware it is not posix 
2022-07-01 14:57:36 <elibrokeit> 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 <elibrokeit> 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 <elibrokeit> (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 <eddsalkield_> 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 <panekj> currently no, because there isn't even a special phase for fetch source after default_prepare
2022-07-01 19:37:27 <ikke> doesn't mean you cannot do it in the prepare phase
2022-07-01 19:37:36 <ikke> though, it doesn't help with rootbld
2022-07-01 19:38:01 <ikke> eddsalkield_: I haven't seen any packages do that yet for go
2022-07-01 19:38:13 <panekj> no packages do that
2022-07-01 19:38:35 <panekj> it was started in rust packages due to jirutka MR in abuild
2022-07-01 19:38:50 <panekj> and I mentioned that it could be done for Go as well, but I forgot to push it
2022-07-01 19:39:00 <ikke> yes, and I have been looking at that myself for go as well
2022-07-01 19:39:15 <panekj> I have it already written on one of my machines, just need to find
2022-07-01 19:40:25 <ikke> What command do you use to fetch just the modules?
2022-07-01 19:42:43 <panekj> ikke: go mod download, eventually go get for non-module go packages
2022-07-01 19:42:55 <ikke> right
2022-07-01 19:45:02 <ikke> Sadly, there is no phase yet after unpackage that still has net in roobld
2022-07-01 19:46:29 <panekj> wouldn't it be just running bwrap twice
2022-07-01 20:27:43 <ikke> patching gitlab in a couple of minutes
2022-07-01 20:31:27 <Thermi> Oh no wonder it didn't work for me right now
2022-07-01 20:31:59 <ikke> It's upgrading
2022-07-01 20:34:17 <ikke> And it's back
2022-07-01 21:17:32 <eddsalkield_> okay, I'll just push the package as it is right now
2022-07-01 21:18:19 <eddsalkield_> 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 <ikke> rootbld would require changes to apkbuild
2022-07-01 21:21:05 <ikke> but doesn't mean you can download the modules in the prepare() phase
2022-07-01 21:21:10 <ikke> you cannot*
2022-07-01 21:23:25 <eddsalkield_> so `go mod download` in prepare(), and `go build` in build()?
2022-07-01 21:23:44 <eddsalkield_> what changes would need to be made to support building in rootbld?
2022-07-01 21:27:46 <panekj> we need a new phase between prepare and build
2022-07-01 21:27:52 <panekj> that fetches stuff again
2022-07-01 21:29:03 <panekj> 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 <Ariadne> panekj: if only package building were an arbitrary pipeline :p
2022-07-02 11:41:33 <panekj> mhmm (:
2022-07-02 15:51:38 <ikke> Hmm, I might have found the solution for the errors we sometimes get when applying labels to issues
2022-07-02 15:58:48 <psykose> what is it
2022-07-02 15:59:18 <ikke> Apparently some poorly documented config file missing
2022-07-02 15:59:59 <ikke> https://docs.gitlab.com/omnibus/settings/actioncable.html
2022-07-02 16:00:16 <ikke> Added it in our test installation, and cannot trigger it anymore
2022-07-02 16:01:04 <psykose> how is some worker pool size related to issue labels
2022-07-02 16:01:14 <ikke> It's not the worker pool size
2022-07-02 16:01:44 <ikke> It configures a backend for those 'cables'
2022-07-02 16:02:29 <psykose> what i mean the only thing on that entire page is `actioncable['worker_pool_size']`
2022-07-02 16:02:38 <ikke> yes, that's why I say poorly documented
2022-07-02 16:02:40 <psykose> heh
2022-07-02 16:02:41 <ikke> https://gitlab.com/gitlab-org/gitlab/-/blob/335007-fix-pipeline-status-stuck/config/cable.yml.example
2022-07-02 16:03:53 <ikke> I just used that file and adopted it
2022-07-03 12:58:23 <ikke> Upgrading gitlab and upgrading host to 3.16 
2022-07-03 13:00:10 <psykose> ~
2022-07-03 13:00:41 <psykose> does this finally come with those permission user ci rebase issue whatever fixes
2022-07-03 13:04:53 <ikke> I suppose so
2022-07-03 13:06:27 <ikke> ok, done, gitlab has been upgraded
2022-07-03 14:33:09 <ikke> ncopa: nlplug-findfs: Skipping message due to size=18446744073709551615
2022-07-03 15:01:11 <psykose> that's a u64 underflow
2022-07-03 15:02:13 <ikke> right
2022-07-03 15:02:30 <ikke> That's what's happening on usa7, preventing it to boot automatically
2022-07-03 15:41:48 <Ermine> psykose: is it kernel bug?
2022-07-03 15:43:07 <ikke> It did start to happen after linux 5.10
2022-07-03 15:43:25 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325
2022-07-03 16:02:22 <psykose> the code does size_t len = recvmsg(.. but recvmsg returns ssize_t
2022-07-03 16:02:51 <psykose> so for it to wrap the %zu it has to have -1 returned on error
2022-07-03 16:03:33 <psykose> is unsigned < 0 legal? :p
2022-07-03 16:03:52 <Habbie> evaluates to false
2022-07-03 16:04:02 <psykose> relevant code https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs/nlplug-findfs.c#L1393
2022-07-03 16:05:35 <psykose> gonna guess the real error is obscured as errno is not printed (warnx doesn't)
2022-07-03 16:06:17 <psykose> 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 <ikke> 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 <ikke> And there is no install target
2022-07-03 20:45:43 <psykose> generally you would need to add all of those yourself, i guess
2022-07-03 20:46:10 <ikke> The symlinks?
2022-07-03 20:48:10 <psykose> manually adding the -Wl soname, copying the .so to .so.1, symlinking it back
2022-07-03 20:48:21 <psykose> 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 <psykose> or well, i'm saying that, but most of the time nothing ends up using these anyway
2022-07-03 21:49:57 <elibrokeit> 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 <skarnet> sounds like a lot of discussion has to happen with upstream
2022-07-03 22:44:01 <ptrc> 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 <panekj> 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 <ptrc> 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 <elibrokeit> well, it also "builds" by running a bash script that creates linux, macos, Windows, and Alpine binaries.
2022-07-03 22:50:12 <panekj> it still applies for build process, it should use system node
2022-07-03 22:50:16 <elibrokeit> which seems a bit ridiculous :p
2022-07-03 22:50:24 <elibrokeit> I'd just patch out that build.sh
2022-07-03 22:51:06 <panekj> I'd say, remove it
2022-07-03 22:51:14 <panekj> it has been in testing for 2 years
2022-07-03 22:51:29 <panekj> clearly maintainer doesn't care about it
2022-07-03 22:51:34 <ptrc> that, and it doesn't build anymore with latest npm anyway
2022-07-03 22:51:46 <panekj> just move it to unmaintained
2022-07-03 22:51:49 <ptrc> 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 <panekj> last release was in 2020
2022-07-03 22:55:14 <panekj> we should probably go through whole testing and kick everything that wasn't  updated for a long time
2022-07-03 22:55:19 <ptrc> panekj: there was a "beta" released 3 days ago, that's why i even noticed this package
2022-07-03 22:56:36 <panekj> right
2022-07-03 22:57:14 <vbranni[m]>  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 <panekj> great
2022-07-03 22:59:27 <psykose> telegraph? did we go back in time?
2022-07-03 22:59:33 <vbranni[m]>  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 <panekj> I guess we're going +r again
2022-07-03 23:01:08 <skarnet> why, aren't you interested?
2022-07-03 23:01:21 <skarnet> this is such an incredible offer
2022-07-03 23:02:01 <panekj> I don't know how to send a telegraph unfortunately
2022-07-03 23:03:06 <psykose> i'd rather move to libera entirely if it's +r again
2022-07-03 23:07:17 <elibrokeit> has telegram the chat app now gone lo-tech for the nostalgia?
2022-07-03 23:07:25 <elibrokeit> fascinating
2022-07-03 23:11:19 <vbranni[m]>  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 <Hello71> - . .-.. .-.. / -- . / -- --- .-. .
2022-07-04 07:37:44 <ncopa> morning! ikke: good catch!
2022-07-04 07:41:24 <ikke> The added warning helped :-) 
2022-07-04 07:41:57 <ikke> You can reproduce it on usa7
2022-07-04 09:26:29 <ncopa> usa7-dev1 [~]# ./nlplug-findfs 
2022-07-04 09:26:29 <ncopa> nlplug-findfs: recvmsg: No buffer space available
2022-07-04 09:46:18 <ikke> ncopa: so the local buffer is too small?
2022-07-04 10:08:59 <ncopa> apparently so
2022-07-04 10:09:15 <Daaanct12> good morning all
2022-07-04 10:09:15 <ncopa> im increasing it
2022-07-04 10:09:32 <ncopa> Daaanct12: morning
2022-07-04 10:10:51 <ncopa> 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 <ncopa> we could also refactor it to a separate message queue in userspace in a separate thread
2022-07-04 10:11:44 <ncopa> eg a separate pthread that only reads the kernel messages and add them to a fifo queue
2022-07-04 10:12:10 <ncopa> and have a separate thread to get the messages from that queue and handle them
2022-07-04 10:12:20 <ncopa> i believe that is what udev does
2022-07-04 10:14:00 <ncopa> 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 <ncopa> https://tpaste.us/qaJB
2022-07-04 10:16:15 <ncopa> might be an idea to have it configurable though
2022-07-04 10:16:26 <ncopa> so we dont need to recompile next time we hit the limit
2022-07-04 10:59:13 <skarnet> 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 <skarnet> 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 <skarnet> so the kernel-side storage looks pretty inefficient :/
2022-07-04 11:26:32 <fcolista> 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 <skarnet> echo something at the start of your .profile?
2022-07-04 11:28:26 <fcolista> did it
2022-07-04 11:28:37 <skarnet> nothing printed?
2022-07-04 11:28:39 <fcolista> just a simple "export PROFILE=1"
2022-07-04 11:28:44 <fcolista> then env does not report anything
2022-07-04 11:29:07 <panekj> or touch ~/test (:
2022-07-04 11:29:46 <fcolista> i mean if there's DEBUG=3 /bin/ash or something like that
2022-07-04 11:30:08 <ikke> fcolista: are you sure you are using a login shell? 
2022-07-04 11:30:20 <ikke> It's only sourced for login shells. 
2022-07-04 11:30:23 <fcolista> cat /etc/passwd returns /bin/ash
2022-07-04 11:30:28 <fcolista> for my user
2022-07-04 11:30:56 <panekj> is that on your pc, ssh, or something else?
2022-07-04 11:31:01 <fcolista> my pc
2022-07-04 11:31:17 <ikke> strace -e openat ash -l
2022-07-04 11:31:31 <fcolista> thx ike
2022-07-04 11:31:32 <fcolista> ikke, 
2022-07-04 11:31:39 <fcolista> that's what I was looking for
2022-07-04 11:31:51 <skarnet> always the subtle solutions
2022-07-04 11:32:35 <fcolista> eheh
2022-07-04 13:08:24 <macmpi> Hi. Having an issue compiling Bluez from github repo (allows to get snapshot for a given commit)
2022-07-04 13:08:54 <panekj> what issue
2022-07-04 13:09:18 <macmpi> ln: unrecognized option: t
2022-07-04 13:09:33 <macmpi> as per https://gitlab.alpinelinux.org/macmpi/aports/-/jobs/758911#L436
2022-07-04 13:10:17 <panekj> needs coreutils
2022-07-04 13:11:03 <macmpi> my changes: https://gitlab.alpinelinux.org/macmpi/aports/-/merge_requests/9/diffs
2022-07-04 13:11:28 <panekj> you need coreutils package in makedepends
2022-07-04 13:12:34 <panekj> or patch whatever it does to not use -t
2022-07-04 13:13:20 <macmpi> just wondering why this does not happen with scm releases
2022-07-04 13:13:53 <macmpi> I have same issue trying to compile plain 5.64 release from github
2022-07-04 13:14:38 <macmpi> while recompiling 5.64 from scm works just fine
2022-07-04 13:17:04 <panekj> probably something changed in build environment
2022-07-04 13:17:28 <psykose> diff them and find out
2022-07-04 13:17:49 <panekj> meant CI
2022-07-04 13:18:20 <panekj> oh wait
2022-07-04 13:18:28 <panekj> you replaced source from kernel with source from github
2022-07-04 13:18:49 <panekj> they probably don't bother making scripts POSIX
2022-07-04 13:18:59 <psykose> it's the same project
2022-07-04 13:19:12 <panekj> tarball source is different
2022-07-04 13:19:39 <panekj> ¯\_(ツ)_/¯
2022-07-04 13:22:17 <macmpi> 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 <macmpi> making a bit of progress thanks
2022-07-04 13:24:56 <panekj> does it work locally?
2022-07-04 13:26:52 <macmpi> don't have a dev machine sety-up locally: just using gitlab build automation for now
2022-07-04 13:28:52 <macmpi> hum... seems like --enable-external-ell option did the trick (except on s390x)
2022-07-04 13:29:17 <macmpi> will test artifacts to be sure
2022-07-04 13:46:52 <psykose> 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 <staceee> 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 <staceee> how to detect things that I can safely remove from world
2022-07-04 14:00:54 <staceee> arf now I'm not even sure about .makedepends virtual package goal
2022-07-04 14:01:27 <ikke> What is it that you want to achieve? 
2022-07-04 14:01:27 <psykose> tl;dr no easy way
2022-07-04 14:01:40 <psykose> but generally you can comb through the list and remove anything you don't use
2022-07-04 14:01:51 <panekj> most likely anything -dev
2022-07-04 14:01:57 <psykose> anything that ends in -dev or whatever you don't need, etc
2022-07-04 14:03:20 <staceee> ah okay, abuild -r use --virtual .makedepends-shit with all makedepends packages names
2022-07-04 14:03:34 <staceee> so I cant just add --virtual .makedepends-shit
2022-07-04 14:03:54 <staceee> but I now can name virtual package to uninstall everything when I drop this virtual package
2022-07-04 14:04:44 <panekj> what's the goal?
2022-07-04 14:04:51 <staceee> 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 <panekj> do you want to clean packages after abuild -r?
2022-07-04 14:05:17 <staceee> I'd like not to fill my world with shity dev packages I use only one times :D
2022-07-04 14:05:31 <panekj> if you use abuild, it will clean them after though
2022-07-04 14:05:43 <staceee> when I'm outside of the aport context
2022-07-04 14:06:18 <panekj> I'm still confused
2022-07-04 14:06:22 <staceee> apk info -R .shit-bemenu give me the list of packages I gave it
2022-07-04 14:06:39 <staceee> yap I understood the -t --virtual apk add argument
2022-07-04 14:07:03 <staceee> panekj: still confused ?
2022-07-04 14:08:17 <panekj> so basically, you just want `abuild undeps`
2022-07-04 14:09:22 <staceee> 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 <staceee> 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 <macmpi> 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 <staceee> but "abuild deps" is also great to know. The nobrain way
2022-07-04 14:13:07 <panekj> I assume the tarballs for kernel.org and github are made different
2022-07-04 14:14:37 <panekj> since github is just autogenerating a repo snapshot and kernel.org source was pre-made tarball
2022-07-04 14:31:35 <donoban> 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 <donoban> 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 <ikke> Atm, this information is not available to apk
2022-07-04 14:40:21 <donoban> yeah I suppose, it should be generated by abuild
2022-07-04 15:11:23 <bl4ckb0ne> psykose: ty for upgrading vkd3d to 1.4
2022-07-04 15:11:27 <psykose> :)
2022-07-04 15:11:36 <bl4ckb0ne> did you pushed the commit directly? I did not receive any mail
2022-07-04 15:11:49 <bl4ckb0ne> lost 10 mins this morning doing the update :<
2022-07-04 15:13:54 <psykose> along with wine yeah
2022-07-04 15:14:47 <bl4ckb0ne> could you ping me next time pls
2022-07-04 15:15:48 <psykose> sure
2022-07-04 15:18:30 <bl4ckb0ne> ty
2022-07-04 17:24:16 <Thermi> Can somebody please move that issue for me? https://gitlab.alpinelinux.org/alpine/aports/-/issues/13266
2022-07-04 17:25:28 <Thermi> 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 <Thermi> (fails as in, does not give the same result as the test at compile time)
2022-07-04 19:53:22 <ikke> Thermi: I replied to the first issue, does not seem to be an apk-tools issue
2022-07-04 20:03:15 <omni> 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 <omni> something with the latest kmod?
2022-07-04 20:03:26 <bl4ckb0ne> got the same today
2022-07-04 20:03:27 <ikke> Haven't seen it yet
2022-07-04 20:03:40 <bl4ckb0ne> havent rebooted yet, mostly out of fear
2022-07-04 20:04:31 <psykose> probably related to kmod as that was the latest change
2022-07-04 20:04:34 <psykose> rebooting works
2022-07-04 20:04:56 <omni> bl4ckb0ne: me neither! :D
2022-07-04 20:05:17 <omni> even though I've got zfs snapshots
2022-07-04 20:05:21 <omni> so perhaps not fear then...
2022-07-04 20:11:42 <psykose> 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 <minimal> omni: yes I noticed the same over the weekend
2022-07-04 20:16:00 <minimal> 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 <psykose> 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 <psykose> (or i'm just lucky)
2022-07-04 20:17:04 <minimal> 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 <minimal> whereas it is already present in /boot/ where the linux-lts/linux-virt package places it
2022-07-04 20:19:02 <minimal> depmod (run by mkinitfs) wants to read it and is warning it is not present
2022-07-04 21:06:21 <minimal> 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 <psykose> makes sense
2022-07-04 21:10:02 <sam_> 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 <sam_> -fno-tree-vectorize is a workaround (for the now-enabled-by-default vectoriser)
2022-07-04 21:10:12 <sam_> https://github.com/openzfs/zfs/issues/13605
2022-07-04 21:13:53 <psykose> interesting
2022-07-04 21:14:06 <psykose> 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 <humm> ncopa: The main/dhcpcd --rundir should be /run/dhcpcd, not /run. That was done in 3154f2947885.
2022-07-04 22:16:03 <minimal> psykose: someone in the archlinuxarm channel also mentioned that depmod warning lol
2022-07-05 01:27:04 <Daanct12> ptrc: if you're the one making !35930, then LGTM
2022-07-05 01:29:32 <psykose> is indeed
2022-07-05 01:31:38 <Daanct12> now the question begs.. when will we get extreme tux racer 0.9
2022-07-05 01:31:43 <Daanct12> https://sourceforge.net/p/extremetuxracer/code/796/tree/trunk/NEWS
2022-07-05 01:33:55 <psykose> probably at '???'
2022-07-05 01:34:03 <psykose> good time if you ask me
2022-07-05 01:54:33 <sam_> it's this decade
2022-07-05 01:55:01 <sam_> also on a date using th
2022-07-05 01:57:49 <psykose> enjoy your date
2022-07-05 01:58:24 <Newbyte> "th"?
2022-07-05 02:03:03 <sam_> Newbyte: it says ??th, which means it's not e.g. "the 2nd", etc
2022-07-05 02:03:33 <Newbyte> hmmm
2022-07-05 02:03:36 <Newbyte> very interesting observation
2022-07-05 06:00:35 <boomanaiden154> 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 <boomanaiden154> 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 <boomanaiden154> (like the qtwebengines) and maybe even electron at some point in the future.
2022-07-05 06:08:39 <boomanaiden154> 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 <ncopa> humm: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28452
2022-07-05 10:18:15 <ikke> ncopa: what about it?
2022-07-05 10:43:33 <omni> ikke: humm commented earlier
2022-07-05 10:43:51 <ikke> oh lol
2022-07-05 10:44:21 <ikke> Didn't interpret it as a username :D
2022-07-05 10:54:32 <omni> (=
2022-07-05 13:29:39 <humm> ncopa: thanks; should have searched for that
2022-07-05 14:59:13 <omni> HRio: XSA-403, XSA-405 & XSA-406 just went public!
2022-07-05 15:01:54 <omni> I'm on it for edge
2022-07-05 15:18:08 <omni> 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 <omni> is there a typo there or is it me having a hard time piecing together what they mean?
2022-07-05 15:23:50 <ikke> Don't you need to apply both?
2022-07-05 15:25:10 <ikke> "
2022-07-05 15:25:12 <ikke> Two different patches are provided for each Xen branch, but only the first
2022-07-05 15:25:14 <ikke> patch will be applied to the official Xen repository for each branch."
2022-07-05 15:25:33 <ikke> So sounds like the 2nd patch is optional and will not be used upstream
2022-07-05 15:25:46 <omni> 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 <ikke> aha, ok
2022-07-05 15:26:58 <omni> right?
2022-07-05 15:54:47 <psykose> 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 <psykose> maybe you have some better workflow than me though :)
2022-07-05 16:00:01 <hello71> maybe if you have a workstation with 128 GB RAM and 9000 Mbps nvme drives
2022-07-05 16:01:25 <psykose> totally forgot i can just get that
2022-07-05 16:01:37 <psykose> thanks! CLOSED FIXED RESOLVED
2022-07-05 16:02:53 <omni> PRIVILEGED WONTFIX
2022-07-05 16:31:39 <boomanaiden154> hello71: Can’t forget the 10gb/s internet connection.
2022-07-05 16:32:25 <boomanaiden154> 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 <boomanaiden154> 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 <psykose> 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 <psykose> also, the current chromium release does not even have a tarball..
2022-07-05 16:39:10 <psykose> https://github.com/archlinux/svntogit-packages/commit/589563cec6ba9e23a67a1470c2da463ecc747e73 :)
2022-07-05 16:39:18 <boomanaiden154> 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 <psykose> and i do not want to snapshot this
2022-07-05 16:41:44 <boomanaiden154> 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 <psykose> sounds about right
2022-07-05 16:53:17 <psykose> also hope i haven't broken anything with the chromium upgrades while you were busy :p
2022-07-05 16:54:12 <psykose> 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 <boomanaiden154> 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 <psykose> seems to have been the only reported issue so far! haven't done much other than rebasing
2022-07-05 17:29:23 <donoban> I'm trying to upgrade & fix a test error on electrum: QSqlDatabase: QSQLITE driver not loaded
2022-07-05 17:29:35 <donoban> it seems that it doesn't have any available driver
2022-07-05 17:30:19 <donoban> maybe just adding sqlite...
2022-07-05 17:31:45 <psykose> qt5-qtbase-sqlite is needed probably
2022-07-05 17:31:57 <psykose> or the qt6- version if it's qt6
2022-07-05 17:31:58 <psykose> :)
2022-07-05 17:32:02 <donoban> ok, I will try that
2022-07-05 17:32:18 <psykose> it's never linked against and has to be manually added
2022-07-05 17:32:27 <donoban> I don't see any specifyc to qt5/6, so probably it's 5
2022-07-05 17:34:50 <donoban> >>> electrum: Signing the index...
2022-07-05 17:34:56 <donoban> thanks psykose :)
2022-07-05 17:35:14 <psykose> anytime
2022-07-05 17:36:06 <donoban> 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 <donoban> should I push both upgrades on same MR?
2022-07-05 17:36:49 <psykose> sure
2022-07-05 17:36:54 <donoban> ok
2022-07-05 17:42:53 <donoban> uhmm, something is wrong here
2022-07-05 17:44:47 <donoban> I think that it has a lot of vendeored libs/packages
2022-07-05 17:44:57 <donoban> and it runs the tests of them
2022-07-05 17:45:14 <donoban> so qt5-qtbase-sqlite it's a depednency for some qtpy tests, but don't for electrum
2022-07-05 17:45:30 <psykose> sure, checkdepends
2022-07-05 17:45:43 <donoban> this looks a way for running it directly from source without any system dep
2022-07-05 17:45:53 <donoban> but abuild should only run the specifc electrum tests rigth?
2022-07-05 17:46:47 <donoban> lol, there aren't tests
2022-07-05 17:46:49 <donoban> :P
2022-07-05 18:04:25 <donoban> ouch, the merge url fails
2022-07-05 18:04:50 <donoban> 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 <donoban> shows "Page Not Found
2022-07-05 18:05:58 <donoban> ops, probably is because i'm not logged
2022-07-05 18:07:42 <ikke> works for me :)
2022-07-05 18:07:53 <donoban> hehe 
2022-07-05 18:10:42 <donoban> all fine
2022-07-06 07:05:08 <psykose> 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 <andypost[m]> That's pretty annoying and maintainers did not notifications as only bot can find maintainer
2022-07-06 07:45:14 <Ermine> Noice
2022-07-06 07:51:20 <psykose> yep
2022-07-06 07:51:25 <psykose> wonder if it can be toggled
2022-07-06 07:51:35 <psykose> or, the bot could always override first selection, but that's not good either
2022-07-06 09:22:22 <psykose> 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 <psykose> boomanaiden154: also fwiw i've had setuptools 60.6 locally this whole time and it's been fine
2022-07-06 09:30:05 <psykose> 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 <psykose> and the unvendor/vendor of it is fucked, didn't spend much time on it
2022-07-06 09:30:19 <psykose> i'll have a look at some point
2022-07-06 09:34:27 <psykose> ncopa: also next openrc is ready !35190
2022-07-06 11:03:50 <donoban> I'm wondering if a massive modification with grep/sed could be a good solution for #13508
2022-07-06 11:04:47 <donoban> 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 <donoban> 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 <psykose> do they actually lack tests or is it more pypi tarballs :p
2022-07-06 11:07:17 <donoban> the three that I checked lack tests
2022-07-06 11:07:53 <psykose> (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 <donoban> uhM, do you mean that there are tests on the source repository but not in the distributed tarball?
2022-07-06 11:08:43 <psykose> yes
2022-07-06 11:09:00 <donoban> well, maybe that can be automated too
2022-07-06 11:09:05 <psykose> 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 <donoban> most APKBUILD have a github or similar url
2022-07-06 11:09:33 <donoban> I'm gonna check electrum :D
2022-07-06 11:09:56 <donoban> https://github.com/spesmilo/electrum/tree/master/electrum/tests
2022-07-06 11:09:58 <donoban> beh
2022-07-06 11:10:25 <donoban> I'm gonna draft the upgrade MR
2022-07-06 11:10:44 <donoban> thanks psykose :P
2022-07-06 11:13:59 <psykose> anytime
2022-07-06 11:15:34 <donoban> well, downloading it from github tag fixes it
2022-07-06 11:17:49 <psykose> personally i always just use repo tags, unless upstream specifically says >>>>>>>>>>> releases here <<<<<<<<<<<<<<
2022-07-06 11:18:12 <psykose> 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 <donoban> they do "release here!", with pgp signatures etc..
2022-07-06 11:21:02 <donoban> but I think that they target multi-arch so prefer to package all dependecies
2022-07-06 11:26:45 <donoban> looks good
2022-07-06 11:27:22 <donoban> =============================================================================== 2 failed, 566 passed, 3 skipped, 503 warnings in 41.57s ===============================================================================
2022-07-06 11:27:24 <donoban> yeah!
2022-07-06 11:28:20 <donoban> beh, just test dependencies
2022-07-06 11:28:24 <donoban> I think it will run fine now
2022-07-06 11:29:31 <donoban> so I thought that it doesn't have any test and has near 600 :P
2022-07-06 11:30:19 <donoban> >>> electrum: Signing the index...
2022-07-06 11:30:21 <donoban> great!
2022-07-06 11:32:33 <donoban> ouch, is not ammend ok for edit last commit message?
2022-07-06 11:33:12 <donoban> lol, is --amend* :P
2022-07-06 11:33:24 <ikke> If it's on a feature branch that has not been merged yet it's fine 
2022-07-06 11:35:47 <psykose> same as any history editing, perfectly okay
2022-07-06 11:36:01 <psykose> 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 <psykose> ikke: noticed at least all those permission denieds are entirely gone now, so that is a plus!
2022-07-06 11:39:18 <ikke> Nice 
2022-07-06 11:40:37 <psykose> 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 <psykose> i assume it's developers only but it's annoying
2022-07-06 11:41:20 <donoban> !35985 Michal approved it :P
2022-07-06 11:44:15 <ikke> psykose: not sure, need to look 
2022-07-06 11:50:05 <donoban> 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 <psykose> i would not script it
2022-07-06 11:56:00 <psykose> 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 <donoban> :D
2022-07-06 12:07:12 <ikke> Check out https://gitlab.alpinelinux.org/kdaudt/apkgquery
2022-07-06 12:15:27 <skarnet> in today's discoveries: busybox's management of utmp in inittab sucks
2022-07-06 12:15:32 <skarnet> (not a real discovery)
2022-07-06 12:16:50 <jvoisin> "busybox […] sucks."
2022-07-06 12:17:36 <oneinsect> ikke: do we have static builds of gcc?
2022-07-06 12:17:49 <ikke> Don't think so 
2022-07-06 12:17:50 <skarnet> 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 <psykose> could you merge https://gitlab.alpinelinux.org/alpine/infra/build-server-status/-/merge_requests/4
2022-07-06 13:39:52 <ncopa> done
2022-07-06 13:44:16 <psykose> thanks
2022-07-06 13:44:20 <psykose> needs a rebuild too i think
2022-07-06 19:14:31 <boomanaiden154> 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 <boomanaiden154> 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 <ikke> Starting from v60, setuptools starts requiring all sorts of dependencies, which make bootstrapping it a lot more difficult
2022-07-06 19:29:09 <boomanaiden154> psykose: seems like chromium tarballs should be available soon. https://chromium.googlesource.com/chromium/tools/build/+/cba067232fe2237b85e4cfec7dd73edb2be6a17d
2022-07-06 19:32:15 <boomanaiden154> 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 <lattis> 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 <ikke> which patch?
2022-07-06 20:40:43 <lattis> https://lists.alpinelinux.org/~alpine/aports/patches/4118
2022-07-06 20:41:07 <ikke> lattis: sadly, the bridge does not support follow-ups
2022-07-06 20:41:17 <ikke> (v2, v3, etc)
2022-07-06 20:41:46 <ikke> So you need to send them as seperate threads
2022-07-06 20:42:04 <lattis> ah, I see
2022-07-06 20:42:33 <lattis> I'm not seeing a MR for my v1 patch either though, is that to be expected?
2022-07-06 20:42:56 <ikke> No
2022-07-06 20:45:09 <ikke> lattis: Seems to be an issue, I need to investigate it
2022-07-06 20:46:14 <lattis> I'll try re-sending my patch as a separate thread too
2022-07-06 20:47:36 <ikke> For now that won't help
2022-07-06 20:47:52 <lattis> Ok, I'll hold off then
2022-07-07 03:22:13 <psykose> boomanaiden154: makes sense. i'll try to bump setuptools soon, but i'm travelling this week
2022-07-07 08:14:20 <Ermine> https://github.com/apache/trafficserver/issues/8887#issuecomment-1176806652
2022-07-07 10:50:10 <Ermine> I guess they are reffering to dlclose, if they want to be able to reload their plugins
2022-07-07 14:21:05 <ncopa> do we have everything we should in 3.16-stable for the 3.16.2 release?
2022-07-07 14:21:54 <ncopa> we should probably pick this one, even if there are no response from upstream 4ffd996b3f8298c7dd424b912c245864c816e354
2022-07-07 14:38:45 <skarnet> 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 <ptrc> 3.16.2? did .1 even come out?
2022-07-07 14:44:23 <ncopa> i meant 3.16.1 ofc
2022-07-07 14:55:44 <ptrc> ah, makes sense :)
2022-07-07 14:58:08 <psykose> just go straight to .2 :)
2022-07-07 16:57:03 <Ermine> psykose: time machine
2022-07-07 17:36:45 <donoban> http://ix.io/41RU any idea why fails to install py3-tox?
2022-07-07 17:37:00 <donoban> other package has exact the same checkdepends="py3-tox"
2022-07-07 17:37:03 <donoban> and works :\
2022-07-07 17:37:46 <donoban> lol, doesn't work. It has options="!check"
2022-07-07 17:38:12 <donoban> I feel that rootbld doesn't load community repository
2022-07-07 17:42:48 <ptrc> you're in main
2022-07-07 17:42:57 <ptrc> you cannot use packages from community in main
2022-07-07 17:43:10 <ptrc> so yeah, rootbld is correct
2022-07-07 17:43:11 <donoban> uhM, even for doing tests?
2022-07-07 17:43:49 <ptrc> for tests you can edit the aports/main/.rootbld-repositories file locally :p
2022-07-07 17:43:50 <omni> ncopa: 5.15.53 (and others) is out, with patches for XSA-403, -405 & -406
2022-07-07 17:47:09 <donoban> 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 <ptrc> i really don't think so
2022-07-07 17:47:34 <hello71> if you mean for check phase, alpine packages in main cannot use community packages, even for check
2022-07-07 17:47:50 <hello71> either one must be moved to community or the other to main
2022-07-07 17:47:52 <donoban> the alterantive is to move all check dependencies to main
2022-07-07 17:48:04 <hello71> (or move everything to unmaintained :p)
2022-07-07 17:49:20 <donoban> uhM, I don't feel that it's a logical policy
2022-07-07 17:49:31 <donoban> it's like you can only use a debugger on main for debug main packages :S
2022-07-07 17:50:34 <donoban> if you want to run checks but only run/build things on main, ignore them 
2022-07-07 17:50:35 <panekj> 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 <donoban> but if there isn't a strong constraint for it
2022-07-07 17:51:08 <donoban> yeah that's the question, is a checkdepends a dependency?
2022-07-07 17:51:15 <panekj> no
2022-07-07 17:51:23 <panekj> it's a dependency during build
2022-07-07 17:51:30 <donoban> an optional depndency
2022-07-07 17:51:33 <panekj> no
2022-07-07 17:51:36 <ikke> It's also out of practical reasons
2022-07-07 17:51:41 <donoban> you can skip checks
2022-07-07 17:51:46 <donoban> or skip checks outside main dependencies
2022-07-07 17:51:51 <ikke> The way to prevent depends / makedepends on community is to prevent any package from community to be installed
2022-07-07 17:52:03 <panekj> you can skip checks for local debug purposes
2022-07-07 17:53:17 <donoban> what do you mean ikke ? I don't see exactly what prevent
2022-07-07 17:53:47 <ikke> 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 <ikke> You could probable juggle around with repositories to allow checkdepends from community, but it would add complexity
2022-07-07 17:55:16 <donoban> 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 <ikke> All dependencies are installed before building anything
2022-07-07 17:56:17 <donoban> installing the checkdepends before doing the checks doesn't seem problematic
2022-07-07 17:56:24 <ikke> 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 <donoban> or I am missing something?
2022-07-07 17:56:41 <ikke> rootbld disables network by default (with bubblewrap)
2022-07-07 17:57:08 <donoban> uhM yes
2022-07-07 17:57:17 <ikke> so you cannot install more dependencies
2022-07-07 17:57:55 <donoban> well, could be downloaded but not installed until reaching check phase
2022-07-07 17:58:16 <ikke> adding more complexity 
2022-07-07 17:58:43 <donoban> adding more complexity vs disable tests vs move all to main
2022-07-07 17:59:03 <ptrc> tbh even the "specify repositories for checkdepends separately" thing sounds impractical
2022-07-07 17:59:06 <psykose> 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 <donoban> so maybe the process of build should be full separated from the build+check
2022-07-07 18:00:26 <donoban> and in the case of build+check let packages from community
2022-07-07 18:00:45 <ptrc> you mean, build stuff separately just for the checks?
2022-07-07 18:01:05 <donoban> run it twice
2022-07-07 18:01:11 <donoban> first only for build, only with main enabled
2022-07-07 18:01:11 <ikke> yay, more build time
2022-07-07 18:01:13 <donoban> all ok
2022-07-07 18:01:18 <ptrc> yeah that sounds pointless
2022-07-07 18:01:20 <donoban> so now run with cheks enabled
2022-07-07 18:01:34 <panekj> double the compute waste
2022-07-07 18:01:45 <panekj> (:
2022-07-07 18:02:03 <ikke> donoban: it's a tradeoff
2022-07-07 18:02:24 <ikke> 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 <psykose> the specific thing you are even trying to check doesn't need tox
2022-07-07 18:03:07 <donoban> sphinxcontrib/?
2022-07-07 18:03:31 <donoban>  
2022-07-07 18:03:33 <donoban> To run the tests with the interpreter available as ``python``, use::
2022-07-07 18:03:35 <donoban>     tox
2022-07-07 18:04:21 <ptrc> or, you look at `tox.ini` and just run pytest
2022-07-07 18:04:40 <psykose> and if you look at the other sphinxcontribs there is a comment about a circular dep
2022-07-07 18:05:03 <psykose> 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 <donoban> well..
2022-07-07 18:07:21 <psykose> if you want my advice, delete the check() and add !check i guess
2022-07-07 18:07:36 <donoban> after bwrp finishes on rootbld
2022-07-07 18:08:06 <donoban> abuild could reenable network, enable community, install checkpedens, and run again bwrap
2022-07-07 18:08:31 <donoban> but if there are programs that depend on checkpends during build..
2022-07-07 18:08:34 <ikke> donoban: saying what it could do, and implementing it are 2 different things
2022-07-07 18:09:34 <donoban> yeah, and implementing it and being accepted :P
2022-07-07 18:10:13 <ikke> Don't forget the tests
2022-07-07 18:10:31 <donoban> they depend on testing :P
2022-07-07 18:12:51 <ikke> ddevault: apparently upgrade to 15.0 broke the mailing-list bot
2022-07-07 18:13:00 <ikke> logs say the token is not accepted
2022-07-07 18:13:08 <ddevault> 15.0 what?
2022-07-07 18:13:10 <ikke> gitlab
2022-07-07 18:13:16 <ddevault> that is very very annoying
2022-07-07 18:13:18 <ikke> yes
2022-07-07 18:13:23 <ddevault> I love it when other people make busy work for me
2022-07-07 18:13:27 <ddevault> I'll look into it
2022-07-07 18:13:28 <ikke> I can try to fix it
2022-07-07 18:13:41 <ikke> but I need to be reminded where we created / added the token
2022-07-07 18:13:49 <ddevault> the other people are gitlab for making breaking changes, to be clear, not anyone here
2022-07-07 18:14:01 <ddevault> not immediately sure what could be wrong, would have to dig
2022-07-07 18:14:13 <ddevault> added to my todo list
2022-07-07 18:16:21 <donoban> http://ix.io/41S7 tests fails because it misses himself :\
2022-07-07 18:18:22 <ptrc> you can add `PYTHONPATH="$PWD"` before the command
2022-07-07 18:18:51 <ptrc> (or "$PWD/build/lib" or whatever the correct directory is)
2022-07-07 18:21:22 <donoban> hmm..
2022-07-07 18:21:56 <donoban> on "$PWD/build/lib" there is sphinxcontrib folder
2022-07-07 18:22:04 <donoban> but it stills failing
2022-07-07 18:25:46 <ptrc> you could try virtualenv then: https://git.alpinelinux.org/aports/tree/main/py3-pytest/APKBUILD#n45
2022-07-07 18:26:55 <donoban> uhm, does it need py3-virtualenv
2022-07-07 18:26:56 <donoban> ?
2022-07-07 18:27:16 <ptrc> nope
2022-07-07 18:27:33 <ptrc> there it's been added to checkdepends by mistake
2022-07-07 18:28:43 <donoban> same error :(
2022-07-07 18:29:30 <donoban> did you mean something like this http://ix.io/41Sb?
2022-07-07 18:29:49 <ptrc> yup
2022-07-07 18:39:46 <ikke> 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 <ddevault> 
ACTION sighs, pulls up the code

2022-07-07 18:41:48 <ddevault> try to log in as alpine on dispatch.alpinelinux.org
2022-07-07 18:41:53 <ddevault> delete the current hook for patches
2022-07-07 18:41:59 <ddevault> then re-add it, going through the authorization flow again
2022-07-07 18:42:05 <ikke> ok, will do
2022-07-07 18:42:07 <ddevault> if it breaks, I'll drop the auth row from the database and we can try again
2022-07-07 18:42:15 <ddevault> if it still breaks, back to the todo list
2022-07-07 18:42:30 <ddevault> you'll have to be logged into gitlab as the mailinglist-bot user
2022-07-07 18:42:41 <ikke> ah right, it was oauth it used
2022-07-07 18:44:49 <psykose> 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 <ddevault> regular old oauth token
2022-07-07 18:46:51 <ddevault> goes through the normal oauth 2.0 flow
2022-07-07 18:47:48 <ikke> ddevault: It says the aports mailing list is already configured
2022-07-07 18:48:04 <ikke> "Choose a mailing list"
2022-07-07 18:48:15 <ddevault> hang on, delete it again and hang tight
2022-07-07 18:48:33 <ikke> deleted
2022-07-07 18:48:50 <ddevault> try again now?
2022-07-07 18:49:36 <ikke> Oh, maybe I misunderstood what happens. I guess you could potentially select multiple lists?
2022-07-07 18:49:50 <ddevault> maybe? not sure
2022-07-07 18:49:55 <ikke> "Submits a merge request to
2022-07-07 18:49:56 <ddevault> I wrote this a while ago and haven't touched it since
2022-07-07 18:49:57 <ikke> alpine / aports for every patchset received by the
2022-07-07 18:49:59 <ikke> aports mailing list. "
2022-07-07 18:50:09 <ikke> Basically after you select a mailing list, you get the same list again
2022-07-07 18:50:10 <ddevault> it looks like the task is re-configured
2022-07-07 18:50:14 <ddevault> shall I send a patch and see what happens?
2022-07-07 18:50:21 <ikke> yes
2022-07-07 18:50:29 <ikke> oh
2022-07-07 18:50:31 <ddevault> sent
2022-07-07 18:50:48 <ikke> Michael Polansky just upgradded yggdrasil
2022-07-07 18:51:03 <ddevault> so it won't apply
2022-07-07 18:51:09 <ddevault> I'll send another
2022-07-07 18:51:48 <ddevault> done
2022-07-07 18:52:21 <ikke> It's listed under 'applications' of the mailinglist-bot user ftr
2022-07-07 18:52:26 <ikke> the oauth token
2022-07-07 18:52:38 <ddevault> the mail server is slow
2022-07-07 18:52:40 <ddevault> it will take a moment
2022-07-07 18:53:36 <ikke> The token was still there (looking at a our test instance)
2022-07-07 18:53:56 <ikke> https://i.imgur.com/J3xWiRA.png
2022-07-07 19:04:25 <ddevault> it is not working
2022-07-07 19:04:30 <ikke> :(
2022-07-07 19:04:59 <ddevault> there is no webhook subscription in place
2022-07-07 19:05:03 <ikke> Last message in dispatch.log was from an hour ago
2022-07-07 19:05:15 <ddevault> we may have had a sync error while I was deleting rows and you were making tasks
2022-07-07 19:05:20 <ddevault> can you delete and re-create the task again
2022-07-07 19:05:41 <ikke> ok
2022-07-07 19:06:40 <ikke> deleted
2022-07-07 19:06:46 <ikke> do you still need to do something?
2022-07-07 19:06:51 <ddevault> no, you can re-create it now
2022-07-07 19:06:55 <ikke> ok
2022-07-07 19:07:16 <ikke> ok, done
2022-07-07 19:07:23 <ddevault> hrm
2022-07-07 19:07:25 <ddevault> there is still no webhook
2022-07-07 19:07:49 <ddevault> I officially give up
2022-07-07 19:07:53 <ddevault> will investigate more later
2022-07-07 19:08:01 <ikke> I see a webhook in the project
2022-07-07 19:08:07 <ddevault> there is no lists.sr.ht webhook
2022-07-07 19:08:20 <ikke> ok
2022-07-07 19:08:39 <ikke> and that webhook in gitlab only gets 404s now
2022-07-07 19:08:42 <ikke> probably expected
2022-07-07 19:09:02 <ddevault> reset to a ground state
2022-07-07 19:09:09 <ddevault> get rid of the webhook on gitlab and delete the dispatch task
2022-07-07 19:09:12 <ikke> ok
2022-07-07 19:09:14 <ddevault> then I'll get back to you once I know why it's not working
2022-07-07 19:09:53 <ikke> Ok, webhook and task deleted
2022-07-07 19:09:57 <ddevault> ty
2022-07-07 19:18:14 <ikke> Is setting subpackages to empty here a mistake? 5f9ea92a3bc5c730daaebd393206558bfdc8256c
2022-07-07 19:20:04 <ikke> Hmm, no, probably done on purpose
2022-07-07 19:20:07 <ikke> they are set later
2022-07-07 19:21:53 <psykose> not sure what x86 is left with, but eh
2022-07-07 19:22:06 <psykose> all of that stuff is fucked because we have no noarch
2022-07-07 19:22:16 <ikke> need to figure out how to use uefi with qemu
2022-07-07 19:22:59 <psykose> on x86_64 for x86_64, add ovmf
2022-07-07 19:23:00 <psykose> then uhh
2022-07-07 19:23:01 <minimal> ikke: I can help
2022-07-07 19:23:03 <psykose> yea
2022-07-07 19:23:08 <psykose> big boss here can give you the steps
2022-07-07 19:23:26 <ikke> 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 <ikke> -bios /usr/share/ovmf/bios.bin 
2022-07-07 19:23:45 <ikke> that's what I do now, but won't work
2022-07-07 19:24:05 <psykose> there's no more bios in edk2?
2022-07-07 19:24:12 <ikke> not for aarch64
2022-07-07 19:24:21 <ikke> at least, not ovmf
2022-07-07 19:24:24 <ikke> what I was using
2022-07-07 19:24:34 <psykose> ah, you mean before that change
2022-07-07 19:24:39 <ikke> yes
2022-07-07 19:24:41 <ikke> 3.15
2022-07-07 19:25:01 <minimal> 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 <ikke> ok
2022-07-07 19:25:31 <ikke> so I can give it the path of the QEMU_EFI.fd file?
2022-07-07 19:25:54 <minimal> so I use the following qemu-system-aarch64 options:
2022-07-07 19:26:01 <minimal> "-drive if=pflash,format=raw,readonly,file=/usr/share/AAVMF/AAVMF_CODE.fd"
2022-07-07 19:26:16 <minimal> "-drive if=pflash,format=raw,file=./AAVMF_VARS.fd"
2022-07-07 19:26:47 <ikke> hmm, so that last one is per VM I suppose?
2022-07-07 19:27:02 <minimal> 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 <minimal> the 2nd file is for UEFI variables to be stored, so yes its per VM
2022-07-07 19:27:51 <ikke> minimal: why is it an issue that the packages are built on aarch64?
2022-07-07 19:28:27 <psykose> to build a aavmf efi you need an aarch64 toolchain
2022-07-07 19:28:52 <psykose> we either need actual noarch, or a cross toolchain usable in apkbuilds
2022-07-07 19:28:53 <minimal> 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 <ikke> minimal: no, this is qemu-system-aarch64 on an aarch64 host
2022-07-07 19:29:35 <psykose> then you should be able to pass that fine, with `aavmf` installed
2022-07-07 19:29:42 <ikke> yes, I installed aavmf
2022-07-07 19:29:44 <minimal> ikke: ah, ok, then you need to install the aavmf package to get the files
2022-07-07 19:30:08 <ikke> minimal: it comes with EFI_VARS.fd, should I copy that for each vm?
2022-07-07 19:30:18 <ikke> sorry QEMU_VARS.fd
2022-07-07 19:31:11 <minimal> so copy /usr/share/AAVMF/AAVMF_VARS.fd locally (for the specific VM)
2022-07-07 19:31:30 <ikke> ok
2022-07-07 19:31:43 <minimal> 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 <minimal> to qemu-system-aarch86
2022-07-07 19:31:55 <ikke> lol
2022-07-07 19:32:03 <minimal> s/aarch86/aarch64/
2022-07-07 19:32:03 <alpine-meetbot> minimal meant to say: to qemu-system-aarch64
2022-07-07 19:32:08 <ikke> funny hybrid :D
2022-07-07 19:33:50 <minimal> ikke: I assume you are also passing appropriate "-machine" and "-cpu" options
2022-07-07 19:34:06 <ikke> -machine virt,accel=kvm,gic-version=3 
2022-07-07 19:34:35 <ikke> -cpu host
2022-07-07 19:34:46 <ikke> (I use qemu-openrc)
2022-07-07 19:35:50 <minimal> ikke: and perhaps "-display none -serial stdio"?
2022-07-07 19:39:10 <ikke> -serial pty
2022-07-07 19:55:00 <ikke> openrc-qemu uses -device ide-cd,drive=cdr0, but it complains that there is no ide bus?
2022-07-07 19:55:35 <ikke> afaik it used to work
2022-07-07 19:57:04 <ikke> qemu-system-aarch64: -device ide-cd,drive=cdr0: No 'IDE' bus found for device 'ide-cd'
2022-07-07 19:58:07 <minimal> ikke: I haven't used ide-cd with qemu aarch86, i'm using scsi-cd
2022-07-07 19:58:30 <ikke> ok, let me try that
2022-07-07 19:58:59 <ikke> ok, seems to work
2022-07-07 20:00:13 <ikke> indeed, it booted the iso now :)
2022-07-07 20:00:16 <minimal> 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 <minimal> to give scsi cd and scsi hdd, both via virtio
2022-07-07 20:00:55 <minimal> you could use virtio-blk instead of virtio-scsi for the disk
2022-07-07 20:01:52 <ikke> qemu-openrc currently used scsi-hd
2022-07-07 20:20:30 <hello71> 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 <psykose> whadya mean by attached? wine cmd works fine for me
2022-07-07 20:24:55 <psykose> (both wine64 cmd and wine64 display cmd)
2022-07-07 20:25:12 <psykose> er, start
2022-07-07 20:25:29 <ptrc> does running anything in that cmd like `dir` works for you? it returns `Invalid function.` for me
2022-07-07 20:25:51 <psykose> yes
2022-07-07 20:27:57 <hello71> 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 <psykose> they all work yeah
2022-07-07 20:30:33 <psykose> and if i unset DISPLAY then it fails with 'make sure ur X is running'
2022-07-07 20:31:38 <hello71> but wine cmd keeps working?
2022-07-07 20:31:48 <hello71> what kind of X are you running?
2022-07-07 20:32:54 <psykose> 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 <psykose> xwayland
2022-07-07 20:33:24 <hello71> hm... what kind of wayland?
2022-07-07 20:33:28 <psykose> sway
2022-07-07 20:34:08 <hello71> it works for me with alpine xvfb but not gentoo sway/xwayland. let me try alpine sway
2022-07-07 20:34:35 <psykose> does gentoo sway imply gentoo wine?
2022-07-07 20:35:07 <hello71> no, it's alpine wine :p
2022-07-07 20:35:32 <hello71> i'm *pretty* sure gentoo wine works
2022-07-07 20:35:54 <psykose> what kind of weird frankenstein experiment is this then
2022-07-07 20:36:37 <psykose> 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 <psykose> :p
2022-07-07 20:37:04 <hello71> chroot related
2022-07-07 20:39:40 <psykose> ah, seems someone also reported a wine issue
2022-07-07 20:39:54 <psykose> #13993
2022-07-07 20:40:16 <psykose> '2nd party on similar setup'
2022-07-07 20:40:26 <psykose> wonder who that is, definitely
2022-07-07 20:41:41 <hello71> 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 <psykose> u should try that in not some weird chroot stuff
2022-07-07 20:54:29 <psykose> but yes, it's broken with root, hm
2022-07-07 20:54:30 <psykose> no idea
2022-07-07 21:01:09 <hello71> i bet it is related to that "Read access denied"
2022-07-07 21:04:01 <psykose> why would it work as non-root then
2022-07-07 21:04:16 <psykose> though it does look sussy
2022-07-07 21:08:11 <hello71> works fine as root for me -.-
2022-07-07 21:09:34 <hello71> maybe it works on tmpfs root
2022-07-08 08:06:53 <ncopa> was there a cli tool to create merge requests to gitlab?
2022-07-08 08:07:01 <ncopa> aports gitlab that is
2022-07-08 08:08:54 <Habbie> glab
2022-07-08 09:08:23 <ikke> Yes, glab indeed 
2022-07-08 09:59:07 <skarnet> I'm glab there is something
2022-07-08 10:05:57 <omni> there's also lab
2022-07-08 10:24:20 <ncopa> :) thanks! i was not able to configure glab properly so it only created an empty MR
2022-07-08 10:24:26 <ncopa> maybe will have a look at it later
2022-07-08 10:27:33 <omni> 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 <omni> 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 <Ermine> Glab sounds like something done by gnome :D
2022-07-08 15:40:02 <omni> bump https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/106
2022-07-08 23:13:45 <boomanaiden154> psykose: Thanks for the work on electron. Being able to run electron apps on Alpine will be awesome.
2022-07-08 23:18:20 <panekj> time to start counting days until it breaks
2022-07-08 23:21:05 <boomanaiden154> 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 <psykose> it actually works fine for vscode for the past month
2022-07-09 06:59:57 <psykose> but that is the only thing i tried :p
2022-07-09 08:17:36 <psykose> 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 <boomanaiden154> I think their build/publish process is public somewhere.
2022-07-09 08:33:37 <boomanaiden154> Are you planning on getting vscode merged into master too?
2022-07-09 08:38:39 <boomanaiden154> https://chromium.googlesource.com/chromium/tools/build/+/refs/heads/main/recipes/recipe_modules/chromium/resources/export_tarball.py
2022-07-09 08:38:43 <boomanaiden154> This is the script right here.
2022-07-09 08:39:30 <boomanaiden154> Lines 219/222 are the relevant xz commands.
2022-07-09 08:39:35 <boomanaiden154> They’re just calling xz -9
2022-07-09 08:40:21 <boomanaiden154> They seem to be deleting some nonessential files/directories though.
2022-07-09 08:42:52 <psykose> deleting dirs pre-compress would lead to smaller raw tar
2022-07-09 08:43:09 <psykose> 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 <psykose> unless that entire extra G was incompressible
2022-07-09 08:43:25 <psykose> eh, guess it's fine
2022-07-09 08:44:09 <psykose> i would add vscode but you can't have extensions
2022-07-09 08:44:16 <psykose> breaks the licence
2022-07-09 08:44:45 <psykose> and a vscode without extensions is not much of a package :)
2022-07-09 08:44:56 <psykose> i have an illegal one on my own repo i guess
2022-07-09 08:45:34 <boomanaiden154> That’s true. It’s annoying that they licensed it that way.
2022-07-09 08:45:43 <psykose> aye, classic microsoft
2022-07-09 08:46:04 <ikke> open core, but you need closed components to be actually useful
2022-07-09 08:46:54 <boomanaiden154> 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 <psykose> that would work probably, assuming they actually have extensions
2022-07-09 08:47:40 <boomanaiden154> 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 <psykose> the normal store is 1 line in a json file
2022-07-09 08:48:09 <boomanaiden154> Oh.
2022-07-09 08:48:12 <boomanaiden154> Open VSX.
2022-07-09 08:48:14 <boomanaiden154> https://open-vsx.org
2022-07-09 08:48:17 <psykose> a few more than one but
2022-07-09 08:48:22 <psykose> https://git.ddd.rip/ptrcnull/ptrcports/src/branch/master/code-oss/enable-extensions.patch
2022-07-09 08:50:12 <psykose> the first thing i checked hasnt been updated in 7 months on vsx
2022-07-09 08:50:31 <psykose> relative to the same extension
2022-07-09 08:50:35 <boomanaiden154> clangd got updated two months ago.
2022-07-09 08:50:59 <boomanaiden154> It’s on the same version as the official marketplace.
2022-07-09 08:51:34 <psykose> yeah
2022-07-09 08:51:55 <boomanaiden154> The python package is up to date as well.
2022-07-09 08:52:02 <psykose> rust-analyzer is an eon behind
2022-07-09 08:52:04 <psykose> wonder who updates those
2022-07-09 08:54:27 <boomanaiden154> 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 <psykose> well, i guess if they have the same paths that can be patched in, it would work
2022-07-09 08:55:11 <boomanaiden154> There’s also VScodium that you should be able to check.
2022-07-09 08:55:20 <boomanaiden154> I think they use OpenVSX by default.
2022-07-09 08:55:35 <psykose> ah
2022-07-09 08:55:37 <psykose> yep, works
2022-07-09 08:56:16 <boomanaiden154> https://github.com/open-vsx/publish-extensions
2022-07-09 08:56:34 <boomanaiden154> There’s this repo that automatically pushes extensions to OpenVSX.
2022-07-09 08:56:55 <psykose> guess all i need to do is write it in then
2022-07-09 08:57:13 <psykose> if only i was not on a bus for most of today
2022-07-09 08:57:51 <boomanaiden154> Should be easier than packaging electron.
2022-07-09 08:58:00 <boomanaiden154> Looks like VSCode is good to go then?
2022-07-09 09:00:14 <boomanaiden154> 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 <boomanaiden154> Seems like someone started to do it manually and then just let it bit rot.
2022-07-09 09:01:15 <psykose> yep, seems to be the case
2022-07-09 09:19:34 <psykose> actually was unrelated <https://github.com/rust-lang/rust-analyzer/issues/11080>
2022-07-09 09:20:52 <psykose> so yeah, almost fixed
2022-07-09 09:20:59 <psykose> many months of back and forth, just the last step
2022-07-09 09:22:42 <boomanaiden154> Oh wow. That is a long thread.
2022-07-09 09:22:49 <psykose> massive indeed
2022-07-09 09:22:50 <psykose> :3
2022-07-09 09:23:08 <psykose> done with vscode too, just have to see if vsx works out of the box
2022-07-09 09:23:15 <psykose> then once it builds, merged i guess
2022-07-09 09:23:56 <boomanaiden154> Then maybe I’ll start actually using Alpine instead of just maintaining packages in docker containers. :p
2022-07-09 09:24:05 <psykose> haha
2022-07-09 09:24:15 <psykose> there's probably some rough edges
2022-07-09 09:25:16 <boomanaiden154> 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 <psykose> you're certainly much better at fixing them than me
2022-07-09 09:25:44 <boomanaiden154> Definitely not.
2022-07-09 09:26:16 <boomanaiden154> 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 <psykose> still amazed it works
2022-07-09 09:27:56 <boomanaiden154> 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 <boomanaiden154> And I still can’t figure out how to make it less janky.
2022-07-09 09:29:21 <psykose> i mean it works perfectly, can't complain
2022-07-09 09:29:32 <psykose> the only outstanding random segfaults are ones i can't really reprodce
2022-07-09 09:29:35 <psykose> reproduce*
2022-07-09 09:30:04 <psykose> 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 <boomanaiden154> Yeah. Always nicer to have it upstreamed though so we don’t have to keep rebasing patches.
2022-07-09 09:31:48 <boomanaiden154> 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 <boomanaiden154> 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 <boomanaiden154> There’s also still the issue with getting CFI working with those clang segfaults.
2022-07-09 09:33:20 <psykose> yep
2022-07-09 09:33:26 <psykose> and i think only lto fails too without cfi
2022-07-09 09:33:55 <psykose> 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 <psykose> so it's a million years to test that stuff
2022-07-09 09:34:12 <psykose> 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 <psykose> a whole llvm meetup huh, sounds fun
2022-07-09 09:35:14 <boomanaiden154> Yeah. I forgot we aren’t using ThinLTO.
2022-07-09 09:36:44 <boomanaiden154> 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 <psykose> that probably takes a thousand years
2022-07-09 09:37:11 <boomanaiden154> And that means a two stage compile plus lots of tests/each marks in between.
2022-07-09 09:37:19 <boomanaiden154> *benchmarks
2022-07-09 09:37:48 <boomanaiden154> 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 <psykose> yep
2022-07-09 09:38:18 <psykose> 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 <psykose> very complex into a build, and takes 50 years
2022-07-09 09:38:39 <psykose> 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 <psykose> 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 <psykose> 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 <boomanaiden154> Interesting. Just straight up LTO does use a ton of memory though.
2022-07-09 09:41:04 <psykose> it's thin, and passes on all the other arches
2022-07-09 09:41:16 <psykose> i tried it on a machine with 256gb and even there it fails
2022-07-09 09:41:29 <boomanaiden154> Oh. LLVM seems to have a couple outstanding problems. :pensivebread:
2022-07-09 09:41:39 <psykose> pensivebread indeed
2022-07-09 09:42:03 <psykose> but yeah that one would be nice to fix :3
2022-07-09 09:45:33 <boomanaiden154> 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 <boomanaiden154> 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 <boomanaiden154> 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 <psykose> could be! what is really strange is that it really is x86_64 only
2022-07-09 09:47:20 <psykose> the opposite of how things normally fail
2022-07-09 11:31:57 <Behemoth> Will the next alpine version ship with gcc 12?
2022-07-09 11:34:34 <psykose> prolly
2022-07-09 11:34:50 <psykose> cant believe i missed my bus just to package vscode
2022-07-09 11:34:55 <ikke> lol
2022-07-09 11:34:55 <psykose> curse of microsoft
2022-07-09 11:35:02 <Behemoth> king
2022-07-09 11:36:01 <psykose> the real reason was my clock was an hour behind because im a moron
2022-07-09 13:27:37 <panekj> desc should say "with Open-VSX"
2022-07-09 14:38:19 <psykose> i dont think anyone even reads that
2022-07-09 14:39:05 <psykose> meet me in warsaw in 9 hours if u disagree
2022-07-09 14:39:14 <panekj> ok
2022-07-09 14:58:21 <minimal> psykose: warsaw in which country? ;-)
2022-07-09 15:02:19 <panekj> the OG warsaw
2022-07-09 15:05:24 <ptrc> surely it's about one of the 10 villages named warsaw in the united states /s
2022-07-09 15:10:38 <minimal> ptrc: don't call me Shirley ;-)
2022-07-09 15:13:44 <psykose> the polish warsaw :p
2022-07-09 15:14:24 <psykose> (before i get on a train and leave a few hours later)
2022-07-09 17:13:16 <Thermi> '[ -n "${APORTSDIR+x}" ] ' <- will that ever evaluate to false?
2022-07-09 17:13:28 <Thermi> -n checksi f the string is empty, but with the +x, it's never empty
2022-07-09 17:13:42 <Thermi> *is not empty
2022-07-09 17:14:06 <Thermi> *with +x the string is never empty
2022-07-09 17:14:33 <hello71> no, it is empty if APORTSDIR is defined to empty string
2022-07-09 17:14:52 <hello71> or something like that
2022-07-09 17:16:34 <hello71> if APORTSDIR is unset
2022-07-09 17:17:37 <Thermi> This is weird and undocumented in the shell
2022-07-09 17:17:48 <Thermi> The shell documents {$FOO:+x} but not ${FOO:x}
2022-07-09 17:17:50 <ikke> + vs :+?
2022-07-09 17:18:12 <Thermi> ${parameter:+word}
2022-07-09 17:18:12 <Thermi>               tuted.
2022-07-09 17:18:12 <Thermi>               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 <Thermi> no occurence of +word
2022-07-09 17:18:30 <ptrc> the `${VAR+something}` syntax is returning `something` if VAR is set
2022-07-09 17:18:30 <Thermi> (in the whole man page)
2022-07-09 17:18:46 <ikke> https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html mentions it for bash
2022-07-09 17:19:04 <Thermi> Yeah I got the man page open for bash
2022-07-09 17:19:04 <ptrc> so that syntax before evaluates to true if it's unset
2022-07-09 17:19:28 <Thermi> The man page only mentions the :+ notation, not the + only notation
2022-07-09 17:19:38 <Thermi> and it seems they act inverse to each other
2022-07-09 17:19:44 <ikke> https://tldp.org/LDP/abs/html/parameter-substitution.html mentions it as well
2022-07-09 17:20:19 <Thermi> I'm not going crazy, am I?
2022-07-09 17:20:22 <hello71> 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 <ikke> "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 <ptrc> 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 <hello71> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html says "In the parameter expansions shown previously, use of the <colon> in the format shall result in a test for a parameter that is unset or null; omission of the <colon> shall result in a test for a parameter that is only unset."
2022-07-09 17:20:48 <Thermi> Thank you, it's in the paragraph above
2022-07-09 17:20:58 <Thermi> WHICH ONE OF COURSE DOESN'T FIND IF JUST SEARCHING FOR THE NOTATION
2022-07-09 17:21:01 <Thermi> Thank's man page writer :(
2022-07-09 17:21:02 <hello71> now, in my opinion, this syntax is *terrible*, but it's what we're stuck with
2022-07-09 17:21:11 <Thermi> thank you for your help
2022-07-09 18:00:06 <the6543[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36170
2022-07-09 18:00:19 <the6543[m]> I'd like to adopt this package ...
2022-07-09 18:00:45 <the6543[m]> ... as it is a dependency of synapse (a package I already maintain)
2022-07-09 18:01:15 <ikke> As it does not have a maintainer atm, that should not be an issue
2022-07-09 18:04:25 <the6543[m]> oh Contributor must be there ...
2022-07-09 18:04:42 <ikke> Not really :)
2022-07-09 18:04:58 <the6543[m]> `https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36170#note_246415` ...
2022-07-09 18:05:22 <ikke> meh
2022-07-09 18:05:33 <ikke> the contributor field is meaningless
2022-07-09 18:06:16 <ikke> But some want it to be there 'in case some one else takes over maintenance'
2022-07-09 18:06:55 <the6543[m]> well added ... I just wasnt aware of the "must have" condition 
2022-07-09 18:07:29 <ptrc> 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 <the6543[m]> whatever ... it's ready to merge
2022-07-09 18:09:11 <the6543[m]> while going through python3 packages ... there are a lot of non-maintained ones :/
2022-07-09 18:10:12 <the6543[m]> py3-canonicaljson, py3-bleach, py3-signedjson, ...
2022-07-09 18:20:13 <Thermi> Is having empty, but set build variables (CFLAGS="" for example) a valid use case?
2022-07-09 18:21:38 <ptrc> i would say it is, as it just unsets the stuff from abuild.conf
2022-07-09 18:23:00 <Thermi> I mean in in abuild, I'm sorry for being unclear about it
2022-07-09 18:23:20 <Thermi> If one wanted to remove CFLAGS, why not call unset on it
2022-07-09 18:23:22 <Thermi> unset CFLAGS
2022-07-09 18:23:23 <Thermi> done
2022-07-09 18:23:46 <ikke> Some use unset, some assign an empty value
2022-07-09 18:23:48 <Thermi> 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 <Thermi> That of course breaks if HOSTCC is empty.
2022-07-09 18:24:18 <Thermi> 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 <ikke> Can't think of anything from the top of my head
2022-07-09 18:25:06 <Thermi> 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 <Thermi> 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 <ikke> 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 <Thermi> Thank you! Shouldn't that be the default?
2022-07-09 19:25:19 <ikke> I think it takes over whatever the original project had set when you fork it
2022-07-09 19:25:57 <Thermi> 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 <Thermi> thank you!
2022-07-09 22:02:19 <omni> 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 <omni> ^^ instead of saying how impressed I am at how low that number sometimes manage to reach
2022-07-09 23:09:54 <omni> not least since I usually have at least one page of stale MRs
2022-07-09 23:13:58 <psykose> it used to be 530 or so
2022-07-09 23:14:25 <psykose> ive put too much work into getting it to 330 :p
2022-07-09 23:14:48 <psykose> the issue page on the other hand..
2022-07-09 23:16:03 <boomanaiden154> There are also some issues that have been fixed that just never got closed.
2022-07-09 23:16:25 <psykose> yeah, went through like 40 the other day
2022-07-09 23:16:32 <psykose> takes a while
2022-07-09 23:17:05 <boomanaiden154> Like #11822, #11223, and #13579 should all be fixed now.
2022-07-09 23:17:06 <omni> it's tedious, I try to take a look at the old ones now and then
2022-07-09 23:17:29 <omni> I sometimes forget about things I have open
2022-07-09 23:18:15 <boomanaiden154> I just saw an issue that I forgot I had open.
2022-07-09 23:19:25 <omni> 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 <psykose> closed
2022-07-09 23:20:19 <omni> psykose: I'm happy to see all the effort you put into this
2022-07-09 23:20:34 <psykose> :)
2022-07-09 23:25:46 <psykose> omni: i'm happy to see all of yours, too
2022-07-10 01:36:46 <skarnet> I'll show you my effort if you show me yours
2022-07-11 12:38:36 <rbq> 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 <psykose> i guess install_if="perl-libww" on perl-lwp-protocol-https, but no idea
2022-07-11 12:47:19 <rbq> Yes, I was hoping it could be done in cpanminus itself, without touching other aports
2022-07-11 12:47:47 <ptrc> maybe it could just depend on both? or is there a situation where that could cause issues
2022-07-11 12:50:12 <Sheila> cpanminus only interacts with CPAN, not Alpine's packaging.
2022-07-11 12:50:35 <rbq> Probably it would make cpanminus have more dependencies, that's all
2022-07-11 12:51:49 <rbq> 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 <Sheila> sounds reasonable.
2022-07-11 13:40:48 <rbq> 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 <Sheila> reasonable. also approved.
2022-07-11 13:41:10 <rbq> Thanks again :)
2022-07-11 13:41:15 <Sheila> np
2022-07-11 17:11:18 <nmeum> 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 <Ariadne> D is the only blocker, and no i have not had much time yet.
2022-07-11 17:12:42 <nmeum> 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 <Ariadne> yeah
2022-07-11 17:15:12 <Ariadne> will shoot it over in a bit
2022-07-11 17:34:54 <nmeum> ty
2022-07-11 17:37:17 <Ariadne> nmeum: https://tpaste.us/5k97
2022-07-11 18:32:05 <omni> 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 <psykose> 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 <omni> !36266
2022-07-11 22:02:01 <edsonwolf> Good afternoon. How do I subscribe to a package?
2022-07-11 22:02:09 <edsonwolf> https://pastebin.com/Ui8Ugtne
2022-07-11 22:03:19 <edsonwolf> Sorry. Wrong group.
2022-07-11 22:22:11 <DavidHeidelberg[m]> 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 <DavidHeidelberg[m]> s/nicely/👀/, s/looking,//, s/merge_requests/merge\_requests/
2022-07-11 22:23:13 <DavidHeidelberg[m]> I would give a shot try some d3d9 game in box86 on pmOS then 😉
2022-07-11 22:24:50 <psykose> i'm confused what the actual request is
2022-07-11 22:25:23 <omni> am I the only one having issues mounting vfat?
2022-07-11 22:25:53 <psykose> ah, gallium-nine
2022-07-11 22:25:56 <psykose> omni: what issues
2022-07-11 22:33:07 <omni> I don't know, I don't have this issue anymore
2022-07-11 22:33:12 <omni> I'm probably just tired
2022-07-11 22:33:25 <psykose> ~
2022-07-11 22:33:26 <psykose> bedtime
2022-07-11 22:34:00 <omni> a command that failed a minute ago now doesnt!
2022-07-11 22:34:09 <omni> *sigh*
2022-07-11 22:34:49 <DavidHeidelberg[m]> 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 <DavidHeidelberg[m]> and surprisingly on low-performance devices nine has still pretty low overhead compare to different translation layers 
2022-07-11 22:37:16 <psykose> afaict -Dgallium-nine=true builds without that commit, does it fail at runtime
2022-07-11 22:39:01 <DavidHeidelberg[m]> hmm, it should fail https://gitlab.freedesktop.org/mesa/mesa/-/issues/5176
2022-07-11 22:39:01 <DavidHeidelberg[m]> maybe architecture dependent?
2022-07-11 22:40:11 <psykose> ah, that is 32-bit
2022-07-11 22:40:17 <psykose> worked for me on x86_64 though
2022-07-11 22:40:18 <psykose> lets see ci
2022-07-11 22:40:25 <DavidHeidelberg[m]> https://www.openwall.com/lists/musl/2021/08/03/5
2022-07-11 22:44:00 <omni> 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 <omni> but I don't remember when last I had to load that module to mount a vfat fs
2022-07-11 22:51:56 <psykose> DavidHeidelberg[m]: give !36286 a test if it has what you want, though it fails on aarch64
2022-07-11 22:56:56 <psykose> though the failure was in some vulkan stuff, seems unrelated
2022-07-11 23:11:46 <psykose> fixed that and now some other dep fails, feel free to figure it out :)
2022-07-11 23:14:25 <DavidHeidelberg[m]> <psykose> "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 <ddevault> rewriting the lists => gitlab thing has been on my todo list for some time
2022-07-12 07:46:35 <ddevault> just gonna do that instead of troubleshooting it
2022-07-12 07:48:36 <ddevault> gonna start with running upgrades on the host, so be prepared for a brief outage
2022-07-12 07:56:57 <ikke> 👍
2022-07-12 08:05:08 <ddevault> upgrades done
2022-07-12 08:37:34 <ncopa> ddevault: thank you!
2022-07-12 08:46:13 <ddevault> is there any interest in setting this up for more than just aports?
2022-07-12 08:46:28 <ddevault> 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 <ncopa> i think that would be nice, but I don't think it is a priority
2022-07-12 08:48:42 <ddevault> it should not require much additional effort
2022-07-12 08:48:59 <ddevault> 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 <ncopa> 👍
2022-07-12 13:25:16 <Ariadne> nmeum: did you have any luck yet with figuring out GDC :D
2022-07-12 13:52:24 <nmeum> Ariadne: no, I did not have the time yet to look into it
2022-07-12 14:06:09 <ncopa> btw, anybody know what the status is for rust on s390x?
2022-07-12 14:07:59 <Ariadne> i guess they got it to build, but have not done anything else
2022-07-12 14:08:57 <ncopa> so we may be able to bootstrap it for our apk?
2022-07-12 14:13:43 <ikke> nmeum and psykose say it should be possible to bootstrap it
2022-07-12 14:40:39 <nmeum> 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 <nmeum> alternatively, we could also just use the boostrap package provided in the PR !34493 (not my prefered solution)
2022-07-12 14:56:49 <ikke> I'll see if I can get bootstrap.sh going 
2022-07-12 16:41:45 <indy> ddevault, something like git pw (git patchwork integration)?
2022-07-12 16:42:00 <ddevault> not totally familiar with git pw, but I doubt it
2022-07-12 16:42:21 <ddevault> 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 <indy> https://patchwork.readthedocs.io/en/latest/
2022-07-12 16:43:44 <indy> https://github.com/getpatchwork/git-pw
2022-07-12 16:44:31 <ikke> We don't have patchwork anymore
2022-07-12 16:44:36 <ikke> We used to have it, but gave it up
2022-07-12 18:56:43 <ikke> fyi, started bootstrap for s390x (rust)
2022-07-12 19:27:39 <ikke> /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 <psykose> 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 <psykose> (LANG_ADA=false abuild ..)
2022-07-12 19:33:43 <psykose> though i don't know why specifically it would fail :)
2022-07-12 19:44:08 <ikke> psykose: thanks, gcc at least built now
2022-07-12 19:44:12 <psykose> ~
2022-07-12 19:48:06 <ikke> 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 <ikke> meson
2022-07-12 19:50:48 <ikke> Is cross compiler: False.
2022-07-12 19:51:13 <ikke> So I suppose we need to fix meson cross-compiling?
2022-07-12 19:55:26 <ikke> https://mesonbuild.com/Cross-compilation.html
2022-07-12 19:56:49 <ikke> Should I just use qemu-s390x?
2022-07-12 20:02:49 <psykose> for this i need to set up some stuff
2022-07-12 20:03:00 <psykose> you should just skip openrc as it's not needed (and it's the only meson thing)
2022-07-12 20:03:23 <psykose> 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 <psykose> wjat
2022-07-12 20:08:12 <psykose> what's the cross build detection? $CHOST != $CBUILD ?
2022-07-12 20:10:55 <ikke> in bootstrap.sh?
2022-07-12 20:11:56 <ikke> if [ "$CHOST" != "$CTARGET" ]; then
2022-07-12 20:11:58 <ikke> in functions.sh
2022-07-12 20:12:25 <ikke> There is also 
2022-07-12 20:12:27 <ikke>  elif [ "$CBUILD" != "$CHOST" ]; then
2022-07-12 20:13:02 <ikke> skipping openrc for nwo
2022-07-12 20:13:07 <psykose> 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 <psykose> so, in your case CBUILD is x86_64-.. and CHOST is s390x-..
2022-07-12 20:13:47 <psykose> (just to make this big ass if block in abuild-meson)
2022-07-12 20:13:53 <psykose> then i can throw you a modified file to test for openrc
2022-07-12 20:15:23 <ikke> bootstrap.sh sets CTARGET
2022-07-12 20:16:51 <ikke> If I read it correctly, CHOST will be set to CBUILD
2022-07-12 20:17:10 <ikke> and because CTARGET != CHOST, it will not do anything else
2022-07-12 20:17:34 <psykose> yes, ctarget and chost should match (in this case), but chost and cbuild should not be the same
2022-07-12 20:17:46 <psykose> unless there terms are not used correctly or i am confused somehow
2022-07-12 20:17:53 <psykose> can you just echo all three
2022-07-12 20:22:18 <ikke> not sure where to echo it, but I see bootstrap.sh sets CHOST manually for several abuild invocations
2022-07-12 20:23:10 <ikke> openssh complains about autoconf/automake missing
2022-07-12 20:23:12 <ikke> will skip it
2022-07-12 20:23:31 <psykose> anywhere in an apkbuild
2022-07-12 20:23:35 <ikke> hmm, something is pulling in openssh?
2022-07-12 20:23:43 <ikke> libssh2?
2022-07-12 20:23:56 <psykose> shouldn't normally
2022-07-12 20:24:26 <ikke> https://tpaste.us/pnRE 
2022-07-12 20:25:42 <psykose> well, it needs host autoconf/automake and they're not part of bootstrap.sh
2022-07-12 20:26:12 <psykose> 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 <vkrishn> andypost[m]: if given choice for packaging swoole's, swoole or openswoole ?
2022-07-12 20:27:26 <ikke> psykose: tryiung
2022-07-12 20:27:29 <ikke> trying*
2022-07-12 20:27:50 <ikke> but now it's skipping openssh
2022-07-12 20:28:04 <ikke> oh, I already removed it apparently :D
2022-07-12 20:31:50 <andypost[m]> vkrishn: I decided to package swoole cos open one looks less maintained
2022-07-12 20:34:40 <ikke> psykose: it's already at building go, waiting for the build to fail/finish
2022-07-12 20:34:47 <psykose> oki
2022-07-12 20:35:42 <ikke> maybe I'll cancel after go, it will build libffi and ghc
2022-07-12 20:36:49 <vkrishn> andypost[m]: ok
2022-07-12 20:37:27 <ikke> psykose: https://tpaste.us/WQMK 
2022-07-12 20:37:34 <ikke> so as expected
2022-07-12 20:37:40 <psykose> as i thought then
2022-07-12 20:37:49 <psykose> ok, do you mind testing an abuild-meson in a bit on openrc?
2022-07-12 20:37:56 <psykose> with that cross config
2022-07-12 20:38:11 <ikke> from void?
2022-07-12 20:39:15 <psykose> i will send you an abuild-meson to just overwrite /usr/bin/abuild-meson with
2022-07-12 20:39:24 <ikke> sure
2022-07-12 20:44:19 <psykose> you have stuff like 's390x-alpine-linux-musl-gcc-ar' in the cross toolchain right
2022-07-12 20:44:53 <ikke> Curl fails now without any error message
2022-07-12 20:45:31 <psykose> here: https://img.ayaya.dev/kr9sGu55Pot6.sh no promises
2022-07-12 20:46:47 <ikke> The buildroot is quite emptty
2022-07-12 20:47:11 <ikke> the rest is probably just packages that get installed as dependencies
2022-07-12 20:51:06 <ikke> Not sure what's going on with curl
2022-07-12 20:53:18 <psykose> try add bash or something :)
2022-07-12 20:54:31 <ikke> hmm, it's not make that is failing
2022-07-12 20:59:13 <ikke> ah, probably [ -z "$BOOTSTRAP" ] && make -C scripts/ returning non-zero
2022-07-12 20:59:34 <ikke> Adding a print statement after it fixed it :D
2022-07-12 21:02:18 <psykose> ~
2022-07-12 21:08:51 <ikke> https://tpaste.us/gZR5 :(
2022-07-12 21:11:39 <ikke> 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 <psykose> hmm
2022-07-12 21:13:38 <ikke> hmm
2022-07-12 21:13:47 <ikke> I think it gets overwritten?
2022-07-12 21:13:53 <ikke> as it's gone now
2022-07-12 21:14:11 <psykose> ah, yep, if you delete/reinstall meson it will get removed
2022-07-12 21:14:15 <psykose> just add it to world
2022-07-12 21:14:18 <psykose> then overwrite
2022-07-12 21:15:46 <ikke> meson.build:1:0: ERROR: Unknown linker(s): [['s390x-alpine-linux-musl-gcc-ar']]
2022-07-12 21:17:38 <psykose> what do you have in the cross root
2022-07-12 21:17:59 <psykose> just a tree of the bin folders in it or whatnot
2022-07-12 21:18:20 <ikke> no
2022-07-12 21:19:01 <ikke> https://tpaste.us/en0B 
2022-07-12 21:19:26 <psykose> well that has nothing at all, so the actual compiler is somewhere else..
2022-07-12 21:19:41 <ikke> Those are installed when running bootstrap.sh as packages
2022-07-12 21:19:45 <ikke> build-base-s390x
2022-07-12 21:19:54 <psykose> then the contents of that with build-base--s390x
2022-07-12 21:22:13 <ikke> trying to figure out how this gets installed
2022-07-12 21:22:55 <psykose> you could tar -tvf the .apk of wherever those are
2022-07-12 21:23:27 <psykose> alternatively.. i dunno, remove the ${CROSS_COMPILE} prefixes from all the things in abuild-meson
2022-07-12 21:23:35 <adhawkins> Not sure whether this should be here or in #alipne-linux. Tell me to move if more appropriate.
2022-07-12 21:23:49 <adhawkins> Anyone used pyusb under Alpine? When I try it, I get 'no backends available'.
2022-07-12 21:24:12 <adhawkins> 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 <adhawkins> Appreciate any advice.
2022-07-12 21:24:16 <ikke> s390x-alpine-linux-musl-gcc-ar
2022-07-12 21:24:28 <ikke> so it is there
2022-07-12 21:24:30 <ikke> psykose: 
2022-07-12 21:24:34 <ikke> this is part of gcc
2022-07-12 21:24:43 <psykose> hmm
2022-07-12 21:24:48 <psykose> why does it say it's a linker
2022-07-12 21:24:49 <psykose> weird
2022-07-12 21:25:30 <ikke> It's getting late for me
2022-07-12 21:25:45 <psykose> ah, maybe $LD gets set to AR for something, try delete that
2022-07-12 21:25:50 <psykose> or i guess i can try a bootstrap myself
2022-07-12 21:26:22 <adhawkins> 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 <psykose> adhawkins: do you have libusb installed
2022-07-12 21:31:59 <adhawkins> 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 <adhawkins> Actually, I assumed that those would pull in the actual library as well, is that true?
2022-07-12 21:36:40 <psykose> yes, not sure why it works for me and not you (though that dependency is normally missing)
2022-07-12 21:36:53 <adhawkins> This is the output I get: https://paste.debian.net/1247028/
2022-07-12 21:37:32 <psykose> ah
2022-07-12 21:37:34 <psykose> you have no /dev
2022-07-12 21:37:37 <psykose> just don't run this in a container :)
2022-07-12 21:37:55 <adhawkins> 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 <adhawkins> I want to run it on a synology NAS, which also doesn't have libusb.
2022-07-12 21:38:32 <psykose> 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 <adhawkins> Oh ok, let me try that.
2022-07-12 21:39:08 <psykose> (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 <psykose> ah, try /dev/bus/usb only
2022-07-12 21:40:01 <psykose> works for me
2022-07-12 21:41:20 <adhawkins> Hmm, not here...
2022-07-12 21:41:32 <adhawkins> My host OS is debian, not sure if that's a factor.
2022-07-12 21:45:46 <adhawkins>  /dev/bus/usb is in the container now. Odd.
2022-07-12 22:17:36 <psykose> 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 <psykose> 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 <psykose> 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 <sam_> i still use the cheesy makefile for zstd because of their weird support thing
2022-07-12 22:24:06 <sam_> everything but the makefiles are "contrib"
2022-07-12 22:31:19 <psykose> 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 <psykose> but iirc even the FindZSTD.cmake files are contrib? lol
2022-07-12 22:34:58 <psykose> 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 <psykose> (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 <psykose> ikke: also starting a s390x-rust bootstrap myself :)
2022-07-12 22:53:05 <psykose> 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 <psykose> 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 <psykose> 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 <psykose> which makes repo_template $PWD/community/.rootbld_repositories instead of the actual path
2022-07-13 01:06:02 <psykose> ghhh
2022-07-13 02:29:42 <craftyguy> I'm confused why this aports CI job is failing: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/768572
2022-07-13 02:34:38 <craftyguy> 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 <Hello71> do you not use an editor with syntax highlighting? are you also using notepad like Saijin_Naib 
2022-07-13 02:38:54 <Saijin_Naib> 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 <Saijin_Naib> 😛
2022-07-13 02:39:08 <ptrc> 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 <Hello71> i actually have no idea what's wrong here
2022-07-13 02:40:06 <psykose> unterminated string quote
2022-07-13 02:40:12 <Saijin_Naib> TBH, probably not using Notepad with my handwriting font with easily-distinguishable glyphs
2022-07-13 02:40:35 <Hello71> well i know what's wrong with the apkbuild
2022-07-13 02:40:43 <Hello71> 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 <Hello71> 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 <Hello71> hm, no, that's not right, because Changed aports in isn't printed
2022-07-13 02:44:35 <Hello71> 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 <Hello71> 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 <psykose> makes sense
2022-07-13 02:47:07 <Hello71> 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 <Hello71> but i don't think busybox ash has BASH_COMMAND or similar, at least from skimming the source
2022-07-13 02:51:45 <Hello71> or better, "$0: $BASH_SOURCE:$BASH_LINENO: $FUNCNAME running $BASH_COMMAND failed"
2022-07-13 02:51:56 <craftyguy> Hello71: vim, but I missed it somehow. also, please be nice.
2022-07-13 02:52:17 <Hello71> the notepad really is/was terrible though
2022-07-13 02:54:30 <Hello71> 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 <Saijin_Naib> 
ACTION uploaded an image: (46KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ZInwysGNwGwvkkhLEfxSCSww/image.png >

2022-07-13 02:59:09 <Saijin_Naib> Hello71, much better now, right?
2022-07-13 03:00:27 <Hello71> the title and menu bar are unreadable on my admittedly-crappy lcd monitor
2022-07-13 03:00:40 <craftyguy> amazing
2022-07-13 03:00:49 <Hello71> and it's very difficult to tell single and double quotes apart
2022-07-13 03:01:01 <Hello71> i mean '"'" just looks like '''''''''''''''
2022-07-13 03:01:26 <Hello71> and also upper and lowercase letters
2022-07-13 03:01:31 <Hello71> other than that i think it's fine
2022-07-13 03:01:58 <Hello71> oh, and also -X GET is unnecessary and discouraged
2022-07-13 03:02:24 <Saijin_Naib> 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 <Hello71> and i think you're using ' where $( should be used
2022-07-13 03:02:39 <Hello71> or at least you mean $( or ` which maybe your font doesn't even have
2022-07-13 03:02:45 <Saijin_Naib> What's your hourly rate?
2022-07-13 03:03:55 <Hello71> if i have to use that font, at least $500
2022-07-13 03:04:42 <Hello71> if you set your whole system to that font then no wonder you can't tell ` from '
2022-07-13 03:09:18 <Saijin_Naib> 
ACTION uploaded an image: (1704KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/vEzMufMxehTYJlsPtmWdRGMM/image.png >

2022-07-13 03:09:26 <Saijin_Naib> Nah, system is set to something reasonable
2022-07-13 03:09:34 <Saijin_Naib> 🤣️
2022-07-13 03:11:29 <Hello71> the biggest problem in the picture is the "Microsoft Bing"
2022-07-13 03:11:53 <Hello71> also the microsoft logo is just four squares now?
2022-07-13 03:12:14 <Saijin_Naib> Been such going on what, 7 years now? Launch of Windows 10
2022-07-13 03:12:39 <Saijin_Naib> 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 <Hello71> i thought it was just the windows logo but apparently it's all of microsoft?
2022-07-13 03:15:16 <Hello71> 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 <Hello71> (e.g. ц and ч look basically the same at crap resolution without a baseline)
2022-07-13 03:18:26 <Saijin_Naib> 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 <Saijin_Naib> 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 <Hello71> np :)
2022-07-13 03:22:44 <Hello71> 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 <psykose> 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 <sam_> psykose: re chromium, i don't know, but i have someone who might, i'll ask
2022-07-13 03:31:34 <sam_> psykose: re bootstrap: lol i did that recently
2022-07-13 03:31:39 <sam_> it was.. okay, but there's no real docs about it
2022-07-13 03:31:56 <psykose> :) 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 <psykose> think it might work this pass, if not, more stuff to try
2022-07-13 03:32:19 <psykose> i should also really convert this configure.py into the raw toml
2022-07-13 03:32:28 <sam_> i spent more time than i want to admit getting really pissed off at the tuple mangling
2022-07-13 03:32:33 <Hello71> are you crossing from amd64 musl or s390x glibc? maybe ibm did the latter
2022-07-13 03:32:35 <sam_> because it kept trying to coerce it into debian
2022-07-13 03:32:49 <Hello71> the latter sounds like it has a higher chance of "working"
2022-07-13 03:33:17 <psykose> 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 <psykose> or they never tried system llvm, if it builds in-rust-tree that would also work
2022-07-13 03:33:43 <Hello71> fuck if i know :)
2022-07-13 03:33:47 <psykose> same :)
2022-07-13 03:35:23 <sam_> i just did in-tree llvm because no pain thanks
2022-07-13 03:35:25 <sam_> also because rust seems to break often enough with system llvm anyway
2022-07-13 03:35:45 <Hello71> 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 <psykose> sam_: does it? i haven't seen anything in months with whatever llvm version
2022-07-13 03:36:58 <psykose> 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 <sam_> the latest issue was uh
2022-07-13 03:37:26 <sam_> 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 <sam_> (https://github.com/ogham/exa/issues/1068)
2022-07-13 03:37:32 <sam_> 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 <sam_> i was a bit pissed off they didn't do new binaries for it
2022-07-13 03:38:49 <psykose> 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 <sam_> right
2022-07-13 03:40:19 <sam_> and i guess in this case using system llvm actually saved me anyway
2022-07-13 03:40:22 <sam_> cause i could actually patch it
2022-07-13 03:41:02 <psykose> 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 <sam_> ok i might change my mind then
2022-07-13 03:42:06 <psykose> hey my memory isn't that great you should actually check!
2022-07-13 03:46:12 <psykose> also a default sysroot of '/' is valid right (just sanity checking)
2022-07-13 08:55:47 <ncopa> morning!
2022-07-13 08:56:48 <ikke> Morning 
2022-07-13 08:57:06 <ikke> Tried to bootstrap rust on s390x, but llvm13 failed 
2022-07-13 08:57:13 <ncopa> i think linux-firmware is broken
2022-07-13 08:57:19 <ncopa> + 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 <ncopa> 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 <ncopa> what error did you get for llvm13?
2022-07-13 09:00:39 <ikke> https://tpaste.us/gZR5
2022-07-13 09:14:32 <nmeum> psykose: nice work on the boostrap improvements, I will try to review it soonish :)
2022-07-13 09:42:15 <ncopa> problem with linux-firmware was upstream. i pushed a backport fix for it
2022-07-13 10:18:54 <ikke> Anyone an idea how to fix llvm13?
2022-07-13 10:19:20 <ikke> Tried searching for the error, but couldn't find anything
2022-07-13 10:22:27 <ncopa> ikke: no idea
2022-07-13 10:23:09 <ncopa> tmhoang: any idea how to fix crosscompile of llvm for s390x? https://tpaste.us/gZR5 ^^^
2022-07-13 10:52:28 <the6543[m]> just for interest how are the riscv builds done?
2022-07-13 10:52:28 <the6543[m]> since you cant find cheep physical bords to buy
2022-07-13 10:58:14 <ncopa> qemu i think
2022-07-13 11:00:25 <nmeum> yes, qemu
2022-07-13 11:00:49 <nmeum> 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 <ikke> qemu-user on a server, with the builds happening in a docker container atm
2022-07-13 11:32:09 <ncopa> 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 <ncopa> 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 <ikke> No PSK SAE here either
2022-07-13 11:34:10 <ncopa> 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 <donoban> only PSK here :\
2022-07-13 11:34:32 <ncopa> it would help with "PSK <anything>"
2022-07-13 11:34:48 <ncopa> thank you for trying though
2022-07-13 12:27:20 <Habbie> how did I not know about abump until today!
2022-07-13 12:27:26 <Habbie> it even generates a commit message
2022-07-13 12:36:49 <Ermine> Habbie: thank you for it
2022-07-13 15:19:17 <ikke> Habbie: do you know `apkgrel -a .` as well?
2022-07-13 15:19:28 <ikke> If you just need to bump the pkgrel for some reason
2022-07-13 15:19:49 <Habbie> oh, also neat
2022-07-13 15:19:57 <Habbie> usually i'd be editing then anyway, i guess
2022-07-13 15:20:00 <panekj> how about we have a single command that can do both
2022-07-13 15:20:02 <Habbie> abump saves me many steps
2022-07-13 19:19:34 <psykose> ikke: you don't need llvm13, and it's wrong
2022-07-13 19:19:50 <psykose> rust needs 14 and that builds fine
2022-07-13 19:20:16 <psykose> 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 <psykose> 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 <psykose> 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 <psykose> 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 <psykose> ah, no, ghc is even 12
2022-07-13 19:23:44 <psykose> but also disabled on s390x so doesn't matter
2022-07-13 19:26:57 <ikke> So remove llvm13 and add llvm14? 
2022-07-13 19:27:40 <ikke> And ghc was indeed skipped 
2022-07-13 19:42:24 <psykose> yeah, i merged the change for it even
2022-07-13 19:42:37 <ikke> ah, let met pull then
2022-07-13 19:42:53 <psykose> only thing not fixed is openrc and openssh, the rest should work
2022-07-13 19:43:10 <psykose> but once you get to rust you're gonna get uhh
2022-07-13 19:43:16 <ikke> Did you also fix curl?
2022-07-13 19:43:25 <ikke> not that it it matters now
2022-07-13 19:43:48 <psykose> yep
2022-07-13 19:43:49 <psykose> https://img.ayaya.dev/M9CVi0A11Dd6
2022-07-13 19:44:08 <ikke> lots of undefined stuff
2022-07-13 19:44:15 <psykose> 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 <psykose> i fixed all of that but it's the same undefined things
2022-07-13 19:44:31 <psykose> note this exact same path works on, say, x86_64->aarch64
2022-07-13 19:44:40 <psykose> also the merge request doesn't apply anymore, it needs rebasing
2022-07-13 19:44:43 <psykose> i can push all my changes to it if you want
2022-07-13 19:46:13 <ikke> I pulled the current changes and started to build again
2022-07-13 19:46:22 <psykose> i mean the rust merge request specifically for those
2022-07-13 19:46:29 <ikke> fine with me
2022-07-13 19:50:31 <psykose> lemme try one more small hunch first..
2022-07-13 19:59:41 <psykose> mm, nope
2022-07-13 19:59:56 <ikke> still building llvm14 here 
2022-07-13 20:00:01 <psykose> sigh, no idea really
2022-07-13 20:01:45 <bl4ckb0ne> is ayakael on this chan?
2022-07-13 20:02:24 <panekj> I told them to join once but I think it never happened
2022-07-13 20:02:39 <ikke> I have a feeling openresolv is broken since recent
2022-07-13 20:02:44 <ikke> in the sense that it's not activated
2022-07-13 20:02:57 <ikke> resolvconf -c <interface> works
2022-07-13 20:03:09 <panekj> bl4ckb0ne: what's the problem?
2022-07-13 20:03:12 <ikke> But after a dhcp refresh it's reset again
2022-07-13 20:13:20 <bl4ckb0ne> just more info about that jellyfin port
2022-07-13 20:13:28 <bl4ckb0ne> the runtimes are a bloody mess
2022-07-13 20:13:47 <bl4ckb0ne> there's the alpine-arch ones and the linux-musl-arch ones that looks like dupes
2022-07-13 20:14:24 <panekj> unfortunately dotnet is mess
2022-07-13 20:15:12 <bl4ckb0ne> thats jellyfin
2022-07-13 20:15:22 <bl4ckb0ne> i really dont know why they have that
2022-07-13 20:15:26 <panekj> which is made in dotnet
2022-07-13 20:15:39 <panekj> I mean whole dotnet ecosystem
2022-07-13 20:16:07 <bl4ckb0ne> there's libe_sqlite3.so that I think alpine ships
2022-07-13 20:16:17 <bl4ckb0ne> and libSkiaSharp.so that we have to package
2022-07-13 20:16:28 <bl4ckb0ne> if the runtime folder is not there, jellyfin will not start
2022-07-13 20:19:00 <bl4ckb0ne> 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 <ikke> psykose: hmm, for some reason it does not build rust
2022-07-13 20:20:33 <ikke> it finished building the kernel
2022-07-13 20:20:39 <ikke> ah
2022-07-13 20:20:45 <ikke> rust is disabled still
2022-07-13 20:21:30 <bl4ckb0ne> panekj: maybe a relevant thread https://github.com/jellyfin/jellyfin/issues/528
2022-07-13 20:21:47 <bl4ckb0ne> im sure symlinking the runtimes first would be a decent workaround
2022-07-13 20:22:23 <bl4ckb0ne> but idk if sqlite3 provides libe_sqlite3.so,
2022-07-13 20:29:35 <psykose> i'm pretty sure it's the same thing renamed
2022-07-13 20:32:41 <psykose> the compiler-builtins.rlib is indeed missing like all those symbols or whatnot
2022-07-13 20:33:06 <ikke> How should udhcp know that it should yield to resolvconf?
2022-07-13 20:34:03 <panekj> 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 <ikke> oh, I could just disable it from updating resolv.conf
2022-07-13 20:36:23 <psykose> hmm
2022-07-13 20:36:29 <psykose> what if i didn't use systemllvm for bootstrap
2022-07-13 20:36:47 <ikke> Is that a specific llvm configuration?
2022-07-13 20:37:02 <bl4ckb0ne> panekj: my bad, i thought you were ayakael
2022-07-13 20:46:12 <psykose> 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 <ikke> aha ok
2022-07-13 20:46:28 <psykose> the compiler-builtin missing symbols normally come from llvm, i'm wondering if it's somehow miscompiled
2022-07-13 20:46:36 <psykose> just a quick test
2022-07-13 20:46:38 <ikke> ok
2022-07-13 20:47:04 <psykose> 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 <ikke> psykose: I suppose you arlready fixed https://tpaste.us/PjXy ?
2022-07-13 20:47:28 <psykose> yeah, that needed a rebase of the thing
2022-07-13 20:47:28 <psykose> sec
2022-07-13 20:47:32 <ikke> psykose: sure, I'm multi-tasking all the time :)
2022-07-13 20:47:57 <psykose> https://img.ayaya.dev/cXyl8LQyk60h
2022-07-13 20:47:57 <psykose> here
2022-07-13 20:48:01 <psykose> rebased version of the MR commit
2022-07-13 20:48:24 <psykose> 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 <psykose> that will get you to my failure above
2022-07-13 21:13:26 <psykose> ikke: https://img.ayaya.dev/jqMFK826UVwR.png :)
2022-07-13 21:22:01 <psykose> tip: don't full-lto llvm with 16 threads all doing lto at once
2022-07-13 21:22:13 <ikke> You needheh
2022-07-13 21:22:17 <ikke> hmm
2022-07-13 21:22:44 <ikke> psykose: I'm now at the same point you are
2022-07-13 21:22:46 <ikke> with rust
2022-07-13 21:22:57 <psykose> yep
2022-07-13 21:23:11 <psykose> 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 <boomanaiden154> 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 <boomanaiden154> 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 <psykose> the issue was more actually the disk i/o, hah
2022-07-13 21:38:06 <psykose> 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 <psykose> easy to override and set them to 2 i guess
2022-07-13 21:38:58 <boomanaiden154> Issue was disk I/O in terms of swap space or just disk I/O in general?
2022-07-13 21:40:43 <psykose> 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 <psykose> (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 <psykose> with less link jobs you dodge all of that at once, yeah
2022-07-13 21:42:32 <psykose> the current jobs are also 5G of ram per thread, so 2 seems like the lucky choice
2022-07-13 21:42:43 <boomanaiden154> Ah. That makes sense. Perhaps the solution is just NVME RAID. :p
2022-07-13 21:44:29 <psykose> what i don't understand is why it does lto at all
2022-07-13 21:44:44 <psykose> nothing passes the LLVM_ENABLE_LTO anywhere..
2022-07-13 21:45:01 <boomanaiden154> The rust vendored LLVM?
2022-07-13 21:45:04 <psykose> ye
2022-07-13 21:45:39 <psykose> no sign of -flto in any generated build files
2022-07-13 21:46:08 <psykose> cmakecache shows =OFF
2022-07-13 21:46:22 <psykose> 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 <psykose> unless that doesn't imply anything
2022-07-13 21:55:09 <psykose> error: failed to build archive: invalid e_shentsize in ELF header: 16384
2022-07-13 21:55:11 <psykose> okay, okay..
2022-07-14 01:24:07 <psykose> slowly losing my sanity after 2 days of this
2022-07-14 01:52:39 <psykose> 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 <psykose> wonder what causes that
2022-07-14 02:10:00 <sam_> i'm sending positive vibes psykose 
2022-07-14 02:10:16 <psykose> i think i figured out the main issue, but it will probably fail different now
2022-07-14 02:10:42 <psykose> it builds the vendored llvm compiler-rt stuff for the compiler-builtin things for.. something? idk
2022-07-14 02:10:56 <psykose> except compiler-rt-builtins don't have anything for s390x
2022-07-14 02:11:06 <psykose> or maybe i'm wrong for the 11th time in a row, that is more likely
2022-07-14 02:21:07 <earboxer> Is lists.alpinelinux.org broken right now?
2022-07-14 02:21:22 <psykose> yes
2022-07-14 02:21:32 <psykose> (for patches)
2022-07-14 02:21:40 <psykose> for actual mailing, not sure, worked earlier today
2022-07-14 02:22:46 <earboxer> 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 <psykose> no idea :) also no idea when it will be fixed
2022-07-14 02:24:35 <psykose> maybe in a few days
2022-07-14 02:24:38 <psykose> it's being rewritten entirely
2022-07-14 02:24:51 <earboxer> interesting, thanks for the info!
2022-07-14 03:11:30 <psykose> and nnope still broken the exact same way
2022-07-14 06:48:39 <ncopa> morning!
2022-07-14 06:49:06 <ncopa> looks dotnet is blocking the (32bit) arm builders
2022-07-14 07:04:24 <ikke> 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 <ncopa> when was the new  pubkeys added?
2022-07-14 07:06:48 <ncopa> yes, if we do the switch index would pick up the new key immediately
2022-07-14 07:06:55 <ncopa> packages will do it gradually
2022-07-14 07:13:13 <ncopa> i would like to do releases
2022-07-14 07:17:13 <ikke> For 3.15
2022-07-14 07:17:33 <ikke> So should be widespread now 
2022-07-14 07:21:08 <ncopa> ok
2022-07-14 07:22:26 <ncopa> 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 <ncopa> cannot resolve host: tarball
2022-07-14 07:23:30 <ikke> 🤔
2022-07-14 07:24:59 <ncopa> seems like dotnet6-build pulls something from version .106 from microsofts servers, whichc responds with temproarily unavailable
2022-07-14 07:25:28 <ncopa> https://tpaste.us/9b84
2022-07-14 07:25:59 <ncopa> can we nuke dotnet? who uses it anyways?
2022-07-14 07:26:36 <ikke> Someone did quite some effort to port it to Alpine 
2022-07-14 07:27:12 <ncopa> 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 <ncopa> sorry. i should eat breakfast before i continue
2022-07-14 07:29:11 <psykose> the reason it's frozen is because 4 of them are building at once on the same machine
2022-07-14 07:29:34 <ncopa> were they manually frozen?
2022-07-14 07:29:40 <psykose> no
2022-07-14 07:29:54 <ncopa> can we manually freeze 3 of them?
2022-07-14 07:30:07 <psykose> just have to kill the 3.16 ones
2022-07-14 07:30:20 <psykose> or well, all 4, and restart master
2022-07-14 07:30:23 <ncopa> i dont want to kill it
2022-07-14 07:30:29 <ncopa> just freeze it
2022-07-14 07:31:11 <psykose> not sure what the point of that would be
2022-07-14 07:31:37 <ncopa> give enough resources for the 4th to complete without restart?
2022-07-14 07:32:05 <ncopa> im gonna have breakfast now
2022-07-14 07:32:20 <ncopa> seems liek the cpu usage is not that bad on the arm machine
2022-07-14 07:32:36 <ncopa> and memory usage is not on the roof either
2022-07-14 07:34:17 <ncopa> but it does not explain why i cannot build it on my laptop
2022-07-14 07:38:17 <psykose> the error was 'Network unreachable'
2022-07-14 07:38:52 <psykose> which is not a 404 or anything usually related to the actual remote (i can build it fine)
2022-07-14 08:02:24 <ncopa> maybe it tried ipv6? i dunno
2022-07-14 08:02:47 <ncopa> so we reboot the 3.16 builders?
2022-07-14 08:03:02 <ncopa> how do we unblock the builders?
2022-07-14 08:08:00 <psykose> you kill all the jobs and restart master only and wait i guess
2022-07-14 08:08:07 <psykose> (or freeze, same thing)
2022-07-14 08:08:24 <psykose> 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 <psykose> there's other aports that do the same, but usually you get oom's instead of actual freezing
2022-07-14 09:09:30 <ncopa> ok. i killed build-{3-16,edge}-{aarch64,armv7}
2022-07-14 09:09:52 <ncopa> and restarted build-edge-armv7. I will reboot build-edge-aarch64 once armv7 is done
2022-07-14 09:10:38 <ncopa> 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 <psykose> it's my best guess, not sure why it wouldn't self terminate from that
2022-07-14 09:12:40 <psykose> 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 <ikke> I did make space again yesterday evening 
2022-07-14 09:32:09 <hcshmk> Are there any plans for enabling the kexec syscall for the kernel packaged as "linux-lts"?
2022-07-14 09:33:33 <psykose> i find it funny how it's enabled for ppc64le only
2022-07-14 09:33:55 <hcshmk> Wait does powerpc have kexec currently? linux-lts for 3.16?
2022-07-14 09:34:36 <psykose> apparently, it's in the config
2022-07-14 09:34:39 <hcshmk> Odd
2022-07-14 09:36:00 <hcshmk> 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 <hcshmk> And unfortunately our embedded devices don't run ppc but x86_64
2022-07-14 09:45:33 <ncopa> 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 <ncopa> re kexec
2022-07-14 09:45:44 <ncopa> > 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 <ncopa> which is why we have not enabled it
2022-07-14 09:46:37 <ncopa> however, it seems that there are a sysctl knob for it? kernel.kexec_load_disabled=1
2022-07-14 09:47:15 <ncopa> i wouldnt mind having it built into the kernel if we have it disabled by default
2022-07-14 09:48:45 <hcshmk> 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 <psykose> it's also disable-once which is nice
2022-07-14 09:49:21 <hcshmk> Could we try it out on linux-lts@edge?
2022-07-14 09:56:23 <ncopa> so, im thinking that we could have it off by default at boot, unless enabled from cmdline
2022-07-14 09:56:59 <ncopa> but i wonder if we can enable it if its off by default
2022-07-14 09:57:11 <ncopa> as its disable-once thing
2022-07-14 09:58:40 <ncopa> i dont want disable it in our sysctl default config or in initramfs or in our cmdline
2022-07-14 09:58:46 <ncopa> (if possible to avoid)
2022-07-14 09:59:30 <hcshmk> Why would you prefer to not have it in sysctl.conf? Just curious
2022-07-14 10:00:08 <ncopa> because then there is a window before sysctl is run where you can inject kernel backdoors
2022-07-14 10:00:37 <ncopa> and sysctl.conf "service" might be disabled (for whatever reason)
2022-07-14 10:00:57 <ncopa> i generally prefer locked down by default, and then open up as needed
2022-07-14 10:01:49 <ncopa> 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 <hcshmk> Makes perfect sense, thanks for the explanation
2022-07-14 11:19:13 <hcs> @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 <hcs> It seems that once kexec has been disabled, it cant be re-enabled before next boot. 
2022-07-14 11:23:21 <ikke> yes, that's what they mean with disable once
2022-07-14 11:23:50 <ikke> 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 <psykose> 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 <ikke> Unless it's to _enable_ it
2022-07-14 11:42:16 <psykose> yep
2022-07-14 11:42:44 <psykose> 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 <psykose> so strange
2022-07-14 11:46:25 <hcs> 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 <ncopa> boot option to allow kexec: https://tpaste.us/nVRv
2022-07-14 11:52:38 <hcs> 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 <ncopa> 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 <psykose> ncopa: was there any downside to adding -none firmware to the makedeps for kernel?
2022-07-14 11:58:24 <psykose> so it doesn't install all of those every time
2022-07-14 11:59:07 <psykose> 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 <hcs> 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 <ncopa> hcs: i havent pushed it anywhere. I created it for discussion
2022-07-14 12:07:19 <ncopa> hcs: maybe you can create an issue for kexec support in our bugtracker?
2022-07-14 12:07:25 <ncopa> so we can discuss it there
2022-07-14 12:08:55 <ncopa> other option is to have a `kexec_load_enable?  boot option or similar
2022-07-14 12:09:16 <ncopa> or maybe even `kexec_load=0|1`
2022-07-14 12:09:41 <ncopa> but kexec_load_disable corresponds to the sysctl, which is nice
2022-07-14 12:14:36 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/8400
2022-07-14 12:17:36 <ncopa> 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 <hcs> I'll create an issue
2022-07-14 12:17:51 <ncopa> as it would uninstall all the firmware during build
2022-07-14 12:18:51 <psykose> linux-firmware and linux-firmware-none at the same time has all the firmware installed
2022-07-14 12:19:27 <ikke> Most users would not have linux-firmware installed explicitly
2022-07-14 12:38:03 <hcs> 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 <ncopa> hcs: thanks!
2022-07-14 12:58:57 <ncopa> psykose: I'm ok as long as it does not uninstall any firmware while building the kernel
2022-07-14 12:59:32 <psykose> 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 <ncopa> what i do in my containers is to install linux-firmware-none
2022-07-14 13:05:09 <ikke> me too
2022-07-14 13:05:24 <ncopa> we could probably do so on the builders as well
2022-07-14 13:22:19 <hcs> ncopa will the CI pipelines still run if i fork aports in order to make a MR?
2022-07-14 13:33:15 <ncopa> not sure. i think you may need to enable the shared runner and have your fork public
2022-07-14 13:46:22 <ikke> That should work by default
2022-07-14 13:49:53 <ikke> ncopa: so I'm going to switch the edge builders to the new key
2022-07-14 13:50:17 <Hello71> ncopa: what is the point of disabling kexec without disabling or signing modules
2022-07-14 13:50:53 <Hello71> "13:05 <ncopa> 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 <Hello71> actually i think i suggested doing this for alpine-gitlab-ci/build-base, but similar idea
2022-07-14 13:52:10 <ikke> ncopa: should we make some anouncement somewhere about edge keys changing?
2022-07-14 14:16:17 <ncopa> ikke: i think that would be a good idea
2022-07-14 14:17:05 <ncopa> Hello71: adding linux-firmware-none to  alpine-gitlab-ci/build-base sound slike an excellent idea
2022-07-14 14:20:29 <Hello71> i would have sent MR but i couldn't decide between alpine-gitlab-ci, build-base, and alpine
2022-07-14 14:22:32 <ikke> 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 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/48
2022-07-14 15:09:32 <ncopa> ikke: merged to master
2022-07-14 15:10:14 <ncopa> 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 <ikke> ncopa: alright, we start setting the new signing keys then
2022-07-14 15:33:57 <ncopa> great! thanks!
2022-07-14 15:37:27 <ikke> ncopa: done
2022-07-14 15:38:43 <ikke> Pushing the anouncement to production now
2022-07-14 15:39:19 <ncopa> 👍
2022-07-14 16:09:59 <psykose> boomanaiden154: nvm, spoke too soon.. everything worked with pgo then back to the same oom trick
2022-07-14 16:09:59 <psykose> gr
2022-07-14 17:23:44 <GeorgiosOPapadopoulos[m]> hello
2022-07-14 17:23:44 <GeorgiosOPapadopoulos[m]> has any one successfully installed either mit-scheme or reduce cas?
2022-07-14 17:24:03 <GeorgiosOPapadopoulos[m]> It seems there is a problem with both of them
2022-07-15 05:50:21 <ncopa> i tagged an edge release
2022-07-15 06:24:00 <ncopa> something went wrong with aarch64 edge release
2022-07-15 06:24:57 <ncopa> the latest-releases.yaml didnt add minirootfs entry
2022-07-15 06:24:59 <ncopa> dont know why
2022-07-15 06:38:47 <ncopa> i know why
2022-07-15 06:39:08 <ncopa> release scripts are buggy
2022-07-15 15:53:05 <skarnet> original dl site?
2022-07-15 15:53:05 <skarnet> 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 <psykose> i don't think the tarball would be the same
2022-07-15 15:56:48 <psykose> if the only difference is needing to run autoreconf then i guess it would be alright
2022-07-15 15:56:54 <psykose> australia one worked for me
2022-07-15 15:57:14 <skarnet> 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 <skarnet> so it's one of the rare cases where the gh-provided tarball is usable
2022-07-15 15:58:40 <skarnet> how the heck is it working for you
2022-07-15 16:00:58 <skarnet> ah, got it, it only works with ipv6. But still provides an A record. -_-
2022-07-15 16:01:29 <psykose> LMAO
2022-07-15 16:01:49 <psykose> welcom to the future :)
2022-07-15 16:01:52 <skarnet> 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 <psykose> mine doesn't either i'm using a HE tunnel
2022-07-15 16:02:59 <skarnet> 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 <psykose> ~
2022-07-15 16:03:31 <ptrc> hm, it works over ipv4 though?
2022-07-15 16:03:48 <skarnet> it hasn't worked for me in over 5 years
2022-07-15 16:04:26 <ptrc> 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 <psykose> i think you got some weird geomeme routing then
2022-07-15 16:04:56 <psykose> try a traceroute to it
2022-07-15 16:05:04 <ptrc> wait, but it's cloudflare
2022-07-15 16:05:19 <psykose> 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 <ptrc> i don't think it's possible to compare v4 traces to v6 :p
2022-07-15 16:06:07 <psykose> by changes i mean breaks
2022-07-15 16:06:11 <ptrc> unless you look up every ASN on the way or something
2022-07-15 16:07:23 <skarnet> 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 <skarnet> so maybe it's an ISP blockade, not a v4 blockade
2022-07-15 16:09:40 <ptrc> i don't think regular customers can drop traffic, so if cloudflare blocked your isp, condolences
2022-07-15 16:11:18 <skarnet> it can't be the only site I access that uses Cloudflare though
2022-07-15 16:11:48 <skarnet> can you give me another well-known Cloudflare customer domain, so I can test?
2022-07-15 16:14:12 <skarnet> 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 <skarnet> that's interesting, man traceroute doesn't say what !A means
2022-07-15 16:14:39 <skarnet> "administratively prohibited" would be !X
2022-07-15 16:15:16 <psykose> !A is too
2022-07-15 16:15:39 <skarnet> thanks, incomplete man
2022-07-15 16:15:51 <psykose> aren't we all
2022-07-15 16:16:15 <skarnet> I should have thought of this one
2022-07-15 16:19:14 <ptrc> as for cf customers, fiverr.com and canva.com seem to be using similar ip blocks
2022-07-15 16:19:36 <ptrc> but as with any networking giant, ymmv
2022-07-15 16:20:07 <skarnet> 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 <ptrc> does it drop packets completely?
2022-07-15 16:20:45 <skarnet> I suppose, because a normal connection times out instead of telling me it's rejected
2022-07-15 16:20:50 <skarnet> only traceroute says !A
2022-07-15 16:20:54 <ptrc> ah, that's.. weird, matt.ucc.asn.au returns the same address for me as just ucc.
2022-07-15 16:21:11 <skarnet> even with v4?
2022-07-15 16:21:22 <ptrc> yeah, i mean specifically v4 addresses
2022-07-15 16:22:08 <skarnet> disagree:
2022-07-15 16:22:13 <skarnet> alpine:~$ s6-dnsip4 matt.ucc.asn.au
2022-07-15 16:22:13 <skarnet> alpine:~$ s6-dnsip4 ucc.asn.au
2022-07-15 16:22:13 <skarnet> 130.95.13.18
2022-07-15 16:22:13 <skarnet> 104.26.8.126
2022-07-15 16:22:13 <skarnet> 172.67.72.143
2022-07-15 16:22:14 <skarnet> 104.26.9.126
2022-07-15 16:23:16 <ptrc> 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 <skarnet> I'm using my own DNS resolver, tyvm
2022-07-15 16:24:16 <skarnet> the answers I gave are exactly the ones published by the DNS servers out there
2022-07-15 16:25:17 <ptrc> d.au seems to return fay.ns.cloudflare.com. and leland.ns.cloudflare.com. for ucc.asn.au
2022-07-15 16:25:32 <psykose> https://img.ayaya.dev/W11kL5BjBVBY
2022-07-15 16:25:35 <psykose> where does this 130 come from
2022-07-15 16:26:10 <ptrc> s/d.au/t.au/
2022-07-15 16:26:10 <alpine-meetbot> 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 <skarnet> psykose: okay, time for some serious DNS investigation. That I know how to do.
2022-07-15 16:26:46 <psykose> ~
2022-07-15 16:27:24 <psykose> even more results for fun: https://dnschecker.org/#A/matt.ucc.asn.au
2022-07-15 16:36:31 <skarnet> okay, thank you both for your help, it's working, nothing to see here, move along
2022-07-15 16:36:49 <psykose> what happened? :)
2022-07-15 16:37:05 <skarnet> what part of "move along" do you not understand
2022-07-15 16:37:17 <psykose> 
ACTION moves alone

2022-07-15 16:37:17 <ikke> :D
2022-07-15 16:37:20 <psykose> along*
2022-07-15 16:37:21 <psykose> gdi
2022-07-15 16:37:28 <skarnet> freudian slip
2022-07-15 16:37:31 <psykose> nothing to see there either, move along :)
2022-07-15 16:37:54 <skarnet> I'll show you mine if you show me yours
2022-07-15 16:38:14 <psykose> kinky
2022-07-15 16:47:37 <skarnet> 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 <skarnet> the other ones don't work ootb, but at least they *build*
2022-07-15 16:48:06 <skarnet> jfc
2022-07-15 17:58:45 <panekj> it's always dns
2022-07-15 17:59:34 <skarnet> 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 <Habbie> 
ACTION looks up

2022-07-16 00:12:01 <psykose> 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 <psykose> 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 <psykose> ah, seems the github mirror tarballs are actually identical..
2022-07-16 00:18:18 <craftyguy> so you found it?
2022-07-16 00:18:19 <psykose> yep, aside from mtime they're completely the same
2022-07-16 00:18:22 <psykose> indeed i did
2022-07-16 00:18:26 <psykose> thanks random github mirror
2022-07-16 00:18:31 <craftyguy> ah nice. I started looking too :P
2022-07-16 00:19:04 <psykose> `diffoscope --exclude-directory-metadata=yes` is squeaky clean for latest
2022-07-16 00:22:01 <craftyguy> does the sha512 match?
2022-07-16 00:22:50 <psykose> no, due to the metadata difference
2022-07-16 00:22:58 <craftyguy> ah ok
2022-07-16 11:04:10 <nmeum> 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 <Ariadne> it was just a local fix i was trying
2022-07-16 13:11:16 <sam_> psnszsn: you should see the bullshit i came up with
2022-07-16 13:11:20 <sam_> sorry psykose *
2022-07-16 13:12:05 <sam_> the huge PATCH ARRAY
2022-07-16 13:12:07 <sam_> i didn't realise he actually yanked the old rollup tarballs though
2022-07-16 16:01:48 <ikke> boomanaiden154: I see that you created https://github.com/boomanaiden154/matplotlib-test-images
2022-07-16 16:01:55 <ikke> is it possible to include rv64 as well?
2022-07-16 16:03:28 <boomanaiden154> Yes. I should be able to do that.
2022-07-16 16:03:45 <ikke> I was trying to test if it builds again on rv64
2022-07-16 16:04:02 <boomanaiden154> Were you able to get it building?
2022-07-16 16:04:27 <ikke> Not yet, I'll skip the prepare step that it's blocking on now
2022-07-16 16:13:39 <ikke> It doesn't seem to fail on configure anymore at least, which is why I (apparently) disabled it
2022-07-16 16:13:44 <ikke> waiting for the build to finish
2022-07-16 16:16:45 <boomanaiden154> Okay. I’ll try and get a commit in this afternoon to enable test image generation on riscv.
2022-07-16 16:17:05 <ikke> alright
2022-07-16 16:17:15 <boomanaiden154> 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 <boomanaiden154> (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 <umk3> ptrc: hi, do you maintain the labwc package?
2022-07-16 16:21:51 <ikke> boomanaiden154: ok, build succeeded
2022-07-16 16:39:42 <ikke> 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 <ikke> 'images not close
2022-07-16 16:40:26 <ikke> 880 failed, 5897 passed, 1585 skipped, 13 xfailed
2022-07-16 16:41:58 <ikke> I'll await your update :)
2022-07-16 16:43:20 <boomanaiden154> 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 <boomanaiden154> Still some with arch specific images (mostly on ppc64), but significantly less.
2022-07-16 16:43:44 <boomanaiden154> ikke: https://github.com/boomanaiden154/matplotlib-test-images/actions/runs/2682510504
2022-07-16 16:43:55 <ikke> Just out of curiosity, what causes these differences between arches? Different floating point handling?
2022-07-16 16:45:03 <boomanaiden154> 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 <ikke> Great, thank you
2022-07-16 16:47:30 <boomanaiden154> 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 <ikke> ok
2022-07-16 16:49:02 <boomanaiden154> 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 <boomanaiden154> ikke: Riscv test images for matplotlib should be there.
2022-07-16 18:27:36 <ikke> ok, let me check
2022-07-16 18:27:58 <boomanaiden154> Hopefully they work well.
2022-07-16 18:29:06 <ikke> checksums haven't changed
2022-07-16 18:29:16 <ikke> oh, need to remove cache :P
2022-07-16 18:31:29 <ikke> boomanaiden154: still don't see riscv64 in the archive
2022-07-16 18:32:07 <ikke> 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 <boomanaiden154> It’s not under riscv64?
2022-07-16 18:34:28 <boomanaiden154> Oh. I probably forgot to change the script that copies the files over.
2022-07-16 18:35:11 <boomanaiden154> $CARCH in an APKBUILD on riscv on Alpine just evaluates to riscv64, right?
2022-07-16 18:35:17 <ikke> yes
2022-07-16 18:38:11 <boomanaiden154> 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 <boomanaiden154> Sorry about that’s
2022-07-16 18:38:19 <boomanaiden154> *that
2022-07-16 18:38:58 <ikke> No worry, happens
2022-07-16 19:47:17 <raspbeguy> 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 <ikke> The builders do not have docker running
2022-07-16 19:48:11 <raspbeguy> Is that something acceptable in a package to require docker compose as a test dependency ?
2022-07-16 19:49:07 <ikke> There is no docker running, so those tests would fail
2022-07-16 19:49:36 <panekj> tests should be skipped
2022-07-16 19:50:37 <raspbeguy> And if I add `checkdepends="py3-pytest"`
2022-07-16 19:50:49 <raspbeguy> Woops wrong paste 
2022-07-16 19:51:15 <raspbeguy> `checkdepends="docker-compose"`
2022-07-16 19:51:31 <ikke> That would not suddenly make docker available
2022-07-16 19:51:43 <ikke> And docker won't run on the builders
2022-07-16 19:54:03 <raspbeguy> Ok
2022-07-16 20:43:33 <raspbeguy> 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 <ikke> https://pkgs.alpinelinux.org/package/edge/main/x86_64/pythonispython3
2022-07-16 20:46:50 <ikke> I don't think there is a helper to automatically patch these scripts
2022-07-16 20:49:16 <raspbeguy> I see
2022-07-16 20:50:01 <panekj> wasn't there supposed to be symlink by default since we dropped py2?
2022-07-16 20:51:29 <raspbeguy> Apparently there isn't 
2022-07-16 20:51:43 <panekj> that I already know
2022-07-16 20:56:13 <ikke> I suppose it's still on someones todo list
2022-07-16 20:57:38 <humm> Why should there be such a symlink? The correct shebang for Python 3 arguably ends in python3.
2022-07-16 20:58:00 <psykose> sam_: it's really a work of art lmao
2022-07-16 20:59:41 <psykose> ikke: not really a todo list, but i can do it if you want
2022-07-16 21:01:48 <psykose> 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 <raspbeguy> psykose: yes
2022-07-16 21:02:46 <psykose> in this case, you should patch it
2022-07-16 21:03:32 <raspbeguy> Hum I fixed it by just adding pythonispython3 as a dependency 
2022-07-16 21:04:22 <psykose> that's not for anything to depend on :)
2022-07-16 21:04:31 <raspbeguy> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36468
2022-07-16 21:04:51 <raspbeguy> Why not?
2022-07-16 21:09:55 <psykose> because it's the equivalent of just removing it and adding the symlink to main/python3 anyway
2022-07-16 21:10:08 <psykose> 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 <raspbeguy> psykose: ok so in this case you think it's better to patch?
2022-07-16 21:32:51 <raspbeguy> If so I'll do it later
2022-07-16 21:34:46 <psykose> yes
2022-07-16 22:37:46 <nmeum> 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 <boomanaiden154> ikke: Test images for riscv64 should hopefully be ready now.
2022-07-17 05:35:48 <ikke> boomanaiden154: it indeed now contains the riscv64 directory. Running the test suite now
2022-07-17 05:35:54 <ikke> boomanaiden154: thanks
2022-07-17 05:45:53 <boomanaiden154> ikke: Did all the tests pass with the updated images?
2022-07-17 05:48:10 <ikke> Still running, but everything seems geen (or skipped) so far
2022-07-17 05:50:25 <ikke> 6777 passed, 1585 skipped, 12 xfailed, 1 xpassed
2022-07-17 05:53:49 <ikke> boomanaiden154: so yes, everythign passed
2022-07-17 05:55:01 <boomanaiden154> Nice. Wasn’t that easy on some of the other architectures.
2022-07-17 05:55:09 <boomanaiden154> I’m assuming I’ll see a PR soon to enable support?
2022-07-17 05:55:20 <ikke> yes
2022-07-17 05:55:35 <boomanaiden154> Thank you for your work on this.
2022-07-17 05:59:27 <ikke> np
2022-07-17 06:00:06 <ikke> boomanaiden154: FYI, on CI we don't have riscv64 yet, so we cannot verify there if it works
2022-07-17 06:01:25 <ikke> !36472
2022-07-17 06:05:00 <boomanaiden154> 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 <ikke> boomanaiden154: yes
2022-07-17 06:45:05 <ikke> boomanaiden154: passed on the builder :)
2022-07-17 06:45:22 <ikke> as well as the other package that was blocked by py3-matplotlib
2022-07-17 11:07:21 <telmich> good day everyone
2022-07-17 11:08:56 <ikke> telmich: o.
2022-07-17 11:08:59 <ikke> o/
2022-07-17 11:25:44 <telmich> :)
2022-07-17 11:26:06 <telmich> I'll need to setup a matrix<->irc bridge, probably using heisenbridge to be more present here
2022-07-17 14:39:35 <wyk72> hello
2022-07-17 14:40:28 <wyk72> 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 <wyk72> asterisk 18 apk is also missing macro module:
2022-07-17 14:56:30 <wyk72> 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 <wyk72> it's hard to recompile it all on armv7
2022-07-17 14:57:38 <ikke> Nothing seems to provide app_macro.so
2022-07-17 15:02:54 <wyk72> afaik is an option while compiling asterisk
2022-07-17 15:03:03 <wyk72> i.e. "macros" module
2022-07-17 15:03:19 <wyk72> on the select menu
2022-07-17 15:03:41 <wyk72> at least that's what usually is done in armbian compiles
2022-07-17 15:03:49 <ikke> wyk72: I'd say open an issue on gitlab.alpinelinux.org/alpine/aports/-/issues
2022-07-17 15:03:56 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues
2022-07-17 15:04:09 <wyk72> thanks I'll do that
2022-07-17 17:43:44 <ptrc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920
2022-07-17 17:45:07 <psykose> brb adding more patches
2022-07-17 17:45:12 <psykose> was planning to do that anyway
2022-07-17 17:54:52 <sam_> i was just about to link that lol
2022-07-17 17:55:04 <sam_> beautiful
2022-07-17 17:58:35 <Ariadne> first of all, the rust foundation is an entirely different entity
2022-07-17 18:00:02 <sam_> (fwiw from what I can tell, I don't think he represents the RF)
2022-07-17 18:01:56 <Ariadne> secondly, there is a porting clause that should be sufficient to allow distributions to do their work
2022-07-17 18:02:10 <Ariadne> i do not think this is a big deal
2022-07-17 20:09:06 <orbea> 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 <panekj> inb4 freight and erosion
2022-07-17 23:06:14 <ptrc> 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 <ptrc> hey, how does one get the reporter role on gitlab?
2022-07-18 05:34:46 <panekj> ptrc: is it?
2022-07-18 08:14:03 <ikke> ptrc: there is no formal process for that atm
2022-07-18 08:14:21 <ikke> My idea was to add all package maintainers as reporters
2022-07-18 08:14:28 <panekj> what does reporter do
2022-07-18 08:14:40 <ikke> Allows you to set labels on issues
2022-07-18 08:14:52 <ikke> but, it also makes it easier to @ people
2022-07-18 08:15:32 <panekj> mhm, you wanted to add *all* package maintainers to reporters?
2022-07-18 08:15:38 <panekj> don't think that's a good idea :P
2022-07-18 15:34:01 <ncopa> im tagging 3.16.1 now
2022-07-18 17:24:13 <craftyguy> panekj: why isn't that a good idae?
2022-07-18 17:24:17 <craftyguy> s/idae/idea/
2022-07-18 17:24:17 <alpine-meetbot> craftyguy meant to say: panekj: why isn't that a good idea?
2022-07-18 17:25:03 <panekj> why giving access to create mess to random people is not a good idea?
2022-07-18 17:35:20 <ikke> Oh, there is also a guest role
2022-07-18 17:37:29 <ikke> Guest appears to be pretty harmless
2022-07-18 21:00:33 <craftyguy> I don't think "reporters" can really do much?
2022-07-18 21:01:06 <craftyguy> I mean, anyone who can register an account can create plenty of mess, filing issues, adding comments. heh.
2022-07-18 21:17:01 <psykose> they get to close issues and label them
2022-07-18 21:17:10 <psykose> and see 'confidential' issues though there isn't usually much happening there
2022-07-18 21:18:12 <z3ntu> 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 <clandmeter> z3ntu: would be nice if somebody can help maintain it
2022-07-18 21:24:22 <z3ntu> 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 <clandmeter> z3ntu: tbh, i did not look at if for a while
2022-07-18 21:27:33 <z3ntu> 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 <z3ntu> https://gitlab.alpinelinux.org/alpine/docker-abuild/-/pipelines/128624/failures
2022-07-18 21:29:58 <clandmeter> z3ntu: what is your username on gitlab?
2022-07-18 21:30:02 <z3ntu> 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 <z3ntu> also z3ntu: https://gitlab.alpinelinux.org/z3ntu
2022-07-18 21:36:45 <clandmeter> z3ntu: i need to check how i can add you to the project without exposing secrets 
2022-07-18 21:36:59 <z3ntu> sure, no rush
2022-07-18 21:45:48 <clandmeter> i guess the rules and the scheduling could block each other
2022-07-18 22:36:51 <panekj> I've been updating docker-abuild images locally for myself
2022-07-18 22:37:03 <panekj> and have patched dabuild for doas/sudo stuff
2022-07-19 03:06:22 <ptrc> 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 <psykose> 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 <ikke> ptrc: only way is adding !tracedeps to options
2022-07-19 04:24:47 <ikke> but that obviously does more
2022-07-19 04:25:16 <ptrc> yeah, i wanted to avoid it
2022-07-19 04:26:20 <psykose> 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 <rbq> psykose: How did it go, and is that the only aport having problems with wxwidgets-3.2?
2022-07-19 06:30:35 <psykose> nah, lots of failures
2022-07-19 06:31:02 <psykose> 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 <psykose> just talking about it :) gtk2 is gone entirely, half the gtk3 stuff fails
2022-07-19 06:35:10 <rbq> When will gtk+2.0 be removed?
2022-07-19 06:35:54 <rbq> From aports, I mean
2022-07-19 06:37:16 <psykose> maybe in 20 years
2022-07-19 06:37:38 <Ermine> Gimp still depends on it afaik
2022-07-19 06:38:06 <psykose> tons of stuff does
2022-07-19 08:32:28 <skarnet> Phew, this MR took a lot more work than it should have, but it’s finally ready: !36606
2022-07-19 08:36:30 <psykose> at last
2022-07-19 09:23:44 <ncopa> 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 <psykose> we both used LANG_ADA=false
2022-07-19 09:38:03 <psykose> every other issue should have been fixed by me
2022-07-19 09:38:57 <psykose> 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 <ncopa> which merge request?
2022-07-19 09:42:49 <ncopa> im fixing the ada thingy
2022-07-19 09:43:31 <ncopa> https://tpaste.us/KekB
2022-07-19 09:47:51 <nmeum> 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 <psykose> ncopa: !34493
2022-07-19 09:48:25 <Ariadne> nmeum: can you send those patches to alpine-gcc-patches
2022-07-19 09:49:12 <Ariadne> i have a couple of meetings but will rebase the snapshot and test it again
2022-07-19 09:49:36 <nmeum> 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 <Ariadne> sure, just send an MR with the new branch and i'll replace it
2022-07-19 09:50:21 <nmeum> ok! will do later today
2022-07-19 10:26:19 <ikke> ncopa: https://tpaste.us/oO7L 
2022-07-19 10:46:17 <ncopa> ikke: this is a fix for that: https://tpaste.us/jPoV
2022-07-19 11:23:55 <ncopa> i get this error when crosscompiling rust: https://tpaste.us/DBbl
2022-07-19 11:24:12 <ncopa> that happens with https://gitlab.alpinelinux.org/alpine/aports/merge_requests/34493 applied
2022-07-19 11:24:17 <ncopa> (and rebased)
2022-07-19 11:48:49 <ikke> ncopa: yes psykose and I got stuck there as well 
2022-07-19 11:49:09 <ikke> FYI, I've created a container on nld5 for the bootstrapping 
2022-07-19 12:24:24 <ncopa> i believe that the __divdi3 errors happens due to lack of linking to libgcc
2022-07-19 12:28:40 <psykose> the majority of them are some compiler intrinsics stuff specific to the crate
2022-07-19 12:28:52 <psykose> whats strange is the .rlib is basically empty
2022-07-19 12:29:14 <psykose> if you look at a working compiler_builtins.rlib it has them
2022-07-19 12:29:48 <psykose> during this cross process, both the s390x stage1 rlib and x86_64 are empty
2022-07-19 13:26:32 <ncopa> do we have another s390x vm where I can experiment tiwh thte gentto->alpine stuff for bootstrapping rust?
2022-07-19 13:28:31 <ikke> We only have access to 2 servers 
2022-07-19 13:28:43 <ikke> One builder and a ci host 
2022-07-19 13:29:15 <ncopa> ok
2022-07-19 13:29:36 <psykose> yoink the builder if you want
2022-07-19 13:29:39 <ncopa> his script needs to run on a s390x machine
2022-07-19 13:30:44 <ikke> We can u suppose run a VM on the ci host 
2022-07-19 14:35:09 <ncopa> 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 <Ariadne> ncopa: when will alpine 3.15.x
2022-07-19 14:41:27 <Ariadne> er
2022-07-19 14:41:32 <Ariadne> ncopa: when will alpine 3.15.x get an update for the busybox CVE
2022-07-19 14:42:25 <ncopa> ah, right
2022-07-19 14:43:19 <ncopa> i got distracted by rust for s390x today. will try get it out either later tonight or tomorrow
2022-07-19 14:43:24 <z3ntu> clandmeter: maybe also someone else in Alpine team (that has gitlab admin) can look into it? 
2022-07-19 14:43:45 <clandmeter> z3ntu: i think i know what the problem is
2022-07-19 14:52:58 <ikke> ncopa: s390x-ci.a.o has docker 
2022-07-19 17:04:52 <divVerent> 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 <panekj> there isn't
2022-07-19 17:22:20 <divVerent> 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 <psykose> 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 <panekj> the dependencies should be provided by alpine when possible
2022-07-19 17:29:39 <psykose> also i made some random changes and rust +crt-static didn't segfault but was still dynamic
2022-07-19 17:29:43 <psykose> maybe i can actually figure it out
2022-07-19 17:29:58 <panekj> what did you do
2022-07-19 17:30:05 <psykose> you know, random changes
2022-07-19 17:30:12 <panekj> sureeeee
2022-07-19 17:30:17 <psykose> cat /dev/urandom > src/rust , and so it goes
2022-07-19 17:30:34 <panekj> ah, pseudo-random changes
2022-07-19 17:30:38 <psykose> i ahve built this shit like 100 times in the past week
2022-07-19 17:31:06 <panekj> want to help me figure out why my stuff doesn't built completely statically then? :P
2022-07-19 17:31:16 <psykose> that is exactly what i'm doing
2022-07-19 17:31:23 <psykose> you can't with the packaged toolchain
2022-07-19 17:31:39 <psykose> iirc they all come out dynamic and segfault lol
2022-07-19 17:31:46 <panekj> (well, I was using pre-built rustup toolchain actually)
2022-07-19 17:32:23 <panekj> it's just that no matter the flags openssl still wouldn't link statically
2022-07-19 17:32:27 <psykose> 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 <divVerent> Issue with dependencies is, the game is written in Go
2022-07-19 17:32:37 <divVerent> and IIRC Go libraries usually don't become Alpine packages
2022-07-19 17:32:40 <panekj> oh well, then carry on
2022-07-19 17:32:48 <divVerent> but there is some vendoring mess going on
2022-07-19 17:32:48 <psykose> oh no, more 400MB executables
2022-07-19 17:32:53 <psykose> i love go!
2022-07-19 17:32:56 <divVerent> Haha
2022-07-19 17:32:59 <divVerent> Only 30M though ;)
2022-07-19 17:33:02 <panekj> I don't care as long as it's not CGO
2022-07-19 17:33:15 <divVerent> Hm... _some_ cgo is included though, is that a problem?
2022-07-19 17:33:21 <panekj> but some people made patches for go compiler to actually multi-thread
2022-07-19 17:33:29 <psykose> as long as it doesn't use the cgo gtk4/3/whatever bindings
2022-07-19 17:33:30 <alpine-meetbot> panekj meant to say: but some people made patches for (c)go compiler to actually multi-thread
2022-07-19 17:33:30 <panekj> s/go/(c)go
2022-07-19 17:33:33 <divVerent> It uses the Ebitengine library which uses glfw which uses cgo to use the C glfw
2022-07-19 17:33:44 <psykose> sus
2022-07-19 17:33:48 <panekj> it's just slow and painful
2022-07-19 17:33:53 <psykose> but i'm mostly trolling, go package it
2022-07-19 17:33:56 <divVerent> hehe
2022-07-19 17:34:05 <divVerent> interestingly on Windows that engine doesn't use cgo
2022-07-19 17:34:05 <panekj> psykose: "go" package it
2022-07-19 17:34:10 <divVerent> it uses something _worse_
2022-07-19 17:34:16 <divVerent> it dumps a DLL to a temp folder and loads that :(
2022-07-19 17:34:16 <psykose> 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 <panekj> dlopen, that's good
2022-07-19 17:34:46 <psykose> 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 <divVerent> 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 <divVerent> ah, that cgo issue, during compiling
2022-07-19 17:35:23 <divVerent> TBH I don't observe that, apparently the cgo amount is low enough to not be noticeable
2022-07-19 17:35:31 <psykose> link to game
2022-07-19 17:35:40 <divVerent> https://divVerent.github.io/aaaaxy/
2022-07-19 17:36:15 <divVerent> 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 <divVerent> (after some C deps glfw needs that will be rather obvious from the error messages)
2022-07-19 17:36:43 <panekj> well, usually anything pre-built without static linking doesn't run on different systems
2022-07-19 17:36:51 <divVerent> indeed
2022-07-19 17:37:10 <divVerent> I did also package for flatpak and snap, but of course, glibc madness too
2022-07-19 17:37:27 <divVerent> 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 <divVerent> like, snap is a great example of how not to do it
2022-07-19 17:37:42 <minecrell> 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 <panekj> AppImages be like: let's just build against the oldest possible OS version
2022-07-19 17:38:53 <divVerent> yeah
2022-07-19 17:39:03 <divVerent> kinda what I do for my raw binaries too - I build on Debian stale
2022-07-19 17:39:05 <divVerent> ;)
2022-07-19 17:39:15 <panekj> ew
2022-07-19 17:39:23 <divVerent> like, anything older than that outright doesn't matter for games
2022-07-19 17:39:28 <psykose> wowee it works
2022-07-19 17:39:45 <panekj> static linking no segfault?
2022-07-19 17:39:49 <psykose> nah the game
2022-07-19 17:39:54 <panekj> eh
2022-07-19 17:39:58 <psykose> lol you thought something i made works? haha get a load of this person
2022-07-19 17:40:08 <divVerent> static linking w/o package manager is evil though - which forces me to make new release frequently
2022-07-19 17:40:29 <panekj> 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 <psykose> minecrell: pretty sure it was the former and was missed for the others
2022-07-19 17:40:38 <panekj> without segfault
2022-07-19 17:41:01 <divVerent> 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 <psykose> i don't see why it shouldn't
2022-07-19 17:41:14 <psykose> the current patches don't even make sense, they intentionally break it for no reason
2022-07-19 17:41:21 <panekj> can't wait for gcc-rs
2022-07-19 17:42:14 <divVerent> hm... it does sound like a good idea to have a reimplementation of Rust
2022-07-19 17:44:17 <panekj> it's already made
2022-07-19 17:44:23 <panekj> and it's eh
2022-07-19 17:45:42 <ptrc> is there any rust reimplementation that's not "rust buth without borrow checker"
2022-07-19 17:45:48 <ptrc> s/buth/but/
2022-07-19 17:45:48 <alpine-meetbot> ptrc meant to say: is there any rust reimplementation that's not "rust but without borrow checker"
2022-07-19 17:46:55 <divVerent> BTW, what are the current "guidelines" (or a positive-example APKBUILD) for Go stuff with dependencies?
2022-07-19 17:47:14 <divVerent> 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 <divVerent> 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 <divVerent> 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 <ptrc> most aports just run `go build` without any vendoring / fetching deps separately
2022-07-19 17:48:43 <divVerent> so it's ok to access network during build? Fine by me then ;)
2022-07-19 17:48:53 <divVerent> it'd still be reproducible as all deps are pinned
2022-07-19 17:49:25 <ptrc> well, i imagine it's not the perfect scenario, but that's the status quo for go aports
2022-07-19 17:49:33 <panekj> currently we don't limit network in builds but that might change in future
2022-07-19 17:49:43 <divVerent> good, thanks
2022-07-19 17:50:55 <divVerent> 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 <panekj> we already have proper flags as default
2022-07-19 17:51:51 <psykose> everything is (almost)already in goflags, unless you mean something specific
2022-07-19 17:54:23 <sam_> 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 <sam_> divVerent: so we've ended up mostly doing dep tarballs now 
2022-07-19 17:55:07 <psykose> yeah it's mostly a waste of time
2022-07-19 17:55:26 <psykose> speaking of i started looking at setuptools 62 and i regret it
2022-07-19 17:55:57 <psykose> they added another like 7 vendored deps???
2022-07-19 17:56:07 <ikke> F.U.N.
2022-07-19 17:56:12 <panekj> *python*
2022-07-19 17:56:14 <psykose> so the initial thought is
2022-07-19 17:56:18 <psykose> 'sure just leave some of them vendored'
2022-07-19 17:56:29 <psykose> except then you have to be more precise with the patching and it's 1k lines
2022-07-19 17:57:14 <psykose> 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 <psykose> great
2022-07-19 17:58:23 <panekj> for what reason those deps are
2022-07-19 18:00:40 <psykose> right when i figured out the entire pyproject mess they decided to make the setuptools circle of hell
2022-07-19 18:01:06 <ikke> psykose: they wanne keep you busy
2022-07-19 18:01:15 <psykose> :)
2022-07-19 18:01:52 <psykose> inb4 stage0-stage1-stage2 levels of setuptools and things building with random versions in the middle
2022-07-19 18:02:04 <divVerent> sam_: yeah, I understand
2022-07-19 18:02:21 <panekj> bootstrapping the bootstrap
2022-07-19 18:02:25 <divVerent> 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 <divVerent> I don't _really_ like the idea of releasing someone else's source code as mine ;)
2022-07-19 18:02:42 <sam_> yeah it's nasty
2022-07-19 18:02:44 <sam_> i don't like it at all
2022-07-19 18:03:10 <divVerent> now the good news is, "go vendor" works out of the box in existing projects now
2022-07-19 18:03:11 <panekj> 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 <divVerent> so at least anyone can build this tarball trivially
2022-07-19 18:03:20 <ikke> 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 <divVerent> they still do that?
2022-07-19 18:03:31 <divVerent> but that breaks things :P
2022-07-19 18:03:39 <divVerent> Ebitengine has recently done something even more stupid
2022-07-19 18:03:40 <ikke> I haven't seen any retagging in go
2022-07-19 18:03:40 <panekj> well
2022-07-19 18:03:49 <divVerent> accidentally bumped minor rev on some package, then "unbumped" it
2022-07-19 18:03:49 <panekj> I've seen few 
2022-07-19 18:03:50 <ikke> especially because the sumdb makes that painful
2022-07-19 18:03:55 <divVerent> as in, the git tag for the wrong minor rev was deleted
2022-07-19 18:04:04 <divVerent> but some existing code still points at it
2022-07-19 18:04:06 <panekj> ikke: that's the point
2022-07-19 18:04:11 <divVerent> and Go's caching proxies still return it
2022-07-19 18:04:14 <ikke> yes
2022-07-19 18:04:19 <panekj> people tagged, untagged then tagged again and sumdb goes crazy
2022-07-19 18:04:22 <ikke> panekj: yes, I understand
2022-07-19 18:04:24 <divVerent> that breaks my vendoring scripts
2022-07-19 18:04:33 <divVerent> which are really nasty as they try to get git URLs back out of a "go vendor" tree ;)
2022-07-19 18:04:37 <panekj> and even worse hell when some another proxy takes new tag as correct one
2022-07-19 18:04:48 <panekj> then each proxy says different thing
2022-07-19 18:04:56 <divVerent> yeah, I so hope the author will not reuse that tag name
2022-07-19 18:05:35 <panekj> at least Go added "deprecated" option
2022-07-19 18:06:13 <ikke> you mean retracted?
2022-07-19 18:06:22 <panekj> yeah
2022-07-19 18:17:51 <sam_> ikke: the problem is what I mentioned :(
2022-07-19 18:17:58 <sam_> but it's doable depending on structure, yeah
2022-07-19 18:18:10 <sam_> really I think it's the only proper way to proceed
2022-07-19 18:18:15 <sam_> it's just awkward logistically
2022-07-19 18:18:49 <ikke> sam_: note that it's not the goal to mention all deps in the APKBUILD
2022-07-19 18:18:58 <ikke> which is not feasible
2022-07-19 18:19:37 <ikke> The idea is to run go mod download before shutting of network access
2022-07-19 18:19:39 <sam_> right
2022-07-19 18:19:41 <sam_> ikke: what's the rough plan then? oh
2022-07-19 18:19:43 <sam_> is it to have go do the download, but then cut it off?
2022-07-19 18:19:45 <sam_> (network)
2022-07-19 18:19:49 <ikke> exactly
2022-07-19 18:19:54 <ikke> but no concrete plans for this yet
2022-07-19 18:20:44 <ikke> Currently with rootbld, everything after fetch is done without networking
2022-07-19 18:21:03 <ikke> But go mod download would need to happen after unpack
2022-07-19 18:23:35 <ikke> (similar with rust)
2022-07-19 18:38:38 <divVerent> let me guess: and cabal, and npm, and virtually every other programming language with its own packaging? ;)
2022-07-19 18:40:22 <divVerent> C++20 modules when? ;)
2022-07-19 18:50:16 <sam_> :D
2022-07-19 18:50:26 <sam_> 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 <sam_> just very interested in how folks handle it
2022-07-19 18:50:35 <ikke> nod
2022-07-19 18:51:17 <ikke> sam_: One step towards this for rust based packages: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/128
2022-07-19 18:51:28 <psykose> 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 <psykose> the biggest positive is it makes it easy to catch things that vendor random deps
2022-07-19 18:51:54 <ikke> psykose: what is as advertised?
2022-07-19 18:52:12 <psykose> the fetch stuff in prepare for network modules
2022-07-19 18:52:21 <ikke> right
2022-07-19 18:52:24 <psykose> nobody has proposed anything else and it makes sense
2022-07-19 18:52:36 <sam_> 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 <ikke> right, though that's not a major concern for us at the moment
2022-07-19 18:53:24 <psykose> one of the biggest bandwidth issues with rootbld is there is no cache currently
2022-07-19 18:53:49 <psykose> 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 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/133?
2022-07-19 18:53:57 <psykose> and redownloading the cargo index on every build is funny
2022-07-19 18:54:07 <psykose> not for apk specifically, builds
2022-07-19 18:54:29 <ikke> You mean distfiles?
2022-07-19 18:54:41 <ikke> or distcc?
2022-07-19 18:54:42 <psykose> no, the literal things being downloaded via `cargo --fetch` for instance
2022-07-19 18:54:47 <ikke> right
2022-07-19 18:55:04 <ikke> but that's not limited to rootbld, is it?
2022-07-19 18:55:17 <psykose> well without rootbld it will just keep the cache in ~/.cargo
2022-07-19 18:55:35 <ikke> right, at least with go, the tendency is to put those things in $srcdir
2022-07-19 18:55:52 <psykose> the go one is a bit different as it also contains built objects iirc
2022-07-19 18:56:00 <ikke> One thing I have to regularly do is to wipe things like ~/.cargo on the builders
2022-07-19 18:56:10 <ikke> psykose: there are 2 directories
2022-07-19 18:56:15 <psykose> ah
2022-07-19 18:56:20 <ikke> ~/go is just the downloaded mod cache
2022-07-19 18:56:32 <ikke> ~/.cache/go-build is the built objects
2022-07-19 18:56:43 <psykose> interesting
2022-07-19 18:56:53 <psykose> wonder why ~/go is like 3x the size of ~/.cargo for me then
2022-07-19 18:56:59 <ikke> I only know it because that's what I have to wipe
2022-07-19 18:57:02 <psykose> guess they just be writing a lot of code
2022-07-19 18:57:16 <ikke> More go projects than rust projects
2022-07-19 18:57:33 <panekj> ~/go/pkg is compiled objects
2022-07-19 18:57:51 <panekj> ~/.cache/go-build is just build cache
2022-07-19 18:58:02 <ikke> panekj: oh, my bad
2022-07-19 18:58:23 <panekj> that's why we added -modcacherw
2022-07-19 18:58:40 <panekj> because normally go protects that directory from deletion
2022-07-19 18:59:23 <ikke> ~/go/pkg only seems to contain source code for me?
2022-07-19 19:00:19 <panekj> forgot that it also contains sumdb
2022-07-19 19:00:39 <ikke> I don't see any binaries / compiled objects there
2022-07-19 19:01:14 <panekj> maybe they changed that, but pretty sure that was once a place for compiled objects
2022-07-19 19:01:36 <ikke> I see them in ~/.cache/go-build
2022-07-19 19:01:41 <ikke> 00563f7dc7fea3460c1df3f8fcc6abb7e7f17dfd7f18b5ae46b4849a826ed68d-d: current ar archive
2022-07-19 19:03:05 <panekj> ls -lah ~/go/pkg/mod/cache ?
2022-07-19 19:03:55 <ikke> panekj: downloaded archives / repositories?
2022-07-19 19:07:02 <panekj> idk, I might be wrong, I've been sitting with rust for too long :P
2022-07-19 19:07:12 <panekj> seems like it's just git stuff that takes a lot of place
2022-07-19 19:07:34 <ikke> yup
2022-07-19 19:07:43 <ikke> And I see the occasinal zip archive as well
2022-07-19 19:07:47 <ikke> occasional*
2022-07-19 20:37:29 <divVerent> 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 <ikke> If it's just a minute it should not be an issue
2022-07-19 20:38:36 <divVerent> because it's the obvious thing I can run in check()
2022-07-19 20:38:59 <divVerent> 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 <divVerent> 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 <psykose> xvfb-run is perfectly fine
2022-07-19 20:40:21 <divVerent> the small one I use for benchmarking would still reveal if anything is egregiously wrong though
2022-07-19 20:40:41 <divVerent> 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 <divVerent> oh, that's what abuild-rootbld is
2022-07-19 20:41:41 <ikke> correct
2022-07-19 20:41:51 <ikke> or docker-abuild
2022-07-19 20:42:02 <divVerent> that contains the d-word
2022-07-19 20:54:39 <divVerent> 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 <psykose> mesa-dri-gallium
2022-07-19 20:56:20 <divVerent> trying... was also checking other packages that use xvfb-run but they have nothing obvious there
2022-07-19 20:57:23 <divVerent> of course, I am kinda _assuming_ they currently pass... trying a randomly chosen one now
2022-07-19 20:58:52 <divVerent> thanks, that rather obviously fixed it... now I do wonder why other packages don't have this
2022-07-19 20:58:55 <ikke> Most of them are desktop apps
2022-07-19 20:59:07 <divVerent> they might of course just pull that already in as transitive dep
2022-07-19 20:59:17 <psykose> no, basically nothing does
2022-07-19 20:59:25 <psykose> for the most part it's not needed
2022-07-19 20:59:38 <psykose> or they all just skip the tests and i missed it :p
2022-07-19 20:59:47 <divVerent> then how come e.g. testing/mixxx passes check?
2022-07-19 20:59:56 <divVerent> (still compiling to see for myself, this one uses cmake)
2022-07-19 21:02:23 <divVerent> oh, it might just not use OpenGL, stupid me
2022-07-19 21:12:40 <divVerent> 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 <divVerent> Somewhat "sus": my game detects a "Synaptic" gamepad while under xvfb-run inside rootbld's bubblewrap sandbox
2022-07-19 21:13:56 <sam_> i would not say you're wasting resources there :p
2022-07-19 21:13:58 <divVerent> didn't expect the sandbox to expose that info ;)
2022-07-19 21:14:10 <sam_> sounds reasonable although possibly fragile, it's a call you can make
2022-07-19 21:15:05 <divVerent> (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 <psykose> dev is mounted into the root
2022-07-19 21:15:23 <divVerent> and apparently enough read permissions to get device names
2022-07-19 21:15:30 <divVerent> just doesn't sound "great" for reproducible builds, but ok
2022-07-19 21:15:36 <psykose> that would be like the most basic level of read access
2022-07-19 21:15:36 <divVerent> builds shouldn't be reading there anyway
2022-07-19 21:15:44 <divVerent> I only do that from check which should be ok
2022-07-19 21:37:25 <ncopa> Ariadne: alpine 3.15.5 is out with busybox cve fix
2022-07-19 21:37:33 <Ariadne> thx
2022-07-19 21:38:01 <Ariadne> now to wait on dockerhub to actually publish it :D
2022-07-19 22:22:38 <psykose> panekj: https://img.ayaya.dev/AjJuDgOxFEQ9.png
2022-07-19 22:22:48 <psykose> at last
2022-07-19 22:23:06 <panekj> attagirl
2022-07-19 22:23:34 <psykose> but, there's a small issue
2022-07-19 22:23:45 <psykose> i am not sure how it even works normally
2022-07-19 22:24:38 <psykose> needs to pass gcc_eh like the patch from the s390x mr but actually specify kind = static
2022-07-19 22:24:56 <psykose> 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 <psykose> so to even build this you need to pass RUSTFLAGS
2022-07-19 22:25:21 <psykose> 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 <psykose> either it fixed itself or i broke everything again, fun
2022-07-20 02:04:25 <divVerent> 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 <divVerent> 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 <divVerent> 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 <divVerent> 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 <panekj> 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 <panekj> s/it the/the
2022-07-20 05:40:37 <alpine-meetbot> 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 <nmeum> psykose: can you boostrap (and fix) rustc for riscv64 next? 🥺👉👈
2022-07-20 09:05:18 <ncopa> i have rust-1.60 packages for s390x now
2022-07-20 09:05:32 <ncopa> but it cannot build 1.62 apaprently
2022-07-20 09:07:08 <clandmeter> 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 <ikke> I did remove some runners the other day that didnt contact gitlab in months 
2022-07-20 09:26:04 <z3ntu> 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 <z3ntu> 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 <z3ntu> (ppc64le also but I don't really care about that one)
2022-07-20 09:48:04 <skarnet> 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 <skarnet> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/52
2022-07-20 10:49:06 <ncopa> skarnet: i cherry-picked `main/eudev: delete setup-udev`
2022-07-20 10:49:14 <ncopa> can you please rebase?
2022-07-20 10:50:12 <ncopa> re mdev-conf, I was thinking to create a separate "upstream" gitlab project for it
2022-07-20 10:50:23 <ncopa> so we can have an APKBUILD that just fetches a tarball
2022-07-20 10:51:29 <skarnet> 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 <skarnet> 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 <skarnet> 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 <skarnet> rebased
2022-07-20 11:01:41 <ncopa> 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 <ncopa> we can run separate unit test CI job
2022-07-20 11:02:05 <ncopa> i think its just generally cleaner
2022-07-20 11:02:42 <ncopa> I thought about it while converting the bats scripts to kyua
2022-07-20 11:03:07 <ncopa> it would make it a bit easier to work with
2022-07-20 11:03:09 <skarnet> 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 <skarnet> it’s unlikely that a mdev-conf package would need a simultaneous aports change
2022-07-20 11:04:04 <skarnet> so okay I have no objection to a separate project
2022-07-20 11:10:18 <skarnet> (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 <z3ntu> <z3ntu> "Btw I think build.alpinelinux...." <- ikke: ^
2022-07-20 11:19:50 <ikke> z3ntu: thanks for the reminder
2022-07-20 11:49:03 <ncopa> in other news....
2022-07-20 11:49:06 <ncopa> >>> rust: Signing the index...
2022-07-20 11:49:06 <ncopa> ncopa-edge-s390x:~/aports/community/rust$ 
2022-07-20 11:49:29 <ikke> 🥳
2022-07-20 11:49:40 <ikke> So it worked in the docker container?
2022-07-20 11:49:46 <ncopa> yes
2022-07-20 11:49:57 <ncopa> i have now built rust 1.61 on s390x
2022-07-20 11:50:06 <ncopa> i will not try build rust 1.62
2022-07-20 11:50:16 <ncopa> which is current latest
2022-07-20 11:51:03 <ikke> Why did that approach work? Did it build rust with rust from Gentoo?
2022-07-20 11:51:11 <ncopa> yes
2022-07-20 11:51:42 <ncopa> he built rust s390x musl using gentoo rust s390x glibc
2022-07-20 11:51:54 <ikke> aha ok
2022-07-20 11:52:25 <ncopa> not sure why that worked better than crosscompile rust s390x musl using rust x86_64 musl
2022-07-20 11:57:15 <ncopa> s/i will not try build rust 1.62/i will now try build rust 1.62/
2022-07-20 11:57:15 <alpine-meetbot> ncopa meant to say: i will now try build rust 1.62
2022-07-20 11:59:57 <ncopa> 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 <ncopa> and when builder is done, i'll remove the manually installed packages from build-edge-s390x
2022-07-20 12:53:15 <divVerent> 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 <divVerent> 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 <panekj> you can just export outside of functions and reference in both
2022-07-20 12:55:00 <panekj> but why you need to share goflags at all?
2022-07-20 12:57:10 <divVerent> some flags may influence go mod download?
2022-07-20 12:57:22 <divVerent> -modcacherw e.g. sounds suspicious, although I don't _really_ know
2022-07-20 12:57:40 <divVerent> 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 <panekj> it should be in prepare()
2022-07-20 12:58:03 <panekj> but what are YOU doing that you have to use GOFLAGS at all
2022-07-20 12:58:21 <panekj> normally that part shouldn't bother you since it's just exported envvar
2022-07-20 12:58:37 <divVerent> 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 <panekj> you don't do that
2022-07-20 12:58:50 <panekj> we already have that as default
2022-07-20 12:58:52 <divVerent> Alpine already passes -buildmode=pie which is nice
2022-07-20 12:58:57 <divVerent> oh, ok, didn't see it when I ran env
2022-07-20 12:59:06 <divVerent> but OTOH it makes sense to share this stuff anyway
2022-07-20 12:59:33 <panekj> I mean, it's probably not propagated to builders, but it's already part of abuild default config
2022-07-20 12:59:55 <divVerent> ah, I probably don't have it because I don't have everything on edge yet
2022-07-20 12:59:56 <panekj> we don't require reproducible builds so it's not necessary to add those flags
2022-07-20 13:00:08 <divVerent> because if I put "env" in my APKBUILD I only see -buildmode=pie in GOFLAGS
2022-07-20 13:00:25 <panekj> it's not released in abuild yet
2022-07-20 13:00:44 <divVerent> 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 <divVerent> Then I may as well ignore GOFLAGS indeed (I did make sure my code honors it)
2022-07-20 13:01:02 <panekj> you only pass flags that you need for stuff to build properly
2022-07-20 13:01:11 <panekj> if none required, you don't do any
2022-07-20 13:01:12 <divVerent> great
2022-07-20 13:01:18 <divVerent> another ugliness fixed :)
2022-07-20 13:01:32 <divVerent> (it seemed weird to export variables outside the functions... although permitted indeed)
2022-07-20 13:01:35 <panekj> I should probably take care of that go mess
2022-07-20 13:02:09 <divVerent> 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 <divVerent> while oddly C/C++ flags are shared properly
2022-07-20 13:02:59 <divVerent> 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 <divVerent> as I clearly want to minimize distro-needed patches
2022-07-20 13:04:07 <panekj> 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 <divVerent> shenanigans? ;)
2022-07-20 13:04:46 <divVerent> 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 <panekj> if possible, all deps should be separate aports (exclusions are go/rust/..)
2022-07-20 13:04:51 <divVerent> they're PNGs of lookup tables for the GPU
2022-07-20 13:05:05 <divVerent> currently I don't rebuild them - but I could
2022-07-20 13:05:41 <divVerent> 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 <panekj> unless you're going to make those PNG do malicious stuff, I don't see any objections
2022-07-20 13:05:55 <divVerent> worst they can do is cause black screen in the game
2022-07-20 13:06:00 <panekj> although I'm probably thinking of JPEG
2022-07-20 13:06:17 <divVerent> 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 <divVerent> like, sure, it could crash out of memory, or return nonsense image... but that should be it
2022-07-20 13:07:11 <divVerent> like, not aware of any code execution exploits there
2022-07-20 13:09:12 <divVerent> 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 <divVerent> of course, my fault for enabling lightdm service right away :)
2022-07-20 13:09:54 <divVerent> 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 <panekj> 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 <divVerent> yeah
2022-07-20 13:10:17 <divVerent> at least Wayland kinda fixes that
2022-07-20 13:10:23 <divVerent> before everything is configured right, Sway just won't start
2022-07-20 13:10:25 <divVerent> problem solved
2022-07-20 13:10:38 <panekj> X11 is (bad word) (: 
2022-07-20 13:11:18 <divVerent> 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 <divVerent> given X11 people like had decades to get OpenGL to work well...
2022-07-20 13:11:32 <divVerent> and Wayland does extra compositing, even
2022-07-20 13:12:03 <divVerent> 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 <divVerent> (after all, the same games on Windows perform even worse...)
2022-07-20 13:12:58 <divVerent> as for Alpine on desktop... well, boot could be faster, but OTOH openrc is way easier to debug
2022-07-20 13:13:10 <divVerent> it seems rather complete nowadays
2022-07-20 13:13:38 <divVerent> but of course, my desktop usage is limited to browser, terminal, gimp and krita ;)
2022-07-20 13:14:41 <divVerent> oh, and mpv, if that even counts ;)
2022-07-20 13:16:54 <divVerent> 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 <divVerent> I am aware of the two x86 ones, and the ARM ones for all those chromebooks out there
2022-07-20 13:17:55 <divVerent> leaves ppc64le, s390x, riscv64
2022-07-20 13:18:04 <divVerent> as I don't really want to build for platforms where llvmpipe is all that exists
2022-07-20 13:18:47 <ncopa> i doubt anyone uses s390x as desktop computer
2022-07-20 13:19:21 <panekj> mhm, I wonder how well it would work as remote desktop
2022-07-20 13:19:35 <divVerent> ppc64le also seems to primarily be IBM Power systems
2022-07-20 13:19:38 <divVerent> not e.g. PPC Macs
2022-07-20 13:19:53 <divVerent> even those would be rather old by now
2022-07-20 13:20:10 <ncopa>  i think there are newer ppc64le workstations
2022-07-20 13:20:13 <divVerent> 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 <divVerent> like, 40fps that way on my Lenovo L440 laptop
2022-07-20 13:20:49 <divVerent> w/o turning them down still 20fps, actually impressive based on what the shaders all do
2022-07-20 13:21:02 <divVerent> but also not a great experience that way
2022-07-20 13:22:49 <divVerent> 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 <divVerent> (at least every old laptop with Intel GPU will do)
2022-07-20 13:30:32 <Ariadne> ncopa: it is not even possible to use s390x as desktop, there is no GPU :D
2022-07-20 13:35:05 <divVerent> Of course, _technically_ on any platform one could remote desktop + virgl it... ;)
2022-07-20 13:40:28 <divVerent> https://gitlab.alpinelinux.org/divVerent/aports/-/jobs/775262 - is this error in line 53 my fault?
2022-07-20 13:40:38 <divVerent> (fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address)
2022-07-20 13:40:51 <panekj> your repo is private
2022-07-20 13:40:54 <panekj> can't see
2022-07-20 13:41:12 <divVerent> oh, fixing that
2022-07-20 13:41:15 <divVerent> that may be the reason even
2022-07-20 13:46:11 <divVerent> Yeah, that fixed it.
2022-07-20 13:46:23 <divVerent> Thanks - nicer error message would be nice, but that explained it :)
2022-07-20 13:46:42 <panekj> it's not intended for aports repo to be private
2022-07-20 13:47:54 <panekj> arch should be "all" unless it doesn't build/run on all
2022-07-20 13:48:14 <panekj> url should not use variables
2022-07-20 13:48:26 <panekj> we don't use $pkgname in package()
2022-07-20 13:48:52 <panekj> not a hard stop, but a general guideline (although some people do that)
2022-07-20 13:51:34 <divVerent> yeah, that was an accident when forking
2022-07-20 13:51:56 <divVerent> 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 <panekj> I have no idea how to use gitlab, so I'll say here: unnecessary backslash in depends
2022-07-20 13:52:16 <panekj> if there are many deps, each goes on its own line
2022-07-20 13:52:23 <divVerent> good, will do
2022-07-20 13:53:02 <divVerent> source= doesn't fit on the punch card, but I guess for URLs that is OK
2022-07-20 13:54:00 <panekj> generally we leave first part of URL as is so github.com/divVerent/aaaaxy, without $pkgname
2022-07-20 13:54:19 <panekj> filename part stays as is
2022-07-20 13:54:24 <divVerent> even in source=? Fine.
2022-07-20 13:55:16 <panekj> that's just minor thing, it can be left as is tbf
2022-07-20 13:56:20 <divVerent> well, it makes the line slightly shorter, so did that :)
2022-07-20 13:56:38 <divVerent> (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 <panekj> sometimes gitlab does that
2022-07-20 13:57:21 <panekj> it's usually when you have non-public repo
2022-07-20 13:57:33 <panekj> and it does that even after changing visibility
2022-07-20 13:58:15 <panekj> that comment above arch is unnecessary
2022-07-20 13:58:46 <panekj> and the one in check is also unnecessary, imo
2022-07-20 13:58:51 <divVerent> ok
2022-07-20 13:59:06 <divVerent> 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 <panekj> but you can leave it as see if someone from devs complains about it
2022-07-20 13:59:24 <divVerent> 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 <divVerent> as it does build anywhere - just won't run well unless someone finally makes a nice riscv64 GPU ;)
2022-07-20 14:01:23 <divVerent> could shorten to archs="..."  # Needs 3D accel.
2022-07-20 14:02:04 <divVerent> well, pushed the shortened comment now
2022-07-20 14:10:02 <ncopa> \o/ rust 1.62.0 built on s390x!
2022-07-20 14:12:45 <panekj> yay
2022-07-20 14:14:45 <panekj> now we need to figure out the rust trademark stuff :P
2022-07-20 14:27:56 <ncopa> rust s390x pushed to edge builders. lets hope 1.62.0 can build 1.62.0
2022-07-20 14:28:25 <ncopa> if this succeeds it means we can upgrade py3-cryptography
2022-07-20 14:28:39 <ncopa> and upgrade openssl3
2022-07-20 14:32:27 <ncopa> oh... what about riscv?
2022-07-20 14:33:04 <ncopa> do we have rust for riscv64? looks like we don't
2022-07-20 14:34:14 <nmeum> ncopa: I started working on it
2022-07-20 14:35:02 <ncopa> is it realistically doable?
2022-07-20 14:35:07 <nmeum> 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 <nmeum> https://github.com/rust-lang/rust/issues/96876
2022-07-20 14:35:49 <nmeum> patches needed for boostrapping are here https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/34151
2022-07-20 14:36:41 <nmeum> 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 <ncopa> rust on riscv64 sounds painful
2022-07-20 14:37:29 <nmeum> Ariadne: ^ did you post in rust's zulip about riscv64 musl support?
2022-07-20 14:37:30 <ncopa> it took a half day to compile rust on s390x
2022-07-20 14:38:13 <ncopa> can we drop anything that touches py3-cryptography on riscv64 for now?
2022-07-20 15:15:14 <nmeum> 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 <ngortheone_> 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 <psykose> nmeum: 🥺👉👈
2022-07-20 15:41:49 <nmeum> :)
2022-07-20 15:48:20 <ncopa> $ ap recursive-revdeps py3-cryptography | xargs ap builddirs | wc -l
2022-07-20 15:48:20 <ncopa> 373
2022-07-20 15:48:50 <ncopa> we will lose those packages: https://tpaste.us/Oq5o
2022-07-20 15:49:23 <Ariadne> nmeum: i have not yet
2022-07-20 15:49:26 <PureTryOut> noooo, Plasma Desktop on riscv64 would be lovely 😢
2022-07-20 15:49:59 <panekj> they are almost all py3-* so I'd say get rid of them 😊
2022-07-20 15:51:29 <panekj> although >qemu >ceph >cloud-init 🤔
2022-07-20 15:52:05 <ikke> docker-compose is replaced luckily by docker-compose-cli (go)
2022-07-20 15:52:47 <ikke> Hmm, qemu
2022-07-20 15:52:51 <ikke> that would be a problem
2022-07-20 15:53:08 <psykose> would it?
2022-07-20 15:53:13 <ikke> although, we run qemu on x86_64
2022-07-20 15:53:15 <ikke> not on rv64
2022-07-20 15:53:18 <psykose> :p
2022-07-20 15:53:46 <ikke> The experience would probably be less then ideal when running qemu on rv64
2022-07-20 15:56:37 <Ariadne> 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 <Ariadne> yes, the rust team is aware of our patches
2022-07-20 15:56:49 <Ariadne> there is an MCP to harmonize them
2022-07-20 15:57:22 <Ariadne> 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 <psykose> Ariadne: fyi there is a >10% gcc speedup by adding the missing -O2 flags for CXX/CPP flags
2022-07-20 15:58:30 <ikke> Ariadne: I suspect this was triggered by some debian thread around the same issue
2022-07-20 15:58:30 <Ariadne> ok
2022-07-20 15:58:40 <Ariadne> ikke: that debian thread is a troll
2022-07-20 15:58:44 <ikke> yes
2022-07-20 15:58:48 <Ariadne> i do not appreciate the troll propagating here
2022-07-20 16:00:24 <psykose> currently seeing how many more % is lto for the compiler as well
2022-07-20 16:05:21 <psykose> eh, just another few %
2022-07-20 16:05:29 <sam_> the gcc thread is way worse too
2022-07-20 16:05:45 <psykose> but the -O2 only is https://img.ayaya.dev/NfSlgZFISK0n
2022-07-20 16:06:02 <Ariadne> sam_: what gcc thread
2022-07-20 16:06:41 <sam_> 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 <sam_> https://gcc.gnu.org/pipermail/gcc/2022-July/239110.html
2022-07-20 16:06:52 <sam_> it's so bad faith
2022-07-20 16:08:37 <psykose> >We’ll call it gust.
2022-07-20 16:08:39 <psykose> lmao
2022-07-20 16:14:56 <ikke> "Please do not approach users of the trademarks with a
2022-07-20 16:14:57 <ikke>   complaint. That should be left to the Rust Foundation and its
2022-07-20 16:14:59 <ikke>   representatives. Thanks!"
2022-07-20 16:16:57 <ikke> https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/#helping-out
2022-07-20 16:16:59 <Ariadne> god damn
2022-07-20 16:20:43 <psykose> i like how we posted the same email
2022-07-20 16:39:25 <ncopa> nice answers. thanks!
2022-07-20 16:40:49 <ncopa> 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 <skarnet> 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 <psykose> indeed, not a troll at all
2022-07-20 17:55:15 <Ariadne> skarnet: he propagated the troll is what i am saying
2022-07-20 17:55:33 <panekj> a bit more trust in Alpine devs would suffice
2022-07-20 18:13:50 <divVerent> 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 <divVerent> a question they probably should ask the Rust foundation
2022-07-20 18:14:21 <divVerent> (and I bet they'd be absolutely OK with that)
2022-07-20 18:16:58 <panekj> that shouldn't concern them if they redistribute Alpine, since, well, they redistribute Alpine and not different thing
2022-07-20 18:24:00 <divVerent> "depends on how litigious the lawyers are" (and on the country), of course
2022-07-20 18:24:36 <divVerent> 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 <divVerent> 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 <divVerent> 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 <divVerent> 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 <divVerent> (ok, fine, I forgot the "have others create the language, then buy them" step) 
2022-07-20 18:30:20 <divVerent> nobody would do such a 'orrible thing
2022-07-20 19:25:14 <psykose> oh right, having rust on s390x now means the s390x rust ci takes 79 millenia
2022-07-20 19:25:26 <psykose> what a miserable pointless architecture
2022-07-20 20:21:36 <psykose> 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 <panekj> cool, I'm doign cursed things
2022-07-20 20:22:11 <psykose> :)
2022-07-20 20:22:20 <psykose> also note this never worked and won't for anything that uses proc-macro
2022-07-20 20:22:34 <panekj> oh good luck then lol
2022-07-20 20:22:48 <psykose> proc-macro itself just doesn't support +crt-static
2022-07-20 20:22:50 <psykose> on any toolchain
2022-07-20 20:22:59 <panekj> it does but you need to set target
2022-07-20 20:23:22 <psykose> in what sense
2022-07-20 20:23:33 <panekj> you have to tell cargo `--target`
2022-07-20 20:23:45 <psykose> as in give me an example of it working
2022-07-20 20:23:51 <psykose> code commands etc
2022-07-20 20:24:08 <psykose> not gonna guess random targets and stuff to build for 30 minutes
2022-07-20 20:24:21 <panekj> RUSTFLAGS="-C target-feature=+crt-static" cargo build --target <triplet>
2022-07-20 20:25:12 <psykose> what the fuck
2022-07-20 20:25:30 <psykose> this is the dumbest shit i've ever seen
2022-07-20 20:25:38 <psykose> specifying the exact same default target fixes it? who made this????
2022-07-20 20:25:49 <panekj> don't ask me
2022-07-20 20:25:52 <psykose> thanks
2022-07-20 20:25:53 <psykose> didn't know
2022-07-20 20:25:54 <panekj> :D
2022-07-20 20:25:56 <psykose> but also what the fuck
2022-07-20 20:26:29 <panekj> I think it even tells you when you do that without --target
2022-07-20 20:26:34 <panekj> but I don't remember
2022-07-20 20:27:06 <psykose> nope
2022-07-20 20:27:24 <psykose> 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 <psykose> just says stuff like `
2022-07-20 20:27:31 <psykose> putting that exact same thing in --target fixes it
2022-07-20 20:27:33 <panekj> mhmm
2022-07-20 20:27:34 <psykose> although it fails to link
2022-07-20 20:27:37 <psykose> so i guess more stuff to fix
2022-07-20 20:30:20 <psykose> ld: deps/liblibgit2_sys-d56d5d6f57e58092.rlib: error adding symbols: file format not recognized
2022-07-20 20:30:20 <psykose> hmmm
2022-07-20 20:30:32 <panekj> liblibgit
2022-07-20 20:31:03 <panekj> oh my, building anything basic needs so many deps
2022-07-20 20:31:15 <lucidiot> `git clone liblibgit.li/liblibgit/liblibgit.git lib`
2022-07-20 20:31:29 <psykose> ah, maybe i need system .a's of everything
2022-07-20 20:32:31 <psykose> ah
2022-07-20 20:33:32 <panekj> ah
2022-07-20 20:33:59 <psykose> no idea actually, all of them are llvm ir
2022-07-20 20:34:18 <panekj> what are you building
2022-07-20 20:34:27 <psykose> ah
2022-07-20 20:34:31 <psykose> llvm-nm is needed
2022-07-20 20:34:39 <ikke> llvm-never-mind
2022-07-20 20:35:35 <psykose> to even read some of them
2022-07-20 20:35:42 <psykose> but i'm not sure how to pass any of these
2022-07-20 20:36:11 <psykose> ah, easy fix, okay, works
2022-07-20 20:46:07 <psykose> just no static vs system libs, so i have one more thing to try there
2022-07-20 20:46:22 <panekj> have you tried full static?
2022-07-20 20:46:36 <panekj> LIBGIT2_STATIC=1 etc.
2022-07-20 20:46:49 <psykose> those would work since the sys crate would just build them static, yes
2022-07-20 20:47:23 <psykose> 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 <panekj> it's hit or miss, I'm not sure
2022-07-20 20:47:59 <panekj> if something depends on libgit2 and it's not static, it will build not static
2022-07-20 20:49:16 <psykose> yeah, but i'm wondering if it's meant to work at all
2022-07-20 20:51:12 <panekj> heh
2022-07-20 21:05:33 <skarnet> don’t blame rust/llvm problems on s390x!
2022-07-20 21:05:56 <psykose> there are none, the machines are just slow as fuck
2022-07-20 21:06:09 <psykose> usually everything is disabled on s390x anyway so you never see it
2022-07-20 21:07:51 <skarnet> can’t see problems if you never run software :thinking guy:
2022-07-20 21:08:56 <psykose> :)
2022-07-20 21:09:40 <panekj> error: '_PATH_WTMP' undeclared here (not in a function)
2022-07-20 21:09:43 <panekj> 48 |         WTMP_FILE;
2022-07-20 21:09:49 <panekj> why 🤔
2022-07-20 21:09:57 <psykose> what are you building
2022-07-20 21:10:02 <panekj> busybox
2022-07-20 21:10:14 <psykose> with the latest changes, or
2022-07-20 21:10:24 <panekj> quite old
2022-07-20 21:10:38 <panekj> but 3.16
2022-07-20 21:10:49 <psykose> the new ones change that specific line
2022-07-20 21:13:51 <psykose> and it builds without changes to whatever is on either, so what did you change
2022-07-20 21:15:19 <panekj> I don't see any changes for that on 3.16
2022-07-20 21:15:26 <panekj> also, man-made horrors
2022-07-20 21:17:37 <psykose> yeah
2022-07-20 21:42:11 <psykose> what i really hate is how there's no standard for these damn cargo features
2022-07-20 21:42:40 <panekj> github issues are standard
2022-07-20 21:42:45 <psykose> 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 <psykose> rly fun needing to go read the build.rs of every single -sys crate every time to remember
2022-07-20 21:43:14 <panekj> it depends if something is actually cargo or if it's passed to rustc
2022-07-20 21:43:50 <psykose> yeah, the ecosystem where nothing works without cargo to begin with, depends on things outside of cargo
2022-07-20 21:43:50 <psykose> a+
2022-07-20 21:44:36 <panekj> you could try PKG_CONFIG_ALL_STATIC=1
2022-07-20 21:44:48 <psykose> god you poles are so smart
2022-07-20 21:45:19 <panekj> nah, I just wasted too much time on building stuff in rust
2022-07-20 21:47:54 <psykose> that env var doesn't exist in pkgconf itself
2022-07-20 21:47:55 <psykose> hm
2022-07-20 21:49:56 <psykose> i've gotten everything so far except openssl
2022-07-20 22:01:55 <psykose> cargo-audit: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked
2022-07-20 22:01:57 <psykose> at last
2022-07-20 22:02:30 <psykose> the fix? OPENSSL_DIR="/usr"
2022-07-20 22:02:34 <psykose> because of course it is
2022-07-20 22:04:41 <panekj> lol
2022-07-20 22:04:53 <panekj> wait
2022-07-20 22:12:35 <sam_> oh i hit that too 
2022-07-20 22:12:37 <sam_> so stupid
2022-07-20 22:13:56 <psykose> 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 <psykose> weh
2022-07-20 22:14:33 <psykose> 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 <psykose> curse you unix!
2022-07-20 22:15:01 <sam_> you should merge ur usr 
2022-07-20 22:15:03 <sam_> ez
2022-07-20 22:15:05 <psykose> i agree!
2022-07-20 22:15:10 <psykose> do you think anyone else does though?
2022-07-20 22:15:10 <sam_> do you actually
2022-07-20 22:15:15 <sam_> cause i do
2022-07-20 22:15:31 <psykose> yes, there is no point of these double paths that mean the same thing
2022-07-20 22:15:38 <psykose> i still have no idea who came up with the split in the first place
2022-07-20 22:15:47 <sam_> 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 <sam_> it's so arbitrary and people don't get the split right anyway
2022-07-20 22:16:36 <sam_> (like, what even is right?)
2022-07-20 22:16:58 <psykose> 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 <psykose> amazing folder
2022-07-20 22:27:58 <orbea> it made more sense when there were small harddrives and /usr might not be mounted
2022-07-20 22:29:05 <ptrc> yeah, like 1.5MB small...
2022-07-20 22:30:01 <orbea> it used to be common in install guides to have different partitions for everything
2022-07-20 22:30:30 <psykose> still is if you're openbsd
2022-07-20 22:30:36 <orbea> :P
2022-07-20 22:41:41 <skarnet> the /usr split is valid for historical reasons. Nowadays, less so. But it *should not matter either way*.
2022-07-20 22:41:58 <skarnet> it’s not like having a split /usr is problematic in any kind of way.
2022-07-20 22:42:05 <panekj> sureeeeeeee
2022-07-20 22:42:36 <skarnet> if you’re talking about libraries, that’s two wrongs making kind of a right
2022-07-20 22:42:57 <skarnet> 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 <skarnet> build-time and run-time linkers should not search the same paths
2022-07-20 22:43:35 <skarnet> it sucks, but using /usr/lib for the .a’s and /lib for the .so’s kinda works
2022-07-20 22:44:05 <skarnet> 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 <panekj> one would think software is smart enough to look at file name
2022-07-20 22:44:35 <orbea> lot of things follow FHS where libdir = $prefix/lib
2022-07-20 22:45:02 <skarnet> it’s not even the problem
2022-07-20 22:45:17 <skarnet> the problem is that libdir is the same for static and dynamic libraries
2022-07-20 22:45:27 <skarnet> you should have staticlibdir and dynlibdir instead
2022-07-20 22:46:02 <orbea> 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 <panekj> if that fix works for my problem, psykose, you're getting a headpat
2022-07-20 22:46:41 <psykose> sure maybe i'll be in poland again
2022-07-20 22:46:48 <skarnet> 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 <psykose> maybe even intentionally this time
2022-07-20 22:47:14 <skarnet> because no build system does things right and everybody’s frustrated
2022-07-20 22:47:35 <panekj> sounds like typical software
2022-07-20 22:48:19 <skarnet> unfortunately yes
2022-07-20 22:48:51 <orbea> 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 <panekj> trying to build linux from scratch is pain
2022-07-20 22:50:16 <skarnet> 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 <skarnet> and these are not optimal by any means
2022-07-20 22:50:55 <panekj> well, for ninja we at least have samurai
2022-07-20 22:51:01 <skarnet> 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 <orbea> skarnet: and with all of that effort there are still countless legacy projects doing their own special things
2022-07-20 22:51:04 <skarnet> because that’s how these things go
2022-07-20 22:51:13 <orbea> or projects like openssl doing other horrible things
2022-07-20 22:51:50 <skarnet> 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 <panekj> being part of the problem :P
2022-07-20 22:52:37 <orbea> skarnet: what build system?
2022-07-20 22:52:55 <skarnet> orbea: configure-style + Makefile, but not autoconf
2022-07-20 22:52:55 <orbea> it can't be as bad as dialog
2022-07-20 22:53:27 <skarnet> panekj: and yet my package files are cleaner than most, go figure
2022-07-20 22:53:55 <orbea> skarnet: seriously that sounds fine if it works
2022-07-20 22:54:32 <skarnet> it does, and I spent months on it, and I hate that I had to do it
2022-07-20 22:55:00 <orbea> some of the things I have found working on this are just ... https://bugs.gentoo.org/765709
2022-07-20 22:55:35 <skarnet> slibtool is a very cool idea
2022-07-20 22:55:59 <skarnet> libtool should be totally ditched in the first place tbh, but slibtool is probably the second best solution
2022-07-20 22:56:44 <orbea> yea, i agree
2022-07-20 22:57:02 <orbea> getting slibtool to work is much easier than ditching libtool
2022-07-20 22:57:04 <psykose> maybe we should put slibtool into alpine
2022-07-20 22:57:19 <psykose> iirc there was like one issue
2022-07-20 22:57:52 <orbea> 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 <panekj> wonderful, cargo just installed some other rust toolchain randomly during build of package
2022-07-20 23:17:00 <psykose> build.rs is great innit
2022-07-20 23:19:19 <panekj> it's not build.rs
2022-07-20 23:20:06 <panekj> also it happened when using alpine's cargo
2022-07-20 23:20:25 <panekj> cargo from rustup didn't do that
2022-07-20 23:21:02 <psykose> what is it then
2022-07-20 23:21:26 <panekj> how do I know
2022-07-20 23:22:08 <psykose> what did you build and what did you see smh headass
2022-07-20 23:22:33 <panekj> https://usercontent.irccloud-cdn.com/file/hIB8M0Og/image.png
2022-07-20 23:22:53 <psykose> that message is from rustup
2022-07-20 23:23:32 <panekj> +5 points for being perceptive
2022-07-20 23:24:59 <panekj> I'm building https://github.com/lapce/lapce
2022-07-20 23:25:20 <panekj> for some reason it stopped linking statically completely
2022-07-20 23:26:11 <psykose> that thing is yet another editor with broken fontconfig
2022-07-20 23:26:13 <psykose> it's hilarious
2022-07-20 23:26:19 <psykose> i tried to use it once
2022-07-20 23:26:51 <panekj> > that thing is yet another editor broken 
2022-07-20 23:27:07 <psykose> yep
2022-07-20 23:27:10 <psykose> in this case idk why it is
2022-07-20 23:27:21 <psykose> i straced it and it was calling open/close on the font
2022-07-20 23:27:26 <psykose> maybe.. 2000 times a second?
2022-07-20 23:27:31 <panekj> probably because of fount
2022-07-20 23:27:32 <psykose> the ui was at 4 seconds per frame
2022-07-20 23:27:45 <psykose> idk why it would open/close a font repeatedly but it sure was having fun
2022-07-20 23:27:56 <psykose> (while actually rendering with the same font correctly)
2022-07-20 23:29:38 <panekj> 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 <sam_> so elegant
2022-07-20 23:32:00 <psykose> only 700+ crates
2022-07-20 23:32:01 <psykose> weak
2022-07-20 23:32:24 <psykose> i think even tidb was less than this, impressive
2022-07-20 23:33:49 <panekj> well, compare that to vscode
2022-07-20 23:34:05 <panekj> >  Dependencies defined in yarn.lock 1,665
2022-07-20 23:34:52 <panekj> and this is just main yarn.lock
2022-07-21 00:20:30 <psykose> rbq: well, i got everything to work with wxwidgets-3.2 except for 4 things
2022-07-21 00:21:41 <rbq> Ok
2022-07-21 00:21:59 <psykose> codeblocks, filezilla, maitreya, and (funnily) wxpython
2022-07-21 00:23:04 <rbq> So, when will wxwidgets-3.2 be merged?
2022-07-21 00:23:14 <psykose> when i fix those 4 things
2022-07-21 00:23:40 <psykose> funnily, everything using wxgtk (python2) actually built against 3 fine
2022-07-21 00:23:44 <psykose> er, (gtk2)
2022-07-21 00:23:46 <psykose> tired
2022-07-21 00:24:48 <rbq> You should rest...
2022-07-21 00:25:18 <rbq> Now I understand what you meant by "gtk2 is gone entirely"
2022-07-21 00:25:46 <rbq> You were referring to wxgtk
2022-07-21 00:26:47 <psykose> the new version doesn't have gtk2 bindings, that's all
2022-07-21 00:27:51 <rbq> Ok
2022-07-21 00:28:04 <psykose> ok, codeblocks has a PATCHARRAY to fix this
2022-07-21 00:28:07 <psykose> onto the others
2022-07-21 00:29:14 <rbq> Thanks for working on this :)
2022-07-21 00:29:35 <psykose> how come
2022-07-21 00:30:42 <rbq> Well you're trying to make those 4 aports compile with wxwidgets-3.2, which is nice...
2022-07-21 00:41:38 <psykose> meh
2022-07-21 04:30:16 <psykose> 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 <psykose> or well, it's still quite useless, but you actually don't segfault instantly
2022-07-21 04:30:51 <psykose> i guess that's what you get when it also needs -lelf
2022-07-21 04:32:55 <psykose> maybe i should port the latest git version
2022-07-21 04:32:59 <psykose> instead of whatever we have in aports
2022-07-21 05:25:50 <psykose> done already, maybe not such a terrible idea
2022-07-21 06:56:44 <panekj> psykose: where are the rust fixes!!!
2022-07-21 06:56:49 <psykose> which ones
2022-07-21 06:56:50 <psykose> it works
2022-07-21 06:57:26 <panekj> rust build time is 8pm
2022-07-21 06:57:45 <psykose> yeah that's the working one
2022-07-21 07:09:37 <panekj> openssl linked statically 👀 hopefully crt will too
2022-07-21 07:12:41 <panekj> error[E0463]: can't find crate for `core`
2022-07-21 07:12:55 <panekj> note: the `x86_64-unknown-linux-musl` target may not be installed
2022-07-21 07:13:03 <panekj> oops
2022-07-21 07:17:48 <psykose> rust is a lot nicer when you don't have rustup installed at all
2022-07-21 07:18:11 <panekj> it's also nicer when you specify correct target
2022-07-21 07:31:14 <panekj> still linked to musl
2022-07-21 07:31:59 <psykose> what does `file` say
2022-07-21 07:32:18 <panekj> 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 <psykose> yep, static
2022-07-21 07:32:26 <psykose> good one panekj!
2022-07-21 07:32:40 <panekj> 
ACTION is confuse

2022-07-21 07:32:50 <panekj> is ldd wrong?
2022-07-21 07:32:52 <psykose> yes
2022-07-21 07:32:56 <panekj> oh lol
2022-07-21 07:32:59 <psykose> copy it to glibc if you really want to make sure
2022-07-21 07:34:44 <panekj> wow
2022-07-21 07:34:46 <panekj> ok
2022-07-21 07:34:51 <panekj> I love software
2022-07-21 07:37:33 <panekj> psykose: congrats, you received a coupon for headpats, it's valid until end of year
2022-07-21 07:40:31 <psykose> 🥺
2022-07-21 07:43:38 <skarnet> ah, the classic trap of static pie not being displayed as static
2022-07-21 07:44:43 <ikke> Hmmm, static pie
2022-07-21 07:44:50 <panekj> Hmmm, pie
2022-07-21 07:44:59 <skarnet> ikke: so good it will shock you
2022-07-21 07:45:02 <fcolista> yummm, apple pie
2022-07-21 07:47:40 <psykose> also file doesn't detect static-pie until like 5.38+ which is quite recent
2022-07-21 07:49:27 <psykose> (if 3 years is recent to you. also i forgot the actual version)
2022-07-21 07:55:21 <panekj> rust is so weird
2022-07-21 08:38:43 <andypost[m]> ikke: please check why ppc64le has diffent setting for queue size for #14041
2022-07-21 10:36:38 <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 10:37:25 <ikke> I suppose we could use some nightly bootstrap.sh run
2022-07-21 10:37:40 <psykose> ah, yeah, utmps wasn't conditionalised to bootstrap
2022-07-21 10:38:18 <psykose> 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 <ncopa> maybe i misunderstood something. i kinda thought that libutmps was a drop-in replacement?
2022-07-21 10:43:30 <ncopa> 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 <ikke> skarnet: ^
2022-07-21 10:44:13 <panekj> psykose: is there an easy way to replace distutils with setuptools
2022-07-21 10:44:24 <panekj> (i hate python)
2022-07-21 10:44:59 <psykose> pretty sure setuptools is worse
2022-07-21 10:45:57 <panekj> idk, but it screams at me
2022-07-21 10:46:20 <psykose> many such cases
2022-07-21 10:46:27 <panekj> 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 <ikke> oh, that you can ignore for now :P
2022-07-21 10:46:50 <ikke> is there a setup.cfg?
2022-07-21 10:47:28 <psykose> the alternative thing you want is pyproject with whatever backend
2022-07-21 10:47:30 <psykose> flit-core is fine
2022-07-21 10:48:07 <psykose> just apk add py3-flit and flit init
2022-07-21 10:49:20 <panekj> ikke: ye
2022-07-21 10:50:24 <panekj> psykose: can i get non-interactive type of it
2022-07-21 10:50:27 <panekj> :P
2022-07-21 10:50:28 <ikke> You could use py3-build + py3-installer
2022-07-21 10:50:36 <psykose> in what sense
2022-07-21 10:50:49 <psykose> that command just gives you the default 8 lines of config
2022-07-21 10:50:51 <panekj> it asks me for stuff when i run it in abuild
2022-07-21 10:50:55 <psykose> oh to build
2022-07-21 10:50:58 <psykose> smh headass
2022-07-21 10:51:01 <panekj> obviously
2022-07-21 10:51:03 <psykose> just build whatever the project has
2022-07-21 10:51:05 <panekj> or so I thought
2022-07-21 10:51:13 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/py3-executing/APKBUILD
2022-07-21 10:51:21 <psykose> for pyproject.toml, use that
2022-07-21 10:51:51 <psykose> 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 <psykose> i should move gpep517 to main and start using that instead of build
2022-07-21 10:52:17 <ikke> is setting PYTHONPATH not enough?
2022-07-21 10:52:33 <ncopa> rust-lldb is broken on x86. it depends on lldb which is disabled on x86
2022-07-21 10:53:18 <ncopa> also if soemthing depends on rust-lldb, we have a build order resolver problem
2022-07-21 10:53:30 <panekj> there is setup.cfg and setup.py only
2022-07-21 10:53:33 <psykose> ikke: for some reason no
2022-07-21 10:53:38 <psykose> panekj: then just setup.py build
2022-07-21 10:54:39 <psykose> ncopa: yeah, but that's fine? nothign depends on rust-lldb
2022-07-21 10:55:13 <ikke> from what I can see, lldp was never enabled on x86
2022-07-21 10:55:33 <ikke> it was disabled in 2017
2022-07-21 10:56:05 <psykose> i'll check the re-enable
2022-07-21 10:56:15 <ncopa> 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 <ikke> 50d30564ce2aae879a5afd925c9addfb158afade
2022-07-21 10:56:43 <ikke> Similar as when it was disabled
2022-07-21 10:56:50 <psykose> ncopa: seen the same when toggling ssp_nonshared linking for rust 
2022-07-21 10:57:03 <psykose> it comes from that
2022-07-21 10:58:18 <psykose> idk why these errors are only on x86
2022-07-21 10:59:31 <psykose> 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 <ikke> right
2022-07-21 11:00:07 <ikke> less dependencies == lead headaches
2022-07-21 11:00:09 <psykose> yep
2022-07-21 11:00:10 <ikke> :D
2022-07-21 11:00:14 <ikke> s/lead/less
2022-07-21 11:00:14 <alpine-meetbot> ikke meant to say: less dependencies == less headaches
2022-07-21 11:00:25 <psykose> the cli is a bit stupid but it works fine, no issues
2022-07-21 11:07:37 <psykose> ayy i ran the lldb configure on riscv and it only took 8 minutes!!
2022-07-21 11:13:45 <Ermine> Enough to have a tea
2022-07-21 11:19:07 <psykose> love tea
2022-07-21 11:20:56 <Ermine> i love it too
2022-07-21 11:22:17 <panekj> 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 <panekj> why people need to do such terrible things
2022-07-21 11:22:32 <ikke> lesigh
2022-07-21 11:23:18 <ncopa> 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 <ncopa> we have a clang patch that enables ssp by default
2022-07-21 11:23:40 <ncopa> so we should also pass -lssp_nonshared i think
2022-07-21 11:30:56 <psykose> 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 <psykose> 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 <psykose> for anything using libLLVMSupport.a
2022-07-21 11:34:28 <panekj> is there are cmd:diffstat ?
2022-07-21 11:35:04 <panekj> but like, not necessarily a cmd:
2022-07-21 11:36:39 <psykose> LLVM_LDFLAGS in BuildVariables.inc seems to be the one
2022-07-21 11:43:04 <psykose> i have a patch for it, will see if it does what is intended
2022-07-21 11:43:52 <psykose> also testing a riscv build
2022-07-21 11:43:56 <psykose> so you can go back to rust :)
2022-07-21 11:53:17 <ikke> psykose: lol
2022-07-21 11:53:21 <psykose> haha
2022-07-21 11:53:27 <psykose> :) good timing
2022-07-21 11:53:59 <ikke> (for reference: #14042)
2022-07-21 12:00:29 <psykose> my god
2022-07-21 12:00:43 <ikke> :D
2022-07-21 12:00:59 <ikke> Well, daniel cannoy complain about lack of support
2022-07-21 12:01:02 <ikke> cannot*
2022-07-21 12:01:15 <psykose> we do provide refunds don't we
2022-07-21 12:01:22 <ikke> Yup
2022-07-21 12:01:29 <panekj> I'd like one
2022-07-21 12:01:40 <ikke> Please bring your receipt
2022-07-21 12:01:55 <panekj> Can you provide the template
2022-07-21 12:03:24 <panekj> or can I use one from npp? https://notepad-plus-plus.org/news/v844-happy-users-edition/
2022-07-21 12:03:55 <psykose> (happy user only)
2022-07-21 12:04:08 <ikke> https://tpaste.us/0W47 
2022-07-21 12:04:19 <psykose> :)
2022-07-21 12:04:24 <panekj> (:
2022-07-21 12:06:13 <psykose> ncopa: i think !36693 should fix it, will see
2022-07-21 12:06:42 <psykose> $ llvm-config --ldflags
2022-07-21 12:06:43 <psykose> -L/usr/lib/llvm14/lib -lssp_nonshared
2022-07-21 12:07:01 <psykose> if the order is still wrong, then idk
2022-07-21 12:07:03 <psykose> more stuff to check
2022-07-21 12:07:19 <psykose> riscv64 failure is different, looking at that now
2022-07-21 12:07:58 <psykose> this spicy food isn't spicy enough
2022-07-21 12:08:47 <ikke> happy customer
2022-07-21 12:13:57 <ncopa> 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 <psykose> that would perhaps make sense, i don't know where that is
2022-07-21 12:14:47 <psykose> could check
2022-07-21 12:15:17 <skarnet> ncopa: two things
2022-07-21 12:15:28 <psykose> three
2022-07-21 12:15:48 <ikke> Who bids more?
2022-07-21 12:15:49 <skarnet> 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 <ncopa> community/clang/30-Enable-stack-protector-by-default-for-Alpine-Linux.patch
2022-07-21 12:16:16 <skarnet> 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 <ncopa> im fine either way, either fix crossomile of utmps or fix busybox build to build without utmps
2022-07-21 12:17:03 <ncopa> s/crossomile/crosscompile/
2022-07-21 12:17:03 <alpine-meetbot> 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 <skarnet> 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 <skarnet> 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 <ikke> yes, they use the regular APKBUILDs
2022-07-21 12:18:27 <skarnet> 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 <ncopa> i think disabling utmps when bootstrapping busybox is fine
2022-07-21 12:18:59 <skarnet> it’s what’s currently happening in the bb apkbuild
2022-07-21 12:19:05 <skarnet> or should be, at least
2022-07-21 12:19:11 <ncopa> build fails
2022-07-21 12:19:46 <skarnet> will fix, can it wait for this evening? I have outside appointments this afternoon
2022-07-21 12:19:52 <ncopa> 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 <ncopa> sure, no worries
2022-07-21 12:21:23 <skarnet> 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 <psykose> $CHOST $CBUILD $CTARGET
2022-07-21 12:21:56 <ikke> ref: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/functions.sh.in
2022-07-21 12:22:18 <skarnet> thanks
2022-07-21 12:22:43 <psykose> ncopa: that doesn't say how to add -lssp_nonshared to the default link line for everything
2022-07-21 12:23:10 <ncopa> that i know. i tried this myslef but i dont think it works:
2022-07-21 12:23:25 <ncopa> https://tpaste.us/a0NN
2022-07-21 12:23:39 <psykose> you want Linux.cpp not Gnu pretty sure
2022-07-21 12:24:07 <psykose> unless i'm wrong which target we are using..
2022-07-21 12:24:12 <ncopa> i searched for -lssp_nonshared in the sources and found it for things like MinGw
2022-07-21 12:24:29 <ncopa> we already touch Gnu.cpp for some reason. I dont know
2022-07-21 12:25:18 <psykose> ah, if the triples are there then yes
2022-07-21 12:25:20 <psykose> correct place
2022-07-21 12:25:39 <psykose> can try without ssp first
2022-07-21 12:25:43 <psykose> just nonshared
2022-07-21 12:27:45 <psykose> (i don't think anything even provides `libssp` anyway)
2022-07-21 12:28:47 <psykose> you also want to add `if(getToolChain().getArch() == llvm::Triple::x86) { ` before that
2022-07-21 12:29:05 <ncopa> yeah
2022-07-21 12:29:15 <ncopa> i mean without ssp first
2022-07-21 12:29:27 <ncopa> not sure about the  llvm::Triple::x86 check
2022-07-21 12:29:34 <psykose> it's not needed on any other platform
2022-07-21 12:30:01 <ncopa> https://www.openwall.com/lists/musl/2018/09/11/2 claims powerpc
2022-07-21 12:30:07 <psykose> we don't even support that
2022-07-21 12:30:09 <ncopa> but its maybe 32 bit ppc
2022-07-21 12:30:11 <psykose> yeah
2022-07-21 12:30:17 <psykose> if it was the one we supported, it would fail like x86
2022-07-21 12:30:25 <ncopa> ok, sounds good then
2022-07-21 12:30:25 <psykose> (but it builds this whole time, so)
2022-07-21 12:30:42 <ncopa> it also measn that clang is basically broken on x86 right now?
2022-07-21 12:31:01 <psykose> no, stuff still builds in ci/builders (and this fails at build time)
2022-07-21 12:31:20 <psykose> but for these cases, yeah
2022-07-21 12:31:26 <psykose> well
2022-07-21 12:31:36 <psykose> 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 <psykose> so yeah, nice fix
2022-07-21 12:31:43 <psykose> lots of fixes recently
2022-07-21 12:33:19 <ncopa> ~ $ ./hello
2022-07-21 12:33:19 <ncopa> Hello rust
2022-07-21 12:33:19 <ncopa> 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 <ncopa> ~ $ uname -a
2022-07-21 12:33:32 <psykose> build something bigger
2022-07-21 12:33:40 <ncopa> i will try the testcase
2022-07-21 12:33:41 <psykose> like rust itself with the same compiler on riscv-native
2022-07-21 12:33:44 <psykose> or that, yeah
2022-07-21 12:37:42 <panekj> or static binary with proc-macro
2022-07-21 13:32:36 <ikke> hmm, TIL go version -m <binary>
2022-07-21 13:33:50 <panekj> what rust targets do we have
2022-07-21 13:34:20 <psykose> oh huh, that's all the deps
2022-07-21 13:34:22 <psykose> wow
2022-07-21 13:34:31 <psykose> well, external
2022-07-21 13:34:34 <psykose> so it's just as  useless as before
2022-07-21 13:34:38 <panekj> guess, I can just steal that from targets patch
2022-07-21 13:34:52 <psykose> panekj: there's no cross
2022-07-21 13:34:59 <psykose> the only targets are chost and wasm32
2022-07-21 13:35:11 <panekj> ok?
2022-07-21 13:35:22 <psykose> whadya mean 'ok'
2022-07-21 13:35:33 <panekj> I still need the targets
2022-07-21 13:35:43 <psykose> for what
2022-07-21 13:35:58 <panekj> so I can build the goddamn proc-macro static bins 
2022-07-21 13:36:14 <psykose> i am not sure how this relates to targets at all
2022-07-21 13:36:20 <psykose> it prints you the target when it fails and you use that
2022-07-21 13:36:31 <psykose> and they're all arch-alpine-linux-musl
2022-07-21 13:37:05 <panekj> sure, I'm just gonna magically know if arm is eabi or eabihf
2022-07-21 13:38:58 <ncopa> ikke: wow.. that go version -m <binary> thingy can be used to track security issues
2022-07-21 13:40:26 <ncopa> panekj: both our armhf  and armv7 are hard-float
2022-07-21 13:40:42 <ncopa> i assume they are that for rust too, but I havent verified
2022-07-21 13:41:20 <ncopa> the rust testcase for riscv64 does not segfault with latest rust/llvm.
2022-07-21 13:41:37 <panekj> yes, I already read the patch for rust
2022-07-21 13:43:31 <psykose> armv7 rust is actually wrong
2022-07-21 13:43:37 <psykose> i will fix it
2022-07-21 13:44:01 <panekj> (:
2022-07-21 13:44:19 <panekj> ncopa: rust on rv64 soon?
2022-07-21 13:44:24 <psykose> it inherits armv7_unknown_linux_musleabihf
2022-07-21 13:44:33 <psykose> which sets "+v7,+vfp3,-d32,+thumb2,-neon"
2022-07-21 13:44:40 <psykose> but our v7 has +neon +thumb-mode
2022-07-21 13:44:46 <psykose> so we can add more features
2022-07-21 13:45:43 <psykose> ncopa: the issue is that that go output does not include internal go stuff
2022-07-21 13:45:54 <psykose> so go compiler updates that fix stuff in the 'syscall' mod or whatever are not in that
2022-07-21 13:46:03 <psykose> so it doesn't help with the 'compiler came out, lets rebuild everything'
2022-07-21 13:46:14 <psykose> speaking of we're 2 weeks behind on a go cve patch
2022-07-21 13:47:38 <ncopa> panekj: depends on how long time it takes to build it, but yes.
2022-07-21 13:47:52 <ncopa> psykose: you want me to update go?
2022-07-21 13:48:00 <psykose> there's an mr already and it works
2022-07-21 13:48:06 <psykose> just needs the rev bump for everything
2022-07-21 13:48:08 <psykose> and 3.16
2022-07-21 13:55:08 <psykose> actually, no
2022-07-21 13:55:09 <psykose> hm
2022-07-21 13:57:01 <psykose> 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 <psykose> but we /do/ have neon enabled for most armv7 things where things have a toggle
2022-07-21 13:58:17 <psykose> iirc it was neon supported, but i would assume the fpu would be the neon one then
2022-07-21 14:15:43 <ikke> 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 <psykose> it's still quite good for 'random gomod had a cve' if we ever get around to that
2022-07-21 14:17:29 <ikke> Yup
2022-07-21 14:19:42 <psykose> pushed all go rebuilds
2022-07-21 14:19:52 <psykose> arm will run out of space as always, have fun :)
2022-07-21 14:27:24 <ikke> Yaaaay
2022-07-21 17:11:10 <nmeum> 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 <bl4ckb0ne> anybody here had some issue with the latest jellyfin update?
2022-07-21 17:44:49 <ikke> I don't use jellyfin
2022-07-21 18:08:43 <Newbyte> 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 <psykose> i would rather not really
2022-07-21 18:09:36 <Newbyte> Correct me if I'm wrong, but I understand s390x Alpine mostly is used for Docker purposes?
2022-07-21 18:10:21 <ikke> That's at least one of the main usecases from what I understood
2022-07-21 18:11:24 <ikke> But once rv64 rust is a thing, we can finally upgrade py3-cryptography
2022-07-21 18:11:34 <Newbyte> 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 <ikke> Newbyte: These mainframes don't have a graphics card
2022-07-21 18:12:09 <Newbyte> Oh, I see then
2022-07-21 18:12:11 <ikke> desktop is not a thing on s390x
2022-07-21 18:12:14 <psykose> 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 <psykose> simple as
2022-07-21 18:12:24 <ikke> :)
2022-07-21 18:12:28 <Newbyte> So there's no s390x workstations?
2022-07-21 18:12:30 <ikke> psykose: and that would probably be cheap
2022-07-21 18:12:32 <ikke> Newbyte: no
2022-07-21 18:13:24 <Newbyte> we could save almost 1 GB of space by disabling supertuxkart on s390x probably
2022-07-21 18:13:32 <Newbyte> if storage space still is an issue
2022-07-21 18:13:42 <ikke> fine with me to disable it
2022-07-21 18:13:51 <psykose> we could save a lot of space by disabling half of aports on it lol
2022-07-21 18:14:12 <psykose> a lot of kde is there too
2022-07-21 18:14:16 <ikke> heh
2022-07-21 18:16:14 <psykose> i wouldn't mind doing it
2022-07-21 18:19:59 <alexdesmote> Hello !
2022-07-21 18:20:14 <ikke> o/
2022-07-21 18:20:50 <alexdesmote> how are you 
2022-07-21 18:20:58 <ikke> Doing quite alright
2022-07-21 18:21:09 <panekj> just disable all graphics stuff
2022-07-21 18:25:02 <Newbyte> actually, I guess someone could want to run a supertuxkart server on s390x?
2022-07-21 18:25:30 <durrendal> obviously the best use for an expensive IBM mainframe
2022-07-21 18:26:01 <panekj> Newbyte: do you want to?
2022-07-21 18:28:44 <Newbyte> panekj I'm good
2022-07-21 18:30:29 <Ariadne> my s390x machine takes too much power
2022-07-21 18:30:39 <Newbyte> done: !36710
2022-07-21 18:30:41 <Ariadne> i am probably going to sell it :p
2022-07-21 18:31:06 <Newbyte> where'd you get an s390x machine from anyway?
2022-07-21 18:31:35 <Ariadne> three dead ones from govdeals.com equals one working one
2022-07-21 18:35:43 <psykose> 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 <psykose> bigbrain
2022-07-21 18:36:04 <Ariadne> 
ACTION shrugs

2022-07-21 18:36:22 <psykose> i already have a working packaged port but i'm wondering how bad of an idea it is
2022-07-21 18:36:32 <psykose> it goes from unmaintained garbage to unmaintained garbage so it can't be that bad
2022-07-21 18:36:44 <psykose> main downside is it needs libelf
2022-07-21 18:38:29 <psykose> alternatively.. we could drop it, and patch out the 20 aports that use libexecinfo
2022-07-21 18:38:33 <psykose> but the current state doesn't really make sense
2022-07-21 18:57:08 <psykose> Ariadne: did you see my question about the armv7 baseline?
2022-07-21 18:59:15 <Ariadne> psykose: i have no idea what baseline is for armv7, did not introduce it
2022-07-21 18:59:44 <psykose> who would
2022-07-21 19:32:02 <divVerent> Stupid question, how much RAM does the s390x build machine have?
2022-07-21 19:32:34 <ikke> Why is that a stupid question?
2022-07-21 19:33:03 <ikke> 32G
2022-07-21 19:33:22 <divVerent> 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 <divVerent> given the game works on laptops with 2G RAM...
2022-07-21 19:37:37 <divVerent> 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 <divVerent> could also be a Go/s390x problem maybe, or something really bad in the glfw cgo code
2022-07-21 19:38:25 <ikke> The CI host didn't use more than 16G of ram over the last 12h
2022-07-21 19:38:32 <ikke> I suspect that
2022-07-21 19:38:32 <divVerent> ok, that's good
2022-07-21 19:38:42 <divVerent> so at least I don't need to feel guilty about having potentially OOM'd the machine
2022-07-21 19:40:08 <divVerent> but just a per-container memory limit for my own build
2022-07-21 19:40:27 <ikke> We don't have a per container memory limit
2022-07-21 19:40:36 <ikke> So not sure why it says it ran out of memory
2022-07-21 19:43:23 <divVerent> Is that maybe a 32bit arch with some kind of PAE-ish extension?
2022-07-21 19:43:54 <divVerent> 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 <ikke> No, iirc it's 64-bits
2022-07-21 19:44:33 <ikke> big-endian
2022-07-21 19:45:03 <ikke> In any case, I don't suspect anyone wanting to / able to play these games on s390x
2022-07-21 19:45:15 <ikke> It doesn't even have a desktop environment
2022-07-21 19:48:49 <ikke> divVerent: yes, it's 64 bit
2022-07-21 19:49:02 <ikke> So I suspect something else going on
2022-07-21 20:59:24 <divVerent> 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 <ikke> yes, that's a gitlab thing
2022-07-21 21:00:24 <panekj> It does nothing
2022-07-21 21:00:47 <ikke> To have more control over it, you need to have premium features
2022-07-21 21:00:54 <divVerent> 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 <ikke> We use it at most for maintainers approving MRs from others
2022-07-21 21:01:13 <divVerent> good then
2022-07-21 21:01:15 <ikke> No, no need to approve it
2022-07-21 21:01:30 <divVerent> 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 <psykose> it was ready forever but you had it set to draft :)
2022-07-21 21:02:00 <divVerent> sure
2022-07-21 21:02:08 <divVerent> because I wanted to combine this with a release of the game...
2022-07-21 21:02:17 <divVerent> except... well, Ubuntu kinda forced me to do that release earlier
2022-07-21 21:02:29 <divVerent> (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 <divVerent> like, the snap ALSA support pulls in half of GNOME just so it can show an error dialog
2022-07-21 21:03:37 <divVerent> something I am happy Alpine doesn't do... "df" looks so happy
2022-07-21 21:04:12 <panekj> lol at that eturnal mail
2022-07-21 21:04:34 <psykose> that doesn't sound related to alsa itself
2022-07-21 21:04:40 <divVerent> yeah, of course not
2022-07-21 21:04:44 <psykose> which has give or take 0 deps lol
2022-07-21 21:05:07 <psykose> panekj: which one
2022-07-21 21:05:26 <panekj> I got only one
2022-07-21 21:05:29 <divVerent> somewhere in there, Pulseaudio is also involved ;)
2022-07-21 21:05:54 <panekj> Dear Alpine team, please find attached a sprunge link containing our patch to include the...
2022-07-21 21:06:44 <psykose> where is that
2022-07-21 21:06:49 <panekj> aports
2022-07-21 21:06:50 <panekj> ml
2022-07-21 21:06:59 <panekj> 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 <psykose> ah
2022-07-21 21:07:25 <ikke> gone
2022-07-21 21:07:34 <psykose> i never check the aports ml
2022-07-21 21:07:37 <psykose> what a miserable place
2022-07-21 21:07:42 <ikke> I do
2022-07-21 21:07:45 <ikke> from time to time
2022-07-21 21:08:16 <panekj> I window shop it from time to time
2022-07-22 00:40:34 <psykose> rbq: alright, i got literally everything to work with wx 3.2 except for maitreya
2022-07-22 00:40:40 <vkrishn> hi, /etc/e2scrub.conf is packaged in e2fsprogs while /usr/sbin/e2scrub in e2fsprogs-extra
2022-07-22 00:40:44 <psykose> wayland actually usable now
2022-07-22 00:40:46 <vkrishn> hope this is ok ?
2022-07-22 00:42:04 <psykose> installing extra installs the base package
2022-07-22 00:54:50 <skarnet> there you go: !36732. Sorry for the delay.
2022-07-22 00:59:21 <psykose> gonna verify the bootstrap real quick
2022-07-22 01:11:43 <rbq> psykose: Ok, when will wx 3.2 be merged?
2022-07-22 01:11:51 <psykose> not until that is fixed
2022-07-22 01:11:58 <psykose> i can't just merge things and break random things from installing
2022-07-22 01:12:53 <rbq> From what you've seen so far, does it look like it is fixable?
2022-07-22 01:13:34 <psykose> it's your package, you tell me :)
2022-07-22 01:13:39 <psykose> if you want me to send you 3.2, i can
2022-07-22 01:19:10 <rbq> I'm not sure I'll be able to do much, don't know C++
2022-07-22 01:19:14 <psykose> 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 <psykose> 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 <psykose> but i've been awake for 35 hours and that's all for me for today
2022-07-22 01:22:54 <rbq> Good night
2022-07-22 07:20:37 <nmeum> 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 <ncopa> i tried compile rust with the crosscompiled binaries yes
2022-07-22 08:13:22 <ncopa> might have been a bug in rust or maybe in llvm. i dont know
2022-07-22 09:12:41 <nmeum> 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 <ncopa> correct. i was able to build rust with the crosscompiled binaries
2022-07-22 10:43:45 <ncopa> and i have pushed rust for riscv64 already
2022-07-22 10:44:14 <ncopa> so we now have rust on all our architectures
2022-07-22 10:44:30 <ncopa> well, as soon build-edge-riscv64 finishes
2022-07-22 12:46:50 <Ariadne> that takes us one step closer to being the best distro for using rust on :)
2022-07-22 13:05:43 <skarnet> if there is such a thing
2022-07-22 13:42:46 <Ermine> skarnet: please consider adding 'provide dev' line to depends() in mdevd-init.
2022-07-22 13:44:23 <skarnet> hm, good idea, but then the eudev init script should as well
2022-07-22 13:44:47 <skarnet> working on it
2022-07-22 13:44:49 <Ermine> it has this line in udev-trigger
2022-07-22 13:50:13 <Ermine> Because acpid depends on dev and I ended up running mdevd and udevd
2022-07-22 13:51:16 <skarnet> wait, in git master mdevd already provides dev
2022-07-22 13:52:23 <skarnet> 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 <skarnet> hint, hint
2022-07-22 13:52:55 <skarnet> but yeah for now udev needs to provide dev and mdevd already does in master
2022-07-22 14:07:17 <skarnet> !36741
2022-07-22 14:15:15 <Ermine> Please note that udev-trigger script also provides dev
2022-07-22 14:17:22 <skarnet> gah. Well that’s very silly.
2022-07-22 14:17:47 <skarnet> udev-trigger is the coldplug, not the device manager.
2022-07-22 14:18:28 <skarnet> 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 <Ermine> I think it's done so coldplug would be done even if it is not explicitly enabled
2022-07-22 14:21:58 <skarnet> maybe, but that’s very much the wrong way to ensure this
2022-07-22 14:22:04 <skarnet> setup-devd gets it right
2022-07-22 14:22:11 <skarnet> so it’s not needed
2022-07-22 14:22:22 <skarnet> (on Alpine)
2022-07-22 14:28:46 <skarnet> there, fixed. >.>
2022-07-22 15:06:19 <nmeum> time to re-enable all the rust aports on riscv64 and s390x :s
2022-07-22 15:18:01 <ikke> Let me upgrade the host first :P
2022-07-22 15:49:58 <ikke> Seems like rust is stuck
2022-07-22 15:50:30 <ikke> https://tpaste.us/en5E 
2022-07-22 15:50:35 <ikke> One process Z, one process S
2022-07-22 15:50:38 <ikke> no CPU usage
2022-07-22 15:52:04 <ikke> FUTEX_WAIT, so I don't think anythign will happen
2022-07-22 15:54:02 <ikke> upgrading the rv64 builder host
2022-07-22 16:04:20 <ncopa> hum
2022-07-22 16:04:45 <ncopa> i guess you can upgrade the host and reboot and wee what happens?
2022-07-22 16:05:16 <ikke> ncopa: just did that
2022-07-22 16:05:21 <ikke> host is up again
2022-07-22 16:42:47 <ikke> hmm, no gitea seems to be stuck 🤨
2022-07-22 17:56:12 <ikke> ncopa: the container was recreated
2022-07-22 17:56:29 <ikke> so the packages you installed for bootstrapping rust are no longer there
2022-07-22 17:56:36 <ikke> (I'm not sure why the container was gone)
2022-07-22 17:57:14 <ikke> ncopa: are these the packages that you put there? 
2022-07-22 17:57:16 <ikke> /var/cache/distfiles/tmp/packages/community/riscv64
2022-07-22 18:11:07 <ikke> installed cargo and rust from that repo
2022-07-22 18:41:33 <ncopa> ikke: yes, those are the packages
2022-07-22 18:41:37 <ncopa> thanks
2022-07-22 18:43:17 <ncopa> 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 <ikke> keeping an 👀 on the builder :)
2022-07-22 18:53:05 <ncopa> i have rebased my openssl3 branch from april
2022-07-22 18:53:12 <ncopa> had a zillion conflicts
2022-07-22 18:53:20 <ncopa> doing a rebuild now
2022-07-22 19:00:36 <sam_> 3 is looking slowly more promising in general, now that mariadb works
2022-07-22 19:01:24 <panekj> rustls supports 3 too
2022-07-22 19:02:26 <panekj> s/rustls/rust-openssl
2022-07-22 19:02:26 <alpine-meetbot> panekj meant to say: rust-openssl supports 3 too
2022-07-22 19:06:47 <psykose> mariadb only works from next release, technically
2022-07-22 19:06:59 <psykose> and anything rust only 'works' if they're not using the 5 year old crate
2022-07-22 19:07:05 <psykose> (they're definitely using the 5 year old crate)
2022-07-22 19:17:05 <sam_> oh right
2022-07-22 19:17:16 <sam_> 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 <psykose> today in fun rust stuff- cargo-c generated libraries have no SONAME
2022-07-22 19:35:17 <psykose> ???
2022-07-22 19:36:00 <ikke> And I'm wondering if rust is still making progress on rv64
2022-07-22 19:36:04 <psykose> hm
2022-07-22 19:36:08 <psykose> the arch one is correct
2022-07-22 19:36:12 <psykose> ours isn't
2022-07-22 19:36:14 <psykose> lets see..
2022-07-22 19:37:02 <ikke> I'll just be patient, at least one process is still 'doing' something
2022-07-22 19:37:13 <psykose> the rust build is usually on one thread
2022-07-22 19:37:33 <psykose> 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 <ikke> yes
2022-07-22 19:38:02 <ikke> but no thread / process is using any CPU atm
2022-07-22 19:38:05 <ikke> before it was
2022-07-22 19:38:25 <psykose> ah
2022-07-22 19:38:48 <panekj> it's not so painful because most stuff did update dependencies, and rest will be easily patchable
2022-07-22 19:38:51 <ikke> compiling rustc_interface
2022-07-22 19:42:51 <ikke> 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 <ikke> (in the build log)
2022-07-22 19:43:16 <psykose> those are correct
2022-07-22 19:43:19 <ikke> ok
2022-07-22 19:43:27 <psykose> this cargo-c shit is broken on musl
2022-07-22 19:43:27 <psykose> sigh
2022-07-22 19:43:54 <psykose> 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 <psykose> https://github.com/lu-zero/cargo-c/issues/180
2022-07-22 19:44:20 <psykose> nice meme
2022-07-22 19:44:36 <ikke> >1 year old
2022-07-22 19:48:06 <ikke> oh,  fun, the old 'oh, musl, it must be static, right?'
2022-07-22 19:50:30 <ikke> I feel like I'm watching paint dry, with the rust build atm
2022-07-22 19:51:39 <psykose> yeah, linked the part of the code that does that
2022-07-22 19:51:48 <psykose> in this case it's just a -type to fix so it doesn't matter too much
2022-07-22 19:51:51 <psykose> https://github.com/lu-zero/cargo-c/issues/267 is the bigger issue
2022-07-22 19:52:51 <psykose> why every time i get out of bed everything broken
2022-07-22 19:53:03 <ikke> Because everythign is brokenb
2022-07-22 19:53:06 <psykose> :)
2022-07-22 19:53:23 <ikke> And I cannot type
2022-07-22 19:53:31 <psykose> keyboard broke too, is ok
2022-07-22 19:57:46 <psykose> there should perhaps really be a check for that
2022-07-22 19:57:59 <psykose> a lint that checks if a .so.xyz file has an SONAME
2022-07-22 19:58:07 <psykose> with a warning otherwise
2022-07-22 19:58:31 <ikke> linting only does static checking
2022-07-22 19:58:42 <ikke> more something like checkapk
2022-07-22 19:58:46 <psykose> also the existing checkapk output isn't complete in CI because without `diffutils` it skips printing the sonames
2022-07-22 19:58:56 <psykose> checkapk already prints soname with the real diff
2022-07-22 19:59:03 <psykose> we just don't have the real diff
2022-07-22 19:59:20 <ikke> psykose: oh, that's something new then
2022-07-22 19:59:22 <ikke> it used to do that
2022-07-22 19:59:30 <psykose> it does it if you `apk add diffutils`
2022-07-22 19:59:37 <psykose> shall i perhaps find out why
2022-07-22 19:59:44 <psykose> what project is this under anyway
2022-07-22 19:59:50 <psykose> oh abuild
2022-07-22 19:59:52 <psykose> nvm not fixing it
2022-07-22 20:11:39 <panekj> can we have abuild but better
2022-07-22 20:29:31 <psykose> 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 <psykose> even for the things that did, there hasn't been a release in 9 months to include them
2022-07-22 20:30:09 <panekj> you don't have to tell me that (:
2022-07-22 20:35:05 <ikke> I'm fearing for rust on rv64
2022-07-22 20:37:34 <ikke> still stuck att rustc_interface
2022-07-22 20:43:40 <psykose> it takes my decent cpu 10 minutes for some of those parts
2022-07-22 20:43:44 <psykose> on rv it's probably 3 hours
2022-07-22 20:44:05 <psykose> 18x slower per thread.. maybe even more, so even more than that
2022-07-22 20:44:40 <ikke> I just see a constant stream of FUTEX_WAIT + etimeout
2022-07-22 20:46:03 <psykose> if there's really nothing else at all then i guess its fucked
2022-07-22 20:46:07 <psykose> did you upgrade the host yet?
2022-07-22 20:46:26 <ikke> yes
2022-07-22 20:46:29 <psykose> mm
2022-07-22 20:47:15 <psykose> maybe we should do some user vs system benchmarks?
2022-07-22 20:47:17 <psykose> i wouldn't mind
2022-07-22 20:47:29 <psykose> if it's not literally half the speed, i think it would work much better
2022-07-22 20:48:08 <psykose> because then we also fix all the weird syscall stuff and whatever too
2022-07-22 20:48:17 <psykose> only issue is that for system we need a kernel
2022-07-22 20:48:20 <psykose> lts is not built for rv
2022-07-22 20:48:29 <psykose> was there a reason for that? we can totally have an rv config
2022-07-22 20:48:33 <psykose> multiple people have requested it
2022-07-22 20:48:37 <ikke> No idea
2022-07-22 20:48:45 <ikke> We do have one for the rv64 boards we received
2022-07-22 20:48:45 <psykose> but -edge would also work fine, so eh
2022-07-22 20:48:55 <ikke> but not in aports
2022-07-22 20:49:26 <psykose> i guess i need to make an edge iso myself for rv and do some system benchmarks
2022-07-22 20:49:29 <psykose> anything you want to see?
2022-07-22 20:49:45 <ikke> I'd be curious
2022-07-22 20:49:50 <ismael> hi; I noticed the extended x86_64 ISO doesn't boot on qemu (with -cdrom file.iso).
2022-07-22 20:49:52 <psykose> i mean specific benchmarks
2022-07-22 20:50:12 <psykose> ismael: let me check that real quick
2022-07-22 20:50:14 <ikke> psykose: I suppose building something significant
2022-07-22 20:50:16 <psykose> can you post the full cmdline
2022-07-22 20:50:24 <psykose> ikke: i can do the usual compiler tests, but maybe there's something else
2022-07-22 20:50:33 <ikke> Can't thing of anything else
2022-07-22 20:50:34 <psykose> kcbench is pretty good for a build, though takes forever
2022-07-22 20:53:03 <psykose> 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 <ismael> 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 <ismael> hmm, didn't seem like a too-little-ram error, but let me try
2022-07-22 20:54:05 <psykose> fails without it for me
2022-07-22 20:54:15 <ismael> ah, yes, it is
2022-07-22 20:54:24 <ismael> is the initramfs that big? :(
2022-07-22 20:54:26 <psykose> iirc by default the image goes into ram
2022-07-22 20:54:31 <psykose> the extended is literally 1G so
2022-07-22 20:54:33 <ismael> the whole thing?
2022-07-22 20:54:36 <ismael> oh
2022-07-22 20:54:47 <psykose> or well, 700
2022-07-22 20:54:48 <psykose> hmm
2022-07-22 20:55:04 <psykose> what is the default?
2022-07-22 20:55:06 <psykose> -m 512 works
2022-07-22 20:55:24 <ismael> I was just testing that
2022-07-22 20:55:27 <psykose> -m 256 works
2022-07-22 20:55:32 <ismael> I think the default is 128
2022-07-22 20:55:36 <psykose> 128 doesnt
2022-07-22 20:55:54 <psykose> yeah, i guess extended just needs more ram for whatever is happening there
2022-07-22 20:55:54 <Hello71> no, it's only the initramfs. iirc it's just enough to successfully fail
2022-07-22 20:56:10 <psykose> and indeed the initrd would be bigger
2022-07-22 20:56:16 <Hello71> hm, right.
2022-07-22 20:56:34 <Hello71> i found that with standard + virtio-vga + maximized window it would hang on black screen
2022-07-22 20:57:20 <ismael> why is initramfs so bloated? :S
2022-07-22 20:57:44 <panekj> "bloated"
2022-07-22 20:57:48 <psykose> it has all of linux-firmware
2022-07-22 20:57:56 <ismael> does it need all of it?
2022-07-22 20:57:57 <panekj> so I can boot my fancy linux on weird hardware
2022-07-22 20:58:03 <panekj> ismael: yes
2022-07-22 20:58:06 <psykose> it's extended for a reason
2022-07-22 20:58:11 <ismael> probably 99% of that is things that aren't needed for boot
2022-07-22 20:58:14 <psykose> why are you using /extended/ in qemu?
2022-07-22 20:58:21 <psykose> that is the part that makes no sense
2022-07-22 20:58:28 <ismael> just testing it before runing in real metal
2022-07-22 20:58:42 <psykose> ah
2022-07-22 20:59:03 <psykose> well, real x86_64 metal has more than 128M of ram, so you'll be fine
2022-07-22 20:59:52 <panekj> and if you care so much about "bloated" initramfs, don't use extended ISO
2022-07-22 20:59:55 <psykose> 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 <psykose> the main goal is to not need networking to function to get most of an install working
2022-07-22 21:00:33 <psykose> 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 <ismael> 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 <ismael> (compressed)
2022-07-22 21:01:16 <ismael> s/psykose/panekj/
2022-07-22 21:01:16 <alpine-meetbot> 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 <psykose> the generated initramfs after is not going to be very big
2022-07-22 21:01:40 <psykose> the main issues with extended currently is it had some issues with actual wifi
2022-07-22 21:02:00 <panekj> we should have all main installed in extended
2022-07-22 21:02:16 <psykose> that would be like 30G
2022-07-22 21:02:30 <psykose> nice joke panekj
2022-07-22 21:02:32 <panekj> official alpine blurays distribution when?
2022-07-22 21:13:18 <Hello71> since when does initramfs have all firmwares
2022-07-22 21:13:29 <Hello71> the whole point of modloop is that it doesn't
2022-07-22 21:14:35 <Hello71> 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 <psykose> i merely confused the two
2022-07-22 21:24:36 <psykose> https://github.com/lu-zero/cargo-c/blob/f6d4984081eec30211af96c38d14844ce0fa222a/src/target.rs#L74-L81
2022-07-22 21:24:39 <psykose> new hotness just dropped
2022-07-22 21:24:46 <psykose> if you're on musl you don't have sonames on the platform right
2022-07-22 21:24:56 <psykose> just not supported :(
2022-07-22 21:39:10 <ikke> yaaay
2022-07-22 21:40:53 <psykose> fixed https://github.com/lu-zero/cargo-c/pull/268
2022-07-22 21:48:19 <skarnet> 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 <skarnet> I’ll try to answer everything tomorrow
2022-07-22 21:49:26 <skarnet> 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 <skarnet> 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 <ptrc> psykose: it's actually 3.2GB with mesa-dbg, kyua-dbg and some other stuff
2022-07-23 04:06:02 <psykose> what is
2022-07-23 04:06:16 <ptrc> ah, my buffer was scrolled up..
2022-07-23 04:06:21 <ptrc> main edge
2022-07-23 04:17:03 <ptrc> 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 <ptrc> so i guess stuffing all of main onto a dvd is not the best idea after all
2022-07-23 05:04:09 <ikke> rust is still stuck at rustc_interface, so I'd say it's stuck
2022-07-23 05:06:37 <psykose> yup
2022-07-23 06:29:12 <bratkartoffel> 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 <ikke> Not sure that still exists, but I can try
2022-07-23 06:31:00 <bratkartoffel> 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 <ikke> I'll just try to build it in s390x
2022-07-23 06:43:20 <ikke> bratkartoffel: is it only 3.16 that fails? I was applying it on edge now
2022-07-23 06:46:02 <psykose> bratkartoffel: you mean https://img.ayaya.dev/6L2mG2JJxQpK ?
2022-07-23 06:46:21 <psykose> strange it's s390x only
2022-07-23 06:46:37 <psykose> __stack_chk_fail+0x2 breaking ssp_nonshared stuff
2022-07-23 06:46:43 <psykose> that should be like an x86 issue
2022-07-23 06:46:48 <psykose> maybe s390x is also special
2022-07-23 06:49:09 <psykose> 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 <psykose> there is a ppc already there too, weird
2022-07-23 06:53:49 <ikke> https://tpaste.us/wYme 
2022-07-23 06:54:49 <ikke> https://tpaste.us/JrPg
2022-07-23 06:54:52 <ikke> bratkartoffel: ^
2022-07-23 06:55:29 <psykose> Size difference for qt6-qtbase-dbg: 773 MiB -> 113 MiB
2022-07-23 06:55:31 <psykose> hehe
2022-07-23 06:55:37 <ikke> nice
2022-07-23 06:56:25 <psykose> Size difference for kwin-dbg: 400 MiB -> 48 MiB
2022-07-23 06:56:31 <psykose> it is after all a serious reduction in debug info, but
2022-07-23 06:57:32 <ikke> Yes, but I think that's acceptable for the intended usecase
2022-07-23 06:57:44 <ikke> end-users being able to provide stacktraces
2022-07-23 06:59:34 <psykose> yeah, just quite barren. granted, 90% of the time everything interesting is <optimized out> so
2022-07-23 06:59:46 <ikke> nod
2022-07-23 06:59:58 <ikke> but that has nothing to do with debug symbols, right?
2022-07-23 07:00:07 <ikke> compiler optmizations
2022-07-23 07:00:15 <psykose> never found a definitive answer
2022-07-23 07:00:44 <ikke> You need to build everything with -O0 I guess?
2022-07-23 07:00:59 <psykose> i've had half a stack trace be <optimized out> with -O0 -g3 -ggdb
2022-07-23 07:01:10 <ikke> including libraries?>
2022-07-23 07:01:16 <psykose> actual program
2022-07-23 07:01:16 <psykose> dunno
2022-07-23 07:01:19 <psykose> sometimes gdb just sucks
2022-07-23 07:01:44 <psykose> i've also had gdb have like
2022-07-23 07:01:46 <psykose> thing = value
2022-07-23 07:01:54 <psykose> and in the code that thing is just passed between 3 places
2022-07-23 07:01:59 <psykose> and in the 3rd one it's now <optimized out>
2022-07-23 07:02:03 <ikke> heh
2022-07-23 07:02:04 <psykose> but nothing even touches it
2022-07-23 07:02:31 <psykose> it's both an impressive piece of software and a piece of shit at once, haha
2022-07-23 07:02:58 <ikke> bratkartoffel: does that help?
2022-07-23 07:03:57 <ikke> Hmm, seems like more and more stuff keeps getting stuck on rv64
2022-07-23 07:06:35 <psykose> maybe the qemu update was bad
2022-07-23 07:06:37 <psykose> but, also
2022-07-23 07:06:41 <psykose> every time we do one of these uh
2022-07-23 07:06:44 <psykose> huge go rebuilds
2022-07-23 07:06:47 <psykose> there's quite a few go things that do
2022-07-23 07:06:49 <ikke> nod
2022-07-23 07:06:55 <psykose> flaky stucks, in a way
2022-07-23 07:07:10 <ikke> yeah, rust now got stuck at a different point as before
2022-07-23 07:07:59 <psykose> sigh
2022-07-23 07:08:06 <psykose> i really should get the test image for system
2022-07-23 07:08:16 <psykose> if it's only 20% or less (do you agree?) it would be worth a real shot
2022-07-23 07:08:44 <ikke> if it prevents things getting stuck, I'd think it would be worth it rather quickly
2022-07-23 07:08:54 <psykose> sure, let me bust out the mkimg
2022-07-23 07:09:03 <psykose> i assume it just works with linux-edge instead, but maybe i'm wrong
2022-07-23 07:09:05 <psykose> time for fun
2022-07-23 07:09:13 <ikke> I'll probably obliterate the mirror on nld5
2022-07-23 07:09:19 <psykose> good idea
2022-07-23 07:09:21 <ikke> as it's not getting updated anyway
2022-07-23 07:09:27 <psykose> also i had a question earlier in -infra about the dev.a.o server
2022-07-23 07:22:20 <psykose> running mkimg for x86_64 works, for riscv64 it's edge/main mirror UNTRUSTED signature
2022-07-23 07:25:28 <ikke> Not sure how it works exactly, but I suppose you need to add the rv64 key?
2022-07-23 07:25:51 <psykose> ah
2022-07-23 07:25:56 <psykose> sure, what do i add
2022-07-23 07:26:51 <ikke> https://pkgs.alpinelinux.org/contents?branch=edge&name=alpine-keys&arch=x86_64&repo=main
2022-07-23 07:27:09 <ikke> They're in /usr/share/apk/keys
2022-07-23 07:29:52 <psykose> thanks!
2022-07-23 07:30:18 <psykose> it go
2022-07-23 07:33:08 <psykose> grub-mkimage: not found
2022-07-23 07:33:09 <psykose> haha
2022-07-23 07:33:33 <psykose> i think it runs it on the host
2022-07-23 07:33:36 <psykose> need qemu-user
2022-07-23 07:35:17 <ikke> new ffmpeg is out
2022-07-23 07:35:22 <ikke> 5.1, lts release
2022-07-23 07:36:14 <psykose> nice
2022-07-23 07:36:16 <psykose> will do that too then
2022-07-23 07:36:22 <psykose> got the release notes
2022-07-23 07:36:26 <psykose> * ?
2022-07-23 07:37:17 <ikke> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/5.1:/RELEASE_NOTES
2022-07-23 07:37:18 <ikke> rather empty
2022-07-23 07:37:36 <ikke> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/5.1:/Changelog
2022-07-23 07:37:59 <psykose> neat
2022-07-23 07:38:10 <psykose> already the patch fails to reapply
2022-07-23 07:38:12 <psykose> goooood start
2022-07-23 07:38:28 <psykose> mm, no, grub-mkimage not found again
2022-07-23 07:39:19 <psykose> oh, i literally don't have it
2022-07-23 07:39:23 <psykose> silly me
2022-07-23 07:40:23 <ikke> :D
2022-07-23 07:41:17 <ikke> 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 <psykose> tis a silly error indeed
2022-07-23 07:42:26 <psykose> and then some people actually say it makes sense :)
2022-07-23 07:42:41 <psykose> grub-mkimage: error: cannot open `/usr/lib/grub/riscv64-efi/moddep.lst': No such file or directory.
2022-07-23 07:42:48 <psykose> now this i need to shim copy random shit for
2022-07-23 07:42:54 <psykose> the lack of noarch sucks
2022-07-23 07:43:14 <psykose> 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 <ikke> That's the easy part
2022-07-23 07:44:04 <ikke> What builder is responsible for noarch packages?
2022-07-23 07:48:07 <psykose> hmm
2022-07-23 07:48:45 <psykose> i would say 'any' and just taking latest uploaded, but also making a lot of packages not-noarch
2022-07-23 07:49:03 <psykose> i don't think py3-* should be for instance
2022-07-23 07:49:04 <psykose> or well, idk
2022-07-23 07:49:20 <ikke> But you want things to be consistent, and the index needs to be signed
2022-07-23 07:49:27 <psykose> right
2022-07-23 07:49:36 <psykose> but to even do this, we have to split builder from mirror, right
2022-07-23 07:49:46 <psykose> and at that point the sign gets reworked and comes from elsewhere
2022-07-23 07:49:55 <psykose> it's 'separate' from this issue slightly
2022-07-23 07:49:59 <ikke> yes
2022-07-23 07:50:56 <psykose> the ffmpeg release has no soname change it seems
2022-07-23 07:51:10 <ikke> nice
2022-07-23 07:52:08 <psykose> chromium still starts and works
2022-07-23 07:52:13 <psykose> and that had an entire patch in ffmpeg for
2022-07-23 07:52:14 <psykose> neat
2022-07-23 07:52:49 <psykose> /sbin/update-kernel: line 303: install: not found
2022-07-23 07:52:50 <psykose> lol
2022-07-23 07:53:33 <psykose> i do have qemu-user running..
2022-07-23 08:07:44 <psykose> still not sure why that happens
2022-07-23 08:20:22 <psykose> ah, it's actually misassuming some stuff and missing files
2022-07-23 08:21:02 <psykose> commented out random stuff
2022-07-23 08:23:33 <psykose> mm, only opens the qemu monitor..
2022-07-23 08:30:58 <psykose> ah, cause it's secretly just at 100% cpu in the background
2022-07-23 08:31:05 <psykose> not sure it's working, heh
2022-07-23 09:16:05 <ikke> rv64 is making progress atm
2022-07-23 10:38:12 <psykose> god i hate stack sizes
2022-07-23 10:45:53 <ncopa> 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 <ncopa> it is also big-endian. could be buffer overflow that only affects big-endian?
2022-07-23 10:49:29 <ikke> ncopa: I had to kill rust again :(
2022-07-23 10:49:47 <ikke> had it running all night, but no progress
2022-07-23 10:51:56 <psykose> 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 <oliv3r[m][m]> /m @oftc-irc:matrix.org
2022-07-23 15:28:05 <Cogitri> 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 <Cogitri> It now just links against the shared version of libapk
2022-07-23 15:28:38 <Cogitri> It’s pretty lowlevel currently, maybe I’ll add higher level safe APIs once apk-tools v3 happens
2022-07-23 15:47:36 <Newbyte> How do I replace _ with . in a concise way in ash?
2022-07-23 15:48:47 <panekj> ${var/_/.} ?
2022-07-23 15:51:09 <Newbyte> looks good, thanks!
2022-07-23 15:53:33 <orbea> Newbyte: fwiw the portable way is tr(1), but seems alpine ash has extra features :)
2022-07-23 15:54:25 <Newbyte> 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 <orbea> agreed, just putting the info out there in case its helpful in the future
2022-07-23 16:17:18 <Newbyte> 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 <psykose> patch the thing that makes it or sed
2022-07-23 16:17:30 <psykose> former is easiest
2022-07-23 16:17:45 <psykose> or generate it yourself; 95% of pkgconfs is a .pc.in with a single @VERSION@ in it
2022-07-23 16:18:03 <psykose> sed 's|@VERSION@..' .pc.in > "$pkgdir"/ ..
2022-07-23 16:34:38 <Newbyte> 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 <psykose> nobody has defined the pkg-config version spec
2022-07-23 16:45:32 <psykose> so understandably it sucks, the pkgconf implementation is probably gentoo-style or a bit less
2022-07-23 16:45:58 <psykose> and pkg-config probably copypastes the rpm code which can have rand() output in the version i guess
2022-07-24 07:19:23 <sam_> i recently added a qa check for a bunch of .pc stuff
2022-07-24 07:19:27 <sam_> the amount of junk
2022-07-24 07:20:00 <sam_> 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 <sam_> these cheesy things hardcoding prefixes
2022-07-24 07:20:11 <sam_> wrong libdir is really common
2022-07-24 07:20:29 <sam_> 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 <ikke> rust hangs again, same point: rustc_interface 😔
2022-07-24 17:29:09 <ikke> I'll let it continue 
2022-07-24 19:10:33 <psykose> 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 <psykose> ld.lld: error: unknown emulation: elf64_s390
2022-07-24 19:10:40 <psykose> 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 <psykose> and of course it fails hundreds of its unit tests
2022-07-24 19:26:15 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/jobs/779930
2022-07-24 19:26:18 <psykose> all the other arches pass fine
2022-07-24 20:21:40 <psykose> what's funny is even riscv64 passes all the tests
2022-07-25 04:22:12 <ikke> rv64 looks dire
2022-07-25 06:40:47 <ncopa> good morning
2022-07-25 06:49:40 <ncopa> rv64 has run rust all weekend, right?
2022-07-25 06:50:01 <ncopa> and no progress? its stuck at Compiling rustc_interface v0.0.0..?
2022-07-25 06:51:25 <ncopa> let me try kill stuff
2022-07-25 06:54:04 <ikke> I restarted it yesterday morning 
2022-07-25 06:56:35 <ikke> Then it was stuck in a zombie state 
2022-07-25 06:57:03 <ikke> But now and before it hangs at rustc_interface
2022-07-25 07:10:11 <ncopa> oh sorry... i killed it
2022-07-25 07:10:14 <ncopa> re-running now
2022-07-25 07:10:22 <ncopa> catching up on other stuff first
2022-07-25 07:10:52 <ncopa> when i built it in my dev env, it appeared to be stuck multiple times
2022-07-25 07:11:01 <ncopa> but it did progress, slowly
2022-07-25 07:11:14 <ncopa> it took 5-6 hours in total to build it
2022-07-25 07:17:44 <ncopa> ok her we go again
2022-07-25 09:54:44 <pabloyoyoista> ikke: sorry to bother you again. Any chance you can recheck the appstream MRs pending on infra?
2022-07-25 10:14:51 <ikke> pabloyoyoista: oh, yes, I promised to look at that, sorry
2022-07-25 10:32:59 <ncopa> 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 <ptrc> 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 <ncopa> LGTM
2022-07-25 10:55:23 <ikke> mergedf
2022-07-25 10:55:47 <ptrc> thanks again :)
2022-07-25 12:15:50 <pabloyoyoista> Thanks a lot ikke :)
2022-07-25 12:20:36 <ncopa> \o/ 
2022-07-25 12:20:37 <ncopa> >>> rust: Updating the community/riscv64 repository index...
2022-07-25 12:20:37 <ncopa> >>> rust: Signing the index...
2022-07-25 12:29:03 <ikke> Wow
2022-07-25 12:29:11 <ikke> It happened! 
2022-07-25 13:29:02 <Piraty> :>
2022-07-25 13:31:57 <orbea> until the next release :P
2022-07-25 13:35:45 <ncopa> 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 <ikke> I watched all weekend 😢
2022-07-25 13:37:28 <ncopa> you are not scary enough :)
2022-07-25 13:39:15 <ikke> 😑
2022-07-25 13:46:33 <skarnet> 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 <Piraty> 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 <panekj> did you clone the repo or create your own
2022-07-25 13:58:25 <Piraty> cloned aports, made a new package
2022-07-25 13:58:57 <panekj> abuild rootbld should work
2022-07-25 14:03:12 <Piraty> repo_template ends up wrong? https://0x0.st/ojpN.txt
2022-07-25 14:03:59 <ncopa> 👍
2022-07-25 14:04:18 <Piraty> setting APORTSDIR manually would fix it
2022-07-25 14:04:31 <Piraty> but aportsgit=${APORTSDIR:-${startdir}} is probably not right
2022-07-25 14:04:47 <Piraty> if it's intended to point to repo root
2022-07-25 14:13:02 <Piraty> am i holding it wrong?
2022-07-25 18:09:55 <ptrc> 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 <ikke> bb is stuck again on 3.16
2022-07-25 20:32:53 <ikke> I suppose we need to backport that fix from nmeum?
2022-07-25 20:33:45 <ikke> but.. 
2022-07-25 20:35:08 <ikke> yes, it would make sense to backport it
2022-07-25 21:07:12 <ikke> pabloyoyoista: I've deployed the latest changes, and removed the DB dir
2022-07-25 21:13:17 <ikke> 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 <pabloyoyoista> ikke: thanks a lot!
2022-07-25 21:27:38 <pabloyoyoista> 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 <pabloyoyoista> And there is an "eol_date", which could be used to filter for non-supported versions
2022-07-25 21:30:10 <pabloyoyoista> 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 <ikke> I already opened the issue :)
2022-07-25 21:31:02 <ikke> I'll assign it
2022-07-25 21:43:03 <pabloyoyoista> Perfect, thank you!
2022-07-25 23:42:16 <andypost[m]> Any idea why clang -dbg package size nearly twice smaller? !36819
2022-07-25 23:43:41 <psykose> magic
2022-07-25 23:43:49 <psykose> don't think the info in there would be different
2022-07-25 23:44:10 <andypost[m]> maybe it using compressin out of box
2022-07-25 23:44:46 <psykose> nope
2022-07-25 23:44:48 <psykose> not without -gz
2022-07-25 23:47:24 <psykose> 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 <psykose> 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 <psykose> (more or less)
2022-07-25 23:48:06 <psykose> it's just better, dunno
2022-07-25 23:48:16 <psykose> tons of stuff just becomes 20% smaller with clang for no reason
2022-07-25 23:48:22 <psykose> or sometimes bigger :)
2022-07-25 23:48:45 <psykose> 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 <psykose> 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 <psykose> and default -dbg adds `-g`
2022-07-25 23:49:41 <psykose> project might be overriding it anyway, but good to know
2022-07-25 23:50:32 <andypost[m]> it makes sense to apply to php8 and php81 as both are stable enough
2022-07-26 05:13:22 <psykose> for whoever here uses chromium, i would appreciate it if you would test the latest artifacts from !36785
2022-07-26 05:29:11 <ikke> installed it
2022-07-26 05:31:57 <ikke> seems to work fine
2022-07-26 05:32:06 <ikke> at least, initial tests
2022-07-26 05:32:29 <psykose> yea
2022-07-26 05:32:32 <psykose> which is pretty good
2022-07-26 05:32:40 <psykose> aside from that seemed faster than usual, but i'm always biased
2022-07-26 05:34:21 <psykose> memory footprint also looks a lot better with partition malloc at a glance
2022-07-26 05:34:30 <psykose> (which is the main change i guess, as sketchy as it is)
2022-07-26 05:43:30 <ptrc> 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 <ikke> nice
2022-07-26 05:44:19 <ptrc> 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 <ptrc> also, wow, the go apkbuild parser is really nice :)
2022-07-26 05:46:04 <ikke> thanks
2022-07-26 05:46:40 <psykose> 'another'
2022-07-26 05:46:42 <psykose> there was like three
2022-07-26 05:46:46 <psykose> at once.
2022-07-26 05:46:54 <ikke> :D
2022-07-26 05:47:11 <psykose> '>.>
2022-07-26 05:47:23 <ikke> It would get meta once we have a circular dependency on circular dependency checkers
2022-07-26 05:47:49 <psykose> ptrc: rewrite it in python so we can make it happen
2022-07-26 05:48:38 <ptrc> 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 <psykose> high quality ;/
2022-07-26 05:51:10 <ikke> speed was one of the reasons I made this, mdvdan.cc/sh being available another major contributor
2022-07-26 09:35:09 <Piraty> ptrc: the (only) git-remote isn't called 'origin' but 'upstream'
2022-07-26 09:35:25 <Piraty> foolish to assume everyone names it origin
2022-07-26 09:35:45 <Piraty> as usually, origin is *my* gitlab/github fork
2022-07-26 09:35:59 <psykose> what is the context
2022-07-26 09:36:11 <panekj> abuild rootbld not working because not found .rootbld-repositories
2022-07-26 09:36:15 <psykose> ah
2022-07-26 09:36:18 <panekj> because it didn't derive path properly
2022-07-26 09:47:38 <ikke> Piraty: I don't have any remote called origin, but rootbld works for me
2022-07-26 09:48:44 <psykose> it also checks if it's ~/aports
2022-07-26 09:48:46 <ptrc> ikke: is your aports repo at "$HOME/aports" by any chance? :p
2022-07-26 09:48:56 <psykose> or APORTSDIR
2022-07-26 09:48:57 <psykose> etc
2022-07-26 09:49:42 <ikke> ptrc: yes 
2022-07-26 09:49:59 <psykose> lucked into the one hardcoded configuration then
2022-07-26 09:50:10 <panekj> abolish abuild
2022-07-26 09:50:16 <ikke> Like it ought to 
2022-07-26 09:50:22 <ikke> :-P
2022-07-26 09:52:24 <psykose> ~/aports is akin to ~/.randomapplication
2022-07-26 09:52:29 <psykose> nuked from orbit
2022-07-26 10:07:15 <Piraty> 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 <psykose> for this you would want to.. hardcode APORTSDIR= in env to the path
2022-07-26 10:08:07 <psykose> i guess
2022-07-26 10:08:10 <psykose> aside from that, yea
2022-07-26 10:08:24 <psykose> i have like 3 patches i manually go type into abuild every time i reinstall it by accident
2022-07-26 10:09:17 <panekj> I'm rewriting abuild in different language so, I guess that counts as wrapper?
2022-07-26 10:36:00 <donoban> 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 <donoban> what language is?
2022-07-26 10:36:38 <panekj> I'm rewriting whole abuild
2022-07-26 10:36:56 <donoban> so with rootbld too
2022-07-26 10:37:51 <psykose> 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 <psykose> (separate files for things aside, of course)
2022-07-26 10:41:33 <donoban> 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 <panekj> I think it would be even more confusing
2022-07-26 10:47:56 <donoban> psykose: the "same logic" it's just rootbld calling abuild
2022-07-26 10:48:09 <psykose> that's what i mean
2022-07-26 10:48:15 <donoban> the rootbld should only handle, bwrap, apk --init, etc...
2022-07-26 10:48:19 <psykose> yeah
2022-07-26 10:49:11 <psykose> and that's all it does
2022-07-26 10:49:25 <psykose> 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 <donoban> well, in a pretty unflexible way
2022-07-26 10:49:53 <donoban> I had a local version without rootbld_actions()
2022-07-26 10:49:59 <psykose> 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 <donoban> it just passes the args of: abuild rootbld args..
2022-07-26 10:50:12 <donoban> to the abuild inside the container
2022-07-26 10:50:35 <donoban> I wanted to replicate the exact behaviour of a plain abuild inside the sandbox
2022-07-26 10:51:15 <donoban> but I needs a change on the mounpoints scheme so it can remove pkg/ src/ on cleanup
2022-07-26 10:51:21 <psykose> 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 <donoban> I can try to fix this version without the hardocded list
2022-07-26 10:52:27 <donoban> but I don't know what to do with the mounpoints
2022-07-26 10:53:32 <donoban> uhmm, I have to take a look
2022-07-26 10:53:45 <donoban> but anyway, will be abuild replaced with another language?
2022-07-26 10:54:06 <psykose> probably not anytime soon
2022-07-26 10:54:33 <donoban> I need some months for a 2 lines merge
2022-07-26 10:54:39 <donoban> needed*
2022-07-26 10:54:43 <donoban> :)
2022-07-26 10:55:16 <psykose> that's what i mean, it's frustrating to try and actually fix anything in it
2022-07-26 10:56:44 <donoban> having a different code for just rootbld
2022-07-26 10:56:48 <donoban> could help on it
2022-07-26 10:57:07 <donoban> breaking something on rootbld couldn't not affect to abuild 
2022-07-26 10:57:29 <donoban> so rootbld could be improved fast and easily
2022-07-26 10:57:33 <psykose> 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 <psykose> sure, i can go write my own rootbld and come up with something workable
2022-07-26 10:58:05 <psykose> 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 <psykose> 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 <psykose> and nothing gets upstreamed into abuild, so it's pointless to spend time on it
2022-07-26 10:58:38 <donoban> uhM
2022-07-26 10:59:10 <donoban> well I would maintain rootbld as part of abuild project
2022-07-26 10:59:12 <donoban> in same repository
2022-07-26 10:59:24 <psykose> 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 <donoban> I started thinking on this when I saw the problem with python tests
2022-07-26 11:00:06 <psykose> 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 <donoban> and the problem with community dependency for tests on main packages
2022-07-26 11:00:22 <psykose> that one does not have a fix with the current infra
2022-07-26 11:00:28 <psykose> unrelated to abuild
2022-07-26 11:01:23 <donoban> current rootbld seems a limitation for having the possiblity of use community packages for test main packages
2022-07-26 11:01:35 <donoban> probably is not the only one
2022-07-26 11:01:41 <donoban> but I felt that i could be fixed
2022-07-26 11:03:57 <donoban> s/i/it
2022-07-26 11:03:57 <alpine-meetbot> donoban meant to say: but I felt that it could be fixed
2022-07-26 11:04:55 <psykose> fixing it would be useless for aports
2022-07-26 11:04:55 <panekj> > but anyway, will be abuild replaced with another language?
2022-07-26 11:04:59 <panekj> is there a need for that?
2022-07-26 11:05:16 <psykose> 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 <psykose> it's not an abuild issue that community/ things cannot be used in main/
2022-07-26 11:05:59 <psykose> 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 <panekj> > current rootbld seems a limitation for having the possiblity of use community packages for test main packages
2022-07-26 11:06:22 <panekj> correct behaviour, community should not leak into main
2022-07-26 11:06:43 <psykose> indeed
2022-07-26 11:07:03 <psykose> now, one could say 'okay it shouldnt leak at runtime but for tests we can make some exceptions'
2022-07-26 11:07:05 <ptrc> wasn't it also broken the other way though?
2022-07-26 11:07:06 <psykose> and sure, that makes sense
2022-07-26 11:07:12 <panekj> 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 <donoban> well that design decision "leaks" a lot of packages into main for be able to run tests
2022-07-26 11:07:23 <psykose> but it needs a redesign of the whole thing
2022-07-26 11:07:24 <ptrc> as in, you can't use locally built main/ packages when rootblding something from community
2022-07-26 11:07:35 <psykose> that's a separate issue
2022-07-26 11:07:52 <donoban> build and test are different things
2022-07-26 11:08:10 <donoban> I understand that the current situation is to avoid too much complexity
2022-07-26 11:08:12 <panekj> donoban: but that at least forces them to be supported for entirety of alpine version lifetime
2022-07-26 11:08:20 <psykose> i don't agree that they are different things
2022-07-26 11:08:26 <ikke> That's not limited to rootbld 
2022-07-26 11:08:28 <panekj> build and test are same things
2022-07-26 11:08:35 <ikke> Ooh n/m
2022-07-26 11:08:47 <donoban> well, the same the same..
2022-07-26 11:08:55 <ikke> Responding to an older message 
2022-07-26 11:09:40 <ikke> But you also need to think about bootstrapping 
2022-07-26 11:10:02 <donoban> does bootstrapping run some tests?
2022-07-26 11:11:03 <ikke> It runs all the tests if they are enabled 
2022-07-26 11:11:41 <psykose> i don't remember bootstrap.sh running any tests
2022-07-26 11:11:55 <psykose> but we have two kinds of bootstrapping, and the other one does
2022-07-26 11:12:29 <donoban> well, I accept that main test dependencies should be on main too...
2022-07-26 11:12:53 <psykose> for the most part most of the tests are not useful anyway
2022-07-26 11:13:02 <donoban> but won't be rootbld better separated of abuild code?
2022-07-26 11:13:04 <psykose> especially in python land
2022-07-26 11:13:23 <psykose> separated in what sense? 'rootbld' just creates the root environment, and the rest is abuild functions
2022-07-26 11:14:29 <donoban> yes, just do that outside abuild code
2022-07-26 11:14:47 <psykose> and what would the benefit be
2022-07-26 11:15:17 <psykose> 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 <psykose> just instead of being at line 2000 in rootbld() it would be in a file
2022-07-26 11:15:42 <donoban> cleanear abuild code, possiblity to modify or add features to rootbld
2022-07-26 11:16:16 <donoban> there are few lines because the current rootbld freatures is very limited
2022-07-26 11:16:19 <psykose> it's.. exactly the same though?
2022-07-26 11:16:19 <panekj> you can add features to rootbld
2022-07-26 11:16:22 <donoban> it even hardcodes the args pased to abuild
2022-07-26 11:16:32 <psykose> and that has nothing to do with it being inside abuild
2022-07-26 11:16:40 <panekj> 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 <psykose> being in the same file is not the limitation of any of thise
2022-07-26 11:17:04 <psykose> the reason all of that is true is because it was made that way
2022-07-26 11:17:12 <psykose> not 'whoops, its in the same file, guess it has to be that way'
2022-07-26 11:17:47 <donoban> well, when you try to modify rootbld currently
2022-07-26 11:17:53 <donoban> you are also affecting abuild
2022-07-26 11:18:06 <psykose> no?
2022-07-26 11:18:16 <donoban> and the sandboxed abuild will be different
2022-07-26 11:18:38 <psykose> yes, but that's identical to doing it out of file
2022-07-26 11:18:40 <donoban> it's not very difficult to "fix"
2022-07-26 11:18:42 <donoban> no
2022-07-26 11:18:51 <donoban> because if it's different and abuild is small/simple/etc..
2022-07-26 11:18:55 <donoban> you will modify the rootbld code
2022-07-26 11:19:00 <donoban> and abuild will be unaffected
2022-07-26 11:19:09 <ptrc> abuild itself is unaffected though
2022-07-26 11:19:26 <ptrc> if you modify rootbld code, the only thing that changes is how abuild is called
2022-07-26 11:19:41 <psykose> 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 <donoban> for some things it was affected
2022-07-26 11:19:45 <ptrc> and that's the same regardless if it's part of the same file or not
2022-07-26 11:20:14 <donoban> I don't remember exactly but I had to overwrite the abuild after creating the chroot
2022-07-26 11:20:32 <donoban> anyway I also see like just a better design
2022-07-26 11:20:42 <donoban> thing of having a different sandbox solution
2022-07-26 11:20:52 <donoban> instead running bwrap, use docker, qemu...
2022-07-26 11:21:14 <ptrc> ...qemu?
2022-07-26 11:21:33 <ptrc> do you want to spin up a whole another vm just to build one package
2022-07-26 11:21:34 <panekj> qemu would be nice
2022-07-26 11:21:51 <donoban> hehe
2022-07-26 11:21:52 <panekj> ptrc: why not?
2022-07-26 11:22:14 <ptrc> seems like a massive waste of resources over little to no benefit
2022-07-26 11:22:16 <donoban> security paranoid like that
2022-07-26 11:22:31 <panekj> I see big benefit
2022-07-26 11:22:48 <psykose> vms are for losers
2022-07-26 11:23:00 <donoban> baremetal!
2022-07-26 11:39:32 <Piraty> *cough*tainers
2022-07-26 11:40:01 <panekj> I'll implement microVMs in abuild
2022-07-26 11:50:56 <Piraty> 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 <donoban> better do it apart ;)
2022-07-26 11:52:08 <donoban> 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 <Piraty> take a look at what xbps-src does in that regard if you want some inspiration
2022-07-26 11:52:29 <panekj> what flexibility and where
2022-07-26 11:53:10 <donoban> do whatever you want wherever :P
2022-07-26 11:53:28 <panekj> so just like right now
2022-07-26 11:54:32 <donoban> Piraty: what's this? I don't have experience with void-linux
2022-07-26 11:54:42 <donoban> it's like the equivalent abuild?
2022-07-26 11:54:54 <panekj> xbps-src builds packages from source
2022-07-26 11:55:38 <panekj> it's not exact equivalent, it's more like apt-src
2022-07-26 11:55:49 <Piraty> xbps-src is the build tool bundled with the void-packages repo, yes it builds packages from source
2022-07-26 11:56:23 <donoban> ok
2022-07-26 11:56:45 <Piraty> i understand that abuild, in addition to build packages from source, wraps some common maintenance stuff as well?
2022-07-26 11:58:31 <donoban> uhm, what kind of 'common maintenance'?
2022-07-26 12:07:41 <panekj> Piraty: it builds stuff and it makes index
2022-07-26 12:07:59 <Piraty> same does xbps-src
2022-07-26 12:08:29 <panekj> or to be exact, it tells `apk` to make index
2022-07-26 12:09:02 <Piraty> so does xbps-src, telling xbps to make index ;) and calling xbps-* for the various package related stuffz
2022-07-26 12:10:12 <Piraty> anyway, https://github.com/void-linux/void-packages/#chroot-methods for what you talked about
2022-07-26 12:15:05 <donoban> so the chroot implementations are outside xbps-src itself?
2022-07-26 12:20:27 <donoban> this is interesting https://github.com/void-linux/void-packages/tree/master/common/chroot-style
2022-07-26 12:26:53 <Piraty> 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 <donoban> I just mean a different file
2022-07-26 12:29:35 <donoban> I cloned it for take a look 
2022-07-26 12:32:41 <donoban> uhM
2022-07-26 12:33:09 <donoban> uchroot.sh calls to exec xbps-uchroot..., but where is xbps-uchroot?
2022-07-26 12:35:13 <donoban> ah, its https://github.com/void-linux/xbps/tree/master/bin/xbps-uchroot
2022-07-26 12:35:36 <donoban> so yes, it's 'outside' :P
2022-07-26 12:37:22 <donoban> 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 <donoban> 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 <panekj> none
2022-07-26 12:38:15 <panekj> better, abandon trying to modify abuild, build something better
2022-07-26 12:38:16 <donoban> thats an option too
2022-07-26 12:38:18 <donoban> null
2022-07-26 12:38:52 <donoban> but panekj , what exactly do you think that writer another is better?
2022-07-26 12:39:08 <panekj> I don't understand the question
2022-07-26 12:39:11 <donoban> and anyway, the first question still relevant
2022-07-26 12:39:29 <donoban> sorry, I mean that whats the problem with the current abuild
2022-07-26 12:39:38 <donoban> that you think that will be fixed with a reimplementation
2022-07-26 12:40:01 <panekj> 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 <donoban> well, it's a critical piece, it needs careful review for changes
2022-07-26 12:42:13 <donoban> but I don't feel it's broken
2022-07-26 12:42:22 <panekj> 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 <panekj> I feel it's very broken
2022-07-26 12:42:57 <donoban> uhm, like net option?
2022-07-26 12:43:01 <panekj> no
2022-07-26 12:44:51 <donoban> I got to go, see you guys
2022-07-26 12:48:53 <pabloyoyoista> How do I do it for a pipeline in gitlab not to build a package?
2022-07-26 12:49:05 <pabloyoyoista> Like, it's building it even if neither the pkgver or pkgrel are increased
2022-07-26 12:50:52 <psykose> 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 <psykose> so python3 cannot load -musl.so anymore, which is all of them
2022-07-26 12:55:01 <ncopa> psykose: ouch!
2022-07-26 12:55:08 <ncopa> i'll fix it
2022-07-26 12:55:09 <psykose> i will rebuild them all, don't worry
2022-07-26 12:55:11 <psykose> already done with main
2022-07-26 12:55:30 <psykose> discovered via #14056 already, haha
2022-07-26 12:56:05 <psykose> also i figured out the clang ssp_nonshared patch, you had it right first try
2022-07-26 12:56:40 <ncopa> psykose: do you need me to do anything with python?
2022-07-26 12:56:44 <psykose> nah, i got it
2022-07-26 12:57:07 <ncopa> we are reverting it?
2022-07-26 12:57:25 <ncopa> we cannot rebuild eerything
2022-07-26 12:57:29 <psykose> i'd rather rebuilds because that is more clean and makes the pip musl wheels usable
2022-07-26 12:57:30 <psykose> sure we can
2022-07-26 12:57:33 <psykose> it's just a pkgrel bump
2022-07-26 12:57:40 <ncopa> we need be ABI compat
2022-07-26 12:57:45 <psykose> with what
2022-07-26 12:58:05 <ncopa> peoples preiously built modules
2022-07-26 12:58:10 <psykose> ah
2022-07-26 12:58:14 <psykose> yes, in that case..
2022-07-26 12:58:28 <psykose> ok, then you have to put the patch back
2022-07-26 12:58:33 <psykose> and i have to rebuild cffi one more time
2022-07-26 12:58:38 <psykose> sure, works
2022-07-26 12:59:22 <ncopa> i removed it because i thought it was applied upsteram
2022-07-26 13:00:09 <psykose> even if it was it would break the abi because of the naming
2022-07-26 13:00:26 <psykose> but eh, i guess all the python modules will just be -gnu forever, haha
2022-07-26 13:06:45 <ncopa> i think i removed the -gnu, but we cannot do it within a stable branch
2022-07-26 13:09:14 <psykose> 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 <psykose> and yeah, not in stable
2022-07-26 13:09:43 <psykose> 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 <ncopa> seems like one of the tests fails?
2022-07-26 13:17:23 <ncopa> in py3-cffi
2022-07-26 13:25:35 <ddevault> starting to rethink my plans of updating sr.ht boxen less frequently
2022-07-26 13:26:58 <ncopa> this shouldnt have happened. and it will not happen again.
2022-07-26 13:27:10 <ddevault> the py3-psycopg2 issue also
2022-07-26 13:27:25 <ddevault> the fact that community is unmaintained in old stable releases escaped my notice
2022-07-26 13:27:28 <ddevault> and probably rules it out
2022-07-26 13:32:37 <psykose> ncopa: they are also skipped for that reason
2022-07-26 13:32:43 <psykose> fwiw none of them actually fail on edge iirc
2022-07-26 13:32:57 <psykose> skipped with || true *
2022-07-26 13:34:00 <psykose> ncopa: we should really fix #14058 soon
2022-07-26 14:13:59 <ncopa> yeah, we should have a look at that
2022-07-26 14:29:57 <skarnet> 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 <skarnet> 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 <skarnet> s/everyone else/everything else/
2022-07-26 14:30:40 <alpine-meetbot> 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 <skarnet> s/very package builder/every package builder/
2022-07-26 14:30:59 <alpine-meetbot> 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 <skarnet> nice, alpine-meetbot has a memory of more than one line per user \o/
2022-07-26 14:31:47 <panekj> but I already know that
2022-07-26 14:32:20 <skarnet> 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 <panekj> I'm complaining so it gets fixed
2022-07-26 14:32:51 <panekj> just like you kept complaining to ncopa about stuff you wanted to get fixed/merged
2022-07-26 14:32:52 <skarnet> a non-broken package builder is a Holy Grail
2022-07-26 14:33:09 <skarnet> uh, not just like me, no
2022-07-26 14:33:22 <panekj> and my complaining at some point worked, to some extent
2022-07-26 14:33:24 <skarnet> I spam devs to merge shit *I have worked on*
2022-07-26 14:33:38 <psykose> very true
2022-07-26 14:33:38 <skarnet> you spam devs to fix shit without putting any effort yourself
2022-07-26 14:33:41 <skarnet> we are not the same
2022-07-26 14:33:46 <panekj> look at you
2022-07-26 14:33:49 <panekj> trying to start shit again
2022-07-26 14:33:51 <psykose> i mean
2022-07-26 14:34:00 <psykose> panekj had put in plenty of effort
2022-07-26 14:34:08 <psykose> (for 0 response)
2022-07-26 14:34:10 <psykose> and then gave up
2022-07-26 14:34:12 <psykose> same as me
2022-07-26 14:34:21 <psykose> it's not like there was 0 effort and just complaining
2022-07-26 14:34:22 <skarnet> into fixing abuild?
2022-07-26 14:34:30 <psykose> at least a start into something, yes
2022-07-26 14:34:36 <skarnet> my bad then, I stand corrected
2022-07-26 14:34:37 <panekj> I want to get abuild fixed properly, but I do not have mental capability for that now
2022-07-26 14:34:45 <psykose> core changes? no
2022-07-26 14:34:55 <psykose> but when you contribute a 2 line diff and it sits there for 6 months..
2022-07-26 14:35:17 <skarnet> in that case yes, we are the same
2022-07-26 14:35:27 <panekj> I have few changes that are opened, few that are left alone on my local PC
2022-07-26 14:35:42 <panekj> it's just that trying to get something *into* abuild is painful
2022-07-26 14:35:47 <panekj> as psykose said, left for months
2022-07-26 14:35:59 <panekj> thus my complaining
2022-07-26 14:36:18 <psykose> i wouldn't even care if they were all rejected
2022-07-26 14:36:31 <panekj> but I also skimmed through abuild many times and I have acquired a dislike for it
2022-07-26 14:36:35 <psykose> better than pending infinity
2022-07-26 14:36:58 <skarnet> 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 <skarnet> but yes there should be someone reviewing proposed changes
2022-07-26 14:37:19 <panekj> schrodinger's MRs, when you don't look at gitlab, your MRs are both merged and not merged
2022-07-26 14:37:25 <psykose> well yes, but it's self inflicted
2022-07-26 14:37:35 <psykose> only one person can maintain and do anything to abuild
2022-07-26 14:38:05 <skarnet> a small bus factor is both a blessing and a curse
2022-07-26 14:38:28 <psykose> it's a blessing when the bus is in operation
2022-07-26 14:38:30 <panekj> theoretically there are people designated to merged changes in abuild
2022-07-26 14:38:59 <panekj> practically it's "we don't know if this change is good enough for main maintainer's taste"
2022-07-26 14:39:09 <psykose> communication and responsiveness and all that
2022-07-26 14:42:24 <ncopa> i'm sorry that i cannot keep up with everything.
2022-07-26 14:42:32 <ncopa> is it my turn to complain now?
2022-07-26 14:42:37 <ncopa> 5c9f3ca3e307be53b45beeed2ce1626f38008625
2022-07-26 14:43:05 <ncopa> actually, its fb2496e8e08eec0708272fa1fd13bf0174250b95
2022-07-26 14:43:21 <Ariadne> if you want to hear complaints about things
2022-07-26 14:43:30 <ncopa> the post-deinstall adds syslog service
2022-07-26 14:43:36 <Ariadne> i can submit some of my own
2022-07-26 14:43:49 <ncopa> rc-update add syslog boot
2022-07-26 14:43:57 <skarnet> 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 <skarnet> 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 <ncopa> 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 <psykose> indeed looks like it should be removed
2022-07-26 14:45:14 <Ariadne> maintainer scripts should not be manipulating openrc like that
2022-07-26 14:45:15 <Ariadne> wtf
2022-07-26 14:45:21 <ncopa> exactly
2022-07-26 14:45:49 <psykose> it's also from 8 years ago
2022-07-26 14:45:54 <ncopa> im not gonna check who was the committer  - probably me anyway... :) - but this is bad
2022-07-26 14:45:56 <ncopa> yeah
2022-07-26 14:46:00 <psykose> (you)
2022-07-26 14:46:22 <psykose> sounds fine to just remove it
2022-07-26 14:46:25 <ncopa> yeah
2022-07-26 14:46:26 <skarnet> well 8 years ago the policies may not have been as well-defined as they are today
2022-07-26 14:46:31 <Ariadne> that one was
2022-07-26 14:47:08 <psykose> there is a bundled setup script but that one seems better
2022-07-26 14:47:35 <psykose> if it even works
2022-07-26 14:48:57 <skarnet> okay, about this syslogd, could we talk about the why before talking about the how
2022-07-26 14:49:50 <psykose> we may not. speaking is forbidden by the supreme council
2022-07-26 14:50:09 <panekj> you may send your complaints to HR
2022-07-26 14:50:09 <ncopa> anyone want to have a look at inetutils-syslogd
2022-07-26 14:50:23 <Ariadne> skarnet: i agree on that, inetutils-syslogd has an atrocious security record
2022-07-26 14:50:35 <Ariadne> should just be yeeted imo
2022-07-26 14:50:36 <psykose> my 'look' is remove from aports
2022-07-26 14:50:41 <skarnet> same
2022-07-26 14:50:43 <skarnet> I mean
2022-07-26 14:51:14 <skarnet> 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 <psykose> that's because
2022-07-26 14:51:22 <psykose> it's a mono-codebase
2022-07-26 14:51:25 <psykose> with 10 things in it
2022-07-26 14:51:29 <psykose> but split into 5 aports
2022-07-26 14:51:33 <psykose> so they all pass different --disable-this
2022-07-26 14:51:35 <psykose> and install one thing
2022-07-26 14:51:36 <skarnet> ah
2022-07-26 14:51:37 <Ariadne> all of which having atrocious security records
2022-07-26 14:51:38 <psykose> instead of subpackages
2022-07-26 14:51:44 <psykose> this was packaged wrong in the first place
2022-07-26 14:51:46 <psykose> :p
2022-07-26 14:51:56 <Ariadne> no, this just shouldn't have been packaged in the first place
2022-07-26 14:52:03 <psykose> yes, but by packaging methods
2022-07-26 14:52:08 <skarnet> ah yes it’s GNU inetutils
2022-07-26 14:52:11 <psykose> and the remaining 5 or so tools just don't exist
2022-07-26 14:52:13 <Ariadne> it's not like there's a shortage of syslogd implementations that have superior security record
2022-07-26 14:52:21 <skarnet> it does nothing that other software can’t do better
2022-07-26 14:52:28 <ncopa> 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 <Ariadne> i mean, basically *any* implementation has better security record than GNU inetutils :D
2022-07-26 14:52:41 <ncopa> :)
2022-07-26 14:53:20 <skarnet> 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 <panekj> 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 <Ariadne> 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 <ncopa> also a problem that I know the codebase best
2022-07-26 14:54:42 <ncopa> my code may be to ugly for other people want to touch it :)
2022-07-26 14:54:45 <Ariadne> speaking of aports, it would be cool if we could have packages built with melange instead
2022-07-26 14:54:47 <Ariadne> 
ACTION ducks

2022-07-26 14:55:03 <ncopa> 
ACTION throws a duck at Ariadne

2022-07-26 14:55:15 <panekj> melange but in rust and in main
2022-07-26 14:55:18 <panekj> 
ACTION hides

2022-07-26 14:55:35 <Ariadne> it was originally written in rust
2022-07-26 14:56:04 <skarnet> 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 <skarnet> having something *correct* would already be a superb start
2022-07-26 14:56:34 <panekj> afaik, the "understands existing APKBUILD syntax" is not (yet?) there
2022-07-26 14:56:34 <Ariadne> 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 <skarnet> yeah you can spawn a shell to interpret it, and collect the environment from the shell execution
2022-07-26 14:57:07 <ncopa> 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 <panekj> ncopa: is there any way to help make that happen
2022-07-26 14:58:20 <ncopa> 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 <ncopa> but it does mean alot to me, so thanks
2022-07-26 14:58:41 <ncopa> let me see what the current status is
2022-07-26 14:59:15 <ncopa> so, i think what would help would be to help improve test coverage
2022-07-26 14:59:28 <ncopa> looks like I already switched it to kyua
2022-07-26 14:59:37 <psykose> before you do anything at all
2022-07-26 14:59:41 <psykose> could you merge that rust change
2022-07-26 14:59:43 <psykose> and make a quick release
2022-07-26 14:59:45 <psykose> and then get to all this
2022-07-26 14:59:46 <psykose> :)
2022-07-26 14:59:51 <psykose> to at least put in the past 10 months of changes in
2022-07-26 14:59:52 <skarnet> 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 <ncopa> the URL?
2022-07-26 15:00:09 <ncopa> oh man.. i have a meeeting now
2022-07-26 15:00:23 <psykose> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/135
2022-07-26 15:00:24 <panekj> psykose: which?
2022-07-26 15:00:28 <Ariadne> me too
2022-07-26 15:00:32 <panekj> oh this
2022-07-26 15:00:35 <panekj> my MR
2022-07-26 15:01:11 <psykose> 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 <panekj> did you run every rust package? :P
2022-07-26 15:03:05 <panekj> 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 <panekj> s/whole aports aports/whole aports again
2022-07-26 15:03:19 <alpine-meetbot> 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 <panekj> 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 <psykose> more or less yes
2022-07-26 15:07:59 <psykose> 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 <donoban> ddevault: it would nice thak 'apk update' warms about unmaintaned repositories
2022-07-26 15:17:33 <ddevault> indeed
2022-07-26 15:18:27 <donoban> I wonder if it could be added to apkv3
2022-07-26 15:19:10 <Hello71> i think i have suggested this in past, also warning about incompatible repositories (e.g. alpine release + edge)
2022-07-26 15:20:51 <panekj> does apkv3 have any idea of repo versions?
2022-07-26 15:21:26 <panekj> otherwise that seems like very alpine-specific issue
2022-07-26 15:23:19 <Ariadne> panekj: nope :)
2022-07-26 15:24:02 <panekj> other way could be warning on mixing repository sources
2022-07-26 15:24:50 <panekj> 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 <donoban> couldn't be the UNMAINTANED flag saved into APKINDEX? it seems the simplest solution for first case
2022-07-26 15:38:49 <panekj> I was solely speaking about stable/edge mixing
2022-07-26 15:40:47 <ikke> Repos do not really have an identity except by convention
2022-07-26 15:49:16 <Ariadne> 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 <donoban> sounds good
2022-07-26 15:49:57 <Ariadne> something like `apk: the [...] repository ended support at [date]`
2022-07-26 15:50:37 <donoban> but is really need to handle the date?
2022-07-26 15:50:54 <donoban> with just a unmantained flag you could just set it true when a new release come
2022-07-26 15:51:06 <Ariadne> the problem with an `UNMAINTAINED` flag is that it requires someone to actually go and set that flagh
2022-07-26 15:51:09 <Ariadne> -h
2022-07-26 15:51:10 <donoban> and the last apkindex upgrade just sets it
2022-07-26 15:51:21 <Ariadne> while an expiration date can be set in advance
2022-07-26 15:51:27 <donoban> ahh, I understand
2022-07-26 15:52:21 <Ariadne> with apkv3 it is a lot simpler to do
2022-07-26 15:53:13 <Ariadne> donoban: the other thing is, we can set a stale-date on `edge` of a few days
2022-07-26 15:53:25 <Ariadne> so apk nags you to update more frequently :)
2022-07-26 15:53:36 <donoban> another thing that I would like in apk, is that it notifies when a package ugprade contains secfixes
2022-07-26 15:53:46 <Ariadne> that is coming to apk3
2022-07-26 15:53:51 <Ariadne> apk list --upgradable --security
2022-07-26 15:53:55 <donoban> great :D
2022-07-26 15:54:04 <Ariadne> challenge is getting the secdb translated to ADB :)
2022-07-26 15:54:11 <donoban> uhm
2022-07-26 15:54:29 <Ariadne> (ADB is a database format used by apkv3)
2022-07-26 15:54:33 <donoban> can't be the secfixes codes, added to the .apk itself?
2022-07-26 15:54:40 <Ariadne> no
2022-07-26 15:54:51 <Ariadne> we don't want to do it that way
2022-07-26 15:55:04 <Ariadne> we want the APKINDEX to have a reference to the secfixes feed for that repo
2022-07-26 15:55:16 <donoban> I see
2022-07-26 15:55:56 <donoban> yeah otherwise you can't know that some upgade contains secfisex
2022-07-26 15:56:03 <donoban> until you download it :\
2022-07-26 15:56:04 <Ariadne> at the moment, there is /etc/secfixes.d which is an ugly hack
2022-07-26 17:35:35 <psykose> times like these i wish i had a rv64 devboard
2022-07-26 17:35:36 <psykose> weh
2022-07-26 17:37:54 <bl4ckb0ne> i think sifive are supposed to make a new one soon
2022-07-26 17:38:25 <bl4ckb0ne> hifive unmatched is a few years old and more extensions got accepted in the spec
2022-07-26 17:38:29 <psykose> that costs a million dollars
2022-07-26 17:39:14 <bl4ckb0ne> was on mouser for less than a grand
2022-07-26 17:39:20 <bl4ckb0ne> https://www.mouser.ca/ProductDetail/SiFive/HF105-000?qs=zW32dvEIR3vHEV%2FPYYkdMA%3D%3D stock's out tho
2022-07-26 17:41:16 <psykose> indeed a million dollars
2022-07-26 17:42:01 <bl4ckb0ne> almost 
2022-07-26 17:46:23 <psykose> hm
2022-07-26 17:46:28 <psykose> seems the riscv textrels are fake
2022-07-26 17:46:34 <psykose> they're all like this https://bugs.gentoo.org/713082
2022-07-26 17:46:49 <psykose> https://img.ayaya.dev/K9DfLpfsY3hG
2022-07-26 17:46:56 <psykose> just a weird binutils ld bug
2022-07-26 17:47:29 <ikke> psykose: I had a suspicion it was something like that
2022-07-26 17:47:32 <psykose> yep
2022-07-26 17:47:46 <psykose> between cbindgen and nodejs, everything else for firefox on riscv is covered i think :)
2022-07-26 17:47:51 <psykose> hehe
2022-07-26 18:52:10 <psykose> using a different linker fixes the textrels
2022-07-26 18:52:26 <psykose> and then breaks everything else, funnily
2022-07-26 18:52:29 <psykose> /usr/bin/strip: ./usr/bin/stLiDJgo: not enough room for program headers, try linking with -N
2022-07-26 18:52:32 <psykose> god i hate binutils
2022-07-26 22:36:56 <samip537> 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 <ptrc> https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images/-/issues/133
2022-07-26 22:43:44 <ptrc> 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 <samip537> Ah, somehow had missed that in Gitlab. Very easy to do though. :)
2022-07-27 05:38:22 <ptrc> is there a good reason why bison depends on itself for check?
2022-07-27 05:40:10 <ptrc> the commit introducing it is just 'add check', so it confuses me a bit
2022-07-27 05:41:57 <ikke> Maybe it requires an installed bison for checks?
2022-07-27 05:42:02 <ikke> not sure
2022-07-27 05:43:50 <ikke> I see the test suite has a wrapper to use the non-installed bison
2022-07-27 08:41:11 <ncopa> community/vdr source url is broken https://projects.vdr-developer.org/
2022-07-27 08:41:23 <ncopa> invalid cert for some reason
2022-07-27 08:41:51 <ncopa> self signed cert
2022-07-27 10:11:25 <ncopa> meh... community/wezterm testsuite fails
2022-07-27 10:20:20 <donoban> uhM, I got many mandb warnings while upgrading
2022-07-27 10:20:41 <donoban> tons of http://ix.io/45Om
2022-07-27 10:22:18 <panekj> ncopa: mhmm?
2022-07-27 10:25:45 <ikke> 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 <ncopa> 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 <panekj> what it says
2022-07-27 10:29:47 <ptrc> ikke: ah, makes sense :) i guess that's not an issue, since it's usually bootstrapped anyway
2022-07-27 10:30:04 <panekj> there is currently MR open by jirutka to rework whole package and it doesn't fail in CI
2022-07-27 10:40:00 <ncopa> failures:
2022-07-27 10:40:00 <ncopa>     shapecache::test::ligatures_jetbrains
2022-07-27 10:40:11 <ncopa> test result: FAILED. 7 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 3.97s
2022-07-27 10:41:26 <panekj> test shapecache::test::ligatures_jetbrains ... ok
2022-07-27 10:41:41 <ncopa> ncopa-desktop:~/aports/community/wezterm (master)$ abuild check 2>&1 | tpaste
2022-07-27 10:41:41 <ncopa> https://tpaste.us/5k1x
2022-07-27 10:42:03 <panekj> what architecture you are building it on
2022-07-27 10:42:32 <ikke> Expected string to match inline snapshot
2022-07-27 10:42:47 <ikke> num_cells: 2 -> num_cells: 1
2022-07-27 10:42:51 <ncopa> x86_64
2022-07-27 10:51:44 <ncopa> wow, I reached the end of my openssl3 rebuilds for main and community
2022-07-27 11:31:32 <ncopa> 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 <ikke> andypost[m]: ^
2022-07-27 11:40:50 <andypost[m]> ncopa: good question I hope yes
2022-07-27 11:41:21 <andypost[m]> Btw I recall a patch for compatibility 
2022-07-27 11:41:34 <fcolista> 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 <fcolista> 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 <panekj> did you add your paths to .rootbld-repositories?
2022-07-27 11:45:39 <fcolista> panekj, no
2022-07-27 11:45:52 <fcolista> But I never did that
2022-07-27 11:50:18 <andypost[m]> 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 <andypost[m]> I hope to have only php81 and php82 before Dec in community 
2022-07-27 11:51:52 <ncopa> php81 builds fine with openssl3
2022-07-27 11:52:14 <ncopa> ok. lest keep php8 with openssl1.1-compat for now then
2022-07-27 11:54:19 <andypost[m]> ++ as checking compatibility of all dependant could take a while 
2022-07-27 12:02:45 <ncopa> hum.. php8 does not build with openssl1.1-compat. it gets in conflict
2022-07-27 12:03:28 <ncopa> conflict with some of the other dependencies that uses openssl3
2022-07-27 12:04:28 <ncopa> 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 <andypost[m]> I will dig it tonight, maybe we can patch it
2022-07-27 13:03:57 <ddooqq> 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 <andypost[m]> 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 <Ermine> what is analogue of debian's pyqt5-dev-tools in alpine? Is it py3-qt5?
2022-07-27 13:14:21 <ptrc> Ermine: iirc we don't split pyqt packages in alpine, so yeah
2022-07-27 13:21:27 <Ermine> ptrc: thx
2022-07-27 14:31:54 <ncopa> andypost[m]: will try. Thanks!
2022-07-27 15:20:19 <ncopa> some tests fails, but not sure if its due to openssl
2022-07-27 15:24:21 <staceee> hey there ! libxcb-doc man pages fails to be processed. It is known ?
2022-07-27 15:24:24 <staceee> from a day or two
2022-07-27 15:24:45 <staceee> every apk command I got thousand of warnings :D
2022-07-27 15:25:22 <ptrc> someone also mentioned it here
2022-07-27 15:25:49 <ptrc> but the libxcb-doc package wasn't touched since forever
2022-07-27 15:25:52 <Ermine> is it ok if package downloads its go dependenices?
2022-07-27 15:26:17 <ptrc> yeah, currently there's no other way for building go stuff
2022-07-27 15:27:07 <ptrc> ah, i guess i know what's with the docs
2022-07-27 15:27:20 <ptrc> 489527ae4f added mandoc as an alternative provider
2022-07-27 15:28:09 <ptrc> or wait, no
2022-07-27 15:29:45 <ptrc> staceee: what's the result of `apk info --installed cmd:man` for you?
2022-07-27 15:30:09 <staceee> man-db
2022-07-27 15:33:11 <ptrc> ah, so i guess the man-db trigger can't handle that specific package?
2022-07-27 15:33:31 <Hello71> i think man-db is not tested so much, probably most people use mandoc
2022-07-27 15:34:30 <ptrc> well, it's only a warning anyway
2022-07-27 15:34:52 <staceee> I only got docs in world
2022-07-27 15:35:53 <staceee> so if I install mandoc it should works ?
2022-07-27 15:35:56 <ptrc> 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 <staceee> added mandoc and so man-db leaved
2022-07-27 15:36:54 <staceee> but I think some other people will come to warn :D
2022-07-27 17:28:03 <andypost[m]> 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 <andypost[m]> s/the/there
2022-07-27 17:28:15 <alpine-meetbot> 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 <andypost[m]> easier to disable failed test
2022-07-27 18:30:37 <sukrit007> 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 <ikke> There is #alpine-security
2022-07-27 18:31:32 <ptrc> #alpine-security would be a better fit
2022-07-27 18:31:48 <ptrc> but fwiw, this is fixed in alpine: https://security.alpinelinux.org/vuln/CVE-2022-30065
2022-07-27 22:55:46 <psykose> staceee: fixed
2022-07-28 06:21:40 <nmeum> Ariadne: did you have a chance yet to take a look at the gcc 12 upgrade? (:
2022-07-28 06:22:06 <nmeum> 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 <Ariadne> i will get to it today or tomorrow.  also pkgconf 1.9
2022-07-28 06:58:23 <psykose> nmeum: did you have a think about libexecinfo
2022-07-28 06:59:40 <nmeum> 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 <psykose> 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 <nmeum> *nod*
2022-07-28 07:03:01 <ncopa> morning! what about libexecinfo?
2022-07-28 07:03:18 <psykose> it's been broken and meaningless for years and just segfaults if you call it
2022-07-28 07:03:38 <psykose> 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 <ncopa> sort of, yes
2022-07-28 07:04:19 <ncopa> have you tried it without -fomit-framepointer?
2022-07-28 07:04:25 <psykose> so you end up with for example https://gitlab.alpinelinux.org/alpine/aports/-/issues/10896
2022-07-28 07:04:29 <ncopa> or have you tested it on aarch64?
2022-07-28 07:04:30 <psykose> yeah, i've tried a thousand thing
2022-07-28 07:04:37 <ncopa> ok
2022-07-28 07:04:45 <psykose> so then i looked at the 'upstream'
2022-07-28 07:04:52 <psykose> https://www.freshports.org/devel/libexecinfo
2022-07-28 07:04:58 <psykose> and noticed it was just merged into freebsd a millenium ago
2022-07-28 07:05:15 <psykose> and so looking at the description
2022-07-28 07:05:16 <psykose> > A quick-n-dirty BSD licensed clone of the GNU libc backtrace facility
2022-07-28 07:05:26 <psykose> i noticed they just put it into the freebsd monorepo
2022-07-28 07:05:34 <psykose> and so i recloned it from there and ported it again
2022-07-28 07:05:42 <ncopa> i had a look at it a few years ago
2022-07-28 07:05:45 <psykose> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36722
2022-07-28 07:06:01 <psykose> and this version (which also uses libelf), at least doesn't segfault
2022-07-28 07:06:02 <ncopa> and to my understanding it cannot work with -fomit-frampointer
2022-07-28 07:06:11 <psykose> it doesn't work either way
2022-07-28 07:06:16 <psykose> it only works at -O0
2022-07-28 07:06:21 <psykose> (the new one)
2022-07-28 07:06:29 <ncopa> does it work with -g?
2022-07-28 07:06:33 <psykose> the old one always segfaults, and sometimes, with -fno -O0 you may get something
2022-07-28 07:06:34 <psykose> iirc no
2022-07-28 07:06:39 <psykose> i mean i can test it all again if you want
2022-07-28 07:06:41 <psykose> but my conclusion was
2022-07-28 07:06:44 <psykose> 'literally never works'
2022-07-28 07:06:49 <ncopa> yeah
2022-07-28 07:06:55 <psykose> except like 2 scenarios involving -O0 or similar
2022-07-28 07:06:59 <psykose> so generally, never in aports
2022-07-28 07:07:20 <ncopa> also, the usecase where it alsmost alwas is used is for printing backtraces on segfault
2022-07-28 07:07:25 <psykose> this one still doesn't; with any non 0 -O you get 1 frame
2022-07-28 07:07:25 <ncopa> which is bad anyway
2022-07-28 07:07:28 <psykose> but no segfault
2022-07-28 07:07:32 <psykose> yeah, more or less
2022-07-28 07:07:38 <psykose> so, i'm not attached to either solution
2022-07-28 07:07:47 <psykose> but it's better than doing nothing, and rm -rf is also okay
2022-07-28 07:08:02 <psykose> (i will take care of the dependents myself no issue)
2022-07-28 07:08:19 <ncopa> im ok with that
2022-07-28 07:08:51 <ncopa> i have known it for a while, but never bothered enough to actually do anything about it
2022-07-28 07:08:53 <psykose> alright, so +1 on removal instead then? :)
2022-07-28 07:09:00 <ncopa> yup
2022-07-28 07:09:04 <psykose> ack
2022-07-28 07:09:11 <ncopa> just check if there is any valid usecase
2022-07-28 07:09:33 <ncopa> ie. antying that uses is that is not for printing a backtrace in a segfault handler
2022-07-28 07:09:59 <psykose> sometimes it was not a segfault handler but rather a c++ abort handler (and the program continues)
2022-07-28 07:10:16 <psykose> or well, not abort but something similar to that
2022-07-28 07:11:49 <ncopa> hum.. those may be broken then
2022-07-28 07:12:17 <ncopa> there was also a patch for musl requested by fabled, to include some more debug info in musl
2022-07-28 07:12:32 <ncopa> which is requried for beinga ble toing any backtraces at all
2022-07-28 07:12:41 <ncopa> s/toing/doing/
2022-07-28 07:12:41 <alpine-meetbot> ncopa meant to say: which is requried for beinga ble doing any backtraces at all
2022-07-28 07:13:05 <ncopa> which use some other data in elf to be able to do backtrace
2022-07-28 07:13:29 <psykose> well, currently, if you build my forked one
2022-07-28 07:13:41 <psykose> and use it on the sample backtrace program (it's in the repo)
2022-07-28 07:13:49 <psykose> you get stacks with -O0 and don't otherwise
2022-07-28 07:13:57 <psykose> if you want to experiment and make it always print stacks, go for it
2022-07-28 07:14:18 <psykose> (i sadly know nothing of the libc-level requirements or whatnot for this ^^)
2022-07-28 07:14:47 <ncopa> there is also libunwind which to my understanding solves the same issue?
2022-07-28 07:15:18 <ncopa> in any case, stop using libexecinfo as crash handler is correct thing to do anyway
2022-07-28 07:15:23 <psykose> maybe? i dunno
2022-07-28 07:15:26 <psykose> there's like 50 tools for this
2022-07-28 07:15:43 <psykose> but sadly backtrace() is in most libcs and things sometimes use it
2022-07-28 07:16:21 <psykose> also, if you know anything about it, fortify-headers is a little broken with LTO
2022-07-28 07:18:21 <sam_> iirc one of my gsoc students is poking at libexecinfo and modernising it
2022-07-28 07:18:35 <psykose> the one from the freebsd tree?
2022-07-28 07:18:42 <nmeum> do other distros package libexecinfo?
2022-07-28 07:18:55 <nmeum> arch, for example, doesn't even seem to have in their repos
2022-07-28 07:18:57 <psykose> other distros use glibc
2022-07-28 07:19:04 <psykose> backtrace() is in glibc
2022-07-28 07:19:07 <nmeum> ahhh!
2022-07-28 07:19:21 <sam_> i think this one originates from there
2022-07-28 07:19:23 <sam_> nmeum: what psykose said
2022-07-28 07:19:27 <sam_> it's useful for when you don't want to patch a million packages
2022-07-28 07:19:29 <sam_> otherwise i'd not have it at all indeed :(
2022-07-28 07:19:45 <psykose> well.. most of the patches are to link it if you do have it
2022-07-28 07:20:01 <psykose> and usually 'figure out where in cmake to add -lexecinfo' is actually more effort than 'remove backtrace()'
2022-07-28 07:20:04 <psykose> which is funny
2022-07-28 07:20:36 <sam_> seriously
2022-07-28 07:20:53 <psykose> 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 <nmeum> 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 <psykose> the version we have is uh
2022-07-28 07:21:21 <sam_> so bad
2022-07-28 07:21:32 <psykose> random version from 2010 freebsd?
2022-07-28 07:21:34 <psykose> or older
2022-07-28 07:21:41 <nmeum> 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 <psykose> it doesn't get touched much in freebsd either, but this latest one does work
2022-07-28 07:21:56 <ncopa> i didnt know about fortify-headers and LTO
2022-07-28 07:21:59 <psykose> the difference in 'the whole stack is missing' is probably libc side
2022-07-28 07:22:10 <sam_> ncopa: i was considering using it and then it triggered rich into explaining some aliasing problems in it
2022-07-28 07:22:12 <psykose> and freebsd libc probably has it more filled with goodies, so it works fine there
2022-07-28 07:22:15 <nmeum> I think the fortify-headers LTO thing might be a gcc bug
2022-07-28 07:22:15 <sam_> he said it'd be better off rewritten
2022-07-28 07:22:22 <psykose> sam_: i was in the same discussion
2022-07-28 07:22:41 <psykose> certainly could be better; no idea how to rewrite it sadly
2022-07-28 07:22:54 <psykose> #13735 all i've found so far
2022-07-28 07:23:31 <sam_> i can dig out the irc logs later, rich gave a few examples of how to fix it
2022-07-28 07:23:33 <psykose> (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 <sam_> (if you dont have it already)
2022-07-28 07:23:40 <sam_> not read bu-
2022-07-28 07:23:43 <psykose> (i always lose irc logs)
2022-07-28 07:24:04 <nmeum> 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 <psykose> yes
2022-07-28 07:24:19 <sam_> 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 <nmeum> 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 <psykose> i certainly use clang in a lot of places :)
2022-07-28 07:37:12 <psykose> ah, okay, i fixed fortify headers
2022-07-28 07:37:15 <psykose> (for gcc)
2022-07-28 07:37:55 <psykose> 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 <psykose> does this even have an upstream
2022-07-28 07:38:17 <psykose> this 'sin' person around or nah
2022-07-28 08:43:50 <ncopa> long time since I saw him
2022-07-28 10:05:11 <andypost[m]> 
ACTION found no benefits/regressions building php82 with clang, except striping

2022-07-28 10:05:50 <psykose> what stripping
2022-07-28 10:05:51 <andypost[m]> ...and size of -dbg package
2022-07-28 10:06:26 <psykose> if you're referring to before that had nothing to do with clang at all
2022-07-28 10:07:01 <andypost[m]> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10072 yep iirc you found the cause psykose 
2022-07-28 10:07:08 <psykose> :)
2022-07-28 10:07:10 <psykose> easy fix
2022-07-28 10:08:20 <psykose> https://img.ayaya.dev/9Hbp7Z03Lmyh
2022-07-28 10:11:14 <andypost[m]> 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 <andypost[m]> otoh clang evolving faster so challenging to try get benefits
2022-07-28 10:14:38 <andypost[m]> at least for pre-release package
2022-07-28 12:31:28 <psykose> nmeum: i think perhaps you have a point about it maybe being a gcc bug
2022-07-28 13:10:49 <ikke> andypost[m]: You need to make sure packages depepend on concrete packages if they are required during build
2022-07-28 13:11:15 <ikke> andypost[m]: re 27597b1945536b800985e31c25041bd91720efa5
2022-07-28 13:11:55 <ikke> ok, n/m, for composer it doesn't matter, there is no build step
2022-07-28 13:12:04 <ikke> although, for checkdepends it does matter
2022-07-28 13:12:31 <ikke> algitbot: in summary, you should add php<x> to makedepends
2022-07-28 13:12:35 <ikke> or checkdepends in this case
2022-07-28 13:12:44 <ikke> andypost[m]: *
2022-07-28 13:13:39 <ikke> Otherwise it might be built before php and fail for new releases
2022-07-28 13:35:14 <andypost[m]> Yes, I just realized it and filed upgrade 
2022-07-28 13:36:28 <andypost[m]> Checking other depending and gonna switch default to 81
2022-07-28 14:33:22 <psykose> 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 <ncopa> psykose: thats the one
2022-07-28 14:55:05 <psykose> ah, hm
2022-07-28 14:55:15 <psykose> that indeed would not be loaded without gdb to load it in, normally
2022-07-28 14:55:21 <psykose> (meaning stacktraces only in gdb)
2022-07-28 14:55:31 <ncopa> we tried to get it in upstream
2022-07-28 14:55:32 <psykose> but yeah, it was removed, and it was disabled even while it was there
2022-07-28 14:55:33 <psykose> weh
2022-07-28 14:55:42 <ncopa> but upstream didn't want it
2022-07-28 14:55:44 <psykose> (and it only touched x86* code?)
2022-07-28 14:55:45 <psykose> mhm
2022-07-28 14:56:00 <ncopa> i think arm already enables eh-frame by default
2022-07-28 14:56:10 <psykose> makes sense
2022-07-28 14:56:41 <ncopa> which was an argument for why we should enable it on x86* as well
2022-07-28 14:56:59 <psykose> do you have a link to the ML from the time?
2022-07-28 14:57:07 <psykose> i mean, i can already guess the reasoning, but eh
2022-07-28 14:57:57 <psykose> 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 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/22958
2022-07-28 14:59:23 <psykose> > runtime profiling
2022-07-28 14:59:35 <psykose> what kind of profiling is this referring to? (via .eh_frame)
2022-07-28 15:00:04 <ncopa> https://www.openwall.com/lists/musl/2021/07/16/1
2022-07-28 15:01:31 <ncopa> i think it was for optimyze https://prodfiler.com/
2022-07-28 15:02:12 <psykose> ah, so not pgo-level things
2022-07-28 15:03:22 <psykose> > explore the most expensive lines of code and functions across your entire fleet
2022-07-28 15:03:33 <psykose> don't need that for this, i already know 40% of the time is in __unlock /j
2022-07-28 15:06:59 <psykose> hm, seems it implies even libunwind needs this
2022-07-28 15:11:15 <psykose> well, fuck it i guess, i will go patch the dependents
2022-07-28 19:02:11 <andypost[m]> ncopa: php81 is default now 3d38ed46b341
2022-07-29 00:15:57 <psykose> hehe, fun https://sourceware.org/bugzilla/show_bug.cgi?id=28981
2022-07-29 00:16:03 <psykose> why is it always binutils bugs all day long
2022-07-29 00:46:44 <omni> 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 <omni> somewhere during OpenRC boot
2022-07-29 00:53:28 <omni> 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 <psykose> without logs it's hard to guess, strange..
2022-07-29 08:37:21 <ncopa> omni: do you have a way to reproduce it?
2022-07-29 09:28:35 <omni> 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 <omni> but now I just got myself another problem when 'apk -aU upgrade' purged 969 packages..
2022-07-29 09:32:50 <omni> maybe I should add that zfsbootmenu aport after all and give up on syslinux
2022-07-29 11:05:31 <ncopa> 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 <omni> 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 <ncopa> omni: how much memory does your dom0 have? Have you tried to increase it a bit?
2022-07-29 11:09:34 <omni> dom0_mem=12288M (stupid web browsers)
2022-07-29 11:10:54 <ncopa> ok. its probably not running out of memory then
2022-07-29 11:15:00 <omni> no =)
2022-07-29 11:35:32 <ncopa> ok, i have done almost all of the openssl3 rebuilds
2022-07-29 11:36:38 <ncopa> 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 <ncopa> i have also not started with the testing repo, which will end up broken after the push.
2022-07-29 11:38:50 <ncopa> 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 <ncopa> main/pound needs an update, which switch to mbedtls
2022-07-29 11:42:26 <omni> 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 <ncopa> LGTM. is it still a draft? or can we merge it?
2022-07-29 13:30:54 <omni> ncopa: no, not if we're not gonna add anything
2022-07-29 13:30:59 <omni> sorry, had to take a nap
2022-07-29 14:34:07 <omni> 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 <ncopa> great!
2022-07-29 14:34:27 <ncopa> what is the difference?
2022-07-29 14:35:10 <omni> not Dom0 and less modules being loaded at boot, as far as I can tell so far
2022-07-29 14:35:35 <ncopa> ok
2022-07-29 14:35:49 <ncopa> so it might still be a regression for dom0 in .57 kernel
2022-07-29 14:36:33 <omni> yes, I'll try again later and see with less modules and one or two other ideas
2022-07-29 14:36:57 <omni> but I'm still awfully tired, despite the nap
2022-07-29 21:43:05 <omni> 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 <omni> 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 <psykose> ncopa: if you don't feel like doing testing/ , open an MR with all your changes
2022-07-29 22:54:17 <psykose> 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 <psykose> a bit better than you merging what you have and me running after it afterward :p
2022-07-29 22:55:02 <psykose> but you've done enough work as it is, i can continue it ^^
2022-07-30 04:02:45 <ikke> omni: Not sure if related, but I have a system that seems to randomly reboot as well
2022-07-30 04:02:51 <ikke> no freezes though
2022-07-30 04:03:33 <ikke> hmm, linux 5.15.52 though, not 57
2022-07-30 04:32:57 <psykose> ikke: do you feel like giving ptrc the reporter role so she can clean up random issues
2022-07-30 04:33:03 <psykose> (she basically just tells me every time)
2022-07-30 04:33:20 <ikke> heh, I think that should be fine
2022-07-30 04:34:02 <ikke> ✔️
2022-07-30 04:34:10 <ptrc> thanks :3
2022-07-30 07:03:58 <psykose> Ermine: are you sure this trafficserver thing even works?
2022-07-30 07:04:07 <psykose> (i am currently patching out libexecinfo from everything)
2022-07-30 07:04:16 <psykose> and this one is doing some weird shit with the symbols
2022-07-30 07:04:29 <psykose> see include/tscore/Allocator.h:203
2022-07-30 07:06:10 <psykose> 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 <ikke> gcc-cross-embedded is brutal for rv64
2022-07-30 07:07:38 <psykose> yep, always
2022-07-30 07:07:44 <ikke> It's still chugging along
2022-07-30 07:07:56 <psykose> iirc it builds 5 gcc's
2022-07-30 07:08:01 <psykose> i am not sure why it's so much worse emulated
2022-07-30 07:08:09 <ikke> me neither
2022-07-30 07:08:40 <psykose> it's not really something that uses 1 core for long
2022-07-30 07:08:44 <psykose> the rust things are worse for that
2022-07-30 07:08:52 <psykose> doesn't have lto enabled or anything
2022-07-30 07:09:23 <ikke> it's switching from multi-core thigns to single core things regularly
2022-07-30 07:09:42 <psykose> yeah, but not in the sense of there being some very single threaded parts
2022-07-30 07:09:43 <psykose> shrug
2022-07-30 07:10:14 <Ermine> psykose: re trafficserver: not sure
2022-07-30 07:10:38 <psykose> if you want to test it, https://img.ayaya.dev/sCx5XgfFyYz4
2022-07-30 07:13:34 <Ermine> Will try later
2022-07-30 09:03:31 <nmeum> 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 <psykose> yeah, but the relative difference is much bigger compared to the others for some reason
2022-07-30 09:06:43 <psykose> 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 <psykose> which is strange :p but that's all
2022-07-30 09:19:46 <nmeum> 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 <psykose> yeah, agreed
2022-07-30 09:20:46 <psykose> (also z3 fails tests on s390x)
2022-07-30 11:25:05 <ikke> I see no issue was reported yet?
2022-07-30 11:25:14 <ikke> Maybe a big-endian issue?
2022-07-30 11:28:08 <psykose> always is
2022-07-30 11:28:47 <ikke> ahuh
2022-07-30 11:56:18 <ncopa> I've done approx half of testing. I think I will rebase and push on Monday 
2022-07-30 11:56:52 <ikke> openssl 3.0?
2022-07-30 11:57:41 <psykose> could do it now too
2022-07-30 11:57:42 <psykose> :)
2022-07-30 14:27:03 <Ermine> psykose: apparently traffic server works
2022-07-30 14:28:11 <Ermine> I configured a basic forward proxy at least
2022-07-30 14:34:09 <ikke> psykose: linting should be fixed now. Something something subshell
2022-07-30 14:34:23 <psykose> subshell more like subhell
2022-07-30 14:34:25 <psykose> Ermine: nice
2022-07-30 14:39:13 <Ermine> 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 <psykose> yeah, it doesn't work for 0-downtime module upgrade
2022-07-30 15:05:45 <psykose> but works fine for normal restart
2022-07-30 15:27:26 <psykose> ncopa: could you also make an abuild release
2022-07-30 16:14:41 <amirulandalib> Hi
2022-07-30 16:27:11 <psykose> what's up
2022-07-30 16:41:02 <ikke> Do you want me to look up?
2022-07-30 16:58:31 <user2> hello
2022-07-30 16:58:57 <ikke> o/
2022-07-30 16:59:03 <user2> i wanted to know what exactly an 'apkovl' is
2022-07-30 17:00:49 <user2> like from genapkovl-dhcp
2022-07-30 17:01:05 <ikke> It's a mechanism that Alpine uses to persist data on a run-from-ram system
2022-07-30 17:01:40 <ikke> It's generated generally by lbu (local backup)
2022-07-30 17:06:55 <user2> 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 <user2> 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 <ikke> No experience with this myself, so no good idea how to achieve it
2022-07-30 17:46:42 <amirulandalib> https://www.irccloud.com/pastebin/PRfOKJDe
2022-07-30 17:47:02 <ikke> a link to a link, nice
2022-07-30 17:51:28 <psykose> comment out the code
2022-07-30 17:51:30 <Hello71> ah, the old alpine-a-roo
2022-07-30 17:51:53 <psykose> i know exactly where that's from and you can just remove the if
2022-07-30 17:52:00 <psykose> for the first one
2022-07-30 17:52:18 <psykose> for the second, either it's the same or you have to cast something :)
2022-07-30 17:53:07 <Hello71> why is the whole question in bold and half of it in italic
2022-07-30 17:55:07 <psykose> ah, yeah
2022-07-30 17:55:16 <psykose> all 3 of the openssl locking functions in that if are no-ops
2022-07-30 17:56:02 <psykose> (unless i really can't read the headers, i'm tired)
2022-07-30 18:26:12 <Hello71> 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 <added> hi
2022-07-30 19:16:10 <added> http://p4db5azdcwp66cq32w3wgdzhh3af2jtujdy6krf22osradgvmr2pshad.onion
2022-07-30 19:16:37 <ikke> added: looks like spam
2022-07-30 19:16:50 <ikke> any case most people will probably not be able to visit that
2022-07-30 19:29:05 <psykose> it is
2022-07-30 19:29:14 <psykose> seen this same spam lots of times now :)
2022-07-30 19:29:20 <psykose> iirc it wasn't even anything good
2022-07-30 19:29:22 <psykose> really benign
2022-07-30 19:29:29 <psykose> not even hot single :(
2022-07-30 20:03:00 <panekj> it also appeared in #chimera-linux
2022-07-30 21:13:25 <Guest6486> 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 <ikke> Guest6486: make sure your used is in the input group
2022-07-30 21:13:54 <ikke> And there are some others you want to be in as well
2022-07-30 21:13:55 <the6543[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36618
2022-07-30 21:13:56 <the6543[m]> gitea v1.17.0 released 🎉
2022-07-30 21:13:58 <Guest6486> i installed everything from the setup-xorg-base script + xf86-video-modesetting
2022-07-30 21:14:00 <panekj> s/used/user
2022-07-30 21:14:15 <Guest6486> but i havent logged in yet, so lightdm must be a root process right?
2022-07-30 21:15:36 <ikke> it's a service that's running
2022-07-31 02:54:01 <Guest6575> 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 <Guest6575> the keyboard at least works while in tty, just not when i start the xorg session
2022-07-31 03:00:09 <Guest6575> dbus and udevd are both running, if that makes any difference
2022-07-31 03:02:17 <ptrc> you have xf86-input-libinput installed, right?
2022-07-31 03:03:19 <Guest6575> yes
2022-07-31 03:03:39 <Guest6575> 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 <Guest6575> this is what i have installed
2022-07-31 03:04:02 <Guest6575> + alpine standard stuff
2022-07-31 03:09:23 <panekj> vmmouse is for vmware
2022-07-31 03:10:17 <Guest6575> i installed just in case, because i dont have any more ideas on how to make this work
2022-07-31 03:10:38 <panekj> log in via ssh and check logs
2022-07-31 03:31:43 <Guest6575> (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 <Guest6575> these are the weird things from Xorg.log.0
2022-07-31 03:43:47 <Guest6575> yes!!! i got it working
2022-07-31 03:44:00 <Guest6575> i just needed to run setup-devd udev
2022-07-31 11:09:45 <psykose> 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 <Guest6605> 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 <Guest6605> How would you like to use it? ('sys', 'data', 'crypt', 'lvm' or '?' for help) [?] sys
2022-07-31 13:44:43 <Guest6605> ERROR: Failed to create usr/share/syslinux/syslinux.exe: No space left on device
2022-07-31 13:44:45 <Guest6605> ERROR: syslinux-6.04_pre1-r11: No space left on device
2022-07-31 13:46:11 <Guest6605> 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 <panekj> > syslinux.exe
2022-07-31 14:10:31 <Guest6605> 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 <ikke> It's using tmpfs, which is in memroy
2022-07-31 14:11:11 <panekj> you are correct that it does not install it directly onto the storage
2022-07-31 14:11:12 <ikke> memory
2022-07-31 14:11:38 <ikke> 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 <Guest6605> i will try increasing to 2048M
2022-07-31 14:14:20 <Hello71> you may also want to apk add linux-firmware-none
2022-07-31 14:18:30 <hazem> o/
2022-07-31 14:18:56 <Guest6605> it worked now! thanks everyone
2022-07-31 14:19:06 <hazem> 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 <panekj> it definitely wasn't tar.xz
2022-07-31 14:20:12 <psykose> the v2 one is tar.gz
2022-07-31 14:20:17 <psykose> the v3 one is custom
2022-07-31 14:20:41 <hazem> idr tar.xz or gz, circa 2017
2022-07-31 14:21:05 <panekj> currently we use tar.gz as apkv3 is not out yet
2022-07-31 14:21:56 <hazem> 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 <hazem> I believe I have a v2 apk yeah
2022-07-31 14:22:38 <panekj> tar zxvf file.apk
2022-07-31 14:22:59 <hazem> 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 <psykose> i'm pretty sure cat'ing a file into another file is just `cp`
2022-07-31 14:24:32 <hazem> what
2022-07-31 14:24:37 <hazem> cat a b > c
2022-07-31 14:25:06 <psykose> that is very different from the previous sentence :)
2022-07-31 14:25:17 <psykose> ikke: could i just change all the shellcheck rules
2022-07-31 14:25:21 <hazem> omg the pedantry, i suppose the correct word is cat with
2022-07-31 14:25:25 <hazem> :P
2022-07-31 14:25:58 <hazem> anyway, believe it or not, `tar xzf the.apk` that's the first thing i tried
2022-07-31 14:26:08 <ikke> psykose: What do you want to do?
2022-07-31 14:26:24 <panekj> hazem: and what is the problem?
2022-07-31 14:26:24 <psykose> see if it's possible to do the inverse of what it does now
2022-07-31 14:26:30 <panekj> could we just remove shellcheck
2022-07-31 14:26:31 <psykose> enable specific things
2022-07-31 14:26:39 <psykose> because currently half the flags are useless
2022-07-31 14:27:10 <hazem> panekj: tar: This does not look like a tar archive
2022-07-31 14:28:04 <panekj> I remember I disabled some of the rules in aports because...
2022-07-31 14:28:10 <psykose> i just ran `tar -xzf some.apk` and it worked
2022-07-31 14:28:11 <panekj> (for my own git repo :P)
2022-07-31 14:28:29 <panekj> hazem: apk is borked
2022-07-31 14:28:32 <panekj> or it's not proper apk
2022-07-31 14:28:36 <ikke> Many rules are context sensitive and it takes a brain to determine whether it applies or not
2022-07-31 14:28:49 <panekj> stuff is still built with abuild so whatever apkv3 uses doesn't matter
2022-07-31 14:28:54 <psykose> indeed
2022-07-31 14:28:56 <hazem> curious, because apk itself can work with it fine
2022-07-31 14:29:08 <psykose> can u run `file` on it
2022-07-31 14:29:14 <hazem> (i just yolo'd and installed it)
2022-07-31 14:29:36 <panekj> appropriate reaction to software of unknown origin
2022-07-31 14:30:26 <hazem> 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 <psykose> 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 <psykose> hazem: wow, looks like tar -xzf would extract that just fine!
2022-07-31 14:31:02 <hazem> wow but it doesn't!
2022-07-31 14:31:10 <panekj> maybe borked tar
2022-07-31 14:31:22 <psykose> can u take a smartphone screen recording of u running `tar -xzf that.apk`
2022-07-31 14:31:41 <hazem> > assuming im on phone
2022-07-31 14:31:46 <panekj> shell=/bin/ash
2022-07-31 14:31:48 <hazem> the relevant file is this
2022-07-31 14:31:49 <psykose> no, using the camera
2022-07-31 14:31:52 <panekj> disable=SC2034,SC2154
2022-07-31 14:32:00 <hazem> https://github.com/koka-lang/koka/releases/download/v2.4.0/koka-v2.4.0-alpine-x64.apk
2022-07-31 14:32:14 <ikke> it's a pitty shellcheck does not have native ash support
2022-07-31 14:32:17 <hazem> tbf it's from a "trusted" source
2022-07-31 14:32:18 <ikke> so you need to teach ti
2022-07-31 14:32:24 <hazem> so I didn't mind yoloing
2022-07-31 14:32:36 <hazem> re "appropriate reaction"
2022-07-31 14:32:51 <panekj> I didn't deep dived aports for finding more useless rules (:
2022-07-31 14:33:45 <panekj> 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 <hazem> keep going..
2022-07-31 14:34:29 <psykose> the tar is broken
2022-07-31 14:34:35 <psykose> you cant even run tar -xf on the .tar inside
2022-07-31 14:34:47 <hazem> wild, i know
2022-07-31 14:35:03 <panekj> seems like apk doesn't mind borked tarballs
2022-07-31 14:35:37 <hazem> seems so, there's also talk in the wiki about how apk modifies the tar a little bit
2022-07-31 14:35:44 <hazem> to allow concatenation
2022-07-31 14:35:58 <psykose> no, if you apk fetch a random thing you can run tar -xzf on it
2022-07-31 14:36:01 <hazem> so IDK if it's broken or an effect of that
2022-07-31 14:36:04 <psykose> this specifically is just a broken tar
2022-07-31 14:36:35 <hazem> 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 <panekj> Since when apkv3 is supposed to have custom format for .apk?
2022-07-31 14:37:18 <hazem> echoing what's said earlier
2022-07-31 14:37:25 <panekj> I'm asking psykose 
2022-07-31 14:37:41 <ikke> panekj: apkv3
2022-07-31 14:37:45 <psykose> since always
2022-07-31 14:37:46 <ikke> yes
2022-07-31 14:37:50 <psykose> unless i jumped realities again
2022-07-31 14:37:51 <panekj> 
ACTION thinks

2022-07-31 14:38:09 <hazem> I wonder if maintainers are receptive to patches to apk-tools
2022-07-31 14:38:14 <panekj> ikke: yes, the apkv3 will have apkv3 format
2022-07-31 14:38:26 <panekj> 
ACTION the floor here is made out of the floor

2022-07-31 14:38:39 <ikke> panekj: I mean, since apv3, it was the goal to have a custom format
2022-07-31 14:39:40 <panekj> great
2022-07-31 14:39:49 <ikke> Since that was the reason to bump to 3 rather than stay on v2
2022-07-31 14:40:19 <panekj> btw. you don't want to know how koka builds package for alpine
2022-07-31 14:40:28 <panekj> spoiler: ew
2022-07-31 14:40:35 <ikke> 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 <ikke> 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 <psykose> i dunno, i just think it's better if it enforces things that are consistently wrong
2022-07-31 14:44:05 <panekj> 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 <ikke> 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 <panekj> I know
2022-07-31 14:48:35 <panekj> but, IMO, shellcheck is much more usefull if you disable all and whitelist specificc common mistakes
2022-07-31 14:48:44 <ikke> To be effective, you kind of have to write with shellcheck in mind
2022-07-31 14:52:52 <panekj> get rid of /bin/*sh*, shells are a mistake
2022-07-31 14:53:20 <ikke> That's a different discussion :)
2022-07-31 14:53:28 <ikke> one that is already taking place for years
2022-07-31 14:53:49 <ikke> For now, that's what we have
2022-07-31 14:54:06 <panekj> APKBUILD.lua? :P
2022-07-31 14:54:16 <ikke> n please
2022-07-31 14:54:18 <ikke> no please*
2022-07-31 14:56:32 <psykose> >get rid of shells
2022-07-31 14:56:35 <psykose> >likes melange
2022-07-31 14:56:40 <psykose> >entire thing is just shell but in snippets
2022-07-31 14:56:41 <psykose> hmmmmmmm
2022-07-31 14:56:55 <panekj> you haven't seen my tweet where I praised YAML
2022-07-31 14:56:59 <psykose> i have
2022-07-31 14:57:02 <panekj> o
2022-07-31 14:57:05 <panekj> (:
2022-07-31 14:57:51 <ikke> I think Ariadne is waiting for cuelang to be considered production ready
2022-07-31 14:57:57 <ikke> https://cuelang.org/
2022-07-31 14:58:06 <panekj> building things out of blocks is better than rewriting same things in all files
2022-07-31 14:58:19 <ikke> panekj: yes and no
2022-07-31 14:58:38 <psykose> sometimes yes, sometimes no
2022-07-31 14:58:47 <panekj> it may and may not be
2022-07-31 14:59:13 <Ariadne> i don't think it is realistic to convert alpine to use melange
2022-07-31 14:59:25 <Ariadne> also, some of the melange pipelines are too inflexible
2022-07-31 14:59:26 <panekj> re: cue, no rust bindings :(
2022-07-31 15:00:08 <ikke> gentoo's eclasses come to mind
2022-07-31 15:00:14 <psykose> the best part of pipelines is they expose the internals
2022-07-31 15:00:31 <psykose> instead of relying on whatever abuild has defined and optionally overriding the function, it's just the pipeline
2022-07-31 15:00:32 <Ariadne> melange pipelines are literally the opposite of eclasses
2022-07-31 15:00:33 <psykose> aside from that, yeah
2022-07-31 15:01:27 <Ariadne> eclasses: you import them and then ✨ stuff happens ✨
2022-07-31 15:01:36 <Ariadne> melange pipelines: you have to ask for them explicitly
2022-07-31 15:01:54 <psykose> 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 <psykose> in abuild you have to override unpack() and guess where the directories are
2022-07-31 15:02:27 <psykose> it's both shell and more or less the same, just composed differently
2022-07-31 15:02:43 <psykose> (and nothing like eclasses)
2022-07-31 15:02:44 <Ariadne> (improving the fetch pipeline is welcome of course)
2022-07-31 15:03:03 <panekj> it can be improved to not be limited to tar.gz only :P
2022-07-31 15:03:30 <psykose> (improvement 1: make it curl /s)
2022-07-31 15:03:48 <Ariadne> technically with busybox tar, it supports anything busybox itself supports out of the box
2022-07-31 15:03:54 <Ariadne> because its all libarchive under the hood :p
2022-07-31 15:04:08 <panekj> I've dabbled into melange pipelines, but didn't have time to upstream
2022-07-31 15:04:15 <psykose> `busybox tar -zxf` fails on .xz
2022-07-31 15:04:20 <psykose> if you remove the -z it does though
2022-07-31 15:04:21 <psykose> haha
2022-07-31 15:05:06 <Ariadne> anyway there are pros and cons to both approaches
2022-07-31 15:05:10 <psykose> 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 <panekj> habit
2022-07-31 15:05:22 <panekj> for me
2022-07-31 15:05:37 <psykose> the gnu one works with zst too iirc, didn't test libarchive
2022-07-31 15:06:34 <Ariadne> melange was also designed to integrate into a platform that is already pipeline-oriented
2022-07-31 15:06:44 <Ariadne> e.g. tekton
2022-07-31 15:07:05 <Ariadne> so having something that matched the mental model users were already used to was a primary goal
2022-07-31 15:09:09 <hazem> how many melanges are out there these days
2022-07-31 15:09:20 <hazem> there's the one for alpine
2022-07-31 15:09:28 <hazem> there's the bucklescript fork
2022-07-31 15:10:15 <hazem> there's the language workbench
2022-07-31 15:24:33 <Ariadne> melange is not "for alpine"
2022-07-31 15:49:32 <user2> is there a reason why setup-alpine does this?
2022-07-31 15:49:34 <user2> $MOCK openrc boot
2022-07-31 15:49:35 <user2> $MOCK openrc default
2022-07-31 15:49:51 <user2> are these services not already started when i booted the iso?
2022-07-31 15:50:42 <user2> 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 <user2> it makes lightdm restart too in my case, stopping the setup if ran outside a tty
2022-07-31 18:47:55 <user2> 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 <user2> # start up the services
2022-07-31 18:47:58 <user2> $MOCK openrc boot
2022-07-31 18:48:00 <user2> $MOCK openrc default
2022-07-31 18:49:01 <user2> 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 <psykose> could open an issue in alpine-conf
2022-07-31 18:55:58 <ikke> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues
2022-07-31 18:57:18 <user2> 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 <user2> maybe i could replace it with something like echo to ignore the openrc lines
2022-07-31 18:57:53 <user2> and without modifying the script
2022-07-31 18:57:53 <ikke> user2: For testing purposes
2022-07-31 18:58:27 <user2> so overwriting it shouldnt be a problem
2022-07-31 18:59:23 <psykose> the other scripts that get called after use MOCK for even more things
2022-07-31 18:59:40 <psykose> you'll more or less install nothing if you call setup-alpine with MOCK=echo or whatever
2022-07-31 19:00:00 <user2> MOCK=checkifopenrc setup-alpine
2022-07-31 19:00:13 <user2> then i export a function that checks if next parameter is openrc ?
2022-07-31 19:00:19 <psykose> patching two lines sounds much easier
2022-07-31 19:00:50 <user2> it seems that /sbin is not writeable from the genapkovl script, im still testing though
2022-07-31 19:16:17 <user2> 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 <user2> where else would i put my scripts
2022-07-31 20:30:19 <psykose> hm, for some reason clang on riscv cannot use -flto
2022-07-31 20:30:30 <psykose> no lto is fine, gcc is fine with any options
2022-07-31 20:31:38 <psykose> error is quite meaningless, though it does point to things
2022-07-31 20:31:42 <psykose> /usr/bin/ld: /tmp/lto-llvm-053b83.o: can't link soft-float modules with double-float modules
2022-07-31 20:32:05 <psykose> save-temps'ing the object and reading it with readelf -h has the double-float ABI flag missing
2022-07-31 20:32:12 <psykose> not sure why that would happen in lto mode only
2022-07-31 20:33:07 <psykose> (every object everywhere has that flag with gcc or without lto at any phase of anything)
2022-07-31 20:35:01 <sam_> not gcc 12 right
2022-07-31 20:35:24 <psykose> 11
2022-07-31 20:35:37 <psykose> but i mean it works fine, clearly some weird clang bug
2022-07-31 20:35:46 <psykose> strangely i can't find anything wrong reading any part of clang..
2022-07-31 20:36:06 <psykose> it must mean it doesn't use -mabi=lp64d with -flto and instead just lp64, but why
2022-07-31 20:36:16 <sam_> oh ok, I asked b/c of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106129
2022-07-31 20:36:18 <psykose> well, passing -mabi=lp64d actually doesn't fix it
2022-07-31 20:36:22 <sam_> (options got dropped for LTO sometimes)
2022-07-31 20:36:37 <psykose> oh wow, not even fixed in 12.1.1
2022-07-31 20:36:49 <psykose> but yeah looks like unrelated breakage of mostly the same thing
2022-07-31 20:36:57 <psykose> this is definitely clang/llvm specific
2022-07-31 20:37:25 <psykose> i found this out because i am trying to build firefox on riscv, don't ask
2022-07-31 20:37:43 <psykose> (all the dependencies are now satisfied)
2022-07-31 20:38:01 <psykose> i can also try without lto i guess
2022-07-31 20:40:47 <user2> you have a riscv processor?
2022-07-31 20:41:00 <psykose> nah, just emulation
2022-07-31 20:41:10 <user2> oh ok
2022-07-31 20:44:39 <psykose> 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 <user2> just found out about login.d
2022-07-31 21:41:38 <user2> that thing is a life saver
2022-07-31 21:41:51 <user2> now i can "bypass" all the restrictions from the genapkovl file
2022-07-31 23:52:59 <user2> oops i meant local.d